System Proxy Not Working: Troubleshoot Browser and Terminal Connections Separately

Break down what “proxy enabled” really means

“The system proxy is enabled” only describes a set of proxy addresses in the operating system. It does not mean the proxy core is running, nor does it guarantee that every application will read those settings. Before troubleshooting, split the connection into four stages: the application sends a request, the application decides whether to use the system proxy, the local proxy port accepts the connection, and the V2Ray or Xray core processes the traffic according to routing rules.

If any stage breaks, the visible symptom may be “the page won’t open” or “the terminal still connects directly.” For example, v2rayN may have enabled the system proxy while its core is not running, so the browser sends the request to an unoccupied local port. Or the browser may work normally while a command-line program ignores the system proxy and connects directly to the destination.

Browser path

Browsers usually read the system proxy, but they may also use their own proxy options, extension settings, and secure DNS configuration. First check which layer the browser is actually using.

Terminal path

curl, package managers, and developer tools often read environment variables or their own configuration files. The system proxy switch usually does not override these programs automatically.

Verify v2rayN and the local listening port

Before changing browser or terminal settings, first prove that the local proxy can accept requests. Using desktop v2rayN as an example, three conditions must be met: a working server is selected, the core is running, and a local HTTP or SOCKS port is listening. Importing a subscription alone does not complete these steps automatically.

Check the server and core status

After updating the subscription, select a configuration from the server list and confirm that it is set as the active server.
Start the core and watch the main window’s status bar and log area. If it exits immediately, address port conflicts, invalid configuration fields, or protocol parameter errors first.
Open the local proxy settings and note the HTTP, SOCKS, or mixed listening port. The result may differ across versions and configuration migrations, so do not guess the port from an old tutorial.
Confirm that the listening address is the local loopback address. When the proxy is used only on this computer, the common address is 127.0.0.1.

The commands below assume that v2rayN’s local HTTP proxy uses port 10809. If the interface shows a different port, replace the number with the actual value. This test bypasses browser settings and tells curl to send an HTTPS request directly to the local HTTP proxy:

curl -I --proxy http://127.0.0.1:10809 https://example.com

If HTTP response headers are returned, curl can connect to the local port and the proxy path has completed at least one request. If the connection to 127.0.0.1 fails, check whether the core is running, whether the port is correct, and whether another process is using it. If the local connection succeeds but a handshake error, timeout, or server rejection follows, inspect the v2rayN logs and server configuration instead of repeatedly toggling the browser proxy.

Distinguish HTTP and SOCKS ports

HTTP and SOCKS proxies are different entry points. If you enter a SOCKS port in the system’s HTTP proxy field, the application may establish a TCP connection but fail the proxy negotiation. When v2rayN shows separate ports, use each strictly according to its type. To test a SOCKS proxy, let curl use socks5h:

curl -I --proxy socks5h://127.0.0.1:10808 https://example.com

The h in socks5h means the proxy resolves the destination hostname. This helps reduce interference from differences between local DNS results and resolution at the proxy exit. The 10808 value here is also only an example; use the value in the client’s current configuration.

Browser proxy not working: check each source of settings

Most desktop browsers follow the operating system proxy by default, but that default can be changed by the browser’s own configuration, extensions, enterprise policies, or an older process that is still running. Do not start by clearing everything. First determine where the browser is getting its proxy information.

Step 1: Verify the system proxy address

Open the operating system’s proxy settings and check that the address and port match the values currently shown in v2rayN. The address should normally point to this computer, not to the subscription server. The system proxy points to the local entry point; the client configuration and core handle the remote server.

v2rayN’s system proxy controls typically include options to set, clear, or leave the current value unchanged. Choosing “leave unchanged” only means that the operating system’s existing value will not be modified; it does not mean that value is correct. If you previously changed the port, switched configuration folders, or ran another proxy tool at the same time, an old port may still be saved in the system.

Step 2: Fully restart the browser process

After visible windows are closed, browser background processes may still be running. After changing proxy settings, exit the browser from the task manager or system tray, then open it again. If the browser offers a “use system proxy settings” option, make sure it has not switched to manual proxy or direct-connection mode.

Private windows can help rule out cached data and some extension effects, but they do not replace a process restart. A browser proxy extension may also bypass specific domains or use another port set. During testing, temporarily disable extensions that rewrite proxy rules and keep one clear system-proxy path.

Step 3: Test HTTP and HTTPS separately

Some system settings let you enter separate HTTP and HTTPS proxies. If only one is filled in, requests to the other type of address may connect directly or fail. Modern websites commonly redirect to HTTPS, so “the home page opens but the sign-in page does not” can also result from inconsistent values in the two protocol fields.

With a local HTTP proxy, HTTPS websites are usually forwarded through an HTTP CONNECT tunnel. You do not need to enter the local proxy address as the remote website’s HTTPS address. The important points are that the browser uses the correct proxy type and connects to a listening port.

Step 4: Check the bypass list

System proxy settings usually allow addresses that should bypass the proxy. Local addresses, LAN hostnames, and internal company domains often appear in this list. If the destination domain was added manually or covered by a broad wildcard rule, the browser will connect directly. Review the complete list during testing, not just its first line.

Direct access to localhost or 127.0.0.1 is usually the right behavior for local sites. When debugging a local development service, do not treat “the local address did not use the proxy” as a fault. What matters is whether an external destination was added to the bypass rules by mistake.

Terminal proxy not working: set proxy environment variables explicitly

The terminal is only a command interpreter; the specific program determines whether a proxy is used. curl, language package managers, build tools, and downloaders may read different variables or have separate configuration. The most common general-purpose entry points are HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY.

Current PowerShell session

The settings below affect only the current PowerShell session and the child processes it launches. They usually disappear when the window closes, making them suitable for troubleshooting and temporary downloads:

$env:HTTP_PROXY = "http://127.0.0.1:10809"
$env:HTTPS_PROXY = "http://127.0.0.1:10809"
curl.exe -I https://example.com

Even when the destination uses HTTPS, the value of HTTPS_PROXY can be http://127.0.0.1:10809. This describes the protocol the application uses to connect to the local proxy, not the protocol of the destination website. To remove the variables from the current session, run:

Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY
Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue

Current Windows Command Prompt session

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809
curl -I https://example.com

To clear a variable, leave everything after the equals sign empty:

set HTTP_PROXY=
set HTTPS_PROXY=
set ALL_PROXY=

Current macOS and Linux shell

export HTTP_PROXY="http://127.0.0.1:10809"
export HTTPS_PROXY="http://127.0.0.1:10809"
curl -I https://example.com

Many command-line tools use lowercase variable names. For compatibility, set the lowercase forms in the current session as well:

export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"

Clear the variables when testing is complete:

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY
unset http_proxy https_proxy all_proxy

Use the SOCKS entry point

If the tool supports SOCKS, specify the entry point through ALL_PROXY. This example still assumes SOCKS port 10808:

export ALL_PROXY="socks5h://127.0.0.1:10808"
curl -I https://example.com

Not every program supports socks5h, and not every program reads ALL_PROXY. If a tool ignores environment variables, check its own proxy settings. Do not assume that every package manager will adopt the same configuration just because curl works.

Set NO_PROXY to bypass local addresses

Development environments often need local services, container endpoints, and LAN interfaces to connect directly. Use NO_PROXY to declare the bypass scope:

export NO_PROXY="localhost,127.0.0.1,::1"
export no_proxy="$NO_PROXY"

Support for domain suffixes, wildcards, and network notation varies between tools. Start with explicit hostnames and loopback addresses instead of broad suffixes. If an external domain always connects directly, check whether it was mistakenly added to NO_PROXY.

The proxy receives the request—but routing and DNS still matter

Once the browser or curl has connected to the local port, the question changes from “is the application using the proxy?” to “how is the core handling the request?” V2Ray and Xray can route traffic based on domains, IPs, ports, protocols, and other conditions. After entering the core, a request may still be sent to a direct, proxy, or blocked outbound according to the rules.

Watch inbound and outbound connections in the logs

Open the v2rayN logs and make one request to a clearly defined destination. If no new connection appears at all, the application probably did not hand traffic to the local proxy; return to the browser settings or environment variables. If the logs show the destination domain and a connection record, the inbound path is working, so inspect the matched outbound and error details.

A subscription provides a set of server configurations, while the client’s routing rules decide which requests use the current server. These are separate layers. Switching servers changes the proxy exit, but it cannot fix a local rule that explicitly sends the destination domain direct.

Temporarily simplify the routing rules

When there are many custom rules, save the current configuration first, then validate with simple test rules. Do not change the node, DNS, system proxy, and routing all at once; even if it works, you will not know which change helped. Once the basic proxy path is confirmed, restore domain groups, IP rules, and application routing one by one.

VMess and VLESS are protocol configurations used between the client and server; the system proxy and environment variables only determine how an application connects to the local inbound. A browser does not need to understand VMess or VLESS—it only needs to send HTTP or SOCKS requests to the local listening port. Keeping these layers separate prevents you from looking for a browser proxy switch in protocol fields.

Identify differences in the DNS path

A browser may use its own secure DNS, while the operating system has a local resolution cache. With SOCKS, the hostname may also be resolved locally or by the proxy. These different paths can produce different results for the same domain in the browser and terminal.

If an IP address responds directly but the domain fails, focus on DNS. When testing SOCKS with curl, choose socks5h so the proxy resolves the hostname. On the browser side, check whether its DNS settings override the system behavior. Restart the browser after changing them and watch the logs for a new request instead of merely refreshing a cached page.

Narrow down the issue in a fixed order

Proxy failures are hardest to diagnose when many options are changed at once. The sequence below starts at the local port, with each step proving one fact. When a step fails, stay at that layer and resolve it.

Confirm that the core is running. Select a server and start v2rayN, then make sure the process does not exit immediately.
Record the actual ports. Read the HTTP and SOCKS listening ports from the client interface instead of reusing numbers from an old screenshot.
Test the local proxy explicitly. Use curl’s --proxy option to connect to the local port, excluding system proxy and environment-variable effects.
Check the browser’s source. Confirm that the browser follows system settings, disable extensions that rewrite proxy rules, and fully restart the process.
Check terminal variables. Read and set HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY, and check NO_PROXY as well.
Watch the core logs. Confirm that the request enters the local inbound and identify which outbound route it ultimately matches.
Handle DNS last. Compare local and proxy-side resolution only when domain resolution behaves abnormally.

Quick diagnosis for three common symptoms

Browser works, curl fails: The browser is probably reading the system proxy, while curl is not reading or has not been given proxy environment variables. Start with an explicit test using --proxy.
curl works with an explicit proxy, but the browser fails: The local port and core are basically working. Focus on the system proxy port, the browser’s independent settings, extension rules, and background processes.
The local port connects, but requests still time out: The application has found the proxy entry point. Continue by checking the server configuration, routing rules, DNS, and remote connection errors in the logs.

After troubleshooting, remember to clear temporary environment variables, or keep a clear set of enable and disable commands for daily development. Proxy ports may change when the configuration changes; permanently storing an old port can hide the next failure in a shell startup file. Keep the port, proxy type, and change location together in one place—it is more reliable than memorizing a fixed number.