This guide uses v2rayN on Windows and is for cases where the system proxy is enabled but a browser or terminal still cannot connect. First test the local proxy with an explicit proxy request, then check browser extensions, auto-configuration scripts, and terminal environment variables. This helps pinpoint whether the issue is how an app uses the proxy, the local listening port, the core's outbound connection, or routing rules—without repeatedly switching nodes.
1. System Proxy, Routing, and TUN: Know the Difference
v2rayN's system proxy setting writes proxy details to the operating system; it does not route every network connection through the proxy. An app must read those settings to send requests to the local proxy port. Browsers typically support the system proxy, but whether command-line tools use system settings, environment variables, or their own config files depends on the tool.
Start troubleshooting with TUN mode off, so a virtual network adapter does not take over traffic and mask a system proxy issue. If you use another tunnel or enterprise networking tool, note its current state; don't delete its configuration. All ports in this guide are examples—use the listening port currently shown in v2rayN.
| Layer | What it does | What it does not prove |
|---|---|---|
| System proxy | Tells apps that follow system settings which proxy endpoint to use | That all terminal and background processes are using the proxy |
| Local inbound | Accepts HTTP or SOCKS requests on a loopback address and specified port | That the remote server connected successfully |
| Core routing | Selects direct, proxy, or blocked outbound traffic for incoming requests | That every incoming request goes through the remote proxy |
| TUN mode | Routes matching network traffic through a virtual network adapter | That apps are correctly using the system proxy |
2. Check the Local Port, Then Test with an Explicit Proxy
In v2rayN, open Settings → Parameter settings to check the local listening configuration, then check the port details at the bottom of the main window. Depending on the version, you may see separate HTTP and SOCKS ports or a mixed port, and the labels and layout may differ. A mixed port can accept the supported protocols; a SOCKS-only port cannot be used directly as an HTTP proxy.
These numbers aren't fixed defaults for every version, and you don't need to listen on both ports. The PowerShell commands below assume you've confirmed that 127.0.0.1:10808 supports HTTP and SOCKS. Use curl.exe instead of curl to avoid parameter differences caused by the alias in some Windows PowerShell environments.
# Check whether the TCP port accepts connections
Test-NetConnection 127.0.0.1 -Port 10808
# Find the listening process and confirm it belongs to the current core
Get-NetTCPConnection -State Listen -LocalPort 10808 |
Select-Object LocalAddress, LocalPort, OwningProcess
# Specify an HTTP proxy; exclude only local addresses
curl.exe --proxy http://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 20 -I https://example.com
# Specify SOCKS and let the proxy resolve the destination hostname
curl.exe --proxy socks5h://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 20 -I https://example.comTcpTestSucceeded : True only confirms that the TCP port is reachable. If the HTTP proxy test returns 200 Connection established, that only means the CONNECT tunnel was allowed; check the subsequent TLS handshake and response from the destination too. Even if the destination returns 403 or 405, first identify whether the response came from the destination, proxy service, or an intermediary network device. The status code alone does not show that the system proxy failed.
Bottom line: If an explicit proxy request works, check the app's settings
If an explicit HTTP proxy request gets a response from the destination but a regular browser visit fails, first check whether the browser is using a different proxy endpoint. Don't start by changing the subscription, transport protocol, or remote port.
3. Browser Proxy Not Working? Check Extensions and Custom Proxy Settings
Browser extensions can override the system proxy. If one browser window works and another doesn't, compare their browser profiles and extension settings before blaming the node. Incognito mode is not a reliable extension-free test: extensions allowed in incognito can still run.
-
Enable the system proxy
In the Windows version of v2rayN, open the System proxy menu at the bottom of the main window and select Automatically configure system proxy. This action writes proxy settings to Windows; it does not mean you're using PAC mode.
-
Check the system proxy endpoint
Open Windows Settings → Network & Internet → Proxy and check the manual proxy address and port. The loopback address should point to this computer, and the port should match the HTTP or mixed endpoint that passed your test.
-
Disable proxy extensions
In Chrome, go to Extensions → Manage extensions and temporarily disable any extension that controls the proxy. In Edge, go to Extensions → Manage extensions. Then close all related browser processes, reopen the browser, and revisit the same test address.
-
Check browser-specific settings
In Firefox, go to Settings → General → Network Settings → Settings and select Use system proxy settings. If manual proxy settings are selected, check the port; don't assume Firefox will update it automatically when Windows settings change.
If the system proxy address changes right after it is set, another program or organizational policy may be managing it. Close any duplicate proxy apps and check again; on a managed device, ask your administrator about the policy. You don't need to change the listening address to 0.0.0.0 for a browser on this computer to connect to the proxy, and disabling the entire firewall should not be your first troubleshooting step.
4. PAC Mode: Check the Script URL and Its Return Value
PAC is short for proxy auto-configuration. A browser calls FindProxyForURL(url, host) in the script to decide whether to use a proxy or connect directly. PAC rules are separate from routing.rules in the v2rayN core: PAC can keep a request from reaching the core at all, while core routing only handles requests that have reached the local inbound.
- Check whether a script is enabled: In Windows Settings → Network & Internet → Proxy → Use setup script, check the script address. If you only intend to use the manual system proxy, note the current address and temporarily turn the script off to test.
- Check that the script is reachable: If the script points to a local port, confirm that the corresponding service is still running. A script address left behind by an old client may no longer be available.
- Check the return value:
DIRECTmeans connect directly;PROXY 127.0.0.1:10808sends the request to that HTTP proxy endpoint. If the script points to an old port, requests can fail even when the current core is working. - Check the fallback:
PROXY 127.0.0.1:10808; DIRECTincludes a direct-connection fallback. If the proxy is unavailable, the browser may try to connect directly, which can make some sites appear to work.
5. Terminal Proxy Not Working? Check Environment Variables and Tool Settings
A browser working while a terminal fails often comes down to different sources of proxy settings. Many command-line tools don't automatically read the Windows user proxy settings; others have their own config files. First test with the explicit proxy command from section 2. Then, if needed, set environment variables for the current terminal session—don't change global settings right away.
# Show proxy environment variables inherited by the current PowerShell process
Get-ChildItem Env: |
Where-Object { $_.Name -match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$' }
# Set the proxy for this session and any child processes it starts
$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"
# Test whether curl.exe reads the current environment variables without --proxy
curl.exe --connect-timeout 10 --max-time 20 -I https://example.comThe name https_proxy means “proxy for HTTPS destinations.” Its value can still use http://; HTTP CONNECT creates the tunnel. Don't switch the local endpoint to https:// just because the destination uses HTTPS. Check the specific tool's documentation to see whether it supports environment variables and which names it recognizes. curl treats the HTTP proxy variable's capitalization specially, so use lowercase http_proxy in cross-platform scripts.
| Check | Common issue | What to do |
|---|---|---|
NO_PROXY | Includes the destination hostname or *, causing it to bypass the proxy | For this test session, keep only the necessary local addresses, then try again |
ALL_PROXY | Still points to an old SOCKS port | Check the protocol and port; make sure multiple variables aren't pointing to conflicting endpoints |
| Terminal process | Was started before the system variable changed | Restart the terminal and its host app, or set the variable directly in the current session |
| Tool config file | The tool's own proxy option overrides the expected setting | Check the tool's effective configuration and compare it with a test using its explicit proxy option |
WSL, containers, and remote terminals each have their own network environment. 127.0.0.1 inside them may not point to the listening endpoint on Windows, so a failure there doesn't necessarily mean the Windows system proxy is broken. First establish a baseline test on Windows, then check the virtual network and host address separately. Don't open a proxy port on every network interface to work around this.
These assignments affect only the current PowerShell session and processes started from it. Close the session to end the temporary settings. If the session already had proxy variables in use, record their original values and restore them after testing.
6. Use Errors and Logs to Narrow Down the Cause
If an explicit proxy request also fails, check in this order: local listener → protocol match → remote connection → destination response. The examples below show curl error snippets you might see; the exact wording varies by version and operating system. Error codes can narrow down the problem, but a single error rarely identifies one definitive cause.
curl: (7) Failed to connect to 127.0.0.1 port 10808
Cause: The local TCP connection could not be established, often because the core isn't running, the port is wrong, or a local connection is being blocked.
Fix: Recheck the listening port and process, then review the v2rayN core startup logs. Don't change the remote protocol first.
curl: (5) Could not resolve proxy
Cause: The hostname in the proxy address could not be resolved, or the proxy variable value may be malformed.
Fix: For a local test, specify http://127.0.0.1:10808 explicitly. Check that the variable value doesn't contain quotes, spaces, or an invalid hostname.
curl: (28) Connection timed out
Cause: The connection or transfer exceeded its time limit. It may be stuck at the proxy endpoint, remote server, or destination response stage.
Fix: Add -v to see which stage completed last, then compare with the core logs from the same time to distinguish an unreachable local endpoint from a remote timeout.
curl: (60) SSL certificate problem
Cause: Certificate verification failed. Possible causes include the system clock, the certificate trust chain, or TLS inspection on the network.
Fix: Check the system clock and certificate source. Don't skip certificate verification as a permanent fix, and don't assume this error means the system proxy isn't working.
No new log entries doesn't necessarily mean the request never reached the core; the current log level may not record every request. In v2rayN, go to Settings → Parameter settings and check the logging options. Temporarily enable more detailed logs, restart the core, and run another test while noting the time. Restore the previous log level afterward. Before sharing logs, remove subscription URLs, credentials, and other sensitive information.
Bottom line: Change one setting at a time
Use the same test destination and record the results for explicit proxy requests, browser system proxy, and terminal environment variables. Continue troubleshooting the core and remote connection only if the explicit proxy test also fails; otherwise, focus on how the app accesses the proxy.
- Explicit proxy works, browser fails: Check extensions, custom proxy settings, PAC, and organizational policies.
- Browser works, terminal fails: Check environment variables, process inheritance, and the tool's own settings.
- Port is reachable, proxy request fails: Check the inbound protocol, outbound logs, server configuration, and DNS.
- Request succeeds but exits through the wrong route: Check whether PAC returns DIRECT and which outbound the core actually selects.