First verify that the v2rayN core, node, and local inbound port are working. Then troubleshoot browsers and terminals separately. In browsers, identify who controls the proxy settings; in terminals, verify that the current process reads the correct HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY values. After completing the port tests, environment checks, and comparison commands below, you can determine whether the issue lies with the client, system settings, or a specific application.
Verify the three basic states of the proxy chain first
“System proxy enabled” only means the operating system has saved a proxy address. It does not mean every target application will use it. The full chain has at least three parts: the V2Ray or Xray core is running, the local listening port accepts connections, and the target application reads the system proxy or an explicit proxy configuration. If any link breaks, you may see direct web access, request timeouts, or terminal traffic bypassing the proxy entirely.
Do not change VMess, VLESS, or routing rules first. Start by checking the v2rayN main window and runtime logs. Once the node connects, v2rayN usually listens on a local SOCKS, HTTP, or mixed inbound port. In v2rayN 7.x, 127.0.0.1 is commonly used as the listening address; use the actual port shown under Settings → Parameters. The examples here use 10808 for the mixed port and 10809 for a dedicated HTTP port. If your client shows different values, replace them in every command.
Verify the node
In the v2rayN main window, select a subscription node and set it as the active server. Reconnect and confirm that the status no longer remains stuck on starting or reconnecting.
Read the port settings
Open Settings → Parameters → Basic Settings. Record the local listening address, mixed port, and HTTP and SOCKS ports. Do not guess the port from an outdated tutorial.
Check the logs
Open the runtime log and check for port conflicts, failed node address resolution, TLS handshake failures, or configuration loading errors.
Test explicitly
First access a test address with the proxy specified explicitly in the command. If the explicit proxy works, continue by checking system proxy inheritance and application settings.
Rule of thumb: If an explicit request to 127.0.0.1 on the correct port still fails, check the local listener and client logs first. If it succeeds but only the browser or terminal fails, the issue is isolated to application settings.
Browser not using the proxy: find out who controls the settings
The most common browser-side issue is not a failed node but conflicting proxy sources. A browser may follow the operating system, use its own network settings, or be controlled by a proxy extension. When all three are present, the active address may not be the 127.0.0.1 address written to the system by v2rayN.
Chromium-based browsers typically use the system network settings, but launch parameters, enterprise policies, and extensions can still change the outcome. Firefox-style browsers can independently choose “No proxy,” “Use system proxy settings,” or “Manual proxy configuration.” That is why one browser can work while another on the same computer connects directly.
Pause extensions
Temporarily disable every browser extension that changes the proxy server, PAC settings, or network request path. Fully quit the browser, then open it again.
Verify the system settings
From the v2rayN tray menu, choose a system proxy mode. Then open the operating system’s proxy settings and confirm that the server is 127.0.0.1 and the port matches the client’s current HTTP or mixed inbound port.
Check the browser
If the browser offers independent network settings, start with “Use system proxy settings.” If manual entry is required, set the HTTP proxy to 127.0.0.1 and the corresponding HTTP port.
Clear old processes
Close every browser window and use Task Manager to confirm that background processes have exited. Start the browser again before testing, so an old process cannot keep using proxy settings read at launch.
Compare the results
Test in a normal window and in a window with extensions disabled. If only the original setup fails, re-enable extensions one at a time to identify the conflict.
Error: ERR_PROXY_CONNECTION_FAILED
Cause and fix: The browser tried to connect to the proxy, but no service is listening on the corresponding 127.0.0.1 port. Check the core status in v2rayN and change the browser port to the current value shown under Parameters.
Error: ERR_TUNNEL_CONNECTION_FAILED
Cause and fix: The browser reached the HTTP proxy, but the proxy could not establish a tunnel for the HTTPS request. Check the node logs, protocol parameters, and routing rules that may block the request, then retest with a known-working node.
Error: The proxy server is refusing connections
Cause and fix: The browser cannot reach the manually configured proxy address. A common cause is entering the SOCKS port as the HTTP port. Use the mixed port, or enter the correct port in the SOCKS settings and select SOCKS5.
Also check the list of addresses that bypass the proxy. localhost, 127.0.0.1, and LAN addresses should usually connect directly, but an overly broad wildcard rule can make ordinary websites bypass the proxy too. Back up custom bypass entries, keep only the required local addresses, and test again. Once confirmed, add back the rules needed for your work one by one.
Terminal not using the proxy: environment variables must reach the current process
Most terminal programs do not automatically read the desktop system proxy. curl, package managers, runtime tools, and scripts may each implement proxy handling differently. The most portable approach is to set HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY for the current terminal session. Because support for uppercase and lowercase names varies by program, set both cases while troubleshooting.
Environment variables affect only processes started after they are set. Existing terminals, integrated editor terminals, and background tasks do not automatically receive new values. After changing system-level environment variables, close the old window and open a new terminal. Values assigned only in the current session naturally disappear when that window closes.
Current PowerShell session
$env:HTTP_PROXY = "http://127.0.0.1:10808"
$env:HTTPS_PROXY = "http://127.0.0.1:10808"
$env:ALL_PROXY = "socks5h://127.0.0.1:10808"
$env:NO_PROXY = "localhost,127.0.0.1"
Get-ChildItem Env:HTTP_PROXY
Get-ChildItem Env:HTTPS_PROXY
Get-ChildItem Env:ALL_PROXY
curl.exe -I --proxy http://127.0.0.1:10808 https://v2ray-os.com/zh-CN/In PowerShell, curl may be mapped to another command, so the example calls curl.exe explicitly. `-I` requests headers only, making it useful for quickly checking whether a connection is established. If the mixed port is not 10808, replace it with the port currently shown by v2rayN. With a dedicated HTTP inbound, replace the address with the actual configuration, such as `http://127.0.0.1:10809`.
Command line and common shells
export HTTP_PROXY="http://127.0.0.1:10808"
export HTTPS_PROXY="http://127.0.0.1:10808"
export ALL_PROXY="socks5h://127.0.0.1:10808"
export NO_PROXY="localhost,127.0.0.1"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"
export no_proxy="$NO_PROXY"
env | grep -i proxy
curl -I --proxy socks5h://127.0.0.1:10808 https://v2ray-os.com/zh-CN/Error: curl: (7) Failed to connect to 127.0.0.1 port 10808
Cause and fix: Nothing is listening on the local port, or the command uses the wrong port. Confirm that the v2rayN core is running, then read the current inbound port under Settings → Parameters.
Error: curl: (5) Could not resolve proxy
Cause and fix: The proxy variable is malformed, commonly because the scheme is missing, quotation marks are incomplete, or spaces were added to the address. Set it again using the complete format `http://127.0.0.1:10808`.
Error: curl: (35) OpenSSL SSL_connect
Cause and fix: The local proxy is usually reachable, but the remote TLS connection failed. Check the server name, clock skew, and handshake details in the core log, then compare the result with another working subscription node.
Error: connection reset by peer
Cause and fix: The remote server or an intermediate link reset the connection after it was established. Rule out a faulty node first, then verify that the VMess or VLESS transport layer, TLS settings, and server name match the subscription data.
Note: `socks5://` usually resolves the target domain locally, while `socks5h://` passes domain resolution to the proxy. If a domain fails in the terminal but a direct IP works, retest with `socks5h://` first and continue checking DNS settings.
Use comparison tests to isolate system proxy, port, and routing issues
Change only one variable at a time to identify the failing layer. Run a direct request, an explicit HTTP proxy request, and an explicit SOCKS5 request in that order. Record status codes, connection times, and log changes. If direct access works but both explicit proxy requests fail, the issue is with the client or node. If explicit proxy access works but the default request goes direct, check system proxy inheritance or environment variables.
| Test result | Likely cause | Next step |
|---|---|---|
| Both the browser and explicit commands fail | The core is not running, the port is wrong, or the node is unavailable | Check the v2rayN logs, verify 127.0.0.1 and the listening port, and switch to a working node |
| The explicit command works, but the browser fails | The browser is not following the system proxy, or an extension is causing a conflict | Disable proxy extensions, restart the browser, and check its independent network settings |
| The browser works, but the terminal fails | The terminal program is not reading the system proxy | Set HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY, then start a new process |
| HTTP works, but SOCKS fails | The SOCKS port or proxy type is incorrect | Read the actual SOCKS or mixed port and retest with socks5h |
| The connection works, but some domains fail | DNS or split-routing rules do not match | Check the domain resolution policy, matched rule, and final outbound tag |
Conclusion: explicit proxy testing is the dividing line
First make curl connect successfully through the explicit 127.0.0.1 address and port. Then troubleshoot browser and terminal inheritance. This avoids repeatedly changing nodes, system settings, and application configuration at the same time.
Check whether routing rules send the test request directly
A working proxy port does not mean every request uses the same outbound. v2rayN routing can choose direct, proxy, or block based on domain, IP, protocol, or inbound tag. If the test address matches a direct rule, the page may load while appearing not to use the proxy. That is routing behavior, not a failed system proxy.
- Search the client log for the test domain and confirm that the request entered the local inbound.
- Check the matched rule and outbound tag for the request, distinguishing direct, proxy, and block.
- Temporarily switch to a simple global proxy rule for comparison. After testing, restore the original split routing.
- After updating the subscription, select an active node again so you do not continue using an expired server entry.
- After changing DNS or routing, restart the core, then close and relaunch the target application.
Common details and the final check order
When the system proxy state changes frequently, the operating system page may show an old value, and the browser may retain the configuration it read at launch. Use this order: quit the target app, verify the core and node, set the system proxy again, then launch the app. Do not switch nodes, change ports, adjust DNS, and rewrite routing at the same time, or new changes will hide the original clues.
v2rayN shows connected. Why does the browser still connect directly?
Open the operating system proxy settings first and verify the address and port, then disable browser proxy extensions. Fully quit the browser’s background processes, reopen it, and check the client log for the requested domain.
HTTP_PROXY is set in the terminal. Why does a new command still bypass the proxy?
Print the current process’s environment variables and confirm that the values include the scheme, address, and port. Some tools read only lowercase names, so set http_proxy and https_proxy as well, then retest in a new terminal window.
Should HTTP_PROXY and ALL_PROXY be set together?
You can set both during troubleshooting. HTTP and HTTPS requests generally prefer their corresponding variables, while tools that need SOCKS5 or proxy-side DNS may read ALL_PROXY. Keep only the variables required after confirming the behavior of the specific tool.
Do I need to restart the browser after switching nodes?
Switching nodes usually does not require a browser restart. Restart it when the port, system proxy mode, or PAC configuration changes. If old connections are being reused for a long time, close every window before testing again.
What if the connection still fails after a subscription update?
A successful subscription update only means the configuration list was fetched; it does not mean every node is usable. Select another node, verify the system clock, and use the core log to determine whether the failure is DNS resolution, the handshake, or a connection timeout.
Checklist before restoring the configuration
- Confirm that the active v2rayN node comes from the latest subscription and that the core log is not showing continuous restarts.
- Confirm that the browser, terminal commands, and client interface use the same local port.
- Confirm that the browser has only one proxy source, so system settings and extensions do not overwrite each other.
- Confirm that the terminal environment variables have reached the current process and use complete scheme prefixes.
- Confirm that the test domain was not excluded in advance by NO_PROXY, the browser bypass list, or a direct route.
- After changing the configuration, reconnect the core and restart applications that need to read the proxy settings.
Final diagnosis: separate the application first, then the protocol
If the browser works but the terminal fails, check environment variables directly. If explicit proxy access works in the terminal but the browser fails, check the proxy source. If both fail, return to the core, listening port, and node logs. Following this order usually avoids rebuilding the subscription or making broad configuration changes.