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

症状：握手失败、说完半句就断、延迟像「对讲机」

你在本地或服务器里接入 OpenAI Realtime API，或直接使用 2026 年 5 月前后发布的 GPT-Realtime-2 一类语音实时模型时，最常见的故障并不是整网断开，而是三种让人抓狂的半通：WebSocket 握手阶段就返回 403／502／连接超时；会话已建立、流式音频播了几秒后突然静音，客户端日志里出现 1006、1011 或反复重连；以及端到端延迟稳定在数百毫秒以上，听感像老式对讲机。很多人会先怀疑 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；
• 同一会话可能持续数分钟，中间不能无故换代理节点；
• 应用侧对往返延迟（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，不要先换十个节点盲试。

节点地区与延迟：怎么选才适合语音 API

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

• 优先美西／美东低延迟专线：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，手动固定一条美西／美东低延迟节点，关闭对该组的 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 侧过载，但若仅在代理开启时出现，仍应查长连接超时与规则误判直连。
延迟高但不断连：换更近的北美节点、避免晚高峰公网中继，并确认本机未同时跑大流量下载占用同一策略组。

常见问题（速览）

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 会话开始，把分流与节点实测做扎实。