本指南帮助你排查 Cloudflare Gateway 策略的常见问题。
如果您认为某个域名被 Gateway 的安全类别或威胁情报错误阻止，可以使用 Cloudflare Radar 分类反馈表 ↗申请复核。
当 Gateway 无法与源站建立安全连接时，会呈现 526 错误页面。这通常发生在以下两种情况中：
- 不受信任的源站证书：源站服务器呈现的证书已过期、已被吊销或由未知权威机构颁发。
- 不安全的源站连接：源站不支持现代加密套件，或者将所有 HTTPS 请求重定向到 HTTP。
有关更多信息，请参阅 错误 526。
与部分支持 HTTP/2 的源站进行通信时可能会发生此问题。如果源站请求降级到 HTTP/1.1（例如，通过带有 HTTP_1_1_REQUIRED 的 RST_STREAM 帧），Gateway 不会自动通过 HTTP/1.1 重新发布请求，而是会返回 502 Bad Gateway。要解决此问题，请在源站服务器上禁用 HTTP/2。
如果用户在每个页面上都看到证书警告，请确保在其设备上安装并信任 Cloudflare 根证书。这是 Gateway 检查 HTTPS 流量所必需的。
如果您在 Gateway 概览页面上没有看到分析数据：
- 验证 DNS 流量：确保您的设备实际正在向 Gateway 发送查询。检查您的 DNS 位置并验证源 IPv4 地址。
- 检查其他解析器：确保设备上没有配置其他 DNS 解析器，因为它们可能会绕过 Gateway。
- 等待处理：分析数据最多需要 5 分钟才会显示在仪表板中。
出口策略故障症状包括流量未使用您的专用出口 IP、故障转移行为不正确，或者由于 Gateway 通过遥远的数据中心路由流量而导致高延迟。
即使有处于活动状态的出口策略，您也可能会发现流量是从默认的 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，而是故障转移到了默认的 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 支持部门。 |
一个常见的混淆点是 Gateway 如何评估其不同的策略类型以及其中的规则。
您为特定应用程序设置了高优先级的 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 解密是使用 Data Loss Prevention (DLP)、浏览器隔离（Browser Isolation）和感知应用程序的 HTTP 策略等 Gateway 功能所必需的。然而，这可能会导致某些类型的软件出现问题。
如果在开启 TLS 解密后，命令行工具（如 git、aws、kubectl 和 terraform）或桌面应用程序（如 ChatGPT 或 Docker）停止工作，这可能是由于证书错误造成的。应用程序可能会返回类似 SSL: CERTIFICATE_VERIFY_FAILED、self-signed certificate in certificate chain 或类似的 TLS 错误。
这些应用程序不使用操作系统的信任存储，因此不信任您安装的 Cloudflare 根证书。它们通常有自己的证书信任存储或使用证书绑定（certificate pinning），要求使用服务器的原始证书，而不是由 Cloudflare 重新签署的证书。
要解决此问题：
当 HTTP 策略阻止用户的请求时，其浏览器将返回通用错误（ERR_SSL_PROTOCOL_ERROR），而不是您配置的 Gateway 阻止页面。
发生这种情况是因为浏览器不信任阻止页面呈现的证书，该证书是由 Cloudflare 根证书签名的。这意味着证书未在用户设备上安装或不受信任。
要解决此问题：
- 确认设备上安装了 Cloudflare 根证书。
- 确保将证书放置在正确的系统级信任存储中（例如 macOS 上的 Keychain System 存储，或 Windows 上的 Local Computer Trusted Root Certification Authorities）。
- 如果您使用 MDM，请验证您的部署脚本是否正确安装并信任该证书。
您已配置 Gateway 来解析内部主机名，但用户无法访问它们。例如，连接到 Cloudflare One 客户端的用户尝试访问诸如 jira.mycompany.local 之类的内部服务，但 DNS 查询失败。
| 常见原因 | 解决方案 |
|---|---|
| 解析器策略缺失或不正确 | 转到 Traffic policies（流量策略）> Resolver policies（解析器策略）。创建匹配您内部域名后缀的策略，并将查询转发到您内部 DNS 服务器的 IP 地址。 |
| Split Tunnel 排除了专用 IP 范围 | 如果您的内部资源位于专用 IP 范围（例如 10.0.0.0/8）中，则该范围必须包含在隧道中。如果它在您的 Split Tunnel 配置的 Exclude 列表中，Cloudflare One 客户端将不会代理该流量。 |
| Local Domain Fallback 配置错误 | 对企业 DNS 使用解析器策略。仅对特定于用户直接物理网络的域名使用 Local Domain Fallback。 |