Cloudflare 在台灣時間 11 月 3 日中午於狀態頁公告，亞太區出現網路效能問題。Cloudflare 在台灣時間 11 月 3 日中午於狀態頁公告，亞太區出現網路效能問題，並於 13:56 標示解決。官方未公布原因與受影響的節點範圍。
官方公告內容
這則公告的標題是「Network Performance Issues in APJC」，受影響的服務列為 Network，目前只有兩次更新：
- 12:44（Investigating）：Cloudflare 正在調查 APJC 區域的網路效能問題。
- 12:53（Identified）：已找到問題，正在實施修復。
公告本身沒有列出城市或節點。狀態頁同時另有一則 Containers 服務的事件，兩者受影響的服務不同，官方也沒有表示彼此相關。
本站從台灣量到的情況
本站今天中午就發現網站變慢，所以留下了幾組量測。以下只是單一線路的觀察，不代表所有用戶的情況。
| 時間 | 量測項目 | 結果 |
|---|---|---|
| 11:45 到 12:01 | HiNet 線路連往本站使用的 Cloudflare IP（104.21.x、172.67.x） | 掉包 60% 到 80%，延遲約 155 毫秒，連到新加坡節點，請求常逾時 |
| 11:45 到 12:01 | 同一線路連往 104.16.123.96（同為 Cloudflare） | 掉包 0%，延遲約 3.9 毫秒 |
| 13:05 前後 | 手機行動網路開啟本站 | 速度緩慢，出現 Cloudflare 的 502 Bad Gateway 頁面 |
| 13:08 | HiNet 線路連往同一批 IP | 掉包降為 0%，改連聖荷西節點，延遲約 126 毫秒 |
| 13:09 到 13:11 | HiNet 線路開啟完整頁面，共 12 次 | 5 次異常：4 次 30 秒內無回應，1 次等待 17.4 秒；其餘正常的請求約 1 到 2 秒 |
| 13:06 | 在原站主機上直接請求頁面 | 6 次都是 HTTP 200，約 0.6 秒 |
同一時段，原站主機的資源使用率很低，後端日誌在 12:32 之後也沒有 5xx 錯誤，所以這次緩慢看來不是原站造成的。
不過有兩點還無法確認。第一，掉包在 11:45 就已出現，比公告早了約一小時，我們無法證明這和官方事件是同一個問題。第二，13:09 之後的延遲沒有逐段計時，只能說證據偏向 Cloudflare 到原站的路徑，尚未完全定案。
站長可以怎麼判斷
先看狀態頁，但不要只看狀態頁。本站開始變慢時，狀態頁還沒有這則事件，公告可能晚於實際影響。
開啟網站的 /cdn-cgi/trace。這個網址由 Cloudflare 節點直接回應，colo= 會顯示連到哪個節點。如果台灣用戶連到國外節點，就值得留意。
分段量測。分別測試在原站主機上直接請求、從用戶端開啟 /cdn-cgi/trace，以及從用戶端開啟完整頁面。前兩者正常而完整頁面異常，問題就不太可能只在用戶端到節點這一段。
不要急著調整主機，或關閉 Cloudflare 代理。原站正常時，重新啟動服務幫助不大；關閉代理則會暴露原站 IP。
本文會在官方更新後再修訂。最新進度請見 Cloudflare 狀態頁的事件公告。
事件更新：官方已標示解決
Cloudflare 在台灣時間 13:49 表示修復已實施並進入監控，13:56 將事件標示為已解決，從開立到解決約 1 小時 12 分鐘。官方公告沒有說明原因和受影響的節點，影響程度列為 minor。
本站在 14:18 從同一條 HiNet 線路複測，連往先前異常的 3 個 Cloudflare IP 都沒有掉包，連續 8 次開啟未快取頁面也全部成功，每次約 1.4 到 1.6 秒。不過目前線路仍連到聖荷西節點，延遲約 126 毫秒，尚未回到亞洲節點。公告也沒有說明本站中午觀察到的掉包和這起事件是否相關，因此兩者的關聯仍無法確認。
完整時間軸請見 Cloudflare 狀態頁的事件公告。
