小搓一个cpa proxy，把从cpa出来的请求全转成ws方式到gpt服务器，返回快很多

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

• 我的帖子已经打上 开源推广 标签： 是


• 我的开源项目完整开源，无未开源部分： 是


• 我的开源项目已链接认可 LINUX DO 社区： 是


• 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是


• 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

以下为项目介绍正文内容，AI 生成、润色内容已使用截图方式发出

就干一件事情，在配置时间内不返回 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 服务器没炸！！！！！！！！！！！！

-------------------------分割线-----------------------------------------

5.27 更新

上面的治标不治本，又写了一个sock5 代理的方式，启动服务把sock5地址填在cpa系统配置里面，然后所有的cpa请求都会走proxy，然后proxy会把所有的http请求转成ws发出去，返回的时候再转成http sse。

优点在哪？你用claude code接cpa也能享受codex ws的速度，从而高效的避免600s 500 502 eof等等问题。你用codex也不用改配置指定走ws方式，就这么简单