Delen via

HTTP-antwoordcodes in Application Gateway

Samenvatting

In dit artikel wordt uitgelegd waarom Azure Application Gateway specifieke HTTP-antwoordcodes retourneert. Het biedt veelvoorkomende oorzaken en stappen voor probleemoplossing om u te helpen de hoofdoorzaak van een HTTP-antwoordcode van een fout te bepalen. Application Gateway kan HTTP-antwoordcodes retourneren aan een clientaanvraag, ongeacht of er een verbinding met een back-enddoel wordt gestart.

Opmerking

Als een clientverbinding mislukt voordat Application Gateway een HTTP-antwoord retourneert, is de fout waarschijnlijk een TLS-handshakefout (Transport Layer Security). Veelvoorkomende oorzaken zijn niet-overeenkomende TLS-versies (de client gebruikt bijvoorbeeld TLS 1.0 of 1.1 terwijl voor de gateway TLS 1.2 of hoger is vereist) en niet-ondersteunde coderingssuites. Vanaf 31 augustus 2025 stopt Azure Application Gateway de ondersteuning voor TLS 1.0 en 1.1. Zie Application Gateway TLS-beleidsoverzicht en TLS-beleidsversies en coderingssuites configureren voor meer informatie.

3XX-antwoordcodes (omleiding)

Application Gateway retourneert 300-399-antwoorden wanneer een clientaanvraag overeenkomt met een toepassingsgatewayregel die omleidingen heeft geconfigureerd. U kunt omleidingen configureren voor een regel as-is of via een padtoewijzingsregel. Zie application gateway-omleidingsoverzicht voor meer informatie over omleidingen.

301 Permanente omleiding

Application Gateway retourneert HTTP 301-antwoorden wanneer u een omleidingsregel opgeeft met de permanente waarde.

302 Gevonden

Application Gateway retourneert HTTP 302-antwoorden wanneer u een omleidingsregel opgeeft met de waarde Gevonden .

303 Zie andere

Application Gateway retourneert HTTP 303-antwoorden wanneer u een omleidingsregel opgeeft met de waarde Overige weergeven .

307 Tijdelijke omleiding

Application Gateway retourneert HTTP 307-antwoorden wanneer u een omleidingsregel opgeeft met de tijdelijke waarde.

4XX-antwoordcodes (klantfout)

400-499-statuscodes geven een probleem aan die de client zelf veroorzaakt. 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 en een logboekregistratiemechanisme hebben 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.

400 – Ongeldige aanvraag

Vaak ziet u HTTP 400-antwoordcodes wanneer:

  • U initieert niet-HTTP- of HTTPS-verkeer naar een toepassingsgateway met een HTTP- of HTTPS-listener.
  • U initieert HTTP-verkeer naar een listener via HTTPS, zonder dat er een doorsturing geconfigureerd is.
  • U configureert wederzijdse verificatie, maar Application Gateway 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 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

Wanneer u wederzijdse verificatie configureert, kunnen verschillende scenario's ertoe leiden dat een HTTP 400-antwoord wordt geretourneerd door de client, waaronder:

  • U schakelt wederzijdse verificatie in, maar het clientcertificaat is niet gepresenteerd.
  • U schakelt DN-validatie (Distinguished Name) in 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.
  • U schakelt de OCSP-clientintrekkingscontrole (Online Certificate Status Protocol) in en het certificaat wordt ingetrokken.
  • U schakelt ocsp-clientintrekkingscontrole in, maar Application Gateway kan geen contact opnemen met OCSP-responder.
  • U schakelt ocsp-clientintrekkingscontrole in, maar de 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

Application Gateway retourneert een niet-geautoriseerd HTTP 401-antwoord op de client als de client niet is geautoriseerd voor toegang tot de resource. Er bestaan verschillende redenen om 401 te retourneren. De volgende lijst bevat een aantal redenen met 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.

Application Gateway kan een HTTP 401-antwoord retourneren dat niet gemachtigd is voor appGW-testaanvragen als u de back-endpool configureert met NTLM-verificatie . In dit scenario markeert Application Gateway het back-end als gezond. Los dit probleem op met behulp van een van de volgende methoden:

  • 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 deze oplossing ons niet vertelt of de werkelijke site achter de toepassingsgateway al dan niet actief is.
  • Stel de applicatiegateway zo in dat 401-antwoorden als geldig worden beschouwd voor de probes: Voorwaarden voor overeenkomende probes.

403 - Verboden

Application Gateway toont HTTP 403 Verboden wanneer u WAF-SKU's (Web Application Firewall) gebruikt en WAF hebt geconfigureerd in de preventiemodus. Als WAF-regelsets of aangepaste WAF-regels voor weigeren overeenkomen met de kenmerken van een binnenkomende aanvraag, geeft Application Gateway een 403 verboden antwoord aan de client.

Fout-positieven van WAF oplossen (legitieme aanvragen geblokkeerd door WAF-regels):

  1. Schakel diagnostische WAF-logboeken in en controleer het ruleId_s veld om te bepalen welke regel de aanvraag blokkeert.
  2. Schakel de WAF tijdelijk over naar de detectiemodus om overeenkomende regels te registreren zonder verkeer te blokkeren. Deze aanpak helpt u om valse positieven te bevestigen voordat u regelwijzigingen aanbrengt. Zie WAF-beleidsinstellingen voor meer informatie.
  3. Maak WAF-uitsluitingen voor specifieke verzoekkenmerken (headers, cookies of argumenten) die fout-positieven veroorzaken.
  4. Als een beheerde regel consistent fout-positieven veroorzaakt en uitsluitingen onvoldoende zijn, schakelt u deze regel in het WAF-beleid uit.

Zie voor gedetailleerde richtlijnen Problemen met WAF oplossen voor Application Gateway en beste praktijken voor WAF.

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

  • h2c protocol upgrade attempts: Application Gateway retourneert 403-fouten wanneer clients proberen een upgrade uit te voeren van HTTP/1.1 naar HTTP/2.0 met behulp van het h2c-protocol (HTTP/2 Cleartext). Application Gateway ondersteunt alleen HTTP/2 via TLS (HTTPS-listeners). Het biedt geen ondersteuning voor h2c-protocolupgrades via HTTP-listeners. Dit gedrag treedt op, ongeacht de WAF-modus. Clients moeten systeemeigen HTTP/2-verbindingen via HTTPS gebruiken of op HTTP/1.1 blijven zonder upgradepogingen.
  • U gebruikt App Service als back-end en u hebt deze geconfigureerd om alleen toegang vanuit Application Gateway toe te staan. Deze configuratie kan een 403-fout retourneren vanuit de App Services. Deze fout treedt meestal op vanwege omleidingen of href-koppelingen die rechtstreeks naar App Services verwijzen in plaats van naar het IP-adres van de Application Gateway.
  • Als u toegang hebt tot een opslagblob en de Application Gateway en het opslageindpunt zich in verschillende regio's bevinden, 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 is niet gevonden

Er wordt een HTTP 404-antwoord gegenereerd wanneer u een aanvraag indient 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. Zie soorten luisteraars voor meer informatie.

408 – Time-out aanvragen

U kunt een HTTP 408-antwoord observeren wanneer clientaanvragen naar de front-endlistener van Application Gateway niet binnen 60 seconden reageren. Mogelijk ziet u deze fout 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

U kunt een HTTP 413-antwoord bekijken 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

Er wordt een HTTP 499-antwoord weergegeven als een clientaanvraag die u hebt verzonden naar toepassingsgateways met behulp van v2-SKU wordt gesloten voordat de server reageert. U kunt deze fout in twee scenario's bekijken. 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 een probleem aan met application gateway of de back-endserver tijdens het uitvoeren van de aanvraag.

500 – Interne serverfout

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

502 - Bad Gateway

HTTP 502-fouten kunnen verschillende hoofdoorzaken hebben, waaronder:

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

503 - Service niet beschikbaar

HTTP 503-antwoorden geven aan dat Application Gateway of een back-endserver de aanvraag tijdelijk niet kan verwerken. Veelvoorkomende oorzaken zijn onder andere:

  • Alle leden van de back-endpool zijn ongezond, zoals wordt bepaald door gezondheidsonderzoeken en er is geen gezonde server beschikbaar om aanvragen te verwerken.
  • De back-endserver is overbelast of ondergaat onderhoud en retourneert 503 rechtstreeks naar Application Gateway.
  • Automatische schaalaanpassing van Application Gateway V2 wordt uitgevoerd en nieuwe exemplaren zijn nog niet klaar om verkeer te verwerken.
  • Verbindingslimieten zijn bereikt op Application Gateway of de backendserver.

Om 503-fouten op te lossen:

  1. Controleer het deelvenster Back-endstatus in Azure Portal om de status van het lid van de back-endpool te controleren.
  2. Controleer de configuratie van de gezondheidsonderzoeken om te verzekeren dat de probes niet ten onrechte gezonde backends als ongezond markeren. Voor meer informatie, zie het overzicht gezondheidsonderzoek.
  3. Controleer of de backendapplicatie operationeel is door er direct toegang toe te verkrijgen, zonder gebruik te maken van de Application Gateway.
  4. Controleer metrische gegevens van Application Gateway voor het aantal verbindingen en het gebruik van capaciteitseenheden in Azure Monitor.
  5. Controleer voor V2-SKU's de autoschaalinstellingen om ervoor te zorgen dat er voldoende minimale hoeveelheden exemplaren zijn tijdens pieken in het verkeer.

Bekijk Problemen met de gezondheid van de back-end oplossen voor meer informatie.

504 – Gateway-time-out

Azure Application Gateway V2 SKU verzendt HTTP 504-fouten als de reactietijd van de back-end de time-outwaarde overschrijdt die u in de back-endinstelling configureert.

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 groter 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 upstream-servers heeft, moet u ervoor zorgen dat de waarde van nginx:proxy_read_timeout overeenkomt of niet hoger is dan de time-out die is ingesteld in de back-endinstellingen.

Scenario's voor probleemoplossing

Fout 'ERRORINFO_INVALID_HEADER' in toegangslogboeken

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

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

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

  • Last updated on