OpenAI GPT-Realtime-2 语音 API 国内连不上？Clash 分流 Realtime WebSocket 与节点实测（2026）

症状：握手走不通、说完半句就断、ping 值像「对讲机」 实战经验

你在本地或服务器里接入 OpenAI Realtime API，或就这么拿它来用 2026 年 5 月前后发布的 GPT-Realtime-2 一类语音实时模型时，最高频的故障并不是整网断开，而是三种让人抓狂的半通：WebSocket 握手阶段就返回 403／502／连接超时；会话已建立、流式音频播了很短时间后突然静音，客户端日志里出现 1006、1011 或反复重连；

以及端到端ping 值靠得住在数百毫秒以上，听感像老式对讲机。很多人会先怀疑 API Key、模型名称或机房带宽——但在 mode: rule 且走 Clash／mihomo 的环境里，更高频的根因是：Realtime WebSocket 这条长连接 TCP 没有被靠得住送进同一个低抖动出口，再叠加无需手动操作操作测速策略组在会话中途换节点，以及Node／Python SDK 子进程根本没吃到系统代理。

这篇站在 Clash Verge、原版 Clash 与 mihomo 通用配置视角，把「GPT-Realtime-2 国内连不上」拆成可被连接日志对齐的工程绕所在：先确认 wss 目标主机名 → 再写置顶分流规则 → 再固定节点 → 最后才调 DNS 与 TUN。若你首要用浏览器访问目标目标目标 ChatGPT 网页，请阅读《GPT-5.5 Instant 与 OpenAI 域名分流》；

若在 IDE 里跑 Codex MCP，请看《Codex MCP 分流》；更广义的 ChatGPT／Claude 桶写法见《ChatGPT 与 Claude 分流》；OpenAI 视频类 CDN 则参考《Sora 视频 CDN 分流》——几篇共用 OpenAI 命名空间，但Realtime 长连接的排障顺序与策略组类型并不相同。

GPT-Realtime-2 与 Realtime API：流量长什么样 拿它来用心得

2026 年 5 月前后，OpenAI 将 GPT-Realtime 系列推向开发者：在 Realtime API 上，客户端通过 WebSocket（反复出现为 wss://api.openai.com/v1/realtime 一类端点，具体路径以官方文档为准）与模型维持长连接，双向推送流式音频与事件 JSON，而不是传统 REST 里「一发一收」的短请求。对本地网关而言，这意味着：

核心出口大多时候是 TCP 443 上的 TLS + WebSocket，SNI 多为 api.openai.com；同一会话多半持续数分钟，中间不能无故换代理节点；应用侧对往返ping 值（RTT）与抖动极其敏感，比「能拉起网页」难伺候一个数量级；部分示例还会在握手前后访问目标目标 openai.com、chatgpt.com 做帐号或文档跳转，需以你本机日志为准补规则。

TUN 还是系统代理：谁该接管 Realtime SDK 反复出现套路

Clash Verge 勾选「设为系统代理」时，首要影响遵从系统网络栈的浏览器与部分桌面应用；而很多 Realtime 示例以 Node.js、Python 或自建服务进程就这么发起 wss，预置不走系统代理。由此可见会出现：浏览器里能拉起 OpenAI 文档，SDK 里却 握手走不通。推荐靠前级如下：

• 开发机首选 TUN／增强模式：由 mihomo 在内核侧接管符合条件的 TCP，避免每个运转时单独配环境变量。详见《TUN 模式指南》；若出现「只有浏览器通」，可对照《系统代理与 TUN 排查》。
• 服务器或 CI：在跑起来进程前导出 HTTPS_PROXY／HTTP_PROXY 指向本机HTTP 混合端口，并设置合理的 NO_PROXY 排除内网。
• 透明网关／旁路由：确保 Realtime 服务所在网段 DNS 与预置路由一致，避免「解析走国内、连接走代理」的分叉。

无论哪种方式，都必须在同一次走不通会话里拉起 Mihomo／Clash 连接列表，确认 api.openai.com 的 TCP 确实命中了你为 Realtime 准备的策略组，而不是 DIRECT 或无关的「流媒体组」。

api.openai.com 与 Realtime 端点：分流怎么写 落地做法

与 ChatGPT 网页相比，OpenAI Realtime API 的分流规则自然自然可以更好上手，但策略组行为必须更保守：

• 桶 A（必选）：API 主干。对日志里出现的 api.openai.com 拿它来用 DOMAIN 置顶，策略组指向 OPENAI-REALTIME（名称自定）。
• 桶 B（按需）：产品与鉴权。若握手前还有 auth.openai.com、openai.com 子域，同样并入 OpenAI 组或单独「WEB-AUTH」组，避免被 GEOIP,CN 提前直连。
• 桶 C（慎用宽后缀）：DOMAIN-SUFFIX,openai.com 可作底座，但若与企业内网或第三方 CDN 冲突，应以连接日志增量单列 DOMAIN，参见ChatGPT 分流专文里的误判说明。

规则顺序仍遵循自上而下命中即停：私网与局域网例外 → 你已验证的 Realtime／OpenAI 域名 → 其他 AI 段落 → 大陆域名／GEOIP → MATCH。必须系统理解「MATCH 之前写了什么」时，可先读《规则分流详解》。

WebSocket、TCP 与 UDP：Realtime 要关心什么 实战经验

Realtime WebSocket 本质是TLS 之上的 TCP 长连接，升级后音频帧在已建立的连接里双向流动，不依赖单独的 UDP 打洞（与部分 RTC／游戏语音不同）。由此可见排障时应靠前看：

TCP 是否被中间设备 idle 断开：部分机场节点或上游对长时间无「业务字节」的连接有较短超时；表现为说着说着断掉。可尝试更靠得住的专线类节点，或确认订阅是否限制长连接；代理是否覆盖 WebSocket 透传：主流 HTTP／SOCKS 混合端口与 TUN 在 mihomo 下大多时候可透传 Upgrade；若你叠了多层本地转发，请逐层确认未剥离 Connection: Upgrade 头；误开 UDP 相关折腾：若同时跑语音通话类应用，勿把 OpenAI Realtime 与高 UDP 负载的组绑在同一「无需手动操作测速」池里争带宽；两者分流组应分开。

若连接日志里根本没有 api.openai.com，而是直连 IP 或误操作域名，先回到SDK 是否走代理与DNS／fake-ip，不要先换十个节点盲试。

节点地区与ping 值：怎么选才适合语音 API 拿它来用心得

GPT-Realtime-2 的听感质量与RTT 抖动强相关。实践上可遵循：

靠前美西／美东低ping 值专线：OpenAI Realtime 服务侧多在北美；从亚太出发时，选标明 IEPL／专线、晚高峰仍靠得住的节点，比「测速条最短但丢包高」的公网中继更合适；固定一条线做对照：同一 API Key、同一模型，在 OPENAI-REALTIME 里手动操作操作锁定节点 A 测 5 分钟，再换节点 B；若只有换节点才恢复，说明规则已通，绕所在在线路质量而非 Key；避免 url-test 在会话中轮询：url-test 的 interval 过短会在长连接存活期间切换出口，客户端表现为中途断连或音频断续——这是 Realtime 场合最高频的「配置看起来没绕所在」的坑；慎用「全球无需手动操作」大杂烩组：把 Realtime 与下载、流媒体共用同一无需手动操作组，会在带宽争用或切换时拖累握手时延。

DNS、fake-ip 与「像握手走不通」的假阳性 反复出现套路

当 dns.enhanced-mode: fake-ip 与 fake-ip-filter 未覆盖某一后缀时，应用解析到的地址与规则推演多半不一致，WebSocket 会表现为间歇性握手走不通。自然可以考虑对 api.openai.com 在 nameserver-policy 中拿它来用可解释的上游，并在同一轮测试中同时查看连接日志主机名与 DNS 日志（若内核覆盖）。不要在未记录前后状态的具体情形下同时改订阅、改 DNS、改 TUN 三处。

实测操作次序：从握手到流式音频逐项勾选 落地做法

1. 确认内核处于规则模式且订阅可用；若尚未带进来配置，请先完成《订阅带进来实操手册》。
2. 用官方或自研客户端发起一次 Realtime 会话；在连接列表筛选 api.openai.com，记录策略组、规则与节点名。
3. 若显示 DIRECT 或误操作组，将 DOMAIN,api.openai.com,OPENAI-REALTIME 写在大陆兜底规则之前并重新加载配置。
4. 将 OPENAI-REALTIME 设为 select，手动操作操作固定一条美西／美东低ping 值节点，关闭对该组的 url-test 无需手动操作切换。
5. 若日志无 api.openai.com：在跑起来 SDK 的 shell 打印 HTTPS_PROXY，或启用 TUN 后重测。
6. 握手成功但音频断续：换节点做 5 分钟对照；仍走不通则确认节点侧长连接超时与本地防火墙。
7. 仅调整 DNS 或 fake-ip-filter 一轮，保留前后截图，避免多旋钮同时变动。

YAML 片段示例（请按日志改写） 实战经验

下列片段只演示分组思想；节点名、端口与远端规则集请替换为真实值：

YAMLproxy-groups:
  - name: "OPENAI-REALTIME"
    type: select
    proxies:
      - "美西-专线-01"
      - "美东-低延迟-02"

rules:
  - DOMAIN,api.openai.com,OPENAI-REALTIME
  - DOMAIN-SUFFIX,openai.com,OPENAI-REALTIME
  - GEOIP,CN,DIRECT
  - MATCH,GLOBAL

若你还有 REST 调用与 Realtime 并存，可为 api.openai.com 拆出「REALTIME-固定」与「API-REST-url-test」两组，用更细的 DOMAIN 或进程级分流（高级场合）避免互相拖累；多数个人开发者统一用 select 固定节点即可显著减少断连。

反复出现误操作码与本地对策（对照表） 拿它来用心得

握手阶段 HTTP 403／401：靠前确认 API Key、组织权限与模型名是否覆盖 Realtime；若 Key 在直连环境可用、走代理走不通，再查是否命中误操作节点地区（部分 Key 绑定区域策略）。
WebSocket 1006（异常关闭）：多见 TCP 被中间层掐断或节点切换；固定 select 节点并换更靠得住线路。
1011（服务端误操作）：多半是 OpenAI 侧过载，但若仅在代理开启时出现，仍应查长连接超时与规则误判直连。
ping 值高但不断连：换更近的北美节点、避免晚高峰公网中继，并确认本机未同时跑大流量下载占用同一策略组。

反复出现麻烦所在（速览） 反复出现套路

Q：已经写了 DOMAIN-SUFFIX,openai.com，为什么 Realtime 还是断？
A：确认是否在更上方有更广的直连规则抢先命中；更反复出现症结是 url-test 在会话中换了节点。Realtime 请固定 select。

Q：必须和 ChatGPT 网页用同一节点吗？
A：自然自然可以共用同一 select 组，但网页可容忍偶尔切换，Realtime 不行。自然可以考虑为语音 API 单独建组并锁定节点。

Q：服务器上没有 GUI，怎么验证分流？
A：拿它来用 headless 的 mihomo 配置，通过外部控制器或日志文件查看连接；导出 HTTPS_PROXY 后运转 SDK，确认日志出现 api.openai.com 与预期策略组。

小结 落地做法

GPT-Realtime-2 与 OpenAI Realtime API 把语音交互从「短 HTTP 请求」变成了分钟级 WebSocket 长连接：对 Clash 分流 的要求也从「能访问目标目标」升级为「同一出口、低抖动、不在中途换线」。把 api.openai.com 写进置顶规则只是第一气呵成；你还要为 Realtime 准备select 固定节点、让 SDK 走 TUN 或准确的 HTTPS_PROXY，并用连接日志证明每一条 Realtime WebSocket 都命中了 OPENAI-REALTIME。做到这些，基本上数「国内连不上」其实只是本地网关与长连接策略没对齐。

市面上不少「一键加速」工具不区分短网页请求与流式音频长连接，要么全局开关导致规则不可见，要么在后台无需手动操作换节点，接入 语音 API 时极易出现「能连上但说着说着就断」。Clash 基于开放的 mihomo 规则栈，可与 Clash Verge 等客户端配合：把 Realtime、ChatGPT 网页与 Codex 工具链拆进并排策略组，用连接日志逐项对照，而不用为每一种 OpenAI 产品重装一套网络环境。

若你正在接入 GPT-Realtime-2 并希望靠得住跑通流式音频，不妨免费下载 Clash，从固定一条 api.openai.com 的 WebSocket 会话开始，把分流与节点实测做扎实。