FlClash 节点超时、无法连接怎么办：从订阅、时间同步到 DNS 的逐层排查顺序

1. 先区分节点测试超时与实际访问失败

FlClash 的节点测试失败，不一定意味着所有网页都无法打开。测试会访问指定的检测地址；地址被阻断、返回异常或响应超过测试时限，都可能显示超时。反过来，测试成功也只代表这一次探测可用，不能证明所有域名、UDP 请求和应用连接都正常。

排查时先保留现场：记录 FlClash 版本、操作系统版本、当前配置名称、出站模式，以及一次失败发生的时间。随后用同一个网址、同一种访问方式复测，每次只改一个设置。不同版本的菜单位置可能变化，下面以设置项名称和可核对的系统操作为准，不把示例端口视为客户端默认值。

先暂时停止其他代理客户端和 VPN，避免多个程序同时改写系统代理或路由。需要访问公司网络时，不要擅自停用受管理的安全软件，应先向管理员确认允许的连接方式。

2. 核对订阅更新与当前配置是否一致

更新成功之后，还要确认正在使用哪份配置

1. 打开 FlClash 的配置列表，找到预期使用的订阅，执行更新，记录结果与更新时间。
2. 确认当前选中的配置就是刚更新的那一份。列表里存在新配置，不等于内核已经切换到该配置。
3. 检查代理页面是否出现预期的策略组与节点。若策略组为空，先查看配置加载错误，不要直接修改 DNS。
4. 在当前规则引用的策略组里手动选择一个节点，再对同一网址测试。自动选择组可能在测试时重新选择出站，导致前后结果不可比。

订阅下载失败和节点连接失败是两条不同链路。前者是客户端获取配置的过程，后者是 mihomo 内核按配置连接服务器的过程。旧配置仍可能继续运行，因此“订阅更新失败，但网页还能打开”并不矛盾。

按返回错误处理，不反复导入同一地址

• HTTP 401 或 403：检查订阅是否过期、链接是否被重置，以及服务端是否限制了访问；这些状态码也可能来自网关，需结合响应来源判断。
• HTTP 200，但配置解析失败：响应可能是登录页、验证页或不兼容的内容。状态码成功不代表返回的是有效配置。
• 域名解析失败或连接超时：先确认当前网络能否访问订阅所在域名。订阅更新是否通过代理，取决于客户端版本与相关设置，不能从浏览器结果直接推断。
• 更新后部分节点消失：核对套餐状态和服务方变更，再检查配置中引用的策略组，避免继续选择已经失效的条目。

3. 检查基础网络与系统时间

先关闭 FlClash 的系统代理和 TUN，再检查普通直连网页能否访问。若网络需要门户认证，先完成 Wi-Fi 登录。可以将电脑切换到手机热点，保持配置和测试网址不变：如果同一节点只在某个网络失败，优先考虑该网络的出口限制、路由或 UDP 支持，而不是重装客户端。

时间偏差会影响 TLS 与部分协议认证

系统日期、时区显示和实际时间应分别核对。时区显示不同不必然造成认证失败，但系统时钟偏离真实时间可能导致证书被判断为尚未生效或已经过期，部分带时间校验的协议也会拒绝连接。

• Windows 11：进入「设置」→「时间和语言」→「日期和时间」，开启「自动设置时间」，然后执行「立即同步」。
• Android：通常在「设置」→「系统」→「日期和时间」开启自动设置；不同厂商可能放在「更多设置」中。
• macOS：进入「系统设置」→「通用」→「日期与时间」，确认自动设置日期与时间已经开启。

同步后重新建立连接，观察证书错误是否消失。如果时间正确仍然出现 TLS 错误，应继续核对服务器域名、证书和配置中的 TLS 参数。不要用跳过证书验证作为常规修复，这会削弱连接身份验证，也不能解决服务器不可达。

4. 检查混合端口、内核启动与防火墙

系统代理只是把支持代理的应用指向本地监听端口。若 mihomo 没有启动，或者监听端口被另一个程序占用，浏览器即使显示已设置代理，也无法通过 FlClash 建立连接。先查看客户端日志中是否有 address already in use、bind 或配置加载失败信息。

用实际混合端口做显式代理测试

在 FlClash 设置中找到「混合端口」，记下数值。以下统一使用 7890 作为示例；只有客户端显示的端口也是 7890 时，才能直接执行。测试网址可换成当前确实需要访问、且允许访问的 HTTPS 站点。

# Windows PowerShell：查看 7890 的监听进程
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# Windows：显式通过本地 HTTP 代理发起请求
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 8 --max-time 20 https://example.com/

# macOS / Linux：检查监听，并执行同样的请求
lsof -nP -iTCP:7890 -sTCP:LISTEN
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 8 --max-time 20 https://example.com/

这里的 8 秒是连接阶段超时上限，20 秒是整次请求的总时限，不是节点质量标准。curl -I 发送 HEAD 请求，有些网站可能返回 403 或 405；收到 HTTP 响应说明连接已经推进到服务端响应阶段，但仍需结合 TLS 是否完成和客户端连接记录判断。

• 立即提示连接被拒绝：重点检查本地端口是否正确、内核是否运行。仅靠更换远端节点通常不能解决。
• 端口由其他进程监听：根据进程 ID 确认归属，正常退出冲突程序，或修改 FlClash 端口后同步更新应用代理设置。不要直接终止不明系统进程。
• 本地代理接入成功，随后超时：继续检查远端连接、规则和 DNS，查看同一时间的日志。

防火墙按程序和网络范围放行

防火墙或终端安全软件可能限制内核的出站连接。检查拦截记录，再针对实际可执行文件放行；升级后文件位置发生变化时，也要核对规则是否仍然有效。本机代理测试通常不需要开启「允许局域网连接」，也不需要开放公共网络入站端口。不要把关闭整套防火墙作为长期处理方式。

5. 用日志区分 DNS 解析失败与远端连接超时

域名涉及至少两个需要区分的对象：代理服务器域名，以及最终访问的网站域名。服务器域名无法解析时，连接代理服务器之前就会失败；网站域名的解析路径则取决于规则、出站协议和 DNS 设置。看到 DNS 错误后，先确认报错的是哪个域名，再决定修改哪一层。

系统查询只检查系统 DNS 路径

# 查询示例站点的系统 DNS 结果
nslookup example.com

如果系统查询也失败，可先检查网络是否正常、系统 DNS 是否可用。若查询成功，但 FlClash 日志仍提示 no such host 或解析超时，说明客户端内核使用的 DNS 路径仍需单独核对。配置中的 nameserver、proxy-server-nameserver 和 direct-nameserver 各有用途，不能把系统查询成功等同于这些路径全部正常。

• 节点服务器域名解析失败：检查用于解析代理服务器域名的解析器是否可达，避免解析器本身必须依赖尚未连通的代理才能访问。
• DNS-over-HTTPS 请求超时：检查解析服务域名的引导解析、HTTPS 连接和路由是否成立。把所有解析器换成同一个地址，可能扩大故障范围。
• 出现 198.18.0.0/15 范围内的地址：在 Fake-IP 模式下，这可能是预期的映射结果，不能仅凭地址形式认定解析错误。
• 仅一个网站异常：先核对该域名命中的规则、DNS 返回与目标服务状态，避免为了单站问题改动全部配置。

调整 DNS 后，通过客户端提供的重载或重启内核操作让配置生效，再关闭旧连接重新测试。Windows 的 ipconfig /flushdns 只刷新系统 DNS 缓存，不等于清除了 mihomo 的 DNS 缓存和已有连接。每次只改一项，并保留可恢复的原配置。

6. 核对出站模式、规则命中与 TUN 接管范围

规则模式失败时，用全局模式缩小范围

规则模式按从上到下的顺序匹配，先命中就采用对应出站。若浏览器请求命中了 DIRECT，即便节点测试成功，该请求也未必经过所选节点。打开客户端的连接记录，对照目标域名、命中规则和最终出站，确认问题请求实际走向。

1. 保持同一节点和测试网址，短暂切换到全局模式，并确认全局策略组选中了该节点。
2. 如果全局模式可用、规则模式失败，检查对应规则是否指向错误策略组、DIRECT 或 REJECT。
3. 如果两种模式都失败，继续检查服务器连接与 DNS，不要仅调整规则顺序。
4. 测试完成后恢复原模式。全局模式用于对照实验，不代表适合所有流量。

系统代理与 TUN 解决的不是同一个问题

显式代理测试成功，但某个应用仍无法访问时，应检查应用是否遵循系统代理。部分应用自行建立连接，或使用 UDP，不会因为开启系统代理就自动进入客户端。TUN 可以通过虚拟网络接口接管更多流量，但仍受路由、权限和排除规则影响，并不保证所有流量都被接管。

启用 TUN 前先确认普通代理链路可用。桌面系统可能需要管理员权限或服务支持；Android 需要授予 VPN 连接权限，且通常不能与另一个基于 VPN 的应用同时运行。若启用 TUN 后整机断网，先关闭 TUN 恢复网络，再检查虚拟接口、路由和其他 VPN 的冲突。不要同时改 TUN、DNS 和规则，否则难以确认是哪项设置起了作用。

7. 汇总结果：何时换节点，何时提交日志

完成上述对照后，结论应能落到具体层级，而不是只剩“FlClash 不能用”。单个节点在不同网络都失败，而其他节点可用，更适合向服务方核对服务器状态和凭据；所有节点仅在同一网络失败，则优先检查本地网络限制。若显式代理可用、系统代理不可用，重点检查系统设置是否被其他程序覆盖。

提交问题前保留这六项信息

• FlClash 版本、系统版本，以及日志中可见的 mihomo 内核版本。
• 失败时间及所在时区，便于对照服务端记录。
• 订阅是否成功更新、当前配置是否加载成功。
• 系统代理与 TUN 的启用状态、实际混合端口、当前出站模式。
• 同一网址在显式代理、规则模式、全局模式下的结果。
• 覆盖一次失败前后的短日志，隐藏订阅令牌、账户凭据和不宜公开的地址。

需要重新核对初始配置时，可先阅读入门指南；需要按故障现象继续定位时，可查看问题诊断。更新客户端前保留当前配置和关键设置，更新后重复同一组测试，才能判断变化是否来自版本或配置。