First confirm that v2rayN’s local port is accepting connections, then check how your browser gets its proxy settings and how your terminal passes proxy parameters. This guide is for Windows users whose system proxy is enabled but some apps still connect directly. Follow the steps in order to distinguish a port that isn’t listening, browser overrides, command-line tools that ignore proxy settings, and traffic that reaches the client but is routed directly.
Start by separating system proxy settings, app-level proxy support, and routing
Keep your current node and routing settings for now. Don’t change your subscription, DNS, and core all at once. In the v2rayN main window, open “System Proxy” at the bottom and select “Automatically configure system proxy.” Some versions also offer this option in the tray icon’s right-click menu. Automatic configuration means the client writes the system proxy settings for you; it doesn’t mean every program will use the proxy, and it shouldn’t be confused with PAC script mode.
System proxy settings tell compatible apps which local address to send requests to. Routing rules decide whether traffic uses a proxy or goes direct after it reaches the core. Browsers usually read the current Windows user’s proxy settings; whether a command-line tool does depends on the tool. A browser test doesn’t tell you what’s happening in the terminal.
- Browser fails, explicit proxy command succeeds: Check browser extensions, custom proxy settings, and Windows proxy status first.
- Browser works, ordinary terminal commands fail: Check whether the tool needs proxy parameters or environment variables.
- Explicit proxy commands also fail: Check the local listener, node connection, and logs before changing browser settings.
- Request reaches the client but traffic still exits directly: Check which outbound route matched. Reaching the client doesn’t mean traffic uses a remote node.
Check the local port, then run an explicit proxy test
Open and look for local listening port options. Depending on the version, you may see a “Local mixed listening port” or separate HTTP and SOCKS ports. The examples below use 10808, a local port that supports HTTP proxying. Replace it with your actual port; don’t assume the example is a fixed default.
Run these commands in PowerShell. The first checks the TCP connection, the second shows the listening process ID, and the third tells curl to connect explicitly to the local HTTP proxy. Use curl.exe to avoid parameter differences caused by the curl alias in Windows PowerShell 5.1.
Test-NetConnection -ComputerName 127.0.0.1 -Port 10808
Get-NetTCPConnection -LocalPort 10808 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
curl.exe -q -v --connect-timeout 10 --max-time 30 --noproxy "localhost,127.0.0.1" --proxy http://127.0.0.1:10808 https://example.com/ -o NUL
Put -q first to skip curl’s default configuration file. --noproxy limits the bypass list for this request to local addresses, so an existing NO_PROXY value won’t accidentally send the test domain direct. example.com is just a connectivity example; repeat the command with the actual destination that’s failing and that you’re authorized to access.
- If
TcpTestSucceededisFalse, first check that the port matches, the core is running, and the startup log has no errors. - If the port is listening, check the process ID under
OwningProcess. If needed, runGet-Process -Idand append the ID you found. A reachable port doesn’t guarantee that the listener belongs to the current v2rayN core. - If curl shows a connection to
127.0.0.1, the app has reached the local proxy. HTTPS through an HTTP proxy will usually also show CONNECT tunnel negotiation. - If you get an HTTP response from the destination, that confirms this request received a response. Check the routing logs to see whether it used a remote proxy outbound.
Bottom line: Once an explicit proxy test works, check system settings
If the same destination works with --proxy but fails in your browser, leave the node and core settings alone for now. Check how the browser gets its proxy settings; this is easier to diagnose than reimporting your subscription.
Browser proxy not working: Check Windows settings and extension overrides
In Windows 11, open . In Windows 10, the path is usually . Make sure the proxy server address and port match v2rayN, and check whether the exceptions list includes the domain you’re testing.
- Write the settings again. In v2rayN, select “Clear system proxy,” then “Automatically configure system proxy.” Return to Windows Settings and confirm the address and port were actually updated—not just that the client menu changed.
- Temporarily disable proxy-management extensions. On your browser’s Extensions page, turn off any extension that controls proxy settings, then fully quit and reopen the browser. Incognito or private browsing may not rule out an extension issue; some extensions are allowed to run there.
- Check where the browser gets its proxy settings. Edge and Chrome usually use the system settings, but launch arguments and organizational policies can override them. In Firefox, open and select “Use system proxy settings.”
- Rule out stale processes and connections. Save your work, close all browser windows, make sure background processes have exited, then request the page again. Refreshing an existing tab may reuse a connection that was already established.
- Check whether the settings keep changing. If the port reverts shortly after you set it, check for other network tools, startup apps, and organizational policies. On a managed device, ask your administrator to check the policy instead of repeatedly overriding it.
If your browser can load ordinary pages but one site has a problem, check that site’s routing, DNS, and certificate errors. An HTTP 403 or 429 means the site returned a response; access policies or request limits may be involved. Don’t assume the system proxy is off.
Terminal proxy not working: Specify a proxy first, then set process environment variables
Start with the earlier curl.exe --proxy test. If it works, decide whether to set environment variables for your terminal. Windows system proxy settings aren’t a universal switch for command-line programs: some read HTTP_PROXY and HTTPS_PROXY, some use their own settings, and others require explicit parameters.
PowerShell: Set variables for the current window and its child processes
Check and note the current variable values before setting temporary ones. The http:// in these addresses describes the protocol the app uses to connect to the local proxy. Even when the destination uses HTTPS, a local HTTP proxy address usually has this format; CONNECT creates the tunnel.
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'
curl.exe -q -v --connect-timeout 10 --max-time 30 https://example.com/ -o NUL
The second test deliberately omits --proxy to check whether the tool reads environment variables. curl has case-specific conventions for HTTP proxy variables, while Windows environment variable names are case-insensitive. If you use these commands on a case-sensitive system, check the tool’s documentation again. For HTTPS tests, pay particular attention to HTTPS_PROXY.
Command Prompt: Use set, not PowerShell syntax
set "HTTP_PROXY=http://127.0.0.1:10808"
set "HTTPS_PROXY=http://127.0.0.1:10808"
set "NO_PROXY=localhost,127.0.0.1"
curl.exe -q -v --connect-timeout 10 --max-time 30 https://example.com/ -o NUL
- Running processes won’t inherit new values automatically. Start the tool from the current terminal for it to inherit the variables set here. Already-running editors and background tasks need to be restarted.
- Don’t rush to use setx. It persists variables but won’t update the current terminal. For troubleshooting, start with process-level settings to avoid leaving a persistent proxy that points to a client that’s no longer running.
- Check NO_PROXY. If the destination domain matches the bypass list, the tool may connect directly. If
ALL_PROXYis already set, note its value and check whether it points to an old port. - Check each runtime environment separately. In a container or a separate Linux subsystem,
127.0.0.1may not point to the Windows host. Don’t assume results from a local Windows terminal will apply there.
To test a PowerShell web request, specify the proxy explicitly: Invoke-WebRequest -Uri 'https://example.com/' -Proxy 'http://127.0.0.1:10808'. How default proxies and environment variables are handled varies across PowerShell and runtime versions. One successful command doesn’t guarantee another will work.
Use the actual error to pinpoint the failure: connection refused, tunnel failure, or certificate error
First identify whether the error came from the browser, curl, or the core log, then locate where the request failed. The snippets below are common examples; exact wording varies by version and destination. Don’t assume a timeout means your subscription is invalid, or that every error is caused by DNS.
ERR_PROXY_CONNECTION_FAILED
Cause: The browser couldn’t establish a working connection to the configured proxy. This commonly happens when the proxy port stops listening or an extension changes the settings.
Fix: Check the proxy address the browser is actually using, run Test-NetConnection against the same port, and confirm which process is listening.
curl: (7) Failed to connect
Cause: The TCP connection couldn’t be established. If the error mentions 127.0.0.1 and a local port, the failure happened before the request reached the proxy.
Fix: Check the core startup log, listening address, and port conflicts. Don’t start by changing the remote node’s transport settings.
ERR_TUNNEL_CONNECTION_FAILED
Cause: The browser couldn’t establish a tunnel through the proxy. The port may use the wrong protocol, or the proxy may be unable to connect to the destination.
Fix: Make sure you entered an HTTP or mixed-protocol listening port. Then use curl’s verbose output and the core log from the same time to investigate further.
curl: (60) SSL peer certificate or SSH remote key was not OK
Cause: Certificate or trust-chain validation failed. That doesn’t prove the request never went through the proxy.
Fix: Check the system clock, the destination certificate, and certificate policies on managed networks. Don’t disable certificate validation as a permanent fix.
If the local port is reachable but the request stalls after tunnel setup, check the destination domain, node connectivity, and TLS logs. With an HTTP proxy, the destination hostname is normally sent to the proxy for handling. If you test with SOCKS instead, socks5:// and socks5h:// resolve hostnames in different places; with the latter, the proxy resolves them. Be clear about which one you used—these aren’t identical tests.
Request reached v2rayN: Check routing, not the proxy entry point
Open the log panel in the main window. Set a log level that shows connection details, refresh the destination once, then search by time for the domain, destination port, and outbound route. Logs usually come from the selected core, and field names vary by core and version. If there’s no entry, the log level may be too low; it doesn’t necessarily mean the app never reached the client.
- Log shows a direct outbound: Check the active routing preset and custom rules. A direct route may be intentional. Temporarily select a route that explicitly sends this destination through the proxy, then repeat the same request.
- Log shows a proxy outbound, but the remote connection fails: Check the active node, server address and port, and the transport and security parameters required by the server. Browser extensions are no longer the first thing to investigate.
- Only some domains fail: Compare the matched rules and DNS results for each domain. Don’t reset the entire subscription because one domain failed.
- Traffic counters change but the page still fails: The traffic may come from another app or a background request. Match the test time and destination domain to the log entries.
Bottom line: Change one entry point or rule at a time
First turn off TUN and test system proxy mode with just that one variable. Then compare the browser, an explicit proxy command, and a command that uses environment variables. Consider TUN only after confirming that an app doesn’t support proxies. Don’t enable multiple entry points at once and assume the issue is resolved just because a page loads.
TUN is a separate way to route traffic and may involve a virtual network adapter, permissions, and routing tables. It can help with apps that don’t read proxy settings, but it can’t fix incorrect node parameters and doesn’t guarantee that all network traffic will be captured. Before configuring it, read the TUN mode guide and keep your current settings in a restorable state.
After testing, clear temporary variables and keep a record of what you found
Restore your original routing, log level, and browser extension settings first. If the temporary variables didn’t exist before, you can remove them in PowerShell using the commands below. If they already had values, restore those values instead of deleting them. Closing the terminal usually ends the process-level variable settings for that session, but child processes that are already running may keep their own copies.
Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue
- Record your environment: Windows version, v2rayN version, active core and version, and local listening port.
- Record these three results: Whether browser access, curl with an explicit proxy, and curl using environment variables each succeeded.
- Record the failure stage: Local port connection, CONNECT tunnel, TLS verification, HTTP response, or the core’s connection to the remote node.
- Prepare logs before asking for help: Keep timestamps and the surrounding error context, but redact subscription URLs, credentials, share links, and sensitive destination details.
When you exit normally, let v2rayN clean up the system proxy settings. If the client crashes and your browser reports a proxy connection failure, check Windows proxy settings to see whether they still point to a stopped local port. For installation and initial setup, follow the connection verification steps. For system proxy and routing concepts, see the proxy modes guide.