Clash Verge Rev
先说结论：“网页打不开”只是结果，不是诊断。先判断失败发生在域名解析、连接建立、TLS 校验还是应用层，再检查这次请求是否真的经过 Clash Verge Rev。浏览器正常而应用离线，也可能是两者走了不同的解析和代理路径。
本文面向 Windows、macOS 和 Linux 桌面用户，是一套依据公开文档整理的诊断方法，不是对所有网络环境的实测保证。菜单名称会随客户端版本变化；企业或学校管理的 DNS、VPN 与安全策略应交由管理员处理。
一、先建立一份可比较的故障记录
选择一个你有权访问、能够稳定复现问题的目标。记录客户端与内核版本、操作系统、当前配置名称、系统代理与 TUN 状态、出错应用、发生时间和错误原文。不要先刷新订阅、换节点、改 DNS、关 IPv6 一起做，否则即使恢复也无法知道哪个动作有效。
对同一个目标分别记录“浏览器是否正常、原应用是否正常、连接记录是否出现”。必要时在获准使用的另一网络重复一次，但保持其他条件不变。敏感内网域名不要拿到公共 DNS 或公开检测网站查询。
二、从错误所在的层开始，而不是从开关开始
- 解析超时或找不到主机：检查使用了哪个解析器、是否可达、是否命中本地 hosts 或缓存。单次超时不能直接证明域名被污染。
- 得到地址但连接超时：继续看目标服务、路由、节点和防火墙，不要把“能解析”当作“能连接”。
- 证书名称不匹配或 TLS 失败：核对系统时间、目标域名、可信证书和网络中间设备。不要通过关闭证书校验来掩盖原因。
- 已经收到 HTTP 403、404 或 429：这次请求至少已经到达一个 HTTP 响应端，但响应可能来自目标、代理或中间网关，仍需核实来源。
这四层是本文的工作分类，不是某个错误码的唯一解释。尤其是“其他网站正常、只有一个站点异常”，应优先保留目标特异性的证据，而不是重置整台电脑的网络。
三、区分应用解析、系统解析与内核解析
先用连接记录和日志验证流量有没有进入内核。系统代理只是应用可能采用的一种配置，并不保证每个进程都遵循；TUN 的路由与 DNS 接管也应分别核实，不能仅凭开关亮起就认定所有查询都已被接管。
在普通终端执行 nslookup example.com 可以观察该工具发出的 DNS 查询结果；它不等于浏览器、应用内部缓存或整个系统解析链的完整行为。Firefox 的 DoH 设置是另一条需要单独核对的线索。关于内核解析流程与接管范围，参见文末的 Mihomo 资料。
四、Fake-IP 返回“特殊地址”不一定是错误
当运行配置使用 Fake-IP 时，返回的地址可能是用于映射的地址，而非网站的真实公网地址。看到 198.18.x.x 这类结果时，先对照当前 fake-ip-range，不要立即把它判为污染，也不要写入系统 hosts。
下一步要问的是：应用拿到映射地址后，后续连接是否仍进入负责该映射的内核？如果应用绕开接管路径、旧缓存未失效，或切换配置后仍复用旧连接，就可能出现“解析成功但连接失败”。这是需要用日志验证的假设，不是仅凭地址就能下的结论。
若问题只在特定应用出现，先保留当前配置副本，再查该应用与 Fake-IP 的兼容性。确有证据需要例外时，只处理必要域名；不要整段替换 DNS 配置或把所有域名都排除。
五、DoH 与 IPv6 应做对照，不应被一键关闭
浏览器启用自己的 DoH 后，解析结果可能与命令行工具不同。普通 53 端口的 DNS 接管不等同于解密 HTTPS 内的 DNS 请求。先记录浏览器的安全 DNS 设置与管理策略；如允许做临时对照，测试后恢复原设置，不要把永久关闭加密 DNS 当作默认修复。
IPv6 也需要分清“是否得到 AAAA 记录”与“IPv6 路径是否可用”。Mihomo 的 dns.ipv6 控制 DNS 的 AAAA 回应行为，并不等于操作系统的全局 IPv6 开关。只有发现同一目标在 IPv4 与 IPv6 路径上结果不同，才进一步检查路由、节点能力与应用选路。
六、用一次显式代理测试缩小范围
以下测试只适用于已经启用本机 SOCKS 或混合监听的情况。把 PORT 替换成界面显示的实际端口，目标换成允许访问且不含令牌的测试地址；没有监听时不要为了照抄命令去开放局域网。
curl --proxy socks5h://127.0.0.1:PORT --noproxy "" --connect-timeout 10 --max-time 20 -I https://example.comWindows PowerShell 中可使用 curl.exe 调用实际程序。socks5h 将目标主机名交由 SOCKS 代理解析；该测试只比较这条显式代理路径，并不完全模拟原应用。若站点不接受 HEAD 请求，收到方法错误也不能直接判为网络失败。
显式代理成功、原应用失败：优先检查应用接管路径与缓存。两者都失败：结合内核日志区分目标解析、节点连接和规则选择。两者都成功但偶发失败：记录时间及重复条件，再检查网络切换、休眠恢复与连接复用。
七、每次修复都必须有撤销与复测
- 备份当前配置，记录要验证的单一假设。
- 只修改相关的一项设置，通过客户端支持的方式应用并检查是否报错。
- 关闭并重新打开测试应用，必要时按系统或应用文档处理对应缓存；不要直接清空整个配置目录。
- 用原目标、一个正常对照目标和原故障应用复测。
- 没有改善就还原；改善后再测试重启客户端或网络重连，确认不是偶然恢复。
如果解析器自身或代理节点域名无法解析，应回到引导解析链检查。不要为了让请求成功而关闭防火墙、关闭 TLS 校验或公开控制接口。
八、案例与提交问题前的检查
假设案例：浏览器正常，桌面应用超时，应用连接记录中没有对应请求。合理的下一步是核实该应用是否采用系统代理，以及 TUN 是否覆盖它，而不是因为浏览器能访问就认定 DNS 完全正常。若后来显式代理测试成功，证据进一步指向应用接入路径，但仍不能证明应用自身没有其他故障。
提交问题时附上版本、系统、模式、脱敏错误、复现时间和“修改前后各一次结果”。删除订阅完整 URL、查询参数中的令牌、节点认证信息与控制密钥。成功标准应是原应用恢复、对照目标不受影响、重新连接后仍可复现正常，而不是只看到一次测速数字。
延伸阅读
参考资料
参考资料核对：2026-10-14。以下链接为项目及平台文档；本文为本站独立编辑指南。