Delen via

HTTP-antwoordcodes in Application Gateway

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 clientverzoek, ongeacht of er een verbinding is geïnitieerd met een backend-doelwit.

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 (klantfout)

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 (Content Delivery Network) en andere verificatieproviders. Zie de volgende artikelen voor meer informatie.

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

400 – Foute 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 maar kan geen goede communicatie tot stand brengen.
  • De aanvraag voldoet niet aan RFC.

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

Categorie Voorbeelden
Ongeldige host in verzoekregel Host dat twee dubbele punten bevat (example.com:8090:8080)
De hostheader ontbreekt Aanvraag heeft geen hostheader
Aanwezigheid van foutief of ongeldig teken Gereserveerde tekens zijn &,!. De tijdelijke oplossing is om deze als percentage te codeeren. Bijvoorbeeld: %&
Ongeldige HTTP-versie GET /content.css HTTP/0.3
Veldnaam en URI van koptekst bevatten niet-ASCII-teken GET /«úü¡»^.doc HTTP/1.1
Ontbrekende Content Length-header voor POST-verzoek Zelfverklarend
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-veld 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:

  • Wederzijdse verificatie is ingeschakeld, maar het clientcertificaat is niet gepresenteerd.
  • DN-validatie (Distinguished Name) 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 (Online Certificate Status Protocol) Clientintrekkingscontrole is ingeschakeld en het certificaat wordt ingetrokken.
  • OCSP (Online Certificate Status Protocol) intrekkingscontrole is ingeschakeld, maar de client kan niet worden bereikt.
  • OcSP (Online Certificate Status Protocol) 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 backend gemarkeerd als gezond. Er zijn verschillende manieren om dit probleem op te lossen:

  • Anonieme toegang toestaan voor achtergrondpool.
  • Configureer de sonde om de aanvraag te verzenden naar een andere vervalsite waar geen NTLM vereist is.
  • Niet aanbevolen, omdat dit ons niet vertelt of de werkelijke site achter de toepassingsgateway actief is of niet.
  • Stel de applicatiegateway zo in dat 401-antwoorden als geldig worden beschouwd voor de probes: Voorwaarden voor overeenkomende probes.

403 - Verboden

HTTP 403 Verboden wordt weergegeven wanneer klanten WAF-SKU's (Web Application Firewall) 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 opleveren via 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 toegang krijgt tot een opslagblog en het Application Gateway en opslag-eindpunt zich in verschillende regio's bevinden, wordt er een 403-fout geretourneerd als het openbare IP-adres van de Application Gateway niet op de lijst met toegestane adressen staat. Zie Toegang verlenen vanuit een IP-adresbereik van internet.

404 - Pagina is niet gevonden

Er wordt een HTTP 404-antwoord gegenereerd wanneer een aanvraag wordt ingediend bij Application Gateway (V2-SKU's) met een hostnaam die niet overeenkomt met een van de geconfigureerde listeners voor meerdere sites en er is geen Basic-listener aanwezig. Meer informatie over soorten luisteraars.

408 – Time-out aanvragen

Een HTTP 408-antwoord kan worden waargenomen wanneer clientaanvragen naar de front-end listener van de toepassingsgateway niet binnen 60 seconden een reactie krijgen. 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 - Bad Gateway

HTTP 502-fouten kunnen verschillende hoofdoorzaken hebben, bijvoorbeeld:

Zie Oplossen van foute gatewayfouten voor meer informatie over scenario's waarin 502-fouten optreden, en hoe je deze kunt oplossen.

504 – Gateway-time-out

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 (Internet Information Services-webserver)

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

Nginx

Als de back-endserver Nginx of Nginx Ingress Controller is en als deze upstreamservers heeft, moet u ervoor zorgen dat de waarde van nginx:proxy_read_timeout overeenkomt of niet overschrijdt met de in de back-end ingestelde time-out.

Scenario's voor probleemoplossing

Fout 'ERRORINFO_INVALID_HEADER' in Access-logboeken

Probleem: in het toegangslogboek wordt een fout 'ERRORINFO_INVALID_HEADER' weergegeven voor een aanvraag, ondanks dat de back-endantwoordcode (serverStatus) 200 is. In andere gevallen kan de back-endserver 500 retourneren.

Oorzaak: De client verzendt een header met CR LF-tekens.

Oplossing: Vervang de CR LF-tekens door SP (witruimte) en verzend de aanvraag opnieuw naar Application Gateway.

Volgende stappen

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