Proxy Types Explained: HTTP, SOCKS, Transparent, Reverse, Residential

“Proxy” is one of those words that means six different things depending on context. A reverse proxy and a residential proxy share the name but solve totally different problems. An HTTP proxy and a SOCKS proxy operate at different network layers. If you’ve ever felt fuzzy on which is which, this post is the practical taxonomy.

We’ll cover every proxy type you’ll meet in production engineering, what each one does, when it’s used, and how to identify it in your application’s traffic.

The Core Definition

A proxy is an intermediary. Something between two endpoints that relays traffic, often modifying it along the way. That’s it. The variations come from where the proxy sits, what protocol it handles, and whose side it’s on.

The two big architectural distinctions:

• Forward proxy — sits in front of clients. Hides the client from the server. Clients explicitly configure it. Examples: corporate web proxies, NetSkope, Squid configured for outbound.
• Reverse proxy — sits in front of servers. Hides the server from the client. Clients don’t know it’s there. Examples: nginx, Cloudflare, AWS ALB, HAProxy.

Both are called “proxies” but they exist for different reasons.

Forward Proxies

A forward proxy is “on the client side” — typically deployed by an organization to control its users’ outbound traffic.

HTTP Forward Proxy

Designed for HTTP/HTTPS only. Clients configure their browser or system to send requests to the proxy, which forwards them on behalf of the user.

Common uses:

• Corporate networks filtering outbound traffic for compliance/security.
• Schools and libraries restricting what users can access.
• Caching proxies (Squid in its classic deployment) that cache popular content for many users.
• Privacy/anonymization for browsing.

How to identify:

• The X-Forwarded-For header (if proxy is honest) shows the original client IP.
• The Via header often identifies the proxy software.
• The client’s apparent IP is the proxy’s IP, not the user’s.

SOCKS Proxy

Lower-level than HTTP proxy. Works for any TCP-based protocol (or UDP for SOCKS5). Doesn’t parse the application protocol; just relays bytes between a configured client and a remote destination.

Common uses:

• Bypassing restrictive firewalls.
• Generic anonymization for non-HTTP traffic.
• Routing specific applications (like SSH or BitTorrent) through a proxy without affecting other traffic.

SOCKS4 vs SOCKS5:

• SOCKS4 — TCP only, no auth.
• SOCKS5 — TCP and UDP, supports authentication, supports IPv6.

In 2026, SOCKS5 is the default. SOCKS4 is legacy.

Transparent Proxy

A proxy the client doesn’t know about. Configured at the network layer (a router intercepts traffic on certain ports) rather than by the client.

Common uses:

• ISP-level caching or content filtering.
• Corporate networks that filter all traffic without user setup.
• Some CGNAT implementations route through transparent proxies for specific protocols.

How to identify:

• Traffic from your IP arrives at the destination from a different IP — the proxy’s.
• Clients often don’t know they’re being proxied.
• Headers may or may not include X-Forwarded-For (legitimate transparent proxies add them; illegitimate ones don’t).

Reverse Proxies

A reverse proxy is on the server side. Clients connect to the proxy thinking it’s the application server; the proxy forwards (proxies) to actual backend servers.

nginx, HAProxy, Caddy

The classic reverse proxies. Run on your infrastructure in front of your application servers. Handle TLS termination, load balancing, caching, request rate limiting, response modification.

Cloudflare, Fastly, AWS CloudFront

Edge reverse proxies at global scale. Your origin sits behind the CDN; the CDN handles caching, DDoS protection, geographic distribution, anycast routing, and more.

For IP geolocation, edge reverse proxies are useful: they often inject geo headers (CF-IPCountry, CloudFront-Viewer-Country) that your origin can read without an explicit API lookup.

How to identify:

• The client connects to the proxy’s IP, not the backend’s.
• Response headers may indicate the proxy (Server: cloudflare).
• The original client IP is preserved in X-Forwarded-For or CF-Connecting-IP.

Residential Proxies

This is where things get interesting from a fraud-detection perspective.

A residential proxy routes traffic through real residential IP addresses — usually devices in actual people’s homes that have agreed (often via app SDK terms-of-service fine print) to relay traffic for proxy network customers.

The user agreeing isn’t usually doing it consciously: some “free VPN” apps, some browser extensions, some free-to-play games include residential-proxy SDKs in their app to monetize their users’ connections. The user agreed in a 50-page TOS; their connection is now part of someone else’s proxy network.

Why residential proxies exist:

• Scrapers want to look like real users from real ISPs.
• Datacenter IPs are easily detected and blocked.
• Residential IPs come from many countries and from many ISPs, making them harder to filter.

How to identify:

• The IP is a residential IP from a real ISP (Comcast, BT, etc.) — so ASN classification shows it as residential.
• The request pattern is automated (high request rates, unusual timing, no real browser fingerprint).
• The traffic appears from a different country than the user account suggests.
• Threat intelligence providers maintain lists of known residential-proxy IPs.

Why you should care: Residential proxies are the favored tool of sophisticated scrapers, credential-stuffers, and ad-fraud operators. If you’re seeing apparent traffic from “random residential IPs in random countries” that doesn’t match your audience, you may be looking at residential-proxy traffic. See VPN and proxy detection for mitigation strategies.

Datacenter Proxies

The cheap alternative to residential proxies. Traffic comes from a cloud/hosting provider’s IPs — AWS, OVH, Hetzner, DigitalOcean.

How to identify:

• ASN belongs to a hosting/cloud provider.
• Easy to detect via asn_type === 'hosting' in any decent IP geolocation API.

Datacenter proxies are easier to block than residential proxies precisely because the IPs are obviously not residential. For fraud detection, a residential-IP “user” doing bot-like behavior is more suspicious than an obvious cloud-provider IP — but neither is a typical real user.

Web Proxies (Browser-Based)

A specific subtype where the proxy is operated through a web interface. The user visits the proxy site, enters the destination URL, and the proxy fetches and renders the page in its own iframe.

Common uses:

• Bypassing school/work content filters.
• Accessing geo-restricted content (sort of — accuracy depends on the proxy’s IPs).
• Quick anonymous browsing without setup.

How to identify:

• Traffic comes from the web proxy operator’s infrastructure (often a single ASN).
• The User-Agent and Referer don’t match the user’s actual browser.
• Common web proxies (CroxyProxy, hide.me, etc.) are well-known and IP-listed.

VPN Services

Technically a different category — VPNs encrypt and tunnel traffic at the network layer rather than proxying at the application layer. But functionally, they look similar from the destination’s perspective: traffic appears from the VPN’s exit IPs, not the user’s real IP.

For detection and policy purposes, VPNs are usually lumped with proxies. See the VPN/proxy blocking guide for the detection mechanics.

Tor

The most anonymous “proxy” — actually a 3-hop encrypted network where each hop only knows the previous and next hop. From the destination’s perspective, traffic appears from a Tor exit node — a publicly-known list maintained by the Tor project itself.

Tor is the easiest to detect because the exit-node list is published in real time. The detection is binary: the IP is or isn’t a Tor exit node. See how-to-block-vpn-and-proxy-users for handling Tor traffic specifically.

Apple Private Relay

A relatively new entrant. Apple’s iCloud Private Relay routes Safari traffic through a two-hop proxy — first to an Apple-operated ingress, then to a partner-operated egress (Akamai, Cloudflare, Fastly).

The user’s IP at the destination is the egress proxy’s, not Apple’s, not the user’s. Detection signals:

• Egress IPs come from specific shared infrastructure (publicly documented by Apple).
• User-Agent is Safari.
• Most Private Relay traffic stays within the user’s general region (country usually correct, city often not).

Treat Private Relay roughly like a VPN with high baseline accuracy — country is usually trustworthy, city is not.

Cloudflare Warp

Similar concept to Private Relay but Cloudflare’s. Routes user traffic through Cloudflare’s network. From the destination’s perspective: traffic appears from Cloudflare-controlled IPs.

Detection: ASN is Cloudflare (AS13335) for end-user traffic — which is unusual outside of CDN-fronted services. Many fraud-detection systems flag Cloudflare end-user traffic as VPN-like.

Caching Proxies

A purpose-specific class: proxies that exist primarily to cache content. They sit between users and origin servers, serving cached responses where possible.

Examples:

• ISP-level caching proxies (less common in HTTPS-everywhere world).
• Squid configured as a forward-caching proxy.
• CDN edges (which are technically caching reverse proxies).

Functionally, caching proxies look the same as other proxies for IP-detection purposes. The difference is intent — they exist to reduce latency and bandwidth, not to obscure identity.

Identifying Proxies in Your Traffic

For an arbitrary inbound request, the signals are:

Signal	What it tells you
Known proxy IP list	Definite proxy (lists for major VPN/proxy services)
Hosting/cloud ASN	Almost certainly a proxy or automation
Via header present	An honest proxy is in the path
X-Forwarded-For with multiple IPs	Chain of proxies
Tor exit node list match	Tor user
Apple Private Relay egress IP range	Apple Private Relay user
Cloudflare ASN	Could be CDN or Warp
Mismatch: residential IP, automated behavior	Possible residential proxy

Most IP geolocation APIs bundle some of this detection. Ip2Geo returns is_vpn, is_proxy, is_tor flags directly in the response, plus the ASN classification.

Why You Should Care

Each proxy type has different implications:

For fraud detection

• Residential proxies + automated patterns = sophisticated scraping or fraud.
• Datacenter proxies = mostly bots and scripts (some legitimate, some not).
• Tor = anonymous user (suspicious or privacy-conscious, depending on context).
• Private Relay / Warp = privacy-conscious legitimate user.
• VPN = anything; treat as one signal among many.

For geo-personalization

• All proxies obscure the user’s real location at varying degrees.
• Country level: usually fine for VPN/proxy (the egress is somewhere meaningful).
• City level: usually wrong for most proxies.

For analytics

• Bot traffic (proxy or otherwise) should be filtered out.
• Residential proxies are harder to filter; consider behavior patterns alongside IP signals.

For security

• Some proxies are abuse vectors (credential stuffing, scraping).
• Some proxies are legitimate (corporate compliance, privacy).
• Hard-blocking all proxies is rarely the right call. See the VPN/proxy blocking guide for nuanced approaches.

A Quick Reference

Type	Layer	Side	Purpose
HTTP forward proxy	App (HTTP)	Client	Filter, cache, anonymize browsing
SOCKS proxy	TCP/UDP	Client	Generic protocol relay
Transparent proxy	Network	Client (invisible)	ISP/corporate filtering
Reverse proxy	App	Server	Load balance, cache, TLS
CDN edge	App	Server	Global caching, DDoS, geo
Residential proxy	TCP	Client (3rd party)	Scraping, fraud-evasion
Datacenter proxy	TCP	Client	Cheap automation, scraping
Web proxy	App	Client (in-browser)	Bypass filters from anywhere
VPN	Network (encrypted)	Client	Privacy, geo-bypass
Tor	App (multi-hop)	Client	Strong anonymity
Apple Private Relay	App (2-hop)	Client	Privacy-oriented user

TL;DR

• Forward proxy = client-side intermediary. Reverse proxy = server-side intermediary. Same word, opposite use.
• HTTP, SOCKS, transparent are the main forward proxy types.
• CDN edges are essentially reverse proxies at global scale.
• Residential proxies are the favored tool of sophisticated scraping — hard to detect by IP alone.
• Tor and Apple Private Relay are distinct categories with their own detection patterns.
• Use multiple signals to detect proxy traffic: IP lists, ASN classification, behavior patterns.
• Don’t hard-block proxies blindly — many are legitimate privacy tools.

For more on detection patterns and what to do once you’ve identified proxy traffic, see How to Block VPN and Proxy Users and IP-Based Fraud Detection. To experiment with proxy detection on real traffic, the Ip2Geo API includes is_vpn and is_proxy flags in every lookup.