Use this guide if v2rayNG has imported a node but times out, fails a real connection test, or cannot load websites. Keep the original configuration, compare the same node across networks, then check the clock, subscription, transport, and certificate. Finally, verify the server listener and logs. Change one setting at a time so an unreachable port, authentication failure, and DNS issue don’t get mixed up.
1. Identify where the connection fails
v2rayNG is an Android client. This guide covers configurations that use the Xray core. The connection icon means the local service has started; it doesn’t confirm a successful handshake with the remote node. A TCP test, a real connection test, and loading a webpage each check a different layer and are not interchangeable.
Select the node on the main screen, start the service, then open Log from the menu. Reproduce the failure once and note the time. Menu labels may vary by version; the test option is usually in the main-screen menu. When saving an error, include a few lines before and after it, but hide subscription URLs, user IDs, and passwords.
| Result | What it tells you | Next step |
|---|---|---|
| TCP test failed | The destination address and TCP port are currently unreachable; this test does not apply to UDP-only transport. | Check the network, DNS resolution, and port |
| TCP succeeded, real connection failed | The port responded, but the proxy handshake or test request did not complete. | Check the protocol, TLS, and transport settings |
| Real connection succeeded, but one app failed | The test destination is reachable, but that doesn’t mean every app is using the proxy. | Check per-app proxy settings, routing, and the app itself |
| Subscription update failed | The request to fetch subscription data failed. | Troubleshoot the subscription URL separately; this does not prove the nodes are unusable. |
2. Local network: compare Wi-Fi and mobile data with the same node
Stop v2rayNG first and make sure your browser can reach websites that normally work without a proxy. Public Wi-Fi may require you to sign in on a system pop-up page; the proxy usually won’t connect until you do. Then keep the node and its settings unchanged and try starting the service on Wi-Fi and mobile data.
- Fails only on Wi-Fi: Check the router’s internet connection, any sign-in page, and DNS on that network. If mobile data works, don’t change the node’s UUID, password, or transport path yet.
- Fails on both networks: Try a known-working node for comparison. If all nodes fail, check the local VPN state, clock, and DNS first. If only one node fails, continue checking that node’s settings.
- Stops immediately after starting: Check for an Android VPN permission prompt and stop other services using the system VPN slot. A startup failure is different from a remote connection timeout.
- Disconnects only after the screen locks: In Android Settings → Apps → v2rayNG, allow background activity in the battery options. The exact menu path varies by device manufacturer, so follow the options shown on your device.
Also check Settings → Network & internet → VPN for Always-on VPN and Block connections without VPN. A leftover VPN configuration may block even direct requests used for comparison. Restore your original security settings after testing; don’t leave essential protections disabled just to troubleshoot.
3. Clock and subscription: rule out expired settings first
In Android Settings → System → Date & time, enable automatic time and time zone. On some devices, these options are under More settings. Check that the date and time are correct, then stop and restart v2rayNG. An incorrect clock can affect certificate validity checks and cause VMess authentication to fail.
A subscription link opening successfully doesn’t mean its nodes are still valid. Sign in to your subscription provider’s dashboard and check the expiration date, data allowance, and node change notices. In v2rayNG, verify the source URL under Subscription group settings, then return to the main screen and update the subscription. Depending on the version, the command may be labeled Update subscription or Update current group subscription.
- Keep a record of the existing settings before updating. Afterward, select the node again so you don’t keep testing an old entry that has been replaced.
- If the subscription request itself requires a proxy, update it through another node that you know works. Using a failed node to update the same source can create a loop.
- Check that the imported result includes the server address, port, protocol, and authentication settings. A link that leads to a sign-in or error page is not valid subscription data.
- Don’t paste a full subscription URL into an unfamiliar online converter. These links often contain access credentials, so treat them as sensitive during troubleshooting too.
4. Transport settings: check the address, port, Host, and path separately
Tap the edit icon for the target node in the list and compare each setting with the original parameters from the server or provider. A transport label in the node name doesn’t guarantee that the edit screen has matching settings. The server address determines where to connect; the port determines which endpoint to use; the transport type determines how the connection is established afterward.
These are standard protocol port facts, not recommended settings. If the node uses a different port, changing only the client to 443 won’t work; the server listener, firewall, and forwarding endpoint must also be configured for it. DNS resolving to an address does not prove the node’s port is reachable.
- WebSocket: Check the transport type, Host, and path. Match the path exactly to the server requirements, including capitalization, leading slash, and query parameters. Incorrect reverse-proxy forwarding can also cause a handshake failure.
- gRPC: Check the service name and any related options required by the provider. Don’t enter a WebSocket path in the service name field.
- Protocol authentication: Make sure the VMess and VLESS user IDs, or the Trojan and Shadowsocks passwords, match the server settings. Changing the transport type won’t fix incorrect credentials.
- DNS resolution: If the logs show that the node’s hostname failed to resolve, check the local DNS path first. If you temporarily test with an IP confirmed by the server, keep the correct TLS server name.
In short: check handshake settings after confirming TCP reachability
If the same address and port cannot establish a TCP connection on either network, check the listener and network path first. If TCP succeeds but the proxy request fails, check authentication, transport, and TLS one at a time. Don’t change DNS, the port, and the path all at once.
5. TLS and logs: pinpoint the stage from the error
The TLS server name usually sets SNI and is used for certificate name verification. It is not the same as the WebSocket Host and may not match the address used to connect. They can be identical, but don’t substitute one for another just because the names look similar. For REALITY nodes, also check the public key, short ID, and server name provided by the server; don’t change them as if this were a standard TLS node.
Error: i/o timeout
What it means and what to do: A network read or write exceeded its timeout. This line alone doesn’t identify the failing layer. Check the destination address and operation in the preceding log lines, then compare results across networks with the server logs from the same time.
Error: connection refused
What it means and what to do: The destination host or an intermediary actively refused the connection. Check the port, confirm the server process is listening, and look for rules that reject connections.
Error: no such host
What it means and what to do: DNS resolution returned no usable result. Confirm whether the hostname in the error is the node or the destination you’re trying to reach, then check its spelling, DNS settings, and DNS records.
Error: x509: certificate has expired or is not yet valid
What it means and what to do: The certificate’s validity period doesn’t match the current time. Correct your phone’s clock first. If the error persists, ask the server administrator to check the certificate renewal and which certificate is actually loaded.
Error: websocket: bad handshake
What it means and what to do: The server didn’t return the expected WebSocket upgrade response. Check the path, Host, and reverse-proxy forwarding rules, and investigate the response status code.
6. Server checks: listener, firewall rules, and forwarding path
If someone else provides the node, send the maintainer the failure time, network type, client version, and a redacted error message. If you manage the server, check its running status first, then the host firewall, cloud security group, container port mapping, and reverse proxy. A client timeout may leave no server application log: if traffic never reaches the process, the application has nothing to record.
The commands below are read-only checks for a Linux server. First list the service units actually in use. Run the last two commands only after confirming the deployment uses a systemd service named xray. For a container-based deployment or a different service name, check the corresponding process and container logs.
ss -lntp
ss -lnup
systemctl list-units --type=service --all
systemctl status xray --no-pager
journalctl -u xray --since "10 minutes ago" --no-pager- Check the actual listening address and port. A backend listening only on
127.0.0.1can be normal if a reverse proxy on the same host connects to it. If the client connects directly to that backend, there must be a matching public endpoint. - Check the cloud security group and host firewall at each layer. Allow rules must match the actual protocol and destination port; don’t rely on the rule name alone.
- Check the domain’s A and AAAA records. If they point to an old address or an IPv6 endpoint that isn’t configured correctly, fix the relevant record or network instead of repeatedly reinstalling the client.
- Run a test from your phone while watching the logs at the entry point and backend. If the entry point receives a request but the backend doesn’t, focus on the reverse proxy. If the backend receives it but authentication fails, check the user credentials.
7. Common questions and final checks
Why can’t I load webpages if the latency looks normal?
First check whether the number comes from a TCP test or a real connection test. TCP only confirms that the port responded; a real connection test checks only its specified destination. After starting the service, check the browser request logs, then make sure per-app proxy settings haven’t excluded the browser and routing sends the request through the expected outbound connection.
My subscription update keeps timing out. Should I delete all nodes?
Keep the existing settings and check the subscription URL and expiration date first. If the subscription can’t be fetched directly, try updating through another working node. If the provider changed the URL, update that group only. Deleting all nodes won’t make an unreachable subscription server available.
Why does the same node work on my computer but not on my phone?
Connect both devices to the same network, then compare the server address, port, transport, SNI, and authentication settings in v2rayN and v2rayNG. Make sure both are testing the same configuration, not old nodes with the same name, and note the core version on each device. Handle configuration compatibility issues based on the specific error.
Will increasing the connection timeout fix it?
Increasing the timeout may help only when the connection can complete the handshake but takes longer than expected. It won’t fix a server that isn’t listening, a certificate error, or mismatched credentials. Use the logs to identify the failing stage first; a longer wait is not a fix.
Keep a troubleshooting record with the client and core versions, test time, network type, whether the node was updated, the first error, and every change you made. Revert changes that didn’t help, then test again. This gives the maintainer enough information to diagnose the issue and saves you from starting over next time. For more on basic connectivity and routing, see Troubleshooting and Advanced Setup.