Use this guide if v2rayN is running but your browser can’t open a site, terminal requests still connect directly, or only some apps can connect. First verify the local proxy endpoint with an explicit proxy request, then check browser proxy controls, system PAC settings, and terminal environment variables. The examples focus on Windows, with Bash and Zsh commands included. Replace the sample port with the one your client is actually listening on.
1. Distinguish System Proxy, App Proxy Settings, and Routing
v2rayN’s “Set system proxy” option does not force all network traffic from your computer through the proxy. It changes the system proxy settings, and only apps that use those settings will connect through the local proxy endpoint. Browsers usually do, but extensions, browser policies, and separate proxy settings can override them. Whether command-line tools use the system proxy depends on how each tool is implemented.
Routing comes after the app connects to the proxy. Even in Global mode, requests that never reach the local listening port won’t be intercepted. Conversely, requests that do reach the core may still be routed directly by the active rules. First check whether the request reached the core, then identify its outbound route. Don’t confuse these two layers.
- Browser works, terminal doesn’t: Check terminal proxy options and environment variables first; there’s no need to switch nodes yet.
- Explicit proxy works, browser doesn’t: Check extensions, PAC settings, and the browser’s separate proxy configuration first.
- Explicit proxy also fails: Check the port, core status, and outbound logs first. The system proxy toggle isn’t the priority yet.
- Only some domains fail: Check bypass lists, routing rules, DNS, and the destination site’s response.
2. Verify the Local Proxy Endpoint on a Specific Port
Check the status bar at the bottom of the v2rayN main window for the local port, then go to “Settings” → “Parameters” to confirm the listening port and protocol. Depending on the version, the endpoint may be SOCKS, HTTP, or mixed. Don’t assume a port number from another guide matches your setup. The examples below assume 127.0.0.1:10808 is configured to accept HTTP proxy connections. If the port only supports SOCKS, use the SOCKS command below.
In Windows PowerShell, check that the port is reachable, then use curl.exe to specify the proxy explicitly. Using curl.exe avoids issues in some PowerShell environments where curl is an alias for a different command. The test URL is https://example.com/; it checks the request path and doesn’t guarantee access to any particular site.
Test-NetConnection 127.0.0.1 -Port 10808
curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 20 -I -v https://example.com/--noproxy "" clears the bypass list for this command so an existing NO_PROXY value won’t interfere with the test. If the endpoint only supports SOCKS5, use this command instead. socks5h sends the destination hostname to the proxy for resolution rather than having curl resolve it locally.
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 20 -I -v https://example.com/Takeaway: Verify the endpoint before checking automatic proxy settings
Once an explicit proxy request gets an HTTP response from the destination, check the browser and terminal’s automatic proxy settings. Seeing only 200 Connection established isn’t enough: it confirms the tunnel was established, but you should also check the TLS handshake and the destination’s response. A 403 response from the destination doesn’t mean the local port is broken.
3. Check Browser Extensions and Stale PAC Settings
The steps below use Chrome, Edge, and Firefox on Windows 11. Note your current proxy settings first, especially any script URL used on a work network. On managed devices, follow your administrator’s instructions rather than deleting existing settings. Incognito mode isn’t a reliable way to isolate extensions: some extensions can run in incognito, and system settings still apply.
-
Disable proxy extensions
In Chrome, open “Extensions” → “Manage extensions”; in Edge, open “Extensions” → “Manage extensions.” Temporarily disable extensions that control proxies, automatic switching rules, or network requests. Close all browser windows, restart the browser, then test the same URL.
-
Check the system proxy
In Windows, open “Settings” → “Network & internet” → “Proxy.” Under “Manual proxy setup,” check that the address and port match the local HTTP or mixed listening endpoint. For an address-only field, enter
127.0.0.1, not a full proxy URL. -
Check script settings
On the same page, check “Use setup script.” On a personal device, if an old PAC URL is still enabled, note it and temporarily turn it off, leaving only the proxy method you’re testing. Don’t change the script, manual port, and routing preset at the same time, or you won’t know which change fixed the problem.
-
Check separate proxy settings
In Firefox, open “Settings” → “General” → “Network Settings” → “Settings.” To use the system settings configured by v2rayN, select “Use system proxy settings.” If you keep a manual proxy, verify each port. Don’t enter a SOCKS-only port in the HTTP proxy field.
-
Reapply the settings
After confirming that the explicit local proxy test works, open “System proxy” from the v2rayN tray menu, select “Clear system proxy,” then select “Set system proxy.” Reopen the Windows proxy page and check that the address and port changed as expected.
PAC scripts choose a proxy based on conditions such as the URL or domain, and may send some requests directly. So the presence of a script URL doesn’t prove that every request uses v2rayN. If the browser says its settings are managed by your organization, or they revert after you turn them off, check management policies and other running proxy tools instead of repeatedly toggling the system proxy.
4. Check Terminal Variables, Protocols, and Process Inheritance
A browser that can connect doesn’t mean the terminal will use the proxy automatically. For tools such as curl, first test with the --proxy option from the previous section, then set environment variables for the current terminal session. https_proxy means “use this proxy for HTTPS destinations”; its value can still be http://127.0.0.1:10808. The client uses the HTTP proxy’s CONNECT method to establish a TLS tunnel to the destination, so the proxy URL itself doesn’t need to use HTTPS.
PowerShell: Check First, Then Set Variables for the Current Session
Get-ChildItem Env: | Where-Object Name -Match '^(http_proxy|https_proxy|all_proxy|no_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'
Remove-Item Env:all_proxy -ErrorAction SilentlyContinue
curl.exe --connect-timeout 5 --max-time 20 -I -v https://example.com/These assignments affect only the current PowerShell process and any child processes started afterward. They won’t update terminals, editors, or background tasks that are already running. Windows environment variable names are case-insensitive; on other systems, check both uppercase and lowercase versions. Don’t post proxy variable output containing credentials in a public forum.
Bash / Zsh: Clear Conflicts and Use Lowercase Variables
env | grep -iE '^(http|https|all|no)_proxy='
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY all_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 5 --max-time 20 -I -v https://example.com/curl handles the case of http_proxy specially, so lowercase variables are preferable for cross-platform troubleshooting. Some tools support ALL_PROXY as a general proxy variable, but don’t assume every tool reads it. NO_PROXY bypasses the proxy. If it includes the destination domain—or is set to *—requests may go direct even when the proxy variables are set. Matching syntax varies between tools.
- Fails only in one terminal window: Compare the variables in both sessions and check whether the older window still has the old port.
- Fails in the editor terminal: If you changed the variables after starting the editor, restart it so new terminals inherit the updated environment.
- Fails in a subsystem or container:
127.0.0.1may refer to the subsystem or container itself, not the host. Check the host address for your network setup; don’t assume the host’s loopback address will work. - curl works, but another tool fails: Check that tool’s proxy settings and official documentation. This alone doesn’t mean v2rayN is broken.
When testing is complete, remove the variables set in this session with Remove-Item Env:http_proxy,Env:https_proxy,Env:no_proxy -ErrorAction SilentlyContinue in PowerShell, or unset http_proxy https_proxy no_proxy in Bash / Zsh. If the variables had values before testing, restore those values instead of deleting them.
5. Identify the Failure by Its Exact Error
Keep the full command-line error and the time it occurred, then compare it with the corresponding request in the v2rayN logs. The examples below show common curl error messages; ports, destination addresses, and timeout values vary by setup. Error codes can narrow down the cause, but you’ll still need to compare them with an explicit proxy test. Don’t rely on a generic “connection failed” message alone.
Error: curl: (7) Failed to connect to 127.0.0.1 port 10808
Cause: curl couldn’t connect to the local endpoint. The core may not be running, the listening port may be wrong, or a local policy may be blocking the connection.
Fix: Check the actual listening port and core logs, then run Test-NetConnection. Verify which process is listening; don’t disable the entire firewall.
Error: curl: (5) Could not resolve proxy
Cause: The proxy server name couldn’t be resolved. Common causes include a typo in the proxy address or a malformed hostname in an environment variable.
Fix: For a local test, specify the confirmed loopback address and port explicitly. Check the variable values, then retry the same command.
Error: curl: (28) Connection timed out
Cause: The connection or transfer exceeded its time limit. A timeout alone can’t tell you whether the problem is the local endpoint, the remote outbound connection, or the destination site.
Fix: Use the -v output to see whether curl connected to the local port, then check the core logs from the same time for outbound connections and the destination’s response.
Error: curl: (60) SSL certificate problem
Cause: Certificate verification failed. Possible causes include the system clock, the certificate chain, or HTTPS inspection on the network. This doesn’t mean the request failed to enter the proxy.
Fix: Check the system date, certificate issuer, and system trust settings. Don’t make disabling certificate verification a permanent fix.
If the logs show that a direct routing rule matched the request, check the routing rules instead of reinstalling the browser. Protocols such as VMess and VLESS describe the proxy’s outbound connection; local apps usually connect through an HTTP or SOCKS endpoint. Putting a node protocol name in http_proxy won’t create a working local proxy connection.
6. Compare Test Results and Change One Layer at a Time
Change only one setting at a time and retest the same destination. Save three results: curl with an explicit proxy, curl using only environment variables, and browser access with proxy extensions disabled. This makes it easier to locate the issue and repeat the checks after updating the client, changing ports, or switching networks.
- Explicit proxy works, variable-based test fails: Check variable values, bypass lists, process inheritance, and tool settings.
- Both curl tests work, but the browser fails: Check extensions, PAC, separate proxy settings, and management policies.
- Port is reachable, but the explicit proxy test fails: Confirm the endpoint protocol matches, then check the core logs, node connection, and destination site.
- Everything works again: Restore extensions and existing scripts one at a time as needed, testing after each change to identify the conflict.
Takeaway: Verify the Same Request at Each Connection Layer
The system proxy button only indicates that a settings change was made; it doesn’t prove that a destination request used the proxy. Compare client logs, curl’s verbose output, and the app’s proxy settings to identify the failing layer instead of repeatedly switching Global mode.
If you need further help, note your operating system and v2rayN versions, listening protocol and port, failed command, and error time. Before sharing logs, remove subscription URLs, access tokens, node credentials, and personal destination addresses. Updating a subscription changes connection settings; it won’t add environment variables to the terminal or disable a browser extension’s control over proxy settings.