DNS泄露怎么修复？Clash、Surge、sing-box的DNS配置思路
修复DNS泄露的核心只有一句话：让域名解析跟着代理流量走同一条路。按顺序试四条通用修法——在代理客户端开启 DNS 接管、管好浏览器自带的安全 DNS（DoH）、处理 IPv6 的 DNS、SOCKS5 场景改用远程解析——绝大多数泄露都能解决。每改一项，回 DNS 泄露检测 复测确认。
第一步：在代理客户端开启DNS接管
先说结论：客户端级的 DNS 接管是最根本的修法，一次配置对所有应用生效。DNS 接管指的是由代理客户端拦截系统发出的所有 DNS 查询，统一在代理链路内完成解析，不再放任系统直接问运营商。三个主流客户端的思路一致，配置项名称不同：
- Clash 系：启用
dns模块并设置enhanced-mode（常用fake-ip），再配合 TUN 模式接管系统全局流量，DNS 查询就不会漏出去。只开系统代理而不开 TUN 时，接管范围有限。 - Surge：核心是「DNS 劫持」（DNS Hijacking）相关设置，把发往任意 DNS 服务器的查询劫持到 Surge 自己处理，通常配合增强模式使用。
- sing-box：在配置的
dns部分定义服务器与rules（DNS 规则），控制哪些域名由哪个 DNS 服务器解析、解析请求走哪个出站。
这里只讲思路，不同版本的具体字段和默认值可能变化，动手前请以各客户端的官方文档为准。
浏览器的安全DNS（DoH）为什么要单独管？
结论：浏览器 DoH 有自己独立的加密解析通道，会绕过代理客户端的 DNS 接管，是接管开了却仍泄露的头号原因。DoH（DNS over HTTPS）是浏览器把 DNS 查询打包成 HTTPS 请求、直接发给指定解析服务商的机制。它加密了查询内容，但解析请求的出口位置未必跟你的代理出口一致——测出来就是"DNS 出口与网页出口不同地区"。修法二选一：在浏览器设置里搜索「安全 DNS」并关闭，让解析回落给系统（由客户端接管）；或者把 DoH 指向一个与代理出口地区一致的可信服务商。改完务必复测，因为浏览器大版本更新有时会重新开启安全 DNS。
IPv6的DNS是怎么漏出去的？
结论：IPv6 DNS 走直连是最常见的漏网之鱼——很多客户端和规则只接管了 IPv4，系统却优先用网络下发的 IPv6 DNS 地址解析。只要你的网络同时下发了 IPv6，哪怕 IPv4 的 DNS 已经被接管，一部分查询仍会从 IPv6 直接发给本地运营商，表现为检测结果里混进了本地出口。修法两条：要么在系统或路由器层面暂时关闭 IPv6（或设置 IPv4 优先），要么在客户端里同样接管 IPv6 的 DNS 查询（确认客户端和 TUN 配置启用了 IPv6 支持）。图省事选前者，追求完整双栈体验选后者，具体开关位置见关闭 IPv6 教程。
SOCKS5代理下域名应该在哪里解析？
结论：SOCKS5 场景应选择「远程解析」，把域名原样交给代理服务器在远端解析，本地完全不发 DNS 查询。SOCKS5 协议本身支持两种模式：本地先解析出 IP 再连接（域名会在本地泄露），或把域名直接传给代理服务器解析（不泄露）。不同软件里这个开关叫法不一：浏览器代理插件里常见「通过代理解析域名」或 remote DNS 选项；命令行工具中体现为 socks5 与 socks5h 的区别（后者表示由代理端解析主机名）。凡是手动配置 SOCKS5 的地方，都确认选了远端解析。
常见泄露场景对照表
先定位再动手：用 DNS 泄露检测 看清表现，再对照下表找到对应的修复动作。
| 泄露场景 | 检测时的表现 | 修复动作 |
|---|---|---|
| 客户端未接管 DNS，系统直连解析 | DNS 出口显示本地运营商 | 开启客户端 DNS 接管：Clash 启用 dns 模块 + TUN，Surge 开 DNS 劫持，sing-box 配 dns 规则 |
| 浏览器开启了安全 DNS（DoH） | DNS 出口显示某公共 DNS 服务商，与代理出口地区不一致 | 关闭浏览器安全 DNS，或指向与代理出口地区一致的可信服务商 |
| IPv6 DNS 走了直连 | 部分解析从本地 IPv6 出口发出，结果时好时坏 | 关闭 IPv6 / 设 IPv4 优先，或让客户端同样接管 IPv6 DNS |
| SOCKS5 选择了本地解析 | 网页流量走代理，DNS 全部本地直连 | 改为远程解析（如 remote DNS / socks5h），域名交给代理端解析 |
| 切换网络后配置残留 | 换 Wi-Fi 或热点后突然复发泄露 | 重启代理客户端，重新复测确认 |
修完之后怎么验证才算真的修好？
唯一可靠的验证方法是实测解析路径，而不是看配置文件写了什么。回到 DNS 泄露检测 重跑一次，合格标准只有一条：DNS 出口与代理出口在同一国家/地区。如果检测显示的 DNS 服务器位置和你的网页访问出口一致，就算修复完成；仍出现本地运营商或其他地区的出口，就按上表回到对应小节继续排查。修好后也别一劳永逸——切换网络、客户端升级、浏览器更新都可能让泄露复发，在注册账号等风控敏感操作前花一分钟复测最稳。DNS 只是环境一致性的一环，ipkk.com 首页的封号风险系数（0-100，越高越危险）还会综合 IP 类型、是否原生 IP、WebRTC 泄露、时区一致性等因子做定性评估，建议整体过一遍。
常见问答
开了TUN模式还需要管DNS吗？
需要。TUN 模式解决的是"流量是否全部进入客户端"，DNS 查询进入客户端后如何解析、走哪个出口，仍由 dns 模块的配置决定；而浏览器 DoH 这类应用层解析通道即使在 TUN 下也可能绕开接管，要单独确认。TUN 与系统代理的区别可看这篇。
fake-ip 和 redir-host 该选哪个？
不确定就选 fake-ip，它让客户端返回虚拟 IP、真实解析全部在代理链路内完成，泄露面更小。redir-host 模式下部分场景仍会发生真实解析，排查成本更高。个别应用与 fake-ip 不兼容时，再按官方文档做例外处理。
把系统DNS改成 8.8.8.8 能修复泄露吗？
不能。泄露的判断标准是解析请求的出口位置，不是用了哪家服务商：系统 DNS 改成公共 DNS 后，查询仍从你的本地网络直接发出，出口还是本地，照样泄露。正确做法是让解析走代理链路，而不是换解析服务商。
修复DNS泄露会影响上网速度吗？
通常影响很小。解析走代理会增加一点解析延迟，但客户端普遍有 DNS 缓存，同一域名只慢第一次；相比泄露带来的环境矛盾和隐私暴露，这点开销几乎可以忽略。
手机上也会DNS泄露吗？
会，修法思路相同。手机端的 Clash 类、sing-box 类客户端同样有 DNS 与 TUN（VPN 模式）设置，开启后由客户端统一接管解析；修改后用手机浏览器打开 DNS 泄露检测 复测即可确认。
真实使用场景
一位做跨境电商的读者在 DNS 泄露检测 里发现：网页出口在美国，DNS 出口却一半显示本地运营商、一半显示美国。他先在 Clash 里确认 dns 模块和 TUN 都已开启，按理不该漏——按本文顺序继续排查，第二步就找到了原因：浏览器不久前大版本更新，自动重新开启了「安全 DNS」，这部分 DoH 查询绕过了客户端接管。关闭安全 DNS 后复测，仍有零星本地出口，再查第三步发现家里宽带下发了 IPv6 DNS，而他的 TUN 配置没启用 IPv6。在路由器上设置 IPv4 优先后再测，所有解析出口终于与代理出口落在同一地区。整个过程没有改动一行分流规则，只是按四条修法逐条对照。社区普遍经验认为，跨境账号运营前把 DNS 出口一致性检查一遍能少踩很多坑——同时提醒：涉及多账号运营请遵守各平台规则与当地法律法规。