这是一个创建于 261 天前的主题，其中的信息可能已经有所发展或是发生改变。
使用 openclash 代理路由器中的请求，此时 openclash 是如何知道请求的域名是什么的？ 我一台电脑请求某个网站，浏览器直接先请求 DNS 解析完域名，得到了 IP ，再丢给路由器，此时路由器层面不是只能拿到 ip 吗,那匹配域名的规则又是如何生效的呢？请大佬们帮忙解惑一下
第 1 条附言 · 261 天前
更新一下背景：
我所描述的网络请求路径是 电脑 ——> 路由器 ——> 互联网。openclash 作为路由器的插件拦截请求流量。且 openclash 用的是 clash 内核（非 meta 内核）
我所描述的网络请求路径是 电脑 ——> 路由器 ——> 互联网。openclash 作为路由器的插件拦截请求流量。且 openclash 用的是 clash 内核（非 meta 内核）
第 2 条附言 · 261 天前
感谢各位留言，经过一段时间的研究，大概搞清楚标题提出的问题了，总结如下：
Openclash 有两种内核可以使用，分别是 clash 和 clash-meta （ clash 的二次开发）
Clash 内核会被强制使用 fake-ip 模式，主要就是为了反解析域名（看了源码这块是做了映射缓存），其原理参考官方文档。（通过 fake-ip-filter 也可以实现透明代理）
Clash-meta 可以激活 redir-host 模式，即透明代理模式，但如果它要实现获取域名，得开启 Sniffer 嗅探，参考文档
Openclash 有两种内核可以使用，分别是 clash 和 clash-meta （ clash 的二次开发）
Clash 内核会被强制使用 fake-ip 模式，主要就是为了反解析域名（看了源码这块是做了映射缓存），其原理参考官方文档。（通过 fake-ip-filter 也可以实现透明代理）
Clash-meta 可以激活 redir-host 模式，即透明代理模式，但如果它要实现获取域名，得开启 Sniffer 嗅探，参考文档
 |
1
lxtyr 261 天前
dnsmasq 了解一下
|
 |
2
tony1016 261 天前
如果你是浏览器代理，则浏览器会发送域名到代理；如果你是 TUN ，则强奸着你的 DNS 访问
|
 |
3
scegg 261 天前
clash 与 meta 的方式不同。openclash 只是个壳。你得明确一下是哪种先。
clash 用的是 fakeip ，meta 用的是 SNI 嗅探。 |
 |
4
long1and 261 天前
如果 OP 是像我一样，自建了另一个 DNS 解析服务器，不使用 openclash 的 dns 解析服务，那 openclash 的域名规则是不生效的。clash 的 dns 解析和代理是分开的。
|
 |
5
misaka19000 261 天前 via Android
因为你解析 dns 的请求被它拦截了
|
 |
6
yunyuyuan 261 天前
如果按照你说的，那 openclash 并不知道请求的域名是什么，看看日志就知道了。正确设置是电脑的 dns 设置为路由器，路由器 dnsmasq 再转到 clash 的 dns
|
 |
7
MeteorVIP 261 天前 via iPhone
因为是浏览器告诉他的
|
 |
8
AoEiuV020JP 261 天前
所以用 fakeip ，更准，简单说就是拦截所有 dns 请求，都返回一个个假的 ip ，下次收到 ip 请求就知道域名了，
反过来终端这边开 doh/dot 之类的话 openclash 日志就只能看到一堆 ip 了， |
 |
9
donnieYeh OP @lxtyr 多谢指点，我看了下 dnsmasq 算是路由器系统层面的 dns 代理，经过梳理，代理流程可以理解为：
1 。解析 DNS： 浏览器 -> 路由器 -> dnsmasq -> openclash -> 上游 DNS 服务器 2 。请求网页：浏览器（这次只会提供 IP ） -> 路由器 -> openclash 除非说 openclash 会缓存 ip 和域名的关系，不然在第 2 步也没法获取到域名，从而执行域名匹配规则。这块还是比较模糊 |
|
10
donnieYeh OP |
 |
11
tutou 261 天前
建议油管上看几个视频就明白了，有几个 up 主讲的和上课一样
|
 |
12
lsdsjy 261 天前
https://blog.skk.moe/post/what-happend-to-dns-in-proxy/ 可以参考这篇文章
如果我理解得没错，设置了代理之后浏览器不一定会把解析 DNS 和请求网页拆成两个独立的步骤，而是全部交给本地的代理服务器 |
 |
13
jujusama 261 天前
重定向 53 到监听的 dns 端口，不拦截的话只能 SNI 嗅探
|
 |
16
xiaooloong 261 天前  1
客户端挂了正向代理的情况，会直接把域名和端口交给代理服务器去连接
透明代理有两种情况。 第一种情况，clash 维护一个 dns-ip 映射表，客户端请求 dns 时 clash 记录了这个表的关系，等到目标 ip 的流量进来再反查这个表就可以知道域名了 第二种情况就比较简单了，tls 协议 client hello 里面一般都会有 sni 表示连接的域名，方便 server hello 的时候发对应域名的证书给客户端。 |
 |
17
yaott2020 261 天前 via Android
如果你选择 tproxy/tun ，你不是和远程服务器建立连接，而是先和 clash 建立连接，并且 clash 会嗅探第一个包，看看是什么协议，tls/http/quic 还是其他的，如果匹配到了，就可以根据域名分流，否则只能 ip 分流。
|
|
18
yaott2020 261 天前 via Android
如果你使用 fake-ip ，那么 clash 会在你查询 dns 的时候就建立好了 ip--域名的映射关系，流量一过，直接就可以知道
|
|
19
yaott2020 261 天前 via Android
如果你使用 socks5/http 代理，代理协议会直接把域名发送到远程，无需嗅探就可以知道
|
 |
20
liofoil 260 天前 1
@donnieYeh 标准的 clash 内核无论 fakeip 和 redir-host 会缓存 dns 和域名的映射的，并不是会执行嗅探。
clash 自己作为一个 dns 服务器，设置为 dnsmasq 的上游，有 dns 请求过来，dnsmasq 给到 clash ，clash 向自己配置文件里设置的 dns 查询域名对应 ip ，并建立映射表。 1 ） redirhost 直接把查到的 ip 给设备，设备按照这个 ip 发起连接，clash 反推域名分流，向代理服务器发起请求的时候不带域名，因此代理服务器看到的是 ip ，这是为了防止多个域名解析到同一个 ip 导致 clash 反推失败，但正因为请求的是 clash 自己本地查到的 ip ，所以会有几率出现 dns 污染或者 cdn 不匹配的情况。 2 ） fakeip 则是返回一个假的 ttl 很短的 ip 给设备，设备按照这个 ip 发起连接，clash 反推域名，并且直接请求这个域名，代理服务器拿到的是域名，这样可以避免 dns 污染，但是一些基于 udp 的服务会变得不正常，尤其是部署在路由器级别的设备上时，fakeip 的兼容性不是很理想。 |
|
21
liofoil 260 天前
要点在于一定要把 dns 设置成递归结构，设备，dnsmasq ，openclash ，里面有一个环节断了，在不开劫持的情况下就会导致 clash 面板里只有 ip ，本质是因为没建立映射表
|
|
23
liofoil 257 天前
@donnieYeh 这个是我和一些同样在使用此工具的人在实际使用中发现的，具体原理不太能解释。表现为：有些基于 udp 的联机游戏会连不上，尤其一些利用 p2p 的游戏； facebook 或者 instagram 等软件喜欢把 dns 的 ttl 手动改长，而且这些软件会使用 udp 进行数据传输，这就导致下一次连接时还会向之前给的那个 fakeip 传数据，但是由于 fakeip 在 clash 那里的 ttl 非常短，clash 早就已经把那个 fakeip 映射至别的域名了，或者没有分配，这就会导致一些错误。
|
 |
25
wcnmm 210 天前
@liofoil 我也遇到了些怪事，steam 连接游戏服务器 udp 异常。openclash 关闭是能连通的 。打开 openclash 情况下 游戏内获取的服务器 ip+端口 与 openclash 的日志端口不一致，如 1.1.1.1:12345 而日志里的却是 1.1.1.1:10003 ，他们都命中了 Geoip:CN 规则 我想应该不是分流的问题。我试了 Redir-Host Fake-ip 以及域名嗅探 Primuim 和 Meta 内核 都未能解决
以前裸装 openclash 没遇到过，现在我想想也许是套娃多了 adg→clash→mosdns 回去再调调试试。之前没有头绪 但是一评论就有点想法了 还是得动起来啊 哈哈 顺便再请教两个问题，我在 dashboard-meta 面板中看到的域名嗅探都为空，无论是 Fake-ip 还是 Redir-Host 配合域名嗅探 都不行，说一句题外话，似乎没有人用 Fake-ip+sniffing 的 应该是 fake-ip 已经分流过一次了，再多此一举浪费时间。 第二个问题是 不考虑协议和其他功能，P 核和 M 核哪一种性能更优？同一个配置文件 P 核的连通性似乎高一点，别的节点延迟也低 100 左右。但是我还是在用 M 核（ 我回去先把 adg 下了再试试吧 这些都是我的胡乱猜想，有不对的请指正 |
|
26
wcnmm 210 天前
@liofoil https://www.v2ex.com/t/951618 很喜欢 fake-ip 的低延迟 但是搜了一圈 确实是问题多多 特别是 UDP
|
Select Language