A wrong system clock breaks connections: diagnosing TLS handshake failures

Latency tests return numbers, the log keeps showing handshake errors, and every node behaves identically — glance at the clock in the corner first. TLS certificates carry a not-before and not-after time, and a local clock off by more than a few minutes makes the handshake treat them as invalid.

Telltale symptoms

• Every Trojan, VMess-over-TLS and Hysteria node fails while plain Shadowsocks nodes still work;
• Turning the proxy off and visiting a site directly also produces a certificate warning;
• It shows up most often right after a reinstall, after replacing the motherboard battery, or on dual-boot machines.

Fixing it

1. Settings → Time & language → Date & time: enable "Set time automatically", then press "Sync now";
2. If the sync button does nothing, change the server: Control Panel → Date and Time → Internet Time → Change settings, and use something other than the default time.windows.com;
3. Check the time zone while you are there — a wrong zone puts you out by whole hours, which is far worse than a few minutes of drift;
4. Dual-boot users: Windows assumes the hardware clock holds local time, Linux assumes UTC. Whichever side you change, make both agree, or the clock shifts every time you switch systems.

A corrected clock takes effect immediately with no client restart, but existing connections have to be re-established — close them all on the Connections page and run the latency test again.