外观
代理突然全部失效？从系统时间、证书到 TLS 握手的排查指南
很多人遇到过一种很困惑的情况：客户端能正常打开，订阅也能更新，节点列表还在，但一连接就超时、握手失败，甚至所有节点同时不可用。此时反复切换节点、删除订阅再导入，通常只能碰运气，未必能解决根因。
如果多个不同地区、不同协议的节点在同一时间失效，尤其日志中出现 TLS handshake failed、certificate verify failed、x509、expired certificate、not yet valid 或 i/o timeout 等提示，排查重点应当从“节点本身”扩大到设备的系统时间、证书信任链、当前网络和客户端内核。
本文不针对某一个服务商或某一款客户端，而是提供一套适用于 Clash 系客户端、v2rayN、NekoBox、Shadowrocket 等工具的通用排障思路。建议按顺序操作，每完成一步都重新测试，不要一次改动太多设置，否则很难判断到底是哪项修复生效。
先判断：是一个节点坏了，还是设备环境出了问题？
排障前先做一个简单分类，这会直接决定后续方向。
- 只有个别节点不可用：更可能是该节点临时故障、入口拥塞、线路变化或配置过期。可以切换到同一订阅中的其他节点观察。
- 同一订阅全部节点不可用，但其他网络环境可以使用：优先怀疑当前 Wi-Fi、校园网、公司网络、路由器 DNS 或网络认证状态。
- 不同订阅、不同协议的节点都不可用：优先检查设备时间、证书、系统代理、网络限制和客户端版本。
- 手机能用、电脑不能用，或电脑能用、手机不能用：问题通常在不能用的那台设备上，而不是订阅链接。
- 浏览器打不开，但某些应用还能用：可能是系统代理设置、浏览器扩展、QUIC、浏览器安全软件或 DNS 配置不一致。
这里有一个重要原则：不要把“节点延迟显示为超时”直接等同于“节点一定失效”。客户端的延迟测试本身也依赖 DNS、网络连通性和测试地址；它失败只能说明测试请求没有完成，不能单独证明某台服务器已经不可用。
系统时间不准，为什么会让代理连接失败？
现在大量网络服务会使用 TLS 加密。简单理解，客户端连接服务器时，不只是建立一条数据通道，还要校验证书是否可信、证书是否在有效期内，以及双方的加密协商是否正常。
证书通常会包含两个关键时间：生效时间和过期时间。设备本地时间明显错误时，便可能发生两类问题：
- 设备时间落后太多：客户端会认为证书“尚未生效”。
- 设备时间超前太多：客户端会认为证书“已经过期”。
这类问题不只影响代理，也可能导致网页提示证书风险、应用商店无法加载、系统账户登录异常、同步服务失败等。笔记本长时间关机、主板 CMOS 电池老化、手动设过时间、双系统切换，都是常见诱因。
Windows 的检查方法
进入“设置 → 时间和语言 → 日期和时间”，确认以下项目：
- 时区是否正确，国内通常应为 中国标准时间 UTC+08:00；
- “自动设置时间”是否开启；
- “自动设置时区”可按实际情况决定，但跨地区使用时应特别留意；
- 点击“立即同步”。
同步后，完全退出代理客户端，再重新打开并测试节点。注意不是只关闭窗口，而是确认程序已从系统托盘退出；部分客户端的后台内核不会因关闭主界面而重启。
macOS、iPhone 与 Android 的检查方法
在系统的“日期与时间”或“系统日期和时间”中，启用自动获取时间和自动时区。若设备使用了手动时区，或长期处于无法校时的网络环境，也应重新核对日期、年份与时区。
特别要注意：时间只差一两个小时未必一定造成 TLS 失败，但年份、月份错误，或误设为未来日期，往往足以使大量 HTTPS 服务同时异常。
时间正确后仍失败：检查证书与 TLS 相关问题
时间无误但仍出现 x509、certificate、unknown authority、handshake failure 等日志时，再检查证书环境。这里的“证书问题”并不一定意味着服务器证书有问题，也可能是本地系统、网络软件或拦截设备改变了校验过程。
不要为了省事关闭证书验证
部分客户端或配置中存在“跳过证书验证”“允许不安全连接”“skip-cert-verify”一类选项。开启后，确实可能让某些连接暂时恢复，但代价是客户端不再可靠地确认服务器身份，容易削弱对中间人攻击和伪造站点的防护。
除非你明确知道该选项的用途，并且是在受控的临时排查场景中，否则不建议把它当作长期解决方案。更合理的目标是找出为何验证失败：是时间错误、系统根证书过旧、网络拦截，还是配置中的域名与证书不匹配。
系统版本过旧可能缺少可信根证书
长期未更新的系统，可能缺少新的根证书或无法正确处理较新的 TLS 特性。常见表现包括：
- 某些 HTTPS 网站也提示连接不安全；
- 新旧节点表现差异很大，只有少数旧站点可打开；
- 客户端日志反复出现证书链验证失败；
- 同一配置在较新的手机或电脑上正常，在旧设备上失败。
处理方式是优先安装系统安全更新，并更新客户端到其官方发布的稳定版本。不要从不明来源下载所谓“证书修复包”“万能根证书”或来历不明的客户端安装包；这类文件本身可能带来更严重的隐私与安全风险。
安全软件、抓包工具和代理工具可能相互干扰
某些安全软件会启用 HTTPS 扫描、加密流量检查或本地网络过滤；部分抓包工具、广告过滤器、家长控制工具也会通过安装本地根证书的方式检查流量。在配置不兼容或证书异常时，它们可能导致 TLS 校验报错。
排查时可以采取“最小化环境”原则：
- 退出浏览器代理扩展、抓包工具和其他 VPN 类软件；
- 暂停安全软件中的 HTTPS 扫描功能，而不是直接永久关闭全部防护；
- 重启代理客户端及电脑；
- 观察错误日志是否发生变化。
如果暂停某项功能后恢复正常，后续应在该软件中寻找兼容设置，而不是长期同时运行多个抢占系统代理、TUN 网卡或本地端口的网络工具。
从日志读出真正的故障方向
客户端日志是排查的关键。不同软件界面不同，但通常能在“日志”“连接”“运行记录”或“核心日志”中找到。记录错误原文，比只看“连接失败”更有价值。
下面是一些常见关键词及其含义方向：
| 日志关键词 | 常见原因 | 优先动作 |
|---|---|---|
certificate has expired | 系统时间错误，或服务端证书过期 | 先校准时间，再更换节点验证 |
certificate is not yet valid | 本地时间明显落后 | 开启自动校时并重启客户端 |
unknown authority | 根证书、HTTPS 扫描或配置证书链异常 | 更新系统，检查安全软件与本地证书 |
TLS handshake timeout | 网络阻断、链路质量差、服务器无响应 | 换网络、换节点、检查当前网络限制 |
no such host | DNS 无法解析域名 | 检查 DNS、网络认证及域名拼写 |
connection refused | 目标端口没有服务响应或被主动拒绝 | 更换节点，不要反复修改本地端口 |
context deadline exceeded | 请求整体超时 | 对比不同网络与不同节点 |
日志中的单条报错不一定就是最终结论。例如 timeout 可能来自 DNS 解析、TCP 建连或 TLS 握手任一环节。因此要结合“换网络后是否恢复”“其他 HTTPS 服务是否正常”“是否所有节点都受影响”来判断。
用“换网络”快速分离设备问题和网络问题
在不修改客户端配置的前提下，切换一次网络往往非常有效。例如从家庭 Wi-Fi 切换到手机热点，或从一个无线网络换到另一个可信网络。测试时最好使用同一个节点，这样变量更少。
- 换网络立即恢复：当前 Wi-Fi、路由器 DNS、网络认证、网络策略或局部链路更值得怀疑。
- 换网络仍完全失败：继续检查设备时间、客户端、证书环境和配置本身。
- 只有特定网络下偶发失败：可能是网络质量、IPv6 路径或 MTU 等兼容性问题，先保留日志和发生时间，再进行针对性排查。
对于需要网页登录认证的公共 Wi-Fi、校园网或酒店网络，先关闭代理并用浏览器打开任意普通网站，确认认证页面已完成。有些网络在认证前会允许少量页面访问，却会拦截其他连接，容易让人误以为客户端配置出了问题。
DNS 问题与证书问题如何区分？
DNS 的职责是把域名转换为 IP 地址；TLS 证书负责在加密连接时验证身份。两者都可能让连接失败，但表现不同。
如果日志出现 no such host、lookup、DNS、server misbehaving，通常先看 DNS。若日志明确出现 certificate、x509、handshake，则更接近证书或 TLS 协商问题。
不过两者也可能串联：假如域名被解析到了错误地址，客户端随后拿到的证书就可能与目标域名不匹配。因此排障时不要随意填入网络上流传的 DNS 地址，更不要同时在路由器、系统、客户端和浏览器中叠加多层 DNS 设置。建议一次只调整一个层级，并保留原始配置以便回退。
一套可复用的排查顺序
当代理突然大面积无法连接时，可以按下面清单执行：
- 查看系统日期、年份、时区，开启自动校时；
- 彻底退出并重新启动客户端；
- 用同一节点分别测试当前 Wi-Fi 和手机热点；
- 查看日志，记录具体错误关键词；
- 暂停可能进行 HTTPS 扫描的安全软件、抓包工具或重复代理工具；
- 更新系统安全补丁和客户端稳定版本；
- 仅测试性地切换一两个其他节点，不要立即删除原订阅；
- 若仅特定订阅持续异常，再向服务提供方反馈节点名称、时间范围和错误原文。
反馈问题时，最好避免直接发送订阅链接、账号密码、完整配置文件和二维码。订阅链接通常相当于账户凭证，泄露后可能被他人导入使用。截图日志前也应遮盖域名、用户名、UUID、服务器地址及本地公网 IP 等敏感信息。
结语：先修基础环境，再动配置
代理工具依赖操作系统时间、DNS、证书信任、网络接口和本地内核协同工作。节点突然不可用时，订阅并不是唯一变量。尤其是“所有节点同时失败”的情况，先检查系统时间和网络环境，往往比反复导入订阅更有效，也更安全。
建立按层排查的习惯后，很多看似复杂的报错都能被拆解：先确认设备基础状态，再验证网络，再读取日志，最后才考虑配置和节点。这样不仅能更快恢复连接，也能减少因盲目关闭证书校验、安装来路不明修复工具而引入的新风险。