Řešení Azure Front Door běžných problémů

  • Článek
  • 3 min ke čtení

Tento článek popisuje, jak řešit běžné problémy se směrováním, se Azure Front Door konfigurace.

Další hlavičky protokolu HTTP pro ladění

Můžete požádat o Front Door, aby vrátil další hlavičky odpovědi HTTP pro ladění. Další podrobnosti najdete v volitelných hlavičkách odpovědi.

Odpověď 503 z Azure Front Door po několika sekundách

Příznak

  • Pravidelné požadavky odeslané do back-endu bez nutnosti procházet Azure Front Door jsou úspěšné. Při Azure Front Door výsledkem je 503 odpovědí na chyby.
  • Selhání z Azure Front Door se obvykle zobrazuje přibližně po 30 sekundách.
  • Občasné chyby 503 s protokolem ErrorInfo: OriginInvalidResponse .

Příčina

Příčinou tohoto problému může být jedna ze tří věcí:

  • Příjem požadavku od uživatele trvá déle, než je nakonfigurovaný časový limit (výchozí hodnota je 30 sekund) Azure Front Door.
  • Odeslání odpovědi na požadavek z Azure Front Door trvá déle, než je hodnota časového limitu.
  • Klient odeslal požadavek na rozsah byte pomocí Accept-Encoding header (povolená komprese).

Postup při řešení potíží

  • Odešlete požadavek přímo do back-endu (bez nutnosti procházet Azure Front Door). Podívejte se, jak dlouho obvykle back-endu trvá reagovat.

  • Odešlete požadavek prostřednictvím Azure Front Door a podívejte se, jestli se vám ne zobrazí nějaké odpovědi 503. Pokud ne, problémem nemusí být problém s časovým limitem. Obraťte se na podporu.

  • Pokud výsledkem požadavků Azure Front Door kód odpovědi chyby 503, nakonfigurujte časový limit odpovědi zdroje (v sekundách) pro koncový bod. Výchozí časový limit můžete prodloužit až na 4 minuty (240 sekund). Nastavení můžete nakonfigurovat tak, že vyberete Správce koncových bodů a vyberete Upravit koncový bod.

    Snímek obrazovky s výběrem možnosti Upravit koncový bod v Endpoint Manageru

    Pak vyberte Vlastnosti koncového bodu a nakonfigurujte časový limit odpovědi zdroje:

    Snímek obrazovky s výběrem vlastností koncového bodu a polem časového limitu odpovědi zdroje

  • Pokud časový limit problém nevyřeší, pomocí nástroje, jako je Fiddler nebo vývojářský nástroj prohlížeče, zkontrolujte, jestli klient odesílá požadavky na rozsahy byte s hlavičkami Accept-Encoding, což vede k tomu, že zdroj odpovídá různými délkami obsahu. Pokud ano, můžete zakázat kompresi u zdroje nebo Azure Front Door vytvořit pravidlo sady pravidel, které se odebere z požadavku na požadavky na accept-encoding rozsah byte.

    Snímek obrazovky s pravidlem accept-encoding v sadě pravidel

Požadavky odeslané do vlastní domény vrací stavový kód 400.

Příznak

  • Vytvořili jste instanci Azure Front Door, ale požadavek na doménu nebo hostitele front-endu vrací stavový kód HTTP 400.
  • Vytvořili jste mapování DNS pro vlastní doménu na hostitele front-endu, který jste nakonfigurovali. Odeslání požadavku na vlastní název hostitele domény však vrátí stavový kód HTTP 400. Zdá se, že se směruje na back-end, který jste nakonfigurovali.

Příčina

K tomuto problému dochází v případě, že jste pro vlastní doménu, která byla přidána jako hostitel front-endu, nekonfigurujete pravidlo směrování. Pro tohoto hostitele front-endu je potřeba explicitně přidat pravidlo směrování. To platí i v případě, že pravidlo směrování už je nakonfigurované pro hostitele front-endu v rámci Azure Front Door domény (*.azurefd.net).

Postup při řešení potíží

Přidejte pravidlo směrování pro vlastní doménu, které bude směrovat provoz do vybrané skupiny původu.

Azure Front Door přesměruje HTTP na HTTPS

Příznak

Azure Front Door má pravidlo směrování, které přesměruje HTTP na HTTPS, ale přístup k doméně stále udržuje HTTP jako protokol.

Příčina

K tomuto chování může dojít v případě, že jste správně nenakonfigurujete pravidla směrování pro Azure Front Door. V podstatě platí, že vaše aktuální konfigurace není specifická a může mít konfliktní pravidla.

Postup při řešení potíží

Požadavek na název hostitele front-endu vrátí stavový kód 411.

Příznak

Vytvořili jste instanci Azure Front Door Standard nebo Premium a nakonfigurovali jste front-end hostitele, skupinu původu s alespoň jedním původem a pravidlo směrování, které připojuje front-end hostitele ke skupině původu. Zdá se, že váš obsah není k dispozici, když požadavek přejde na nakonfigurovaného hostitele front-endu, protože se vrátí stavový kód HTTP 411.

Odpovědi na tyto požadavky mohou také obsahovat chybovou stránku HTML v textu odpovědi, která obsahuje vysvětlující příkaz. Příklad: HTTP Error 411. The request must be chunked or have a content length.

Příčina

Tento příznak může způsobovat několik příčin. Celkovým důvodem je, že váš požadavek HTTP není plně kompatibilní s dokumentem RFC.

Příkladem nedokonalosti je požadavek odeslaný bez hlavičky nebo POST Content-Length Transfer-Encoding (například pomocí curl -X POST https://example-front-door.domain.com ). Tento požadavek nesplňuje požadavky uvedené v dokumentu RFC 7230. Azure Front Door by ho blokovat odpovědí HTTP 411.

Toto chování je oddělené od Web Application Firewall (WAF) Azure Front Door. V současné době neexistuje žádný způsob, jak toto chování zakázat. Všechny požadavky HTTP musí splňovat požadavky, a to i v případě, že se funkce WAF nebude používat.

Postup při řešení potíží

  • Ověřte, že vaše požadavky splňují požadavky uvedené v nezbytných dokumentech RFC.

  • Poznamenejte si text zprávy HTML, který se vrátí jako odpověď na váš požadavek. Text zprávy často přesně vysvětluje, jak je požadavek nekompatibilní.

Další kroky