For new users who have installed a client but can’t yet connect reliably. First check that your subscription imported correctly, then verify the local listener, system proxy, node handshake, and DNS. Desktop steps use v2rayN as an example; on Android with v2rayNG or v2flyNG, use the app’s VPN connection option instead of the system proxy. Change one thing at a time and retest with the same address.
1. Subscription Update Failed: What Should You Check First?
First, distinguish between a failed subscription download and a subscription that downloaded successfully but contains nodes that won’t connect. A subscription URL is used to download node configurations; it isn’t a node address to enter in a server field. If an update times out, first check that your computer has internet access and that the subscription URL is complete. Don’t start by changing VMess or VLESS settings.
In v2rayN, open “Subscription Group” → “Subscription Group Settings” and check the address for the relevant group. When copying, make sure there are no leading or trailing spaces, quotation marks, or line breaks. Menu labels may vary slightly by version; use the “Subscription Group” and “Update Subscription” options shown in your client.
-
Check the URL
Make sure you copied the full subscription URL provided by your service, not the URL of your account page. The token in the link is a credential—don’t share it in public chats or screenshots.
-
Try without a proxy first
In “Subscription Group,” choose the update option that bypasses the proxy. Check the log to see whether the error is a timeout, an HTTP status error, or a parsing failure.
-
Then try through the proxy
Only use the proxied update option if you already have a working node. If the current node is down, updating through it will fail too.
-
Check your account
If you get a 401 or 403 response, check whether the subscription has expired, the token has been reset, or the service restricts access. Changing local ports repeatedly won’t fix an authorization issue.
2. Update Complete, but the Node List Is Empty—Why?
A successful request doesn’t guarantee valid content. The subscription endpoint may return a login page, an error message, or data the client can’t parse. Check the number of imported nodes in the log, then make sure the right group is selected in the main window. An empty group or active search filter can hide nodes that were imported successfully.
- Clear filters first: Switch to a view that shows all nodes, clear the search box, and check the group name.
- Check the import count: If the log shows 0 new nodes, verify the subscription format and client compatibility. Don’t rely on the “Update complete” message alone.
- Check the link type: A single
vmess://orvless://link should be added using the node import feature. Subscription groups store URLs used to fetch configurations. - Keep your existing configuration: Create a test group and import the subscription again. Don’t delete an old group that still works.
v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Whether a subscription can be parsed and its nodes can run depends on the client and core’s support for the specific protocol settings. Don’t assume a configuration that imports on desktop will work in another client just because of its file name.
3. What Does the Latency Test Measure? Is Lower Always Better?
Start by checking what kind of test was run. TCP latency mainly measures how long it takes to connect to the server’s port; it doesn’t confirm that proxy protocol authentication succeeded. A real connection test typically sends a request to a specified address through the proxy, covering more of the connection path—but it still doesn’t measure sustained download speed. Results from different test addresses aren’t directly comparable.
These figures are troubleshooting parameters, not measured node performance or default settings for every installation. For example, if one node shows 80 ms and another 160 ms under the same test conditions, that only means the first responded faster in this test. Video playback also depends on bandwidth, congestion, packet loss, and the destination site. Check whether results are consistent across multiple tests before comparing the lowest values.
How to compare: Verify connectivity first, then compare latency
Use the same test address and run three tests for each node you’re considering. Rule out nodes that consistently time out, then compare performance with real websites or downloads. Don’t assume a node works just because it ranks well on a single TCP latency test.
4. TCP Test Shows a Result, but the Connection Times Out. How Do You Read the Log?
A successful TCP connection to the server port doesn’t mean the UUID, transport path, TLS, or REALITY settings are correct. Select the node, set it as the active server, and open the client log before making another web request. Note the time of the request and focus on the first specific error, rather than repeated timeouts that follow.
Error: connection refused
Cause and fix: The connection was refused. Check the destination address in the log first. If it’s 127.0.0.1, check whether the local core is running. If it’s the remote node address, verify the server port and service status.
Error: i/o timeout
Cause and fix: A network operation took longer than the allowed wait time. Check the connection destination to determine whether the timeout occurred during DNS resolution, the remote connection, or the response. Then compare the result with a known working node.
Error: x509: certificate has expired or is not yet valid
Cause and fix: The certificate validity check failed. First sync your system date, time, and time zone. If the error persists after correcting the clock, the server administrator should check the certificate. Don’t disable certificate verification.
Log messages vary by core and version. For VLESS configurations, check the address, port, UUID, transport type, and security settings one by one. With REALITY, also verify the server-provided serverName, public key, shortId, and required flow. Don’t substitute fields from a standard TLS node for REALITY settings.
5. The Node Works, but Apps Bypass the Proxy. Why?
The system proxy only affects apps that honor the system proxy settings; it doesn’t automatically route all traffic. In v2rayN, the system proxy controls how apps connect to the local port, while routing rules determine which outbound route traffic takes after entering the core. Check both settings separately. Setting the route to “Global” doesn’t replace configuring the app’s proxy entry point.
| Where to check | What to do | What to look for |
|---|---|---|
| v2rayN system proxy menu | Select “Automatically configure system proxy” | The system proxy address should point to the local listening address and port |
| Windows proxy settings | Open “Settings” → “Network & internet” → “Proxy” | Check the manual proxy address, port, and bypass list |
| App settings | Check whether the app has its own proxy settings or ignores the system proxy | The app’s proxy entry must use a protocol supported by the client listener |
| v2rayN routing mode | Check which rule matches the destination domain and where it routes traffic | Make sure a direct-connection rule isn’t matching the destination before the intended proxy rule |
If only one app fails, troubleshoot that app first instead of changing all your nodes. Consider TUN if you need to route traffic from apps that don’t use the system proxy. TUN involves a virtual network adapter, routing, and DNS, so enable it only after you’ve verified the basic connection.
6. A Browser Can’t Open Websites. How Do You Tell a Proxy Problem from a DNS Problem?
Bypass browser extensions and custom proxy settings by specifying the local proxy directly in a command. The example below is for Windows and assumes the client provides an HTTP or mixed proxy at 127.0.0.1:10808. If your client uses a different port, replace it with the value shown in the client. The example URL is for connectivity testing only; it may not be reachable on every network.
curl.exe -I --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:10808 https://example.com/- Local connection failed: The request never reached the proxy. Check the listening port and whether the core is running.
- Received HTTP response headers: The request through the specified proxy got a response, but that doesn’t mean every website is reachable. Check the browser’s own proxy and secure DNS settings next.
- Timed out after establishing a proxy connection: Check the node, destination address, and routing rules in the core log. Don’t assume the browser cache is to blame.
- Log shows a DNS resolution error: Check the client’s DNS settings and whether its upstream servers are reachable. Determine whether the failed lookup is for the node’s domain or the destination website.
When troubleshooting with a SOCKS proxy, distinguish between local DNS resolution and resolution through the proxy. With curl, socks5:// usually resolves the destination domain locally, while socks5h:// sends the domain to the proxy for resolution. Different results can help identify the resolution path; changing DNS addresses at random won’t fix every problem.
7. Port Already in Use: Which Process Should You Stop?
Don’t terminate an unknown process just because a port is in use. First, in v2rayN, open “Settings” → “Parameter Settings” and confirm the local listening port, then identify what’s using it. This article uses 10808 as an example. Older configurations and other installations may use a different port, so check the current interface and startup log.
netstat -ano | findstr :10808
tasklist /FI "PID eq 1234"In the first command, look for the line containing LISTENING to confirm the local address and port; the rightmost column shows the process ID. In the second command, 1234 is just an example—replace it with the process ID you found. If another running instance of the client is using the port, exit the duplicate instance normally.
8–10. TUN, Disconnects, and Sharing Configurations
Once you’ve checked the subscription, listener, and node, move on to traffic routing and connection stability. Reinstalling repeatedly won’t fix the issues below. First confirm the current setup and keep a copy of the configuration so you can undo individual changes.
8. Do You Need TUN to Use the Client?
Not necessarily. If your browser follows the system proxy, start with that. Enable TUN from the v2rayN main window only if you need to route traffic from more apps, and grant the permissions requested by your system. If your connection drops after enabling it, turn TUN off to restore the previous setup, then check the virtual network adapter, routing conflicts, and DNS. On Android, v2rayNG and v2flyNG route traffic through the system VPN interface. Confirm the VPN permission the first time you connect; desktop system proxy instructions don’t apply.
9. It Works at First, Then Disconnects. What Should You Do?
First note whether the disconnect happens after sleep, switching Wi-Fi, or changing networks. Once your connection is back, test the same node again, then compare it with another. On Windows, check power and network status. On Android, if disconnects happen only when the screen is off, check the system’s battery optimization and background activity restrictions for the client. If all nodes fail at once, check the local network and core log first. If only one node fails, check the server status, data allowance, and connection limits.
10. Is It Safe to Share a Subscription Link for Troubleshooting?
Share error logs and settings screenshots with credentials hidden. Subscription links, node QR codes, and UUIDs may let others access or use your nodes, so never share them publicly. Keep the error time, core type, port, and original error message visible in screenshots, but hide subscription tokens, passwords, UUIDs, and account details. If a full subscription link has been exposed, reset it with your service provider and update the saved URL in your client.
Follow this troubleshooting order: internet connection works → subscription contains valid nodes → core starts and listens → active node connects → app reaches the local proxy → routing and DNS behave as expected. Retest after each step so you don’t lose track of the cause by changing ports, protocols, routing, and DNS all at once. If the problem persists, give the maintainer your operating system, client and core versions, the time of the issue, and redacted logs. That’s more useful than simply saying “it won’t connect.”