Felsöka Azure Front Door vanliga problem

  • Artikel
  • 3 minuter för att läsa

Den här artikeln beskriver hur du felsöker vanliga routningsproblem som kan uppstå för din Azure Front Door konfiguration.

Ytterligare felsökning av HTTP-huvuden

Du kan begära Front Door returnera ytterligare HTTP-svarshuvuden för felsökning. Mer information finns i valfria svarshuvuden.

503-svar Azure Front Door efter några sekunder

Symptom

  • Regelbundna begäranden som skickas till din backend utan att gå Azure Front Door går igenom dem lyckas. Om du går Azure Front Door 503-felsvar.
  • Felet från den Azure Front Door visas vanligtvis efter cirka 30 sekunder.
  • Tillfälliga 503-fel med logg ErrorInfo: OriginInvalidResponse .

Orsak

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

  • Ursprunget tar längre tid än den konfigurerade tidsgränsen (standard är 30 sekunder) att ta emot begäran från Azure Front Door.
  • Den tid det tar att skicka ett svar på begäran Azure Front Door tar längre tid än tidsgränsvärdet.
  • Klienten skickade en byteintervallbegäran med Accept-Encoding header (komprimering aktiverat).

Felsökningsanvisningar

  • Skicka begäran till din backend direkt (utan att gå Azure Front Door). Se hur lång tid det vanligtvis tar för din backend 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. Kontakta supporten.

  • Om begäranden som går Azure Front Door resulterar i en 503-felsvarskod konfigurerar du origin-tidsgränsen (i sekunder) för slutpunkten. Du kan utöka standardtidsinställningen till upp till 4 minuter (240 sekunder). Du kan konfigurera inställningen genom att gå till Slutpunktshanteraren och välja Redigera slutpunkt.

    Skärmbild av val av redigeringsslutpunkt från Slutpunktshanteraren.

    Välj sedan Slutpunktsegenskaper för att konfigurera tidsgränsen för origin-svar:

    Skärmbild av val av slutpunktsegenskaper och fältet Origin response timeout (Tidsgräns för ursprungssvar).

  • Om tidsgränsen inte löser problemet kan du använda ett verktyg som Fiddler eller webbläsarens utvecklarverktyg för att kontrollera om klienten skickar byteintervallbegäranden med Accept-Encoding-huvuden, vilket leder till att ursprunget svarar med olika innehållslängder. Om ja, kan du antingen inaktivera komprimering på ursprungs-/Azure Front Door eller skapa en regel för regeluppsättning för att ta bort från begäran accept-encoding om byteintervallbegäranden.

    Skärmbild av regeln för accept-encoding i en regeluppsättning.

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

Symptom

  • Du har skapat Azure Front Door instans, men en begäran till domänen eller frontend-värden returnerar en HTTP 400-statuskod.
  • Du har skapat en DNS-mappning för en anpassad domän till den frontend-värd som du har konfigurerat. Men om du skickar en begäran till det anpassade domännamnet returneras statuskoden HTTP 400. Det verkar inte som om den dirigeras till den backend som du har konfigurerat.

Orsak

Problemet uppstår om du inte har konfigurerat en routningsregel för den anpassade domänen som har lagts till som frontend-värd. En routningsregel måste uttryckligen läggas till för den frontend-värden. Det stämmer även om en routningsregel redan har konfigurerats för frontend-värden under Azure Front Door underdomänen (*.azurefd.net).

Felsökningsanvisningar

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 åtkomst 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. I princip är din aktuella konfiguration inte specifik och kan ha motstridiga regler.

Felsökningsanvisningar

Begäran till värdnamnet för frontend returnerar statuskoden 411

Symptom

Du skapade en Azure Front Door Standard/Premium-instans och konfigurerade en frontend-värd, en ursprungsgrupp med minst ett ursprung och en routningsregel som ansluter frontend-värden till ursprungsgruppen. Innehållet verkar inte vara tillgängligt när en begäran skickas till den konfigurerade frontend-vä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. Exempel: HTTP Error 411. The request must be chunked or have a content length.

Orsak

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

Ett exempel på inkompatibilitet är en begäran POST som skickas utan antingen ett - eller Content-Length Transfer-Encoding -huvud (till exempel med hjälp av curl -X POST https://example-front-door.domain.com ). Den här begäran uppfyller inte kraven som anges i RFC 7230. Azure Front Door blockerar den med ett HTTP 411-svar.

Det här beteendet skiljer sig från Web Application Firewall (WAF) i Azure Front Door. Det finns för närvarande 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 uppfyller kraven som anges i de nödvändiga RFC:erna.

  • Anteckna HTML-meddelandetexten som returneras som svar på din begäran. En meddelandetext förklarar ofta exakt hur din begäran inte är kompatibel.

Nästa steg