This guide covers TLS handshake and certificate errors when connecting to TLS nodes with the v2rayN desktop client, v2rayNG, or v2flyNG on Android. Use core logs to identify where the connection fails, then check your device clock, node address, SNI, certificate chain, and server listener in order. Don’t treat skipping certificate verification as a fix. The guide also distinguishes standard TLS from REALITY so you don’t mix their settings.
1. Pinpoint Where the Connection Fails
v2rayN is a desktop client interface; the proxy core it launches handles connections and reports TLS errors. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Log wording varies by core and version, but the troubleshooting order is much the same: first determine whether the failure occurs while downloading a subscription, connecting to a node, or browsing to a website.
If a certificate error appears while updating a subscription, check the HTTPS service hosting the subscription URL first. Changing a node’s SNI usually won’t help in this case. If only your browser reports a website certificate error while the core log shows the node connection succeeded, check the destination site, local HTTPS inspection software, or a network sign-in page. Don’t assume the node’s certificate is at fault.
- Keep the full context: Note the time of the error, the selected node, the core name, and several surrounding log lines. Before sharing, redact subscription URLs, user IDs, and credentials.
- Send just one request: Pause automatic latency tests and other network activity. Select one node and open a standard HTTPS page to avoid mixing up multiple errors.
- Check the innermost error first:
failed to process outbound trafficis only a high-level message. The followingx509,timeout, orconnection refusederror tells you what to check next.
2. Choose a Troubleshooting Path by Log Message
The common English error snippets below are shown as they appear in logs. Domains, dates, and addresses vary by environment, so the entire line may not match exactly. Change one setting at a time, reconnect, and check whether the innermost error changes.
Error: x509: certificate has expired or is not yet valid
Cause and fix: Your device’s current time falls outside the certificate’s validity period. The device clock may be wrong, or the server certificate may have expired. Sync your device clock first, then compare it with the validity dates in the log. If the time is correct, the server needs to renew and reload its certificate.
Error: x509: certificate is valid for …, not …
Cause and fix: The certificate name doesn’t match the name the client is checking. Compare the node’s SNI, the certificate’s SAN names, and the server’s virtual host configuration. Don’t use the node IP as the certificate hostname.
Error: x509: certificate signed by unknown authority
Cause and fix: The client can’t build a trusted certificate chain. Common causes include a missing intermediate certificate, a self-signed certificate, or a problem with the device’s trust store. Public certificate deployments should include the full chain. For a private service, deploy the trusted root certificate using your established security process.
Error: remote error: tls: handshake failure
Cause and fix: The remote end rejected the handshake, but this message alone doesn’t reveal why. Check the server logs for SNI, TLS version, client certificate requirements, and listener protocol. Also confirm the request reached the expected service.
Error: tls: first record does not look like a TLS handshake
Cause and fix: The port returned data that isn’t TLS. Check whether TLS is actually enabled on that port and whether the reverse proxy or forwarding rules route traffic to a plaintext service.
EOF and connection reset by peer don’t prove an SNI problem on their own. They indicate that the connection ended or was reset. Check server access logs and port connectivity, and test the same node on another network to narrow down the cause.
3. Incorrect System Time: Sync It, Then Check Certificate Validity
TLS verification uses the device’s actual system time to determine whether a certificate is valid. Verification fails if the clock is before the certificate’s start date or past its expiration date. A displayed time zone error doesn’t necessarily mean the system timestamp is wrong. Check the automatic sync result and actual date rather than simply changing the time zone.
-
Open Date and Time Settings
In Windows 11, go to Settings → Time & language → Date & time and check the year, date, and time. On other desktop systems, open the Date & Time page in system settings.
-
Sync the Clock Automatically
Turn on Set time automatically, then select Sync now under Additional settings. If syncing fails, check your network connection and whether the time service is reachable. Don’t keep adjusting the clock manually as a trial-and-error fix.
-
Check the Android Clock
On Android, open Settings, search for Date & time, and enable automatic time and time zone. Depending on the device, these options may be under System or Additional settings; use Settings search to find them.
-
Reconnect
Stop and restart the client connection, then try the request again. If the certificate validity error persists, compare the current time with the certificate’s start and expiration dates in the log to see whether the server needs to renew it.
If the device clock resets to a date years in the past every time it shuts down, check the hardware clock, battery, or system time service. If your clock is correct and multiple devices report an expired certificate on the same node, check the server certificate rather than changing security settings on each device.
4. Check SNI, Node Address, and Host Separately
The node address determines which host to connect to. SNI is the server name sent during the TLS handshake, which the server can use to select a site and certificate. In standard TLS configurations, serverName is also typically used to verify the certificate name. A WebSocket Host is an HTTP request header that operates at a different layer. These fields may all look like domain names, but that doesn’t mean they must match.
| Field | Purpose | What to check |
|---|---|---|
| Address and port | Identify the connection endpoint | DNS resolution, listening port, and forwarding destination |
| SNI / serverName | Select the TLS virtual host; usually used as the name to verify | Match the server configuration and certificate SAN |
| WebSocket Host | Select the HTTP virtual host or route | Match the Host received by the reverse proxy |
| WebSocket Path | Select the HTTP request path | Match the server’s capitalization and leading slash |
In v2rayN, double-click the node you want to edit to open its settings, then find the SNI or ServerName field in the TLS section. Check it against the value provided by your service provider; field names vary between versions. In v2rayNG and v2flyNG, open the node’s edit screen and check the corresponding TLS setting. Record the original values first, and don’t change the address, port, SNI, and transport at the same time.
- Enter only the hostname for SNI: For example,
edge.example.net, withouthttps://, a port, or a path. This is a reserved example domain; use the hostname specified by your server provider. - The address and SNI can differ: Connecting to an IP address doesn’t mean the certificate must be issued for that IP. If the server uses a domain certificate, enter the correct server name from its configuration.
- Check the SAN: Certificate names are usually verified against the Subject Alternative Name. A wildcard such as
*.example.netgenerally matchesa.example.net, but don’t assume it also covers the root domain or deeper subdomains. - “Camouflage domain” isn’t a value to pick at random: This term may refer to SNI or to the HTTP Host. Confirm which field is meant; don’t substitute the domain of just any website that loads.
5. allowInsecure and Certificate Chains: Restore Verification Instead of Bypassing Errors
allowInsecure is a common TLS core setting that skips certificate verification. Enabling it may stop hostname mismatches, expired certificates, or trust-chain errors from blocking the connection, but a successful connection doesn’t prove the server is genuine. For standard public TLS nodes, leave certificate verification enabled and fix the underlying certificate problem.
- On the client: Check that Skip certificate verification is disabled in the node’s TLS settings. The corresponding setting is usually
allowInsecure: false. If you use a subscription, check whether an update overwrites this setting. - On the server: Confirm that the service loads the complete certificate chain, usually the leaf certificate and any required intermediate certificates, not just the site certificate. The server generally doesn’t need to send the root certificate.
- After renewal: Check which component actually terminates TLS. It may be a reverse proxy or the proxy core itself. Make sure that component reloads the certificate; an updated file on disk alone doesn’t mean the new certificate is in use.
- Private certificates: Configure a trusted certificate using a method supported by the system or core only after verifying the issuer and deployment policy. Don’t import an unknown root certificate for an unfamiliar node.
If the same node reports unknown authority on an older device but works on a newer one, check the older device’s system updates and trust store. Also rule out a missing intermediate certificate on the server or a cached certificate on the other device. HTTPS inspection by security software can introduce a different issuer; verify this against your organization’s security policy rather than disabling all protection.
6. Use Commands to Separate Port Connectivity Issues from TLS Errors
The commands below are for standard TLS services you’re authorized to troubleshoot. Replace the example hostname with the actual node address and SNI, and use the node’s configured port. These commands don’t test proxy protocol connectivity. In Windows PowerShell, you can first check the TCP port; in an environment with OpenSSL installed, you can also inspect the handshake and certificate verification results.
# PowerShell: Check whether the node's TCP port is reachable
Test-NetConnection -ComputerName node.example.net -Port 443
# OpenSSL: Connect to the node and send and verify the specified server name
openssl s_client -connect node.example.net:443 -servername edge.example.net -verify_hostname edge.example.net -verify_return_error -showcertsTcpTestSucceeded: True means only that the TCP connection was established; it doesn’t prove that the certificate is trusted, proxy authentication is correct, or routing works. In OpenSSL, -servername sends SNI, while -verify_hostname explicitly verifies the hostname. They serve different purposes; using the former alone doesn’t provide full hostname verification.
- If TCP fails, check the address, port, server listener, and firewall first. Don’t keep changing certificate names.
- If TCP succeeds but the response isn’t TLS, check for an incorrect port mapping or reverse proxy entry point.
- If TLS reports a hostname or trust-chain error, check the certificate SAN, full chain, and local trust store.
- If TLS verification succeeds but the client still fails, check the proxy protocol, authentication settings, WebSocket path, and other transport settings.
7. Retest After Fixing the Issue: Common Questions
For a reliable retest, keep the same node, network, and destination page. Turn off automatic switching, then restart the connection. Check that the new log no longer shows the certificate error before restoring your usual routing settings. If you need help from your service provider, send the error time, error keyword, core in use, and checks you’ve completed. Don’t send the full subscription URL.
Still seeing an expired certificate error after syncing the clock?
First confirm that system time sync succeeded, then check the certificate expiration date in the log. If it has expired, ask the server operator to renew and reload the certificate. Also check SNI to make sure you’re not receiving an old certificate from a different virtual host.
Checking Skip certificate verification makes it work. Can I leave it on?
Don’t use it as a long-term setting. Restore verification, then check the certificate’s validity period, SAN, and full chain. A connection that works with verification skipped only means the check was bypassed; it doesn’t prove you reached the intended server.
Why won’t a webpage load even though the latency test shows a result?
Different tests may check only TCP or use a different request path. Check the core log for the actual webpage request. If TLS succeeds, check the system proxy, routing rules, and DNS. See the site’s Troubleshooting guide for more help.
Did your corrected SNI revert after updating the subscription?
Compare the node settings before and after the update to see whether the subscription source keeps sending the wrong value. You can copy the node for a temporary comparison, keep the original configuration, and ask your provider to fix the subscription source so you don’t have to repeat the manual change after every update.
It works in another client. Should I reinstall the original one?
First compare the node settings, core versions, system clocks, and trust stores in both clients. Nodes with the same name don’t necessarily use the same parameters. Identify the difference before updating the client; this usually makes the problem easier to pinpoint than reinstalling it straight away.
Check these in order: the connection endpoint is correct, the system clock is accurate, SNI matches the certificate, the certificate chain is trusted, and the proxy settings agree. Recording the result of each check makes it easier to find the cause than changing DNS, ports, hostnames, and security settings all at once. For help with field names, see the Glossary. To import a node for the first time, follow the client setup guide.