This article explains how to configure a “WS TLS node”: from importing a subscription and checking settings to troubleshooting connection issues. It helps everyday users set up nodes correctly in their clients and explains how WS TLS relates to account stability in team environments. The examples use clients that support VLESS and VMess; setting up your own server is not covered.
1. Understand WS, TLS, and node protocols
WS is a WebSocket transport, while TLS encrypts the connection. Neither is a standalone proxy protocol. Common combinations include VLESS + WS + TLS and VMess + WS + TLS. The node protocol, transport, and TLS setting must match the information provided by your provider. A standard TCP node cannot simply be changed to WS TLS.
Have your node link or subscription URL ready, or gather the server address, port, UUID, WS path, Host, SNI, and other settings. Host is the hostname used for the WebSocket handshake; SNI is the server name used in the TLS handshake. They may be the same or different, so enter them as specified by your provider.
2. Import using a subscription or link whenever possible
- Install a version suited to your operating system from the client’s official source. For example, use v2rayN on Windows or v2rayNG on Android. Make sure the current version supports the node protocol.
- Copy the subscription URL. In the client, add a subscription under “Subscription Settings” or “Subscription Groups,” paste the URL, save it, and update the subscription. If you only have a single node link, use “Import from Clipboard.”
- Open the imported node’s edit page and check that the protocol, server, and port are present. The transport should be set to ws, and TLS should be enabled.
- Select the node and enable the system proxy or the client’s VPN mode. Test websites in rule mode first. If you need to route more apps through the proxy, use TUN mode as described in the client’s documentation.
- Verify the connection by visiting a website you normally use, and check the client logs. A successful latency test does not mean every app will work; open the service you want to use to confirm.
Free nodes from this site can be imported in the same way, but availability may change. Treat subscription links as sensitive information and do not post them in public group chats.
3. Check these fields carefully when configuring a node manually
When creating a node, first select the correct protocol, then enter the server address, port, and UUID. For VMess, fill in any additional fields as specified by your provider. Set the transport to ws. The WS path must include its initial slash, for example, /example. Do not change capitalization or any trailing parameters without a reason. Enter the Host, SNI, and TLS settings as provided.
The server address, Host, and SNI are not necessarily the same value. Do not replace them all with one value just to make them “match.” TLS certificate verification should generally remain enabled. Do not use “Skip certificate verification” to mask a configuration error. If there are additional settings such as a fingerprint or ALPN, keep the imported values where possible, and ask your provider if you are unsure.
4. Troubleshoot connection issues and team usage
If the connection times out, check your local network, whether the node is still active, and whether the port is correct. If you see a certificate error, check your system time, SNI, and certificate verification settings. If the WebSocket handshake fails, focus on the path, Host, and transport type. If the problem persists after updating the subscription, test another node for comparison. Avoid changing multiple fields at once.
For team use, standardize the client version and rule settings, and record the node name, time of changes, and symptoms to make issues easier to reproduce. WS TLS only affects the connection method; it does not guarantee a fixed exit IP or protect an account from triggering risk controls. Account stability also depends on changes in login location, devices, cookies, simultaneous use by multiple people, and platform policies. Avoid unnecessary changes to the exit IP, use team member permissions and multi-factor authentication allowed by the platform, and do not share passwords or treat a node as a guarantee that platform restrictions can be bypassed.