排解外部應用程式負載平衡器的相關問題

本指南說明如何排解外部應用程式負載平衡器的設定問題。請先熟讀下列頁面內容後,再研究問題。

排解網路分析器的常見問題

網路分析器會自動監控虛擬私有雲網路設定,並偵測不盡理想的設定和錯誤設定。它會找出網路故障、提供根本原因資訊,並建議可能的解決方法。如要瞭解 Network Analyzer 自動偵測到的各種錯誤設定情況,請參閱 Network Analyzer 說明文件中的「負載平衡器深入分析」。

Google Cloud 控制台提供 Network Intelligence Center 中的 Network Analyzer。

前往網路分析器

後端有不相容的平衡模式

建立負載平衡器時,您可能會看到以下錯誤訊息:

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

當您嘗試在兩個不同的負載平衡器中使用相同的後端,且後端沒有相容的平衡模式時,就會發生這種情況。

如要瞭解詳情,請參考下列資源:

排解一般連線問題

未說明的 5XX 錯誤

如果是負載平衡器 Proxy 與後端之間的通訊問題導致錯誤,負載平衡器會產生 HTTP 錯誤回應碼 (5XX),並將該錯誤回應碼傳回給用戶端。並非所有 HTTP 5XX 錯誤都是由負載平衡器產生,舉例來說,如果後端將 HTTP 5XX 回應傳送至負載平衡器,負載平衡器會將該回應轉送給用戶端。如要判斷 HTTP 5XX 回應是否由後端轉送,或是由負載平衡器 Proxy 產生,請參閱負載平衡器記錄statusDetails 欄位。

如果 statusDetails 傳回記錄字串 response_sent_by_backend,負載平衡器只會轉送後端傳送給它的任何回應碼,在這種情況下,您需要排解後端的 HTTP 錯誤回應。

如果 HTTP 錯誤回應的 statusDetails 與記錄字串 response_sent_by_backend 不符,請採取以下做法:

  • 全域外部應用程式負載平衡器和區域性外部應用程式負載平衡器會產生有意義的 HTTP 回應錯誤代碼,例如 503 (服務無法使用) 和 504 (閘道逾時)。

  • 傳統版應用程式負載平衡器一律會使用 HTTP 回應錯誤代碼 502。

全域外部應用程式負載平衡器的設定變更 (例如新增或移除後端服務),可能會導致使用者在短時間內看到 HTTP 回應錯誤碼 502。當這些設定變更傳播至全球的 GFEs 時,您會看到 statusDetails 欄位與 failed_to_pick_backend 記錄字串相符的記錄項目。

如果完成負載平衡器設定後,HTTP 5XX 錯誤持續出現超過幾分鐘的時間,請按照下列步驟排解 HTTP 5XX 回應問題:

  1. 請確認您已設定防火牆規則,允許系統執行健康狀態檢查。如果沒有,負載平衡器記錄通常會顯示 statusDetailsfailed_to_pick_backend 相符,這表示負載平衡器無法挑選健康狀態良好的後端來處理要求。

  2. 確認健康狀態檢查流量傳送至後端 VM。如要使用這項功能,請啟用健康狀態檢查記錄功能,並搜尋成功的記錄項目。

    對於新的負載平衡器,缺少成功的健康狀態檢查項目,並不代表健康狀態檢查流量未到達後端。這可能表示後端的初始健康狀態尚未從 UNHEALTHY 變更為其他狀態。只有在健康狀態檢查探測器收到後端傳送的 HTTP 200 OK 回應後,才會看到成功的健康狀態檢查記錄項目。

  3. 確認後端的軟體是否正在執行。為此,請確認 5xx 回應是由負載平衡器提供,還是來自於後端。請執行下列步驟:

    1. 使用 Cloud Logging 查看負載平衡器的記錄檔。您可以建立查詢,只查看 5xx 回應代碼
    2. 檢查 statusDetails 欄位的值:

      statusDetail 失敗訊息 可能的原因與解決方案
      failed_to_connect_to_backend

      負載平衡器無法與後端建立連線。這可能表示在後端執行的服務並未監聽後端服務中定義的通訊埠。

      建議:

      • 將健康狀態檢查的通訊埠設為使用 服務通訊埠。也就是說,後端會在符合放送實際流量的資格前,先判定為不健康。
      • 請使用下列指令,確認後端服務的命名通訊埠上有服務在執行:
        $ netstat -tnl | grep PORT
      failed_to_pick_backend

      負載平衡器無法挑選後端。這可能表示所有後端的運作狀態皆不良。請確認您已設定 正確的健康狀態檢查防火牆規則

      backend_connection_closed_before_data_sent_to_client 在將回應經由 Proxy 傳送至用戶端前,後端意外關閉其負載平衡器連線。如果負載平衡器將流量傳送給其他實體,就可能發生這種情況。其他實體可能是第三方負載平衡器,其 TCP 逾時時間比負載平衡器的逾時時間短。詳情請參閱「 逾時和重試」。
      backend_timeout 後端回應時間過長。 後端服務逾時時間可能設定得太短,導致指定服務無法回應。建議您提高後端服務逾時時間,或找出服務為何需要這麼長的時間才能回應。
  4. 請確認在後端執行個體上執行的 HTTP 伺服器軟體的 keepalive 設定參數,不會低於負載平衡器的 keepalive 逾時值,後者固定為 10 分鐘 (600 秒),且無法設定。

    當傳送 HTTP 要求時,或在收到完整 HTTP 回應之前,後端連線意外關閉,負載平衡器就會產生 HTTP 5XX 回應碼。這是因為在後端執行個體上執行的網路伺服器軟體的保留設定參數,小於負載平衡器的固定保留逾時時間。請確認每個後端的 HTTP 伺服器軟體的保留連線逾時設定值略大於 10 分鐘 (建議值為 620 秒)。

解決 HTTP 408 錯誤

對於 HTTP 流量,用戶端完成傳送要求所需的時間上限,等於後端服務的逾時時間。如果您看到 HTTP 408 回應中含有 jsonPayload.statusDetail client_timed_out,表示在 Proxy 用戶端要求或後端回應時,進度不足。如果問題是因為用戶端發生效能問題,您可以增加後端服務的逾時時間,解決這項問題。

經過負載平衡後的流量沒有原始用戶端的來源位址

後端所看到的封包來源 IP 位址「不是」負載平衡器的外部 IP 位址。以 Proxy 為基礎的負載平衡器 (例如外部應用程式負載平衡器) 會使用兩個 TCP 連線,將流量從用戶端傳輸至後端:

  • 連線 1:從原始用戶端連線至負載平衡器 (GFE 或僅限 Proxy 的子網路)
  • 連線 2:從負載平衡器 (GFE 或僅限 Proxy 的子網路) 到後端 VM 或端點

每個連線的來源和目的地 IP 位址會因您使用的外部應用程式負載平衡器類型而異。詳情請參閱「用戶端封包的來源 IP 位址 」。

嘗試查看 Cloud Storage bucket 中的物件時遇到權限錯誤

如要透過負載平衡提供物件,Cloud Storage 物件必須處於可公開存取的狀態。請務必針對要提供的物件更新權限,將其設為可公開讀取

網址未提供預期的 Cloud Storage 物件

系統會依據網址對應和要求的網址決定要提供的 Cloud Storage 物件。如果要求路徑對應到網址對應中的後端 bucket,則會透過將完整要求路徑附加至網址對應指定的 Cloud Storage bucket,藉此決定 Cloud Storage 物件。

舉例來說,如果您將 /static/* 對應至 gs://[EXAMPLE_BUCKET]https://<GCLB IP or Host>/static/path/to/content.jpg 的要求會嘗試提供 gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg。如果該物件不存在,您會收到以下錯誤訊息,而非物件:


NoSuchKey
The specified key does not exist.

壓縮無法作用

外部應用程式負載平衡器本身不會壓縮或解壓縮回應,但可以提供後端服務產生的回應,這些回應會使用 gzipDEFLATE 等工具加以壓縮。

如果負載平衡器提供的回應未經壓縮,但應經過壓縮,請確認在執行中執行個體上執行的網頁伺服器軟體是否已設定為壓縮回應。根據預設,部分網路伺服器軟體會自動為包含 Via 標頭的要求停用壓縮功能,這表示要求是由 Proxy 轉送。由於外部應用程式負載平衡器是 Proxy,因此會依據 HTTP 規格在每個要求中新增 Via 標頭。如要啟用壓縮功能,您可能需要覆寫網路伺服器的預設設定,讓伺服器在要求含有 Via 標頭時,壓縮回應。

如要設定 nginx 後端,以便透過外部應用程式負載平衡器代理服務壓縮回應,請按照下列步驟操作:

如要設定 Apache 後端,以便透過外部應用程式負載平衡器代理服務壓縮回應,請按照下列步驟操作:

排解後端健康狀態不良的問題

排解後端的 HTTP/2 問題

請確認後端執行個體處於良好的健康狀態,且支援 HTTP/2 通訊協定。您可以使用 HTTP/2 測試與後端執行個體的連線能力,確認這項資訊。請確認 VM 使用符合 HTTP/2 規格的加密組合。舉例來說,HTTP/2 不允許使用某些 TLS 1.2 加密套件。請參閱 TLS 1.2 加密套件黑名單

確認 VM 使用 HTTP/2 通訊協定後,請確認防火牆設定允許健康檢查器和負載平衡器通過。

如果防火牆設定沒有問題,請確認負載平衡器已設定為與 VM 上的正確通訊埠通訊。

排解外部後端和網際網路 NEG 問題

請先熟讀下列頁面內容後,再研究問題。

流量無法連上端點

設定服務後,如果符合下列條件,就能透過外部應用程式負載平衡器存取新端點:

  • 端點已連結至網際網路 NEG。
  • 相關聯的 FQDN 可成功解析 DNS (如果您使用 FQDN 端點類型)。
  • 可透過網際網路存取端點。

如果流量無法連上端點,導致出現 502 錯誤代碼,請使用 dig 或 nslookup 等工具查詢 _cloud-eoips.googleusercontent.com DNS TXT 記錄。請記下 CIDR (以下為 ip4:),並確認防火牆或雲端存取控制清單 (ACL) 允許這些範圍。

設定外部後端後,向外部後端提出的要求失敗,並顯示 5xx 錯誤

  • 勾選「記錄」
  • 確認網路端點群組已針對外部後端設定正確的 IP:Port 或 FQDN:Port。
  • 如果您使用 FQDN,請確認可以透過 Google 公用 DNS 解析。您可以按照這些步驟直接使用網路介面,確認 FQDN 是否可透過 Google 公用 DNS 解析。
  • 如果您只透過外部 IP 存取負載平衡器,而原始網頁伺服器預期會收到主機名稱,請設定自訂要求標頭,確保您會將有效的 HTTP 主機標頭傳送至後端。
  • 如果您透過 HTTPS 或 HTTP2 (如後端服務的 protocol 欄位所設定) 與後端通訊,且後端已設定為 INTERNET_FQDN_PORT 外部後端端點,請確認來源會顯示有效的傳輸層安全標準 (TLS) 憑證,且已設定的 FQDN 與憑證 SAN 清單中的 SAN (主體別名名稱) 相符。有效憑證的定義為由公開憑證授權單位簽署且未過期的憑證。
  • 使用 INTERNET_FQDN_PORT 外部後端端點時,負載平衡器不會接受自行簽署的憑證,並拒絕接受。
  • 當您使用 HTTPS 或 HTTP/2 搭配 INTERNET_IP_PORT 類型端點時,系統不會執行 SSL 憑證驗證/SAN 檢查。這表示可以使用自行簽署的憑證。使用 SSL 時,建議您使用 INTERNET_FQDN_PORT 端點,確保伺服器憑證和 SAN 可進行驗證。

Cloud CDN 未快取外部後端的回應

請確認下列事項:

  • 您已在後端服務中啟用 Cloud CDN,該服務包含 enableCDN 設為 true 的 NEG,可指向外部後端。
  • 外部後端提供的回應符合 Cloud CDN 快取規定。舉例來說,您正在從來源傳送 Cache-Control: public, max-age=3600 回應標頭。

排解無伺服器網路端點群組 (NEG) 問題

請先熟讀下列頁面內容後,再研究問題。

要求失敗,並傳回 404 錯誤

請確認底層無伺服器資源 (例如 App Engine、Cloud Run 函式或 Cloud Run 服務) 仍在執行。如果無伺服器資源已刪除,但無伺服器 NEG 仍存在,外部應用程式負載平衡器會繼續嘗試將要求路由至不存在的服務。這會導致 404 回應。

一般來說,外部應用程式負載平衡器無法偵測基礎無伺服器資源是否正常運作。也就是說,如果某個區域中的服務傳回錯誤,但該區域的整體 Cloud Run、Cloud Run 函式或 App Engine 基礎架構運作正常,外部應用程式負載平衡器就不會自動將流量導向其他區域。請務必先徹底測試新版服務,再將使用者流量轉送至該服務。

處理網址遮罩不相符

如果將已設定的網址遮罩套用至使用者要求網址,但未產生服務名稱,或是產生不存在的服務名稱,負載平衡器可能會根據所使用的無伺服器運算平台,以不同方式處理這些不相符的情況。

Cloud Run:如果網址遮罩不相符,負載平衡器會傳回 HTTP 錯誤 404 (找不到)。

Cloud Run 函式:如果網址遮罩不相符,負載平衡器會傳回 HTTP 錯誤 404 (找不到)。

App Engine:如果網址遮罩不相符,App Engine 會使用 dispatch.yaml 和 App Engine 的預設轉送邏輯,判斷要將要求傳送至哪個服務。