HTTP-antwoordcodes in Azure 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 Azure Application Gateway de ondersteuning voor TLS 1.0 en 1.1 stopgezet. Zie Application Gateway TLS-beleidsoverzicht en TLS-beleidsversies en coderingssuites configureren voor meer informatie.

3XX-antwoordcodes (omleiding)

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

301 Permanent

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 overige

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

307 Tijdelijk

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

4XX-antwoordcodes (klantfout)

HTTP 400-499-responscodes duiden op een probleem dat door de client wordt veroorzaakt. Deze problemen kunnen variëren van de client die aanvragen initieert tot een niet-overeenkomende hostnaam, time-outs voor aanvragen, niet-geverifieerde aanvragen, schadelijke aanvragen en meer.

Application Gateway verzamelt metrische gegevens die de distributie van HTTP 4xx- en 5xx-statuscodes vastleggen en heeft 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 HTTP 4xx-antwoorden ontvangen van andere proxy's tussen het clientapparaat en Application Gateway, waaronder Content Delivery Network (CDN) 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 de aanvraag voor opmerkingen (RFC).

De volgende tabel bevat enkele veelvoorkomende redenen waarom de aanvraag niet compatibel is met RFC.

Categorie Voorbeelden
Ongeldige host in aanvraagregel Host dat twee dubbele punten bevat (example.com:8090:8080)
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 in POST-aanvraag Spreekt voor zich
Ongeldige HTTP-methode GET123 /index.html HTTP/1.1
Dubbele kopteksten Autorisatie:<met base64 gecodeerde inhoud>, autorisatie: <met base64 gecodeerde inhoud>
Ongeldige waarde voor Content-Length Lengte van inhoud: abc, inhoudslengte: -10

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

  • U schakelt wederzijdse verificatie in, maar het clientcertificaat is niet gepresenteerd.
  • U hebt validatie van de distinguished name (DN) 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 (Secure Sockets Layer).
  • Het clientcertificaat is verlopen.
  • U schakelt een ocsp-clientintrekkingscontrole (Online Certificate Status Protocol) in en het certificaat wordt ingetrokken.
  • U schakelt een OCSP-clientintrekkingscontrole in, maar Application Gateway kan geen contact opnemen met OCSP-responder.
  • U schakelt een 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. 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 niet-geautoriseerd antwoord retourneren op een Application Gateway-testaanvraag 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 in de back-endpool.
  • Configureer de test om de aanvraag te verzenden naar een andere nepsite waarvoor geen NTLM-verificatie is vereist.
  • Configureer Application Gateway om HTTP 401-antwoorden toe te staan als geldig voor de tests. Zie Testkoppelingsvoorwaarden voor meer informatie.

403 - Verboden

Application Gateway presenteert HTTP 403 Verboden wanneer u WAF-SKU's (Azure Web Application Firewall) gebruikt en WAF hebt geconfigureerd in de preventiemodus. Indien ingeschakeld, komen WAF-regelsets of aangepaste WAF-regels voor weigeren overeen met de kenmerken van een binnenkomende aanvraag. Application Gateway geeft vervolgens een HTTP 403-antwoord (Forbidden) aan de client.

Voer de volgende stappen uit om problemen met fout-positieven van WAF (legitieme aanvragen geblokkeerd door WAF-regels) op te lossen:

  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 HTTP 403-antwoorden ontvangen, zijn:

  • upgradepogingen voor h2c-protocollen. Application Gateway retourneert HTTP 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 biedt alleen ondersteuning voor HTTP/2 via TLS -listeners (Transport Layer Security). 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 Azure App Service als back-end en u hebt deze geconfigureerd om alleen toegang vanuit Application Gateway toe te staan. Deze configuratie kan leiden tot een HTTP 403-fout van 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 Toepassingsgateway.
  • Als u toegang hebt tot een opslag-blob en de Application Gateway en het opslageindpunt zich in verschillende regio's bevinden, wordt een HTTP 403-fout geretourneerd als het openbare IP-adres van de Application Gateway niet op de allowlist staat. Zie Toegang verlenen vanuit een IP-adresbereik voor internet voor meer informatie.

404 - Pagina is niet gevonden

Application Gateway (v2-SKU's) genereert een HTTP 404-antwoord wanneer u een aanvraag indient met een hostnaam die niet overeenkomt met een van de geconfigureerde listeners voor meerdere sites en er is geen basislistener aanwezig. Zie soorten luisteraars voor meer informatie.

408 – Time-out aanvragen

U krijgt een HTTP 408-antwoord wanneer clientaanvragen naar de frontend-listener van Application Gateway niet binnen 60 seconden worden beantwoord. Deze fout kan optreden als gevolg van verkeersopstoppingen tussen on-premises netwerken en Azure, wanneer virtuele apparaten het verkeer inspecteren of de client zelf overbelast raakt.

413 – Aanvraagentiteit te groot

Er wordt een HTTP 413-antwoord weergegeven wanneer u Azure Web Application Firewall gebruikt in Application Gateway en de grootte van de clientaanvraag groter is dan de maximale limiet voor de aanvraagbodygrootte. 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 treedt op als een clientaanvraag die u naar toepassingsgateways hebt verzonden met behulp van de v2-SKU wordt gesloten voordat de server reageert. Deze fout treedt op in twee scenario's:

  • Wanneer een grote reactie naar de client wordt gestuurd en de client de toepassing heeft gesloten of vernieuwd voordat de server klaar was met het verzenden van een grote reactie.
  • 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 aan de clientzijde te verhogen. In toepassingsgateways die gebruikmaken van de v1-SKU, kan er een HTTP 0-antwoordcode worden gegenereerd voor de client die de verbinding sluit voordat de server ook reageert.

5XX-antwoordcodes (serverfout)

HTTP 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 is voor de service. Zie Maak een ondersteuning voor Azure aanvraag voor meer informatie over het openen van een ondersteuningsaanvraag.

502 - Bad Gateway

HTTP 502-fouten kunnen verschillende hoofdoorzaken hebben, waaronder:

Zie Foute gatewayfouten oplossen voor informatie over scenario's waarin HTTP 502-fouten optreden en hoe u 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 HTTP 503 rechtstreeks naar Application Gateway.
  • Automatische schaalaanpassing van Application Gateway v2 wordt uitgevoerd en nieuwe exemplaren zijn nog niet gereed om verkeer te verwerken.
  • Verbindingslimieten zijn bereikt op Application Gateway of de backendserver.

Volg deze stappen 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 instellingen voor automatische schaalaanpassing om ervoor te zorgen dat er voldoende minimale exemplaren worden geteld tijdens pieken in het verkeer.

Raadpleeg Problemen met de gezondheid van de backend in Application Gateway oplossen voor meer informatie.

504 – Time-out van de gateway

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

Internet Information Services (IIS)-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 verbindingstime-out in IIS overeenkomt met of niet hoger is dan de time-outwaarde die is ingesteld in de Backend Settings.

Nginx

Als de backendserver Nginx of Nginx Ingress Controller is en upstreamservers heeft, zorg er dan voor dat de waarde van nginx:proxy_read_timeout overeenkomt met of niet hoger is dan de time-out die is ingesteld in de Backend-instellingen.

Scenario's voor probleemoplossing

Fout 'ERRORINFO_INVALID_HEADER' in toegangslogboeken

Probleem

Het Access-logboek toont een ERRORINFO_INVALID_HEADER fout voor een verzoek, ook al is de backendresponscode (200) serverStatus. In andere gevallen retourneert 500de back-endserver.

Oorzaak

De client verzendt een header die Carriage Return (CR)- en Line Feed (LF)-tekens bevat.

Solution

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

  • Laatst bijgewerkt om