Playwright使用代理时，首先要分清两个阶段：执行playwright install下载浏览器，以及测试运行时由Chromium、Firefox或WebKit访问页面。安装下载通常由Node进程和安装脚本完成；浏览器启动后的代理则由Playwright启动参数或上下文配置控制。把两者混在一起，是最常见的排障弯路。
一、浏览器级代理的基本结构
Playwright启动浏览器时可提供代理服务器地址，并按API支持设置账号、密码和绕过规则。示意代码如下：
const browser = await chromium.launch({
proxy: {
server: 'http://proxy.example:8080',
username: process.env.PROXY_USER,
password: process.env.PROXY_PASS
}
});真实凭据应来自秘密变量，不应写入测试仓库或截图。
二、HTTP代理与SOCKS代理有什么差别
| 类型 | 主要特点 | 验证重点 |
|---|---|---|
| HTTP代理 | HTTPS常通过CONNECT隧道 | 407、CONNECT、TLS与目标端口 |
| SOCKS5 | 转发TCP连接 | 认证、域名解析位置与客户端支持 |
| 无认证代理 | 配置简单 | 访问控制与来源白名单 |
| 账号密码代理 | 可做细粒度授权 | 凭据保护与浏览器兼容 |
三、Browser和BrowserContext的边界
一个Browser进程可包含多个Context，但是否能为每个Context分配独立代理，取决于Playwright版本、语言绑定和浏览器实现。需要多出口隔离时，应先做小规模兼容测试；若行为不明确，使用独立Browser进程通常更容易界定连接池、DNS和生命周期。
四、浏览器下载失败应该查什么
安装阶段应检查运行安装命令的Node进程环境、下载源、代理变量、CA证书和CI网络。测试代码中的launch({proxy})还没有执行，不能影响已经失败的安装脚本。Node工具链代理可参考npm、pnpm和Yarn代理配置。
五、页面能打开，为什么接口或WebSocket失败
页面主文档、子资源、API、WebSocket和下载文件可能使用不同域名和连接类型。应在测试Trace、网络事件和代理日志中查看实际请求。WebSocket还可能受升级握手、空闲超时和心跳影响，相关排查见代理下WebSocket断线分析。
六、代理认证失败怎么判断
HTTP 407表示代理要求认证，页面自身的401通常属于目标服务。凭据写对仍失败时，要确认代理支持的认证机制、浏览器实现和CONNECT阶段。Basic、Digest、NTLM的差异见代理认证与407排查。
七、bypass列表为什么会造成出口不一致
绕过列表用于让指定主机直连，但匹配语法、端口和子域规则需按当前实现验证。若把过宽的域名后缀加入列表，页面主请求可能走代理，API却直连，或者反过来。测试报告应同时记录目标主机和实际出口，而不是只截一张IP页面。
八、HTTPS证书错误怎么处理
ignoreHTTPSErrors适合受控环境中定位问题，不应成为正式测试的默认值。应检查系统时间、容器CA、代理是否做TLS检查、证书链和目标域名。否则测试可能在证书异常时仍显示通过，失去真实用户路径的验证价值。
九、CI容器中还要检查什么
- 浏览器依赖与Playwright版本是否匹配；
- 容器是否拥有正确DNS和CA证书；
- 代理变量是否只注入需要的Job；
- 共享内存、资源限制是否造成假性网络超时；
- Trace、视频和日志是否包含敏感Cookie或代理凭据。
十、如何验证代理确实生效
- 访问自有或授权的出口检测端点；
- 记录浏览器类型、版本、代理配置版本；
- 测试主文档、API、WebSocket和文件下载；
- 分别验证代理目标与bypass目标；
- 测试错误凭据是否明确返回认证失败；
- 关闭并重新创建浏览器，排除旧连接复用；
- 检查日志和Trace已脱敏。
十一、连接复用会影响切换吗
浏览器会复用HTTP/1.1和HTTP/2连接。修改配置后，已启动的Browser不一定自动迁移到新出口。应结束旧Context或Browser，按已验证的生命周期重新创建。批量测试还需控制并发，避免把代理容量问题误认为页面代码失败。
十二、结论
Playwright代理配置应拆分为安装阶段、浏览器进程、Context和具体请求。先确定失败在哪一层，再验证认证、绕过、证书与连接生命周期，才能得到可重复的自动化测试结果。
