Branch Browser to Proxy: Two Connections, Two Routes

A branch browser behind an explicit proxy opens two connections, and they fail for different reasons. The first is browser to proxy listener, carried through the site VPN. The second is proxy to website, using the proxy's own resolver, route and egress policy. Support tickets that treat them as one flow send people to the wrong device for hours. Set each one up deliberately and test them in that order.

Step 1: write the two flows down

The browser's immediate destination is the proxy listener, not every site the user eventually visits. That single sentence resolves most of the confusion in this design.

branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> website

Different sources, different routes, different permissions. Keep the sketch in the change record, because every later check refers to one of its two halves.

Step 2: give the browser a path to the listener

Record the proxy hostname, the listener port, the authentication requirements and the permitted branch sources. That list is the acceptance criteria for the first flow, and it should include private name resolution as well as the tunnel route.

Apply a narrow network rule for the intended service instead of publishing an unrestricted proxy to the internet. The proxy can stay on an internal network when its intended clients have a supported path to it.

Step 3: configure the browser, not just the route table

Use the browser's proxy setting, a PAC file, or the organization's managed discovery mechanism. Sending ordinary website packets toward the proxy address with a route does not make the browser speak the proxy protocol; that is transparent interception and it belongs to a different gateway design.

Write down which applications honour the setting. Mail clients, updaters and games often do not, and they will keep using the plain path.

Step 4: prove the proxy's onward connection

The proxy needs its own resolver and a permitted route to the website, plus whatever firewall or translation policy its internet boundary requires. A browser that reaches the listener proves none of that. Test the second flow from the proxy itself, using the same destination and port the user reported.

For HTTPS, CONNECT opens a tunnel to the requested destination. Ordinary forwarding does not hand the proxy the decrypted page, and disabling certificate validation to improvise inspection is not a fix.

Step 5: tell four failures apart

A proxy authentication challenge is a 407 from the listener. A denied CONNECT is a policy decision on the proxy, usually with its own status and log line. A failed onward connection looks like a timeout or reset that the proxy logs against the destination. A website response means both connections worked and the problem is at the origin.

Report the boundary you observed, not the summary that the VPN failed.

Step 6: scope it and plan the fallback

Decide what happens when the proxy or the tunnel is unavailable, and say plainly which traffic this design covers. It carries web access from clients that honour the proxy setting; it does not carry mail, arbitrary device protocols or software that ignores the configuration.

Validate the required browser operation and one required denial under an approved plan before extending the design to more clients.