為什麼2026年GPT-Realtime-2接入時，WebSocket比 REST 更容易「看起來連不上」？

2026 年 5 月 OpenAI 正式推出 GPT-Realtime 系列，其中 GPT-Realtime-2 面向低延遲語音對話、即時轉寫與雙向串流音訊場景。與傳統 Chat Completions 的「發請求、等回應」不同，OpenAI Realtime API 透過 wss://api.openai.com/v1/realtime 建立長連線 WebSocket，在單一會話中持續推送 PCM 音訊片段、接收模型語音回覆，並以 JSON 事件協調 turn-taking。對已用 Clash、mihomo 或 Clash Verge Rev 維持開發環境出海的工程師而言，REST 測試可能順利返回 200，但 Realtime 客戶端卻在握手階段報 connection refused、403、或連上後 10～30 秒即斷線——這類現象在代理環境裡極為常見，且根因往往不在 API Key，而在出站路徑分裂與長連線對節點抖動的敏感性。

實務上，OpenAI Realtime API 的流量特徵與一般 HTTPS 瀏覽有明顯差異：一是 HTTP Upgrade 必須在同一 TCP 連線上完成，中間若被錯誤規則截走或 DNS 解析不一致，Upgrade 會直接失敗；二是連線建立後需維持數十秒至數分鐘的雙向串流，若 url-test 在會話中途換出口，WebSocket 會無預警關閉；三是 SDK（Node、Python、Swift 等）的 Proxy 繼承行為與瀏覽器、curl 並不一致，容易出現「curl 通、SDK 不通」的分裂表象。本文把焦點收斂在Clash 分流如何讓 Realtime WebSocket 穩定走預期出口，並與站內既有 OpenAI 專文形成互補。

站內分工如下：ChatGPT／Claude 分流專文適合建立 AI 獨立策略群組的心智模型；GPT-5.5 Instant 網頁版分流聚焦對話前端與一般 API；Codex MCP 外掛分流則對應 IDE 工具鏈。本篇專注語音即時 API 的 WebSocket 長連、api.openai.com 置前規則、TUN／系統代理選型，以及節點地區與 TCP 穩定性實測。

症狀分桶：握手失敗、中途斷連，還是延遲飄高？

開始改 YAML 前，建議把現象分三桶，避免把「節點品質問題」誤判成「規則寫錯」或反之。

• 握手階段失敗：客戶端在 wss://api.openai.com/v1/realtime 連線時即報錯，常見訊息包含 WebSocket connection failed、HTTP 403／502、或 TLS handshake timeout。這類問題多半與請求未進核心、規則誤命中直連、或DNS 解析到錯誤 IP有關，而非 Realtime 模型本身。
• 連上後中途斷線：WebSocket 已 Upgrade 成功，串流音訊 10～60 秒後突然 close，或收到 session.expired 以外的不明斷連。高頻根因是url-test 在長連期間換節點、出口對 TCP 長連支援差、或防火牆／NAT 逾時。Realtime 對「同一 TCP 連線維持不變」的要求比 REST 嚴格得多。
• 延遲飄高、語音卡頓：連線未斷但 round-trip 時間（RTT）從百毫秒飄到數秒，語音播放出現明顯 lag。這常與節點地區選錯、與 REST 走不同出口、或訂閱線路在高峰拥塞有關。固定節點做 AB 對照通常能快速分辨。

除錯起點永遠是複製連線紀錄裡的確切主機名與命中規則。社群文章常一次貼上整份「OpenAI 全域名表」，但未經您環境的合成規則校準，容易造成規則行數爆增仍命中錯組。對 mihomo 而言，能穩定觀察的出站與規則名稱標籤，比口頭形容「我用了代理」更關鍵。

Realtime API 與 REST 的差異：為什麼分流邏輯不能照搬？

OpenAI Realtime API 的核心端點是 wss://api.openai.com/v1/realtime（部分 SDK 或區域可能略有別名，以官方文件與您日誌為準）。連線流程大致為：客戶端發起 HTTPS 請求並帶 Upgrade: websocket 標頭 → 伺服器回 101 Switching Protocols → 後續在同一 TCP 連線上傳送 JSON 事件與 base64 編碼的音訊 chunk。這意味著：

• 單一主機、單一長連：不像 REST 每次請求可分散到不同 CDN 邊緣，Realtime 會話綁定在與 api.openai.com 的那條 TCP 連線上。規則必須確保該主機從握手到斷線全程走同一策略群組。
• 對節點切換極敏感：url-test 若在 300 秒 interval 內判定「更優節點」並切換，正在進行的 WebSocket 會直接中斷。Realtime 場景建議手選固定節點或拉大 tolerance，細節可延伸閱讀健康檢查與容忍值專文。
• SDK 出站可能與 curl 不同：Node 的 ws、Python 的 websockets 等函式庫未必自動讀取系統 Proxy；若只用 curl -v https://api.openai.com 驗證而忽略 SDK 行程，會誤以為「代理已生效」。

若您同時使用 Realtime 的會話建立 REST 端點（例如部分流程需先 POST 取得 session token），請確認這些短連線與 WebSocket 長連命中同一 REALTIME_OPENAI 群組，避免 token 在一條路徑取得、Upgrade 在另一條路徑失敗的 split-brain 現象。

常用主機輪廓（請以連線紀錄為準補漏）

下列分組是多數 GPT-Realtime-2 接入環境會反覆見到的代表性子域方向，不是官方白名單；新版本若引入額外 CDN 或統計子域，請以連線紀錄自動跟進：

• Realtime WebSocket 核心：api.openai.com 是 OpenAI Realtime API 的必經主機。規則應以 DOMAIN-SUFFIX,openai.com 或更精準的 DOMAIN,api.openai.com 置前，確保 wss 與 https 同源請求走同一出口。
• 身分驗證與帳號：部分整合流程可能涉及 auth.openai.com、chatgpt.com 或 OAuth 跳轉。若 Realtime 客戶端需先完成瀏覽器授權，請確認這類主機也在同一策略群組，避免「人已登入、WebSocket 仍 403」。
• 靜態與 CDN 延伸：控制台或 SDK 文件頁可能從 *.oaistatic.com、oaiusercontent.com 載入資源；雖非 Realtime 主路徑，但若安裝／除錯工具依賴這些主機，建議一併納入 OpenAI 群組，避免漏網。
• 與 Sora／影片類 API 的區隔：若您的產品同時接入影片生成，可對照Sora 與 OpenAI 影片 CDN 分流專文，但 Realtime 語音 API 的核心仍是 api.openai.com，不必把影片 CDN 規則與 WebSocket 混在同一兜底邏輯。

TUN 與系統代理：Realtime SDK 該選哪種出站？

GPT-Realtime-2 的客戶端常見三類：瀏覽器 WebRTC／WebSocket 示範頁、Node／Python 後端服務、以及行動或桌面原生 App。三者對 Proxy 的繼承差異很大：

• 瀏覽器：通常自動走系統 Proxy 或擴充功能設定；若 Clash 只開系統代理而未開 TUN，多數瀏覽器能正常 Upgrade WebSocket。但若您用無頭瀏覽器或Electron 內嵌頁，行為可能不同。
• Node／Python SDK：預設不讀取 macOS／Windows 系統 Proxy，需手動設定 HTTPS_PROXY／HTTP_PROXY，或依賴 TUN 模式讓 mihomo 在 IP 層接管所有 TCP。實務上，Realtime 後端服務強烈建議 TUN，比指望環境變數更穩。
• 原生 App：iOS／Android 需確認 App 是否尊重 VPN／系統 Proxy 設定；桌面 Electron 宿主請對照全域與瀏覽器分流辨析與TUN 模式指南。

若目前是「REST curl 通、SDK WebSocket 不通」，請先在 Clash 連線列表過濾 api.openai.com：若 SDK 發起連線時完全無紀錄，問題在出站覆蓋而非規則；若有紀錄但命中 DIRECT 或錯誤群組，則回到規則順序調整。

規則順序：為什麼 api.openai.com 寫了仍像沒設定？

在 mode: rule 下，mihomo 採由上到下、初次命中即止。訂閱提供方常預載「超大陸／海外」合集或覆蓋極廣的 RULE-SET；若合成的最終陣列中，您的 OpenAI 片段被排到後半段而更早的 GEOIP,CN,DIRECT 或海外自動代理規則已決策，面板裡就只會留下「我用了 PROXY」，但對 api.openai.com 的真相卻是另一条更早的規則先行截胡。

與國內外分流骨架並用時，請特別審視任何「對整段國外流量自動代理」的片段：OpenAI Realtime API 這種對抖動敏感的長連線，未必適合被 url-test 隨機打散的泛泛群組。這也是為何本文推薦把 api.openai.com 抽到可觀測的 REALTIME_OPENAI 獨立群組。

策略群組：建議單獨建立 REALTIME_OPENAI

Realtime WebSocket 與一般瀏覽器翻頁不一樣，排錯時您需要能快速回答：「請求是否真的進入了核心？」與「當它進入後，走的是哪個具名出站？」因此建議在 Clash Verge Rev 或文字設定中拆分一個 REALTIME_OPENAI select 組，內層可放 url-test 做日常優選，但Realtime 除錯期間請改用手選，並保留 DIRECT 作為對照列。

節點地區選擇上，OpenAI Realtime 服務通常以美西或官方文件建議區域為主。實務建議：從訂閱中挑 2～3 個延遲低、抖動小的美西／美東節點，固定其中一個做 Realtime 專用出口，避免與 Netflix、Steam 等流量共用會頻繁切換的 url-test 池。若固定節點後延遲立刻改善，再回頭調 tolerance 與 interval，而非盲目換訂閱。

YAML 骨架（請將節點名稱與順序對齊您實際訂閱）

下面片段示意如何在寬泛兜底前插入 GPT-Realtime-2／OpenAI Realtime API 相關主機。不要未審核即貼上到生產帳號，必要時對企業區域調整為直連／專線，並在日誌中補 DOMAIN 特例：

YAMLproxy-groups:
  - name: "REALTIME_OPENAI"
    type: select
    proxies:
      - "US-West-Stable"
      - "REALTIME_AUTO"
      - DIRECT
  - name: "REALTIME_AUTO"
    type: url-test
    proxies: []
    url: "https://www.gstatic.com/generate_204"
    interval: 600
    tolerance: 80

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  # Put BEFORE broad GEOIP / RULE-SET / MATCH catch-alls
  - DOMAIN,api.openai.com,REALTIME_OPENAI
  - DOMAIN-SUFFIX,openai.com,REALTIME_OPENAI
  - DOMAIN-SUFFIX,chatgpt.com,REALTIME_OPENAI
  - DOMAIN-SUFFIX,oaistatic.com,REALTIME_OPENAI
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

注意 REALTIME_AUTO 的 interval 設為 600 秒、tolerance 設為 80，目的是降低長連線期間換出口的機率。若您尚未準備好用戶端基底，可先依訂閱匯入教學把節點名稱寫進 proxies，再替換 proxies: []，避免合成規則引用不存在的群組。

WebSocket、TCP 與 UDP：Realtime 需要開 UDP 轉發嗎？

這是社群常見誤區：OpenAI Realtime API 的 WebSocket 走 TCP（TLS），不依賴 UDP。Realtime 語音串流在應用層以 JSON 事件 + base64 音訊 chunk 傳輸，底層仍是標準 TCP 長連。因此：

• 不必為 Realtime 專門開啟 Clash 的 UDP 轉發或 TUN 的 UDP 路由（除非您的訂閱對 TCP 長連本身支援差，而您誤以為是 UDP 問題）。
• 要確認節點對 TCP 長連線的穩定性：部分線路對短 HTTPS 請求正常，但對維持 60 秒以上的 TCP 連線會在中途 RST。這類問題用固定節點 + 長時間 WebSocket ping 即可驗證。
• 若您同時使用WebRTC 語音（非官方 Realtime API 路徑），才可能牽涉 UDP；但 GPT-Realtime-2 官方 SDK 的標準接入仍是 wss://api.openai.com，與 WebRTC 分流邏輯不同。Discord 語音等 UDP 場景可對照Discord 語音 UDP 分流專文，勿混用規則。

遇到「Upgrade 成功但數秒後 close」時，可檢查：① 節點是否在 interval 內被 url-test 替換；② 本機防火牆或公司 Proxy 是否對長連有 idle timeout；③ DNS 是否在 fake-ip 模式下對 api.openai.com 解析不一致。

DNS、enhanced-mode 與「規則正確仍斷線」

啟用 enhanced-mode: fake-ip 時，請同步理解名稱解析與規則比對的耦合。若 api.openai.com 被錯誤列入 fake-ip-filter 或漏列，可能出現「控制台顯示已命中 REALTIME_OPENAI、WebSocket 卻拿不到預期路由」的假象。建議依DNS 模式調整專文做單因子實驗，並暫時關閉瀏覽器「安全 DNS」對照。

Realtime WebSocket 對 DNS 抖動的容忍度低於 REST：若握手階段解析到不同 IP、或 redir-host 與 fake-ip 混用導致 SNI 與實際連線目標不一致，Upgrade 可能間歇性失敗。除錯時可暫時改 redir-host 或把 api.openai.com 加入 nameserver-policy 固定走可信 DNS，觀察握手成功率是否改善。

連線紀錄驗證：如何確認 Realtime 真的走對出口？

建議將「每次 Realtime 會話建立」與連線紀錄逐一對時間軸對齊：

1. 用官方 SDK 或最小範例建立 wss://api.openai.com/v1/realtime 連線，立即開啟 Clash Verge／核心日誌，過濾 api.openai.com，確認有紀錄且策略為 REALTIME_OPENAI。
2. 若日誌完全無紀錄，先在宿主環境用 SDK 同版本做一次連線，並對照是否需啟 TUN 或設定 HTTPS_PROXY；無紀錄則優先調整出站覆蓋，而非改規則。
3. 將 DOMAIN,api.openai.com 規則上移至任何會對海外流量提早終止的 GEOIP／RULE-SET 之前；重載配置後再觀察命中是否改變。
4. 把 REALTIME_OPENAI 暫改成手選單一美西節點，持續串流音訊 60 秒以上；若不再斷線，改調 url-test 的 interval 與 tolerance。
5. 若握手仍 403，複查 API Key 權限是否包含 Realtime scope，並確認 OAuth／session 相關子域與 api.openai.com 走同一具名出站。
6. 最後對照Codex MCP 分流與GPT-5.5 Instant專文，確認沒有把 Realtime 與網頁對話／IDE 工具鏈混在同一會頻繁切換的 url-test 池。

常見問題

REST API 能通，為什麼 Realtime WebSocket 仍失敗？

REST 是短連線，每次請求可獨立走代理；WebSocket 需在同一 TCP 上完成 Upgrade 並維持長連。若 curl https://api.openai.com/v1/models 走代理而 SDK 的 ws 連線直連，就會出現 REST 通、Realtime 不通。請用連線紀錄證明 SDK 請求是否進核心，而非只靠 curl 推論。

Realtime 需要 UDP 嗎？

不需要。OpenAI Realtime API 標準接入是 wss:// over TCP。若您遇到類似 UDP 的「斷斷續續」，更可能是 TCP 長連被節點切換或線路品質問題，請固定節點排查。

該選哪個地區的節點？

實務上以美西低延遲、抖動小的節點為優先；具體請用訂閱內建測速與 60 秒 WebSocket 長連測試做 AB，而非照搬論壇「某國一定最好」的說法。

結語

GPT-Realtime-2 與 OpenAI Realtime API 在 2026 年的接入體驗，本質上是「WebSocket 長連 + 串流音訊 + 同一出口穩定維持」三件事的疊加；若只靠泛用代理或零散論壇域名表，常常在下一輪改版或換訂閱模板後又得全盤重做。Clash 分流的強項在於可把 Realtime 流量寫進可複查的置前規則，並用連線紀錄把 api.openai.com 的出站對齊到專用的 REALTIME_OPENAI 群組，而不是賭運氣尚可的預設合併。

相較於僅強調「能連上國外」的泛泛工具，市面不少方案缺乏對 WebSocket 長連、節點切換與 SDK 出站的對照說明，開發者在接入語音 API時往往要在多個論壇貼間拼圖。Clash 官網 把 TUN 選型、置前規則、TCP 排錯與節點地區選擇整理為同一語言環境可直接照順序執行的演練，讓 Realtime WebSocket 工作流可以在「節點由您選、策略由我們對齊規則敘述」前提下完成收斂。若您需要先備妥用戶端與圖形面板，再打開本篇的規則骨架做微調，不妨先從 免費下載 Clash 官網 取用整理好的程式與資源，大多數環境都能在短時間內跑通基底並開始閱讀 Realtime 連線紀錄。