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

Start with the logs: Find the TLS handshake failure

Connection stages: A node showing a timeout does not necessarily indicate a certificate problem. A typical TCP + TLS proxy connection first resolves the server address, establishes a TCP connection, negotiates TLS, then performs proxy authentication and transfers data. A failure at any earlier stage can make the connection appear unavailable in the client.

Check the logs: Find the error from your most recent connection attempt in the client log, and note the timestamp, exact error, and core name. Look for the underlying cause, not just the generic failed to process outbound traffic message. That wrapper alone usually cannot tell you whether the issue is with the certificate, network, or protocol settings.

Timeouts: If the log only shows dial tcp, i/o timeout, or a connection refusal—with no certificate error—check the address, port, and server listener first. If the server has not sent a certificate, changing certificate verification settings will not fix the connection.

System clock out of sync: Check the date, then sync status

How validity is checked: A certificate has a start date and an expiration date, and the client uses its system clock to determine whether it is valid. A computer left off for a long time, a virtual machine restored from a snapshot, or a device whose clock reset after losing power can make a valid certificate appear not yet valid or expired. Check the year and date, not just the time in your taskbar.

1. Set the time in Windows: Go to Settings → Time & language → Date & time, turn on Set time automatically, check your time zone, then select Sync now. The exact button locations may vary between Windows versions.
2. Check sync status: Look at the time of the last successful sync. To investigate further, run the read-only command below in Command Prompt to check the time source and sync status.
3. Set the time on Android: Search Settings for “Date & time,” then turn on automatic date and time and automatic time zone. The exact steps vary by device. Try connecting again afterward.
4. Retest: After syncing the clock, reconnect and compare the new log for the same node. If the certificate still appears expired, ask the server administrator to check it instead of continuing to change your device's date.

w32tm /query /status
w32tm /query /source

Time zones: A time zone mainly changes how local time is displayed; TLS verification compares absolute time. Changing your time zone to another region will not fix a certificate. The goal is an accurate system clock, not a display that happens to match another device.

Incorrect SNI: Check the server address, certificate hostname, and Host separately

What SNI does: SNI is the server name a client sends during the TLS handshake. It is often used to select the right certificate and site when multiple services share an address. Common TLS configurations in Xray and V2Ray use serverName for this setting; the client may label it SNI or Server name. You can connect to an IP address, but the certificate identity usually still needs to be verified against the hostname specified by the server.

Check the client settings: In v2rayN, edit the current node and check its address, port, transport, and TLS settings. In v2rayNG or v2flyNG, open the node editor and check the fields related to the server name. Layouts vary by version, so go by what each field means and the core configuration it generates—not just where an input appears.

• Hostname format: SNI is usually a hostname only—no https://, port, path, or trailing spaces.
• Certificate match: Check the certificate's Subject Alternative Name (SAN), not just the abbreviated name shown in a certificate list. A wildcard usually matches only one subdomain level and does not automatically cover the root domain.
• When the field is blank: Some configurations infer the name from the server address. Don't rely on guesswork, especially when connecting by IP; check the value specified by the server.
• Subscription updates: A manual fix may be overwritten the next time the subscription updates. If imported settings keep coming in wrong, report the subscription configuration source instead of repeatedly editing the same node.

Certificate chain and server: A working browser connection doesn't guarantee the core will accept it

Check the trust chain: The server usually needs to send the site certificate and any required intermediate certificates, which the client then chains to a trusted root. A browser may cache intermediates or use a different trust mechanism, so being able to open the site in a browser is a useful clue—not a substitute for the proxy core's verification result.

1. Check where TLS terminates: Confirm whether TLS is handled by a reverse proxy, load balancer, or the proxy core itself. Update the certificate at the layer that actually handles the handshake.
2. Check the full chain: Make sure the server loads the complete certificate chain and that the certificate matches its private key. After updating the certificate, confirm the configuration was reloaded; replacing the file on disk alone is not enough.
3. Check every endpoint: If the domain resolves to multiple addresses or has multiple entry points, check the certificate served by each one. An endpoint still using an old certificate can cause intermittent failures.
4. Check local trust: Update your operating system and client to supported releases, and check for TLS inspection on corporate networks. Do not install root certificates from untrusted sources just to troubleshoot.

Misusing allowInsecure: Skipping verification doesn't fix a certificate

What the setting does: In common TLS configurations, allowInsecure: true skips the usual certificate chain and hostname checks, removing the connection's usual guarantee of server identity. It cannot fix a failed TCP connection, wrong port, server-rejected handshake, or proxy authentication error, and should not be used as a permanent setting.

{
  "security": "tls",
  "tlsSettings": {
    "allowInsecure": false
  }
}

Snippet limitations: This shows only the common TLS verification setting within streamSettings. It is not a complete node configuration and does not include the actual serverName, transport, or authentication parameters. Do not replace your existing configuration with this snippet. In the current node's TLS settings, check that “Allow insecure connections” or “Skip certificate verification” is disabled.

• What it means when the error disappears: If skipping verification makes the error go away, that only suggests certificate verification may be involved. It does not prove you connected to the correct server.
• Recommended fix: Keep verification enabled. Correct the system time, SNI, certificate chain, or server certificate, then test again.
• For self-signed certificates: Choose an explicit trust model and check the certificate trust settings supported by your current core. Turning off verification is not a general-purpose workaround.

Core and protocol differences: Don't apply regular TLS settings to REALITY

Know the difference: VMess and VLESS are proxy protocols; whether they use TLS depends on the transport and security-layer settings. Don't assume every VLESS connection uses standard TLS, or treat every server name field in the client as a certificate expiration issue.

REALITY is different: REALITY uses a verification mechanism distinct from standard TLS certificate deployment, and its settings must match the server as a set. Checking the system clock is still worthwhile, but first identify the security layer and verify its parameters against the requirements of the relevant core. Don't expect the server administrator to fix every issue simply by replacing a standard website certificate.

Final retest: Change one thing at a time and record the original error, the change, and the new log. Narrow down the cause in this order: system time, SNI, certificate chain, server, and security-layer compatibility. If TLS succeeds but the service is still unreachable, check proxy authentication, routing rules, and DNS instead of continuing to disable security settings.

1. Keep a baseline: Record the current fields and original error; keep subscription details in a trusted location.
2. Test one change at a time: After fixing one setting, reconnect and confirm the log is from this test.
3. Restore settings: Revert temporary troubleshooting changes and keep certificate verification enabled.
4. Check that the fix sticks: Restart the client. If you use a subscription, check whether the next update overwrites the fix.