2026
Forward Proxy: Controlling Outbound Traffic
A forward proxy sits between clients and the internet. Requests go through it before they leave the network. Here is what that means in practice, how HTTPS tunnelling works and where forward proxies actually show up.
Most proxy conversations online are actually about reverse proxies. Load balancers, TLS terminators, CDN edge nodes. Those sit in front of servers. A forward proxy sits in front of clients. It intercepts outbound requests before they leave the network.
The distinction matters because the two solve different problems for different people. A reverse proxy is invisible to the user and configured by the operator. A forward proxy is configured by whoever controls the client and is invisible to the destination. Understanding that difference makes it easier to reason about where each one belongs.
What a forward proxy is
A forward proxy is a server that sits between a client and the wider internet. When the client wants to reach a destination, the request goes to the proxy first. The proxy evaluates the request, applies any rules, then forwards it to the destination on the client's behalf. The response travels back through the same path.
From the destination's perspective, the conversation is with the proxy. It does not know who originated the request. From the client's perspective, it sent a request and received a response. The proxy is transparent to the end result even though it handled every packet in between.
This is the key property: the client knows about the proxy. The client's software is explicitly configured to route through it. That explicit configuration is what makes it a forward proxy rather than a transparent intercepting device.
How a request flows through it
The steps are straightforward once you see the request path laid out. Each hop has a specific role.
Request path through a forward proxy
Client (browser, curl, application)
↓ sends request to proxy address, not destination
Forward proxy
↓ checks rules (allow list, deny list, auth)
↓ optionally caches or logs the request
↓ opens connection to destination using its own IP
Destination server
↓ processes request, returns response to proxy
Forward proxy
↓ passes response back to the original client
Client receives response
For plain HTTP traffic, the proxy reads the full request and constructs its own outbound connection. For HTTPS, most proxies use a mechanism called CONNECT. The client sends a CONNECT request to the proxy asking it to open a TCP tunnel to the destination. Once the proxy acknowledges, the client negotiates TLS through that tunnel directly with the destination server. The proxy passes the encrypted bytes through without being able to read them.
CONNECT tunnel for HTTPS
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
# Proxy responds:
HTTP/1.1 200 Connection Established
# Client now negotiates TLS directly through the tunnel
Why you would run one
Forward proxies solve several different problems. The right one to reach for depends on what you are actually trying to achieve.
Privacy
The destination server sees the proxy's IP address rather than the client's. This separates the client's identity from the request. It does not make traffic anonymous end-to-end but it does prevent the target server from logging the originating address directly.
Content filtering
Organisations route outbound traffic through a proxy that blocks requests to specific domains or categories of site. The proxy inspects each request before forwarding it. Requests that match a deny list are dropped before they leave the network.
Access control
A proxy can require authentication before forwarding requests. This gives network administrators visibility into who is making requests and allows per-user policies rather than blanket network rules.
Caching
A forward proxy can cache responses from frequently visited destinations. When a second client requests the same resource, the proxy serves the cached copy without making an outbound connection. This reduces bandwidth on networks with many users hitting the same content.
Bypassing restrictions
If a network blocks access to certain destinations at the firewall level, routing through a proxy located outside that network can reach them. This is the mechanism behind most consumer VPN-adjacent tools. The local network sees traffic to the proxy. The proxy forwards it onward.
Forward proxy versus reverse proxy
The naming is what trips people up. Both types are proxies. Both sit between two parties and forward traffic. The difference is which side they serve and who knows they are there.
Who configures it
Forward
The client. The client's browser or OS must be told to route through the proxy.
Reverse
The server operator. Clients connect to it without knowing it exists.
Who it serves
Forward
The client. It acts on behalf of outbound requests.
Reverse
The server. It acts on behalf of inbound requests.
What the origin server sees
Forward
The proxy's IP address rather than the client's.
Reverse
The proxy's IP address rather than the upstream server's internal address.
Typical use
Forward
Privacy, filtering, corporate egress control, caching outbound content.
Reverse
Load balancing, TLS termination, caching inbound responses, DDoS protection.
A useful way to keep them straight: a forward proxy is configured on the client side and protects the client's identity from servers. A reverse proxy is configured on the server side and protects the server's infrastructure from clients. Same forwarding mechanic, opposite direction of concern.
Configuring a client to use one
Because the client must be explicitly configured, there are several ways to set this up depending on what is making the requests.
Shell environment variables
export http_proxy=http://proxy.internal:3128
export https_proxy=http://proxy.internal:3128
export no_proxy=localhost,127.0.0.1,.internal
Most command-line tools including curl and package managers respect http_proxy and https_proxy when set in the environment. The no_proxy variable holds a comma-separated list of hosts that should bypass the proxy entirely. Local addresses and internal domains belong there.
curl with explicit proxy flag
$ curl -x http://proxy.internal:3128 https://example.com
# Or with authentication:
$ curl -x http://user:pass@proxy.internal:3128 https://example.com
In containerised environments the environment variables are typically injected at the workload level or set cluster-wide so every container routes outbound traffic through a central egress proxy without any per-application configuration.
Squid
Squid is the most widely deployed open-source forward proxy. It has been around since 1996. Corporate networks have used it for egress filtering for decades. It handles HTTP caching, access control lists and SSL bumping for HTTPS inspection.
SSL bumping is worth understanding separately. When a proxy needs to inspect HTTPS traffic it cannot just pass a CONNECT tunnel through untouched. Instead, it terminates the TLS connection from the client using its own certificate, reads the plaintext request, then opens a new TLS connection to the destination. The client sees a certificate issued by the proxy rather than by the real server. For this to work without browser warnings, the proxy's certificate authority must be trusted by the client. This is how corporate content inspection tools operate on managed devices.
Minimal squid.conf snippet
http_port 3128
acl localnet src 10.0.0.0/8
acl SSL_ports port 443
acl CONNECT method CONNECT
http_access allow localnet
http_access deny all
The access control list model in Squid maps well to most organisational policies. You define named groups of IPs, ports or domains then write allow and deny rules against them. Rules are evaluated top to bottom. The first match wins.
Where it fits
Forward proxies show up in a few recurring situations. Corporate networks use them to control what employees can reach from company devices. Security teams use them to log outbound connections from servers so that unexpected traffic stands out. Developers use them locally to inspect what an application is actually sending before it leaves the machine.
The mechanism is the same in each case. Clients route through the proxy. The proxy sees the request. Whatever policy applies gets enforced before the connection reaches its destination. The destination knows nothing about who originated it.
Once you have seen it laid out as a request path, most proxy tools become easier to read. The configuration is almost always describing the same three things: which clients to accept, which destinations to allow or deny and what to do with the traffic in between.