v2rayN System Proxy Not Working? Fix Browser and Terminal Proxy Issues

1. System proxy and terminal proxy are separate paths

v2rayN’s system proxy feature writes a local proxy address to the operating system settings for apps that choose to use them. It does not take over every network connection on your device. A browser may use system settings, or have them overridden by an extension or organization policy. Command-line tools may instead read environment variables, their own configuration files, or command-line options.

In this chain, the system proxy only helps an app find the entry point. Once a request reaches the core, routing rules determine whether it goes direct, through a proxy, or gets blocked. So “the client received the request” does not mean “the request went through a remote node.” A browser may load a site because a direct-connection rule applies; that alone does not prove the node is working.

• System proxy: Provides a proxy address to apps that support it; it does not guarantee that every terminal tool will use it automatically.
• Local inbound: An HTTP, SOCKS, or mixed-protocol listener provided by the core. The address and protocol must match.
• Routing: Selects an outbound route after a request reaches the core. It does not make an app that connects directly use the proxy.
• TUN mode: A separate way to capture traffic. Turn it off during this isolation test to avoid confusion with the system proxy, then restore your previous setting when you’re done.

2. Check ports 10808 and 10809—don’t rely on outdated guides

Some older configurations use 10808 for SOCKS and 10809 for HTTP. Others provide a mixed-protocol listener on 10808 only. The port number does not determine the protocol, and it may change after an upgrade, migration, or manual edit. In v2rayN, check the local listener settings under Settings → Parameter Settings, then confirm the active values in the startup log. Labels may vary slightly between versions.

These PowerShell commands only check the two example ports; they do not change your configuration. Replace the ports if yours are different. In the output, OwningProcess is the ID of the listening process. To identify it, run Get-Process -Id process ID. The listener is usually the core process, not necessarily the GUI.

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

3. Isolate terminal issues with an explicit proxy request

Skip environment variables for now and specify the proxy address directly in the command. In Windows PowerShell, call curl.exe explicitly to avoid environments where curl is an alias for a different command. First run curl.exe --version to confirm it’s available. The destination below illustrates the test; you can use the same public HTTPS URL you’re troubleshooting in the browser so both tests follow the same route.

# Run only after confirming that 10809 is an HTTP listener
curl.exe -v --connect-timeout 10 --max-time 30 --noproxy "" --proxy http://127.0.0.1:10809 https://example.com/ -o NUL

# Run only after confirming that 10808 supports SOCKS5
curl.exe -v --connect-timeout 10 --max-time 30 --noproxy "" --proxy socks5h://127.0.0.1:10808 https://example.com/ -o NUL

--noproxy "" clears the bypass list for this test, preventing an existing NO_PROXY value from sending the request directly. If the HTTP mixed-protocol listener is actually on 10808, change the first command to use that port instead of copying 10809. socks5h lets the SOCKS proxy resolve the destination hostname; with socks5, the local machine usually resolves it first. The two use different DNS paths.

1. Check the local connection first. Verbose output should show a connection to the specified loopback address and port—not directly to the public destination.
2. Then check proxy negotiation. An HTTP proxy typically negotiates a CONNECT tunnel for HTTPS. With SOCKS, look for the corresponding connection handshake.
3. Finally, check the response. An HTTP status code means a response was received from the server. A response such as 403 is not necessarily a local port problem, nor does it mean the destination service is usable.
4. Check the core log at the same time. Confirm the destination hostname and selected outbound route. You can only determine whether the expected node was used if the log clearly records the outbound connection.

If an explicit proxy request works but a regular command fails, first check how that tool reads proxy settings. If the explicit request also fails, check the local listener, node connection, and routing instead of piling on more environment variables. Change one thing at a time and record the command, time, and result; that’s easier to reproduce than simply noting that a website won’t load.

4. Check browser system proxy settings, extensions, and bypass rules

Check the System Proxy status in the v2rayN tray menu. “Set system proxy” generally means the client writes the current proxy settings; it does not mean a PAC file is necessarily active. “Clear system proxy” removes the corresponding settings. “Do not change system proxy” means the client won’t modify them—it does not mean an existing system proxy is disabled.

1. In Windows, go to Settings → Network & Internet → Proxy. Check that the manual proxy address and port match the current HTTP or mixed-protocol listener, and see whether a setup script is also enabled.
2. Temporarily disable browser extensions that manage proxy settings. If an extension still points to an old port, the browser may ignore the correct system settings entirely.
3. Check whether the browser has its own manual proxy configured. In Firefox, go to Settings → General → Network Settings → Settings and check whether it uses the system proxy. For organization-managed browsers, also check for policy restrictions.
4. Close and reopen the browser, then retry the same destination while watching the core log for a new request. An existing connection or cached page does not prove that the new settings are in effect.

If the browser only works with a particular extension enabled, note the protocol and port the extension actually uses, then compare them with the system settings. This usually means the two paths are different—not that the system proxy button is broken. If the browser and terminal tests use different hostnames, test the same destination in both before comparing outbound routes.

5. Match terminal environment variables to the tool

Many terminal tools read HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY, but support, precedence, and configuration-file behavior vary by tool. First check which values are visible to the current process; don’t change system-wide variables yet. The PowerShell command below only reads them. If the output includes usernames, passwords, or internal addresses, remove them before sharing.

Get-ChildItem Env: |
  Where-Object { $_.Name -match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$' }

This example sets variables for the current PowerShell session, assuming you’ve confirmed that 10809 supports HTTP proxy connections. If these variables already have values, save them first and restore them after testing. Windows environment variable names are usually case-insensitive; other shells may treat case differently. For example, curl uses the lowercase http_proxy variable for HTTP proxies.

$env:http_proxy = 'http://127.0.0.1:10809'
$env:https_proxy = 'http://127.0.0.1:10809'

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

The value of https_proxy can still start with http://: the scheme describes how the tool connects to the proxy, not the protocol used by the destination website. To reach an HTTPS site, the tool can create a CONNECT tunnel through a regular HTTP proxy and establish TLS with the destination inside that tunnel. Changing it mechanically to https://127.0.0.1:10809 may make the tool attempt a TLS handshake with a local proxy that does not support TLS.

• NO_PROXY: If it contains the destination hostname, a domain suffix, or *, the request may bypass the proxy. Save the original value before testing a specific case; don’t permanently remove required internal-network exceptions.
• ALL_PROXY: Some tools use this as a general proxy setting. An old value can interfere with troubleshooting; check the tool’s documentation for precedence rules.
• Child processes: Programs launched from a terminal usually inherit its environment. An editor’s already-open integrated terminal may not pick up system variables changed later.
• Separate environments: WSL and containers have their own network contexts. 127.0.0.1 inside them may not point to the Windows host. Verify the actual network setup instead of assuming the host’s loopback address will work.

If the variables were unset before testing, use the command below to clear them from the current session. If they already had values, restore those values instead of deleting them. Closing the PowerShell window also ends session-level changes. Only consider persistent settings once the test succeeds, and check the proxy options for each command-line tool to avoid affecting unrelated tasks.

Remove-Item Env:http_proxy -ErrorAction SilentlyContinue
Remove-Item Env:https_proxy -ErrorAction SilentlyContinue

6. Diagnose by the stage of failure—not every timeout is a node issue

The examples below show common curl error snippets; addresses, timings, and TLS backend details vary by environment. First identify whether the failure occurred while connecting to the local listener, negotiating with the proxy, or reaching the destination. Then change the relevant setting.

Temporarily increasing log verbosity can help distinguish routing problems from connection failures, but logs may contain destination hostnames and node addresses. Restore the original log level after troubleshooting. When sharing logs, include only the necessary lines and redact subscription URLs, credentials, and personal browsing history.

7. Common questions and final checks

Finish by confirming three things: an explicit request connects to the correct local listener; the browser and terminal each use the intended proxy settings; and the core log shows the expected outbound route. This distinguishes a successful system proxy setup from an app actually using the proxy and a request taking the intended route—so the next issue won’t send you straight to reinstalling.

• Note the active listener address, port, and protocol, and keep one test command you can run again.
• Restore extensions disabled during troubleshooting, environment variables you changed, and any temporary log-level changes. Keep only settings you’ve confirmed work.
• If the problem persists, note the tool name, full command, failure stage, and redacted logs before tracing the same connection path further.