应首先对比多源DNS解析结果：用dig分别查询8.8.8.8、1.1.1.1、114.114.114.114及本机配置DNS，若前三者一致而后者异常（如返回广告IP），再检查dig响应头中SERVER是否为运营商IP、STATUS是否NOERROR但答案错误、flags是否缺失ad标志，结合tcpdump抓包确认UDP 53响应源是否被篡改，最后验证DoH/DoT是否正常以判定运营商劫持。
Linux中排查DNS被运营商劫持，核心是验证解析结果是否被篡改、是否与权威应答不一致，以及是否出现非预期跳转或错误IP。运营商劫持通常表现为：域名解析出错IP（如返回广告页IP）、特定域名被强制指向本地缓存服务器、或查询结果与全球真实解析不一致，且该现象在更换DNS后消失。
对比多个DNS源，确认解析结果是否异常
运营商劫持最典型的特征是“你用的DNS返回了不该有的IP”。需用不同可信DNS服务器并行查询同一域名，观察结果差异：
- 运行 dig @8.8.8.8 example.com +short（Google DNS）
- 运行 dig @1.1.1.1 example.com +short（Cloudflare DNS）
- 运行 dig @114.114.114.114 example.com +short（国内公共DNS）
- 再运行不指定服务器的 dig example.com +short（走本机配置）
若前三者返回一致且合理的IP，而最后一项返回明显不同（如私有IP、127.0.0.1、或某广告平台IP），则高度怀疑本机使用的DNS被劫持——很可能是运营商在出口网关做了UDP 53拦截并伪造响应。
检查响应头中的SERVER和STATUS字段
运营商劫持常伴随非标准响应行为。用 dig example.com 查看完整输出，重点关注：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- SERVER 字段：是否显示为本地网关IP（如192.168.1.1）或运营商DNS（如211.136.17.107）？正常应为你配置的nameserver IP
- Status 字段：若为 NOERROR 但 ANSWER SECTION 返回了错误IP，说明响应被伪造；若为 SERVFAIL 或超时，可能被丢包或重定向
- flags 中是否含 ad（authentic data）？劫持响应通常不带此标志，而真实递归DNS在启用DNSSEC验证时会标记
抓包验证DNS流量是否被篡改
直接观察原始UDP 53报文，是最硬核的判断方式：
- 执行 sudo tcpdump -i any port 53 -w dns.pcap，另起终端运行 dig example.com
- 用Wireshark打开dns.pcap，过滤 udp.port == 53
- 查看请求发出的DNS服务器是否为你配置的地址；再看响应包的源IP是否匹配——若请求发往8.8.8.8，但响应却来自114.114.114.114或本地网关，即存在中间劫持
- 特别注意响应包中的 Answer RRs 内容是否与权威结果不符，且无合理TTL或签名
绕过UDP 53，测试DoH/DoT是否正常
运营商劫持多针对传统UDP 53端口。若启用加密DNS后问题消失，基本坐实劫持：
- 安装 stubby（DoT）或使用 curl --doh-url https://1.1.1.1/dns-query（DoH）发起查询
- 例如：curl -H "accept: application/dns-json" "https://1.1.1.1/dns-query?name=example.com&type=A"
- 若DoH/DoT返回正确结果，而普通dig失败或返回错误IP，说明UDP路径被干扰，典型运营商DNS劫持场景
不复杂但容易忽略：劫持往往只影响部分域名（如未备案的境外站），或仅在HTTP明文访问时触发重定向。排查时务必选多个对照域名（如github.com、cloudflare.com、一个已知IP的内网服务），避免误判为单点故障。
