先区分客户端状态与网页请求

Clash 客户端显示“已连接”，通常表示内核运行、代理开关启用或某次检测成功，不代表浏览器的每个请求都已经过节点。完整链路包含应用代理入口、内核规则、出口节点、域名解析和目标服务。任何一段出错，都可能表现为网页一直转圈。

排查时每轮只改一个变量。先保留当前配置与覆写文件，记录客户端名称、内核版本、所选策略和报错时间。不同客户端的设置名称不同，下面以配置字段、系统入口和可观察结果为准，不把某一款客户端的按钮名称当作通用菜单。

  • 所有应用都无法上网：先关闭代理与 TUN，确认 Wi-Fi、网线、默认网关及网络认证是否正常。
  • 只有浏览器打不开：检查浏览器扩展、独立代理设置、安全 DNS 和缓存。
  • 只有部分站点打不开：优先检查命中规则、节点出口与目标站点限制。
  • 开启 TUN 后才断网：先用系统代理建立可用基线，再检查路由接管。

第一步：确认系统代理指向实际监听端口

系统代理常见入口是 127.0.0.1:7890，但 7890 不是固定要求。应以当前运行配置中的 mixed-port 为准。它同时接收 HTTP 与 SOCKS 代理连接；external-controller 是控制接口，不能用来填写浏览器代理端口。

核对系统设置与浏览器设置

  • Windows 11：打开「设置」→「网络和 Internet」→「代理」，检查手动代理的地址和端口。若客户端使用自动配置脚本，则核对实际启用的入口，避免手动代理与旧脚本混用。
  • macOS：打开「系统设置」→「网络」→ 当前网络连接 →「详细信息」→「代理」，检查 HTTP、HTTPS 或 SOCKS 的配置与客户端是否一致。
  • Firefox：打开「设置」→「常规」→「网络设置」→「设置」，确认使用系统代理，或核对手动配置的地址与端口。
  • 手机端通常通过本地 VPN 接管流量，不能照搬桌面的系统代理入口；先确认系统中当前启用的是哪个 VPN 配置。

检查端口是否真正监听

下面的 Windows PowerShell 命令用于检查 TCP 7890 的监听状态和进程编号。没有输出表示当前没有该端口的 TCP 监听，不应继续假定系统代理已经连上内核。

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

在 macOS 或安装了 lsof 的 Linux 系统中，可检查同一端口：

lsof -nP -iTCP:7890 -sTCP:LISTEN

如果配置改成 mixed-port: 7891，系统代理、命令行代理和应用内手动代理都要同步改为 7891。本机使用时，监听在回环地址是正常情况，不必为了排障直接启用局域网访问。

第二步：用显式代理请求隔离浏览器问题

先暂时关闭 TUN，保留内核运行，再用命令显式指定代理。这能绕开浏览器扩展与系统代理选择过程。Windows 使用 curl.exe，避免某些 PowerShell 环境将 curl 解析为其他命令；macOS 与 Linux 使用 curl。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

这里的 example.com 用作公开测试域名，不代表固定测速目标。--noproxy "" 用于避免环境中的代理绕过列表影响测试。若要测试不经显式代理的路径，可在 TUN 关闭后执行：

curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com
观察结果下一步检查
提示无法连接 127.0.0.1:7890检查监听端口、内核是否退出，以及客户端是否应用了当前配置。
显式代理成功，浏览器失败检查系统代理、扩展、浏览器独立代理和安全 DNS；用新建浏览器配置复测。
出现 407 响应检查本地代理认证设置，以及请求使用的用户名、密码。
建立连接后超时或 TLS 失败继续检查出口节点、目标连接、系统时间与证书错误详情。

HTTPS 代理日志中的 200 Connection established 只表示 CONNECT 隧道被接受，还要看后续 TLS 握手和目标服务器响应。目标返回 403 或 405 说明至少收到了一次 HTTP 响应，但不表示站点业务可用；必要时改用普通 GET 请求复核。

第三步：检查模式、规则与最终出口

打开客户端连接列表，刷新一次故障网页，按域名或进程寻找对应连接。重点看匹配规则、策略组和最终节点，而不是只看首页选中的节点名称。规则可能把该域名交给 DIRECT、REJECT 或另一个策略组。

  • rule：按规则顺序匹配，首个命中项决定策略。检查较靠前的域名规则、规则集与末尾 MATCH。
  • global：用于短暂对照测试，并确认 GLOBAL 策略实际选中了预期节点。切换全局并不保证节点可用。
  • direct：进入内核的连接按直连处理，不能用于验证代理节点是否通畅。

如果同一网址在全局模式可用、规则模式失败，应查看规则模式下的实际出口。常见原因是订阅规则让目标直连，或某个嵌套策略组仍选中不可用节点。修改后恢复 rule，再确认新连接命中了预期策略。

连接列表没有记录时

先确认列表没有被筛选，网页不是直接从缓存读取，内核日志也确实记录了测试时段。仍看不到请求，优先回到应用入口与 TUN 接管排查，不要先重写规则。浏览器可能使用独立代理、VPN 或其他网络扩展，使请求根本没有进入当前内核。

第四步：验证节点，而不是只看延迟数字

节点显示延迟，表示它完成了客户端指定的探测请求。这个结果不能覆盖所有目标域名、UDP 流量、IPv6 路径或长连接。某个探测地址可达，而目标网站被出口限制，仍可能出现“延迟正常但网页打不开”。

  1. 固定同一个目标网址，分别用两个节点测试，避免一边换节点一边换网站。
  2. 检查订阅服务的有效期、流量余额及节点参数是否更新。只从已有的可信订阅入口更新，不把订阅地址提交给在线检测站。
  3. 查看日志中的具体错误，例如连接节点超时、认证失败、TLS 握手失败或域名解析失败。
  4. 核对系统日期和时间。时间偏差可能导致证书验证失败，不应通过关闭证书验证来掩盖问题。

如果所有节点都在连接服务器阶段超时，还要检查当前网络是否限制相应传输端口。切换手机热点可作为网络路径对照，但它只是定位手段，不等于证明节点配置一定正确。

第五步：分清系统 DNS、内核 DNS 与浏览器安全 DNS

DNS 故障需要先判断“谁在解析”。系统解析器、mihomo 的 DNS 模块和浏览器的加密 DNS 可能走不同路径。系统 nslookup 成功，不足以证明内核 DNS 正常；内核 DNS 正常，也不能保证浏览器使用了同一个解析入口。

先观察，再修改 nameserver

Windows 可先查看系统 DNS 返回结果。命令会显示所用服务器与响应地址；如果请求超时，应继续检查该 DNS 服务器的网络可达性。

nslookup example.com

若正在使用 mihomo，并希望单独观察内核 DNS，可在确认端口未占用后，将下面片段合并到现有 dns 段。它只是诊断片段，不包含节点、策略组和规则，不能单独作为完整配置运行。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1

这里的 1.1.1.1 是普通 DNS 上游示例，能否访问取决于当前网络。已有企业或校园 DNS 要求时，应保留符合网络环境的设置，不要把公共 DNS 当作通用修复。配置生效后，可用安装了 dig 的终端查询指定端口：

dig @127.0.0.1 -p 1053 example.com A

在 fake-ip 模式下，返回配置范围内的映射地址可能是正常现象。它用于关联域名与后续连接，不是目标站点的真实公网地址。若应用拿到映射地址，但后续连接绕开内核，网页就可能失败；因此 Fake-IP 必须与实际接管路径一起检查。

  • 节点服务器使用域名：先确认服务器域名能够解析。mihomo 的 proxy-server-nameserver 可用于指定节点服务器域名的解析上游，避免建立代理前就依赖该代理的循环。
  • 使用 fallback：它与 fallback-filter 配合参与解析结果选择，不是所有连接超时的通用备用开关。
  • 使用浏览器安全 DNS：临时切回系统解析做对照，随后恢复需要的设置。不要同时更改浏览器和内核的多组上游。
  • 只有部分站点卡顿：对比 A、AAAA 记录及 IPv6 连通性。先用 curl -4 与 curl -6 对照，不要把关闭 IPv6 作为默认答案。

Windows 可在修改解析设置后执行 ipconfig /flushdns 清理系统 DNS 缓存，并重启浏览器。它不会清除所有浏览器缓存或内核 Fake-IP 映射，也不能修复不可达的 DNS 上游。

第六步：系统代理可用后，再排查 TUN 与防火墙

如果显式 HTTP 代理测试成功，而开启 TUN 后失败，说明应重点检查流量接管。TUN 依赖虚拟网卡、路由及运行权限；客户端开关显示启用，不足以证明路由已经安装成功。先查看启动日志，确认没有权限不足、设备创建失败或路由冲突。

检查接管范围与 DNS 劫持

mihomo 中的 tun.auto-route 用于自动设置路由，tun.auto-detect-interface 用于辅助识别出口接口，具体支持情况应以当前内核和平台为准。存在多个网卡、其他 VPN 或虚拟机网络时，自动识别可能不符合预期。

tun.dns-hijack 可将匹配的传统 DNS 请求交给内核 DNS。常见条目是 any:53；若需要匹配 TCP 53，应按内核支持情况配置 tcp://any:53。这不会自动接管浏览器发往 HTTPS 443 的加密 DNS 请求，也不能代替可用的上游解析器。

  1. 暂时退出其他 VPN、加速器或重复运行的代理客户端，再只启动一个接管程序。
  2. 确认客户端要求的服务已安装并运行，或按其说明以所需权限启动，随后检查日志。
  3. Windows 使用 route print，Linux 使用 ip route 查看路由，核对实际出口，不要盲目删除系统路由。
  4. 防火墙中检查当前内核可执行文件是否获准联网。客户端更新导致路径改变时，旧规则可能不再匹配。
  5. 若仅 TUN 下的大文件或部分 HTTPS 页面卡住，再考虑 MTU、路径 MTU 探测和 UDP 支持；不要在没有证据时反复切换网络栈。

恢复使用前：确认配置生效与结果可复现

客户端可能同时存在订阅原文、覆写配置和最终运行配置。编辑某个 YAML 文件，不代表内核读取的就是该文件。先在客户端确认当前配置来源，再查看实际应用的端口、DNS 与 TUN 字段。

若使用独立 mihomo，可在配置目录中用下面的 Windows 命令检查语法。该命令假定当前目录已有 mihomo.exe 与 config.yaml；图形客户端用户应优先使用其配置检查入口，不要另外启动第二个内核争用端口。

.\mihomo.exe -t -f .\config.yaml

语法检查通过只说明配置能够被解析，不保证节点、DNS 或网络可达。完成修复后，按以下顺序收尾：

  • 恢复日常使用的规则模式，检查一个直连目标和一个代理目标的实际出口。
  • 重新打开浏览器，复测原先失败的网址，并核对同一时段的连接记录。
  • 将临时调试日志恢复到日常级别，移除不再需要的测试监听端口。
  • 记录最终端口、修改字段和生效方式，避免下次订阅更新覆盖修复。

仍无法定位时，提供客户端与内核版本、系统版本、故障时间、系统代理与 TUN 开关状态，以及经过脱敏的单次请求日志。清晰的最小复现，比一张“已连接”截图更能说明问题。基础入口可参考使用指南，字段含义可继续查阅mihomo 进阶配置。