502 Bad Gateway

---

nginx ：nginx伺服器常見錯誤的深入解析與解決之道

遇上「502 Bad Gateway」，網站瞬間打烊？別慌！

相信不少網站經營者、網管人員，甚至是一般使用者，都曾經在瀏覽網頁時，被一個簡潔卻令人頭痛的錯誤訊息給打斷：「502 Bad Gateway」。這個錯誤，通常伴隨著「nginx」的字樣，就像是網站突然按下「暫停鍵」，讓你摸不著頭緒。別擔心，你不是孤單一人！今天，我們就要來好好地深入剖析這個「502 Bad Gateway」到底是什麼，以及為什麼會跟 nginx 這個強大的網頁伺服器軟體扯上邊，更重要的是，我會一步一步帶你找出解決問題的關鍵。

什麼是「502 Bad Gateway」？

簡單來說，「502 Bad Gateway」是一個 HTTP 狀態碼，它代表著網頁伺服器（在這裡主要是 nginx）在嘗試處理你的請求時，從上游伺服器（也就是負責實際處理你請求的伺服器，可能是應用程式伺服器、API 閘道器等）收到了無效的回應。想像一下，你點了一個餐，服務生（nginx）去廚房（上游伺服器）幫你拿餐點，結果廚房送回來的不是你點的菜，而是個「壞掉的包裹」，服務生也沒辦法交給你，只好無奈地跟你說「502 Bad Gateway」。

這個錯誤訊息中的「nginx」，則明確地指出了，在你與網頁之間的這道防線，是由 nginx 這個廣泛使用的網頁伺服器軟體所負責。nginx 的強大之處在於它的高效能、高併發處理能力，常被用來作為反向代理（Reverse Proxy）、負載平衡器（Load Balancer），或是靜態檔案伺服器。也正因為它經常扮演「中間人」的角色，所以當上游伺服器出狀況時，nginx 就會第一時間接收到這個錯誤，並回報給使用者。

為什麼nginx會出現「502 Bad Gateway」？

造成「502 Bad Gateway」的原因百百種，但我們可以從幾個常見的面向來深入探討。畢竟，了解根本原因，才能對症下藥，讓你的網站重回正軌。

1. 上游伺服器（應用程式伺服器）問題

這是最常見也最直接的原因。nginx 本身可能運作正常，但它所依賴的上游伺服器出了狀況，導致無法正常回應。這又可以細分為：

• 應用程式崩潰或無回應： 運行網站後端的應用程式（例如 PHP、Python、Node.js 應用程式）可能因為程式碼錯誤、記憶體洩漏、過載等原因而崩潰，或者完全沒有回應。nginx 嘗試連接時，自然收不到有效的數據。
• 伺服器資源耗盡： 上游伺服器可能因為 CPU、記憶體、磁碟 I/O 或網路帶寬等資源被大量佔用，導致無法及時處理請求。
• 資料庫連接問題： 如果應用程式需要與資料庫互動，而資料庫伺服器出現問題（例如離線、延遲過高、連接數爆滿），也會間接導致上游伺服器無法提供有效回應。
• API 服務異常： 如果你的網站依賴外部 API 服務，而這些 API 服務出現了問題，也會反映在你的網站上，造成 502 錯誤。

2. Nginx 設定或網路配置問題

雖然 nginx 本身是穩定可靠的，但有時候錯誤的設定或網路的配置也可能引發 502 錯誤。

• 上游伺服器地址或端口錯誤： Nginx 的設定檔（通常是 `nginx.conf` 或 `conf.d` 目錄下的檔案）中，用於指定上游伺服器地址（`proxy_pass` 指令）或端口號可能設定錯誤，導致 nginx 無法連接到正確的上游伺服器。
• 防火牆阻止： 伺服器之間的防火牆設定，或者雲端服務提供商的網路安全群組，可能錯誤地阻止了 nginx 與上游伺服器之間的通訊。
• DNS 解析問題： 如果你的上游伺服器是透過域名訪問，而 DNS 解析出現問題，nginx 就無法找到正確的 IP 地址。
• 超時設定過短： Nginx 的 `proxy_connect_timeout`、`proxy_send_timeout`、`proxy_read_timeout` 等參數，如果設定得過於嚴苛，當上游伺服器處理請求時間稍長時，nginx 就會提前斷開連接，導致 502 錯誤。

3. 伺服器負載過大

當伺服器同時面臨著遠超其處理能力的流量時，無論是 nginx 本身還是上游伺服器，都可能不堪重負而出現各種錯誤，其中就包括 502 Bad Gateway。

• 突發流量： 網站突然湧入大量訪客，例如在促銷活動、熱點新聞事件發生時。
• DDoS 攻擊： 分散式阻斷服務攻擊，惡意地讓大量無效請求淹沒伺服器，使其無法正常服務。

4. Nginx 本身問題（較少見）

雖然相對少見，但 nginx 本身也可能因為 Bug、版本衝突，或是在特定高負載情境下出現異常。不過，這通常需要更深入的系統級別排查。

如何系統性地排查與解決「502 Bad Gateway」？

當你遇上這個惱人的錯誤時，別急著砸電腦！一個有條理的排查過程，能幫助你快速找到問題癥結。以下我將分享一套系統性的解決步驟，希望能讓你不再束手無策。

步驟一：觀察與確認錯誤範圍

首先，你需要了解這個錯誤是只發生在你一個人身上，還是普遍性的。

• 清空瀏覽器快取與 Cookie： 有時候，瀏覽器快取的問題也會誤導判斷。嘗試清除瀏覽器快取和 Cookie 後重新載入網頁。
• 使用不同瀏覽器或裝置： 嘗試用不同的瀏覽器（Chrome, Firefox, Safari 等）或裝置（手機、平板）訪問網站，看看是否還有同樣的問題。
• 匿名模式（無痕模式）： 在瀏覽器的無痕模式下訪問，排除瀏覽器擴充功能或設定的干擾。
• 檢查其他網站： 看看你是否能正常訪問其他網站，排除你的網路連接本身的問題。
• 詢問其他人： 如果可能，詢問你團隊的成員或身邊的人，是否也遇到相同的錯誤。

如果只有你一個人遇到，那問題很可能出在你自己的電腦、網路或瀏覽器上。但如果大家也遇到，那問題就出在伺服器端了！

步驟二：檢查伺服器日誌（Log Files）

伺服器日誌是解決伺服器問題的「偵探眼睛」，裡面記錄了伺服器運行的所有蛛絲馬跡。對於 nginx 來說，我們主要需要關注以下兩個檔案：

• Nginx 錯誤日誌 (Error Log)：
  • 預設路徑通常在 `/var/log/nginx/error.log`。
  • 在這個檔案中，你可以找到關於 nginx 處理請求時發生的錯誤訊息。尋找與「502」相關的關鍵字，或是關於「connect() failed」、「upstream prematurely closed connection」等訊息，它們通常會指向是哪個上游伺服器出了問題，或是連接被中斷的原因。
• Nginx 訪問日誌 (Access Log)：
  • 預設路徑通常在 `/var/log/nginx/access.log`。
  • 雖然主要記錄成功的訪問，但有時也能提供請求的上下文資訊，例如請求的時間、請求的 URL 等。
• 應用程式伺服器日誌：
  • 這取決於你使用的應用程式框架和語言。例如，PHP-FPM 的日誌通常在 `/var/log/phpX.Y-fpm.log`（X.Y 為 PHP 版本），Node.js 或 Python 應用程式則有各自的日誌記錄方式。
  • 這些日誌能提供應用程式本身崩潰、錯誤處理的詳細訊息。

舉例來說： 你可能會在 nginx 的 error.log 中看到類似以下的訊息：

[emerg] 12345#0: bind() to 0.0.0.0:80 failed (98: Address already in use)

或者，更常見的與 502 相關的訊息：

[crit] 6543#0: 1 connect() to 127.0.0.1:8080 failed (111: Connection refused) while connecting to upstream, client: 192.168.1.100, server: example.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8080/"

這就明確告訴我們，nginx 嘗試連接上游伺服器 127.0.0.1 的 8080 端口時失敗了，原因可能是對方拒絕連接。

步驟三：檢查上游伺服器狀態

既然 502 錯誤多半源於上游伺服器，那我們就得把焦點放在它身上。

• 確認上游伺服器是否正在運行：
  • 如果你使用的是像 PHP-FPM 這樣的進程管理器，可以檢查它的狀態。例如，在 CentOS/Ubuntu 系統中，可以使用 `systemctl status php-fpm` 來查看。
  • 對於 Node.js、Python 等應用程式，通常會使用 PM2、Supervisor 等進程管理器來監控，檢查這些管理器的日誌和運行狀態。
  • 如果是一個獨立的應用程式伺服器，可以嘗試直接通過其端口（例如上面的範例中的 8080）進行連接測試。可以使用 `telnet` 或 `nc` (netcat) 命令：telnet 127.0.0.1 8080。如果連接失敗，就說明上游伺服器沒有在監聽該端口，或者被防火牆擋住了。
• 檢查上游伺服器的日誌： 如前所述，務必仔細查看應用程式伺服器自身的日誌，尋找任何錯誤或崩潰的跡象。
• 檢查伺服器資源：
  • 登入伺服器，使用 `top`、`htop`、`free -m`、`df -h` 等命令，檢查 CPU 使用率、記憶體佔用、磁碟空間等，確保沒有資源耗盡的情況。
• 檢查資料庫連接： 如果你的應用程式依賴資料庫，確保資料庫伺服器運行正常，並且應用程式能成功連接。

步驟四：檢查 Nginx 設定檔

nginx 的設定檔是整個架構的「指揮中心」，任何微小的錯誤都可能導致嚴重的後果。

• 檢查 `proxy_pass` 指令：
  • 在你的 nginx 設定檔（通常是 `/etc/nginx/nginx.conf`，或者 `/etc/nginx/conf.d/your_site.conf`）中，找到 `location` 區塊，檢查 `proxy_pass` 指令指向的上游伺服器地址和端口是否正確。
  • 確認格式無誤，例如 `proxy_pass http://127.0.0.1:8080;` 或 `proxy_pass http://your_upstream_server_name;`。
• 檢查 `upstream` 區塊（如果有的話）：
  • 如果你的設定檔中有 `upstream` 區塊來定義一個伺服器池，請確保其中列出的伺服器地址和端口是正確的，並且它們確實都在運行。
• 測試設定檔語法： 在修改 nginx 設定檔後，務必執行測試命令，確保語法沒有錯誤，才重新載入 nginx。
  sudo nginx -t
  如果顯示 `syntax is ok` 和 `test is successful`，就可以安心重載。
• 重載 Nginx： 執行重載命令，讓新的設定生效。
  sudo systemctl reload nginx （推薦使用 systemctl，更現代化）
  或 sudo service nginx reload

步驟五：檢查防火牆與網路

有時候，防火牆就像一道無形的牆，阻礙了 nginx 和上游伺服器之間的溝通。

• 檢查伺服器防火牆：
  • 如果你使用的是 `ufw` (Uncomplicated Firewall)，可以使用 `sudo ufw status` 查看規則。確保允許 nginx 和上游伺服器之間的通訊端口開放。
  • 如果是 `firewalld`，使用 `sudo firewall-cmd --list-all`。
  • 對於 `iptables`，則需要更詳細的查詢。
• 檢查雲端防火牆/安全群組： 如果你的伺服器託管在 AWS (EC2)、Google Cloud、Azure 或其他雲端平台上，請務必檢查相應的「安全群組」或「網路規則」，確保允許 nginx 伺服器與上游伺服器之間的通訊。
• 測試網路連通性： 從 nginx 伺服器上，嘗試 `ping` 或 `telnet` 上游伺服器的 IP 地址和端口，確認網路是通暢的。

步驟六：考慮負載與連結數

如果以上步驟都無法找到明顯問題，那就要考慮伺服器負載和連線數的限制。

• 檢查伺服器負載： 如步驟三所述，持續監控伺服器資源。如果資源經常滿載，可能需要考慮升級伺服器配置、優化應用程式效能，或者使用負載平衡器分散流量。
• 檢查應用程式最大連接數： 某些應用程式伺服器或資料庫有最大連接數的限制。如果請求量過大，超出限制，就可能導致請求被拒絕。
• Nginx 的 `worker_connections`： Nginx 的 `worker_connections` 參數決定了每個 worker 處理的最大連接數。如果這個值設定得過低，在極端高流量下也可能成為瓶頸。

常見的 502 Bad Gateway 相關問題解析

在實際處理問題的過程中，我遇到過不少客戶提出類似的疑問，這裡我整理了一些常見問題，並進行詳細的解答，希望能幫助大家更全面地理解這個錯誤。

Q1：為什麼我的網站有時候正常，有時候卻出現 502 Bad Gateway？

A1：這種間歇性的錯誤，通常指向了資源耗盡或偶發性的應用程式問題。當伺服器負載達到閾值時，應用程式可能就無法及時回應，導致 nginx 出現 502。這就像一個餐廳，平時客人不多時服務周到，但一到用餐尖峰時段，廚房忙不過來，服務員也手忙腳亂，就容易出錯。
您可以這樣排查：

1. 嚴密監控伺服器資源： 尤其是 CPU 和記憶體。使用 `top` 或 `htop` 持續觀察，找出負載高峰期的觸發原因。
2. 分析應用程式日誌： 尋找在出現 502 的時間點，應用程式日誌中是否有報錯，例如記憶體不足、調用超時等。
3. 檢查定時任務： 有些定時任務（cron jobs）可能會在特定時間運行，消耗大量資源。檢查這些任務的執行情況。
4. 優化應用程式效能： 如果發現應用程式在處理特定請求時效能低下，需要進行程式碼優化，例如查詢慢、循環冗長等。
5. 考慮緩存機制： 對於不經常變動的數據，引入緩存層（如 Redis, Memcached）可以大大減輕後端壓力。

Q2：我更新了網站的程式碼後，就一直出現 502 Bad Gateway，該怎麼辦？

A2：這幾乎可以肯定是程式碼本身的問題。新的程式碼可能存在 Bug，導致應用程式崩潰或進入無限迴 loop，無法正常向 nginx 回應。
請您立即執行以下步驟：

1. 立即回滾程式碼： 如果可能，盡快將網站恢復到更新前的版本，確保網站能先正常運行。
2. 仔細檢查更新的程式碼：
   • 重點查看新增或修改的部分，是否有語法錯誤、邏輯錯誤。
   • 特別注意與數據庫互動、外部 API 調用、檔案讀寫等操作，這些地方容易出現問題。
3. 在測試環境中徹底測試： 在將程式碼部署到正式環境之前，務必確保在與正式環境相似的測試環境中進行過充分的測試，包括壓力測試。
4. 調試應用程式日誌： 即使在測試環境沒有發現問題，也請在部署後嚴密關注正式環境的應用程式日誌，尋找任何異常。

Q3：我使用的是 VPS/獨立伺服器，配置不算低，為什麼還會出現 502？

A3：這說明問題可能不是單純的「配置不足」，而是配置不當、軟體衝突、惡意攻擊，或是上游服務的特定問題。
您可以進一步排查：

• 仔細檢查 nginx 設定檔： 即使配置高，錯誤的 `proxy_pass` 指令、超時設定、或 `worker_connections` 設定得太低，也可能導致 502。
• 防火牆設定： 再次確認伺服器防火牆和雲端安全群組，是否意外地阻止了 nginx 和上游伺服器之間的通訊。
• 檢查是否有其他程式佔用端口： 有時候，一個新安裝的程式可能會意外地佔用了 nginx 或上游伺服器預期使用的端口，導致衝突。可以使用 `netstat -tulnp` 或 `ss -tulnp` 來查看哪些進程在使用哪些端口。
• 系統級別的安全掃描： 排除惡意軟體或被攻擊的可能性。
• 檢查系統核心參數： 在一些極端情況下，Linux 系統的核心參數（如 TCP 連接超時、最大文件描述符數量等）也可能成為瓶頸。

Q4：我看到 nginx 的 error.log 裡有 `connect() to ... failed (111: Connection refused)`，這是什麼意思？

A4：這個錯誤訊息非常明確，它的意思是：nginx 嘗試連接到指定 IP 地址和端口的「上游伺服器」，但該伺服器「主動拒絕了連接」。這通常有幾種可能：

• 上游伺服器未運行： 上游應用程式伺服器（例如 PHP-FPM, Node.js 應用）根本沒有啟動，或者已經崩潰了。
• 端口號錯誤： Nginx 設定檔中的 `proxy_pass` 指令指定的端口號，與上游伺服器實際監聽的端口號不符。
• 防火牆拒絕： 儘管 nginx 嘗試連接，但伺服器上的防火牆（iptables, firewalld）或網路層的防火牆，明確地拒絕了來自 nginx 的連接請求。
• 上游伺服器配置問題： 上游伺服器可能配置為只監聽本機回環地址（localhost/127.0.0.1），而 nginx 嘗試從外部（即使是同一台機器）連接，也被拒絕。

要解決這個問題，就需要針對以上幾點逐一排查，確保上游伺服器正常運行，監聽正確的端口，並且網路通暢無阻。

我的經驗談：預防勝於治療

經過這麼多年跟伺服器打交道的經驗，我發現很多時候「502 Bad Gateway」並非天災，而是人為的疏忽。所以，我總結了幾個「預防勝於治療」的經驗，希望能幫助大家少走彎路：

• 建立完善的監控系統： 不僅僅是網站的可用性監控，更重要的是伺服器資源（CPU、記憶體、磁碟、網路）的實時監控。當資源異常升高時，就能及早發現問題，而不是等到 502 出現才去處理。
• 定期檢查伺服器日誌： 不要等到問題發生才翻日誌。養成定期（例如每天或每週）瀏覽 nginx 和應用程式日誌的習慣，很多潛在問題會在早期就暴露出來。
• 建立標準化的部署流程： 確保每一次的程式碼更新或伺服器配置變更，都經過充分的測試，並且有回滾方案。
• 熟悉你的伺服器架構： 清楚你的網站是由哪些元件組成（nginx, 應用程式伺服器, 資料庫, 快取系統等），它們之間的依賴關係，以及它們的日誌文件路徑。
• 測試環境至關重要： 永遠不要直接在生產環境（正式伺服器）上進行實驗。搭建一個盡可能模擬生產環境的測試環境，並在那裡進行所有重要的變更和測試。

總結來說，「502 Bad Gateway」是一個常見但絕對可以解決的錯誤。關鍵在於耐心、細心，以及一套系統性的排查方法。希望這篇文章能成為你解決這個問題的有力助手，讓你不再為這個訊息而煩惱！