risk/troubleshoot · 集群 A · 连接故障 · 5/6

系统时间不同步为什么会导致代理断连

时间为什么会影响代理连接

时间影响代理连接，是因为连接建立过程中有两类校验依赖本机时间：一是 TLS 证书的有效期校验，二是部分代理协议的时间戳校验。只要本机时间偏离实际时间过多，这两类校验就可能失败，握手因此中断。

  客户端发起连接
        │
  ┌─────┴──────────────────────────────┐
  │ TLS 证书校验                        │
  │  本机时间 < 证书生效时间 → 失败      │
  │  本机时间 > 证书过期时间 → 失败      │
  └─────┬──────────────────────────────┘
        │通过
  ┌─────┴──────────────────────────────┐
  │ 协议认证（部分协议）                │
  │  请求时间戳与服务端时间差过大 → 拒绝 │
  └─────┬──────────────────────────────┘
        │通过
     连接建立

TLS 证书有效期

每张证书都有「生效时间」和「过期时间」。客户端判断证书是否有效时，用的就是本机时间。如果本机时间被调到几年前或几年后，任何正常证书都会被判定为无效。这种情况通常会伴随明确的证书错误提示，参考 代理连接出现证书错误。

协议时间戳校验

部分代理协议会在认证信息中包含时间信息，服务端用它来防止请求被录下后重放。如果客户端时间与服务端时间差得太多，服务端会把请求当成无效请求直接丢弃。社区中常见的说法是某些协议要求偏差在一两分钟以内，但具体容忍范围以协议实现的文档为准。由于服务端往往不会返回明确错误，这种情况下客户端通常只显示超时。协议的差异可以参考 代理协议 专题。

时间问题的典型表现

时间问题有几个比较典型的特征，符合越多，越值得优先检查时间：

最后一条值得说明：在同一台电脑上安装两个操作系统时，它们对硬件时钟是否按本地时间存储的处理方式可能不同，切换系统后时间可能相差若干小时。

各平台检查时间的通用方法

校准时间的原则是：设置正确的时区，然后开启自动对时，而不是手动把时间调到「看起来对」。

不同系统版本的菜单名称可能不同，以设备实际界面为准。设备上的客户端设置可以参考 桌面客户端 和 移动客户端 教程。

路由器场景的特殊情况

路由器上运行代理时，时间问题更容易出现，也更隐蔽。很多家用路由器没有可靠的电池供电时钟，重启后时间可能回到某个默认值。如果代理服务在对时完成前就已经启动并尝试连接，就会因为时间错误而失败；有时即使后来对时完成，代理也需要重启才能恢复。

  路由器重启
      │
  时间回到默认值（例如很早的某个日期）
      │
  代理插件启动 ──▶ TLS / 协议校验失败
      │
  网络对时完成（若对时服务器可达）
      │
  代理是否自动重连？
      ├─ 是 → 恢复
      └─ 否 → 需要手动重启代理服务

如果你使用路由器方案，建议重启后先确认系统时间正确，再检查代理状态。具体配置可以参考 路由器方案 专题。

为什么时间会突然变得不准

很多人会疑惑：时间一直是自动的，怎么会突然不准？实际上，时间出错往往有具体的诱因。

常见诱因包括：主板纽扣电池电量耗尽，断电后硬件时钟被重置；系统的自动对时服务因为网络问题长时间没有成功同步；某些软件或脚本修改了系统时间，例如为了测试试用期的工具；双系统切换导致的时区解释差异；手动修改过时区后没有恢复。手机上则可能是关闭了「自动设置」后忘记打开。

找到诱因后对症处理，才能避免问题反复出现。

时间正常后仍然连不上

如果时间已经确认正确，问题依然存在，就说明时间不是原因，可以继续往下一层排查：检查订阅是否最新、节点是否普遍超时。完整的流程可以参考 节点连接超时的原因分析 和 分层排障法。

时间校准是所有排障步骤中成本最低的一项，建议把它固定为排查的第二步，仅排在确认本地网络之后。如果排查下来发现是服务端问题，需要考虑备用方案，可以到 机场品牌库 了解其他品牌的资料。本站未对任何品牌做过连接实测。