节点显示超时或连不上:按顺序逐项排查

1. 区分测速超时与实际连接失败

FlClash 中的延迟测试通常是经节点请求指定测试地址，并非单纯对节点服务器执行 ping。显示“超时”，表示这次探测没有在限制时间内完成；问题可能出在节点入口、域名解析、协议握手，也可能只是测试站点不可达。先记录现象，再决定检查哪一层。

2. 本地网络：先确认关闭接管后能够直连

先在 FlClash 中关闭系统代理和 TUN，再访问平时能够直连的网站。如果操作系统仍保存了手动代理，也要检查并恢复；只退出客户端，可能留下指向本地端口的代理设置。此时浏览器会继续连接已经停止监听的端口，看起来就像整个网络中断。

检查网络入口与系统时间

1. 完成联网认证。酒店、校园或公共 Wi-Fi 可能需要先在浏览器完成认证。确认系统没有“需要登录网络”的提示。
2. 检查系统代理。Windows 11 可打开「设置」→「网络和 Internet」→「代理」，核对手动代理与设置脚本；macOS 可打开「系统设置」→「网络」→ 当前网络 →「详细信息」→「代理」。
3. 校准时间。Windows 11 的路径为「设置」→「时间和语言」→「日期和时间」。日期、时区或时钟偏差可能影响 TLS 证书验证及部分代理协议认证。
4. 更换接入网络。保持节点不变，将电脑从原来的 Wi-Fi 切到手机热点。如果热点下可以连接，优先检查原网络的 DNS、防火墙或出口限制。

普通网站能直连，只能说明基础联网可用，不能证明节点端口也能通过。反过来，ping 没有回应也不足以证明服务器离线，因为服务器或运营网络可能过滤 ICMP。后续需要针对订阅中的服务器地址和实际端口继续验证。

3. 订阅有效性：区分下载成功、配置生效与账户可用

在 FlClash 的「配置」页面，找到当前使用的订阅，手动执行更新，并确认选中的仍是这份配置。不同版本的按钮名称可能略有差异，应以当前界面为准。更新完成后，再到「代理」页面核对节点列表及所选策略组，避免测速的是旧配置或另一个组里的节点。

按三个层次检查

• 订阅请求：返回 HTTP 401 或 403 时，重点检查链接凭据和服务端访问限制；返回 404 时，核对地址是否过期或路径是否改变。HTTP 200 只代表请求成功，响应也可能是登录页而非配置。
• 配置解析：检查日志是否出现 YAML 语法错误、未知代理类型或配置加载失败。适用于其他客户端的分享链接，不一定能直接当作 mihomo 完整配置导入。
• 服务账户：到订阅提供方页面确认到期时间、剩余流量、设备数量与维护公告。账户失效时，本地仍可能保留完整节点列表。

如果配置使用远程代理集合，还要查看对应集合是否更新成功。主配置下载成功，并不代表每个远程资源都已刷新。需要重新导入时，可参考订阅导入步骤；订阅来源的说明见订阅来源与使用范围。

4. 系统代理与 TUN：确认请求确实进入 FlClash

系统代理主要影响遵循系统代理设置的应用；TUN 则通过虚拟网络接口和路由接管流量。两者的排查起点不同。先选一种路径做最小验证，比同时启用多个客户端、浏览器代理扩展和 TUN 更容易定位问题。

桌面端：先验证本地代理端口

关闭 TUN，保留 FlClash 内核运行，检查客户端显示的实际监听地址、混合端口和系统代理开关。下面仅以本机混合端口 7890 为例；若配置使用其他端口，必须按实际值修改。端口号不能仅凭教程猜测。

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

Windows PowerShell 中可将命令开头改为 curl.exe，避免旧环境把 curl 解释为其他命令。执行时同时观察 FlClash 的连接记录：收到 HTTP 响应，说明该次代理请求已到达目标；出现本地端口拒绝连接，则应先检查监听端口、内核运行状态或端口占用。

• 命令能通、浏览器不通：重点检查系统代理、浏览器扩展、浏览器自身代理设置，以及是否用了另一份自动代理脚本。
• 连接进入客户端、但出口错误：检查「代理」页面的模式和策略组选择。规则模式可能将目标分到 DIRECT，测速成功也不代表实际网页使用了该节点。
• 连接记录完全没有请求：先检查应用是否绕过代理。不要在此阶段反复修改远端节点参数。

TUN 路径：检查权限、路由与 VPN 冲突

停止其他 VPN 或同类 TUN 客户端，按系统提示授予所需权限，再单独启用 FlClash 的 TUN。查看日志是否明确报告虚拟接口创建失败、权限不足或路由写入失败。桌面环境可能需要管理员权限或客户端提供的服务支持，具体取决于系统与版本。

Android 上应确认已批准 VPN 连接请求，同时检查应用访问控制是否把目标应用排除。若系统设置了其他“始终开启的 VPN”或“阻止未使用 VPN 的连接”，也应核对。不要通过长期关闭防火墙来验证；可以检查拦截日志，并为确认可信的客户端建立范围明确的规则。

5. DNS 设置：分别检查节点域名与目标域名

代理连接通常涉及两类解析：一类是把节点服务器域名解析成入口 IP，另一类是处理要访问的网站域名。节点入口解析失败时，连接还没到代理服务器；目标域名解析失败时，则可能出现节点测速正常、部分网页无法打开的情况。判断时应结合错误日志中的具体主机名。

先用系统解析做对照

nslookup example.com

将命令中的域名换成实际出错的网站域名，或配置中节点服务器的域名。超时、无记录与返回异常地址分别代表不同方向。nslookup 结果只反映这次查询所走的解析路径，不能直接等同于 mihomo 的最终结果；启用 TUN DNS 劫持时，查询还可能被客户端接管。

• 日志出现解析错误：先确认 DNS 上游本身可达。使用加密 DNS 时，其服务器域名也需要完成引导解析，相关流量的路由要能成立。
• 日志出现循环拨号或反复解析：检查是否把解析节点入口所需的 DNS 请求，又交给了尚未连接成功的同一个代理。
• 仅浏览器异常：核对浏览器的“安全 DNS”或自定义解析设置，暂时恢复为系统解析做对照，然后重新访问相同网址。
• 返回 Fake-IP 地址：配置使用 Fake-IP 模式时，看到常见配置范围内的 198.18.0.0/16 地址并不自动代表解析错误，应继续检查地址映射和接管链路。

mihomo 配置中的 nameserver 与 proxy-server-nameserver 有不同用途，后者用于代理节点域名解析。配置由订阅或覆写功能管理时，应先备份并确认最终生效内容，再修改相应字段。随机粘贴一整段 DNS 配置，容易同时改变解析模式、路由行为和规则匹配条件。

6. 节点本身：从入口连接检查到协议握手

完成前面的本地验证后，再检查远端节点。先固定一个节点，在原网络和手机热点各测试一次；随后固定网络，换一个不同入口的节点。两个看似不同的节点名称可能共用同一服务器，因此应结合服务器地址判断，而不是只看地区名称。

按错误阶段读取日志

对于使用 TCP 入口的节点，Windows PowerShell 可检查实际服务器端口是否可达。下面是命令格式示例，域名使用保留的示例域名，不能将执行结果视为真实节点状态：

Test-NetConnection -ComputerName node.example.com -Port 443

应换成配置中的真实地址和端口，并且只检查有权使用的服务。TcpTestSucceeded 为真，只说明 TCP 连接建立成功，不代表密码、TLS、WebSocket 路径或完整代理协议正确。Hysteria2、TUIC 等使用 UDP 传输的节点，也不能用 TCP 探测结果判断其可用性。

若 TCP 可达但协议握手失败，应优先重新获取服务方配置，核对服务器名称、认证信息与传输参数。遇到证书错误时，应修复时间、证书链或服务端名称配置，避免把跳过证书验证当作长期处理方式。

7. 恢复验证：记录结果，再恢复日常模式

节点恢复后，回到日常使用的规则模式，重新打开系统代理或 TUN 中实际需要的接管方式。依次检查一个直连站点、一个需要代理的站点和一个常用应用，并在连接记录中确认出站策略。全局模式下能访问，只能说明该次代理链路可用；规则模式下的分流仍需单独确认。

1. 记录环境：操作系统、FlClash 版本、内核版本，以及故障发生的日期和时间。版本信息以客户端实际显示为准。
2. 记录对照：原 Wi-Fi 与热点是否有差异，同一节点是否在其他设备可用，其他入口是否正常。
3. 记录链路：使用系统代理还是 TUN、实际监听端口、出站模式，以及请求命中的策略组。
4. 保存错误：只截取与本次复现对应的日志片段，隐藏凭据、订阅链接和不必要的访问记录。

如果全部节点只在一个网络下失败，优先处理该网络的解析和出口限制；如果某个节点在不同网络、不同设备上都失败，则应把入口与日志信息交给服务方核查。按层定位后再修改配置，才能保留明确的因果关系。更多接管与分流概念可参考协议详解。