Rozwiązywanie problemów z kompresją plików usługi Azure Content Delivery Network
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 została wycofana 15 stycznia 2025 r. Aby uzyskać więcej informacji, zobacz Azure CDN from Edgio retirement FAQ (Usługa Azure CDN from Edgio retirement FAQ).
Ten artykuł ułatwia rozwiązywanie problemów z kompresją plików CDN.
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
Kompresja punktu końcowego jest włączona, ale pliki są zwracane nieskompresowane.
Napiwek
Aby sprawdzić, czy pliki są zwracane skompresowane, należy użyć narzędzia takiego jak Fiddler lub narzędzia deweloperskie przeglądarki. Sprawdź nagłówki odpowiedzi HTTP zwracane z buforowaną zawartością sieci dostarczania zawartości. Jeśli istnieje nagłówek o nazwie Content-Encoding z wartością gzip, bzip2, brotli lub deflate, zawartość jest kompresowana.
Przyczyna
Istnieje kilka możliwych przyczyn, w tym:
- Żądana zawartość nie kwalifikuje się do kompresji.
- Kompresja nie jest włączona dla żądanego typu pliku.
- Żądanie HTTP nie zawiera nagłówka żądającego prawidłowego typu kompresji.
- Źródło wysyła fragmentowaną zawartość.
Kroki rozwiązywania problemów
Napiwek
Podobnie jak w przypadku wdrażania nowych punktów końcowych, zmiany konfiguracji sieci dostarczania zawartości zajmują trochę czasu, aby propagować je za pośrednictwem sieci. Zazwyczaj zmiany są stosowane w ciągu 90 minut. Jeśli po raz pierwszy skonfigurowano kompresję dla punktu końcowego sieci dostarczania zawartości, rozważ odczekanie 1–2 godzin, aby upewnić się, że ustawienia kompresji zostały rozpropagowane do punktów pops.
Weryfikowanie żądania
Najpierw należy przeprowadzić szybką kontrolę kondycji na żądanie. Możesz użyć narzędzi deweloperskich przeglądarki, aby wyświetlić wysyłane żądania.
- Sprawdź, czy żądanie jest wysyłane do adresu URL punktu końcowego,
<endpointname>.azureedge.net, a nie do źródła. - Sprawdź, czy żądanie zawiera nagłówek Accept-Encoding , a wartość tego nagłówka zawiera gzip, deflate, brotli lub bzip2.
Weryfikowanie ustawień kompresji
Przejdź do punktu końcowego w witrynie Azure Portal i wybierz przycisk Konfiguruj .
- Sprawdź, czy kompresja jest włączona.
- Sprawdź, czy typ MIME zawartości do skompresowania znajduje się na liście skompresowanych formatów.
Sprawdź żądanie na serwerze pochodzenia dla nagłówka Via
Nagłówek Via HTTP wskazuje serwer internetowy, że żądanie jest przekazywane przez serwer proxy. Serwery internetowe usług Microsoft IIS domyślnie nie kompresują odpowiedzi, gdy żądanie zawiera nagłówek Via . Aby zastąpić to zachowanie, wykonaj następujące czynności: