Udostępnij za pośrednictwem

Kody odpowiedzi HTTP w usłudze Application Gateway

Ten artykuł zawiera powody, dla których usługa aplikacja systemu Azure Gateway zwraca określone kody odpowiedzi HTTP. Podano typowe przyczyny i kroki rozwiązywania problemów, które ułatwiają ustalenie głównej przyczyny błędu kodu odpowiedzi HTTP. Kody odpowiedzi HTTP można zwrócić na żądanie klienta, niezależnie od tego, czy połączenie zostało zainicjowane do docelowego serwera zaplecza.

Kody odpowiedzi 3XX (przekierowanie)

Odpowiedzi z zakresu 300–399 są wyświetlane, gdy żądanie klienta spełnia regułę bramy aplikacji z skonfigurowanymi przekierowaniami. Przekierowania można skonfigurować na podstawie reguły jako takiej lub przy użyciu reguły mapy ścieżki. Aby uzyskać więcej informacji na temat przekierowań, zobacz Omówienie przekierowania usługi Application Gateway.

301 Przekierowanie trwałe

Odpowiedzi HTTP 301 są wyświetlane, gdy istnieje określona reguła przekierowania z wartością Permanent.

302 Znaleziono

Odpowiedzi HTTP 302 są prezentowane, gdy zostanie określona reguła przekierowania z wartością Znaleziono .

303 Zobacz inny

Odpowiedzi HTTP 302 są prezentowane, gdy reguła przekierowania jest określona z wartością Zobacz inne .

307 Przekierowanie tymczasowe

Odpowiedzi HTTP 307 są wyświetlane, gdy zostanie określona reguła przekierowania z wartością 'Temporary'.

Kody odpowiedzi 4XX (błąd klienta)

Kody odpowiedzi 400–499 wskazują problem zainicjowany przez klienta. Te problemy mogą być różne od klienta inicjującego żądania do niedopasowanej nazwy hosta, limitu czasu żądania, nieuwierzytelnionego żądania, złośliwego żądania i nie tylko.

Bramka aplikacyjna (Application Gateway) gromadzi metryki dotyczące rozkładu kodów stanu 4xx/5xx i posiada mechanizm logowania, który rejestruje informacje takie jak adres IP klienta oraz identyfikator URI wraz z kodem odpowiedzi. Metryki i rejestrowanie umożliwiają dalsze rozwiązywanie problemów. Klienci mogą również odbierać odpowiedź 4xx z innych serwerów proxy między urządzeniem klienckim a usługą Application Gateway. Na przykład usługa CDN (Content Delivery Network) i inni dostawcy uwierzytelniania. Aby uzyskać więcej informacji, zobacz następujące artykuły.

Metryki obsługiwane przez jednostkę SKU aplikacji Application Gateway w wersji 2Dzienniki diagnostyczne

400 — nieprawidłowe żądanie

Kody odpowiedzi HTTP 400 są często obserwowane, gdy:

  • Ruch nie korzystający z protokołu HTTP/HTTPS jest kierowany do bramy aplikacji, która posiada odbiornik HTTP lub HTTPS.
  • Ruch HTTP jest inicjowany do odbiornika przy użyciu protokołu HTTPS bez skonfigurowanego przekierowania.
  • Uwierzytelnianie wzajemne jest skonfigurowane, ale nie można przeprowadzić prawidłowej negocjacji.
  • Żądanie nie jest zgodne z RFC.

Oto niektóre typowe przyczyny niezgodności żądania z RFC:

Kategoria Przykłady
Nieprawidłowy host w wierszu żądania Host zawierający dwa dwukropki (example.com:8090:8080)
Brak nagłówka hosta Żądanie nie ma nagłówka Host
Obecność źle sformułowanego lub nielegalnego znaku Zastrzeżone znaki to &,!. Obejście polega na zakodowaniu go jako wartości procentowej. Na przykład: %&
Nieprawidłowa wersja protokołu HTTP Pobierz /content.css HTTP/0.3
Nazwa pola nagłówka i identyfikator URI zawierają znak inny niż ASCII GET /«úü}»}.doc HTTP/1.1
Brakuje nagłówka Content Length dla żądania POST Samoobjaśniające się
Nieprawidłowa metoda HTTP GET123 /index.html HTTP/1.1
Zduplikowane nagłówki Authorization:<zawartość zakodowana w base64>, Authorization: <zawartość zakodowana w base64>
Nieprawidłowa wartość w długości zawartości Content-Length: abc,Content-Length: -10

W przypadku skonfigurowania wzajemnego uwierzytelniania kilka scenariuszy może prowadzić do zwrócenia odpowiedzi HTTP 400 klientowi, na przykład:

  • Wzajemne uwierzytelnianie jest włączone, ale certyfikat klienta nie został przedstawiony.
  • Weryfikacja DN (Nazwa Wyróżniająca) jest włączona, a DN certyfikatu klienta nie jest zgodna z DN określonego łańcucha certyfikatów.
  • Łańcuch certyfikatów klienta nie jest zgodny z łańcuchem certyfikatów skonfigurowanym w zdefiniowanych zasadach PROTOKOŁU SSL.
  • Certyfikat klienta wygasł.
  • Sprawdzanie odwołania klienta OCSP (Online Certificate Status Protocol) jest włączone i certyfikat zostanie odwołany.
  • Sprawdzanie odwołania klienta OCSP (Online Certificate Status Protocol) jest włączone, ale nie można nawiązać połączenia.
  • Sprawdzanie przez klienta odwołania certyfikatu przy użyciu OCSP (Online Certificate Status Protocol) jest włączone, ale respondor OCSP nie jest podany w certyfikacie.

Aby uzyskać więcej informacji na temat rozwiązywania problemów z uwierzytelnianiem wzajemnym, zobacz Rozwiązywanie problemów z kodem błędu.

401 — Brak autoryzacji

Odpowiedź HTTP 401 nieautoryzowana jest zwracana do klienta, jeśli klient nie ma autoryzacji dostępu do zasobu. Istnieje kilka powodów, dla których należy zwrócić 401. Poniżej przedstawiono kilka przyczyn potencjalnych poprawek.

  • Jeśli klient ma dostęp, może mieć nieaktualną pamięć podręczną przeglądarki. Wyczyść pamięć podręczną przeglądarki i spróbuj ponownie uzyskać dostęp do aplikacji.

Nieautoryzowana odpowiedź HTTP 401 może zostać zwrócona na żądanie sondy AppGW, jeśli pula zaplecza jest skonfigurowana z uwierzytelnianiem NTLM. W tym scenariuszu zaplecze jest oznaczone jako w dobrej kondycji. Istnieje kilka opcji umożliwiających rozwiązanie tego problemu:

  • Zezwalaj na dostęp anonimowy dla zaplecza.
  • Skonfiguruj sondę w celu wysłania żądania do innej „fałszywej” witryny, która nie wymaga protokołu NTLM.
  • Niezalecane, ponieważ nie informuje nas to, czy rzeczywista lokacja za bramą aplikacji jest aktywna, czy nie.
  • Skonfiguruj bramę aplikacji w celu umożliwienia odpowiedzi 401 jako prawidłowych dla sond: warunki dopasowania sond.

403 — Zabronione

Protokół HTTP 403 Zabronione jest wyświetlany, gdy klienci korzystają z jednostek SKU zapory aplikacji internetowej (Zapora aplikacji internetowej) i mają zaporę aplikacji internetowej skonfigurowaną w trybie zapobiegania. Jeśli włączone zestawy reguł WAF lub niestandardowe reguły odmowy WAF są zgodne z charakterystyką żądania przychodzącego, klient otrzymuje odpowiedź 403 Forbidden.

Inne przyczyny otrzymywania przez klientów odpowiedzi 403 to:

  • Używasz usługi App Service jako zaplecza i jest ona skonfigurowana do zezwalania na dostęp tylko z usługi Application Gateway. To może skutkować błędem 403 z usług App Services. Zazwyczaj dzieje się tak z powodu przekierowań/linków href, które wskazują bezpośrednio usługę App Services, zamiast wskazywać adres IP usługi Application Gateway.
  • Jeśli uzyskujesz dostęp do bloga o magazynowaniu, a Application Gateway i punkt końcowy magazynu znajdują się w różnych regionach, zwracany jest błąd 403, jeśli publiczny adres IP Application Gateway nie znajduje się na liście dozwolonych. Zobacz Udzielanie dostępu z zakresu adresów IP internetu.

404 — Nie znaleziono strony

Odpowiedź HTTP 404 jest generowana po wysłaniu żądania do Application Gateway (V2) z nazwą hosta, która nie pasuje do żadnego ze skonfigurowanych odbiorników dla wielu lokalizacji i nie ma odbiornika podstawowego. Dowiedz się więcej o typach odbiorników.

408 — limit czasu żądania

Odpowiedź HTTP 408 może być zaobserwowana, gdy żądania klienta do odbiornika frontowego bramy aplikacji nie odpowiadają w ciągu 60 sekund. Ten błąd można zaobserwować z powodu przeciążenia ruchu między sieciami lokalnymi a platformą Azure, gdy urządzenie wirtualne sprawdza ruch lub sam klient staje się przeciążony.

413 — Zbyt duża jednostka żądania

Podczas korzystania z usługi Azure Web Application Firewall w usłudze Application Gateway można zaobserwować odpowiedź HTTP 413, a rozmiar żądania klienta przekracza maksymalny limit rozmiaru treści żądania. Maksymalne pole rozmiaru treści żądania kontroluje ogólny limit rozmiaru żądania z wyłączeniem przekazywania plików. Wartość domyślna rozmiaru treści żądania to 128 KB. Aby uzyskać więcej informacji, zobacz Limity rozmiaru żądań zapory aplikacji internetowej.

499 — Klient zamknął połączenie

Odpowiedź HTTP 499 jest wyświetlana, jeśli żądanie klienta wysyłane do bram aplikacyjnych przy użyciu SKU V2 zostanie zamknięte przed zakończeniem odpowiedzi serwera. Ten błąd można zaobserwować w 2 scenariuszach. Pierwszy scenariusz polega na tym, że duża odpowiedź jest zwracana do klienta, a klient mógł zamknąć lub odświeżyć aplikację, zanim serwer zakończy wysyłanie dużej odpowiedzi. Drugi scenariusz polega na tym, że limit czasu po stronie klienta jest niski i nie czeka wystarczająco długo, aby odebrać odpowiedź z serwera. W takim przypadku lepiej zwiększyć limit czasu oczekiwania na kliencie. W bramkach aplikacji korzystających ze SKU v1 może zostać zgłoszony kod odpowiedzi HTTP 0, jeśli klient zamknie połączenie przed zakończeniem odpowiedzi przez serwer.

Kody odpowiedzi 5XX (błąd serwera)

Kody odpowiedzi 500–599 wskazują, że wystąpił problem z bramą aplikacji lub serwerem zaplecza podczas wykonywania żądania.

500 — wewnętrzny błąd serwera

Brama Azure Application Gateway nie powinna zawierać 500 kodów odpowiedzi. Otwórz żądanie pomocy technicznej, jeśli widzisz ten kod, ponieważ ten problem jest błędem wewnętrznym usługi. Aby uzyskać informacje na temat otwierania zgłoszenia do pomocy technicznej, zobacz Tworzenie żądania pomocy technicznej platformy Azure.

502 — Zła brama

Błędy HTTP 502 mogą mieć kilka głównych przyczyn, na przykład:

Aby dowiedzieć się o scenariuszach związanych z błędami 502 i jak je rozwiązać, zobacz Rozwiązywanie problemów z błędami nieprawidłowej bramy.

504 – Przekroczono limit czasu bramy

SKU usługi Azure Application Gateway V2 wysyła błędy HTTP 504, gdy czas odpowiedzi zaplecza przekracza wartość timeoutu skonfigurowaną w ustawieniach zaplecza.

Serwer internetowy IIS (Internet Information Services)

Jeśli serwer zaplecza to IIS, zobacz Domyślne limity dla witryn sieci Web, aby ustawić wartość limitu czasu. Aby uzyskać szczegółowe informacje, zapoznaj się z atrybutem connectionTimeout . Upewnij się, że limit czasu połączenia w usługach IIS jest zgodny lub nie przekracza limitu czasu ustawionego w ustawieniu zaplecza.

Nginx

Jeśli serwer zaplecza jest Nginx lub kontrolerem ruchu przychodzącego Nginx i ma serwery źródłowe, upewnij się, że wartość nginx:proxy_read_timeout odpowiada lub nie przekracza limitu czasu ustawionego w ustawieniach zaplecza.

Scenariusze rozwiązywania problemów

Błąd "ERRORINFO_INVALID_HEADER" w dziennikach dostępu

Problem: Dziennik dostępu wyświetla błąd "ERRORINFO_INVALID_HEADER" dla żądania, mimo że kod odpowiedzi zaplecza (serverStatus) wynosi 200. W innych przypadkach serwer zaplecza może zwrócić 500.

Przyczyna: Klient wysyła nagłówek zawierający znaki CR LF.

Rozwiązanie: zastąp znaki CR LF znakiem SP (biały znak) i wyślij ponownie żądanie do usługi Application Gateway.

Następne kroki

Jeśli informacje zawarte w tym artykule nie pomogą rozwiązać problemu, prześlij zgłoszenie pomocy technicznej.