Proxy connected but websites won’t open? A step-by-step DNS, routing, and system proxy troubleshooting checklist

A client showing “Connected” and a latency test returning a number does not necessarily mean browser traffic is passing through the full proxy path. A web request typically involves DNS resolution, route matching, inbound listening, outbound connectivity, and system-level traffic capture. An error at any point can leave the client looking normal while pages load indefinitely or fail outright.

Do not change the node, DNS, routing, and system settings all at once. Changing several variables makes it difficult to identify the real cause, even if connectivity returns. A safer order is to verify the node first, then DNS, then simplify the routing rules, and finally confirm system proxy or VPN capture. After each step, retest the same page and record the result.

First, confirm what “Connected” actually means

A running status in v2rayN, v2rayNG, or v2flyNG usually only means that the local core has started or a local proxy entry has been created. It does not by itself prove that the remote node is reachable or that the browser is using that entry. Latency tests also have limitations: some measure only the connection time to the server, while real web requests are affected by protocol handshakes, DNS resolution, routing rules, and the remote exit status.

Start by grouping the symptoms below. Different symptoms point to different checks:

Step 1: Check whether the node actually works

The node is upstream of the entire connection path. If it is unavailable, repeatedly adjusting local DNS or routing usually will not help. The most effective test is not latency alone, but switching the same client to another known-good node and loading a real webpage. If the new node works immediately, the problem is most likely with the original node or its parameters.

Verify the node details one by one

1. Check the address and port. Make sure the server address contains no extra spaces, the port is a valid number, and the imported configuration was not changed incorrectly.
2. Check the protocol. VMess and VLESS are different protocols; you cannot switch between them by keeping only the address and port. The protocol shown in the client must match the original node configuration.
3. Check the user identifier. Authentication fields such as the UUID and user ID must be complete. A missing character during copying can cause the handshake to fail.
4. Check the transport parameters. Transport types such as TCP, WebSocket, and gRPC, along with fields such as Host, path, and serviceName, must match the server configuration.
5. Check the security parameters. VLESS nodes using TLS or REALITY require the correct server name, public key, short ID, and other parameters. If a parameter is missing, the local core may still start while the remote handshake fails.
6. Check the device clock. A significantly incorrect date, time, or time zone can cause certificate validation and some protocol authentication steps to fail. Enable automatic time synchronization, then reconnect.

If the node came from a subscription, update the subscription once and confirm that the selected node still exists. An empty subscription response, a removed node, or a stale configuration can leave the client using a record that no longer works. After updating, do not just check the node count: select the node again and perform a real connection test.

Step 2: Determine whether DNS resolution is failing

When a browser visits a domain, it must first resolve the domain to an address. If DNS queries fail, the proxy core may still be running while the browser reports “server not found,” “address could not be resolved,” or remains stuck connecting. If only domain-based access fails while existing connections or services accessed by address still respond, make DNS the first thing to check.

Start with a minimal test

• Check whether the error mentions domain resolution, name resolution, or DNS.
• Switch to another node and test again. If every node produces the same domain-related error, the local DNS configuration is more likely to be the cause.
• Temporarily restore the client’s default DNS settings and disable any custom split-resolution rules.
• Confirm that the exit used for DNS queries is reachable. For proxied DNS queries, the proxy node must connect first; for direct DNS queries, the local network must allow access to the resolver.

DNS and routing have a dependency order. If routing rules match IP addresses, the core may need to resolve the domain first; yet the DNS query itself must choose a direct or proxied exit. When multiple DNS configurations, domain-based routing, and address-based routing coexist, they can form a complex loop in which the resolution result determines routing and routing affects resolution. During troubleshooting, reduce the number of policies first, confirm basic resolution works, and restore them one at a time.

Caches are another common source of interference. After changing DNS, the client, operating system, browser, and proxy core may still hold old results. Fully quit and restart the client, then reopen the browser. Refreshing the page alone may not trigger a new DNS query.

What if DNS works but websites still do not open?

Successful resolution only means that an address was returned; it does not mean that the address is reachable through the current exit. A domain may return multiple IPv4 or IPv6 addresses, while the local network, node exit, or routing rules work with only some of them. If the logs show that resolution completed but the connection then times out, temporarily use a simpler address strategy or disable a custom IPv6-preferred setting for comparison. Once confirmed, choose an address-family strategy that matches the actual network.

Step 3: Rule out incorrect routing and the wrong exit

Routing rules decide whether a connection goes through the proxy, uses a direct connection, or is blocked. Rules are usually evaluated from top to bottom, and matching stops at the first hit. A broad direct rule placed too early may send a site that should use the proxy directly and cause it to fail; an overly broad block rule can terminate the request locally.

Use global proxy mode for comparison

Once the node has been confirmed usable, switch briefly to global proxy mode. If webpages open globally but not in rule mode, the problem is almost certainly in the routing configuration. Do not continue changing node parameters; focus on rule order, matching scope, and outbound tags.

When checking routing, focus on these items:

1. Is there a fallback exit? Traffic that matches no rule needs a clearly defined default exit; it must not point to a nonexistent outbound tag.
2. Is the rule order correct? Exact-domain and narrow-scope rules should generally come before broad rules to prevent premature matches.
3. Are domain and address conditions being mixed? Address-based matching may trigger DNS resolution, and the resolution strategy affects the final result.
4. Is the block scope too broad? Temporarily disable recently added block rules during testing, then restore them one at a time and retest.
5. Does a direct rule cover the target? If the target domain or resolved address falls within a direct-connection range, the page may bypass the proxy and fail to connect.
6. Are the outbound tags consistent? The outboundTag in a rule must exactly match a tag in the actual outbound configuration.

Troubleshooting decision order:
1. Does real access through the node succeed?
2. Does global proxy mode work?
3. Does rule mode fail?
4. Check which rule matches the target domain
5. Confirm whether that rule points to proxy, direct, or block
6. Retest immediately after adjusting one rule

Do not import multiple rule sets at once during troubleshooting. Different sources may contain overlapping domain and address ranges. Start with the client’s default rules, then add one custom rule set and test it. This incremental approach identifies exactly which rule changes the exit.

Step 4: Confirm that system proxy or VPN capture is working

After the proxy core starts, application traffic still needs to enter its local inbound port. Desktop clients typically use the system proxy, an in-app proxy, or another capture method; on Android, v2rayNG and v2flyNG usually capture device traffic through VPN mode. A running local core and captured traffic are separate states, so do not rely only on the start button.

v2rayN desktop checks

• Confirm that the node you intend to use is selected, rather than merely having the client window running.
• Confirm that system proxy mode is enabled, then check the operating system’s proxy settings for the corresponding local address and port.
• If a proxy was entered manually in the browser, switch it back to “Use system proxy” or clear the old port so the browser does not keep connecting to a dead local port.
• Check whether another proxy program is using the same port. A port conflict usually appears in the core logs as a listen failure or an address-already-in-use error.
• After quitting the client, confirm that the system proxy has been restored correctly, then start the client again. An abnormal exit can leave an old proxy address behind, sending all requests to a nonexistent port.

v2rayNG and v2flyNG Android checks

• After starting the connection, confirm that the system status area shows a VPN connection and allow the client to establish the VPN.
• Review per-app proxy settings. If the target browser or app is excluded, its traffic will not enter the proxy.
• Temporarily disable battery-saving or background-activity restrictions for testing, so the system does not stop the core process when the screen locks or you switch apps.
• If another VPN connection is active on the device, disconnect it before testing. Systems generally cannot keep two VPN capture paths working normally at the same time.
• After switching from one network to another, disconnect and reconnect manually so the core can rebuild the underlying connection.

“The browser works, but one app does not” usually does not mean the node is completely down. Some apps ignore the system proxy, some have their own proxy settings, and others use UDP. First check whether the app is captured, whether UDP is allowed, and whether routing assigns its target addresses to a different exit.

Step 5: Use logs to locate the failing layer

If the first four steps do not identify the issue, open the client logs, clear the old entries, and load the test page once more. This reduces historical noise. Focus on the new lines generated during the request, not only on messages from core startup.

“No request” in the logs is itself an important result. If no new inbound entry appears while loading a webpage, the problem occurs before the core, so return to the system proxy or VPN capture checks. If an inbound request is visible but no outbound connection succeeds, determine whether DNS, routing, or the node handshake failed. Asking whether the request entered and where the outbound connection stopped quickly narrows the scope.

Final troubleshooting checklist: work through each item in order

1. Confirm that the ordinary network connection works and that the device can access pages allowed by the local network.
2. Synchronize the system date, time, and time zone.
3. Update the subscription and select the node again; do not keep using a removed old entry.
4. Switch to at least one known-good node and verify it by loading a real webpage.
5. Verify the VMess or VLESS protocol, address, port, UUID, transport, and security parameters.
6. Restore the client’s default DNS, then restart the client and browser before testing again.
7. Temporarily switch to global proxy mode. If global mode works, focus on the routing rules.
8. Check rule order, direct-connection scope, block scope, and outbound tags.
9. On desktop, confirm that the system proxy address matches the local listening port.
10. On Android, confirm that the VPN is established and the target app is not excluded by per-app rules.
11. Check for a local port conflict or another active VPN connection.
12. Clear the logs, reproduce the issue once, and use the new entries to identify the failing layer.

After troubleshooting, restore global mode to the routing mode used day to day, then restore custom DNS, rule sets, and per-app settings one at a time. Test access after each change. This preserves the original traffic-splitting requirements while identifying which setting triggers the failure again.

If authentication or handshake errors continue after re-importing the node while other nodes work normally, the node’s complete parameters usually need to be updated. If all nodes time out on the same network but work after switching networks, check whether the current network restricts the target address, port, or protocol traffic. Narrowing the issue to one node, one device, or one network makes the next step much clearer.