Felsöka problem med hälsotillstånd för Application Gateway

Översikt

Azure Application Gateway pingar som standard servrar i serverdelen för att kontrollera deras hälsostatus och att de är redo att hantera förfrågningar. Användare kan också skapa anpassade avsökningar för att nämna värdnamnet, sökvägen som ska avsökas och statuskoder som ska godkännas som felfria. Om backend-servern inte svarar korrekt markerar Application Gateway servern som Inte feltillstånd och slutar vidarebefordra begäranden till servern. När servern har börjat svara Application Gateway fortsätter vidarebefordran av begärandena.

Så här kontrollerar du hälsotillståndet för backend

Om du vill kontrollera hälsotillståndet för din backend-pool kan du använda sidan Backend Health Azure Portal. Du kan också använda Azure PowerShell, CLIeller REST API.

Statusen som hämtas av någon av dessa metoder kan vara något av följande:

• Felfri

• Ohälsosamt

• Okänt

Om serverserverns hälsostatus är Felfri innebär det att Application Gateway vidarebefordrar begärandena till den servern. Men om serverhälsan för alla servrar i en serverpool är Inte felskyddad eller okänd kan det uppstå problem när du försöker komma åt program. I den här artikeln beskrivs symptom, orsak och lösning för vart och ett av de fel som visas.

Hälsostatus för backend: Inte feltillstånd

Om hälsostatusen för backend är Inte felskyddad liknar portalvyn följande skärmbild:

Eller om du använder en Azure PowerShell-, CLI- eller Azure REST API-fråga får du ett svar som liknar följande:

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"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

När du får statusen Ej felande server för alla servrar i en serverpool vidarebefordras inte begäranden till servrarna och Application Gateway returnerar felet "502 Felaktig gateway" till den begärande klienten. Om du vill felsöka det här problemet kontrollerar du kolumnen Information på fliken Backend Health.

Meddelandet som visas i kolumnen Information ger mer detaljerad information om problemet och utifrån det kan du börja felsöka problemet.

Felmeddelanden

Tidsgräns för serverdel

Meddelande: Den tid det tar för backend att svara på Application Gateways hälsoavsökning är mer än ' tidsgränströskeln i avsökningsinställningen.

Orsaka: När Application Gateway skickar en HTTP(S)-avsökningsbegäran till backend-servern väntar den på ett svar från backend-servern under en konfigurerad period. Om serverdelsservern inte svarar inom den konfigurerade perioden (tidsgränsvärdet) markeras den som Inte felig tills den börjar svara inom den konfigurerade tidsgränsen igen.

Upplösning: Kontrollera varför serverdelsservern eller programmet inte svarar inom den konfigurerade tidsgränsen och kontrollera även programberoendena. Kontrollera till exempel om databasen har problem som kan utlösa en fördröjning i svaret. Om du är medveten om programmets beteende och det bara bör svara efter tidsgränsvärdet ökar du timeout-värdet från de anpassade avsökningsinställningarna. Du måste ha en anpassad avsökning för att ändra tidsgränsvärdet. Information om hur du konfigurerar en anpassad avsökning finns på dokumentationssidan.

Följ dessa steg om du vill öka timeout-värdet:

1. Öppna serversidan direkt och kontrollera hur lång tid det tar för servern att svara på den sidan. Du kan använda val annat verktyg för att få åtkomst till backend-servern, inklusive en webbläsare med hjälp av utvecklarverktyg.

2. När du har räknat ut hur lång tid det tar för programmet att svara väljer du fliken Hälsoavsökningar och väljer sedan den avsökning som är associerad med HTTP-inställningarna.

3. Ange ett timeout-värde som är större än programmets svarstid i sekunder.

4. Spara de anpassade avsökningsinställningarna och kontrollera om hälsotillståndet för backend visas som Felfritt nu.

DNS-lösningsfel

Meddelande: Application Gateway kunde inte skapa en avsökning för den här backend- Detta inträffar vanligtvis när det fullständiga domännamnet (FQDN) för serverdelen inte har angetts på korrekt sätt.

Orsaka: Om serverpoolen är av typen IP-adress/FQDN eller App Service matchar Application Gateway IP-adressen för det FQDN som anges via Domain Name System (DNS) (anpassad eller Azure-standard) och försöker ansluta till servern på TCP-porten som anges i HTTP-Inställningar. Men om det här meddelandet visas föreslår det att Application Gateway inte kunde matcha IP-adressen för det angivna FQDN:et.

Lösning:

1. Kontrollera att det FQDN som angetts i backend-poolen är korrekt och att det är en offentlig domän och försök sedan att matcha det från den lokala datorn.

2. Om du kan lösa IP-adressen kan det vara något fel med DNS-konfigurationen i det virtuella nätverket.

3. Kontrollera om det virtuella nätverket är konfigurerat med en anpassad DNS-server. Om den är det kontrollerar du om DNS-servern kan matchas mot IP-adressen för det angivna FQDN-namnet.

4. Om du använder Azures standard-DNS kontrollerar du med domännamnsregistratorn om korrekt A-post- eller CNAME-postmappning har slutförts.

5. Om domänen är privat eller intern kan du försöka matcha den från en virtuell dator i samma virtuella nätverk. Om du kan lösa det startar du Application Gateway och kontrollerar igen. Om du Application Gateway måste du stoppa och starta med hjälp av PowerShell-kommandona som beskrivs i dessa länkade resurser.

Uppdateringar av DNS-posterna i serverpoolen

Meddelande: Det gick inte att hämta hälsostatus för backend. Detta inträffar när en NSG/UDR/brandvägg i application gateway-undernätet blockerar trafik på portarna 65503-65534 för v1 SKU och portarna 65200-65535 för v2-SKU:n eller om det FQDN som konfigurerats i backend-poolen inte kunde matchas till en IP-adress. Mer information finns https://aka.ms/UnknownBackendHealth här: .

Orsaka: Application Gateway matchar DNS-posterna för serverpoolen vid tidpunkten för start och uppdaterar dem inte dynamiskt under körning.

Lösning:

Application Gateway måste startas om efter ändringar i DNS-posterna på serverservern för att börja använda de nya IP-adresserna. Den här åtgärden kan utföras via Azure PowerShell eller Azure CLI.

Azure PowerShell

# Get Azure Application Gateway
$appgw=Get-AzApplicationGateway -Name <appgw_name> -ResourceGroupName <rg_name>
 
# Stop the Azure Application Gateway
Stop-AzApplicationGateway -ApplicationGateway $appgw
 
# Start the Azure Application Gateway
Start-AzApplicationGateway -ApplicationGateway $appgw

Azure CLI

# Stop the Azure Application Gateway
az network application-gateway stop -n <appgw_name> -g <rg_name>

# Start the Azure Application Gateway
az network application-gateway start -n <appgw_name> -g <rg_name>

TCP-anslutningsfel

Meddelande: Application Gateway kunde inte ansluta till backend-datorn. Kontrollera att backend svarar på den port som används för avsökningen. Kontrollera också om någon NSG/UDR/brandvägg blockerar åtkomst till IP-adressen och porten för den här backend-datorn

Orsaka: Efter DNS-lösningsfasen Application Gateway att ansluta till serverservern på TCP-porten som har konfigurerats i HTTP-inställningarna. Om Application Gateway inte kan upprätta en TCP-session på den angivna porten markeras avsökningen som Inte felskyddad med det här meddelandet.

Lösning: Följ dessa steg om du får det här felet:

1. Kontrollera om du kan ansluta till backend-servern på den port som anges i HTTP-inställningarna med hjälp av en webbläsare eller PowerShell. Kör till exempel följande kommando: Test-NetConnection -ComputerName www.bing.com -Port 443

2. Om den port som anges inte är den önskade porten anger du rätt portnummer för Application Gateway ansluta till backend-servern

3. Om du inte kan ansluta på porten från den lokala datorn också gör du följande:

   a. Kontrollera inställningarna för nätverkssäkerhetsgruppen (NSG) för backend-serverns nätverkskort och undernät och om inkommande anslutningar till den konfigurerade porten tillåts. Om de inte är det skapar du en ny regel som tillåter anslutningarna. Information om hur du skapar NSG-regler finns på dokumentationssidan.

   b. Kontrollera om NSG-inställningarna för undernätet Application Gateway tillåter utgående offentlig och privat trafik, så att en anslutning kan upprättas. Mer information om hur du skapar NSG-regler finns på dokumentsidan i steg 3a.

           $vnet = Get-AzVirtualNetwork -Name "vnetName" -ResourceGroupName "rgName"
           Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
   

   c. Kontrollera inställningarna för användardefinierade vägar (UDR) Application Gateway och backend-serverns undernät för eventuella routningsavvikelser. Kontrollera att UDR inte dirigerar trafiken från backend-undernätet. Du kan till exempel söka efter vägar till virtuella nätverksutrustning eller standardvägar som annonseras till Application Gateway-undernätet via Azure ExpressRoute och/eller VPN.

   d. Om du vill kontrollera gällande vägar och regler för ett nätverkskort kan du använda följande PowerShell-kommandon:

           Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
           Get-AzEffectiveRouteTable -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
   

4. Om du inte hittar några problem med NSG eller UDR kontrollerar du om det finns programrelaterade problem på serverservern som hindrar klienter från att upprätta en TCP-session på de konfigurerade portarna. Några saker att kontrollera:

   a. Öppna en kommandotolk (Win+R - > cmd), ange netstat och välj Retur.

   b. Kontrollera om servern lyssnar på den konfigurerade porten. Exempel:

           Proto Local Address Foreign Address State PID
           TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
   

   c. Om den inte lyssnar på den konfigurerade porten kontrollerar du inställningarna för webbservern. Exempel: webbplatsbindningar i IIS, serverblock i NGINX och virtuell värd i Apache.

   d. Kontrollera inställningarna för operativsystemets brandvägg för att se till att inkommande trafik till porten tillåts.

Matchningsfel för HTTP-statuskod

Meddelande: Statuskoden för http-svaret ' för backend matchar inte avsökningsinställningen. Expected:{HTTPStatusCode0} Received:{HTTPStatusCode1}.

Orsaka: När TCP-anslutningen har upprättats och en TLS-handskakning är klar (om TLS är aktiverat) skickar Application Gateway avsökningen som en HTTP GET-begäran till serverservern. Som tidigare beskrivits kommer standardavsökningen att vara <protocol> till ://127.0.0.1: /, och den betraktar svarsstatuskoder i <port> 200 till 399 som Felfri. Om servern returnerar någon annan statuskod markeras den som Inte feltillstånd med det här meddelandet.

Lösning: Beroende på serverserverns svarskod kan du göra följande. Några av de vanliga statuskoderna visas här:

Om du tror att svaret är giltigt och du vill Application Gateway godkänna andra statuskoder som Felfri kan du skapa en anpassad avsökning. Den här metoden är användbar i situationer där serversidans webbplats behöver autentisering. Eftersom avsökningsbegäranden inte innehåller några användarautentiseringsuppgifter misslyckas de och en HTTP 401-statuskod returneras av backend-servern.

Följ dessa steg om du vill skapa en anpassad avsökning.

Matchningsfel för HTTP-svarstext

Meddelande: Brödtexten i ' http-svaret för backend matchar inte avsökningsinställningen. Mottagen svarstext innehåller inte {string}.

Orsaka: När du skapar en anpassad avsökning kan du markera en serverdelsserver som Felfri genom att matcha en sträng från svarstexten. Du kan till exempel konfigurera Application Gateway godkänna "obehörig" som en sträng som ska matchas. Om serversvaret för avsökningsbegäran innehåller strängen obehörig markeras den som Felfri. Annars markeras den som Inte feltillstånd med det här meddelandet.

Lösning: Följ dessa steg för att lösa problemet:

1. Öppna serverdelen lokalt eller från en klientdator på avsökningssökvägen och kontrollera svarstexten.

2. Kontrollera att svarstexten i Application Gateway anpassade avsökningskonfigurationen matchar det som har konfigurerats.

3. Om de inte matchar ändrar du avsökningskonfigurationen så att den har rätt strängvärde att acceptera.

Läs mer om Application Gateway avsökningsmatchning.

Ogiltig certifikatutfärdare för serverserver

Meddelande: Servercertifikatet som används av serverservern är inte signerat av en välkänd certifikatutfärdare (CA). Tillåt serverservern på Application Gateway genom att ladda upp rotcertifikatet för servercertifikatet som används av serverservern.

Orsaka: Ssl från Application Gateway v2 kräver att serverserverns certifikat verifieras för att servern ska anses vara felfri. För att ett TLS-/SSL-certifikat ska vara betrott måste certifikatet på backend-servern utfärdas av en certifikatutfärdare som ingår i det betrodda arkivet för Application Gateway. Om certifikatet inte har utfärdats av en betrodd certifikatutfärdare (till exempel om ett själv signerat certifikat har använts) bör användarna ladda upp utfärdarens certifikat till Application Gateway.

Lösning: Följ dessa steg för att exportera och ladda upp det betrodda rotcertifikatet till Application Gateway. (De här stegen är Windows klienter.)

1. Logga in på den dator där programmet finns.

2. Välj Win+R eller högerklicka på knappen Start och välj sedan Kör.

3. Ange certmgr.msc och välj Retur. Du kan också söka efter Certifikathanteraren på Start-menyn.

4. Leta upp certifikatet, vanligtvis \Certificates - Current User\\Personal\\Certificates\ i , och öppna det.

5. Välj rotcertifikatet och välj sedan Visa certifikat.

6. I Egenskaper för certifikat väljer du fliken Information.

7. På fliken Information väljer du alternativet Kopiera till fil och sparar filen i base-64-kodad X.509 (. CER)-format.

8. Öppna http Application Gateway Inställningar sidan i Azure Portal.

9. Öppna HTTP-inställningarna, välj Lägg till certifikat och leta upp den certifikatfil som du nyss sparade.

10. Välj Spara för att spara HTTP-inställningarna.

Du kan också exportera rotcertifikatet från en klientdator genom att direkt komma åt servern (kringgå Application Gateway) via webbläsaren och exportera rotcertifikatet från webbläsaren.

Mer information om hur du extraherar och laddar upp betrodda rotcertifikat i Application Gateway finns i Exportera betrott rotcertifikat (för v2 SKU).

Felmatchning i betrott rotcertifikat

Meddelande: Rotcertifikatet för servercertifikatet som används av serverservern matchar inte det betrodda rotcertifikatet som lagts till i programgatewayen. Se till att du lägger till rätt rotcertifikat för att tillåta att server slutet listas.

Orsaka: Ssl från Application Gateway v2 kräver att serverserverns certifikat verifieras för att servern ska anses vara felfri. För att ett TLS-/SSL-certifikat ska vara betrott måste servercertifikatet utfärdas av en certifikatutfärdare som ingår i det betrodda arkivet för Application Gateway. Om certifikatet inte har utfärdats av en betrodd certifikatutfärdare (till exempel om ett själv signerat certifikat har använts) bör användarna ladda upp utfärdarens certifikat till Application Gateway.

Certifikatet som har laddats upp till Application Gateway HTTP-inställningarna måste matcha rotcertifikatet för servercertifikatet.

Lösning: Om du får det här felmeddelandet finns det ett matchningsfel mellan certifikatet som har laddats upp till Application Gateway och det som laddades upp till backend-servern.

Följ steg 1–11 i föregående metod för att ladda upp rätt betrott rotcertifikat till Application Gateway.

Mer information om hur du extraherar och laddar upp betrodda rotcertifikat i Application Gateway finns i Exportera betrott rotcertifikat (för v2 SKU).

Exempel:

OpenSSL> s_client -connect 10.0.0.4:443 -servername www.example.com -showcerts

Om utdata inte visar hela kedjan av certifikatet som returneras exporterar du certifikatet igen med hela kedjan, inklusive rotcertifikatet. Konfigurera certifikatet på serverservern.

  CONNECTED(00000188)\
  depth=0 OU = Domain Control Validated, CN = \*.example.com\
  verify error:num=20:unable to get local issuer certificate\
  verify return:1\
  depth=0 OU = Domain Control Validated, CN = \*.example.com\
  verify error:num=21:unable to verify the first certificate\
  verify return:1\
  \-\-\-\
  Certificate chain\
   0 s:/OU=Domain Control Validated/CN=*.example.com\
     i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2\
  \-----BEGIN CERTIFICATE-----\
  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\
  \-----END CERTIFICATE-----

Ogiltigt eget namn (CN) för servercertifikat

Meddelande: Serverdatorns eget namn (CN) matchar inte avsökningens värdrubrik.

Orsaka: Application Gateway kontrollerar om värdnamnet som anges i HTTP-inställningarna för serverplatsen matchar det CN som presenteras av serverserverns TLS/SSL-certifikat. Detta är Standard_v2 och WAF_v2 SKU (V2). Standard- och WAF-SKU:erna (v1) Servernamnindikator (SNI) anges som FQDN i adressen för backend-poolen. Mer information om SNI-beteende och skillnader mellan v1 och v2 SKU finns i Översikt över TLS-avslutningoch TLS från Application Gateway .

Om det finns en standardavsökning i v2-SKU:n (ingen anpassad avsökning har konfigurerats och associerats) anges SNI från det värdnamn som anges i HTTP-inställningarna. Eller om "Välj värdnamn från backend-adress" anges i HTTP-inställningarna, där backend-adresspoolen innehåller ett giltigt FQDN, tillämpas den här inställningen.

Om det finns en anpassad avsökning som är associerad med HTTP-inställningarna anges SNI från det värdnamn som anges i konfigurationen för anpassad avsökning. Om Välj värdnamn från HTTP-inställningar för backend har valts i den anpassade avsökningen, anges SNI från värdnamnet som anges i HTTP-inställningarna.

Om Välj värdnamn från backend-adress har angetts i HTTP-inställningarna måste backend-adresspoolen innehålla ett giltigt FQDN.

Om du får det här felmeddelandet matchar inte CN för servercertifikatet värdnamnet som konfigurerats i den anpassade avsökningen eller HTTP-inställningarna (om Välj värdnamn från HTTP-inställningarna för serverdatorn har valts). Om du använder en standardavsökning anges värdnamnet som 127.0.0.1. Om det inte är ett önskat värde bör du skapa en anpassad avsökning och associera den med HTTP-inställningarna.

Lösning:

Följ dessa anvisningar för att lösa problemet.

För Windows:

1. Logga in på den dator där programmet finns.

2. Välj Win+R eller högerklicka på knappen Start och välj Kör.

3. Ange certmgr.msc och välj Retur. Du kan också söka efter Certifikathanteraren på Start-menyn.

4. Leta upp certifikatet (vanligtvis \Certificates - Current User\\Personal\\Certificates i ) och öppna certifikatet.

5. På fliken Information kontrollerar du certifikatets ämne.

6. Kontrollera certifikatets CN från informationen och ange samma i fältet värdnamn i den anpassade avsökningen eller i HTTP-inställningarna (om Välj värdnamn från HTTP-inställningar för serverdatorn har valts). Om det inte är det önskade värdnamnet för din webbplats måste du hämta ett certifikat för domänen eller ange rätt värdnamn i konfigurationen för anpassad avsökning eller HTTP-inställning.

För Linux med OpenSSL:

1. Kör det här kommandot i OpenSSL:

   openssl x509 -in certificate.crt -text -noout
   

2. Leta reda på certifikatets CN från egenskaperna som visas och ange samma i fältet värdnamn i http-inställningarna. Om det inte är det önskade värdnamnet för din webbplats måste du hämta ett certifikat för domänen eller ange rätt värdnamn i konfigurationen för anpassad avsökning eller HTTP-inställning.

Servercertifikatet är ogiltigt

Meddelande: Servercertifikatet är ogiltigt. Aktuellt datum ligger inte inom " giltigt " " från- och giltigt " datumintervall för certifikatet.

Orsaka: Varje certifikat har ett giltighetsintervall och HTTPS-anslutningen är inte säker om inte serverns TLS/SSL-certifikat är giltigt. Aktuella data måste vara inom giltiga från och giltiga till intervallet. Om det inte är det betraktas certifikatet som ogiltigt och det skapar ett säkerhetsproblem där Application Gateway markerar serverservern som Inte felskyddad.

Lösning: Om ditt TLS/SSL-certifikat har upphört att gälla förnyar du certifikatet med leverantören och uppdaterar serverinställningarna med det nya certifikatet. Om det är ett själv signerat certifikat måste du generera ett giltigt certifikat och ladda upp rotcertifikatet till Application Gateway HTTP-inställningarna. Det gör du genom att följa dessa steg:

1. Öppna ditt Application Gateway HTTP-inställningar i portalen.

2. Välj den inställning som har det utgångna certifikatet, välj Lägg till certifikat och öppna den nya certifikatfilen.

3. Ta bort det gamla certifikatet med hjälp av ikonen Ta bort bredvid certifikatet och välj sedan Spara.

Certifikatverifieringen misslyckades

Meddelande: Det gick inte att verifiera certifikatets giltighet. Om du vill ta reda på orsaken kontrollerar du OpenSSL-diagnostiken för meddelandet som är associerat med felkoden {errorCode}

Orsaka: Det här felet uppstår Application Gateway det inte går att verifiera certifikatets giltighet.

Lösning: Lös problemet genom att kontrollera att certifikatet på servern har skapats korrekt. Du kan till exempel använda OpenSSL för att verifiera certifikatet och dess egenskaper och sedan försöka att ladda om certifikatet till Application Gateway HTTP-inställningarna.

Hälsostatus för backend: okänd

Om hälsotillståndet för backend visas som Okänt liknar portalvyn följande skärmbild:

Det här beteendet kan inträffa av en eller flera av följande orsaker:

1. NSG:n i Application Gateway-undernätet blockerar inkommande åtkomst till portarna 65503-65534 (v1 SKU) eller 65200-65535 (v2 SKU) från "Internet".
2. UDR på Application Gateway-undernätet är inställt på standardvägen (0.0.0.0/0) och nästa hopp har inte angetts som "Internet".
3. Standardvägen annonseras av en ExpressRoute-/VPN-anslutning till ett virtuellt nätverk via BGP.
4. Den anpassade DNS-servern är konfigurerad i ett virtuellt nätverk som inte kan matcha offentliga domännamn.
5. Application Gateway är i ett feltillstånd.

Lösning:

1. Kontrollera om din NSG blockerar åtkomst till portarna 65503-65534 (v1 SKU) eller 65200-65535 (v2 SKU) från Internet:

   a. På Application Gateway fliken Översikt väljer du länken Virtual Network/undernät.

   b. På fliken Undernät i det virtuella nätverket väljer du det undernät där Application Gateway har distribuerats.

   c. Kontrollera om någon NSG har konfigurerats.

   d. Om en NSG har konfigurerats söker du efter den NSG-resursen på fliken Sök eller under Alla resurser.

   e. I avsnittet Regler för inkommande trafik lägger du till en regel för inkommande trafik som tillåter målportintervallet 65503-65534 för v1-SKU eller 65200-65535 v2-SKU:n med källuppsättningen Valfri eller Internet.

   f. Välj Spara och kontrollera att du kan visa backend som Felfri. Du kan också göra det via PowerShell/CLI.

2. Kontrollera om din UDR har en standardväg (0.0.0.0/0) med nästa hopp inte inställt som Internet:

   a. Följ steg 1a och 1b för att fastställa undernätet.

   b. Kontrollera om det finns någon konfigurerad UDR. Om det finns det söker du efter resursen i sökfältet eller under Alla resurser.

   c. Kontrollera om det finns några standardvägar (0.0.0.0/0) med nästa hopp inte inställt på Internet. Om inställningen antingen är virtuell installation eller Virtual Network Gateway måste du se till att den virtuella installationen eller den lokala enheten korrekt kan dirigera paketet tillbaka till Internetmålet utan att ändra paketet.

   d. Annars ändrar du nästa hopp till Internet, väljer Spara och verifierar hälsotillståndet för backend.

3. Standardväg som annonseras av ExpressRoute/VPN-anslutningen till det virtuella nätverket via BGP:

   a. Om du har en ExpressRoute-/VPN-anslutning till det virtuella nätverket via BGP, och om du annonserar en standardväg, måste du se till att paketet dirigeras tillbaka till Internetmålet utan att ändra det. Du kan verifiera med hjälp av alternativet Felsöka anslutning i Application Gateway portalen.

   b. Välj målet manuellt som valfri Internet-dirigerbar IP-adress som 1.1.1.1. Ange målporten som vad som helst och verifiera anslutningen.

   c. Om nästa hopp är en virtuell nätverksgateway kan det finnas en standardväg som annonseras via ExpressRoute eller VPN.

4. Om det finns en anpassad DNS-server konfigurerad i det virtuella nätverket kontrollerar du att servern (eller servrarna) kan matcha offentliga domäner. Offentlig domännamnsmatchning kan krävas i scenarier där Application Gateway måste kontakta externa domäner som OCSP-servrar eller för att kontrollera certifikatets återkallningsstatus.

5. Kontrollera att Application Gateway är felfri och körs genom att Resource Health alternativet i portalen och kontrollera att tillståndet är Felfritt. Kontakta supporten om tillståndet Inte feltillstånd eller degraderat visas.

Nästa steg

Läs mer om Application Gateway diagnostik och loggning.