Connection to S3 Storage Vault fails: TLS handshake timeout

Kuzma Ivanov

Updated September 22, 2026 05:13

Symptoms

When running a backup job, the backup fails consistently with the error message:

CONFIG_TEXT: Can't access Storage Vault: BucketExists: Get "https://************/************/?location=": net/http: TLS handshake timeout

Cause

A TLS handshake timeout indicates that the Comet Backup client and the target S3 storage provider cannot establish an encrypted communication channel within the allowed timeframe.

Because the issue persists across different client versions and entirely new storage buckets, it is almost always caused by local network infrastructure or environment issues rather than a software defect in Comet Backup. Common triggers include:

High latency, packet loss, or an overloaded local internet connection at the time of the backup.
Misconfigured deep packet inspection (DPI), aggressive firewall rules, or faulty NAT/routing policies blocking or delaying the SSL/TLS handshake packets to the S3 endpoint.
If the client machine's local system clock drifts significantly from real-world time, the TLS handshake will fail or time out due to security certificate validation rules.

Resolution

To isolate and resolve this network-level timeout, perform the following troubleshooting steps in sequence:

Ensure that the affected machine's system date, time, and time zone are accurately synchronised with an internet time server (NTP). Even a few minutes of drift can disrupt the cryptographic handshakes required for TLS connections.
Test whether the storage provider is accessible outside of Comet Backup from the same machine.

Download an independent S3 client (such as Cyberduck). Input the same S3 credentials and endpoint URL used in the Comet Storage Vault settings.
Determine if local routing or firewalls are throttling the connection.
Check if the failure corresponds with periods of high network saturation (e.g., other large data transfers occurring simultaneously).

Run a persistent ping or pathping to the S3 endpoint URL during the backup window to check for latent spikes or intermittent packet loss.