Use this guide when v2rayN, v2rayNG, or v2flyNG logs show TLS, x509, or handshake errors. Start with the original error to distinguish a timeout from a certificate validation failure, then check system time, node address and SNI, the certificate chain, fingerprint, and transport settings. Troubleshoot standard TLS separately from REALITY; skipping certificate verification is not a substitute for fixing the configuration.
1. Start with the logs: a failed handshake doesn't always mean a certificate problem
TLS sits between establishing a connection and communicating over the proxy protocol. A failed DNS lookup, unreachable TCP port, or server closing the connection can all end with a generic “connection failed” message. Prioritize certificate checks only when the logs explicitly mention certificate validity dates, hostnames, or trusted authorities. A lone EOF or context deadline exceeded is not enough to identify the cause.
Reproduce the issue once in the log panel on the v2rayN main screen, note the time, and look above the error for the underlying message from that same connection. On Android, open “Logs” from the menu. The log entry may be in a different place in other versions; look for the core's raw output, not just a “failed” result in the speed test list. Before sharing logs, redact subscription URLs, user identifiers, and authentication details.
Error: x509: certificate has expired or is not yet valid
Cause and fix: Your device's clock is outside the certificate's validity period, or the server certificate has actually expired. Sync the device's date and time, then check the certificate's start and expiration dates.
Error: x509: certificate signed by unknown authority
Cause and fix: The certificate chain does not lead to a trusted root. A missing intermediate certificate, a self-signed certificate, or certificate replacement somewhere on the network could be the cause. Check the complete server certificate chain and the device's trust store instead of disabling verification.
Error: tls: unrecognized name
Cause and fix: The server may have rejected the SNI name sent by the client. Compare the node's server name character by character with the names accepted by the server, and check that you're connecting to the right endpoint.
Error: remote error: tls: handshake failure
Cause and fix: The remote peer terminated the handshake. Possible causes include TLS settings, a client certificate requirement, or server-side endpoint policies. Check the server logs and node settings; this message alone does not prove the certificate has expired.
2. Sync your system clock: date, time zone, and certificate validity
Certificate validation compares the current time with the certificate's notBefore and notAfter values. An incorrect device year or a clock that drifts after waking from sleep can make a valid certificate appear not yet valid or expired. The time zone affects how time is displayed; what matters is whether the system clock itself is accurate. Changing the displayed time zone alone isn't enough.
-
Sync the clock on your computer
In Windows 11, open Settings → Time & language → Date & time, turn on “Set time automatically,” then select “Sync now” under Additional settings. Check the date, year, and selected time zone.
-
Sync the clock on Android
On stock Android, open Settings → System → Date & time and turn on automatic time and time zone. Menu names vary by manufacturer; search Settings for “Date & time” and make sure network-provided time is working.
-
Reconnect and check the logs
Disconnect, reconnect to the node, and check the timestamps in the new logs. If the certificate still appears expired, check its dates on the remote server. The server administrator will need to renew and reload an expired certificate.
If time sync fails, first make sure the device can access the internet; corporate networks may block time-sync traffic. Don't set the system clock back to accommodate an expired certificate. This can break other HTTPS connections and hide a server-side renewal problem.
3. Check SNI: distinguish the server address, certificate name, and Host
The node's address determines which host or IP to connect to; its port specifies the service. SNI is the server name sent during the TLS handshake. In standard TLS configurations, an explicitly set serverName is also typically used to verify the certificate hostname. You can connect to an IP address, but the name used for verification must match a domain on the certificate and meet the server's endpoint requirements.
| Field | What it does | Common mistake |
|---|---|---|
| Address and port | Specify the remote connection endpoint | Assuming every node uses the common HTTPS port 443 |
| SNI / serverName | Select the TLS virtual host and, in standard TLS, verify the server name | Including an https:// prefix, a path, or the wrong subdomain |
| WebSocket Host | Set the host field in the HTTP request after TLS is established | Assuming changing Host will fix a certificate name mismatch |
| WebSocket path | Specify the WebSocket request path | Leaving out the leading slash or using another node's path |
| gRPC serviceName | Specify the gRPC service name | Entering a domain name or a name that doesn't match the server |
In v2rayN, double-click the node in the list to open its settings, then check “Address,” “Port,” and the “SNI” or server name field in the TLS section. In v2rayNG, tap the edit icon beside the node and check its TLS and SNI settings. Field names vary by version; use the node editor rather than looking for SNI in global routing settings.
- SNI is usually a bare domain name, such as
www.example.com, without a protocol, port, or path. This domain is just an example of the format; use the name provided by the server. - A wildcard certificate for
*.example.comtypically matchesa.example.com. Don't assume it also covers the root domain or subdomains several levels deep. - Providers may use “disguise domain” ambiguously. Ask whether they mean TLS SNI, HTTP Host, or the REALITY server name; these settings are not interchangeable.
If the logs say the certificate is valid for one name but not the current one, first check whether you're connecting to the wrong IP or the endpoint is serving a default site's certificate, then correct the SNI. Randomly switching to a well-known website's domain will usually just cause another name mismatch.
4. Check the certificate chain, fingerprint, and REALITY settings
A trusted root certificate doesn't guarantee that the server is sending a complete certificate chain. Standard TLS servers should usually provide the leaf certificate and any required intermediate certificates. Some browsers may fill in missing intermediates from cache, so a site opening in a browser doesn't prove the proxy core can validate the same chain. Also make sure you're testing the same address, port, and SNI—not another endpoint for the same domain.
- Certificate chain error: Ask the server administrator to check the full chain file and confirm the renewed certificate has been loaded. If the device's trust store is outdated, update the system and client, then test again.
- Fingerprint mismatch: A core that supports uTLS can use
fingerprintto select a ClientHello profile. This is not a certificate fingerprint or a certificate trust setting; start with the value required by the node. - REALITY node: The server name, public key, shortId, and other settings must match the server configuration. Field names may differ between versions; use the complete configuration provided by the server administrator.
- Core support: v2rayNG uses Xray, while v2flyNG uses V2Fly. Their supported security and transport options are not identical. A node requiring REALITY won't work just by changing a TLS option in an unsupported core.
v2rayN is a client interface; actual connection behavior also depends on the core used by the node. After upgrading the interface, an outdated core may not support new settings as expected. Check the core name and version in the logs, then update it if required by the node. Don't assume that a certificate issue is solved just because changing the fingerprint occasionally works.
5. Why allowInsecure isn't a long-term fix
With standard TLS, allowInsecure permits insecure certificate verification. Turning it on typically skips normal certificate chain and hostname checks, but it does not downgrade the connection to plaintext: encryption may still be used, but the client can no longer verify the remote server's identity through the usual process. A working connection doesn't mean the configuration is correct.
Symptom: the connection works after skipping certificate verification
Cause and fix: The problem may involve certificate verification, but this doesn't tell you whether the cause is an incorrect clock, a name mismatch, an incomplete chain, or a replaced certificate. Restore verification and use the logs to fix the underlying issue; this does not establish that the remote server is trustworthy.
Symptom: the connection still times out after skipping verification
Cause and fix: The connection may not have reached certificate validation, or there may be a transport or endpoint policy issue. Check the address, port, network reachability, and server logs instead of enabling more unrelated options.
In an authorized, controlled test environment, an administrator may briefly change verification settings to narrow down a problem. Don't use this as a routine way to connect over an untrusted network. This is especially important for account sign-ins, subscription retrieval, and sensitive requests: establish a verifiable connection first. For a private certificate authority, configure trust correctly using the core's supported options instead of permanently skipping verification.
- Save the original node configuration or take a screenshot, and note the original verification setting so you can restore it after testing.
- Reproduce the issue with normal certificate verification enabled and save the full underlying error.
- Change only one setting at a time, based on evidence—for example, sync the clock or correct the SNI—then reconnect.
- After fixing the issue, confirm
allowInsecureis set tofalse, or that “Skip certificate verification” is turned off in the interface.
6. Retest checklist: what if the site still won't open after certificate validation succeeds?
A successful TLS handshake is only one layer. The WebSocket handshake, gRPC service match, proxy protocol authentication, or target domain lookup can still fail afterward. If the new logs no longer show an x509 error but instead show an HTTP status issue or authentication failure, troubleshoot that layer. Don't keep changing an SNI that's already correct.
Why does it still say the certificate is expired after syncing the clock?
Check the latest logs to make sure you're not looking at an old entry, then ask the server administrator to check which certificate the current endpoint is actually serving. The renewed file may not have been reloaded, or one load-balanced endpoint may still be using the old certificate.
It works on my phone but not my computer. Should I change the SNI?
First compare the full node settings, active core, and clock on both devices, then compare their networks. Check whether security software on the computer is replacing certificates or connecting to a different endpoint. A difference between devices alone doesn't prove the SNI is wrong.
Is a WebSocket 400 or 404 response still a TLS problem?
An HTTP response usually means the connection reached the HTTP layer. Check the WebSocket Host, path, and reverse proxy rules. Also confirm the response comes from the expected service; a default site response doesn't mean the node is working.
Why did my changes disappear after updating the subscription?
A subscription update may overwrite node settings. Copy the node for a separate test, record your changes, and ask the provider to fix the subscription source. Don't rely on manually re-entering settings after every update.
What should I include when asking for troubleshooting help?
Include the client and core versions, system time, when the error occurred, redacted raw logs, and whether you're using TLS or REALITY. Say whether switching networks changes the result. Don't share full subscription URLs or credentials publicly.
For the final test, keep certificate verification enabled and use the same node to connect, access the target, and reconnect once after disconnecting. The fix is complete only when the error is gone and the request works as expected. For more on basic settings, see the terminology guide. To distinguish network, proxy connection, and core issues, see the troubleshooting reference.