Sdílet prostřednictvím


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

Tento článek obsahuje důvody, proč Aplikace Azure 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 do požadavku klienta bez ohledu na to, jestli bylo připojení inicializováno k back-endovému cíli.

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 prostřednictvím pravidla mapování 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.

Nalezeno 302

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 můžou být v rozsahu od klienta, který iniciuje požadavky, na chybějící název hostitele, vypršení časového limitu požadavku, neověřený požadavek, škodlivý požadavek a další.

Application Gateway shromažďuje metriky, které zaznamenávají distribuci stavových kódů 4xx/5xx, má mechanismus protokolování, který zaznamenává informace, jako je IP adresa klienta identifikátoru URI, s kódem 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 a další zprostředkovatelé ověřování. Další informace najdete v následujících článcích.

Metriky podporované diagnostickými protokoly skladovépoložky služby Application Gateway V2

400 – Chybný požadavek

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

  • Do služby Application Gateway s naslouchacím procesem HTTP nebo HTTPS se inicioval jiný provoz než HTTP nebo HTTPS.
  • Do naslouchacího procesu HTTPS se inicioval provoz HTTP bez nakonfigurovaného přesměrování.
  • Je nakonfigurované vzájemné ověřování, ale dochází k selhání při vyjednávání.
  • Požadavek nevyhovuje dokumentu RFC.

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

Kategorie Příklady
Neplatný hostitel na řádku požadavku Hostitel obsahující dvě dvojtečky (example.com:8090:8080)
Chybějící hlavička hostitele Požadavek nemá hlavičku hostitele.
Přítomnost poškozeného nebo neplatného znaku Rezervované znaky jsou &,!. Alternativním řešením je naprogramovat ho jako procento. Příklad: %&
Neplatná verze HTTP Získání /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ějící hlavička Délka obsahu pro požadavek POST Vysvětlovat
Neplatná metoda HTTP GET123 /index.html HTTP/1.1
Duplicitní záhlaví Authorization:<base64 kódovaný obsah>, autorizace: <kódovaný obsah base64>
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:

  • Klientský certifikát se nezobrazuje, ale je povolené vzájemné ověřování.
  • Je povoleno ověřování DN a DN klientského certifikátu neodpovídá DN zadaného řetězu 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 je povolená a certifikát je odvolán.
  • Kontrola odvolání klienta OCSP je povolená, ale nelze ji kontaktovat.
  • Je povolená kontrola odvolání klienta OCSP, ale v certifikátu není uvedený respondér 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 back-endový fond nakonfigurovaný s ověřováním NTLM , může se požadavek na sondu AppGW vrátit do požadavku testu HTTP 401. V tomto scénáři je back-end označený jako v pořádku. Tento problém můžete vyřešit několika způsoby:

  • Povolte anonymní přístup v back-endovém fondu.
  • 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 umožňovala 401 odpovědí jako platnou pro sondy: Podmínky shody sondy.

403 – Zakázáno

Http 403 Zakázáno se zobrazí, když zákazníci využívají skladové položky WAF 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ů, které odkazují přímo na App Services, místo aby odkazy na IP adresu služby 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ělení přístupu z rozsahu internetových IP adres.

404 – Stránka nebyla nalezena

Odpověď HTTP 404 se dá vrátit, pokud se požadavek odešle do aplikační brány, která je:

  • Použití skladové položky v2
  • Bez shody názvu hostitele definovaného v naslouchacích procesech s více lokalitami.
  • Nenakonfigurováno se základním naslouchacím procesem.

408 – Vypršení časového limitu požadavku

Odpověď HTTP 408 se dá pozorovat, když požadavky klientů na front-endový naslouchací proces služby Application Gateway nereagují zpět během 60 sekund. Tuto chybu je možné pozorovat kvůli zahlcení provozu mezi místními sítěmi a Azure, když virtuální zařízení kontroluje provoz nebo se samotný klient zahltí.

413 – Žádost o příliš velkou entitu

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í v případě, že se požadavek klienta odeslaný do služby Application Gateway se skladovou položkou v2 uzavře před dokončením odpovědi serveru. 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řijetí odpovědi ze serveru. V takovém případě je lepší zvýšit časový limit klienta. V aplikačních branách používajících skladovou položku v1 může být vyvolán kód odpovědi HTTP 0 pro klienta, který ukončí připojení předtím, než server dokončí odezvu.

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 Gateway by neměla zobrazovat stavový kód 500. Pokud vidíte tento kód, požádejte o podporu, protože tento problém je vnitřní chybou služby. Informace o tom, jak otevřít případ podpory, najdete v tématu Vytvoření podpora Azure žádosti.

502 – Chybná brána

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

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 Chybná brána.

504 – Vypršení časového limitu brány

Skladová položka služby Azure Application Gateway V2 odeslala chyby HTTP 504, pokud doba odezvy back-endu překračuje hodnotu časového limitu nakonfigurovanou v nastavení back-endu.

IIS

Pokud je back-endovým serverem služba IIS, nastavte hodnotu časového limitu dle části Výchozí limity pro weby. Podrobnosti najdete v atributu connectionTimeout . Ujistěte se, že časový limit připojení ve službě IIS odpovídá časovému limitu nastavenému v nastavení back-endu nebo tento limit nepřekračuje.

nginx

Pokud je back-endový server nginx nebo nginx kontroler příchozího přenosu dat a pokud má nadřazené servery, zajistěte, aby hodnota shod nginx:proxy_read_timeout nebo nepřekročila časový limit nastavený v nastavení back-endu.

Další kroky

Pokud informace v tomto článku nepomohly problém vyřešit, odešlete lístek podpory.