502 Bad Gateway
The proxy server received an invalid response from an upstream server.
原本系統是通過一個SLB轉發到后端ECS上的nginx，由我們自己的Nginx再反向代理了各類服務器，畢竟使用了SLB了就打算去掉nginx。分拆后發現文件服務器的SLB映射好后報了上面的502錯誤。
看了看我們的系統沒有超時、內容過大等問題。而且之前也是SLB->nginx->file server。這次只是去掉了nginx，所以參數上沒有什么需要變化的。
負責雲服務器管理的同學說我們后端服務器端口是有問題的，說健康檢查有問題，讓我們查服務器是否正常。但我們本身就是運行的好好的，通過ECS服務器自己的ip訪問都是好的。
既然是健康檢查出了問題，那么應該是阿里雲SLB健康檢查機制導致的。
| 健康檢查配置 | 說明 |
|---|---|
| 域名和檢查路徑 (僅限HTTP方式的健康檢查) |
HTTP健康檢查默認由負載均衡系統通過后端ECS內網IP地址向該服務器應用配置的缺省首頁發起http head請求。 如果您用來進行健康檢查的頁面並不是應用服務器的缺省首頁，需要指定具體的檢查路徑. 因為有些應用服務器會對請求中的host字段做校驗，即要求請求頭中必須存在host字段。如果在健康檢查中配置了域名，則SLB會將域名配置到host字段中去，反之，如果沒有配置域名，SLB則不會在請求中附帶host字段，因此健康檢查請求就會被服務器拒絕，可能導致健康檢查失敗。綜上原因，如果您的應用服務器需要校驗請求的host字段校，那么則需要配置相關的域名，確保健康檢查正常工作。 |
從這里可以發現SLB與ECS之間如果是HTTP協議的話，需要有一個默認的url可以接收HEAD請求，這樣SLB才知道ECS是否還活着，這就是所謂的健康檢查。簡單點可以理解為心跳檢查。
那我們的問題原因很簡單就是因為文件服務沒有一個可供SLB檢查的默認頁，所以導致了健康檢查失敗。解決的方法也簡單，給SLB配置一個健康檢查的url即可，這樣就好了。