This article addresses common questions about configuring WS TLS nodes. It explains how to import a node into a client, verify the WebSocket and TLS settings, and distinguish connection issues caused by IP addresses, DNS, or the browser environment. It applies to WS+TLS nodes provided by a service, such as VLESS and VMess, and does not cover setting up your own server.
1. What information do you need before configuring a node?
WS is a WebSocket transport, while TLS encrypts the connection; neither is a standalone node protocol. First confirm whether the node uses VLESS or VMess, then gather the server address, port, user ID, WS path, Host, and TLS server name (SNI). Use the values supplied by the node provider; do not combine fields from different nodes.
We recommend installing a client that supports the relevant protocol from its official project source, such as v2rayN on Windows or v2rayNG on Android. For Clash-type clients, confirm that the core you use supports the protocol and that you have a compatible subscription format. Free nodes on this site should also be imported according to their accompanying instructions; their availability is not guaranteed long-term.
2. Import the node first, then check the key fields
- Copy the complete node link or subscription URL, then choose “Import from Clipboard” or “Add Subscription” in the client. After adding a subscription, update it and confirm that the node appears in the list.
- Open the node’s edit page and check the basic protocol, server address, port, and user ID. Even if the port is commonly 443, enter the value exactly as provided.
- Set the transport to WS or WebSocket. Enter the path supplied by the service, preserving the leading slash, capitalization, and query parameters. Do not change it to the homepage path.
- Enter the specified domain in the WS Host field. Enable TLS, then enter the specified name under SNI or “Server Name.” Host and SNI may be the same or different; do not guess or swap them.
- Keep certificate verification enabled, save the node, and select it. Start the client connection first, then enable the system proxy. On a phone, approve the VPN permission prompt if one appears.
Do not use “Skip Certificate Verification” as a routine fix. If you get a certificate error, first check the device time, SNI, and node details. If you cannot verify them, contact the provider or switch to another node.
3. How do the server IP, DNS, and browser relate?
The server address determines where the connection goes. SNI identifies the domain during the TLS handshake, while the WS Host is part of the WebSocket request. Changing the server domain directly to an IP address might bypass a DNS resolution issue, but it could also connect to the wrong endpoint. Do this only if the provider explicitly supports it, and keep the required SNI and Host values.
DNS resolves domain names to IP addresses. If the logs say a domain cannot be resolved, first check your local network and the client’s DNS settings, then adjust them according to the client documentation. Secure DNS in the browser may use a different resolution path from the system or client, but it cannot fix an incorrect WS path, user ID, or SNI.
4. Troubleshoot connection failures in order
- Cannot connect at all: Confirm that the subscription has not expired and the node is still active, then check the address and port. Test over both Wi-Fi and mobile data.
- TLS handshake or certificate error: Check the system time, SNI, and certificate verification message. Do not disable verification without a clear reason.
- WebSocket handshake failure or HTTP status code error: Check the WS path and Host first. If needed, reimport the original link.
- The client connects, but the browser cannot open websites: Confirm that the system proxy is enabled, check for conflicting browser proxy extensions, and use an incognito window to rule out cache or extension issues.
Change only one setting at a time, and note how the logs change. Browser language, time zone, and cookies may affect website verification and regional display, but they do not determine whether the node handshake succeeds. If you share a screenshot of an error, hide credentials such as the subscription URL and user ID.