V2Ray TLS Handshake Failed? Fix Certificate Errors in v2rayN

1. Read the full log and identify where the connection fails

“TLS handshake failed” describes a failure, not its cause. A typical connection first resolves the server address and establishes a TCP connection, then negotiates TLS and verifies the certificate. Only after that do the proxy protocol and higher-level transport come into play. VMess and VLESS are proxy protocols; their names alone say nothing about whether a certificate is valid.

Check the log panel in the v2rayN main window. If needed, go to “Settings” → “Parameter Settings,” find the core log level, and temporarily set it to info. The location and label may vary by version. In v2rayNG and v2flyNG, check core output on the log screen in the app menu. Clear old logs, retry a single node, and record the error from that attempt so unrelated connection failures aren’t mixed in.

Log entries such as i/o timeout, connection refused, or EOF don’t by themselves prove there’s a certificate problem. For the first two, check network reachability and whether the service is listening. An EOF means the connection ended early; use the server logs to investigate further. Before sharing logs, redact subscription links, user identifiers, and access tokens.

2. Incorrect system time: sync the clock before checking certificate expiry

Certificates have a start date and an expiration date. A system clock that’s off by a year can put the current date outside that validity period. Even a difference of a few minutes can cause verification to fail when a certificate has just been issued or is about to expire. A displayed time zone mismatch doesn’t necessarily mean the clock is wrong: check whether the device’s actual time is accurate, not just the time zone label.

1. Windows: Open “Settings” → “Time & language” → “Date & time,” turn on automatic time, and select “Sync now.” Check the date, year, and time zone, then restart the client core.
2. macOS: Open “System Settings” → “General” → “Date & Time” and turn on automatic date and time. Check the clock again after waking the device from an extended sleep.
3. Android: Search Settings for “Date & time,” then turn on automatic time and automatic time zone. Make sure the network is available, then return to v2rayNG or v2flyNG and retry the same node.
4. Linux: Run timedatectl status to check clock synchronization. On systemd-based systems, enable network time synchronization with sudo timedatectl set-ntp true.

On Windows, you can check synchronization status in a terminal. Run the second command as an administrator. If synchronization fails, follow the system’s prompts to check the time service and network rather than repeatedly changing node settings.

w32tm /query /status
w32tm /resync

These are commonly used protocol ports; your node isn’t necessarily configured to use any of them. Blocking UDP 123 can affect traditional NTP synchronization, but that doesn’t mean the proxy port is blocked. If the system clock is accurate and the log still reports an expired certificate, the server needs to renew and reload it. Changing the local date won’t solve the problem.

3. Check SNI, server address, and Host separately

SNI is the server name sent during the TLS handshake, allowing a service to select the right certificate when multiple sites share an address. In the v2rayN node editor, “SNI” or “Server Name” usually corresponds to serverName in the core’s TLS settings. The client also uses the configured server name to verify the certificate’s identity, so don’t enter an arbitrary domain just because it looks like a working website.

Routes requests to the corresponding backend through the reverse proxy.

• Enter a hostname only for SNI, such as example.com. Do not include https://, a port, a slash, or spaces.
• *.example.com usually covers a.example.com, but not example.com or a.b.example.com.
• A subscription's “disguise domain” field may refer to Host or SNI. Check what the field is for; don't assume every field labeled “domain” should use the same value.

Bottom line: If the certificate name doesn’t match, fix SNI before changing DNS

If the log says the certificate received doesn’t match the expected name, the connection has reached a TLS service. Check SNI, the destination address, and the certificate SAN first. Check DNS results only if you suspect the address resolved to the wrong service.

1. Check how widespread the issue is: If the same node reports an unknown issuer on multiple devices with accurate clocks, ask the maintainer to check the deployed certificate and intermediate certificates.
2. Compare affected devices: If only older systems fail, check for system updates and trusted root certificates, and note the client and actual core versions in use.
3. Check how many devices are affected: If the same node reports an unknown issuer on several devices with accurate clocks, ask the maintainer to check the deployed certificate and intermediate certificates.
4. Compare devices: If only older systems fail, check for system updates and the state of the trusted root certificates. Also note the client and core versions in use.

If you have access to a command line, use OpenSSL to inspect the certificate returned by the server. The reserved example domain below illustrates the command syntax only. For troubleshooting, replace the two domains with the node's connection address and expected SNI, and use the node's port.

openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_hostname example.com -verify_return_error

-servername sends SNI, while -verify_hostname specifies the name to verify; they serve different purposes. This command may use a different trust store from the client core. If OpenSSL is not configured with trusted CAs, an error does not by itself prove a server problem. Record the certificate's SAN, validity period, and chain; don't capture only the last line.

5. Certificate verification: Keep it enabled and fix the configuration

“Allow insecure” and “skip certificate verification” generally correspond to allowInsecure. Enabling this may stop the client from rejecting untrusted or name-mismatched certificates, but it does not fix the certificate—it bypasses normal verification of the server's identity. It also won't fix TCP timeouts, an incorrect port, a wrong WebSocket path, or proxy authentication failures.

The example below shows part of the streamSettings for a standard TLS outbound. It is not a complete, importable configuration and does not apply to REALITY. example.com illustrates how the fields relate; use values from the server configuration, not the example domain, to connect to a node.

{
  "streamSettings": {
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.com",
      "allowInsecure": false
    }
  }
}

• Save the changes, restart the core, and confirm it loaded the updated configuration.
• If the log still shows the old domain, check the selected node and subscription group, and make sure you edited the configuration currently in use.
• After saving, restart the core and confirm it has loaded the new configuration.

If the log still shows the old domain, check the selected node, subscription group, and whether you edited the configuration currently in use.

Don’t edit a temporary generated file and expect the change to stick. The client may regenerate it the next time it starts or updates the node.

Error: remote error: tls: handshake failure

• Cause and fix: The remote server aborted the TLS negotiation. Possible causes include its SNI policy, protocol compatibility, or server authentication requirements. This client log line alone isn’t enough to identify the cause. Compare it with the server’s handshake logs rather than assuming the local certificate store is at fault.
• Node details: Connection address type, port, TLS type, SNI, and transport type. Redact user IDs and subscription credentials.
• Local details: Operating system, client version, core name and version, and system time synchronization status.
• Node details: Address type, port, TLS type, SNI, and transport type. Redact user IDs and subscription credentials.

7. FAQs: Choose the next step based on the error