sub2api会话池管理，维持大量网页账号会话减少

首先明确，sub2api 会话池管理的目标不是把 Cookie 存起来就完事，而是让大量网页账号的登录态保持有效，在请求时按需切换，遇到失效 Cookie 能自动剔除并补充。
下面按准备、配置、保活、避坑和验证的顺序说明。

会话池和 Cookie 的关系

sub2api 这类中转工具通过保存网页版账号的 Cookie 或 Session Token 模拟用户请求。
多个账号组成一个池，每次调用随机或按策略取出一个可用会话。
Cookie 一旦过期，该账号就会被标记为失效，重登次数随之增加。
因此会话池管理的核心两个动作：持久化保存会话 和 周期性检测保活。

准备条件清单

开始操作前，确认下列项目：

• 一台可运行 Docker 或 Node.js 的服务器，网络稳定即可，不追求高配置。
• 已经部署好的 sub2api 实例；如果还没装，先按官方 README 完成基础部署。
• 需要纳入会话池的网页账号 Cookie，数量越多越建议分批添加。
• 多个代理出口 IP（可选但推荐），用于分散请求来源，降低风控风险。

多账号 Cookie 写入会话池

多数 sub2api 版本使用 SQLite 或 JSON 文件保存会话数据。
以常见的 data/accounts.json 为例，结构类似：

[
  {
    "name": "account_01",
    "token": "cookie_value_or_session_token",
    "remark": "主账号"
  }
]

写入后重启服务，或通过后台管理页面逐条添加。
如果项目提供 API，也可以通过 POST 请求批量导入，速度更快。

注意： 添加完成后立即检查日志，确认会话被正常识别。
不要一次性写入超过服务器内存能承载的账号量，建议每 100 个账号观察一次。

减少 Cookie 重登的保活策略

Cookie 有时效，完全避免更新不现实，但可以通过以下手段把重登频率降到最低：

1. 定时轻量请求保活：每 5-10 分钟发起一次低开销请求，模拟活跃用户。可在服务器上设置 crontab：

*/5 * * * * cd /opt/sub2api && python3 ping_sessions.py

ping_sessions.py 是你自己写的检测脚本，内容为遍历会话池并向 API 发起 /hello 之类的轻量请求。

1. 失效即移除：当返回 401 或 cookie invalid 时，自动将该会话标记为禁用，避免后续请求一直打到坏账号上。
2. IP 与账号绑定：给固定账号绑定固定出口 IP，避免同一 IP 频繁切换多个账号，减少风控触发概率。

常见报错和避坑说明

• 所有账号同时失效：先检查服务器时间是否准确，时间偏移会导致 Cookie 校验失败。
• 保存 Cookie 后仍然重登：确认是否使用了已过期的 Cookie，或验证时触发二次校验（如生物验证）。
• 高频请求导致账号受限：不要对单个账号设过高的并发，建议每个账号 1-2 并发。
• 代理混乱：使用代理时不要让账号 A 的请求从账号 B 的 IP 发出，尽量通过池配置绑定关系。
• 重启服务后会话消失：确认数据库或 JSON 文件路径是否持久化挂载，如果使用 Docker，记得把数据目录映射到宿主机。

验证会话池是否正常

验证两条路径：

• 查看 sub2api 日志，观察是否频繁出现 refresh token、session expired 等字样。如果一直干净，说明维持良好。
• 通过 API 连续发送 20-50 次测试请求，记录返回码和延迟。正常情况下请求成功且不会出现 invalid cookie。

如果 24 小时内重登次数明显减少，说明会话池管理生效。
后续记得定期检查 Cookie 有效期，在失效前手动更新或根据项目文档接入自动化刷新流程。

如果你正在处理 sub2api 会话池管理，建议先按本文步骤完整执行，再根据自己的环境做微调；
遇到异常时优先回看避坑和高频问题部分。