修改DNS以后为什么还是无法连接？
快速结论
DNS仅负责将域名翻译为IP地址，不能修复物理断流与节点超时。且在分流客户端启用Fake-IP时本地网卡DNS会被覆盖接管，修改公共DNS自然无效。
“修改DNS解决一切”的技术误区
在互联网论坛中，常常能看到“网页打不开就改成8.8.8.8或114.114.114.114”的通用口诀。许多用户在遇到节点连接失败或特定工具报错时，也盲目在网卡属性里反复修改DNS，结果发现毫无改善。
必须明确：修改DNS绝不是万能修复手段。
Fake-IP内核接管机制解析
在现代分流客户端（Clash/Verge）中，为了防止本地DNS污染并降低解析延迟，普遍默认采用了Fake-IP分流模式。
当浏览器请求 google.com 时，客户端内置的DNS拦截器会瞬间向浏览器返回一个虚假的局域网保留IP（如 198.18.0.1）。随后，真实的域名解析交由远端节点在服务器侧执行。这意味着：你在Windows网卡里填写的任何公共DNS，都被客户端直接旁路截获并忽略了，修改它自然没有任何效果。
DNS能管什么与管不了什么
DNS能解决的：国内直连网站因运营商Local DNS瘫痪导致的域名解析失败、内网自建域名解析。
DNS根本管不了的：节点服务器TCP端口断流、系统代理未开启导致的流量未转发、特定平台IP被封锁、账号注册地合规风控。
常见疑问解答
什么时候修改DNS才真正有意义？
当本地完全不开启代理时，访问国内普通网站提示DNS_PROBE_FINISHED_NXDOMAIN，或者订阅链接自身是一个无法解析的纯新域名时，修改为阿里的223.5.5.5才具有实际排查意义。
Fake-IP 198.18.0.0/16 运行机制
在现代分流架构中，为什么网卡改DNS对分流节点毫无作用？
Clash内核在启动时，会划定一个专属的保留私网地址段（通常为 198.18.0.0/16）。当操作系统或浏览器发起任何外部域名解析请求时，Fake-IP模块会在1毫秒内返回一个该保留网段内的虚构IP地址（例如 198.18.0.45）。
操作系统以为解析已完成，立即向该虚构IP发送TCP数据包；客户端内核拦截该数据包后，从内存映射表中还原出最初的真实域名，并将域名打包发送到远端海外服务器进行最终解析。
因此，真实的域名解析全过程完全发生在远端服务器上。你在本地网卡中把DNS改成8.8.8.8还是114.114.114.114，对远端服务器的解析行为没有产生任何实质影响。
何时必须且应当配置DNS
修改DNS真正适用的场景非常明确：
- 国内直连网站（如网银、政务网站、国内云服务）打不开或提示DNS劫持；
- 订阅链接本身使用的域名无法在本地运营商网络中被解析；
- 在路由器全局透明网关中，为了优化国内CDN就近接入速度而设置本地上游DNS。
底层网络协议栈与路由跃点（Metric）分析
在多网卡与异构设备环境中，操作系统的路由判定直接决定了数据包的物理出口。理解以下系统网络调试方法，有助于攻克疑难网络杂症：
| 诊断对象 | 诊断工具 / 检查项 | 健康技术指标 | 异常现象与处置 |
|---|---|---|---|
| 本地DNS解析 | nslookup www.baidu.com |
毫秒级返回真实国内公网IP | 若超时，排查路由器DHCP分配或网卡DNS设置 |
| 系统路由表跃点 | route print -4 |
TUN虚拟网卡跃点数（Metric）低于物理网卡 | 若物理网卡跃点更低，流量将绕过代理，需重装TUN驱动 |
| 网卡IPv6泄漏 | 访问 ipv6-test.com 验证 | IPv6未连接或走代理出口 | 若泄漏本地IPv6真实地址，在网卡属性中禁用IPv6 |
| MTU/MSS网络分片 | ping -f -l 1472 [网关IP] |
数据包无分片正常通过（无DF错误） | 若丢包严重，可在客户端中将MTU调小至1400 |
结合上述系统层级排查手段，无论面对复杂的校园网802.1x认证、酒店网页认证热点，还是移动蜂窝热点漫游，均能从容恢复网络通信。