排查一次 CDN 的 TCP 連線重置：從現象到根因

這是一篇排查筆記。重點不在結論，而在「怎麼一步步縮小範圍」——這也是 Pre-sales 跟客戶談技術問題時最該展現的能力。

問題現象

客戶回報網站「有時候連得上、有時候連不上」。這種間歇性問題最難搞，因為無法穩定重現。第一步永遠是：把模糊的「有時候」變成可量化的數據。

縮小範圍的思路

我習慣用一套漏斗式的排查順序，從外層往內層逐一排除：

1. 是不是全站？ — 測試多個頁面與資源，確認影響範圍。
2. 是不是所有地區？ — 從不同節點測試，判斷是否與特定 CDN 節點有關。
3. 是哪一層斷的？ — 用工具觀察是 DNS、TLS 交握，還是 TCP 連線本身被重置。

查到第三層時，看到了關鍵訊號：TCP connection reset。連線在建立後被對方主動中斷，這通常不是網路壅塞，而是某一端主動拒絕了連線。

根因

最後定位到問題出在 CDN 的萬用網域（wildcard domain）設定與來源站的對應關係。當請求打到某些情況下的子網域時，來源站沒有對應的處理，導致連線被重置。

驗證方式是直接測試萬用網域在不同子網域下的回應行為，確認哪些情況會觸發 reset。

學到的事

• 間歇性問題，先求穩定重現，否則所有修正都是猜測。
• TCP reset 不是壅塞，是拒絕。方向判斷對了，少走很多冤枉路。
• CDN 的萬用網域很方便，但來源站要確保每個會被打到的網域都有對應處理，否則就是這種難查的雷。

對 Pre-sales 來說，這種排查能力的價值在於：當客戶問「你們的 CDN 會不會出問題」，你能講得出真實案例與排查方法，而不是只會說「我們很穩」。