HTTP-válaszkódok az Application Gatewayben

  • Cikk

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 konfigurálhatók szabályon is, 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álatok

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 é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, és nem tud 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érelemsorban Két kettőspontot tartalmazó gazdagép (example.com:8090:8080)
Hiányzó gazdagépfejléc A kérelem nem rendelkezik gazdagépfejléccel
Hibás vagy illegális karakter jelenléte A fenntartott karakterek & ,!. A kerülő megoldás az, hogy százalékként kódozza. Például: %>
Érvénytelen HTTP-verzió A /content.css HTTP/0.3 beszerzése
A fejlécmező neve és az URI nem ASCII-karaktert tartalmaz GET /«úü¿.doc HTTP/1.1
Hiányzó tartalomhossz fejléce a POST-kérelemhez 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 értékben Tartalomhossz: abc,Tartalomhossz: -10

Ha a kölcsönös hitelesítés konfigurálva van, több esetben http 400-as választ ad vissza az ügyfél, például:

  • Az ügyféltanúsítvány nem jelenik meg, de a kölcsönös hitelesítés engedélyezve van.
  • A DN é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 ügyfél-visszavonási ellenőrzése engedélyezve van, és a tanúsítvány visszavonva.
  • Az OCSP-ügyfél visszavonási ellenőrzése engedélyezve van, de nem lehet kapcsolatba lépni vele.
  • Az OCSP-ü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 – Unauthorized

Ha az ügyfél nem jogosult az erőforrás elérésére, http 401 jogosulatlan választ ad vissza az ügyfélnek. A 401-nek több oka is van. Az alábbiakban néhány lehetséges hibalehetőséget is bemutatunk.

  • Ha az ügyfélnek van hozzáférése, akkor lehet, hogy elavult a böngésző gyorsítótárában. 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érelemhez. 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 – Forbidden

A HTTP 403 Forbidden akkor jelenik meg, ha az ügyfelek WAF-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ó

HTTP 404-válasz akkor adható vissza, ha a rendszer egy kérelmet küld egy application gatewaynek, amely a következő:

408 – Kérelem időtúllépé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 – Túl nagy entitás kérése

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 elvben nem jeleníthet meg 500-as válaszkódot. Ha ezt a kódot látja, nyisson támogatási kérést, mert ez a probléma a szolgáltatás belső hibáját jelzi. 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 – Á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

Ha a háttértár kiszolgálója az IIS, az időkorlát értékének beállításához lásd: A weboldalak alapértelmezett korlátai. Részletekért tekintse meg az connectionTimeout attribútumot. Győződjön meg arról, hogy az IIS-ben a kapcsolat időkorlátja megegyezik a backend-beállításban beállított időkorlátozással, vagy nem haladja meg azt.

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 nem haladja meg a háttérbeállításban beállított időtúllépést nginx:proxy_read_timeout .

További 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.