Playwright 自动化如何验证每个测试上下文使用了预期的代理 IP 出口
在每个测试上下文内校验出口 IP 与 ASN，记录代理参数、断言和失败表现；复用连接或并行运行时，先确认出口没有串到其他用例。
要验证 Playwright 的每个 context 是否使用了预期出口，先分清两级代理配置：浏览器启动时设置的是默认代理，每个 context 也可以单独配置。设置完成后，在 context 创建后立即检查出口 IP；并发测试时，还要确认每个用例拿到的是自己的预期出口。
Playwright 的代理配置分为浏览器级和 context 级
browserType.launch({ proxy }) 会作用到所有 context；要每个 context 不同出口，必须配在 browser.newContext({ proxy }) 上。这是 Playwright 的 context 级选项，具体可用参数和浏览器支持范围以所装版本的官方文档为准（playwright.dev/docs/api/class-browser#browser-new-context）。
```js
const context = await browser.newContext({
proxy: { server: "<代理IP地址和端口>", username, password }
});
```
如果只在浏览器启动时设置代理，多个 context 可能会共用同一个出口。测试仍可能运行成功，因此应在每个 context 中请求回显 IP，并与该用例的预期出口逐一比对。
为每个 context 设置代理并验证实际出口
context 创建后先请求回显 IP 的接口，比对“预期出口”和“实际出口”，断言通过再跑业务用例。断言放在业务之前，能更早暴露问题，但不能仅凭它定责：回显不符时先标“路径或分配待查”，再分段排查配置与运行环境。配置 context 代理时，可对照代理设置帮助核对协议与认证参数。
回显接口应使用自有或已获授权的稳定端点。固定出口时，将响应中的 IP 与分配值比较；动态出口则根据产品的分配规则验证本次结果，不能一概要求每次都返回同一个 IP。页面请求和 API 请求应分别记录用例、context、时间和回显结果，便于与代理侧的分配记录核对。日志中不要保存用户名或密码。
分别验证页面请求和 API 请求的代理出口
页面请求通过 page 发出，API 请求则可使用 context.request（Playwright 的 APIRequestContext）。分别检查两类请求的实际出口，避免只验证网页流量。配置时若不确定主机、端口或认证字段，可对照代理参数说明。
Playwright 代理配置常见问题及处理方法
如果所有 context 都显示同一个出口，先检查是否在 launch 层设置了全局代理。出现 407 或连接被拒时，核对用户名和密码是否传入。某个浏览器不接受该配置时，按所用 Playwright 版本的官方说明确认支持范围。复用 storageState 后出口断言不符合预期，则分别检查代理配置和会话状态。
将出口断言加入 fixture 并记录验证结果
把出口断言放进 fixture（测试用例共享的初始化逻辑），断言失败就让用例失败，而不是只记录日志。并发运行时，确保每个 context 与对应的预期出口一一匹配。
每条测试记录应包含 context 名称、预期和实际出口、断言结果，以及浏览器和 Playwright 版本。测试仅在自有或已获授权的环境中运行；若出口不符，先停止该用例，再检查代理配置层级。
配置选项以官方文档为准：
- Playwright 网络与代理配置
browser.newContext()的proxy选项说明
常见问题
为什么每个 context 配了 proxy 还是走同一个出口？
先检查浏览器启动参数和 context 配置，再核对代理侧的分配记录。如果多个 context 使用同一代理接入或共享同一会话，实际出口可能相同；Cookie 和 storage 隔离本身并不保证出口不同。
context.request 会走 context 的代理吗？
会，但容易被漏测，需要单独断言。