构建CPA代理转WebSocket加速GPT请求

背景

在通过 CPA 代理（疑似某个用于访问 OpenAI 服务的第三方代理项目，如 sub2api 之类）向 GPT 服务器发送请求时，用户频繁遇到 600 秒超时（即请求发出去后长时间无响应），以及 502、500、EOF 等错误。即使更换不同家宽 IP、美西节点等，也只能临时缓解，问题会反复出现。社区用户推测，问题大概率不在 Codex 逻辑或 OpenAI 全局服务侧，而在代理出口到 OpenAI 边缘之间的网络路径。

核心内容

作者分享了两套方案来缓解乃至规避上述问题。

方案一：临时性的 CPA Proxy

制作一个简单的 proxy，其核心逻辑是：在配置的等待时间内，如果后端没有返回 response headers，则直接 reset 连接，然后重新开启一个新连接到 CPA（sub2api），在重试时发送请求。这个方案能临时解决 600s 超时，但作者很快指出它“治标不治本”。

方案二：基于 Socks5 代理的转换方案

作者随后开发了一个更完善的 socks5 代理服务。使用方法：启动该服务后，将 socks5 地址填入 CPA 系统的配置中。之后，所有 CPA 发出的请求都会经过这个 proxy，proxy 会把所有的 HTTP 请求转换成 WebSocket（ws）方式发送出去；当收到返回时，再转回 HTTP SSE（Server-Sent Events）格式交给 CPA。

这个方案的核心收益是：让原本只支持 HTTP 模式的客户端（如 Claude Code 通过 CPA 调用）也能享受到 WebSocket 长连接带来的速度优势，从而高效地避免 600s、500、502、EOF 等问题。用户使用 Codex（应为 OpenAI Codex 或类似工具）时也不需要额外修改配置去手动指定走 ws 方式。

关键要点

• 非 WebSocket 模式频繁建立 HTTP/TLS 连接，代理节点在共享人数多、出口 IP 信誉差或单位时间连接数过高时，极易被 CDN/WAF/反滥用系统限流或 tarpitting（连接不断开但迟迟不返回 response headers）。这是 600s 超时的根源。
• WebSocket 保持长连接，显著降低新建连接频率，因此不容易触发同类阈值。
• 作者实测即使 20 人共享自己的家宽 IP 通过 CPA 使用，问题仍会重现，说明连接次数阈值极低。
• 方案二通过 socks5 proxy 统一封装，将任意 HTTP 请求转化为 WebSocket 再发送，使得所有走 CPA 的工具（如 Claude Code、Codex）都能自动获得 ws 加速效果，无需单独配置。

意义与影响

• 提供了一种可复用的、对客户端透明的 WebSocket 加速方案，降低了使用 CPA 代理访问 OpenAI 服务时的网络稳定性门槛。
• 揭示了 OpenAI 边缘网络对高频短连接 HTTP 请求的限流机制（tarpitting），并给出了切实可行的工程规避思路：通过代理层将短连接转化为长连接。
• 对于依赖 CPA 的多人共享场景（如小团队、开源项目），该方案能显著提升请求成功率，减少因网络问题造成的中断和等待。
• 方法简单（启动一个 socks5 proxy 并修改配置），且不依赖节点 IP 的更换，具有普适性。