Use the logs to distinguish clock validation failures, certificate name mismatches, and ordinary connection timeouts. Then sync your system clock, check the node’s SNI, and retest with a real connection delay test and an actual request. This guide is for users who have imported a subscription and can start the core, but see TLS or x509 errors when connecting. If the server certificate has expired, contact the node provider.
Identify Where the TLS Handshake Fails
The TLS handshake takes place while a secure connection is being established. For a standard TLS node, the client negotiates parameters with the server and checks the server certificate’s validity period, chain, and identity. A reachable TCP port only confirms that the transport layer is accessible; it doesn’t mean certificate validation passed or that VMess or VLESS authentication will succeed.
Find the log entry for the current test in the log panel at the bottom of v2rayN. Look for the most specific cause rather than copying only the outer failed to process outbound traffic message. A connection can be wrapped in several layers; the useful details are usually near x509:, tls:, or dial tcp.
Error: x509: certificate has expired or is not yet valid
Cause and fix: The device’s current time falls outside the certificate’s validity period. Sync the date and time first. If the error persists, ask the node provider to check the certificate’s validity dates and the certificate actually deployed on the server.
Error: x509: certificate is valid for …, not …
Cause and fix: The server name used for validation isn’t covered by the certificate. Check the SNI against the node provider’s settings, and ask whether the server is returning a default certificate because the name is incorrect.
Error: x509: certificate signed by unknown authority
Cause and fix: The certificate chain doesn’t lead to a trusted root certificate. Check that the server provides the complete intermediate chain, that the device’s trust store is working, and that the network isn’t using a TLS inspection device.
Sync Your System Clock and Check the Time Zone
Certificate validity is based on absolute time, not the time zone shown on your desktop. A wrong time zone alone generally won’t invalidate a certificate if the system clock still shows the correct moment. Manually changing the date, inconsistent time settings in a dual-boot setup, or restoring a virtual machine from an old snapshot can shift the actual system time. Check the year, month, and day first, then the minutes—not just the hour in the taskbar.
-
Note the Times
Write down the current time in the log and the certificate’s validity period. If the log uses UTC, convert it before comparing: for example, 02:00 UTC and 10:00 UTC+8 are the same moment, not an eight-hour discrepancy.
-
Enable Automatic Time Sync
In Windows 11, open Settings → Time & language → Date & time, turn on Set time automatically, check the time zone, then select Sync now. If syncing fails, first check whether your network can reach a time server.
-
Check Sync Status
On Windows, run
w32tm /query /statusin a terminal to check the time source and the last successful sync. To trigger a sync manually, runw32tm /resyncin an administrator terminal. If it returns an error, don’t keep changing node settings. -
Run the Test Again
Return to the client, select the current server again, and run a real connection delay test. Check the new log’s timestamp to confirm it’s from the latest connection; don’t use an old entry to judge whether the fix worked.
Check the Time Source on Other Platforms
- macOS: Open System Settings → General → Date & Time and enable automatic date and time. If your device is managed by an organization, check whether its policy locks the time source.
- Android: Usually, go to Settings → System → Date & time and enable automatic time and time zone. Some devices put these options under Additional settings or General management; use Settings search to find them. Then reconnect in v2rayNG or v2flyNG.
- Linux: On systemd-based distributions, run
timedatectl statusto check whether the system clock is synchronized. You can enable network time sync withsudo timedatectl set-ntp trueif supported by your system. If your distribution uses a separate time service, check that service’s status.
These numbers distinguish service types; they don’t mean every node should be changed to port 443. If the certificate still appears expired after syncing, check its expiry date in the log. Changing the client’s clock doesn’t renew a server certificate.
Check SNI, Server Address, and Transport Host
SNI is the server name sent in the TLS ClientHello. It may appear in the interface as “SNI,” “Server name,” or “serverName”; some guides call it a “disguised domain.” It isn’t arbitrary display text: in standard TLS validation, it often affects both which certificate the server presents and which name the client checks.
| Field | Purpose | What to check |
|---|---|---|
| Address and port | Specifies the remote endpoint to connect to | Keep the domain or IP from the subscription; don’t change the port just because of a certificate error |
| SNI / serverName | Indicates the TLS server name, usually for name validation | Enter the hostname specified by the provider, without a scheme, path, or port |
| WebSocket Host | Helps select the virtual host for HTTP requests | It can’t directly replace SNI; whether the two match depends on the deployment |
| WebSocket path | Specifies the path for the HTTP upgrade request | Keep the leading slash, capitalization, and required parameters; don’t enter it as SNI |
The example hostname edge.example.invalid illustrates the SNI format only; it won’t work for a real connection. Don’t enter https://edge.example.invalid:443/path as SNI or paste in the entire subscription URL. Get the actual hostname from the node provider—don’t substitute a popular website’s domain.
-
Find the Current Node
In the v2rayN server list, confirm the selected entry and subscription group, then double-click that entry to open its settings. Note the address, port, transport, and security type first so you don’t edit a different node with the same name.
-
Check the Server Name
Under transport security settings, check the SNI or server name field. Compare it character by character with the provider’s settings and remove any leading or trailing spaces. Don’t add
https://, a port, or a path. The field’s location varies by client version and protocol. -
Check Host Separately
When using WebSocket, check Host and path as well. Don’t change the address, SNI, and Host to the same value just to clear a domain error; the endpoint address and certificate name may be different.
-
Save and Retest
Save the settings, select the node again, and run a real connection delay test. Check whether the error changes from a certificate name mismatch to another type. Change only one related group of fields at a time.
In v2rayNG or v2flyNG, open the relevant node’s edit screen from the node list and expand the TLS settings to check the server name. Manual changes to subscription nodes may be overwritten the next time the subscription updates. If the correction works, ask the provider to update the subscription rather than relying on a local workaround.
Distinguish Certificate Chain Errors from REALITY Settings
A correct device clock and matching SNI don’t rule out a server-side issue. A standard TLS server must present the correct leaf certificate and any required intermediate certificates. Failures can be intermittent if only the leaf certificate is deployed, the service wasn’t reloaded after renewal, or only some machines behind a load balancer received the update.
- Validity error: Ask the provider to check the certificate actually returned by the current endpoint, not just the dates on a new certificate file. A successful renewal doesn’t mean every endpoint is using the new certificate.
- Name mismatch: Check whether the certificate’s Subject Alternative Name covers the configured server name. A wildcard such as
*.example.invalidusually covers only one subdomain level, not the root domain or deeper subdomains. - Unknown certificate authority: Check the intermediate chain, system updates, and root certificate trust. If the problem occurs only on a company or campus network, ask whether TLS inspection is in use. Don’t install a root certificate from an untrusted source.
- REALITY nodes: Along with the server name, check the public key, shortId, fingerprint, and flow against the provider’s settings. REALITY doesn’t use a standard self-managed certificate deployment, so renewing a certificate isn’t the right fix.
v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. For issues involving features such as REALITY, first confirm that the client and core support the node’s configuration; switching interfaces won’t add protocol support. On desktop, see the client comparison to understand where v2rayN fits, then check the core and version currently in use.
Retest the Real Connection Delay and Actual Access
After making changes, retest the node before testing an app. If TCPing succeeds but the real connection delay test fails, the issue may still be in TLS, proxy authentication, or access to the test target. The result also depends on the test address and routing rules, so one latency number can’t confirm that every app will work.
- Keep a copy of the original node or note its key settings. Fix the clock and test once; if the domain error remains, check SNI next. Avoid changing too many settings at once.
- Run a real connection delay test for the current node and check the log entry with the same timestamp. See the real connection delay test guide for instructions.
- Use the system proxy guide to confirm that the app is actually using the proxy. System proxy and TUN mode cover different traffic, so a browser failure doesn’t necessarily mean the core failed to start.
- Visit an allowed HTTPS destination and check the egress details. If only one destination fails, check routing rules and that destination’s certificate instead of immediately changing the node’s SNI again.
- When reporting an issue, include the exact error, when it occurred, your system version, client and core versions, and the checks you’ve completed. Hide subscription tokens, user IDs, and full node credentials.
TLS Handshake Troubleshooting FAQ
My computer’s clock looks right. Why does the certificate still appear expired?
Compare the absolute time in the log with the certificate’s validity period, accounting for UTC display differences. If the system time is correct, the server certificate may have expired or an endpoint may still be using an old certificate. The provider needs to check it; the client can’t extend a certificate’s validity.
The node address is an IP. Does SNI have to be an IP too?
No. The connection address can be an IP while the server name is a domain specified by the provider. If the certificate identity is validated against an IP, the certificate must include that IP address. Don’t clear SNI on your own based on the address alone.
It broke again after updating the subscription. Should I keep changing the settings?
First check whether the updated entry’s SNI, transport, or port changed. If the subscription keeps supplying incorrect fields, send the provider the differences before and after your changes. Use the subscription group guide to make sure you updated the right group.
The same node works on my phone but not on my computer. What should I check first?
Compare the system time, node settings, and core version on both devices, then retest them on the same network. If only the computer reports an unknown certificate authority, check its system trust store and any HTTPS inspection settings in security software. Don’t disable certificate verification.