Megosztás a következőn keresztül:

HTTP-válaszkódok az Application Gatewayben

Ez a cikk azt ismerteti, hogy Azure-alkalmazás Gateway miért ad vissza adott HTTP-válaszkódokat. A gyakori okok és hibaelhárítási lépések segítséget nyújtanak a HTTP-válaszkód hiba kiváltó okának meghatározásában. A HTTP-válaszkódokat vissza lehet adni egy ügyfélkérésnek, függetlenül attól, hogy egy háttérbeli cél felé indítottak-e kapcsolatot.

3XX válaszkódok (átirányítás)

300–399 válasz jelenik meg, ha egy ügyfélkérés megfelel egy olyan Application Gateway-szabálynak, amely átirányításokat konfigurált. Az átirányítások változtatás nélkül konfigurálhatók egy szabályra, vagy útvonaltérkép-szabályon keresztül. Az átirányításokról további információt az Application Gateway átirányítási áttekintésében talál.

301 Állandó átirányítás

A HTTP 301-válaszok akkor jelennek meg, ha egy átirányítási szabály meg van adva az Állandó értékkel.

302 Találat

A HTTP 302-válaszok akkor jelennek meg, ha egy átirányítási szabály meg van adva a Found értékkel.

303 Lásd: Egyéb

A HTTP 302-válaszok akkor jelennek meg, ha átirányítási szabály van megadva a See Other értékkel.

307 Ideiglenes átirányítás

A HTTP 307-válaszok akkor jelennek meg, ha egy átirányítási szabály meg van adva az Ideiglenes értékkel.

4XX válaszkódok (ügyfélhiba)

A 400–499 válaszkódok az ügyfél által kezdeményezett problémát jeleznek. Ezek a problémák a kéréseket kezdeményező ügyféltől a nem egyező állomásnévig, a kérés időtúllépésétől, a hitelesítés nélküli kéréstől, a rosszindulatú kéréstől és egyebekig terjedhetnek.

Az Application Gateway olyan metrikákat gyűjt, amelyek rögzítik a 4xx/5xx állapotkódok eloszlását, és olyan naplózási mechanizmussal rendelkezik, amely olyan információkat rögzít, mint például az URI-ügyfél IP-címe a válaszkóddal. A metrikák és a naplózás további hibaelhárítást tesznek lehetővé. Az ügyfelek 4xx választ is kaphatnak más proxyktól az ügyféleszköz és az Application Gateway között. Például CDN (Content Delivery Network) és más hitelesítési szolgáltatók. További információért tekintse meg az alábbi cikkeket.

Az Application Gateway V2 termékváltozatdiagnosztikai naplói által támogatott metrikák

400 – Hibás kérés

A HTTP 400-válaszkódok általában akkor figyelhetők meg, ha:

  • Nem HTTP-/HTTPS-forgalom irányul egy HTTP- vagy HTTPS-figyelővel rendelkező Application Gatewayre.
  • HTTP-forgalom lett indítva egy HTTPS-figyelő felé, és nincs konfigurálva átirányítás.
  • A kölcsönös hitelesítés konfigurálva van, de nem képes megfelelően egyeztetni.
  • A kérés nem felel meg az RFC-nek.

Az RFC-nek való nem megfelelő kérés néhány gyakori oka a következő:

Kategória Példák
Érvénytelen gazdagép a kérés sorában Házigazda, amely két kettőspontot tartalmaz (example.com:8090:8080)
Gazdagép fejléce hiányzik A kérelem nem tartalmaz Host fejlécet
Hibás vagy illegális karakter jelenléte A kódolt karakterek a következők: &,!. A megoldás az, hogy ezeket százalékos kódolással lássa el. Például: %>
Érvénytelen HTTP-verzió Letöltés /content.css HTTP/0.3
A fejlécmező neve és az URI nem ASCII-karaktert tartalmaz GET /«úü¿.doc HTTP/1.1
Hiányzik a Tartalom Hosszúság fejléce a POST kéréshez Magától értetődő
Érvénytelen HTTP-metódus GET123 /index.html HTTP/1.1
Ismétlődő Fejlécek Engedélyezés:<base64 kódolású tartalom>, Engedélyezés: <base64 kódolású tartalom>
Érvénytelen érték a Content-Length esetén Tartalomhossz: abc,Tartalomhossz: -10

Ha a kölcsönös hitelesítés konfigurálva van, több forgatókönyv is HTTP 400-as válasz visszaküldéséhez vezethet az ügyfélnek, például:

  • A kölcsönös hitelesítés engedélyezve van, de az ügyféltanúsítvány nem jelent meg.
  • A DN (megkülönböztető név) érvényesítése engedélyezve van, és az ügyféltanúsítvány DN-je nem egyezik a megadott tanúsítványlánc DN-ével.
  • Az ügyféltanúsítvány-lánc nem egyezik a megadott SSL-házirendben konfigurált tanúsítványlánccal.
  • Az ügyféltanúsítvány lejárt.
  • Az OCSP (online tanúsítványállapot-protokoll) ügyfél-visszavonási ellenőrzése engedélyezve van, és a tanúsítvány visszavonva.
  • Az OCSP (online tanúsítványállapot-protokoll) ügyfél-visszavonási ellenőrzése engedélyezve van, de nem lehet kapcsolatba lépni vele.
  • Az OCSP (online tanúsítványállapot-protokoll) ügyfél-visszavonási ellenőrzése engedélyezve van, de az OCSP-válaszadó nem szerepel a tanúsítványban.

További információ a kölcsönös hitelesítés hibaelhárításáról: Hibakód hibaelhárítása.

401 – Jogosulatlan

Ha az ügyfél nem jogosult az erőforrás elérésére, http 401 jogosulatlan választ ad vissza az ügyfélnek. Több oka is van annak, hogy a 401-es visszatérhet. Az alábbiakban néhány okot és lehetséges megoldást mutatunk be.

  • Ha az ügyfélnek van hozzáférése, akkor lehet, hogy elavult a böngésző gyorsítótára. Törölje a böngésző gyorsítótárát, és próbálja meg újra elérni az alkalmazást.

Ha a háttérkészlet NTLM-hitelesítéssel van konfigurálva, HTTP 401 jogosulatlan válasz adható vissza az AppGW mintavételi kérésére. Ebben a forgatókönyvben a backend egészségesnek van jelölve. Ezt a problémát többféleképpen is meg lehet oldani:

  • Névtelen hozzáférés engedélyezése a backend poolhoz.
  • Állítsa be a szondát úgy, hogy a kérést egy másik "hamis" webhelyre küldje, amely nem igényel NTLM-et.
  • Nem ajánlott, mivel ez nem árulja el, hogy az application gateway mögötti tényleges webhely aktív-e vagy sem.
  • Konfigurálja az Application Gatewayt úgy, hogy 401 válasz legyen érvényes a mintavételekre: Mintavételi feltételek egyeztetése.

403 – Hozzáférés megtagadva

A HTTP 403 Forbidden akkor jelenik meg, ha az ügyfelek WAF (webalkalmazási tűzfal) termékváltozatokat használnak, és a WAF megelőzési módban van konfigurálva. Ha az engedélyezett WAF-szabálykészletek vagy az egyéni megtagadási WAF-szabályok megfelelnek egy bejövő kérés jellemzőinek, az ügyfél 403 tiltott választ jelenik meg.

A 403 választ kapó ügyfelek egyéb okai a következők:

  • Az App Service-t használja háttérrendszerként, és úgy van konfigurálva, hogy csak az Application Gatewayről engedélyezze a hozzáférést. Ez 403-at eredményezhet az App Servicesben. Ez általában az Olyan átirányítások/href-hivatkozások miatt történik, amelyek közvetlenül az App Servicesre mutatnak, nem pedig az Application Gateway IP-címére mutatnak.
  • Ha egy tárolási bloghoz fér hozzá, és az Application Gateway és a tárvégpont eltérő régióban található, akkor 403-os hiba jelenik meg, ha az Application Gateway nyilvános IP-címe nem szerepel a listán. Lásd: Hozzáférés biztosítása internetes IP-címtartományból.

404 – Az oldal nem található

Egy HTTP 404 válasz akkor generálódik, amikor az Application Gateway (V2 SKUs) felé érkezik egy kérés olyan hostnévvel, amely nem felel meg a konfigurált többhelyszínes hallgatók egyikének sem, és nincs jelen alapvető hallgató. További információ a figyelők típusairól.

408 – Időtúllépés kérése

HTTP 408-válasz akkor figyelhető meg, ha az Application Gateway előtérbeli figyelőjének küldött ügyfélkérések 60 másodpercen belül nem válaszolnak vissza. Ez a hiba a helyszíni hálózatok és az Azure közötti forgalmi torlódás miatt figyelhető meg, amikor a virtuális berendezés ellenőrzi a forgalmat, vagy maga az ügyfél túlterhelődik.

413 – Kérelem túl nagy entitással

HTTP 413-válasz figyelhető meg, ha az Azure Web Application Firewallt használja az Application Gatewayen , és az ügyfélkérés mérete meghaladja a kérelem törzsméretének maximális korlátját. A maximális kérés testméret mező szabályozza a kérés teljes méretkorlátozását, kivéve a fájlfeltöltéseket. A kérés testméretének alapértelmezett értéke 128 KB. További információ: Webalkalmazási tűzfal kérések méretkorlátjai.

499 – Az ügyfél lezárta a kapcsolatot

HTTP 499-válasz jelenik meg, ha a 2-es verziójú termékváltozatot használó alkalmazásátjáróknak küldött ügyfélkérés lezárul, mielőtt a kiszolgáló befejezi a válaszadást. Ez a hiba 2 forgatókönyvben figyelhető meg. Az első eset az, amikor a rendszer nagy választ ad vissza az ügyfélnek, és előfordulhat, hogy az ügyfél bezárta vagy frissítette az alkalmazást, mielőtt a kiszolgáló befejezte a nagy válasz küldését. A második forgatókönyv az, amikor az ügyféloldali időtúllépés alacsony, és nem vár elég sokáig ahhoz, hogy megkapja a választ a kiszolgálótól. Ebben az esetben jobb, ha növeli az ügyfél időtúllépését. Az 1. verziós termékváltozatot használó Application Gatewayekben http 0 válaszkód jelenhet meg a kapcsolatot lezáró ügyfél számára, mielőtt a kiszolgáló is befejezi a válaszadást.

5XX válaszkódok (kiszolgálóhiba)

Az 500–599 válaszkód azt jelzi, hogy probléma lépett fel az Application Gateway vagy a háttérkiszolgáló esetében a kérés végrehajtása során.

500 – Belső kiszolgálóhiba

Az Azure Application Gateway nem jeleníthet meg 500-as válaszkódokat. Ha ezt a kódot látja, nyisson meg egy támogatási kérést, mert ez a probléma a szolgáltatás belső hibája. A támogatási eset megnyitásáról további információt a Azure-támogatás kérés létrehozása című témakörben talál.

502 – Rossz átjáró

A HTTP 502-hibáknak számos kiváltó oka lehet, például:

Az 502-ben előforduló hibákkal és azok elhárításával kapcsolatos információkért tekintse meg a Hibás átjáró hibáinak elhárítása című témakört.

504 – Az átjáró időtúllépése

Az Azure Application Gateway V2 termékváltozata HTTP 504-et küldött, ha a háttérrendszer válaszideje meghaladja a háttérbeállításban konfigurált időtúllépési értéket.

IIS (Internet Information Services webkiszolgáló)

Ha a háttérkiszolgáló IIS, tekintse meg a webhelyek alapértelmezett korlátait az időtúllépési érték beállításához. Részletekért tekintse meg az connectionTimeout attribútumot. Győződjön meg arról, hogy a kapcsolat időtúllépése megegyezik az IIS-ben, vagy nem lépi túl a háttérbeállításban beállított időtúllépést.

Nginx

Ha a háttérkiszolgáló Nginx vagy Nginx bejövőforgalom-vezérlő, és felsőbb rétegbeli kiszolgálókkal rendelkezik, győződjön meg arról, hogy az egyezések értéke nginx:proxy_read_timeout nem haladja meg a háttérbeállításban beállított időtúllépés értékét.

Hibaelhárítási forgatókönyvek

"ERRORINFO_INVALID_HEADER" hiba az Access-naplókban

Probléma: Az Access-napló "ERRORINFO_INVALID_HEADER" hibaüzenetet jelenít meg egy kérés esetében, annak ellenére, hogy a háttérrendszer válaszkódja (serverStatus) 200. Más esetekben a háttérkiszolgáló 500 értéket adhat vissza.

Ok: A kliens olyan fejlécet küld, amely CR LF karaktereket tartalmaz.

Megoldás: Cserélje le a CR LF karaktereket sp (whitespace) karakterre, és adja meg újra a kérést az Application Gatewaynek.

Következő lépések

Ha a cikkben szereplő információk nem segítenek a probléma megoldásában, küldjön támogatási jegyet.