This guide covers TLS handshake failures, expired certificates, domain mismatches, and dropped connections in v2rayN, v2rayNG, and v2flyNG. Sync the system clock first, then verify the node address, SNI, and transport settings. Finally, use core logs to determine whether the issue is local configuration, network interception, or a server-side certificate problem.
Use the TLS handshake sequence to locate the failure
TLS sits above the transport connection. The client first resolves the server address and opens a TCP connection, then sends a ClientHello containing the protocol version, cipher suites, and SNI. After the server returns its certificate, the Xray or V2Fly core checks its validity period, signing chain, and domain name. If any check fails, VMess or VLESS authentication has not reached the normal exchange stage, so changing the UUID, alterId, or routing rules usually will not fix a certificate error.
Save a complete core log before troubleshooting; do not rely only on the interface message “Connection failed.” In v2rayN, check recent output in the log area at the bottom of the main window or open “Help” → “View Logs.” In v2rayNG, open “Logs” from the top-left menu to view core errors. Wording may vary slightly between core versions, but keywords such as x509, certificate, handshake, and server name are enough to identify the likely direction.
Error: x509: certificate has expired or is not yet valid
Cause and fix: The device clock is outside the certificate’s validity period, or the server certificate has actually expired. Turn on automatic date, time, and time-zone sync, then reconnect. If several devices show the same error, contact the configuration provider and ask them to renew the certificate.
Error: x509: certificate is valid for another domain, not current domain
Cause and fix: The domain specified by SNI is not listed in the certificate’s Subject Alternative Names. Set TLS serverName to a domain covered by the certificate; do not simply copy the server IP address.
Error: remote error: tls: handshake failure
Cause and fix: The server rejected the handshake. Common causes include mismatched SNI, port, TLS toggle, or transport settings. Compare each item with the server configuration and make sure WS, gRPC, TCP, and other transport parameters have not been mixed up.
Error: tls: failed to verify certificate
Cause and fix: Certificate-chain, domain, or validity checks failed. Fix the clock and SNI first; disabling certificate verification should not be the standard solution.
Sync the system clock, time zone, and network time
Certificates contain explicit not-before and expiration times, and validation uses the device’s current clock. Even a few minutes of clock drift can make a newly issued or renewed certificate appear not yet valid. Clock drift after sleep, inconsistent clock standards in dual-boot systems, suspended virtual machines, and routers blocking time synchronization can all trigger this error.
In Windows, open “Settings” → “Time & language” → “Date & time,” enable automatic time and automatic time zone, then select “Sync now.” On macOS, enable automatic time in “System Settings” → “General” → “Date & Time.” On Android, open “Settings” → “System” → “Date & time” and enable both network-provided time and time zone. On Linux, verify that the system clock, time zone, and time-synchronization service are all operating normally.
-
Record the original error
Disconnect the current connection, clear the displayed logs, and connect again once. Keep the complete error line containing x509, TLS, and the target domain.
-
Check the date and time zone
Check the year, month, day, hour, and time zone. Correcting only the clock while leaving the time zone wrong can cause the offset to return after a restart.
-
Synchronize the clock
Enable automatic system time and trigger one manual synchronization. If synchronization fails, first switch to a connection that can reach a network time service.
-
Restart the client
Fully exit v2rayN, v2rayNG, or v2flyNG, then restart the core to prevent an old connection from reusing its previous handshake state.
-
Cross-check on another device
Test the same configuration on another device with an accurate clock. If only one device fails, continue by checking that device’s time and certificate environment.
Verify the server address, SNI, and certificate domain
The server address sends the connection to the target host, while SNI tells the server which certificate to return during the TLS handshake. They may be the same or different. For example, the server address may be an IP, while SNI must be the domain covered by the certificate. Putting the IP in SNI as well usually causes a domain mismatch because public certificates generally cover domain names, not IP addresses.
When checking certificate domains, distinguish the base domain from subdomains. A certificate covering example.net does not necessarily cover edge.example.net; a wildcard certificate covering one level of subdomain does not automatically cover deeper levels. The node’s host, SNI, serverName, and camouflage domain may serve different purposes, so do not set them all to the same value just because their text looks similar.
| Configuration item | Purpose | Correct entry rule | Common mistake |
|---|---|---|---|
| Address | Used for DNS resolution and establishing the connection | Enter the domain or IP provided by the node | Pasting a protocol prefix, path, or extra spaces |
| Port | Specifies where the remote service listens | Match the server’s actual listening port | Entering the local proxy port 10808 by mistake |
| SNI | Selects the TLS certificate and virtual host | Enter a domain covered by the certificate and required by the server | Entering an IP or unrelated domain |
| Host | Used for HTTP, WS, or other transport-layer requests | Follow the node instructions; do not force it to match SNI | Entering the full URL together with its path |
| Transport security | Determines whether TLS or the corresponding security layer is enabled | Match the server’s deployment exactly | The server has TLS enabled, but the client selects none |
Error: x509: cannot validate certificate for an IP because it does not contain any IP SANs
Cause and fix: The client is validating the certificate against an IP, but the certificate does not include that IP. Keep the IP as the connection address, and enter the certificate’s domain in SNI or serverName.
Error: EOF or connection closed by peer
Cause and fix: The remote side closes the connection during the handshake. Check the port and TLS toggle first, then verify SNI, the transport method, and whether the network is sending the connection to the wrong service.
TLS fields in subscription nodes are usually generated from the subscription content. Manual changes may be overwritten when the subscription is updated. If every node in the same group shows the same error, update the subscription first and verify that its content has been corrected. If only one node fails, that node’s certificate, domain, or server listening configuration is more likely to be at fault.
Understand what allowInsecure is for
allowInsecure controls whether the client skips some certificate checks. For normal connections to public services, leave it disabled so the core continues checking the certificate chain, validity period, and domain. If enabling it restores the connection temporarily, that only indicates a problem in certificate validation; it does not prove that SNI, certificate deployment, or the system clock is correct.
- Everyday use: Keep allowInsecure disabled and fix the certificate, system clock, and SNI.
- Short-term diagnosis: Test it temporarily only when you understand the risks and need to identify the failing layer. Turn it off immediately after testing.
- Self-signed environments: Prefer installing the trusted root certificate correctly on managed devices instead of permanently skipping validation.
- Subscription configurations: Do not enable this option for every node in bulk; it can hide different certificate problems across multiple nodes.
REALITY configurations can also have serverName-related issues, but their security-layer parameters cannot be copied directly from ordinary TLS nodes. VLESS is only a proxy protocol; TLS, XTLS Vision, and REALITY are transport-security settings. First identify which security method the node uses, then check the corresponding fields. Do not mechanically apply ordinary TLS certificate procedures to a different security layer.
Review each setting in v2rayN, v2rayNG, and v2flyNG
Desktop and Android interfaces use different labels, but the fields to verify are the same: address, port, transport protocol, transport security, SNI, Host, path, and core logs. Copy the original configuration as a backup, change one item at a time, and retest so you can identify which field caused the change.
-
Check the core settings
In v2rayN, open “Settings” → “Parameters” → “Core type” and confirm that the node is handled by the intended core. Do not accidentally switch a standard Xray configuration to an incompatible core.
-
Edit the node fields
Double-click the v2rayN node to open the editor, then check the address, port, transport protocol, TLS, security type, and SNI in order. Do not add the https:// prefix to the address field.
-
Check the Android configuration
In the v2rayNG or v2flyNG configuration list, select the target configuration and open its editor. Check “Camouflage domain,” “SNI,” or equivalent fields, save, and restart the connection.
-
Update the subscription
Open the subscription group and run an update, then compare the failed node’s fields to see whether they changed. A subscription update failure and a node TLS failure are separate connection processes, so check their logs independently.
-
Close old connections
Stop the client proxy, wait for old connections to close, and start it again. On desktop, also confirm that the system proxy points to the current local listening port rather than an exited old instance.
-
Compare another node
Test another node in the same subscription. If every node fails, check the local environment; if only one fails, focus on that node’s certificate and server configuration.
Routing rules generally do not change the remote certificate, but they can determine which outbound connection is used. If a rule sends the node domain through an unavailable proxy outbound, the result may look like a timeout or dropped connection. To rule out routing, temporarily switch to a direct, explicit test rule. Once TLS works again, restore the original routing configuration and inspect match logs one by one.
Common questions and the final troubleshooting checklist
If the connection still fails after checking the clock, SNI, and certificate validation, continue at the network and server layers. DNS tampering may resolve the domain to the wrong address, a transparent proxy may alter the connection path, or a reverse proxy may not have loaded the renewed certificate. Use resolution results, the connection port, and server logs together instead of repeatedly changing the UUID.
Your phone connects, but your computer keeps reporting a certificate time error?
Check the computer’s year, time zone, and automatic time synchronization first. After syncing, fully exit v2rayN, restart the core, and test again; do not simply disconnect the node and reconnect immediately.
Can leaving SNI blank make the client detect it automatically?
When the connection address is the certificate domain, some configurations can use that address as the default serverName. If the address is an IP, a fronting domain, or a special deployment entry point, enter SNI explicitly according to the node instructions.
What if every node fails the handshake after a subscription update?
Check the system clock first, then see whether the subscription changed the transport security, SNI, or port. If several devices show the same error at the same time, the configuration provider usually needs to inspect the certificate and server deployment.
It works after enabling allowInsecure. Can I leave it enabled?
Not recommended. It is suitable only for short-term diagnosis. Restore strict validation and fix the domain match, certificate chain, or clock problem.
Are TLS errors related to VMess or VLESS keys?
Certificate validation happens before proxy-protocol authentication. When logs clearly point to x509, certificate, or server name, fix TLS first. After the handshake succeeds, check the UUID, encryption method, and flow-control parameters.
- Confirm that the device date, time, and time zone are accurate, and that automatic synchronization completed successfully.
- Confirm that the node address contains no protocol prefix, path, spaces, or copy-and-paste errors.
- Confirm that the remote port matches the server’s listening port and that no local port such as 10808 was entered by mistake.
- Confirm that SNI matches a domain covered by the certificate rather than an IP that the certificate does not cover.
- Confirm that TLS, WS, TCP, gRPC, and other transport parameters match the server.
- Keep allowInsecure disabled and use the logs to identify the actual certificate error.
- Confirm that a subscription update has not overwritten your manual fix; if necessary, copy the configuration and test it separately.
- Compare another device and another node to distinguish a local problem from a server-side problem.
Keep the troubleshooting order consistent: read the logs first, sync the clock, verify the address, port, SNI, and transport security, then check the certificate chain and server status. This order helps prevent certificate issues from being mistaken for node authentication, system proxy, or routing problems, and reduces unnecessary bulk changes.