Use this checklist if v2rayNG shows the VPN icon or v2rayN’s core is running, but websites still won’t load. Check your network and system clock first, then confirm that app traffic reaches the client. Next, test DNS, routing, and the node separately. Change one setting at a time and keep a log of a failed request—it’s more useful than repeatedly replacing the entire configuration.
1. A Running Client Doesn’t Mean Requests Are Working
The VPN icon in Android’s status bar means the system has created a local VPN interface; it doesn’t confirm that the remote node authenticated successfully. In v2rayN, a running core only means the local process has started. Websites also depend on app traffic being captured, DNS resolution, routing, the remote connection, and the destination site’s response.
Start with one consistent test: use the same browser to open the same full HTTPS URL. Choose another site you can normally reach as a comparison. Don’t change nodes, DNS, and browser settings all at once—or you won’t know which change fixed the problem.
| What you see | Check first | Next step |
|---|---|---|
| No apps can connect | Local network, VPN traffic capture, node exit | Stop the proxy and test your basic connection first |
| Only one browser fails | Browser proxy extensions, Secure DNS, per-app list | Try the same URL in another browser |
| Only some domains fail | DNS, domain rules, destination site restrictions | Check the failed request’s domain and outbound route |
| Node test succeeds, but websites still fail | The actual app traffic path | A test result doesn’t prove the entire connection works |
2. Check Your Network and System Clock
Disconnect v2rayNG, or in v2rayN open System Proxy and select Clear System Proxy. Temporarily turn off TUN too, if enabled. Clearing the system proxy doesn’t automatically stop TUN from capturing traffic. Open a site you normally use to confirm that Wi-Fi or mobile data works on its own.
-
Test your connection
Turn off the proxy and open a browser. If public Wi-Fi displays a sign-in page, complete network authentication first. If you still can’t connect, try mobile data before changing node settings.
-
Set the correct time
On Android, go to Settings → System → Date & time and enable automatic time. On Windows, go to Settings → Time & language → Date & time, enable automatic time, and sync. Menu names may vary by device manufacturer.
-
Reconnect
Return to the client, select the original node, and reconnect. An incorrect device clock can affect certificate validity checks or cause time-related VMess authentication to fail. Changing the displayed time zone won’t fix an incorrect system clock.
-
Record the results
Note the network type, node name, failed URL, and request time. Use the same URL for each test. After switching networks, reconnect so you don’t mistake a stale connection for a result on the new network.
3. Make Sure Browser Traffic Reaches the Client
v2rayNG needs Android’s VPN permission. If another tool is using the system VPN interface, stop it before starting v2rayNG. With v2rayN, distinguish between the system proxy and TUN: the system proxy only works for apps that follow system proxy settings, while terminal programs usually need a proxy specified separately.
In v2rayNG, open Settings → Per-app proxy from the side menu and check the toggle, app list, and mode. If Only proxy selected apps is enabled, make sure your browser is selected. In bypass mode, selected apps are excluded from the proxy instead. Mode labels may differ between versions, so follow the on-screen descriptions.
- Android check: Note the current app list, temporarily disable per-app proxy restrictions, reconnect, and try the same browser again.
- Windows check: In v2rayN, open System Proxy and select Automatically configure system proxy. Check whether a browser extension is forcing a direct connection or using an outdated port.
- Check the logs: Make a request and look for its domain or destination address. If access logging is disabled, the lack of an entry doesn’t prove traffic never reached the client. Temporarily increase the log detail and try again.
On desktop, you can also specify the local proxy explicitly to compare results without relying on the browser’s proxy settings. The ports below are examples, not fixed defaults across all versions. Check the client’s current listening ports and replace the example ports in the commands with the actual values.
# Windows terminal; replace the destination URL with the site where you’re reproducing the issue
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
curl.exe --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -I https://example.com/socks5h sends the destination hostname to the proxy for resolution. If an explicit proxy returns an HTTP status but the browser still fails, check browser and system proxy settings first. A 403 or 405 still means you received an HTTP response; it doesn’t mean you have permission to view the page. Some sites reject HEAD requests, so try again without -I.
4. Check Node DNS and Website DNS Separately
DNS involves two easily confused destinations: the node server and the website you want to visit. If the node address is a hostname, the client must resolve it to an IP address before it can connect. Sending all DNS requests through a proxy that hasn’t been established yet can create a dependency loop.
Another possibility is that the node connects successfully but the website’s hostname won’t resolve. The browser’s Secure DNS, Android Private DNS, and the client’s DNS rules may each use different resolution paths. On Android, check Settings → Network & internet → Private DNS. Some manufacturers place this under Connection & sharing.
- Record the original settings: Keep a note of custom DNS addresses and related rules. Don’t overwrite the entire configuration.
- Try a temporary comparison: If Private DNS uses a custom hostname, switch to Automatic temporarily, reconnect, and test again. Test the browser’s custom Secure DNS separately too.
- Identify which hostname failed: If the log shows a node hostname, fix its resolution first. If it shows a website hostname, check the DNS path used for website traffic.
- Avoid misleading tests: Don’t simply replace an HTTPS hostname with its IP address. Certificate names and virtual host matching can change the result.
Error: no such host
Cause and fix: The hostname couldn’t be resolved to a usable address. Check the specific hostname in the log for typos and DNS reachability. If it’s the node hostname, make sure resolution doesn’t depend on a proxy connection that hasn’t been established yet.
Error: connection refused
Cause and fix: The destination refused the connection. If the destination is 127.0.0.1, check the local listening port and core status. If it’s a remote node, check the port in your subscription and confirm the service is running.
Error: i/o timeout
Cause and fix: The operation didn’t complete before the timeout. This message alone doesn’t point to a DNS failure. Check the destination and the stage of the request, then test the network, DNS resolution, and remote connection separately.
5. Check Rule Order and Routing Matches
If only some sites fail, check which outbound route they actually use. V2Ray/Xray evaluates routing rules in order; once a rule matches, later rules generally don’t determine the connection. A broad direct-connection rule near the top can send sites that should use the proxy directly instead.
In v2rayNG, open Routing from the side menu and check the current rules and mode. In v2rayN, go to Settings → Routing and review the selected rule set. Mode names can vary by version; focus on the outbound route used by the test request, not just the mode label.
- Save the current routing configuration or take a screenshot of the selected mode so you can restore it.
- Temporarily use a test mode that sends regular website traffic through the proxy, while keeping necessary direct connections to your local network.
- Reconnect, then revisit the site that failed. This avoids stale connections affecting the test.
- If access works again, restore your custom rules and check domain, IP, outbound tags, and rule databases from top to bottom.
geosite:cn matches a domain collection, while geoip:private matches a private IP address collection. They aren’t interchangeable. When using rule databases, a missing file or invalid collection name can prevent loading; check the startup log. Also, don’t assume that a rule containing both domain and IP conditions matches when either condition is met.
If the test mode works, focus on the rules
If the same node on the same network can access the site only after changing routing modes, compare which rules match in each configuration. Repeatedly changing TLS or transport settings at this point usually makes troubleshooting harder.
6. Check the Node and Server Settings Last
If traffic reaches the client and DNS resolves successfully but the remote connection still fails, check the node itself. Update the subscription and make sure the selected entry hasn’t been replaced by an outdated configuration. Updating a subscription only retrieves settings—it doesn’t confirm that the server is online or that your account has available traffic.
- Server and port: Compare the settings with the provider’s current configuration. Don’t assume every node uses port 443 just because it’s common for websites.
- Protocol and authentication: The VMess or VLESS protocol and user ID must match the server. Changing only the protocol name while keeping unrelated settings won’t work.
- Transport and security: Check the WebSocket path, Host, and TLS server name. For REALITY, also check the corresponding settings, including the public key and shortId. Verify only settings enabled for the node.
- Core support: v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. The cores don’t support exactly the same features, so check protocol and security compatibility before copying a node configuration.
Two comparisons are usually enough: try another known-working node on the same network, then try the same node on a different network. If other nodes work but this one keeps failing, focus on its configuration, server status, and account. If all nodes fail only on one Wi-Fi network, check that network’s restrictions and DNS path. These comparisons are useful clues, not definitive proof from a single test.
7. Restore Settings and Common Questions
Once you’ve found the cause, restore each temporary setting you changed for comparison. In particular, don’t leave full-proxy mode, Private DNS, or browser Secure DNS altered just because you changed them during testing. First confirm the original failed URL works again, then test a direct-connection site and a local network service to make sure fixing one route hasn’t changed another.
Why does the latency test show a result if websites still won’t load?
First check whether the test measures port connectivity or sends a real request. An open port doesn’t confirm that authentication, DNS, or the destination site is working. Even a successful request only confirms that the specific test path works. Next, open the same URL in a browser and check whether its traffic reaches the proxy.
Why does it work in a browser but not in other apps?
In v2rayNG, check the per-app proxy list and mode. In v2rayN, confirm whether the app follows the system proxy. A working browser doesn’t mean all apps are using the proxy. If needed, configure TUN using the relevant guide and test it separately.
Why does the connection fail after the screen locks, then work again after restarting the client?
On Android, check Settings → Apps → v2rayNG → Battery for background activity restrictions. The exact menu may vary by device. Allow necessary background activity, then test again with the screen locked. If the issue occurs only after switching networks, check whether the client reconnects.
I’ve changed too many settings. Should I reinstall?
Back up your subscription groups and custom rules first. Restore a known-working basic configuration, then test with one node. Reinstalling won’t fix a remote server outage and may erase settings and logs needed to diagnose the issue, so it shouldn’t be your first step.