GA4 的流量是這樣掉的（以事件發生前一天為基準）：
| 日期 | 相對流量 |
|---|---|
| Day 1（基準） | 100% |
| Day 2 | 約 7% |
| Day 3 | 約 3.5% |
| Day 4 | 約 1% |
不是突然全斷，是慢慢爛掉的。這個模式有個名字：DNS cache 失效在網路上各地依序擴散。
A record 綁定的是一個時間點，不是一個服務
根本原因很直接：Cloudflare 的 DNS A record 指向一個過期的 Fastly IP——Railway 之前分配給這個服務的那個。Railway 在某個時間點調整了底層基礎設施，換了 IP。新的 IP 上有正確的 TLS 憑證，服務正常跑著。舊的 Fastly 伺服器不再認識客戶的域名，對所有進來的連線回傳 HTTP 421。
問題是 DNS 有 TTL。各地 ISP、瀏覽器、作業系統都快取舊的 A record，快取沒過期之前一切正常。Railway 換 IP 之後，快取陸續在不同地方過期，越來越多請求打到錯的伺服器——所以不是某個時間點突然斷，而是三天內慢慢死掉。
Cloudflare 代理多加了一層煙霧
如果 DNS 直接指向 Railway，你會直接看到 Fastly 的 421 錯誤頁面，指向非常明確。但 Cloudflare proxy 在前面，錯誤從 Cloudflare 那端噴出來，表面看起來像 SSL 問題。「網站有域名、有 SSL 憑證」這件事掩蓋了「後端已經在回應錯的伺服器」的事實。
這類故障的診斷路徑不直觀：要繞過 proxy 直接測後端，才能看到真正的錯誤。從中間件開始找，可能把很多時間花在錯的地方。
廣告一直在燒
三天內廣告繼續跑，有人點進來，但 landing page 是一個 Fastly 黑屏錯誤頁：數百次點擊，數千元廣告費打水漂，轉換全零。這是雲端基礎設施 IP 異動最直接的業務損失——不是技術債，是已經花出去的廣告預算。
修法：A record 換成 CNAME
刪掉舊 A record，改成 CNAME 指向 Railway 的服務域名（DNS only，不走 Cloudflare proxy）。CNAME 追的是名稱，不是 IP。Railway 之後再換 IP，CNAME 仍然正確，不需要人工更新。
A record 的根本問題是把一個特定時間點的 IP 硬編碼進去。雲端基礎設施調整 IP 是預期行為，不是異常。一個硬編碼的 A record 是隱患：你不知道它什麼時候爆，只知道它一定會。
監控要建在繞過 CDN 的位置
這類故障的特徵是：站點「看起來存在」——有域名、有 SSL——但實際在回應錯誤頁面。建在 CDN 上層的監控可能不會告警，因為 CDN 本身是健康的；壞的是 CDN 後面的路由。可用性監控需要從用戶端角度做端到端探測，或設定繞過 proxy 的後端健康檢查——只看 Cloudflare status 不夠。