This guide addresses a common question: how to configure a WS TLS node. If you have a V2Ray/VLESS/VMess WS+TLS node or subscription, learn how to import it correctly into your client and troubleshoot connection failures or websites that won’t load due to IP, DNS, or browser settings.
1. What information does a WS TLS node need?
WS TLS typically means that the transport layer uses WebSocket, with TLS encryption enabled on top. You don’t need to understand the underlying details, but make sure all the required information is present when importing a node: server address, port, UUID or user ID, the ws transport protocol, whether TLS is enabled, Host, Path, SNI, and so on. Many connection failures aren’t caused by an inactive node, but by an incorrect Host, Path, or SNI, or by TLS being disabled in the client.
If you’re using a free node listed on this site, we recommend importing the subscription link or full share link rather than entering the details manually. Manual configuration is useful when the node details are clear and you need to change DNS or routing rules.
2. Importing nodes into Clash / V2RayN / sing-box
- Clash clients: Open configuration or subscription management, paste the subscription link, and click Update. For a single node, import the YAML and make sure network is set to ws, tls to true, and the path and Host under ws-opts are correct.
- V2RayN: Copy a vmess://, vless://, or trojan:// share link, then click “Import from clipboard.” After importing, double-click the node and check that the transport protocol is ws, TLS is enabled, and SNI/Host/Path match the node’s details.
- sing-box: Using a subscription that supports sing-box is the easiest option. If converting the configuration manually, check that transport.type in outbounds is set to ws, tls.enabled is true, and server_name is correct.
After importing, test the node in Rule mode or Global mode. If it connects but some websites won’t load, adjust your routing rules instead of immediately assuming the node is unavailable.
3. How IP, DNS, and browser settings affect the connection
WS TLS nodes can be sensitive to network conditions. First, check your IP: some home broadband, campus, or corporate networks may interfere with certain ports or domain lookups, so try connecting through a mobile hotspot. Next, check DNS: DNS poisoning can resolve a domain to the wrong IP, causing client timeouts, TLS handshake failures, or unexpected redirects. You can enable remote DNS in your client or change your system DNS to a trusted public DNS service.
Your browser environment can also affect your diagnosis. Browser cache, proxy extensions, DoH, and privacy extensions may override the system proxy. For testing, disable other proxy extensions, open an incognito window, and visit an IP lookup site to check whether your exit IP has changed. If the client shows that it’s connected but the browser still shows your local IP, the browser probably isn’t using the system proxy, or Clash isn’t properly handling the browser’s traffic.
4. Quick checklist for troubleshooting connection failures
- Make sure your system clock is accurate. A clock that’s off can cause TLS certificate validation to fail.
- Check whether the node has expired and whether the subscription update completed successfully.
- Verify the port, UUID, encryption method, WS Path, Host, and SNI.
- Switch to Global mode to rule out routing rule issues.
- Change your DNS server or network to check for local network restrictions.
- Check the client logs, especially for messages such as timeout, tls handshake, or bad request.
If the logs show 404 or bad request, the Path or Host is usually incorrect. For handshake failure, first check TLS, SNI, and your system clock. If the connection keeps timing out, the IP, port, or local network may be blocked. Following these steps should help you identify the main issues with WS TLS node configuration.