System Proxy Enabled but Not Working: Troubleshoot Browser and Terminal Separately

The switch is on, but traffic still bypasses the proxy. Check browser proxy handling and extension conflicts, then inspect terminal environment variables and proxy ports.

At a Glance

This guide is for cases where a node has been selected in v2rayN, the core is running, and the system proxy is enabled, but the browser or terminal still connects directly. First verify the local listening ports, then test browser integration and explicit terminal proxies separately. Finally, check the node, routing, and DNS. This identifies whether the issue lies with the app, system proxy, local port, or remote connection.

Separate the Four Stages Before Reinstalling Anything

“System proxy enabled” only means the operating system has saved a proxy address; it does not mean every app is using it. A complete connection passes through at least four stages: the app’s proxy settings, the system proxy configuration, the local listening port, and the remote node. If any stage breaks, the visible result may be an unreachable website or an unchanged exit IP.

Browsers usually read the system proxy, but their own proxy settings, enterprise policies, or proxy extensions can override it. Terminal tools are less consistent: some read HTTP_PROXY and HTTPS_PROXY, some require command-line options, and others ignore the system proxy entirely. So a working browser and a terminal that connects directly are not contradictory.

127.0.0.1
Common Local Listen Address
10808
Common SOCKS Example Port
10809
Common HTTP Example Port
4 stages
App, system, local, remote

Bottom line: verify the local port first

Do not treat 10808 or 10809 as fixed values. Use the listening settings currently shown in v2rayN, then access the same address with an explicit proxy command. If the explicit proxy works but the system proxy does not, check app integration or system settings. If both fail, inspect the core, ports, and node.

Browser Track: Confirm System Proxy Integration

The first browser check is not repeatedly refreshing the page; it is verifying the proxy server actually written to the operating system. On Windows, open Settings → Network & Internet → Proxy and check that the manual proxy points to 127.0.0.1 and uses the same port as v2rayN’s HTTP listener. On macOS, open System Settings → Network → your current network → Details → Proxies and verify the same values.

  1. Confirm the Active Node

    Select an available server on the v2rayN main screen, set it as the active server, and confirm that the core is not repeatedly starting and exiting.

  2. Rewrite the System Proxy

    First select “Clear system proxy,” wait three seconds, then select “Auto-configure system proxy.” This removes stale addresses and ports.

  3. Verify the System Port

    Open the system proxy page and confirm that the address is 127.0.0.1 and the port matches v2rayN’s current HTTP port. If the interface shows 10809, the system settings must also use 10809.

  4. Rule Out Extension Overrides

    Temporarily disable browser proxy-management extensions, fully quit the browser, and reopen it. Closing tabs alone usually does not rebuild the proxy process.

  5. Create a Clean Window

    Test with a fresh browser profile or temporary guest window to avoid cached network policies, extension rules, and reused connections affecting the result.

If one browser works while another fails, the local core and remote node are usually available; focus on the failed browser’s independent proxy settings. Some browsers offer “No proxy,” “Use system proxy,” or “Manual proxy.” Choose the system setting, or enter the confirmed local HTTP port manually.

Error: ERR_PROXY_CONNECTION_FAILED

Cause and fix: The browser tried to connect to the proxy, but nothing is listening at the configured local address—verify the port after 127.0.0.1 and make sure the v2rayN core is running.

Error: ERR_TUNNEL_CONNECTION_FAILED

Cause and fix: The browser reached the HTTP proxy, but the proxy could not establish a tunnel to the destination—switch to a tested working node and check whether routing rules reject the domain.

Error: Proxy server refused the connection

Cause and fix: The browser’s independent proxy settings still point to an old port, or the local listener has changed—switch back to the system proxy, fully quit every browser process, and try again.

Terminal Track: Specify the Proxy with Variables or Options

curl, package managers, and developer tools in a terminal may not read the desktop system proxy. The most reliable test is to specify a proxy for a single command. If that command succeeds, v2rayN’s local port and node are working; configure environment variables or tool-specific proxy options afterward.

You cannot identify an HTTP or SOCKS proxy reliably from the port label alone. Use v2rayN’s HTTP port for HTTP tests and its SOCKS port for SOCKS tests. socks5h delegates DNS resolution to the proxy, helping distinguish local DNS failures from proxy connection failures.

curl.exe --proxy http://127.0.0.1:10809 https://v2raylink.com/
curl --proxy socks5h://127.0.0.1:10808 https://v2raylink.com/

# Current PowerShell session
$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"

# Current Linux or macOS shell
export HTTP_PROXY="http://127.0.0.1:10809"
export HTTPS_PROXY="http://127.0.0.1:10809"
export ALL_PROXY="socks5h://127.0.0.1:10808"
Test result What it indicates Next step
Both HTTP and SOCKS succeed The local core, listening ports, and remote node are basically working Check whether the specific terminal tool reads environment variables
HTTP fails, SOCKS succeeds The HTTP port is incorrect or the corresponding listener is disabled Return to the parameter settings and verify the HTTP port
Both HTTP and SOCKS refuse the connection The core is not listening, the ports changed, or the process exited Check the core log and port usage
The connection is established but times out The local entry point is reachable; the remote node or routing may be failing Switch nodes and inspect the connection log

Error: curl: (7) Failed to connect to 127.0.0.1 port 10809

Cause and fix: No usable HTTP listener is available on that port—check the actual port in v2rayN, confirm the core is running, and retry with the correct port.

Error: curl: (5) Could not resolve proxy

Cause and fix: The proxy address format is invalid, commonly because of extra quotes, spaces, or a mistyped scheme—set it again in the format http://127.0.0.1:port.

Error: connection reset by peer

Cause and fix: The connection reached the local proxy, but the remote link was interrupted—switch nodes and verify that the server address, port, and transport parameters in the subscription are complete.

Client Track: Check Listeners, the Core, and Port Usage

When both the browser and explicit proxy commands fail, return to v2rayN and inspect the local service. The system proxy only points traffic to a local port; the V2Ray or Xray core actually accepts the connection. If the core fails to start, configuration generation fails, or another process occupies the port, the system proxy switch may remain on while every connection fails.

  1. Open Basic Settings

    Go to Settings → Parameters → Basic Settings and record the local listen address, HTTP port, and SOCKS port. Field order may vary between versions; use the values shown in the interface.

  2. Check the Core Type

    Go to Settings → Parameters → Core Type and confirm that the protocol used by the current node matches the selected core. VMess and VLESS configurations should also retain the transport parameters supplied by the subscription.

  3. View the Runtime Log

    Immediately check the log after restarting the core. Search for keywords such as failed, error, bind, refused, and invalid instead of relying only on the system-tray status.

  4. Change the Listening Ports

    If the log reports that a port is already in use, assign unused values to the HTTP and SOCKS ports, save, restart the core, and then write the system proxy settings again.

  5. Update the Subscription Configuration

    Run Update all subscriptions under Subscription groups, then select the active server again. If only one node fails, investigate its configuration before reinstalling the client.

After changing a port, update all three locations: v2rayN’s listening settings, the operating system proxy settings, and the terminal environment variables. Changing only one creates a mismatch where the client appears to be running while apps still connect to the old port. Existing terminal windows retain their old environment variables, so reopen the terminal or override them in the current session.

Error: bind: Only one usage of each socket address is normally permitted

Cause and fix: Another process is using the local listening port—stop that process or change the v2rayN port, then set up the system proxy again.

Error: failed to start core

Cause and fix: The core process could not finish starting, possibly because of a configuration error or file-access failure—look upward from the same timestamp in the log for the first error, fix the specified field, and restart.

Error: invalid config

Cause and fix: The generated node configuration contains missing or incompatible fields—update the subscription and reimport the node; avoid manually mixing VMess and VLESS transport parameters.

The Connection Is Established but Still Fails: Check Routing and DNS

A reachable local port does not guarantee that the target traffic uses the remote proxy. v2rayN split routing selects an exit based on domains, IPs, protocols, or rule sets. If the target domain matches a direct rule, the exit address will not change; if it matches a blocking rule, the browser may report a connection failure. Repeatedly toggling the system proxy will not help.

Symptom Most likely cause Verification
Explicit proxy succeeds, but the exit address is unchanged The target domain matches a direct-connection rule Temporarily switch to global proxy mode and test again
The domain fails, but a known address responds when accessed directly A local DNS resolution problem Use socks5h to test remote DNS resolution
Only one node consistently times out The node address, port, or transport parameters are incorrect Compare it with another node from the same subscription
VMess works, but one VLESS configuration fails That configuration has incomplete transport or security parameters Update the subscription and compare the handshake errors in the log

When troubleshooting routing, start with a short comparison test: keep the same node and access the same destination once with split routing and once with global proxy mode. If global mode works but rule-based routing fails, inspect the rule matched by the domain and its selected exit. Restore the normal split-routing configuration after testing; do not treat global mode as a permanent fix.

Bottom line: change one variable at a time

Keep the destination and node fixed, then change the app’s proxy method, port, or routing mode one at a time. This reliably isolates the issue to browser integration, terminal configuration, local listening, or the remote node instead of changing the node, DNS, and rules simultaneously and losing track of the cause.

Close the Loop: A Five-Minute Checklist

After troubleshooting, do not rely on an icon that merely looks normal. Confirm the result with concrete connection tests: the system port matches the client, an explicit proxy command succeeds, the browser works after proxy extensions are disabled, and the log shows no new startup errors. Use this sequence for a quick review if the same issue returns.

  1. Confirm that v2rayN has an active server selected and that the core log shows a completed startup.
  2. Record the actual HTTP and SOCKS ports; do not rely on the remembered values 10808 or 10809.
  3. Clear and reconfigure the system proxy, confirming the address is 127.0.0.1 and the port matches.
  4. Disable browser proxy extensions, fully quit the browser, and open it again.
  5. Use curl’s --proxy option to test the HTTP and SOCKS entry points separately.
  6. After the explicit proxy works, set the current-session environment variables for terminal tools.
  7. If only rule-based routing fails, check the matched route and DNS instead of changing the local port again.
  8. If only one node fails, update the subscription and compare with another node.
Why does the browser work while the terminal still connects directly?

Most terminal tools do not automatically read the desktop system proxy. Add a proxy option to a single command, or set HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY in the current shell. The right variable depends on the proxy types supported by the tool.

Does the system proxy port have to be 10809?

No. 10809 is only a common example; the port can be changed. The system proxy, v2rayN listening configuration, and terminal environment variables must all use the same actual HTTP port.

What does it mean if enabling global proxy mode restores access?

This usually means the local port and node are working, so the issue is more likely in split routing. Check the rules matched by the target domain, their order, and the corresponding exit; restore the routing mode suited to everyday use after testing.

Download Client Windows, macOS, Android, Linux