Proxies Explained: Forward, Reverse, and Why They Are a Security Control Plane

What a proxy actually is

A proxy is a server that makes a network connection on someone else's behalf, so that a policy can be applied at that one point instead of everywhere.

That is the whole idea. Everything else about proxies is a variation on where the proxy sits and who wrote the policy.

Two rough analogies carry most of the way. A forward proxy is your company mailroom. You hand it your outbound letters, it decides what actually goes out, and it keeps a record. A reverse proxy is the receptionist at the front desk of a building. Visitors arrive, the receptionist decides who gets through to which office, and the offices never talk to the street directly.

The common way to explain the difference is direction of traffic. That explanation is not wrong, but it is not useful, because both machines forward requests and both sit in the middle. The useful distinction is ownership of the policy:

• A forward proxy is deployed by the side that originates the traffic. Your organization runs it to control where your users, servers, and AI agents are allowed to connect. The destination usually has no idea it exists.
• A reverse proxy is deployed by the side that receives the traffic. A service owner runs it to control who reaches the origin servers, and to do the work that the origin should not have to do. The client usually has no idea it exists.

Once you frame it that way, the security questions answer themselves. If you want to know what left your network, you need a forward proxy. If you want to protect an application from what arrives, you need a reverse proxy. Most organizations of any size run both, operated by different teams, with different policies, logs, and failure modes.

One more term worth clearing up early. A proxy that passes traffic through without reading or changing it is often called a tunnel or a gateway. That is not a different product category. It is the same proxy operating in a mode where it moves bytes and applies policy on the connection rather than on the content. The distinction matters a great deal for security, and the next section is about why.

The protocols, and why the choice matters

The protocol a proxy speaks decides how much it can see, and therefore how much policy it can enforce. There are four worth knowing.

HTTP proxying. An HTTP proxy receives the full request, including the method, the path, the headers, and the body. It can allow, deny, rewrite, cache, or log any of that. This is the richest form of control available, and it is why almost every corporate web filter is an HTTP proxy.

HTTP CONNECT tunneling. HTTPS breaks the model above, because the client wants an encrypted end-to-end connection. So the client sends CONNECT example.com:443 to the proxy, and the proxy opens a raw TCP tunnel to that host and then simply relays bytes. The proxy now sees the destination hostname and the connection metadata, and nothing else. Message framing for this lives in the HTTP/1.1 specifications, originally RFC 7230 and now RFC 9110 and RFC 9112.

SOCKS5. Defined in RFC 1928, SOCKS5 is a generic connection broker. The client tells the proxy "connect me to this address and port," and the proxy does it. It carries any TCP protocol, not just HTTP, and it can also forward UDP through the UDP ASSOCIATE command, which matters for DNS, for QUIC, and for games and voice traffic. SOCKS5 added authentication, which SOCKS4 lacked entirely.

The critical property of SOCKS5 for a security team: it does not read your traffic, and it does not encrypt it either. It is a relay. Two common misunderstandings follow from this. The first is that SOCKS5 provides privacy, which it does not; it hides your address from the destination and nothing more. The second is that a SOCKS5 proxy can enforce content policy, which it cannot, because content is not something it ever parses.

PROXY protocol v2. When a proxy operates at Layer 4, the backend sees the proxy's IP address rather than the real client's, which breaks rate limiting, geolocation, and audit logs. The PROXY protocol solves this by prefixing the connection with a small header carrying the original source address. Version 2 is the binary form and is what you should be using. One warning: any listener that trusts this header must accept it only from known proxy addresses, because a client that can send it directly can claim to be any IP it likes.

DNS proxying. A DNS proxy sits between clients and resolvers, and it is where a great deal of cheap security value lives, because blocking a name is easier than blocking an address. Encrypted DNS complicates this. DNS over HTTPS and DNS over TLS move resolution inside an encrypted channel that a client may point at a resolver you do not run, which quietly removes your visibility. The practical countermeasure is to force resolution through your own resolver on managed devices and block the alternatives, rather than to try to inspect it.

The practical rule: if you need to enforce policy on content, you need a proxy that speaks the application protocol. If all you need is to control which destinations are reachable, a connection-level proxy is simpler, faster, and much less invasive.

Where a proxy sits in Zero Trust

Zero Trust vendor vocabulary hides a lot of proxies behind marketing names. Almost every product in the category is a proxy with a policy engine and a management console attached.

• A Secure Web Gateway (SWG) is a forward proxy for outbound web traffic, with URL categorization, malware scanning, and usually TLS inspection.
• A Cloud Access Security Broker (CASB), in its inline mode, is a forward proxy that understands specific software-as-a-service applications well enough to write per-action policy, such as allowing a download but blocking a share.
• Zero Trust Network Access (ZTNA) replaces the VPN with a broker that authenticates the user and the device, then proxies a connection to one specific application. The application is never exposed to the network directly.
• SASE and SSE are bundles. SSE is the security services (SWG, CASB, ZTNA, DLP, firewall as a service) delivered from a provider's cloud. SASE is SSE plus the wide-area networking piece.

For how those bundles fit together and what to buy first, see the deeper treatment in Zero Trust Architecture Explained.

The point of the diagram is the order. Identity comes first, then the proxy enforces. A proxy without identity can only write rules about addresses and names. A proxy that knows who the user is, and what device they are on, can write rules that actually mean something.

What TLS inspection can and cannot see

TLS inspection, also called SSL inspection or TLS bumping, is the practice of having a forward proxy terminate the encrypted connection, look inside, and then open a second encrypted connection to the real destination. The proxy presents a certificate it generated itself, and the client accepts that certificate because you installed your organization's root certificate authority on the device.

Say the uncomfortable part plainly: this is the same mechanism as a man-in-the-middle attack. The only differences are that you control the trust store, you told people you were doing it, and you wrote down what you keep. Those differences are not technical. They are governance, and they are the entire justification for the control.

When it works, a bumping proxy sees the full request and response: URLs, headers, form fields, uploaded files, and API payloads. That is what makes data loss prevention and malware scanning possible on web traffic.

There are three situations where it stops working, and it is important to understand that they are not degradations. They are hard stops.

Certificate pinning. An application that pins its certificate has the expected key baked into the app itself and will not accept your CA no matter how correctly you installed it. The application does not fall back to an inspectable connection. It simply fails. This is why banking apps, many mobile applications, and a lot of software update channels have to be bypassed rather than inspected.

Unmanaged devices. Inspection depends entirely on your ability to install a root CA. On a contractor's laptop or an employee's personal phone, you cannot, and you should not want to. There is no partial version of this control.

QUIC. QUIC carries HTTP/3 over UDP with encryption integrated much more deeply than in the TLS-over-TCP model. Many gateways handle QUIC by blocking UDP 443 and forcing clients to fall back to TCP, where existing inspection works. That is a workable answer today and a deteriorating one over time, because more traffic is moving to QUIC and some of it does not fall back gracefully.

Then there is Encrypted Client Hello. ECH encrypts the first message of the TLS handshake, including the Server Name Indication field that says which site the client wants. SNI is what most firewalls and gateways use to identify a destination without decrypting anything, so ECH removes the cheapest visibility signal in the stack.

Here is the accurate 2026 picture, which is less dramatic than the headlines. ECH was published as RFC 9849 in March 2026 as a Proposed Standard. Adoption is real but small: measurements through 2025 found ECH in use on a tiny fraction of connections, well under one percent, and enterprise applications overwhelmingly do not use it. Browsers support it, but a browser only uses ECH when the destination publishes the necessary key in DNS, and many do not.

So the correct posture is neither complacency nor panic. Start moving policy off SNI now, onto identity, device posture, and DNS-layer signals, because those survive. Do it as planned work over the next year or two, not as an incident. If you already have an explicit forward proxy that terminates TLS on managed devices, ECH does not change your visibility at all, because you are not relying on SNI in the first place.

For the practical deployment decisions, including the bypass list you must write before you turn any of this on, see TLS Inspection with a Forward Proxy.

When proxies are the attack

Proxies are dual-use infrastructure, and the offensive side of the market is large, professional, and commercially organized.

The business model is simple. Attackers and fraudsters want to originate traffic from addresses that look ordinary. Residential and mobile IP addresses look ordinary. Data center IP addresses do not, and get blocked or challenged. So there is real money in supplying residential exit nodes, and one common way to supply them is malware.

Socks5Systemz is the clearest documented example. Bitsight's research, published in December 2024, traced a malware family that installs a SOCKS5 proxy on infected consumer machines and rents those machines out as exit nodes, in that case behind a service marketed as PROXY.AM. The reported scale was substantial: a peak of roughly 250,000 compromised systems in early 2024, declining to a daily average in the range of 85,000 to 100,000 by late 2024. The malware itself was distributed by loaders such as PrivateLoader and Amadey, which arrive through the ordinary channels of pirated software, malicious advertising, and phishing.

The pattern did not stop there. In August 2026, Fortinet's FortiGuard Labs documented Evooo1Bot, a Linux botnet active since July 2026 that borrows Mirai's denial-of-service engine and adds encrypted command and control, an SSH brute-force scanner, a credential sniffer, and a SOCKS5 proxy module. It spreads by exploiting known, already-patched flaws in edge devices from vendors including Hikvision, Zyxel, TP-Link, and D-Link. Routers, cameras, and firewalls become proxy exit nodes.

Three defensive conclusions follow, and they are more useful than the threat detail itself.

1. Residential IP space is not a trust signal. A meaningful share of it is rented, and some of it is rented without the owner's knowledge. Do not weight "residential" as safer than "data center" in fraud or abuse scoring.
2. Outbound proxy behavior on your own endpoints is an indicator of compromise. A workstation accepting inbound connections and relaying traffic is not doing anything a workstation should do. Egress logging from your forward proxy is where you notice.
3. Your unpatched edge devices are somebody's inventory. The exploited flaws in Evooo1Bot were all known and fixed. The device on the network boundary that nobody owns is the one that ends up in a proxy botnet.

Controlling what AI agents can reach

This is where proxies became newly interesting, and it is the part most security programs have not caught up with.

An AI agent is a program that decides at runtime what to do next, including which network calls to make. It reaches model APIs, calls tools over the Model Context Protocol (MCP), fetches web pages, installs packages, and holds open WebSocket connections. Every one of those is an outbound connection, and every one of them is a potential path for data to leave.

The forward proxy is the only place in the stack that sees all of it. Controls inside the agent framework are easier to add but weaker in kind, because the thing you are constraining is a system that writes and runs its own code. A framework-level restriction is a request. A proxy the agent's traffic must physically traverse is a boundary.

The design that works is default deny. The agent can reach nothing until a destination is explicitly allowed, and the allowlist is built from observed traffic rather than imagination. Model APIs, tool endpoints, and package registries are three genuinely different risk profiles and deserve separate treatment.

And then the point that most published guidance misses: an allowlist by itself does not prevent exfiltration. If an attacker has achieved prompt injection, they do not need to reach an attacker-controlled server. They can put the data in a free-text field of a destination you already allowed. A comment on your own issue tracker, a message in your own chat workspace, a field in your own CRM. The destination is on the list, the request is permitted, and the data is gone.

Stopping that requires inspecting the request body, not just the destination: scanning for credential patterns, for base64 and other encodings that hide payloads, and for volumes of text that do not match what the tool call should be doing.

There is one specific hole worth naming, because it catches teams who believe they are covered. MCP server traffic often bypasses an allowlist scoped to the agent process. The MCP server is usually its own process, sometimes on its own host, and it makes its own outbound connections to do its job. If you proxied the agent and not the tool servers it calls, you have built a fence with a gate in it. The mitigation is to route the MCP servers' egress through the same proxy.

The implementation details are in Egress Control for AI Agents, and the identity side of the same problem is covered in the non-human identity security tools comparison.

Which proxy solves which problem

Start from the problem, not from the product category.

The unifying idea is worth restating one last time, because it is what makes the topic worth your attention. A proxy is not a networking component that happens to have security features bolted on. It is the place where a policy about traffic can actually be enforced, which is why almost every security product that governs network traffic turns out, underneath the branding, to be a proxy.

Frequently asked questions

What is the difference between a forward proxy and a reverse proxy?

A forward proxy is deployed by the side sending traffic, so your organization runs it to control where your users, servers, and agents connect. A reverse proxy is deployed by the side receiving traffic, so a service owner runs it to control who reaches its origin servers. The machinery is the same. Ownership of the policy is what differs.

Does a proxy encrypt my traffic?

No. A proxy relays or inspects traffic, and encryption is a separate concern. SOCKS5 in particular provides no encryption at all, only address substitution and authentication to the proxy. Any confidentiality comes from TLS running inside the connection. A forward proxy that performs TLS inspection actually reduces confidentiality, because it reads the plaintext by design.

Is a proxy the same thing as a VPN?

No. A VPN moves all of a device's traffic through an encrypted tunnel at the network layer, usually to provide confidentiality or reach a private network. A forward proxy handles specific application traffic, is normally deployed for policy and visibility rather than privacy, and can read what passes through it. They solve different problems and are often deployed together.

Can TLS inspection see everything?

Only on devices whose certificate trust store you control, and never against an application that pins its certificate. A pinned application rejects your certificate and fails outright rather than falling back to something inspectable. Unmanaged devices cannot be inspected at all, and QUIC traffic requires blocking UDP 443 to force a fallback that inspection can reach.

Has Encrypted Client Hello broken TLS inspection?

No. ECH was published as RFC 9849 in March 2026 and encrypts the server name in the TLS handshake, which removes a metadata signal that firewalls use to identify destinations. Measured adoption remains well under one percent of connections. An explicit forward proxy that terminates TLS is unaffected, because it never relied on that signal.

Why do AI agents need an egress proxy?

Because an agent chooses its own network calls at runtime, so you cannot enumerate its destinations in advance, and controls inside the agent framework are requests that agent-generated code can route around. A proxy the traffic must physically traverse is a boundary instead. It is also the only point that sees every model API call, MCP tool call, and WebSocket frame in one place.

Does an allowlist stop an AI agent leaking data?

No, not on its own. An attacker with prompt injection does not need an attacker-controlled server: they can place the data in a free-text field of a service you already permitted, such as your own issue tracker or chat workspace. The request passes policy and the data still leaves. Inspecting the request body for credentials and encoded payloads is what closes that gap.