今天，咱們來聊一個對于許多剛接觸AWS的運維同學來說，既常見又有點頭疼的話題：如何優雅地排查和解決AWS上ALB（Application Load Balancer）暴露EC2服務時遇到的種種疑難雜癥。

最近，我剛幫一個朋友解決了類似的問題，他遇到的坑，我相信許多aws韻味朋友可能也踩過。結合他的案例和我的經驗，我整理出了一套清晰的故障定位思路和關鍵檢查點。希望這篇文章能成為大家云上運維工具箱里的一件利器。

從宏觀到微觀：理解ALB的工作流

在深入細節之前，我們先來建立一個全局視野。當一個用戶通過互聯網訪問我們的服務時，請求的旅程是怎樣的？下圖清晰地展示了從用戶到EC2服務的完整路徑，以及我們接下來要討論的關鍵檢查點。

這個流程圖就像一張地圖，當我們遇到“服務訪問不了”這類問題時，按圖索驥，逐一排查，就能快速定位問題所在。

故障排查實戰：七個關鍵檢查點

下面，我們來詳細拆解朋友總結的七個關鍵點，這也是一套行之有效的故障排查清單。

1. EC2安全組：為服務敞開對內的大門

很多新手或懶鬼會下意識地把EC2安全組的入站規則設置為對所有IP（0.0.0.0/0）開放，這雖然能讓服務跑起來，但存在巨大的安全隱患。

正確的做法是，EC2實例的安全組（Security Group）應該只允許來自ALB所在安全組的流量。這是一個最小權限原則的最佳實踐。

• 如何配置：

  1. 找到我們的ALB，記下它的安全組ID（例如 sg-alb12345）。
  2. 進入我們的EC2實例的安全組配置頁面。
  3. 添加入站規則：
     • 類型/協議： 選擇我們的服務使用的協議和端口（例如，HTTP/80端口，或我們自定義的8080端口）。
     • 源： 選擇“自定義”，然后輸入ALB的安全組ID sg-alb12345。

• 常見錯誤： 源地址錯誤地配置為ALB的公網IP。請記住，ALB與EC2之間是通過私有IP通信的，并且ALB節點的IP可能會變化，因此引用安全組是最穩定可靠的方式。

2. ALB安全組：對外開放服務的窗口

與EC2安全組的“對內”不同，ALB的安全組需要“對外”，即允許來自最終用戶的訪問。

• 如何配置：

  • 入站規則：
    • 類型/協議： 通常是HTTP（80端口）和/或HTTPS（443端口）。
    • 源： 一般設置為 0.0.0.0/0，表示允許來自任何互聯網用戶的訪問。如果我們的服務只對特定IP開放，可以在這里做限制。
  • 出站規則： 默認情況下，出站規則是允許所有流量，這通常不需要修改。

• 實用建議： 將ALB的安全組和EC2的安全組分開管理，職責清晰，一個負責對外，一個負責對內，能有效降低配置錯誤的風險。

3. 健康檢查：ALB的“聽診器”

ALB通過健康檢查來判斷后端的EC2實例是否“活蹦亂跳”且能正常處理請求。如果健康檢查失敗，ALB會認為該實例“不健康”（Unhealthy），并停止向其轉發流量。

• 關鍵配置項：

  • 協議（Protocol）： 應與我們的目標組協議一致。
  • 端口（Port）： 應該是我們EC2上服務真正在監聽的端口。
  • 路徑（Path）： ALB會向這個路徑發送GET請求。我們需要確保這個URL能返回HTTP 200狀態碼。很多Web框架默認的 / 路徑可能包含復雜的業務邏輯或重定向，建議專門為健康檢查創建一個簡單的路徑，如 /health 或 /ping，它只需直接返回一個200 OK即可。
  • 成功代碼（Success codes）： 默認是200。如果我們的健康檢查接口返回其他成功碼（如200-299），需要在這里修改。

• 排查技巧： 如果目標組中的實例持續處于unhealthy狀態，可以直接從一臺能訪問該EC2的機器上（比如同一VPC下的另一臺EC2），使用curl -v http://<EC2-私有IP>:<端口>/<健康檢查路徑>命令來模擬健康檢查，查看返回的狀態碼和內容是否符合預期。

4. 健康檢查的耐心：了解初始化時間

“為什么我的實例明明啟動了，卻一直是unhealthy？” 這是一個非常常見的問題。ALB將一個新注冊的實例判定為“健康”需要一個過程。

• 相關配置：
  • 檢查間隔（Interval）： 兩次健康檢查之間的間隔時間（默認30秒）。
  • 超時（Timeout）： 每次檢查等待響應的最長時間（默認5秒）。
  • 健康閾值（Healthy threshold）： 實例從不健康變為健康，需要連續成功的檢查次數（默認5次）。

計算一下：Interval * Healthy threshold = 30s * 5 = 150s。也就是說，在理想情況下，一個新實例至少需要2.5分鐘才能被標記為健康。如果中間有一次失敗，時間會更長。

• 實用建議： 在服務部署或變更后，請保持耐心。先去喝杯咖啡，再回來看狀態。如果幾分鐘后依然不健康，再根據上一條的技巧進行排查。對于需要快速啟動的應用，可以適當調低這些參數，但要小心過于頻繁的檢查給應用帶來壓力。

5. 目標組協議：與后端服務的“暗號”

ALB的目標組（Target Group）定義了流量將如何被轉發到后端EC2。這里的協議和端口必須與我們EC2上實際運行的服務監聽的協議和端口完全匹配。

• 常見場景：

  • 用戶通過HTTPS訪問ALB，ALB終止SSL，然后通過HTTP將請求轉發給后端EC2。這時，ALB監聽器是HTTPS:443，而目標組協議是HTTP:80（或8080等）。
  • 端到端加密，ALB和EC2之間也使用HTTPS。這時，目標組協議需要配置為HTTPS，并且EC2上需要配置好證書。

• 錯誤案例： 后端服務監聽的是8080端口，但目標組里填寫的端口是80。后端服務監聽的是http端口，但目標組里填寫的協議是https。這種“暗號”對不上的情況，流量自然無法送達。

6. 證書與域名：HTTPS的“身份證”

如果我們使用HTTPS監聽器，ALB需要綁定一個SSL/TLS證書。這個證書必須與用戶訪問的域名完全匹配，否則瀏覽器會報“NET::ERR_CERT_COMMON_NAME_INVALID”之類的安全警告。

• 最佳實踐：
  • 使用AWS Certificate Manager (ACM) 來免費申請和管理我們的SSL證書。
  • 確保證書覆蓋了我們的主域名（example.com）和需要的子域名（如 www.example.com）。使用通配符證書（*.example.com）可以簡化管理。
  • 當證書即將過期時，如果使用的是ACM管理的公有證書，ACM會自動續訂，非常省心。

7. 域名解析與Host頭：測試的捷徑

在服務部署的最后一步，我們需要將我們的域名通過DNS解析到ALB的DNS名稱上（通常是CNAME記錄）。

• 快速測試技巧： DNS解析在全球生效需要一些時間。如果想立即測試，有兩種方法：

  1. 修改本地hosts文件： 在我們的電腦上，將ALB的IP地址和我們想要測試的域名綁定。
  2. 使用curl的--resolve或Host頭： 這是一種更優雅的方式，無需修改系統文件。我們可以直接指定域名與IP的解析關系，或者通過Host頭來模擬特定域名的訪問。

  # 使用Host頭，<ALB_DNS_NAME>是ALB的地址
  curl -H "Host: your-domain.com" http://<ALB_DNS_NAME>/path# 或者，如果知道ALB的某個IP
  curl --resolve "your-domain.com:80:123.45.67.89" http://your-domain.com/path
  

  這個技巧在排查基于域名的路由規則時尤其有用。

總結

排查ALB與EC2的通信問題，本質上是一個抽絲剝繭、由外及里的過程。從用戶DNS查詢開始，到ALB的監聽器和安全組，再到目標組的健康檢查和協議配置，最后落到EC2實例自身的安全組和應用服務。

記住這七個關鍵檢查點，下次再遇到“網站打不開”的緊急工單時，相信大家一定能更有條理，從容不迫地定位并解決問題。

希望這篇文章對大家有幫助！如果大家有其他問題或者獨到的經驗，歡迎在評論區分享交流！