v2rayN System Proxy Not Working: Troubleshoot Browser and Terminal

System proxy settings don't control all traffic

v2rayN's system proxy feature primarily writes a local proxy address to the system settings. Whether an app uses those settings depends on the app itself. Browsers may follow the system settings, use an extension, or have their own configuration; command-line tools often rely on environment variables or their own config files. So there's no contradiction when a browser works but a terminal doesn't.

Keep the two routing layers separate: the app first decides whether to send a request to the local proxy; once the core receives it, routing rules determine whether it goes direct or through a proxy outbound. A request reaching v2rayN doesn't necessarily travel through a remote node, and enabling the system proxy doesn't mean every process will send requests through it.

• System proxy: Provides a proxy endpoint for apps that follow system settings; it does not take over every network connection.
• PAC: A script returns a proxy address or DIRECT based on the destination. A direct connection may be the result of a rule, not a failed proxy switch.
• Terminal proxy: Common sources include http_proxy, https_proxy, ALL_PROXY, or tool-specific options.
• TUN: This is a separate way to capture traffic. For an isolated test, turn TUN off first so it doesn't complicate the system-proxy diagnosis.

Check the local port before testing proxy egress

The examples below use SOCKS port 10808 and HTTP port 10809; these are not universal defaults. Some configurations expose a single mixed port that accepts both HTTP and SOCKS. In v2rayN, check the local listener options under “Settings” → “Parameter Settings,” then confirm in the startup log. Labels may vary by version, so rely on what your installation actually shows.

Run these commands in PowerShell. First check whether the ports are listening, then use curl.exe to specify the proxy explicitly. The executable name avoids PowerShell environments where curl is an alias for a different command. The destination is for connectivity testing; you can also use the HTTPS site you're troubleshooting.

# Check whether the example ports are listening
Get-NetTCPConnection -State Listen -LocalPort 10808,10809 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress,LocalPort,OwningProcess

# HTTP proxy: bypass the proxy bypass list and wait up to 20 seconds
curl.exe --noproxy "" --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -I https://example.com/

# SOCKS proxy: resolve the destination hostname through the proxy
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

When an HTTP proxy connects to an HTTPS destination, you’ll usually first see 200 Connection established. This only confirms that the CONNECT tunnel was created. Check whether the TLS handshake completes and the destination responds. If the site doesn't accept HEAD requests, remove -I and use -o NUL -D - to inspect the GET response headers.

Browser checks: system settings, extensions, and PAC

Test in a regular browser window first. Don't assume a private window disables every extension—some extensions are allowed to run in private browsing. A more reliable test is to temporarily disable proxy-related extensions or use a fresh browser profile, then fully close and reopen the browser.

1. Set the system proxy

   From the v2rayN tray menu, select “System Proxy” → “Set system proxy automatically.” Make sure the core is running. Here, “automatically” means the client writes the system settings; it doesn't necessarily mean that PAC is in use.

2. Check the system proxy endpoint

   In Windows 11, open “Settings” → “Network & internet” → “Proxy” and check the address and port under “Use a proxy server.” If “Use setup script” is enabled, note the script URL and confirm that it’s the configuration you intend to use.

3. Rule out extension overrides

   Open chrome://extensions/ in Chrome or edge://extensions/ in Edge and temporarily disable proxy-switching extensions. Then open the browser’s “Settings” → “System” or “System and performance,” select the option to open your computer’s proxy settings, and check the actual endpoint.

4. Check browser-specific settings

   In Firefox, open “Settings” → “General” → “Network Settings” → “Settings” and select “Use system proxy settings” for the test. With “Manual proxy configuration” or “Automatic proxy configuration URL” selected, Firefox may not follow the settings written by v2rayN.

5. Retest the same destination

   Temporarily disable any PAC script you don't need for the test. Make sure the manual proxy points to the actual HTTP or mixed port, then visit the same destination used in the command-line test. Restore your original script, extensions, and bypass rules afterward; don't permanently remove settings whose purpose you don't understand.

If only some domains bypass the proxy, check whether PAC returns DIRECT, review the system proxy exception list, and see whether the core's routing rules send the traffic direct. PAC makes its choice before a request reaches the core; core routing happens after it arrives. Logs from the relevant time can help identify which layer is responsible.

• Browser fails, but an explicit proxy command works: check extensions, browser-specific proxy settings, and system policies first.
• Browser works, but the access log shows a direct connection: check core routing instead of changing the browser port again.
• Disabling the script fixes the issue: check PAC domain matching, script availability, and browser cache.

Terminal checks: environment variables and tool-specific settings

The terminal itself doesn't determine how every command connects. curl.exe, package managers, and runtimes may each handle proxies differently. First list the proxy environment variables in the current PowerShell process, paying particular attention to NO_PROXY: a destination matching the bypass list may connect directly even when the proxy address is correct.

# List proxy variables in the current terminal process
Get-ChildItem Env: |
  Where-Object { $_.Name -match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$' }

# Check the Windows WinHTTP proxy separately as a different configuration
netsh winhttp show proxy

The output of netsh winhttp show proxy isn't simply a copy of the browser's system proxy settings. WinHTTP and per-user proxy settings are separate configuration systems. A result showing “Direct access” doesn't mean v2rayN failed to write the system proxy, and changing system-wide settings to fix a single command is usually not advisable.

This test changes only the current PowerShell session and restores the original values when finished. Replace the port with your actual HTTP or mixed port. For an HTTPS destination, using http://127.0.0.1:10809 as the proxy address is normal: the scheme describes how the client connects to the local proxy, not the destination site's protocol.

$names = @('http_proxy', 'https_proxy', 'ALL_PROXY', 'NO_PROXY')
$saved = @{}
foreach ($name in $names) {
  $saved[$name] = [Environment]::GetEnvironmentVariable($name, 'Process')
}

try {
  $env:http_proxy = 'http://127.0.0.1:10809'
  $env:https_proxy = 'http://127.0.0.1:10809'
  Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue
  Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue

  curl.exe --connect-timeout 10 --max-time 20 -I https://example.com/
}
finally {
  foreach ($name in $names) {
    if ($null -eq $saved[$name]) {
      Remove-Item "Env:$name" -ErrorAction SilentlyContinue
    }
    else {
      Set-Item "Env:$name" $saved[$name]
    }
  }
}

If this command succeeds, it only proves that the current curl.exe can use these variables. If another tool still fails, check that tool's proxy options, config files, and runtime account. Open terminals typically don't inherit user environment variable changes made afterward. If you confirm the variables need to persist, update the user variables and restart the terminal; don't start by applying a system-wide change that affects more than necessary.

Use the error to narrow down the cause—don't blame every failure on the node

For more detail, add -v to the test command and check whether the connection is to the local proxy or the destination. Before sharing output, redact proxy credentials, subscription URLs, and other sensitive parameters. These common curl errors point to different causes and fixes.

If the local listener is working but explicit HTTP and SOCKS tests both fail during egress, check the selected node, system clock, and remote configuration. For VLESS or VMess nodes, also verify the transport, TLS, and server parameters; toggling the system proxy won't fix these issues. After updating a subscription, make sure the selected configuration is still valid—not just that the list refreshed.

Common questions and reset checks

Finally, restore your original TUN, PAC, extensions, and environment variables, testing after each change. Keep a working explicit proxy command as a baseline: the next time an issue comes up, first test the local endpoint and egress, then check whether the app is sending traffic to it. This narrows down the cause and helps avoid mistaking a browser settings issue for a node problem.