OpenClash 是如何知道请求的域名是什么的?

dnsmasq 了解一下

如果你是浏览器代理，则浏览器会发送域名到代理；如果你是 TUN ，则强奸着你的 DNS 访问

clash 与 meta 的方式不同。openclash 只是个壳。你得明确一下是哪种先。

clash 用的是 fakeip ，meta 用的是 SNI 嗅探。

如果 OP 是像我一样，自建了另一个 DNS 解析服务器，不使用 openclash 的 dns 解析服务，那 openclash 的域名规则是不生效的。clash 的 dns 解析和代理是分开的。

因为你解析 dns 的请求被它拦截了

因为是浏览器告诉他的

所以用 fakeip ，更准，简单说就是拦截所有 dns 请求，都返回一个个假的 ip ，下次收到 ip 请求就知道域名了，
反过来终端这边开 doh/dot 之类的话 openclash 日志就只能看到一堆 ip 了，

@lxtyr 多谢指点，我看了下 dnsmasq 算是路由器系统层面的 dns 代理，经过梳理，代理流程可以理解为：

1 。解析 DNS： 浏览器 -> 路由器 -> dnsmasq -> openclash -> 上游 DNS 服务器
2 。请求网页：浏览器（这次只会提供 IP ） -> 路由器 -> openclash

除非说 openclash 会缓存 ip 和域名的关系，不然在第 2 步也没法获取到域名，从而执行域名匹配规则。这块还是比较模糊

@tony1016
抱歉我没说清楚，就是我用的软路由进行代理，openclash 是装在路由器，而不是装在电脑本机

@scegg
我看了一下，我的配置里没有勾选“使用 Meta 内核”，按你的意思，我说的这种场景用 redir-host 模式不就没法正常匹配域名了吗

建议油管上看几个视频就明白了，有几个 up 主讲的和上课一样

https://blog.skk.moe/post/what-happend-to-dns-in-proxy/ 可以参考这篇文章

如果我理解得没错，设置了代理之后浏览器不一定会把解析 DNS 和请求网页拆成两个独立的步骤，而是全部交给本地的代理服务器

重定向 53 到监听的 dns 端口，不拦截的话只能 SNI 嗅探

@donnieYeh
clash 不支持 redir-host 。

@scegg
我也发现了，感谢指点，已经搞清楚了

客户端挂了正向代理的情况，会直接把域名和端口交给代理服务器去连接
透明代理有两种情况。
第一种情况，clash 维护一个 dns-ip 映射表，客户端请求 dns 时 clash 记录了这个表的关系，等到目标 ip 的流量进来再反查这个表就可以知道域名了
第二种情况就比较简单了，tls 协议 client hello 里面一般都会有 sni 表示连接的域名，方便 server hello 的时候发对应域名的证书给客户端。

如果你选择 tproxy/tun ，你不是和远程服务器建立连接，而是先和 clash 建立连接，并且 clash 会嗅探第一个包，看看是什么协议，tls/http/quic 还是其他的，如果匹配到了，就可以根据域名分流，否则只能 ip 分流。

如果你使用 fake-ip ，那么 clash 会在你查询 dns 的时候就建立好了 ip--域名的映射关系，流量一过，直接就可以知道

如果你使用 socks5/http 代理，代理协议会直接把域名发送到远程，无需嗅探就可以知道

@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 的兼容性不是很理想。

要点在于一定要把 dns 设置成递归结构，设备，dnsmasq ，openclash ，里面有一个环节断了，在不开劫持的情况下就会导致 clash 面板里只有 ip ，本质是因为没建立映射表

@liofoil 请教一下为何在 fakeip 模式下“基于 udp 的服务会变得不正常”？这一块不太理解

@donnieYeh 这个是我和一些同样在使用此工具的人在实际使用中发现的，具体原理不太能解释。表现为：有些基于 udp 的联机游戏会连不上，尤其一些利用 p2p 的游戏； facebook 或者 instagram 等软件喜欢把 dns 的 ttl 手动改长，而且这些软件会使用 udp 进行数据传输，这就导致下一次连接时还会向之前给的那个 fakeip 传数据，但是由于 fakeip 在 clash 那里的 ttl 非常短，clash 早就已经把那个 fakeip 映射至别的域名了，或者没有分配，这就会导致一些错误。

@liofoil 确实是，我改成 fakeip 后，就连不上黑魂 3 的服务器了，蛋疼

@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 下了再试试吧 这些都是我的胡乱猜想，有不对的请指正

@liofoil t/951618 很喜欢 fake-ip 的低延迟 但是搜了一圈 确实是问题多多 特别是 UDP

@wcnmm 虚拟机搞了个旁路由测试出来 其实是修改网络栈导致的 gvisor 导致了游戏服务器端口不一致问题 但是 meta 的域名嗅探还是没有 不过我还是挺好奇的 为什么作为旁路由同网段 openclash 也会代理，我还以为他只会代理 DHCP 过的设备

很有意思的问题，最近在 openwrt 下 surge 开直连上不了外网，发现就是因为 surge 走了 doh 导致 openclash 识别不出域名，meta 内核开启 sni 嗅探就可以了