System Proxy Not Working: Browser Uses the Proxy but Terminal Does Not? A Step-by-Step Troubleshooting Guide

“The webpage opens, but terminal commands still connect directly” usually does not mean the node itself is down. Different applications read proxy settings in different ways. After starting the core, v2rayN listens locally on SOCKS, HTTP, or mixed proxy ports; the system proxy switch only writes one entry point into the operating system settings. It does not force every process to send traffic to that port.

Browsers, desktop apps, PowerShell, Command Prompt, and Linux shells do not handle system proxies the same way. Troubleshoot the issue in three layers: whether a local listening port exists, whether the application knows the proxy address, and whether the request is routed to the correct outbound. Checking only node latency does not cover all three.

Separate the system proxy, local port, and TUN

v2rayN operation has two stages: core listening and application access. After you select a node and start the service, the Xray or v2fly core creates inbound ports locally. Only when a browser or terminal sends requests to those ports do VMess, VLESS, and other protocol connections occur. The node protocol and local proxy protocol are different concepts: a remote VLESS connection does not mean the terminal must understand VLESS. Terminals usually connect only to a local HTTP or SOCKS entry point.

The system proxy mainly affects applications that actively read the operating system proxy settings. Common browsers usually read this setting, so webpages may work immediately after enabling the v2rayN system proxy. Many command-line tools instead read their own configuration files or the HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY environment variables, so the terminal may still connect directly to the destination.

Check the v2rayN system proxy and listening ports

First confirm that the current server in the v2rayN main window is set as the active node and that the status bar is not showing persistent errors. Then open the logs and check whether the core finished starting. Importing a subscription or selecting a row in the list does not enable the proxy by itself: the subscription supplies node settings, while the system proxy directs applications that support it to the local entry point.

1. Confirm the active node

   Select a node in the server list and use the context menu to set it as the active server. Make sure the status bar shows that the core is running rather than a startup failure or configuration parsing error.

2. Read the local ports

   Open “Settings” → “Parameter Settings” → “Basic Settings” and note the local listening address, SOCKS port, HTTP port, or mixed port. All subsequent commands must use the actual values shown there.

3. Set the proxy mode

   Open “System Proxy” and choose “Automatically Configure System Proxy” or the corresponding enable option in your version. If an old manual proxy remains, choose “Clear System Proxy” first, then enable it again.

4. Check the routing mode

   Under “Settings” → “Routing Settings,” confirm the active rule set. During testing, first rule out the possibility that the target domain is being sent to a direct outbound by mistake, then restore the required split routing.

5. Restart the target application

   Fully quit the browser or desktop application and reopen it. Some programs read the system proxy only at startup, so changing the v2rayN switch while they are running will not immediately update existing connections.

On Windows, PowerShell can check whether a port is listening. Replace the example port with the value shown in the v2rayN interface:

Test-NetConnection 127.0.0.1 -Port 10808
Test-NetConnection 127.0.0.1 -Port 10809

If TcpTestSucceeded is True, at least one process is accepting connections on that port; this does not prove that the remote node is available. If the result is False, return to v2rayN and check core startup, port conflicts, and security software rules instead of continuing to configure terminal environment variables.

• When another program is using the port, the logs usually report a listening failure or that the address is already in use.
• When the listening address is 127.0.0.1, only applications on the same machine can connect; other devices on the local network cannot use it directly.
• After changing a port, restart the core and update the environment variables in any existing terminal windows.
• The port recorded in the system proxy must match the current HTTP or mixed entry point. Do not enter a SOCKS-only entry as an HTTP proxy.

What to do when the browser works but the terminal connects directly

The terminal is only the command execution environment; the specific program determines whether a proxy is read. curl, package managers, script runtimes, and remote download tools may use different variables. The safest test is to specify a proxy explicitly for one command first. Once it works, decide whether to set it for the current session, the user environment, or the tool’s own configuration file.

Specify the proxy explicitly with curl first

If the local entry is an HTTP or mixed proxy, run the following command. --connect-timeout 5 limits the connection phase to 5 seconds, making it easier to distinguish a refused port from a slow remote response:

curl --proxy http://127.0.0.1:10809 --connect-timeout 5 https://example.com/

If the interface confirms that 10808 is a SOCKS5 entry, use socks5h. The trailing h sends DNS resolution to the proxy as well, helping avoid differences between local DNS results and the proxy route:

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 https://example.com/

Set variables for the current terminal session

In PowerShell, environment variables apply only to the current window and child processes launched from it. They disappear when the window closes, making this approach suitable for troubleshooting and temporary tasks:

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
$env:ALL_PROXY="socks5h://127.0.0.1:10808"

curl --connect-timeout 5 https://example.com/

In a macOS or Linux shell, use the same variable names. Some tools recognize only lowercase forms, so set both uppercase and lowercase variants while troubleshooting:

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"

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

Check these items when environment variables still do not work

Correct variable names do not guarantee that every tool will use them. Some programs prioritize their own settings, some support only HTTP proxies, and others cache variables at startup. Check the values and send the request immediately in the same terminal window to avoid confusing “the new window did not inherit the variables” with “the proxy server is unavailable.”

Check the values read by the current session

# PowerShell
Get-ChildItem Env:HTTP_PROXY
Get-ChildItem Env:HTTPS_PROXY
Get-ChildItem Env:ALL_PROXY

# macOS or Linux shell
env | grep -i proxy

• Variable values should not contain full-width quotation marks, trailing comments, or line breaks.
• If NO_PROXY or no_proxy contains the target domain, the request bypasses the proxy.
• A terminal launched from a desktop shortcut may not inherit variables recently set in another terminal.
• Running development tools usually do not automatically read system environment changes made later; fully quit and restart them.
• An HTTP proxy address can carry CONNECT requests for HTTPS targets. The variable does not need to be changed to a nonexistent TLS listening port just because the target uses HTTPS.

If only one command fails while curl --proxy succeeds, check that tool’s proxy configuration priority. Do not enter three different ports in the system proxy, environment variables, and tool configuration at the same time; otherwise the logs will not clearly show which entry point received the request.

Consider TUN mode when more applications need to be captured

TUN mode captures more IP traffic through a virtual network interface without relying on each application to read the system proxy. It is more direct when a program explicitly ignores the system proxy, cannot use environment variables, or when multiple command-line processes need to be handled consistently. However, it changes the traffic entry point; it does not automatically fix node parameters, certificate domains, DNS, or routing rules.

1. First confirm that a normal HTTP or SOCKS entry can complete a request through an explicitly specified proxy.
2. In the v2rayN TUN settings, enable virtual network adapter mode and grant the permissions required to create a network interface when prompted by the system.
3. Check that routing rules keep the local network, loopback addresses, and required local services on a direct connection.
4. Test the terminal request again while checking the inbound type, destination address, and outbound tag in the logs.
5. If the entire network goes offline, disable TUN first, confirm that the system’s default route has returned, and then check DNS and the virtual interface status.

TUN is useful for programs that do not read the system proxy, but it is not necessary as a first step when the browser and terminal behave differently. An explicit proxy command establishes the boundary faster: whether the local port works, whether the protocol prefix is correct, and whether the node can establish an outbound connection. TUN troubleshooting has a clear starting point only after these basics work.

Use symptoms to locate routing, DNS, and subscription issues

When both the browser and terminal are already reaching v2rayN but their results still differ, inspect DNS resolution and routing matches. The browser may use its own cache while the terminal uses system DNS; once they obtain different destination addresses, they may also match different geoip, domain, or private-address rules.

A subscription link provides a collection of nodes; after updating it, you still need to select an active server. If the node list refreshes successfully but the core logs show that the configuration cannot start, the system proxy may remain enabled yet send browser requests to a local entry point that is not working. Fix the first configuration error in the startup log before anything else.

Verify and restore after troubleshooting

After fixing the issue, do not judge the result from a single webpage. Complete at least four checks—local port, explicit proxy, ordinary terminal request, and browser—and confirm that the system proxy is cleared after exiting v2rayN. This prevents the current window from appearing fixed while an old port remains configured in the system.

1. Retest the listening port

   Use Test-NetConnection or an equivalent tool to confirm that the current port is reachable, and verify that the test port exactly matches the value in the parameter settings.

2. Run an explicit request

   Run curl --proxy once through an HTTP or socks5h entry to confirm that both the local entry point and proxy path can complete a request.

3. Run a normal request

   Remove the explicit proxy argument from the command and send the request again using the current session’s environment variables. Only a successful result confirms that the terminal proxy configuration is working.

4. Check split-routing logs

   Review the access logs for the same period and confirm that the target domain matched the expected rule and was sent to the proxy or direct outbound.

5. Test recovery after exit

   In v2rayN, clear the system proxy first, then exit the client. Confirm that the browser and system network no longer point to the closed 127.0.0.1 port.

The entire troubleshooting sequence can be reduced to one sentence: check that the local port is listening, verify the path with an explicit proxy, configure terminal environment variables, and only then consider TUN, DNS, and complex routing. A browser using the proxy proves only that the browser read one entry point; it does not mean every process has been captured.

Frequently Asked Questions