For nodes that are already imported but fail with a TLS or x509 error when connecting. First determine whether the error occurs while fetching the subscription or connecting to a node. Then check the system clock, certificate hostname, trust chain and fingerprint—in that order. Change one field at a time and keep the original node for comparison. Disabling certificate verification is not a fix.
First, tell subscription errors from node handshake failures
“TLS handshake failed” doesn’t point to a single cause. Fetching a subscription over HTTPS establishes one TLS connection; connecting to a proxy node that uses TLS establishes another. A browser also verifies certificates separately when visiting an HTTPS site. All three errors may include x509, but each requires checking a different connection.
If the error appears as soon as you click Update Subscription and the node list hasn’t changed, check the website certificate for the subscription URL first. If the subscription updates successfully but the core reports an error when you use a particular node to visit a website, check that node’s TLS settings. If only the browser reports a certificate problem and the core logs no corresponding error, check the browser’s trust store, any network sign-in page, and local HTTPS inspection software.
- Note what triggered the error: updating the subscription, connecting to a node, or opening a particular website. “Connection failed” alone isn’t enough.
- Note when it happened: check the client log, retry once, then find the underlying error at that exact time—not just the final summary line.
- Check the security layer: VMess and VLESS are proxy protocols; that doesn’t mean every node uses standard TLS. If the security layer is REALITY, check its specific parameters rather than applying every standard TLS check.
Use the exact error message to guide your checks
Logs may include a server address, timestamp and core call details around the messages below. Look for the most specific cause. EOF or context deadline exceeded alone doesn’t prove a certificate problem; the server may have closed the connection, the network may be blocking it, or the handshake may have timed out.
Error: x509: certificate has expired or is not yet valid
Cause: The current time falls outside the certificate’s validity period. The device clock may be wrong, or the server certificate may have expired. Fix: Sync the device clock first. If the error persists with the correct time, send the validity dates from the log to your service provider and ask them to check the certificate deployment.
Error: x509: certificate is valid for …, not …
Cause: The hostname the client is verifying isn’t covered by the server certificate. The omitted part of the message shows the actual hostname. Fix: Check the node’s SNI and serverName against the certificate hostname specified by your provider. Changing only the connection address won’t fix the mismatch.
Error: x509: certificate signed by unknown authority
Cause: The certificate chain doesn’t lead to a trusted root. Common causes include a missing intermediate certificate, a self-signed certificate, or a problem with the local trust store. Fix: Try another network for comparison, then ask the server administrator to check the complete certificate chain. Don’t install root certificates from untrusted sources.
Error: remote error: tls: handshake failure
Cause: The remote server rejected the handshake. Possible causes include SNI, TLS parameters, the service endpoint or server policy. Fix: Restore the subscription’s original parameters, make sure the port and security layer match, then use the server logs to investigate. Don’t simply disable verification.
System clock: sync it, then reconnect
Certificate checks compare absolute time, not just the hour shown on screen. A different time zone usually won’t invalidate a certificate if the absolute time is correct. Manually setting the clock forward or back can trigger an error. Check the clock first if the device has been powered off for a long time, switched between operating systems, or failed to sync automatically.
-
Sync your computer’s clock
In Windows, open Settings → Time & language → Date & time. Turn on Set time automatically, check the time zone, then select Sync now. If syncing fails, make sure your regular internet connection works; don’t keep changing node settings.
-
Sync your phone’s clock
On Android, go to Settings → System → Date & time and turn on Set time automatically and Set time zone automatically. On some devices, search Settings for “Date & time.” Menu names vary by system version.
-
Reconnect
In v2rayN, restart the core. In v2rayNG, stop the connection and start it again. Send a new request and check the latest log so you don’t mistake an error from before the clock was synced for a current one.
-
Check the validity period
If the validity error remains after correcting the clock, note the current time, the certificate’s start and end dates, and the time zone shown in the log. If the certificate has expired, the server must renew it and reload it. Changing the client’s date won’t fix it properly.
On Windows, run the commands below in a terminal to check the local time and time service status. The second command may return an error if the system service isn’t running. It’s a diagnostic aid, not proof that the node is at fault. You don’t need to share your full device details when asking for help.
powershell -NoProfile -Command "Get-Date -Format o"
w32tm /query /statusCheck SNI, connection address and Host separately
The node’s address determines which IP or hostname to connect to. SNI is the server name sent during the TLS handshake and is usually also checked against the certificate. For WebSocket, Host is a field in the subsequent HTTP request. These values may be the same in some setups and different in others. Setting all three to the domain of a website that loads won’t make a node work.
| Setting | Purpose and what to check |
|---|---|
| Address and port | Identifies the connection endpoint. Port 443 is commonly used for TLS, but the port number alone doesn’t confirm that TLS is enabled. Use the values provided in your subscription. |
| SNI / serverName | Specifies the target name to the TLS server. For a standard TLS node, use the hostname specified by your provider that matches the certificate. Don’t include a protocol prefix, path or port. |
| Host | Often used to match the virtual host for HTTP transports such as WebSocket. Changing Host doesn’t change SNI or fix a certificate hostname mismatch. |
| Path and ALPN | The path is used by the relevant transport; ALPN negotiates the application-layer protocol. Keep the subscription’s values unless you have a clear reason to change them. Don’t force h2 or http/1.1 without specific instructions. |
In v2rayN, double-click the node to open the server editor. Check the address, port, transport protocol and server name in the TLS section. In v2rayNG, tap the edit icon next to the node and check Address, Port and SNI under TLS. Depending on the version, the field may be called serverName or Server name. Match fields by their meaning rather than looking for a menu that’s identical across every version.
Bottom line: restore the original SNI first, then check DNS resolution
If the certificate hostname doesn’t match, restore the SNI from the freshly imported subscription node. If the fields match but the wrong certificate is still returned, check DNS resolution for the node address and the server endpoint. Randomly changing the “disguise domain” only adds variables.
- Using an IP address as the connection address isn’t necessarily wrong. The connection can still validate a domain certificate if the server permits it and the correct SNI is configured.
- Wildcard certificates usually match only one level of subdomain. For example,
*.example.comdoesn’t matcha.b.example.com. These domains illustrate the rule; they aren’t node settings. - A later subscription update may overwrite manual changes to a node. For troubleshooting, duplicate the node before editing it and keep the original subscription entry for comparison.
Certificate chains and skipping verification are separate issues
Certificate verification checks the hostname, signature chain and validity period. If the server omits an intermediate certificate, some browsers may still load the site because the certificate is cached, while the proxy core reports an error. So a site loading in your browser is only a clue, not a substitute for checking the core’s result.
- Only one node fails: If other TLS nodes work on the same device, ask your provider to check that endpoint’s full certificate chain, hostname and certificate loading status.
- Multiple services fail on the same device: Check system updates, the root certificate trust store and local HTTPS inspection software. Don’t disable all security protections just to test.
- It fails on only one network: Complete any network sign-in first, then compare with another trusted network. If the certificate issuer looks suspicious, don’t enter subscription credentials; check the network environment.
- Using a self-signed certificate by design: Confirm the server’s identity through a trusted channel, then configure trust using a method supported by your client and core. If you can’t confirm its identity, don’t continue by ignoring verification.
If you enabled certificate verification bypass while troubleshooting, turn it off when you’re done and reconnect. The issue is fixed only when verification is back on, the log no longer shows the same error, and requests work as expected. Passing one latency test doesn’t prove that all traffic is going through the intended TLS endpoint.
TLS fingerprints: use the node’s specified settings, not trial and error
A TLS fingerprint affects characteristics of the client’s handshake, such as the order of extensions and the combination of supported parameters. It doesn’t replace a certificate or make an expired certificate valid again. Standard TLS and REALITY have different parameter requirements; don’t copy settings from one type of node to another.
v2rayN is a client interface; the selected core performs the handshake. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. A field appearing in the interface doesn’t mean every core supports it in the same way. Note which core is in use and check your provider’s requirements instead of comparing client names alone.
- Check the security layer. Edit the node and confirm whether it uses TLS or REALITY. Keep the original subscription settings. For standard TLS errors containing
x509, check the clock, SNI and certificate chain first. - Check the fingerprint field. Look for Fingerprint in the TLS or REALITY section of the node editor. If the subscription specifies a value such as
chrome, keep it as provided and don’t change ALPN as well. - Check core support. If the log says a field isn’t supported, update the compatible client and core, then import the subscription again. Deleting the field isn’t a universal compatibility fix.
- Check REALITY separately. In addition to serverName and the fingerprint, verify the provider’s public key, shortId and other parameters. Don’t put the public key in the certificate path or use the standard TLS verification bypass in place of these settings.
Bottom line: fix certificate-related issues before changing fingerprint settings
If the log clearly reports an expired certificate or hostname mismatch, fix that first; then check fingerprint compatibility if needed. Only investigate client handshake characteristics and server policy after verifying the clock, endpoint and parameters and confirming that the remote server still rejects the handshake.
Common questions and how to retest
Why does my phone connect while my computer reports a certificate error?
First confirm that both devices use the same node, SNI and security layer, then sync the computer’s clock. Connect both devices to the same network and test again. If only the computer still fails, check its trust store and local HTTPS inspection software. The same node name doesn’t guarantee identical settings.
It works with “Skip certificate verification” enabled. Should I leave it on?
Don’t leave it enabled as a regular setting. Note the original certificate error, turn the option off, then fix the clock, hostname and certificate chain one by one. If your provider asks you to ignore verification permanently, confirm its identity verification method first rather than accepting an unknown certificate outright.
Can switching to global mode fix a TLS handshake failure?
It won’t fix a certificate problem directly. Routing rules decide which outbound route a request takes; TLS verification confirms the identity of the server on that connection. Check which node the log actually selected. If switching modes makes the error disappear, traffic may simply be using a different route—the original node still needs fixing.
If a subscription update reports a certificate error, should I change the node’s SNI too?
Don’t change the node first. Sync the system clock and check that the hostname in the subscription URL is correct. If only that subscription URL fails, ask the provider to check the subscription site’s certificate. Changing an existing node’s SNI won’t change the HTTPS certificate of the subscription website.
For the final retest, use the same device, network and node, changing only one setting at a time. Restart the connection, check the core log and try loading a website. Confirm that it still works with certificate verification enabled. If you need help, share only the minimum details below; don’t post the full subscription URL, UUID, password or other credentials.
- Client name, installed version, current core and its version, and operating system.
- What triggered the error, the exact time, and the complete underlying error text with sensitive details removed.
- Transport, security layer and port, and whether SNI matches the provider’s requirements.
- What happened after syncing the clock, switching networks and restoring the original node settings. Note which single setting changed each time.