Cloudflare Realtime TURN TCP／UDP 怎麼查？從事故狀態到 WebRTC ICE Restart

2026-09-07 的 TURN 事件告訴我們什麼？#

Cloudflare Status 曾記錄一個 Performance degradation affecting TURN service 事件：頁面在 2026-09-07 13:02 UTC 建立，13:52 UTC 標示 resolved；第一則更新則寫明相關效能問題自 2026-08-22 起被觀察到。事件描述指出，有相當一部分流量被 relay 到 TCP，而不是預期的 UDP；Chrome／WebRTC 使用者可能遇到延遲或連線變慢。修復後，新連線的影響已結束，但事件更新也提醒既有連線會繼續使用 TCP，直到 client 結束連線或重新啟動。

換算成台灣時間，這次 Status 頁面的調查到 resolved 約在 21:02–21:52；它不是整段效能問題的起始與持續時間。這個時間點只屬於該次事件的紀錄，不代表日後所有 TCP 都是 Cloudflare 故障。若你現在才看到延遲，先查看 Cloudflare Status 是否有新的 incident，再依下列方法檢查實際路徑。

先分辨三個不同的「協定」#

TURN／WebRTC 的 protocol 很容易被混在一起。排錯時至少要分開看：

Cloudflare Realtime TURN 的主要 endpoint 包含 turn.cloudflare.com:3478 的 UDP 與 TCP，以及 TLS 的 5349；也提供 80／443 等 alternate port。Port 53 雖然出現在部分回傳的 iceServers 清單裡，但 Cloudflare 文件提醒許多瀏覽器和 ISP 會封鎖它，不應只依賴這個 alternate port。

其中最能回答「是不是透過 TURN 用 TCP 連出去」的是 local relay candidate 的 relayProtocol。如果選中的 local candidate 不是 relay，代表目前的連線沒有使用 TURN relay，這時應把問題轉到 direct／server-reflexive candidate、SFU 或對端網路，而不是繼續只看 TURN。

用 getStats() 找目前選中的 relay candidate#

標準做法是先從 transport stats 讀 selectedCandidatePairId，再透過 candidate pair 的 localCandidateId 找到 local candidate。不要只搜尋第一筆 candidate-pair，因為報告裡可能同時存在尚未選用、已失敗或舊的候選配對。

1
async function inspectSelectedIcePath(peerConnection) {
2
  const stats = await peerConnection.getStats();
3
  let selectedPair;
4

5
  for (const report of stats.values()) {
6
    if (report.type === 'transport' && report.selectedCandidatePairId) {
7
      selectedPair = stats.get(report.selectedCandidatePairId);
8
      break;
9
    }
10
  }
11

12
  if (!selectedPair) {
13
    return { state: 'no-selected-pair' };
14
  }
15

16
  const local = stats.get(selectedPair.localCandidateId);
17
  const remote = stats.get(selectedPair.remoteCandidateId);
18

19
  return {
20
    state: selectedPair.state,
21
    nominated: selectedPair.nominated,
22
    localCandidateType: local?.candidateType ?? null,
23
    localProtocol: local?.protocol ?? null,
24
    relayProtocol: local?.relayProtocol ?? null,
25
    localTurnUrl: local?.url ?? null,
26
    remoteCandidateType: remote?.candidateType ?? null,
27
    remoteProtocol: remote?.protocol ?? null,
28
  };
29
}
30

31
const path = await inspectSelectedIcePath(peerConnection);
32
console.table(path);

解讀時先看 localCandidateType：

• relay + relayProtocol: 'udp'：本機到 TURN 的 relay transport 是 UDP。
• relay + relayProtocol: 'tcp' 或 'tls'：本機到 TURN 的 relay transport 不是 UDP，需再對照 Status、網路政策與部署時提供的 URLs。
• 不是 relay：目前選中的 path 沒有透過 TURN；不要把它當成 TURN TCP 事故證據。
• relayProtocol 是 null：瀏覽器可能沒有暴露這個欄位，或 stats 尚未完整；把 state、candidate type、時間和瀏覽器版本一併記錄，不能用空值硬推論 UDP。

RTCIceCandidatePairStats 的標準選擇關係是 transport.selectedCandidatePairId；MDN 也提醒 Firefox 的 candidate-pair.selected 是非標準屬性，不應只依賴它。這個差異能避免在 Chrome 上因為查不到 selected: true 而誤判沒有可用連線。

事故已 resolved，為什麼畫面還是慢？#

如果 Status 已經 resolved，但原本建立的通話仍顯示 local relay 是 TCP，這和該次事件的更新內容一致：既有連線不會自動換成新路徑。依你的應用程式能力選擇：

1. 一般通話或短工作階段：讓使用者離開並重新加入，建立新的 ICE gathering。
2. 需要維持 session：透過 signaling 執行 ICE restart，讓雙方重新交換 offer／answer。
3. TURN credential 即將到期：先從後端取得新的短效 credential，再用 setConfiguration() 更新 peer connection，接著依 signaling 流程重新協商。

最小的 ICE restart 示意如下，實際仍需要把 offer 傳給對端並套用 answer：

1
const offer = await peerConnection.createOffer({ iceRestart: true });
2
await peerConnection.setLocalDescription(offer);
3

4
// 將 peerConnection.localDescription 送到你的 signaling server。
5
// 對端回傳 answer 後，再呼叫 setRemoteDescription(answer)。

Cloudflare Realtime FAQ 也建議 client 支援 ICE restart，因為 TURN allocation 可能在維護或網路拓撲變化時中斷。這是連線韌性的設計，不是只針對 2026-09-07 事件的臨時 workaround。

TURN URLs 與短效 credential 怎麼設計？#

TURN key 是長期 secret，應留在 server；瀏覽器只收到後端產生的短效 credential。Cloudflare 官方示例用 generate-ice-servers 取得 iceServers，並把短效 username／credential 傳給前端。概念上的後端呼叫如下：

1
curl "https://rtc.live.cloudflare.com/v1/turn/keys/$TURN_KEY_ID/credentials/generate-ice-servers" \
2
  --header "Authorization: Bearer $TURN_KEY_API_TOKEN" \
3
  --header "Content-Type: application/json" \
4
  --data '{"ttl": 3600}'

前端只使用後端回傳的 iceServers：

1
const peerConnection = new RTCPeerConnection({
2
  iceServers: [
3
    {
4
      urls: [
5
        'stun:stun.cloudflare.com:3478',
6
        'turn:turn.cloudflare.com:3478?transport=udp',
7
        'turn:turn.cloudflare.com:3478?transport=tcp',
8
        'turn:turn.cloudflare.com:80?transport=tcp',
9
        'turns:turn.cloudflare.com:5349?transport=tcp',
10
        'turns:turn.cloudflare.com:443?transport=tcp',
11
      ],
12
      username: turn.username,
13
      credential: turn.credential,
14
    },
15
  ],
16
});

不要把 TURN_KEY_API_TOKEN 放進瀏覽器，也不要為了「一定走 UDP」刪掉所有 TCP／TLS fallback。正確做法是按照使用者網路和安全政策保留可用候選，再用 stats 觀察實際被選中的 path。如果使用 trickle ICE，port 53 timeout 通常不會阻塞候選收集；不使用 trickle ICE 時，依 Cloudflare 文件考慮過濾 port 53 以免多等一次 timeout。

Credential 的 TTL 應長於預期工作階段，但不宜無限期。Cloudflare FAQ 說明 credential 最長 48 小時；長時間 allocation 應在到期前產生新 credential，並在連線中透過 setConfiguration() 配合重新協商。若 credential 過期，連線最後仍會被中斷，不能只靠 ICE restart 掩蓋 credential lifecycle 問題。

一份可放進監控的判斷表#

常見問題#