很多佬友以为开了代理就可以万事大吉的在本地使用某些应用，但现实是一些应用在节点正常的情况下请求失败、偶发5xx，严重的甚至被封号，除了IP的问题(这个占主要原因)，还有一个容易被忽略的地方就是：虽然HTTP/HTTPS 走了代理，DNS 却出了问题，露出了小鸡脚（尤其在使用 Claude / OpenAI / Codex / Gemini 这类应用时）。
这篇帖子想带着大家了解DNS是怎么泄露的以及应该如何解决。
1. 先确认自己“有没有露出鸡脚”
建议在修改前、修改后各测一次。包括：
- IP 泄露：页面显示的出口 IP 是否为代理出口（https://ipleak.net，https://browserleaks.com/ip，https://whatismyipaddress.com/）
- DNS 泄露：检测结果里的 DNS 服务器归属是否仍显示本地 ISP / 本地地区（https://dnsleaktest.com，https://browserleaks.com/dns）
贴一张我自己没修改前的，靠北啦，怪不得AI降智
2. 请开启TUN模式
很多客户端/服务并不严格遵循系统代理（尤其涉及 UDP/QUIC、系统服务、某些桌面应用、或应用内部自带网络栈的情况）。这会导致你以为“流量都走了代理”，实际上仍可能存在绕行。而TUN 的意义是：减少绕过代理栈的机会，在网络层统一接管。
3. Clash中的DNS 覆写是个什么东西
DNS 泄露的典型形态是：
访问网站的连接走代理，但域名解析（DNS 查询）仍走本地网关/ISP。
所以“防 DNS 泄露”的核心不是换节点，而是做到两点：
- DNS 查询入口被 Clash 接管（系统/应用问 DNS 时，问到的是 Clash，关闭系统代理，开启TUN模式）
- Clash 的上游 DNS 不走 system/ISP（否则等于把查询又交回本地，覆写DNS）
下面我们来详细看看DNS覆写
4. DNS 覆写中的一些关键字段解释
下面以 Clash / Clash Meta 系的常见字段为语义解释（GUI 名称可能略有差异，但逻辑大差不差）。
4.1 DNS 入口相关
启用 DNS 开启后 Clash 会提供本地 DNS 服务；不开启通常意味着系统继续使用原来的 DNS（常见就是 ISP），泄露风险直接拉满。
DNS 监听地址 Clash 在哪个地址/端口上提供 DNS 服务（常见 :53）。如果端口被占用、监听失败，系统仍可能回退到原 DNS；这类问题很隐蔽，表现为“我明明配置了，但检测还是 ISP DNS”。
4.2 解析方式相关
增强模式 最常见的是 fake-ip。它的思路是：Clash 对域名返回一个“假 IP”，后续连接再由 Clash 接管映射到真实目标。 对防泄露而言，fake-ip 的优势是 纳管强、路径更可控，配合 TUN 往往最稳。代价是：极少数局域网/特殊域名可能需要加入 fake-ip-filter 以避免兼容问题。
Fake IP 范围 只是“假 IP 池”的网段范围，通常默认值即可（除非与你局域网网段冲突）。
Fake IP 过滤 用于声明哪些域名不要走 fake-ip（例如 .lan、.local、部分系统探测域名等）。目的通常是兼容性与减少奇怪的本地网络问题，而不是“提升安全性”。 推荐用 blacklist 思路：只把确实需要排除的域名放进去即可。
4.3 上游 DNS 相关
这是最容易踩坑、也最决定“会不会泄露”的部分。
默认域名服务器 用于“先解析上游 DNS 的DNS服务器”。比如你填了 https://dns.google/dns-query，那 Clash 也得先知道 dns.google 的 IP 才能连上它——这一步就靠 default-nameserver。如果这里填 system 或 ISP DNS，就可能在“第一跳”就把域名暴露给本地。因此这里最好填可靠的公共 IPv4 DNS（不要 system），例如 1.1.1.1 / 8.8.8.8 这类；你也可以放多个做冗余。
域名服务器 真正负责日常解析的上游 DNS。这里推荐优先使用 加密上游（DoH/DoT），因为它能降低本地网络侧窥探/劫持的概率，也更符合“可控出口”的目标。可填写tls://1.1.1.1:853, tls://dns.google:853
回退服务器 当主 nameserver 不可用或不满足条件时用于回退。很多人的 DNS 泄露就出在这里：fallback 指向了 system / ISP，导致“平时看起来没事，偶发就泄露”。 如果你要用 fallback，最稳的策略是：fallback 也只放加密上游，不要放 system/ISP。
代理节点DNS 用于解析“代理节点本身的域名”（很多机场节点是域名形式）。如果这里走 system/ISP，你的“代理节点域名”可能暴露给本地 DNS（常听到的域名被污染就是因为有用户这里设置的有问题）；同时也可能导致连节点慢、切换不稳定。
直连域名服务器 当某些流量被判定为 DIRECT 时，用哪个 DNS 解析。这里本质是隐私与体验的权衡：
- 用本地/ISP：可能更“就近”，但域名可见性更高
- 用加密公共 DNS：隐私更好，但个别场景可能不如 ISP 就近 如果你的目标是“尽量不泄露”，建议 direct-nameserver 也使用加密上游，但这样速度可能会变慢。
4.4 其余设置
域名服务器策略、回退过滤设置、Hosts设置等保持默认即可
4.5 旁路风险相关
IPv6 开关（ipv6） 如果你的代理链路/节点对 IPv6 支持不完整，IPv6 非常容易成为旁路，出现“我明明开了代理但检测仍能看到本地信息”的现象。 不确定就关：禁用 IPv6 是降低泄露概率最直接的手段之一。
prefer-h3 / HTTP3 主要是性能/兼容性取舍，在一些网络环境下 QUIC 更容易不稳定。稳妥起见可以先关。
respect-rules（遵循路由规则） 让 DNS 的出站策略与规则更一致。对“防泄露”来说，它不是第一优先级：更关键的是不要让任何上游指向 system/ISP。上游安全了，respect-rules 的风险面会小很多。
5. 一套“通用且稳妥”的落地建议
如果你主要目标是：使用 Claude/OpenAI/Codex/Gemini 这类应用时尽量不发生 DNS 泄露，可以按这个顺序做：
- 启用 TUN（优先保证流量纳管）
- DNS 覆写启用，增强模式选 fake-ip
- 禁用 IPv6（避免旁路）
- 上游 DNS 全部避免 system/ISP：
- default-nameserver：用可靠公共 IPv4 DNS（不要 system）
8.8.8.8, 1.1.1.1 - nameserver：优先 DoH/DoT
tls://1.1.1.1:853, tls://dns.google:853 - fallback：如需启用，也只放 DoH/DoT（不要 system/ISP）
tls://1.1.1.1:853, tls://dns.google:853 - proxy-server-nameserver / direct-nameserver：尽量与 nameserver 保持一致（减少分叉与意外出口）
最后回到第 1 节：改后再测一次 IP 与 DNS。
修改完之后变成了这样，又可以愉快的玩耍了 
6. 常见踩坑提醒
- 上游里出现
system/ 本地 ISP：把 default-nameserver / fallback / direct-nameserver 留成223.5.5.5, 119.29.29.29或doh.pub / alidns，然后检测必然出现中国 DNS，这不是泄露，是“你配置的上游就是国内”。 - fallback 指向 ISP：最隐蔽的“偶发泄露”来源
- TUN 未启用：部分应用不走系统代理，配置形同虚设
- IPv6 未禁用：IPv6 旁路非常常见
- DNS 监听失败（端口占用）：你以为覆写了，其实系统还在用原 DNS
- 览器启用了“安全 DNS / DoH”，绕过 Clash，Chrome/Edge/Firefox 可能启用 Secure DNS（DoH），这会让浏览器直接用它自己的上游（可能自动选了国内），绕过系统/Clash。关闭浏览器的 Secure DNS 或 把浏览器 Secure DNS 指定到你想要的（例如 Cloudflare/Google/Quad9）。
最后，给使用 AI 应用的建议
如果你只想要一个“够稳、够通用”的答案：
使用 Claude / OpenAI / Codex / Gemini 等应用时：开 TUN + 开 DNS 覆写（fake-ip）+ 禁 IPv6 + 上游 DNS 不用 system/ISP；改前改后各做一次 DNSLeakTest 验证。
以上，希望大家都能愉快玩耍~
