部落格寫一小時。SSE 預設仍是 15 秒。

公告寫的是上限，設定頁寫的是預設，兩句不要併成一句。10 月 22 日那則公告說串流最長可以開一小時。設定頁說 SSE 和分塊傳輸的 deadline 仍預設 15 秒，打開串流不會改這個行為。一小時是 3600 秒。那是天花板。你若只新建閘道、沒寫 deadline，拿到的不是天花板。

這個站看過套接字範例和模型卡不是同一個字串。語音套接字用別名，模型卡寫的是 3.0。也看過知識 API 要先搜片段。先搜片段。也看過標價不是帳單。Haiku 5.5 短提示 0.10 美元。API Gateway 的一小時是同一種錯法：天花板被寫成你已經設好的值。

15 秒還是 SSE 的牆鐘

文件講得很直。在閘道上啟用串流，不會改變 SSE 或分塊傳輸路徑上 deadline 的行為。deadline 仍是整段回應的牆鐘上限。時間一到，串流就斷，不管後面還有沒有資料在送。預設 15 秒。上限 3600 秒。

這句要寫在公告引文上面。客戶端開了一條 SSE 聊天補全，第一個 token 來得慢，15 秒就斷。閘道即使是串流閘道，只要沒設 deadline，預覽並沒有把預設往上抬。它抬的是天花板，而且只對建立時就打開串流的閘道。表格寫明 3600 秒的上限適用於已啟用串流的閘道。先有新閘道，再寫 deadline，才是公告裡的「最多一小時」。只讀貼文，兩步都還沒做。

閒置那一欄會讓人以為可以不設 deadline。HTTP 串流（SSE、分塊傳輸）的閒置逾時標成不適用，實際上等於沒有閒置計時，只有請求逾時會結束串流。沒有閒置計時，不等於可以一直活著。每秒吐一個 token 的串流，牆鐘碰到 deadline 一樣斷。40 秒沒吐資料的串流，若你留著預設，也是 15 秒斷，斷的原因是請求計時，不是閒置計時。那一列沒有閒置旋鈕。日誌裡去找 idle timeout，會找到一個 SSE 列上不存在的東西。

WebSocket 和 gRPC 是另一列。把它們併進 SSE 那句，設定審查會放行錯誤的數字。gRPC 或 WebSocket 串流的閒置逾時預設 300 秒。你可以改 deadline，已啟用串流的閘道最高 3600 秒。WebSocket 上，低於 300 秒的 deadline 會被忽略，最低就是 300。這一列的請求逾時，在已啟用串流的閘道上永遠是 3600 秒，不能改。連線層的上限是一小時，訊息之間空 300 秒仍可能被拆掉。從 HTTP 習慣抄來的 deadline: 30，不會給你 30 秒的 WebSocket 間隔。文件說這個值被忽略，最低 300。你若需要更短的 WebSocket，這次預覽沒有那個旋鈕。

非串流請求也停在 15 秒預設。表格第一列：閒置不適用，請求逾時預設 15 秒，deadline 最高 3600，僅限已啟用串流的閘道。旗標打開，不會悄悄拉長你的一元呼叫。它只是允許你拉長。健康檢查若一直靠 15 秒預設，現在仍是 15 秒，除非有人把聊天路由的 backend deadline 設成 3600.0，又把健康檢查掛到同一個 backend。

旗標在建立時決定，MCP 不會跟著串起來

串流是建立閘道時指定的。正式環境裡要緊的限制是不可變：不能把既有閘道更新成啟用或關閉串流。你得新建一個。啟用串流的閘道主機名形狀不同，客戶端或 DNS 要跟著搬。文件提到主機名模式，也提到若要把既有紀錄改成新格式可以找支援。模式字串在我能乾淨引用的那一段沒有留下來。切 DNS 之前去讀那個標題。能確定的是形狀會變，而且客戶端若還指著舊閘道，不會因為你更新了規格就突然開始串流。

公告的起步句子和這條限制對得上，如果你把「新」讀進去。「把一個新的、已啟用串流的閘道指到既有的、會吐 SSE 的後端。」新閘道。舊後端。規格，公告說，不必改。這可以成立，同時你仍只有 15 秒的串流，因為「規格不必改」和「把 deadline 設成 3600」是兩句話。描述串流操作不需要新的擴充欄位。deadline 才是把公告裡的一小時花掉的欄位。現有規格若沒有 deadline，新閘道會套預設。

MCP 是會耗掉一個下午的例外。用 --enable-streaming 建立閘道，不會讓 MCP 端點開始串流。MCP 回應仍是單一的 application/json，跟閘道有沒有開串流無關。其餘文件指向 MCP Limitations。我沒讀到的變通方法，不會在這裡補完。代理協定若是 MCP，預覽旗標不是把 body 切成片段的開關。公告列出的是 SSE、分塊 HTTP、WebSocket、gRPC 串流。MCP 在設定頁被單獨寫成仍是一整份 JSON。先看 content type。回應是 application/json，客戶端卻在等 event-stream 影格，旗標就是岔路。

協定是第二個容易跳過的欄位，因為範例看起來已經寫完。OpenAPI 2.0 的片段在 x-google-backend 裡把 protocol 設成 h2，旁邊是 deadline: 3600.0。另一句說 WebSocket 要用 http/1.1。把 h2 範例貼到 WebSocket 後端，不是那句話的意思。OpenAPI 3.x 把同一組放在 x-google-api-management 的 backends 底下，protocol h2、deadline 3600.0，再用 x-google-backend 指向具名後端。範例裡的 3600.0 是選項。它是上限，被寫出來。閘道啟用串流時，系統不會替你填這個數字。

路徑轉譯有預設，deadline 設對了，URL 仍可能被改掉。頂層 x-google-backend 預設 pathTranslation: APPEND_PATH_TO_ADDRESS。閘道會把請求路徑接到後端位址後面，所以打到 /v1/chat/completions 的請求，會落到真的有這條路徑的後端。後端若期望路徑在根上，這個接法會讓本來能維持的串流變成 404。那看起來像串流壞了。它是路徑壞了。文件用這個預設說明 Gemma 風格的後端為什麼收得到 /v1/chat/completions。要嘛對齊後端，要嘛改轉譯。不要靠拉長 deadline 去查 404。

570 和 600，誰的計時器先響

文件舉了一個具體的衝突，這個例子比口號有用。deadline 設 570 秒，比 Gemma 指南在服務上設的 --timeout 600 短 30 秒。跑太久的串流，是閘道的 deadline 先結束，不是服務逾時。兩個計時器，短的贏。那個例子裡短的是閘道。

你若因為部落格寫一小時就把 deadline 設成 3600，閘道後面的行程若仍是 600 秒逾時，贏的是行程。客戶端會在 10 分鐘看到串流斷掉，然後覺得部落格說錯。部落格描述的是閘道上限。行程有自己的上限。選 3600.0 之前先把兩個數字寫下來。570 對 600 是文件在說，他們至少為 Gemma 想過一次。你的 vLLM、反向代理、負載平衡器各有一票。閘道活不過一個 60 秒就關連線的代理。SSE 那列的閒置「無限」打不穿那個代理。

同一個例子裡的認證是 Google 簽的 ID token，受眾是 gemma-api。文件說受眾字串可以換，只要呼叫端鑄 token 時要的是同一個。受眾不是串流設定。401 不是 deadline。串流根本沒開始，因為 token 受眾不合，事後報告會寫成「預覽的串流失敗」。先看狀態碼，再碰 deadline。安全要求會讓閘道拒絕任何沒帶那個 token 的請求。拒絕是一個回應。它不是被截斷的串流。

公告裡模型路由那句很容易讀過頭。使用模型路由的閘道，現在會把 Gemini、Claude，以及 model garden 裡的 OpenAI gpt-oss，在生成時就串出來；你放在別處的串流後端也一樣。「一樣」是指閘道會把串流透傳。不是指這些模型無視 15 秒預設。也不是指 gpt-oss 和 Claude 共用一個逾時。它是說預覽不限於某一家的分塊格式。SSE 被稱為把模型輸出串到瀏覽器或 SDK 的事實標準，也是多數 OpenAI 相容聊天補全 API 後面的傳輸。分塊傳輸和 NDJSON 以後端產出的節奏透傳，而不是緩衝到最後才一次給。WebSocket 是全雙工。gRPC 的伺服器端串流和雙向串流，是閘道終於可以擋在以前無法代理的服務前面的原因。四種模式。它們不共用 WebSocket 的閒置列。SSE 在 HTTP 那列。gRPC 在 300 秒那列。

重新連線是公告裡另一句操作說明，deadline 表格讓它變得急。客戶端應該做重連，讓工作階段熬過串流結束。行為正常的 WebSocket 或 SSE 客戶端本來就該這樣。在預設的 SSE 閘道上，「串流結束」可以是長補全進行到第 15 秒。重連若假設唯一的切斷是一小時上限，會把預設 deadline 當成網路故障，然後迴圈重試。客戶端程式庫若分得出 deadline 切斷和斷線，就分開。分不出，就記經過時間。整整 15 秒是預設。整整 3600 秒是上限。中間的數字是你設的，或是閘道前面某個你忘了的元件。

規格裡要按這個順序放

新建一個啟用串流的閘道。MCP 限制裡點名的旗標是 --enable-streaming。不要計畫在已經掛著 DNS 的那台閘道上翻這個旗標。計畫一個新主機名，再搬客戶端。

把閘道指到已經會吐 SSE、分塊 JSON，或你打算暴露的 gRPC 串流的後端。MCP 若必須維持單一 JSON，就讓它走自己的路由。不要指望旗標會改那個 content type。

在你真的想讓它活久一點的 backend 定義上設 deadline。SSE 聊天路由寫 3600.0，就是公告的天花板，也是文件接受的數字。呼叫本來就短、你寧可快速失敗，寫小一點也行。什麼都不寫，你已經有 15。WebSocket 不必寫低於 300 的 deadline。文件說會被忽略。那個 WebSocket 後端用 protocol: http/1.1，不要用 h2 範例，除非你讀到的說明比我這次用的更新。

若你希望結束串流的是閘道，行程逾時就要長過閘道 deadline。570 對 600 是這個形狀：閘道先斷，服務晚 30 秒，你要查的切斷就是你設的那個。中間的代理更早關，就去修代理，或不要對外說一小時。

路由已經描述好了，就留著現有的 OpenAPI。公告的主張是串流不是新的資源類型，也不是新的註解。這句和文件對得上，只多一件事：deadline 欄位才是讓一小時從標題變成設定的東西。受眾、路徑轉譯、協定本來就是欄位。它們仍會切斷串流，只是不用計時器。

兩邊都標了公開預覽。預覽的意思是，主機名形狀、不可變、MCP 例外，寫在限制清單裡是故意的。我會先立新閘道，設一個日誌裡認得出的 deadline，再發一條你預期會超過 15 秒的 SSE。15 秒斷，旗標開了，欄位沒寫。在你設的 deadline 斷，你才站在公告所摘要的那一頁上。摘要把預設留在頁外。