很多佬友以为开了代理就可以万事大吉的在本地使用某些应用，但现实是一些应用在节点正常的情况下请求失败、偶发 5xx，严重的甚至被封号，除了 IP 的问题 (这个占主要原因)，还有一个容易被忽略的地方就是：虽然 HTTP/HTTPS 走了代理，DNS 却出了问题，露出了小鸡脚（尤其在使用 Claude / OpenAI / Codex / Gemini 这类应用时）。

声明：为兼顾相关名词解释的专业性和可理解性，部分名词解释由GPT+Gemini给出。

先确认自己 “有没有露出鸡脚”

建议在修改前、修改后各测一次。包括：

• IP 泄露：页面显示的出口 IP 是否为代理出口（https://ipleak.net，https://browserleaks.com/ip，https://whatismyipaddress.com/）
• DNS 泄露：检测结果里的 DNS 服务器归属是否仍显示本地 ISP / 本地地区（https://dnsleaktest.com，https://browserleaks.com/dns）
  
  
  
  贴一张我自己没修改前的，靠北啦，怪不得 AI 降智

开启 TUN 模式

很多客户端 / 服务并不严格遵循系统代理（尤其涉及 UDP/QUIC、系统服务、某些桌面应用、或应用内部自带网络栈的情况）。这会导致你以为 “流量都走了代理”，实际上仍可能存在绕行。而 TUN 的意义是：减少绕过代理栈的机会，在网络层统一接管。

Clash 中的 DNS 覆写是个什么东西

DNS 泄露的典型形态是：

访问网站的连接走代理，但域名解析（DNS 查询）仍走本地网关 / ISP。

所以 “防 DNS 泄露” 的核心不是换节点，而是做到两点：

1. DNS 查询入口被 Clash 接管（系统 / 应用问 DNS 时，问到的是 Clash，关闭系统代理，开启 TUN 模式）
2. Clash 的上游 DNS 不走 system/ISP（否则等于把查询又交回本地，覆写 DNS）

下面我们来详细看看 DNS 覆写

DNS 覆写中的一些关键字段解释

为保证专业性和可理解性，部分名词解释由大模型辅助生成

下面以 Clash / Clash Meta 系的常见字段为语义解释（GUI 名称可能略有差异，但逻辑大差不差）。

启用 DNS 开启后 Clash 会提供本地 DNS 服务；不开启通常意味着系统继续使用原来的 DNS（常见就是 ISP），泄露风险直接拉满。

DNS 监听地址 Clash 在哪个地址 / 端口上提供 DNS 服务（常见 :53）。如果端口被占用、监听失败，系统仍可能回退到原 DNS；这类问题很隐蔽，表现为 “我明明配置了，但检测还是 ISP DNS”。

增强模式 最常见的是 fake-ip。它的思路是：Clash 对域名返回一个 “假 IP”，后续连接再由 Clash 接管映射到真实目标。 对防泄露而言，fake-ip 的优势是 纳管强、路径更可控，配合 TUN 往往最稳。代价是：极少数局域网 / 特殊域名可能需要加入 fake-ip-filter 以避免兼容问题。

Fake IP 范围 只是 “假 IP 池” 的网段范围，通常默认值即可（除非与你局域网网段冲突）。

Fake IP 过滤 用于声明哪些域名不要走 fake-ip（例如 .lan、.local、部分系统探测域名等）。目的通常是兼容性与减少奇怪的本地网络问题，而不是 “提升安全性”。 推荐用 blacklist 思路：只把确实需要排除的域名放进去即可。

默认域名服务器 用于 “先解析上游 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 也使用加密上游，但这样速度可能会变慢。

域名服务器策略、回退过滤设置、Hosts 设置等保持默认即可

IPv6 开关（ipv6） 如果你的代理链路 / 节点对 IPv6 支持不完整，IPv6 非常容易成为旁路，出现 “我明明开了代理但检测仍能看到本地信息” 的现象。 不确定就关。

prefer-h3 / HTTP3 主要是性能 / 兼容性取舍，在一些网络环境下 QUIC 更容易不稳定。可以先关 *。

respect-rules（遵循路由规则） 让 DNS 的出站策略与规则更一致。对 “防泄露” 来说，它不是第一优先级：更关键的是不要让任何上游指向 system/ISP。上游安全了，respect-rules 的风险面会小很多。

知道了上面这些之后，怎么才能不漏鸡脚呢？

如果你主要目标是：使用 Claude/OpenAI/Codex/Gemini 这类应用时尽量不发生 DNS 泄露，可以按这个顺序做：

1. 启用 TUN（优先保证流量纳管）
2. DNS 覆写启用，增强模式选 fake-ip
3. 禁用 IPv6（避免旁路）
4. 上游 DNS 全部避免 system/ISP：

• default-nameserver：用可靠公共 IPv4 DNS（不要 system）8.8.8.8, 1.1.1.1
• nameserver：优先 DoH/DoTtls://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。

修改完之后变成了这样，又可以愉快的玩耍了

常见的坑

• 上游里出现 system / 本地 ISP：把 default-nameserver / fallback / direct-nameserver 留成 223.5.5.5, 119.29.29.29 或 doh.pub / alidns，然后检测必然出现中国 DNS
• DNS 监听失败（端口占用），以为覆写了，其实系统还在用原 DNS
• Chrome/Edge/Firefox 可能启用 Secure DNS（DoH），这会让浏览器直接用它自己的上游（可能自动选了国内），绕过系统 / Clash。关闭浏览器的 Secure DNS 或 把浏览器 Secure DNS 指定到你想要的 DNS
• WebRTC 泄露，可以考虑使用指纹浏览器或者找插件禁用
• fallback 指向 ISP
• TUN 未启用
• IPv6 未禁用

如果想求稳，使用 Claude / OpenAI / Codex / Gemini 等应用时：开 TUN + 开 DNS 覆写（fake-ip）+ 禁 IPv6 + 上游 DNS 不用 system/ISP；改前改后各做一次 DNSLeakTest 验证。

以上，希望大家都能愉快玩耍～