Dela via

HTTP-svarskoder i Application Gateway

  • Artikel

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 rotorsaken till felet HTTP-svarskod. HTTP-svarskoder kan returneras till en klientbegäran om en anslutning initierades till ett serverdelsmål 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.

Permanent omdirigering 301

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 samlar in fördelningen av 4xx/5xx-statuskoder har en loggningsmekanism som samlar in information som URI-klientens IP-adress med 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 och andra autentiseringsprovidrar. Mer information finns i följande artiklar.

Mått som stöds av Application Gateway V2 SKU-diagnostikloggar

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örhandla korrekt.
  • Begäran är inte kompatibel med RFC.

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

Kategori Exempel
Ogiltig värd i begäranderad Värd som innehåller två kolon (example.com:8090:8080)
Värdhuvud saknas Begäran har inte värdhuvud
Förekomst av felaktigt eller olagligt tecken Reserverade tecken är ,!. Lösningen är att koda den i procent. Till exempel: %&
Ogiltig HTTP-version Hämta /content.css HTTP/0.3
Rubrikfältnamn och URI innehåller icke-ASCII-tecken GET /«úü¡»¿.doc HTTP/1.1
Rubrik för innehållslängd saknas för POST-begäran Självförklarande
Ogiltig HTTP-metod GET123 /index.html HTTP/1.1
Duplicerade rubriker Authorization:<base64-kodat innehåll>, auktorisering: <base64-kodat innehåll>
Ogiltigt värde i Innehållslängd Innehållslängd: abc,Innehållslängd: -10

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

  • Klientcertifikatet visas inte, men ömsesidig autentisering är aktiverat.
  • DN-validering ä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.
  • KONTROLLEN AV OCSP-klientåterkallning är aktiverad och certifikatet har återkallats.
  • Kontrollen av OCSP-klientåterkallning är aktiverad, men kan inte kontaktas.
  • KONTROLLEN AV OCSP-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-otillåtet svar kan returneras till AppGW-avsökningsbegäran om serverdelspoolen har konfigurerats med NTLM-autentisering . I detta scenario markeras serverdelen som felfri. Det finns flera sätt att lösa problemet:

  • Tillåt anonym åtkomst på serverdelspoolen.
  • 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 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 visas ett 403-förbjudet svar.

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 och lagringsslutpunkten finns i en annan region returneras ett 403-fel om Application Gateways offentliga IP-adress inte är tillåten. Se Bevilja åtkomst från ett INTERNET-IP-intervall.

404 – Det gick inte att hitta sidan

Ett HTTP 404-svar kan returneras om en begäran skickas till en Application Gateway som är:

408 – Tidsgräns för begäran

Ett HTTP 408-svar kan observeras när klientbegäranden till programgatewayens klientdelslyssnare inte svarar 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 502-fel kan ha flera rotorsaker, till exempel:

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

504 – Gateway-timeout

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

Om serverdelsservern är IIS, se du Standardgränser för webbplatser för att ange värdet för tidsgränsen. Mer information finns i attributet connectionTimeout . Kontrollera 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 överordnade servrar kontrollerar du att värdet nginx:proxy_read_timeout för matchar eller inte överskrider med tidsgränsen i serverdelsinställningen.

Nästa steg

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