v2rayN System Proxy Not Working: Troubleshoot Browsers and Command-Line Tools

First, understand system proxies, app proxies, and routing

Enabling the system proxy does not mean every program uses v2rayN. Windows proxy settings only apply to apps that read them; browsers usually do, while many command-line tools rely on their own options or environment variables. If a browser works but a terminal does not, that alone does not mean the node is broken.

Keep variables fixed while troubleshooting. Temporarily turn off TUN, leave only one proxy client running, and choose one node and one test URL. The examples use https://example.com to demonstrate a request; it is not a dedicated test site for determining regional access. To investigate the actual issue, repeat the test with the URL that originally failed.

Step 1: Is the local proxy port listening?

Verify the local endpoint before changing browser settings. The examples below use 127.0.0.1:10808, an endpoint confirmed to support HTTP proxying; this is not a promise that every version uses this default port. If the client shows a different port, update it in every command. Do not confuse HTTP and SOCKS ports from older guides.

1. Check the endpoint

   In v2rayN, open “Settings” → “Parameter Settings” and check the local listening port and protocol under Basic Settings. Menu group names may vary between versions. Also check the main window status and core startup logs; do not infer the protocol from the port number.

2. Confirm the listener

   Run Test-NetConnection in PowerShell. If TcpTestSucceeded is False, check whether the core has stopped and whether the port is correct, then review the startup logs.

3. Check the process

   Use netstat to find the listening entry and PID, then check the process in Task Manager under “Details.” A reachable port only means some program is accepting connections; it does not prove that the listener belongs to the core launched by the current v2rayN instance.

4. Send an explicit request

   Use curl.exe --proxy from the next section to specify the endpoint directly. If it works, move on to the system proxy; if it fails, first check the endpoint protocol, node settings, and core errors.

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808
netstat -ano | findstr ":10808"

If the core log shows address already in use, resolve the port conflict first. Do not terminate an unfamiliar process. Identify the program, close duplicate instances or change the local port, then reapply the system proxy settings.

Browser not using the proxy? Check system settings, extensions, and PAC

The key to troubleshooting a browser is finding which proxy source is actually in effect. In Edge or Chrome, system settings, proxy extensions, startup flags, and organization policies can all affect connections. Seeing the v2rayN tray icon does not prove the browser is using it.

1. Apply the system proxy

   From the v2rayN tray menu, select “System Proxy” → “Set system proxy.” Then open Windows “Settings” → “Network & Internet” → “Proxy” and check that the manual proxy address and port match the current local endpoint.

2. Disable proxy extensions

   In the browser, open “Extensions” → “Manage extensions,” temporarily disable any extension that manages proxies, and restart the browser. Do not rely only on an Incognito window: some extensions are allowed to run in Incognito, and browser policies still apply.

3. Check the automatic configuration script

   On the same Windows “Proxy” page, check “Use setup script.” If enabled, verify the script address and rules. Note the original settings, then temporarily switch to a single manual proxy endpoint to prevent PAC returning DIRECT and confusing the test.

4. Retest and check the logs

   Close and reopen the browser, visit the same test URL, and watch the core access logs. If the request reaches the core, check its outbound tag too: a direct routing rule is a routing decision, not a system proxy failure.

PAC determines which proxy receives an app's request; core routing determines where that request goes next. Either layer can result in a direct connection, but the fix is different. Do not rewrite PAC, DNS, and all routing rules just to proxy one website.

Terminal not using the proxy? Try curl options, then set environment variables

Command-line programs usually do not switch to the proxy just because the Windows system proxy is enabled. Test with an explicit option first, then consider environment variables. In PowerShell, use the full command curl.exe to avoid the curl alias invoking a different command with different argument behavior.

Test the HTTP proxy endpoint with a single request

This command does not rely on the system proxy. For this request, --noproxy limits the bypass target to the reserved test domain unused.invalid, preventing an existing NO_PROXY setting from unexpectedly sending example.com directly. The command does not change persistent settings.

curl.exe --proxy http://127.0.0.1:10808 --noproxy unused.invalid --connect-timeout 10 --verbose --head https://example.com

In verbose output, the connection to 127.0.0.1 and the HTTPS CONNECT exchange can confirm the endpoint is being used; the HTTP response code reflects the subsequent request result. A response does not necessarily mean traffic passed through the remote proxy node, so also check the core's outbound logs. Remove credentials and sensitive addresses before sharing logs.

Set a proxy for the current PowerShell session

$env:HTTP_PROXY = "http://127.0.0.1:10808"
$env:HTTPS_PROXY = "http://127.0.0.1:10808"
$env:NO_PROXY = "localhost,127.0.0.1,::1"

curl.exe --connect-timeout 10 --head https://example.com

It is valid to use http:// for HTTPS_PROXY: it describes the connection from the terminal to the local HTTP proxy endpoint, while HTTPS destinations are typically accessed through a CONNECT tunnel. Do not change the proxy endpoint to https:// just because the destination URL uses HTTPS.

• Scope: These PowerShell assignments apply only to the current session and child processes started afterward. Other terminals that are already running will not inherit the variables.
• Tool-specific behavior: Environment variables are not a universal enforcement mechanism. Some tools require lowercase variables, their own configuration, or command-line options; check the tool's documentation.
• Terminal environments: WSL and containers may have separate network environments. Their 127.0.0.1 may not point to the Windows host endpoint, so do not copy the address without checking.
• SOCKS endpoint: Use the relevant options only after confirming that the port supports SOCKS5. In curl, socks5h:// sends the destination hostname to the proxy for resolution; do not use it with an HTTP-only port.

Clear the session variables after testing

Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:ALL_PROXY, Env:NO_PROXY -ErrorAction SilentlyContinue

Record the original values before clearing them, and restore the previous configuration if the computer already had proxy environment settings. In particular, do not rush to set test variables at the system level: after v2rayN exits and the local port closes, programs that inherit those variables may keep failing to connect.

Which layer should you fix based on the error?

Interpret errors in context. A “timeout” can occur while the terminal connects to the local endpoint, while the core connects to a remote server, or while the remote server accesses the destination site. The examples below show the actual error phrases; versions may add an address, port, or elapsed time.

When does TUN mode make things easier?

TUN is worth considering when several apps ignore the system proxy and are difficult to configure individually. It captures traffic through a virtual interface and routes, but still depends on the core, DNS policy, and exclusion rules. It does not send all traffic through a remote node unconditionally.

• Establish a baseline first: Confirm that an explicit HTTP proxy test succeeds, and note the current node and routing settings before enabling TUN. Otherwise, endpoint issues and virtual network adapter issues become entangled.
• Grant permissions when prompted: Enable TUN from the v2rayN main window. If administrator access is requested, restart as prompted; then check the initialization logs for the virtual interface, routes, and DNS.
• Avoid configuring multiple proxy paths: For the first comparison test, clear the terminal proxy variables and set “System Proxy” to “Clear system proxy” to test TUN on its own. Do not change multiple endpoints at once.
• Keep work networks accessible: Test access to local network devices and internal company domains. If TUN conflicts with another virtual network adapter or work network, turn TUN off to restore connectivity before adjusting exclusions.

Common questions: Why do results differ even when the proxy is on?

Base your final diagnosis on three observable facts: whether the app connects to the local endpoint, whether the core receives the request, and which outbound the request selects. Gathering evidence in that order is more effective than reinstalling the client or changing DNS at random. For a refresher on importing a subscription and setting up the proxy, read the Quick Start Guide.