分支机构浏览器到代理：两条连接，两条路由

位于显式代理之后的分支浏览器会打开两条连接，而它们失败的原因各不相同。第一条是浏览器到代理监听器，经由分支 VPN 承载。第二条是代理到网站，使用代理自己的解析器、路由和出口策略。把两者当作一条流程的工单，会让人在错误的设备上排查数小时。请分别有意识地配置，并按这个顺序测试。

第 1 步：把两条流程写下来

浏览器的直接目标是代理监听器，而不是用户最终访问的每个网站。这一句话就能消除这个设计中的大部分混乱。

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

不同的来源、不同的路由、不同的权限。把草图留在变更记录里，因为后续每次检查都指向它的两半之一。

第 2 步：让浏览器有一条通往监听器的路径

记录代理主机名、监听器端口、认证要求以及允许的分支来源。这份清单就是第一条连接的验收标准，其中既应包含内部名称解析，也应包含隧道路由。

为预期服务应用一条狭窄的网路规则，而不是把不受限制的代理发布到互联网。当预期客户端有受支持的路径时，代理可以留在内部网络。

第 3 步：配置浏览器，而不只是路由表

使用浏览器的代理设置、PAC 文件或组织管理的发现机制。仅凭一条路由把普通网站数据包发往代理地址，并不会让浏览器说代理协议；那是透明拦截，属于另一种网关设计。

写下哪些应用会遵守该设置。邮件客户端、更新程序和游戏往往不会，它们会继续走普通路径。

第 4 步：证明代理的去程连接

代理需要自己的解析器和一条通往网站的获准路由，还需要其互联网边界所要求的防火墙或转换策略。浏览器到达监听器并不能证明其中任何一项。请从代理本身测试第二条连接，使用用户报告的同一目的地和端口。

对于 HTTPS，CONNECT 会打开一条通往所请求目的地的隧道。普通转发不会把解密后的页面交给代理，而为了临时凑出检查而关闭证书验证并不是解决办法。

第 5 步：区分四种故障

代理认证质询是监听器返回的 407。被拒绝的 CONNECT 是代理上的策略决定，通常有自己的状态码和日志行。去程连接失败看起来像代理针对目的地记录的超时或重置。网站有响应则说明两条连接都正常，问题在源站。

报告你观察到的边界，而不是“VPN 失败了”这种结论。

第 6 步：界定范围并规划回退

决定代理或隧道不可用时会发生什么，并明确说明这个设计覆盖哪些流量。它承载遵守代理设置的客户端的网页访问；它不承载邮件、任意设备协议或无视该配置的软件。

在把设计扩展到更多客户端之前，按已批准的方案验证所需的浏览器操作和一次必需的拒绝。