2026-10-30 · 技術
502 是上游返回了無效響應，504 是等上游超時，兩者指向的問題完全不同。本文按客戶端、CDN、反向代理、應用、資料庫這條鏈路給出排查順序，幫你十分鐘內定位到具體環節。
網站突然報 502 或 504，很多人的第一反應是重啟服務，重啟後好了，過一會兒又出現。這兩個錯誤碼看著像，指向的問題卻不一樣：502 是閘道器收到了上游的無效響應，通常意味著後端程序掛了、崩了或者拒絕了連線；504 是閘道器等上游響應超時，後端還活著，但處理太慢或者根本沒處理完。 排查要按鏈路走，從外到內，一層層排除。 第一步，看錯誤頁面是誰返回的。頁面上如果帶 CDN 的標識，說明請求在邊緣節點就沒拿到源站響應；如果是自己配置的錯誤頁，說明請求已經到源站了。這一步能直接砍掉一半的排查範圍。 第二步，繞過 CDN 直連源站。用 hosts 繫結源站 IP 訪問，如果直連正常、走 CDN 異常，問題在回源鏈路或節點；如果直連也報錯，問題在源站內部。 第三步，看反向代理的錯誤日誌。502 通常伴隨 upstream prematurely closed connection 或 connection refused，前者多半是後端程序崩潰或被 OOM 殺掉，後者是後端沒在監聽埠。504 則多是 upstream timed out，說明請求發出去了但沒等到回應。 第四步，看應用程序和慢日誌。PHP 看程序池是否被佔滿、有沒有卡在外部請求上；Java 看執行緒池、GC 日誌和 Full GC 頻率；Node 看事件迴圈是否被阻塞。這一層最常見的原因是某個介面呼叫了沒設超時的外部服務，把工作程序全拖住了。 第五步，看資料庫。連線池被打滿、慢查詢堆積、鎖等待，都會讓應用層表現為超時。這一層的特點是錯誤只在特定頁面出現，而不是全站。 第六步，看資源和頻寬。CPU 打滿、記憶體吃緊觸發 OOM、頻寬跑滿導致丟包，也會造成大量 504。如果是整點或固定時間出現，還要懷疑備份、定時任務、日誌切割這類瞬時 IO 壓力。 最後區分偶發和全站。偶發且集中在某個介面，往應用和資料庫查；全站同時出現，優先看頻寬、連線數和反向代理本身。 加速IDC 提供雲伺服器和物理伺服器，標配頻寬與流量監控，遇到這類問題可以協助定位是資源不足還是鏈路異常。
