System Proxy Not Working? Fix Browser and Terminal Proxy Issues

At a glance

Turning on the system proxy only adds proxy settings to the operating system; it doesn’t mean every app will use them. Using desktop v2rayN as an example, this guide first checks the local listener and an explicitly proxied request, then walks through browser settings and terminal environment variables. Finally, it explains how to diagnose connection, DNS, and certificate errors. Use it when websites won’t load, the browser works but command-line requests time out, or you still can’t connect after closing the client.

System Proxy vs. TUN: Understand What Each One Routes

The system proxy is a connection setting for apps to read, not a switch that forces all traffic through a proxy. Browsers that follow system settings connect to a local proxy port; command-line tools that ignore those settings may still connect directly. v2rayN TUN mode routes traffic through a virtual network interface, involving permissions, routing, and DNS. It’s a separate mechanism from the system proxy.

App reads proxy settings Local proxy listener Core matches routing rules Outbound connection selected Destination responds

A failure at any point in this chain can prevent a page from loading. If system settings are correct but the core isn’t running, the problem is the local listener. If the listener works but the node connection fails, the problem is outbound. If only one browser fails, check its own proxy settings first. For troubleshooting, use one routing method at a time. Temporarily disable TUN and other proxy tools so overlapping routes don’t obscure where requests are going.

Browser and terminal both fail: Test the local port first, then check the node and routing logs.
Browser fails, but an explicitly proxied command works: Check extensions, PAC, and browser-specific proxy settings first.
Browser works, but the terminal fails: Check environment variables, tool settings, and the execution environment first.
Only some domains fail: Check bypass lists, domain routing, DNS, and the destination service.

Local Listener: Start with an Explicit Proxy Test

Open v2rayN, select a node, and check the runtime log for startup errors or port conflicts. Then read the listener address, port, and proxy type from the client settings or active configuration. The example below uses 127.0.0.1:10808 as an HTTP proxy listener. This is only an example, not a claim about the default port in every version. Replace it with your actual settings before running the commands.

10808

Example local port; use your actual configuration

5 sec

Example connection timeout

20 sec

Example total request timeout

On Windows, use the following PowerShell commands to test the port, then send a request to a public test domain through the explicitly specified proxy. curl.exe avoids cases where some PowerShell environments interpret curl as a different command. The example uses GET and discards the response body, avoiding false negatives from sites that don’t accept HEAD requests.

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808

curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 20 --output NUL --write-out "HTTP=%{http_code}\n" https://example.com/

TcpTestSucceeded : True only means the TCP port is reachable. It doesn’t prove the port accepts HTTP proxy connections or that the remote node works. An HTTP status code from an explicitly proxied request confirms that an HTTP response was received; if the status is 403 or another rejection, check whether it came from the destination or an intermediary. This test covers just one domain and doesn’t verify every use case.

Bottom Line: Test the Explicit Proxy Before Changing Browser Settings

If a request to the explicitly specified local proxy succeeds, leave the node and core settings alone and adjust only the failing app’s proxy settings. If the test fails, fix the listener or outbound connection first instead of repeatedly changing browser options.

Browser Troubleshooting: Extensions, PAC, and Bypass Lists

Browsers may use system settings, proxy extensions, or their own proxy configuration. Save your current settings, then check one item at a time, testing the same URL after each change. If a different browser works, don’t assume the node is fixed—the browsers may be using different connection routes.

Check the system proxy

In Windows 11, go to Settings → Network & internet → Proxy. Under Manual proxy setup, check that the address and port match the client’s current listener. If you use PAC, check the script address under Use setup script; don’t enter the script URL as the proxy server address.
Disable proxy extensions temporarily

In Chrome, go to Extensions → Manage Extensions and temporarily disable any extension that controls the proxy. Then go to Settings → System → Open your computer’s proxy settings and check the system configuration. If settings are managed by your organization, check the device policy; a regular toggle may not override it.
Check browser-specific settings

In Firefox, go to Settings → General → Network Settings → Settings. Check whether Use system proxy settings or Manual proxy configuration is selected. With manual configuration, the port and proxy type must match the local listener. Don’t enter an HTTP listener in the SOCKS field.
Check bypass rules

Check system proxy exceptions, the browser’s “No proxy for” list, and the result returned by PAC. If the test domain matches a bypass rule, the request will connect directly. In PAC, DIRECT means connect directly; PROXY 127.0.0.1:10808 sends traffic through that HTTP proxy listener.
Reconnect the browser

Close all browser windows and reopen the browser to rule out reused connections. Private browsing doesn’t necessarily disable every extension or bypass the system proxy. For a cleaner comparison, use a temporary browser profile with no extensions installed.

PAC is a script that chooses how to connect based on a URL or hostname; it doesn’t proxy everything automatically. A page may still fail if the script is unreachable, returns an outdated port, or directs the target domain to connect directly. Temporarily switch to a verified manual proxy listener for comparison. If that fixes the problem, restore PAC and check its rules. When finished, restore any original corporate network or LAN exceptions to avoid disrupting internal services.

Terminal Troubleshooting: http_proxy and App-Specific Settings

Command-line tools don’t always read the system proxy settings. First, use --proxy to specify the listener explicitly. Once that works, configure environment variables. Don’t start by changing global settings: test in the current terminal session first, then decide whether to make the change persistent. New terminals, editor-integrated terminals, and background services may inherit different environments, so results from one window don’t necessarily apply to other processes.

PowerShell: Change the Current Session Only

Get-ChildItem Env: | Where-Object Name -Match '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"

curl.exe --connect-timeout 5 --max-time 20 --output NUL --write-out "HTTP=%{http_code}\n" https://example.com/

https_proxy is generally used to specify a proxy for HTTPS destinations; its value doesn’t have to start with https://. Support for variable name casing varies by tool. curl handles the casing of http_proxy specially, so lowercase names are easier to reuse across environments. Also check ALL_PROXY and NO_PROXY; the latter may bypass the proxy for the target domain.

macOS and Linux: Check the Current Shell

env | grep -i 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 --output /dev/null --write-out 'HTTP=%{http_code}\n' https://example.com/

Symptom	Check first	What to do
Explicit proxy works; regular request fails	Variables aren’t being read, or a bypass rule applies	Check the variables and tool documentation; narrow the no_proxy scope and test again
curl works; other tools fail	The tool’s own proxy settings	Check startup arguments, configuration files, and runtime proxy options
New terminal works; existing terminal fails	The existing process inherited an outdated environment	Restart the terminal or its parent process
Container or virtual environment connection is refused	127.0.0.1 points to the environment itself	Use a host address reachable from that environment, and check the listener and firewall

Proxy extension settings aren’t automatically passed to the terminal, and terminal variables don’t change a browser that’s already running. In a container, 127.0.0.1 usually refers to the container, not the host. Don’t solve this by casually exposing the listener on every network interface. If cross-environment access is necessary, restrict the source addresses and configure appropriate access controls.

Diagnose Errors: Separate Connection, DNS, and TLS Issues

Keep the complete error from the failed command and check the client log from the same time. A browser error page only identifies part of the failure; detailed command-line output often makes it easier to distinguish an unreachable local listener from a failed remote handshake. Before sharing logs, remove subscription URLs, node credentials, and private browsing records.

Error: ERR_PROXY_CONNECTION_FAILED

Cause: The browser couldn’t connect to the configured proxy listener. Common causes include the client being closed, a changed port, or an extension still pointing to an old address.

Fix: Test the local port at the configured address and check which proxy settings the browser is actually using. Don’t start by switching remote nodes.

Error: curl: (7) Failed to connect

Cause: The TCP connection wasn’t established. Check the rest of the error to see whether the failed address is the local proxy or the destination server.

Fix: If the failed address is 127.0.0.1, check the listener port, core startup logs, and port conflicts. If it’s a remote address, check that part of the network path.

Error: curl: (5) Could not resolve proxy

Cause: The proxy hostname couldn’t be resolved, or a malformed variable caused the tool to treat an invalid value as a hostname.

Fix: Check the proxy URL’s scheme, host, and port. For a local listener, use its actual loopback address; don’t enter a PAC script URL as a proxy variable.

Error: curl: (6) Could not resolve host

Cause: The destination hostname couldn’t be resolved. This commonly happens on a direct connection or with a SOCKS configuration that resolves the hostname locally.

Fix: First confirm whether the request is bypassing the proxy, then compare local DNS resolution with resolution through the proxy. Don’t change all DNS settings based on this error alone.

Error: curl: (60) SSL certificate problem

Cause: Certificate chain verification failed. Possible causes include an incorrect system clock, a missing trusted certificate, or a TLS inspection device on the network.

Fix: Check the system clock and certificate chain, and configure trusted certificates as required by your organization. Don’t disable certificate verification as a permanent fix.

If the listener accepts SOCKS5, compare the two commands below to see where the hostname is resolved. With socks5://, curl resolves the destination locally; with socks5h://, the proxy resolves it. If only the second command works, investigate local DNS resolution first. The port shown here is still an example; don’t use these SOCKS commands with an HTTP-only listener.

curl.exe --noproxy "" --proxy socks5://127.0.0.1:10808 --connect-timeout 5 --max-time 20 --output NUL https://example.com/

curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 20 --output NUL https://example.com/

V2Ray protocol selection is a separate concern: the browser connects to a local HTTP or SOCKS listener, and the core then uses the configured outbound protocol, such as VMess or VLESS. Changing the outbound protocol won’t make an app that ignores the system proxy start reading its settings. V2Ray node tests are also only indicative under specific test conditions; they don’t verify browser bypass rules, terminal variables, or the destination website’s certificates.

Restore Settings and Retest: Avoid Leftover Proxy Settings

Restore all temporary changes when you’re done troubleshooting. If the client is closed while the system’s manual proxy still points to a local port, browsers following system settings will keep connecting to a listener with no program behind it. In v2rayN, select Clear system proxy from the system proxy menu before closing the client. If the client won’t start, disable the corresponding listener manually in your operating system’s proxy settings.

Browser: Restore any extensions you need and your original PAC settings. Make sure they no longer point to an old port.
Terminal: Close the test session or remove the temporary environment variables. If you added them to a startup file, check that file too.
Client: Restore your original routing and traffic-capture settings, and remove any global proxy settings used for comparison.
Retest: Record the results for direct connections, explicit proxy requests, browser requests, and regular terminal requests separately. Make sure the results are reproducible.

Remove proxy variables from the current session

# PowerShell
Remove-Item Env:http_proxy, Env:https_proxy, Env:all_proxy, Env:no_proxy -ErrorAction SilentlyContinue

# macOS / Linux shell
unset http_proxy https_proxy all_proxy no_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

These commands clear the corresponding variables from the current session. They don’t delete persistent Windows user variables or modify shell startup files. Note the original values before running them. If the variables are part of a network configuration provided by your organization, restore their original values instead of clearing them. For editor-integrated terminals, you may also need to restart the editor to discard variables inherited from its parent process.

Bottom Line: Keep the Settings That Work

If the local listener works, keep the port settings. If an explicit proxy request succeeds, leave the node configuration alone. If only one app fails, troubleshoot that app. Changing one variable at a time is usually more reliable than reinstalling the client or repeatedly updating the subscription.

Importing a subscription provides node configurations; it doesn’t configure a browser proxy or add environment variables to a terminal. On desktop, follow this guide to check v2rayN’s listener and app settings. On Android, importing a subscription into v2rayNG is only the first step—you must also start its VPN service through the app. That’s a different connection path from the desktop system proxy. To download v2rayNG or find another V2Ray client, choose v2rayN, v2rayNG, or v2flyNG for your platform on the downloads page, then follow the getting started guide to complete the basic setup.