v2rayN System Proxy Not Working: Fix Browser and Command-Line Proxy Issues

Understand system proxy, local ports, and routing

v2rayN’s “Set system proxy” option mainly writes proxy settings to the operating system; it does not intercept traffic from every program. An app must read those settings to connect to the local proxy. Browsers usually do, while command-line tools vary, so different results on the same computer are no contradiction.

After a request reaches the local proxy, the core uses routing rules to decide whether to connect directly, use a proxy, or block it. Enabling the system proxy only gives an app a chance to send traffic to the core; it does not guarantee that every destination exits through a remote server. A successful subscription update or a latency result for a server does not replace testing an actual web request.

Turn off TUN while troubleshooting and leave only one proxy client running. This prevents TUN from masking incorrect system proxy settings and reduces interference from having two traffic-capture methods active. If your device is managed by your organization, do not bypass its network policies.

Step 1: Verify the port and test with an explicit proxy

In v2rayN, open Settings → Parameter settings and check the local listening ports and inbound protocols. Review the core startup log as well. Depending on the version, HTTP and SOCKS may use separate ports or share a mixed port. Do not assume a port number is a fixed default based on an older guide. The separate ports below are examples, not a claim about the current version’s defaults.

1. Note the ports

   Note the local HTTP or mixed port and the SOCKS port. If there is only one mixed port, use it for both tests. Do not enter the remote server port from your subscription.

2. Start the core

   On the main screen, select the server you want to test and set it as active. Confirm that the log shows no startup errors. Use just one server and the same rules throughout testing.

3. Check the listener

   Run the listener check below in PowerShell. If it returns no results, check core startup first. If another process owns the port, resolve the conflict before changing browser settings.

4. Specify the proxy

   Use curl.exe to specify the proxy explicitly and check the HTTP response and any errors. In Windows PowerShell, typing curl directly may invoke an alias, so use the full program name here.

# Replace the ports with the values actually listening on your machine
Get-NetTCPConnection -State Listen -LocalPort 10809 |
  Select-Object LocalAddress, LocalPort, OwningProcess

# HTTP proxy: HTTPS requests are sent through a CONNECT tunnel
curl.exe --proxy http://127.0.0.1:10809 --noproxy "" --connect-timeout 10 --max-time 20 -I https://example.com/

# SOCKS5: the proxy resolves the destination hostname
curl.exe --proxy socks5h://127.0.0.1:10808 --noproxy "" --connect-timeout 10 --max-time 20 -I https://example.com/

--noproxy "" clears the bypass list for this explicit test. The example URL is only for checking the connection path; it does not indicate availability in any particular region. For further diagnosis, substitute the destination that is actually failing. An HTTP status from the destination means an HTTP response was received. Even a 403 or 405 differs from a failure to connect to the local proxy, but check the logs to confirm whether traffic exited through the remote server.

Browser not using the proxy? Check system settings and extensions

If the explicit proxy test succeeds but the browser still behaves unexpectedly, first make sure it uses the system proxy, then check its proxy extensions. Edge and Chrome generally use Windows proxy settings, but extensions, launch options, and organizational policies can change that behavior. Incognito mode does not necessarily disable extensions; some can run there if permitted.

1. Set the system proxy

   Right-click the v2rayN tray icon and choose System proxy → Automatically configure system proxy. Do not select Clear system proxy, and do not assume that “Do not change system proxy” enables it automatically.

2. Check the system address

   In Windows 11, open Settings → Network & internet → Proxy. Under Use a proxy server, check the address and port and make sure they match v2rayN’s HTTP or mixed inbound. Note any existing setup script so two configurations do not interfere with troubleshooting.

3. Temporarily disable proxy extensions

   Temporarily turn off proxy-switching extensions in the browser’s extensions manager. Check whether the browser shortcut includes proxy launch options. Close all browser windows, reopen it, and visit the same test address.

4. Check browser-specific settings

   In Firefox, go to Settings → General → Network Settings → Settings and select Use system proxy settings. If you choose manual configuration, check the HTTP and SOCKS settings and the list of addresses that bypass the proxy.

If only one website connects directly, check proxy exceptions and v2rayN routing. For example, the browser may exclude local network addresses, or a rule may send a domain through a direct outbound. Neither means the system proxy toggle is broken. You can briefly switch to a global proxy routing mode for comparison, then restore your original rules. Do not delete the entire routing setup.

• All browsers fail: First check the system proxy port, setup script, and whether another program keeps changing the settings.
• Only one browser fails: Check that browser’s extensions, independent proxy settings, launch options, and management policies first.
• Pages load, but the apparent exit location is different: Check the outbound log for the destination domain. An IP-check website only shows the route used for its own request.

Terminal not using the proxy? Try explicit options first, then environment variables

Command-line tools do not necessarily use the Windows system proxy. A terminal window is not a single, unified network client: in the same PowerShell session, curl.exe, a scripting runtime, and a package manager may each get proxy settings from a different source. Test the specific program first, then decide whether to set environment variables. A working browser does not mean the terminal is using the proxy.

For curl, https_proxy specifies which proxy to use for HTTPS destinations; its value can still be http://127.0.0.1:10809. Here, http:// describes the local proxy protocol. It does not mean the destination page uses unencrypted HTTP. If you mistakenly enter https://127.0.0.1:10809, the program may attempt a TLS handshake with a standard HTTP proxy port and fail.

# Record the old values first; these settings affect only this PowerShell session and new child processes
$oldHttpsProxy = $env:https_proxy
$oldNoProxy = $env:no_proxy

$env:https_proxy = "http://127.0.0.1:10809"
$env:no_proxy = "localhost,127.0.0.1"

# Without --proxy, check whether this program reads environment variables
curl.exe --connect-timeout 10 --max-time 20 -I https://example.com/

# Restore the original values when testing is complete
if ($null -eq $oldHttpsProxy) {
  Remove-Item Env:https_proxy -ErrorAction SilentlyContinue
} else {
  $env:https_proxy = $oldHttpsProxy
}
if ($null -eq $oldNoProxy) {
  Remove-Item Env:no_proxy -ErrorAction SilentlyContinue
} else {
  $env:no_proxy = $oldNoProxy
}

Run the setup, test, and restore commands separately; do not run the whole block at once and check the variables afterward. If you also need to proxy HTTP destinations, check the tool’s documentation for http_proxy. curl has specific case-handling rules for this variable, so lowercase is preferable in cross-platform scripts. ALL_PROXY can serve as a general fallback proxy in curl, but not all programs support it or accept SOCKS addresses.

If environment variables have no effect, check the program’s own proxy options. You can test explicitly with PowerShell’s Invoke-WebRequest using -Proxy http://127.0.0.1:10809. Do not assume it reads the same variable just because curl works. WSL and containers also have separate network environments. Their 127.0.0.1 may not point to the Windows host, so check the host address and listening scope for your network mode.

Use the actual error to distinguish port, TLS, and remote timeouts

Keep the complete error from the failed request and note when it occurred, then compare it with the v2rayN log. The port below is an example; the actual error will show your port and wait duration. Do not share just the words “connection failed,” and do not publicly post full logs containing subscription URLs or credentials.

If socks5h:// succeeds but a method that resolves locally fails, investigate the DNS resolution path first; this does not automatically mean a public DNS provider is at fault. Also check whether routing rules depend on domain resolution and whether DNS requests are sent through the expected outbound.

When to switch to TUN—and when to keep fixing the system proxy

Consider TUN when multiple apps have no proxy settings, managing their environment variables individually is impractical, or you need to capture more IP traffic. It routes traffic through a virtual network interface and generally covers more than the system proxy. Correct interception still depends on the core, permissions, routing, DNS, and app behavior, so TUN is not a universal fix for network problems.

• Fix the system proxy first: The browser has the wrong port, an extension forces direct connections, or curl options are incorrect. These have identifiable causes and do not require switching traffic-capture methods.
• Consider TUN: Multiple apps do not use the system proxy, and configuring each one individually would be too much work. First confirm the standard proxy path works.
• Hold off for now: Explicit proxy requests still fail, the remote server has handshake errors, or your organization enforces network policies. TUN will not fix a server or authentication configuration.

Before enabling TUN, note the current system proxy and routing state. Grant the required permissions as prompted by v2rayN, then enable TUN in the interface. During testing, clear the system proxy and restore any temporary terminal variables to avoid routing apps through both an explicit proxy and TUN, which can make results hard to interpret. Check that the virtual interface, default route, and DNS are set up, then verify that local network services remain accessible.

Frequently asked questions and final checks

You only need one clear chain of evidence: the local port is listening, an explicit proxy request gets a response, the browser uses the right proxy source, the terminal program reads its own proxy settings, and the routing log shows the expected outbound. Check each layer in that order; it is more effective than repeatedly toggling the system proxy or switching servers. To reorganize subscriptions, servers, and startup steps, use the site’s quick-start guide to establish a clean baseline.