LNMP 一鍵包 502 Bad Gateway 徹底解決方案：自動監控與重啟腳本實戰

使用 LNMP 架構一段時間後，最讓人頭疼的莫過於流量高峰期頻繁出現的「Nginx 502 Bad Gateway」錯誤。往往不是 PHP-FPM 進程掛了，就是 Nginx 自己崩潰了。網站多的時候根本無法逐一人工巡檢，往往等到發現時網站已經宕機一兩天，流量損失慘重。

這裡分享一套經過實戰驗證的自動化解決方案：通過定時腳本監控網站狀態，一旦檢測到非 200 狀態碼，立即自動重啟 LNMP 服務並發送郵件告警，讓你徹底告別手動搶修的疲憊。

核心思路

在網站根目錄建立一個極簡的探針文件，腳本定時請求該文件，若返回碼非 200，則判定服務異常，觸發重啟邏輯並發送告警郵件。

步驟一：建立探針文件

在網站根目錄（如 /home/wwwroot/default/）新建 test200.php，內容如下：

<?php
echo "200_OK";
?>

步驟二：編寫監控腳本

在 /root 目錄下建立 test200_monitor.sh：

vi /root/test200_monitor.sh

腳本內容（請根據實際路徑修改）：

#!/bin/bash
# 監控目標 URL，請替換為你的探針地址
wget https://www.yourdomain.com/test200.php --spider -q -T 10
c_monitor=$?

if [ $c_monitor -ne 0 ]; then
    # 記錄時間並發送告警郵件（需配置 mail 命令）
    echo "# Error: Non-200 status detected at $(date +"%Y-%m-%d %H:%M:%S"), restarting LNMP..." | mail -s "Critical: Website Offline" admin@yourdomain.com
    
    # 重啟 PHP-FPM（或根據你的 LNMP 版本調整為 /root/lnmp restart）
    /usr/local/php/sbin/php-fpm restart
    echo "Restarted php-fpm at $(date)"
fi

關鍵點說明：

• wget --spider 僅檢查頭部，不下載內容，輕量高效。
• $? 獲取上一條命令退出碼，0 代表成功（HTTP 200），非 0 代表失敗。
• 郵件發送需服務器安裝並配置好 mailx 或 sendmail。
• 重啟命令請根據實際安裝路徑調整，常見為 /etc/init.d/php-fpm restart 或 LNMP 一鍵包的 /root/lnmp restart。

步驟三：賦予執行權限

chmod +x /root/test200_monitor.sh

步驟四：配置定時任務

crontab -e

添加以下行，每 5 分鐘檢測一次：

*/5 * * * * /root/test200_monitor.sh > /dev/null 2>&1

進階方案：純 PHP 監控腳本（無需 Shell）

若不想寫 Shell，也可直接用 PHP + Cron 實現，同樣放在網站根目錄下，如 monitor.php：

<?php
$url = 'https://www.yourdomain.com';
$cmd = '/usr/local/php/sbin/php-fpm restart'; // 或 /root/lnmp restart

$exec = "curl --connect-timeout 5 -I $url 2>/dev/null";
$res = shell_exec($exec);

if (stripos($res, '502 Bad Gateway') !== false || stripos($res, '504 Gateway Time-out') !== false) {
    shell_exec($cmd);
    // 可選：寫入日誌或發送郵件
    error_log("[".date("Y-m-d H:i:s")."] 502 detected, restarted php-fpm\n", 3, "/var/log/lnmp_monitor.log");
    exit();
}
?>

然後在 crontab -e 中添加：

*/5 * * * * /usr/bin/php /home/wwwroot/default/monitor.php

避坑指南

1. 探針文件權限：確保 Web 服務器進程（如 www 用戶）可讀取 test200.php。
2. 郵件通道：生產環境建議配置 SMTP 郵件發送，避免本地 mail 進垃圾箱或被拒收。
3. 重啟命令驗證：先在終端手動執行重啟命令確認無誤，再寫入腳本。
4. 日誌留存：建議在腳本中追加寫入 /var/log/lnmp_monitor.log，便於事後複盤。
5. 誤觸發防護：可增加連續 2 次檢測失敗才重啟的邏輯，避免網絡抖動導致誤重啟。

總結

這套方案成本極低、部署簡單，卻能有效解決 LNMP 架構下 502 錯誤的「最後一公里」問題。配合日誌分析與郵件告警，實現「睡覺時服務器也在自我修復」。對於中小型項目、個人站長或缺乏運維團隊的場景，是性價比極高的自動化運維手段。

現在，你可以放心去忙別的了——LNMP 的 502 錯誤，已經有了「自動駕駛」。