Clash 节点超时排查

一、先区分测速超时与实际连接失败

Clash 客户端显示“超时”，通常表示一次探测没有在规定时间内完成，并不能单凭这一项断定节点失效。延迟测试一般通过选定节点访问测试 URL；从节点域名解析、连接远端端口，到协议握手、访问测试站点，任何一步失败都可能得到相似结果。先记录报错与影响范围，再修改设置，能够避免把测试地址不可达误当成所有节点故障。

用三项观察确定排查起点

• 只有一个节点失败：保留当前配置，换到同一策略组中的另一个节点访问相同网站。若恢复，优先检查该节点的服务状态和参数。
• 所有节点都失败：先检查本地网络、系统时间、订阅有效期和内核日志，不要立即批量修改节点端口。
• 测速失败但网页能打开：检查测试 URL 是否可达，以及网页连接是否确实命中该节点。浏览器缓存或直连规则也可能制造“可以访问”的假象。

在客户端的“连接”或“日志”页面查看新建请求的目标域名、命中规则和实际出口。示例：若网页请求命中 DIRECT，它只能证明直连正常，不能证明所选代理节点可用。不同客户端的页面名称可能不同，以下操作均以实际界面和当前内核配置为准。

二、关闭代理后确认本地网络与时间

先退出其他代理或 VPN，再暂时关闭当前客户端的系统代理和 TUN。浏览器若单独设置过代理，也需要恢复为使用系统设置。用一个平常可以直接访问的网站确认基础网络可用；连接公共 Wi-Fi 时，先完成网络认证。直连本身失败，应先解决无线连接、路由器或运营商链路问题。

按顺序完成基础检查

1. 在 Windows 11 的「设置」→「网络和 Internet」→「代理」中检查手动代理。客户端已经关闭时，不应留下指向失效本地端口的代理设置。
2. 在「设置」→「时间和语言」→「日期和时间」中启用自动设置时间，并执行“立即同步”。校对实际日期和时间，不仅是时区显示。
3. macOS 可在「系统设置」→「通用」→「日期与时间」中检查自动设置；网络代理位于「网络」→ 当前网络服务 →「详细信息」→「代理」。
4. 基础网络恢复后，仅启动一个代理客户端。先用系统代理测试，确认正常后再恢复 TUN，避免同时引入虚拟网卡和路由变量。

TLS 证书有明确的有效时间范围，系统日期偏差可能导致握手直接失败。另一方面，不是所有协议都使用相同的校时机制，因此“同步时间”是必要的基础检查，而不是所有超时问题的通用修复。

三、确认订阅未过期且当前配置已更新

订阅链接能够下载，不代表账号仍有可用流量，也不代表所有节点处于运行状态。进入订阅服务的账户页面，核对到期时间、剩余配额、维护公告与客户端使用限制。若账户已停用，应先处理账户状态；反复更换 DNS 不会恢复已停用的服务。

1. 在客户端的“订阅”或“配置”页面找到当前使用的条目，执行更新，并查看更新时间和更新结果。
2. 确认更新后的配置仍然被选中，并成功加载到内核。下载成功但解析失败时，运行中的可能仍是旧配置。
3. 检查策略组实际选择的节点。自动选择组和故障转移组的当前出口可能不同于上次手动点击的节点。
4. 如果日志显示未知代理类型、缺少字段或引用了不存在的策略组，先处理配置兼容性，不要把它归类为网络超时。

四、检查节点域名与远端端口

确认订阅正常后，再区分“解析不到地址”和“地址已解析但连不上端口”。查看节点的 server 与 port，不要把本地 HTTP 代理监听端口当成远端节点端口。下列命令中的 example.com 和 443 仅演示命令格式，执行时应改为当前节点的实际服务器域名和端口；示例不代表可用节点。

# Windows PowerShell：先查询域名，再测试 TCP 端口
Resolve-DnsName example.com
Test-NetConnection -ComputerName example.com -Port 443

# macOS：查询域名与测试 TCP 连接
nslookup example.com
nc -vz -G 5 example.com 443

如果域名查询失败，先确认节点域名没有拼写错误或已经失效，再检查当前网络的 DNS 服务。启用 mihomo 内置 DNS 时，还应检查节点服务器域名使用哪条解析路径；配置中的 proxy-server-nameserver 可用于指定代理节点域名的解析服务器，但需要结合实际版本与 DNS 配置判断，不能只复制一个字段就认为解析链路已经正确。

TcpTestSucceeded: True 只说明一次 TCP 连接成功，不证明认证、TLS 或代理协议握手成功。Hysteria2、TUIC 等依赖 UDP 的协议，也不能用 TCP 端口测试代替可用性验证。普通 ping 使用 ICMP，服务器可以不响应 ICMP 却仍正常提供代理服务。

用手机热点做一次对照

保持客户端、订阅和节点不变，只把电脑从当前 Wi-Fi 切换到手机热点，再发起一次新连接。如果热点正常、原网络持续超时，问题更接近原网络路径、UDP 限制、路由策略或出口过滤，但还不能直接认定某个端口被封锁。需要结合相同时间段的日志与服务端状态继续判断。企业或校园网络应遵守其访问规定，不要擅自修改受管理的安全策略。

五、核对内核兼容性与协议参数

Clash 是客户端生态和内核配置中常见的名称，并不意味着所有内核支持完全相同的协议。Clash Meta 后续以 mihomo 名称发展；较旧内核可能无法识别新协议或新字段。先在“关于”、内核信息或启动日志中记录客户端版本及内核版本，再对照订阅服务要求。仅升级界面程序但未切换实际运行内核，兼容性问题可能仍然存在。

这些参数应以服务方提供的当前配置为准，不要凭经验把端口统一改成 443，也不要随意更换传输类型。服务器名称不一定等于节点连接域名，直接把 server 改为 IP 还可能改变解析行为并影响证书验证。出现证书错误时，应修正时间、名称或服务端证书，而不是把跳过证书验证作为默认处理方法。

六、节点能通但应用失败时检查接管链路

如果内置测试通过，浏览器或某个应用仍然超时，排查重点应移到应用是否进入客户端、使用哪条规则，以及是否被送往错误的策略组。系统代理与 TUN 是两种不同的流量接管方式，开启其中之一不代表所有应用都会按预期使用同一出口。

先验证本地监听，再验证规则

假设当前配置明确写着 mixed-port: 7890，可用下面的命令让一次 HTTPS 请求显式经过本地 HTTP 代理。7890 是此处的示例值，不是所有客户端的固定端口；请先在实际设置或配置中确认监听端口。

# Windows PowerShell 使用 curl.exe，避免命令别名差异
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

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

• 连接本地端口被拒绝：检查内核是否运行、监听端口是否一致，以及端口是否被其他程序占用。Windows 可用 netstat -ano | findstr :7890 查看监听记录与 PID。
• 请求进入客户端但远端握手失败：回到节点地址、协议参数和远端网络检查，不必继续调整浏览器代理。
• 请求命中 REJECT：检查规则顺序与来源。规则按顺序匹配，首条匹配会决定处理方式；应修正规则，而不是只更换节点。
• 仅 TUN 开启时失败：检查服务权限、虚拟网卡、DNS 接管及其他 VPN 的路由冲突。先恢复已验证可用的系统代理路径，再逐项启用 TUN 功能。

命令成功返回 HTTP 响应，只证明该次请求完成，仍需在日志中核对实际出口。连接复用也可能保留旧节点连接，因此更换节点后应重新发起请求；必要时只关闭相关旧连接，不必直接清空全部配置。

七、整理最小复现记录再反馈

如果前述检查仍不能定位原因，提供一份可以对照的记录，比只发一张“超时”截图更有帮助。测试时一次只改一个条件，并记录修改前后的结果；不要同时换订阅、DNS、内核和网络，否则无法判断是哪项变化起作用。

1. 记录环境：操作系统、客户端版本、实际内核版本，以及系统代理或 TUN 的启用状态。
2. 记录范围：单节点还是全部节点，只有测速失败还是实际 HTTPS 请求也失败，是否限定某个应用。
3. 记录对照：同一节点在原网络与手机热点的结果、测试时间和失败阶段，不把示例数字当作实测证据。
4. 记录日志：临时提高日志级别，复现一次后截取相关时间段；脱敏后提交，并在完成排查后恢复常用日志级别。