Felsöka Azure Content Delivery Network-slutpunkter som returnerar en 404-statuskod

Viktigt!

Azure CDN Standard från Microsoft (klassisk) dras tillbaka den 30 september 2027. För att undvika avbrott i tjänsten är det viktigt att du migrerar dina Azure CDN Standard-profiler från Microsofts (klassiska) profiler till Azure Front Door Standard- eller Premium-nivån senast den 30 september 2027. Mer information finns i Azure CDN Standard från Microsoft (klassisk) tillbakadragning.

Azure CDN från Edgio drogs tillbaka den 15 januari 2025. Mer information finns i Azure CDN från vanliga frågor och svar om Edgio-pensionering.

Med den här artikeln kan du felsöka problem med Azure Content Delivery Network-slutpunkter som returnerar 404 HTTP-svarsstatuskoder.

Om du behöver mer hjälp när som helst i den här artikeln kan du kontakta Azure-experterna på MSDN Azure och Stack Overflow-forumen. Du kan också skicka in en Azure Support-incident. Gå till Azure Support-webbplatsen och välj Hämta support.

Symptom

Du har skapat en nätverksprofil för innehållsleverans och en slutpunkt, men innehållet verkar inte vara tillgängligt i nätverket för innehållsleverans. Användare som försöker komma åt ditt innehåll via url:en för innehållsleveransnätverket får en HTTP 404-statuskod.

Orsak

Det finns flera möjliga orsaker, bland annat:

• Filens ursprung är inte synligt för nätverket för innehållsleverans.
• Slutpunkten är felkonfigurerad, vilket gör att nätverket för innehållsleverans letar på fel plats.
• Värden avvisar värdhuvudet från nätverket för innehållsleverans.
• Slutpunkten har inte haft tid att spridas i hela nätverket för innehållsleverans.

Felsökningsanvisningar

Viktigt!

När du har skapat en slutpunkt blir den inte omedelbart tillgänglig för användning eftersom det kan ta upp till tio minuter innan registreringen sprids via nätverket för innehållsleverans.

Om du slutför stegen i det här dokumentet och fortfarande får 404 svar kan du överväga att vänta några timmar för att kontrollera igen innan du öppnar ett supportärende.

Kontrollera ursprungsfilen

Kontrollera först att filen som ska cachelagrats är tillgänglig på ursprungsservern och är offentligt tillgänglig på Internet. Det snabbaste sättet att göra det är att öppna en webbläsare i en privat session eller inkognitosession och bläddra direkt till filen. Skriv eller klistra in URL:en i adressrutan och kontrollera att den resulterar i den fil som du förväntar dig. Anta till exempel att du har en fil i ett Azure Storage-konto som är tillgängligt på HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt. Om du kan läsa in filens innehåll klarar den testet.

Varning

Även om det här är det snabbaste och enklaste sättet att verifiera att filen är offentligt tillgänglig, kan vissa nätverkskonfigurationer i din organisation få det att se ut som att en fil är offentligt tillgänglig när den faktiskt bara är synlig för användare av nätverket (även om den finns i Azure). Kontrollera att så inte är fallet genom att testa filen med en extern webbläsare, till exempel en mobil enhet som inte är ansluten till organisationens nätverk eller en virtuell dator i Azure.

Kontrollera ursprungsinställningarna

När du har kontrollerat att filen är offentligt tillgänglig på Internet kontrollerar du ursprungsinställningarna. I Azure Portal bläddrar du till nätverksprofilen för innehållsleverans och väljer den slutpunkt som du felsöker. På den resulterande slutpunktssidan väljer du ursprunget.

Sidan Ursprung visas.

Ursprungstyp och värdnamn

Kontrollera att värdena för ursprungstypen och ursprungsvärdnamnet är korrekta. I det här exemplet HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txtär värdnamnsdelen av URL:en cdndocdemo.blob.core.windows.net, vilket är korrekt. Eftersom Azure Storage, Web App och Cloud Service-ursprung använder ett listrutevärde för fältet Ursprungsvärdnamn är felaktiga stavningar inte ett problem. Men om du använder ett anpassat ursprung kontrollerar du att värdnamnet är rättstavat.

HTTP- och HTTPS-portar

Kontrollera HTTP - och HTTPS-portarna. I de flesta fall är 80 och 443 korrekta och du behöver inga ändringar. Men om ursprungsservern lyssnar på en annan port måste den representeras här. Om du inte är säker kan du visa URL:en för ursprungsfilen. HTTP- och HTTPS-specifikationerna använder portarna 80 och 443 som standard. I exempel-URL:en HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txtanges inte en port, så standardvärdet 443 antas och inställningarna är korrekta.

Anta dock att URL:en för ursprungsfilen som du testade tidigare är HTTP://www.contoso.com:8080/file.txt. Observera delen : 8080 i slutet av värdnamnssegmentet. Det numret instruerar webbläsaren att använda port 8080 för att ansluta till webbservern på www.contoso.com, därför måste du ange 8080 i HTTP-portfältet . Observera att dessa portinställningar endast påverkar vilken port slutpunkten använder för att hämta information från ursprunget.

Kontrollera slutpunktsinställningarna

På sidan Slutpunkt väljer du knappen Konfigurera .

Sidan Konfigurera nätverksslutpunkt för innehållsleverans visas.

Protokoll

För Protokoll kontrollerar du att det protokoll som används av klienterna är valt. Eftersom samma protokoll som används av klienten är det som används för att komma åt ursprunget är det viktigt att ursprungsportarna konfigureras korrekt i föregående avsnitt. Nätverksslutpunkten för innehållsleverans lyssnar bara på standardportarna HTTP och HTTPS (80 och 443), oavsett ursprungsportar.

Nu går vi tillbaka till vårt hypotetiska exempel med HTTP://www.contoso.com:8080/file.txt. Som du kommer ihåg angav Contoso 8080 som HTTP-port, men vi antar också att de angav 44300 som HTTPS-port. Om de skapade en slutpunkt med namnet contoso skulle deras värdnamn för innehållsleveransnätverksslutpunkten vara contoso.azureedge.net. En begäran om HTTP://Contoso.azureedge.net/file.txt är en HTTP-begäran, så slutpunkten använder HTTP på port 8080 för att hämta den från ursprunget. En säker begäran via HTTPS HTTPS://Contoso.azureedge.net/file.txtgör att slutpunkten använder HTTPS på port 44300 när filen hämtas från ursprunget.

Värdadress för ursprung

Ursprungsvärdrubriken är värdet för värdrubriken som skickas till ursprunget med varje begäran. I de flesta fall bör det här värdet vara samma som det ursprungsvärdnamn som vi verifierade tidigare. Ett felaktigt värde i det här fältet orsakar inte 404-statusar, men kommer sannolikt att orsaka andra 4xx-statusar, beroende på vad ursprunget förväntar sig.

Sökväg till ursprung

Slutligen bör vi verifiera vår ursprungssökväg. Som standard är den här sökvägen tom. Du bör bara använda det här fältet om du vill begränsa omfånget för de origin-värdbaserade resurser som du vill göra tillgängliga i nätverket för innehållsleverans.

I exempelslutpunkten ville vi att alla resurser på lagringskontot skulle vara tillgängliga, så ursprungssökvägen lämnades tom. En begäran om att HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt resultera i en anslutning från slutpunkten till cdndocdemo.core.windows.net som begär /publicblob/lorem.txt. På samma sätt resulterar en begäran om HTTPS://cdndocdemo.azureedge.net/donotcache/status.png resultat i slutpunkten som begär /donotcache/status.png från ursprunget.

Men vad händer om du inte vill använda nätverket för innehållsleverans för varje sökväg i ditt ursprung? Anta att du bara ville exponera den offentliga blobsökvägen . Om vi anger /publicblob i fältet Ursprungssökväg kommer slutpunkten att infoga /publicblob innan varje begäran görs till ursprunget. Så begäran för HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt tillfället tar begärandedelen av URL:en, /publicblob/lorem.txt, och lägger till /publicblob i början. Resulterar i en begäran om /publicblob/publicblob/lorem.txt från ursprunget. Om sökvägen inte matchar en faktisk fil returnerar ursprunget statusen 404. Rätt URL för att hämta lorem.txt i det här exemplet skulle faktiskt vara HTTPS://cdndocdemo.azureedge.net/lorem.txt. Vi inkluderar inte sökvägen /publicblob alls, eftersom begärandedelen av URL:en är /lorem.txt och slutpunkten lägger till /publicblob, vilket resulterar i att /publicblob/lorem.txt skickas till ursprunget.