V2Ray TLS Handshake and Certificate Errors: Check System Time and SNI

1. Tell Certificate Errors Apart from Handshake Timeouts

The TLS handshake takes place before the proxy protocol exchanges application data. The client connects to the server, sends handshake parameters, verifies the server’s identity, and negotiates an encrypted connection. A failure at any step may appear in the outer logs simply as “connection failed.” Don’t rely on the final line alone; look earlier for the underlying cause, such as x509, tls, or a specific network error.

In v2rayN, note the time and node name for a failed connection from the log area at the bottom of the main window. In v2rayNG, open “Logs” from the main menu, reconnect, and check the new entries. Menu names may vary by version, but the goal is the same: find the most specific underlying error for that connection, rather than repeatedly checking a summary such as “all retries failed.”

2. System Clock Out of Sync: Correct It, Then Reconnect

Certificates have a start date and an expiry date. If the device date is months behind, the certificate may appear “not yet valid”; if it’s set in the future, the certificate may appear expired. TLS validation checks the actual time. A displayed time zone mismatch doesn’t necessarily mean the system clock is wrong, but manually changing the time after changing the time zone can shift the actual time.

1. Windows 11: Go to Settings → Time & language → Date & time. Turn on “Set time automatically,” confirm the time zone, then select “Sync now.” After syncing, check the year, date, and minutes.
2. Check sync status: Run the query command below in a terminal and check the time source and the most recent successful sync. To force a new sync, run the second command as an administrator.
3. Android: Go to Settings → System → Date & time and turn on automatic time and automatic time zone. On some devices, these options are under “More settings.” Reconnect to the network and confirm the time has updated.
4. Retest: Disconnect and reconnect to the current node, then make a new request. Correcting the clock won’t retry a failed connection; check the new log entries to confirm the result.

w32tm /query /status
w32tm /resync

If Windows says the time service isn’t running, check the status of Windows Time in Services first. On a managed computer, follow the time source configured by your administrator; don’t replace it without approval. If the date resets after every shutdown, check the device’s firmware clock and hardware. If the time is correct but the error still says the certificate has expired, the server operator must renew the certificate and reload the service.

3. SNI and serverName: Match the Domain, Not the Connection IP

SNI is the server name the client sends during the handshake. It helps a service choose the right certificate and site when multiple sites share an address. In a standard configuration, tlsSettings.serverName is generally used both to send SNI and to verify the certificate name. It’s not the same as the node’s connection address or the WebSocket HTTP Host. These values may match, but the server setup may require different values.

In v2rayN, double-click the target server row to open the node editor, then check “SNI” or “Server Name” in the TLS section. In v2rayNG, tap the node’s edit icon and check the corresponding field in the TLS section. Field names vary by version and node type, so use the subscription’s configuration as the source of truth. Don’t blindly set the connection address, camouflage domain, and SNI to the same value.

• Enter a bare domain, such as edge.example.com. Don’t enter https://edge.example.com/ or append :443.
• If the node connects by IP but the certificate is issued to a domain, you’ll usually still need to enter the domain specified by the provider. Don’t replace the SNI with the IP address.
• A wildcard certificate for *.example.com typically covers edge.example.com, but not example.com or a.edge.example.com.
• Subscription updates may overwrite manual changes. Before testing, duplicate the node and label it clearly so your troubleshooting changes aren’t lost on the next update.

The snippet below shows only streamSettings for standard TCP + TLS; it isn’t a complete, standalone configuration. The example domain illustrates the fields—replace it with the value supplied for your node. For WebSocket or another transport, keep the existing transport type and its settings.

{
  "streamSettings": {
    "network": "tcp",
    "security": "tls",
    "tlsSettings": {
      "serverName": "edge.example.com",
      "allowInsecure": false
    }
  }
}

4. allowInsecure and the Certificate Chain: Keep Identity Verification On

allowInsecure is not a “compatibility mode” or a speed boost. In a standard TLS configuration, setting it to true skips critical certificate checks, so expired, mismatched, or untrusted certificates may no longer be blocked as expected. This can hide the problem, but it doesn’t prove you’re connected to the intended server or fix a network timeout.

In the node editor, look for “Skip certificate verification” or “Allow insecure connections.” Keep this off for normal use; the corresponding setting is allowInsecure: false. If an older configuration had this option enabled and certificate errors appear after restoring verification, investigate the error instead of turning the option back on as a permanent workaround.

• Name mismatch: Check the SNI first. If it’s correct, the server may be serving its default site certificate; check the virtual host configuration.
• Unknown issuer: The server should provide the complete intermediate certificate chain. Publicly trusted certificates generally don’t require users to import a private root certificate.
• Only one older device fails: Update the system and use a supported client version, then check the system trust store. Don’t import a root certificate from an unverified source for a single node.
• Certificate changes after switching networks: Check for a public Wi-Fi sign-in page, a corporate proxy, or HTTPS inspection by security software. If needed, ask the network administrator to confirm.

5. ALPN and Timeouts: Match the Server’s Transport Requirements

ALPN negotiates the application-layer protocol during the TLS handshake. Common values include h2 and http/1.1. It’s neither a node protocol name nor a case where more options are always better. gRPC over HTTP/2 requires HTTP/2 support; traditional WebSocket Upgrade commonly uses HTTP/1.1. The right choice depends on the server and reverse-proxy setup.

1. Check the node’s transport type first, then set ALPN according to the provider’s instructions. If no specific value is required, don’t force a single protocol just to experiment.
2. If the log shows tls: no application protocol, check whether the client’s ALPN list has a protocol in common with those allowed by the server.
3. If the only error is a timeout, first confirm the actual server port. For example, if the node is configured to use 8443, a successful test on 443 doesn’t prove the node is reachable.
4. Keep the node settings unchanged and retest on your current network and another available network. If the results differ, investigate the network path and access restrictions first.

On Windows, use the command below to test TCP connectivity to a specific port. The example domain and port only demonstrate the command format; replace them with the node’s actual values. TcpTestSucceeded: True only confirms that a TCP connection can be established—it doesn’t verify the TLS certificate, ALPN, or proxy authentication.

Test-NetConnection -ComputerName edge.example.com -Port 443

6. Common Questions and How to Verify the Fix

After making changes, reconnect to the node and make a real request. Check that the new log no longer contains certificate validation or handshake errors, then verify that app access is restored. If TLS completes but access still fails, check proxy protocol authentication, the transport path, and routing. Don’t keep changing an SNI value you’ve already verified.

• Keep troubleshooting notes: Record the client and core versions, failure time, network environment, and exact error. “It won’t connect” isn’t enough detail.
• Restore secure settings: Confirm that certificate verification is enabled, and remove unsupported settings added during testing.
• Share only what’s needed: Send the operator the certificate error and port status. Before sharing logs publicly, remove subscription URLs, credentials, and personal network addresses.