Nginx 504 Gateway Time-out 徹底解決方案：fastcgi 參數調優與 php-fpm 核心配置實戰

現象與誤區

DedeCMS 欄目超 2000 篇文章，生成列表頁出現 504 Gateway Time-out。伺服器 Nginx，維護人員隨意改緩存設定無效。本地複現：Nginx 能全量生成但報 504；Apache 更誇張，生成 83 頁即卡死。最終找到有效方案，記錄備查。

錯誤碼本質區分

實戰鐵律：需綜合考慮伺服器性能與訪客量，雙配置同調。

實戰環境基線

• CPU：奔騰 4 1.5GHz
• 記憶體：1GB
• OS：CentOS
• 併發：~50 人同時在線，大量請求 PHP-CGI 處理複雜邏輯

nginx.conf 關鍵調優 (解決 504 核心)

fastcgi_connect_timeout 300s;
fastcgi_send_timeout 300s;
fastcgi_read_timeout 300s;
fastcgi_buffer_size 128k;
fastcgi_buffers 8 128k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on;

前三條是核心：規定 PHP-CGI 連接/發送/讀取最長 300 秒，足夠覆蓋長時間腳本執行，極大降低 504 發生率。

php-fpm.conf 兩大核心參數深度解析 (防 502 兼顧 504)

1. request_terminate_timeout

• 若伺服器性能夠好、頻寬充足、PHP 無死循環/BUG → 設 0s (無時間限制，PHP-CGI 永不超時)。
• 現實多有 BUG/頻寬不足/其他原因導致 PHP-CGI 假死 → 必須賦值。性能越好可設越高 (20-30 分鐘)。
  實戰設定：900s (15 分鐘) — 覆蓋長時間生成任務，避免 PHP-CGI 被殺產生 502。

2. max_children

• 原則：越大越好 (進程多 → 處理快 → 排隊少)。
• 計算法：單 php-cgi 進程佔記憶體 ~20MB。
  實戰設定：40 → 峰值總佔用 800MB (< 1GB 物理記憶體)。
• 若設過小 (5-10) → php-cgi 「很累」處理慢 → 排隊久 → 504；正在處理的累進程遇問題 → 502。

綜合調優檢查清單

1. 確認 Nginx 與 PHP-FPM 通訊方式：Unix Socket (同機) vs TCP (分離) — Socket 性能更高。
2. 啟用 PHP OpCache (生產環境必開) — 大幅降低編譯開銷。
3. DedeCMS 層面：生成靜態頁面時分批次、增加延遲、優化 SQL 查詢、關閉不必要插件。
4. 監控告警：netstat -an | grep :9000 觀察 PHP-FPM 連接數；pm.status_path 監控進程池狀態。
5. 壓測驗證：ab -n 1000 -c 50 模擬併發，觀察 502/504 率、響應時間分佈。

避坑指南

• 盲目增大 max_children 導致 OOM Killer 殺進程 → 更災難性後果。
• 設 request_terminate_timeout 0 卻有 BUG 代碼 → 掛死進程佔滿槽位 → 服務癱瘓。
• 忽略 fastcgi_buffer 參數 → 大響應體導致臨時檔頻繁讀寫 → 性能抖動。
• 未區分 502/504 成因，單調單配置 → 治標不治本。

結語

Nginx 504 本質是「等不到 PHP-CGI」。雙軌調優：Nginx 端給足等待時間 (300s)、緩衝區優化；PHP-FPM 端給足進程池 (max_children 依記憶體算)、給足單進程執行上限 (request_terminate_timeout 依業務最長耗時算)。在有限硬體上跑重業務，核心是精準計算資源上限、留足安全邊際、建立觀測閉環。