SSE 串流輸出停頓如何排查？分清連接、事件邊界與代理緩衝

SSE 串流輸出停頓時，分開未建立連接、收到位元組但事件未完整，以及緩衝延遲交付。HTTP 回應成功不表示應用已及時收到 Server-Sent Events。

關鍵要點：

• 查看實際事件 feed，而非只看載入它的網頁。
• 完整事件需要正確格式及結束邊界。
• 伺服器 flush、中介緩衝與客戶端顯示須分別觀察。
• 重連須有回放及去重政策，不盲目重發付費或改變狀態的請求。

步驟 1：SSE 串流輸出停頓時收到甚麼？

只用自有或明確獲准診斷的事件流。請營運方提供無害只讀 feed 及預期事件，不用付費模型生成、訂單提交或敏感活動 feed 重複測試。記下客戶端版本、執行環境、端點、回應狀態與首個預期事件的時間。

開始前開啟開發者工具，找出實際事件請求。網頁可以來自另一主機或早已快取；多個不相關應用失敗時，先使用裝置層面的診斷程序。HTTP 回應與可見內容更新要分開記錄。

確認程式使用原生 EventSource 或以 fetch 讀取回應。EventSource 有定義好的重連模型，自訂 reader 則需要自行解析及恢復。不把它的規則自動套用到每個稱作串流的介面。［1］［3］

不同階段都可能令文字框看似停頓。記錄最早可觀察的階段：等待回應標頭、收到位元組及收到完整事件，後續處理各有不同。

步驟 2：SSE 事件格式是否完成？

相容 EventSource 的 feed 使用 text/event-stream 和 UTF-8。事件以 data、event、id 等欄位組成，空白行結束一個區塊，多條 data 行可屬同一事件。TCP 封包及 fetch reader 的 chunk 不一定與事件邊界對齊。［1］［3］

獲負責人批准後查看無敏感內容樣本。data 到達但結尾空白行未到，瀏覽器可能還沒有完整事件可派發；這屬格式問題，不足以證明連接被阻斷。具名事件亦需要對應類型的監聽器，只處理普通 message 可能漏掉它。［1］

觀察	優先檢查環節	核對內容
沒有回應標頭	開場連接或存取	真正端點、錯誤與獲准認證
HTML 而非事件 feed	路徑或登入回應	預期狀態及 text/event-stream
位元組到達但沒事件	格式或監聽器	結束空白行及具名事件處理
最後一起出現全部事件	flush、緩衝或顯示	各可觀察階段的時間
閒置斷線後重連	連接壽命	心跳、計時器與恢復行為
重連後事件 ID 重複	回放行為	伺服器保留及客戶端去重政策

命令列與瀏覽器不同時，使用curl 與瀏覽器路徑比較。客戶端顯示緩衝與伺服器緩衝須分開；命令自行緩衝輸出，也可令正常 feed 看似延後。不能以螢幕更新直接量度封包到達。

步驟 3：SSE 代理緩衝在哪裏發生？

請服務負責人比較事件產生、完整事件寫入及經部署代理交付的時間。程式內部已產生 token 或事件，不表示已寫進回應；一層 flush 亦不能證明所有下游立即轉發。

NGINX 預設啟用代理回應緩衝。停用時收到多少便即時轉交，不嘗試緩衝整份回應。官方亦描述 X-Accel-Buffering 及忽略該標頭的設定，故它並非能命令所有 CDN 或中介的通用開關。［2］

管理伺服器時，只對事件端點作獲准的路徑設定變更並複核。不要為一個 feed 全站關閉緩衝，須保留認證、快取政策、資源限制及正常部署審查。

本地示例由實際 HTTP 伺服器分次發送三個無害完整事件，瀏覽器記錄 ID 及到達時間。另一端點短暫保留事件末尾空白行，顯示收到位元組與派發完整事件為何不同。

截圖是受控 loopback 示範的即時報告，並非正式流量、模型生成基準或 VPN 速度證據。真實服務須比較兩端觀察，不能預期得到本例的時間。

步驟 4：SSE 重連如何保留原任務？

原生 EventSource 通常依處理規則在中斷後重連。伺服器提供事件 ID 後，後續請求可傳 Last-Event-ID 供選擇恢復點。ID 不會自動建立保留歷史、回放或恰好一次交付，這些由應用政策決定。［3］

確認 ID 過舊、缺失或重複時怎樣處理。通知 feed 可以丟棄已處理 ID，歷史不足時取得新快照；工作狀態 feed 則重連原工作，不為拿新流而重新提交工作。

註解行可提供流量以協助避免閒置關閉，而不派發訊息事件。按負責人與已知中介限值設定頻率，不用過密探針，不假定一個通用計時器適用所有網絡。最後位元組與最後有效應用事件分開記錄。［1］［3］

離開任務時關閉 EventSource，限制自訂重連次數。開啟大量 feed 可以耗盡瀏覽器或服務資源。若問題是Python 讀取等待，獨立查看其有限期限，不當作相同 EventSource 重連政策。

步驟 5：獲准路徑會改變事件交付嗎？

確認端點、存取、格式及可觀察緩衝層後，才比較路線。保留相同無害 feed、客戶端、監聽器、認證與觀察窗口，僅使用管理員及當地法律允許的網絡。

在接收串流的受支援電腦上連接 AethoVPN，選 App 目前提供的本國或鄰近位置並開啟全局模式。重新開啟同一獲准只讀 feed，記錄首個完整事件及後續 ID 是否持續分次到達。與直接連接比較時，不同時改變伺服器事件頻率。

Windows 用官方安裝程式，Debian／Ubuntu x64 用 .deb；Mac 經網站設定指南取得配置，需要 Pro 或 Premium。收集事件前先核對公網出口，但瀏覽器 IP 頁面不能證明遠端 reader 或其他進程同路。

路線實驗不會 flush 尚未寫出的應用內容、修復事件邊界或改變模型及 API 配額。需要帳戶作獲准交付比較時，可開始 3 天免費 Pro 試用，每人一次，註冊時起算。

使用連接準備檢查，再判斷實際 feed。事件仍只在末尾出現時，保存證據並請負責人檢查緩衝及顯示。服務拒絕存取或兩路都沒有改善，就停止換路。

步驟 6：診斷記錄應包括甚麼？

記錄執行環境、脫敏 URL、開場狀態、Content-Type、首個完整事件、後續 ID 順序、閒置間隔及重連。獲准時與伺服器寫入時間對照，分開已觀察事實與推斷，也註明不可觀察的環節。

分享前移除認證標頭、Cookie、私人內容、帳戶識別資料及簽署 URL。不因方便而公開完整事件紀錄。另一個API 工具等待方式不同時，記下其實際執行環境和有限期限，不能直接當作瀏覽器對照。

WebSocket 工作階段有不同握手和雙向生命週期。換協議是應用設計變更，不是診斷捷徑。關閉診斷 feed、還原臨時設定，重試任何原操作前先確認其狀態。

總結

• 分開回應開場、位元組到達、完整事件及可見顯示。
• 變更網絡前核對事件邊界與監聽器。
• 緩衝與回放屬具體服務及中介責任。
• 比較無害獲准 feed 後，停止、還原並交付未解決環節。

常見問題

HTTP 200 是否證明串流正常？

200 只確認回應狀態。還須檢查 Content-Type 和完整事件，登入頁或沒有事件的回應並非所需 feed。

為何全部輸出最後一起出現？

伺服器 flush、中介緩衝或客戶端顯示都可能批次交付。先對照事件產生及到達的時間，再判斷是否網絡中斷。

數據到達卻沒有 message 事件，是甚麼原因？

不完整事件區塊會等待結束空白行，具名事件也可能需要獨立監聽器。因此須同時查看格式與處理器註冊。

Last-Event-ID 保證不漏事件嗎？

它只傳送恢復標記，不保證伺服器保留對應歷史。確認保留、回放限制及標記不可用時的恢復程序。

重連等於再次提交生成請求嗎？

連接已有只讀 feed 與建立新操作不同。付費或改變狀態的請求，須先確認原工作狀態，再決定新提交。

應否每個回應都用 X-Accel-Buffering？

只在部署代理支援而且需要時使用。它不是其他中介的通用修復，也不能代替指定路徑的設定複核。

VPN 能讓模型更快生成 token 嗎？

可比較路徑對交付的影響，但模型工作及 API 配額獨立。不可由事件流實驗推斷生成加快，或承諾 VPN 移除服務限制。

免責聲明： 只使用獲准事件流及網絡。保留服務存取控制，遵守當地法律，不重試有財務或其他副作用的操作。

來源：

1. MDN — Using server-sent events — https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
2. NGINX — ngx_http_proxy_module — https://nginx.org/en/docs/http/ngx_http_proxy_module.html
3. WHATWG HTML — Server-sent events — https://html.spec.whatwg.org/multipage/server-sent-events.html

Sources checked 2026 年 10 月 7 日。

---

延伸閱讀：

• 分開 Python 連接及回應等待
• 檢查雙向通道生命週期
• 比較瀏覽器與命令列路徑
• 確認裝置的 VPN 準備