When choosing a Windows VPN, first check whether traffic is routed through the client correctly, then consider whether global proxying or split tunneling fits your gaming and work needs. Access to international websites in a browser does not mean games or enterprise apps use the same route. This guide compares how the modes work and offers a way to test them on your own PC. It does not rank speeds without collected data or present configuration assumptions as test results.
Global proxy and split tunneling: distinguish traffic capture from routing
Windows clients usually have two separate kinds of controls: the capture method determines which connections enter the client, while the routing mode determines whether captured connections use a proxy, connect directly, or are blocked. The “global” option in an interface usually refers to the latter. Enabling global rules does not automatically route apps that ignore the system proxy through the client.
The system proxy provides an entry point for apps that follow the relevant settings. Browsers usually can use it, but apps rely on different networking components: some have their own settings, while others ignore the system proxy entirely. WinINET and WinHTTP proxy configurations in Windows are not necessarily the same, so background services and desktop browsers may behave differently.
Virtual network adapter capture, often called TUN mode, uses a virtual network interface and routes to send more IP traffic through the client. It can help when troubleshooting apps that do not follow the system proxy, but actual coverage still depends on routing, permissions, IPv6, protocol support, and exclusion rules. An enabled toggle alone does not prove that all traffic is captured.
| Setting | Scope | Use case | What to check |
|---|---|---|---|
| System proxy | Apps that follow system proxy settings | Browsers and some desktop tools | Whether the app reads the setting or has its own proxy configuration |
| Virtual network adapter capture | Traffic routed through the virtual interface | Games and apps with independent network stacks | Permissions, UDP, IPv6, and enterprise routes |
| Global rules | Captured traffic generally uses the same proxy exit | Temporarily checking the exit or finding missed rules | Whether intranet traffic is sent through the proxy by mistake and whether apps reopen connections |
| Rule-based routing | Captured traffic follows rules to select a route | Using international websites alongside everyday work | Rule order, domain resolution, and fallback behavior |
Desktop testing: create a repeatable comparison process
A useful compatibility comparison uses the same PC, network, and target service throughout. Keep the node unchanged and observe system proxy with rule-based routing, system proxy with global routing, and virtual network adapter capture if needed. Do not change the node, DNS, and game accelerator at the same time; otherwise, you cannot tell what caused a change.
- Record a baseline. Exit other proxy tools and note how the browser, game login, work apps, and intranet resources perform with a direct connection. For apps that access enterprise resources, first confirm the scope of testing allowed by your organization.
- Check the system proxy. Enable the client and visit the target website, then compare the client’s connection log and exit location. My IP can help you check the browser’s exit, but it does not represent all traffic from the PC.
- Compare rules with global mode. Close and reopen the target app, then repeat the same actions. Existing long-lived connections may continue using their original route, so checking an old window right after switching modes can be misleading.
- Enable the virtual adapter if needed. Test it only when a target app is not being captured or there is a clear need. Check whether the target connection appears in the client, whether a UDP session is established, and whether the enterprise intranet remains accessible.
- Check recovery behavior. Exit the client normally, then check the system proxy, web access, and intranet. Test wake from sleep, network switching, and signing in again to confirm that the configuration does not remain in a broken state.
Test notes can record verifiable outcomes such as “session established,” “login works but voice does not,” or “no connection log appeared in rule mode.” A single download speed is not enough to create a ranking; speed-test results also cannot directly predict gameplay or video-call quality.
Gaming compatibility: check UDP and connection routes
A game launcher and the game process may use different network routes. A launcher that can update does not prove that gameplay traffic uses the proxy; a successful web login does not confirm that voice, matchmaking, or room connections work. Test login, entering a match, and voice separately rather than relying on a screenshot of the launcher.
Many games rely on UDP, but UDP support does not guarantee compatibility with every game. The client, proxy protocol, server configuration, and local network can all affect the result. If TCP websites work but a game session fails, check the client log to see whether UDP was established instead of repeatedly changing browser proxy settings.
UDP support for Shadowsocks, VMess, Trojan, and VLESS depends on the implementation and configuration. Hysteria2 and TUIC are based on QUIC and rely on UDP underneath, so test them carefully on networks that restrict UDP. Protocol names are not speed ratings and do not confirm that VPNAdd currently offers a particular protocol; check the actual client and subscription contents.
If you already use a game accelerator, test each tool separately before deciding whether to use them together. Two tools modifying routes or DNS at the same time can cause detours or connection failures. Do not disable anti-cheat or security protections to get connected; check the game and client compatibility notes and follow the game’s service rules.
Work app compatibility: preserve intranet and enterprise connections
A work PC may need international collaboration sites, a company intranet, shared folders, and an enterprise VPN at the same time. Global routing may send addresses meant for the intranet through an external exit. Excluding private addresses alone may not be enough, since enterprises can also use custom domains, internal DNS, or specified network ranges.
For everyday use, it is usually better to start with rule-based routing: send international services through the proxy as needed while keeping authorized enterprise resources on their usual routes. Rules generally match in order, so check whether a broad rule earlier in the list overrides a more specific one. Domain rules also depend on how the client obtains domain information; the rule text alone does not show that a rule is working.
For meeting apps, test login, starting a call, screen sharing, and reconnecting separately. Command-line tools, development environments, and background services may need their own proxy settings or environment variables. A working browser and a failing command-line tool do not necessarily indicate a network route problem.
- ✅ Enterprise intranet domains still use the correct internal resolution route, and shared folders and work systems remain accessible.
- ✅ The enterprise VPN and personal client work when enabled separately, and the organization has approved coexistence testing.
- ✅ Login and actual tasks in international collaboration apps have been tested, not just the homepage.
- ✅ The system network recovers after exiting the client, with no settings left pointing to a stopped local proxy.
DNS and split tunneling: a changed exit does not mean DNS follows the right route
DNS resolves domain names to addresses, and its traffic may take a different route from the actual connection. Browsers may also use encrypted DNS and bypass the client’s intended resolution setup. Whether DNS is leaking depends on the expected resolution policy: if queries that should go through the proxy are still handled by the local network, investigate. Not all local resolution is a problem.
To verify DNS behavior, first check the client’s DNS settings, then see whether the browser uses a separate resolver. Compare domain requests, routing matches, and resolution results. A public test page only reflects queries triggered by its test domains and cannot prove that all apps use the same route. Enterprise internal domains should not be sent to public resolvers without a reason.
Consider IPv6 separately. If capture only covers IPv4 and the target app chooses IPv6, the exit may differ from what you expect. First confirm whether the client supports and handles IPv6 correctly, then make changes according to its official guidance. Permanently disabling a system feature is not a universal solution.
Importing a subscription and startup: check the configuration lifecycle
A subscription link is generally used to retrieve nodes and related configuration; it is not an installer or a URL to share publicly. Get it from the user panel, import it through a subscription option supported by the client, then update the configuration and check that the nodes appear. Clients differ in the subscription formats and protocols they support, so do not assume a link will work in any app.
If import fails, first confirm that the link is complete and the current network can reach the subscription address, then check the client version and format support. Do not post a complete subscription link containing access credentials in a public screenshot or on an unfamiliar conversion site. If you need help, share redacted error details through a user panel ticket.
“Start on boot” can mean launching the app after sign-in, connecting automatically, or starting a background service. An app opening automatically does not mean the system proxy is active; virtual adapter mode may also require permissions or a service component. After restarting, check the node, mode, and exit again, and see whether the client can recover when the network is not yet ready.
Experience on other platforms does not necessarily apply to Windows. macOS network extension permissions, VPN authorization on mobile systems, and Linux routing and permissions all differ. When comparing platforms, look at the capabilities of the actual client for each platform, not just the shared brand name.
Windows VPN guide: choose by app, then check the plan
Route types and traffic capture methods are also different things. IEPL describes a type of dedicated transport route; relay usually describes a path forwarded through an intermediate server; direct usually means the client connects to the entry point directly. These names alone do not prove gaming compatibility, a dedicated exit, or a fixed speed. Test in your actual network environment.
If you mainly use a browser and everyday work apps, first test the system proxy with rule-based routing. For a game or app that ignores the system proxy, then evaluate virtual network adapter capture. Use global mode to locate rule problems, and follow organization policies for enterprise intranet access. Knowing the route each app takes is more useful than a broad claim that “global is faster.”
If you are considering VPNAdd, check the client setup in the getting started guide, then test with the steps in this article. VPNAdd supports Windows, macOS, iOS, Android, and Linux, with unlimited simultaneous devices and no email address required to register. The core security claim is bank-grade encryption, but this does not replace endpoint protection, system updates, or correct routing configuration.
Choose based on actual usage: monthly subscriptions are ¥9.9/month for 60GB, ¥18/month for 250GB, or ¥28/month for 500GB, with traffic resetting monthly on the activation date; mid-cycle upgrades convert the price difference into the remaining days. Data packs are ¥158/300GB, ¥358/1000GB, or ¥658/3000GB; they expire when used and never expire otherwise. VPNAdd offers a 14-day no-reason refund. See the plans page for full details. Check compatibility before choosing a data allowance, rather than relying on rankings without actual test evidence.