V2Ray Connected but Websites Won’t Load: System Proxy, DNS, and Routing Checklist

When a client displays “Connected” or “Service started,” it usually means only that the local proxy core is running and its listening ports are open. It does not mean browser requests are passing through the proxy, nor that the remote node can complete a connection. Troubleshoot outward along the path a request actually takes instead of repeatedly refreshing the subscription or switching nodes at random.

What “client connected” actually means

V2Ray, Xray, and V2Fly cores typically establish remote connections on demand. When the client starts, its local HTTP, SOCKS, or VPN interface becomes ready first; only after the browser sends a request does the core perform DNS resolution, route matching, protocol encapsulation, and remote dialing. The status shown in the interface therefore cannot replace a complete website request test.

First define the fault boundary: can ordinary websites open with the proxy fully disabled? With the proxy enabled, do all sites fail, or only sites covered by proxy rules? When a domain fails, does opening a known address directly also fail? These answers point respectively to the local network, the proxy path, or the DNS and routing layers.

Step 1: Confirm the system proxy actually points to the client

On Windows with v2rayN, the running core and the system proxy are separate states. Starting the service alone does not route browser traffic through it. In the v2rayN main window, choose “System Proxy” → “Set system proxy automatically,” then open Windows “Settings” → “Network & Internet” → “Proxy” and confirm that the proxy server points to 127.0.0.1 and that its port matches v2rayN’s current HTTP port.

1. Open v2rayN “Settings” → “Parameters,” and note the local SOCKS and HTTP listening ports.
2. Make sure the ports have not been manually changed; a common combination is SOCKS 10808 and HTTP 10809.
3. Check whether the browser has a proxy extension or a fixed proxy address configured separately, which could override the system proxy.
4. Temporarily quit other network tools that modify the system proxy, then run “Set system proxy automatically” again.
5. Close and reopen the browser to invalidate old connection pools and proxy settings.

To bypass the system proxy settings and test the local port directly, send a request through the HTTP proxy from a terminal. If the test returns HTTP response headers, the browser-to-local-proxy segment is basically working. If it immediately reports that it cannot connect to 127.0.0.1, first check whether the core exited, the port is incorrect, or the listening address was changed.

curl --proxy http://127.0.0.1:10809 --head https://v2help.com/

Android works differently. v2rayNG and v2flyNG need system VpnService authorization before they can route app traffic. If authorization was skipped on the first connection, or the system reclaimed the VPN in the background, the client may still show the node while actual traffic never reaches the core. Tap Connect again, confirm that a VPN indicator appears in the status bar, and check “Settings” → “Per-app proxy” to make sure the browser being tested has not been excluded.

Step 2: Verify node reachability and subscription parameters

Once the system proxy is correct, check the node itself. A latency test only proves that one type of probe received a response; it does not prove that the VMess, VLESS, or transport-layer handshake completed successfully. A more reliable approach is to select one node, make a real website request, and watch the runtime log for dialing, TLS, WebSocket, or authentication errors.

A successful subscription update only means the client downloaded a configuration; it does not mean every node in it works. Do not guess the user ID, port, TLS server name, or WebSocket path manually—these fields must match the server. If all nodes stop working right after an update, first confirm that the selected group actually references the new nodes, then restart the core to avoid continuing with an old active configuration.

Step 3: Check whether DNS fails before the proxy

When the browser visits a domain, it first needs an address. If the node server itself uses a domain, the client must resolve the node address first; if that fails, the proxy protocol never gets a chance to handshake. Typical log messages include lookup, no such host, or failed to find an available destination, while an old page in the local cache may still appear to work temporarily.

nslookup v2help.com
nslookup v2help.com 1.1.1.1

Use the system’s current DNS for the first command, then specify a DNS server for comparison in the second. If the first keeps timing out while the second returns an address within 1–2 seconds, fix the system DNS first. If both fail, check whether the current network permits DNS queries. After testing, return to the client, restart the core, and make the request again so an old failed lookup cache does not affect the result.

• On Windows, check the DNS configuration under “Settings” → “Network & Internet” → the current network connection.
• After changing DNS, run ipconfig /flushdns, then fully quit and reopen the browser.
• When using custom DNS in v2rayN 7.x, confirm that the server address resolves and that the configuration syntax contains no extra commas or invalid entries.
• When routing rules match domains, do not force every domain to be rewritten into an address that the rules are not designed to match before resolution.
• If only the node domain fails to resolve while ordinary domains work, check that the node address in the subscription is complete and contains no stray spaces.

Step 4: Rule out routing rules sending requests through the wrong exit

Routing rules decide whether a request uses the proxy, connects directly, or is blocked. A node can work perfectly while a rule sends the target domain through the direct exit, causing the page to time out; conversely, sending a local network address through the proxy can make a router admin page or local service unreachable. The most effective diagnostic is not to rewrite rules immediately, but to switch temporarily to global proxy mode for comparison.

1. Save the current routing settings and note the name of the rule set in use.
2. In v2rayN, temporarily select the routing mode corresponding to global proxy mode, then restart the core.
3. Close the browser’s existing tabs and revisit the same address that failed earlier.
4. If global mode restores access, the problem is in the domain rules, address rules, or outbound tag.
5. Restore the original routing mode and inspect the matching order one rule at a time; do not use global mode permanently to hide incorrect rules.

V2Ray and Xray routing usually matches rules in configuration order. A broad rule placed first can intercept a more specific rule later. For example, an overly broad direct-domain rule can send a request directly when it should use the proxy; an early blocking rule can reject it locally. When the log shows the target domain and its outbound tag, trust the actual match result.

v2rayNG and v2flyNG also require checking per-app proxy settings. If only selected apps are allowed through the VPN and the browser is not selected, the client can remain connected while the browser continues to connect directly. Go to “Settings” → “Per-app proxy” and check whether the current mode is “Bypass selected apps” or “Proxy selected apps”; the meaning of the selections is opposite in these two modes.

Step 5: Correct the system clock and check TLS and protocol parameters

An incorrect system clock affects TLS certificate validity checks and can disrupt authentication flows that depend on a time window. VMess is sensitive to the time difference between client and server; clock drift after sleep or a paused virtual environment can leave the local port working while the remote side repeatedly rejects connections. VLESS with TLS likewise requires the correct time to validate certificates.

• On Windows, open “Settings” → “Time & language” → “Date & time,” and enable automatic time and automatic time zone.
• Click “Sync now” and confirm that the date, time zone, and minutes are all correct.
• On Android, open system “Settings” → “System” → “Date & time,” and enable network-provided time.
• After correcting the clock, restart the v2rayN, v2rayNG, or v2flyNG core—not just the browser page.
• If the log still reports a TLS failure, verify the server name, transport security type, and port in the subscription. Do not manually mix parameters from another node.

Also confirm that the client core supports the node’s capabilities. v2rayN can call the appropriate core for each configuration; v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. A standard VMess or VLESS configuration does not mean every extended transport feature can be exchanged directly between different cores. If fields disappear after import or the log explicitly reports an unsupported feature, choose a client that matches the configuration instead of deleting unfamiliar fields.

Final troubleshooting checklist, in order

After completing the checks above, run through the sequence below once more. At each step, answer only “pass” or “fail.” Stop at the first failure and fix that layer before making further changes. This shortens diagnosis and makes temporary settings easier to undo after recovery.

1. Basic network: With the proxy disabled, the current network can access ordinary websites normally.
2. Core status: The client runtime log shows no port conflict, configuration parsing failure, or process exit.
3. Local entry point: The system proxy points to 127.0.0.1 and the actual HTTP port, or the Android VPN has been authorized.
4. Request received: When the page is refreshed, the access log shows a new target domain or connection record.
5. Node reachable: At least one node completes a real website request, not just a latency probe.
6. DNS working: System lookups return results in about 1–2 seconds, with no repeated lookup errors in the log.
7. Routing correct: The comparison between global and split-routing modes is clear, and the target reaches the expected outbound.
8. Time accurate: The system date, time zone, and minutes are synchronized, and TLS logs no longer report validity-period problems.
9. App coverage: The browser is not excluded by per-app proxy rules and is not using an outdated standalone proxy configuration.
10. Configuration consistent: The protocol, port, user ID, TLS server name, and transport path all come from the same subscription record.

If the checklist stops at “Request received,” focus on the browser, system proxy, or VPN authorization. If dialing errors appear after the request enters the core, focus on the node, network, and DNS. If only split routing fails, return directly to rule matching. Limiting the fault to one layer before changing the configuration is more likely to produce a repeatable result than reinstalling the client all at once.