How to Fix System Proxy Not Working: Troubleshoot Browsers and Command-Line Tools Separately

First, identify which traffic the system proxy affects

“v2rayN is running” and “application traffic is using the proxy” are two different things. After starting the Xray core, v2rayN creates SOCKS, HTTP, or mixed inbound ports on the local loopback address; the system proxy then writes one of those ports into the operating system settings. Only applications that actively read those settings send requests to the local port. A connected node only shows that the client has a working outbound path—it does not prove that browsers, terminals, or other programs are using it.

In a common v2rayN 7.x setup, the local SOCKS port may be 127.0.0.1:10808, while the HTTP port may be 127.0.0.1:10809. Always use the local listener settings under “Settings” → “Parameter Settings” as the source of truth; if you changed the starting port, update your test commands too. Sending an HTTP request to a SOCKS port, or entering a SOCKS address as an HTTP address, will appear as a connection failure.

Verify that v2rayN’s local port is available

Before checking the browser, rule out a local port that is not listening, a port conflict, or a core that failed to start. Switch v2rayN to the node you intend to use, then check the main window or runtime log for a successful startup message and confirm the current core type. The core handles VMess, VLESS, and other node parameters; the system proxy cannot fix an incorrect server address, port, transport, or user ID.

1. Confirm that the core started

   Select a node in the v2rayN main window, set it as the active server, and open the runtime log. Normally, the log shows core startup and local inbound listener messages. If the window keeps showing restarts or exits, fix the configuration error reported in the log first.

2. Check the listening ports

   Go to “Settings” → “Parameter Settings” and note the local SOCKS and HTTP ports. This guide uses SOCKS 10808 and HTTP 10809; do not copy these numbers if they differ from your interface.

3. Set the system proxy

   Open v2rayN’s “System Proxy” menu and choose the option to configure the system proxy automatically. Then open Windows “Settings” → “Network & Internet” → “Proxy” and confirm that the address is 127.0.0.1 and the port matches the client’s current HTTP listener.

4. Test the loopback connection

   Run Test-NetConnection 127.0.0.1 -Port 10809 in PowerShell. The result should show TcpTestSucceeded as True. If it is False, the issue is still with the local listener or a port conflict.

5. Run an explicit proxy test

   Run curl.exe --proxy http://127.0.0.1:10809 -I https://example.com. In a normal local test, loopback connection setup is usually under 0.01 seconds; the time to receive the remote response depends on the node route.

Browser troubleshooting sequence

If an explicit curl request through the proxy succeeds but the browser still connects directly, the node and local port are probably working. Focus next on how the browser obtains proxy settings. Fully quit and reopen the browser to avoid an old process retaining its connection pool or startup proxy state. Closing one tab is usually not enough to rebuild every network process.

Chromium-based browsers usually use the Windows system proxy, but standalone proxy extensions, managed policies, and startup parameters can override it. Firefox lets you choose “No proxy,” “Use system proxy settings,” or “Manual proxy configuration” in its own network settings. If only Firefox fails, open “Settings” → “General” → “Network Settings,” choose the system proxy, or enter the current v2rayN HTTP and SOCKS addresses manually.

• Confirm that the system’s manual proxy address is 127.0.0.1, not a stale LAN address.
• Confirm that the port matches the current v2rayN configuration, especially after switching configuration directories, which may restore the default port.
• Temporarily disable browser extensions that rewrite proxy rules, then restart the entire browser process and test again.
• Check the exception list in Windows proxy settings. A target domain on the bypass list connects directly.
• Test in both a normal window and a private window. Different results usually indicate differences in extension permissions or browser profiles.
• Do not judge the result from a single cached page. Open Developer Tools and test a new HTTPS request instead.

Command-line tools need separate proxy configuration

Command-line tools cannot all be assumed to read the system proxy automatically. In the same terminal, curl, PowerShell modules, runtime package managers, and standalone download programs may follow different rules. The most reliable approach is to pass the proxy address explicitly to one command first, then decide whether to set environment variables for the current session. This prevents tool configuration issues from being mistaken for v2rayN node failures.

Use v2rayN’s HTTP listener for an HTTP proxy address, such as http://127.0.0.1:10809. For SOCKS, use socks5h://127.0.0.1:10808; socks5h tells the proxy to resolve the destination domain, which can avoid mismatches between local DNS resolution and proxy-side results. Check each tool’s own proxy options to confirm that this format is supported.

# PowerShell: affects only programs started afterward in the current window
$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"

# Explicitly test the HTTP proxy
curl.exe --proxy http://127.0.0.1:10809 -I https://example.com

# Explicitly test SOCKS and let the proxy resolve the domain
curl.exe --proxy socks5h://127.0.0.1:10808 -I https://example.com

:: Windows Command Prompt: affects only the current window
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

# macOS or Linux shell: affects only the current session
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 port works but access still fails, check DNS and routing

A reachable local port only proves that the application reached the proxy entry point. After entering Xray, the request still passes through domain resolution, route matching, and proxy egress. If a rule sends the target through a direct outbound, external results may still reflect the local network. If the node server hostname cannot be resolved, every request routed through that node may time out. Watch the runtime log while reproducing the issue instead of relying only on the browser error page.

Reduce the test to one node, one browser, and one explicit curl command. Temporarily disable complex custom routing, keep private addresses direct, and send all other test requests through proxy egress. If this restores access, the issue is usually in rule order, domain sets, or the outbound tag. If it still fails, verify that the subscription’s server address, port, VMess or VLESS user parameters, TLS, and transport method match the server.

1. Find the test timestamp in the v2rayN runtime log and confirm that the target domain or address appears.
2. If the request appears but shows a direct connection, check the outbound tag matched by the routing rules and the rule priority.
3. If you see timeout, distinguish a timeout connecting to the node server from one connecting to the final destination.
4. If domain resolution fails, verify the node server address and switch to a working DNS configuration before restarting the core.
5. If no request appears at all, return to the application’s proxy settings. Do not change node protocol parameters first.

Choose the fix based on the test result

After troubleshooting, there is no need to change every setting at once. Keep one known-good node and let the test results guide the next step: a failed loopback port test points to the core or port; an explicit proxy that works while the browser fails points to the browser’s proxy source; a working browser with a failing terminal points to command options and environment variables; if every application reaches the log but outbound traffic fails, inspect DNS, routing, and node settings.