Problemen met Azure Content Delivery Network-eindpunten oplossen die een 404-statuscode retourneren

Belangrijk

Azure CDN Standard van Microsoft (klassiek) wordt op 30 september 2027 buiten gebruik gesteld. Om serviceonderbrekingen te voorkomen, is het belangrijk dat u uw Azure CDN Standard migreert van Microsoft-profielen (klassiek) naar de Azure Front Door Standard- of Premium-laag op 30 september 2027. Zie Azure CDN Standard van Microsoft (klassiek) buiten gebruik stellen voor meer informatie.

Azure CDN van Edgio is op 15 januari 2025 buiten gebruik gesteld. Zie Azure CDN van de veelgestelde vragen over buitengebruikstelling van Edgio voor meer informatie.

In dit artikel kunt u problemen met Azure Content Delivery Network-eindpunten oplossen die 404 HTTP-antwoordstatuscodes retourneren.

Als u op elk gewenst moment in dit artikel meer hulp nodig hebt, kunt u contact opnemen met de Azure-experts op de MSDN Azure en de Stack Overflow-forums. U kunt ook een Azure-ondersteuningsincident indienen. Ga naar de Azure-ondersteuningssite en selecteer Ondersteuning krijgen.

Symptoom

U hebt een netwerkprofiel voor contentlevering en een eindpunt gemaakt, maar uw inhoud lijkt niet beschikbaar te zijn op het netwerk voor contentlevering. Gebruikers die toegang proberen te krijgen tot uw inhoud via de NETWERK-URL voor contentlevering, ontvangen een HTTP 404-statuscode.

Oorzaak

Er zijn verschillende mogelijke oorzaken, waaronder:

• De oorsprong van het bestand is niet zichtbaar voor het netwerk voor contentlevering.
• Het eindpunt is onjuist geconfigureerd, waardoor het netwerk voor contentlevering op de verkeerde plaats kan zoeken.
• De host weigert de hostheader van het netwerk voor contentlevering.
• Het eindpunt heeft geen tijd gehad om door te geven in het netwerk voor contentlevering.

Stappen voor probleemoplossing

Belangrijk

Nadat u een netwerkeindpunt voor contentlevering hebt gemaakt, is het niet onmiddellijk beschikbaar voor gebruik, omdat het even duurt voordat de registratie is doorgegeven via het netwerk voor contentlevering:

• Voor profielen van Azure CDN Standard van Microsoft is het doorgeven gewoonlijk binnen tien minuten voltooid.
• Voor Azure CDN Standard van Edgio en Azure CDN Premium van Edgio-profielen wordt doorgifte meestal binnen 90 minuten voltooid.

Als u de stappen in dit document voltooit en nog steeds 404 antwoorden krijgt, kunt u een paar uur wachten om het opnieuw te controleren voordat u een ondersteuningsticket opent.

Het oorspronkelijke bestand controleren

Controleer eerst of het bestand in de cache beschikbaar is op de oorspronkelijke server en openbaar toegankelijk is op internet. De snelste manier om dit te doen, is door een browser te openen in een privésessie of incognitosessie en rechtstreeks naar het bestand te bladeren. Typ of plak de URL in het adresvak en controleer of deze resulteert in het bestand dat u verwacht. Stel dat u een bestand in een Azure Storage-account hebt, dat toegankelijk is op HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt. Als u de inhoud van dit bestand kunt laden, wordt de test doorgegeven.

Waarschuwing

Hoewel dit de snelste en eenvoudigste manier is om te controleren of uw bestand openbaar beschikbaar is, kunnen sommige netwerkconfiguraties in uw organisatie ervoor zorgen dat een bestand openbaar beschikbaar is wanneer het in feite alleen zichtbaar is voor gebruikers van uw netwerk (zelfs als het wordt gehost in Azure). Om ervoor te zorgen dat dit niet het geval is, test u het bestand met een externe browser, zoals een mobiel apparaat dat niet is verbonden met het netwerk van uw organisatie of een virtuele machine in Azure.

De oorsprongsinstellingen controleren

Nadat u hebt gecontroleerd of het bestand openbaar beschikbaar is op internet, controleert u de oorspronkelijke instellingen. Blader in Azure Portal naar uw netwerkprofiel voor contentlevering en selecteer het eindpunt dat u wilt oplossen. Selecteer de oorsprong op de resulterende eindpuntpagina .

De pagina Oorsprong wordt weergegeven.

Oorsprongstype en hostnaam

Controleer of de waarden van het type Origin en de hostnaam Van oorsprong juist zijn. In dit voorbeeld HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txtis het hostnaamgedeelte van de URL cdndocdemo.blob.core.windows.net, wat juist is. Omdat oorsprongen van Azure Storage, Web App en Cloud Service een vervolgkeuzelijst gebruiken voor het veld Origin-hostnaam , zijn onjuiste spellingen geen probleem. Als u echter een aangepaste oorsprong gebruikt, moet u ervoor zorgen dat uw hostnaam juist is gespeld.

HTTP- en HTTPS-poorten

Controleer uw HTTP- en HTTPS-poorten. In de meeste gevallen zijn 80 en 443 juist en u hebt geen wijzigingen nodig. Als de oorspronkelijke server echter luistert op een andere poort, moet deze hier worden weergegeven. Als u het niet zeker weet, bekijkt u de URL voor het oorspronkelijke bestand. De HTTP- en HTTPS-specificaties gebruiken poorten 80 en 443 als standaardwaarde. In de voorbeeld-URL HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txtwordt geen poort opgegeven, dus wordt ervan uitgegaan dat de standaardwaarde 443 is en dat de instellingen juist zijn.

Stel dat de URL voor het oorspronkelijke bestand dat u eerder hebt getest, echter is HTTP://www.contoso.com:8080/file.txt. Let op het gedeelte : 8080 aan het einde van het hostnaamsegment. Dit nummer geeft de browser de opdracht om poort 8080 te gebruiken om verbinding te maken met de webserver op www.contoso.com. Daarom moet u 8080 invoeren in het veld HTTP-poort. Het is belangrijk om te weten dat deze poortinstellingen alleen van invloed zijn op de poort die het eindpunt gebruikt om informatie op te halen uit de oorsprong.

De eindpuntinstellingen controleren

Selecteer op de pagina Eindpunt de knop Configureren .

De pagina Netwerkeindpunt voor contentlevering configureren wordt weergegeven.

Protocollen

Controleer voor Protocollen of het protocol dat door de clients wordt gebruikt, is geselecteerd. Omdat hetzelfde protocol dat door de client wordt gebruikt, het protocol is dat wordt gebruikt voor toegang tot de oorsprong, is het belangrijk dat de oorspronkelijke poorten correct zijn geconfigureerd in de vorige sectie. Het netwerkeindpunt voor contentlevering luistert alleen op de standaard-HTTP- en HTTPS-poorten (80 en 443), ongeacht de oorspronkelijke poorten.

Laten we terugkeren naar ons hypothetische voorbeeld met HTTP://www.contoso.com:8080/file.txt. Zoals u weet, heeft Contoso 8080 opgegeven als http-poort, maar laten we er ook van uitgaan dat ze 44300 als hun HTTPS-poort hebben opgegeven. Als ze een eindpunt met de naam contoso hebben gemaakt, wordt de hostnaam van het netwerkeindpunt van de inhoudslevering contoso.azureedge.net. Een aanvraag voor HTTP://Contoso.azureedge.net/file.txt is een HTTP-aanvraag, dus het eindpunt gebruikt HTTP op poort 8080 om deze op te halen uit de oorsprong. Een veilige aanvraag via HTTPS HTTPS://Contoso.azureedge.net/file.txt, zou ervoor zorgen dat het eindpunt HTTPS gebruikt op poort 44300 bij het ophalen van het bestand uit de oorsprong.

Orignele hostheader

De hostheader origin is de hostheaderwaarde die bij elke aanvraag naar de origin wordt verzonden. In de meeste gevallen moet deze waarde hetzelfde zijn als de hostnaam van oorsprong die we eerder hebben geverifieerd. Een onjuiste waarde in dit veld veroorzaakt geen 404-statussen, maar veroorzaakt waarschijnlijk andere 4xx-statussen, afhankelijk van wat de oorsprong verwacht.

Origineelpad

Ten slotte moeten we ons origin-pad verifiëren. Dit pad is standaard leeg. U moet dit veld alleen gebruiken als u het bereik wilt beperken van de resources die worden gehost op basis van oorsprong die u beschikbaar wilt maken op het netwerk voor contentlevering.

In het voorbeeldeindpunt willen we dat alle resources in het opslagaccount beschikbaar zijn, zodat het origin-pad leeg is gelaten. Daarom wordt een aanvraag om HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt een verbinding van het eindpunt tot stand te cdndocdemo.core.windows.net die /publicblob/lorem.txt aanvragen. Een aanvraag voor HTTPS://cdndocdemo.azureedge.net/donotcache/status.png resultaten in het eindpunt dat /donotcache/status.png van de oorsprong aanvraagt.

Maar wat als u het netwerk voor contentlevering niet wilt gebruiken voor elk pad op uw oorsprong? Stel dat u alleen het openbare blobpad wilt weergeven. Als we /publicblob invoeren in het padveld Oorsprong, zorgt dit ervoor dat het eindpunt /publicblob invoegt voordat elke aanvraag wordt ingediend bij de oorsprong. De aanvraag voor HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt nu neemt dus het aanvraaggedeelte van de URL, /publicblob/lorem.txt en voegt /publicblob toe aan het begin. Dit resulteert in een aanvraag voor /publicblob/publicblob/lorem.txt van de oorsprong. Als dat pad niet wordt omgezet in een daadwerkelijk bestand, retourneert de oorsprong een 404-status. De juiste URL voor het ophalen van lorem.txt in dit voorbeeld zou eigenlijk zijn HTTPS://cdndocdemo.azureedge.net/lorem.txt. Het /publicblob-pad is helemaal niet opgenomen, omdat het aanvraaggedeelte van de URL /lorem.txt is en het eindpunt /publicblob toevoegt, wat resulteert in /publicblob/lorem.txt de aanvraag wordt doorgegeven aan de oorsprong.