Řešení potíží s koncovými body služby Azure Content Delivery Network, které vracejí stavový kód 404
Důležité
30. září 2027 bude vyřazena služba Azure CDN Standard od Microsoftu (Classic). Abyste se vyhnuli přerušení služeb, je důležité do 30. září 2027 migrovat profily Azure CDN Standard z Microsoftu (classic) na úroveň Azure Front Door Standard nebo Premium. Další informace najdete v tématu Azure CDN Standard od Microsoftu (klasického) vyřazení.
Azure CDN z Edgio bude vyřazeno z Januray 15, 2025. Před tímto datem musíte migrovat úlohu do služby Azure Front Door, abyste se vyhnuli přerušení služeb. Další informace najdete v tématu Azure CDN z nejčastějších dotazů k vyřazení Edgio.
Tento článek umožňuje řešit problémy s koncovými body služby Azure Content Delivery Network, které vrací stavové kódy odpovědi HTTP 404.
Pokud potřebujete další pomoc v libovolném bodě tohoto článku, můžete kontaktovat odborníky na Azure na fórech MSDN Azure a Stack Overflow. Případně můžete také podat incident podpory Azure. Přejděte na web podpory Azure a vyberte Získat podporu.
Příznaky
Vytvořili jste profil sítě pro doručování obsahu a koncový bod, ale zdá se, že váš obsah není dostupný v síti pro doručování obsahu. Uživatelé, kteří se pokusí získat přístup k vašemu obsahu prostřednictvím adresy URL sítě pro doručování obsahu, obdrží stavový kód HTTP 404.
Příčina
Existuje několik možných příčin, mezi které patří:
- Původ souboru není viditelný v síti pro doručování obsahu.
- Koncový bod je chybně nakonfigurovaný, což způsobí, že síť pro doručování obsahu bude hledat na nesprávném místě.
- Hostitel odmítá hlavičku hostitele ze sítě pro doručování obsahu.
- Koncový bod neměl čas rozšířit do celé sítě pro doručování obsahu.
Postup při řešení potíží
Důležité
Po vytvoření koncového bodu sítě pro doručování obsahu nebude okamžitě k dispozici pro použití, protože registrace se bude časově šířit prostřednictvím sítě pro doručování obsahu:
- V případě profilů Azure CDN Standard od Microsoftu je šíření obvykle hotové během deseti minut.
- Pro Azure CDN Standard z profilů Edgio a Azure CDN Premium z profilů Edgio se šíření obvykle dokončí do 90 minut.
Pokud dokončíte kroky v tomto dokumentu a stále dostáváte 404 odpovědí, zvažte před otevřením lístku podpory počkat několik hodin, než znovu zkontrolujete.
Kontrola zdrojového souboru
Nejprve ověřte, že je soubor, který se má ukládat do mezipaměti, dostupný na zdrojovém serveru a je veřejně přístupný na internetu. Nejrychlejším způsobem, jak to udělat, je otevřít prohlížeč v privátní nebo anonymní relaci a přejít přímo k souboru. Zadejte nebo vložte adresu URL do pole adresa a ověřte, že výsledkem bude očekávaný soubor. Předpokládejme například, že máte soubor v účtu Azure Storage, který je přístupný na adrese
Upozorňující
I když je to nejrychlejší a nejsnadnější způsob, jak ověřit, jestli je váš soubor veřejně dostupný, můžou se některé konfigurace sítě ve vaší organizaci zdát, že soubor je veřejně dostupný jenom uživatelům vaší sítě (i když je hostovaný v Azure). Abyste měli jistotu, že tomu tak není, otestujte soubor pomocí externího prohlížeče, například mobilního zařízení, které není připojené k síti vaší organizace nebo virtuálního počítače v Azure.
Kontrola nastavení zdroje
Jakmile ověříte, že je soubor veřejně dostupný na internetu, ověřte nastavení původu. Na webu Azure Portal přejděte do profilu sítě pro doručování obsahu a vyberte koncový bod, který řešíte. Na výsledné stránce koncového bodu vyberte původ.
Zobrazí se stránka Původ .
Typ zdroje a název hostitele
Ověřte správnost hodnot typu Původ a název hostitele Origin. V tomto příkladu HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txtje část názvu hostitele adresy URL cdndocdemo.blob.core.windows.net, což je správné. Vzhledem k tomu, že zdroje služby Azure Storage, Webové aplikace a cloudové služby používají pro pole Název hostitele původu hodnotu rozevíracího seznamu, nejsou nesprávné pravopisy problém. Pokud ale používáte vlastní původ, ujistěte se, že je název hostitele správně napsaný.
Porty HTTP a HTTPS
Zkontrolujte porty HTTP a HTTPS. Ve většině případů jsou 80 a 443 správné a nevyžadujete žádné změny. Pokud však server původu naslouchá na jiném portu, musí být zde reprezentován. Pokud si nejste jistí, podívejte se na adresu URL zdrojového souboru. Specifikace HTTP a HTTPS používají jako výchozí porty porty 80 a 443. V příkladu adresy URL HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txtnení zadaný port, takže se předpokládá výchozí hodnota 443 a nastavení jsou správná.
Předpokládejme však, že adresa URL původního souboru, který jste otestovali dříve, je HTTP://www.contoso.com:8080/file.txt. Všimněte si části : 8080 na konci segmentu názvu hostitele. Toto číslo dává prohlížeči pokyn, aby se pomocí portu 8080 připojil k webovému serveru v www.contoso.com, a proto je nutné zadat 8080 do pole portu HTTP. Je důležité si uvědomit, že tato nastavení portů ovlivňují jenom to, jaký port koncový bod používá k načtení informací z původu.
Kontrola nastavení koncového bodu
Na stránce Koncový bod vyberte tlačítko Konfigurovat.
Zobrazí se stránka Konfigurace koncového bodu sítě pro doručování obsahu.
Protokoly
V části Protokoly ověřte, že je vybraný protokol používaný klienty. Vzhledem k tomu, že stejný protokol používaný klientem je ten, který se používá pro přístup k původu, je důležité, aby byly porty původu správně nakonfigurované v předchozí části. Koncový bod sítě pro doručování obsahu naslouchá pouze na výchozích portech HTTP a HTTPS (80 a 443) bez ohledu na původní porty.
Vraťme se k našemu hypotetickému příkladu s využitím HTTP://www.contoso.com:8080/file.txt. Jak si pamatujete, společnost Contoso jako svůj port HTTP zadala 8080 , ale předpokládejme také, že jako port HTTPS zadala 44300 . Pokud vytvořili koncový bod s názvem contoso, název hostitele koncového bodu sítě pro doručování obsahu by byl contoso.azureedge.net. Požadavek na HTTP://Contoso.azureedge.net/file.txt požadavek HTTP, takže koncový bod by použil HTTP na portu 8080 k načtení z původu. Zabezpečený požadavek přes PROTOKOL HTTPS způsobí, HTTPS://Contoso.azureedge.net/file.txtže koncový bod při načítání souboru ze zdroje použije HTTPS na portu 44300.
Záhlaví hostitele původu
Hlavička hostitele Origin je hodnota hlavičky hostitele odeslaná do zdroje s každou žádostí. Ve většině případů by tato hodnota měla být stejná jako název hostitele Origin, který jsme ověřili dříve. Nesprávná hodnota v tomto poli nezpůsobí stav 404, ale pravděpodobně způsobí jiné stavy 4xx v závislosti na tom, co původ očekává.
Cesta k původu
Nakonec bychom měli ověřit cestu původu. Ve výchozím nastavení je tato cesta prázdná. Toto pole byste měli použít pouze v případě, že chcete zúžit rozsah prostředků hostovaných původem, které chcete zpřístupnit v síti pro doručování obsahu.
V ukázkovém koncovém bodu jsme chtěli, aby byly všechny prostředky v účtu úložiště dostupné, takže cesta zdroje zůstala prázdná. Proto požadavek na HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt připojení z koncového bodu k cdndocdemo.core.windows.net, který požaduje /publicblob/lorem.txt. Stejně tak požadavek na HTTPS://cdndocdemo.azureedge.net/donotcache/status.png výsledky v koncovém bodu žádajícím o /donotcache/status.png z původu.
Ale co když nechcete používat síť pro doručování obsahu pro každou cestu ve vašem původu? Řekněme, že jste chtěli zveřejnit pouze veřejnou cestu k objektu blob . Pokud do pole Cesta ke zdroji zadáme /publicblob, způsobí to, že koncový bod vloží /publicblob před každým požadavkem na zdroj. Požadavek teď HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt tedy přebírá část adresy URL , /publicblob/lorem.txt a na začátek připojte /publicblob . Výsledkem je žádost o /publicblob/publicblob/lorem.txt z původu. Pokud se tato cesta nepřeloží na skutečný soubor, vrátí zdroj stav 404. Správná adresa URL pro načtení lorem.txt v tomto příkladu by ve skutečnosti byla HTTPS://cdndocdemo.azureedge.net/lorem.txt. Cestu /publicblob nezahrneme vůbec, protože část požadavku adresy URL je /lorem.txt a koncový bod přidá /publicblob, což vede k tomu, že požadavek předá do zdroje /publicblob/lorem.txt.