部署平台
Docker
版本号
1.2.5
客户端/工具
No response
请求接口
OpenAI - Chat Completions
问题/请求描述
🪓 Bug 反馈：多账号轮询偶尔提前重置
【问题现象】
配置了大约 40 个账号凭证。但在使用中发现，轮询切换账号时有时并不会完整跑完整个账号列表队列，而是会从中间的某个账号凭证（例如第 #31 个）异常、提前跳转回第一个凭证（#1）开始循环。
【证据排查】
- 正常预期： Account 1 ➔ ... ➔ Account 31 ➔ Account 32 ➔ ... ➔ Account 40 ➔ Account 1
- 实际异常路径： Account 1 ➔ ... ➔ Account 31 ➔ (异常跳跃) ➔ Account 1 ➔ Account 2
- 附图证明：
在运行日志快照中，可以明显观察到请求在编号 #31 成功返回并中止后，下一个请求直接切到了 #1 s 进而到 #2 j，此时还有 9 个账号（#32~#40）未被合理轮询：
注：因该现象为随机发生，当人工注意到时，由于并发请求高，底层详细 Debug 日志往往已被后续日志冲掉，未能捕捉到精确的堆栈。推测可能与并发锁、指针计数器在多路复用时未做并发安全保护有关。
💡 功能请求 1：凭证导入后快速/强制激活机制
【现状痛点】
目前上传/更新部分凭证时，程序并不会立刻对其进行检测激活，往往需要等待较长的时间（或者当首个凭证不是 0 或 1 时，甚至直接不激活）。
【建议方案】
可以加快激活速度。
💡 功能请求 2：新增 AUTH_DELETE_CODE 环境变量（自动清理风控被封账号）
【现状痛点】
由于部分用于桥接的 Gmail 账号极易遭遇官方风控，遭遇风控后 API 会直接返回 401\403等。废弃凭证若继续留在队列中，会大幅降低响应成功率。
【建议方案】
引入一个全新环境变量配合自动剔除逻辑：
- 环境变量：
AUTH_DELETE_CODE=401,403 （支持配置逗号分隔的 HTTP 状态码）
- 逻辑：当请求上游遭遇检测到自定义匹配的403 错误码时，系统自动执行实时清除，将该凭证从 active pool 中物理删除（或将标记为过期的凭证执行硬删除）。
之前在本地使用 1.3.0 源码让 AI 临时手搓了此功能
部署平台
Docker
版本号
1.2.5
客户端/工具
No response
请求接口
OpenAI - Chat Completions
问题/请求描述
🪓 Bug 反馈：多账号轮询偶尔提前重置
【问题现象】
配置了大约 40 个账号凭证。但在使用中发现，轮询切换账号时有时并不会完整跑完整个账号列表队列，而是会从中间的某个账号凭证（例如第 #31 个）异常、提前跳转回第一个凭证（#1）开始循环。
【证据排查】
在运行日志快照中，可以明显观察到请求在编号
#31成功返回并中止后，下一个请求直接切到了#1 s进而到#2 j，此时还有 9 个账号（#32~#40）未被合理轮询：💡 功能请求 1：凭证导入后快速/强制激活机制
【现状痛点】
目前上传/更新部分凭证时，程序并不会立刻对其进行检测激活，往往需要等待较长的时间（或者当首个凭证不是 0 或 1 时，甚至直接不激活）。
【建议方案】
可以加快激活速度。
💡 功能请求 2：新增
AUTH_DELETE_CODE环境变量（自动清理风控被封账号）【现状痛点】
由于部分用于桥接的 Gmail 账号极易遭遇官方风控，遭遇风控后 API 会直接返回 401\403等。废弃凭证若继续留在队列中，会大幅降低响应成功率。
【建议方案】
引入一个全新环境变量配合自动剔除逻辑：
AUTH_DELETE_CODE=401,403（支持配置逗号分隔的 HTTP 状态码）之前在本地使用 1.3.0 源码让 AI 临时手搓了此功能