What is a Web Proxy?

A web proxy is an intermediary server that sits between a client and the websites it visits, forwarding HTTP and HTTPS requests under its own IP address. Because the destination site sees only the proxy’s address, the proxy can enforce security policy, cache content to speed up browsing, and keep the originating user anonymous.

Key takeaways

• Forwards web requests under its own IP, hiding the client’s address.
• Clients connect explicitly via HTTP CONNECT, or transparently.
• Enables caching, URL filtering, and TLS decryption for inspection.
• SD-WAN traffic steering can route proxy traffic by transport or app.
• Proxy chaining lets a branch forward specific traffic to another proxy.

On this page: Why it matters · How it works · Types · Web Proxy & Versa · FAQ

Why is a web proxy important?

Enterprises have long used web proxies as the enforcement point for internet-bound traffic. Routing every HTTP/HTTPS request through one intermediary gives security teams a single place to apply URL filtering, inspect TLS sessions, and log which users reached which sites – control hard to reproduce once traffic breaks out directly from dozens of branches. Because the destination server only sees the proxy’s address, it also shields client addresses from the sites they visit.

Proxies matter operationally too: endpoints reach the internet via the configured proxy address, often through a PAC file, instead of a LAN-wide default route, and caching serves repeat requests locally instead of re-fetching them. As SD-WAN moves internet access from central breakout to direct breakout per branch, proxy traffic still needs a clear path out – so it is increasingly paired with traffic steering rather than replaced by it.

What is a web proxy?

A web proxy sits between a client and the site it is accessing: the client sends its HTTP or HTTPS request to the proxy, which makes the request to the destination on the client’s behalf. In explicit mode, the client is configured, manually or via a PAC file, with the proxy’s address and port, and uses HTTP CONNECT to ask the proxy to open a connection to the target; the client skips DNS resolution, the proxy does it instead. In transparent mode, traffic is intercepted in-path with no client-side configuration.

When TLS inspection is required, the proxy terminates one TLS session with the client and opens a second with the server, decrypting and re-encrypting traffic in the middle – a design that needs a CA certificate the proxy uses to impersonate the destination to the client.

Types of web proxies

Explicit web proxy is the most common form: the client is configured with the proxy’s address and port and sends CONNECT requests directly, giving full visibility but requiring endpoint setup, typically via a PAC file.

Transparent web proxy intercepts traffic in-path with no client configuration – useful when a branch needs to break out specific SaaS traffic locally even though clients still point at a centralized explicit proxy.

Chained (cascaded) web proxy forwards specific traffic from one proxy to another instead of straight to the internet, for example a branch that breaks out one SaaS application locally while chaining the rest to a data center proxy.

Cloud-delivered proxy moves the same function to a cloud security provider’s points of presence, reached over a GRE or IPsec tunnel, so no on-premises appliance is needed.

Web Proxy & Versa

VOS devices can act as a web proxy, listening for HTTP CONNECT requests on a configured IP and port and applying firewall, URL filtering, and TLS decryption policy to everything that passes through. Explicit Web Proxy with SD-WAN Traffic Steering walks through a full example: VOS terminates the client’s TLS session, inspects the decrypted traffic, and re-encrypts it toward the real destination, while a DNS proxy profile resolves hostnames on its behalf.

Because proxy traffic is just another flow to the SD-WAN engine, traffic steering rules can match it by application or URL category and pin it to a transport. The Versa SD-WAN Design Guide covers the broader pattern: centralized, transparent, and chained proxies alongside DNS proxy.

Frequently asked questions

What is the difference between an explicit and a transparent proxy?

Explicit proxies require the client to be configured with the proxy’s address and port and send CONNECT requests directly. Transparent proxies intercept traffic in-path with no client configuration, useful when a branch needs to redirect sessions locally.

Does a web proxy replace a firewall?

No. A web proxy forwards and can inspect traffic, but enterprises pair it with firewall policy, URL filtering, and TLS decryption – the proxy is the choke point, the firewall the policy.

Why does a web proxy need TLS decryption for HTTPS?

Without decryption, a proxy only sees encrypted bytes. With decryption enabled, it terminates the client’s TLS session, inspects the plaintext, then opens a second session to the real server, acting as an authorized man-in-the-middle using an uploaded CA certificate.

Can SD-WAN steering control which link proxy traffic uses?

Yes. Proxy sessions are ordinary flows to the SD-WAN engine, so steering rules can match them by destination, application, or URL category and pin them to a preferred transport, with automatic failover.

What is proxy chaining?

Proxy chaining forwards specific traffic from one web proxy to another instead of sending it directly to the internet – for example, a branch that breaks out one SaaS application locally while forwarding the rest to a data center proxy.

More on Web Proxy

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about web proxy, these are worth looking at next.