針對應用程式閘道中的後端健康情況問題進行疑難排解

發行項
03/12/2024

概觀

根據預設，Azure 應用程式閘道會探查後端伺服器，以檢查其健全狀態，並檢查其是否已準備好處理要求。使用者也可以建立自定義探查，以提及主機名、要探查的路徑，以及要接受為狀況良好的狀態代碼。在每個案例中，如果後端伺服器未成功回應，應用程式閘道會將伺服器標示為「狀況不良」，並停止將要求轉送到伺服器。伺服器開始回應成功之後，應用程式閘道繼續轉送要求。

如何檢查後端健康情況

若要檢查後端集區的健康情況，您可以使用 Azure 入口網站上的 [後端健康情況] 頁面。或者，您可以使用 Azure PowerShell、CLI 或 REST API。

這些方法所擷取的狀態可以是下列任何一種狀態：

良好
Unhealthy
Unknown

如果要求狀態良好，則應用程式閘道會從後端集區將要求轉送至伺服器。如果後端集區中的所有伺服器狀況不良或未知，用戶端可能會遇到存取後端應用程式時發生問題。進一步閱讀以瞭解後端健康情況報告的不同訊息、其原因及其解決方式。

注意

如果您的用戶沒有查看後端健康狀態的許可權， No results. 將會顯示。

後端健康狀態：狀況不良

如果後端健全狀況狀態為 [狀況不良]，入口網站檢視會類似下列螢幕快照：

如果您使用 Azure PowerShell、CLI 或 Azure REST API 查詢，您會收到類似下列範例的回應：

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appg
                          w1/backendHttpSettingsCollection/appGatewayBackendHttpSettings"
                                  },
                                  "Servers": [
                                    {
                                      "Address": "10.0.0.5",
                                      "Health": "Healthy"
                                    },
                                    {
                                      "Address": "10.0.0.6",
                                      "Health": "Unhealthy"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

針對後端集區中的所有伺服器收到「狀況不良」後端伺服器狀態之後，要求就不會轉送到伺服器，而應用程式閘道會將「502 錯誤閘道」錯誤傳回給要求的用戶端。若要針對此問題進行疑難解答，請檢查 [後端健康情況] 索引標籤上的 [詳細數據] 數據行。

[詳細數據] 資料行中顯示的訊息提供有關問題的更詳細見解，並根據這些詳細數據，您可以開始針對問題進行疑難解答。

注意

默認探查要求會以 protocol>：//127.0.0.1：<port> 的格式<傳送。例如， http://127.0.0.1:80 針對埠 80 上的 HTTP 探查。只有 200 到 399 的 HTTP 狀態代碼會被視為狀況良好。通訊協定和目的地埠繼承自 HTTP 設定。如果您想要應用程式閘道在不同的通訊協定、主機名或路徑上探查，以及將不同的狀態代碼辨識為狀況良好，請設定自定義探查，並將它與 HTTP 設定產生關聯。

錯誤訊息

後端伺服器逾時

訊息：後端回應應用程式閘道的健全狀態探查所需的時間超過探查設定中的逾時閾值。

原因： 應用程式閘道將 HTTP(S) 探查要求傳送至後端伺服器之後，其會等待來自後端伺服器的回應持續一段設定的時間。如果後端伺服器未在設定的期間 (逾時值) 內回應，則會在重新開始於設定的逾時期間內回應前，系統會將其標示為「狀況不良」。

解決方案： 檢查後端伺服器或應用程式未在設定的逾期期間內回應的原因，同時檢查應用程式的相依性。例如，檢查資料庫是否有任何可能觸發回覆延遲的問題。如果您知道應用程式的行為，而且它應該只在逾時值之後回應，請從自訂探查設定中增加逾時值。您必須擁有自訂探查，才能變更逾時值。如需如何設定自定義探查的詳細資訊，請參閱文件頁面。

若要增加逾時值，請遵循下列步驟：

直接存取後端伺服器，並檢查伺服器在該頁面上回應所需的時間。您可以使用任何工具來存取後端伺服器，包括使用開發人員工具的瀏覽器。
找出應用程式回應所花費的時間之後，請選取 [健康情況探查 ] 索引標籤，然後選取與您 HTTP 設定相關聯的探查。
輸入大於應用程式回應時間的任何逾時值，以秒為單位。
儲存自定義探查設定，並檢查後端健康情況現在是否顯示為 [狀況良好]。

DNS 解析錯誤

訊息：應用程式閘道無法為此後端建立探查。這通常會在後端的 FQDN 未正確輸入時發生。

原因：如果後端集區的類型為IP位址、FQDN（完整功能變數名稱）或App Service，應用程式閘道解析為透過 DNS 輸入的 FQDN IP 位址（自定義或 Azure 預設值）。然後，應用程式閘道會嘗試連線到 HTTP 設定中所提 TCP 連接埠上的伺服器。但是，如果顯示此訊息，則表示應用程式閘道無法成功解析所輸入 FQDN 的 IP 位址。

解決方法：

確認在後端集區中輸入的 FQDN 是正確的，而且是公用網域，然後嘗試從本機電腦進行解析。
如果您可以解析 IP 位址，則虛擬網路中的 DNS 設定可能會發生問題。
檢查是否已使用自訂 DNS 伺服器設定虛擬網路。如果是，請檢查 DNS 伺服器為何無法解析為指定 FQDN 的 IP 位址。
如果您使用的是 Azure 預設 DNS，請洽詢您的網域註冊機構，了解是否已完成適當的 A 記錄或 CNAME 記錄對應。
如果是私人或內部網域，請嘗試從相同虛擬網路中的 VM 進行解析。如果您可加以解析，請重新啟動應用程式閘道，再檢查一次。若要重新啟動應用程式閘道，您必須使用這些連結資源中所述的 PowerShell 命令進行停止和啟動。

TCP 連線錯誤

訊息：應用程式閘道無法連線到後端。檢查後端是否在用於探查的連接埠上回應。同時檢查是否有任何 NSG/UDR/防火牆封鎖存取此後端的 Ip 和連接埠。

原因： 在 DNS 解析階段之後，應用程式閘道會嘗試連線到 HTTP 設定中設定的 TCP 通訊埠上的後端伺服器。如果應用程式閘道無法在指定的連接埠上建立 TCP 工作階段，此訊息就會將探查標示為「狀況不良」。

解決方案： 如果您收到此錯誤，請遵循下列步驟：

檢查您是否可以使用瀏覽器或 PowerShell，在 HTTP 設定中所述的埠上連線到後端伺服器。例如，執行下列命令： Test-NetConnection -ComputerName www.bing.com -Port 443。
如果所述的埠不是所需的埠，請輸入正確的埠號碼，應用程式閘道連線到後端伺服器。
如果您無法從本機電腦連線到埠，則：

a. 檢查後端伺服器網路適配器和子網的網路安全組（NSG）設定，以及是否允許對所設定埠的輸入連線。如果沒有，請建立新的規則以允許連線。若要瞭解如何建立 NSG 規則，請參閱文件頁面。

b. 檢查應用程式閘道子網的 NSG 設定是否允許輸出公用和私人流量，以便建立連線。請查看步驟 3a 中提供的文件頁面，以深入瞭解如何建立 NSG 規則。
```
        $vnet = Get-AzVirtualNetwork -Name "vnetName" -ResourceGroupName "rgName"
        Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
```
c. 檢查應用程式閘道的使用者定義路由（UDR）設定，以及後端伺服器的子網是否有任何路由異常。請確定 UDR 不會將流量導向後端子網。例如，檢查路由至網路虛擬設備，或透過 Azure ExpressRoute 和/或 VPN 向應用程式閘道子網公告的預設路由。

d. 若要檢查網路適配器的有效路由和規則，您可以使用下列 PowerShell 命令：
```
        Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
        Get-AzEffectiveRouteTable -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
```
如果您找不到 NSG 或 UDR 的任何問題，請檢查後端伺服器是否有應用程式相關問題，以防止客戶端在設定的埠上建立 TCP 工作階段。要檢查的一些事項：

a. 開啟命令提示字元（Win+R -> cmd），輸入 netstat，然後選取 Enter。

b. 檢查伺服器是否正在接聽所設定的埠。例如：
```
        Proto Local Address Foreign Address State PID
        TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
```
c. 如果未接聽設定的埠，請檢查您的網頁伺服器設定。例如：IIS 中的月台系結、NGINX 中的伺服器區塊和 Apache 中的虛擬主機。

d. 請檢查您的OS防火牆設定，以確定允許連入埠的流量。

HTTP 狀態代碼不符

訊息： 後端 HTTP 回應的狀態代碼不符合探查設定。必須是：{HTTPStatusCode0} Received：{HTTPStatusCode1}。

原因： 建立 TCP 連線並完成 TLS 交握後 (如果已啟用 TLS)，應用程式閘道會將探查當作 HTTP GET 要求傳送至後端伺服器。如先前所述，預設探查會是 <protocol>://127.0.0.1:<port>/，它會將 200 到 399 範圍內的響應狀態代碼視為 [狀況良好]。如果伺服器傳回任何其他狀態代碼，則會將此訊息標示為 [狀況不良]。

解決方案： 視後端伺服器的回應碼而定，您可以採取下列步驟。這裡列出一些常見的狀態代碼：

錯誤	動作
探查狀態代碼不符：收到 401	檢查後端伺服器是否需要驗證。應用程式閘道探查無法傳遞認證以進行驗證。在探查狀態代碼中允許「HTTP 401」比對，或探查到伺服器不需要驗證的路徑。
探查狀態代碼不符：收到 403	禁止存取。檢查後端伺服器上是否允許存取路徑。
探查狀態代碼不符：收到 404	找不到頁面。檢查後端伺服器上是否可以存取主機名路徑。將主機名或路徑參數變更為可存取的值。
探查狀態代碼不符：收到 405	應用程式閘道的探查要求會使用 HTTP GET 方法。檢查您的伺服器是否允許此方法。
探查狀態代碼不符：收到 500	內部伺服器錯誤。檢查後端伺服器的健康情況，以及服務是否正在執行中。
探查狀態代碼不符：收到 503	服務無法使用。檢查後端伺服器的健康情況，以及服務是否正在執行中。

或者，如果您認為回應是合法的，而且您想要應用程式閘道接受其他狀態代碼為「狀況良好」，您可以建立自定義探查。在後端網站需要驗證的情況下，此方法很有用。因為探查要求不會攜帶任何用戶認證，所以它們將會失敗，後端伺服器會傳回 HTTP 401 狀態代碼。

若要建立自定義探查，請遵循下列步驟。

HTTP 回應本文不符

訊息： 後端 HTTP 回應的本文不符合探查設定。收到的回應本文不包含 {string}。

原因：當您建立自訂探查時，您可以透過比對回應本文中的字串，將後端伺服器標示為「狀況良好」。例如，您可以將應用程式閘道設定為接受「未經授權」作為要比對的字串。如果探查要求的後端伺服器回應包含未經授權的字串，則會將其標示為狀況良好。否則，它會以指定的訊息標示為 [狀況不良]。

解決方案： 若要解決此問題，請遵循下列步驟：

在本機或從探查路徑上的用戶端計算機存取後端伺服器，並檢查回應本文。
確認應用程式閘道自訂探查設定中的回應本文符合已設定的內容。
如果兩者不相符，請變更探查設定，使其具有可接受的正確字串值。

深入瞭解應用程式閘道探查比對。

注意

如需所有 TLS 相關錯誤訊息，若要深入瞭解 SNI 行為和 v1 與 v2 SKU 之間的差異，請參閱 TLS 概觀頁面。

一般名稱 (CN) 不相符

訊息： （針對 V2）後端伺服器所呈現之分葉憑證的一般名稱不符合應用程式閘道的探查或後端設定主機名。
（V1）後端憑證的一般名稱（CN）不相符。

原因： (針對 V2) 當您在後端設定中選取 HTTPS 通訊協定，而且自訂探查或後端設定的主機名稱 (依此順序) 與後端伺服器憑證的一般名稱 (CN) 不相符時，就會發生這種情況。
（V1）後端集區目標的 FQDN 不符合後端伺服器憑證的一般名稱（CN）。

解決方案： 主機名信息對於後端 HTTPS 連線很重要，因為該值用來在 TLS 交握期間設定伺服器名稱指示（SNI）。您可以根據閘道的設定，以下列方式修正此問題。

針對 V2，

如果您使用預設探查 – 您可以在應用程式閘道的相關聯後端設定中指定主機名。您可以在後端設定中選取 [以特定主機名覆寫] 或 [從後端目標挑選主機名]。
如果您使用自定義探查 – 針對自定義探查，您可以使用 [主機] 字段來指定後端伺服器證書的一般名稱。或者，如果後端設定已經使用相同的主機名進行設定，您可以在探查設定中選擇 [從後端設定挑選主機名]。

針對 V1，確認後端集區目標的 FQDN 與一般名稱（CN）相同。

提示：若要判斷後端伺服器憑證的一般名稱（CN），您可以使用這些方法。另請注意，根據 RFC 6125 ，如果 SAN 存在，SNI 驗證只會針對該欄位完成。如果憑證中沒有 SAN，則會比對一般名稱欄位。

使用瀏覽器或任何用戶端：直接存取後端伺服器（而非透過應用程式閘道），然後按兩下網址列中的憑證掛鎖，以檢視憑證詳細數據。您會在 [發行至] 區段底下找到它。
登入後端伺服器（Windows）：
1. 登入裝載應用程式的電腦。
2. 選取 [Win+R]，或以滑鼠右鍵按兩下 [開始] 按鈕，然後選取 [執行]。
3. 輸入 certlm.msc，然後選取 Enter。您也可以在 [開始] 功能表上搜尋憑證管理員。
4. 找出憑證（通常是在 [憑證 - 本機計算機\個人\憑證] 中），然後開啟憑證。
5. 在 [詳細數據] 索引標籤上，檢查憑證主體。
藉由登入後端伺服器（Linux）：藉由指定正確的憑證檔名來執行此 OpenSSL 命令 openssl x509 -in certificate.crt -subject -noout

後端憑證已過期

訊息： 後端憑證無效。目前日期不在憑證上的「有效從」和「有效至」日期範圍內。

原因： 過期的憑證被視為不安全，因此應用程式閘道會將憑證已過期的後端伺服器標示為狀況不良。

解決方案： 解決方案取決於後端伺服器上憑證鏈結的哪個部分已過期。

針對 V2 SKU，

過期的分葉（也稱為網域或伺服器）憑證 – 使用憑證提供者更新伺服器證書，並在後端伺服器上安裝新的憑證。請確定您已安裝包含 Leaf (topmost) > Intermediate(s) > Root的完整憑證鏈結。根據證書頒發機構單位類型（CA），您可以在閘道上採取下列動作。
- 公開已知的 CA：如果憑證簽發者是已知的 CA，您就不需要對應用程式閘道採取任何動作。
- 私人 CA：如果分葉憑證是由私人 CA 簽發，您必須檢查簽署的根 CA 憑證是否已變更。在這種情況下，您必須上傳新的根 CA 憑證（。CER）至閘道的相關聯後端設定。
過期的中繼或跟證書 – 一般而言，這些憑證的有效期間相對較長（十年或兩年）。當跟證書/中繼憑證到期時，建議您洽詢憑證提供者以取得更新的憑證檔案。請確定您已在後端伺服器上安裝此更新且完整的憑證鏈結 Leaf (topmost) > Intermediate(s) > Root 。
- 如果跟證書保持不變，或簽發者是已知的 CA，則您不需要對應用程式閘道採取任何動作。
- 使用私人 CA 時，如果根 CA 憑證本身或更新中繼憑證的根憑證已變更，您必須將新的跟證書上傳至應用程式網關的後端設定。

針對 V1 SKU，

使用您的 CA 更新過期的分葉（也稱為網域或伺服器）憑證，並上傳相同的分葉憑證（。CER）至應用程式閘道的相關聯後端設定。

找不到中繼憑證

訊息：後端伺服器所呈現的憑證鏈結遺漏中繼憑證。請確定憑證鏈結已完成，並在後端伺服器上正確排序。

原因： 中繼憑證未安裝在後端伺服器上的憑證鏈結中。

解決方案： 中繼憑證可用來簽署分葉憑證，因此需要完成鏈結。請洽詢憑證授權單位 (CA)，以了解所需的中繼憑證，並將其安裝在後端伺服器上。此鏈結的開頭必須是分葉憑證，接著是中繼憑證，最後是根 CA 憑證。建議您在後端伺服器上安裝完整的鏈結，包括根 CA 憑證。如需參考，請查看分葉必須是鏈結中最上層底下的憑證鏈結範例。

注意

非證書頒發機構單位的自我簽署憑證也會導致相同的錯誤。這是因為應用程式閘道會將這類自我簽署憑證視為「分葉」憑證，並尋找其簽署中繼憑證。您可以遵循本文來正確產生自我簽署憑證。

這些影像顯示自我簽署憑證之間的差異。

找不到分葉或伺服器證書

訊息：後端伺服器呈現的憑證鏈結中遺漏分葉憑證。請確定鏈結已完成，並在後端伺服器上正確排序。

原因： 後端伺服器上的憑證鏈結遺失分葉 (也稱為網域或伺服器) 憑證。

解決方案： 您可以從證書頒發機構單位（CA）取得分葉憑證。在後端伺服器上安裝此分葉憑證及其所有簽署端憑證 (中繼和根 CA 憑證)。此鏈結的開頭必須是分葉憑證，接著是中繼憑證，最後是根 CA 憑證。建議您在後端伺服器上安裝完整的鏈結，包括根 CA 憑證。如需參考，請查看分葉必須是鏈結中最上層底下的憑證鏈結範例。

伺服器證書不是由公開已知的CA所簽發

訊息： 後端 伺服器證書 未由已知的證書頒發機構單位（CA）簽署。若要使用未知的 CA 憑證，其跟證書必須上傳至應用程式閘道的後端設定。

原因： 您已在後端設定中選擇「已知 CA 憑證」，但後端伺服器所呈現的跟證書並不公開。

解決方案： 當私人證書頒發機構單位（CA）發行分葉憑證時，簽署的根 CA 憑證必須上傳至應用程式閘道的相關聯後端設定。這可讓應用程式閘道與該後端伺服器建立信任的連線。若要修正此問題，請移至相關聯的後端設定，選擇 [並非已知的 CA]，並將根 CA 憑證 (.CER) 上傳。若要識別並下載根憑證，您可以依照與受信任根憑證不相符中所述的相同步驟進行。

中繼憑證不是由公開已知的 CA 簽署。

訊息：中繼憑證未由已知的證書頒發機構單位（CA）簽署。請確定憑證鏈結已完成，並在後端伺服器上正確排序。

原因： 您已在後端設定中選擇「已知 CA 憑證」，但後端伺服器所提供的中繼憑證不會由任何公開的 CA 簽署。

解決方案： 當私人證書頒發機構單位（CA）簽發憑證時，簽署根 CA 的憑證必須上傳至應用程式閘道的相關聯後端設定。這可讓應用程式閘道與該後端伺服器建立信任的連線。若要修正此問題，請連絡您的私人 CA 以取得適當的根 CA 憑證（。CER）並上傳該。選取「不是已知的 CA」，將 CER 檔案移至應用程式閘道的後端設定。我們也建議您在後端伺服器上安裝完整的鏈結，包括根 CA 憑證，以便於驗證。

受信任的跟證書不符（後端伺服器上的跟證書沒有跟證書）

訊息： 中繼憑證未由上傳至應用程式閘道的任何跟證書簽署。請確定憑證鏈結已完成，並在後端伺服器上正確排序。

原因： 上傳至相關聯後端設定的根 CA 憑證皆尚未簽署安裝在後端伺服器上的中繼憑證。後端伺服器只安裝分葉和中繼憑證。

解決方案： 分葉憑證是由中繼憑證簽署，此憑證是由根 CA 憑證簽署。使用來自私人憑證授權單位 (CA) 的憑證時，必須將對應的根 CA 憑證上傳至應用程式閘道。請和您的私人 CA 連絡，以取得適當的根 CA 憑證 (.CER)，並將該 CER 檔案上傳至應用程式閘道的後端設定。

受信任的跟證書不符（後端伺服器上有跟證書可用）

訊息： 後端所使用的伺服器證書跟證書不符合新增至應用程式閘道的受信任跟證書。請確定您新增正確的跟證書以允許列出後端。

原因： 當上傳至應用程式閘道後端設定的根憑證不符合後端伺服器上存在的根憑證，就會發生此錯誤。

解決方案： 這適用於私人證書頒發機構單位（CA）所簽發或自我簽署的後端伺服器證書。識別正確的根 CA 憑證，並將其上傳至相關聯的後端設定。

提示：若要識別並下載跟證書，您可以使用其中任何一種方法。

使用瀏覽器：直接存取後端伺服器（而非透過應用程式閘道），然後按兩下網址列中的憑證掛鎖，以檢視憑證詳細數據。
1. 選擇鏈結中的跟證書，然後按兩下 [導出]。根據預設，這會是。CRT 檔案。
2. 開啟此。CRT 檔案。
3. 移至 [詳細數據] 索引標籤，然後按下 [複製到檔案]
4. 在 [憑證導出精靈] 頁面上，按 [下一步]
5. 選取 [Base-64 編碼 X.509 （.CER）並按兩下 [下一步]，然後按兩下 [下一步]
6. 提供新的檔名，然後按 [下一步]
7. 按兩下 [完成] 以取得。CER 檔案。
8. 上傳此跟證書（。您私人 CA 的 CER）到應用程式閘道的後端設定。
登入後端伺服器（Windows）
1. 登入裝載應用程式的電腦。
2. 選取 [Win+R]，或以滑鼠右鍵按兩下 [開始] 按鈕，然後選取 [執行]。
3. 輸入 certlm.msc，然後選取 Enter。您也可以在 [開始] 功能表上搜尋憑證管理員。
4. 找出憑證，通常是在 [憑證 - 本機計算機\個人\憑證] 中，然後開啟它。
5. 選取跟證書，然後選取 [檢視憑證]。
6. 在 [憑證屬性] 中，選取 [詳細數據] 索引卷標，然後按兩下 [複製到檔案]
7. 在 [憑證導出精靈] 頁面上，按 [下一步]
8. 選取 [Base-64 編碼 X.509 （.CER）並按兩下 [下一步]，然後按兩下 [下一步]
9. 提供新的檔名，然後按 [下一步]
10. 按兩下 [完成] 以取得。CER 檔案。
11. 上傳此跟證書（。您私人 CA 的 CER）到應用程式閘道的後端設定。

分葉必須是鏈結中最上層的。

訊息： 分葉憑證不是後端伺服器所呈現鏈結中最上層的憑證。請確定憑證鏈結在後端伺服器上已正確排序。

原因： 分葉（也稱為網域或伺服器）憑證未以正確的順序安裝在後端伺服器上。

解決方案： 後端伺服器上的憑證安裝必須包含由分葉憑證及其所有簽署憑證（中繼和根 CA 憑證）組成的已排序憑證清單。此鏈結的開頭必須是分葉憑證，接著是中繼憑證，最後是根 CA 憑證。建議您在後端伺服器上安裝完整的鏈結，包括根 CA 憑證。

假設是伺服器證書安裝及其中繼和根 CA 憑證的範例，其表示 OpenSSL 中的深度（0、1、2 等等）。您可以使用下列 OpenSSL 命令來驗證後端伺服器的憑證相同。
s_client -connect <FQDN>:443 -showcerts
或
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

憑證驗證失敗

訊息： 無法驗證後端憑證的有效性。若要找出原因，請檢查 OpenSSL 診斷，以取得與錯誤碼 {errorCode} 相關聯的訊息

原因： 當應用程式閘道無法驗證憑證的有效性時，就會發生此錯誤。

解決方案： 若要解決此問題，請確認伺服器上的憑證已正確建立。例如，您可以使用 OpenSSL 來驗證憑證及其屬性，然後嘗試將憑證重新上傳至應用程式閘道的 HTTP 設定。

後端健康狀態：未知

更新後端集區的 DNS 專案

訊息： 無法擷取後端健康狀態。當應用程式閘道子網上的 NSG/UDR/Firewall 在 v1 SKU 的情況下封鎖埠 65503-65534 上的流量，如果 v2 SKU，則為埠 65200-65535，如果後端集區中設定的 FQDN 無法解析為 IP 位址，就會發生這種情況。若要深入瞭解，請造訪 - https://aka.ms/UnknownBackendHealth。

原因：若為 FQDN （完整功能變數名稱）型後端目標，應用程式閘道會快取，並在無法取得後續 DNS 查閱的回應時，使用最後已知良好的 IP 位址。處於此狀態之閘道上的 PUT 作業會完全清除其 DNS 快取。因此，閘道無法連線到任何目的地位址。

解決方案： 檢查並修正 DNS 伺服器，以確保它為指定的 FDQN DNS 查閱提供回應。您也必須檢查 DNS 伺服器是否可透過應用程式閘道的虛擬網絡連線。

其他原因

如果後端健康情況顯示為 [未知]，入口網站檢視會類似下列螢幕快照：

Application Gateway backend health - Unknown

下列一個或多個原因會發生此行為：

應用程式閘道子網上的 NSG 封鎖來自「因特網」的埠 65503-65534（v1 SKU）或 65200-65535 （v2 SKU）的輸入存取。
應用程式閘道子網上的 UDR 會設定為預設路由（0.0.0.0.0/0），且下一個躍點未指定為「因特網」。
預設路由是由透過 BGP 對虛擬網路進行的 ExpressRoute/VPN 連線來公告。
自訂 DNS 伺服器會設定於無法解析公用網域名稱的虛擬網路上。
應用程式閘道處於「狀況不良」狀態。

解決方案：

檢查 NSG 是否封鎖從 因特網存取埠 65503-65534（v1 SKU）或 65200-65535 （v2 SKU）的存取：

a. 在 [應用程式閘道概觀] 索引標籤上，選取 [虛擬網絡/子網] 連結。 b. 在虛擬網路的 [子網] 索引卷標上，選取已部署應用程式閘道的子網。 c. 檢查是否已設定任何 NSG。 d. 如果已設定 NSG，請在 [搜尋] 索引標籤或 [所有資源] 底下搜尋該 NSG 資源。 e. 在 [ 輸入規則 ] 區段中，新增輸入規則，以允許 v1 SKU 的目的地埠範圍 65503-65534 或 65200-65535 v2 SKU ，並將來源 設定為 GatewayManager 服務標籤。 f. 選取 [ 儲存 ]，並確認您可以將後端檢視為 [狀況良好]。或者，您可以透過 PowerShell/CLI來執行此動作。
檢查您的 UDR 是否具有預設路由（0.0.0.0.0/0），且下一個躍點未設定為 因特網：

a. 請遵循步驟 1a 和 1b 來判斷您的子網。 b. 檢查是否已設定 UDR。如果有，請在搜尋列或 [所有資源] 底下 搜尋資源。 c. 檢查是否有任何預設路由（0.0.0.0.0/0），下一個躍點未設定為 因特網。如果設定為虛擬設備或虛擬網絡閘道，您必須確定虛擬設備或內部部署裝置可以正確地將封包路由回因特網目的地，而不需修改封包。如果探查是透過虛擬設備路由傳送並修改的，後端資源會顯示 200 狀態代碼，而應用程式閘道健康情況狀態會顯示為未知。這不會指出錯誤。流量仍應透過應用程式閘道路由傳送，而不會發生問題。 d. 否則，請將下一個躍點變更為 [因特網]，選取 [ 儲存]，然後確認後端健康情況。
透過 BGP 對虛擬網路的 ExpressRoute/VPN 連線通告的預設路由（邊界閘道通訊協定）：

a. 如果您有透過 BGP 與虛擬網路的 ExpressRoute/VPN 連線，而且您正在公告預設路由，您必須確定封包已路由回因特網目的地，而不需修改。您可以使用應用程式閘道入口網站中的 [連線 ion 疑難解答] 選項進行驗證。 b. 手動選擇目的地做為任何因特網可路由IP位址，例如1.1.1.1.1。將目的地埠設定為任何專案，並確認連線能力。 c. 如果下一個躍點是虛擬網路網關，可能會有透過 ExpressRoute 或 VPN 公告的預設路由。
如果虛擬網路上已設定自定義 DNS 伺服器，請確認伺服器可以解析公用網域。在應用程式閘道必須連絡 OCSP （線上憑證狀態通訊協定）伺服器等外部網域，或檢查憑證的撤銷狀態時，可能需要公用功能變數名稱解析。
若要確認應用程式閘道狀況良好且正在執行中，請移至入口網站中的 [資源健康狀態] 選項，並確認狀態為 [狀況良好]。如果您看到狀況不良或降級狀態，請連絡支持人員。
如果因特網和私人流量正經歷裝載於安全虛擬中樞的 Azure 防火牆（使用 Azure 虛擬 WAN 中樞）：

a. 若要確保應用程式閘道可以直接將流量傳送至因特網，請設定下列使用者定義的路由：

位址首碼：0.0.0.0/0
下一個躍點：Internet

b. 若要確保應用程式閘道可以透過虛擬 WAN 中樞中的 Azure 防火牆將流量傳送至後端集區，請設定下列使用者定義的路由：

地址前綴：後端集區子網
下一個躍點：Azure 防火牆私人IP位址

下一步

深入瞭解應用程式閘道診斷和記錄。