V2Ray Connected but No Internet: A Checklist for Proxy Ports, Routing Modes, and DNS

First, clarify what “connected” actually means

A changed tray icon or a startup-complete message in the log only confirms that the core process loaded its configuration. It does not mean browser traffic is using the proxy or that the remote node is forwarding traffic successfully. The full path includes the app, system proxy or VPN interface, local listening port, routing rules, DNS, and outbound node. A failure at any point can leave the interface looking normal while webpages remain unreachable.

Start with a minimal test: close every extra proxy tool and keep only one V2Ray client running; select a known-working node; use the same browser to open a regular webpage and a webpage that requires a proxy. If regular webpages also fail, check the local port, system proxy, and TUN first. If regular webpages work but specific sites fail, focus on routing, DNS, node protocol parameters, and remote reachability.

Step 1: Check the system proxy and local listening port

The most common desktop issue is that the core is running while the system proxy remains disabled. v2rayN’s local port receives requests from browsers and apps; the system proxy tells programs that support it to send requests to that port. Both must point to the same values that are actually listening—do not rely on assumed default ports.

If the browser has a separate proxy configuration, make sure it is not still pointing to an old port. For example, if the client has changed to 127.0.0.1:10818 while a browser extension still uses 127.0.0.1:10808, requests will go to a nonexistent listener. Corporate network tools, debugging proxies, and older clients may also be using the same port.

1. Check the running status

   In the v2rayN main window, confirm that the intended server is selected and the core log shows a completed startup without repeated restarts or an immediate exit.

2. Check the listening port

   Open “Settings” → “Parameter Settings” → “Basic Settings” and note the local SOCKS or mixed-proxy port. 10808 is common, but use the value shown in the current interface.

3. Enable the system proxy

   In the main window, open “System Proxy” and select “Auto Configure System Proxy”. Then confirm that the system proxy settings point to 127.0.0.1 and the current port.

4. Rule out port conflicts

   Exit other proxy and network debugging programs, then restart v2rayN. If the log still reports a bind failure, change the local port to 10818 and start it again.

5. Restart the app and test

   Fully exit the browser and reopen it so an old connection pool does not keep reusing direct connections. Test a regular webpage first, followed by the target address that requires a proxy.

Step 2: Return routing to a verifiable state

Routing rules determine whether a request uses the proxy, connects directly, or is blocked. Expired rule sets, incorrect custom domains, and reversed priorities can all send a target site to the wrong outbound route. During troubleshooting, avoid changing several rule groups at once. Start with a clearly defined mode, then use the logs to see which rule ultimately matched the target domain.

In v2rayN, open “Settings” → “Routing Settings”, temporarily select the basic rule set provided by the client, and disable recently added custom rules. If “Global Proxy” works but “Bypass local networks and common direct domains” does not, the node and port are probably fine; focus on split-routing rules, domain categories, and DNS results.

• Global Proxy works, rule mode fails: Check whether the target domain was incorrectly assigned to a direct outbound route, especially custom suffix rules and regular expressions.
• Global Proxy also fails: Go back to the local port, node protocol parameters, TLS time, and remote network checks instead of repeatedly changing routing.
• Only LAN addresses fail: Confirm that private addresses are not being sent through the proxy. Printers, router admin pages, and shared devices should normally use a direct connection.
• Only some subdomains fail: A webpage may call several API domains. Use the core log to identify the specific host that failed instead of adding only the main site domain.

Step 3: Check DNS resolution and system time

DNS failures usually appear in three ways: the domain cannot be resolved, it resolves to an unreachable address, or DNS requests are routed incorrectly. If connecting directly to a server address works but using its domain fails, the problem is probably DNS. If the node server itself uses a domain, DNS failure can stop the core before it establishes the outbound connection.

First check the system date, time zone, and automatic time synchronization. An incorrect clock can affect TLS certificate validation and make an otherwise valid subscription configuration fail during the handshake. Then clear the system DNS cache and temporarily disable encrypted DNS configured separately in the browser so test requests use one resolution path.

1. Synchronize system time

   Open system “Settings” → “Time & language” → “Date & time”, enable automatic time and time-zone settings, then sync immediately.

2. Review resolution logs

   Reconnect to the node and open the core log. Search for lookup, DNS, no such host, or timeout, and record the failed domain.

3. Clear the cache

   Flush the system DNS cache using the normal troubleshooting procedure, then quit and reopen the browser so it does not keep using an old cached address.

4. Use one resolution path

   During troubleshooting, keep one DNS configuration active. Do not enable client DNS, browser-specific DNS, and DNS takeover by another network tool at the same time.

ipconfig /flushdns
nslookup example.com
netstat -ano | findstr 10808

The first command clears the Windows DNS cache; the second checks whether the current system resolver can return an address; the third checks whether 10808 is listening. If the client uses a different port, replace it with the value shown in “Parameter Settings”. Command output does not prove the full path works, but it quickly separates “nothing is listening” from “DNS resolution failed”.

Step 4: Rule out TUN, VPN interfaces, and firewall conflicts

TUN mode creates a virtual network interface and also routes traffic from programs that do not read the system proxy. Its wider coverage makes conflicts more likely with other VPN interfaces, virtual machine adapters, enterprise security software, or firewall rules. A typical sign is that webpages work with the system proxy but all connectivity stops as soon as TUN is enabled, or that abnormal routes remain after the client is closed.

First disable TUN and keep only the regular system proxy. If access returns, the node configuration is not the primary issue. Then check whether the virtual interface was created successfully, whether the default route is being controlled twice, and whether DNS still points to a virtual interface that has stopped. Do not enable two network tools that can modify the default route.

• Exit any program that creates a virtual network adapter or modifies the default route, leaving only the current client running.
• In v2rayN, disable TUN mode and re-enable “Auto Configure System Proxy”, then verify basic browser access.
• Check that the firewall allows the v2rayN main program and its current core to access private and public networks.
• If you recently upgraded the client, restart the system so old virtual interfaces, routing tables, and locked processes are fully released.
• After restoring TUN, watch the log again. Confirm that the inbound type has changed and check whether the failure occurs during DNS forwarding.

Step 5: Check VPN permissions and app routing on Android

v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. On Android, both typically take over traffic through the system VPN interface. A VPN icon in the status bar only means the interface was requested; it does not prove every app was included correctly. If the browser works but one app does not, check app routing first. If no apps work, check VPN permissions, node parameters, DNS, and battery background restrictions.

Configurations such as VMess and VLESS must keep the server address, port, user identifier, transport, TLS, and path parameters consistent. After a subscription update, the server parameters may have changed while the old configuration remains selectable in the list; the connection then times out during the handshake. Update the subscription and select the refreshed entry instead of copying and modifying the old node.

1. Recreate the VPN interface

   Stop the current connection, wait for the VPN icon to disappear from the status bar, then start the connection again and confirm that the system authorization dialog was accepted.

2. Disable app routing

   Open the client’s “Settings” → “Per-app proxy”. Temporarily disable whitelist or blacklist rules during troubleshooting so the browser and test app use the same path.

3. Update the subscription

   Run an update from the subscription group, confirm that the number and names of nodes have refreshed, then select an updated node for the connection test.

4. Verify node parameters

   Check the server port, transport, TLS, SNI, Host, and path. Make sure parameters from another node were not mixed into the current configuration.

5. Allow background activity

   In the system app settings, allow the client to remain active in the background so battery policies do not pause the VPN process after the screen turns off.

A 10-minute troubleshooting sequence: change one variable at a time

The fastest approach is not repeatedly switching nodes. Keep the node unchanged and check the traffic path from the nearest point outward. Retest and record the result after each step. Once access returns, the only variable just changed identifies the likely fault. If you change the node, port, DNS, and routing together, even a recovery will not reveal the real cause, and the entire process may be repeated next time.

1. Minute 1: Close other proxy tools and confirm that only one client instance is running.
2. Minute 2: Check the system proxy address, the client’s local listening port, and the browser proxy port.
3. Minutes 3–4: Switch to Global Proxy for comparison and use the result to determine whether split routing is the issue.
4. Minutes 5–6: Synchronize system time and review DNS, lookup, and timeout entries in the log.
5. Minutes 7–8: Disable TUN or per-app proxy rules and test through the simplest system-proxy or VPN path.
6. Minute 9: Update the subscription and verify the VMess or VLESS port, transport, TLS, SNI, and path.
7. Minute 10: Restart the client and test app, save the key logs, then decide whether to switch nodes.