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

Read the Full Error First: Certificate Errors Aren’t Connection Timeouts

The TLS handshake happens before proxy protocol authentication. The client typically connects to the server, negotiates encryption settings, receives and verifies the certificate, and only then starts higher-level communication. If you see a clear x509 certificate error, check the system clock, names, and chain of trust first—not the VMess or VLESS user ID. A log that says only handshake failed isn’t enough to identify the cause; expand the error details.

Check the log area in the v2rayN main window; some versions label it “Information.” Select a node to test, clear the old logs, then make a real web request and record the full error sequence around that time. Menu names can vary between desktop versions. If the log only says the connection failed, look under “Settings” → “Parameter Settings” for a log-level option, temporarily set it to info, and try again. Restore the previous level when done. Before sharing logs, remove subscription URLs, user IDs, and destination addresses.

Sync Your System Clock: Correct the Date, Then Retest the Same Node

Certificates have a start date and an expiry date. The client uses your device’s current time to determine whether a certificate is valid. A clock months behind can make a certificate appear not yet valid; one set in the future can make a valid certificate appear expired. A wrong-looking time zone doesn’t necessarily mean the clock itself is wrong, so check the date, time, and time zone—not just the hour shown in the taskbar.

1. Open Date and Time Settings

   In Windows 11, go to “Settings” → “Time & language” → “Date & time.” The path is the same in Windows 10. First, check that the year, month, and day are correct.

2. Sync the Clock Now

   Turn on “Set time automatically,” make sure the time zone matches your location, then select “Sync now” under “Additional settings” or the clock sync section. If syncing fails, check that your internet connection works. On a managed device, use the time source specified by your administrator.

3. Verify the Sync

   Check that the last successful sync time has updated. In Command Prompt, run w32tm /query /status to view the time source and last successful sync time. If the command fails, check the Windows Time service and your organization’s policies.

4. Retest the Original Node

   Keep the server address, port, and SNI unchanged. Reconnect to the same node and load a web page. If the error still mentions the certificate’s validity period, give the operator the log’s current time and the certificate’s validity dates to compare.

On Android, search Settings for “Date and time,” turn on automatic time and time zone, then reconnect. The settings path varies by manufacturer; you don’t need to change proxy app settings to fix the system clock. If your PC’s date resets after every shutdown, check the firmware clock and motherboard battery. Repeatedly switching nodes only hides the underlying cause.

w32tm /query /status
w32tm /query /source

The two commands above only read status; they don’t change node settings. If they show a local clock source or failed sync, investigate the time service instead of turning off certificate verification. Don’t roll your system clock back to a date when an old certificate was still valid; doing so can affect other secure connections.

How to Set SNI: Server Address, Certificate Name, and Host

SNI is the name sent to the server during the TLS handshake to help it select the right site and certificate for a shared entry point. Clients often also use the configured server name to verify the certificate, but fallback behavior depends on the core and client. Don’t assume leaving SNI blank will work. Use the TLS settings provided by your node operator, and enter a bare domain name—no https://, path, or port.

In the v2rayN main list, double-click the node you want to test to open its edit window. Check that “Transport Layer Security” has TLS enabled as required, then look for “Server Name” or the SNI field. The editor varies slightly by protocol. If you can’t find the field, confirm that you’re editing the right protocol and transport security type. For a subscription node, make a copy for testing so a later subscription update won’t overwrite your changes.

Check the certificate’s SAN (Subject Alternative Name). For example, a certificate for example.com doesn’t automatically cover www.example.com. A wildcard such as *.example.com usually matches a.example.com, but not the root domain example.com or a deeper name like a.b.example.com. If you connect to an IP address but need a domain certificate, enter the required name explicitly as specified by the node operator; don’t let the client treat the IP as the certificate’s domain name.

• Don’t enter a random working website’s domain as SNI. The remote entry point must be configured to serve a matching site for that name.
• Changing only the Host header won’t fix a certificate name mismatch; HTTP requests are usually sent after TLS verification succeeds.
• “Fake domain” isn’t a standard protocol field. It may mean Host or SNI. Confirm which one the provider means before changing anything.
• For REALITY nodes, check dedicated parameters such as serverName and the public key. Don’t apply ordinary TLS certificate replacement steps.

Certificate Chains and TLS Versions: Make Sure the Server Sends the Right Certificate

Once your system clock and SNI are correct, check the server certificate. A common issue is that a certificate was renewed but the reverse proxy wasn’t reloaded. Another is that the server sends only the site certificate and omits a required intermediate certificate. A browser’s ability to fill in a missing chain doesn’t mean every client core can verify it. The server should provide the complete certificate chain.

If you have command-line access, use OpenSSL to inspect the TLS entry point directly. The example below shows the command format only; example.com is a documentation example, not a node server. For a real diagnosis, use your own connection target, port, and SNI. The command connects directly to the target; it won’t automatically use the v2rayN system proxy. If the connection address and SNI differ, set them separately with -connect and -servername—don’t force them to match.

openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_hostname example.com -verify_return_error

Check the returned certificate’s names and validity dates, the certificate chain, and the verification result. The -servername option sends SNI; -verify_hostname explicitly checks the name. They do different things. If your OpenSSL build doesn’t support these options, check its version documentation. Press Ctrl+C to exit after the handshake completes. This test checks TLS only; it doesn’t verify the WebSocket path, proxy protocol authentication, or traffic forwarding.

• “Unknown authority” error: Check the complete chain, update your local root certificates, and find out whether a managed network is inspecting TLS.
• Fails on only one network: Compare the certificate issuer on your usual network and a mobile hotspot.
• Protocol version or cipher suite mismatch: Compare both sides’ settings and restore the node’s recommended negotiation defaults; don’t lock the version blindly.
• Wrong service on a standard TLS port: Check whether the entry point is actually serving plain HTTP, another protocol, or forwarding to the wrong target.

How to Set allowInsecure: Keep Verification On and Fix the Certificate

In common TLS configurations, allowInsecure allows the client to skip server certificate verification. Enabling it may stop name or trust-chain errors, but it doesn’t fix the certificate or ensure you’ve connected to the intended server. It can’t fix an unreachable port, the wrong protocol, or a server rejecting the handshake, and it’s no substitute for the right SNI.

In the v2rayN node editor, look for “Allow insecure”; some versions show allowInsecure. If the client has a global default, check whether it affects newly imported nodes. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core; their editing screens and supported fields may differ. Follow the actual interface for each client, and don’t copy every option exported by one client into another.

1. Note the node’s server address, port, SNI, and verification setting. Keep a copy of the original configuration so you can restore it.
2. Turn certificate verification back on, reconnect, and check whether the error still points to a name mismatch, validity period, or trust-chain issue.
3. Fix the issue based on its category. For private certificates, get trusted materials from your administrator; never install a root certificate from a chat screenshot or an unknown attachment.
4. When you’re done, check the setting again so test changes don’t remain in a subscription copy or on another device.

Retest and FAQs: Change One Variable at a Time

After applying a fix, retest with the same node, destination page, and proxy mode. First confirm that the log no longer shows a certificate error, then check that the page loads. If TLS succeeds but access still fails, investigate the transport path, proxy protocol authentication, DNS, and routing rules. A node’s latency value reflects only its particular test method; it can’t replace a real request.

• Time: Confirm the system clock sync succeeded and the date stays correct after a restart.
• Name: SNI contains no scheme or path and matches the server certificate’s SAN.
• Trust: Keep certificate verification enabled and make sure the server sends the complete certificate chain.
• Result: Note the time of a successful request. When reporting an issue, include only the relevant redacted error—not the full subscription.