VPN vs Proxy: One Is an Application Setting, the Other Is a Route

A proxy is a relay that a program is told to send its requests to. A VPN is a change to your device’s routing table that redirects traffic regardless of what any program wants. Both end up substituting the address a destination sees, which is why they get compared — but everything that actually distinguishes them follows from where the instruction lives, and the most overlooked consequence is what happens to your hostname lookups.

Where each one is configured

A proxy setting is a piece of application configuration. You give a browser, a download tool, or a script the address and port of a relay, and that program routes its own requests there. The setting lives inside the program. Your interfaces are unchanged, your routing table is unchanged, and the operating system is not involved in the decision at all.

A VPN edits the routing table. The client creates a virtual interface and installs a default route pointing at it, so the kernel — not the application — chooses the path. Programs do not need to know a VPN exists and cannot decline to use it. The step-by-step version is in how does a VPN work.

That is the whole distinction. Every other difference people list is a symptom of it.

Why the scope difference is a consequence, not a feature

The usual summary is “a proxy covers one app, a VPN covers the device”. True, but stated as a feature list it invites the assumption that a sufficiently good proxy could cover everything. It cannot, because coverage is not something the relay provides — it is a property of who makes the routing decision.

A proxy covers exactly the programs you configured, and nothing else, ever. On a typical device the things you did not configure include your mail client, your messaging apps, your calendar, cloud file sync, software updaters, your operating system’s own telemetry and connectivity checks, and every application you have not thought about today. All of it continues to leave through your ordinary interface, under your own address.

There is a variation worth knowing: a system proxy setting, which most operating systems offer. It looks device-wide but is only a suggestion — it is a value applications can read and honour, and plenty of software either ignores it or has its own separate setting. Honouring it is a convention, whereas the routing table is enforcement.

What each one does with your hostname lookups

This is the part that decides whether a proxy leaks what you are doing, and it is almost never in the comparison tables.

Before anything can connect to a website, a hostname has to become an address. With a proxy there are two possible arrangements, and which one applies depends on the proxy type and the program’s settings.

The program resolves the name itself, then asks the proxy for that address. Your own resolver receives the query. So your resolver — usually your provider’s — gets a complete record of the hostnames you visit even though the traffic goes through the relay. The DNS resolution chain runs exactly as it would with no proxy at all.

The program passes the hostname to the proxy and lets the relay resolve it. Now your resolver sees nothing and the relay’s resolver sees everything. Some proxy protocols support this and some do not; some clients support it and default to the other behaviour anyway.

The practical upshot is that with a proxy you have to know which arrangement you have, and the tooling rarely tells you plainly. With a VPN the equivalent question is whether the client pointed resolution at a resolver reachable through the tunnel, which is at least a single setting you can inspect — and which fails often enough that it deserves checking. Either way, who runs your DNS resolver is the check that settles it.

What the destination sees in each case

Both substitute the source address, and from the destination’s point of view a request relayed by a proxy and a request forwarded by a VPN exit look broadly alike. Two differences are worth noting.

A proxy operating at the request level may add headers describing the original client, which some do by design and which a destination can read. A VPN forwards packets and adds nothing of the kind.

And a proxy handles only the protocol it was built for. A relay designed for web traffic does nothing for anything else you might want to send, whereas a routed tunnel is indifferent to what it is carrying.

What neither of them changes

Both leave untouched: your accounts and cookies, your browser and device characteristics, your local network addresses, your device’s clock and language settings, and anything you have previously told a service. Neither is anonymity, and neither will move a restriction that was based on your account rather than your address.

Both also leave the operator of the relay or the exit in the same position: able to see the traffic you routed through it. The scope of that visibility differs — one program’s requests versus the device’s traffic — but the structure of the trust is identical. A free browser extension from an operator you cannot name deserves the same scepticism as a VPN service would, and it usually receives far less because it feels like a smaller decision.

Telling which one you are actually running

Browser extensions marketed as VPNs are very often proxies, and the listing will not always say so. Three checks, in order of speed:

1. Look for a new interface. A device-wide tunnel produces one, with its own address and resolver settings. A proxy produces nothing new. How to read your own network settings covers where to look.
2. Check the exit address from two different programs. If a page in the configured browser reports one address and a command-line tool reports your own, you have a proxy.
3. Check the default route. If it still points at your router, nothing device-wide is happening no matter what an icon says.

Choosing by the shape of the problem

• You do not administer the network you are on, and you care what it can observe. Only the routing change answers that, because only the routing change covers the programs you did not configure.
• You want one browser to appear elsewhere while the rest of the device stays local. A proxy is the lighter and more precise instrument, and it is genuinely the better choice here.
• You are testing how something behaves from a different origin. A relay in one window is the right tool for exactly this narrow job.
• You cannot install anything device-wide, on a managed machine, for example. A proxy may be your only option; know what it is not covering.
• You want your name lookups to leave with your traffic. Neither tool does this automatically. It is a setting in both cases, and it is worth verifying separately from the address check.