本指南說明如何排解外部應用程式負載平衡器的設定問題。請先熟讀下列頁面內容後，再研究問題：
排解網路分析器的常見問題
網路分析器會自動監控虛擬私有雲網路設定，並偵測不盡理想和錯誤的設定。識別網路故障、提供根本原因資訊，並建議可能的解決方法。如要瞭解網路分析器自動偵測到的各種設定錯誤情況，請參閱網路分析器說明文件中的「負載平衡器洞察」一節。
網路分析器 位於 Google Cloud 控制台，是 Network Intelligence Center 的一部分。
前往網路分析器後端平衡模式不相容
建立負載平衡器時，您可能會看到以下錯誤：
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。這些設定變更會傳播至全球的 GFE，您會看到 statusDetails 欄位與 failed_to_pick_backend 記錄字串相符的記錄項目。
如果完成負載平衡器設定後，HTTP 5XX 錯誤持續出現超過幾分鐘的時間，請按照下列步驟排解 HTTP 5XX 回應問題：
確認已設定防火牆規則，允許健康狀態檢查。如果沒有，負載平衡器記錄通常會有
statusDetails相符的failed_to_pick_backend，表示負載平衡器無法挑選健康狀態良好的後端來處理要求。確認健康狀態檢查流量傳送至後端 VM。如要使用這項功能，請啟用健康狀態檢查記錄功能，並搜尋成功的記錄項目。
對於新的負載平衡器，缺少成功的健康狀態檢查項目，並不代表健康狀態檢查流量未到達後端。這可能表示後端的初始健康狀態尚未從
UNHEALTHY變更為其他狀態。只有在健康狀態檢查探測器收到後端傳送的 HTTP 200 OK 回應後，才會看到成功的健康狀態檢查記錄項目。確認後端軟體正在執行。如要這麼做，請檢查 5xx 回應是由負載平衡器提供，還是由後端產生。請執行下列步驟：
- 使用 Cloud Logging 查看負載平衡器的記錄。您可以建立查詢，只尋找 5xx 回應代碼。
檢查
statusDetails欄位的值：- 如果
statusDetails傳回成功訊息 (例如response_sent_by_backend)，就表示提供 HTTP 502 回應的是後端。請查看後端記錄檔，並根據後端執行的服務進一步排解問題。 - 如果
statusDetails傳回失敗訊息，請參閱下列解決方案清單，瞭解與 5xx 回應相關的常見失敗情形：
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後端回應時間過長。 後端服務逾時可能設得太低，導致服務無法回應。請考慮增加後端服務逾時時間，或調查服務回應時間過長的原因。 - 如果
確認後端執行個體上執行的 HTTP 伺服器軟體的 Keep-Alive 設定參數，不小於負載平衡器的 Keep-Alive 逾時 (固定為 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。如果該物件不存在，您會收到下列錯誤訊息，而不是物件：
NoSuchKeyThe specified key does not exist.
未執行壓縮
外部應用程式負載平衡器本身不會壓縮或解壓縮回應，但會提供後端服務產生的回應，這些回應會使用 gzip 或 DEFLATE 等工具加以壓縮。
如果負載平衡器提供的回應沒有依預期壓縮，請檢查在執行個體上執行的網路伺服器軟體是否設為需壓縮回應。根據預設，部分網路伺服器軟體會自動針對包含 Via 標頭的要求停用壓縮功能，這表示要求是經由 Proxy 轉送。由於外部應用程式負載平衡器是 Proxy，因此會依據 HTTP 規格，在每個要求中新增 Via 標頭。如要啟用壓縮功能，可能需要覆寫網路伺服器的預設設定，指示伺服器即使要求含有 Via 標頭也需壓縮回應。
如要設定 nginx 後端，透過外部應用程式負載平衡器 Proxy 處理壓縮回應，請按照下列步驟操作：
- 適當設定
gzip_proxied指令 (例如設為any)，以及 - 將
gzip_vary指令設為on。
如要設定 Apache 後端，透過外部應用程式負載平衡器提供經過 Proxy 處理的壓縮回應，請按照下列步驟操作：
- 使用
DEFLATE篩選器，以及 - 使用
mod_headers模組，將Vary Accept-Encoding新增至回應標頭 。
排解後端健康狀態不良的問題
排解後端的 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 Host 標頭傳送至後端。
- 如果您透過 HTTPS 或 HTTP2 與後端通訊 (如後端服務的
protocol欄位所設定)，並將後端設定為INTERNET_FQDN_PORT外部後端端點，請確保來源提供有效的傳輸層安全標準 (TLS) (安全資料傳輸層 (SSL)) 憑證，且設定的完整網域名稱 (FQDN) 與憑證的 SAN (主體別名) 清單中的 SAN 相符。有效憑證是指由公開憑證授權單位簽署且未過期的憑證。 - 使用
INTERNET_FQDN_PORT外部後端端點時，負載平衡器不會接受自行簽署的憑證，且會拒絕這類憑證。 - 使用 HTTPS 或 HTTP/2 時，如果端點類型為
INTERNET_IP_PORT，系統不會執行 SSL 憑證驗證/SAN 檢查。也就是說，使用者可以自行簽署憑證。使用 SSL 時，建議使用INTERNET_FQDN_PORT端點，確保伺服器憑證和 SAN 可以驗證。
Cloud CDN 未快取外部後端的回應
請確認下列事項：
- 您已在包含 NEG 的後端服務上啟用 Cloud CDN，並將 enableCDN 設為 true，指向外部後端。
- 外部後端提供的回應符合 Cloud CDN 快取條件。舉例來說，您要從來源傳送
Cache-Control: public, max-age=3600回應標頭。
排解無伺服器 NEG 問題
請先熟讀下列頁面內容後，再研究問題：
要求失敗並出現 404 錯誤
確認基礎無伺服器資源 (例如 App Engine、Cloud Run functions 或 Cloud Run 服務) 仍在執行。如果無伺服器資源已刪除，但無伺服器 NEG 仍存在，外部應用程式負載平衡器會繼續嘗試將要求轉送至不存在的服務。這會導致 404 回應。
一般來說，外部應用程式負載平衡器無法偵測底層無伺服器資源是否正常運作。也就是說，如果某個區域的服務傳回錯誤，但該區域的整體 Cloud Run、Cloud Run functions 或 App Engine 基礎架構運作正常，外部應用程式負載平衡器不會自動將流量導向其他區域。請務必徹底測試服務的新版本，再將使用者流量轉送至這些版本。
處理網址遮罩不符的問題
如果將設定的網址遮罩套用至使用者要求網址後，沒有產生服務名稱，或是產生不存在的服務名稱，負載平衡器可能會根據使用的無伺服器運算平台，以不同方式處理這些不符情況。
Cloud Run：如果網址遮罩不符，負載平衡器會傳回 HTTP 錯誤 404 (找不到)。
Cloud Run 函式：如果網址遮罩不符，負載平衡器會傳回 HTTP 錯誤 404 (找不到)。
API Gateway：如果網址遮罩不符，負載平衡器會傳回 HTTP 錯誤 404 (找不到)。
App Engine：如果網址遮罩不符，App Engine 會使用 dispatch.yaml 和 App Engine 的預設路由邏輯，判斷要將要求傳送至哪個服務。