The system proxy only affects apps that use that setting; it does not route all traffic through v2rayN. This guide first verifies the local proxy endpoint, then checks browser system settings, extensions, and PAC, followed by terminal environment variables and tool-specific settings. Work through the tests in order to isolate the issue to the local listener, app configuration, routing, or node egress—without reinstalling the client as a first step.
1. Understand system proxy, app proxy, and node egress
v2rayN is a desktop client that manages configurations and starts the proxy core. The system proxy setting simply tells apps that honor it which local address and port to send requests to. If an app ignores this setting or overrides it with its own configuration, it may connect directly to the destination. Terminal tools such as curl, package managers, and developer tools may not use the same system proxy as your browser.
For troubleshooting, use one test URL and one active node throughout. Temporarily turn off TUN, and note the original system proxy and routing modes so you can avoid confusion from combining two traffic-capture methods. If your network requires TUN, note that up front; a successful test alone does not prove the system proxy is working.
- Local endpoint: Can the app connect to the proxy port actually listening on
127.0.0.1? - App configuration: Are the browser and terminal actually using this endpoint, rather than an old port or a direct connection?
- Node egress: Once the request reaches the core, does it use the expected node according to the routing rules and connect to the destination?
2. Test the local port with an explicit proxy
In v2rayN, open “Settings” → “Parameter Settings” and check the local listening port. In some versions, the relevant fields appear under “Core: Basic Settings.” Field names and layouts vary by version, so check the current UI and startup logs. This guide assumes you’ve confirmed that 10808 is a mixed inbound port that supports HTTP. If you use a separate HTTP port, replace the example port throughout.
In Windows PowerShell, use curl.exe to avoid versions of PowerShell that interpret curl as a different command. First check the listener, then specify the proxy explicitly. These commands work regardless of whether your browser uses the system proxy.
Get-NetTCPConnection -State Listen -LocalPort 10808
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com
On macOS and Linux, use the curl command below for the same explicit proxy test. Before testing, check NO_PROXY and no_proxy in the current session. Make sure neither contains the test domain or the wildcard *, or the request may bypass the proxy.
curl --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com
If the explicit proxy test fails, leave the browser alone for now
Fix the listener or core egress first. If the logs show the destination matched a direct-connection rule, specifying the local proxy alone does not prove traffic went through a remote node; check the routing result as well.
3. Browser won’t load pages: check system settings, extensions, and PAC
These steps focus on Windows desktops. On macOS, check the system proxy under “System Settings” → “Network” → the current network service → “Details” → “Proxies.” Proxy settings vary across Linux desktop environments, and setting them usually does not automatically add proxy environment variables to the terminal.
-
Set the system proxy
From the v2rayN tray menu, select “System Proxy” → “Automatically configure system proxy.” Don’t use “Clear system proxy” to enable it. “Do not change system proxy” keeps the current system setting, which may not point to the port used by this v2rayN session.
-
Check the system address
Open Windows “Settings” → “Network & internet” → “Proxy” and check that the manual proxy address and port match v2rayN’s current listener. Note whether “Use setup script” is enabled, so an old PAC script and the manual proxy don’t take turns affecting the result.
-
Disable proxy extensions
Temporarily disable browser extensions that manage proxies, then fully quit and reopen the browser. Chrome and Edge usually use the system proxy, but extensions or startup flags can override it. On managed devices, check browser policies too.
-
Check browser-specific settings
In Firefox, check the connection options under “Settings” → “General” → “Network Settings” → “Settings.” To test the system proxy, select “Use system proxy settings.” If manual proxy is selected, check the address, port, and exception list separately.
-
Review PAC rules
If you normally use PAC, restore the script and test the same URL. Make sure the script URL is reachable and returns a proxy auto-configuration script, then check whether the target domain resolves to
DIRECT. The script’s local port must also match the current endpoint.
PAC determines whether an app sends a connection to the proxy; v2rayN routing rules determine where it goes after reaching the core. These are separate stages. “PAC selected the proxy” does not mean “the core selected a remote node.” Record the original settings, temporarily switch to an explicit manual proxy for comparison, then restore your usual PAC setup.
- Only one browser fails: check its extensions, separate proxy settings, startup flags, and browser policies first.
- All browsers fail, but explicit curl works: check the system proxy address, port, and bypass list first.
- Only one website fails: check the PAC result for its domain, the routing rules, and the site’s own response.
4. Terminal bypasses the proxy: check environment variables and tool settings separately
Similar environment variable names do not mean the same thing. https_proxy specifies which proxy to use for HTTPS destination requests; it does not mean the proxy endpoint itself must use HTTPS. If the local endpoint is an HTTP proxy, its value can still be http://127.0.0.1:10808; the tool uses CONNECT to establish an HTTPS tunnel.
In PowerShell, check the existing variables first, then set the proxy for the current session. This example affects only the current terminal and processes it launches; it does not change the device-wide settings. For HTTP destinations, curl typically reads lowercase http_proxy, so don’t rely on uppercase HTTP_PROXY alone.
Get-ChildItem Env: | Where-Object Name -Match '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 --connect-timeout 10 --max-time 20 -I https://example.com
In Bash, Zsh, and similar shells, set the proxy for the current session as shown below. If an uppercase bypass variable already exists, check its value first, since tools may differ in how they handle variable case. Other terminals that are already open won’t pick up changes to your shell configuration file automatically.
env | grep -i proxy
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 --connect-timeout 10 --max-time 20 -I https://example.com
| Configuration location | What to check | Common misconception |
|---|---|---|
| Command-line options | curl’s --proxy and --noproxy | Explicit options or bypass rules can override environment variables. |
| Environment variables | http_proxy、https_proxy、ALL_PROXY | Assuming one variable will be used by every tool. |
| Bypass list | no_proxy、NO_PROXY | * or the target domain may bypass the proxy. |
| Tool-specific settings | For example, npm config get proxy and npm config get https-proxy | A tool may retain an old port and override the expected settings. |
| Isolated environments | Container, remote terminal, and subsystem networking and variables | The 127.0.0.1 in that environment may not be the host’s proxy endpoint. |
5. Use the actual error to pinpoint the failure
Here are some common error messages. The same error can have multiple causes, so compare the request time with the v2rayN logs. Before sharing logs, remove subscription URLs, node credentials, and personal browsing records; include only the relevant error lines and port details.
Error: curl: (7) Failed to connect to 127.0.0.1 port 10808
Cause and fix: The local connection was not established. Common causes include a core that isn’t running, an incorrect port, or an unreachable endpoint. Check the listener and core startup logs, then retry with the actual port. Don’t change remote DNS as a first step.
Error: ERR_PROXY_CONNECTION_FAILED
Cause and fix: The browser couldn’t connect to the configured proxy endpoint. Check the system address, extension settings, and the port returned by PAC, then run an explicit curl test against the same address.
Error: curl: (5) Could not resolve proxy
Cause and fix: The proxy address itself could not be resolved. The port, protocol, or a space may be in the wrong place. Make sure the variable is set to a complete value such as http://127.0.0.1:10808, then check the tool’s own proxy settings.
Error: curl: (6) Could not resolve host
Cause and fix: The destination hostname could not be resolved. First check whether the request is connecting directly or using a SOCKS mode that resolves locally. Check the bypass list and proxy type. If the proxy should resolve the hostname, compare with a confirmed working SOCKS5 endpoint using socks5h.
Error: curl: (28) Operation timed out
Cause and fix: The request did not complete within the time limit. A timeout alone does not identify the failure point. Check whether the core received the request and which outbound route it matched, then check node connectivity and the destination site separately.
Seeing 200 Connection established in an HTTP proxy test only means the CONNECT tunnel was accepted. Check the destination’s TLS handshake and final HTTP response too. A 403 or 405 from the destination does not mean the proxy is broken; some sites restrict access by source or reject HEAD requests. Don’t mask TLS errors by disabling certificate verification.
6. Compare test results, then restore your usual settings
To minimize interference from caching and temporary network changes, use the same test domain and record results in the order below. Change only one variable at a time, and note whether the request succeeds, the error message, and the actual outbound route in the logs. The timeout values in this guide are test parameters, not measured node speeds or network quality.
- Explicit proxy test: Use
--proxywith the confirmed local port and make sure the bypass list does not exclude the target. - Browser test: Disable proxy extensions, enable the system proxy, visit the same domain, and check the core logs.
- Terminal variable test: Remove explicit proxy options, keep only the current session’s environment variables, and retry the request.
- Direct-connection comparison: curl’s
--noproxy '*'bypasses the app-level proxy. If TUN is still running, this does not mean the connection bypasses the network layer. - Restore settings: Restore the original PAC, routing, and TUN settings, remove temporary variables, then test your usual apps.
Bottom line: get the local endpoint working before fixing app settings
If the explicit proxy works but the browser fails, focus on system settings, extensions, and PAC. If the browser works but the terminal fails, check environment variables, the bypass list, and tool settings. Only investigate routing, DNS, and node egress if the request reaches the core and still fails.
To remove temporary variables from the current PowerShell session, run Remove-Item Env:http_proxy, Env:https_proxy, Env:no_proxy -ErrorAction SilentlyContinue. In Bash or Zsh, run unset http_proxy https_proxy no_proxy. If these variables already had values, restore the values you recorded instead of deleting them. For more on configuration concepts, see the site’s troubleshooting guide or glossary.