System Proxy Enabled but Not Working: Separate Troubleshooting for Browsers and Terminals

Break “not working” into three scopes

v2rayN is a desktop client for managing configuration and the proxy core. Xray and other proxy cores handle actual connections, while the Windows system proxy only publishes a local proxy address to some applications. Enabling the system proxy does not force every network connection through the core, nor does it guarantee that routing rules will choose the proxy outbound.

The first layer is local listening. After starting the core, the client usually listens on the loopback address for HTTP, SOCKS, or mixed-proxy traffic. Browsers and terminals have no entry point unless that listener exists. The second layer is application access: whether an app reads the Windows system proxy or uses its own saved proxy settings. The third layer is routing and outbound selection: once traffic enters the core, configured domain, IP, protocol, and routing rules determine whether it connects directly, uses the proxy, or is blocked.

So “the browser works but PowerShell does not” often means their access methods differ, not that the node suddenly failed. If the browser reports a proxy connection failure, check the local port first rather than changing VLESS, VMess, or TLS parameters. Layer-by-layer troubleshooting prevents an entry-point problem from being mistaken for a server problem.

Step 1: Confirm the core and local listener

In v2rayN, select a configuration and start the core. Then check the main window or log area for startup failures, port conflicts, or configuration parsing errors. A subscription is only a source of configuration; a successful subscription update does not mean the core is running or that the system proxy points to the correct port.

Next, open “Settings” → “Parameter Settings” and note the current HTTP and SOCKS listening ports. If the version uses a single mixed port, record the value shown in the interface. The listening address is usually 127.0.0.1, which accepts connections only from the local machine. Unless LAN access is explicitly required, do not change it to an address exposed on every network interface just for troubleshooting.

1. Record the ports

   Open v2rayN “Settings” → “Parameter Settings” and write down the HTTP, SOCKS, or mixed listening port. Do not guess from an old tutorial.

2. Check the process

   Start the selected configuration. Confirm that the client is not repeatedly reporting core exits, and find the first error in the log instead of looking only at the last line.

3. Check the listener

   In PowerShell, run Get-NetTCPConnection to confirm that the target port is in the Listen state, and record the associated process ID.

4. Test the entry point

   Use Test-NetConnection to test the loopback address and HTTP port. If the TCP test fails, fix the listener first.

Get-NetTCPConnection -State Listen |
  Where-Object { $_.LocalPort -in 10808, 10809 } |
  Select-Object LocalAddress, LocalPort, OwningProcess

Test-NetConnection 127.0.0.1 -Port 10809

A TcpTestSucceeded value of True only proves that the port accepts a TCP connection. It does not by itself prove that the node protocol, server address, or routing rules are correct. Next, use a request with an explicitly specified proxy to verify the full path. If the target port is missing from the results, check the v2rayN logs for a core startup issue. If another process owns the port, use Get-Process -Id process ID to identify it.

Check browsers separately: “use system settings” vs. “custom settings”

Most desktop browsers that use system network settings read the Windows proxy, but browser extensions, enterprise policies, launch arguments, or browser-specific network settings can override it. During troubleshooting, keep one control source only: either follow the Windows system proxy or specify the local proxy in the browser. Do not let an extension and the system settings rewrite the outbound path at the same time.

When selecting a system-proxy option from the v2rayN tray menu, confirm that its mode matches your needs, such as automatically configuring the system proxy. Then open Windows “Settings” → “Network & Internet” → “Proxy” and check whether the manual proxy or automatic configuration script reflects the current client settings. Different v2rayN modes may write system settings differently, so do not manually override the address at the same time.

If only one browser is affected, create a temporary browser profile or disable the extension responsible for switching proxies, then test again. Private browsing usually does not bypass the system proxy, so it is useful for ruling out cache and sign-in state, not for proving that the proxy entry point has recovered. A browser’s secure DNS handles domain resolution; it is not the same as an HTTP or SOCKS proxy.

1. Use one control source

   Temporarily disable the browser extension that switches proxies, remove test-only launch arguments, and keep Windows system proxy as the only control path.

2. Check the system settings

   Open Windows “Settings” → “Network & Internet” → “Proxy” and check that the address, port, or automatic configuration state matches the current v2rayN mode.

3. Restart the browser

   Fully exit all browser processes and reopen the browser so an old process does not continue using proxy settings read at launch.

4. Compare one case at a time

   Test a regular HTTPS page first, then the domain that originally failed. If only the latter fails, investigate routing, DNS, SNI, and server configuration.

Terminal tools need explicit proxy settings

PowerShell, command-line download tools, package managers, and developer tools may not read the Windows system proxy. Some recognize only uppercase environment variables, some recognize both cases, and others require a proxy in their own configuration file. A system proxy can be enabled while a terminal still connects directly; this is common with these tools.

First run an explicit test with the --proxy option in curl.exe. This removes uncertainty about whether the tool reads system settings and directly verifies the full request from the local entry point to the target site. The example HTTP port is 10809; the example SOCKS port is 10808. Replace them with v2rayN’s current values before testing.

curl.exe --proxy http://127.0.0.1:10809 https://example.com/ --max-time 10

curl.exe --proxy socks5h://127.0.0.1:10808 https://example.com/ --max-time 10

In socks5h, the h tells the proxy to resolve the target hostname. This is useful for comparing local DNS with proxy-side resolution. If both HTTP and SOCKS tests succeed but a command without --proxy fails or connects directly, the problem is terminal access, not the subscription configuration.

If several tools in the current PowerShell session need to try the proxy, set temporary environment variables. They disappear when the session closes, making them useful for troubleshooting. Before writing them at the user or system level, confirm that the relevant tools support the variables and understand their effect on internal addresses.

$env:HTTP_PROXY = "http://127.0.0.1:10809"
$env:HTTPS_PROXY = "http://127.0.0.1:10809"
$env:ALL_PROXY = "socks5h://127.0.0.1:10808"
$env:NO_PROXY = "localhost,127.0.0.1"

Get-ChildItem Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:ALL_PROXY, Env:NO_PROXY

Check routing and DNS after access succeeds

Once an explicit proxy request reaches the core but a specific site still fails, shift the focus from “did the app connect?” to “how did the core handle it?” Routing rules managed by v2rayN may choose direct or proxy outbound based on domains, IPs, or protocols. VLESS and VMess are part of the node protocol configuration; they do not determine whether a terminal reads the Windows system proxy.

When reading logs, match them to the same test request: note the test time, send one request, and check for the target domain, matched rule, and outbound error. If the request is completely absent, traffic has not entered the core. If it appears and clearly chose direct, inspect the routing rules. If it chose the proxy but then produced a resolution or handshake error, investigate node parameters and DNS.

• A subscription update only retrieves a list of configurations; it does not prove that every configuration can currently establish a connection.
• The system proxy determines how some applications find the local entry point, while routing rules determine where traffic goes after entering the core.
• Local DNS may resolve a hostname differently from proxy-side DNS. When testing SOCKS, compare socks5 with socks5h.
• After changing a rule, send one new request and verify it with fresh logs. Do not change the port, DNS, node, and routing at the same time.

When should you consider TUN?

TUN is useful for applications that do not support HTTP or SOCKS proxy settings, or when you need broader control of network traffic. It changes how traffic enters through a virtual network interface, so its coverage is usually wider than the system proxy. It also requires coordination with routing tables, DNS, administrator permissions, and other VPN-like connections.

If the problem affects only one terminal tool that supports proxy arguments, configure that tool or use environment variables first; the behavior is easier to observe and undo. Consider TUN when multiple applications do not read the system proxy and configuring them individually is costly. Do not use TUN as a substitute for fixing a missing local listener, a failed node handshake, or incorrect routing rules.

Review in order of least change

Change one condition at a time so you know which step restored the connection. The safest order is local listening, an explicit proxy test, application access settings, routing and DNS, and TUN last. Keep the port, command result, and log time for each step instead of relying on the visible state of a toggle.

1. In v2rayN “Settings” → “Parameter Settings,” record the current listening address and port, and confirm that the core is running.
2. Use Get-NetTCPConnection and Test-NetConnection to verify that the port is actually listening.
3. Use curl.exe --proxy to test the HTTP or SOCKS entry point separately, with a 10-second timeout.
4. Keep one proxy control source in the browser, fully exit and restart it, then compare with another browser.
5. Connect the terminal through command arguments or temporary environment variables; do not assume it will read the Windows system proxy automatically.
6. After confirming that the request entered the core, use the logs to check routing, DNS, the node protocol, and TLS.
7. Configure and verify TUN only when multiple applications cannot set a proxy individually and broader coverage is genuinely required.