For users seeing certificate verification failures in v2rayN, v2rayNG, or v2flyNG logs. Start with the underlying error, then sync your system clock, check the TLS SNI and certificate name, and verify the server’s certificate chain. Keep certificate verification enabled, change one setting at a time, and don’t mistake a temporary connection for a fix.
Read the logs first: distinguish certificate errors from timeouts
A node that won’t connect doesn’t necessarily have a TLS problem. The TLS handshake happens after the underlying connection is established and before proxy protocol data is sent. Follow the certificate troubleshooting steps only when the logs show x509, certificate, or a specific handshake error. context deadline exceeded on its own means the request timed out; it doesn’t indicate an expired certificate.
In v2rayN, check the log area at the bottom of the main window. If your version has a separate log screen, open “Logs” and reconnect. In v2rayNG, open “Logs” from the side menu, stop the service, then start it again to find the latest entries. In v2flyNG, check the core logs for the current connection. Don’t mistake an earlier failure for the latest result. Log locations may vary by version, so use the interface you have.
- Note the client version, core type, connection time, and complete underlying error—not just the top-level “connection failed” message.
- Temporarily pause background browser requests, then try connecting again to avoid confusing interleaved errors.
- Before sharing logs, redact subscription links, authentication identifiers, and server addresses. Keep the error type, timestamp, and domain relationships in anonymized form.
Use the exact x509 error to guide your checks
Here are some common error messages. Full logs may include a core prefix, certificate name, or date, and wording can vary between core versions. Check the innermost cause. For validity errors in particular, compare the current time in the message with the certificate’s validity period; don’t request a node change just because you see “expired.”
Error: x509: certificate has expired or is not yet valid
Cause and fix: The client considers the certificate outside its validity period. Check the system clock first. If the error persists with the correct time, ask the server administrator to check the certificate’s start and expiration dates and confirm that the renewed certificate was deployed.
Error: x509: certificate signed by unknown authority
Cause and fix: The certificate chain can’t be traced to a trusted root. A missing intermediate certificate, private certificate, or system trust store issue may be responsible. Verify the certificate’s source and the complete server chain. On managed devices, also check whether the network replaces certificates.
Error: x509: cannot validate certificate for 192.0.2.1 because it doesn't contain any IP SANs
Cause and fix: The client is validating the certificate against an IP address, but the certificate has no matching IP SAN. The address shown is for documentation only. Use the TLS name covered by the certificate, as specified by the server administrator; don’t substitute an arbitrary domain.
Error: remote error: tls: handshake failure
Cause and fix: The remote server terminated the TLS handshake, which doesn’t necessarily mean local certificate verification failed. Check the SNI, port, TLS settings, and server requirements, then ask the administrator to compare the server logs from the same time.
If the logs say the certificate is valid for one name but not the current name, check the SNI and verification name first. If the error is just EOF or a connection reset, the service on that port may not accept the current handshake. Don’t assume the system clock is at fault.
Sync the system clock before diagnosing an expired certificate
Certificates have start and expiration dates. If the device’s clock falls outside that range, the certificate will be considered not yet valid or expired, even when the server is configured correctly. Switching between operating systems, a failing motherboard battery, long periods offline, and manually changing the date can all cause clock drift. Time zones mainly affect how the time is displayed; correcting the time zone alone doesn’t ensure the system clock shows the right time.
-
Check the date and time
Check the year, month, day, and hour first. In Windows PowerShell, run
Get-Date -Format oto see the full time, including the time zone offset, then compare it with a trusted clock. -
Sync the clock
On Windows 11, go to “Settings” → “Time & language” → “Date & time,” turn on “Set time automatically,” then select “Sync now” under “Additional settings.” If syncing fails, fix the network or time service issue first.
-
Check Android
On Android, the usual path is “Settings” → “System” → “Date & time.” Turn on “Set time automatically” and “Set time zone automatically.” Menu names vary by manufacturer, so search Settings for “date and time” and confirm that the displayed time has updated.
-
Reconnect
After syncing, stop and restart the client connection, then check the new logs. If the current time is correct and the certificate has actually expired, the server administrator needs to renew and reload it.
On Windows, you can also run w32tm /query /status to check the time source and sync status. If the command reports that the service isn’t running, check the Windows Time service instead of repeatedly restarting the proxy core. On devices managed by organizational policies, ask your administrator to fix the configured time source; don’t override management policies.
SNI and hostnames: check the address, TLS name, and Host separately
SNI is a TLS handshake extension that tells the server which hostname you’re connecting to, allowing it to choose a certificate or virtual host. The TLS server name is usually also used to verify the certificate name, but some cores allow a separate verification name, so check for an explicit override. “Fake domain” isn’t a consistently defined server setting. Confirm whether it refers to SNI, the HTTP Host header, or another transport parameter.
| Setting | What it does | What to check |
|---|---|---|
| Address and port | Selects the server endpoint to connect to. | The address can be a domain or IP. The port must match the server configuration; TLS doesn’t mean you should always change it to 443. |
| SNI / serverName | Usually sends the TLS name and is used to verify the certificate name. | Enter the domain specified by the server, without a scheme, path, or port. |
| Certificate SAN | Lists the DNS names or IP addresses the certificate is valid for. | The verification name must be covered. A wildcard such as *.example.com usually doesn’t cover example.com or deeper subdomains. |
| WebSocket Host | Routes HTTP requests sent after TLS is established. | Use the value specified by the transport configuration. Changing Host won’t fix a certificate name mismatch that occurred earlier in the connection. |
| WebSocket Path | Specifies the path for the HTTP upgrade request. | Use the path provided by the server. A wrong path usually isn’t a certificate verification issue. |
In v2rayN, double-click the node to open its editor, then check “SNI” or the equivalent server name field in the TLS section. In v2rayNG, tap the edit icon next to the node and check “SNI” in the TLS settings. Field names can vary by version; look in the TLS section, and don’t confuse “Host” under transport settings with SNI. In v2flyNG, use the field that matches the current core and node protocol.
For example, if the server specifies edge.example.com as the TLS name, don’t enter https://edge.example.com/ in this field. This domain is only an example of the correct format, not a working node setting. A server address can be an IP; as long as it’s the right destination and TLS uses an authorized name covered by the certificate, you don’t need to replace the address with that domain.
Bottom line: verify the TLS name before changing transport settings
When the logs clearly report a name mismatch, compare the server-provided SNI with the certificate SAN first. Check Host and the path only if certificate verification succeeds but HTTP or the upgrade still fails.
Keep certificate verification on: check the server chain and network
“Skip certificate verification” may appear as allowInsecure or a similar option. When enabled, the client may stop checking the certificate chain or name properly. That doesn’t confirm the server’s identity or fix the original configuration. Keep this option off while troubleshooting. If it was already enabled, turn verification back on and use the exact error that appears to identify the cause.
- Only one node is affected: Ask the server administrator to check the certificate’s validity period, complete intermediate chain, SNI-to-virtual-host mapping, and whether the renewed certificate has been reloaded.
- Several nodes fail at once: Check your device clock, system updates, and current network first. HTTPS inspection on company networks or by security software can alter the certificate trust path, but look for evidence before concluding that traffic is being intercepted.
- It works on another network: Check whether the original network requires web sign-in, whether DNS resolves to the expected endpoint, and whether network policies affect TLS. Don’t install a root certificate from an untrusted source just to connect.
- Private certificate: Configure trust according to your administrator’s instructions only when there’s a clear management requirement and the issuer and certificate source are verified. If you’re using a regular subscription, ask the provider to confirm the configuration first.
This guide covers standard TLS certificate verification. If the node uses REALITY, check the server-provided server name, public key, short ID, and client core compatibility. The standard certificate renewal steps don’t apply. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core; they don’t support exactly the same protocols and security parameters. Changing the client name alone doesn’t guarantee compatibility.
Verify the connection and troubleshoot common issues
Reconnect and check the new logs after every change. An existing connection may still be active, or a subscription update may overwrite manual settings, making results seem inconsistent. Don’t change the time, SNI, DNS, and routing all at once. Record each change and the new error so you can tell what made a difference.
Why does it still say the certificate is expired after syncing the clock?
Compare the current time in the error with the certificate’s expiration time. If your device clock is correct and the certificate really has expired, send the administrator the redacted error and timestamp. Ask them to check the renewal and the certificate currently in use.
Why does the domain open in my browser, but the client still reports an error?
The browser may connect to a different port or endpoint, or use a different trust store. Check the node address, port, and SNI. A homepage loading in your browser doesn’t prove that the proxy endpoint’s certificate is valid.
What if changing SNI works, but the connection fails again after a subscription update?
Edit the node again and check whether the subscription overwrote the field. Tell your provider that the subscription’s TLS settings need to be corrected. You can keep a separate test configuration for comparison, but use the corrected subscription going forward.
If disabling verification lets me connect, is the problem fixed?
No. Turn “Skip certificate verification” back off and fix the time, hostname, or trust chain based on the error. The certificate issue is resolved only when the connection succeeds with normal verification enabled.
- Confirm automatic time sync is working and the displayed date and time zone are correct.
- Confirm the node’s TLS name matches the server information and certificate verification is enabled.
- Stop and reconnect, then check that the new logs no longer show the same certificate error.
- If the connection still fails, provide the client and core versions, time of the error, checks performed, and redacted underlying error. Don’t send the full subscription.