Rozwiązywanie problemów z punktami końcowymi usługi Azure Content Delivery Network, które zwracają kod stanu 404

Ważne

Usługa Azure CDN Standard firmy Microsoft (klasyczna) zostanie wycofana 30 września 2027 r. Aby uniknąć zakłóceń w działaniu usługi, należy przeprowadzić migrację profilów usługi Azure CDN Standard z usługi Microsoft (klasycznej) do warstwy Azure Front Door Standard lub Premium do 30 września 2027 r. Aby uzyskać więcej informacji, zobacz Azure CDN Standard from Microsoft (classic) retirement (Wycofanie usługi Azure CDN w warstwie Standardowa z firmy Microsoft (wersja klasyczna).

Usługa Azure CDN z Edgio zostanie wycofana 15 stycznia 2025 r. Przed tą datą należy przeprowadzić migrację obciążenia do usługi Azure Front Door, aby uniknąć przerw w działaniu usługi. Aby uzyskać więcej informacji, zobacz Azure CDN from Edgio retirement FAQ (Usługa Azure CDN from Edgio retirement FAQ).

Ten artykuł umożliwia rozwiązywanie problemów z punktami końcowymi usługi Azure Content Delivery Network, które zwracają kody stanu odpowiedzi HTTP 404.

Jeśli potrzebujesz więcej pomocy w dowolnym momencie tego artykułu, możesz skontaktować się z ekspertami platformy Azure na forach MSDN Azure i Stack Overflow. Alternatywnie możesz również zgłosić zdarzenie pomocy technicznej platformy Azure. Przejdź do witryny pomocy technicznej platformy Azure i wybierz pozycję Uzyskaj pomoc techniczną.

Objaw

Utworzono profil sieci dostarczania zawartości i punkt końcowy, ale zawartość nie jest dostępna w sieci dostarczania zawartości. Użytkownicy, którzy próbują uzyskać dostęp do zawartości za pośrednictwem adresu URL sieci dostarczania zawartości, otrzymują kod stanu HTTP 404.

Przyczyna

Istnieje kilka możliwych przyczyn, w tym:

• Źródło pliku nie jest widoczne dla sieci dostarczania zawartości.
• Punkt końcowy jest nieprawidłowo skonfigurowany, co powoduje, że sieć dostarczania zawartości będzie wyglądała w niewłaściwym miejscu.
• Host odrzuca nagłówek hosta z sieci dostarczania zawartości.
• Punkt końcowy nie miał czasu na propagację w całej sieci dostarczania zawartości.

Kroki rozwiązywania problemów

Ważne

Po utworzeniu punktu końcowego sieci dostarczania zawartości nie będzie ona natychmiast dostępna do użycia, ponieważ rejestracja będzie propagowana za pośrednictwem sieci dostarczania zawartości:

• W przypadku profili usługi Azure CDN Standard from Microsoft propagacja zwykle trwa do 10 minut.
• W przypadku profilów usługi Azure CDN Standard from Edgio i Azure CDN Premium from Edgio propagacja zwykle kończy się w ciągu 90 minut.

Jeśli wykonasz kroki opisane w tym dokumencie i nadal otrzymujesz 404 odpowiedzi, rozważ odczekanie kilku godzin ponownego sprawdzenia przed otwarciem biletu pomocy technicznej.

Sprawdzanie pliku pochodzenia

Najpierw sprawdź, czy plik do buforowania jest dostępny na serwerze pochodzenia i jest publicznie dostępny w Internecie. Najszybszym sposobem, aby to zrobić, jest otwarcie przeglądarki w prywatnej lub incognito sesji i przejście bezpośrednio do pliku. Wpisz lub wklej adres URL w polu adresu i sprawdź, czy powoduje to oczekiwany plik. Załóżmy na przykład, że masz plik na koncie usługi Azure Storage dostępny pod adresem HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt. Jeśli możesz pomyślnie załadować zawartość tego pliku, przejmie test.

Ostrzeżenie

Chociaż jest to najszybszy i najprostszy sposób sprawdzania, czy plik jest publicznie dostępny, niektóre konfiguracje sieci w organizacji mogą sprawić, że plik jest publicznie dostępny, gdy jest widoczny tylko dla użytkowników sieci (nawet jeśli jest hostowany na platformie Azure). Aby upewnić się, że tak nie jest, przetestuj plik za pomocą przeglądarki zewnętrznej, na przykład urządzenia przenośnego, które nie jest połączone z siecią organizacji lub maszyną wirtualną na platformie Azure.

Sprawdzanie ustawień źródła

Po zweryfikowaniu, że plik jest publicznie dostępny w Internecie, sprawdź ustawienia źródła. W witrynie Azure Portal przejdź do profilu sieci dostarczania zawartości i wybierz punkt końcowy, który rozwiązujesz. Na wynikowej stronie Punkt końcowy wybierz źródło.

Zostanie wyświetlona strona Źródło .

Typ źródła i nazwa hosta

Sprawdź, czy wartości typu źródła i nazwy hosta źródła są poprawne. W tym przykładzie HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txtczęść adresu URL nazwy hosta jest cdndocdemo.blob.core.windows.net, która jest poprawna. Ponieważ źródła usług Azure Storage, Web App i Cloud Service używają wartości listy rozwijanej dla pola Nazwa hosta źródła, nieprawidłowe pisownie nie są problemem. Jeśli jednak używasz niestandardowego źródła, upewnij się, że nazwa hosta jest poprawna.

Porty HTTP i HTTPS

Sprawdź porty HTTP i HTTPS. W większości przypadków 80 i 443 są poprawne i nie trzeba żadnych zmian. Jeśli jednak serwer pochodzenia nasłuchuje na innym porcie, należy to przedstawić tutaj. Jeśli nie masz pewności, wyświetl adres URL pliku pochodzenia. Specyfikacje HTTP i HTTPS używają portów 80 i 443 jako domyślnych. W przykładowym adresie URL HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txtnie określono portu, więc przyjmuje się, że wartość domyślna to 443, a ustawienia są poprawne.

Załóżmy jednak, że adres URL pliku pochodzenia, który przetestowano wcześniej, to HTTP://www.contoso.com:8080/file.txt. Zwróć uwagę na część : 8080 na końcu segmentu nazwy hosta. Ten numer nakazuje przeglądarce użycie portu 8080 w celu nawiązania połączenia z serwerem internetowym w www.contoso.com, dlatego należy wprowadzić wartość 8080 w polu Port HTTP. Należy pamiętać, że te ustawienia portów mają wpływ tylko na port używany przez punkt końcowy do pobierania informacji ze źródła.

Sprawdzanie ustawień punktu końcowego

Na stronie Punkt końcowy wybierz przycisk Konfiguruj.

Zostanie wyświetlona strona Konfigurowanie punktu końcowego sieci dostarczania zawartości.

Protokoły

W obszarze Protokoły sprawdź, czy wybrano protokół używany przez klientów. Ponieważ ten sam protokół używany przez klienta jest używany do uzyskiwania dostępu do źródła, ważne jest, aby porty pochodzenia były poprawnie skonfigurowane w poprzedniej sekcji. Punkt końcowy sieci dostarczania zawartości nasłuchuje tylko na domyślnych portach HTTP i HTTPS (80 i 443), niezależnie od portów źródłowych.

Wróćmy do naszego hipotetycznego przykładu z HTTP://www.contoso.com:8080/file.txt. Jak pamiętasz, firma Contoso określiła 8080 jako port HTTP, ale załóżmy również, że określono 44300 jako port HTTPS. Jeśli utworzyli punkt końcowy o nazwie contoso, nazwa hosta punktu końcowego sieci dostarczania zawartości będzie contoso.azureedge.net. Żądanie dla HTTP://Contoso.azureedge.net/file.txt jest żądaniem HTTP, więc punkt końcowy użyje protokołu HTTP na porcie 8080, aby pobrać go ze źródła. Bezpieczne żądanie za pośrednictwem protokołu HTTPS spowodowałoby, że punkt końcowy używa protokołu HTTPS HTTPS://Contoso.azureedge.net/file.txtna porcie 44300 podczas pobierania pliku ze źródła.

Nagłówek hosta pochodzenia

Nagłówek hosta pochodzenia to wartość nagłówka hosta wysłana do źródła z każdym żądaniem. W większości przypadków ta wartość powinna być taka sama jak nazwa hosta pochodzenia, która została zweryfikowana wcześniej. Nieprawidłowa wartość w tym polu nie powoduje stanu 404, ale prawdopodobnie spowoduje inne stany 4xx, w zależności od tego, czego oczekuje źródło.

Ścieżka do źródła

Na koniec powinniśmy zweryfikować naszą ścieżkę źródła. Domyślnie ta ścieżka jest pusta. Tego pola należy używać tylko wtedy, gdy chcesz zawęzić zakres zasobów hostowanych w źródłach, które mają być dostępne w sieci dostarczania zawartości.

W przykładowym punkcie końcowym chcieliśmy, aby wszystkie zasoby na koncie magazynu były dostępne, więc ścieżka źródła była pusta. W związku z tym żądanie HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt powoduje połączenie z punktu końcowego do cdndocdemo.core.windows.net, które żąda /publicblob/lorem.txt. Podobnie żądanie dotyczące HTTPS://cdndocdemo.azureedge.net/donotcache/status.png wyników w punkcie końcowym żądającym /donotcache/status.png ze źródła.

Ale co zrobić, jeśli nie chcesz używać sieci dostarczania zawartości dla każdej ścieżki w źródłach? Załóżmy, że chcesz uwidocznić tylko publiczną ścieżkę obiektu blob . Jeśli wprowadzimy /publicblob w polu Ścieżka źródła, spowoduje to, że punkt końcowy wstawi /publicblob przed każdym żądaniem do źródła. Więc żądanie na HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt razie przyjmuje część żądania adresu URL, /publicblob/lorem.txt i dołącza /publicblob na początku. W wyniku żądania / publicblob/publicblob/lorem.txt ze źródła. Jeśli ta ścieżka nie zostanie rozpoznana jako rzeczywisty plik, źródło zwróci stan 404. Poprawny adres URL do pobrania lorem.txt w tym przykładzie będzie rzeczywiście HTTPS://cdndocdemo.azureedge.net/lorem.txt. W ogóle nie uwzględniamy ścieżki /publicblob, ponieważ część żądania adresu URL to /lorem.txt, a punkt końcowy dodaje /publicblob, co powoduje przekazanie żądania do źródła /publicblob/lorem.txt.