Ask five people what a proxy server is and you'll probably get five different answers. One will mention the thing their office uses to block YouTube. Another will talk about scraping prices off retail sites for a living.
They're all right, sort of. A proxy is just a server that passes your traffic along and shows its own IP address instead of yours. But that simple job comes in a lot of flavors, and picking the wrong one is how projects end up stuck behind CAPTCHAs (or quietly served cached pages from last Tuesday).
Forward vs. Reverse
Start with direction, because everything else builds on it. A forward proxy works for the user. Companies have used them for decades to filter sites and cache downloads, and Squid, which first came out in 1996, is still running in plenty of corporate networks today.
A reverse proxy is the opposite. It sits in front of a website's servers and decides where incoming requests go. Nginx and HAProxy are the usual suspects here, and big sites often stack a few of them.
So which kind are people actually shopping for? Almost always forward proxies, even if they don't call them that.
Most of the categories you'll run into when comparing different types proxy servers fall on that side. Reverse proxies are more of an infrastructure thing, and Cloudflare has a solid explainer on how they spread load and handle TLS for busy sites.
Then there's the transparent proxy. Nobody configures it and nobody sees it, yet hotel Wi-Fi and some ISPs push traffic through one anyway, mostly for caching and filtering.
The Protocol Question
Here's where it gets a bit more technical. HTTP proxies understand web traffic. They can read requests, cache pages and mess with headers, but that's about all they're good for.
HTTPS works a little differently. Your client sends a CONNECT request, the proxy opens a tunnel, and from then on it can see where you're going but not what you're sending.
SOCKS5 doesn't care what the traffic is. It was written up in RFC 1928 back in March 1996, listens on port 1080 by default and will relay pretty much any TCP or UDP connection, so email clients and FTP tools work fine through it.
The trade-off? No caching, no inspection. Some people would call that a feature.
Where the IP Actually Comes From
Honestly, this is the part most buyers care about. Datacenter proxies use IPs owned by hosting companies. They're fast and cheap, but any site that checks who owns the network can spot a hosting range almost instantly.
Residential proxies borrow real home connections from consumer ISPs. They look like regular visitors, which is why teams use them for ad verification or for checking what local search results look like. They're also slower and cost noticeably more.
ISP proxies try to get the best of both: hosted in a data center, but registered to a consumer ISP. Mobile proxies go a step further and use 4G or 5G carrier IPs. Carriers squeeze hundreds of phones behind a single address with CGNAT, so blocking one of those IPs means blocking a lot of real customers, and most sites won't do it.
Why are good IPs so pricey anyway? Because IPv4 addresses ran out in the 2010s as the regional registries emptied their pools, and clean addresses now get bought and sold like any other asset.
Static or Rotating, Shared or Dedicated
On top of all that, there are a couple of settings to pick. Static IPs stay the same for weeks, which is what you want for managing accounts. Rotating ones change with every request or every few minutes, so they're better for big data collection jobs.
Shared IPs are cheaper. The catch is that someone else's bad behavior can get the address flagged, and if you're logged in to anything that matters, that's not a risk worth saving a few dollars on.
What Comes Next
The IP address alone won't get anyone very far for much longer. Anti-bot systems already look at browser fingerprints and TLS handshakes, so a perfectly good residential IP running a sloppy script still gets blocked in minutes.
And once IPv6 catches on more widely, with its 2^128 addresses, scarcity stops mattering and reputation is everything. The smart move hasn't changed, though: figure out the task first (which site, how long the sessions run), then pick the proxy type. Not the other way around.