V2Ray System Proxy Not Working: Troubleshoot Browsers and Terminals

1. Understand the system proxy, local listener, and proxy route

When v2rayN shows “Set system proxy automatically,” it means the client is set to write system proxy settings. It doesn’t prove that every app uses those settings or that the node is connected. v2rayN manages configuration; the active V2Ray or Xray core handles the actual connection. Check separately whether an app reaches the local port and whether the core successfully connects outbound. This avoids repeatedly updating subscriptions without addressing the actual problem.

The system proxy setting doesn’t route all traffic from your computer. A browser may use system settings, or its own settings or an extension may override them. Command-line tools often have their own options and environment variables. Even after a request reaches the core, routing rules may send it through a direct outbound route. A connection appearing in local logs doesn’t necessarily mean it went out through the proxy.

• Neither the browser nor terminal works: Check the listening port first, then test the node and outbound route against the same destination.
• Explicit proxy request works, but the browser doesn’t: Check system settings, extension overrides, and browser policies.
• Browser works, but the terminal doesn’t: Check command-line options, proxy variables, and bypass lists.
• Pages fail after quitting the client: Check whether the system still points to a local port that is no longer listening.

2. Check the 10808 listener, then test with an explicit proxy

This example uses 127.0.0.1:10808 as a local mixed-protocol listener. It isn’t a fixed value for every installation. In v2rayN, go to “Settings” → “Parameter settings” and look for “Local mixed port.” In some versions, it’s under the “Core: Basic settings” tab. If the interface lists separate HTTP and SOCKS ports, use the actual HTTP port for the HTTP test below; don’t assume the mixed-port example applies.

Run these two commands in Windows PowerShell. The first checks the listening process. The second bypasses system proxy discovery and tells curl to connect directly to the local HTTP proxy. Use curl.exe to avoid older versions of Windows PowerShell interpreting curl as an alias for another command. Put -q first to skip curl’s default configuration file.

Get-NetTCPConnection -State Listen -LocalPort 10808 |
  Select-Object LocalAddress, LocalPort, OwningProcess

curl.exe -q --proxy http://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 30 --head https://example.com/

example.com is a generic HTTPS connectivity target, not necessarily the site you’re troubleshooting. When retesting, use the full URL that’s failing and keep the target the same across tests. If the target doesn’t support HEAD requests, remove --head; on Windows, add --output NUL to discard the response body. Don’t judge whether the proxy works solely by whether a particular site is directly reachable on your current network.

3. Browser won’t connect: rule out extensions, system settings, and PAC

If the explicit proxy test succeeds but the browser still reports ERR_PROXY_CONNECTION_FAILED, first check which endpoint the browser is actually using. Don’t treat an incognito window as a reliable extension-free test: some extensions can run in incognito mode, and proxy settings may be controlled by organizational policies. Explicitly disable proxy extensions, then fully quit and reopen the browser.

1. Pause proxy extensions

   In Chrome, open “Extensions” → “Manage extensions”; in Edge, open “Extensions” → “Manage extensions.” Pause any extension that changes proxy settings. If you need to keep an extension, note its current mode and port so you can test it separately later.

2. Rewrite the system proxy settings

   Right-click the v2rayN tray icon. Under “System proxy,” select “Clear system proxy,” then “Set system proxy automatically.” Keep the client running, then check the values actually written to the system instead of relying only on the tray menu’s selected state.

3. Check the address and port

   In Windows 11, open “Settings” → “Network & internet” → “Proxy.” Under “Manual proxy setup,” check “Use a proxy server.” The local endpoint for automatic system proxy configuration should match the client’s actual listening address and port, for example 127.0.0.1 and 10808.

4. Check for script conflicts

   On the same page, check “Use setup script.” If an old PAC URL is configured, note where it came from. On a personal device that isn’t managed by an organization, temporarily turn off the script and use only one proxy selection method. On a work device, confirm the management requirements first so you don’t override organizational settings.

5. Check browser-specific settings

   In Firefox, open “Settings” → “General” → “Network Settings” → “Settings,” select “Use system proxy settings,” and test again. If you choose manual configuration, check the HTTP proxy, port, and proxy option for HTTPS requests. Don’t assume these settings update automatically with the system proxy.

“Set system proxy automatically” and “Use setup script” aren’t the same thing. The first usually has the client set a local proxy endpoint; the second tells the browser to read a PAC script that determines whether each destination uses the proxy or connects directly. If the PAC rules omit a domain, only that domain may fail. Check the script’s result and cache rather than changing subscription URLs and local ports at the same time.

• Settings revert immediately after you save them: Check whether another proxy tool, startup task, or organizational policy keeps rewriting the configuration.
• Only one browser has the problem: Create a temporary browser profile for comparison, focusing on that browser’s extensions and separate proxy settings.
• Only one site has the problem: Check routing rules, site status, and the full domain. Access to other sites doesn’t mean every routing path is working.

4. Terminal won’t connect: check environment variables and tool-specific options

There’s no contradiction if your browser loads pages but PowerShell or another terminal times out. The terminal is just the shell that launches a program; whether that program uses system proxy settings depends on its implementation. Environment variables are usually inherited when a process starts. Setting a variable in one terminal window won’t update another window that’s already open or change the browser’s system proxy settings.

First, list the proxy variables in PowerShell, then set an HTTP proxy for the current session. HTTPS_PROXY specifies which proxy to use for HTTPS destinations; it doesn’t mean the local proxy address must start with https://. For a typical local HTTP CONNECT endpoint, continue to use http://127.0.0.1:10808.

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,::1"

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

Windows environment variable names are case-insensitive; on macOS and Linux, case can matter. For security reasons, curl doesn’t use uppercase HTTP_PROXY as an HTTP proxy variable, so these cross-platform examples use lowercase names. Other command-line tools may handle variables differently, so don’t assume curl’s behavior applies to every program.

# macOS / Linux: affects only the current shell and processes started from it
export http_proxy='http://127.0.0.1:10808'
export https_proxy='http://127.0.0.1:10808'
export no_proxy='localhost,127.0.0.1,::1'

curl -q --connect-timeout 10 --max-time 30 --head https://example.com/

If a command runs in a container, virtual machine, or WSL with a different network mode, 127.0.0.1 may point to that environment instead of the desktop host. First check whether the host endpoint is reachable, then decide whether the listening address needs to change. Don’t expose the proxy on every network interface just to save time. If cross-environment access is necessary, restrict source addresses and check the firewall rules.

5. Distinguish HTTP, SOCKS, and DNS failures

A local mixed-protocol endpoint can usually accept both HTTP and SOCKS requests, but older configurations may use two separate ports. Sending HTTP CONNECT to a SOCKS-only port may result in a handshake failure or empty response. This is a local inbound protocol mismatch, not an issue with the VMess or VLESS node protocol. Check the local inbound protocol before investigating the remote node configuration.

# Test on the actual SOCKS port; resolve the destination domain through the proxy
curl -q --proxy socks5h://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 30 --head https://example.com/

When running the command above in Windows, replace curl with curl.exe. For curl, socks5:// usually resolves the destination domain locally, while socks5h:// sends the domain to the SOCKS proxy for resolution. Different results can point to a difference in where DNS resolution happens, but don’t prove which DNS server should be changed.

• HTTP proxy accessing HTTPS: curl usually asks the proxy to establish a CONNECT tunnel to the destination hostname, so the local DNS cache may not be the problem.
• Core logs report that the node hostname couldn’t be resolved: Check the node address and the DNS path used by the core. Clearing the browser cache won’t fix a node resolution problem.
• The same destination is routed directly: Check the current routing mode and rule order. Reaching the proxy port doesn’t guarantee the request will use a proxy outbound route.

6. Restore settings and keep reproducible troubleshooting results

Once you’ve identified the problem, undo temporary changes so test settings don’t cause the next issue. If you set variables temporarily in PowerShell, you can remove them from the current window. If you set persistent variables through system settings, remove them there too, then restart affected apps. The command below clears four proxy variables from the current PowerShell session only; it doesn’t change persistent user or system settings.

Remove-Item Env:http_proxy, Env:https_proxy, Env:all_proxy, Env:no_proxy -ErrorAction SilentlyContinue

In the current macOS or Linux shell, run unset http_proxy https_proxy all_proxy no_proxy. If you set uppercase variables too, check and remove those as well. If the variables are defined in a shell startup file, running unset in the current window won’t prevent them from being loaded again next time.

1. Before quitting v2rayN, select “Clear system proxy” under “System proxy” if needed, then check whether the browser can connect directly as expected.
2. Restore any extensions or TUN you need, one at a time. Retest the same destination after each change.
3. Record the test time, actual listening port, full error code, browser result, and explicit curl result. Don’t reduce every symptom to “no internet.”
4. If you need help troubleshooting, share only the relevant log excerpts. Hide subscription URLs, node credentials, and request links containing tokens.