This guide covers TLS handshake and certificate verification issues when connecting to nodes with v2rayN, v2rayNG, and v2flyNG. Use core logs to distinguish timeouts, certificate date errors, and hostname mismatches, then check the system clock, node address, SNI, transport settings, and server certificate chain. Change one setting at a time, keep certificate verification enabled, and don’t treat TUN mode as a general fix for handshake failures.
1. Identify where the connection fails
A TLS handshake takes place while a secure connection is being established, usually before application data is sent. A latency test in the node list does not mean TLS succeeded: a TCP check may only confirm that the port is reachable, not that the certificate, authentication, and proxy forwarding are working. VMess and VLESS are proxy protocols; TLS is a security layer. They are separate settings.
Check the log area at the bottom of the v2rayN main window for entries just before and after the failure. On Android, open “Logs” from the side menu. Menu locations may vary by version, so follow the current interface. Clear or note the old logs, then try connecting once to avoid confusing a subscription download error, a node connection error, and a destination website error.
Error: x509: certificate has expired or is not yet valid
Cause: The device clock is outside the certificate’s validity period, or the server certificate has actually expired. Fix: Sync the system clock, then compare the current time in the logs with the certificate’s validity dates. If the time is correct and the error persists, ask the node operator to check the certificate.
Error: x509: certificate signed by unknown authority
Cause: The certificate chain does not lead to a trusted root certificate. A missing intermediate certificate, a self-signed certificate, or local HTTPS inspection may be involved. Fix: Check for system updates, review the network environment, and make sure the server provides the complete certificate chain. Don’t simply disable verification.
Error: remote error: tls: handshake failure
Cause: The remote server rejected the handshake, possibly because the SNI, TLS settings, or server entry point don’t match. Fix: Compare the security and transport settings with the original node configuration, and ask the operator to check the server logs for the same time.
If the logs show only i/o timeout, connection refused, or EOF, that isn’t enough to conclude there’s a certificate problem. First check that the node address resolves, the remote port is reachable, and the service on that port actually speaks TLS. The full error chain is more useful than just the final word.
2. Sync the system clock, then reconnect
Certificates have defined start and expiration dates. A device set to the wrong year, or a virtual machine restored from an old snapshot with a clock offset, can make a valid certificate appear “not yet valid” or “expired.” Correct the clock before changing node settings to avoid altering configurations that are already right.
-
Check the date
In Windows 11, open Settings → Time & language → Date & time and check the full date and current time. Don’t check only the hours and minutes on the taskbar.
-
Sync the clock
Turn on “Set time automatically,” then select “Sync now” under “Additional settings.” If syncing fails, make sure the current network can reach a time service. On organization-managed devices, follow your administrator’s settings.
-
Check the Android clock
On Android, go to Settings → System → Date & time and turn on “Set time automatically” and “Set time zone automatically.” Some devices put these options under “Additional settings”; search Settings for “Date & time” to find them.
-
Check a fresh log
After correcting the clock, stop and restart the client connection, then try again. If the date error persists, compare the certificate’s validity dates in the logs instead of repeatedly changing node transport settings.
On macOS, check automatic time under System Settings → General → Date & Time. On Linux, use the command below to check the clock and sync status. The time zone mainly affects how time is displayed; certificate checks use absolute time. Changing the displayed time zone alone won’t correct an inaccurate system clock.
timedatectl statusRule of thumb: check the clock before changing node settings
If multiple TLS nodes from different sources report certificate date errors at the same time, check the device clock first. If the time is accurate and only one node reports an expired certificate, send the error time and node details to the operator.
3. Distinguish the server address, SNI, and Host
In the v2rayN node list, double-click the node to open its settings and find “Address,” “Port,” and the “SNI” or “Server Name” field in the TLS section. In v2rayNG and v2flyNG, use the edit option beside the node to check the corresponding settings. Field names vary by version and protocol; don’t switch protocols just to match a screenshot.
| Field | What it does | What to check |
|---|---|---|
| Server address | Specifies the IP address or hostname the client connects to | Compare it with the original subscription value and DNS results; don’t add a webpage path |
| Remote port | Specifies the port the service listens on | Use the port in the server configuration; TLS does not mean you should always switch to 443 |
| SNI / serverName | Usually provides the hostname during the handshake and is used to verify the certificate name | Use the hostname provided by the operator and confirm the certificate covers it |
| WebSocket Host | Matches the virtual host for HTTP requests | Match the reverse proxy or CDN configuration; Host is not a substitute for SNI |
| WebSocket Path | Determines which path the request is routed to | Check capitalization and the leading slash; don’t enter this in SNI |
For example, if a certificate covers edge.example.net but SNI is set to other.example.net, the names may not match. Enter only a hostname in SNI—no https://, port, or /ws. These hostnames illustrate the field format; they are not working nodes and cannot be used to connect.
Using an IP address for the server and a hostname for SNI can work, provided the server configuration and certificate match. If you connect by IP without setting the correct verification name, the client may check the certificate against the IP address, which most standard domain certificates don’t cover. A “fake domain” field in the interface isn’t an arbitrary hostname: first determine whether it maps to the HTTP Host or the TLS server name.
4. Check the certificate chain and transport security settings
Once the system clock and SNI are correct, check system trust and the server’s certificate chain. An older system may be missing root certificate updates, or the server may send only the site certificate and omit an intermediate certificate. Either can cause verification to fail. A browser loading a page on the same domain doesn’t rule this out: browsers and proxy cores may use different trust stores or certificate-chain completion methods.
- Only one device fails: Check the system date, system updates, and managed root certificate policies. If permitted, try another network to see whether HTTPS inspection is involved.
- The same node fails on every device: Ask the operator to check the certificate’s expiration date, the complete certificate chain, hostname coverage, and whether services were reloaded after the certificate was updated.
- Transport settings were recently changed: Check the TCP, WebSocket, gRPC, and TLS settings again. Sending a TLS handshake to a plain HTTP port won’t be fixed by changing SNI.
- The error returned after a subscription update: Check whether you edited the node manually. Subscription updates can overwrite local changes. Fix the subscription source instead of reapplying settings after every update.
If the logs point to REALITY authentication failure, re-import the complete configuration from a trusted source, then check that the client and core support it. Don’t switch the security type from REALITY to TLS just to see if it works, and don’t enter the public key as a certificate hostname.
5. Why you shouldn’t skip certificate verification
Options such as “Allow insecure,” “Skip certificate verification,” or the allowInsecure setting change how the server’s identity is checked. Even if data is still encrypted, that doesn’t mean the remote server is trusted. An invalid certificate, the wrong server endpoint, or an intercepted connection may no longer trigger the certificate warning you would otherwise see.
- For a date error, correct the system clock. If the server certificate has expired, renew it instead of telling the client to ignore the expiration.
- For a hostname mismatch, check SNI and the certificate’s hostname coverage. Don’t leave verification disabled as a permanent setting.
- If a self-hosted service requires a private trust setup, configure it only after understanding how certificates are distributed and what they’re trusted for. Don’t install root certificates from unknown sources.
- If you temporarily changed this setting while troubleshooting, turn verification back on and test again to confirm the final configuration still connects.
Enabling the system proxy or TUN mode changes how traffic enters the proxy; it usually won’t fix a certificate error on the node itself. If the error comes from the HTTPS request to the subscription URL, check the subscription hostname and the network used for the update. That request and the node’s TLS handshake are separate connections, so changing the node’s SNI won’t fix the subscription site’s certificate.
6. Common questions and troubleshooting notes
The clock is synced, but the certificate still shows as expired. Why?
Reconnect and check the new log to make sure you’re not looking at an old entry. If the system date is correct and the reported expiration date has passed, ask the node operator to renew the certificate and reload the relevant services. Don’t keep changing the device’s time zone.
The SNI field in my subscription is blank. Should I fill it in?
First check whether the server address is a hostname and whether the current core derives the server name from it. A blank field isn’t necessarily an error. If the logs explicitly report a hostname verification failure, ask the operator which SNI to use; don’t copy a hostname from another node.
My phone connects, but my computer doesn’t. What should I check first?
Compare the node address, port, SNI, security type, and transport settings on both devices, then check the computer’s clock and system trust. Keep a copy of the original settings and change one thing at a time. A working Android connection doesn’t rule out desktop core or configuration compatibility issues.
What should I send the operator to help diagnose the problem?
Include the client and core versions, when the error occurred, the full error text with surrounding context, whether the clock has been synced, and whether all nodes fail. Redact subscription URLs, UUIDs, passwords, and authentication details. Don’t send the entire configuration.
To wrap up, test again with the same node and destination. Confirm the new logs no longer show the same error, then restore your usual routing rules. If the problem persists, briefly note what you changed and whether the error changed. A certificate date error turning into a connection timeout is a new troubleshooting clue—not a reason to repeat the same certificate checks.