Dela via

Felsöka vanliga problem med Azure Front Door

  • Artikel

I den här artikeln beskrivs hur du felsöker vanliga routningsproblem som du kan stöta på för din Azure Front Door-konfiguration.

Andra felsöknings-HTTP-huvuden

Du kan begära att Azure Front Door returnerar extra felsökande HTTP-svarshuvuden. Mer information finns i valfria svarshuvuden.

503- eller 504-svar från Azure Front Door efter några sekunder

Symptom

  • Regelbundna begäranden som skickas till serverdelen utan att gå via Azure Front Door lyckas. Om du går igenom Azure Front Door får du 503- eller 504-felsvar.
  • Felet från Azure Front Door visas vanligtvis efter cirka 30 sekunder.
  • Tillfälliga 503-fel visas med "ErrorInfo: OriginInvalidResponse".

Orsak

Orsaken till det här problemet kan vara en av tre saker:

  • Ditt ursprung tar längre tid än tidsgränsen som konfigurerats för att ta emot begäran från Azure Front Door. Standardtimeouten är 30 sekunder.
  • Den tid det tar att skicka ett svar på begäran från Azure Front Door tar längre tid än tidsgränsvärdet.
  • Klienten skickade en byteintervallbegäran med ett accept-Encoding-huvud, vilket innebär att komprimering är aktiverat.

Felsökningsanvisningar

  • Skicka begäran direkt till ditt ursprung utan att gå via Azure Front Door. Se hur lång tid ditt ursprung normalt tar att svara.

  • Skicka begäran via Azure Front Door och se om du får några 503-svar. Annars kanske problemet inte är ett timeout-problem. Skapa en supportbegäran för att felsöka problemet ytterligare.

  • Om begäranden som går via Azure Front Door resulterar i en 503-felsvarskod konfigurerar du tidsgränsen för Origin-svar för Azure Front Door. Du kan öka standardtidsgränsen till upp till 4 minuter (240 sekunder). Om du vill konfigurera inställningen går du till sidan Översikt för Front Door-profilen. Välj Tidsgräns för ursprungssvar och ange ett värde mellan 16 och 240 sekunder.

    Kommentar

    Möjligheten att konfigurera tidsgränsen för Origin-svar är endast tillgänglig i Azure Front Door Standard/Premium.

    Skärmbild av tidsgränsinställningarna för ursprung på översiktssidan för Azure Front Door-profilen.

  • Om du inte löser problemet genom att öka tidsgränsen använder du ett verktyg som Fiddler eller webbläsarens utvecklarverktyg för att kontrollera om klienten skickar byteintervallbegäranden med Accept-Encoding-huvuden . Det här alternativet leder till att ursprunget svarar med olika innehållslängder.

    Om klienten skickar byteintervallbegäranden med Accept-Encoding-huvuden har du två alternativ. Det första alternativet är att inaktivera komprimering av origo eller Azure Front Door. Det andra alternativet är att skapa en regeluppsättningsregel för att ta bort Accept-Encoding från begäran för byteintervallbegäranden.

    Skärmbild som visar regeln Accept-Encoding i en regeluppsättning.

503 svar från Azure Front Door endast för HTTPS

Symptom

  • Alla 503-svar returneras endast för HTTPS-aktiverade AZURE Front Door-slutpunkter.
  • Regelbundna begäranden som skickas till serverdelen utan att gå via Azure Front Door lyckas. Att gå via Azure Front Door resulterar i 503-felsvar.
  • Tillfälliga 503-fel visas med "ErrorInfo: OriginInvalidResponse".

Orsak

Orsaken till det här problemet kan vara en av tre saker:

  • Serverdelspoolen är en IP-adress.
  • Serverdelsservern returnerar ett certifikat som inte matchar det fullständigt kvalificerade domännamnet (FQDN) för Azure Front Door-serverdelspoolen.
  • Serverdelspoolen är en Azure Web Apps-server.

Felsökningsanvisningar

  • Serverdelspoolen är en IP-adress.

    EnforceCertificateNameCheck måste inaktiveras.

    Azure Front Door har en växel som heter EnforceCertificateNameCheck. Som standard är den här inställningen aktiverad. När det är aktiverat kontrollerar Azure Front Door att serverdelspoolens värdnamn FQDN matchar serverdelsservercertifikatets certifikatnamn eller någon av posterna i tillägg för alternativa namn för ämne.

    • Så här inaktiverar du EnforceCertificateNameCheck från Azure-portalen:

      I portalen använder du en växlingsknapp för att aktivera eller inaktivera den här inställningen i fönstret Azure Front Door (klassisk) Design .

      Skärmbild som visar växlingsknappen.

      För Azure Front Door Standard- och Premium-nivån finns den här inställningen i ursprungsinställningarna när du lägger till ett ursprung i en ursprungsgrupp eller konfigurerar en väg.

      Skärmbild av kryssrutan validering av certifikatmottagarens namn.

  • Serverdelsservern returnerar ett certifikat som inte matchar FQDN för Azure Front Door-serverdelspoolen. För att lösa det här problemet har du två alternativ:

    • Det returnerade certifikatet måste matcha det fullständiga domännamnet.
    • EnforceCertificateNameCheck måste inaktiveras.

  • Serverdelspoolen är en Azure Web Apps-server:

    • Kontrollera om Azure-webbappen har konfigurerats med IP-baserad SSL i stället för att vara SNI-baserad (servernamnindikering). Om webbappen är konfigurerad som IP-baserad bör den ändras till SNI.
    • Om serverdelen inte är felfri på grund av ett certifikatfel returneras ett 503-felmeddelande. Du kan kontrollera hälsotillståndet för serverdelarna på portarna 80 och 443. Om endast 443 är felfritt är det troligtvis ett problem med SSL. Eftersom serverdelen är konfigurerad för att använda FQDN vet vi att den skickar SNI.

    Använd OPENSSL för att verifiera certifikatet som returneras. Om du vill göra den här kontrollen ansluter du till serverdelen med hjälp -servernameav . Den bör returnera SNI:n, som måste matcha med det fullständiga domännamnet för serverdelspoolen:

    openssl s_client -connect backendvm.contoso.com:443 -servername backendvm.contoso.com

Begäranden som skickas till den anpassade domänen returnerar en 400-statuskod

Symptom

  • Du har skapat en Azure Front Door-instans. En begäran till domänen eller klientdelsvärden returnerar en HTTP 400-statuskod.
  • Du har skapat en DNS-mappning (domännamnsserver) för en anpassad domän till den klientdelsvärd som du har konfigurerat. Om du skickar en begäran till det anpassade domännamnet returneras en HTTP 400-statuskod. Den verkar inte dirigeras till den serverdel som du har konfigurerat.

Orsak

Problemet uppstår om du inte konfigurerade en routningsregel för den anpassade domän som lades till som klientdelsvärd. En routningsregel måste uttryckligen läggas till för den klientdelsvärden. Du måste skapa regeln även om en routningsregel redan har konfigurerats för klientdelsvärden under Azure Front Door-underdomänen, som är *.azurefd.net.

Felsökningssteg

Lägg till en routningsregel för den anpassade domänen för att dirigera trafik till den valda ursprungsgruppen.

Azure Front Door omdirigerar inte HTTP till HTTPS

Symptom

Azure Front Door har en routningsregel som omdirigerar HTTP till HTTPS, men åtkomsten till domänen har fortfarande HTTP som protokoll.

Orsak

Det här beteendet kan inträffa om du inte har konfigurerat routningsreglerna korrekt för Azure Front Door. Den aktuella konfigurationen är inte specifik och kan ha motstridiga regler.

Felsökningsanvisningar

Begäran till klientdelsvärdnamnet returnerar statuskoden 411

Symptom

Du har skapat en Azure Front Door Standard/Premium-instans och konfigurerat:

  • En klientdelsvärd.
  • En ursprungsgrupp med minst ett ursprung i den.
  • En routningsregel som ansluter klientdelsvärden till ursprungsgruppen.

Innehållet verkar inte vara tillgängligt när en begäran skickas till den konfigurerade klientdelsvärden eftersom en HTTP 411-statuskod returneras.

Svar på dessa begäranden kan också innehålla en HTML-felsida i svarstexten som innehåller en förklarande instruktion. Ett exempel är "HTTP-fel 411. Begäran måste vara segmenterad eller ha en innehållslängd."

Orsak

Det finns flera möjliga orsaker till detta symptom. Den övergripande orsaken är att HTTP-begäran inte är helt RFC-kompatibel.

Ett exempel på inkompatibilitet är en POST begäran som skickas utan antingen en innehållslängd eller ett överföringskodningshuvud . Ett exempel skulle vara att använda curl -X POST https://example-front-door.domain.com. Den här begäran uppfyller inte kraven i RFC 7230. Azure Front Door blockerar det med ett HTTP 411-svar. Sådana begäranden loggas inte.

Det här beteendet är skilt från waf-funktionerna (web application firewall) i Azure Front Door. För närvarande finns det inget sätt att inaktivera det här beteendet. Alla HTTP-begäranden måste uppfylla kraven, även om WAF-funktionen inte används.

Felsökningsanvisningar

  • Kontrollera att dina begäranden är i överensstämmelse med de krav som anges i de nödvändiga RFC:erna.
  • Anteckna alla HTML-meddelandetexter som returneras som svar på din begäran. En meddelandetext förklarar ofta exakt hur din begäran inte är kompatibel.

Mitt ursprung är konfigurerat som en IP-adress.

Symptom

Ursprunget konfigureras som en IP-adress. Ursprunget är felfritt, men avvisar begäranden från Azure Front Door.

Orsak

Azure Front Door-användare ursprungsvärdnamnet som SNI-huvud under SSL-handskakning. Eftersom ursprunget har konfigurerats som en IP-adress kan felet vara en av följande orsaker:

  • Om kontrollen av certifikatnamnet är inaktiverad är det möjligt att orsaken till problemet ligger i ursprungscertifikatlogik. Den här logiken kanske avvisar alla begäranden som inte har ett giltigt värdhuvud som matchar certifikatet.

Felsökningsanvisningar

Ändra ursprunget från en IP-adress till ett FQDN till vilket ett giltigt certifikat utfärdas som matchar ursprungscertifikatet.

Nästa steg