For cases where v2rayN is running and the system proxy is enabled, but browser and terminal traffic behave differently. First test the local listener and node with an explicit proxy request, then check where the browser gets its proxy settings and inspect command-line environment variables. Follow the steps for Windows, macOS, or Linux to distinguish app-level bypasses and routing rules from node connection failures.
1. A System Proxy Is an Entry Point, Not a Catch-All
When you select “Set system proxy” in v2rayN, it writes proxy settings to the operating system. Whether an app uses those settings depends on the app. A browser may follow the system settings, or they may be overridden by an extension, startup option, or enterprise policy. Command-line tools usually have their own proxy options and environment variables. If a browser can reach a site, that alone does not prove the terminal is using the proxy.
There are two separate decisions: the app decides whether to connect to the local proxy, then the core decides whether that connection uses a proxy outbound or a direct outbound. Even when an app connects through v2rayN, routing rules may send its traffic direct. VMess and VLESS configure remote connections; they do not make browsers or terminals read the system proxy automatically.
- App bypass: The app is not connecting to the local listener. Check system settings, extensions, environment variables, and bypass lists.
- Direct routing: The local proxy received the request, but a rule selected a direct outbound. Check the active routing mode and rule order.
- Outbound failure: The request reached the core, but the connection to the remote node or destination service failed. Check the node, DNS, authentication, and transport settings.
2. Test the Local Proxy Entry Point First
Note the local listener address, port, and protocol shown in v2rayN. Check the listener settings under “Settings” → “Parameter settings,” and use the configuration currently running in the core as the source of truth; field locations can vary between interface layouts. The examples below use 127.0.0.1:10808 as a local entry point that supports HTTP. This is not a default for every installation. If only a SOCKS listener is available, use the corresponding SOCKS test command.
In Windows PowerShell, use curl.exe to avoid the curl alias in older Windows PowerShell versions, which runs a different command. On macOS and Linux, use curl. The test URL is for demonstration; replace it with a real HTTPS site you need to diagnose. Do not use a local address to check whether public internet proxying works.
# Windows PowerShell: HTTP or mixed listener
curl.exe -v --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://example.com/ -o NUL
# macOS / Linux: HTTP or mixed listener
curl -v --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://example.com/ -o /dev/null
# Use only if this port supports SOCKS5; DNS resolution happens on the proxy side
curl -v --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://example.com/ -o /dev/null--noproxy "" clears the bypass list for this test. In verbose output, look for a connection to 127.0.0.1 first. When an HTTP proxy accesses an HTTPS site, you should also see the CONNECT tunnel negotiation. If the destination site returns an HTTP response, the request reached at least the response stage. Even a non-200 status does not mean the system proxy is simply “not working.”
Result: Explicit proxy works—check the app’s proxy settings
If an explicit proxy request reaches the same destination but the browser or a regular terminal request fails, leave the current node and subscription settings alone for now. Focus on the app’s proxy source, bypass list, and environment variables.
3. Browser Bypassing the Proxy: Check for Overrides
Use the same destination and node throughout troubleshooting. Avoid changing the node, DNS, and routing at the same time. Whether a page loads is too crude a test: cached pages, existing connections, and sites that are reachable directly can all mask the actual route. Check the core’s connection records at the time of the request to see whether traffic reached the local proxy. If access logging is disabled, the absence of a log entry does not prove that no request was made.
-
Reset the system proxy
In the v2rayN tray menu, open “System proxy,” select “Clear system proxy,” then select “Set system proxy automatically.” If your version places the menu at the bottom of the main window, use the corresponding options with the same names. Then check the address and port saved in the system settings.
-
Pause proxy extensions
In Chrome or Edge, open “Extensions” → “Manage extensions” and temporarily disable any extension that can change proxy settings. A regular Incognito window may not isolate all proxy settings. Close all browser processes, reopen the browser, and test again.
-
Check the browser’s proxy source
In Chrome, open “Settings” → “System” → “Open your computer’s proxy settings.” In Firefox, open “Settings” → “General” → “Network Settings” → “Settings.” Confirm that it uses the system proxy, not “No proxy” or an outdated manual proxy.
-
Check the bypass list
Check system proxy exceptions, auto-configuration scripts, and browser rules. If the list includes the destination domain, an overly broad domain suffix, or a wildcard, note the original value and then narrow the scope. Intranet and loopback addresses are commonly excluded, so do not use them as your only test destinations.
-
Check for policy overrides
Check
chrome://policyin Chrome andedge://policyin Edge for proxy policies. On managed devices, ask your administrator to handle enforced settings; do not repeatedly change system settings that are being overridden by policy.
If only one browser is affected, check whether its startup shortcut includes proxy-related options. A browser’s Secure DNS setting is not a switch for enabling the proxy: it affects some DNS lookups but does not replace HTTP or SOCKS proxy configuration. Confirm the proxy source first, then troubleshoot DNS separately so you do not change both at once.
4. How to Check the Current System Proxy on Each Platform
Cross-check the system settings UI against command output. The commands below are for reading settings; they do not change the system proxy. Check that the server address, port, enabled state, auto-configuration script, and exception list match the current v2rayN entry point.
| Platform | Where to find it | What to check |
|---|---|---|
| Windows 11 | “Settings” → “Network & Internet” → “Proxy” | Manual proxy address and port, plus setup script; do not check only whether automatic detection is enabled |
| macOS | “System Settings” → “Network” → current connection → “Details” → “Proxies” | HTTP, HTTPS, and SOCKS settings, plus exceptions, for the active network service |
| Linux GNOME | “Settings” → “Network” → “Network Proxy” | Desktop proxy mode and protocol ports; check the corresponding settings in other desktop environments |
Windows: Check user settings and WinHTTP separately
# PowerShell: read the current user's proxy settings
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL
# Check the separate WinHTTP proxy configuration
netsh winhttp show proxyProxyEnable set to 1 means the static proxy is enabled; check the actual value of ProxyServer as well. Auto-configuration scripts use a separate configuration path. If netsh winhttp show proxy reports a direct connection, that does not mean the browser is not using a proxy. WinHTTP and the current user's Internet settings are separate configurations; do not import settings blindly just to make the output match.
macOS: Read the active proxy dictionary
scutil --proxyCheck HTTPEnable and HTTPSEnable, along with their server and port fields. Also check ProxyAutoConfigEnable and the exception list. Reread the settings after switching between Wi-Fi, Ethernet, or another network service; proxy settings for an old service do not show what the current connection is using.
Linux GNOME: Read desktop proxy settings
gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy.http host
gsettings get org.gnome.system.proxy.http port
gsettings get org.gnome.system.proxy.https host
gsettings get org.gnome.system.proxy.https port
gsettings get org.gnome.system.proxy ignore-hostsThese commands apply to GNOME sessions with the relevant settings schema; they are not a universal interface for every Linux environment. SSH sessions, containers, and background services generally do not inherit desktop proxy settings directly. Even if the desktop settings are correct, check the command-line program’s environment too.
5. Configure http_proxy and https_proxy Separately for the Terminal
A terminal window does not apply a proxy to everything; each program running inside it reads its own settings. curl, package managers, and developer tools may handle proxies differently. Start with a controlled curl test, then check the specific tool’s proxy options. One tool working does not mean the entire terminal session is using the proxy.
macOS / Linux: Check and set variables temporarily
# Check both uppercase and lowercase variables, plus the bypass list
env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='
# Set variables for this shell and its child processes only
export http_proxy=http://127.0.0.1:10808
export https_proxy=http://127.0.0.1:10808
# Clear the bypass list for this test; restore the original settings afterward
curl -v --noproxy "" --connect-timeout 5 --max-time 15 https://example.com/ -o /dev/nullIn https_proxy, https refers to the destination URL’s protocol; the variable value does not have to start with https://. A common local HTTP proxy uses http://127.0.0.1:10808 and accesses HTTPS destinations through CONNECT. Use an HTTPS proxy URL only if the proxy entry point itself supports TLS.
http_proxy: Provides a proxy for HTTP destinations. curl accepts only the lowercase form of this variable; setting only uppercaseHTTP_PROXYis not sufficient.https_proxy: Provides a proxy for HTTPS destinations. Other programs may handle capitalization differently; check the documentation for the specific tool.all_proxy: A general fallback proxy for some tools; it can use a SOCKS URL. Protocol-specific variables usually take precedence, so do not leave conflicting values set at the same time.no_proxy: A list of destinations that bypass the proxy. In curl, a value of*bypasses the proxy for every destination, so check this if variables are set but requests still connect directly.
Windows PowerShell: Set environment variables for the current process
# Check proxy environment variables in the current process
Get-ChildItem Env: | Where-Object Name -Match '^(http_proxy|https_proxy|all_proxy|no_proxy)$'
# Set variables for this PowerShell session and subsequently started child processes
$env:http_proxy = 'http://127.0.0.1:10808'
$env:https_proxy = 'http://127.0.0.1:10808'
curl.exe -v --noproxy "" --connect-timeout 5 --max-time 15 https://example.com/ -o NULThese settings do not change programs that are already running and are not automatically applied to new terminal windows. Before making the settings permanent, consider user environment variables or shell configuration files. Values set with setx are mainly read by future processes; they do not immediately change the current PowerShell session. Do not save an incorrect port permanently before testing it.
127.0.0.1 refers to the current network environment. A loopback address inside WSL, a container, or a remote SSH host is not necessarily the desktop host’s address; direct access to a host listener depends on the network mode and forwarding setup. If you need to connect across environments, first confirm the reachable address, listener scope, and firewall rules. Avoid exposing the proxy port on every network interface.
6. Match Common Errors to the Right Troubleshooting Layer
The examples below show common curl errors; exact addresses and wording vary by system and version. Fix the earliest failing step first: changing the remote protocol is pointless if the local port cannot be reached. Likewise, a TLS error from the destination means the issue can no longer be attributed to “the system proxy not being set.”
curl: (7) Failed to connect to 127.0.0.1 port 10808
Cause: The current environment cannot connect to the specified local entry point. Common causes include a wrong port, a stopped core, or a different network environment.
Fix: Check the listener protocol and port. On Windows, check for a listener with Get-NetTCPConnection -State Listen -LocalPort 10808; on Linux, use ss -lntp.
curl: (5) Could not resolve proxy
Cause: The hostname in the proxy address could not be resolved; the request has not reached the destination’s DNS lookup stage.
Fix: Check for spaces, an incorrect hostname, or a malformed address in the proxy variables. For the local entry point, start with an explicit loopback IP address.
curl: (6) Could not resolve host
Cause: The destination hostname could not be resolved. This may be due to a direct connection, a SOCKS request resolved locally, or a bypass rule.
Fix: Check the connection address in verbose output and inspect no_proxy. To resolve DNS on the proxy side, compare with socks5h:// on a port that supports SOCKS5.
curl: (28) Operation timed out
Cause: The request did not complete within the time limit. This message alone cannot tell you whether the timeout occurred at the local connection, remote node, or destination response.
Fix: Check where the -v output stops: local connection, CONNECT, TLS, or response. Use core logs from the same time to narrow down the cause.
If certificate verification fails, do not disable verification permanently as a workaround. Check the system clock, certificate trust chain, and any HTTPS inspection device on the network. If the proxy tunnel connects but TLS fails, that is a different issue from the terminal not reading proxy variables at all.
7. Use Test Results to Choose the Next Step—Don’t Enable TUN Yet
| Test result | Check first | Next step |
|---|---|---|
| Explicit proxy works; browser fails | Browser proxy source | Pause proxy extensions; check the system proxy, startup options, and policies |
| Explicit proxy works; regular curl fails | Variables and bypass list | Check the current process environment; review variables in both cases and inspect no_proxy |
| Cannot connect to the local entry point | Listener status and network environment | Check the port and core process, and confirm whether you are in a container or remote session |
| Can connect to the entry point; destination request fails | Protocol match and remote connection | Check the entry-point protocol, then use logs to investigate the node, DNS, and TLS |
| Request reaches the core but goes direct | Routing rules | Check the first matching rule and outbound tag; do not change the system proxy again |
TUN routes traffic through a virtual network interface and can handle apps that do not follow the system proxy. However, it adds new variables to troubleshoot, including permissions, routing, and DNS. TUN is not required to verify the system proxy. Enabling it before the explicit proxy test works often adds complexity; first verify the local entry point and remote outbound connection.
Result: Change one layer at a time
Record the results for the same destination using an explicit proxy, a browser, and a regular terminal request. Then decide whether to change the entry-point or outbound settings. Once the issue is fixed, undo temporary variables and test changes, restart the app, and retest to confirm the fix does not depend on an open terminal window.