Gateway

本指南帮助你排查 Cloudflare Gateway 策略的常见问题。

被阻止的网站与连接性

网站被错误阻止

如果您认为某个域名被 Gateway 的安全类别或威胁情报错误阻止，可以使用 Cloudflare Radar 分类反馈表 ↗申请复核。

错误 526：无效的 SSL 证书

当 Gateway 无法与源站建立安全连接时，会呈现 526 错误页面。这通常发生在以下两种情况中：

不受信任的源站证书：源站服务器呈现的证书已过期、已被吊销或由未知权威机构颁发。
不安全的源站连接：源站不支持现代加密套件，或者将所有 HTTPS 请求重定向到 HTTP。

有关更多信息，请参阅错误 526。

错误 502：Bad Gateway

与部分支持 HTTP/2 的源站进行通信时可能会发生此问题。如果源站请求降级到 HTTP/1.1（例如，通过带有 HTTP_1_1_REQUIRED 的 RST_STREAM 帧），Gateway 不会自动通过 HTTP/1.1 重新发布请求，而是会返回 502 Bad Gateway。要解决此问题，请在源站服务器上禁用 HTTP/2。

不受信任的证书警告

如果用户在每个页面上都看到证书警告，请确保在其设备上安装并信任 Cloudflare 根证书。这是 Gateway 检查 HTTPS 流量所必需的。

仪表板和分析

未显示 Gateway 分析

如果您在 Gateway 概览页面上没有看到分析数据：

验证 DNS 流量：确保您的设备实际正在向 Gateway 发送查询。检查您的 DNS 位置并验证源 IPv4 地址。
检查其他解析器：确保设备上没有配置其他 DNS 解析器，因为它们可能会绕过 Gateway。
等待处理：分析数据最多需要 5 分钟才会显示在仪表板中。

出口策略

出口策略故障症状包括流量未使用您的专用出口 IP、故障转移行为不正确，或者由于 Gateway 通过遥远的数据中心路由流量而导致高延迟。

症状：流量未使用您的专用出口 IP

即使有处于活动状态的出口策略，您也可能会发现流量是从默认的 Cloudflare IP 地址流出，而不是从您的专用出口 IP 流出。

常见原因	解决方案
DNS 解析到 CGNAT（运营商级 NAT）	当出口策略使用 Domain 或 Host 选择器时，Gateway 必须首先解析该域名。对于通过 Cloudflare 代理的流量，这通常会解析为 `100.64.0.0/10` 范围内的 CGNAT IP 地址。因为此 IP 是 Cloudflare 网络的内部 IP，它可能不受出口策略的约束，出口策略仅适用于离开网络的流量。请将出口策略中的选择器从 Domain 或 Host 更改为 Destination IP。使用您尝试访问的服务的公网 IP 地址。
策略优先级	优先级更高（数字更小）的其他出口策略首先匹配了该流量。请记住，出口策略遵循相同的“首次匹配获胜”逻辑。
Split Tunnel 配置	目标 IP 或域名已通过您的 Split Tunnel 配置从 WARP 隧道中排除。从隧道中排除的流量将不受任何 Gateway 策略的约束，包括出口策略。
无出口日志	出口日志可通过带 Gateway Egress 数据集的 Logpush 获取。这对于排除故障至关重要。您也可以使用第三方 IP 检查服务来验证测试设备的出口 IP。

症状：故障转移未正常工作或使用了错误的 IP

您的主专用出口 IP 变得不可用，但流量并未切换到配置的备用专用 IP，而是故障转移到了默认的 Cloudflare 共享 IP。

常见原因	解决方案
Cloudflare 侧的路由或配置问题	记录事件发生的时间，并从受影响用户的 Gateway HTTP 或 DNS 日志中收集请求 ID（Request ID）。开设支持工单并提供此信息。临时操作上，您可以编辑出口策略，将您的备用 IP 设置为主 IP 以恢复服务。

症状：用户从地理位置遥远的区域流出

Gateway 将位于某国家/地区（例如澳大利亚）的用户通过位于另一区域（例如德国）的专用出口 IP 进行路由，从而导致高延迟并破坏对受地理限制内容的访问。

常见原因解决方案

单一出口策略您可能拥有一条适用于所有用户（无论其位置如何）的宽泛出口策略。创建感知位置的出口策略。在您的策略中使用 User Location 选择器，将特定用户位置绑定到其最近的专用出口 IP。例如，创建一条策略：当 User Location 为 United Kingdom 时，通过伦敦 IP 流出；创建第二条策略：当 User Location 为 Australia 时，通过悉尼 IP 流出。

地理位置数据不正确用户 ISP 的 IP 地址定位可能不正确。在 Gateway 日志中检查 Cloudflare 所看到的该用户的位置。如果看起来不正确，您可以将其报告给 Cloudflare 支持部门。

常见原因	解决方案
单一出口策略	您可能拥有一条适用于所有用户（无论其位置如何）的宽泛出口策略。创建感知位置的出口策略。在您的策略中使用 User Location 选择器，将特定用户位置绑定到其最近的专用出口 IP。例如，创建一条策略：当 User Location 为 `United Kingdom` 时，通过伦敦 IP 流出；创建第二条策略：当 User Location 为 `Australia` 时，通过悉尼 IP 流出。
地理位置数据不正确	用户 ISP 的 IP 地址定位可能不正确。在 Gateway 日志中检查 Cloudflare 所看到的该用户的位置。如果看起来不正确，您可以将其报告给 Cloudflare 支持部门。

策略优先级

一个常见的混淆点是 Gateway 如何评估其不同的策略类型以及其中的规则。

症状：Block（阻止）策略覆盖了更具体的 Allow（允许）或 Do Not Scan（不扫描）策略

您为特定应用程序设置了高优先级的 Allow 或 Do Not Scan 策略（例如 Allow finance.example.com），但 Gateway 仍使用低优先级的 Block 策略阻止流量（例如 Block All High-Risk Sites）。

最重要的概念是 Gateway 策略优先级，Gateway 根据策略的序号来强制执行。列表中更小的序号意味着更高的优先级。当遇到第一个匹配的规则时，Gateway 会停止处理后续的策略。

要解决 Gateway 策略优先级问题：

在 Cloudflare 仪表板 ↗中，转到 Zero Trust > Traffic policies（流量策略）> Firewall policies（防火墙策略）。
审查您的 DNS、Network 和 HTTP 策略的顺序。
确保您最具体的 Allow、Do Not Scan 或 Do Not Inspect 策略的序号小于您的通用 Block 策略。
根据需要拖放策略以重新排序。针对 teams.microsoft.com 的 Allow 策略应放在针对所有文件共享应用程序的通用 Block 策略之前。

TLS 解密破坏应用程序

开启 TLS 解密是使用 Data Loss Prevention (DLP)、浏览器隔离（Browser Isolation）和感知应用程序的 HTTP 策略等 Gateway 功能所必需的。然而，这可能会导致某些类型的软件出现问题。

症状：命令行工具（CLI 工具）或原生应用程序因证书错误而失败

如果在开启 TLS 解密后，命令行工具（如 git、aws、kubectl 和 terraform）或桌面应用程序（如 ChatGPT 或 Docker）停止工作，这可能是由于证书错误造成的。应用程序可能会返回类似 SSL: CERTIFICATE_VERIFY_FAILED、self-signed certificate in certificate chain 或类似的 TLS 错误。

这些应用程序不使用操作系统的信任存储，因此不信任您安装的 Cloudflare 根证书。它们通常有自己的证书信任存储或使用证书绑定（certificate pinning），要求使用服务器的原始证书，而不是由 Cloudflare 重新签署的证书。

要解决此问题：

创建针对性的 HTTP 策略，以绕过这些工具需要访问的特定域名的解密。将此策略的优先级放在高于您主要 TLS 解密策略的位置（更小的序号）。

创建包含 github.com、*.amazonaws.com 和 *.docker.io 等主机的列表。

选择器	运算符	值	操作
Domain（域名）	in list	CLI 工具域名	Do Not Inspect（不检查）

您可以将某些工具配置为信任自定义 CA 或禁用 SSL 验证。这安全性较低，且在规模化管理时更加困难。有关更多信息，请参阅手动安装证书。

症状：未显示自定义阻止页面

当 HTTP 策略阻止用户的请求时，其浏览器将返回通用错误（ERR_SSL_PROTOCOL_ERROR），而不是您配置的 Gateway 阻止页面。

发生这种情况是因为浏览器不信任阻止页面呈现的证书，该证书是由 Cloudflare 根证书签名的。这意味着证书未在用户设备上安装或不受信任。