A browser can work through a proxy while another application on the same Windows PC still goes direct. That is not contradictory: a proxy endpoint and a default gateway control different parts of the network path.
Take a simple case. Chrome on PC B is configured to use an HTTP proxy on Windows A. Chrome reaches an internal web site successfully. A desktop client on PC B has no proxy support and still uses PC B's normal network.
Both paths can exist at the same time. The mistake is assuming that changing one application's proxy setting automatically changes Windows routing for every process.
Proxy, system proxy, VPN, gateway, NAT, and TUN are not synonyms
| Concept | Plain-English job | Who usually decides to use it? |
|---|---|---|
| HTTP / SOCKS5 proxy | Forward connections for proxy-aware applications | The application or a component acting on its behalf |
| Windows proxy setting | Provide proxy configuration that compatible Windows applications can consume | Each application's networking stack |
| VPN | Create a protected or virtual network path and associated routing/policy | VPN client plus operating-system networking |
| Default gateway | Receive packets for remote networks when no more specific route is selected | The operating system's IP routing table |
| NAT | Rewrite network addresses/ports as traffic crosses a boundary | A router, gateway, firewall, or host providing NAT |
| TUN-style virtual interface | Present a virtual layer-3 interface that can receive IP packets | Routes/policies send traffic into the interface |
Putting the terms in separate boxes matters because a product can support one without supporting the others.
What a default gateway changes
When Windows sends an IP packet, it checks its routing table. If the destination is on another network and no more specific route wins, the packet is typically sent to a default gateway.
Microsoft's TCP/IP addressing documentation describes the default gateway as the router used to reach hosts on other networks.
The application does not normally need to know the gateway's address. It opens a socket; Windows routing decides the next hop.
What an explicit proxy changes
An HTTP or SOCKS5 proxy is a service endpoint. The client application knows the proxy's LAN address and port and deliberately sends supported connections there.
This can be exactly what you want when only a few tools need the special path:
- a browser needs an internal web portal;
- an API client needs a specific upstream network;
- a database tool supports SOCKS5;
- a VM application can be configured with an HTTP or SOCKS5 proxy.
It is less natural when dozens of unrelated applications must all follow the same path, or when the device has no proxy configuration at all.
For the protocol details, see What Is an HTTP Proxy? and What Is SOCKS5?.
NAT is often present on a gateway, but NAT is not the gateway itself
NAT answers a different question: should addresses or ports be translated while traffic crosses this device?
A home router commonly acts as a default gateway and performs NAT for private IPv4 clients, so users experience both functions in one box. That makes the terms easy to mix up.
Where VPN fits
A VPN client typically creates a virtual or protected path and changes routing or policy so selected traffic uses that path. Some deployments send most external traffic into the VPN; others use split tunneling so only particular destinations or applications use it.
The important question for a Windows host is not simply “is the VPN connected?” It is:
Which destinations and applications can this host actually reach through the resulting Windows network state?
A downstream proxy can only reuse paths that are genuinely usable from the host. A connected adapter name is not proof that every destination will be reachable through it.
TUN explains why some tools can cover more traffic than an app proxy
A TUN-style interface behaves like a virtual layer-3 network interface. Routes can direct IP packets into it, after which a user-space networking component can process or tunnel those packets.
That is fundamentally different from telling Chrome to use an HTTP proxy. The browser does not need an HTTP proxy address when the operating system is already routing its packets into a virtual interface.
It is also why “proxy mode” and “TUN/gateway mode” should not be described as the same current capability merely because both can produce the same public IP in a browser test.
Five common requirements and the layer they point to
Only the browser needs the special network
An HTTP proxy is often the simplest answer. Changing the whole machine's routing can add complexity without solving an additional need.
A database tool supports SOCKS5
Use the application's SOCKS5 support and verify the target, DNS behavior, and transport. There is no requirement to turn the whole PC into a routed client just because one tool needs a TCP path.
Twenty unrelated applications should follow the same Windows host
Per-application proxy configuration becomes harder to manage, and some programs will ignore it. That requirement points toward routing, TUN, gateway, or another system-level design rather than assuming explicit proxying will cover everything.
A game console, TV, or IoT device has no proxy settings
HTTP/SOCKS5 alone is usually not a complete solution. The device needs a network-level path it can actually use, such as an appropriate gateway or router design.
Chrome works through the proxy but a desktop program does not
First check whether the desktop program supports and uses that proxy. Do not start by changing firewall rules or blaming the upstream VPN if the application never sent its connection to the proxy in the first place.
Where NetConfiger fits today
NetConfiger's current public distribution mode is explicit HTTP/SOCKS5 proxying from a Windows host that already has an authorized, usable upstream network path.
That means:
- the Windows host keeps the upstream client or network connection;
- NetConfiger exposes HTTP/SOCKS5 on the LAN;
- downstream applications that support those proxies can use the host's path;
- applications that do not use the proxy can continue to use their own route.
It should not be presented as a transparent default gateway, full-device traffic takeover, or universal VPN replacement in this mode. Gateway-style networking is a separate network-layer capability.
How to tell which layer is actually responsible when something fails
- Check the application. Does it have an HTTP/SOCKS5 setting, and is that setting enabled?
- Check the proxy service. Can the client reach the Windows host and proxy port?
- Check the host's real reachability. Can Windows A reach the exact destination through the intended upstream path?
- Check DNS separately. A hostname failure can occur even when an IP connection succeeds.
- Check routing when the requirement is device-wide.
route printcan show the Windows routing table; proxy settings alone cannot explain a gateway-level path.
The practical rule is simple: choose the narrowest layer that solves the real requirement. Use an application proxy when the application can participate. Move to gateway or routing designs when the device itself must use the path regardless of per-app proxy support.
Key points
- Explicit proxies are normally selected by applications; default gateways are selected by the operating system routing table for IP packets.
- VPN, gateway, NAT, TUN, and HTTP/SOCKS5 proxying can appear in the same deployment but they solve different network-layer problems.
- NetConfiger’s current public mode is explicit HTTP/SOCKS5 distribution, so applications must actually support and use the proxy rather than assuming transparent device-wide routing.