VPN vs proxy, what you actually need

The airport Wi‑Fi test

I’m in an airport lounge, half awake, trying to push a quick patch before boarding. The Wi‑Fi has one of those cheerful captive portals and a password printed on a napkin.

Slack connects. Git pulls. Then my browser starts throwing weird certificate warnings on a random news site.

That’s when “VPN vs proxy” stops being a tidy comparison chart and turns into a practical question: what do you need right now to get your work done without handing the network operator a front-row seat.

VPNs aren’t magic.

But they change who can see what, and that’s the whole point.

What a proxy actually does (and what it doesn’t)

A proxy is a middleman. Your app talks to the proxy server, and the proxy talks to the internet. People use proxies for lots of reasons: getting a different exit IP, bypassing a basic blocklist, or routing one chat app without touching the rest of the phone.

The crucial detail is scope. Most proxies are per-app or per-client.

That sounds small, but it’s the source of most confusion. If you set a SOCKS5 proxy in Firefox, only Firefox uses it. Your system update service, your DNS lookups, and that one stubborn app that ignores system settings keep using the regular connection.

A proxy doesn’t cover your whole device.

There are a few common proxy “shapes” you’ll run into:

• HTTP/HTTPS proxy: usually for browsers and corporate environments. Works fine for web traffic, gets awkward with non-web apps.
• SOCKS5: more general-purpose. A lot of apps can speak it, and many developer tools support it.
• Shadowsocks-2022: technically a proxy protocol, but designed for hostile networks and censorship conditions.

If you’ve used Shadowrocket on iOS or V2RayNG/NekoBox on Android, you’ve probably toggled between “proxy” mode and “VPN” mode inside the same app. That’s where the vocabulary gets messy. Many of these clients create a local VPN interface on your phone, then implement proxy-style routing rules inside it. Functionally, you get per-domain rules and app-based routing, but the OS thinks it’s a VPN.

So what does a proxy protect you from?

If your traffic is already HTTPS (most web and most APIs), the Wi‑Fi operator can’t read the content. A proxy can still be useful for changing your apparent location or escaping a block.

What it usually won’t do is give you consistent privacy across the whole device. DNS is the classic leak. Unless you force DNS through the same tunnel (or you use encrypted DNS correctly), your network can still learn what hostnames you’re looking up, even if the pages load over HTTPS.

And if you’re on an app that still uses plain HTTP anywhere, a random “free proxy” is basically asking for trouble.

VPNs: the boring tunnel that saves you

A VPN is simpler conceptually. The device creates an encrypted tunnel to a VPN server, and the VPN server forwards traffic out to the public internet. The key change is that the local network sees one encrypted flow, not a bunch of distinct connections.

On modern clients, WireGuard is the baseline. It’s lean, fast, and behaves well on mobile radios. It runs over UDP (often on port 51820 by default), which is great until you hit a network that blocks UDP or only allows traffic on 80 and 443.

When UDP is blocked, you have options, and none are perfect. Some VPNs offer TCP-based modes, and a lot of the “anti-censorship” crowd uses Xray-based setups like VLESS+REALITY because they can blend in on port 443 in ways that survive picky firewalls. If you’ve ever configured Hiddify or a V2Ray client, you’ve seen how flexible (and how annoying) this can get.

Here’s the part people skip: with a VPN, you’re swapping trust.

Your ISP can’t see your browsing destinations as clearly, and the café Wi‑Fi can’t casually snoop your traffic. The VPN provider can. Even if they don’t log, they still sit at the choke point.

In practice, I treat a VPN like a cleaner network, not like a cloak of invisibility. It’s great at reducing exposure to local networks and making traffic harder to profile from the outside. It won’t fix weak account security, a compromised device, or a browser full of questionable extensions.

Speed, battery, and the stuff that breaks

People ask which is faster, proxy or VPN. The honest answer is “it depends,” and that’s not a dodge.

Latency is about distance and routing. If your proxy or VPN server is in the next city over, it can be snappy. If it’s across an ocean, your ping won’t be pretty no matter what protocol you pick.

Protocol choice matters too. WireGuard is usually low overhead, especially on mobile where CPU time equals battery. Some proxy stacks add overhead in weird places, like wrapping TCP inside TCP, which can lead to nasty stalls when packet loss spikes. On a moving phone, packet loss is a fact of life. Elevators, subways, dense city blocks, all of it.

Battery life matters.

VPNs keep state. They have to, because the OS wants the tunnel to stay up, and the client needs to detect when your IP changes or your phone roams between Wi‑Fi and LTE. A well-built WireGuard client is pretty gentle, but always-on tunneling still adds work. On iOS, the system is aggressive about background behavior, so some clients feel “sticky” when switching networks.

Proxies can feel lighter because they’re often only used by one app. The catch is that the moment you need five apps routed the same way, you end up stacking workarounds: per-app proxy settings, PAC files, and random “does this app even support SOCKS?” experiments.

Then things break.

A few real failure modes I keep seeing:

• DNS going outside the tunnel: you connect, the IP changes, but your DNS still hits the ISP resolver. Your browsing looks “private” until you check.
• One app ignores your proxy: many streaming apps and some games do their own networking. They’ll bypass your neat configuration.
• Captive portals: the hotel Wi‑Fi login page won’t load when the VPN is already forced. Sometimes you need to connect, log in, then enable the tunnel.

If you run a router at home, a VPN can be cleaner. Put it on an OpenWrt box, and everything behind it just works. Smart TVs, consoles, the weird IoT junk you regret buying. Proxies don’t scale like that unless you enjoy maintaining exceptions for every device.

So which one do you really need?

I decide based on what I’m trying to prevent, not on ideology.

If I’m on a trusted home network and I only need to route one thing (say, a single app that’s blocked on public Wi‑Fi), a proxy-style setup is fine. Shadowsocks-2022 is a solid choice in places where ordinary VPN traffic gets throttled or flagged.

If I’m on unknown Wi‑Fi, I want a VPN. I want the whole device covered, including the weird background services I’m not thinking about when I’m just trying to send an email.

If you want a quick rule without turning this into a philosophy debate, here’s what I do:

• Use a proxy when you only need one app or one browser to exit somewhere else, and you’re not trying to protect the rest of the device.
• Use a VPN when the network itself is the problem (airport, hotel, coworking), or when you need consistent behavior across apps.
• Use an Xray-style setup (VLESS+REALITY) or Shadowsocks-2022 when you’re dealing with active blocking and UDP is unreliable or filtered.
• Use router-level VPN when you’re tired of configuring every device separately.

There’s also a middle ground I use a lot: split tunneling. Work traffic and banking apps go through the tunnel, while local network stuff (printers, Chromecast, LAN SSH) stays direct. It reduces weird breakage and can help with battery on mobile.

One more opinion, since people don’t like hearing it: “free proxy” lists are a mess. Some are honeypots. Some are misconfigured. Many are slow because they’re overloaded. If you wouldn’t paste your password into a random website, don’t route your traffic through a random server you found on a forum thread.

Near the end of my own testing loop, when I just want a paid service that behaves predictably across iOS, Android, and a laptop without endless tweaking, I point people at DuduVPN and let them start from the Telegram bot at https://t.me/duduvpnsbot.

Whatever you choose, test it by checking both your IP and DNS after you connect, because half the “VPN vs proxy” arguments come down to leaks nobody bothered to verify.