一、日志里这条报错在说什么
TLS Handshake Timeout 出现在 Clash 作为「中间人」替你的应用去和远端服务器握手时：客户端（你的浏览器或 App）已经把 TCP 连到了 Clash，Clash 再去连真正的网站或上游代理，并在这一阶段完成 TLS 版本协商、证书校验与密钥交换。若在配置的超时时间内没有完成握手，内核或客户端就会打出这类日志。它不等于「一定是你家宽带坏了」，也不等于「一定是节点挂了」——要先看清这一条连接对应的域名、策略组、出站类型与目标地址。
实操上建议先打开详细日志（各 GUI 名称不同，常见为 Debug 或记录「连接 / DNS / 规则」级别），复现一次问题，然后沿时间轴找到同一条五元组或同一域名前后的几行：是否有 [Rule] 命中、是否出现 Sniff 相关字段、DNS 解析结果是真实 IP 还是 fake-ip 段内地址。把这几类信息抄在便签上，再进入下面各步，避免「同时改节点又改规则」导致无法归因。
不同客户端对同一错误的文案可能略有差异，例如 tls: handshake failed、i/o timeout 等与超时混排；不必纠结字面是否完全一致，关键是判断失败发生在「到远端代理之前」还是「代理到目标站之间」。若你使用 链式代理（proxy-groups 嵌套或多跳），日志里通常会分段显示；请分别观察每一跳是否都有握手超时，以判断是入口节点还是出口节点的问题。
二、节点与出口（测速与对照）
先把「节点质量」验证掉，因为这是最容易做 A/B 的变量。使用客户端自带的延迟测试或真连接测速（若支持）观察：若延迟测试长期超时或抖动极大，握手阶段也更容易拖到超时。请对同一策略组内多个节点轮换，看日志中的域名是否始终在同一节点上失败；若换节点后立刻恢复，则问题大概率在该出口 IP 被目标站限制、线路拥塞或节点本身 TLS 出口异常。
与「直连对照」配合
在确认合规前提下，可临时为出问题域名写一条明确的规则指向另一出站或直连，再观察日志：若直连正常、仅代理失败，说明瓶颈在代理链或远端对代理 IP 的策略；若直连与代理都失败，则要回到本地网络、DNS 或目标站本身故障。注意对照时每次只改一个出站，并在日志里核对规则命中名称是否与你预期一致。
若你使用 TUN 模式，还要排除「全局流量被误导入 Clash 后又无法正确回程」的情况；表现上也会是大量 TLS 握手阶段卡住。可结合 《Clash TUN 与 Windows 路由防火墙排查》 中的步骤，先确认没有断网或回环，再回到 TLS 本身。
三、SNI、证书与会话还原
TLS 握手里，SNI（Server Name Indication）告诉对端「你希望访问哪个主机名」，以便同一 IP 上托管的多个站点返回正确证书。若 Clash 向上游发起的连接里 SNI 与证书 CN/SAN 不匹配，或 SNI 被错误还原成内网占位名，握手可能反复失败直至超时。请在日志中查找该连接对应的 host / sni / server name 字段，与浏览器地址栏或应用配置中的域名是否一致。
许多 CDN 与云厂商会在证书链上使用通配符或多 SAN 证书，正常情况下仍能匹配；但若你通过「仅 IP 访问」或本地 hosts 强行绑定到另一台机器，就会出现「TCP 能通、TLS 一直完不成」的现象。此时日志里除握手超时外，有时还会伴随证书校验相关字样（具体取决于内核与出站类型）。把日志中的目标 IP与 dig / nslookup 在「走代理 DNS」与「直连 DNS」下的结果对照，可以快速判断是不是解析结果被污染或劫持导致连到了错误主机。
常见错位场景
- 规则里用了 IP 而嗅探未还原出域名：上游看到的是 IP 的 SNI，与证书域名不一致。
- HTTP/2 或多路复用下的子请求：部分日志只显示连接级信息，需要结合完整会话查看。
- MITM 或自定义证书：若你启用了中间人解密（一般不建议非专业场景使用），证书链错误会直接表现为握手失败或超时。
若怀疑 SNI 与证书问题，可暂时换用另一浏览器或命令行 curl（在已配置代理的环境下）对同一 URL 复现，并对比 Clash 日志中的主机名是否一致。此类问题与「单纯节点慢」不同：往往固定域名必现，换节点有时能好（因为走了不同出口或不同中间盒），但根因仍在会话参数而非物理延迟。
四、嗅探与分流是否误伤
嗅探（sniffer）用于在加密流量中还原域名，让规则模块在看不到明文 Host 时仍能分流。若嗅探范围过大、或与某些 QUIC、ECH、自定义 TLS 行为不兼容，可能出现错误嗅探结果，进而把连接送到错误的策略组或错误的 SNI 路径上，最终在日志里体现为握手超时或证书错误。建议步骤：先在配置中收窄嗅探（限定端口、协议或关闭对特定进程的嗅探），重载后复测；若收窄后问题消失，再逐项恢复以定位触发条件。
嗅探与 fake-ip、TUN 经常叠加使用，三者同时变更时最难排查。若你近期刚开启 fake-ip，且只有部分站点 TLS 异常，建议对照 《fake-ip 与 DNS 逐步排查》 一文，先确认不是解析链路与 fake-ip-filter 漏项，再回到嗅探本身。
五、规则命中、DNS 与 fake-ip
有时握手超时是因为连接从未到达你以为的节点：规则把流量送到了 REJECT、错误的 DIRECT 路径，或 DNS 先把域名解析到了不可达地址。请在日志中确认 [Rule] 命中的规则名与目标出站，再核对 DNS 查询是否经过 Clash、结果是否为 fake-ip 段。若 DNS 在企业网或运营商侧被干扰，表现为间歇性超时，换 DNS 上游或调整 fallback 往往比换节点更有效。
快速对照表
| 日志或现象线索 | 优先检查 |
|---|---|
| 规则显示直连，但目标应在墙外 | 修正 DOMAIN-SUFFIX / GEOSITE 命中顺序；检查 PROCESS-NAME 等更高优先级规则是否抢跑 |
| DNS 日志异常或解析很慢 | nameserver 可达性、DoH 被阻断、fallback-filter 是否过激 |
| 仅 fake-ip 开启后出现问题 | fake-ip-filter 是否漏域名；必要时对照 redir-host 实验（见 fake-ip 专文） |
| Sniff 后规则命中与浏览器域名不一致 | 收窄嗅探或对该域名禁用嗅探；检查是否为 CDN CNAME 链上的子域 |
涉及 Clash TLS handshake timeout 的搜索里，很多人会先换订阅；但若日志显示规则与 DNS 一直稳定，仅握手阶段耗时飙升，更应优先导出同一分钟内的完整日志片段再分析，而不是反复清空配置。
对于移动端 App，部分 SDK 会自建连接池或证书钉扎，系统代理不一定能完整覆盖；若仅在某一 App 内复现，而在同一台设备的浏览器里访问同一域名正常，则要怀疑进程级规则或该 App 是否绕过系统代理。此时可尝试开启 TUN 并核对进程名规则，但仍建议先完成桌面端的日志对照，再迁移结论到移动端，以免变量过多。
六、本机防火墙、时间与其他代理
本机系统时间误差过大会导致 TLS 证书校验失败，部分实现上也会表现为长时间重试后超时。请确认操作系统时间同步开启。Windows 上第三方防火墙、杀软网络层、公司 EDR 也可能拦截本地回环或虚拟网卡上的连接，从而让你在 Clash 日志里看到握手阶段卡住；可对照官方文档做一次最小化启动（临时退出冲突软件）验证。
若机器上同时运行其他 VPN 或「全局加速器」，多个驱动争抢路由时，可能出现「部分进程走错栈」的偶发 TLS 超时。建议保留单一明确出口，或在其他软件中为特定应用设置绕过。需要系统级代理与文档说明时，可参考 本站配置文档 中与 DNS、TUN 相关的章节，避免与本文步骤重复时遗漏关键检查点。
七、小结
当你在日志里看到 TLS Handshake Timeout 时，可以把它理解成「代理在帮应用完成 HTTPS 隧道前的最后一段没有按期完成」。按 节点测速与轮换 → 核对 SNI 与证书 → 收窄嗅探 → 核对规则命中与 DNS、fake-ip → 本机时间与其他代理冲突 的顺序排查，通常能把「换十个节点都没用」的困境拆成几个可验证的小问题。与「TUN 断网」「fake-ip 少数站异常」等主题相比，本文刻意锚定典型报错字符串与日志字段，便于你带着关键词直接对照自己的客户端输出。
相比其他同类工具，Clash 系内核在日志粒度、规则与 DNS 协同方面信息较全；把每一次异常的域名、命中规则与出站记录下来，你的配置会越调越稳，也能明显减少无效换节点的时间成本。