A forward proxy is a server that sits between users and the internet and makes requests on their behalf: the client sends its request to the proxy, the proxy fetches the destination, inspects or filters the result, and returns it. Every secure web gateway ever sold is a forward proxy. What changed over twenty years is only where the proxy sits: first an appliance in your data center, then a vendor's cloud, and now, with dope.security, the device itself. The forward proxy's defining cost, that all traffic must route through the proxy before reaching the internet, is inherited by every cloud SWG rather than solved by it. Running the proxy on the endpoint keeps the control and removes the detour.

This is the explainer for anyone who has heard "explicit proxy," "transparent proxy," "PAC file" and "cloud proxy" used in the same meeting and wants the plain-language map. It covers what a forward proxy does, how it differs from a reverse proxy, the ways clients get pointed at one, why SSL inspection turns a proxy into a security product, and how the three generations of forward proxy compare on the one metric users feel. If you want the security-product framing first, what is a next-gen SWG covers the category this article sits underneath.

What is a forward proxy?

A forward proxy acts for the client. When a user's browser wants example.com, it does not connect to example.com; it connects to the proxy and asks the proxy to fetch example.com. The proxy opens its own connection to the destination, retrieves the response, applies whatever policy it has (block, allow, log, scan, rewrite) and hands the result back. To the destination server, the request appears to come from the proxy's IP address, not the user's.

Enterprises deploy forward proxies for four reasons that have not changed since the 1990s: to filter which sites employees can reach, to scan downloads for malware, to log who went where, and to hide internal addresses from the outside world. Caching used to be a fifth reason, back when bandwidth was scarce and pages were static. Today the first four are the job, and the fourth is mostly a side effect.

Forward proxy vs reverse proxy: which direction does it face?

The two are mirror images. A forward proxy sits in front of clients and speaks to the internet for them. A reverse proxy sits in front of servers and speaks to the internet for them: it receives inbound requests, terminates TLS, balances load across back-end servers and shields them from direct exposure. Cloudflare's CDN, an NGINX load balancer and an API gateway are reverse proxies. A secure web gateway, a corporate web filter and a cloud SSE node are forward proxies.

The confusion in security conversations usually comes from CASB, which uses both. A CASB in "forward proxy mode" steers managed devices' traffic through it; a CASB in "reverse proxy mode" sits in front of a SaaS app's login to catch unmanaged devices. Forcepoint's reverse-proxy CASB, inherited from Bitglass, is a documented example of how brittle the second pattern is when SaaS apps change their front ends [Documented]. The full taxonomy is in CASB vendors in 2026.

Explicit proxy vs transparent proxy: how does the client find it?

A forward proxy only works if traffic reaches it, and there are three ways to make that happen.

Explicit proxy

The client is told the proxy's address, either by hand in the browser or OS settings or, far more commonly, by a PAC (proxy auto-configuration) file. A PAC file is a small JavaScript function that returns "use proxy X" or "go direct" for each URL. PAC files are how Zscaler and Broadcom historically steered traffic, and they are fragile: they must be hosted, cached, kept in sync and handled by every application that respects system proxy settings, which many do not. Broadcom is deprecating PAC-based redirection in Cloud SWG [Documented], and Palo Alto's Prisma Access Explicit Proxy carries hard limits its own docs list: no HTTP/2, ALPN stripped, decryption mandatory [Documented].

Transparent proxy

The client is not configured at all. A network device (a firewall, a router doing WCCP or policy-based routing, or a GRE/IPsec tunnel from the office) intercepts traffic on ports 80 and 443 and redirects it to the proxy. Transparent proxies are invisible to users until something breaks, and they only work on networks you control, which is why they fell out of favor when the workforce left the office.

Agent-steered proxy

An agent on the device captures traffic at the operating-system level and forwards it to the proxy, wherever it is. This is what Zscaler Client Connector, the Netskope Client and Palo Alto GlobalProtect do. The agent solves the "how does traffic find the proxy off-network" problem. It does not change where the proxy is. The distinction between a steering agent and an inspecting agent is the subject of Zscaler Client Connector vs an on-device agent.

Why SSL inspection is what makes a forward proxy a security product

Roughly 95 percent of web traffic is encrypted [Documented]. A forward proxy that only looks at the destination hostname is a DNS filter with extra steps. To read URLs, file contents, upload payloads or the tenant header that distinguishes a corporate ChatGPT login from a personal one, the proxy has to terminate TLS, inspect the plaintext, and re-encrypt toward the destination with a certificate the device trusts. This is break-and-inspect, and it is the reason every SWG deployment includes a root certificate rollout.

Break-and-inspect has a well-known failure mode: applications that pin their certificates refuse the proxy's substitute and break. Cloud proxies carry long bypass lists for Microsoft 365 components, WebEx, Dropbox and developer tooling such as Docker, Git and Python [Documented]. When inspection runs on the device instead, a pinned-app failure surfaces as an SSL error notification in the console and the bypass is a few clicks, which is one of the reasons a Fortune 100 customer could scale dope.security to more than 18,000 devices in weeks. We cover the mechanics in certificate pinning and SSL inspection and the privacy dimension in on-device vs cloud proxy SSL inspection.

Three generations of forward proxy, one inherited cost

The history of the SWG is the history of moving the forward proxy closer to the user without ever removing it from the path.

Generation one: the appliance

Blue Coat ProxySG, Websense and McAfee Web Gateway sat in the corporate data center. Branch offices backhauled traffic over MPLS to reach them. Fast for people in headquarters, slow for everyone else, and useless once laptops left the building.

Generation two: the cloud proxy

Zscaler, Netskope, Cisco Umbrella SIG, Forcepoint ONE and Prisma Access moved the same proxy into vendor data centers and added an agent to reach it. This fixed the branch-office backhaul and broke the geography differently: now every user, everywhere, detours to the nearest vendor point of presence. Netskope's own SLA is under 10 ms for non-decrypted traffic but 50 ms for decrypted traffic, a five-times penalty for turning on the feature that makes the proxy useful [Documented]. Gartner has cited a 10 to 20 percent throughput reduction for cloud proxy inspection [Documented]. And the shared proxy became a shared point of failure: Zscaler's October 2022 and January 2025 incidents, Netskope's May 2026 management-plane outage and Cloudflare's November 18, 2025 global outage were all shared-infrastructure events that hit every customer routed through the affected nodes at once [Documented]. We tell that story in the backhaul bottleneck and what is backhauling.

Generation three: the on-device proxy

dope.security runs the forward proxy inside the dope.endpoint agent. The agent terminates TLS, inspects, applies URL filtering, Cloud Application Control and Dopamine DLP, and forwards the request from the device straight to the destination. There is no point of presence to reach and no detour to pay for. Policy is authored once in dope.console and pushed to every device in seconds, and enforcement continues from cached policy if the console is unreachable. The agent runs in under 100 MB of RAM and delivers up to 4x performance over legacy proxy SWGs. The architecture is described in cloud proxy vs on-device SWG.

What does the proxy's location cost in latency?

Because a forward proxy is in the path of every request, its location is a tax paid on every request. An appliance taxes remote users. A cloud proxy taxes everyone by the distance to the nearest point of presence, typically 40 to 80 ms near a PoP and 150 to 400 ms far from one, per ThousandEyes and vendor documentation. An on-device proxy taxes nobody by distance, because the proxy is zero network hops from the client. The arithmetic across a page with 20 round trips is in the cloud proxy latency math.

Measure it yourself: the Fly-Direct Speed Test times your real round-trip latency in the browser and shows what a proxy detour adds to common apps. See how Fly Direct removes the hop, or book a 20-minute demo and we will run it on your network.

Takeaway: every forward proxy is in the path; only the on-device proxy is in the path with no distance to travel.

Forward proxy architectures compared

The same control, three places to put it. Each bullet pairs the cloud proxy behavior with the on-device behavior, with the appliance noted where it differs.

• Traffic path: a cloud proxy routes device to PoP to destination and back; the on-device proxy routes device to destination. An appliance routes device to data center to destination and back.
• How the client finds it: a cloud proxy needs a steering agent, PAC file or tunnel; the on-device proxy is on the device already, so there is nothing to find. A transparent appliance needs a network you control.
• SSL inspection cost: a cloud proxy pays a documented latency penalty for decryption (Netskope's SLA: 50 ms decrypted vs under 10 ms not); the on-device proxy decrypts locally with no network penalty.
• Pinned apps: a cloud proxy maintains blind bypass lists; the on-device proxy surfaces the failure as an SSL error notification and the bypass is a few clicks.
• Failure domain: a cloud proxy incident affects every tenant routed through that PoP or control plane; the on-device proxy fails per device and continues from cached policy.
• Privacy and residency: a cloud proxy decrypts your users' traffic in a third-party data center; the on-device proxy decrypts on hardware you own and logs only metadata to the console. See data sovereignty and SSL inspection.
• China and restricted regions: cloud proxies sell China access as a paid uplift or partner-operated service; the on-device proxy has no PoP to reach, so it works without an uplift.
• AI governance: cloud proxies add prompt DLP and tenant control as higher-tier SKUs; dope.security ships three-layer AI governance natively, from Shadow IT discovery to SWG policy to Cloud Application Control, with Dopamine DLP (US Patent 12,464,023) classifying prompts on the device through zero-retention APIs.

The bottom line on forward proxies

A forward proxy is the right control for web, SaaS and AI traffic because it is the only place URLs, payloads and tenant identity can be read. The mistake of the last decade was assuming the proxy had to be a place users travel to. It does not. Put the forward proxy on the device and the filtering, the inspection, the DLP and the logging all survive, while the detour, the bypass lists and the shared outage do not. Customers such as Greylock Partners made that switch in 27 days from first proposal to signed contract. Start a free trial or book a 20-minute demo to see the on-device proxy on your own laptops.

Frequently Asked Questions

Is a secure web gateway a forward proxy?

Yes. A secure web gateway is a forward proxy with security policy attached: URL filtering, malware scanning, SSL inspection and, increasingly, DLP and SaaS tenant control. Appliance SWGs, cloud SWGs and dope.security's on-device SWG are all forward proxies; they differ in where the proxy runs, which determines latency, failure domain and privacy.

Is a VPN a forward proxy?

No. A VPN tunnels all IP traffic to a gateway at the network layer without understanding HTTP. A forward proxy operates at the application layer and understands URLs and requests. Many SASE products combine them by using a VPN-style tunnel to carry traffic to a cloud forward proxy, which is why products like GlobalProtect and Zscaler Client Connector feel like VPNs. dope.security does neither for web traffic: it proxies on the device and sends traffic direct.

What is a PAC file and do I still need one?

A PAC file is a JavaScript function that tells a browser or OS which proxy to use for each URL. Explicit cloud proxies rely on them and they are a recurring source of breakage, which is why Broadcom is deprecating PAC redirection in Cloud SWG. With an on-device proxy there is no PAC file, because the proxy is not at a network address the client has to be told about.

Does a forward proxy hide my IP address?

From the destination server, yes: the request appears to come from the proxy. For a cloud proxy that means your users share egress IP ranges with every other tenant, which some SaaS apps rate-limit or flag. An on-device proxy uses the device's own egress, so the destination sees the same address it would without a proxy.

Can a forward proxy see inside HTTPS?

Only if it performs SSL inspection, terminating TLS with a certificate the device trusts and re-encrypting toward the destination. Without inspection, a forward proxy sees only hostnames, which is roughly the visibility of DNS filtering. dope.security performs SSL inspection on the device, so the plaintext never leaves hardware you own.

How does an on-device forward proxy scale to 10,000 users?

Better than a centralized one, because each device brings its own inspection capacity and there is no shared PoP to size. A Fortune 100 customer scaled dope.security from 900 to over 18,000 devices in a matter of weeks at roughly 3,000 per week through a silent Intune push, with policy managed from one console. The performance and pricing considerations are in the Fly Direct SWG explainer.