v2rayN can connect to a VMess or VLESS node successfully while Windows applications still use the normal network path. The reason is that connecting the Xray core and applying a Windows system proxy are two separate actions. The core may be listening on local ports such as 127.0.0.1:10808 for SOCKS and 127.0.0.1:10809 for HTTP, but browsers and other applications will not use those ports unless they read the system proxy configuration or are configured manually.
In v2rayN, the system proxy menu normally provides options such as setting the system proxy, using PAC mode, and clearing the system proxy. These options do not change the remote node, UUID, transport, or subscription. They decide how Windows applications discover the local proxy and whether traffic is sent through a single proxy endpoint or selected according to PAC rules.
This guide explains the system proxy modes in v2rayN 7.x on Windows, shows the exact tray-menu workflow, compares global and PAC behavior, and provides practical tests for browsers, command-line tools, and applications. It also covers how to clear leftover proxy settings after closing v2rayN so Windows does not keep pointing to an unavailable local port.
What the System Proxy Mode Actually Controls
The Windows system proxy is a set of operating-system settings that supported applications can read. When v2rayN enables it, Windows may receive an HTTP proxy address, a secure-proxy address, a bypass list, or an automatic configuration script address. The exact fields depend on the selected v2rayN mode and the Windows version. The important point is that v2rayN is not magically intercepting every packet at this layer; it is publishing a local proxy endpoint for applications that agree to use it.
In a common configuration, v2rayN starts the core with an HTTP inbound on 127.0.0.1:10809 and a SOCKS inbound on 127.0.0.1:10808. Windows applications that support the system HTTP proxy usually use the HTTP listener. Applications with their own SOCKS settings can use the SOCKS listener instead. If the HTTP port is changed to 18080, the Windows system proxy must also point to 127.0.0.1:18080; otherwise the client can show a connected node while browsers report connection failures.
System proxy mode should therefore be distinguished from routing mode. “Global” or “PAC” in v2rayN usually describes how the core chooses an outbound after receiving a request. “Set system proxy” describes whether Windows-supported applications are directed to the local inbound. A browser can use the system proxy while the core still applies rule-based routing, and a browser can also use global routing while other applications remain direct because they never read the Windows setting.
- Core running: The Xray or other selected core has started and is listening locally.
- System proxy enabled: Windows-supported applications are told to use v2rayN’s local HTTP endpoint.
- Global routing: Requests received by the core generally use the proxy outbound unless a higher-priority rule overrides it.
- PAC mode: A local automatic configuration script decides whether a destination should use the proxy or connect directly.
- System proxy cleared: Windows no longer uses v2rayN’s local address, but this does not necessarily stop the core itself.
System proxy mode does not cover every type of traffic. Programs that use their own network stack, ignore WinHTTP or WinINet settings, use a separate proxy configuration, or send non-HTTP protocols directly may bypass it. For those cases, application-level configuration or TUN mode may be more suitable. Do not enable TUN merely because a browser has not yet been configured; first confirm that the ordinary system-proxy path is correct.
Understand the Main v2rayN Proxy Modes
The names can differ slightly between v2rayN releases and language packs, but the underlying behavior is usually similar. Open the v2rayN tray icon or main window and look for the system-proxy section. If your release places the items under a submenu, expand the menu instead of assuming that a missing top-level label means the feature is unavailable.
Uses a fixed local HTTP proxy address for supported applications. It is the easiest mode to test because the browser sends all requests that follow the Windows proxy setting to the same local endpoint.
Suitable for: first setup, troubleshooting, and a controlled all-proxy test
Uses an automatic configuration script. The PAC rules can send selected domains through v2rayN while allowing local or trusted destinations to connect directly.
Suitable for: split routing and reducing unnecessary proxy traffic
Removes the proxy values that v2rayN placed in Windows. It is a cleanup action, not a node test and not a command to stop the Xray core.
Suitable for: closing v2rayN, switching clients, or recovering direct access
Fixed system proxy mode
Fixed mode is the best baseline because it has fewer moving parts. Windows applications that honor the system proxy send requests to the local HTTP address shown in v2rayN. The core then applies its routing rules. If the selected routing mode is global, most received requests use the proxy outbound. If the routing mode is rule-based, domains and IP ranges may be sent directly or through the proxy according to the active configuration.
This mode does not mean that every Windows connection is forced through the node. It only makes the local proxy available through the system setting. A game launcher that ignores the setting can still connect directly, and a command-line program may use WinHTTP settings rather than the browser-oriented WinINet settings. Such differences explain why a browser test can succeed while another application remains unreachable.
PAC mode
PAC mode points Windows to a locally hosted JavaScript proxy auto-configuration file. The file returns a decision such as using the local proxy for a destination or using DIRECT for a destination. PAC is useful when local websites, intranet addresses, or private network ranges should not use the remote node. It is also convenient when the v2rayN rule set already contains a maintained domain list.
PAC is not a TUN replacement. A PAC file is consulted only by applications that support automatic proxy configuration. It does not capture arbitrary UDP packets, applications with their own resolver, or programs that deliberately bypass Windows proxy settings. If a PAC test behaves unexpectedly, temporarily switch to fixed system proxy mode. If fixed mode works but PAC mode does not, the node is probably healthy and the issue is in PAC matching, browser caching, or the application’s support for automatic configuration.
Clear system proxy
Clearing the system proxy returns Windows to a direct configuration or to the previous state that v2rayN can restore. It should be used before closing the client if other applications will continue running. Otherwise, Windows may still contain an address such as 127.0.0.1:10809 after v2rayN has stopped listening. The next browser request then fails locally with a refused connection, even though the remote node and the internet connection are working.
Enable and Change the Mode Step by Step
Use a working node and a normal browser for the first test. Do not change the local ports, routing rules, DNS settings, and proxy mode at the same time. A controlled setup makes it possible to identify whether a failure comes from the node, the local listener, Windows, the browser, or a routing rule.
-
Start v2rayN
Launch v2rayN 7.x and wait until the main window or tray icon appears. Confirm that the Xray core has started without a bind error. If the log reports that port
10809or10808is already in use, resolve that local conflict before changing proxy modes. -
Select a node
Update the subscription through “Subscription Group” → “Update subscription,” then select a node that has worked previously. A system proxy cannot repair an invalid UUID, expired subscription, incorrect Reality parameters, or an unreachable server.
-
Choose a route
From the v2rayN tray menu, open the routing or proxy-mode submenu and choose a known route such as Global or the normal rule-based profile. For the first verification, avoid an unfamiliar custom rule set that may intentionally send the test domain direct.
-
Set the proxy
Open the tray menu and choose “Set system proxy” or the equivalent fixed-proxy entry. If you specifically need split routing, choose “Set system proxy (PAC mode)” instead. Wait a few seconds for Windows applications to reload the setting.
-
Test the browser
Open a new private browser window and visit a site that shows the public exit address. Then open a second ordinary website. Test both a new domain and a previously visited domain so that a cached connection does not produce a false success.
-
Clear when finished
When stopping v2rayN, return to the tray menu and choose “Clear system proxy.” Confirm in Windows Settings that no stale manual proxy or automatic configuration script remains before using the network directly.
On some releases, the same controls are available from the main window’s system-proxy or tray menu area. The wording can differ between English and Chinese builds, but the functional distinction remains: fixed proxy, PAC configuration, and clear. If the menu action appears to do nothing, open Windows proxy settings immediately afterward and check whether the manual proxy or setup-script field changed.
Verify the Proxy Path Instead of Trusting the Menu Label
A menu check mark only indicates that v2rayN requested a Windows setting change. It does not prove that the browser accepted the setting, that the local port is listening, or that the request reached the selected node. Verification should include the client log, the local listener, the Windows configuration, and an external result.
- Check the core log: Look for a new inbound connection when opening a page. If the browser loads a page but the log remains completely silent, the browser may be using a different proxy profile or a cached connection.
- Check the listener: In PowerShell, run
Test-NetConnection 127.0.0.1 -Port 10809. A successful TCP test proves that something is listening on the HTTP port; it does not prove that the remote node works. - Check Windows settings: Open “Settings” → “Network & internet” → “Proxy.” Confirm whether “Use a proxy server” or “Use setup script” matches the v2rayN mode you selected.
- Check the exit address: Compare a direct result with the result obtained while fixed proxy mode is enabled. The result should reflect the selected outbound, subject to the node provider and routing policy.
- Check a second application: Use a program known to honor Windows proxy settings. Do not treat a single browser extension or application with its own proxy as proof of system-wide behavior.
Conclusion: use fixed mode as the diagnostic baseline
If fixed system proxy mode works and PAC mode does not, troubleshoot PAC rules or application support rather than changing the server protocol. If neither mode works, compare the local port, Windows setting, core log, and node connectivity in that order.
Command-line verification needs additional care. Many tools use WinHTTP, while browsers commonly use WinINet or their own settings. A command may therefore bypass the setting visible in Windows’ graphical proxy page. If a command-line tool supports explicit HTTP or SOCKS options, test it with the same local address and port configured in v2rayN. This isolates the core from Windows’ automatic proxy-discovery behavior.
Remove Leftover Settings and Fix Common Failures
The most common shutdown problem is a stale local proxy. v2rayN exits, the Xray listener disappears, but Windows still tries to send browser traffic to 127.0.0.1:10809. The browser may show “proxy connection failed,” “connection refused,” or a page that never finishes loading. Open v2rayN again if necessary, choose “Clear system proxy,” and then revisit Windows proxy settings to confirm that both the manual proxy and PAC fields are inactive.
If Windows shows a proxy that v2rayN did not create, another client or management policy may be controlling it. VPN clients, enterprise policies, browser extensions, and automatic configuration scripts can all write related settings. Disable only the entry you can identify, and record the previous value before changing a managed computer. Repeatedly toggling v2rayN may not override a policy that reapplies the setting after every change.
Fixed proxy baseline
- Windows mode
- Manual proxy
- Local address
- 127.0.0.1
- Typical port
- 10809 HTTP
- Routing test
- Global or known rule set
Use this configuration first when proving that the local proxy path works.
PAC split-routing setup
- Windows mode
- Automatic setup script
- Decision source
- Local PAC file
- Direct traffic
- Matched by PAC rules
- Fallback test
- Switch to fixed mode
Use this after fixed mode succeeds and you need selective direct access.
Error: The proxy server is refusing connections
Cause and fix: Windows points to a local port where no core is listening. Start v2rayN, confirm the HTTP port, or clear the system proxy before browsing directly.
Error: The browser works, but one application remains direct
Cause and fix: The application may ignore Windows proxy settings or use its own network configuration. Add an explicit HTTP or SOCKS proxy in that application, or use TUN mode when broad traffic capture is required.
Error: PAC mode opens local sites but not external sites
Cause and fix: The PAC script may return DIRECT for the destination, or the application may not retrieve the script correctly. Test fixed system proxy mode and inspect the PAC-related entry in Windows Proxy settings.
Error: v2rayN reports a running core, but pages still fail
Cause and fix: A running process only proves that the core started. Check the selected node, local HTTP port, routing profile, and core log entries for timeout, DNS, TLS, or remote rejection messages.
When a node is changed, repeat the test instead of relying on an old browser tab. Existing HTTP/2, QUIC, WebSocket, or TLS sessions can remain alive after a proxy setting change. Close the tab, start a new private window, and if necessary restart the browser. If UDP-based browser transport behaves differently from ordinary TCP requests, temporarily disable the browser’s secure transport experiment or use a controlled HTTP request to verify the basic proxy path first.
Finally, remember that system proxy mode and TUN mode solve different coverage problems. System proxy mode is lightweight and easy to reverse, making it the right first choice for browsers and desktop applications that respect Windows settings. TUN mode creates a virtual network interface and can capture more traffic, including programs that ignore system proxy values, but it introduces additional DNS, route, permission, and adapter considerations. Start with the smallest mode that covers the applications you actually use.