DNS出了问题，怎样查污染与子网泄露

网站打不开，换个解析器就恢复，能说明解析路径发生了变化。它还不能证明原来的应答遭到篡改，更不能证明新路径没有隐私问题。

我会把问题拆开看：域名交给谁，查询怎么过去，解析器向外带了什么信息。把这些问题揉成“换个 DNS”，配置容易改，故障原因却可能一直没查明。

这一页没有自建环境的验证记录，也没有不同网络之间的性能比较。我只讲原理、配置判断和你能自行复查的方法。没有证据的地方，我不会拿线路名称补答案。

网页未连接就能出错吗

DNS解析发生在按域名建立连接的准备阶段，错误应答可能让后续连接走偏。我会先确认解析路径，再判断节点故障。

你在客户端选中的节点，未必负责设备上的全部域名查询。系统可能有自己的解析设置，应用也可能采用单独的解析入口。客户端显示代理已开启，只能作为检查起点，不能当作查询已经进入代理的证明。

因此，排查时要把“网页请求走哪里”和“域名查询走哪里”分开记录。前者正常，后者仍可能走另一条路径。反过来，解析已经完成，网页打不开也可能发生在连接阶段。把所有超时都归到 DNS，会让你反复改动本来可用的设置。

错误应答与应答差异也不能画等号。同名网站可能返回不同地址，缓存状态、解析器位置和调度策略都可能参与其中。仅凭地址发生变化，我不会直接判断存在注入。

更有用的证据是：异常出现在什么入口，是否能重复，改变解析方式后是否消失，以及恢复原设置后是否重现。你不必先解释所有网络细节，但要让每次改动对应清楚的观察。

线路标签同样不能代替证据。IEPL、IPLC或其他名称描述的内容，与设备实际采用的解析路径不是同一个问题。可以先了解IEPL与IPLC分别说明什么，再回到自己的配置检查查询去向。

我的判断很简单：没有解析记录，就先保留原因，不给某条线路下结论。

加密究竟覆盖哪段

DoH与DoT保护客户端到所选解析器的传输，后续查询是否加密要另查。我不会把入口加密写成整条解析链路都已加密。

可以把解析过程想成代办查询。终端提出域名，递归解析器负责寻找答案，再把结果交回来。递归解析器可能直接使用缓存，也可能继续询问其他服务器。你与代办者之间的通信方式，不能直接代表代办者向外询问的方式。

DoH与DoT处理的是传输保护。它们让相应连接中的查询内容受到加密保护，但接收查询的解析器仍然能够读取域名。选择加密解析器，也是在选择把这些查询交给谁处理。

ECS处理的是另一件事：查询中是否附带客户端子网信息。加密通道可以把这项信息一起送到解析器，却不会因为通道加密就自动删除它。解析器是否继续向外附带，以及采用什么范围，需要检查服务策略或解析器出口。

DNSSEC关注应答数据的验证。它不负责隐藏查询内容，也不负责替你挑选解析器。传输加密、子网信息最小化和应答验证，可以互相配合，但没有哪项能概括其他项目的作用。

检查对象	主要回答什么	不能据此推断什么
DoH或DoT连接	到所选解析器的传输是否受保护	解析器后续查询是否同样加密
ECS处理策略	是否携带客户端子网信息	查询日志是否被保存
DNSSEC验证	应答是否通过相应验证	网站本身是否可信
域名分流	某类域名交给哪个解析入口	该入口必然返回正确答案

还有一个容易混淆的边界：查询发往公共解析器，不等于查询内容只停留在那里；查询发往自建解析器，也不等于后续没有明文通信。你需要沿着实际路径检查，不能只看终端上的开关名称。

我会先画出终端、客户端、递归解析器与后续查询的关系。只要其中有一段说不清，就把那段列为检查对象，而不是用“全链路”掩盖未知。

自己验证该留什么证据

DNS排查应保留查询入口、返回内容和配置变化，单看网页恢复不足以确认原因。我会用可重复的对照缩小问题范围。

原文中的跨网络比较没有可沿用的数据，因此这里不保留对应表格。你自己检查时，也不必从复杂统计开始。先建立可恢复的配置副本，再写清当前系统与客户端分别采用什么解析设置。

选择你确实需要访问的域名，记录查询是否返回、返回内容有什么差异、网页停在哪个阶段。内部域名与公开域名应分开检查，否则公开网站恢复了，内部服务失效了，很容易被误认为修复完成。

对照过程中保持其他设置不动。只改解析入口，或只改传输方式，观察对应变化。把节点、分流、解析器和连接模式同时换掉，即使网页恢复，也难以解释是哪项起作用。

dig适合观察指定解析入口给出的回答，但它不天然代表浏览器或所有应用的查询路径。你要先确认工具实际问了谁，再把结果与应用行为对照。工具能解析，应用不能访问，只能说明还要继续查入口差异。

dig +trace可以帮助理解逐级查询过程，但它不能完整复现公共递归解析器内部的行为。它的查询路径也可能与应用不同。因此，我把它当作补充线索，不会用某处停顿直接断言权威服务器出了问题。

缓存也会影响对照。改完配置后，旧答案可能还在被使用；没有看到新的外发查询，也可能只是当前请求命中了缓存。检查时要区分“没有发出查询”和“发出了查询但没有收到回答”。

你可以把证据写成简短记录：

• 改动前采用什么入口，出现什么症状。
• 只调整了哪项设置，查询与访问怎样变化。
• 恢复原设置后，原症状是否又出现。

这些记录比“感觉更快了”更有用。如果证据仍然冲突，我会停在“原因尚未区分”，继续查路径，不把猜测升级成结论。其他连接故障可以对照节点超时怎样分层排查。

配置从哪里开始改

DNS配置应先明确解析器职责，再分别处理ECS、加密传输与应答验证。我会保留回退路径，让每项变化都能单独检查。

ECS该在哪边处理

能管理递归解析器时，先检查它会不会接收、生成或继续传递ECS。只在终端删除相关选项，无法证明上游解析器不会根据自己的策略补充子网信息。

这里的配置思路，是检查module-config中的模块安排，避免让subnetcache参与不需要的ECS处理，同时保留负责验证的validator。这里要结合当前配置理解，不能把删除某个词当作全部检查完成。

配置文件可能还有其他入口、前置转发或不同用途的服务实例。你修改的文件是否被运行中的进程采用，也要确认。文件内容正确与实际服务生效，是两个需要分别回答的问题。

如果入口前还有负责转发请求的组件，应同时检查入站ECS和向外发送的查询。入口去掉了原有选项，后续组件仍可能重新附加信息。判断依据应落在实际出口，不能停留在配置文本。

qname-minimisation: yes与ECS不是同一个开关。前者对应查询名称最小化的处理，后者涉及客户端子网。把相关设置放在一起管理可以，但验证时要分清各自目标。

我不会建议你为了套用示例，把所有解析器选项整体覆盖。先理解已有配置为什么存在，再改与当前目标直接相关的部分。参数是否适用于你的安装环境，以官方说明为准。

域名该交给谁

终端侧先处理域名归属。公开网站、内部服务和加密解析入口自身的名称，可能需要不同的解析安排。把所有请求交给同一个入口，配置看起来短，问题却可能藏到实际访问时才出现。

Clash中的nameserver-policy可以用来表达域名与解析入口之间的关系。你应先写清哪些域名必须留在内部解析，哪些域名交给加密入口，再检查规则是否真的命中。

default-nameserver涉及解析入口自身的引导问题。若解析器地址也需要先通过域名找到，就要确认这项准备工作怎样完成。否则，表面上设置了加密解析，实际却可能卡在找到入口之前。

这不是鼓励把任意公共地址填进去。引导查询同样属于解析路径，应该知道它经过哪里、能看到什么，以及故障时是否会触发其他路径。

fallback-filter也不能作为真假应答的通用裁判。过滤规则可以排除某些不符合预期的结果，却不能仅凭地址类别证明答案可信。过滤过严，还可能让正常应答被丢弃。

使用Clash Verge时，除了编辑内容，还要检查导入配置、当前生效配置以及后续更新之间的关系。可以结合Clash Verge配置怎样生效检查操作位置；具体字段是否支持，以所用内核说明为准。

验证标志怎样读

dig +dnssec可以用于观察与验证有关的应答内容，但命令中出现+dnssec，不代表发起命令的工具已经独立完成验证。

查看应答中的AD，也就是常见输出里的ad标志，要同时说明回答来自哪里。如果终端信任这个标志，就要先确认它确实来自预期解析器，且传输过程有相应保护。

我不会把带有ad的输出直接翻译成“域名没有风险”。验证针对的是相应DNS数据，不是网页内容、商家信誉或后续连接的全部行为。

没有看到这个标志，也不能立刻宣布验证失败。目标域名是否具备可验证条件、解析器是否执行验证、查询经过什么转发，都可能影响结果。要把“没有验证结论”与“验证发现异常”分开。

同样，看到有关签名链的记录，只能说明取得了这些记录。是否形成有效验证，需要结合完整验证过程判断，不能把查询到了记录当成验证已经完成。

抓包该抓哪个出口

检查ECS之前，先明确你想证明什么：终端有没有向入口发送子网信息，还是递归解析器有没有向后续服务器发送子网信息。观察位置不同，能够回答的问题也不同。

tshark中的dns.opt.client_subnet可以帮助提取可解析报文里的相关字段。但字段为空，只能说明当前捕获并成功解析的这些报文中没有提取到相应内容，不能直接证明整条路径都没有ECS。

如果抓到的是DoH或DoT的加密传输，普通报文分析看不到内部DNS字段是正常边界。这种情况下，不能拿空输出作为“已经剥离”的证据。

如果抓错接口、没有覆盖实际出口，或者请求命中了缓存，也可能什么都看不到。你要先确认捕获到了目标查询，再讨论查询里有没有子网信息。

管理自建递归解析器时，可以在自己有权限的位置检查实际外发查询。使用公共解析器时，你通常无法直接观察它向外询问的全部过程。这时应结合服务说明判断策略，并保留“出口行为未直接验证”的边界。

抓包没有出现异常，不等于所有未观察到的路径都正常。

还是打不开该怎么查

DNS故障应按查询、应答和连接阶段拆开排查，解析差异本身不足以证明污染。我会先查证据，再决定是否调整规则。

先确认卡在哪里

从应用症状开始。是域名没有得到回答，还是已经得到地址却连接失败？是公开网站异常，还是内部服务异常？同一设备上的应用表现是否一致？这些问题能决定接下来该看解析配置还是连接路径。

如果只有某个应用异常，先检查它是否使用单独的解析入口。不要因为系统查询正常，就排除该应用自己的解析问题；也不要因为应用报错，就把系统解析器整体替换。

已经能够得到答案时，继续确认应用采用的是否就是这份答案。工具查询与应用访问之间可能存在缓存或路径差异，直接把两者并在一起，容易误判。

换解析器为何有效

更换解析器同时可能改变缓存、出口和调度结果。恢复访问说明这次改动与症状有关，但原因还需要拆分。公共解析器的名气不能替代这一步。

如果加密入口恢复、明文入口异常，也要确认其他条件是否相同。入口不同、出口不同、缓存不同，都可能干扰比较。能解释的差异越少，证据才越容易判断。

返回地址落在意外范围，值得继续查；返回地址与你预想不同，却不一定是错误。你需要结合域名用途和实际连接表现，而不是凭地址陌生就定性。

回退会不会绕开保护

备用路径应检查触发条件和传输方式。主路径加密，备用路径却采用另一种处理方式，故障时的隐私边界就可能变化。正常访问期间没问题，不能覆盖回退后的行为。

回退也不是越多越好。入口堆在一起，会增加解释实际结果的难度。保留你能说明用途、能够验证生效条件的路径，比盲目添加地址更便于排查。

如果你遇到的是整个网站访问异常，可以按国外网站打不开怎样定位继续检查连接阶段。DNS只是其中一环，证据走到哪里，判断就停在哪里。

个人与业务怎样维护

DNS维护应围绕可控范围安排，个人先保证配置可恢复，业务再明确入口职责。我不会把自建解析器当作通用升级答案。

个人设备优先处理你能看清的部分：当前由谁解析，公开与内部域名是否分开，故障时怎样恢复。没有维护准备时，照抄复杂配置可能增加新的不确定性。

公共加密解析入口减少了自行维护服务的工作，却仍然需要你判断服务策略。加密保护传输，不代表服务端不处理或不保存查询。隐私判断要把接收者纳入范围。

自建解析器提供更多配置控制，也把故障处理和配置维护交给了你。它部署在什么位置、采用什么上游、后续查询怎么走，都需要说明。只因服务由自己搭建，就认为查询不会向外暴露，是把控制权与实际行为混在一起。

业务环境还要明确内部域名的处理边界。哪些名称只能交给内部入口，哪些可以外发，备用路径能否接触内部名称，应在故障发生前写清楚。不要等员工访问失败后，靠临时换公共解析器恢复工作。

每次调整都保留改动原因、预期结果与恢复方法。客户端或订阅配置发生变化后，复查原先的分流是否仍然生效。这里不要求固定频率，重点是变化出现时有人检查。

我也会把服务说明与自己的观察分开保存。说明写了关闭ECS，就记为服务策略；自己在可观察出口确认没有携带，才记为对应路径的验证结果。两种材料可以互相支持，但不能相互替代。

常见疑问怎么判断

DoH、DoT、ECS和DNSSEC应分别判断，协议名称不能代替路径证据。我会把已确认的范围与尚未观察的部分分开说明。

跨境就该选DoH吗

我不会仅凭“跨境”决定。先看客户端是否支持、入口能否连通、内部域名是否受影响，以及故障时能否判断卡点。没有自己的对照记录，就不宣称某种协议更快。

DoH和DoT都需要核对实际连接。配置里写了协议名称，不等于所有应用都采用该入口，也不等于备用路径遵循相同策略。先确认生效范围，再比较使用表现。

关闭ECS会影响调度吗

可能改变调度依据，但不能提前替你的访问效果下结论。解析器不携带客户端子网后，服务端可利用的信息发生变化，实际影响还与解析出口及网站策略有关。

我会检查你确实使用的网站是否发生可重复的访问变化，而不是把关闭ECS自动归类为性能下降。内部域名和公开网站分开处理，也能减少这类改动互相牵连。

有AD就能放心吗

AD表达的是解析器给出的验证结论，前提还包括你正确识别并信任应答来源。它不是覆盖整次访问的保证，更不能替代对加密传输和ECS策略的检查。

如果需要更高把握，应继续明确谁执行验证、终端怎样获得结果，以及验证异常时采用什么处理。只截取输出中的标志，无法回答这些问题。

子网前缀算泄露吗

子网前缀不等于完整终端地址，但它仍然是额外的网络位置线索。是否可以接受，要结合你希望向解析服务及后续接收者提供多少信息判断。

也不要反过来夸大它：看到前缀，不能直接推断已经识别到具体个人。这里能确认的是查询携带了子网信息，不能凭这项证据补出个人身份或精确位置。

自建更适合业务吗

只有当你需要相应控制，并能承担维护时，自建才有明确价值。业务规模本身不能回答谁负责故障、谁核对策略、谁恢复配置。

我会先把公共入口与自建入口都放进同一张路径说明里，检查传输、ECS、验证和回退。能够解释并维护整条路径，比拥有一个“自建”的标签更有用。