排查一次 CDN 的 TCP 連線重置：從現象到根因 Debugging a CDN TCP Reset: From Symptom to Root Cause
這是一篇排查筆記。重點不在結論，而在「怎麼一步步縮小範圍」——這也是 Pre-sales 跟客戶談技術問題時最該展現的能力。
問題現象
客戶回報網站「有時候連得上、有時候連不上」。這種間歇性問題最難搞，因為無法穩定重現。第一步永遠是：把模糊的「有時候」變成可量化的數據。
縮小範圍的思路
我習慣用一套漏斗式的排查順序，從外層往內層逐一排除：
- 是不是全站？ — 測試多個頁面與資源，確認影響範圍。
- 是不是所有地區？ — 從不同節點測試，判斷是否與特定 CDN 節點有關。
- 是哪一層斷的？ — 用工具觀察是 DNS、TLS 交握，還是 TCP 連線本身被重置。
查到第三層時，看到了關鍵訊號：TCP connection reset。連線在建立後被對方主動中斷，這通常不是網路壅塞，而是某一端主動拒絕了連線。
根因
最後定位到問題出在 CDN 的萬用網域（wildcard domain）設定與來源站的對應關係。當請求打到某些情況下的子網域時，來源站沒有對應的處理，導致連線被重置。
驗證方式是直接測試萬用網域在不同子網域下的回應行為，確認哪些情況會觸發 reset。
學到的事
- 間歇性問題，先求穩定重現，否則所有修正都是猜測。
- TCP reset 不是壅塞，是拒絕。方向判斷對了，少走很多冤枉路。
- CDN 的萬用網域很方便，但來源站要確保每個會被打到的網域都有對應處理，否則就是這種難查的雷。
對 Pre-sales 來說，這種排查能力的價值在於：當客戶問「你們的 CDN 會不會出問題」，你能講得出真實案例與排查方法，而不是只會說「我們很穩」。
This is a debugging notebook entry. The focus isn’t the conclusion — it’s “how to narrow down the scope step by step.” That’s also the ability you most need to demonstrate when discussing technical problems with clients in a pre-sales context.
The Problem
A client reported that their website "sometimes connects, sometimes doesn't." Intermittent problems are the hardest to deal with because they can't be reliably reproduced. The first step is always: turn the vague "sometimes" into quantifiable data.
The Narrowing-Down Process
I follow a funnel-style debugging sequence, eliminating layers from the outside in:
- Is it the whole site? — Test multiple pages and resources to confirm the scope of impact.
- Is it all regions? — Test from different nodes to determine if it's related to a specific CDN node.
- Which layer is breaking? — Use tools to observe whether it's DNS, TLS handshake, or the TCP connection itself being reset.
At the third layer, I saw the key signal: TCP connection reset. The connection was being actively terminated after establishment — this typically isn't network congestion, it's one side actively rejecting the connection.
Root Cause
The issue traced back to the interaction between the CDN's wildcard domain configuration and the origin server's handling. When requests hit certain subdomain combinations, the origin server had no corresponding handler, causing the connection to be reset.
The verification method was to directly test the wildcard domain's response behavior across different subdomains and confirm which conditions trigger the reset.
What I Learned
- For intermittent problems, first get stable reproduction — otherwise every fix is just guesswork.
- TCP reset is rejection, not congestion. Getting the direction right saves a lot of wasted effort.
- CDN wildcard domains are convenient, but the origin server must have handlers for every subdomain that can be hit — otherwise you get exactly this kind of hard-to-find bug.
For pre-sales, the value of this debugging ability is: when a client asks "will your CDN have problems?", you can walk through a real case and methodology — not just say "we're very stable."