HTTP-svarskoder i Application Gateway

Den här artikeln beskriver varför Azure Application Gateway returnerar specifika HTTP-svarskoder. Vanliga orsaker och felsökningssteg tillhandahålls för att hjälpa dig att fastställa orsaken till felet med HTTP-svarskoden. HTTP-svarskoder kan returneras till en klientbegäran oavsett om en anslutning initierades till ett mål på serverns baksida eller inte.

3XX-svarskoder (omdirigering)

300–399-svar visas när en klientbegäran matchar en programgatewayregel som har konfigurerat omdirigeringar. Omdirigeringar kan konfigureras på en regel som den är eller via en sökvägsöversiktsregel. Mer information om omdirigeringar finns i Översikt över omdirigering av Application Gateway.

301 Permanent omdirigering

HTTP 301-svar visas när en omdirigeringsregel anges med värdet Permanent .

302 hittades

HTTP 302-svar visas när en omdirigeringsregel anges med värdet Hittad .

303 Se övrigt

HTTP 302-svar visas när en omdirigeringsregel anges med värdet Se annat .

307 Tillfällig omdirigering

HTTP 307-svar visas när en omdirigeringsregel anges med det tillfälliga värdet.

4XX-svarskoder (klientfel)

400–499-svarskoder anger ett problem som initieras från klienten. De här problemen kan sträcka sig från klienten som initierar begäranden till ett omatchat värdnamn, tidsgräns för begäranden, oautentiserad begäran, skadlig begäran med mera.

Application Gateway samlar in mått som visar fördelningen av 4xx/5xx-statuskoder och har en loggningsmekanism som fångar information som URI, klientens IP-adress och svarskoden. Mått och loggning möjliggör ytterligare felsökning. Klienter kan också få 4xx-svar från andra proxyservrar mellan klientenheten och Application Gateway. Till exempel CDN (Content Delivery Network) och andra autentiseringsprovidrar. Mer information finns i följande artiklar.

Mått som stöds av Application Gateway V2 SKUDiagnostikloggar

400 – Felaktig begäran

HTTP 400-svarskoder observeras ofta när:

• Icke-HTTP / HTTPS-trafik initieras till en programgateway med en HTTP- eller HTTPS-lyssnare.
• HTTP-trafik initieras till en lyssnare med HTTPS utan att någon omdirigering har konfigurerats.
• Ömsesidig autentisering har konfigurerats och kan inte förhandlas korrekt.
• Begäran är inte kompatibel med RFC.

Några vanliga orsaker till att begäran inte är kompatibel med RFC är:

I fall där ömsesidig autentisering har konfigurerats kan flera scenarier leda till att ett HTTP 400-svar returneras till klienten, till exempel:

• Ömsesidig autentisering är aktiverat men klientcertifikatet visades inte.
• DN-validering (unikt namn) är aktiverat och DN för klientcertifikatet matchar inte DN för den angivna certifikatkedjan.
• Klientcertifikatkedjan matchar inte certifikatkedjan som konfigurerats i den definierade SSL-principen.
• Klientcertifikatet har upphört att gälla.
• Kontroll av klientåterkallning för OCSP (Online Certificate Status Protocol) är aktiverad och certifikatet återkallas.
• OCSP-kontrollen (Online Certificate Status Protocol) för klientåterkallning är aktiverad, men kan inte kontaktas.
• OCSP-kontroll (Online Certificate Status Protocol) Klientåterkallning är aktiverad, men OCSP-svararen finns inte i certifikatet.

Mer information om hur du felsöker ömsesidig autentisering finns i Felkodsfelsökning.

401 – behörighet saknas

Ett HTTP 401-otillåtet svar returneras till klienten om klienten inte har behörighet att komma åt resursen. Det finns flera orsaker till att 401 returneras. Följande är några orsaker till potentiella korrigeringar.

• Om klienten har åtkomst kan den ha en inaktuell webbläsarcache. Rensa webbläsarens cacheminne och försök komma åt programmet igen.

Ett HTTP 401 obehörigt svar kan returneras till förfrågan från AppGW-sond om backend-poolen är konfigurerad med NTLM-autentisering. I detta scenario markeras serverdelen som felfri. Det finns flera sätt att lösa problemet:

• Tillåt anonym åtkomst på backend-poolen.
• Konfigurera avsökningen så att den skickar begäran till en annan "falsk" webbplats som inte kräver NTLM.
• Rekommenderas inte eftersom detta inte talar om för oss om den faktiska platsen bakom programgatewayen är aktiv eller inte.
• Konfigurera programgatewayen så att 401-svar tillåts som giltiga för avsökningarna: Avsökningsmatchningsvillkor.

403 – förbjuden

HTTP 403 Förbjudet visas när kunder använder WAF-sku:er (Web Application Firewall) och har WAF konfigurerat i förebyggande läge. Om aktiverade WAF-regeluppsättningar eller anpassade WAF-regler för nekande matchar egenskaperna för en inkommande begäran, kommer klienten att få ett svar med statuskod 403 som förbjudet.

Andra orsaker till att klienter får 403 svar är:

• Du använder App Service som serverdel och har konfigurerats för att endast tillåta åtkomst från Application Gateway. Detta kan returnera ett 403-fel från App Services. Detta beror vanligtvis på omdirigeringar/href-länkar som pekar direkt på App Services i stället för att peka på Application Gateways IP-adress.
• Om du har åtkomst till en lagringsblogg och Application Gateway samt lagringsslutpunkten finns i en annan region, returneras ett 403-fel om Application Gateways offentliga IP-adress inte finns i tillåtslistan. Se Bevilja åtkomst från ett INTERNET-IP-intervall.

404 – Det gick inte att hitta sidan

Ett HTTP 404-svar genereras när en begäran görs till Application Gateway (V2 SKU:er) med ett värdnamn som inte motsvarar någon av de konfigurerade lyssnarna för flera webbplatser och det inte finns någon grundläggande lyssnare. Läs mer om typer av lyssnare.

408 – Tidsgräns för begäran

Ett HTTP 408-svar kan observeras när klientförfrågningar till frontlistenern i applikationsgatewayen inte besvaras inom 60 sekunder. Det här felet kan observeras på grund av trafikstockningar mellan lokala nätverk och Azure, när den virtuella installationen inspekterar trafiken eller om själva klienten blir överbelastad.

413 – Begärandeentiteten är för stor

Ett HTTP 413-svar kan observeras när du använder Azure Web Application Firewall på Application Gateway och storleken på klientbegäran överskrider den maximala storleksgränsen för begärandetext. Det maximala fältet för brödtext för begäran styr den totala storleksgränsen för begäranden exklusive filuppladdningar. Standardvärdet för brödtextstorlek för begäran är 128 KB. Mer information finns i Storleksbegränsningar för begäranden för webbaserade programbrandväggar.

499 – Klienten stängde anslutningen

Ett HTTP 499-svar visas om en klientbegäran som skickas till programgatewayer med v2 SKU stängs innan servern har svarat. Det här felet kan observeras i två scenarier. Det första scenariot är när ett stort svar returneras till klienten och klienten kan ha stängt eller uppdaterat programmet innan servern har skickat ett stort svar. Det andra scenariot är när tidsgränsen på klientsidan är låg och inte väntar tillräckligt länge för att få svaret från servern. I det här fallet är det bättre att öka tidsgränsen för klienten. I programgatewayer med v1 sku kan en HTTP 0-svarskod genereras för klienten som stänger anslutningen innan servern har svarat.

5XX-svarskoder (serverfel)

500-599-svarskoder anger att ett problem har uppstått med programgatewayen eller serverdelsservern när begäran utfördes.

500 – internt serverfel

Azure Application Gateway ska inte uppvisa 500-svarskoder. Öppna en supportbegäran om du ser den här koden, eftersom det här problemet är ett internt fel för tjänsten. Information om hur du öppnar ett supportärende finns i Skapa en Azure Support begäran.

502 – Felaktig gateway

HTTP-fel 502 kan ha flera grundorsaker, till exempel:

• NSG (nätverkssäkerhetsgrupp), UDR (användardefinierad väg) eller anpassad DNS blockerar åtkomst till medlemmar i serverdelspoolen.
• Backend-VM:er eller instanser av skalningsuppsättningar för virtuella maskiner svarar inte på standardhälsoavsökningen.
• Ogiltig eller felaktig konfiguration av anpassade hälsosonder.
• Azure Application Gateways serverdelspool är inte konfigurerad eller tom.
• Ingen av de virtuella datorerna eller instanserna i VM-skalningsuppsättningen är felfria.
• Tidsgräns för begäran eller anslutningsproblem med användarbegäranden – Azure Application Gateway V1 SKU skickade HTTP 502-fel om svarstiden för serverdelen överskrider tidsgränsvärdet som har konfigurerats i serverdelsinställningen.

Information om scenarier där 502-fel inträffar och hur du felsöker dem finns i Felsöka fel med felaktig gateway.

504 – Tidsgräns för gateway

Azure Application Gateway V2 SKU skickade HTTP 504-fel om svarstiden för serverdelen överskrider det timeout-värde som har konfigurerats i serverdelsinställningen.

IIS (Internet Information Services-webbserver)

Om din bakomliggande server är IIS, läs Standardgränser för webbplatser för att ställa in tidsgränsvärdet. Mer information finns i attributet connectionTimeout . Se till att tidsgränsen för anslutningen i IIS matchar eller överskrider inte tidsgränsen i serverdelsinställningen.

Nginx

Om serverdelsservern är Nginx eller Nginx-ingresskontrollant och om den har uppströmservrar säkerställ att värdet nginx:proxy_read_timeout matchar eller inte överskrider tidsgränsen i serverdelsinställningen.

Felsökningsscenarier

Felet "ERRORINFO_INVALID_HEADER" i Åtkomstloggar

Problem: Åtkomstloggen visar ett "ERRORINFO_INVALID_HEADER"-fel för en begäran, trots att serverdelssvarskoden (serverStatus) är 200. I andra fall kan backend-servern returnera "500."

Orsak: Klienten skickar en header som innehåller CR LF-tecken.

Lösning: Ersätt CR LF-tecknen med SP (blanksteg) och skicka begäran till Application Gateway igen.

Nästa steg

Om informationen i den här artikeln inte hjälper dig att lösa problemet skickar du ett supportärende.