A node can show low latency and still fail when real traffic starts. If logs mention handshake failure, certificate verification, TLS alert, or unsupported protocol, the problem is likely in the TLS negotiation layer rather than raw network speed.
Quick answer
TLS provides the encrypted handshake, SNI tells the server which hostname the client wants, and ALPN negotiates the application protocol. In VPN and proxy clients, fields such as server name, host, path, security, transport, and ALPN must match the server side.
What TLS does
TLS verifies the server certificate, negotiates encryption parameters, and creates a secure channel. If the device clock is wrong, the certificate chain is missing, the certificate is expired, or the hostname does not match, the handshake may fail before any page loads.
Why SNI matters
SNI is the hostname sent during the TLS handshake. CDNs, reverse proxies, and multi-domain servers use SNI to select the correct certificate and backend. A wrong SNI value can make the server return a default certificate or reject the connection.
What ALPN changes
ALPN negotiates the application protocol, such as h2, http/1.1, or h3. Some proxy transports require a specific protocol. If the client and server disagree, the TLS layer may complete but the application layer will not work correctly.
Troubleshooting checklist
- Check the device date, time, and time zone.
- Verify that SNI, host, and serverName match the expected certificate domain.
- Confirm the transport type: TCP, WebSocket, gRPC, HTTP/2, QUIC, or another mode.
- Read the client log and separate DNS errors, TCP errors, TLS errors, and application errors.
- If a CDN is used, check port, TLS mode, origin protocol, and DNS records.
Why speed tests can be misleading
Some clients test only TCP reachability or a partial handshake. That does not prove that certificate validation, SNI, ALPN, routing rules, and DNS are all correct. This is why a node may look fast in a list but fail in real browsing. The same principle applies to node speed tests versus real performance.
When to replace the node
Replace the node only after confirming the local configuration. If several clients and networks produce the same TLS error with correct SNI, transport, and time settings, the server certificate, CDN configuration, or upstream service is more likely at fault.
FAQ
Can SNI be any domain?
No. It should match the certificate and server configuration expected by the node provider.
Does a certificate error always mean the node is unsafe?
No. Incorrect device time, old root certificates, or a mistyped hostname can cause the same error.
Should ALPN be left empty?
Some clients can auto-negotiate it, but protocol-specific setups may require an explicit ALPN value.