粘性会话还是轮换 IP？多步骤任务的代理验收方法

如果一个任务需要连续发出多次请求，并保持同一网络出口，就按任务保持粘性代理会话；请求相互独立时，再考虑在任务之间轮换。应用的 Cookie 和其他必要状态要单独维护。IP 没变，不能补回丢失的登录 Cookie；保留 Cookie，也不能替代理服务决定使用哪个出口。

对于正在接入多步骤业务的开发者，购买前真正要确认的是：一整项经过授权的任务，能否在所需条件下完成。下面的七项验收表、状态排查示例和时间预算，可以帮助你把这个问题说清楚。本文提供评估方法，不代表已经完成 IPHTML 性能实测。

先划定任务边界，再决定什么时候轮换

假设你在自有测试站点上依次打开目录、选择地区、读取允许访问的报表。后一步需要前一步的结果，这三步就应作为一个任务管理。先列出从开始到完成必须保留的状态，再把有上限的等待与重试时间算进去。

任务特点	初步选择	验收重点
相互独立、不共享应用状态的公开页面请求	服务商管理轮换，可能让客户端更简单。	目标允许访问，每次响应有用，地区条件符合任务要求。
应用明确要求出口一致的多步骤任务	每个任务绑定代理会话标识，并维护自己的 Cookie 或浏览器上下文。	整个任务中，出口和应用状态都满足连续性要求。
只依赖 Cookie 的多步骤任务	先保留应用上下文，再测试是否确实需要固定出口。	不能仅因有登录步骤，就推断必须保持同一 IP。
需要长期加入白名单的地址，或持续时间超过临时会话	评估明确分配地址的静态／独享方案，或获准使用的 API。	地址分配、共享、更换和可用性条款；“粘性”二字不能代替这些约定。

目标已经拒绝访问时，轮换不等于获得继续重试的许可。遵守目标的访问规则和速率限制；如果官方 API 已能提供所需数据与状态约定，也应纳入比较。

别把四种“会话”当成同一个东西

代理会话标识：交给服务商的出口选择指令，含义取决于具体产品。例如，Oxylabs 文档介绍了它自己的会话控制参数，那不是 IPHTML 的配置方法。
出口 IP：目标收到某次请求时实际看到的地址。会话标识是控制输入，实际观察到的地址才是结果证据。
传输连接：客户端使用的 TCP 连接或隧道。重新连接与重新选择出口是两件事，两者怎样关联要看代理实现。
应用上下文：Cookie、必要的浏览器存储、令牌，以及服务端保存的业务状态。它们属于应用流程。

Requests 文档说明 Session 可以保留 Cookie 并复用连接，这不等于配置了代理服务商的出口分配。Playwright 的浏览器上下文隔离 Cookie 和存储，适合分离测试任务，但不承诺各任务拥有不同公网 IP。不能拿其中一层的修复代替另一层的配置。

MDN 对 HTTP Cookie 的说明解释了应用如何记住状态。目标服务还可能检查有效期、账号或网络条件，应以实际应用约定为准，不能认定所有登录都绑定 IP。

用一份排查记录，判断状态到底丢在哪一层

下面是为受控测试应用编写的假设示例：该应用的测试规则要求一个任务内保持 Cookie 上下文和出口一致。A、B 只是标签，不是实际地址或凭据。每个对照都从相同、已知的初始状态重新开始，不是在同一个任务上连续修改多个条件。

情境       代理会话标识   Cookie 上下文   出口   应用结果
基准       job-A          jar-A           A      报表就绪
重新连接   job-A          jar-A           A      报表就绪
新上下文   job-A          空              A      要求重新登录
新出口     job-B          jar-A           B      要求重启任务

以上是说明性示例，不是服务商实测结果。

“新上下文”一行即使 IP 没变，也会因为应用状态缺失而要求登录。“重新连接”一行描述只改变传输连接时希望得到的行为。“新出口”的结果来自这个测试应用预先声明的规则，不适用于所有网站。换一个代理会话标识也可能再次分到同一出口；没有观察到地址变化，就不能声称已经测过换 IP 的影响。

在自有服务上，可用不含秘密的任务编号关联目标端请求日志，核对实际出口与业务结果。如果无法查看目标日志，要注明观测限制。向另一个 IP 查询网站发送请求，不能证明原目标请求使用了相同出口。共享排查材料时，不要放入密码、Cookie 值或认证请求头。

用七项测试验收会话行为

下载中文代理会话验收 CSV。表格的实际观察项全部留空，初始状态为 NOT_RUN。先填写目标应用预期、套餐文档中的行为、样本数、地区、客户端版本和负载，再执行测试。七个情境不代表七次测试已经成功。

情境	控制与改变	需要回答的问题
S1：基准任务	一个完整任务内保留会话标识和应用上下文。	在确实需要的出口与状态条件下，能否交付有用结果？
S2：重新连接	保留上下文和标识，只重新建立传输连接。	是否符合服务商的重连规则和应用约定？
S3：新上下文	使用干净的应用上下文，尝试保持出口不变。	是否符合新状态预期？若出口也变了，本次对照应记为无法判定。
S4：新标识	保留受控的基准应用状态，改用另一个代理会话标识。	先观察出口；只有确实变化，才能评估换 IP 对任务的影响。
S5：会话到期	在无副作用的测试任务中跨过文档规定的会话边界。	任务能完成，还是应按事先约定安全重启？
S6：并发任务	不同任务分别使用自己的标识和独立应用上下文。	是否存在意外状态串用？不同标识不必然对应不同出口。
S7：中途断连	只在自己的测试环境中注入可控连接故障。	是否在预算内停止重试，避免把未完成任务算成成功或重复执行？

执行后可记录 PASS（通过）、FAIL（失败）、INCONCLUSIVE（无法判定）或 NOT_APPLICABLE（不适用），同时填写证据与原因。S3 中符合预期的重新登录提示，不应算成代理故障。不要用真实支付等不可逆动作做重试测试；有实际副作用时，应遵循应用自身的幂等和对账规则，代理会话标识不能防止重复交易。

在计划使用的地区和并发量下重复相关测试，报告实际次数及失败次数，而不是预设一个所有业务通用的合格率。后续持续使用可配合任务交付稳定性记分表；少量验收测试不能证明长期在线率。

会话时间要覆盖等待和重试

假设任务调度器设定：步骤 A 最多 20 秒、B 最多 40 秒、C 最多 30 秒，等待及重试合计最多 45 秒，再留 15 秒调度余量，共计 150 秒。这些数字是人为设置并由程序执行的上限，不是实测平均值或百分位数。

任务总耗时预算 = 20 + 40 + 30 + 45 + 15 = 150 秒
从第一个使用代理的步骤开始前计时
无法在预算内完成时，停止或按约定安全重启
另行核对会话到期、空闲超时和出口失效的处理方式

要向服务商确认会话从何时计时、持续请求是否延长有效期、出口不可用后如何处理。若任务开始前会话已经存在一段时间，这段时间也要计入。标称会话时长超过 150 秒只是条件之一，不能证明期间一定不中断。也不要把各步骤的 p95 直接相加，称为整个任务的 p95。

把测试结果变成可以讨论的采购需求

评估 IPHTML 轮换代理方案前，整理已获授权的目标域名和步骤、所需地区、最长任务预算、预期并发、必须保留的应用状态，以及安全重启规则。针对具体套餐确认当前配置和会话行为，说明自己需要的是临时保持出口，还是单独分配地址。不要把其他服务商的参数直接拼进凭据。

准备好一个有代表性的任务后，可携带需求和脱敏验收表联系 IPHTML。必要情境达到事先约定的标准、商业条款适合负载后，再扩大使用。即使每次请求都返回 HTTP 200，只要状态变化仍然解释不清，就应先排查，而不是把请求成功当成任务交付成功。