Delen via

HTTP-antwoordcodes in Application Gateway

  • Artikel

In dit artikel vindt u redenen waarom Azure-toepassing Gateway specifieke HTTP-antwoordcodes retourneert. Veelvoorkomende oorzaken en stappen voor probleemoplossing worden gegeven om u te helpen de hoofdoorzaak van de HTTP-antwoordcode van de fout te bepalen. HTTP-antwoordcodes kunnen worden geretourneerd naar een clientaanvraag of er al dan niet een verbinding is gestart met een back-enddoel.

3XX-antwoordcodes (omleiding)

300-399-antwoorden worden weergegeven wanneer een clientaanvraag overeenkomt met een toepassingsgatewayregel die omleidingen heeft geconfigureerd. Omleidingen kunnen worden geconfigureerd op basis van een regel als zodanig of via een padtoewijzingsregel. Zie application gateway-omleidingsoverzicht voor meer informatie over omleidingen.

301 Permanente omleiding

HTTP 301-antwoorden worden weergegeven wanneer een omleidingsregel wordt opgegeven met de permanente waarde.

302 Gevonden

HTTP 302-antwoorden worden weergegeven wanneer een omleidingsregel wordt opgegeven met de waarde Gevonden .

303 Zie overige

HTTP 302-antwoorden worden weergegeven wanneer een omleidingsregel is opgegeven met de waarde Zie overige .

307 Tijdelijke omleiding

HTTP 307-antwoorden worden weergegeven wanneer een omleidingsregel wordt opgegeven met de tijdelijke waarde.

4XX-antwoordcodes (clientfout)

400-499-antwoordcodes geven een probleem aan dat is gestart vanaf de client. Deze problemen kunnen variëren van de client die aanvragen initieert tot een niet-overeenkomende hostnaam, time-out van aanvragen, niet-geverifieerde aanvragen, schadelijke aanvragen en meer.

Application Gateway verzamelt metrische gegevens die de distributie van statuscodes van 4xx/5xx vastleggen, hebben een mechanisme voor logboekregistratie waarmee informatie zoals het IP-adres van de URI-client wordt vastgelegd met de antwoordcode. Metrische gegevens en logboekregistratie maken verdere probleemoplossing mogelijk. Clients kunnen ook 4xx-antwoorden ontvangen van andere proxy's tussen het clientapparaat en Application Gateway. Bijvoorbeeld CDN en andere verificatieproviders. Zie de volgende artikelen voor meer informatie.

Metrische gegevens die worden ondersteund door diagnostische logboeken van Application Gateway V2 SKU

400 – Ongeldige aanvraag

HTTP 400-antwoordcodes worden vaak waargenomen wanneer:

  • Niet-HTTP-/HTTPS-verkeer wordt gestart naar een toepassingsgateway met een HTTP- of HTTPS-listener.
  • HTTP-verkeer wordt gestart naar een listener met HTTPS, zonder dat er omleiding is geconfigureerd.
  • Wederzijdse verificatie is geconfigureerd en kan niet goed onderhandelen.
  • De aanvraag voldoet niet aan RFC.

Enkele veelvoorkomende redenen waarom de aanvraag niet compatibel is met RFC, zijn:

Categorie Voorbeelden
Ongeldige host in aanvraagregel Host met twee dubbele punten (example.com:8090:8080)
Hostheader ontbreekt Aanvraag heeft geen hostheader
Aanwezigheid van onjuist of ongeldig teken Gereserveerde tekens zijn &,!. De tijdelijke oplossing is om deze als percentage te codeeren. Bijvoorbeeld: %&
Ongeldige HTTP-versie /content.css HTTP/0.3 ophalen
Veldnaam en URI van koptekst bevatten niet-ASCII-teken GET /«úü¡»^.doc HTTP/1.1
Koptekst inhoudlengte ontbreekt voor POST-aanvraag Verklarend
Ongeldige HTTP-methode GET123 /index.html HTTP/1.1
Dubbele kopteksten Autorisatie:<met base64 gecodeerde inhoud>, autorisatie: <met base64 gecodeerde inhoud>
Ongeldige waarde in Inhoudslengte Content-Length: abc, Content-Length: -10

Voor gevallen waarin wederzijdse verificatie is geconfigureerd, kunnen verschillende scenario's leiden tot een HTTP 400-antwoord dat wordt geretourneerd door de client, zoals:

  • Clientcertificaat wordt niet weergegeven, maar wederzijdse verificatie is ingeschakeld.
  • DN-validatie is ingeschakeld en de DN van het clientcertificaat komt niet overeen met de DN van de opgegeven certificaatketen.
  • Clientcertificaatketen komt niet overeen met de certificaatketen die is geconfigureerd in het gedefinieerde SSL-beleid.
  • Het clientcertificaat is verlopen.
  • OcSP-clientintrekkingscontrole is ingeschakeld en het certificaat wordt ingetrokken.
  • OcSP-clientintrekkingscontrole is ingeschakeld, maar kan geen contact opnemen.
  • OcSP-clientintrekkingscontrole is ingeschakeld, maar OCSP-responder is niet opgegeven in het certificaat.

Zie Foutcode oplossen voor meer informatie over het oplossen van problemen met wederzijdse verificatie.

401 - Niet geautoriseerd

Een niet-geautoriseerd HTTP 401-antwoord wordt geretourneerd aan de client als de client niet is gemachtigd voor toegang tot de resource. Er zijn verschillende redenen waarom 401 moet worden geretourneerd. Hier volgen enkele redenen voor mogelijke oplossingen.

  • Als de client toegang heeft, heeft deze mogelijk een verouderde browsercache. Wis de browsercache en probeer opnieuw toegang te krijgen tot de toepassing.

Een niet-geautoriseerd HTTP 401-antwoord kan worden geretourneerd naar de AppGW-testaanvraag als de back-endpool is geconfigureerd met NTLM-verificatie . In dit scenario wordt de back-end gemarkeerd als in orde. Er zijn verschillende manieren om dit probleem op te lossen:

  • Anonieme toegang toestaan voor back-endpool.
  • Configureer de test om de aanvraag te verzenden naar een andere 'nep'-site waarvoor geen NTLM is vereist.
  • Niet aanbevolen, omdat dit ons niet vertelt of de werkelijke site achter de toepassingsgateway actief is of niet.
  • Configureer de toepassingsgateway om 401-antwoorden toe te staan als geldig voor de tests: voorwaarden voor tests die overeenkomen met tests.

403 - Verboden

HTTP 403 Verboden wordt weergegeven wanneer klanten WAF-SKU's gebruiken en WAF hebben geconfigureerd in de preventiemodus. Als WAF-regelsets of aangepaste WAF-regels voor weigeren overeenkomen met de kenmerken van een binnenkomende aanvraag, krijgt de client een 403 verboden antwoord te zien.

Andere redenen voor clients die 403-antwoorden ontvangen, zijn:

  • U gebruikt App Service als back-end en deze is geconfigureerd om alleen toegang vanuit Application Gateway toe te staan. Dit kan een 403-fout retourneren door App Services. Dit gebeurt meestal door omleidingen/href-koppelingen die rechtstreeks naar App Services verwijzen in plaats van naar het IP-adres van de Application Gateway.
  • Als u een opslagblog opent en het Application Gateway- en opslageindpunt zich in een andere regio bevindt, wordt er een 403-fout geretourneerd als het openbare IP-adres van de Toepassingsgateway niet is toegestaan. Zie Toegang verlenen vanuit een IP-adresbereik van internet.

404 – Pagina niet gevonden

Een HTTP 404-antwoord kan worden geretourneerd als een aanvraag wordt verzonden naar een toepassingsgateway die:

408 – Time-out aanvragen

Een HTTP 408-antwoord kan worden waargenomen wanneer clientaanvragen naar de front-endlist van de toepassingsgateway niet binnen 60 seconden reageren. Deze fout kan worden waargenomen vanwege verkeersopstoppingen tussen on-premises netwerken en Azure, wanneer het virtuele apparaat het verkeer inspecteert of de client zelf overbelast raakt.

413 - Aanvraagentiteit te groot

Een HTTP 413-antwoord kan worden waargenomen wanneer u Azure Web Application Firewall op Application Gateway gebruikt en de grootte van de clientaanvraag groter is dan de maximale grootte van de aanvraagbody. De maximale grootte van de hoofdtekst van de aanvraag bepaalt de totale aanvraaggroottelimiet, met uitzondering van bestandsuploads. De standaardwaarde voor de grootte van de hoofdtekst van de aanvraag is 128 kB. Zie Web Application Firewall-aanvraaggroottelimieten voor meer informatie.

499 – Client heeft de verbinding gesloten

Een HTTP 499-antwoord wordt weergegeven als een clientaanvraag die wordt verzonden naar toepassingsgateways met behulp van v2 SKU wordt gesloten voordat de server klaar is met reageren. Deze fout kan worden waargenomen in twee scenario's. Het eerste scenario is wanneer een groot antwoord wordt geretourneerd naar de client en de client de toepassing mogelijk heeft gesloten of vernieuwd voordat de server klaar is met het verzenden van een groot antwoord. Het tweede scenario is wanneer de time-out aan de clientzijde laag is en niet lang genoeg wacht om het antwoord van de server te ontvangen. In dit geval is het beter om de time-out op de client te verhogen. In toepassingsgateways die v1 sku gebruiken, kan er een HTTP 0-antwoordcode worden gegenereerd voor de client die de verbinding sluit voordat de server ook reageert.

5XX-antwoordcodes (serverfout)

500-599-antwoordcodes geven aan dat er een probleem is opgetreden bij de toepassingsgateway of de back-endserver tijdens het uitvoeren van de aanvraag.

500 – Interne serverfout

Azure Application Gateway mag geen 500 antwoordcodes vertonen. Open een ondersteuningsaanvraag als u deze code ziet, omdat dit probleem een interne fout voor de service is. Zie Een ondersteuning voor Azure aanvraag maken voor meer informatie over het openen van een ondersteuningsaanvraag.

502 - Ongeldige gateway

HTTP 502-fouten kunnen verschillende hoofdoorzaken hebben, bijvoorbeeld:

Zie Foute gatewayfouten oplossen voor meer informatie over scenario's waarin 502-fouten optreden en hoe u deze kunt oplossen.

504 – Time-out van gateway

Azure Application Gateway V2 SKU heeft HTTP 504-fouten verzonden als de reactietijd van de back-end de time-outwaarde overschrijdt die is geconfigureerd in de back-endinstelling.

IIS

Als uw back-endserver IIS is, raadpleegt u Standaardlimieten voor websites om de time-outwaarde in te stellen. Raadpleeg het connectionTimeout kenmerk voor meer informatie. Zorg ervoor dat de verbindingstime-out in IIS overeenkomt of niet hoger is dan de time-out die is ingesteld in de back-endinstelling.

nginx

Als de back-endserver nginx- of nginx-ingangscontroller is en als deze upstream-servers heeft, moet u ervoor zorgen dat de waarde van nginx:proxy_read_timeout overeenkomsten overeenkomt of niet wordt overschreden met de time-out die is ingesteld in de back-endinstelling.

Volgende stappen

Als de informatie in dit artikel niet helpt om het probleem op te lossen, dient u een ondersteuningsticket in.