Kódy odpovědí HTTP ve službě Application Gateway

Tento článek obsahuje důvody, proč Azure Application Gateway vrací konkrétní kódy odpovědí HTTP. K dispozici jsou běžné příčiny a kroky pro řešení potíží, které vám pomůžou určit původní příčinu kódu odpovědi HTTP. Kódy odpovědí HTTP se dají vrátit na požadavek klienta bez ohledu na to, zda bylo připojení inicializováno k cílovému backendu.

Kódy odpovědí 3XX (přesměrování)

Odpovědi 300–399 se zobrazí, když požadavek klienta odpovídá pravidlu služby Application Gateway, které má nakonfigurované přesměrování. Přesměrování je možné nakonfigurovat pro pravidlo tak, jak je, nebo pomocí pravidla mapy cest. Další informace o přesměrování najdete v tématu Přehled přesměrování služby Application Gateway.

301 Trvalé přesměrování

Odpovědi HTTP 301 se zobrazí, když je zadáno pravidlo přesměrování s trvalou hodnotou.

302 Nalezeno

Odpovědi HTTP 302 se zobrazí, když je zadáno pravidlo přesměrování s hodnotou Nalezeno .

303 Viz ostatní

Odpovědi HTTP 302 se zobrazí, když je zadáno pravidlo přesměrování s hodnotou Viz ostatní .

307 Dočasné přesměrování

Odpovědi HTTP 307 se zobrazí, když je zadáno pravidlo přesměrování s dočasnou hodnotou.

Kódy odpovědí 4xx (chyba klienta)

Kódy odpovědí 400-499 označují problém, který je inicializován z klienta. Tyto problémy se mohou pohybovat od situací, kdy klient iniciuje požadavky na neodpovídající název hostitele, vypršení časového limitu požadavku, neautentizovaný požadavek, a škodlivý požadavek, a další.

Application Gateway shromažďuje metriky, které zaznamenávají distribuci stavových kódů 4xx/5xx, a má mechanismus protokolování, který zaznamenává informace, jako je například IP adresa klienta, URI a kód odpovědi. Metriky a protokolování umožňují další řešení potíží. Klienti můžou také přijímat odpověď 4xx z jiných proxy serverů mezi klientským zařízením a službou Application Gateway. Například CDN (Content Delivery Network) a další zprostředkovatelé ověřování. Další informace najdete v následujících článcích.

Metriky podporované službou Application Gateway V2 SKUDiagnostické protokoly

400 – Chybný požadavek

Kódy odpovědí HTTP 400 se běžně pozorují v případech:

• Provoz, který není HTTP nebo HTTPS, je směrován na aplikační bránu s naslouchacím procesem pro HTTP nebo HTTPS.
• Do naslouchacího zařízení s HTTPS byl zahájen provoz HTTP, aniž by bylo nakonfigurováno přesměrování.
• Vzájemné ověřování je nakonfigurováno, ale nelze ho správně vyjednat.
• Požadavek nevyhovuje dokumentu RFC.

Mezi běžné důvody, proč požadavek nedodržuje předpisy RFC, patří:

Kategorie	Příklady
Neplatný hostitel ve vyžádané řádce	Hostitel obsahující dvě dvojtečky (example.com:8090:8080)
Chybějící hlavička hostitele	Požadavek nemá Host Header.
Přítomnost neformátovaného nebo nelegálního znaku	Rezervované znaky jsou &,!. Alternativním řešením je naprogramovat ho jako procento. Příklad: %&
Neplatná verze HTTP	Získejte /content.css HTTP/0.3
Název pole záhlaví a identifikátor URI obsahují znak jiného než ASCII.	GET /«úüï»»^.doc HTTP/1.1
Chybí hlavička Content Length pro požadavek POST	Samo vysvětlující
Neplatná metoda HTTP	GET123 /index.html HTTP/1.1
Duplicitní záhlaví	Authorization:<base64 kódovaný obsah>, Authorization: <base64 kódovaný obsah>
Neplatná hodnota v content-length	Délka obsahu: abc, Délka obsahu: -10

V případech, kdy je nakonfigurované vzájemné ověřování, může několik scénářů vést k vrácení odpovědi HTTP 400 klientovi, například:

• Vzájemné ověřování je povolené, ale klientský certifikát nebyl prezentován.
• Je povoleno ověřování DN (Rozlišující název) a DN klientského certifikátu neodpovídá DN zadaného řetězce certifikátů.
• Řetěz klientských certifikátů neodpovídá řetězu certifikátů nakonfigurovaným v definovaných zásadách SSL.
• Platnost klientského certifikátu vypršela.
• Kontrola odvolání klienta OCSP (Online Certificate Status Protocol) je povolená a certifikát je odvolán.
• Kontrola odvolání klienta OCSP (Online Certificate Status Protocol) je povolená, ale nelze ji kontaktovat.
• Je povolená kontrola odvolání klienta OCSP (Online Certificate Status Protocol), ale v certifikátu není uvedena odpověď OCSP.

Další informace o řešení potíží se vzájemným ověřováním najdete v tématu Řešení potíží s kódem chyby.

401 – Neautorizováno

Pokud klient nemá oprávnění k přístupu k prostředku, vrátí se klientovi neautorizovaná odpověď HTTP 401. Existuje několik důvodů, proč se má vrátit číslo 401. Následuje několik důvodů s možnými opravami.

• Pokud má klient přístup, může mít zastaralou mezipaměť prohlížeče. Vymažte mezipaměť prohlížeče a zkuste znovu získat přístup k aplikaci.

Pokud je fond back-endu nakonfigurován s ověřováním NTLM, může být na požadavek sondy AppGW vrácena odpověď HTTP 401 Neoprávněné. V tomto scénáři je backend označen jako zdravý. Tento problém můžete vyřešit několika způsoby:

• Umožnit anonymní přístup ke skupině backendových serverů.
• Nakonfigurujte test tak, aby odesílal požadavek na jiný „falešný“ web, který nevyžaduje protokol NTLM.
• Nedoporučuje se, protože to nám neřekne, jestli je skutečný web za aplikační bránou aktivní nebo ne.
• Nakonfigurujte aplikační bránu tak, aby považovala odpovědi 401 za platné pro sondy: Podmínky shody sondy.

403 – Zakázáno

HTTP 403 Zakázáno se zobrazí, když zákazníci využívají produkty WAF (Firewall webových aplikací) a mají WAF nakonfigurovaný v režimu prevence. Pokud povolené sady pravidel WAF nebo vlastní odepření pravidel WAF odpovídají charakteristikám příchozího požadavku, zobrazí se klientovi 403 zakázaná odpověď.

Mezi další důvody, proč klienti dostávají odpovědi 403, patří:

• Používáte službu App Service jako back-end a je nakonfigurovaná tak, aby povolovala přístup jenom ze služby Application Gateway. Služba App Services tak může vrátit chybu 403. K tomu obvykle dochází kvůli přesměrování nebo href odkazům, které odkazují přímo na App Services, místo na IP adresu Application Gateway.
• Pokud přistupujete k blogu o úložišti a služba Application Gateway a koncový bod úložiště jsou v jiné oblasti, vrátí se chyba 403, pokud veřejná IP adresa služby Application Gateway není uvedená v seznamu povolených. Viz Udělit přístup z rozsahu internetových IP adres.

404 – Stránka nebyla nalezena

Odpověď HTTP 404 se vygeneruje, když je požadavek odeslán na službu Application Gateway (SKU V2) s hostitelským jménem, které neodpovídá žádnému z nakonfigurovaných naslouchacích procesů pro více webů a neexistuje žádný základní naslouchací proces. Přečtěte si další informace o typech posluchačů.

408 – Časový limit žádosti vypršel

Odezvu HTTP 408 lze pozorovat, když klientské požadavky na frontendový posluchač aplikační brány neodpoví do 60 sekund. Tuto chybu lze pozorovat při dopravní zácpě mezi lokálními sítěmi a Azure, když virtuální zařízení kontroluje provoz nebo když je samotný klient přetížený.

413 – Požadovaný subjekt je příliš velký

Odpověď HTTP 413 se dá pozorovat při použití služby Azure Web Application Firewall ve službě Application Gateway a velikost požadavku klienta překračuje maximální limit velikosti textu požadavku. Maximální velikost pole velikosti textu požadavku určuje celkový limit velikosti požadavku s výjimkou nahrávaných souborů. Výchozí hodnota pro velikost textu požadavku je 128 kB. Další informace najdete v tématu Omezení velikosti požadavků firewallu webových aplikací.

499 – Klient ukončil připojení

Odpověď HTTP 499 se zobrazí, pokud je klientský požadavek odeslaný přes Application Gateway s verzí sku v2 přerušen předtím, než server dokončí odpověď. Tuto chybu lze pozorovat ve 2 scénářích. Prvním scénářem je vrácení velké odpovědi klientovi a klient mohl aplikaci zavřít nebo aktualizovat předtím, než server dokončil odesílání velké odpovědi. Druhým scénářem je, že časový limit na straně klienta je nízký a nečeká dostatečně dlouho na příjem odpovědi ze serveru. V takovém případě je lepší zvýšit časový limit na straně klienta. U aplikačních bran používajících v1 může být vyvolán kód odpovědi HTTP 0, pokud klient ukončí připojení před tím, než server dokončí odpověď.

Kódy odpovědí 5XX (chyba serveru)

Kódy odpovědí 500–599 značí, že při provádění požadavku došlo k problému se službou Application Gateway nebo back-endovým serverem.

500 – Vnitřní chyba serveru

Brána aplikace Azure by neměla zobrazovat stavové kódy 500. Pokud vidíte tento kód, požádejte o podporu, protože tento problém je vnitřní chybou služby. Pro informace o otevření podpůrného případu najdete v tématu Vytvoření žádosti o podporu Azure.

502 – Chybná brána

Chyby HTTP 502 můžou mít několik původních příčin, například:

• Skupina zabezpečení sítě (skupina zabezpečení sítě), trasa definovaná uživatelem (trasa definovaná uživatelem) nebo vlastní DNS blokuje přístup k členům back-endového fondu.
• Back-endové virtuální počítače nebo instance škálovacích sad virtuálních počítačů nereagují na výchozí sondu stavu.
• Neplatná nebo nesprávná konfigurace vlastních sond pro sledování stavu.
• back-endový fond Azure Application Gateway není nakonfigurovaný nebo prázdný.
• Žádný z virtuálních počítačů nebo instancí ve škálovací sadě virtuálních počítačů není v pořádku.
• V případě problémů s vypršením časového limitu nebo s připojením u uživatelských požadavků odešle Azure Application Gateway V1 SKU chybové hlášení HTTP 502, pokud doba odezvy back-endu překročí hodnotu časového limitu nakonfigurovaného v nastavení back-endu.

Informace o scénářích, ve kterých dochází k chybám 502 a jak je řešit, najdete v tématu Řešení chyb špatné brány.

504 – Časový limit brány vypršel

Azure Application Gateway V2 SKU zasílá chyby HTTP 504, pokud doba odezvy backendu překročí hodnotu časového limitu nastavenou v nastavení backendu.

IIS (webový server Internetové informační služby)

Pokud je back-endovým serverem služba IIS, přečtěte si informace o výchozích omezeních pro weby a nastavte hodnotu časového limitu. Podrobnosti najdete v atributu connectionTimeout . Ujistěte se, že časový limit připojení ve službě IIS odpovídá nebo nepřekračuje časový limit nastavený v nastavení back-endu.

Nginx

Pokud je back-endový server Nginx nebo Nginx Ingress Controller a pokud má upstream servery, zajistěte, aby hodnota nginx:proxy_read_timeout nepřekročila časový limit nastavený v nastavení back-endu.

Scénáře řešení potíží

Chyba "ERRORINFO_INVALID_HEADER" v protokolech Accessu

Problém: V protokolu Accessu se u požadavku zobrazuje chyba "ERRORINFO_INVALID_HEADER", přestože kód odpovědi back-endu (serverStatus) je 200. V jiných případech může back-endový server vrátit hodnotu 500.

Příčina: Klient odešle hlavičku obsahující znaky CR LF.

Řešení: Nahraďte znaky CR LF znakem SP (prázdné znaky) a znovu odešlete požadavek službě Application Gateway.

Další kroky

Pokud informace v tomto článku nepomohly problém vyřešit, odešlete žádost o podporu.