What Is a Transparent Proxy? How Interception Works, and How to Detect One

Networking guide · Last reviewed 1 October 2026 · 18 min read

A transparent proxy is a proxy you never configured. It sits in the network path, on a router, a firewall or a gateway, and catches your web traffic on its way out, so your browser thinks it is talking straight to the website while an intermediary is actually handling the request. The standards call it an interception proxy; you will also see “inline proxy” and “forced proxy”. This guide explains how interception works (policy routing, WCCP, iptables REDIRECT and TPROXY), what such a proxy can and can’t see on HTTP and HTTPS, where networks use it, how to detect one, and how it differs from an explicit proxy you set up yourself, such as a rotating residential proxy.

What is a transparent proxy?

An ordinary proxy is something you choose. You enter its address in a browser, an operating system setting or a script, and your software sends requests to it on purpose. An interception proxy works the other way round. The network operator puts it in the path, and a router, switch or firewall quietly diverts your connections to it. Your device doesn’t know it is there.

The HTTP specification, RFC 9110, describes it in exactly those terms: an interception proxy, also commonly known as a transparent proxy, differs from an HTTP proxy because it is not chosen by the client. Instead, it filters or redirects outgoing TCP port 80 packets, and occasionally other common ports. RFC 9110 adds that such proxies are commonly found on public network access points, to make users sign up before they can reach the internet, and inside corporate firewalls to enforce usage policies.

The name itself is a known source of confusion. RFC 3040, the IETF’s web caching taxonomy from 2001, points out that the caching industry used “transparent” to mean “zero configuration in the user agent”, while the HTTP/1.1 specification of the time used “transparent proxy” for a proxy that doesn’t modify requests or responses. Because of that clash, RFC 3040 introduced the term “interception proxy” for proxies that receive traffic redirected to them by network elements. Both names are still in use, and this guide treats them as the same thing.

How traffic interception works

Interception has two halves. First, something in the network has to send the client’s packets to the proxy box instead of routing them normally. Second, the proxy box has to accept connections that are addressed to somebody else’s IP, and work out where they were really going.

EXPLICIT PROXY (the client knows)
browser  --  GET http://example.com/ HTTP/1.1  -->  proxy 192.0.2.10:3128  -->  example.com

INTERCEPTION PROXY (the client doesn't)
browser  --  GET / HTTP/1.1, Host: example.com  -->  to 203.0.113.80:80
                          |
               router / firewall redirects TCP port 80
                          v
                 proxy process :3129  -->  example.com
                 (answers as if it were 203.0.113.80)

Step 1: getting the packets to the proxy

• Inline placement. The simplest case: the proxy is the router or gateway, so all traffic already passes through it. RFC 3040 calls this being directly in-line with the flow of traffic.
• Policy-based routing. A router matches traffic, for example TCP to port 80 from the office LAN, and forwards it to the proxy’s address instead of the default route. The Squid documentation recommends policy routing when the gateway and the proxy are separate machines.
• WCCP. The Web Cache Coordination Protocol, originally from Cisco, lets caches register with a router, which then redirects matching traffic to them, over GRE or by rewriting layer-2 addresses. RFC 3040 notes that one proxy can tell the router how to spread traffic across an array, and the Squid FAQ adds the useful part: if the cache goes offline, the router stops redirecting and users are unaffected.
• Layer 4 switches and appliances. Load-balancing switches can match port 80 and hand the flow to a cache farm.

Step 2: accepting the connection on the proxy

Once the packets arrive, the proxy host’s kernel needs to deliver them to the proxy process even though they are addressed to the website’s IP. Linux offers two ways.

NAT, with iptables REDIRECT. The REDIRECT target, per the iptables-extensions manual, works only in the nat table and sends the packet to the machine itself by changing its destination IP to the address of the incoming interface, optionally with a new port via --to-ports. The proxy then asks the kernel’s connection tracking for the original destination. The website sees the proxy’s own IP address.

TPROXY, without NAT. The Linux kernel’s transparent proxy documentation describes TPROXY as similar functionality without relying on NAT. The TPROXY target lives in the mangle table, redirects the packet to a local socket without changing the packet header in any way, and sets a firewall mark that policy routing uses to deliver the packet locally. The proxy’s socket must set IP_TRANSPARENT, which the Linux man page says requires the CAP_NET_ADMIN or CAP_NET_RAW capability and lets the program bind to a non-local address. That is what allows a proxy to connect upstream using the client’s own IP, as long as return traffic is routed back through the proxy box. Since Linux 4.18 the same feature is available in nftables.

# send packets that belong to an existing local socket straight to it
iptables -t mangle -N DIVERT
iptables -t mangle -A PREROUTING -p tcp -m socket --transparent -j DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT

# hand new port-80 connections to the proxy listening on 50080
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \
  --tproxy-mark 0x1/0x1 --on-port 50080

# deliver marked packets locally
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

# nftables equivalent of the TPROXY rule (Linux 4.18+)
nft add rule filter divert tcp dport 80 tproxy to :50080 meta mark set 1 accept

HTTP vs HTTPS: what an intercepting proxy can see

On plain HTTP, the intercepted request is readable text. The proxy sees the method, the path, every header and the body, and it learns the intended site from the Host header. It can serve a cached copy, block the request, rewrite the response or log it.

HTTPS changes that. The browser starts a TLS handshake with what it believes is the website, and the proxy can’t read the request inside. What it can see is the destination IP address and the Server Name Indication (SNI) extension, defined in RFC 6066, in which the client names the host it wants in its first handshake message. That is enough to allow or block by domain, and to log which sites were visited, but not which pages.

To see more, the proxy has to terminate TLS: present its own certificate for the site, decrypt, inspect, and open a second TLS connection to the real server. Squid calls this SslBump, and its http_port documentation says plainly that in this mode Squid decrypts HTTPS messages and becomes the man-in-the-middle. The certificates are generated on the fly and signed by a local certificate authority, so every client has to trust that CA. Squid’s own setup guide walks through creating the CA and importing it into browsers; without that step, its documentation notes that most user agents will warn about a possible man-in-the-middle attack. That’s why TLS interception is realistic on company laptops and school devices with managed certificates, and not on a stranger’s phone on public Wi-Fi.

Two newer developments shrink what a proxy can see even further. RFC 9849, published in March 2026, defines TLS Encrypted Client Hello (ECH), which encrypts the ClientHello, including the SNI, under the server’s public key; its introduction calls the plaintext SNI perhaps the most sensitive information left unencrypted in TLS 1.3. And HTTP/3 runs over QUIC, which is carried in UDP, so a proxy that only intercepts TCP never sees it. RFC 9114 says clients should fall back to TCP-based HTTP when UDP is blocked, which is how networks that block UDP port 443 bring that traffic back within reach.

Where transparent proxies are used

Public Wi-Fi and captive portals

The login page at a hotel, airport or café is the best-known example. Until you accept the terms or pay, the network intercepts your web requests and answers them with its own sign-in page. RFC 8952, the IETF’s captive portal architecture, is blunt about the older way of doing this: current solutions typically forge DNS or HTTP responses, and some attempt a man-in-the-middle proxy of HTTPS. Its appendix explains why operating systems test for a portal with a plain-HTTP “canary” request to a known address: a network with a captive portal may intercept the connection, which would cause a host name mismatch over TLS.

Companies and schools: filtering, caching and logging

Intercepting at the gateway means every device is covered without configuring each one, including guest devices and anything that ignores proxy settings. Typical jobs are blocking categories of sites, enforcing an acceptable-use policy, logging which domains were visited, scanning downloads for malware and caching large, frequently requested files to save bandwidth. Where the organisation manages its devices, it can install its own CA and decrypt HTTPS too; elsewhere it filters by SNI.

ISPs and caching

Caching was the original reason for interception. RFC 3040 describes redirecting traffic to caching proxies so they can be deployed without reconfiguring each user agent, and the Squid FAQ’s WCCP and layer 4 switch recipes come from that world. That made interception attractive to anyone paying for upstream bandwidth, internet providers included. RFC 9110 also describes transforming proxies, with the example of one that converts between image formats to save cache space or reduce traffic on a slow link. A cache in the middle can’t read or store encrypted pages, though, so as the web moved to HTTPS this kind of interception came to matter far less. Carrier networks still put many subscribers behind shared addresses, which is a different technique, explained in our guide to CGNAT.

CDNs

Content delivery networks are also sometimes called transparent, because visitors never configure them, but they are not interception proxies. A CDN edge is a reverse proxy that the site owner puts in front of their own servers, and visitors reach it through the site’s DNS records. RFC 3040 calls such devices surrogates: gateways that operate on behalf of one or more origin servers and typically deliver responses from an internal cache.

Transparent reverse proxies

“Transparent reverse proxy” usually means something narrower: a load balancer that connects to the backend servers using the visitor’s own IP address as the source, so the servers see real client addresses without reading any headers. It’s the same kernel feature as above, used in the other direction.

HAProxy calls this full transparent proxy mode. Its configuration manual describes the usesrc keyword of the source directive, which makes HAProxy connect to servers with an address that doesn’t belong to the system itself, typically the client’s. For it to work, the backend servers have to route their replies back through the HAProxy machine, and it needs root privileges or the cap_net_raw capability. One of the manual’s examples:

backend transparent_smtp
    # Connect to the SMTP farm from the client's source address/port
    # with Tproxy version 4.
    source 0.0.0.0 usesrc clientip

Most setups don’t need this. The more common approach is to let the reverse proxy connect from its own address and pass the client’s IP in an X-Forwarded-For or Forwarded header, as covered in our forward proxy vs reverse proxy guide.

Example: Squid as an interception proxy

Squid is a long-established open-source caching proxy, and its wiki documents interception in detail. The minimal NAT setup has two parts: a dedicated Squid port flagged intercept, and iptables rules on the same machine that redirect port 80 to it. The http_port reference defines intercept as support for IP-layer NAT interception delivering traffic to this Squid port, and notes that it disables authentication on the port.

# squid.conf
http_port 3128              # normal port for clients configured to use the proxy
http_port 3129 intercept    # receives only NAT-redirected traffic

# iptables on the Squid machine itself (Squid wiki: LinuxRedirect)
SQUIDIP=192.168.0.2
SQUIDPORT=3129
iptables -t nat -A PREROUTING -s $SQUIDIP -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port $SQUIDPORT
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -t mangle -A PREROUTING -p tcp --dport $SQUIDPORT -j DROP

Each line has a reason, and the wiki explains them. The first rule exempts Squid’s own outbound traffic; without it first, the page warns, you can get forwarding loops. The last rule, in the mangle table, blocks direct connections to the intercept port from outside, which the wiki calls a very good idea because of NAT security vulnerabilities. And the NAT must run on the Squid box, because Squid needs the kernel’s record of the original destination. To intercept on a separate gateway, the wiki says to use policy routing to deliver the traffic to Squid rather than NAT on the router.

For TPROXY instead of NAT, the Squid wiki uses a dedicated port with the tproxy flag (http_port 3129 tproxy), the mangle-table DIVERT and TPROXY rules shown in Figure 2 with --on-port 3129, and the policy routing rule for mark 1. In that mode Squid connects to websites using the client’s IP address, so the reply path has to lead back through the Squid machine.

For port 443, Squid can intercept and peek at the TLS handshake without decrypting. The wiki’s “basic splicing” example only observes the SNI and server certificate so they can be logged, then passes the connection through as an untouched TCP tunnel:

# squid.conf: intercepted port 443 traffic, redirected to 3130
https_port 3130 intercept ssl-bump tls-cert=/etc/squid/myCA.pem generate-host-certificates=on

# read the TLS ClientHello (SNI), log it, then splice: no decryption
ssl_bump peek all
ssl_bump splice all

Squid also protects interception setups from a specific attack. Its host header forgery check, added in Squid 3.2, resolves the domain the client claims to be visiting and compares it with the IP address the connection was really going to. RFC 9110 explains the risk: an interception proxy that trusts the Host header for routing or as a cache key, without checking it against the intercepted destination, is particularly vulnerable to cache poisoning.

How to detect a transparent proxy

1. Look for proxy headers on plain HTTP. RFC 9110 requires a proxy to send a Via header in each message it forwards, in requests and responses. Fetch a plain-HTTP page and inspect the response headers, and if you control a server, log the request headers it receives. Via, X-Forwarded-For or Forwarded entries you didn’t add point to an intermediary. Squid, for example, adds Via and X-Forwarded-For by default.
2. Compare your IP on HTTP and HTTPS. Many intercepting setups only catch port 80, and a NAT-based one connects from its own address. If an HTTP-only IP check shows a different address from an HTTPS one, something is intercepting port 80.
3. Check who issued the site’s certificate. If a site’s certificate chain ends at your company’s, school’s or security software’s CA instead of a public one, your HTTPS is being decrypted in the middle.
4. Watch the error pages. The Squid FAQ notes that when a site is down, an intercepted browser still connects to the interceptor, so you may get the proxy’s error page, or a hang, instead of the browser’s own connection error.
5. Notice the captive portal prompt. A “sign in to network” notification means your device’s canary request was intercepted.

# response headers from a plain-HTTP site: look for Via or proxy cache headers
curl -sI http://example.com/

# who issued the certificate you actually receive for a site
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer

A clean result doesn’t prove there is no proxy. Squid’s via setting can be switched off and its forwarded_for setting can delete the header, and a TPROXY setup connects from your own address. The certificate check, on the other hand, is reliable: a proxy that decrypts HTTPS has to present a certificate that it, or a CA it controls, has signed.

Transparent vs explicit (forward) proxy

An explicit proxy, also called a forward proxy or non-transparent proxy, is one the client is configured to use. The difference shows up on the wire. RFC 9112 says that a client talking to a proxy must send the full URL in “absolute-form” (GET http://example.com/ HTTP/1.1), and RFC 9110 defines CONNECT for HTTPS, which asks the proxy to open a tunnel and then blindly forward the encrypted data. An intercepted client does neither, because it thinks it is talking to the website directly.

The authentication row is worth a note. The Squid FAQ explains that with interception, the client thinks it is talking to an origin server and would never send a Proxy-Authorization header, so proxy sign-in simply can’t happen. Commercial proxy services are explicit proxies, and you sign in to use them. If you want to try one from the command line, our curl with proxy guide shows the flags.

Risks and side effects

• It breaks end-to-end assumptions. RFC 3040 records the argument that introducing an interception proxy is itself a denial-of-service attack, since the end-to-end nature of the internet is destroyed without the user’s knowledge. The Squid FAQ lists practical breakage: path MTU discovery can fail, making some remote sites inaccessible, and WebSockets and other protocols tunnelled over the intercepted port can stop working.
• Everyone shares one address. With NAT interception, the Squid FAQ notes that IP-based authentication at the origin fails because all users appear to come from the cache’s own IP.
• It is a single point to attack. RFC 3040 warns that redirection is susceptible to denial of service at the redirect point, and that caching proxies can give intruders access to information previously only available at the network level.
• Decryption is sensitive. Squid’s SslBump page warns that decrypting HTTPS without user consent or knowledge may violate ethical norms and may be illegal in your jurisdiction. If you run TLS interception, tell users and exempt categories such as banking, as the Squid examples do.

The other meaning: transparent as an anonymity level

Proxy lists and IP-checker sites use “transparent” for something else: the lowest of three anonymity levels. In that sense, a transparent proxy is one you did configure, but it forwards your real IP address to the website, typically in X-Forwarded-For, and announces itself with a Via header. An anonymous proxy hides your IP but still reveals that a proxy is involved, and an elite proxy hides both. A network-level interception proxy may or may not behave like that; the two ideas overlap only in name. We cover the three levels, and how to test a proxy for them, in proxy anonymity levels explained.

Where ProxyEmpire fits

ProxyEmpire proxies are explicit forward proxies. Nothing is intercepted: you point your browser, app or script at the gateway, v2.proxyempire.io on port 5000 for residential and mobile, and sign in with a username and password, over HTTP, HTTPS or SOCKS5. The website’s connection comes from the ProxyEmpire exit IP, so your own IP address isn’t passed to the site: our gateways don’t add it to X-Forwarded-For or any other forwarding header. For HTTPS, the proxy relays an encrypted CONNECT tunnel and can’t read or change your requests. Only ports 80 and 443 are open by default and there is no UDP, so browsers use HTTP over TCP rather than HTTP/3.

Keep expectations realistic: a different IP isn’t anonymity on its own. Cookies, logged-in accounts and your browser’s fingerprint can still identify you, so treat the proxy as one layer. ProxyEmpire’s own “ProxyEmpire Proxy Manager” Chrome extension, which includes WebRTC leak protection, and the Android app of the same name make the browser and phone setup quicker. For locations, rotating residential proxies cover 30M+ IPs in 179 countries and territories and rotating mobile proxies 4M+ IPs in 174 countries, with targeting by country, region, city, ZIP, ISP or carrier, ASN and OS fingerprint at no extra charge, and rotating or sticky sessions. Static residential and datacenter proxies are available too, with country-level targeting. Residential starts at $3.50/GB and falls to $1.50/GB, unused bandwidth rolls over, uptime is 99.9% on the public status page, support is 24/7 from real people, and the $1.97 trial includes 100 MB of residential and 50 MB of mobile traffic.

Transparent proxy FAQ

References

1. IETF — RFC 3040, “Internet Web Replication and Caching Taxonomy” (2001). rfc-editor.org/rfc/rfc3040
2. IETF — RFC 9110, “HTTP Semantics” (2022): sections 3.7 Intermediaries, 7.6.3 Via, 9.3.6 CONNECT. rfc-editor.org/rfc/rfc9110
3. IETF — RFC 9112, “HTTP/1.1”: section 3.2.2 absolute-form. rfc-editor.org/rfc/rfc9112
4. IETF — RFC 7239, “Forwarded HTTP Extension”. rfc-editor.org/rfc/rfc7239
5. IETF — RFC 6066, “TLS Extensions: Extension Definitions” (Server Name Indication). rfc-editor.org/rfc/rfc6066
6. IETF — RFC 9849, “TLS Encrypted Client Hello” (2026). rfc-editor.org/rfc/rfc9849
7. IETF — RFC 9114, “HTTP/3”. rfc-editor.org/rfc/rfc9114
8. IETF — RFC 8952, “Captive Portal Architecture”. rfc-editor.org/rfc/rfc8952
9. Linux kernel documentation — “Transparent proxy support” (TPROXY). docs.kernel.org/networking/tproxy
10. Linux man-pages — iptables-extensions(8): REDIRECT and TPROXY targets. man7.org/iptables-extensions.8
11. Linux man-pages — IP_TRANSPARENT(2const). man7.org/IP_TRANSPARENT.2const
12. Squid wiki — Interception Caching FAQ. wiki.squid-cache.org/SquidFaq/InterceptionProxy
13. Squid wiki — Linux traffic interception using REDIRECT. wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect
14. Squid wiki — TPROXY v4.1+ support. wiki.squid-cache.org/Features/Tproxy4
15. Squid wiki — SslBump Peek and Splice. wiki.squid-cache.org/Features/SslPeekAndSplice
16. Squid wiki — SslBump. wiki.squid-cache.org/Features/SslBump
17. Squid wiki — Host header forgery detected. wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery
18. Squid configuration reference — http_port. squid-cache.org/Doc/config/http_port
19. HAProxy 3.2 configuration manual — “source” and “usesrc”. docs.haproxy.org/3.2/configuration
20. OpenSSL documentation — openssl-s_client. docs.openssl.org/openssl-s_client