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

Browser and command-line proxy issues have different causes. Check Windows proxy settings, browser extensions, and terminal proxy variables.

At a glance

First confirm that v2rayN’s local port is accepting connections, then check how your browser gets its proxy settings and how your terminal passes proxy parameters. This guide is for Windows users whose system proxy is enabled but some apps still connect directly. Follow the steps in order to distinguish a port that isn’t listening, browser overrides, command-line tools that ignore proxy settings, and traffic that reaches the client but is routed directly.

Start by separating system proxy settings, app-level proxy support, and routing

Keep your current node and routing settings for now. Don’t change your subscription, DNS, and core all at once. In the v2rayN main window, open “System Proxy” at the bottom and select “Automatically configure system proxy.” Some versions also offer this option in the tray icon’s right-click menu. Automatic configuration means the client writes the system proxy settings for you; it doesn’t mean every program will use the proxy, and it shouldn’t be confused with PAC script mode.

App reads proxy settingsLocal port accepts connectionRouting rules are matchedOutbound connection establishedResponse returned to app

System proxy settings tell compatible apps which local address to send requests to. Routing rules decide whether traffic uses a proxy or goes direct after it reaches the core. Browsers usually read the current Windows user’s proxy settings; whether a command-line tool does depends on the tool. A browser test doesn’t tell you what’s happening in the terminal.

Check the local port, then run an explicit proxy test

Open Settings → Parameter Settings and look for local listening port options. Depending on the version, you may see a “Local mixed listening port” or separate HTTP and SOCKS ports. The examples below use 10808, a local port that supports HTTP proxying. Replace it with your actual port; don’t assume the example is a fixed default.

10808
Example local proxy port
127.0.0.1
Loopback address
443
Common HTTPS destination port

Run these commands in PowerShell. The first checks the TCP connection, the second shows the listening process ID, and the third tells curl to connect explicitly to the local HTTP proxy. Use curl.exe to avoid parameter differences caused by the curl alias in Windows PowerShell 5.1.

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808
Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess
curl.exe -q -v --connect-timeout 10 --max-time 30 --noproxy "localhost,127.0.0.1" --proxy http://127.0.0.1:10808 https://example.com/ -o NUL

Put -q first to skip curl’s default configuration file. --noproxy limits the bypass list for this request to local addresses, so an existing NO_PROXY value won’t accidentally send the test domain direct. example.com is just a connectivity example; repeat the command with the actual destination that’s failing and that you’re authorized to access.

  1. If TcpTestSucceeded is False, first check that the port matches, the core is running, and the startup log has no errors.
  2. If the port is listening, check the process ID under OwningProcess. If needed, run Get-Process -Id and append the ID you found. A reachable port doesn’t guarantee that the listener belongs to the current v2rayN core.
  3. If curl shows a connection to 127.0.0.1, the app has reached the local proxy. HTTPS through an HTTP proxy will usually also show CONNECT tunnel negotiation.
  4. If you get an HTTP response from the destination, that confirms this request received a response. Check the routing logs to see whether it used a remote proxy outbound.

Bottom line: Once an explicit proxy test works, check system settings

If the same destination works with --proxy but fails in your browser, leave the node and core settings alone for now. Check how the browser gets its proxy settings; this is easier to diagnose than reimporting your subscription.

Browser proxy not working: Check Windows settings and extension overrides

In Windows 11, open Settings → Network & internet → Proxy → Manual proxy setup. In Windows 10, the path is usually Settings → Network & internet → Proxy. Make sure the proxy server address and port match v2rayN, and check whether the exceptions list includes the domain you’re testing.

  1. Write the settings again. In v2rayN, select “Clear system proxy,” then “Automatically configure system proxy.” Return to Windows Settings and confirm the address and port were actually updated—not just that the client menu changed.
  2. Temporarily disable proxy-management extensions. On your browser’s Extensions page, turn off any extension that controls proxy settings, then fully quit and reopen the browser. Incognito or private browsing may not rule out an extension issue; some extensions are allowed to run there.
  3. Check where the browser gets its proxy settings. Edge and Chrome usually use the system settings, but launch arguments and organizational policies can override them. In Firefox, open Settings → General → Network Settings → Settings and select “Use system proxy settings.”
  4. Rule out stale processes and connections. Save your work, close all browser windows, make sure background processes have exited, then request the page again. Refreshing an existing tab may reuse a connection that was already established.
  5. Check whether the settings keep changing. If the port reverts shortly after you set it, check for other network tools, startup apps, and organizational policies. On a managed device, ask your administrator to check the policy instead of repeatedly overriding it.

If your browser can load ordinary pages but one site has a problem, check that site’s routing, DNS, and certificate errors. An HTTP 403 or 429 means the site returned a response; access policies or request limits may be involved. Don’t assume the system proxy is off.

Terminal proxy not working: Specify a proxy first, then set process environment variables

Start with the earlier curl.exe --proxy test. If it works, decide whether to set environment variables for your terminal. Windows system proxy settings aren’t a universal switch for command-line programs: some read HTTP_PROXY and HTTPS_PROXY, some use their own settings, and others require explicit parameters.

PowerShell: Set variables for the current window and its child processes

Check and note the current variable values before setting temporary ones. The http:// in these addresses describes the protocol the app uses to connect to the local proxy. Even when the destination uses HTTPS, a local HTTP proxy address usually has this format; CONNECT creates the tunnel.

Get-ChildItem Env: |
  Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'

$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'

curl.exe -q -v --connect-timeout 10 --max-time 30 https://example.com/ -o NUL

The second test deliberately omits --proxy to check whether the tool reads environment variables. curl has case-specific conventions for HTTP proxy variables, while Windows environment variable names are case-insensitive. If you use these commands on a case-sensitive system, check the tool’s documentation again. For HTTPS tests, pay particular attention to HTTPS_PROXY.

Command Prompt: Use set, not PowerShell syntax

set "HTTP_PROXY=http://127.0.0.1:10808"
set "HTTPS_PROXY=http://127.0.0.1:10808"
set "NO_PROXY=localhost,127.0.0.1"
curl.exe -q -v --connect-timeout 10 --max-time 30 https://example.com/ -o NUL

To test a PowerShell web request, specify the proxy explicitly: Invoke-WebRequest -Uri 'https://example.com/' -Proxy 'http://127.0.0.1:10808'. How default proxies and environment variables are handled varies across PowerShell and runtime versions. One successful command doesn’t guarantee another will work.

Use the actual error to pinpoint the failure: connection refused, tunnel failure, or certificate error

First identify whether the error came from the browser, curl, or the core log, then locate where the request failed. The snippets below are common examples; exact wording varies by version and destination. Don’t assume a timeout means your subscription is invalid, or that every error is caused by DNS.

ERR_PROXY_CONNECTION_FAILED

Cause: The browser couldn’t establish a working connection to the configured proxy. This commonly happens when the proxy port stops listening or an extension changes the settings.

Fix: Check the proxy address the browser is actually using, run Test-NetConnection against the same port, and confirm which process is listening.

curl: (7) Failed to connect

Cause: The TCP connection couldn’t be established. If the error mentions 127.0.0.1 and a local port, the failure happened before the request reached the proxy.

Fix: Check the core startup log, listening address, and port conflicts. Don’t start by changing the remote node’s transport settings.

ERR_TUNNEL_CONNECTION_FAILED

Cause: The browser couldn’t establish a tunnel through the proxy. The port may use the wrong protocol, or the proxy may be unable to connect to the destination.

Fix: Make sure you entered an HTTP or mixed-protocol listening port. Then use curl’s verbose output and the core log from the same time to investigate further.

curl: (60) SSL peer certificate or SSH remote key was not OK

Cause: Certificate or trust-chain validation failed. That doesn’t prove the request never went through the proxy.

Fix: Check the system clock, the destination certificate, and certificate policies on managed networks. Don’t disable certificate validation as a permanent fix.

If the local port is reachable but the request stalls after tunnel setup, check the destination domain, node connectivity, and TLS logs. With an HTTP proxy, the destination hostname is normally sent to the proxy for handling. If you test with SOCKS instead, socks5:// and socks5h:// resolve hostnames in different places; with the latter, the proxy resolves them. Be clear about which one you used—these aren’t identical tests.

Request reached v2rayN: Check routing, not the proxy entry point

Open the log panel in the main window. Set a log level that shows connection details, refresh the destination once, then search by time for the domain, destination port, and outbound route. Logs usually come from the selected core, and field names vary by core and version. If there’s no entry, the log level may be too low; it doesn’t necessarily mean the app never reached the client.

Bottom line: Change one entry point or rule at a time

First turn off TUN and test system proxy mode with just that one variable. Then compare the browser, an explicit proxy command, and a command that uses environment variables. Consider TUN only after confirming that an app doesn’t support proxies. Don’t enable multiple entry points at once and assume the issue is resolved just because a page loads.

TUN is a separate way to route traffic and may involve a virtual network adapter, permissions, and routing tables. It can help with apps that don’t read proxy settings, but it can’t fix incorrect node parameters and doesn’t guarantee that all network traffic will be captured. Before configuring it, read the TUN mode guide and keep your current settings in a restorable state.

After testing, clear temporary variables and keep a record of what you found

Restore your original routing, log level, and browser extension settings first. If the temporary variables didn’t exist before, you can remove them in PowerShell using the commands below. If they already had values, restore those values instead of deleting them. Closing the terminal usually ends the process-level variable settings for that session, but child processes that are already running may keep their own copies.

Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue
  1. Record your environment: Windows version, v2rayN version, active core and version, and local listening port.
  2. Record these three results: Whether browser access, curl with an explicit proxy, and curl using environment variables each succeeded.
  3. Record the failure stage: Local port connection, CONNECT tunnel, TLS verification, HTTP response, or the core’s connection to the remote node.
  4. Prepare logs before asking for help: Keep timestamps and the surrounding error context, but redact subscription URLs, credentials, share links, and sensitive destination details.

When you exit normally, let v2rayN clean up the system proxy settings. If the client crashes and your browser reports a proxy connection failure, check Windows proxy settings to see whether they still point to a stopped local port. For installation and initial setup, follow the connection verification steps. For system proxy and routing concepts, see the proxy modes guide.

Download v2rayNView platforms and installers