PHP-FPM 502 Bad Gateway 根因分析與自動重啟腳本方案

解決 Nginx + PHP-FPM 頻繁 502 錯誤的實戰方案

502 Bad Gateway 通常意味著 Nginx 無法從上游獲取有效回應。PHP-FPM 常見原因包括：進程耗盡、請求阻塞、記憶體洩漏、僵屍進程、配置不當。本文提供診斷思路與自動化恢復腳本。

常見原因排查

• pm.max_children 不足：高併發時進程池耗盡，新請求排隊超時
• 請求執行過慢：request_terminate_timeout 觸發殺死進程
• 記憶體洩漏：長期運行導致記憶體耗盡，觸發 OOM Killer
• 僵屍進程：主進程存活但 Worker 無響應（accept() 閒置）
• Nginx 緩衝區過小：fastcgi_buffers 導致大回應截斷

方案一：進程存在性檢查（針對進程意外退出）

#!/bin/bash
# restart-php-fpm-v1.sh
SERVICE="php-fpm"
if netstat -anp | grep -q ":9000"; then
    echo "$SERVICE 運行正常"
else
    echo "$SERVICE 未運行，嘗試重啟"
    systemctl restart php-fpm
fi

方案二：HTTP 健康檢查（針對僵屍進程/阻塞）

#!/bin/bash
# restart-php-fpm-v2.sh
MY_URL="https://your-domain.com"
RESULT=$(curl -I -s -o /dev/null -w "%{http_code}" "$MY_URL" --max-time 10)

if [[ "$RESULT" == "502" ]]; then
    echo "檢測到 502，強制重啟 PHP-FPM"
    killall -9 php-fpm 2>/dev/null
    systemctl restart php-fpm
    # 可選：發送告警通知
    # curl -X POST "https://hooks.slack.com/..." -d '{"text":"PHP-FPM 自動重啟"}'
fi

部署為定時任務

chmod +x restart-php-fpm-v2.sh
# 每分鐘檢查一次
echo "* * * * * /path/to/restart-php-fpm-v2.sh >> /var/log/php-fpm-watchdog.log 2>&1" | crontab -

進階優化建議

1. 調整 PHP-FPM 配置（/etc/php-fpm.d/www.conf）：

   pm = dynamic
   pm.max_children = 100          # 依記憶體計算：總記憶體 / 單進程記憶體
   pm.start_servers = 20
   pm.min_spare_servers = 10
   pm.max_spare_servers = 30
   pm.max_requests = 500          # 重生進程防洩漏
   request_terminate_timeout = 60s
   rlimit_files = 65535

2. 啟用慢日誌：

   slowlog = /var/log/php-fpm/slow.log
   request_slowlog_timeout = 5s

3. 監控指標：整合 Prometheus + Grafana 監控 php-fpm_exporter 指標
4. Nginx 配置優化：

   fastcgi_buffers 8 16k;
   fastcgi_buffer_size 32k;
   fastcgi_connect_timeout 60s;
   fastcgi_send_timeout 60s;
   fastcgi_read_timeout 60s;

總結

自動重啟是治標手段，根治需從配置優化、代碼效能、資源監控三方面入手。建議建立完整觀測體系，而非單純依賴重啟腳本。