Use this guide if the v2rayN core is running but your browser can't connect, terminal requests time out, or only some apps have internet access. First test the local proxy with an explicit proxy request, then check whether the browser uses the system proxy, and finally review terminal environment variables, PAC, and bypass lists. The examples use Windows; replace the sample port with the one your client actually listens on. A successful command doesn't mean all traffic is being proxied.
Separate system proxy settings, core status, and server connectivity
If v2rayN shows that the core is running, that only confirms the relevant process is active. Selecting a server doesn't mean your browser is using it. The system proxy setting provides a local proxy address to apps that honor it; it doesn't automatically route every program's traffic. Terminal tools, browser extensions, and app-specific proxy settings may use different connection paths.
Test each link in this chain. If an explicit request through the local proxy still fails, check the listening port, core logs, and server connection first. If the explicit proxy works but normal browsing doesn't, check system settings and the browser. This order avoids repeatedly changing PAC rules before the local endpoint is reachable.
- Note the current server, system proxy mode, local listen address, and port so you can restore them later.
- Temporarily turn off TUN while troubleshooting to prevent traffic from being captured by a separate routing path. Don't run another app that also manages the system proxy at the same time.
- In v2rayN, check the local listener options under Settings → Parameter Settings. Field locations may vary between versions; use the labels shown in your interface.
- Open the client logs and check for startup failures, port binding errors, or repeated connection errors before running the tests below.
Test the local endpoint with an explicit proxy request
In PowerShell, call curl.exe to avoid environments where curl points to a different command. The two requests below use the same destination: the first bypasses proxies, and the second explicitly uses the local HTTP proxy. Connection and overall timeouts prevent excessive waiting. The sample site is only for testing connectivity, not for measuring performance.
# Direct connection: bypass all proxies
curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com/
# HTTP proxy endpoint: make sure the test domain isn't on the bypass list
curl.exe --proxy http://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 20 -I https://example.com/
# If this port supports SOCKS only, use this command instead
curl.exe --proxy socks5h://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 20 -I https://example.com/socks5h lets the SOCKS proxy handle the destination hostname, but the final DNS resolution behavior still depends on the core configuration. HTTP proxies typically use a CONNECT tunnel for HTTPS destinations. Using http://127.0.0.1:10808 as the proxy address doesn't turn the destination website into plain HTTP.
| Test results | Check first | What you can't conclude |
|---|---|---|
| Explicit proxy works, browser fails | Browser extensions, system proxy address, PAC, and bypass list | You can't assume the browser is using the proxy |
| Connection to local proxy refused | Listening port, endpoint protocol, and whether the core is running | You can't conclude that the remote server is at fault |
| Both direct and proxied requests work | Use the logs to determine the actual outbound route | Opening the same page doesn't mean both requests took the same route |
| Proxy request times out | Check DNS, routing, and outbound connections against the log timestamps | A timeout alone doesn't identify which step failed |
Next: change system settings only after the explicit proxy works
Keep one explicit proxy command that succeeds consistently as your baseline. Then change only one browser, PAC, or environment-variable setting at a time. If the baseline still works while an app fails, you can focus on that app's proxy path.
Browser bypassing the proxy: check system settings and extensions
In Windows 11, open Settings → Network & internet → Proxy and check whether a setup script or manual proxy is enabled. If v2rayN is using manual system proxy mode, the address and port should match the client's active HTTP or mixed-protocol endpoint. If you're using PAC, check the script address; you don't also need to enable the manual proxy toggle.
- Reapply the system proxy. In the v2rayN tray menu, go to System Proxy and select Auto Configure System Proxy. If your version uses different wording, choose the option that sets the local proxy address, then return to Windows settings to verify the result.
- Temporarily disable proxy extensions. An extension may pin a server, force direct connections, or route traffic using its own rules. Disable related extensions and test in a regular browser window. Don't assume private browsing disables extensions; some may be allowed to run there too.
- Check the browser's own settings. If the browser has separate proxy settings, select Use system proxy. If it doesn't, check whether its launch options force a proxy or direct connection.
- Restart the browser. Close all browser windows and make sure its background processes have exited. Then open the same test address again to avoid reusing an old connection.
If the system settings revert right after you change them, check for another proxy app, a browser extension, or an organization-managed policy. On a managed device, don't repeatedly override policy settings; ask your administrator which proxy methods are allowed. If system proxying works but one app still fails, that app may not use the system setting at all.
PAC and bypass lists: check whether requests are being excluded
PAC is a proxy selection script that an app reads and runs. Common results include DIRECT and PROXY 127.0.0.1:10808. It determines where a request goes first; this is separate from routing rules applied by the core after the request reaches it. If PAC returns DIRECT, the request may never reach v2rayN.
- PAC script is reachable: Copy the PAC address shown in system settings into a browser and check that the script text loads. If it's hosted locally, the script may be unavailable when the client exits or its service stops.
- PAC uses the right port: If you change the local proxy port, make sure the PAC script points to the new endpoint instead of the old port.
- Check which rules match: If the destination domain matches a direct-connection rule, the page may open even though the proxy wasn't used. Check the PAC script and core logs when testing.
- Check proxy exclusions: Keep local address exclusions that you need, but look for overly broad domain rules. Wildcards may work differently across apps, so don't copy another tool's syntax without checking it.
Check Windows manual proxy exclusions and direct-connection rules inside PAC separately, depending on which mode is active. Terminal NO_PROXY is a separate setting. Removing an exclusion in Windows won't clear the bypass list used by command-line tools.
Next: temporarily set a known endpoint to separate PAC and core issues
Record the PAC address, then temporarily switch to a verified manual proxy endpoint. If the browser starts working while the explicit proxy command continues to succeed, focus on PAC loading and rule matching. Restore the original mode after troubleshooting; there's no need to rewrite core routing rules at the same time.
Terminal bypassing the proxy: check environment variables and tool settings
Terminal programs don't necessarily use the Windows system proxy. If the browser works but command-line requests time out, check the tool's proxy options and environment variables separately. The PowerShell settings below affect only the current session and processes started from it; they don't automatically change other terminal windows that are already open.
# List environment variables containing proxy in the current session
Get-ChildItem Env: | Where-Object { $_.Name -match 'proxy' }
# Example: set an HTTP proxy for tools that support these variables
$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"
# Remove --proxy to check whether curl.exe uses the current environment
curl.exe --connect-timeout 10 --max-time 20 -I https://example.com/
# Remove the session variables set for troubleshooting
Remove-Item Env:http_proxy,Env:https_proxy,Env:no_proxy -ErrorAction SilentlyContinuehttps_proxy specifies which proxy to use for HTTPS destinations; it doesn't mean the proxy address itself must use HTTPS. If the local endpoint supports only a regular HTTP proxy, setting it to https://127.0.0.1:10808 may cause a TLS handshake failure. Support and precedence for environment variables vary by tool, so don't assume every program behaves like curl.
- Check leftover variables:
ALL_PROXYmay still point to an old SOCKS port, whileNO_PROXYmay include the destination domain or*. Note the existing values before changing them. - Check case sensitivity: Windows environment variable names are usually case-insensitive. On Linux and other systems, support for uppercase and lowercase names varies by tool. For curl's HTTP proxy variable, use lowercase
http_proxy. - Check tool-specific settings: Command-line options, user configuration files, and environment variables can override one another. Establish a baseline with an explicit
--proxy, then restore other settings one at a time. - Check the runtime environment: In a remote terminal, container, or separate network environment,
127.0.0.1refers to that environment itself, not necessarily the desktop running v2rayN.
Port conflicts and error messages: start by checking the listener
If an explicit proxy command fails while connecting to the local port, check the listener before changing protocol settings such as VMess or VLESS. Run the commands below in PowerShell; they use the sample port from earlier. After finding a listener, check which process owns it: a listening process isn't necessarily the v2rayN core.
# Check whether the port is listening for TCP connections
Get-NetTCPConnection -LocalPort 10808 -State Listen -ErrorAction SilentlyContinue |
Select-Object LocalAddress,LocalPort,OwningProcess
# Find the name of the listening process
Get-NetTCPConnection -LocalPort 10808 -State Listen -ErrorAction SilentlyContinue |
ForEach-Object { Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue }
# Check the Windows WinHTTP proxy as a separate configuration clue
netsh winhttp show proxynetsh winhttp show proxy displays the WinHTTP proxy configuration, not the user-level system proxy used by browsers. If it shows a direct connection, that doesn't mean v2rayN failed to set the system proxy used by browsers. Don't import the user proxy into another configuration without confirming it's needed.
Error: Connection refused
Cause: When this appears while connecting to a local loopback address, it usually means no service is accepting connections on the target port, or the connection was actively rejected. Fix: Check the actual listening address and port, review the core startup logs, and retry with the correct endpoint protocol.
Error: address already in use
Cause: This is a common port binding error. Another process or a duplicate instance may already be using the same address and port. Fix: Identify the process listening on the port, close the conflicting app normally, or change the local port and update the system proxy, PAC, and terminal variables to match.
Error: Could not resolve proxy
Cause: curl can't resolve the proxy hostname. Common causes include a typo in the proxy address, a leftover variable, or an invalid address format. Fix: Test first with the explicit address http://127.0.0.1:10808, then check the proxy address in your environment variables and tool settings.
Error: Could not resolve host
Cause: The destination hostname couldn't be resolved along the current request path. Where this happens depends on whether you're using a direct connection, SOCKS, or HTTP proxy. Fix: Note the command and proxy type, check the core logs to see whether the request reached the proxy, then review DNS settings for that path.
Exact error wording varies across operating systems and core versions. Note the error keyword, timestamp, and destination port to help locate the issue; don't conclude that a server is down based only on a “timeout.” If the local endpoint is reachable but the logs show a failed remote connection, check the server address, port, transport, and security settings.
After restoring your settings, finish with these three checks
Once you've found the cause, restore the proxy mode you need and remove any temporary troubleshooting settings. In particular, make sure the system proxy isn't using a new port while the terminal still uses the old one, or PAC still points to the previous address. Restore one setting at a time and confirm it works before proceeding.
- Explicit proxy works consistently: Run the baseline command again to confirm the local endpoint and outbound route still complete the request.
- App proxy path is clear: Confirm the browser uses the expected system proxy or PAC, and that the terminal uses environment variables if needed. Check the logs to confirm whether requests reach the core.
- Shutdown behavior is predictable: Clear or restore the system proxy before stopping proxy use. If websites stop loading after the client exits unexpectedly, check whether the system still points to a local port that is no longer listening.
If you need help, include your operating system, v2rayN interface type, actual listening protocol and port, system proxy mode, test command, and relevant log timestamps. Hide subscription URLs, credentials, and sensitive server details before sharing. For configuration concepts, see Advanced Configuration; for a first setup, review the basics in the Getting Started Guide.