返回列表

騰訊雲帳號安全認證網站 502 Bad Gateway 快速排查

騰訊雲國際 / 2026-05-14 23:18:59

502 Bad Gateway是什麼？先別慌！

當你打開網站，突然蹦出「502 Bad Gateway」的頁面，腦袋可能瞬間一片空白：「我沒動過伺服器啊！怎麼就崩了？」別急，502就像你家的Wi-Fi突然斷了——可能只是路由器重開一下就好，也可能需要叫維修工。但別慌，我們一步步來，用「偵探式」思維找出原因！

簡單說，502錯誤是「網關錯誤」，通常發生在Nginx或Apache等反向代理伺服器，無法從後端服務（如PHP-FPM、Node.js、Tomcat）取得有效回應。後端可能當機、網路斷掉、配置錯誤，或者連線超時。關鍵在於：先找到「誰不回應」。

常見原因速查表

502的元兇通常有以下幾種：

後端服務掛了：例如PHP-FPM崩潰、Tomcat沒啟動，或者Node.js應用崩掉。
Nginx配置錯誤：proxy_pass指向的IP或端口寫錯，upstream設定錯誤。
超時時間太短：後端處理慢，但Nginx等太久就報502。
防火牆攔截：比如雲端主機的安全組沒開口，或者本機防火牆封鎖了端口。
資源耗盡：CPU或記憶體用光，後端服務無法處理新請求。
DNS問題：如果proxy_pass用了域名，DNS解析失敗也會導致502。

別被這些原因嚇到！我們按步驟排查，就像破案一樣，先從簡單的開始。

快速排查步驟（實戰指南）

Step 1：檢查Nginx錯誤日誌——這是「犯罪現場」

首先，打開Nginx錯誤日誌，這是找出問題的第一手資料。路徑通常是/var/log/nginx/error.log，用以下命令快速查看：

tail -n 50 /var/log/nginx/error.log

重點看是否有這類關鍵字：

connect() failed (111: Connection refused)：後端服務沒開或端口錯誤。
upstream timed out：後端處理太久，Nginx等不及了。
no live upstreams：upstream配置的伺服器都掛了。

如果日誌裡什麼都沒有，可能是Nginx根本沒收到請求，這時檢查前端網路或防火牆。但90%的情況，日誌會給你明確的線索。

Step 2：確認後端服務是否活著

假設日誌顯示「Connection refused」，那後端服務可能沒運行。舉例：

PHP-FPM：輸入systemctl status php-fpm，如果顯示inactive (dead)，就重啟它：systemctl restart php-fpm。
Node.js應用：如果是用pm2管理，用pm2 list確認應用是否運行；若沒有，用pm2 start app.js重新啟動。
Tomcat：檢查systemctl status tomcat，或者直接用jps命令看Java程序是否在跑。

另外，用netstat確認後端端口是否在監聽。例如PHP-FPM預設9000端口：

netstat -tuln | grep 9000

如果沒看到LISTEN狀態，說明服務沒啟動，或者配置錯誤。這時要檢查PHP-FPM的配置檔（通常在/etc/php-fpm.d/www.conf），確保listen參數正確。

騰訊雲帳號安全認證 Step 3：檢查Nginx代理配置——別讓中間人「說錯話」

Nginx作為「中間人」，如果配置錯誤，就會傳錯話。打開Nginx配置檔（通常在/etc/nginx/conf.d/default.conf或/etc/nginx/nginx.conf），檢查以下幾點：

proxy_pass是否正確：例如proxy_pass http://localhost:8080;，確認IP和端口是否對。如果是域名，用dig example.com檢查DNS解析是否正確。
upstream設定：如果使用upstream模塊，確認所有server都正常。例如：
upstream backend { server 192.168.1.100:8080; server 192.168.1.101:8080; }
用curl http://192.168.1.100:8080測試每個後端IP是否能連接。

常見錯誤：把localhost寫成127.0.0.1，但實際上Nginx和後端服務不在同一台機器！或者後端改了端口，但Nginx沒同步更新。

Step 4：調整超時參數——給後端多點時間

有時候後端服務處理時間長（比如資料庫查詢慢），但Nginx預設只等60秒。這時可以調大超時時間，在Nginx配置中加入：

location / {
    proxy_connect_timeout 60s;
    proxy_read_timeout 120s;
    proxy_send_timeout 120s;
}

這裡proxy_read_timeout是關鍵，設定後端回應的最大等待時間。如果後端要2分鐘處理，就設120秒，避免Nginx誤判為超時。

修改後別忘了重啟Nginx：systemctl restart nginx。如果問題消失，恭喜！你成功「耐心等待」了後端服務。

騰訊雲帳號安全認證 Step 5：檢查防火牆和安全組——別讓門鎖住了

很多時候，502不是服務問題，而是「門沒開」。檢查兩層防火牆：

雲端主機的安全組：比如AWS EC2、阿里雲、GCP，確認入站規則允許80、443，以及後端服務的端口（如9000、8080）。
本機防火牆：如果是Ubuntu，用ufw status查看規則；如果是CentOS，用firewall-cmd --list-all。確保相關端口已開放。

例如，讓雲端主機放行80和443：
sudo ufw allow 80/tcp sudo ufw allow 443/tcp

如果用雲服務商的控制台，記得安全組要「入站規則」允許你的IP或0.0.0.0/0（注意安全風險）。

Step 6：監控資源使用率——別讓伺服器「累到吐」

資源不足也會導致502。用以下命令檢查：

top：看CPU和記憶體佔用率。如果CPU 100% 或記憶體耗盡，後端服務可能崩潰。
free -h：查看記憶體使用，如果available接近0，需要增加記憶體或優化應用。
df -h：檢查磁碟空間是否滿了，特別是/var/log目錄。

如果是PHP-FPM，檢查其進程池設定。例如pm.max_children過低，當併發量大時無法處理更多請求。調整參數後重啟PHP-FPM。

進階建議：用htop或nmon實時監控，或設定告警（如Prometheus+Alertmanager），在資源告急前預防問題。

真實案例分析：黑五促銷大崩盤

去年雙11，某電商網站突然出現大規模502錯誤，用戶狂罵。我們快速檢查：

Nginx日誌顯示upstream timed out，後端是PHP-FPM。
用top發現CPU佔用98%，記憶體也快沒了。
檢查PHP-FPM設定，pm.max_children只有50，但並發請求超過200。

解決方案：

立即調整pm.max_children到100，並增加記憶體限制（php_admin_value[memory_limit]）。
重啟PHP-FPM後，壓力測試確認可以處理更高併發。
後續啟用自動擴容，並在Nginx設定proxy_read_timeout 180s，給後端更多喘息空間。

從故障到恢復僅花20分鐘！關鍵在於快速定位「資源不足」這個根本原因，而非盲目重啟。

預防勝於治療：長期保養技巧

502頻繁發生？那就來點「養生」方法：

騰訊雲帳號安全認證 設定監控告警：用Zabbix、Prometheus監控伺服器狀態，當CPU、記憶體、磁碟空間異常時即時通知。
自動化重啟腳本：例如，若PHP-FPM崩潰，寫一個crontab腳本每5分鐘檢查一次，自動重啟。
負載均衡+冗餘：多台伺服器+負載均衡器（如Nginx upstream），單點故障時自動切換。
定期壓力測試：用ab或wrk模擬高流量，提前發現瓶頸。

記住：502不是「天災」，而是「人禍」！只要平時多注意，就能把問題扼殺在搖籃裡。下次再遇到502，你也能淡定地掏出這份指南，像個專業偵探一樣，一步步揪出真相！