Forward Proxy

A forward proxy is a server that a client deliberately sends its outbound HTTP requests through. This lets one intermediary act on the traffic of a whole group of clients. RFC 9110 section 3.7 calls this component simply a “proxy”: “a message-forwarding agent that is chosen by the client, usually via local configuration rules, to receive requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface.” The same section explains why organizations run one. Proxies are often used to “group an organization’s HTTP requests through a common intermediary for the sake of security services, annotation services, or shared caching”. In practice, that means filtering, logging, authentication, and a cache shared by many users.

A forward proxy is not a CDN. A CDN is the mirror image: a gateway, or reverse proxy. RFC 9110 defines it as an intermediary that “acts as an origin server for the outbound connection but translates received requests and forwards them inbound to another server or servers”. The gateway stands in front of the origin, not in front of the clients, and the client never chose it. A forward proxy is not a VPN either. A VPN relays IP packets and never reads the HTTP request. A proxy, by contrast, is defined by satisfying requests for absolute URIs through the HTTP interface. Nor is a forward proxy the same thing as a transparent or intercepting box on the network path. RFC 9110 is explicit that an “interception proxy” (also commonly known as a “transparent proxy”) “differs from an HTTP proxy because it is not chosen by the client”. It also groups such devices with lower-layer intermediaries that are “indistinguishable (at a protocol level) from an on-path attacker”.

How it works

1. The client is pointed at the proxy. A user or an administrator sets the proxy in browser or operating-system settings, or the browser loads a proxy auto-config (PAC) file. Cloudflare describes one as “a text file written in JavaScript that specifies which traffic should redirect to the proxy server”. Such a file can pick a different proxy per destination. The choice belongs to the client side. That is what makes the proxy a forward proxy.
2. Plain HTTP requests carry the whole URL. In HTTP/1.1 the rule is absolute: “When making a request to a proxy, other than a CONNECT or server-wide OPTIONS request …, a client MUST send the target URI in ‘absolute-form’ as the request-target” (RFC 9112 section 3.2.2). For example: GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1. The proxy, not the browser, therefore resolves the hostname and opens the onward connection. HTTP/2 has no request line. It conveys the same information in the :scheme and :authority pseudo-header fields instead (RFC 9113 section 8.3.1).
3. HTTPS goes through a tunnel, not through the proxy’s parser. The client first sends a CONNECT request. Its request target consists “of only the host and port number of the tunnel destination, separated by a colon”. On success, the proxy must “restrict its behavior to blind forwarding of data, in both directions, until the tunnel is closed”. The tunnel is then “secured using TLS” (RFC 9110 section 9.3.6). TLS runs end to end between client and origin. So the proxy learns the destination host and port and nothing else.
4. The proxy applies policy to what it can see. It may demand credentials. The “Proxy-Authorization” header field “allows the client to identify itself (or its user) to a proxy that requires authentication”. Unlike Authorization, it “applies only to the next inbound proxy that demanded authentication” (RFC 9110 section 11.7.2). The proxy may then filter, log, and answer from a shared cache: “a cache that stores responses for reuse by more than one user” (RFC 9111 section 1). That cache obeys the same directives a CDN obeys. s-maxage overrides max-age “for a shared cache”. An unqualified private directive means “a shared cache MUST NOT store the response” (RFC 9111 section 5.2.2.10 and section 5.2.2.7).
5. Every hop signs the message. “A proxy MUST send an appropriate Via header field … in each message that it forwards” (RFC 9110 section 7.6.3). Each intermediary appends its own entry. So the forwarding chain is visible to the server at the end of it.
6. The client’s address has to be put back deliberately. Proxying loses it, so RFC 7239 defines the Forwarded field to “disclose information that is altered or lost when a proxy is involved in the path of the request”, such as the source IP address. That section says more. Forwarded “is an OPTIONAL header field”. It “should be turned off by default”. Each parameter “should be configured individually”. It is “only for use in HTTP requests and is not to be used in HTTP responses” (RFC 7239 section 4). Most real deployments still send the older X-Forwarded-For. RFC 7239 itself notes it is “widely used” (section 8.3).

Why it matters for a CDN

A CDN edge server is a reverse proxy. So a forward proxy and a CDN sit at opposite ends of the same chain. When one of your users is behind a corporate forward proxy, the request path is client → forward proxy → CDN edge → origin. Both the CDN and the origin see the proxy rather than the person. RFC 1919 is the document RFC 9110 still cites for the term “transparent proxy”. It states the consequence: “server software that accepts connections that have gone through a classical proxy do not see the IP address of the incoming client, unless this information is included in the application protocol”. That last clause is the whole game. The address survives only if something deliberately forwards it.

So every CDN feature keyed to the client address degrades at once. With an explicit proxy, the proxy performs the DNS lookup. So Geo DNS steers on the proxy’s resolver rather than the user’s location, and geo-blocking sees the proxy’s country. WAF rules and IP-bound token checks judge the wrong actor. Per-IP rate limits put an entire office behind a single counter, so one noisy client can throttle or block everyone who shares the egress. Caching gains a layer you do not control either. The corporate proxy is a shared cache in front of yours, bound by your s-maxage and private directives, and only for the traffic it can actually read.

What CDNs do

CDN delivery is reverse-proxy work. So an edge server is not a forward proxy. Forward proxying appears in CDN vendors’ catalogues as a separate, licensed Zero Trust secure-web-gateway product. Customers point their own employees at it.

• Cloudflare Gateway, part of Cloudflare One, proxies client traffic outbound: “You can forward HTTP and network traffic to Gateway for logging and filtering”. “Gateway will accept the connection and establish a new, separate connection to the origin server”. Devices are pointed at it with the Cloudflare One client. Or, as the docs put it, “To proxy HTTP traffic without deploying the Cloudflare One Client, you can configure PAC files on your devices”, hosted at proxy endpoints.
• Akamai Secure Internet Access Enterprise offers two proxy modes. A selective proxy inspects only traffic to domains it judges risky and “is available with an SIA Intelligence license”. A full web proxy analyzes all web traffic. It can be fed from Akamai’s client, an existing on-premises proxy, browser or computer proxy settings, or IPsec tunnels from branch offices.

Both can only inspect HTTPS by terminating it. Both say so. Akamai: “The proxy acts as a MITM to intercept TLS/SSL traffic … An IT or Desktop administrator deploys the certificate across the enterprise network.” Cloudflare, for its proxy endpoints: “You must install a Cloudflare certificate on your devices.”

Watch out for

• Never trust a forwarded client address from a hop you do not control. RFC 7239 warns that the Forwarded field “cannot be relied upon to be correct, as it may be modified, whether mistakenly or for malicious reasons, by every node on the way to the server, including the client making the request” (section 8.1). X-Forwarded-For is no better. Accept the value only from the immediate hop you operate. Overwrite whatever the client sent.
• HTTPS blinds an explicit proxy, and un-blinding it is invasive. Over CONNECT, the proxy is a blind relay that knows only host and port. So it can neither cache nor inspect the body. Reading it means installing a proxy-generated CA on every device that must trust it. That changes the certificate the user is served. Akamai’s SIA Proxy documents that it “downgrades the certificate to domain-validated (DV) certificates” and “does not support origin websites that require certificate authentication”. So mTLS clients break behind it.
• HTTP/3 is where forward proxies and CDNs collide. CDNs serve HTTP/3 over QUIC on UDP. Forward proxies handle it inconsistently, per vendor and per setting. Akamai states that “SIA Proxy does not support the QUIC protocol, the technology that’s behind HTTP/3”. Cloudflare Gateway needs both TLS decryption and the UDP proxy enabled. It documents that Gateway “will then intercept the HTTP/3 connection and connect to the origin server over HTTP/2. Otherwise, HTTP/3 traffic will bypass inspection.” Either way, a user behind a forward proxy may reach your edge on an older protocol than they would directly. So do not read your CDN’s HTTP/3 adoption figures as a client capability.
• An intercepting box is not an HTTP proxy. A device that needs no client configuration works below HTTP. RFC 9110 says an interception proxy “filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic)” and is “commonly found on public network access points … and within corporate firewalls to enforce network usage policies”. RFC 1919 explains why it is hard to diagnose. A transparent proxy “is often described as a system that appears like a packet filter to clients, and like a classical proxy to servers”.
• Via can be deliberately misleading. An intermediary at a firewall “SHOULD NOT forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so” and should substitute “an appropriate pseudonym” instead (RFC 9110 section 7.6.3). An intermediary “MAY combine an ordered subsequence of Via header field list members into a single member”. A Via chain is a hint about the path, not an inventory of it.
• Anonymity is narrower than users assume. “Users that do not actively choose an anonymizing proxy cannot rely on having their IP address shielded” (RFC 7239 section 8.3). A forward proxy hides the client from the server beyond it. It does not hide the client from the proxy operator, who is normally logging precisely that.

Best practice

• Decide and document which you run: an explicit proxy that clients choose through browser, OS or PAC configuration, or a lower-layer interception device. Only the first is a proxy in the specification’s sense. The two fail in different ways.
• Allow CONNECT so HTTPS clients get an end-to-end tunnel, but constrain it. RFC 9110 is blunt: “There are significant risks in establishing a tunnel to arbitrary servers”, and “Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable list of safe request targets”. Its own example is a CONNECT to port 25 turning the proxy into a spam relay (RFC 9110 section 9.3.6).
• Require proxy authentication and restrict who may relay. An unauthenticated forward proxy reachable from the public Internet is an open relay and will be found and abused.
• Have the proxy insert the real client address. Enable only the parameters you actually need: RFC 7239 says each “should be configured individually” and that the field “should be turned off by default”. Strip any inbound Forwarded or X-Forwarded-For before adding your own.
• Drive CDN geo, WAF, token and rate-limit decisions from that forwarded identity rather than the connecting address. That way, one office egress is not treated as one user.
• Expect TLS interception to break clients that need the origin’s real certificate. Akamai lists client-certificate authentication and extended-validation certificates among what its proxy cannot preserve. Keep a documented bypass list for destinations that must not be inspected. Akamai’s own limitations page recommends exactly that: “you can configure requests to bypass the proxy by creating a custom list with the domains you want to allow”.