Clash 节点全部显示 timeout：从本机网络到远端服务器的排查顺序

1. 先区分延迟测试失败与实际代理失败

timeout 表示一次操作没有在限定时间内完成。它不是“服务器已停机”的确定结论。客户端延迟测试通常会通过节点访问指定 HTTP 或 HTTPS 地址；解析域名、连接服务器、完成协议握手、访问测试站点，任何一步停住，都可能显示超时。

先固定一个节点、一个测试网址和一个应用。暂时停止批量测速，避免几十条连接同时发起。记录客户端名称、内核名称与版本、当前网络、测试时间，以及日志中的第一条错误。后面每轮只改变一个条件。

2. 本机网络：先排除断网、认证与代理残留

恢复可验证的直连环境

1. 记录原设置。关闭客户端的系统代理和 TUN 模式，再退出其他 VPN、加速器或代理工具。
2. Windows 11 打开「设置」→「网络和 Internet」→「代理」，检查是否残留手动代理或自动配置脚本。受组织管理的设备先联系管理员，不要擅自移除策略。
3. macOS 打开「系统设置」→「网络」→当前网络连接→「详细信息」→「代理」，检查 HTTP、HTTPS 与 SOCKS 代理是否仍指向已退出的本地程序。
4. 连接酒店、校园或公共 Wi-Fi 时，先完成网络认证。浏览器出现登录页时，先处理认证，不要继续修改节点参数。

仅退出客户端不一定会移除系统代理。若系统还指向 127.0.0.1:7890，而该端口已经没有进程监听，浏览器会连接失败。这属于本地入口问题，尚未到达远端节点。

用明确绕过代理的请求测试

Windows PowerShell 使用 curl.exe，避免旧版 PowerShell 中同名命令别名带来的差异。以下请求绕过显式代理，连接超时设为 5 秒，总时限设为 15 秒；这些是排查参数，不是实测结果。

curl.exe --noproxy "*" --connect-timeout 5 --max-time 15 -I https://www.example.com/

macOS 与 Linux 使用相同参数，将命令名改为 curl。示例域名只用于说明请求方法；可替换为当前网络中已知能直连的网站。若 TUN、旁路由或上游透明代理仍在工作，--noproxy 不能绕过这些网络层接管。

直连仍失败时，先检查网卡地址、默认网关与路由器联网状态。再用手机热点复测同一台电脑。热点正常、原网络失败，说明问题更接近原网络的 DNS、路由或访问策略；这仍不能单独证明某个端口被封锁。

3. 系统时间与 DNS：先让域名和证书可用

校准系统时钟

TLS 证书校验依赖当前时间，部分代理认证也有时间要求。Windows 11 打开「设置」→「时间和语言」→「日期和时间」，启用自动设置时间并执行同步。macOS 打开「系统设置」→「通用」→「日期与时间」，检查自动设置日期与时间。

核对日期、年份和实际时刻，而不只是界面显示的时区。日志出现 certificate has expired 或 certificate is not yet valid 时，同时检查本机时钟和远端证书；不要直接开启跳过证书验证。

分开检查节点域名与测速域名

• 节点域名解析失败：内核无法得到服务器地址，代理连接无法开始。
• 测速域名解析失败：服务器可能可连接，但指定测试请求不能完成。
• 内核与系统解析结果不同：系统查询成功，不代表内核配置的 DNS 上游也正常。

先从日志定位失败的具体域名。Windows 可运行 Resolve-DnsName www.example.com，macOS 或 Linux 可运行 nslookup www.example.com，将示例域名换成日志中的目标。系统查询只是一项对照，还要查看内核是否报告 DNS resolve failed、上游连接超时或解析循环。

4. 测速地址：验证请求目标，而不是只看数字

检查客户端当前使用的测试 URL。它可能来自界面设置，也可能来自配置中的 url-test 策略组或 proxy-providers 健康检查。这几处并不一定共用同一个地址，改了界面选项后，后台健康检查仍可能访问旧地址。

选择响应简短、地址稳定且当前线路允许访问的 HTTPS 目标。返回 204 的地址常用于连通性探测，但不要把所有“无法得到 204”的情况都当作节点失效：重定向、认证页、站点限流和客户端对状态码的判断方式都会影响结果。

按同一目标做两组请求

下面通过本地 HTTP 代理端口访问示例网址。7890 仅是示例，必须替换成客户端实际 HTTP 或 mixed 监听端口。先确认当前规则会把这个请求交给待测节点；否则请求成功也可能只是命中了 DIRECT。

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

1. 对同一个目标，分别执行直连请求和代理请求，保存错误文本。
2. 在客户端连接记录中确认目标域名、命中规则和最终出站节点。
3. 若只有测试目标失败，再换一个已知可用的目标，保持节点不变。
4. 若 5 秒测试失败、15 秒请求能完成，记录为慢响应线索，继续检查握手与丢包；不要只把超时值无限调大。

curl -I 使用 HEAD 请求，与部分客户端使用的 GET 探测不同。遇到目标不支持 HEAD，可去掉 -I，改用 -o NUL（Windows）或 -o /dev/null（macOS、Linux）丢弃响应体。对比时应保持请求方法一致。

5. 本地端口、规则与 TUN：确认流量确实走了待测节点

先验证一个显式代理入口

Windows 可用以下命令检查示例端口是否监听。结果为空时，回到客户端检查内核是否启动、配置是否加载成功，以及端口是否被其他程序占用。

Get-NetTCPConnection -State Listen -LocalPort 7890

macOS 可用 lsof -nP -iTCP:7890 -sTCP:LISTEN，Linux 可用 ss -lntp 查看监听。只看到端口存在还不够，需确认所属进程确实是当前客户端内核。不要把 HTTP 代理请求发到控制接口端口；控制接口不是代理流量入口。

用连接记录确认策略

• 规则模式：检查目标命中的规则及策略组，确认最终不是 DIRECT、REJECT 或另一个节点。
• 自动选择组：排查时固定一个具体节点，避免测试过程中自动切换造成结果混杂。
• 链式代理：任意一跳失败都可能让最终请求超时，先简化为单跳连接再比较。

若显式 HTTP 代理正常、开启 TUN 后才失败，重点转向路由、DNS 接管、权限和其他 VPN 冲突。TUN 会改变流量进入内核的方式，不会修复错误密码或远端端口不通。先保存日志与配置副本，再逐项检查，不要同时开启多个接管默认路由的工具。

只有游戏、语音或 QUIC 请求失败时，单独检查 UDP 支持。浏览器经 TCP 访问成功，不能证明节点协议、服务端和本地网络都允许 UDP。临时禁用应用 QUIC 后恢复，仅能作为 UDP 路径异常的线索。

6. 协议参数与远端服务器：从可达性到握手逐层确认

先核对当前内核是否支持节点协议

Clash 配置格式相似，不代表所有内核支持相同协议与字段。使用 mihomo 配置时，应记录实际内核名称和版本，而不是只记录客户端界面版本。日志若出现不支持的代理类型、未知字段或配置解析失败，先处理兼容性问题，再做网络测速。

从可信的原始订阅重新获取配置，并核对账户流量、到期状态与节点列表是否变化。逐项检查 server、port、协议类型和认证字段。使用 TLS 或 WebSocket 时，再核对 servername、路径及 Host；使用 REALITY 时，还要核对公钥、short ID 等服务方给出的参数。

这些参数不能根据域名外观猜测。直接把节点域名改为 IP，可能改变 TLS SNI、证书验证或服务端分流结果；即使 TCP 能连上，也不等于完整协议可以建立。

把端口检测当作局部证据

Windows 可用 Test-NetConnection 检查服务器的 TCP 端口。将下面变量改成配置中实际的服务器地址与端口，再执行检测；示例中的 443 不是所有节点的通用端口。

$server = Read-Host "输入节点 server 地址"
$port = [int](Read-Host "输入节点 port，例如 443")
Test-NetConnection -ComputerName $server -Port $port

• TCP 成功：仅证明 TCP 连接可建立，不证明认证、TLS、WebSocket 或代理转发成功。
• TCP 失败：可能涉及路由、访问策略、服务未监听或地址错误，不能仅凭一次结果确定责任方。
• UDP 协议：Hysteria2、TUIC 等基于 UDP 的连接，不能用 TCP 端口检测结果判定可用性。
• ping 失败：目标可能不响应 ICMP，不能据此认定代理端口不可用。

同一节点在两条独立网络上都失败，且参数与账户状态已确认时，再联系服务方核对监听端口、防火墙、证书与服务器运行情况。若多个节点共用同一个入口域名或中转链路，全部失败仍可能来自这一共同依赖，而不是每台落地服务器同时故障。

7. 用日志收尾：保留第一处失败，不只截全红界面

临时把日志级别提高到 debug，清空旧记录后只复现一次失败。查看请求开始到报错之间的完整上下文：目标域名、选中节点、解析结果和握手阶段。排查结束后恢复原日志级别，避免持续产生大量记录。

一轮排查的完成标准

1. 关闭代理后，已确认本机直连是否正常。
2. 固定一个节点，已分别测试实际访问和延迟探测。
3. 已核对系统时间、节点域名解析和本地监听端口。
4. 已通过连接记录确认规则与最终出站。
5. 已完成另一网络的对照，或记录暂时无法对照的原因。
6. 已定位失败阶段，并整理脱敏日志供进一步核查。

按这个顺序排查，可以把“节点全部 timeout”缩小到本机入口、DNS、测试目标、协议握手或远端链路中的某一层。需要核对配置术语时，查看概念速查；需要继续检查系统代理和规则设置时，查看疑难手册。