AWS帳號充值優惠 AWS Global Accelerator 終端點健康檢查失敗導致流量未分發診斷
一、先看懂問題：為什麼健康檢查失敗，流量就不會分發
AWS Global Accelerator 的核心價值，是把使用者流量快速送到最合適的終端點，並在區域或節點發生異常時自動切換。它不是單純的負載平衡器，而是先透過固定的靜態入口接住流量，再根據健康狀態與路由策略，把請求導向後端的 Application Load Balancer、Network Load Balancer、EC2、EIP 或其他支援的終端點。
所以，一旦健康檢查失敗，Global Accelerator 會把對應終端點標記為不健康，進而停止向這個終端點分發流量。若該終端點是唯一可用目標，使用者就會直接感受到服務不可達、請求超時，或流量沒有明顯進入後端系統的現象。很多人第一時間會懷疑是 DNS、是應用程式、是安全群組，但實際上根因往往只是健康檢查沒有通過。
這類問題最麻煩的地方，不在於它難理解，而在於它看起來像「流量突然消失」，實際上是系統按規則把流量擋在了外面。要快速恢復服務，關鍵不是盲目重啟，而是先判斷健康檢查到底在哪一層失敗。
二、Global Accelerator 的判斷邏輯：不是有終端點就一定有流量
很多故障都源自一個誤解：終端點加入了 endpoint group，流量就應該會自動過去。其實不然。Global Accelerator 會先做健康判斷，再決定是否把流量送往該終端點。當健康檢查長時間失敗，該終端點就不再承接流量；如果同一個端點群組內所有終端點都不健康，整個群組都會失去分流能力。
健康檢查通常會檢查協定、埠號、路徑、回應碼與連線時間。只要其中任一條件不符合預期，就可能被判定為失敗。也就是說，服務明明還活著，但只要健康檢查 URL 回了 301、302、403、404，或者連線太慢、TLS 握手不成功、後端埠沒開，Global Accelerator 仍然可能把它視為不健康。
這也是為什麼診斷這類問題時，不能只看應用程式本身是否啟動，還要看「健康檢查是否真的打到了預期回應」。
三、先確認現象：流量未分發到底是什麼樣子
AWS帳號充值優惠 1. 使用者端的表現
使用者通常會遇到以下幾種情況：網站打不開、API 請求超時、延遲突然飆高、部分地區可用但部分地區不可用。若服務前面掛著 Global Accelerator，這些現象不一定代表整體網路壞掉，而可能是某個終端點群組被判定為不健康後，流量被轉往其他節點，甚至完全沒有可用節點可接。
2. 後端觀察到的現象
在後端主機或負載平衡器的存取日誌裡，可能看不到預期流量，或請求量明顯下降。若健康檢查本身也失敗，你會看到該埠沒有固定週期的探測成功紀錄。若只有應用端流量少，但健康檢查正常，問題就要改查 Listener、流量權重或路由設定。
3. AWS 主控台狀態
在 Global Accelerator 的終端點群組中，健康狀態常是最直接的線索。若顯示 Unhealthy，先不要急著改配置，先釐清是單一終端點失敗，還是整個區域都失敗；是所有健康檢查都失敗，還是只在特定條件下失敗。這會直接決定排查方向。
AWS帳號充值優惠 四、最常見的失敗原因：問題通常不在「流量」，而在「回應」
1. 健康檢查端口或協定設定錯誤
這是最常見的情況之一。健康檢查設定的是 HTTP，但後端只開了 HTTPS；或檢查埠設為 80，實際服務卻聽在 8080；又或者健康檢查走 TCP，但後端只允許應用層特定來源。只要協定和埠對不上，探測自然失敗。
2. 路徑回應不符合預期
HTTP 健康檢查常常不是只要有回應就算成功，而是要回傳指定成功碼。假如你的健康檢查路徑是 /health，但應用程式會把請求導到登入頁，最後回 302；或路徑不存在回 404；或被權限系統擋住回 403，這些都可能讓健康檢查判定失敗。
3. 安全群組或網路 ACL 擋住探測
AWS帳號充值優惠 服務本身可能可以從內部訪問，但健康檢查來源並不在你的允許清單裡。安全群組、網路 ACL、主機防火牆，甚至容器網路政策，只要有一層擋掉探測封包，健康檢查就會失敗。這類問題很像應用壞了，實際上只是網路被拒絕。
4. 應用程式處理太慢或偶發逾時
如果健康檢查超時設定過短，而應用在高峰時段回應較慢，就會出現「平時正常、尖峰不健康」的情況。這種故障最容易被忽略，因為應用不是完全掛掉，而是延遲把健康檢查拖死了。只要連續多次失敗，終端點就會被摘除。
5. 回應內容或狀態碼與預期不一致
AWS帳號充值優惠 有些團隊把健康檢查路徑設在一個需要登入的頁面，結果每次都回 401；或應用升級後，原本回 200 的 API 改成回 204，健康檢查條件卻沒有同步調整。這類問題非常典型，也最容易在版本更新後突然出現。
五、診斷順序：照這個步驟查，通常最快
1. 先看 Global Accelerator 的健康狀態
先確認是哪個 endpoint group、哪個終端點、哪個協定的健康檢查出問題。不要一開始就進應用。因為若終端點已經被判定不健康，你看到的「沒流量」其實只是結果，不是原因。
2. 再看健康檢查設定
逐項核對協定、埠號、路徑、逾時、間隔、成功碼範圍。很多故障不是配置完全錯，而是細節改動後忘了同步更新。例如應用改版後健康檢查路徑變了，或者反向代理新增了轉址規則，導致原本正常的檢查突然失敗。
3. 直接從終端點做本地驗證
如果是 EC2 或容器主機，直接在主機上用 curl 或本機命令測試健康檢查路徑，觀察是否回傳預期內容與狀態碼。若本機都不正常，問題在應用層；若本機正常，但外部健康檢查失敗，問題多半在網路、權限或來源限制。
4. 檢查安全群組與防火牆規則
確認健康檢查使用的埠在入站規則中被允許，並且沒有被主機防火牆、WAF、反向代理限制。若前面還有 ALB/NLB，也要檢查它們的健康檢查與轉發鏈路是否正常。很多人只查了一層，結果真正擋住的是第二層。
5. 看應用日誌與負載情況
查應用日誌時，不只看錯誤，也要看健康檢查請求是否真的有到達。若完全沒有到達，先查網路；若有到達但回應碼不對，先查應用邏輯；若到達且回應正確，但偶發失敗，則要看資源瓶頸、GC、連線池、CPU、磁碟 I/O 或其他尖峰因素。
六、幾個很容易誤判的情境
1. 服務其實正常，只是健康檢查被轉址
很多網站會把未登入請求導向登入頁，這對使用者沒問題，但對健康檢查卻是失敗。因為健康檢查通常期待的是固定成功碼，而不是一串跳轉流程。這種情況下，應該建立專用的 /health 或 /ready 路徑，避免與業務頁面共用。
2. 容器已啟動，但應用尚未就緒
在微服務或容器環境裡，啟動不代表可服務。若健康檢查太早開始，應用可能還在載入設定、等待資料庫、初始化快取，這時檢查就會失敗。解法通常是拉開啟動與就緒的定義，讓就緒檢查真正代表服務可用。
3. 只在某一區域失敗
若 Global Accelerator 的某個區域健康，但另一個區域不健康，可能是該區域的後端資源、路由、NACL、跨區存取設定出現差異。這種問題常見於多區部署，因為每個區域看起來像複製品，實際上常有細微差別。
七、修復建議：先恢復可用，再優化設計
1. 建立專用健康檢查路徑
專用路徑不要依賴登入、權限、外部服務或資料庫查詢，最好只回傳最基本的成功狀態。它的目標不是證明整個系統百分之百正常，而是快速、穩定地告訴調度層：這個終端點目前可以接流量。
2. 放寬或調整成功條件
如果業務上允許，健康檢查的成功碼範圍可以適度放寬，避免因為少數非關鍵狀態碼造成頻繁抖動。但這個調整要保守，否則會把真正的異常也放過去。原則是：不要讓健康檢查太嚴，也不要讓它失去判斷力。
3. 增加冗餘終端點
如果只有單一終端點，健康檢查一失敗就等於整條路斷掉。至少要有備援終端點，並在不同區域或不同故障域部署，讓 Global Accelerator 真的有地方可以切換。否則再漂亮的流量調度，也只是建立在單點之上。
4. 把健康檢查納入發布流程
每次上線前，應把健康檢查路徑、回應碼、埠號、協定納入檢查清單。尤其是反向代理、路由規則、認證流程變更時，健康檢查最容易被順手改壞。若沒有發布前驗證，故障常常會在正式流量進來後才爆出來。
八、實戰排查清單：遇到流量未分發時先問自己這些問題
- 終端點在主控台裡是健康還是不健康？
- 健康檢查的協定、埠號、路徑是否與實際服務一致？
- 回應碼是否符合健康檢查預期？
- 安全群組、NACL、防火牆是否允許探測流量？
- 應用是否在高峰時出現逾時或資源耗盡？
- 是否只有某個區域或某個 endpoint group 出問題？
- 最近是否有發布、改路由、換憑證或調整反向代理？
如果以上問題逐一核對，通常很快就能把故障範圍縮到很小。真正花時間的，往往不是找出「有問題」，而是找出「哪一層的問題先發生」。
九、總結：流量沒分發，先懷疑健康檢查，不要先懷疑整個網路
AWS Global Accelerator 的流量調度，表面上看起來像路由問題，實際上經常是健康檢查問題。只要終端點被判定為不健康，它就不會拿到流量；若所有終端點都不健康，使用者就會感覺服務像是憑空消失。這不是系統失靈，而是調度機制在忠實執行規則。
處理這類故障，最有效的方法是從健康狀態往下查：先看主控台，再看配置，再看網路，再看應用回應。不要一開始就大範圍改設定，也不要只盯著流量圖。真正能讓系統恢復的，通常不是一次大修，而是把健康檢查設對、把終端點設穩、把備援做好。
只要把這幾件事做好，Global Accelerator 才能發揮它真正的價值：在前端保持穩定入口，在後端維持可靠分流，讓流量在服務出問題時不至於整片掉線。
