For users seeing TLS handshake failures, expired certificates, or hostname mismatches in v2rayN, v2rayNG, or v2flyNG. First identify whether the error occurs during subscription updates or node connections, then check the clock, address and port, SNI, certificate chain, and transport settings. Learn which issues you can fix in the client, which require the node operator, and why allowInsecure should not be used for everyday connections.
First, identify which connection is failing
“Handshake failed” describes the result, not the cause. A typical TLS connection first resolves the server address and establishes a TCP connection, then negotiates TLS parameters and verifies the certificate. Proxy protocol authentication and forwarding usually happen afterward. A DNS lookup failure, an unreachable port 443, or rejected protocol authentication can all appear as connection failures in the client—but changing certificate settings won't fix them.
Check what you were doing when the error appeared. A certificate error after clicking “Update subscriptions” concerns the subscription server's HTTPS connection. If you selected a node, tried to open a webpage, and the core log shows x509, the proxy's outbound TLS verification may be failing. The allowInsecure setting in a node's editor usually does not affect HTTPS verification for subscription downloads.
- Subscription update failed: Note when the update occurred and the subscription service's domain. Check the system clock and the service's certificate; don't share the full subscription URL.
- Node connection failed: Check the log output on the v2rayN main screen, or find the outbound error at the same time in v2rayNG's “Logs” menu.
- Only the browser reports an error: Check whether the domain in the error belongs to the destination website. Don't assume a certificate error on the destination site is caused by the proxy node.
Choose a troubleshooting path based on the exact error
Different core and client versions may add connection details around the error text. The snippets below are common core errors; the full log line may look different. They can help narrow down the cause, but a single error message rarely proves it.
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. Sync the system clock first. If the error persists with the correct time, ask the operator to check the certificate's validity and reload the service after renewal.
Error: x509: certificate is valid for edge.example, not node.example
Cause and fix: The name the client is verifying isn't covered by the certificate. Confirm the required SNI and the certificate's SAN with the server operator. Don't set SNI to node.example just because that's the connection address.
Error: x509: certificate signed by unknown authority
Cause and fix: The trust chain couldn't be established. Possible causes include a missing intermediate certificate, a self-signed certificate, an outdated trust store, or certificate replacement somewhere on the network. Compare results across devices and networks, then check that the server sends the complete certificate chain.
Error: remote error: tls: handshake failure
Cause and fix: The server rejected the handshake. SNI, protocol versions, client fingerprinting, or server-side policy may be involved. Restore the node's original settings and check parameters one at a time; don't assume the certificate has expired.
Error: tls: first record does not look like a TLS handshake
Cause and fix: The destination port returned non-TLS data. Check the port and whether TLS is enabled. For example, don't use port 80 for a TLS service that's listening on port 443; port 80 commonly serves plain HTTP.
EOF, connection reset by peer, and i/o timeout can have many causes, including an interrupted connection, firewall, wrong port, or unavailable server. These messages alone are no reason to disable certificate verification. First check whether a TCP connection can be established, then troubleshoot the TLS layer.
Five checks for your system clock and node settings
Change one variable at a time and repeat the same test request. Save the original configuration first. If you change the address, port, SNI, and fingerprint all at once, a successful connection won't tell you which change fixed the problem. The Windows paths below use the Windows 11 interface as an example. Client fields may appear in different places depending on the app and version, but their meanings remain the same.
-
Sync your clock
On Windows, open Settings → Time & language → Date & time, turn on “Set time automatically,” then click “Sync now.” On Android, automatic time is usually under Settings → System → Date & time, though some manufacturers place it under “Additional settings.” Check the actual date and time, not just the time zone.
-
Check the port
In v2rayN, double-click the active node on the main screen to open its editor. In v2rayNG, tap the node's edit icon in the node list. Compare the “Address” and “Port” with the details from your node provider. TLS commonly uses port 443, but 8443 and other ports are also valid. Don't change everything to 443 just because you see a certificate error.
-
Check SNI
In the node editor, find the TLS or transport security section and check the “SNI” or “serverName” field. Enter the hostname required by the server—without
https://, a port, a path, or spaces. The connection address and SNI can differ; use the node's specified values rather than guessing. -
Restore certificate verification
Check “Allow insecure” or “allowInsecure.” It should normally be off, meaning
false. Also restore the fingerprint and ALPN settings required by your provider. If they weren't in the original configuration, don't add them just to make the error disappear. -
Reconnect and check the logs
Save the node and reconnect. In v2rayNG, stop and then restart the connection. In v2rayN, make sure the edited node is selected before running the test again. Note whether the error changes from a certificate error to a connection timeout or protocol authentication error; that means the failure is occurring at a different stage.
Certificate verification uses the actual system time, not just the displayed time zone. Changing the time zone without correcting an inaccurate system clock usually won't fix a validity error. For example, if the system date is still in 2025 but the certificate becomes valid in 2026, it will appear “not yet valid.” Setting the clock too far ahead can make a valid certificate appear expired.
# Linux: Check the system time and synchronization status
timedatectl status
# Linux: Enable the system's supported network time synchronization; administrator privileges are usually required
sudo timedatectl set-ntp trueThe second Linux command depends on a supported time synchronization service being available on your system. Check the sync status again afterward. On macOS, go to System Settings → General → Date & Time and check automatic time settings. If the clock is correct and only one node fails, there's no need to keep changing your device's time; check the server certificate and node settings instead.
SNI, connection address, and Host are different fields
SNI is the name the client sends to the server during the TLS handshake. It's commonly used to select a virtual host and certificate. In a standard TLS configuration, serverName is also typically used as the certificate verification name. The connection address is used to reach the server, while the HTTP Host header belongs to the higher-level HTTP request. These values may match or differ, depending on how the service is configured.
| Field | Stage | What to use | Common mistake |
|---|---|---|---|
| Address and port | DNS lookup and connection setup | The actual node endpoint, such as port 443 or 8443 | Using the subscription website address as the node address |
| SNI / serverName | TLS handshake and hostname verification | The server-approved name and the certificate's SAN | Adding a protocol prefix or path, or changing the hostname at random |
| WebSocket Host | HTTP upgrade request | Virtual host configuration on the reverse proxy | Assuming that changing Host also changes SNI |
| WebSocket path | Request path matching | The path configured on the server | Troubleshooting only the certificate when the path is wrong |
For example, if the entry address is node.example and the server requires SNI edge.example, the connection still goes to the entry address, but the certificate for standard TLS must cover edge.example. The .example names in this article are reserved examples, not usable nodes. If you connect directly by IP without setting the correct verification name, hostname validation may fail when the certificate covers only a domain.
Bottom line: Check the fields before changing hostnames
If you see a hostname mismatch, first ask the operator to confirm the address, SNI, and HTTP Host values. Only a name covered by the certificate and accepted by the server will work. Replacing it with a well-known website's domain won't fix a standard TLS configuration.
“Fake domain” isn't a standardized technical field. It may refer to SNI, HTTP Host, or the server name used by REALITY, depending on the configuration. First identify the transport security type: CA certificate validation in standard TLS follows a different troubleshooting process from the authentication parameters used by REALITY.
How to check the certificate chain, fingerprint, and transport settings
A domain opening in your browser doesn't prove that a proxy node's TLS configuration is correct. The browser may connect on port 443 while the node uses 8443; the two connections may also use different SNI values, entry addresses, or trust stores. For a meaningful comparison, use the same entry point and hostname.
- Complete certificate chain: The server should usually send the leaf certificate and all required intermediate certificates. If an intermediate certificate is missing, some devices may still build a trusted chain while others report unknown authority.
- Hostname coverage: Check the certificate's Subject Alternative Name.
*.example.comusually coversa.example.com, but nota.b.example.comorexample.com. - TLS versions: TLS 1.2 and TLS 1.3 are protocol versions, not client version numbers. If the client and server have no supported version or cipher suite in common, the connection may fail before certificate verification.
- Client fingerprint: Relevant Xray settings can use a fingerprint option to adjust ClientHello characteristics, such as
chrome. This is not the server certificate's fingerprint and does not disable authentication. Check which options the current core supports. - ALPN:
h2andhttp/1.1are used to negotiate the application protocol. Requirements differ for gRPC, WebSocket, and plain TCP, so don't copy an ALPN list from another node.
If OpenSSL is installed on your device, you can use the command below to check a standard TLS endpoint. The example uses reserved domain names; update the endpoint and SNI for your setup before running it. This is not a proxy protocol test and cannot tell you whether a REALITY node is working.
openssl s_client \
-connect node.example:443 \
-servername edge.example \
-verify_hostname edge.example \
-verify_return_error \
-showcerts-connect sets the connection target, -servername sends SNI, and -verify_hostname specifies the name to verify. Sending SNI alone doesn't perform hostname matching. Check the certificate's validity, names, and verification result. OpenSSL may use a different trust store from your client, so treat the result as a diagnostic clue, not a definitive verdict.
Why allowInsecure should stay off
In common V2Ray/Xray standard TLS configurations, allowInsecure: true skips normal verification of the server's certificate chain and hostname. The connection may still be encrypted, but the client can no longer reliably confirm the identity of the server it's connected to. Encryption alone doesn't prove you're connected to the intended server.
| Issue | What enabling it may change | What to do instead |
|---|---|---|
| Expired certificate or hostname mismatch | May bypass the verification error | Correct the clock or SNI, or renew the server certificate |
| Untrusted self-signed certificate | May bypass the trust chain error | Use a trusted certificate or supported trust configuration appropriate for the controlled environment |
| Blocked port or connection timeout | Won't restore network connectivity | Check the port, network, and service status |
| Incorrect path or authentication parameters | Won't fix higher-level protocol settings | Restore the correct path and node credentials |
| REALITY authentication failure | Can't replace REALITY authentication | Check REALITY-specific parameters and core support |
If temporarily enabling this in a controlled test lets you connect, it suggests certificate verification may be involved—but it doesn't prove the node is secure or that every issue is fixed. Don't transmit sensitive data during testing. Turn it off immediately afterward and fix the cause indicated by the original error. A safer approach is to use logs and certificate checks to identify the problem, rather than leaving verification disabled to keep the connection working.
Bottom line: The issue isn't fixed until verification works again
Set allowInsecure back to false and reconnect to the same node. If the error persists, continue checking the clock, hostname, and trust chain. Troubleshooting is complete only when normal verification succeeds and the actual request works.
Common questions and what to include in a bug report
It works on my computer. Why does Android say the certificate isn't trusted?
Use the same node, SNI, and network on both devices, and make sure automatic time is enabled. If the settings match, check for differences in system trust stores and ask whether the server is missing an intermediate certificate. Don't copy the setting that skips verification from your computer.
The TLS handshake started failing after a subscription update. Should I reinstall the client?
First compare the node's address, port, TLS type, and SNI in the editor, and make sure you've selected the updated node rather than an older duplicate. Reinstalling usually won't fix an expired server certificate. Save the original error and ask the operator to check the configuration.
Why does it work when I switch to my phone's hotspot?
This suggests the network path may affect the connection, but it doesn't identify the cause. Keep the node settings unchanged and record the error on both networks. If the problem network reports an unknown certificate authority, check for HTTPS inspection or certificate replacement. Don't blindly trust an unfamiliar root certificate.
The latency test passes. Does that mean the certificate is fine?
Not necessarily. A TCP latency test only shows that the port accepts a connection; it may not verify TLS or send a proxy request. Check which test you're running, then make a real request and review the core log. A latency number alone doesn't confirm that the connection works end to end.
The certificate was renewed. Why does the client still say it's expired?
Ask the operator to confirm that the service has reloaded the new certificate and that all entry points are serving it. Check the clock and endpoint address in the client. Inconsistent settings across servers or IPv4 and IPv6 endpoints can also cause failures on only some connections.
If you need more help, share only the minimum information needed to reproduce the issue. Don't post the full configuration file or include your subscription link in a screenshot. Use the checklist below, then continue troubleshooting in our Troubleshooting section. For unfamiliar terms, see the Quick Reference.
- Client name, exact version, active core name and version, and operating system version.
- Whether the error occurred during a subscription update, node test, or actual browsing; include the time and a redacted copy of the error.
- Port, transport type, TLS or REALITY type, and whether SNI matches the connection address. Do not include node credentials.
- Whether the system clock is synchronized, whether the issue reproduces on another network, whether another device works, and which individual settings you've tried changing.