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 den 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 Seite Ursprünge von Media CDN auf.

   Zu „Herkunft“

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. Rufen Sie Ihren Cloud Storage-Bucket auf und wählen Sie ihn aus.

7. Behalten Sie für Cloud Storage die Standardeinstellungen für Protokoll und Port bei.

8. Optional: Für Überschreibungen des Ursprungs-Anfrageheaders Vorrang gegenüber Headern, die vom Client gesendet oder durch Aktionen für Header auf Routenebene:

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

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 Wiederholbedingungen aus.

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

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

    1. Wählen Sie für Verbindungs-Timeout die maximale Dauer aus, die gewartet werden soll, bis die Ursprungsverbindung hergestellt ist.
    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 ist unabhängig davon, ob der Bucket multiregional, biregional oder regional ist.

Wenn du einen Dienst konfigurierst, kannst du deine Video-on-Demand-Inhalte an einen und Livestreaming-Inhalte in einen zweiten Bucket. Das ist nützlich, wenn verschiedene Teams die einzelnen Workflows verwalten. Um die Latenz für die Cache-Füllung zu reduzieren, können Sie die Region eu-media.example.com ebenfalls an einen multiregionalen Cloud Storage-Bucket in der EU und die Region us-media.example.com (oder eine Übereinstimmung in Pfad, Header oder Abfrageparameter) an einen US-basierten Storage-Bucket weiterleiten.

Wichtig: Wir empfehlen die Verwendung eines multiregionalen Buckets für den Ursprungsspeicher, da dieser eine erhöhte 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

Du kannst eine der folgenden unterstützten Methoden verwenden, um zu prüfen, ob eine Anfrage von Media CDN stammt:

• Prüfe, ob die IP-Adresse der Verbindung zu den Cache-Füllungsbereichen des Media CDN gehört. Diese Bereiche werden für alle Kunden freigegeben, werden aber 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 am Ursprung validieren (z. B. einen zufälligen 16-Byte-Wert). Ihr Ursprung kann dann Anfragen ablehnen die diesen Wert nicht enthalten.

Ursprungsprotokoll konfigurieren

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

Console

1. Rufen Sie in der Google Cloud Console die Media CDN-Seite Origins auf.

   Zu „Herkunft“

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

3. Wählen Sie als Protokoll HTTPS oder HTTP aus. Geben Sie für HTTP 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 sein, dass Sie eine Authentifizierung erforderlich machen möchten, damit nur Media CDN Inhalte abrufen kann und nicht autorisierter Zugriff verhindert wird. 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.

So gehen Sie bei Cloud Storage-Quellen vor:

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

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

Das Media CDN-Dienstkonto gehört zum 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 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 du Media CDN Zugriff auf einen Bucket gewähren möchtest, musst du dem Dienstkonto die Rolle objectViewer zuweisen:

gcloud storage buckets add-iam-policy-binding gs://BUCKET \
--member=serviceAccount:[e-mail] \
--role=roles/storage.objectViewer

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

Verwenden Sie den Befehl gcloud storage buckets remove-iam-policy-binding. zum Entfernen von Berechtigungen, die der Rolle allUsers für den angegebenen Bucket gewährt wurden. Wenn der Bucket beispielsweise allUsers die Rolle objectViewer gewährt, entfernen Sie die Berechtigung mit dem folgenden Befehl:

gcloud storage buckets remove-iam-policy-binding gs://BUCKET \
--member=allUsers --role=roles/storage.objectViewer

Öffnen Sie einen Inkognitomodus, um zu prüfen, ob der öffentliche Zugriff entfernt wurde Browserfenster und versuchen, 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.

Achten Sie dabei darauf, dass die 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 unterschiedliche Media CDN-Umgebungen (z. B. Entwicklung, Staging oder Produktion) und ein separates Projekt mit Ihren Video- oder Medien-Assets haben.

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 für Compute Engine, GKE oder lokale Ursprünge Sie können einen externen Application Load Balancer konfigurieren. als Ursprung verwendet.

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 für folgende Komponenten konfigurieren:

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

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 erstellen, die auf die Weiterleitungsregeln Ihres Load Balancers verweist. 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 müssen Sie Folgendes beachten:

• Ihr Load-Balancer hat eine Route, die dem für Ihr EdgeCacheService-Ressource oder von Ihnen konfiguriert urlRewrite.hostRewrite für Routen, bei denen Ihr Load-Balancer als Ursprung konfiguriert ist.
• 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 Origins auf.

   Zu „Herkunft“

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 die Quelladresse die Option FQDN oder IP-Adresse angeben aus.

6. Geben Sie den FQDN oder die IP-Adresse Ihres Google Cloud-Load Balancers 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 Wiederholbedingungen 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 die folgenden Werte für die Zeitüberschreitung an:

    1. Wählen Sie für Verbindungs-Zeitlimit die maximale Dauer aus, die gewartet werden soll, bis die Ursprungsverbindung hergestellt ist.
    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 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 Verhalten beim Failover des Ursprungs konfigurieren.

Ursprungs-Failover ohne Folgen der 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 der Parameter 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 bewirkt, dass Media CDN bei Verbindungsfehlern (wie DNS-, TCP- oder TLS-Fehlern), HTTP 5xx-Antworten vom Ursprung oder HTTP 404 Not Found Wiederholungsversuche unternimmt. 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 einen maxAttempts-Wert pro Ursprung konfigurieren, um zu bestimmen, wie viele Wiederholungsversuche ausgeführt werden, bevor ein Failover durchgeführt 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

Ursprungs-Failover mit folgender Weiterleitung

Angenommen, Sie haben die folgenden EdgeCacheOrigin-Ressourcen konfiguriert und die Routen Ihrer EdgeCacheService-Ressource sind so konfiguriert, dass PrimaryOrigin für die Cache-Auslieferung verwendet wird:

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 geschieht Folgendes:

• 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 PrimaryOrigin in diesem Beispiel für zwei maxAttempts konfiguriert ist.

Wenn Media CDN auf SecondaryOrigin umstellt, verwendet Media CDN die SecondaryOrigin-Konfiguration 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 geschieht Folgendes:

• Wenn secondary.example.com eine erfolgreiche Antwort zurückgibt, verwendet Media CDN diese Antwort für die Cache-Auslieferung.
• Wenn secondary.example.com einen HTTP-302 Found Redirect an Location: c.example.com zurückgibt, versucht Media CDN, c.example.com zu kontaktieren. 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 führt unabhängig von EdgeCacheOrigin-Konfigurationen höchstens vier Versuche über alle Ursprünge hinweg durch. Wenn Media CDN schließlich bei der Kontaktaufnahme mit c.example.com fehlschlägt, gibt Media CDN entweder eine 504 Gateway Timeout-Antwort oder eine 502 Bad Gateway-Antwort zurück.

Wenn Sie eine Systemdiagnose, Round Robin- oder lastenabhängiges Steuern über Ursprünge hinweg 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 domainübergreifenden Weiterleitungen.

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 Weiterleitung von Ursprüngen am besten nur für vertrauenswürdige und von Ihnen kontrollierte Ursprünge. 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 die Bedingungen für einen erneuten Versuch oder ein Failover ausgewertet werden.

Mit der Einstellung redirectConditions wird festgelegt, bei welchen HTTP-Antwortcodes Media CDN für jeden Ursprung einer Weiterleitung 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

Ursprungsspezifische Umschreibungen oder Headeränderungen des Hosts konfigurieren

Wenn Ihr Ursprung eine ursprungsspezifische Hostumschreibung oder Header-Änderung erfordert, 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

Die Einstellung originOverrideAction.hostRewrite hat Vorrang vor allen vorhandenen Header-Neuschreibungen, die für 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 ist das Hinzufügen statischer Authorization-Header. 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, setzen Sie headerAction.replace auf true.

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

Fehlerbehebung

Wenn ein Ursprung nicht wie erwartet funktioniert, finden Sie hier Informationen zur Fehlerbehebung.

Nächste Schritte

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