VPN vs Proxy: What Each One Covers and What It Doesn't

A VPN and a forward proxy both change the address a website sees, and that is where most comparisons stop. The difference that decides your setup is coverage: a forward proxy is an intermediary your application chooses to use, unlike the reverse proxy that sits in front of a website, and a VPN moves whatever the operating system routes into a tunnel. Encryption, DNS handling and failure behavior all follow from that split. Run these five checks in order, and the first one that fails tells you which tool you actually need.

Which apps does the intermediary cover?

A browser proxy extension applies to that browser profile. Mail clients, package managers and a second browser keep using their own settings, and some applications ignore system proxy variables entirely. A VPN covers what the routing table sends into the tunnel, which can be every application or a split-tunnel subset depending on routes and client policy.

Test the applications that matter instead of extrapolating from one page load. curl https://ifconfig.me follows environment proxy variables; a desktop app may not. On Windows, netsh winhttp show proxy prints the WinHTTP proxy used by services, which is a different setting from the browser's.

Is the hop encrypted, and where does TLS end?

A proxy protocol is a rendezvous, not a guarantee. SOCKS5 forwards TCP without encrypting it, and a plain HTTP proxy carries the request line and headers in clear text. HTTPS through a proxy uses CONNECT, so your TLS session still terminates at the destination rather than at the proxy. The MDN guide to proxy servers and tunneling describes that distinction from the protocol side.

A VPN encrypts the segment between your device and its endpoint. Beyond the endpoint, the same rules apply as on any other network, which is why a tunnel alone does not protect an application that sends credentials over plain HTTP. Neither design hides a logged-in account, a cookie, or a browser fingerprint.

curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/null

The verbose output shows whether curl issued CONNECT to port 443 or a plain GET with a full URL. With socks5h:// the proxy is handed the hostname inside the SOCKS5 request and then relays TLS it cannot read, so it sees the name and the byte counts. Through an http:// proxy an https:// URL is a CONNECT, so that proxy also sees the destination name and volume, not the request or the response body.

Which resolver sees the name?

Name resolution can happen locally before the request leaves, or remotely at the proxy. With curl, socks5h:// sends the hostname to the proxy while socks5:// resolves it locally first. Browser proxy settings expose a comparable DNS option, and PAC files can route different hosts different ways.

Two protocols can bypass a proxy without any misconfiguration. WebRTC gathers candidates over STUN, and QUIC runs HTTP/3 over UDP, which a TCP proxy cannot carry. A browser will fall back to TCP if UDP 443 is blocked, so blocking UDP 443 on the host firewall (or on the router for a whole network), not a browser flag, is the reliable way to keep HTTP/3 inside the proxy path.

Check the resolver from the destination's perspective, not from your laptop's. A request that arrives with the proxy's exit address but a locally resolved name still tells the local resolver which sites you visit.

What happens when the intermediary fails?

An explicit proxy fails closed: stop the proxy process and the browser or app returns a connection error instead of going direct. PAC and WPAD setups are the ones that fail open - if the script cannot be fetched, the client falls back to DIRECT and the site sees your real address again. A VPN can fail open or closed depending on the client and whether a kill switch or firewall rule is active.

Test the failure case on purpose: stop the proxy service and reload; if you get an error page rather than a direct load, point the PAC URL at an unreachable host to see the fallback. If the page still loads through your ordinary route, the proxy offers no protection against its own outage, and that is a property you should know before relying on it.

Order decides what the site sees. A proxy whose outbound travels through the VPN leaves the site seeing the VPN endpoint's address; put the proxy outside the tunnel (VPN to a proxy on a remote host) and the site sees that proxy's exit address instead. Either way the two hops can log different things.

Five checks, in order

The checklist below is the whole decision in one place. Coverage comes first because it eliminates most mismatches: if the app that must be covered does not honor the setting, nothing later in the list rescues it.

Then confirm the result with the app that motivated the change. Load a page in the configured browser, fetch the same page with curl, and compare the address each one reports. If they disagree, an extension, a PAC rule, or an app-level override is still in play, and no amount of tunnel tuning will fix it.

Record what you configured: which apps use the proxy, whether DNS is local or remote, whether UDP is blocked, and what the failure behavior is. That small inventory is what makes the next comparison possible, because "the IP changed" never told you which of these five checks passed.