Udostępnij za pośrednictwem

Rozwiązywanie typowych problemów z usługą Azure Front Door

  • Artykuł

W tym artykule opisano sposób rozwiązywania typowych problemów z routingiem, które mogą wystąpić podczas konfigurowania usługi Azure Front Door.

Inne debugowanie nagłówków HTTP

Możesz poprosić usługę Azure Front Door o zwrócenie dodatkowych nagłówków odpowiedzi HTTP debugowania. Aby uzyskać więcej informacji, zobacz opcjonalne nagłówki odpowiedzi.

503 lub 504 odpowiedź z usługi Azure Front Door po kilku sekundach

Objaw

  • Regularne żądania wysyłane do zaplecza bez przechodzenia przez usługę Azure Front Door kończą się powodzeniem. Przejście przez usługę Azure Front Door powoduje 503 lub 504 odpowiedzi na błędy.
  • Awaria usługi Azure Front Door zwykle pojawia się po około 30 sekundach.
  • Sporadyczne błędy 503 są wyświetlane z komunikatem "ErrorInfo: OriginInvalidResponse".

Przyczyna

Przyczyną tego problemu może być jedna z trzech rzeczy:

  • Źródło trwa dłużej niż limit czasu skonfigurowany do odbierania żądania z usługi Azure Front Door. Domyślny limit czasu to 30 sekund.
  • Czas wysyłania odpowiedzi do żądania z usługi Azure Front Door trwa dłużej niż wartość limitu czasu.
  • Klient wysłał żądanie zakresu bajtów z nagłówkiem Accept-Encoding , co oznacza, że jest włączona kompresja.

Kroki rozwiązywania problemów

  • Wyślij żądanie bezpośrednio do źródła bez przechodzenia przez usługę Azure Front Door. Zobacz, jak długo zwykle trwa reagowanie źródła.

  • Wyślij żądanie za pośrednictwem usługi Azure Front Door i sprawdź, czy otrzymujesz odpowiedzi 503. Jeśli nie, problem może nie być problemem przekroczenia limitu czasu. Utwórz wniosek o pomoc techniczną, aby rozwiązać ten problem.

  • Jeśli żądania przechodzące przez usługę Azure Front Door spowodują wyświetlenie kodu odpowiedzi błędu 503, skonfiguruj limit czasu odpowiedzi źródła dla usługi Azure Front Door. Domyślny limit czasu można zwiększyć do 4 minut (240 sekund). Aby skonfigurować to ustawienie, przejdź do strony przeglądu profilu usługi Front Door. Wybierz pozycję Limit czasu odpowiedzi źródła i wprowadź wartość z zakresu od 16 do 240 sekund.

    Uwaga

    Możliwość skonfigurowania limitu czasu odpowiedzi źródła jest dostępna tylko w usłudze Azure Front Door Standard/Premium.

    Zrzut ekranu przedstawiający ustawienia limitu czasu źródła na stronie przeglądu profilu usługi Azure Front Door.

  • Jeśli zwiększenie limitu czasu nie rozwiąże problemu, użyj narzędzia takiego jak Fiddler lub narzędzie deweloperskie przeglądarki, aby sprawdzić, czy klient wysyła żądania zakresu bajtów za pomocą nagłówków Accept-Encoding . Użycie tej opcji prowadzi do odpowiedzi źródła o różnych długościach zawartości.

    Jeśli klient wysyła żądania zakresu bajtów z nagłówkami Accept-Encoding , masz dwie opcje. Pierwszą opcją jest wyłączenie kompresji źródła lub usługi Azure Front Door. Drugą opcją jest utworzenie reguły zestawu reguł, aby usunąć kodowanie Accept-Encoding z żądania dla żądań zakresu bajtów.

    Zrzut ekranu przedstawiający regułę Accept-Encoding w zestawie reguł.

503 odpowiedzi z usługi Azure Front Door tylko dla protokołu HTTPS

Objaw

  • Wszystkie odpowiedzi 503 są zwracane tylko dla punktów końcowych z obsługą protokołu HTTPS usługi Azure Front Door.
  • Regularne żądania wysyłane do zaplecza bez przechodzenia przez usługę Azure Front Door kończą się powodzeniem. Przejście za pośrednictwem usługi Azure Front Door powoduje 503 odpowiedzi na błędy.
  • Sporadyczne błędy 503 są wyświetlane z komunikatem "ErrorInfo: OriginInvalidResponse".

Przyczyna

Przyczyną tego problemu może być jedna z trzech rzeczy:

  • Pula zaplecza jest adresem IP.
  • Serwer zaplecza zwraca certyfikat, który nie jest zgodny z w pełni kwalifikowaną nazwą domeny (FQDN) puli zaplecza usługi Azure Front Door.
  • Pula zaplecza jest serwerem usługi Azure Web Apps.

Kroki rozwiązywania problemów

  • Pula zaplecza jest adresem IP.

    EnforceCertificateNameCheck musi być wyłączona.

    Usługa Azure Front Door ma przełącznik o nazwie EnforceCertificateNameCheck. Domyślnie to ustawienie jest włączone. Po włączeniu usługa Azure Front Door sprawdza, czy nazwa FQDN hosta puli zaplecza jest zgodna z nazwą certyfikatu serwera zaplecza lub jednym z wpisów w rozszerzeniu nazw alternatywnych podmiotu.

    • Jak wyłączyć EnforceCertificateNameCheck z witryny Azure Portal:

      W portalu użyj przycisku przełącznika, aby włączyć lub wyłączyć to ustawienie w okienku Projekt usługi Azure Front Door (wersja klasyczna).

      Zrzut ekranu przedstawiający przycisk przełącznika.

      W przypadku warstwy Azure Front Door Standard i Premium to ustawienie można znaleźć w ustawieniach źródła podczas dodawania źródła do grupy pochodzenia lub konfigurowania trasy.

      Zrzut ekranu przedstawiający pole wyboru walidacji nazwy podmiotu certyfikatu.

  • Serwer zaplecza zwraca certyfikat, który nie jest zgodny z nazwą FQDN puli zaplecza usługi Azure Front Door. Aby rozwiązać ten problem, masz dwie opcje:

    • Zwrócony certyfikat musi być zgodny z nazwą FQDN.
    • EnforceCertificateNameCheck musi być wyłączona.

  • Pula zaplecza to serwer usługi Azure Web Apps:

    • Sprawdź, czy aplikacja internetowa platformy Azure jest skonfigurowana przy użyciu protokołu SSL opartego na protokole IP zamiast sNI (oznaczania nazwy serwera). Jeśli aplikacja internetowa jest skonfigurowana jako oparta na adresie IP, powinna zostać zmieniona na SNI.
    • Jeśli zaplecze jest w złej kondycji z powodu błędu certyfikatu, zostanie zwrócony komunikat o błędzie 503. Kondycję zapleczy można sprawdzić na portach 80 i 443. Jeśli tylko 443 jest w złej kondycji, prawdopodobnie występuje problem z protokołem SSL. Ponieważ zaplecze jest skonfigurowane do używania nazwy FQDN, wiemy, że wysyła SNI.

    Użyj polecenia OPENSSL, aby zweryfikować zwracany certyfikat. Aby to sprawdzić, połącz się z zapleczem przy użyciu polecenia -servername. Powinien zwrócić nazwę SNI, która musi być zgodna z nazwą FQDN puli zaplecza:

    openssl s_client -connect backendvm.contoso.com:443 -servername backendvm.contoso.com

Żądania wysyłane do domeny niestandardowej zwracają kod stanu 400

Objaw

  • Utworzono wystąpienie usługi Azure Front Door. Żądanie do domeny lub hosta frontonu zwraca kod stanu HTTP 400.
  • Utworzono mapowanie dns (serwera nazw domen) dla domeny niestandardowej na skonfigurowany host frontonu. Wysłanie żądania do niestandardowej nazwy hosta domeny zwraca kod stanu HTTP 400. Wydaje się, że nie jest kierowany do skonfigurowanego zaplecza.

Przyczyna

Problem występuje, jeśli nie skonfigurowano reguły routingu dla domeny niestandardowej, która została dodana jako host frontonu. Dla tego hosta frontonu należy jawnie dodać regułę routingu. Należy utworzyć regułę, nawet jeśli reguła routingu została już skonfigurowana dla hosta frontonu w poddomenie usługi Azure Front Door, czyli *.azurefd.net.

Krok rozwiązywania problemów

Dodaj regułę routingu dla domeny niestandardowej, aby kierować ruch do wybranej grupy pochodzenia.

Usługa Azure Front Door nie przekierowuje protokołu HTTP do protokołu HTTPS

Objaw

Usługa Azure Front Door ma regułę routingu, która przekierowuje protokół HTTP do protokołu HTTPS, ale uzyskiwanie dostępu do domeny nadal utrzymuje protokół HTTP.

Przyczyna

To zachowanie może wystąpić, jeśli nie skonfigurowaliśmy poprawnie reguł routingu dla usługi Azure Front Door. Bieżąca konfiguracja nie jest specyficzna i może mieć reguły powodujące konflikt.

Kroki rozwiązywania problemów

Żądanie do nazwy hosta frontonu zwraca kod stanu 411

Objaw

Utworzono wystąpienie usługi Azure Front Door Standard/Premium i skonfigurowano:

  • Host frontonu.
  • Grupa pochodzenia z co najmniej jednym źródłem.
  • Reguła routingu, która łączy hosta frontonu z grupą źródeł.

Zawartość nie jest dostępna, gdy żądanie trafia do skonfigurowanego hosta frontonu, ponieważ zwracany jest kod stanu HTTP 411.

Odpowiedzi na te żądania mogą również zawierać stronę błędu HTML w treści odpowiedzi, która zawiera instrukcję objaśnienia. Przykładem jest "Błąd HTTP 411. Żądanie musi być fragmentowane lub mieć długość zawartości.

Przyczyna

Istnieje kilka możliwych przyczyn tego objawu. Ogólną przyczyną jest to, że żądanie HTTP nie jest w pełni zgodne z specyfikacją RFC.

Przykładem niezgodności jest POST żądanie wysyłane bez nagłówka Content-Length lub Transfer-Encoding . Przykładem może być użycie elementu curl -X POST https://example-front-door.domain.com. To żądanie nie spełnia wymagań określonych w specyfikacji RFC 7230. Usługa Azure Front Door zablokowałaby ją z odpowiedzią HTTP 411. Takie żądania nie są rejestrowane.

To zachowanie jest oddzielone od funkcji zapory aplikacji internetowej (WAF) usługi Azure Front Door. Obecnie nie ma możliwości wyłączenia tego zachowania. Wszystkie żądania HTTP muszą spełniać wymagania, nawet jeśli funkcja zapory aplikacji internetowej nie jest używana.

Kroki rozwiązywania problemów

  • Sprawdź, czy twoje żądania są zgodne z wymaganiami określonymi w niezbędnych rfcs.
  • Zanotuj treść komunikatu HTML, która zostanie zwrócona w odpowiedzi na żądanie. Treść komunikatu często wyjaśnia dokładnie , jak żądanie jest niezgodne.

Moje źródło jest skonfigurowane jako adres IP.

Objaw

Źródło jest skonfigurowane jako adres IP. Źródło jest w dobrej kondycji, ale odrzuca żądania z usługi Azure Front Door.

Przyczyna

Usługa Azure Front Door użytkownicy nazwy hosta pochodzenia jako nagłówka SNI podczas uzgadniania PROTOKOŁU SSL. Ponieważ źródło jest skonfigurowane jako adres IP, awaria może być jedną z następujących przyczyn:

  • Jeśli sprawdzanie nazwy certyfikatu jest wyłączone, możliwe, że przyczyną problemu jest logika certyfikatu pochodzenia. Ta logika może odrzucać wszystkie żądania, które nie mają prawidłowego nagłówka hosta pasującego do certyfikatu.

Kroki rozwiązywania problemów

Zmień źródło z adresu IP na nazwę FQDN, do której wystawiono prawidłowy certyfikat zgodny z certyfikatem pochodzenia.

Następne kroki