此页面由 Cloud Translation API 翻译。

配置服务路由

媒体 CDN 提供高级 HTTP 路由功能，可让您以精细的级别将流量映射到特定的边缘配置和源。

配置路由规则

为媒体 CDN 服务配置路由规则。

控制台

在 Google Cloud 控制台中，前往 Media CDN 页面。

前往媒体 CDN
如需打开要为其配置路由规则的服务的详情页面，请点击相应服务名称。
如需切换到修改模式，请点击修改按钮。
如需前往路由部分，请点击下一步。
请至少指定一条主机规则。点击添加主机规则。然后，执行以下操作：
1. 对于主机，请指定至少一个用于匹配的主机。
2. 对于说明，请提供主机规则的简要说明。
或者，如需修改主机规则，请点击相应箭头将其展开。
请至少指定一条路由规则。点击添加路由规则。

或者，如需修改路线规则，请点击相应行中的修改。
在修改路由规则窗格中，为优先级设置路由优先级值。
在说明中，提供简短的说明，以便在规则列表中识别该规则。
在匹配部分中，指定至少一个匹配条件。点击添加匹配条件。之后，执行以下操作：
1. 对于匹配类型，选择任意路径匹配选项。
2. 在路径匹配字段中，指定名称、路径或模板。考虑使用通配符模式匹配。
  
  如果需要，还可以选择对路径值区分大小写。
3. 可选：选择标头匹配和查询参数匹配。然后，点击相关按钮以添加标头和查询参数。为每个规则指定名称、匹配类型和值。
  
  如需了解详情，请参阅根据标头和查询参数进行匹配。
4. 如需保存匹配条件，请点击完成。
对于主要操作，选择以下选项之一：
- 从来源提取：如需将请求定向到特定来源，请选择此选项，然后选择一个来源。
- 网址重定向：如需重定向请求，请选择此选项。然后，指定重定向类型、路径和状态代码。
  
  您可以选择将所有响应重定向到 HTTPS 或剥离查询。
点击高级配置。
1. 在标头操作部分中，点击添加内容。
  
  选择一种操作类型，然后以名称-值对的形式指定标头。接着，点击完成。
2. 在路由操作部分中，点击添加内容。
  
  指定操作类型及其相关选项。接着，点击完成。
对于 HTTP 方法过滤，请选择自定义 HTTP 方法过滤。

然后，选择要代理到源的 HTTP 方法。
如需保存路由规则，请点击保存。
如需保存对服务的更改，请点击更新服务。

gcloud 和 YAML

将 Media CDN 配置导出到 YAML 文件中。使用 gcloud edge-cache services export 命令。
```
gcloud edge-cache services export SERVICE_NAME \
    --destination=FILENAME.yaml
```
替换以下内容：
- SERVICE_NAME：服务的名称
- FILENAME：您的 YAML 文件的名称
按照本页各部分中的说明，使用所需的配置更新 YAML 文件。
如需更新服务，请从 YAML 文件导入 Media CDN 配置。使用 gcloud edge-cache services import 命令。
```
gcloud edge-cache services import SERVICE_NAME \
    --source=FILENAME.yaml
```

匹配请求

媒体 CDN 配置包含一组在 EdgeCacheService 资源的路由部分中定义的路由。这些路由至少会根据主机来匹配请求。如需详细了解流量如何定向到源，请参阅 HostRule 和 PathMatcher。每条路由都可以定义自己的 CDN 配置、重写、重定向、CORS 政策、自定义 HTTP 标头和源映射。路线可以共用起点。

例如，您可以将清单请求路由到特定源站，并定义短效缓存 TTL 和负缓存政策。可以使用标头和查询参数将细分请求拆分到其他来源，以分离出特定的清单类型或用户。

以下示例展示了如何为主机 media.example.com 路由与特定标头、查询参数和路径前缀匹配的请求：

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 10
      origin: staging-live-origin
      matchRules:
      - prefixMatch: /vod/
        headerMatches:
        - headerName: "x-staging-client"
          presentMatch: true
        queryParameterMatches:
        - name: "live"
          exactMatch: "yes"
      routeAction:
        cdnPolicy:
          defaultTtl: 5s

路径匹配

媒体 CDN 支持完整（完全）、前缀和通配符路径匹配。路径匹配可以与基于主机、标头和查询参数的匹配相结合，以构建精细的请求路由规则。

以下是三种匹配网址路径的方法。

字段说明示例

字段	说明	示例
`matchRules[].fullPathMatch`	`fullPathMatch` 条件会匹配完整的网址路径，但不包括查询字符串。如果适用，您必须指定尾部斜杠。	匹配规则为 `fullPathMatch: "/stream/"` 的路由匹配 `/stream/`，但不匹配 `/stream` 或 `/stream/us/hls/1234.ts`。 `fullPathMatch` 表示显式（完全）匹配。
`matchRules[].prefixMatch`	`prefixMatch` 条件匹配网址路径前缀；以相同字符串开头的网址会匹配。	匹配规则为 `prefixMatch: "/videos/"` 的路由同时匹配 `/videos/hls/58481314/manifest.m3u8` 和 `/videos/dash`，因为它们都包含 `/videos/` 前缀。
`matchRules[].pathTemplateMatch`	`pathTemplateMatch` 条件支持通配符运算符，可用于匹配复杂的网址格式和路径段，以及捕获用于重写网址的命名变量。	匹配规则为 `pathTemplateMatch: "/**.m3u8"` 的路由会匹配以 `.m3u8` 结尾的任何网址路径。 `/content/en-GB/13/51491/manifest_193193.m3u8` 和 `/p/abc/1234/manifest_1080p5000.m3u8` 都符合此模式。如需查看更多示例，请参阅模式匹配部分。

matchRules[].fullPathMatch

fullPathMatch 条件会匹配完整的网址路径，但不包括查询字符串。如果适用，您必须指定尾部斜杠。

匹配规则为 fullPathMatch: "/stream/" 的路由匹配 /stream/，但不匹配 /stream 或 /stream/us/hls/1234.ts。

fullPathMatch 表示显式（完全）匹配。

matchRules[].prefixMatch

prefixMatch 条件匹配网址路径前缀；以相同字符串开头的网址会匹配。

匹配规则为 prefixMatch: "/videos/" 的路由同时匹配 /videos/hls/58481314/manifest.m3u8 和 /videos/dash，因为它们都包含 /videos/ 前缀。

matchRules[].pathTemplateMatch

pathTemplateMatch 条件支持通配符运算符，可用于匹配复杂的网址格式和路径段，以及捕获用于重写网址的命名变量。

匹配规则为 pathTemplateMatch: "/**.m3u8" 的路由会匹配以 .m3u8 结尾的任何网址路径。

/content/en-GB/13/51491/manifest_193193.m3u8 和 /p/abc/1234/manifest_1080p5000.m3u8 都符合此模式。

如需查看更多示例，请参阅模式匹配部分。

如需了解详情，请参阅 MatchRule 的 API 规范。

例如，如需匹配以 /stream/ 开头的所有请求，请创建类似于以下内容的路由规则：

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    - *.vod.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      matchRules:
      - prefixMatch: /stream/

此示例在匹配规则中明确包含尾部斜杠：

对 media.example.com/stream/id/1234/hls/manifest.m3u8 的请求与此路由匹配。
对 media.example.com/stream-eu/id/4567/hls/manifest.m3u8 的请求与此路由不匹配。

在第二种情况下，除非配置了其他路由或全能路由，否则媒体 CDN 会返回 HTTP 404 错误。

如需了解具有相似前缀的路由的优先顺序，请参阅路由优先级和排序部分。

模式（通配符）匹配

借助格式匹配，您可以使用通配符语法来匹配网址的多个部分，包括部分网址和后缀（文件扩展名）。

您还可以在 pathTemplateMatch 字段中将一个或多个路径段与命名变量相关联，然后在 pathTemplateRewrite 字段中重写网址时引用这些变量。这样一来，您就可以在将请求发送到来源之前对网址段重新排序和移除。

以下示例展示了如何匹配两个不同的网址后缀：

# EdgeCacheService.routing.pathMatchers[]
    routeRules:
    - priority: 1
      description: "Match video segments"
      matchRules:
      - pathTemplateMatch: "/**.ts"
      - pathTemplateMatch: "/**.m4s"
      origin: prod-video-storage

支持的语法包括以下内容。

运算符	Matches	示例
`*`	匹配单个路径段，直至下一个路径分隔符：`/`	`/videos///*.m4s` 与 `/videos/123414/hls/1080p5000_00001.m4s` 匹配。
`**`	匹配零个或多个路径段。如果存在，则必须是最后一个运算符。	`/**.mpd` 与 `/content/123/india/dash/55/manifest.mpd` 匹配。
`{name} or {name=*}`	与一个路径段匹配的命名变量。匹配单个路径段，直至下一个路径分隔符： `/`。	`/content/{format}/{lang}/{id}/{file}.vtt` 匹配 `/content/hls/en-us/12345/en_193913.vtt` 并将 `format="hls"`、`lang="en-us"`、`id="12345"` 和 `file="en_193913"` 捕获为变量。
`{name=videos/*}`	与多个路径段匹配的命名变量。与 `videos/*` 匹配的路径段会捕获为命名变量。	`/videos/{language=lang/}/` 与 `/videos/lang/en/video.m4s` 匹配，并使用值 `lang/en` 填充路径变量 `language`。
`{name=**}`	与零个或零个以上路径段匹配的命名变量。如果存在，则必须是最后一个运算符。	`/.m3u8` 或 `/{path=}.m3u8` 匹配扩展名之前的所有路径段。 `/videos/{file=**}` 匹配 `/videos/en-GB/def566/manifest.m3u8`（包括扩展名），并捕获路径变量 `file="en-GB/def566/manifest.m3u8`。

注意：

如果您不重写网址，请使用更简单的 * 和 ** 运算符。
使用变量捕获路径段时，未被变量捕获的网址部分无法在后续的 pathTemplateRewrite 中引用。如需查看示例，请参阅捕获路径变量部分。
您无法在后续 pathTemplateRewrite 中引用同一路线上的 pathTemplateMatch 中不存在的变量。
变量区分大小写，其中{FORMAT}、{forMAT}和{format}表示不同的变量和值。
您可以在匹配中指定最多 10 个运算符（通配符或变量）。 pathTemplateMatch 和 pathTemplateRewrite 字段不得超过 255 个字符。

示例：针对文件扩展名进行匹配

以下示例展示了通配符运算符的常见用例：匹配直至后缀的所有路径段。

在这种情况下，您需要执行以下操作：

从清单来源提取以 .m3u8 和 .mpd 结尾的视频清单（播放列表），并对这些响应应用较短的 TTL（5 秒），因为它们会定期更改。
从片段源站提取以 .ts 和 .m4s 结尾的视频片段，并对这些响应应用更长的 TTL（1 天）。

使用 SSAI（服务器端广告注入）或 DAI（动态广告插播）服务时，以及对于每隔几秒更新清单的直播视频，通常会采用这种方法。

以下配置展示了如何配置 Media CDN 路由以支持此功能：

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    # the first route only matches video manifests
    - priority: 1
      matchRules:
      - pathTemplateMatch: "/**.m3u8" # "**" matches all path segments
      - pathTemplateMatch: "/**.mpd"
      origin: manifest-origin
      routeAction:
        cdnPolicy:
          cacheMode: FORCE_CACHE_ALL
          defaultTtl: 5s
    # the second route matches video segments, fetches them
    # from a separate origin server, caching them for a longer
    # duration (1 day).
    - priority: 2
      matchRules:
      - pathTemplateMatch: "/**.ts"
      - pathTemplateMatch: "/**.m4s"
      origin: segment-origin
      routeAction:
        cdnPolicy:
          cacheMode: FORCE_CACHE_ALL
          defaultTtl: 86400s

示例：捕获路径变量

以下示例展示了如何使用命名变量来描述一个或多个路径段。

这些变量可用于 pathTemplateRewrite 中，以在请求发送到来源之前重写路径，或使复杂的 pathTemplateMatch 具有自描述性。

routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      matchRules:
      # Matches a request of "/us/en/hls/123139139/segments/00001.ts"
      - pathTemplateMatch: "/{country}/{lang}/{format}/{id}/{file=**}"
      origin: my-origin
      routeAction:
        urlRewrite:
          # Rewrites to "/123139139/hls/segments/00001.ts"
          pathTemplateRewrite: "/{id}/{format}/{file}"

具体而言：

每个 {name} 变量捕获一个路径段。路径段是指网址路径中一对 /（“斜杠”）之间的所有字符。
变量 {name=**} 会捕获所有剩余的路径段；在本例中，它会同时匹配 segments/00001.ts 和 master.m3u8。
在 pathTemplateRewrite 同一路线中，您会回过头来引用在 pathTemplateMatch 中捕获的某些变量。您明确省略了 {country} 和 {lang} 变量，因为它们与来源上的目录结构不匹配。

在此示例中，会发生以下情况：

传入的请求网址 /us/en/hls/123139139/segment_00001.ts 与 pathTemplateMatch 相匹配，在发送到来源之前被重写为 /123139139/hls/segment_00001.ts。
传入的请求网址 /us/123139139/master.m3u8 与 pathTemplateMatch 不匹配，并收到 HTTP 404 (Not Found) 状态代码。
传入的请求网址 /br/es/dash/c966cbbe6ae3/subtitle_00001.vtt 也与 pathTemplateMatch 匹配，并且在发送到来源之前重写为 /c966cbbe6ae3/dash/subtitle_00001.vtt。

如需详细了解通配符匹配如何与网址重写协同运作，请参阅重写部分。

主机匹配

每个服务都可以匹配多个主机名，每组主机名都包含自己的路由组（称为路径匹配器）。在最常见的情况下，服务的所有主机名都映射到一组共享路由，其中包含一个主机列表和一个路径匹配器。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    - *.vod.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    # list of routes for the configured hosts
    - priority: 999
      matchRules:
      - prefixMatch: /
      origin: DEFAULT_ORIGIN

不匹配的主机将收到默认的 HTTP 404 网页。如需接受任何主机，您可以添加通配符 * 作为 hostRules[].hosts[] 条目。

您还可以定义一组路线（例如，按国家/地区或直播与点播进行分组）。由于每项服务都只有一项安全政策，因此我们通常建议您为每个市场（地理位置）或工作负载设置一项服务。

注意：

包含端口的主机（或 HTTP/2 :authority）标头会隐式与配置的主机进行匹配。您无需明确指定端口。
如果请求是通过 HTTP 发出的，则 hostRules[].hosts[] 条目 *.vod.example.com 会与 us.vod.example.com 和 us.vod.example.com:80 匹配。
如果请求是通过 HTTPS (TLS) 发出的，则 hostRules[].hosts[] 条目的 *.vod.example.com 与 us.vod.example.com:443 相匹配。

如需了解详情，请参阅 HostRule 的 API 规范。

根据标头和查询参数进行匹配

您可以配置路由，以匹配特定的标头和查询参数名称，以及标头值的存在情况（前缀、后缀或完全匹配）。

查询参数和标头匹配是逻辑“AND”运算，即请求必须与所有查询参数和标头键（以及值，如果指定）匹配，才能与给定的路由匹配。

例如，如果您想将具有特定标头字段名称和标头值的请求路由到名为 alternate-origin 的源，请在 routeRules[].matchRules[].headerMatches[] 中配置匹配条件：

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      origin: alternate-origin
      matchRules:
      - prefixMatch: "/videos/"
        headerMatches:
        - headerName: "x-device-name"
          exactMatch: "roku"

在此示例中，以 /videos/ 开头的网址和 x-device-name: roku 标头的请求与此路由匹配。缺少此标头名称或具有不同值的请求与此路由不匹配。

如需了解详情，请参阅 HeaderMatch 的 API 规范。

同样，如需匹配查询参数，请指定一个或多个 queryParameterMatches，如下所示：

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      origin: eu-live-origin-prod
      matchRules:
      - prefixMatch: "/videos/"
        queryParameterMatches:
        - name: "playback_type"
          exactMatch: "live"
        - name: "geo"
          exactMatch: "eu"

在此示例中，客户端请求 https://cdn.example.com/videos/1234/abcd/xyz.m3u8?playback_type=live&geo=eu 与此路由匹配。

如需了解详情，请参阅 QueryParameterMatcher 的 API 规范。

定义一个全能（默认）路由

默认情况下，如果请求与任何已配置的路由都不匹配，媒体 CDN 会返回 HTTP 404 (Not Found) 错误。

如需为给定的 pathMatcher（路由集合）配置全能路由，请执行以下操作：

创建优先级最低（数字最高）的 routeRule，例如 999，这是可能的最低路由优先级。
配置一个 matchRule，其前缀匹配值为 /（匹配所有请求路径）。
在路线上配置 origin 或 urlRedirect（之一）。

例如，如需配置一个无限别名地址路由，将所有不匹配的请求定向到名为 my-origin 的默认来源，请创建一个新路由，其中包含 priority: 999 和值为 / 的 matchRules[].prefixMatch，如下所示：

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 999
      origin: my-origin
      matchRules:
      - prefixMatch: /

您可以选择在提取来源之前重写网址，也可以重定向到默认网页（例如着陆页），而不是“按原样”将请求发送到来源。

路由优先级和排序

routeRules[] 数组中的每个路由都必须具有与之关联的 priority。

应将更具体的路由设置为更高的优先级（数值更小）。匹配前缀 /stream/ 的路由的优先级为 1，否则会阻止优先级为 5 的更具体的路由 /stream/live/eu/ 匹配任何请求。

最高优先级路由为“1”，最低优先级路由为“999”。
您无法配置两条或更多具有相同优先级的 routeRule。每条规则的优先级必须设置为 1 到 999（含）之间的数字。
通过定义全能路由，您可以将所有不匹配的请求发送到默认来源，或将这些请求重定向到着陆页或端点。

在以下示例中，您可以看到 /live/us/ 路由永远不会匹配，因为 /live/ 路由的优先级更高：

routeRules:
- priority: 1
  description: "Live routes"
  matchRules:
  - prefixMatch: /live/
  routeAction:
    cdnPolicy:
      defaultTtl: 5s
- priority: 2
  description: "U.S based live streams"
  matchRules:
  # This would never be matched, as the /live/ prefixMatch at priority 1
  # would always take precedence.
  - prefixMatch: /live/us/
  routeAction:
    cdnPolicy:
      defaultTtl: 5s
- priority: 999
  description: "Catch-all route"
  matchRules:
  - prefixMatch: /

为解决此问题，您可以将更具体（更长）的路由设置为更高的优先级：

routeRules:
- priority: 1
  description: "U.S based live streams"
  matchRules:
  # The more specific (longer) match is at a higher priority, and now
  # matches requests as expected.
  - prefixMatch: /live/us/
  routeAction:
    cdnPolicy:
      defaultTtl: 5s
- priority: 2
  description: "Live routes"
  matchRules:
  - prefixMatch: /live/
  routeAction:
    cdnPolicy:
      defaultTtl: 5s
- priority: 999
  description: "Catch-all route"
  matchRules:
  - prefixMatch: /

这样，更具体的路由就能正确匹配请求。以 /live/eu/ 为前缀的请求仍会以优先级 2 传递到 /live/ 路由。

方法过滤

默认情况下，媒体 CDN 仅使用代理将 GET、HEAD 和 OPTIONS 方法转发到您的来源，并过滤掉可能会修改来源的方法。

您可以指定要代理到源站的方法，从而针对特定路由规则替换此默认行为。除了 GET、HEAD 和 OPTIONS 之外，媒体 CDN 还支持 PUT、POST、DELETE 和 PATCH。

媒体 CDN 仅针对使用较安全的 HTTP 方法（例如 GET、HEAD 或 OPTIONS）的请求重试或尝试故障切换。

如需为路由规则配置对一组方法的支持，请指定一个 routeMethods 部分，其中包含每个方法的 allowed_methods 值。

routeRules:
- priority: 5
  description: "Video uploads"
  routeMethods:
    allowedMethods: ["PUT", "POST", "OPTIONS"]
  matchRules:
  - pathTemplateMatch: "/uploads/**.ts"
  origin: prod-video-storage
- priority: 10
  description: "Video serving"
  routeMethods:
    allowedMethods: ["GET", "HEAD"]
  matchRules:
  - pathTemplateMatch: "/videos/**.ts"
  origin: prod-video-storage

路径规范化

路径规范化描述了在特定场景下，Media CDN 如何将网址的多种表示形式合并为一种规范表示形式。

路径规范化可以直接提高缓存命中率，方法是减少表示相同内容的请求网址数量，并针对需要规范化路径的源站缓解源站错误。

传入请求会按以下方式进行标准化处理：

多个连续斜杠会合并为一个斜杠。例如，网址路径 /videos///12345/manifest.mpd 会规范化为 /videos/12345/manifest.mpd。
路径段会根据 RFC 3986 第 6.2.2.3 节进行规范化。例如，根据 RFC 3986 中定义的“移除点段”算法，路径 /a/b/c/./../../g 会标准化为 /a/g。此规范化操作会在检查缓存或将请求转发到源之前进行。
请求不进行百分比编码。例如，采用百分号编码的斜杠字符 (%2F) 的网址不会解码为未编码的形式。

网址仍然区分大小写，并且不会进行大小写规范化。许多网址都包含区分大小写的 base64 编码，包括带有签名请求令牌的网址。

重写和重定向

以下部分提供了有关如何重写请求和配置重定向的示例。

重写请求网址

媒体 CDN 支持主机和路径重写。重写会更改发送到源的网址，并允许您根据需要修改主机和路径。主机和路径重写位于路由级别，可让您根据任何匹配器（包括路径、查询参数和请求标头）定义要重写的特定请求。

如需了解详情，请参阅 RouteAction.UrlRewrite 的 API 规范。

以下是重写请求的三种方式：

字段说明

字段	说明
`urlRewrite.pathPrefixRewrite`	重写路径，移除与请求匹配的 `prefixMatch` 中指定的前缀。在单个路由规则中，只能指定 `pathPrefixRewrite` 或 `pathTemplateRewrite` 中的一个。
`urlRewrite.pathTemplateRewrite`	`pathTemplateRewrite` 只能与同一路由上的相应 `pathTemplateMatch` 匹配规则搭配使用。在单个路由规则中，只能指定 `pathPrefixRewrite` 或 `pathTemplateRewrite` 中的一个。
`urlRewrite.hostRewrite`	在将请求发送到源服务器之前重写主机。

urlRewrite.pathPrefixRewrite

重写路径，移除与请求匹配的 prefixMatch 中指定的前缀。

在单个路由规则中，只能指定 pathPrefixRewrite 或 pathTemplateRewrite 中的一个。

urlRewrite.pathTemplateRewrite

pathTemplateRewrite 只能与同一路由上的相应 pathTemplateMatch 匹配规则搭配使用。

在单个路由规则中，只能指定 pathPrefixRewrite 或 pathTemplateRewrite 中的一个。

urlRewrite.hostRewrite 在将请求发送到源服务器之前重写主机。

注意：

重写的网址不会更改缓存键。缓存键基于客户端发送的请求网址。
重写发生在路由匹配和签名请求验证之后。不会根据其他匹配规则重新匹配路线。

示例：移除路径前缀

例如，如需将客户端请求网址从 /vod/videos/hls/1234/abc.ts 重写为 /videos/hls/1234/abc.ts（从路径中移除 /vod），您可以使用 pathPrefixRewrite 功能：

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      origin: my-origin
      matchRules:
      - prefixMatch: "/vod/videos/"
      routeAction:
        urlRewrite:
          pathPrefixRewrite: "/videos/"

pathPrefixRewrite 的工作方式是将 matchRules[].prefixMatch 中匹配的整个路径前缀替换为 pathPrefixRewrite 的值。

如需重写主机名（例如，将 cdn.example.com 重写为 my-bucket.s3.us-west-2.amazonaws.com），您可以配置以下内容：

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      origin: my-origin
      matchRules:
      - prefixMatch: "/videos/"
      routeAction:
        urlRewrite:
          hostRewrite: "my-bucket.s3.us-west-2.amazonaws.com"

在这种情况下，原始请求网址会从 cdn.example.com/videos/* 更改为 my-bucket.s3.us-west-2.amazonaws.com/videos/*。您还可以在单个路由中同时组合使用主机重写和路径重写。

示例：使用变量重写网址

如需使用 pathTemplateMatch 和 pathTemplateRewrite 重写传入请求网址的部分内容，请参阅捕获变量部分。

重定向请求

媒体 CDN 支持以下三种类型的重定向：

主机重定向，仅重定向主机（网域），保持路径和查询参数不变。
路径重定向，用于完全替换路径。
路径前缀重定向，仅替换匹配的前缀。

重定向默认使用 HTTP 301 (Moved Permanently)，但可以配置为按路由返回不同的重定向状态代码。

以下配置是一个基于前缀的重定向示例，其中将访问 https://cdn.example.com/on-demand/* 的用户重定向到 https://cdn.example.com/streaming/*。

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 10
      matchRules:
      - prefixMatch: "/on-demand/"
      urlRedirect:
        # The prefix matched in matchRules.prefixMatch is replaced
        # by this value
        prefixRedirect: "/streaming/"
        redirectResponseCode: TEMPORARY_REDIRECT # corresponds to a HTTP 307

此示例还将重定向更改为临时重定向，以防止客户端（例如浏览器）缓存该重定向。如果您预计在不久的将来会更改此设置，那么此功能会非常有用。

下表显示了支持的 redirectResponseCode 值。

重定向响应代码	HTTP 状态代码
`MOVED_PERMANENTLY_DEFAULT`	HTTP 301（永久移动）
`FOUND`	HTTP 302（已找到）
`SEE_OTHER`	HTTP 303（查看其他）
`TEMPORARY_REDIRECT`	HTTP 307（临时重定向）
`PERMANENT_REDIRECT`	HTTP 308（永久重定向）

注意：

路由可以将流量直接引导至来源，也可以向客户端返回重定向。您不能同时设置 origin 和 urlRedirect 字段。
重定向到 HTTPS 的路由要求至少有一个 SSL 证书附加到服务。

如需了解详情，请参阅 RouteRule.UrlRedirect 的 API 规范。

将所有请求重定向到 HTTPS

如需将所有请求重定向到 HTTPS（而非 HTTP），您可以将每个服务配置为自动将所有客户端请求重定向到 HTTPS。通过 HTTP 连接的客户端会收到 HTTP 301 (Permanent Redirect) 状态代码，其中 Location 标头设置为同一网址，但使用“https://”而不是“http://”。

gcloud

gcloud edge-cache services update MY_SERVICE \
    --require-tls

Request issued for: [MY_SERVICE]
Updated service [MY_SERVICE].

该命令会返回服务说明，其中 requireTls 现在设置为 true。

  name: MY_SERVICE
  requireTls: true

您还可以选择将 Strict-Transport-Security 标头设置为响应标头，以指示客户端始终通过 HTTPS 直接连接。

使用第三方存储后端

Media CDN 支持连接到 Google Cloud之外可公开访问的 HTTP 端点，包括 AWS S3 存储分区、Azure Blob 存储和其他存储提供商。如果您采用多云架构，或者尚未使用 Storage Transfer Service 将数据迁移到 Cloud Storage，此功能会非常有用。

以下是一个最低限度的源配置，用于在 AWS S3 中配置虚拟托管的存储桶：

name: MY_S3_ORIGIN
originAddress: BUCKET-NAME.s3.REGION.amazonaws.com

如果您使用的存储桶名称与为 EdgeCacheService 资源配置的主机名不匹配，则还必须为与此来源（或多个来源）关联的路由配置主机重写。否则，从源站提取内容时，系统会使用客户端请求设置的 Host 标头。

例如，如需将路径前缀为 /legacy/ 的所有请求映射到外部存储桶，您可以同时配置 hostRewrite 和 pathPrefixRewrite，以从原始请求中剥离此路径前缀：

routeRules:
  - description: legacy backend
    matchRules:
    - prefixMatch: "/legacy/"
    routeAction:
      urlRewrite:
        hostRewrite: BUCKET-NAME.s3.REGION.amazonaws.com
        pathPrefixRewrite: /
      cdnPolicy:
        cacheMode: CACHE_ALL_STATIC
        defaultTtl: 3600s

如需详细了解如何在源请求中设置 Host 标头，请参阅源请求标头文档。

跨源资源共享 (CORS)

跨源资源共享 (CORS) 是一种以浏览器为中心的方法，可用于安全地发出跨源请求。借助 CORS 政策，您可以根据每条路由的政策自动设置 CORS 标头，例如 Access-Control-Allow-Origins。

配置 CORS

借助媒体 CDN，您可以在 EdgeCacheService 的路由上定义 CORS 政策。

CORS 政策通过一组通用的 HTTP 标头来定义这些规则。您可以在响应中设置常见的 CORS 标头，例如 Access-Control-Allow-Origin、Access-Control-Max-Age 和 Access-Control-Allow-Headers。借助这些标头，您可以对 Media CDN 服务进行跨源调用，这些服务可能托管在与网站前端不同的网域（来源）中，并且可能会阻止您未明确允许的跨源请求。

例如，player.example.com 和 api.example.com 是不同的来源（在浏览器意义上），您可能希望前端应用向 api.example.com 发出请求，以获取下一个播放列表或刷新相关内容的列表。同样，player.example.com可能需要与 cdn.example.com 联系以获取视频播放列表和视频片段：cdn.example.com需要表明这是可以的，并且player.example.com是 allowed origin，以及任何其他规则（允许的标头、是否可以包含 Cookie）。

再举一个例子，如果您想允许 stream.example.com 作为来源，并在 CORS 请求中允许 X-Client-ID 标头，则可以在路由上配置 corsPolicy，如下所示：

corsPolicy: maxAge: 600 allowOrigins: ["stream.example.com"] allowHeaders:
["X-Client-ID"]

在 EdgeCacheService 内，corsPolicy 配置在 routing.pathMatchers[].routeRules[].routeAction.corsPolicy。每个 routeRule 都可以根据需要定义不同的 corsPolicy，也可以完全不定义。

如果您定义了 corsPolicy 值，并且还通过使用具有相同名称的路由上的 responseHeadersToAdd 字段设置了自定义响应标头，则自定义响应标头优先于 corsPolicy 值，并会取代 corsPolicy 值。

如果源响应设置了 HTTP 标头，并且您设置了 corsPolicy 值，则系统会改用 corsPolicy 值。这些值不会折叠或合并，以避免向客户端发送无效的标头值，或无意中设置比预期更宽松的政策。

特殊 {origin_request_header} 会填充客户端请求中的 Origin HTTP 标头。可以将其设置为路由上 Access-Control-Allow-Origin 标头的自定义响应标头值。

如需了解详情，请参阅 RouteAction.CORSPolicy 的 API 规范。

CORS 政策字段

下表介绍了 CORS 政策包含的字段。

字段	说明	示例
allowOrigins	设置 `Access-Control-Allow-Origins` 响应标头，用于指定哪些来源可以在浏览器环境中发出跨源请求。例如，如果您的视频内容是从 `https://video.example.com` 提供的，但面向用户的门户是从 `https://stream.example.com` 提供的，则您需要将 `https://stream.example.com` 添加为允许的来源。	`Access-Control-Allow-Origins: https://stream.example.com`
maxAge	设置 `Access-Control-Max-Age` 响应标头，该标头用于指定浏览器客户端应将 CORS 预检请求的响应缓存多长时间（以秒为单位）。即使指定了最大值 (86400 秒)，某些浏览器也会将此值限制为 2 小时或更短。	`Access-Control-Max-Age: 7200`
allowMethods	设置 `Access-Control-Allow-Methods` 响应标头，用于指定允许哪些 HTTP 方法访问资源。默认情况下，Media CDN 仅支持 `GET`、`HEAD` 和 `OPTIONS` 方法。如需配置对其他方法的支持，请参阅路由方法。	`Access-Control-Allow-Methods: GET, OPTIONS, HEAD`
allowHeaders	设置 `Access-Control-Allow-Headers` 标头，该标头用于确定可以在 CORS 请求中发送哪些标头。视频播放器通常需要这样做，因为在跨源请求视频内容时，它们需要访问一些响应标头。	`Access-Control-Allow-Headers: Content-Type, If-Modified-Since, Range, User-Agent`
exposeHeaders	设置 `Access-Control-Expose-Headers` 响应标头，该标头用于确定客户端 JavaScript 可以访问哪些标头。视频播放器通常需要这样做，因为在跨源请求内容时，视频播放器可能需要访问视频内容的特定响应标头。	`Access-Control-Expose-Headers: Date, Cache-Status, Content-Type, Content-Length`
allowCredentials	设置 `Access-Control-Allow-Credentials` 响应标头，该标头允许客户端 JavaScript 检查包含凭据的请求的响应。如果设置为 false，则会省略此标头。	`Access-Control-Allow-Credentials: true`
disabled	停用 `corsPolicy`，但不移除它。飞行前 `OPTIONS` 请求会代理到来源。	不适用

corsPolicy 示例

以下配置示例展示了基本的 corsPolicy 配置：

routeRules:
- priority: 1
  matchRules:
  - prefixMatch: /stream/
  routeAction:
    cdnPolicy:
      defaultTtl: 3600s
    corsPolicy:
      allowOrigins:
      - "https://stream.example.com"
      - "https://stream-staging.example.com"
      maxAge: 86400s # some browsers might only honor up to 7200s or less
      allowMethods:
      - "GET"
      - "HEAD"
      - "OPTIONS"
      allowHeaders:
      - "Content-Type"
      - "If-Modified-Since"
      - "Range"
      - "User-Agent"
      exposeHeaders:
      - "Content-Type"
      - "Content-Length"
      - "Date"

排查转送问题

如果某些请求未检索到匹配的结果或返回错误，请检查以下各项：

路线必须具有 matchRule，且其中只能定义 prefixMatch、fullPathMatch 或 pathTemplateMatch 中的一个。如果您未添加其中一个字段，该 API 会返回错误。
确保每条路由的 priority 设置正确：较具体（较长）的路由应优先于较短、较宽泛的路由匹配。
默认情况下，仅支持 GET、HEAD 和 OPTIONS 请求。如需配置对其他方法的支持，请参阅路由方法。对于未针对特定路由启用的方法，系统会拒绝并返回 HTTP 405 (Method Not Allowed) 错误。
包含正文的 HTTP GET 请求或包含尾部的任何请求都会被拒绝，并返回 HTTP 400 错误，因为 GET 请求中不允许包含请求正文。
查询参数和标头匹配是逻辑“AND”运算，即请求必须与所有查询参数或标头键（以及值，如果指定了）匹配，才能与给定的路由匹配。

后续步骤

查看有关配置缓存的文档。
了解如何连接到不同的来源。
为您的服务设置 TLS (SSL) 证书。
配置已签名请求，以对内容访问进行身份验证。
如需详细了解如何使用 Terraform 配置 EdgeCacheService 资源，请参阅 Terraform 注册表文档。