System Proxy Set but Not Working? Troubleshoot Browsers and Command-Line Tools Separately

Establish a reproducible local proxy baseline

“System proxy enabled” only means the operating system has saved a proxy address. It does not prove that v2rayN’s local port is working or that every app reads those settings. A useful diagnosis should confirm three things: the core is running, the local inbound port is listening, and the test app is actually sending requests to that port.

Using a common v2rayN 7.x configuration as an example, the HTTP proxy may listen on 127.0.0.1:10809, while the SOCKS proxy may listen on 127.0.0.1:10808. These are typical examples only; use the local listening settings shown in the client. After an upgrade, backup import, or manual port change, ports from older guides may no longer apply.

1. On the v2rayN main screen, confirm that the target node is selected as the active server and that the core is not stuck in a failed-start or restart loop.
2. Open “Settings” → “Parameters”. Note the local HTTP and SOCKS listening ports and the listening address. If the menu labels differ by version, look for a page containing “local port” or “inbound settings”.
3. From the tray menu, select the enabled state corresponding to “Set system proxy”. Do not choose “Clear system proxy” or “Keep system proxy unchanged”. After switching, close and reopen the browser used for testing.
4. Temporarily select a node that can complete a latency test and switch routing to an easy-to-verify proxy mode. Restore the original routing rules after the baseline test passes.

Browser path: confirm that the system proxy is actually being used

Most desktop browsers read the operating system proxy by default, but a browser may retain its own proxy policy, extension settings, or an older background process. Refreshing a page after changing the system proxy is not always enough because background processes may continue using settings read at startup. Fully exit and reopen the browser to rule out this cached state.

Use a regular window for testing, pause extensions that can change proxy behavior, and choose an address you have not opened before. If ordinary pages load but a specific domain fails, the local proxy path is probably working. Next check routing, DNS resolution, and the remote destination instead of repeatedly toggling the system proxy.

What to check when the browser still connects directly

• Open the browser’s network settings and confirm that “Use system proxy” is selected rather than an old manually entered address.
• Check that the system proxy address is 127.0.0.1 and that its port matches the current v2rayN HTTP port.
• Disable extensions that may override proxy settings, then repeat the test in a regular window.
• Confirm that the system time and time zone are accurate. A large clock difference can cause TLS connections to fail and may look like a proxy problem.
• Check the v2rayN runtime log. If refreshing the page produces no new connection entry at all, the request usually never reached the local proxy.

Terminal path: specify the proxy with environment variables or explicit options

A command-line terminal is only a container for launching programs; it does not automatically send every network connection through the system proxy. The specific tool determines whether a proxy is used: some read HTTP_PROXY and HTTPS_PROXY, some accept only command-line options, and others require their own configuration file. So “the browser works but the terminal times out” usually means they are taking different network paths, not that the node suddenly failed.

For tools that support HTTP proxy environment variables, start by setting them temporarily in the current terminal session. Keep the proxy URL scheme as http://; even when the destination is an HTTPS site, the tool uses the HTTP proxy to establish a CONNECT tunnel. The examples below use 10809; replace it with the actual port shown by the client before running them.

Temporary Windows PowerShell setup

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

These three lines affect only the current PowerShell process and child processes launched afterward. The settings disappear when the window closes, making them useful for troubleshooting but unsuitable as a permanent solution. To view the current value, run $env:HTTPS_PROXY. To clear it, use Remove-Item Env:HTTP_PROXY and Remove-Item Env:HTTPS_PROXY.

Temporary Windows Command Prompt setup

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809
set NO_PROXY=localhost,127.0.0.1

Temporary setup for the current macOS or Linux shell

export HTTP_PROXY="http://127.0.0.1:10809"
export HTTPS_PROXY="http://127.0.0.1:10809"
export NO_PROXY="localhost,127.0.0.1"

If the tool supports SOCKS5, use an explicit option to test port 10808. In socks5h, the letter h means the proxy resolves the destination domain. This helps distinguish local DNS failures from proxy-path failures. Not every program reads ALL_PROXY, so an explicit option is usually better for the first test.

curl -v --proxy socks5h://127.0.0.1:10808 https://example.com/
curl -v --proxy http://127.0.0.1:10809 https://example.com/

• Explicit proxy command succeeds, but the regular command fails: the tool does not read the system proxy. Keep the command option or configure proxy environment variables.
• HTTP proxy succeeds, but SOCKS5 fails: verify the SOCKS port and local inbound type; do not swap the two ports.
• Both explicit proxy tests fail: return to v2rayN and check the listening status, active node, and runtime log.
• The command connects but the download breaks partway through: investigate remote connection resets, node stability, and restrictions imposed by the destination service instead of checking only the local port.

Use the actual error to locate the failing layer

Detailed terminal output is more useful than “unable to access”. With curl -v, first check whether it connects to 127.0.0.1 on the expected port, then check whether the proxy successfully establishes a tunnel to the destination. If the first step fails, the problem is local; if the local connection succeeds before a timeout, the issue has usually moved to routing or outbound connectivity.

How to read the runtime log

1. Inbound: Does a new connection from the local machine appear when the test command runs? No entry at all means the app is not using the proxy or the port is wrong.
2. Routing: Is the destination domain or IP sent to the proxy, direct, or blocked outbound? In split-routing mode, the matched rule matters more than node latency.
3. Outbound: Look for connection timeouts, refused connections, DNS resolution failures, or invalid authentication parameters. These errors are the ones directly associated with the remote node.
4. Return: Does the tunnel get reset soon after it is established? If it happens only with a specific destination, also consider that service’s connection policy.

Browser works but some commands fail: check DNS and split routing

The same domain may use different resolution paths in a browser and a terminal. A browser may use its own secure DNS settings, while terminal tools usually call the operating system resolver. With socks5://, resolution may happen locally; with socks5h://, the proxy resolves the domain. Different resolution locations can produce different addresses and routing results.

Split-routing rules can also create the impression that some programs work while others do not. The V2Ray or Xray core selects an outbound based on the domain, IP, port, and inbound tag. If the destination domain matches a direct rule, the request may leave through the direct connection even though the app is connected to the local proxy. The system proxy has not failed; the routing decision needs correction.

• First change the test destination to a stable, confirmed-accessible address so a single-site issue is not mistaken for a proxy failure.
• Test socks5h://127.0.0.1:10808 and http://127.0.0.1:10809 once each, then compare whether only the local-resolution path fails.
• In the v2rayN routing settings, check which rule matches the destination domain, then temporarily switch to a simpler proxy mode for comparison.
• If the failure occurs only after custom rules are enabled, check domain suffixes, IP ranges, and rule order one by one. An earlier rule may intercept the request first.
• After changing DNS or routing, restart the core and open a new terminal window to avoid interference from old connections and environment variables.

Common issues and recovery steps

After testing, roll back temporary changes so old variables, old ports, and new settings do not conflict the next time you start. This is especially important for environment variables saved persistently: even after v2rayN exits, command-line tools may keep trying to connect to the old local port, resulting in repeated connection refusals.

Final cleanup checklist

1. Restore the temporary global proxy mode to the original split-routing configuration.
2. Clear the HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY environment variables used only for testing.
3. Confirm that the system proxy port still matches the current local HTTP port in v2rayN.
4. Keep a text record of the working node, port numbers, test commands, and key errors so the next diagnosis can resume at the failing layer.
5. If switching nodes restores access, keep monitoring for a while to distinguish a temporary network fluctuation from a node configuration problem.