504 錯誤怎麼辦？一次搞懂 504 Gateway Timeout 原因與解決方法

你有沒有遇過這種情況，活動剛上線、廣告剛開跑、流量正衝高，畫面卻突然整片白底黑字：

504 Gateway Timeout

那種崩潰感真的會讓人血壓飆升。

其實 504 通常不是「網站壞掉」，而是「等太久等不到回應」。

尤其在高峰期，當流量暴增、第三方服務延遲、資料庫查詢變慢時，就很容易出現 504 Gateway Timeout。

這篇文章會帶你：

搞懂 504 是什麼

一步步定位是哪一層出問題

建立排障 SOP，避免下次再當無頭蒼蠅

如果你是網頁新手，或最近正被 504 搞到懷疑人生，這篇會很實用，記得收藏唷！

504 是什麼？用白話搞懂 504 Gateway Timeout

504 Gateway Timeout 是一種 HTTP 狀態碼。

意思是：

「網關（Gateway）或代理伺服器，在規定時間內，等不到上游伺服器回應。」

簡單說明請求流程：

使用者 → CDN / 反向代理 → 應用伺服器 → 資料庫

504 發生的位置，通常是「中間那層」在等待「後端」，但後端遲遲沒有回應。

504 常見原因有哪些？最容易踩到的 7 種情境一次看

當你看到 504 Gateway Timeout，先不要急著怪主機商。

多數時候，它其實是在告訴你：「後端某一段卡住了。」

以下是最常見導致 504 的幾種原因：

上游伺服器處理太慢（最常見）

這是 504 的頭號兇手。

所謂「上游伺服器」，指的是在 CDN 或反向代理後面的應用伺服器。

如果它處理請求太慢（例如超過 30 秒），前面的網關等不到回應，就會直接回傳 504。

常見原因包括：

流量突然暴增

伺服器 CPU 滿載

程式進入無限迴圈

I/O 操作卡住

愛立歐小提醒：

簡單來說，就是「車子塞住了」，前面的人等太久，只好宣布逾時。

資料庫慢查詢或鎖表

很多 504 問題，其實根本不是網站壞掉，而是資料庫在拖後腿。

例如：

沒加索引的大型查詢

一次撈幾十萬筆資料

資料表被鎖住

連線池滿了

當資料庫回應變慢，應用程式就會卡住，最後導致 504。

愛立歐小提醒：

這種情況在高峰期特別容易發生唷！

應用程式執行緒耗盡

每個應用程式都有「處理名額」。

如果同時間太多人進來：

執行緒池滿了

佇列堆積

worker 不夠

新的請求就只能排隊。

排太久，前面的代理層等不到，就出現 504。

愛立歐小提醒：

這種問題常見於沒有做流量控管的網站。

外部 API 回應卡死

現在很多網站都依賴第三方服務：

金流

物流

驗證 API

外部資料接口

如果第三方 API 變慢或沒有回應，而你的系統又沒有設計「降級機制」，整個請求就會被拖住。

結果不是 API 壞，而是你的網站跟著一起被拖垮。

這也是 504 的隱形地雷之一。

DNS 解析異常

有時候問題根本不在程式，而是在「找不到人」。

例如：

DNS 解析錯誤

TTL 設定不當

解析到舊 IP

跨區延遲過高

當代理層找不到正確的上游 IP，自然也等不到回應。

愛立歐小提醒：

這種問題常發生在搬主機或切流量時。

網路延遲或跨區問題

如果：

伺服器在國外

CDN 節點距離太遠

跨區傳輸延遲

封包丟失

都可能造成回應時間拉長。

愛立歐小提醒：

特別是多區架構或雲端跨區部署時，更要留意這點。

逾時（timeout）設定不一致

這是很多新手最容易忽略的問題。

假設：

CDN timeout 設 30 秒

Nginx 設 60 秒

App 設 90 秒

資料庫設 120 秒

那 30 秒就會先炸掉。

不是系統真的壞，而是前面等不及了。

愛立歐小提醒：

逾時值一定要「全鏈路對齊」，這是避免 504 的基本功。

504 怎麼排查？新手也能照做的分層定位流程

快速判斷：先區分哪一段超時

你可以把網站想成「接力賽」：

使用者的請求會一路從 邊緣層 → 應用層 → 資料層 → 外部依賴 跑完一圈，任何一段跑太慢，前面的人等不及，就回傳 504。

邊緣層（CDN / WAF / Nginx）：先看「門口」是不是卡住

邊緣層就是最靠近使用者的那一層，通常包含 CDN、WAF、防火牆、反向代理（例如 Nginx）。

這層出問題的特徵是：

你甚至還沒打到後端，前面就先說「我等不到」了。

你可以先檢查：

查看 CDN 日誌 / 防火牆事件：是否被擋、是否回應逾時

檢查 proxy timeout 設定：例如 proxy_read_timeout、proxy_connect_timeout

確認邊緣節點是否負載過高：高峰期特別容易發生（尤其活動、廣告剛開跑時）

愛立歐小提醒：

如果你用 Cloudflare 這類 CDN，很多時候錯誤其實會先出現在 CDN 的日誌或事件紀錄裡，別直接跳去看資料庫，會白忙一場。

應用層（App Server）：看「後端是不是忙到爆」

如果邊緣層沒問題，那下一步通常就是應用層（你的網站程式、API、後台服務）。

這層出問題的特徵是：

可以連到後端，但後端處理變超慢，慢到前面那層等不下去。

新手可以先看這三個重點：

APM 是否顯示 p95 / p99 延遲暴增？

代表大多數使用者還好，但「一部分請求」卡住（通常是某些功能或某些頁面特別慢）

Thread pool 是否耗盡？

很多框架都有執行緒池，如果池子滿了，新請求只能排隊，排到超時就 504

GC 是否頻繁？（Java / JVM 特別常見）

GC 變頻繁常意味記憶體壓力大，會造成整體回應抖動、延遲突然飆高

如果你看到「延遲突然拉高 + 錯誤率增加」，通常就是應用層塞車了。

資料層（Database）：最常被低估的「隱形拖油瓶」

很多 504 的根本原因，其實躲在資料庫裡。

資料庫一慢，後端就會等它，後端一等，反向代理就開始倒數計時，最後變成 504。

你要檢查的重點是：

是否出現慢查詢？（Slow Query Log）

是否鎖表？（Lock / Deadlock）

連線池是否滿載？ 連線池滿載通常會讓請求「卡在等連線」，不是你程式壞，是你根本拿不到資料庫門票

愛立歐小提醒：

如果 504 只發生在「特定頁面／特定功能」，非常高機率是那條路徑的 SQL 查詢在拖時間。

外部依賴：第三方 API 一慢，你網站就跟著一起慢

現在很多網站都不是自己一個人跑完流程，還會依賴第三方服務：

金流

物流

簡訊 / 驗證

外部資料 API

外部依賴的問題是：

不是你能控制的，但你必須有能力「承受它變慢」。

你可以檢查：

第三方 API 是否延遲？（對照你自己的請求時間）

是否沒有設計 retry 或熔斷？

沒有保護機制時，一旦外部卡住，你的 thread / connection 也會跟著被卡住，最後拖垮整個系統

這也是很多網站高峰期爆 504 的原因：不是你流量太大，是「第三方剛好也在塞車」。

最小可行排障流程（SOP）

如果你希望「有一套照做就不會走偏」的流程，下面這套是實務上很常用的 504 排查 SOP。

先穩定服務（先止血，別硬扛）

當下最重要的是：先讓使用者不要一直撞牆。

你可以做的快速止血手段包括：

開啟快取頁面：讓熱門頁先用快取撐住

降級非關鍵功能：例如暫停推薦系統、關閉非必要 API 呼叫

切換到備援節點：如果有多台或多區，先切流量

擴容實例：短期先把 CPU/RAM/節點數撐起來

愛立歐小提醒：

止血不是作弊，是爭取時間。很多事故就是一開始沒止血，後面越修越炸。

看關鍵指標（用數據決定你要查哪裡）

新手最常犯的錯是「沒看數據就開始改設定」。

建議你先看這幾個指標，快速判斷瓶頸在哪：

p95 / p99 延遲（是不是突然暴增）

錯誤率（是特定路徑爆？還是全面爆）

連線數（有沒有爆量）

Queue 長度（請求是不是在排隊）

CPU / RAM 使用率（是不是滿載）

看到「延遲暴增 + Queue 變長」通常就代表後端塞車了。

查日誌順序（照順序，別跳著看）

建議順序：

CDN / Nginx → 應用程式 Trace → 資料庫慢查詢 Log

這個順序的好處是：你會先確認「請求到底卡在哪一段」，再往裡面鑽。

真的不要跳著看，會超浪費時間，還可能誤判唷。

對齊逾時值（很多 504 其實是「設定打架」）

504 常見地雷是 timeout 設定不一致，例如：

CDN timeout 60 秒

Nginx timeout 30 秒

App timeout 90 秒

結果會變成：

代理層 30 秒就先斷線 → 直接回 504

即使後端 40 秒其實就會成功回來，也來不及了。

所以你要記得：timeout 必須全鏈路對齊（CDN / 代理 / App / DB / 外部 API），才不會某一段先斷。

加保護機制（把「一次事故」變成「可控風險」）

要讓 504 不再一直找上門，最後一定要做保護機制：

重試（Retry + 指數退避）：不要一秒狂打 10 次，會更炸

熔斷（Circuit Breaker）：第三方掛了就先暫停呼叫，避免拖垮自己

隔離資源池：把「關鍵路徑」跟「非關鍵路徑」分開，不要互相拖累

這些才是把 504 從根本變少的關鍵。

504 元兇對照表：Nginx、App、DB、外部 API 該怎麼解

Nginx upstream 逾時

Nginx 是站在前線的「守門員」。

如果後端（upstream）回應太慢，Nginx 等到 timeout 就會直接回 504。

常見原因

proxy timeout 設太短

upstream 節點數量不足

後端伺服器卡住

沒設健康檢查導致流量打到壞節點

如何解決

調整 timeout 設定

proxy_read_timeout 120s;

keepalive_timeout 65;

愛立歐小提醒：

拉長 timeout 只是緩衝，不是根治。

增加 upstream 節點

如果只有一台 App Server，流量一大就爆。

增加 upstream 節點可以分流壓力。

加入健康檢查

壞掉的節點要自動被排除。

否則流量會一直打到已經卡死的後端。

App 卡 I/O 或 CPU

應用層最常見的問題是：

同步處理太多事情

I/O 阻塞

CPU 滿載

worker 不夠

當應用層塞車，前面那層自然就等到 timeout。

如何解決

非同步處理

把耗時操作改成 async，避免主流程被卡住。

批次化處理

不要一筆一筆慢慢跑。

例如報表或資料更新，可以改成批次排程。

壓縮回應

大型 JSON 回應沒壓縮會拖時間。

開啟 gzip 或 brotli 可以明顯改善。

增加 worker 數量

如果 CPU 還有空間，可以增加 worker。

但注意：

不要盲目增加，否則可能導致 context switch 變多，反而更慢。

DB 慢查詢

資料庫其實是很多 504 的「幕後黑手」。

常見狀況

沒有索引

一次撈太多資料

鎖表

連線池滿載

應用程式其實沒壞，只是在等資料庫。

如何解決

加索引

慢查詢幾乎都能從索引改善。

分頁查詢

不要一次 SELECT 幾十萬筆資料。

重寫 SQL

有時候只是 SQL 寫法太差，EXPLAIN 一下就知道。

調整連線池上限

如果連線池太小，新請求會卡在「等連線」。

但也不要設太大，會把 DB 壓垮。

外部 API 不穩

你依賴的第三方服務：

金流

物流

驗證

外部資料 API

一旦變慢，你的 thread 就會被拖住。

如果沒有保護機制，很容易整站一起爆 504。

如何解決

本地快取

常用資料先快取，不要每次都打 API。

回傳預設值（降級）

例如：

推薦清單拿不到 → 顯示熱門商品

第三方資料失敗 → 回傳預設內容

不要讓整頁因為一個 API 壞掉。

加入 retry + timeout

設合理 timeout，不要無限等。

Retry 要搭配「指數退避」，避免瞬間打爆對方。

封包追蹤網路延遲

用 traceroute / tcpdump 看看是不是網路路徑出問題。

DNS 或網路問題

有時候不是系統慢，是「找不到正確的人」。

例如：

DNS 解析錯誤

TTL 設太長

切主機後還在指向舊 IP

跨區延遲高

如何解決

檢查 TTL

切流量或搬主機前，TTL 要先調低。

檢查跨區延遲

跨區部署要確認節點延遲是否合理。

固定 upstream IP

避免 DNS 解析不穩定造成隨機 timeout。

切流量測試

用部分流量測試新節點，不要一次全切。

504 設定範例整理：Node.js、Java、Cloudflare 常用做法

這一段我們會用「可直接拿去用」的方式整理：

你不一定要懂所有細節，但你至少要知道：timeout、retry、fallback 這三個東西是避免 504 的基本功，而且要「全鏈路一致」才有效唷。

Node.js HTTP client（Axios）：先把 timeout 設好，再談 retry

很多新手呼叫第三方 API 時，最常犯的錯是「不設 timeout」。

結果對方一慢，你的請求就一直卡著，卡到上游（Nginx / CDN）先斷線，最後變成 504。

設定 timeout（必要）

axios.get(url, {

timeout: 5000

})

timeout: 5000 代表 5 秒沒回應就放棄

不要讓請求「無限等待」，無限等待就是 504 的溫床

愛立歐小提醒：

timeout 不是越長越好，重點是「合理」，並搭配 fallback 或快取。

加入 retry 機制（建議）

axiosRetry(axios, { retries: 3 });

這代表：失敗時最多重試 3 次。

但要注意喔：retry 不是狂按重送，否則第三方本來只是慢，你會把它打到更慢。

更安全的做法是：

重試要加「間隔」

最好用「指數退避」（越重試越拉長間隔）

只針對「可重試」錯誤（例如網路抖動）重試

Java 連線池設定：避免「連線等不到」造成整串逾時

Java 專案常見的 504 問題，除了程式本身慢，還有一個很常被忽略的原因：

連線池用光了

你想像成餐廳座位：

座位（connection）滿了，客人（request）只能排隊，排到最後就超時。

連線池三個必看設定

maxPoolSize：最大連線數

設太小會排隊，設太大會把 DB / 外部服務壓垮

idleTimeout：閒置多久回收連線

避免長時間不用的連線佔著位置，造成浪費

fallback 機制：真的連不上時要怎麼回應

例如回傳快取、預設值或提示稍後再試

愛立歐小提醒：

Java 的連線池調整要搭配監控看「等待連線時間」與「連線使用率」，不然很容易越調越亂。

Cloudflare：先確認 Edge timeout 上限，再排除 WAF 與快取規則

如果你網站前面有用 Cloudflare（或其他 CDN），那 504 很可能不是你主機直接回的，而是 Edge（邊緣節點）等不到你後端。

檢查 Edge timeout 上限

每家 CDN 對「邊緣等待時間」都有上限。

如果你的後端回應時間超過上限，就算後端最後會成功，CDN 也會先回 504。

所以你要做的不是只拉長後端 timeout，而是：

確認 Cloudflare 的等待上限

優化後端回應速度（快取、查詢優化、拆解耗時任務）

必要時改成非同步流程（例如先回「已收到」再背景處理）

檢查是否被 WAF 擋住

有時候你看到的像 504，但實際是：

WAF 規則誤判

Bot 防護擋到正常流量

特定國家/ASN 被封

建議你看：

Cloudflare Security Events

Firewall/WAF logs

確認是不是被攔截或挑戰（challenge）造成請求延遲。

測試 bypass cache（排除快取規則干擾）

如果你懷疑快取規則、頁面規則或特定路徑的設定有問題，可以先做「旁路測試」：

暫時對該路徑關閉快取或改規則

測試是否仍會 504

釐清是「快取層」問題，還是「後端回應」問題

504 常見問題 FAQ：你最常卡住的點，這裡一次解答

504 Gateway Timeout 是什麼意思？

504 是一種 HTTP 狀態碼，代表「閘道（Gateway）等不到上游伺服器（upstream server）回應」。

白話來說就是：

中間那層（CDN / Nginx）在等後端，但後端太慢或沒回應，時間到了就回傳 504。

通常不是使用者網路問題，而是伺服器端或架構問題。

504 是不是代表主機壞掉了？

不一定。

504 多半代表：

主機太忙

資料庫太慢

外部 API 卡住

Timeout 設定不一致

很多時候只是流量暴增或某個查詢變慢，不是整台主機掛掉。

臨時出現 504，我可以怎麼快速處理？

優先順序建議這樣做：

1. 先開啟快取頁面

2. 降級非關鍵功能

3. 切換到備援節點

4. 臨時擴容主機

先止血，再慢慢排查，不要一開始就亂改設定。

為什麼 504 常在流量高峰出現？

因為高峰時：

CPU / 記憶體吃滿

Thread pool 耗盡

連線池爆滿

第三方 API 同時塞車

平時看不出來的效能瓶頸，在高峰就會被放大。

這也是為什麼壓力測試很重要。

504 只在特定頁面發生，該怎麼查？

通常是該頁面：

SQL 查詢特別慢

呼叫特定外部 API

Feature Flag 差異

某次部署版本改動

建議：

用 Trace ID 鎖定該路徑

對照慢查詢 log

檢查該路徑依賴的服務

504 會影響 SEO 嗎？

會，而且影響很大。

如果 Google 爬蟲多次遇到 504：

網頁可能暫時被降權

索引會減少

排名下滑

搜尋引擎會認為網站不穩定。

穩定性其實就是 SEO 的基礎分數。

504要怎麼從根本避免？

記住這幾個原則：

全鏈路 timeout 對齊

高峰前壓測與快取預熱

慢查詢優化

外部 API 加保護機制

監控 p95 / p99 延遲

事後檢討

504 不是偶發 bug，而是架構健康度的警訊。

遇到 504 Gateway Timeout：

第一步，穩定服務

第二步，用數據定位瓶頸

第三步，從架構與設定消除根因

不要只改 timeout，那只是延後爆炸時間而已。

如果你發現 504 一直反覆發生，很可能是網站架構、伺服器配置或效能設計本身就有問題。

這時候，找專業團隊協助會更有效率。

如果你希望：

幫你的團隊建立 504 排障 SOP

客製 Nginx / Node / Java 設定範例

優化網站架構避免高峰炸裂

提升整體網站穩定度與 SEO 表現

可以直接聯繫 愛立歐網路。

我們專注於高穩定網站架構與效能優化的網頁設計服務，協助企業打造能撐住流量高峰的網站。

👉 現在就預約 愛立歐網頁設計 諮詢，讓網站穩定成為你的競爭優勢。