一、先区分“内核运行”与“网页可达”

客户端的运行状态通常只能说明内核已经启动，或者系统代理开关已经打开。节点延迟测试成功，也只证明测试请求在当时能够完成；浏览器访问另一个域名时，可能走不同的规则、策略组或 DNS 路径。因此，不要看到“已连接”就直接判断故障在网站，也不要一次修改端口、DNS 和规则三个位置。

排查前先记录客户端名称、内核类型、当前配置名称、工作模式与本地监听端口。Clash 与 Clash Meta（现称 mihomo）的配置能力并不完全相同，图形界面的菜单也随客户端变化。下文使用“系统代理”“连接”“日志”等功能名称定位；操作系统菜单则给出具体路径。

  1. 确认当前使用的配置确实已选中，而不只是订阅下载成功。
  2. 记下网页报错，例如 ERR_PROXY_CONNECTION_FAILED、ERR_NAME_NOT_RESOLVED 或连接超时。
  3. 选择一个失败网址作为固定测试对象，每次修改后重新发起请求，并记录结果。
  4. 临时退出其他代理客户端、浏览器代理扩展及网络加速工具，避免多个程序同时修改代理设置。

二、关闭代理，验证本地网络基线

先关闭客户端的系统代理与 TUN，再检查系统中是否还残留手动代理。Windows 11 可打开「设置」→「网络和 Internet」→「代理」；macOS 可打开「系统设置」→「网络」→ 当前网络连接 →「详细信息」→「代理」。如果正在使用 PAC 自动配置脚本，也要记录脚本地址，避免将 PAC 与手动代理混为一谈。

随后访问一个在当前网络下本应能够直连的网站，并检查 Wi-Fi 是否需要登录认证。酒店、校园或公共网络未完成认证时，客户端启动并不能绕过本地接入限制。可以在终端执行以下命令，观察直连 HTTPS 是否能够建立：

curl -I --noproxy "*" --connect-timeout 10 https://example.com/

Windows 下建议使用 curl.exe，避免旧版 Windows PowerShell 把 curl 解释为其他命令。此命令只测试指定站点，失败不能证明整个网络中断；应结合另一个本地可访问站点或手机热点复测。若关闭全部代理后，连路由器管理页和常用直连站点都打不开，优先处理网络接入、认证或系统网络设置。

三、检查系统代理地址与本地监听端口

先核对端口，再打开系统代理

在客户端设置中找到 HTTP 端口或混合端口，并与操作系统的代理地址逐项对照。例如，配置若实际监听 mixed-port: 7890，同一台电脑的手动代理可使用 127.0.0.1:7890。这里的 7890 是示例，不是所有客户端的固定默认值；若界面显示 7897，命令与系统设置都应改为实际值。

HTTP 代理端口和仅支持 SOCKS 的端口不能随意互换。系统设置指向已关闭的端口时，浏览器常会直接显示代理连接失败。可以绕开系统代理设置，显式指定 HTTP 代理测试：

curl -I --proxy http://127.0.0.1:7890 --connect-timeout 10 https://example.com/
  • 显式代理成功，浏览器失败：检查系统代理是否被其他程序改写、浏览器扩展是否覆盖设置，以及该浏览器是否使用独立代理配置。
  • 立即提示无法连接到 127.0.0.1：先查内核是否启动和端口是否监听，此时还没有必要调整远端节点。
  • 显示 200 Connection established 后仍失败：这只说明 HTTP 代理接受了隧道请求，不代表后续 TLS 握手和网页响应已经成功。
  • 返回 407：检查本地代理是否配置了身份验证，不能把认证失败当成节点超时。

确认占用端口的确实是当前客户端

在 Windows 终端执行以下命令，查找监听状态及进程编号；macOS 可用第二条命令查看监听进程：

netstat -ano | findstr ":7890"
lsof -nP -iTCP:7890 -sTCP:LISTEN

Windows 输出中应重点看本地地址与 LISTENING 状态，再到「任务管理器」→「详细信息」按 PID 核对进程。不要仅凭输出出现了端口数字就判断监听正常。若端口被旧客户端占用，应正常退出旧程序，或为当前客户端更换空闲端口并同步更新系统代理。仅供本机使用时，通常无需开启“允许局域网连接”。

四、用连接记录定位规则与策略组

保持规则模式，打开客户端的「连接」或「日志」页面，再刷新失败网页。记录目标域名、匹配规则、策略组和最终出口。已有长连接可能继续使用旧出口，因此切换节点后应关闭对应连接，或重启浏览器再测试。没有任何记录时，先确认日志没有过滤掉目标请求；如果仍无记录，应返回检查代理入口。

观察到的结果优先检查下一步操作
目标连接命中 REJECT域名规则、规则集和广告拦截规则定位具体条目，确认是否误拦登录、验证或静态资源域名
目标连接走 DIRECT该站点是否适合当前网络直连检查命中的域名规则及末尾兜底规则
进入代理组但仍超时组内实际选中的节点及嵌套策略组换一个可用出口，对同一网址复测
仅部分资源加载失败图片、脚本、接口各自的出口按失败域名检查，不只看网页主域名

Clash 规则按顺序匹配，首条匹配生效。一个过宽的 DOMAIN-SUFFIX 规则放在前面，可能让后面的精确规则没有机会执行。若怀疑规则问题，可短暂切换全局模式，并明确选中一个可用节点进行对照：同一网址在全局模式可用、规则模式不可用时，应重点比较出口与命中记录，而不是长期保持全局模式掩盖配置问题。

五、区分系统 DNS 与内核 DNS 故障

浏览器提示域名解析失败，不一定是系统 DNS 单独出错。系统解析器、浏览器的安全 DNS、内核 DNS 和远端节点都可能参与解析；实际路径取决于代理方式与配置。先运行以下命令，检查系统解析器对目标域名的回答：

nslookup example.com

nslookup 成功只说明这次系统侧查询得到了响应，不证明内核正在使用的上游正常；反过来，系统查询失败也不代表由代理端解析域名的请求一定失败。HTTP 代理访问 HTTPS 时，客户端通常能收到目标域名；SOCKS 测试中，socks5:// 与 socks5h:// 还涉及不同的域名解析位置，比较结果时要保留这个区别。

按实际解析路径逐层检查

  1. 在日志中搜索 DNS、resolve、timeout，核对出错的域名和上游地址，不要只看最后一条超时。
  2. 如果启用了 DoH 或 DoT，确认上游地址本身可达；上游使用域名时，还要检查其引导解析是否存在循环依赖。
  3. 临时关闭浏览器的“安全 DNS”进行对照，测试后恢复原设置。浏览器自建的加密 DNS 连接可能走不同于系统解析器的路径。
  4. 使用 fake-ip 时，看到 198.18.0.0/15 范围内的映射地址并不自动代表解析错误；应继续确认后续连接是否被内核接管并正确还原域名。

Windows 修改 DNS 后可执行 ipconfig /flushdns 清除系统缓存；客户端内核缓存与浏览器缓存可能仍需分别清理。不要用“直接访问网站 IP”代替完整测试：HTTPS 站点依赖域名参与证书校验、SNI 和虚拟主机选择，直接访问 IP 失败可能与 DNS 无关。

六、系统代理正常后再检查 TUN

如果显式代理与浏览器系统代理都正常，只有打开 TUN 才断网，排查重点应转向虚拟网卡、路由和 DNS 接管。TUN 用于接管被路由到虚拟网卡的 IP 流量，并不保证每个应用、每种网络环境都会自动获得正确配置。权限不足、驱动异常或其他 VPN 安装的路由，都可能造成流量走错接口。

  • 权限与服务：确认客户端要求的服务模式或管理员授权已经完成，并查看内核是否明确报告 TUN 启动成功。
  • 路由冲突：暂时断开其他 VPN，再用 Windows 的 route print 或 macOS 的 netstat -rn 对比开启前后的路由。
  • DNS 接管：检查配置中的 dns-hijack 与实际 DNS 路径是否一致；不能假定接管普通 53 端口就能接管浏览器的 DoH。
  • IPv6 路径：当域名同时返回 A 与 AAAA 记录时，分别检查 IPv4、IPv6 的路由与接管状态，不要仅凭 IPv4 测试成功判断全部流量正常。

网页能打开但大图片或下载容易停住时，可以进一步观察丢包、MTU 和协议差异；不过这些属于入口、规则与 DNS 都确认正常后的检查项。没有证据时直接改 MTU，容易增加变量，也会让原始故障更难复现。

七、只剩特定网站失败时检查上游与浏览器

如果不同浏览器访问同一站点都失败，而其他站点正常，应换一个节点访问同一目标，并检查订阅状态、节点协议参数及系统时间。系统时间偏差可能导致 TLS 证书验证失败；订阅能更新则只证明配置获取成功，并不能证明每个节点仍然可用。

若只有一个浏览器异常，使用未启用扩展的新配置文件进行对照，再检查独立代理、安全 DNS、缓存与站点权限。无痕窗口仍可能保留部分允许在无痕模式运行的扩展，所以不能把无痕测试等同于排除了所有扩展。遇到证书错误时，应记录错误代码和证书颁发者，不要通过安装来源不明的根证书来消除提示。

节点延迟低但网页慢，还可能与目标站点距离、丢包、带宽或服务端限速有关。一次延迟测试不能替代真实网页请求。应使用相同网址、相同网络、相同时间段做对照，避免把更换测试对象后的差异归因于刚才的设置修改。

八、整理结果并恢复日常配置

排查结束后恢复规则模式，撤销没有产生改善的临时修改，确认系统代理端口与客户端一致，再决定是否启用 TUN。若关闭客户端后出现全局断网，应先检查系统是否仍指向已经停止监听的本地代理，而不是立即重置整个网络。

需要进一步求助时，提供可复现信息比只发“已连接但打不开”更有用。建议按下面的清单整理，并隐藏订阅链接、访问令牌、节点密码、个人 IP 与其他敏感信息：

  • 操作系统、客户端与内核的准确版本，以及使用系统代理还是 TUN。
  • 失败目标的域名和浏览器错误代码，不要公开含有登录令牌的完整 URL。
  • 本地监听端口、显式代理测试结果，以及直连是否正常。
  • 同一请求的匹配规则、策略组、最终出口和对应时间段的错误日志。
  • 切换节点、关闭 TUN 或更换网络后，哪些结果发生了变化。

推荐的顺序始终是：本地网络 → 代理入口 → 监听端口 → 规则出口 → DNS → TUN 与上游。每次只调整一项，并用同一个请求验证，这样才能把“看起来正常”的状态转化为能够解释的连接结果。