你可能花了很多精力去隐藏 IP、配置代理、清理浏览器指纹，但有一个环节往往被忽略——DNS。你的每一次上网请求都是从 DNS 开始的，如果这个环节出了问题，前面的努力可能全白费。这篇文章会把 DNS 安全这件事从头到尾说清楚：从原理到攻击方式，从检测到修复，从加密方案到日常自查。
一、DNS 是什么？为什么它的安全比你想象的重要？
你在浏览器里敲 008ip.com 然后回车，这一秒内发生的事情里，第一步就是 DNS 查询。你的设备需要把”008ip.com”这个人能读的域名，翻译成机器能用的 IP 地址（比如 128.14.79.71），这个翻译过程就叫 DNS 解析。
问题在于：传统的 DNS 查询是明文的，没有任何加密。这意味着任何能监控你网络的人——你的 ISP、咖啡馆的 Wi-Fi 管理员、甚至你路由器上某个被感染的设备——都能看到你访问了哪些网站。更糟的是，他们不光能看，还可以篡改你的 DNS 响应，把你引到一个假的网站上而你完全不会察觉。
DNS 面临的威胁大致可以分成三类。第一类是窃听——别人能看到你在查什么域名，从而知道你在访问什么网站。第二类是篡改——攻击者把正确的 IP 地址换成假的，你的流量就被劫持了（这就是著名的 DNS 欺骗）。第三类是阻断——比如 DNS 污染，直接把某个域名的查询结果改成错误的或者根本不给回应。这三类攻击的手法不同，但后果是一样的：你以为你访问的是正确的网站，实际上你去了一个完全不同的地方。
有个数据很能说明问题：根据 Cloudflare Radar 和 APNIC 的统计数据，截至 2025 年底，全球域名的 DNSSEC 签名率约在 7.6% 到 8% 之间——也就是说，超过 90% 的 DNS 查询在技术上仍然是可以被伪造的。但更扎心的是另一个数字：真正由用户本地设备实现端到端验证（End-to-End Validation）的比例只有大约 0.47%——也就是说，即使一个域名部署了 DNSSEC，解析到了用户设备那一步也大概率不会再做一次校验。不过这并不意味着 DNSSEC 完全形同虚设。实际上，全球约有 30% 到 40% 的互联网用户正在使用启用了 DNSSEC 验证的公共递归解析器（比如 Cloudflare 的 1.1.1.1 或 Google 的 8.8.8.8），这些解析器已经在帮你做签名验证了。只是从解析器到你设备之间的”最后一公里”仍然是明文且没有验证的——如果有人在这段路上劫持了你的 DNS 响应，你照样无从知晓。部署 DNSSEC 需要域名注册商、DNS 托管商、网站管理员三方配合，而要真正做到全链路安全，还需要用户端的解析器也开启验证——四个环节缺一个，整条信任链就不完整。
💡 快速检测你的 DNS 安全状况：打开 008ip.com，在检测报告中查看 DNS 状态——它会告诉你当前 DNS 服务器是谁，是否存在 DNS 泄露，以及你的 DNS 请求是否走了加密通道。
二、DNS 泄露：代理没翻车，DNS 先翻车了
这是日常使用中最常见、也最容易被忽略的 DNS 安全问题。很多人以为开了代理或者 VPN 就万事大吉了——你的网页流量确实走了代理通道，IP 地址也变成了代理服务器的。但 DNS 查询不一定。
DNS 泄露的原理很简单：你的系统或者浏览器在解析域名时，DNS 请求没有走代理通道，而是直接发给了你本地的 DNS 服务器——通常是运营商的。这样运营商就能看到你在解析哪些域名。即使你的网页浏览流量已经加密了，运营商还是能从 DNS 查询记录里推断出你在访问什么网站。跨境电商从业者对这一点尤其敏感：你的 IP 是美国的，但 DNS 查询显示你在反复解析 Amazon 卖家后台，这套组合拳被平台风控抓到基本就是关联判定。
怎么判断自己有没有 DNS 泄露？最简单的办法是在使用代理的情况下打开一个 DNS 泄露检测工具。如果检测结果显示的 DNS 服务器地址是你本地运营商的（国内常见的是 202.96.x.x 或 211.x.x.x 这类段），而不是代理服务器的 DNS，那就说明泄露了。008ip.com 的检测工具可以直接帮你判断——在检测报告的 DNS 状态一栏，如果显示”DNS 泄露：检测到本地 DNS 服务器”，就需要马上处理。
修复 DNS 泄露的办法分两个层面。软件层面上，大多数代理工具都有”DNS 通过代理”或”强制远程 DNS 解析”的选项，打开就行。系统层面上，可以手动把 DNS 服务器设成不会记录日志的公共 DNS（比如 Cloudflare 的 1.1.1.1 或 Google 的 8.8.8.8），这样即使不走代理，至少你的 DNS 查询不会被运营商完整记录。详细的排查和配置方法见 DNS 泄露检测方法大全。
三、DNS 劫持与污染：你的请求被送到了哪里？
DNS 泄露是”别人能看到你在查什么”，而 DNS 劫持和污染更进一步——别人能篡改你得到的答案。
DNS 劫持通常发生在你想访问某个网站但被定向到了一个完全不同的 IP 地址。手法有很多种：攻击者可能通过恶意软件篡改了你设备上的 DNS 设置，把你的 DNS 服务器偷偷换成了他控制的服务器；也可能在路由器层面做了手脚，让你整个家庭网络的 DNS 流量都经过他的服务器。还有一种更隐蔽的方式是通过入侵域名注册商账户，直接把域名的 NS 记录改掉——你输入的域名是对的，但负责解析这个域名的服务器已经被换了，所有的流量都被导到了攻击者的服务器上。
DNS 污染（国内常说的”DNS 投毒”）则是一种更粗暴的手段。它不是针对你的设备，而是在 DNS 解析链条的中间环节——运营商的递归 DNS 服务器或者国家级的 DNS 网关——直接对某些特定域名的查询返回假的 IP 地址。你查的是 google.com，返回给你的却是 0.0.0.0 或者一个莫名其妙的 IP。这种做法在国内网络环境下比较常见，某些境外网站通过正常 DNS 根本解析不到真实 IP。
怎么判断自己遇到了 DNS 劫持还是国家级污染？有个简单的区分方法：如果你把 DNS 从运营商默认地址换成公共 DNS（比如 114.114.114.114）后就能正常解析了，那大概率只是本地运营商的广告劫持。如果你换了 8.8.8.8 等海外明文 DNS 依然解析出错误 IP——这在国内访问某些境外网站时很常见——说明你遇到的是国家级或骨干网级的 DNS 污染。因为 GFW 的 DNS 污染机制会旁路监听发往境外的 UDP/TCP 53 端口明文流量，一旦检测到你查询的域名命中了黑名单，就会迅速抢答返回伪造的错误 IP。对于这些受限域名，换哪个明文 DNS 都没用。必须通过代理来解决——加密 DNS（DoH 或 DoT）虽然能防止 DNS 投毒拿到真实 IP，但这只解决了”找到正确地址”这一步。当你用浏览器向这个真实 IP 发起 HTTPS 连接时，GFW 的 SNI 审查仍然会在 TLS 握手阶段切断连接，或者该 IP 本身就在黑名单里根本连不上。换句话说，加密 DNS 防的是 DNS 层面的投毒，但它不能替代代理——两者是解决不同层面的问题。
应对 DNS 劫持的第一步永远是检查你设备的 DNS 设置——确保没有被改成陌生的地址。第二步是确保你的路由器管理密码不是默认的——大量 DNS 劫持就是通过路由器漏洞实现的。更长远的方案是启用加密 DNS（下一节会详细讲），因为加密后的 DNS 查询无法被中间人篡改。
四、DNSSEC：给 DNS 加一把”防伪锁”
前面说的 DNS 泄露和劫持都是”传输过程”中的问题——要么被人偷看，要么被人篡改。而 DNSSEC（DNS Security Extensions）解决的是另一个层面的问题：我怎么知道我拿到的 DNS 记录是真货？
DNSSEC 的思路很直接——给 DNS 记录加上数字签名。就像你签完名别人可以验证是不是你的笔迹一样，DNS 记录经过 DNSSEC 签名后，解析器可以验证”这条记录确实来自它声称的那个域名授权服务器，中途没有被篡改过”。签名是通过一个从根域名到具体域名的信任链逐级传递的：根 DNS 服务器用自己的密钥签名了 .com 的记录，.com 又签名了 example.com 的记录，一层套一层。任何一环的签名对不上，整个链条就断了，解析器就知道数据不可信。
但 DNSSEC 的现实处境有点尴尬。截至 2025 年底，全球域名的 DNSSEC 签名率约 7.6% 到 8%，远谈不上普及。更关键的是，签名不等于有人验证：真正由用户本地设备实现端到端验证的比例只有大约 0.47%。好在全球约有 30% 到 40% 的用户在使用启用了 DNSSEC 验证的公共解析器（如 1.1.1.1 和 8.8.8.8），这些解析器在服务器端帮你完成了签名校验——只是从解析器到你的设备之间仍然是未验证的。另外有一个反直觉的现象：流量越大的头部网站，DNSSEC 的采用率往往低于大盘平均水平。根据 Cloudflare Radar 的遥测数据和多项学术测量，全球 Top 100 等顶级域名的 DNSSEC 部署率通常在 5% 左右，比整体签名率（7.6-8%）还低。原因不复杂：大型网站严重依赖 CDN、GeoDNS（基于地理位置的智能解析）和全局负载均衡，这些技术需要根据用户位置动态生成 DNS 响应，而 DNSSEC 要求对这些动态响应进行实时签名（Live Signing），技术集成难度和计算开销都很高。更关键的是，DNSSEC 是一把很容易伤到自己的双刃剑——一旦签名过期或配置有微小错误，DNS 解析器会直接返回 SERVFAIL，导致网站在全球范围内彻底断网。Slack、HBO 等科技巨头都曾因 DNSSEC 配置失误遭遇过严重的全球宕机。对商业巨头来说，稳定性压倒一切，宁愿不部署也不愿承担自爆风险。能做到高部署率的反而是受监管强制驱动的行业——.bank 和 .insurance 两个金融类顶级域名达到 100% 部署率，但那是因为注册局将其作为准入门槛，不代表自发意愿。ECDSA 椭圆曲线签名算法正在快速取代老旧的 RSA——2025 年已有 40.3% 的已签名域名使用 ECDSA，同比增长近 25%，相同的安全强度下签名更短、验证更快。
DNSSEC 有一个重要的局限性需要了解：它只验证 DNS 数据没有被篡改，但不加密数据。也就是说，DNSSEC 保证了 DNS 响应”是真的”，但它不保证”只有你和我能看”。加密 DNS 数据的任务交给了下一节要讲的两个协议。
五、加密 DNS：DoH 和 DoT 到底怎么选？
如果你想要的是”DNS 查询内容不被中间人看到”，那你需要的是 DNS 加密协议。目前有两个主流选项：DoH（DNS over HTTPS）和 DoT（DNS over TLS）。
两者的核心区别就一条：DoH 把 DNS 查询伪装成普通网页流量，走 443 端口；DoT 给 DNS 单独开了一个加密通道，走 853 端口。这会影响到实际使用中的方方面面。
DoH 的最大优势是端口的宽容度。因为 DNS 查询和 HTTPS 网页请求一样走 443 端口，在公共 Wi-Fi、酒店网络、企业访客网络这类受限环境里，几乎不可能被封锁——毕竟没人会把 443 端口全封了。对于个人用户来说，DoH 的部署也简单到几乎不需要操作——Chrome、Firefox、Edge 都内置了 DoH 支持，在设置里搜”安全 DNS”打开就行。
DoT 的优势则在于可控性。因为使用专用端口 853，网络管理员可以精确识别 DNS 流量并对它施加策略——比如强制所有 DNS 请求必须走企业内部的 DNS 服务器，阻止用户绕过公司 DNS 过滤。对于企业网络管理来说，DoT 的端口可识别性是好事，对于个人用户则相反——853 端口在某些网络环境下会被封锁。
需要注意的是，很多人仍然把 Android 的”私人 DNS”（Private DNS）等同于 DoT。虽然 Android 9 首次引入这个功能时确实只支持 DoT，但从 Android 13（2022 年发布）开始，Google 已经在系统中加入了对 DoH 的原生支持，并且正在向”优先使用 DoH”的方向迁移。所以现在的主流 Android 手机用 Private DNS 功能，实际上既支持 DoT 也支持 DoH，填入支持 DoH 的 DNS 提供商地址即可。iOS 14 以上同样通过配置描述文件支持两者。也就是说，手机端的加密 DNS 已经不是 DoT 的专属领域了。
性能方面两者差异不大。实测数据表明，Cloudflare 的 DoH 平均查询延迟约 25.2ms，与传统明文的 23.4ms 只差了不到 2ms，日常使用完全感知不到。DoT 的延迟也在这个量级。所以选 DoH 还是 DoT，更多是一个场景问题而不是性能问题：个人用户优先用 DoH（浏览器内置、省事、不怕端口封锁），Android 用户可以用 DoT（系统级、全应用覆盖），企业环境推荐用 DoT（端口可识别、策略可管控）。如果你在国内网络环境下希望 DNS 查询不被干扰，DoH 明显更合适——因为 443 端口几乎不可能被封锁。
六、日常 DNS 安全自查清单
把上面讲的内容浓缩成一份可以定期过一遍的清单，每次几分钟就够了。
先用 008ip.com 做一次完整的 DNS 状态检测，看三个关键指标：DNS 服务器是谁（是不是你设的那个）、有没有 DNS 泄露（代理状态下服务器不该是运营商）、DNS 请求是否走了加密通道。如果 DNS 服务器显示的是你本地运营商的地址但你明明设的是 1.1.1.1，检查一下是不是代理软件或者安全软件覆盖了你的 DNS 设置——很多 VPN 客户端会悄悄改 DNS。
然后打开浏览器的安全 DNS 功能。Chrome 在 chrome://settings/security，Firefox 在设置里搜”DNS over HTTPS”，Edge 在 edge://settings/privacy。选一个靠谱的 DNS 提供商——Cloudflare（1.1.1.1）在隐私和速度上综合表现最好，Google（8.8.8.8）在国内连通性更稳定，Quad9（9.9.9.9）主打安全过滤会主动拦截已知恶意域名。
如果你在用代理，确认代理软件的 DNS 设置里”DNS 通过代理”是开着的。有些代理工具默认不代理 DNS 请求，这个默认行为就是 DNS 泄露的根源。用手机上网的用户，Android 去设置里搜”Private DNS”打开，填入 DNS 提供商的主机名（比如 dns.google），系统会自动协商使用 DoH 还是 DoT——注意这里只能填域名，不能填完整的 DoH URL（如 https://dns.google/dns-query），否则会报错。iPhone 需要用配置描述文件来启用加密 DNS，稍微麻烦一点但值得做。
最后一步也是最容易被忽略的：检查你的路由器。登进管理后台，看一眼 DNS 设置有没有被改成陌生的地址。同时确认一下路由器的管理员密码不是出厂默认的——国内大量家用路由器的 DNS 劫持事件就是因为默认密码没改。
常见问题 FAQ
换了公共 DNS 之后上网会变快吗？
有可能，但不是必然的。运营商默认的 DNS 服务器通常距离你最近（物理延迟低），但解析速度不一定快。像 1.1.1.1 和 8.8.8.8 这样的公共 DNS 胜在缓存大、全球节点多，很多常用域名的解析速度反而比运营商更快。但如果你在国内且离运营商的 DNS 服务器很近，换公共 DNS 可能会因为物理距离增加几毫秒延迟。建议实际测一下再决定。
DoH 和 DoT 会被墙吗？
DoT 的 853 端口被封锁的可能性远高于 DoH，因为端口固定且可识别。DoH 虽然跟 HTTPS 共用 443 端口无法被端口封锁，但在国内实际网络环境下，GFW 有更直接的手段——很多海外知名 DoH 节点的 IP 地址（包括 Cloudflare 的 1.1.1.1 和 Google 的 8.8.8.8 的部分节点）在国内是直接被 IP 层阻断的，连 TCP 握手都建不起来。对于没被 IP 封锁的节点，GFW 还可以通过 SNI 审查在 TLS 握手阶段识别出你正在连接 DoH 服务（比如目标域名是 cloudflare-dns.com），然后切断连接。所以在国内直连海外 DoH 节点经常处于不可用状态。DoH 确实比 DoT 更隐蔽，但远不能保证在国内环境下稳定工作。
设置了代理还需要关心 DNS 安全吗？
需要，而且更需要。代理只代理了你的应用层流量，DNS 查询默认很可能不走代理。不检查 DNS 泄露就在代理状态下上网，等于你花了很多精力去隐藏 IP，但运营商通过 DNS 查询记录依然能知道你访问了哪些网站。这是一个极其常见的配置盲区。
关于 DNS 安全，记住三个核心原则就够了：查泄露——不管用什么代理，定期确认 DNS 没泄露到运营商那里；防篡改——打开浏览器的加密 DNS 功能，让中间人没法偷看或修改你的 DNS 请求；验证数据——对 DNSSEC 有基本的了解，知道哪怕端到端验证率还不到 1%，它仍然是目前唯一能保证 DNS 记录没有被篡改的机制。把这三点做到位，DNS 这个最基础的环节就不会成为你整个安全链条里的短板。
