阿里雲國際 遭遇502 Bad Gateway排查思路

什麼是502 Bad Gateway？別急，先別砸鍵盤！

跟你說個小故事

想像你去餐廳點餐，傳菜員急吼吼地衝進廚房大喊「客人的菜好了嗎？」廚房裡卻空無一人，鍋子冷得結霜。傳菜員只能回來跟你說「不好意思，廚房關門了」。這就是502的日常——網關伺服器（傳菜員）找不到後端伺服器（廚房），只能苦著臉說「Bad Gateway」。別急著砸鍵盤，先冷靜想想：是不是你的伺服器「翹辮子」了？

常見病因大解密

上游伺服器「翹辮子」了

這是502的「常見病」。舉例：你的Nginx反向代理到後端的PHP-FPM服務，結果PHP-FPM崩潰或停止運作。Nginx收到「這服務不存在」的回應，轉頭就對用戶說「502，別怪我，怪它沒人管」。檢查方式超簡單：在伺服器上執行 systemctl status php-fpm 或 ps aux | grep php，看到狀態是active就放心，要是顯示「inactive」或「dead」，快去把服務拉起來！

代理配置搞砸了

有些同學手賤改了Nginx設定檔，結果把 upstream 的 IP 寫錯，或者 port 寫成 8080 卻實際跑在 9000。這時候 Nginx 對著空氣喊話：「喂！後台有人嗎？」結果沒人理，只好回報 502。檢查設定檔： nginx -t 測試語法，再用 cat /etc/nginx/conf.d/your.conf 核對 upstream 設定。記住：設定檔裡的 port 要和實際運行的服務一致，這是基本禮貌！

網路傳輸卡關

防火牆擋了？交換機當機？網線鬆了？這些網路層問題也會導致 502。比如你的伺服器和後端服務在不同網段，但防火牆規則沒開通，導致連不上。用 telnet 後端IP 端口 測試連通性，如果顯示「Connection refused」或「timeout」，那網路層就有問題。快檢查防火牆設定： iptables -L -n 或 ufw status，確保端口開放。

超時大作戰

有時候後端服務跑得慢，比如資料庫查詢卡住，Nginx 等太久就等不及了，直接說「等不下去了，502！」。這時需要調整超時設定。在 Nginx 裡加： proxy_read_timeout 300s; 或 fastcgi_read_timeout 300s;，把等待時間拉長。但別太長，否則資源浪費，合理就好。

DNS小故障

如果你的 upstream 設定用域名而非 IP，而 DNS 伺服器掛了或解析錯誤，Nginx 就找不到正確地址。用 dig 域名 或 nslookup 域名 檢查 DNS 解析是否正常。要是回傳錯誤，切換到 IP 或換 DNS 伺服器。

負載過高？還是資源告急？

伺服器 CPU 100%、記憶體爆掉、磁碟滿了，都可能讓後端服務崩潰。用 top 或 htop 看資源佔用，df -h 檢查磁碟空間。要是資源不足，得擴容或優化程式碼，別讓伺服器累到吐血。

排查步驟實戰指南

第一步：檢查服務狀態

先確認所有相關服務是否運行。舉例：Nginx 作為代理，後端有 PHP-FPM 和 MySQL。用 systemctl status nginx、systemctl status php-fpm、systemctl status mysql 檢查狀態。如果某個服務沒起來，先重啟它： systemctl start php-fpm。注意：重啟前先看看日誌，別盲目重啟，搞不好問題是配置錯誤，重啟也沒用。

第二步：看日誌，別讓日誌「裝死」

日誌是 troubleshooting 的最佳夥伴。Nginx 錯誤日誌通常在 /var/log/nginx/error.log，後端服務日誌要看具體配置。用 tail -f /var/log/nginx/error.log 實時監控，找關鍵字「upstream」、「connection refused」、「time out」等。比如看到「connect() failed (111: Connection refused)」，就知道後端服務沒開；看到「upstream timed out」，就該調整超時設定。

第三步：用curl等工具測試

直接測試後端服務是否正常。例如，如果後端跑在 localhost:8080，用 curl -v http://localhost:8080。如果回傳 200，表示後端正常；如果是 502，那問題可能出在代理設定。如果 curl 連不上，可能是防火牆或服務崩潰。進階用法： curl -x http://代理IP:代理端口 目標URL 模擬代理行為，確定問題點。

第四步：檢查代理設定檔

以 Nginx 為例，檢查 nginx.conf 或 site 配置。重點看 upstream 區塊、proxy_pass 設定是否正確。例如： upstream backend { server 192.168.1.100:8080; }，確認 IP 和 port 是否正確。另外檢查 proxy_set_header 設定，有時 Host 頭傳遞錯誤也會導致後端拒接。

第五步：網路層面排查

用 ping 看基礎連通性，traceroute 看路由是否正常。防火牆檢查： sudo ufw status 或 sudo iptables -L -n，確保目標端口開放。如果服務在雲端，檢查安全組規則是否允許流量。例如 AWS EC2 安全組需要開放 80/443 端口，否則外網連不上。

解決方案：對症下藥

重啟服務，但先別急

很多人一看到 502 就急著重啟服務，這其實不對。先確認原因：如果服務崩潰，重啟可能暫時解決，但根本問題沒處理。例如，如果因為記憶體不足崩潰，重啟後可能很快又崩。先看日誌找到原因，再決定是否重啟。重啟前最好備份設定檔，避免重啟失敗後無法恢復。

阿里雲國際 調整超時設定

Nginx 的 proxy_connect_timeout、proxy_read_timeout、proxy_send_timeout 是常見調整點。例如： proxy_read_timeout 60s; 如果後端處理時間長，可以調大。但別太過，合理範圍內調整即可，避免無限等待佔用資源。

檢查DNS解析

阿里雲國際 如果上游服務用域名，確認 DNS 解析正確。用 dig example.com 或 nslookup example.com，看是否解析到正確 IP。如果 DNS 伺服器掛了，可以改用 public DNS，比如 8.8.8.8 或 1.1.1.1，臨時解決問題。

負載均衡調優

如果後端有多個伺服器，檢查負載均衡設定是否均勻。Nginx 的 upstream 可以設定權重或健康檢查，確保流量分配合理。例如： server 192.168.1.100:8080 weight=3;，讓某台伺服器承擔更多流量，但要確保它能扛得住。

預防措施：讓502「無處可逃」

監控告警要及時

用 Prometheus + Grafana 或 Zabbix 監控伺服器狀態。設定關鍵指標告警，比如 CPU >90%、記憶體 <10%、服務宕機。當問題剛出現時就收到通知，及早處理，避免變成 502 嚴重問題。另外，Nginx 自帶的狀態模組也可以監控，例如 stub_status 指令。

定期巡檢，防微杜漸

每週檢查日誌，清理無用檔案，更新系統和軟體。定期做壓力測試，模擬高流量情況下系統表現。比如用 ab -n 1000 -c 100 http://your-site.com/ 測試承載能力，確保系統穩定。另外，設定自動化腳本，定期重啟服務（但不是盲目重啟），例如每晚 2 點重啟 PHP-FPM，避免記憶體洩漏導致崩潰。

備份與災難恢復計畫

備份所有設定檔，尤其是 Nginx 和服務配置。當問題發生時，快速回滾到正常版本。同時，制定災難恢復計畫，例如：當 502 發生時，第一時間切換到備份伺服器，或啟用負載均衡的備用節點。雲端服務可用多可用區部署，確保單點故障不影響整體服務。

總之，502 雖煩人，但只要系統化排查，根本不是問題。記住：冷靜、看日誌、一步步測試，問題終會解決。下次遇到 502，別急著砸鍵盤，先喝杯咖啡，慢慢來——你的專業級排查技巧，此刻正閃閃發光！