Problembehandlung bei Azure Content Delivery Network-Endpunkten, die einen Statuscode von 404 zurückgeben

  • Artikel

Mit diesem Artikel können Sie Probleme mit Azure Content Delivery Network-Endpunkten beheben, die 404 HTTP-Antwortstatuscodes zurückgeben.

Wenn Sie beim Lesen dieses Artikels feststellen, dass Sie weitere Hilfe benötigen, können Sie Ihre Frage im MSDN Azure-Forum oder im Stack Overflow-Forumstellen, um dort Hilfe von Azure-Experten zu erhalten. Alternativ dazu haben Sie die Möglichkeit, einen Azure-Supportfall zu erstellen. Rufen Sie die Azure-Support-Website auf, und wählen Sie die Option Support erhalten.

Symptom

Sie haben ein Netzwerkprofil für die Inhaltsübermittlung und einen Endpunkt erstellt, aber Ihre Inhalte scheinen nicht im Netzwerk für die Inhaltsübermittlung verfügbar zu sein. Benutzer, die versuchen, über die Netzwerk-URL für die Inhaltsübermittlung auf Ihre Inhalte zuzugreifen, erhalten einen HTTP 404-Statuscode.

Ursache

Es gibt mehrere mögliche Ursachen, darunter folgende:

  • Der Ursprung der Datei ist für das Inhaltsübermittlungs-Netzwerk nicht sichtbar.
  • Der Endpunkt ist falsch konfiguriert, sodass das Netzwerk für die Inhaltsübermittlung an der falschen Stelle aussieht.
  • Der Host lehnt den Hostheader aus dem Inhaltsübermittlungs-Netzwerk ab.
  • Der Endpunkt hatte keine Zeit, sich im gesamten Inhaltsübermittlungs-Netzwerk zu verteilen.

Schritte zur Fehlersuche

Wichtig

Nachdem Sie einen Endpunkt für ein Content Delivery Network erstellt haben, steht dieser nicht sofort zur Verfügung, da es einige Zeit dauert, bis sich die Registrierung im Content Delivery Network verbreitet:

  • Bei Profilen vom Typ Azure CDN Standard von Microsoft ist die Weitergabe in der Regel in zehn Minuten abgeschlossen.
  • Bei Profilen vom Typ Azure CDN Standard von Edgio und Azure CDN Premium von Edgio ist die Weitergabe in der Regel innerhalb von 90 Minuten abgeschlossen.

Wenn Sie die in diesem Dokument beschriebenen Schritte ausgeführt haben und dennoch weiterhin der Code 404 zurückgegeben wird, warten Sie unter Umständen ein paar Stunden, und versuchen Sie es dann erneut, bevor Sie ein Supportticket öffnen.

Überprüfen der Ursprungsdatei

Überprüfen Sie zunächst, ob die zwischenzuspeichernde Datei auf dem Ursprungsserver vorhanden ist und darauf öffentlich im Internet zugegriffen werden kann. Das geht am schnellsten, wenn Sie eine InPrivate- oder Inkognito-Browsersitzung öffnen und die Datei direkt aufrufen. Wenn Sie die URL in das Adressfeld eingeben oder einfügen, können Sie prüfen,ob die gewünschte Datei angezeigt wird. Angenommen, Sie verfügen über eine Datei in einem Azure Storage Konto, auf das unter HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt. zugegriffen werden kann. Wenn Sie den Inhalt dieser Datei laden können, war der Test erfolgreich.

Erfolgreich!

Warnung

Dies ist die schnellste und einfachste Möglichkeit, um zu prüfen, ob Ihre Datei öffentlich zugänglich ist. Bei manchen Netzwerkkonfigurationen von Organisationen kann unter Umständen der Eindruck entstehen, dass eine Datei öffentlich zugänglich ist, während sie jedoch nur Benutzern des Netzwerks angezeigt wird (selbst wenn sie in Azure gehostet wird). Um sicherzustellen, dass dies nicht der Fall ist, führen Sie den Test über einen externen Browser durch, z.B. über ein Mobilgerät, das nicht mit dem Netzwerk Ihrer Organisation verbunden ist, oder einen virtuellen Computer in Azure.

Überprüfen der Ursprungseinstellungen

Nachdem Sie geprüft haben, ob die Datei im Internet öffentlich verfügbar ist, überprüfen Sie die Ursprungseinstellungen. Navigieren Sie im Azure-Portal zu Ihrem Content Delivery Network-Profil und wählen Sie den Endpunkt aus, den Sie beheben möchten. Wählen Sie auf der angezeigten Seite Endpunkt den Ursprung aus.

Endpunktseite mit hervorgehobenem Ursprung

Die Seite Ursprung wird angezeigt.

Ursprungsseite

Ursprungstyp und Hostname

Überprüfen Sie die Werte Ursprungstyp und Hostname des Ursprungs auf Ihre Richtigkeit. In diesem Beispiel, HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt, ist cdndocdemo.blob.core.windows.net der Teil der URL, der den Hostnamen darstellt, was korrekt ist. Da die Ursprünge von Azure Storage, Web App und Cloud Service einen Dropdown-Listenwert für das Feld Origin hostname verwenden, sind falsche Schreibweisen kein Problem. Wenn Sie einen benutzerdefinierten Ursprung verwenden, müssen Sie jedoch sicherstellen, dass der Hostname richtig geschrieben ist.

HTTP- und HTTPS-Ports

Überprüfen Sie die HTTP- und HTTPS-Ports. Die Einstellungen 80 und 443 stimmen meistens, und es sind keine Änderungen erforderlich. Wenn der Ursprungsserver jedoch an einem anderen Port lauscht, muss das hier angegeben werden. Wenn Sie sich in Bezug darauf nicht sicher sind, sehen Sie sich die URL Ihrer Ursprungsdatei an. Die HTTP- und HTTPS-Spezifikationen verwenden standardmäßig die Ports 80 und 443. Weil in der Beispiel-URL (HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt) kein Port festgelegt ist, wird der Standardport 443 vorausgesetzt, und die Einstellungen sind richtig.

Wir nehmen nun an, die URL für die zuvor getestete Ursprungsdatei sei HTTP://www.contoso.com:8080/file.txt.. Am Ende des Hostnamensegments wird der Teil : 8080 angezeigt. Diese Zahl weist den Browser an, Port 8080 für die Verbindung mit dem Webserver unter „www.contoso.com“ zu verwenden. Deshalb müssen Sie im Feld HTTP-Port den Wert 8080 eingeben. Beachten Sie, dass sich diese Porteinstellungen nur darauf auswirken, welchen Port der Endpunkt zum Abrufen von Informationen vom Ursprung verwendet.

Überprüfen der Endpunkteinstellungen

Klicken Sie auf der Seite Endpunkt auf die Schaltfläche Konfigurieren.

Endpunktseite mit hervorgehobener Schaltfläche „Konfigurieren“

Die Seite Konfigurieren des Netzwerkendpunkts für die Inhaltsübermittlung wird angezeigt.

Konfigurieren, Seite

Protokolle

Prüfen Sie für die Protokolle, dass das von den Clients verwendete Protokoll ausgewählt ist. Das vom Client verwendete Protokoll wird für den Zugriff auf den Ursprung genutzt. Daher müssen die Ursprungsports wie im letzten Abschnitt beschrieben richtig konfiguriert sein. Der Content-Delivery-Network-Endpunkt lauscht nur auf den Standard-HTTP- und HTTPS-Ports (80 und 443), unabhängig von den Ursprungsports.

Kehren wir nun zu unserem Beispiel mit HTTP://www.contoso.com:8080/file.txt. zurück. Wie Sie wissen, hat Contoso 8080 als HTTP-Port festgelegt. Doch nehmen Sie jetzt einmal an, dass 44300 als HTTPS-Port festgelegt wurde. Wenn Sie einen Endpunkt mit dem Namen contoso erstellen, lautet der Hostname des Content Delivery Network-Endpunkts contoso.azureedge.net. Eine Anforderung für HTTP://Contoso.azureedge.net/file.txt ist eine HTTP-Anforderung. Somit verwendet der Endpunkt HTTP auf Port 8080 für den Abruf vom Ursprung. Bei einer sicheren Anforderung über HTTPS (HTTPS://Contoso.azureedge.net/file.txt) verwendet der Endpunkt HTTPS auf Port 44300 beim Abruf der Datei vom Ursprung.

Header des Ursprungshosts

Der Header des Ursprungshosts ist der Hostheaderwert, der bei jeder Anforderung an den Ursprung übermittelt wird. In den meisten Fällen sollte dieser Wert mit Hostname des Ursprungs übereinstimmen, den Sie bereits zuvor geprüft haben. Bei einem falschen Wert in diesem Feld wird kein 404-Status ausgegeben. Je nachdem, was der Ursprung erwartet, werden aber wahrscheinlich andere 4xx-Statuscodes zurückgegeben.

Ursprungspfad

Als Letztes sollte noch der Ursprungspfadgeprüft werden. Dieser Pfad ist standardmäßig leer. Sie sollten dieses Feld nur verwenden, wenn Sie den Umfang der im Ursprungsland gehosteten Ressourcen, die Sie im Content Delivery Network verfügbar machen möchten, eingrenzen möchten.

Im Beispielendpunkt sollen alle Ressourcen im Speicherkonto verfügbar sein, weshalb das Feld Ursprungspfad leer gelassen wurde. Deshalb führt eine Anforderung an HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt zu einer Verbindung zwischen dem Endpunkt und „cdndocdemo.core.windows.net“, der /publicblob/lorem.txt anfordert. Ebenso führt eine Anforderung an HTTPS://cdndocdemo.azureedge.net/donotcache/status.png dazu, dass der Endpunkt /donotcache/status.png vom Ursprung anfordert.

Aber was geschieht, wenn Sie das Inhaltsübermittlungs-Netzwerk nicht für jeden Pfad ihres Ursprungs verwenden möchten? Angenommen, Sie möchten nur den Pfad public blob verfügbar machen. Wenn Sie im Feld Ursprünglicher Pfad den Pfad /publicblob eingeben, fügt der Endpunkt vor jeder Anforderung an den Ursprung /publicblob ein. Deshalb übernimmt die Anforderung für HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt jetzt den Anforderungsteil der URL, /publicblob/lorem.txt, und an den Anfang wird /publicblob angefügt. Das führt zu einer Anforderung für /publicblob/publicblob/lorem.txt vom Ursprung. Wenn dieser Pfad zu keiner tatsächlichen Datei führt, gibt der Ursprung den Status 404 zurück. Die richtige URL zum Abruf von „lorem.txt“ wäre in diesem Beispiel HTTPS://cdndocdemo.azureedge.net/lorem.txt.. Sie geben den Pfad /publicblob hier nicht an, weil der Anforderungsteil der URL /lorem.txt lautet und der Endpunkt /publicblob hinzufügt, sodass /publicblob/lorem.txt als Anforderung an den Ursprung weitergegeben wird.