此页面由 Cloud Translation API 翻译。

配置服务路由

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

匹配请求数

媒体 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.

例如，如需匹配以 /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

支持的语法包括：

运算符	会匹配出的结果	示例
`*`	匹配单个路径组成部分，直到下一个路径分隔符：`/`	`/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`，并填充路径变量 `language`，值为 `lang/en`。
`{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 结尾的视频清单（播放列表）：清单来源，向这些响应应用一个较短（5 秒）的 TTL，因为它们会定期更改
从片段来源提取以 .ts 和 .m4s 结尾的视频片段；以及为这些响应应用较长的（1 天）TTL。

在使用 SSAI（服务器端广告注入）或 DAI（动态广告插播）服务，以及清单每隔几秒钟更新一次。

以下配置演示了如何配置为支持此功能的媒体 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.

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

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

查询参数和标头匹配采用逻辑“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 个标头与此路线匹配。缺少此标头的请求或其他值与此路由不匹配。

priority

有关详情，请参阅 HeaderMatch.

同样，要匹配查询参数，请指定一个或多个 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.

定义无限别名（默认）路由

默认情况下，媒体 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 的路由，则会阻止 /stream/live/eu/（优先级为 5）的更具体的路由，无法与任何路由匹配请求。

最高优先级路由为“1”，最低优先级为“999”。
您不能配置两个或更多个具有相同优先级的 routeRule。优先级设为 1 到 999 之间的数字（含 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/ 时，仍可连接到 /live/ 路由，优先级 2。

方法过滤

默认情况下，媒体 CDN 仅代理 GET、HEAD 和 OPTIONS 方法，并过滤掉可以修改源的方法。

在预览中，您可以替换此默认设置特定路由规则的行为方式，例如通过代理转发到您的源除了GET、HEAD和OPTIONS之外，媒体 CDN 支持 PUT、POST、DELETE 和 PATCH。

要为路由规则配置对一组方法的支持，请指定 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

在预览版中，媒体 CDN 允许更新和查看 v1alpha1 Network Services API 进行配置。或者，您也可以使用 gcloud alpha edge-cache services export 命令和 gcloud alpha edge-cache services import 命令更新您的服务配置 YAML 文件。

路径归一化

路径标准化描述了媒体 CDN 如何将多个以单一、规范化的表示法表示，场景。

路径标准化可以减少同时减少来源错误。

传入请求将按以下方式进行标准化：

多个连续斜杠会合并为一个斜杠。例如， /videos///12345/manifest.mpd 的网址路径标准化为 /videos/12345/manifest.mpd.
路径细分根据 RFC 3986 第 6.2.2.3 节。例如，根据以下规则，路径 /a/b/c/./../../g 已标准化为 /a/g 该 “移除点线段” RFC 3986 中定义的算法。这种标准化在检查缓存或将请求转发到源站。
请求未对百分比编码进行标准化。例如，包含百分号编码的斜杠字符 (%2F) 不会解码为未编码的表单。

网址区分大小写，并且不区分大小写。许多网址包含区分大小写的 base64 编码，包括带有签名请求令牌。

重写和重定向

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

重写请求网址

媒体 CDN 支持主机和路径重写。重写会改变发送到源站的网址，可让您根据需要修改主机和路径。托管和路径重写在路由级别，让您可以定义基于任何匹配器（包括路径、查询参数和请求）被重写标头。

有关详情，请参阅 RouteAction.UrlRewrite.

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

字段说明

字段	说明
`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 的工作原理是替换与值为 pathPrefixRewrite 的 matchRules[].prefixMatch。

如需重写主机名（例如，将 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.

将所有请求重定向到 HTTPS

要将所有请求重定向到 HTTPS（而不是 HTTP），您可以在将您的服务自动将所有客户端请求重定向到 HTTPS。客户系统会发送 HTTP 301 (Permanent Redirect) 响应和使用“https://”将 Location 标头设为同一网址而非“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

您还可以选择设置严格传输安全标头作为响应标头，以指示客户端始终直接通过 HTTPS。

使用第三方存储后端

媒体 CDN 支持连接到可公开访问的 HTTP Google Cloud 之外的端点，包括 AWS S3 存储分区、Azure Blob Storage 和其他存储提供程序。如果你有多云架构，或者尚未将数据迁移到 Cloud Storage 使用 Storage Transfer Service。

一个最低限度的来源配置，用于配置虚拟托管存储桶：

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

如果您使用的存储桶名称与为存储桶配置的主机名一致， EdgeCacheService 资源，您还必须为路由配置主机重写与此源（或这些源）关联的任意键。否则，由从源站提取时使用客户端请求。

例如，如需将路径前缀为 /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

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

跨源资源共享 (CORS)

跨源资源共享 (CORS) 是一种以浏览器为中心的方法，用于安全地发出跨源请求。 CORS 政策允许您自动设置 CORS 标头，如 Access-Control-Allow-Origins（基于每个路由的政策）。

配置 CORS

媒体 CDN 允许您为 EdgeCacheService.

CORS 政策使用一组常用的 HTTP 标头来定义这些规则。您可以在响应中设置常用的 CORS 标头，如 Access-Control-Allow-Origin、Access-Control-Max-Age、和 Access-Control-Allow-Headers。借助这些标头跨源调用可能造成了托管在与网站前端不同的网域（源）上，阻止未经您明确许可的跨源请求。

例如，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 作为来源和 X-Client-ID 标头，那么您可以在corsPolicy 具体如下：

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

corsPolicy配置为 routing.pathMatchers[].routeRules[].routeAction.corsPolicy内 EdgeCacheService.每个 routeRule 都可以将不同的 corsPolicy 定义为也可能根本不需要

如果您定义了 corsPolicy 值，还通过使用名称相同的路线上的 responseHeadersToAdd 字段，自定义响应标头的优先级高于并取代 corsPolicy 值。

如果源响应设置了 HTTP 标头，并且您设置了 corsPolicy 值则改用 corsPolicy 值。这些值未收起也可进行组合，以避免向客户端发送无效的标头值；无意中设置了比预期更宽松的政策。

特殊 {origin_request_header} 使用 Origin HTTP 标头填充。此字段可以设置为自定义响应标头值，对于 Access-Control-Allow-Origin 标头。

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

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 预检请求。有些浏览器会将时间限制在 2 小时或更短，即使指定最大值 (86400s)。	`Access-Control-Max-Age: 7200`
allowMethods	设置 `Access-Control-Allow-Methods` 响应标头。用于指定允许哪些 HTTP 方法访问资源。默认情况下，媒体 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) 证书服务。
配置签名请求以进行身份验证访问内容的权限。