Ursprung konfigurieren

Sie können Ursprünge für Media CDN auf verschiedene Arten konfigurieren. Auf dieser Seite finden Sie wie Sie Ursprünge konfigurieren.

Cloud Storage-Bucket als Ursprung konfigurieren

Media CDN unterstützt Cloud Storage-Buckets als Back-Ends nach Inhalten suchen. Jeder Dienst kann auf mehrere Buckets verweisen, indem er Routen für Host, Pfade und andere Anfrageattribute.

Cloud Storage-Buckets werden konfiguriert, indem die Bucket-URL, z. B. gs://my-bucket, als Ursprungsadresse beim Erstellen einer Ursprungsressource verwendet wird.

Console

1. Rufen Sie in der Google Cloud Console die Media CDN-Seite Ursprünge auf.

   Zu „Ursprünge“

2. Klicken Sie auf Ursprung erstellen.

3. Geben Sie einen Namen für den Ursprung ein. Beispiel: cloud-storage-origin.

4. Optional: Geben Sie eine Beschreibung ein.

5. Wählen Sie als Ursprungsadresse die Option Google Cloud Storage-Bucket auswählen aus.

6. Suchen Sie Ihren Cloud Storage-Bucket und wählen Sie ihn aus.

7. Für Cloud Storage das Standardprotokoll und den Standardport beibehalten Einstellungen.

8. Optional: Damit Überschreibungen des Ursprungsanfrageheaders Vorrang vor Header, die vom Client gesendet oder durch Header-Aktionen auf Routenebene verändert wurden, Gehen Sie so vor:

   1. Wählen Sie Ursprungsüberschreibung aktivieren aus.
   2. Legen Sie im Abschnitt Headers einen oder mehrere Header fest, um Header anzugeben. Name/Wert-Paare.

9. Optional: Wählen Sie einen Failover-Ursprung für den Fall aus, dass dieser Ursprung zu nicht erreichbar. Sie können dieses Feld später aktualisieren.

10. Wählen Sie Weiterleitungsbedingungen aus.

11. Wählen Sie Bedingungen für Wiederholungen aus.

12. Wählen Sie für Maximale Versuche die maximale Anzahl von Versuchen aus, den Cache zu füllen von diesem Ursprung.

13. Optional: Geben Sie das folgende Zeitlimit an. Werte:

    1. Wählen Sie unter Zeitlimit für Verbindung die maximale Wartezeit für den Ursprungsverbindung, die hergestellt werden soll.
    2. Wählen Sie für Antwortzeitlimit die maximale Dauer aus, die für den Abschluss einer Antwort zulässig sein soll.
    3. Wählen Sie für Lesezeitlimit die maximale Dauer aus, die zwischen Lesevorgängen einer einzelnen HTTP-Verbindung oder eines Streams gewartet werden soll.

14. Optional: Klicken Sie auf Label hinzufügen und geben Sie ein oder mehrere Schlüssel/Wert-Paare an.

15. Klicken Sie auf Ursprung erstellen.

gcloud

Führen Sie folgenden gcloud edge-cache origins create-Befehl aus:

gcloud edge-cache origins create ORIGIN \
    --origin-address=ADDRESS

Ersetzen Sie Folgendes:

• ORIGIN: der Name des neuen Ursprungs
• ADDRESS: der Bucket-Name, z. B. gs://my-bucket

Dies gilt unabhängig davon, ob der Bucket multiregional, dual-region oder regional.

Wenn du einen Dienst konfigurierst, kannst du deinen Video-on-Demand-Content an einen und Livestreaming-Inhalte in einen zweiten Bucket. Dies ist nützlich, wenn Sie die für die Verwaltung jedes Workflows zuständig sind. Um die Latenz beim Füllen des Cache zu verringern, können Sie die Region eu-media.example.com ähnlich an ein multiregionales Cloud Storage-Bucket in der EU und in us-media.example.com Region (oder Abgleich auf Pfad, Header oder Suchparameter) mit einem US-amerikanischen Speicher Bucket.

Wichtig: Wir empfehlen, einen multiregionalen Bucket zu verwenden für den Ursprungsspeicher, da ein multiregionaler Bucket erhöhte geografische Redundanz für gespeicherte Objekte.

Media-CDN-Buckets (zum Vergrößern klicken)

In Fällen, in denen die Schreiblatenz von kritischer Bedeutung ist, z. B. beim Livestreaming mit niedriger Latenz, können Sie einen regionalen Cloud Storage-Endpunkt so nah wie möglich bei Ihren Nutzern konfigurieren.

Anfragen authentifizieren

So können Sie prüfen, ob eine Anfrage von Media CDN stammt: Verwenden Sie einen der folgenden unterstützten Ansätze:

• Prüfen Sie, ob die Verbindungs-IP-Adresse vom Media CDN-Server stammt Cache-Füllbereiche. Diese Zeiträume werden für alle Kunden verwendet, wird immer von EdgeCacheService-Ressourcen verwendet, wenn eine Verbindung zu einem Ursprung hergestellt wird.
• Fügen Sie einen benutzerdefinierten Anfrageheader mit einem Tokenwert hinzu, den Sie im origin (z. B. ein zufälliger 16-Byte-Wert). Ihr Ursprung kann dann Anfragen ablehnen die diesen Wert nicht enthalten.

Informationen zum Festlegen von Anfrageheadern pro Route finden Sie unter benutzerdefinierten Headern.

Ursprungsprotokoll konfigurieren

Für Ursprünge, die nur HTTPS (HTTP/1.1 über TLS) oder HTTP/1.1 (ohne TLS) verwenden, legen Sie das Feld protocol so fest:

Console

1. Rufen Sie in der Google Cloud Console die Media CDN-Seite Ursprünge auf.

   Zu „Ursprünge“

2. Wählen Sie Ihren Ursprung aus und klicken Sie auf Bearbeiten.

3. Wählen Sie als Protokoll HTTPS oder HTTP aus. Auch für HTTP: Geben Sie als Port 80 an.

4. Klicken Sie auf Ursprung aktualisieren.

gcloud

Führen Sie folgenden gcloud edge-cache origins update-Befehl aus:

gcloud edge-cache origins update LEGACY_ORIGIN \
    --protocol=HTTPS

Wenn Ihr Ursprung HTTP/2 unterstützt, müssen Sie das Protokoll nicht explizit festlegen.

Private Cloud Storage-Buckets konfigurieren

Media CDN kann Inhalte aus jedem über das Internet erreichbaren HTTP oder HTTPS abrufen Endpunkt. In einigen Fällen kann es erforderlich sein, eine Authentifizierung Media CDN nur erlauben, Inhalte abzurufen, und nicht autorisierte Zugriffe verhindern Zugriff haben. Cloud Storage unterstützt dies über IAM Berechtigungen

Wichtig: Für Routen, die mit einem privaten Cloud Storage verknüpft sind stellen Sie den Cache-Modus auf FORCE_CACHE_ALL Andernfalls wird das Caching verhindert, da private Cloud Storage-Buckets einen cache-control: private-Header festlegen.

Gehen Sie für Cloud Storage-Ursprünge so vor:

• Media CDN-Dienstkonto die Berechtigung objectViewer gewähren IAM-Berechtigung für die Cloud Storage-Buckets, die Sie die Sie als Ursprünge verwenden.
• Die Berechtigung allUsers entfernen.
• Optional: Entfernen Sie die Berechtigung allAuthenticatedUsers.

Zum Ändern der Berechtigungen eines Cloud Storage-Bucket benötigen Sie die IAM-Rolle „Storage-Administrator“:

Das Media CDN-Dienstkonto gehört dem Media CDN-Projekt hinzugefügt und nicht in der Liste der Dienstkonten.

Das Dienstkonto hat das folgende Format und gewährt nur Zugriff auf Media CDN-Ressourcen in den Projekten, die Sie explizit zulassen

[e-mail]

Hinweis: Sie müssen mindestens eine Media CDN-Ressource zum Auslösen erstellen. Erstellen eines Dienstkontos. In den meisten Fällen ist dies die EdgeCacheOrigin-Ressource die mit dem Cloud Storage-Bucket verbunden sind.

Wenn Sie Media CDN Zugriff auf einen Bucket gewähren möchten, gewähren Sie den objectViewer dem Dienstkonto eine Rolle zu:

gsutil iam ch \
serviceAccount:[e-mail]:objectViewer gs://BUCKET

Hinweis: Warten Sie mindestens 10 Minuten, bis die Konfiguration übernommen wurde. Öffentlichen Zugriff auf einen vorhandenen Storage-Bucket entfernen, der als Produktion verwendet wird Ursprung.

Führen Sie den folgenden Befehl aus, um alle Berechtigungen der Rolle allUsers für den angegebenen Bucket zu entfernen: folgenden Befehl:

gsutil iam ch -d allUsers gs://BUCKET

Öffnen Sie einen Inkognitomodus, um zu prüfen, ob der öffentliche Zugriff entfernt wurde Browserfenster und versuchen Sie, mithilfe des Tools auf ein Bucket-Objekt zuzugreifen. https://storage.googleapis.com/BUCKET/object.ext

Zugriff auf EdgeCacheService-Ressourcen in einem Projekt gewähren einem Cloud Storage-Bucket in einem anderen Projekt hinzugefügt haben, können Sie den Zugriff des Media CDN-Dienstkontos in diesem Projekt auf den Speicher Bucket.

Stellen Sie dabei sicher, dass PROJECT_NUM in [e-mail] ist die/der Projektnummer des Projekts mit den EdgeCacheService-Ressourcen, die Zugriff haben. Sie können dies für mehrere Projekte wiederholen, insbesondere wenn einige davon für verschiedene Media CDN-Umgebungen (z. B. Entwicklung, Staging oder Produktion) und ein separates Projekt Ihr Video oder Ihre Medien enthält. Assets.

Sie können den Zugriff auf Ihren Cloud Storage-Ursprung schützen, ohne signierte Anfragen für diese Route senden.

Die Konfiguration von privatem Cloud Storage verhindert nicht, dass im Cache gespeicherte Inhalte gespeichert werden direkt über Media CDN. Informationen darüber, wie Sie signierte Anfragen an einzelne Nutzer senden können, finden Sie unter signierte Anfragen.

Externen Application Load Balancer als Ursprung konfigurieren

Wenn Sie eine aktive Systemdiagnose, Round-Robin- oder lastbasierte Steuerung benötigen in Compute Engine, GKE oder lokalen Quellen Sie können einen externen Application Load Balancer konfigurieren. als Ursprung.

So können Sie z. B. Ihre Livestreaming-Packager konfigurieren, Media CDN oder eine Gruppe von Envoy-Proxys, die von Cloud Service Mesh verwaltet werden um eine Verbindung zurück zu Ihrer lokalen Infrastruktur herzustellen.

Mit Load-Balancern können Sie Back-Ends konfigurieren. für Folgendes:

• Compute Engine VM-Instanzgruppen
• Netzwerk-Endpunktgruppen (einschließlich Compute Engine-VMs und Google Kubernetes Engine-Cluster).
• Serverlose Netzwerk-Endpunktgruppen (Cloud Run, App Engine und Cloud Functions).

Eine Architektur, die einen externen Application Load Balancer-Ursprung für die Bereitstellung von Videos kombiniert und ein Cloud Storage-Ursprung für die Segmentspeicherung mit zwei Startorten, die verschiedenen Routen zugeordnet sind.

Edge-Cache-Bereitstellung (zum Vergrößern klicken)

Wenn Sie einen externen Application Load Balancer als Ursprung konfigurieren möchten, müssen Sie eine Ursprungsressource mit der IP-Adresse oder dem öffentlichen Hostnamen, die auf Ihren Weiterleitungsregeln des Load-Balancers. Ein öffentlicher Hostname (Domainname) wird bevorzugt, da er für ein SSL erforderlich ist. (TLS) und für moderne HTTP-Versionen (HTTP/2 und HTTP/3).

Außerdem muss Folgendes gewährleistet sein:

• Ihr Load-Balancer hat eine Route, die dem für Ihr EdgeCacheService-Ressource oder von Ihnen konfiguriert urlRewrite.hostRewrite für Routen, für die Ihr Load-Balancer konfiguriert ist als Ursprung festlegen.
• Für Ihren Load-Balancer ist ein öffentlich vertrauenswürdiges SSL-Zertifikat (TLS) konfiguriert für diese Hostnamen.

Wenn z. B. der Name der öffentlichen Domain auf die origin-packager.example.com lautet, müssen Sie eine „Origin“ mit dem originAddress auf diesen Namen festgelegt.

Console

1. Rufen Sie in der Google Cloud Console die Media CDN-Seite Ursprünge auf.

   Zu „Ursprünge“

2. Klicken Sie auf Ursprung erstellen.

3. Geben Sie einen Namen für den Ursprung ein. Beispiel: load-balancer-origin.

4. Optional: Geben Sie eine Beschreibung ein.

5. Wählen Sie für Ursprungsadresse die Option FQDN oder IP-Adresse angeben aus.

6. Geben Sie den FQDN oder die IP-Adresse für den Google Cloud-Load-Balancer ein.

7. Optional: Wählen Sie einen Failover-Ursprung für den Fall aus, dass dieser Ursprung zu nicht erreichbar. Sie können dieses Feld später aktualisieren.

8. Wählen Sie Bedingungen für Wiederholungen aus.

9. Wählen Sie für Maximale Versuche die maximale Anzahl von Versuchen aus, den Cache zu füllen von diesem Ursprung.

10. Optional: Geben Sie das folgende Zeitlimit an. Werte:

    1. Wählen Sie unter Zeitlimit für Verbindung die maximale Wartezeit für den Ursprungsverbindung, die hergestellt werden soll.
    2. Wählen Sie für Antwortzeitlimit die maximale Dauer aus, die für den Abschluss einer Antwort zulässig sein soll.
    3. Wählen Sie für Lesezeitlimit die maximale Dauer aus, die zwischen Lesevorgängen einer einzelnen HTTP-Verbindung oder eines Streams gewartet werden soll.

11. Optional: Klicken Sie auf Label hinzufügen und geben Sie ein oder mehrere Schlüssel/Wert-Paare an.

12. Klicken Sie auf Ursprung erstellen.

gcloud

Führen Sie folgenden gcloud edge-cache origins create-Befehl aus:

gcloud edge-cache origins create LB_ORIGIN \
    --origin-address=LB_ADDRESS

Ersetzen Sie Folgendes:

• LB_ORIGIN: der Name des Ursprungs
• LB_ADDRESS: der FQDN oder die IP-Adresse Adresse, z. B. origin-packager.example.com

Wenn Sie die IP-Adresse der Weiterleitungsregel als Ursprungsadresse verwenden, oder kein SSL-Zertifikat an den Load-Balancer angehängt ist, können Sie Legen Sie als Protokoll HTTP fest, um auf unverschlüsselte Verbindungen zurückzugreifen. Wir empfehlen, dass Sie dies nur zu Entwicklungs- oder Testzwecken tun.

Ursprungs-Failover konfigurieren

In den folgenden Abschnitten wird beschrieben, wie Sie das Ursprungs-Failover-Verhalten konfigurieren.

Ursprungs-Failover ohne folgende Weiterleitung

Im Folgenden ist eine grundlegende Failover-EdgeCacheOrigin-Konfiguration aufgeführt:

name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME

Media CDN wiederholt den primären Ursprung der Route maximal drei Mal bevor ein Failover-Ursprung versucht wird. Nachdem Sie in dieser Konfiguration versucht haben, dreimal den primären Ursprung hat, versucht Media CDN, -Anfrage für FAILOVER_ORIGIN. Wenn die auch der Failover-Ursprung nicht erfolgreich reagiert, dann Media CDN gibt entweder die gesamte Ursprungsantwort zurück oder, falls keine, Statuscode empfangen, wird die HTTP-Antwort 502 Bad Gateway zurückgegeben.

Die Latenz beim Füllen von Cache erhöht sich mit der Anzahl der Wiederholungen und Failover-Ereignisse. Das Erhöhen der Ursprungs-Zeitlimitwerte (z. B. connectTimeout) wirkt sich weiter auf die Cache-Füllungslatenz aus, weil dadurch die Zeit erhöht wird, die mit dem Warten auf die Antwort eines überlasteten oder ausgelasteten Ursprungsservers verbracht wird.

Das folgende Beispiel zeigt eine Konfiguration, die Füllungsanfragen an MY_ORIGIN sendet. Die Konfiguration führt zu Media CDN bei Verbindungsfehlern wie DNS-, TCP- oder TLS-Fehler), HTTP 5xx-Antworten des Ursprungs oder HTTP 404 Not Found. Nach zwei Versuchen erfolgt ein Failover auf FAILOVER_ORIGIN

Über Ihre konfigurierten Ursprünge hinweg werden insgesamt maximal vier Versuche unternommen: der ursprüngliche Versuch plus bis zu drei Wiederholungsversuche. Sie können ein maxAttempts-Wert pro Ursprung, um zu bestimmen, wie viele Wiederholungen vor dem und versucht, ein Failover durchzuführen.

name: MY_ORIGIN
originAddress: DOMAIN_NAME
maxAttempts: 2 # the number of attempts to make before trying the failoverOrigin
failoverOrigin: FAILOVER_ORIGIN
# what conditions trigger a retry or failover
retryConditions:
- CONNECT_FAILURE
- HTTP_5xx # any HTTP 5xx response
- NOT_FOUND # retry on a HTTP 404
timeout:
  maxAttemptsTimeout: 10s # set a deadline for all retries and failover

Wenn für Ihren Ursprung eine ursprungsspezifische Überschreibung oder eine Headeränderung erforderlich ist, Verwenden Sie dazu das folgende originOverrideAction-Konfigurationsbeispiel:

name: FAILOVER_ORIGIN
originAddress: "FAILOVER_ORIGIN_HOST"
originOverrideAction:
  urlRewrite:
    hostRewrite: "FAILOVER_ORIGIN_HOST"
  headerAction:
    requestHeadersToAdd:
    - headerName: "Authorization"
      headerValue: "AUTH-KEY"
      replace: true

Bei der folgenden Konfiguration handelt es sich um eine abgeschlossene:

name: MY_ORIGIN
originAddress: DOMAIN_NAME
maxAttempts: 2 # the number of attempts to make before trying the failoverOrigin
failoverOrigin: FAILOVER_ORIGIN
# what conditions trigger a retry or failover
retryConditions:
- CONNECT_FAILURE
- HTTP_5xx # any HTTP 5xx response
- NOT_FOUND # retry on a HTTP 404
timeout:
  maxAttemptsTimeout: 10s # set a deadline for all retries and failover

name: FAILOVER_ORIGIN
originAddress: "FAILOVER_ORIGIN_HOST"
originOverrideAction:
  urlRewrite:
    hostRewrite: "FAILOVER_ORIGIN_HOST"
  headerAction:
    requestHeadersToAdd:
    - headerName: "Authorization"
      headerValue: "AUTH-KEY"
      replace: true

Im vorherigen Beispiel übernimmt die Einstellung originOverrideAction.hostRewrite Vorrang vor vorhandenen Header-Umschreibungen die für Routen konfiguriert sind, die auf diesen Startpunkt verweisen.

Sie können mit requestHeadersToAdd eindeutige Header pro Ursprung verwenden, die von diesem bestimmten Ursprung angefordert werden. Ein häufiger Anwendungsfall fügt statische Authorization-Header hinzu. Da die Header-Manipulationen während der Ursprungsanfrage ausgeführt werden, ersetzen Header, die pro Ursprung hinzugefügt werden, entweder vorhandene Header desselben Feldnamens oder sie werden diesen angefügt. Standardmäßig fügt Media CDN an vorhandene Header an. Bis vorhandene Header ersetzen sollen, legen Sie für headerAction.replace den Wert true fest.

Ursprungs-Failover mit folgender Weiterleitung

Angenommen, Sie haben die folgende EdgeCacheOrigin konfiguriert Ressourcen und die Routen Ihrer EdgeCacheService-Ressource sind so konfiguriert, Verwenden Sie PrimaryOrigin für die Cache-Füllung:

name: PrimaryOrigin
originAddress: "primary.example.com"
maxAttempts: 2
failoverOrigin: "SecondaryOrigin"
retryConditions: [CONNECT_FAILURE]
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

name: SecondaryOrigin
originAddress: "secondary.example.com"
maxAttempts: 3
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

In diesem Beispiel liest Media CDN, wenn es eine Cache-Füllung durchführt, die Konfiguration der PrimaryOrigin und reagiert entsprechend.

Angenommen, Media CDN stellt als Versuch Nr. 1, den Ursprung zu kontaktieren, eine Verbindung zu primary.example.com her. Wenn primary.example.com eine erfolgreiche verwendet Media CDN diese Antwort für die Cache-Füllung.

Angenommen, primary.example.com gibt ein HTTP-302 Found Redirect-Objekt an Location: b.example.com 2. Versuch, den Ursprung zu kontaktieren, Media CDN folgt der Weiterleitung zu b.example.com. In diesem Fall Media CDN führt Folgendes aus:

• Wenn b.example.com eine erfolgreiche Antwort zurückgibt, verwendet diese Antwort für die Cache-Füllung.
• Wenn b.example.com eine Weiterleitung oder eine Fehlerantwort zurückgibt, erfolgt ein Failover von Media CDN auf den konfigurierten SecondaryOrigin. Das liegt daran, dass in diesem Beispiel PrimaryOrigin für zwei maxAttempts.

Bei einem Failover von Media CDN auf SecondaryOrigin Media CDN verwendet die Konfiguration „SecondaryOrigin“ und versucht, um eine Verbindung mit secondary.example.com herzustellen. Dies ist Versuch Nr. 1, den Ursprung zu kontaktieren, und Versuch Nr. 3 insgesamt.

In diesem Fall geht Media CDN so vor:

• Wenn secondary.example.com eine erfolgreiche Antwort zurückgibt, Media CDN verwendet diese Antwort für die Cache-Füllung.
• Wenn secondary.example.com eine HTTP-302 Found Redirect an Location: c.example.com zurückgibt, versucht Media CDN, eine Verbindung c.example.com. In diesem Beispiel ist das der zweite Versuch für SecondaryOrigin. und Versuch Nr. 4 insgesamt.

Wenn die Kontaktaufnahme mit c.example.com eine erfolgreiche Antwort zurückgibt, Media CDN verwendet diese Antwort für die Cache-Füllung. Wenn der Versuch, eine Weiterleitung zurückgibt, für die Media CDN konfiguriert ist. Media CDN gibt den HTTP-Fehler 502 Bad Gateway zurück, weil hat die maximale Anzahl an Versuchen erreicht, einen Ursprung zu kontaktieren. Media CDN unternimmt maximal vier Versuche für alle Ursprünge. unabhängig von EdgeCacheOrigin-Konfigurationen. Wenn schließlich Media CDN kann keine Verbindung zu c.example.com herstellen, Media CDN gibt entweder eine 504 Gateway Timeout-Antwort oder einen 502 Bad Gateway-Antwort.

Wenn Sie Systemdiagnosen, Round-Robin- oder lastbasierte Steuerung können Sie einen externen Application Load Balancer als primär Ursprung.

Folgen von Ursprungsweiterleitungen konfigurieren

Media CDN unterstützt das Folgen von Weiterleitungen, die von Ihrem Ursprung intern während der Cache-Füllung zurückgegeben werden, anstatt Weiterleitungsantworten direkt an den Client zurückzugeben. Wenn Media CDN so konfiguriert ist, dass es Ursprungsweiterleitungen folgt, ruft Media CDN Inhalte vom Weiterleitungsstandort ab, bevor die weitergeleitete Antwort an den Client im Cache gespeichert und zurückgegeben wird. Media CDN folgt Weiterleitungen domainübergreifend.

Warnung: Durch das Konfigurieren von Weiterleitungen von einem nicht vertrauenswürdigen oder von Angreifern kontrollierten Ursprungsdienst kann Ihre Media CDN-Konfiguration möglicherweise offenen Weiterleitungs-Sicherheitslücken ausgesetzt werden.

Konfigurieren Sie die Ursprungsweiterleitung als Best Practice nur für Ursprünge, denen Sie vertrauen und Kontrolle. Achten Sie darauf, dass Sie jedem Ursprung in einer Weiterleitungskette vertrauen. Jeder Ursprung erzeugt Inhalte, die von Ihrer EdgeCacheService bereitgestellt werden.

Fügen Sie die folgende Konfiguration zu Ihrem EdgeCacheOrigin-Ressource:

name: MY_ORIGIN
originAddress: "DOMAIN_NAME"
maxAttempts: 2
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

Media CDN verwendet das in den Weiterleitungen angegebene Protokoll, um auf allen Servern. Achten Sie darauf, dass alle Server, die Media CDN nutzen könnte, um Ihre erforderlichen Protokolle zu unterstützen. Speziell wenn das Protokoll auf HTTPS, HTTP/2 oder HTTP/3 gesetzt ist, führt Media CDN kein Fallback auf HTTP/1.1-Verbindungen aus, um unsicheren Weiterleitungen zu folgen. Der Host-Header, der an den weitergeleiteten Ursprung gesendet wird, stimmt mit der weitergeleiteten URL überein. Media CDN folgt einer einzelnen Weiterleitung pro EdgeCacheOrigin Versuch, bevor die endgültige Antwort zurückgegeben oder bewertet wird Wiederholungs- oder Failover-Bedingungen.

Mit der Einstellung redirectConditions wird angegeben, welche HTTP-Antwortcodes Media CDN muss einer Weiterleitung für jeden Ursprung folgen.

Bedingung	Beschreibung
MOVED_PERMANENTLY	Weiterleitung für Antwortcode HTTP 301 folgen
FOUND	Weiterleitung für Antwortcode HTTP 302 folgen
SEE_OTHER	Weiterleitung für Antwortcode HTTP 303 folgen
TEMPORARY_REDIRECT	Weiterleitung für Antwortcode HTTP 307 folgen
PERMANENT_REDIRECT	Weiterleitung für Antwortcode HTTP 308 folgen

Quellen der Fehlerbehebung

Wenn sich ein Ursprung nicht wie erwartet verhält, prüfen Sie, wie Sie Ursprünge beheben

Nächste Schritte

• Privaten Amazon S3-kompatiblen Bucket als Ursprung verwenden
• Dienstrouten konfigurieren