Nginx + PHP-FPM 504 Gateway Time-out 根因排查與解決實戰

Nginx + PHP-FPM 504 Gateway Time-out 根因排查與解決實戰

504 Gateway Time-out 是 Web 運維高頻故障，盲目調整 Nginx/PHP-FPM 超時參數往往治標不治本。本文分享從「調參數」轉向「查慢日誌」的精準定位思路，直擊業務代碼層面的性能瓶頸。

常見誤區：只調配置不查代碼

• 調大 nginx.conf 中 fastcgi_read_timeout、proxy_read_timeout
• 調大 php-fpm.conf 中 request_terminate_timeout
• 若非全站 504，上述調整多無效，因為瓶頸在特定業務邏輯執行耗時過長。

核心定位手段：開啟 PHP-FPM 慢日誌

配置啟用

; php-fpm.conf 或 pool 配置
request_slowlog_timeout = 5s  ; 超過 5 秒記錄慢日誌，0 為關閉
slowlog = /var/log/php-fpm.slow.log

日誌分析示例

慢日誌會記錄完整 PHP 調用堆棧，例如：

[15-Jan-2017 10:30:45]  [pool www] pid 12345
script_filename = /var/www/html/api/order.php
[0x00007f8b1c05e8a0] mysqli_query() /var/www/html/lib/db.php:128
[0x00007f8b1c05e720] query() /var/www/html/service/order.php:45
[0x00007f8b1c05e5a0] getOrderList() /var/www/html/api/order.php:22

直觀定位到 mysqli_query() 在 db.php:128 執行緩慢，進而排查 SQL 執行計劃、索引缺失或鎖等待。

實戰建議

1. 非全站 504 時，優先開啟慢日誌定位具體接口/方法，而非全局調大超時。
2. 生產環境慎用：慢日誌會增加 I/O 開銷，建議設置合理閾值（如 3-5s），排查後及時關閉或調高閾值。
3. 結合 Xdebug/Blackfire：複雜調用鏈可配合性能分析器做火焰圖分析。
4. 檢查下游依賴：慢日誌指向 RPC/DB/外部 API 調用時，需進一步排查下游服務健康狀態。

總結

504 本質是上游等待下游響應超時。調大超時只是緩兵之計，通過 PHP-FPM 慢日誌直達代碼層面，才能從根上解決性能瓶頸，實現系統穩定性持續提升。