Puppeteer控制的是Chromium，但代理通常在启动浏览器进程时通过--proxy-server确定。页面创建以后再修改Node环境变量，不会自动迁移已经建立的浏览器连接。需要不同出口的并行任务，还要考虑BrowserContext是否足以隔离代理，不能只隔离Cookie就认为网络也独立。
一、最小启动配置
const browser = await puppeteer.launch({
args: ['--proxy-server=http://proxy.example:8080']
});上述示例只指定代理服务器，不包含真实凭据。HTTP和SOCKS代理应使用Chromium支持的明确格式，并与服务端协议一致。
二、为什么代理认证需要单独处理
启动参数决定连接哪个代理，但账号密码可能通过页面认证API、受支持的浏览器机制或外部网关完成。认证方式受Chromium版本和代理挑战影响。把密码直接拼入启动参数，可能出现在进程列表、日志或错误报告中，不是稳妥做法。
收到407时，可参考代理认证机制与排查。
三、Browser、Context和Page分别隔离什么
| 对象 | 主要隔离内容 | 代理注意 |
|---|---|---|
| Browser进程 | Chromium进程与网络栈 | 启动代理通常在此层确定 |
| BrowserContext | Cookie、存储和会话 | 不应默认拥有独立进程级代理 |
| Page | 标签页与页面生命周期 | 共享Browser网络能力 |
多租户任务需要不同代理、DNS和连接池时，独立Browser进程边界更清楚，但资源占用也更高，需要测量容量。
四、浏览器下载阶段为何另算
Puppeteer安装或首次准备Chromium时，请求由Node安装流程发出，--proxy-server尚未生效。应检查包管理器、下载源、环境变量和运行环境CA。相关方法见npm、pnpm与Yarn代理配置。
五、绕过列表如何影响结果
Chromium支持代理绕过规则，但语法与通用NO_PROXY不完全相同。内部域名、本机服务和测试API应按目标逐项验证。若规则过宽，主页面可能走代理，XHR或WebSocket却直连，最终看到混合出口。
六、SOCKS5的DNS在哪里解析
是否由代理解析目标域名，取决于Chromium和代理配置方式。仅看到SOCKS连接成功，不能说明DNS没有在本地泄露。应在授权环境同时观察代理请求和DNS查询，并测试不存在域名、IPv4与IPv6目标。
七、HTTPS证书错误怎么处理
启动时忽略证书错误会改变浏览器安全行为，不应作为正式自动化默认值。应检查容器系统时间、CA证书、代理是否做TLS检查、SNI和证书链。证书排查见HTTPS代理TLS与SNI检查。
八、请求拦截不是代理替代品
Puppeteer的请求拦截适合修改或模拟受控测试请求，不等同于网络层正向代理。它无法自然覆盖浏览器的所有连接、DNS和协议行为。不要用拦截器伪造出口验证，也不要在未授权站点执行大规模自动化访问。
九、CI容器中常见的假性网络故障
- 浏览器与Puppeteer版本不匹配；
- 缺少运行依赖或共享内存不足；
- 容器没有企业CA或正确DNS；
- 代理密码被Shell转义破坏；
- 并发Browser过多导致CPU和代理连接耗尽。
十、代理切换的正确生命周期
完成当前页面任务后，关闭旧Browser，创建带新代理启动参数的新进程，并从授权出口检测端点验证。不要修改共享全局变量后复用旧Browser。对任务队列，可按代理配置维护有限的Browser池，并在凭据轮换时有序淘汰。
十一、验证清单
- 记录Puppeteer和Chromium版本；
- 用单Browser测试HTTP、HTTPS和WebSocket；
- 验证正确与错误代理凭据；
- 测试应代理和应绕过的目标；
- 观察DNS、IPv4与IPv6路径；
- 关闭Browser后切换代理并重测；
- 检查日志、截图与Trace不含秘密。
十二、结论
Puppeteer代理应围绕Chromium进程生命周期设计。启动参数、认证、绕过、证书和多任务隔离是不同问题；只有重新创建并验证浏览器，才能确认代理切换真正生效。
