Řešení běžných problémů se službou Azure Front Door
Tento článek popisuje, jak řešit běžné problémy se směrováním, se kterými se můžete setkat při konfiguraci služby Azure Front Door.
Další ladění hlaviček HTTP
Můžete požádat službu Azure Front Door, aby vrátila hlavičky odpovědi HTTP navíc pro ladění. Další informace najdete v volitelných hlavičkách odpovědi.
Odpověď 503 nebo 504 od služby Azure Front Door po několika sekundách
Příznaky
- Pravidelné požadavky odeslané do back-endu bez úspěšného průchodu službou Azure Front Door. Při procházení služby Azure Front Door dojde k chybám 503 nebo 504.
- Selhání služby Azure Front Door se obvykle objeví přibližně po 30 sekundách.
- Přerušované chyby 503 se zobrazují s informací o chybě OriginInvalidResponse.
Příčina
Příčinou tohoto problému může být jedna ze tří věcí:
- Váš původ trvá déle, než je časový limit nakonfigurovaný pro příjem požadavku ze služby Azure Front Door. Výchozí časový limit je 30 sekund.
- Doba, kterou trvá odeslání odpovědi na požadavek ze služby Azure Front Door, trvá déle než hodnota časového limitu.
- Klient odeslal požadavek na rozsah bajtů s hlavičkou Accept-Encoding , což znamená, že je povolená komprese.
Postup při řešení potíží
Odešlete požadavek přímo do vašeho původu, aniž byste prošli službou Azure Front Door. Podívejte se, jak dlouho váš původ obvykle trvá, než odpoví.
Odešlete požadavek přes Azure Front Door a zjistěte, jestli se vám zobrazuje 503 odpovědí. Pokud ne, problém nemusí být problém s vypršením časového limitu. Vytvořte žádost o podporu pro další řešení problému.
Pokud požadavky procházející službou Azure Front Door způsobí kód odpovědi na chybu 503, nakonfigurujte časový limit odpovědi origin pro Službu Azure Front Door. Výchozí časový limit můžete prodloužit až na 4 minuty (240 sekund). Nastavení nakonfigurujete tak, že přejdete na stránku přehledu profilu služby Front Door. Vyberte časový limit odpovědi Origin a zadejte hodnotu mezi 16 a 240 sekund.
Poznámka:
Možnost konfigurovat vypršení časového limitu odpovědi origin je dostupná jenom ve službě Azure Front Door Standard/Premium.
Pokud se vypršení časového limitu 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 rozsah bajtů s hlavičkami Accept-Encoding . Použití této možnosti vede k tomu, že zdroj reaguje s různými délkami obsahu.
Pokud klient odesílá požadavky na rozsah bajtů s hlavičkami Accept-Encoding , máte dvě možnosti. První možností je zakázat kompresi na serveru původu nebo ve službě Azure Front Door. Druhou možností je vytvořit pravidlo sady pravidel pro odebrání funkce Accept-Encoding z požadavku na požadavky na rozsah bajtů.
503 odpovědí z Azure Front Dooru pouze pro HTTPS
Příznaky
- Všechny odpovědi na 503 se vrátí jenom pro koncové body s podporou HTTPS služby Azure Front Door.
- Pravidelné požadavky odeslané do back-endu bez úspěšného průchodu službou Azure Front Door. Při přechodu přes Azure Front Door dojde k chybám 503 odpovědí.
- Přerušované chyby 503 se zobrazují s informací o chybě OriginInvalidResponse.
Příčina
Příčinou tohoto problému může být jedna ze tří věcí:
- Back-endový fond je IP adresa.
- Back-endový server vrátí certifikát, který neodpovídá plně kvalifikovanému názvu domény (FQDN) back-endového fondu služby Azure Front Door.
- Back-endový fond je server Azure Web Apps.
Postup při řešení potíží
Back-endový fond je IP adresa.
EnforceCertificateNameCheck
musí být zakázaná.Azure Front Door má přepínač s názvem
EnforceCertificateNameCheck
. Toto nastavení je ve výchozím nastavení povoleno. Pokud je tato možnost povolená, Služba Azure Front Door zkontroluje, jestli plně kvalifikovaný název domény hostitele back-endového fondu odpovídá názvu certifikátu back-endového serveru nebo jedné z položek v rozšíření alternativních názvů subjektu.Jak zakázat
EnforceCertificateNameCheck
na webu Azure Portal:Na portálu můžete toto nastavení zapnout nebo vypnout pomocí přepínače v podokně návrhu služby Azure Front Door (Classic).
U úrovně Azure Front Door Standard a Premium se toto nastavení nachází v nastavení původu, když přidáte zdroj do skupiny původu nebo nakonfigurujete trasu.
Back-endový server vrátí certifikát, který neodpovídá plně kvalifikovanému názvu domény back-endového fondu služby Azure Front Door. Pokud chcete tento problém vyřešit, máte dvě možnosti:
- Vrácený certifikát musí odpovídat plně kvalifikovanému názvu domény.
EnforceCertificateNameCheck
musí být zakázaná.
Back-endový fond je server Azure Web Apps:
- Zkontrolujte, jestli je webová aplikace Azure nakonfigurovaná s protokolem SSL založeným na PROTOKOLU IP místo toho, aby byla založená na SNI (označení názvu serveru). Pokud je webová aplikace nakonfigurovaná jako založená na IP adrese, měla by se změnit na SNI.
- Pokud back-end není v pořádku kvůli selhání certifikátu, vrátí se chybová zpráva 503. Stav back-endů můžete ověřit na portech 80 a 443. Pokud není v pořádku jenom 443, pravděpodobně se jedná o problém s protokolem SSL. Vzhledem k tomu, že back-end je nakonfigurovaný tak, aby používal plně kvalifikovaný název domény, víme, že odesílá SNI.
Pomocí knihovny OPENSSL ověřte vrácený certifikát. Chcete-li to provést, připojte se k back-endu pomocí
-servername
. Měl by vrátit SNI, který se musí shodovat s plně kvalifikovaným názvem domény back-endového fondu:openssl s_client -connect backendvm.contoso.com:443 -servername backendvm.contoso.com
Požadavky odeslané do vlastní domény vrátí stavový kód 400.
Příznaky
- Vytvořili jste instanci služby Azure Front Door. Požadavek na hostitele domény nebo front-endu vrátí stavový kód HTTP 400.
- Vytvořili jste mapování DNS (server názvu domény) pro vlastní doménu na hostitele front-endu, který jste nakonfigurovali. Odeslání požadavku na vlastní název hostitele domény vrátí stavový kód HTTP 400. Zdá se, že se nenasměruje na back-end, který jste nakonfigurovali.
Příčina
K tomuto problému dochází, pokud jste nekonfigurovali pravidlo směrování pro vlastní doménu přidanou jako hostitele front-endu. Pro tohoto hostitele front-endu je potřeba explicitně přidat pravidlo směrování. Pravidlo je potřeba vytvořit i v případě, že už bylo pro hostitele front-endu nakonfigurované pod subdoménou služby Azure Front Door, což je *.azurefd.net.
Krok ř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 nepřesměruje HTTP na HTTPS
Příznaky
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 protokol HTTP.
Příčina
K tomuto chování může dojít, pokud jste správně nenakonfigurovali pravidla směrování pro Službu Azure Front Door. 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říznaky
Vytvořili jste instanci Azure Front Door Standard/Premium a nakonfigurovali jste:
- Hostitel front-endu.
- Skupina původu s alespoň jedním původem.
- Pravidlo směrování, které připojí hostitele front-endu ke skupině původu.
Zdá se, že váš obsah není dostupný, 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í prohlášení. Příkladem je chyba HTTP 411. Požadavek musí být blokovaný nebo musí mít délku obsahu.
Příčina
Existuje několik možných příčin tohoto příznaku. Celkovým důvodem je, že váš požadavek HTTP není plně kompatibilní se standardem RFC.
Příkladem nedodržení předpisů je POST
požadavek odeslaný bez hlavičky Content-Length nebo Transfer-Encoding . Příklad by používal curl -X POST https://example-front-door.domain.com
. Tato žádost nesplňuje požadavky stanovené v dokumentu RFC 7230. Azure Front Door by ho zablokoval s odpovědí HTTP 411. Tyto požadavky se nezaprotokolují.
Toto chování je oddělené od funkcí firewallu webových aplikací (WAF) služby Azure Front Door. V současné době neexistuje způsob, jak toto chování zakázat. Všechny požadavky HTTP musí splňovat požadavky, i když se funkce WAF nepoužívají.
Postup při řešení potíží
- Ověřte, že vaše požadavky splňují požadavky stanovené v nezbytných dokumentech RFC.
- Poznamenejte si všechny texty zprávy HTML, které se vrátí v odpovědi na vaši žádost. Text zprávy často vysvětluje, jak vaše žádost nedodržuje předpisy.
Můj původ je nakonfigurovaný jako IP adresa.
Příznaky
Zdroj je nakonfigurovaný jako IP adresa. Původ je v pořádku, ale odmítá žádosti ze služby Azure Front Door.
Příčina
Azure Front Door během použití metody handshake PROTOKOLU SSL uživatelem původního hostitele jako hlavičku SNI. Vzhledem k tomu, že zdroj je nakonfigurovaný jako IP adresa, může být selhání jedním z následujících důvodů:
- Pokud je kontrola názvu certifikátu zakázaná, je možné, že příčinou problému je logika certifikátu původu. Tato logika může odmítnout všechny požadavky, které nemají platnou hlavičku hostitele odpovídající certifikátu.
Postup při řešení potíží
Změňte původ z IP adresy na plně kvalifikovaný název domény, na který je vystaven platný certifikát, který odpovídá zdrojovému certifikátu.
429 odpovědí od služby Azure Front Door
Příznaky
- Procento požadavků začíná zobrazovat chyby s odpovědí 429: Příliš mnoho požadavků.
Příčina
- Azure Front Door má výchozí limity přenosové rychlosti platformy. Pokud váš provoz překročí limit, AFD zahájí omezování provozu a vrátí 429 odpovědí.
Postup při řešení potíží
- Pokud začnete u legitimního provozu zobrazovat 429 a potřebujete vyšší kvótu, vytvořte podpora Azure žádost.
Další kroky
- Přečtěte si, jak vytvořit Front Door.
- Přečtěte si jak vytvořit službu Front Door Standard nebo Premium.