For users who have imported a configuration but see TLS or x509 errors in the connection log. First determine whether the error occurs during a subscription request or a node connection. Then sync the system clock, check the server address, SNI, and certificate hostname, and finally inspect the certificate chain and server endpoint. Change one field at a time and keep certificate verification enabled so you can tell which change fixed the issue.
Identify where the error occurs and which handshake failed
“TLS handshake failed” describes an outcome, not a specific cause. Updating a subscription over HTTPS also requires a TLS handshake; when a node uses TLS, the proxy core performs a separate handshake with the node server. If the subscription request fails, check the subscription domain and service. Only check the node’s SNI if the node connection fails. Don’t change both sets of settings just because the same keyword appears in the error.
Stop the connection and note what action triggered the error. Then reconnect and make a web request. In v2rayNG and v2flyNG, open Logs from the main screen’s side menu. In v2rayN, check the log panel on the main screen. Labels vary slightly by version; capture several lines before and after the error, along with the destination domain and port, rather than just “connection failed.” Before sharing logs, redact subscription URLs, user IDs, and credentials.
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 expired. Fix: Sync the device clock, then check the certificate’s validity dates. If the time is correct and the error persists, have the server operator renew and reload the certificate.
x509: certificate signed by unknown authority
Cause: The certificate chain cannot be traced to a root certificate trusted in the current environment. An intermediate certificate may be missing, or the certificate may be private. Fix: Check the complete certificate chain on the server and the device’s trust store. Don’t bypass verification.
remote error: tls: handshake failure
Cause: The remote server terminated the handshake. Possible causes include SNI, TLS parameters, a client certificate requirement, or server endpoint configuration. Fix: Check the original subscription parameters first, then use server logs to narrow down the cause. This message alone does not prove that the certificate has expired.
If the log shows only i/o timeout, connection refused, or EOF, that does not confirm a certificate verification error. First check that the server address resolves, the destination port is reachable, and the service on that port actually supports TLS. The steps below apply to connections explicitly configured to use standard TLS. REALITY has different parameters and verification requirements, so don’t apply these steps to it.
Sync the System Clock First to Rule Out Certificate Date Errors
Certificates have a start date and an expiration date. If the device clock is set too far ahead, a valid certificate may appear expired; if it’s set too far back, the certificate may appear not yet valid. Checking the hour and minute isn’t enough—verify the year and date, and make sure automatic time sync is working. A different displayed time zone doesn’t necessarily cause an error; verification uses the actual time reported by the system.
-
Find the Date and Time Settings
On Android, go to Settings → System → Date & time. On some devices, this option is under More settings or General management. You can also search for “Date & time” in Settings.
-
Turn On Automatic Time Sync
Turn on “Set time automatically” and “Set time zone automatically,” then wait for the network time sync to complete. If the date is still wrong, check the device’s network and system time service. Don’t keep testing the node with an incorrect date.
-
Check the Desktop Clock
On Windows, go to Settings → Time & language → Date & time, turn on Set time automatically, and select Sync now. On macOS, go to System Settings → General → Date & Time and turn on automatic date and time.
-
Reconnect and Save the Logs
Stop the client connection, reconnect, and request the same web page again. If the validity error persists, note the current time shown in the log and the certificate’s validity period, then ask the node operator to check the certificate renewal status.
On Linux, run timedatectl status to check the system time and sync status. On systemd systems, run sudo timedatectl set-ntp true to enable network time sync. This command does not work on every distribution. If another time sync service is already running, follow your system’s configuration instead of enabling conflicting services.
Server Address, SNI, and Hostname: What’s the Difference?
The server address determines which IP address or domain to connect to; the port selects the listening endpoint. SNI is the server name sent during the TLS handshake. The server may use it to select a certificate or backend site, and the client typically also uses the configured server name to verify the certificate hostname. Enter a domain only in SNI—no https://, port, or path.
“Camouflage domain” in tutorials doesn’t always refer to the same field. The WebSocket Host, HTTP request path, and TLS SNI operate at different layers. They may use the same domain if the server is configured that way, or they may differ. A domain in the Host field does not guarantee that the certificate covers it, and a web page path should never be copied into SNI.
| Field | Purpose | What to Check |
|---|---|---|
| Server address | Establishes the underlying network connection | Must match the endpoint provided; can be an IP address or domain |
| Server port | Selects the remote listening service | 443 is a common TLS port, but the port number alone does not prove that TLS is enabled |
| SNI / serverName | Sends the TLS server name and is usually used for hostname verification | Must match the server’s expected name and a hostname covered by the certificate’s SAN |
| Host | The host field for HTTP-based transports | Set it as required by the WebSocket or other transport endpoint; it does not replace SNI |
| allowInsecure | Controls whether certificate verification is skipped | Keep set to false for normal use; it cannot fix a certificate or hostname error |
Bottom line: If the server address is an IP, check SNI first
If the node connects to an IP address but the certificate covers only a domain, use the domain specified by the server operator and covered by the certificate as SNI. Don’t substitute a well-known website’s domain, or change the server address to the certificate domain just to silence the error—you could end up connecting to a completely different endpoint.
Hostname matching is based primarily on the certificate’s SAN. A wildcard such as *.example.com typically matches node.example.com, but not the root domain example.com or a.node.example.com. These domains are examples to illustrate matching rules, not usable nodes.
Where to Check SNI and Certificate Verification in Each Client
Note the node’s original address, port, transport, TLS type, SNI, and Host value. Subscription-generated nodes may revert manual changes on the next update, so make a separate test configuration first. If the client has no duplicate option, save the original settings and create a test node manually. Field labels vary by release and may appear in English or another language; go by what each field does. SNI is usually configured per node, not in a single global setting.
-
Check v2rayNG
On the main screen, tap the pencil icon beside the node and open its configuration. In the TLS section, make sure the security type is
tlsand check the “SNI” field. Keep “Allow insecure” orallowInsecureturned off. Save, select the node again, and reconnect. -
Check v2rayN
In the server list, double-click the node to open its settings. In the “Transport Layer Security (TLS)” section, check the TLS type, “SNI,” and “Allow insecure (allowInsecure).” Set the latter to
false, save, select the node as the active server, and reconnect. -
Check v2flyNG
On the main screen, tap the edit button for the configuration to open its node settings. In the TLS fields, check
serverNameor SNI, and turn offallowInsecure. If you imported custom JSON, check the TLS settings in that configuration; don’t assume the standard node form overrides them. -
Compare with the Original Settings
Compare each field in the editor with the provider’s configuration details. Pay particular attention to whether an update removed SNI or changed TLS to a different security type. Fix one field at a time, then save, reconnect, and check the new log.
v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. They don’t support exactly the same configurations, so don’t swap configurations containing specific extensions just to test them. For standard VMess or VLESS connections over TLS, first confirm that the current core supports the protocol and transport. An incorrect user ID usually isn’t fixed by changing SNI.
Check the Certificate Chain and Server Endpoint
If an untrusted certificate error persists after checking the time and SNI, inspect the certificate chain served by the server. A common issue is that only the site certificate is configured and an intermediate certificate is missing. Another is that the certificate has been renewed but the reverse proxy handling TLS hasn’t reloaded it. If traffic passes through a relay or CDN, check the layer the client actually connects to—not just the origin server’s certificate files.
- Self-hosted server: Check the certificate path, full certificate chain, and private key loaded by the TLS listener. Check that the configuration reload succeeded.
- Subscription node: Send the exact error, time of occurrence, node label, and client name to the operator. Don’t share your full subscription URL or authentication credentials.
- Fails on only one network: Test on another trusted network. Check for a captive portal, DNS issues, or network equipment that replaces certificates. Don’t install root certificates from untrusted sources.
- Fails only on older devices: Check for system updates and the status of the trust store. A successful desktop test doesn’t mean the Android client uses the same trust environment.
On macOS or Linux with OpenSSL installed, use the command below to inspect the TLS certificate chain and hostname verification. It connects to a reserved example domain, not your node. For troubleshooting, replace the connection address, port, and both domain names with your actual settings. The command establishes a connection, but does not verify VMess or VLESS authentication or the rest of the transport path.
openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error -showcertsCheck the output for the certificate’s validity period, hostname, and any verification errors. Even if you see Verify return code: 0 (ok), it only means certificate verification passed in that test environment; it doesn’t prove the proxy configuration works end to end. If the standard TLS handshake succeeds but the client still fails, check the transport path, Host, protocol authentication, and whether the client connects to the same address.
allowInsecure and Common Misconceptions
allowInsecure=true skips essential certificate checks, so the server’s identity is no longer reliably verified. It won’t renew a certificate, complete a certificate chain, or correct SNI. Even if enabling it temporarily allows a connection, that only points to a verification-related issue; it doesn’t mean the configuration is fixed.
If disabling certificate verification lets it connect, can I leave it that way?
Not recommended. Set allowInsecure=false again and check the time, hostname, and certificate chain in that order. For a self-hosted service using a private certificate, configure trust or certificate pinning in a controlled way and confirm that the current core supports it instead of bypassing identity checks long term.
If SNI is blank, does the client use the server address automatically?
Some configurations derive the server name from the address, but the behavior depends on the core and configuration type. Don’t rely on this when the address is an IP. Enter the certificate-covered domain specified by the provider, then save and reconnect.
The domain opens in my browser. Why does the node still fail?
The browser may connect to a different port, IP address, or endpoint, and it may use a different trust store. Compare the node’s connection address, port, and SNI first. A page loading in the browser only confirms that particular web request worked; it doesn’t mean the node uses the same TLS connection.
What should I do if a subscription update restores the original error?
Compare the SNI, TLS type, and port before and after the update. Keep temporary changes in a separate test configuration and report incorrect subscription parameters to the provider. Don’t repeatedly change settings only to have an update overwrite them, and don’t assume the issue is caused by routing rules.
The node connects, but subscription updates show an x509 error. Why?
Check the HTTPS certificate for the subscription URL and verify the system time. The SNI in the node editor usually does not control subscription requests. If the subscription is updated through a proxy, check that proxy connection too, but don’t start by changing the node’s certificate verification setting.
Retest After Fixing the Issue
When you’re done troubleshooting, confirm that the system time is correct and certificate verification is enabled, then restart the connection. Don’t rely on a latency test alone: different tests cover different connection stages, and a result doesn’t prove that authentication, transport, and web requests all work. Retest with the same node, network, and destination to minimize variables.
- Make sure the edited node is the active configuration and the previous connection has been stopped and restarted.
- Make an actual web request and check the log for any remaining x509 or TLS errors.
- If the certificate error is gone but the page still won’t load, use the new log to check authentication, the WebSocket path, Host, DNS, and routing rules. Don’t keep changing SNI.
- Confirm that subscription updates won’t overwrite the fix. Record what you changed and the test results so you can refer to them if the same issue comes up again.
Bottom line: Use the Latest Log to Choose Your Next Step
If correcting the time changes the error to a hostname mismatch, check SNI next. If the hostname error goes away and a transport error appears, move on to transport troubleshooting. Following the latest specific error is more effective than changing DNS, the port, protocol, and certificate settings all at once.