跳转到内容
本站为社区维护的非官方中文翻译，与 Cloudflare, Inc. 无关联。本站不提供账户登录，请勿在任何非官方站点输入您的 Cloudflare 账户信息。官方文档：developers.cloudflare.com
CF 中文文档非官方翻译
搜索文档
↵选择
↑↓导航
ESC关闭

执行顺序

最后更新 查看 MarkdownAgent 设置

借助 Cloudflare Gateway，您可以启用和配置 DNS、网络和 HTTP 策略的任意组合。

执行流程图

flowchart TB
    %% Accessibility
    accTitle: Gateway 执行顺序
    accDescr: 描述 Gateway 策略执行顺序的流程图。HTTP 请求策略之后，第一条匹配的 Forward 策略会在请求体策略和检查之前调用 Worker。Gateway 会在将原始请求体交给 Worker 之前对其进行检查，来自请求体策略或检查的拦截决定可以中断 Worker。Gateway 会检查 Worker 返回的最终响应。

 subgraph Resolution["解析"]
        dns2["1.1.1.1"]
        dns4["自定义解析器"]
        dns3["解析器策略 <br>（仅限 Enterprise 用户）"]
        internal["内部 DNS"]
  end
 subgraph DNS["DNS"]
        dns1["DNS 策略"]
        Resolution
  end
 subgraph HTTP["HTTP 策略"]
        http1{{"“不检查”策略 (Do Not Inspect)"}}
        http2["“隔离”策略  <br>（带浏览器隔离附加组件）"]
        http3["HTTP 请求策略：允许、拦截、不扫描、隔离区和重定向"]
        forward["第一条匹配的 Forward 策略（Beta）（如有）"]
        worker["策略所选的 Worker"]
        body["请求体策略和检查：DLP、防病毒扫描和文件沙箱"]
        blocked["拦截响应"]
        https["HTTP 还是 HTTPS？"]
  end
 subgraph Proxy["代理"]
        HTTP
        network1["网络策略"]
        nonhttp["非 HTTP(S) 流量"]
  end
 subgraph Egress["出站 (Egress)"]
        egress1["出站策略 <br>（仅限 Enterprise 用户）"]
  end
    start(["流量"]) --> dns0[/"DNS 查询"/] & http0["网络连接"]
    dns0 ----> dns1
    dns1 -- 解析自 --> dns2
    dns1 --> dns3
    dns3 -- 解析自 --> dns4
    dns2 -----> internet(["互联网"])
    dns4 -----> internet
    dns4 ---> cloudflare["私有网络服务 <br>（Cloudflare Tunnel、Cloudflare WAN、Cloudflare Mesh）"]
    http1 -- 不检查 --> internet
    http1 -- 检查 --> http2
    http2 --> http3
    http0 --> magic["Cloudflare Network Firewall（仅限 Enterprise 用户）"]
    magic --> egress1
    egress1 --> timing{"是否为 Worker 推迟上游连接？"}
    timing -- 否 --> tcp["检查源站可用性 (TCP SYN)"]
    timing -- 是 --> network1
    tcp --> network1
    http3 -- 允许的请求 --> forward
    http3 -- 已拦截 --> blocked
    forward -- 匹配 --> worker
    forward -- 原始请求体 --> body
    body -- 已检查的请求体流，Forward 匹配 --> worker
    body -- 已拦截 --> blocked
    body -. 请求体拦截会中断 Worker .-> worker
    worker -- next，若已推迟则连接上游 --> internet
    body -- 无 Forward 匹配，若已推迟则连接上游 --> internet
    https -- HTTPS --> http1
    https -- HTTP --> http2
    network1 --> https & nonhttp
    dns3 -- 解析自 --> internal & dns2
    nonhttp -----> internet

    https@{ shape: hex}
    http0@{ shape: lean-r}

连接建立

对于 Gateway 未转发到 Worker 的流量，Gateway 首先与目标服务器在用户请求的端口上建立 TCP 连接。由于 TCP 流量由 Cloudflare 代理，因此 Gateway 与源站建立的连接独立于用户与 Gateway 建立的连接。这意味着 Gateway 会为用户的连接分配一个新的源 IP 和端口，且用户的 TCP 握手详情不会包含在与源站服务器的 TCP 握手中。

如果与目标服务器的 TCP 连接成功，Gateway 将应用策略。如果 Gateway 策略允许该连接，Gateway 将把用户连接到目标服务器。如果 Gateway 策略拦截了该连接，Gateway 将终止连接，并且不会在用户与目标服务器之间发送任何数据。如果与目标服务器的 TCP 连接不成功，Gateway 将不运行任何策略，并重试从用户到服务器的 TCP 连接。

对于通过 Forward 操作（Beta）调用的 Worker 所处理的请求，Gateway 会推迟原始上游连接，直到 Worker 调用 next()。如果 Worker 返回合成响应且未调用 next()，则不会将请求发送到源站。

以下流程图描述了 Gateway 未转发到 Worker 的连接：

flowchart TD
    %% Accessibility
    accTitle: Gateway 代理工作原理
    accDescr: 描述 Gateway 代理如何使用 Happy Eyeballs 算法建立 TCP 连接并代理用户流量的流程图。

    %% Flowchart
    A[用户的设备向 Gateway 发送 TCP SYN] --> B[Gateway 向源站服务器发送 TCP SYN]
    B --> C{{源站服务器响应 TCP SYN-ACK？}}
    C -->|是| E[TCP 握手完成]
    C -->|否| D[连接失败]
    E --> F{{是否允许连接？}}
    F -->|允许策略| G[Gateway 双向代理流量]
    F -->|拦截策略| H[连接被防火墙策略拦截]

    %% Styling
    style D stroke:#D50000
    style G stroke:#00C853
    style H stroke:#D50000

无论连接是否成功，与 Zero Trust 的连接都将始终显示在您的 Zero Trust 网络会话日志中。由于 Gateway 不会检查失败的连接，因此它们不会显示在您的 Gateway 活动日志中。

使用 Cloudflare Network Firewall 过滤 TCP SYN 数据包

对于 Gateway 未转发到 Worker 的流量，Gateway 会在评估策略之前向目标服务器发送 TCP SYN。因此，Gateway 网络或 HTTP 拦截策略不会阻止初始 TCP SYN 到达目标服务器。如果您需要阻止向特定目标 IP 地址发送 TCP SYN 数据包，您可以创建 Cloudflare Network Firewall 规则以在数据包级别拦截流量。如执行流程图所示，Cloudflare Network Firewall 会在 Gateway 检查源站可用性之前评估流量。

要拦截指向特定目标的 TCP SYN 数据包：

  1. 在 Cloudflare 仪表板 ↗中，转到 Zero Trust > Firewall policies（防火墙策略） > Custom policies（自定义策略）。
  2. 选择 Add a policy（添加策略）。
  3. 使用您要拦截的目标 IP 地址或 CIDR 范围创建一条规则。例如，要拦截指向 10.0.0.0/8 的所有流量，请使用表达式 ip.dst in {10.0.0.0/8}，并配合 Block（拦截） 操作。
  4. 选择 Add new policy（添加新策略）。

有关创建数据包过滤规则的更多信息，请参阅添加策略。

策略生成器之间的优先级

Gateway 按以下顺序应用您的策略：

  1. 在解析前评估选择器的 DNS 策略
  2. 解析器策略（如果适用）
  3. 在解析后评估选择器的 DNS 策略
  4. 出站策略（如果适用）
  5. 网络策略
  6. HTTP 策略

DNS 和解析器策略是独立的。例如，如果您通过 DNS 策略拦截了某个网站，但未创建相应的 HTTP 策略，则用户在知道其 IP 地址的情况下仍可访问该网站。

HTTP/3 流量

对于代理的 HTTP/3 流量，Gateway 按以下顺序应用您的策略：

  1. DNS 策略
  2. 网络策略
  3. HTTP 策略

策略生成器内的优先级

DNS 策略

Gateway 首先按照 DNS 解析的顺序评估 DNS 策略，然后按照优先顺序进行评估。

收到 DNS 查询时，Gateway 会评估具有解析前选择器的策略，解析 DNS 查询，然后评估具有解析后选择器的策略。这意味着在 DNS 解析之前评估选择器的策略具有优先权。例如，以下策略集将拦截 example.com：

优先级 选择器 运算符 值 操作
1 解析的国家/地区 IP 地理定位 is United States 允许
2 域 is example.com 拦截

尽管明确的“允许”策略排在第一位，但策略 2 具有优先权，因为 Domain（域）选择器在 DNS 解析之前进行评估。

如果策略同时包含解析前和解析后选择器，Gateway 将在 DNS 解析后评估整个策略。有关何时评估每个选择器的信息，请参阅 DNS 选择器列表。

网络策略

Gateway 按照优先顺序评估网络策略。

HTTP 策略

Gateway 根据操作类型和优先顺序的组合来应用 HTTP 策略：

  1. 首先评估所有“不检查 (Do Not Inspect)”策略，按优先顺序排列。
  2. 如果没有策略匹配，则按优先顺序评估所有“隔离 (Isolate)”策略。
  3. 按优先顺序评估所有“允许 (Allow)”、“拦截 (Block)”和“不扫描 (Do Not Scan)”策略。
  4. 对于 HTTP 请求策略允许的流量，Gateway 按优先顺序评估 Forward 策略，并调用第一个匹配的 Worker。未匹配任何 Forward 策略的流量将在没有 Worker 的情况下继续。
  5. 随后，Gateway 评估请求体策略并检查原始请求体（包括数据防泄露（DLP）、防病毒扫描和文件沙箱），然后再将其交给 Worker 或源站。来自请求体策略或检查的拦截决定可以中断已在运行的 Worker。
  6. Gateway 检查最终响应，包括 Worker 产生的任何更改或合成响应。

这种执行顺序允许 Gateway 首先确定是否应该进行解密。如果网站与“不检查”策略匹配，它将自动允许通过 Gateway 并绕过所有其他 HTTP 策略。

接下来，Gateway 根据您的“隔离”策略检查解密后的流量。当用户发出的请求触发了“隔离”策略时，该请求将被重定向到远程浏览器。

接下来，Gateway 评估所有“允许”、“拦截”和“不扫描”策略。这些策略适用于隔离和非隔离流量。例如，如果 example.com 被隔离且 example.com/subpage 被拦截，Gateway 将在远程浏览器内部拦截该子页面（example.com/subpage）。

随后，Gateway 在请求体策略和检查（包括 DLP 策略、防病毒扫描和文件沙箱）之前评估 Forward 策略。如果存在 DLP 拦截策略，Gateway 最终采取的操作可能与它最初记录的操作不匹配。

有关更多信息，请参阅 DLP 策略优先级。

匹配的允许策略不会跳过 Forward 阶段。带有拦截操作的 HTTP 请求策略会阻止调用 Worker，而来自请求体策略或检查的拦截决定可以中断 Worker。

Gateway 会在将原始请求体交给 Worker 之前对其进行检查，并检查 Worker 返回的最终响应。经过修改的请求字节不会再接受一次请求侧检查。

请参阅 Forward 流量。

解析器策略

当存在解析器策略时，Gateway 首先评估具有解析前选择器的任何 DNS 策略，然后根据您的解析器策略的优先顺序路由任何 DNS 查询，最后评估具有解析后选择器的任何 DNS 策略。

无策略匹配时的默认行为

如果流量与任何明确的“允许”或“拦截”策略都不匹配，Gateway 将应用以下默认值：

策略类型 默认操作 描述
DNS 允许 DNS 查询通过配置的解析器正常解析。
网络 允许 TCP 和 UDP 连接允许通过 Gateway 代理。
HTTP 允许 HTTP 和 HTTPS 请求是允许的。但是，如果您在 HTTP 策略设置中配置了默认的 Block（拦截）操作，未匹配的流量则会被拦截。

由于默认行为是允许未匹配的流量，因此 Gateway 遵循宽松模式。要切换到严格模式（默认拦截，例外允许），请在相关策略生成器中以最低优先级创建一条包含一切（catch-all）的拦截策略，并在其上方添加特定的允许策略。

优先顺序

优先顺序是指 DNS、网络或 HTTP 策略生成器中各个策略的优先级。Gateway 按照升序评估策略，从最低值开始。

优先顺序遵循首次匹配原则。一旦流量与“允许”或“拦截”策略匹配，该过滤阶段的评估就会停止。

同一阶段中后续的过滤策略无法覆盖该决定。由 HTTP 请求策略允许的 HTTP 流量仍会经过单独的 Forward 阶段，然后是请求体策略和检查。

因此，Cloudflare 建议将最具针对性的策略和例外分配最高的优先级，而将最通用的策略分配最低的优先级。

Cloudflare 仪表板

在 Cloudflare 仪表板中，策略按照在列表中的从上到下的顺序优先执行。策略以优先级 1 开始并向上累加。您可以通过在仪表板中拖放单个策略来修改优先顺序。

Cloudflare API

要使用 Cloudflare API 更新策略的优先级，请使用 Update a Zero Trust Gateway rule 端点来更新 precedence field。

DLP 策略优先级

对于具有 DLP 策略的 Gateway 配置，Gateway 将基于首次匹配对流量进行过滤和记录，然后扫描 HTTP 请求的主体以查找匹配内容。由于首次匹配原则，Gateway 可能会对流量执行并记录一个决定，然后又执行一个与之矛盾的决定。例如，如果流量首先被 HTTP 允许策略允许，随后又被 DLP 拦截策略拦截，Gateway 将记录初始的 Allow（允许）操作，尽管最终拦截了该请求。

Access 应用程序

如果 Gateway 流量正走向被保护为 Access 应用程序的私有 IP 地址，该流量仍将由目标应用程序的 Access 策略进行评估，即使 Gateway 允许策略首先匹配也是如此。与流量匹配的 Gateway 拦截策略将终止任何其他策略评估。这是预期行为。Gateway 允许策略不会覆盖或绕过 Access 策略。

示例

假设您有一组按照以下优先顺序排列的策略：

  • DNS 策略：

    优先级 选择器 运算符 值 操作
    1 主机 is example.com 拦截
    2 主机 is test.example.com 允许
    3 域 matches regex .\ 拦截

  • HTTP 策略：

    优先级 选择器 运算符 值 操作
    1 主机 is example.com 拦截
    2 主机 is test2.example.com 不检查

  • 网络策略：

    优先级 选择器 运算符 值 操作
    1 目的端口 is 80 拦截
    2 目的端口 is 443 允许
    3 SNI 域 is test.example.com 拦截

当用户访问 https://test.example.com 时，Gateway 会执行以下操作：

  1. 根据 DNS 策略评估 DNS 请求：

    1. 策略 #1 不匹配 test.example.com — 继续检查策略 #2。
    2. 策略 #2 匹配，因此允许 DNS 解析。
    3. 策略 #3 不进行评估，因为已经有了明确的匹配。

  2. 根据网络策略评估 HTTPS 请求：

    1. 策略 #1 不匹配，因为端口 80 用于标准 HTTP，而不是 HTTPS。
    2. 策略 #2 匹配，因此该请求被允许并代理到上游服务器。
    3. 策略 #3 不进行评估，因为已经有了明确的匹配。

  3. 根据 HTTP 策略评估 HTTPS 请求：

    1. 首先评估策略 #2，因为“不检查”始终比“允许”和“拦截”具有优先权。由于没有匹配项，继续检查策略 #1。
    2. 策略 #1 与 test.example.com 不匹配。由于没有匹配的“拦截”策略，该请求通过了 HTTP 过滤器。

因此，用户能够连接到 https://test.example.com。

优先级计算

在 Cloudflare 仪表板 ↗中排列策略时，Gateway 会自动计算重新排列策略的优先级。

使用 API 创建策略时，除非在策略中明确定义了优先级，否则 Gateway 将为策略分配从 1000 开始的优先级。每当在排序底部添加新策略时，Gateway 都会计算账户中当前的最高优先级，并将 1 到 100 之间的随机整数相加到最高优先级上，以使其声称拥有账户中的最大优先级。要手动更新策略的优先级，请使用 Update a Zero Trust Gateway rule 端点。您可以将策略的优先级设置为尚未使用的任何值。

在使用 Terraform 时，在 Cloudflare 仪表板或通过 API 更改顺序可能会导致配置问题。

使用 Terraform 管理优先级

您可以使用 Terraform 管理 Gateway 策略的执行顺序。使用第 5 版的 Terraform Cloudflare 提供商，Gateway 用户可以在 Terraform 文件中列出其策略，并赋予任何所需的整数优先级值。Cloudflare 建议从 1000 的优先级开始，并在每个策略的优先级之间留出额外的空间，以便应对未来可能添加的策略。例如：

resource "cloudflare_zero_trust_gateway_policy" "policy_1" {
  account_id = var.cloudflare_account_id
  # other attributes...
  precedence = 1000
}

resource "cloudflare_zero_trust_gateway_policy" "policy_2" {
  account_id = var.cloudflare_account_id
  # other attributes...
  precedence = 2000
}

resource "cloudflare_zero_trust_gateway_policy" "policy_3" {
  account_id = var.cloudflare_account_id
  # other attributes...
  precedence = 3000
}

为避免使用 Terraform 重新排序策略时出现优先级计算错误，您应该在运行 terraform plan 和 terraform apply 之前每次只移动一个策略。如果您同时使用 Terraform 和 Cloudflare 仪表板或 API，请在 Terraform 中重新排序策略之前，先通过 terraform refresh 同步您的策略。或者，您也可以将账户设置为 Cloudflare 仪表板中的只读状态，仅允许使用 API 或 Terraform 进行更改。

这篇文档对您有帮助吗？