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

發行項
10/01/2024

概觀

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

如何檢查後端健康情況

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

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

Healthy
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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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. 如果其並未在設定的連接埠上接聽，請檢查您的 Web 伺服器設定。例如：IIS 中的網站繫結、NGINX 中的伺服器區塊，以及 Apache 中的虛擬主機。

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

HTTP 狀態碼不符

訊息：後端 HTTP 回應的狀態碼與探查設定不相符。預期：{HTTPStatusCode0} 收到：{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. 輸入 certmgr.msc 並選取 Enter。您也可以在 [開始] 功能表上搜尋 [憑證管理員]。
4. 找到憑證 (通常位於「憑證-本機電腦\個人\憑證」)，並且開啟憑證。
5. 在 [詳細資料] 索引標籤上，檢查憑證 [主旨]。
藉由登入後端伺服器 (Linux)：藉由指定正確的憑證檔案名稱 openssl x509 -in certificate.crt -subject -noout 來執行此 OpenSSL 命令

後端憑證已過期

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

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

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

針對 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. 輸入 certmgr.msc 並選取 Enter。您也可以在 [開始] 功能表上搜尋 [憑證管理員]。
4. 找到憑證 (通常位於「憑證-本機電腦\個人\憑證」)，然後開啟憑證。
5. 選取根憑證，然後選取 [檢視憑證]。
6. 在 [憑證屬性] 中，選取 [詳細資料] 索引標籤，並且按兩下 [複製到檔案]，
7. 在 [憑證匯出精靈] 頁面上，按一下 [下一步]，
8. 選取 [Base-64 編碼的 X.509 (.CER)]，並且按一下 [下一步]，
9. 提供新的檔案名稱，並且按一下 [下一步]，
10. 按兩下 [完成] 以取得 .CER 檔案。
11. 上傳私人 CA 的根憑證 (.CER) 到應用程式閘道的後端設定。

分葉必須在鏈結的最上層。

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

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

解決方案：後端伺服器上的憑證安裝必須包括憑證排序清單，其中包括分葉憑證及其全部簽署憑證 (中繼 CA 憑證和根 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/防火牆在 v1 SKU 的情況下封鎖連接埠 65503-65534 上的流量，以及 v2 SKU 的連接埠 65200-65535，或後端集區中設定的 FQDN 無法解析為 IP 位址時，就會發生這種情況。若要深入了解，請瀏覽 - https://aka.ms/UnknownBackendHealth。

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

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

其他原因

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

應用程式閘道後端健康情況 - 未知

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

應用程式閘道子網路上的 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. 在 [輸入規則] 區段中，新增輸入規則以允許 [來源] 設為 GatewayManager 服務標籤的目的地連接埠範圍 65503-65534 (適用於 v1 SKU) 或 65200-65535 (適用於 v2 SKU)。 f. 選取 [儲存]，並確認您可以將後端視為「良好」。或者，您也可以透過 PowerShell/CLI 來執行此作業。
檢查您的 UDR 是否有下一個躍點未設定為 [網際網路] 的預設路由 (0.0.0.0/0)：

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

a. 如果您有透過 BGP 對虛擬網路的 ExpressRoute/VPN 連線，而且您要公告預設路由，則必須確定封包會路由傳送回到網際網路目的地，而不需進行修改。您可使用應用程式閘道入口網站中的 [連線疑難排解] 選項來進行確認。 b. 手動將目的地選擇為任何可從網際網路路由傳送的 IP 位址，例如 1.1.1.1。將目的地連接埠設定為任何連接埠，並確認連線能力。 c. 如果下一個躍點是虛擬網路閘道，則可能會有透過 ExpressRoute 或 VPN 公告的預設路由。
如果虛擬網路上已設定自訂 DNS 伺服器，請確認該伺服器可解析公用網域。在應用程式閘道必須連絡 OCSP （線上憑證狀態通訊協定）伺服器等外部網域，或檢查憑證的撤銷狀態時，可能需要公用功能變數名稱解析。
若要確認應用程式閘道狀況良好且正在執行，請移至入口網站中的 [資源健康情況] 選項，並確認狀態為 [良好]。如果您看到 [狀況不良] 或 [已降級] 狀態，請連絡支援部門。
如果網際網路和私人流量透過託管在安全虛擬中心 (使用 Azure Virtual WAN Hub) 中的 Azure 防火牆：

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

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

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

位址首碼：後端集區子網路
下一個躍點：Azure 防火牆私人 IP 位址

注意

如果應用程式閘道無法存取 CRL 端點，它可能會將後端健康情況狀態標示為「未知」。若要避免這些問題，請檢查您的應用程式閘道子網是否能夠存取 crl.microsoft.com 和 crl3.digicert.com。您可以藉由設定網路安全組將流量傳送至 CRL 端點來完成。

下一步

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

共用方式為