macOS DNS诊断需分层验证：先用scutil --dns和networksetup查真实生效的DNS配置，再清缓存（Ventura+用dscacheutil与mDNSResponder），接着用dig、nslookup、time实测解析路径与响应时间，最后排查路由器转发、应用级缓存及CDN地理敏感等干扰环节。
诊断 macOS 网络 DNS 查询路径，关键不是“换一个 DNS 就完事”，而是看清请求从发出到返回的完整链路——哪一环拖慢了、哪一环被绕过了、哪一环根本没生效。优化必须分层验证，否则改了 DNS 也白改。
一、确认当前实际生效的 DNS 服务器
图形界面里点的设置，不等于系统真在用。最可靠的方式是终端直查底层配置：
- 运行 scutil --dns | grep nameserver：输出的是当前网络栈真正读取的 DNS 列表，含服务名和 IP，这是真实生效的依据
- 运行 networksetup -getdnsservers "Wi-Fi"（把 Wi-Fi 换成你实际服务名）：查的是该服务配置项，用于比对是否写入成功
- 运行 cat /etc/resolv.conf：仅作快速参考（此文件由系统动态生成，不可编辑），若内容与 scutil 不一致，说明配置未落地或被覆盖
二、检查 DNS 缓存是否阻断新配置
即使 DNS 已设对，旧缓存仍会返回过期结果，导致网页加载无改善。必须清干净再测：
- macOS Ventura 及更新（Sonoma 14 / Sequoia 15）：sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
- macOS Monterey 及更早：sudo killall -HUP mDNSResponder
- 清完后立刻执行 scutil --dns | grep 'nameserver'，确认输出已更新；再用 nslookup apple.com 看解析是否走新 IP
三、实测解析路径与响应时间
别只信“设上了”，要测真实效果。不同工具看不同环节：
- dig example.com @223.5.5.5 +short：强制指定 DNS 查询，验证该服务器能否返回正确 IP
- dig example.com +stats：不指定服务器，走系统默认链路，看 “Query time” 是否合理（300ms 需排查）
- time nslookup github.com：三次取平均，观察 real 时间变化，对比换 DNS 前后差异
- ping -c 3 $(dig github.com +short | head -1)：拿到解析出的 IP 后测连通性延时，排除 DNS 正确但网络路由差的问题
四、识别常见干扰环节
很多“改了没用”其实卡在下游或上游：
- 路由器 DNS 转发：Mac 设了 1.1.1.1，但路由器开了 DNSMasq 或 OpenWrt 的 DNS 转发，所有请求仍先打到路由器再出去——需登录路由器后台同步改
- 应用级 DNS 缓存：Chrome 启用 DNS 预加载、Safari 启用 QUIC，可能绕过系统 DNS；可临时关闭预加载测试，或用 curl -v https://example.com 观察 Host 头解析行为
- CDN 域名地理敏感：访问 cloudfront.net 或 akamai.net 类域名时，离你近的 DNS（如阿里 223.5.5.5）才可能返回就近节点；换远端 DNS 反而拉长路径
- DNS 污染检测机制：部分国内平台（如某些银行、政务站）会检测非运营商 DNS 并主动降级响应或跳转，此时换 DNS 可能适得其反
