Ursprung konfigurieren

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

Cloud Storage-Bucket als Ursprung konfigurieren

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

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. Behalten Sie für Cloud Storage die Standardeinstellungen für Protokoll und Port bei.

8. Optional: Damit Überschreibungen des Ursprungs-Anfrageheaders Vorrang vor Headern haben, die vom Client gesendet oder durch Headeraktionen auf Routenebene verändert wurden, gehen Sie so vor:

   1. Wählen Sie Ursprungsüberschreibung aktivieren aus.
   2. Geben Sie im Abschnitt Headers Header an, indem Sie ein oder mehrere Name/Wert-Paare hinzufügen.

9. Optional: Wählen Sie einen Failover-Ursprung aus, den Sie ausprobieren möchten, falls dieser Ursprung nicht mehr erreichbar ist. 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 von diesem Ursprung aus zu füllen.

13. Optional: Geben Sie die folgenden Werte für timeout an:

    1. Wählen Sie für Zeitüberschreitung für Verbindung die maximale Wartezeit aus, die auf den Aufbau der Verbindung für den Ursprung gewartet 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-regional oder regional ist.

Wenn Sie einen Dienst konfigurieren, können Sie Ihre Video-on-Demand-Inhalte an einen Bucket und Livestreaming-Inhalte an einen zweiten Bucket weiterleiten. Dies ist nützlich, wenn Sie verschiedene Teams haben, die jeden Workflow verwalten. Um die Latenz beim Füllen des Cache zu reduzieren, können Sie die Region eu-media.example.com an einen multiregionalen Cloud Storage-Bucket in der EU und die Region us-media.example.com (oder einen Abgleich im Pfad, Header oder Abfrageparameter) an einen US-basierten Storage-Bucket weiterleiten.

Wichtig: Wir empfehlen die Verwendung eines multiregionalen Buckets als Ursprungsspeicher, da ein multiregionaler Bucket mehr geografische Redundanz für gespeicherte Objekte bietet.

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

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

• Prüfen Sie, ob die IP-Adresse der Verbindung aus den Cache-Füllbereichen von Media CDN stammt. Diese Bereiche werden von allen Kunden gemeinsam genutzt, aber beim Herstellen einer Verbindung zu einem Ursprung immer von EdgeCacheService-Ressourcen verwendet.
• Fügen Sie einen benutzerdefinierten Anfrageheader mit einem Tokenwert hinzu, den Sie am Ursprung validieren (z. B. einen zufälligen 16-Byte-Wert). Ihr Ursprung kann dann Anfragen ablehnen, die diesen Wert nicht enthalten.

Informationen zum Festlegen von Anfrageheadern pro Route finden Sie unter Benutzerdefinierte Header.

Ursprungsprotokoll konfigurieren

Legen Sie für Ursprünge, die nur HTTPS (HTTP/1.1 über TLS) oder HTTP/1.1 (ohne TLS) unterstützen, das Feld protocol explizit fest. Gehen Sie dazu so vor:

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. Geben Sie für HTTP auch den Port als 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 von jedem über das Internet erreichbaren HTTP- oder HTTPS-Endpunkt abrufen. In einigen Fällen kann es erforderlich sein, eine Authentifizierung zu verlangen, damit Media CDN nur Inhalte abrufen und unbefugten Zugriff verhindern kann. Cloud Storage unterstützt dies über IAM-Berechtigungen.

Wichtig: Legen Sie für Routen, die mit einem privaten Cloud Storage-Ursprung verknüpft sind, den Cache-Modus auf FORCE_CACHE_ALL fest. 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:

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

Wenn Sie die Berechtigungen eines Cloud Storage-Bucket ändern möchten, benötigen Sie die IAM-Rolle „Storage-Administrator“.

Das Media CDN-Dienstkonto gehört dem Media CDN-Projekt und wird nicht in der Liste der Dienstkonten Ihres Projekts angezeigt.

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 erstellen, um die Erstellung des Dienstkontos auszulösen. In den meisten Fällen ist dies die EdgeCacheOrigin-Ressource, die mit Ihrem Cloud Storage-Bucket verbunden ist.

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

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

Hinweis: Warten Sie mindestens 10 Minuten, bis die Konfiguration übernommen wurde, bevor Sie den öffentlichen Zugriff auf einen vorhandenen Storage-Bucket entfernen, der als Produktionsursprung dient.

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

gsutil iam ch -d allUsers gs://BUCKET

Wenn Sie prüfen möchten, ob der öffentliche Zugriff entfernt wurde, öffnen Sie ein Browserfenster im Inkognitomodus und versuchen Sie, mit https://storage.googleapis.com/BUCKET/object.ext auf ein Bucket-Objekt zuzugreifen.

Wenn Sie EdgeCacheService-Ressourcen in einem Projekt Zugriff auf einen Cloud Storage-Bucket in einem anderen Projekt gewähren möchten, können Sie dem Media CDN-Dienstkonto in diesem Projekt Zugriff auf den Storage-Bucket gewähren.

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

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

Die Konfiguration von privatem Cloud Storage verhindert nicht, dass direkt über Media CDN auf Ihre im Cache gespeicherten Inhalte zugegriffen wird. 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 zwischen Compute Engine, GKE oder lokalen Ursprüngen benötigen, können Sie einen externen Application Load Balancer als Ursprung konfigurieren.

Auf diese Weise können Sie beispielsweise Ihre Livestreaming-Packager hinter Media CDN oder einer Gruppe von Envoy-Proxys, die von Cloud Service Mesh verwaltet werden, für die Verbindung zurück zu Ihrer lokalen Infrastruktur konfigurieren.

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

• VM-Instanzgruppen in Compute Engine
• 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 Videomanifesten und einen Cloud Storage-Ursprung für die Segmentspeicherung kombiniert, sieht in etwa so aus, wobei zwei Ursprünge 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 erstellen, die auf die Weiterleitungsregeln Ihres Load-Balancers verweist. Ein öffentlicher Hostname (Domainname) wird bevorzugt, da dieser für ein SSL (TLS)-Zertifikat und für moderne HTTP-Versionen (HTTP/2 und HTTP/3) erforderlich ist.

Außerdem muss Folgendes gewährleistet sein:

• Ihr Load-Balancer hat eine Route, die mit dem Hostnamen übereinstimmt, der für Ihre EdgeCacheService-Ressource verwendet wird, oder Sie haben eine urlRewrite.hostRewrite für Routen konfiguriert, bei denen Ihr Load-Balancer als Ursprung konfiguriert ist.
• Ihr Load-Balancer hat ein öffentlich vertrauenswürdiges SSL-Zertifikat (TLS), das für diese Hostnamen konfiguriert ist.

Wenn der Name der öffentlichen Domain, der auf die Weiterleitungsregel Ihres Load-Balancers verweist, beispielsweise origin-packager.example.com ist, müssen Sie einen Ursprung erstellen, bei dem originAddress auf diesen Namen festgelegt ist.

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 aus, den Sie ausprobieren möchten, falls dieser Ursprung nicht mehr erreichbar ist. 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 von diesem Ursprung aus zu füllen.

10. Optional: Geben Sie die folgenden Werte für timeout an:

    1. Wählen Sie für Zeitüberschreitung für Verbindung die maximale Wartezeit aus, die auf den Aufbau der Verbindung für den Ursprung gewartet 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, z. B. origin-packager.example.com

Wenn Sie die IP-Adresse Ihrer Weiterleitungsregel als Ursprungsadresse verwenden oder kein SSL-Zertifikat an Ihren Load-Balancer angehängt ist, können Sie das Protokoll auf HTTP setzen, um auf unverschlüsselte Verbindungen zurückzugreifen. Wir empfehlen, dies nur zu Entwicklungs- oder Testzwecken zu 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 dreimal, bevor ein Failover-Ursprung versucht. Bei dieser Konfiguration versucht Media CDN nach dreimaligem Testen des primären Ursprungs eine einzelne Anfrage für FAILOVER_ORIGIN. Wenn auch der Failover-Ursprung nicht erfolgreich reagiert, gibt Media CDN entweder die gesamte Ursprungsantwort oder, wenn kein Statuscode empfangen wird, eine HTTP-502 Bad Gateway-Antwort zurück.

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. Aufgrund der Konfiguration versucht Media CDN bei Verbindungsfehlern (z. B. DNS-, TCP- oder TLS-Fehler), HTTP 5xx-Antworten vom Ursprung oder HTTP-404 Not Found. Nach zwei Versuchen wird ein Failover auf FAILOVER_ORIGIN durchgeführt.

Über Ihre konfigurierten Ursprünge hinweg werden maximal vier Versuche unternommen: der ursprüngliche Versuch plus bis zu drei Wiederholungsversuche. Sie können einen maxAttempts-Wert pro Ursprung konfigurieren, um zu bestimmen, wie viele Wiederholungsversuche durchgeführt werden, bevor ein Failover versucht wird.

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 das folgende originOverrideAction-Konfigurationsbeispiel, um sie festzulegen:

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 hat die Einstellung originOverrideAction.hostRewrite Vorrang vor vorhandenen Header-Umschreibungen, die auf Routen konfiguriert sind, die auf diesen Ursprung 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. Wenn Sie vorhandene Header ersetzen möchten, legen Sie für headerAction.replace den Wert true fest.

Ursprungs-Failover mit folgender Weiterleitung

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

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 Antwort zurückgibt, verwendet Media CDN diese Antwort für die Cache-Füllung.

Angenommen, primary.example.com gibt ein HTTP-302 Found Redirect an Location: b.example.com zurück. Bei dem zweiten Versuch, den Ursprung zu kontaktieren, folgt Media CDN der Weiterleitung zu b.example.com. In diesem Fall geht Media CDN so vor:

• Wenn b.example.com eine erfolgreiche Antwort zurückgibt, verwendet Media CDN 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 konfiguriert ist.

Bei einem Failover von Media CDN zu SecondaryOrigin verwendet Media CDN die Konfiguration SecondaryOrigin und versucht, eine Verbindung zu 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, verwendet Media CDN 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, c.example.com zu kontaktieren. In diesem Beispiel ist dies der 2. Versuch für SecondaryOrigin und der 4. Versuch insgesamt.

Wenn der Versuch, c.example.com zu kontaktieren, eine erfolgreiche Antwort zurückgibt, verwendet Media CDN diese Antwort für die Cache-Füllung. Wenn bei diesem Versuch eine Weiterleitung zurückgegeben wird, für die Media CDN konfiguriert ist, gibt Media CDN den HTTP-Fehler 502 Bad Gateway zurück, da die maximale Anzahl von Versuchen zur Kontaktaufnahme mit einem Ursprung erreicht wurde. Media CDN unternimmt maximal vier Versuche über alle Ursprünge hinweg, unabhängig von EdgeCacheOrigin-Konfigurationen. Wenn Media CDN c.example.com nicht kontaktiert, gibt Media CDN entweder eine 504 Gateway Timeout- oder eine 502 Bad Gateway-Antwort zurück.

Wenn Sie eine Systemdiagnose, Round-Robin- oder lastbasierte Steuerung zwischen den Ursprüngen benötigen, können Sie einen externen Application Load Balancer als primären Ursprung konfigurieren.

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.

Als Best Practice sollten Sie die Ursprungsweiterleitung nur für Ursprünge konfigurieren, denen Sie vertrauen und die Sie kontrollieren. Achte darauf, jedem Ursprung in einer Weiterleitungskette zu vertrauen, da jeder Ursprung Inhalte produziert, die von deiner EdgeCacheService bereitgestellt werden.

Fügen Sie der Ressource EdgeCacheOrigin die folgende Konfiguration hinzu, um die folgenden Ursprungsweiterleitungen zu aktivieren:

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

Media CDN verwendet das in den Weiterleitungen angegebene Protokoll, um alle Server zu erreichen. Achte darauf, dass alle Server, auf die Media CDN weitergeleitet werden kann, so weitergeleitet werden können, dass sie deine erforderlichen Protokolle 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 die Wiederholungs- oder Failover-Bedingungen ausgewertet werden.

Die Einstellung redirectConditions gibt an, welche HTTP-Antwortcodes dafür sorgen, dass Media CDN einer Weiterleitung für jeden Ursprung folgt.

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, lesen Sie die Informationen zur Fehlerbehebung bei Ursprüngen.

Nächste Schritte

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