AWS帳號快速開戶 AWS Route 53 健康檢查（Health Check）頻繁誤報 Fail 導致 DNS 切換排查
一、先搞清楚：為什麼健康檢查會誤報
AWS Route 53 的健康檢查看起來很直接，實際上卻很容易被誤解。它不是在真正意義上替你判斷服務有沒有壞掉，而是站在幾個固定探測點，按照你設定的協議、端口、路徑、回應碼和超時條件，定期去探測目標。如果探測結果不符合預期，就會把目標標成 Fail。也就是說，健康檢查看到的是「探測結果」，不是「業務真相」。
這個差異，正是頻繁誤報的根源。很多團隊一開始以為，只要後端服務還能被自己打通，Route 53 就不該報 Fail。可問題在於，健康檢查的視角和你日常登入機器排障的視角完全不同。你在內網、在同一個 VPC、在同一台跳板機上測試，和 Route 53 從外部節點發起請求，結論可能完全相反。
因此，當出現 DNS 自動切換、流量抖動、主備頻繁翻轉時，先不要急著懷疑 Route 53 本身有問題，應該先把「它到底在檢查什麼」弄清楚。很多所謂誤報，其實是監控配置、網路邊界、TLS 設定、回應時間或中間層行為造成的。
二、Route 53 健康檢查的工作方式
理解原理，才能定位問題。Route 53 健康檢查通常會檢查以下幾個維度：協議類型、端口、請求路徑、回應內容、狀態碼、字串匹配，以及超時與失敗次數閾值。它會在多個位置定期探測，並根據連續失敗次數決定是否把健康狀態切成不健康。
這裡最容易被忽略的有三點。第一，探測是週期性的，不是實時的，所以你看到的 Fail 可能是前幾次探測的累積結果。第二，健康檢查對延遲很敏感，只要超出超時值，哪怕服務最終真的回了，也可能被判失敗。第三，如果你配置了字串檢查、狀態碼檢查或 HTTPS 憑證檢查，任何一個條件不滿足都會被視為失敗。
還要注意，Route 53 的健康檢查是分散式的。也就是說，不同檢查節點看到的結果可能不同。如果你的服務只對部分來源可達，或者中間有地域性防火牆、WAF 規則、CDN 緩存、地理封鎖，那麼就可能出現某些探測點健康、某些探測點失敗，最後整體判定搖擺不定。
三、頻繁誤報 Fail 的常見原因
1. 網路層不可達或被誤擋
最常見的情況，是安全組、NACL、防火牆、WAF 或主機防護策略擋住了健康檢查來源。很多人只放行了業務流量，卻忘了健康檢查是從 AWS 公網探測節點來的，不在你的內網白名單裡。這種時候，服務本身沒壞，但對探測者來說就是不可達。
AWS帳號快速開戶 還有一種情況更隱蔽：平時業務流量走 CDN 或負載均衡，健康檢查卻直接打到源站。源站只對 CDN 回源地址開放，卻沒有對健康檢查地址放行，結果自然是時好時壞。
2. 回應時間超過超時閾值
健康檢查不是只看最終成功與否，還看你多久才回應。當後端壓力升高、資料庫抖動、GC 變長、連線池耗盡、磁碟 I/O 飆高時，應用層可能還沒來得及返回，健康檢查就已經超時。從業務角度看，頁面也許只是慢了一點，但從健康檢查角度看，這就是失敗。
如果你把超時設得太短，或者把失敗門檻設得太低，任何短暫尖峰都可能把狀態拉成 Fail。這也是很多系統在高峰期發生 DNS 來回切換的真正原因。
3. HTTP 狀態碼與內容檢查不一致
有些團隊會讓健康檢查訪問某個特定路徑，並期待返回 200。可實際上，應用在維護模式、灰度模式、登入態失效、跳轉到 HTTPS、跳轉到登入頁時，回應碼可能是 301、302、403、503。這些在瀏覽器看起來或許是正常流程，但在健康檢查眼裡就是異常。
如果還加了字串檢查，比如要求頁面必須包含某個關鍵字，那麼模板變更、字體切換、靜態頁調整，都可能讓檢查失敗。很多看似神秘的誤報，其實只是前端模板換了一句文案。
4. TLS 或憑證問題
HTTPS 健康檢查對憑證、協議版本、SNI、加密套件都可能敏感。如果服務端更新了憑證鏈，卻沒有正確配置中繼證書；或者只支援較新的 TLS 協議，而探測過程中存在協議協商問題，就會導致連線失敗。還有些場景是域名和證書不匹配，瀏覽器可能只是警告，但健康檢查直接判定異常。
5. 依賴項抖動造成的間歇性失敗
服務本身只是健康檢查的表面目標，真正拖垮它的往往是下游。比如資料庫短暫鎖表、Redis 連線超時、第三方 API 卡住、磁碟空間逼近上限、容器節點資源吃緊，都可能讓健康檢查請求剛好撞上慢路徑。這種失敗最麻煩，因為它不是永久故障，而是偶發波動，最容易把人帶偏。
6. 負載均衡和路由鏈路配置不一致
如果健康檢查打的是 ALB、NLB、反向代理或某個內部服務地址，請確認它和真實業務流量走的是不是同一條路徑。很多問題出在，業務實際流量經過了多層代理、重寫、轉發，但健康檢查只測了其中一段，或反過來直接打到底層服務，導致結果與真實情況脫節。
四、排查時，先看四個時間點
遇到 DNS 切換異常，不要一上來就改參數。先把時間線拉出來，看四個點：健康檢查第一次失敗的時間、連續失敗的次數、Route 53 狀態翻轉的時間、業務端真正開始受影響的時間。這四個時間點一對，就能快速判斷是健康檢查先誤報，還是後端真的有波動。
如果健康檢查先失敗，DNS 隨後切換，但業務沒有明顯故障，通常是誤報。這時重點排查探測可達性、超時、回應碼、憑證和防火牆。如果業務先慢下來，之後健康檢查才失敗，那就要轉向服務本身，看看是不是資源瓶頸或依賴問題。
實務上，很多團隊只有健康檢查告警，卻沒有服務側的延遲、錯誤率、連線數、CPU、記憶體、I/O 指標。這會讓排查陷入盲區。真正有效的做法，是把健康檢查結果和應用監控、負載均衡日誌、WAF 日誌、主機系統指標一起對照。
五、實戰排查路線：從外到內逐層縮小
第一步：確認探測目標和路徑
先確認健康檢查到底在檢查哪個地址、哪個端口、哪個路徑。是直接打 IP，還是打域名？是 HTTP 還是 HTTPS？是否跟 DNS 記錄綁定到同一個目標？很多人以為自己在查 A 記錄，實際上健康檢查檢的是另一個服務入口。
AWS帳號快速開戶 這一步的目的，是避免在錯誤的對象上浪費時間。只要目標搞錯，後面的分析都會南轅北轍。
第二步：從探測視角復現請求
AWS帳號快速開戶 不要只在本機 curl，一定要想辦法從接近探測視角的環境模擬請求。可以從外部主機、不同地域節點、不同出口 IP 去測。關鍵不是能不能打通，而是能不能穩定打通，並且在健康檢查設定的超時內完成。
如果本地正常、外部偶發失敗，就要懷疑網路策略、地域封鎖、回源限制或 WAF 規則。如果不同來源結果差異很大，基本就不是應用程式單點問題，而是入口層策略問題。
第三步：檢查健康檢查參數是否過於激進
很多誤報不是服務太差，而是設定太苛刻。比如超時過短、間隔過密、失敗閾值過低、路徑太重、回應內容檢查過於嚴格。對於稍有波動的系統來說，這些參數會把短暫抖動放大成切換事件。
通常健康檢查應該盡量打到一個輕量、穩定、獨立的檢查端點，這個端點不依賴複雜業務邏輯，不查資料庫，不做外部請求，只要核心依賴正常就快速返回。這比直接拿首頁、下單頁、登入頁做健康檢查更穩。
第四步：看主機和應用是否存在尖峰波動
如果健康檢查是偶發性失敗，那就別只盯著配置，還要看資源圖。CPU 是否有短時飆高？記憶體是否觸發回收？磁碟是否有 IO wait？連線數是否接近上限？應用日誌裡是否有超時、拒絕連線、上下游調用慢？很多誤報其實是底層系統在某個瞬間卡住了一下。
這裡要特別重視固定時間段的失敗。如果每天同一時段失敗，常常不是隨機故障，而是批處理、備份、日誌輪轉、流量尖峰或定時任務搶資源。
第五步：檢查是否有中間層干擾
負載均衡、反向代理、CDN、WAF、API Gateway 都可能在中間改變請求行為。比如某些層會主動回傳 301 跳轉，某些層會在沒有特定 Header 時返回 403，某些層會把慢請求直接切斷。健康檢查只看到結果，不知道中間發生了什麼，所以要逐層排查。
如果條件允許，可以臨時繞過中間層，直接測試源站，或者反過來只測代理層，看看問題在哪一層出現。這種拆層法，比盲目改參數有效得多。
六、DNS 切換頻繁翻轉時，真正要防的是抖動
Route 53 的健康檢查一旦和故障轉移記錄綁定，就不只是監控問題，而是切流量的開關。這意味著，只要判斷不穩，DNS 就會在主備之間來回切，造成用戶體感上的不穩定。這種情況最可怕的不是完全不可用，而是時好時壞。
要避免翻轉，核心不是追求永遠不失敗，而是讓短時波動不至於觸發切換。可以從三個方向入手：提高失敗判定門檻、降低檢查敏感度、讓健康檢查目標更穩定。比如把檢查端點做輕量化，把超時設得合理一點，把連續失敗次數拉高一些，都能減少無意義切換。
不過這裡要把握平衡。門檻太高，雖然少了誤報，卻可能讓真正故障的切換變慢；門檻太低，又會被小抖動放大。最好的方式不是單純調參，而是讓健康檢查更接近真實可用性，同時讓後端更穩。
七、實際處理時，建議的修正順序
如果你正在面對頻繁誤報，建議按這個順序處理。先確認是否是網路可達與白名單問題，再確認回應時間和超時設定，接著檢查 HTTP 狀態碼與內容匹配，最後再看 TLS、依賴和中間層。這個順序的好處是，能先排除最常見、最便宜、最容易修的問題，避免一開始就陷入複雜系統分析。
AWS帳號快速開戶 如果確認是檢查路徑不合理，最好建立專用 health endpoint。這個端點要小、快、穩，不要和主業務耦合太深。若是安全策略導致誤擋，就單獨放行健康檢查來源，而不是把整個防護規則粗暴關掉。若是超時太短，就根據真實延遲分布重新設計，而不是憑感覺調整。
同時要把變更流程管起來。很多誤報都發生在部署、證書更新、WAF 規則調整、CDN 設定修改之後。如果沒有變更記錄，你會花很多時間猜。只要把健康檢查異常和最近的配置改動對上，往往很快就能找到突破口。
八、避免重演的關鍵，不是修一次，而是設計一次
真正成熟的做法，不是等誤報來了再救火，而是在設計階段就把問題擋掉。健康檢查要盡量檢查一個專用、可預期、低依賴的接口；安全組和防火牆要明確允許探測來源；TLS 配置要與健康檢查方式一致；監控要能區分探測失敗和業務故障；切換策略要能容忍短暫波動。
此外，還要建立一個事實：DNS 切換不是萬靈丹。它只是一種故障應對手段，不是用來補償架構設計不足的。若後端本身不穩，健康檢查再精準也只是在放大問題。若健康檢查設計得太敏感，它又會把正常波動誤判為故障。
所以，當你看到 Route 53 健康檢查頻繁 Fail，不要只問它為什麼報錯，更要問：探測是否合理、路徑是否穩定、依賴是否清晰、切換是否必要。這四個問題想清楚，很多 DNS 翻轉問題就不再神祕。
九、最後給一份簡單的排查清單
先看健康檢查目標是否正確，再看是否有白名單、防火牆或 WAF 擋住；接著檢查超時、間隔、失敗閾值是否過於激進；然後確認回應碼、跳轉、字串檢查、TLS 憑證是否匹配；再對照應用日誌、負載均衡日誌、系統指標和最近變更；最後評估是否需要建立專用 health endpoint，並調整切換策略避免抖動。
如果你能把這幾步做完整，Route 53 健康檢查的誤報率通常會明顯下降。更重要的是，你會從只會看告警，變成能看懂告警背後的系統行為。這才是處理 DNS 切換問題最有價值的能力。
