- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
以下为项目介绍正文内容，AI 生成、润色内容已使用截图方式发出
github.com
GitHub - mucsbr/codex-reset-proxy
通过在 GitHub 上创建帐户来为 mucsbr/codex-reset-proxy 开发做出贡献。
就干一件事情，在配置时间内不返回 header 直接 reset 连接，然后再开启新连接到 cpa（sub2api）在重试发送。
效果就是能临时帮你解决 600s 的问题，因为今天这个情况特别严重，把我整抑郁了。
补充：
家宽、美西、各种节点治标不治本，用一会一样会出现，只不过临时切节点会短时间降低 600s 问题（502 500 eof 等问题）。
还有
codex 开 ws，cpa 认证文件里面开启 ws
codex 登录直连
开 WS 和直连能规避，说明问题大概率不在 Codex 逻辑和 OpenAI 全局服务，而在代理出口到 OpenAI 边缘之间。非 WS 模式可能更频繁建立 HTTP/TLS 连接，代理节点如果共享人数太多、出口 IP reputation 差、单位时间连接数过高，就可能被 CDN/WAF/ 反滥用系统限流或 tarpitting。表现为连接不断开但迟迟不返回 response headers。WS 因为保持长连接，显著降低新建连接频率，所以不容易触发同类阈值。
但是我的家宽用一会也一样这样（20 个人一起用 cpa），这个连接次数阈值也太低了吧。
以上推断前提：gpt 服务器没炸！！！！！！！！！！！！
1 个帖子 - 1 位参与者
来源: LinuxDo 最新话题查看原文