Connected but No Internet: A Step-by-Step Troubleshooting Checklist for v2rayN and v2rayNG

First, identify what “Connected” actually means

A client showing that it is running does not mean the remote node has completed a usable data exchange. After v2rayN starts the Xray or V2Fly core, this only confirms that the local process is running and the configuration passed basic parsing. In v2rayNG, a key icon at the top or an Android VPN connection likewise only confirms that Android’s traffic interception service has been established. Whether the remote address resolves, the port is reachable, and the protocol parameters match still requires a real connection test.

A web request passes through the application, local proxy entry, routing rules, proxy outbound, and remote response in sequence. Failure at any point can look like a browser loading forever, an immediate connection reset, or only certain websites being unavailable. Do not change DNS just because the client tray icon changed color, and do not keep switching routing modes before confirming that the node works.

Step 1: Verify node availability and system time

In the v2rayN node list, select the current node and run a real connection latency test first. A regular Ping only checks whether the host responds to ICMP; it does not prove that a VMess, VLESS, or other proxy connection can complete its handshake. A real connection test establishes an outbound connection through the active core, making it a better first filter. If several nodes in the same subscription all time out, update the subscription first, then cross-test two nodes with different addresses and ports.

Record the exact results during testing. For example, if node A returns a real connection latency of 186 ms three times in a row while node B times out above 5,000 ms each time, use node A for the remaining checks. High latency does not always make a node unusable, but repeated timeouts, refused connections, or immediate handshake failures usually cannot be fixed by changing browser settings.

1. In the v2rayN main window, select a node and run the real connection latency test; do not substitute Ping results.
2. Switch between at least two subscription nodes and wait for each test to finish. Avoid starting too many connections in parallel.
3. Open the runtime log and confirm that a new outbound entry appears during the test rather than an old result being reused.
4. In v2rayNG, tap the test option for the current configuration, then switch to another node and repeat once.
5. If every test fails over Wi-Fi, try another working network to distinguish a node issue from restrictions on the current network.

Clock drift can also affect connections that require time validation. In Windows, open Settings → Time & language → Date & time, enable automatic time setting, and sync immediately. On Android, open the system date and time settings and enable network-provided time. If the device clock differs from the standard time by several minutes, correct it, then fully stop and restart the client core.

Step 2: Locate DNS resolution failures

If the node test succeeds but a page waits indefinitely after you enter a domain, DNS is the next thing to check. DNS converts domain names into reachable addresses; a working proxy outbound does not guarantee that the combination of local DNS, core DNS, and the system’s private DNS is correct. This is especially common after importing a custom configuration, changing split-routing rules, or enabling encrypted DNS, when lookups may be sent through an unsuitable route for the current network.

In v2rayN 7.x, open Settings → Parameters to review the basic settings and DNS options. If you use a custom DNS configuration, save the original content first, then restore the client defaults for comparison. Restart the core after making changes; closing a browser tab is not enough to make the core reload its configuration. In Windows, you can also run the built-in query command in a terminal to see whether the system can resolve the name.

nslookup example.com
ipconfig /flushdns

nslookup returning an address only proves that the system lookup path produced a result; it does not mean the core uses the same DNS. If the system lookup succeeds while the v2rayN log continually reports DNS failures, check the core DNS configuration and routing rules. If the system lookup itself times out, restore the network adapter’s DNS to automatic, clear the cache, and test again.

Step 3: Use global proxy mode to rule out routing mistakes

Routing rules decide whether a request goes through the proxy, connects directly, or is blocked. If custom rules match a domain, IP range, port, or inbound tag incorrectly, the node itself may work while a particular website or app remains inaccessible. Rules are usually evaluated in a defined order; an overly broad direct rule can intercept a request before a later proxy rule gets a chance to match.

The most direct diagnostic is not to delete the rules immediately, but to switch temporarily to global proxy mode and open the same domain. If global mode works while the original routing mode fails, the problem is likely within the split-routing configuration. Restore the original mode after testing and inspect each custom rule’s match target and outbound action.

VMess and VLESS are node connection protocols, while routing rules decide which requests are handed to that node. They are separate layers. Changing protocol parameters cannot fix an incorrect direct rule; conversely, switching to global proxy mode cannot fix an incorrect user ID, transport parameters, or server port.

Step 4: Check the v2rayN system proxy and local ports

On Windows, macOS, and Linux desktops, whether an app enters the proxy chain depends on whether it reads the system proxy, has its own proxy configured, and whether TUN is enabled. While the v2rayN core is running, it usually listens on a local SOCKS or HTTP entry. If the system proxy does not point to the actual listening port, the browser may connect directly or fail completely because it is pointing to an old port.

In v2rayN, open Settings → Parameters and check the local SOCKS, HTTP, or mixed entry port. A common setup uses 127.0.0.1:10808 for SOCKS and may use 127.0.0.1:10809 for HTTP, but use the values shown in the current interface. Then choose the automatic system proxy configuration option from the tray menu and confirm that the system proxy address matches the client’s current port.

• Check 127.0.0.1 first for the local address; never enter the remote node address as the system proxy.
• After changing a port, restart the core and apply the system proxy settings again.
• If the browser has a manual proxy configured, confirm that the protocol and port match, or temporarily switch it to use the system proxy.
• Command-line programs do not necessarily read the desktop system proxy. Check the proxy environment variables or configuration options supported by the program.
• If another process is already using the port, the core may fail to start or be unable to create the corresponding inbound.

Step 5: Check v2rayNG VPN interception and app scope

On Android, v2rayNG normally captures traffic through the system VPN interface. After the connection indicator appears in the status bar, confirm that the system allows the service to run and check per-app proxying, LAN bypass, routing mode, and battery-management settings. If only one app fails while the browser works, the problem is usually not the node itself but the per-app selection or the app’s own network policy.

First confirm the local port and routing options in v2rayNG settings, then check whether per-app proxying is enabled. With “Proxy only selected apps” enabled, the target app must be in the list; with the inverse exclusion logic enabled, it must not be on the exclusion list. After changing the scope, disconnect, wait a few seconds, and reconnect so the system can rebuild the VPN routes.

When v2flyNG uses the V2Fly core, it follows similar Android traffic-interception logic, but its core support range and log output may differ. Do not apply an Xray-specific v2rayNG configuration unchanged to v2flyNG. If the subscription contains parameters that depend on a particular core, choose a client and core that match the node’s requirements.

Retest in a fixed order and read the logs

After each individual check, retest under the same conditions: the same network, node, domain, and browser. If you change the test target every time, even a recovered page will not reveal the actual cause. Keep the log window open and observe from core startup instead of capturing only the final red error.

Read the log in chronological order. First check whether the local entry received the request, then see which outbound the routing selected, and finally determine whether the failure occurred during resolution, connection, handshake, or the remote response. A single timeout only means that an operation exceeded its deadline; the destination address, outbound tag, and DNS details in the surrounding lines determine what to do next.

1. Disable the system proxy or disconnect the Android VPN and confirm that the device itself can access ordinary pages over the basic network.
2. Correct the system time, update the subscription, and select a node that passes the real connection test.
3. After starting the core, check the log for configuration parsing failures or local port conflicts.
4. Temporarily use global proxy mode to test the same domain and rule out custom routing rules.
5. Restore the default DNS for comparison, restart the core, and clear the browser or system DNS cache.
6. Reapply the system proxy on desktop and verify 127.0.0.1 and the actual listening port.
7. On Android, establish the VPN again and verify the per-app scope, Private DNS, and background-execution permissions.
8. After confirming that access is restored, revert personalized settings one at a time and retest after each change.