起点
真正有用的问题是：一个工作流需要同一个出口维持多久，以及当这种连续性消失时你的应用应当怎么做。
阅读服务商对会话的定义
轮换和粘性描述的是出口选择策略。轮换通常在请求、连接或时间窗口之间更换分配的出口。粘性则是在定义好的会话期间请求绑定到同一个出口。触发条件、持续时长和故障切换行为取决于服务商；并不存在适用于所有服务的通用用户名参数。
例如，Decodo 的文档说明了按请求进行的移动出口轮换以及可配置的粘性会话，同时警告出口可能在请求的时长结束之前消失。把任何服务商的会话时长当作需要测试的对象，而不是应用恢复路径的替代品。
让会话与完整工作流对齐
设想在你自己的预发布商店上做一次结账测试：加载商品、加入购物车并核对配送预估。一个实用的起点是：整个场景使用一个浏览器上下文和一个代理会话。在断言完成之前保持两者不变，然后销毁该场景的状态。
对于相互独立的区域可用性检查，每次检查可以作为独立的单元。为每个结果记录预期区域、可获取时的实际观测出口以及时间戳。不要假设新选中的出口是唯一的，也不要假设更换出口能带来更高的请求配额。
区分三种状态
当以下内容作为相互独立、非机密的标识分别记录时，排障会清晰得多。代理会话无法恢复丢失的 Cookie 存储，而持久化的 Cookie 存储也无法迫使一个不可用的出口重新出现。
- 应用会话：由目标站点持有的 Cookie、令牌和状态。
- 客户端连接：一条 TCP 连接或可复用的连接池。
- 代理会话：服务商从会话标识到出口的映射。
在提高并发之前先测试过期
选择一个获准的诊断端点，在请求的会话窗口内顺序发送几个请求。记录观测到的出口。在文档标明的过期时间之后重复一次，并单独测试一次强制重连。把这些标记为来自你的样本的测量结果，而不是对整个池的保证。
决定出口提前变更对你的工作流意味着什么：重新开始一个只读场景、停止并报告失败，或从检查点恢复。不要自动重放可能已经创建了订单或改变了账户状态的操作。在运行大量工作进程之前，把恢复决策写进任务规范。
上线前检查
- 在选择会话时长之前先定义一个完整的工作流。
- 让 Cookie 状态与代理绑定保持独立。
- 用小样本测试出口提前丢失和过期的情况。
参考来源与延伸阅读
本指南参考的技术资料。请以你所安装版本的文档以及代理服务商支持的配置为准。