Gateway 故障排除

本指南可帮助您排除 Cloudflare Gateway 策略的常见问题。这些问题按最常见问题的顺序列出。

出站（Egress）策略是 Gateway 最常见的一类问题。症状包括流量未使用您的专用出站 IP、故障转移行为不正确，或者由于 Gateway 通过遥远的数据中心路由流量而导致高延迟。

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

您的主专用出站 IP 变得不可用，但流量没有使用您配置的辅助专用 IP，而是故障转移到默认的 Cloudflare 共享 IP。

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

常见原因和解决方案：

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

您针对特定应用程序设置了高优先级的允许（Allow）或不扫描（Do Not Scan）策略（例如允许 finance.example.com），但 Gateway 仍使用低优先级的阻止（Block）策略（例如阻止所有高风险网站）阻止流量。

最核心的概念是 Gateway 策略优先级，Gateway 根据策略的顺序号来实施该优先级。列表中较小的顺序号表示较高的优先级。当 Gateway 遇到第一条匹配的规则时，它就会停止处理后续的策略。

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

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

开启 TLS 解密是使用 Data Loss Prevention (DLP)、Browser Isolation 和应用感知的 HTTP 策略等 Gateway 功能的前提条件。然而，它可能会对某些类型的软件造成问题。

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

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

要解决此问题：

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

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

要解决此问题：

1. 确认设备上已安装 Cloudflare 根证书。
2. 确保将证书放置在正确的系统级信任存储中（例如 macOS 上的 Keychain 系统存储，或 Windows 上的本地计算机受信任的根证书颁发机构）。
3. 如果您使用移动设备管理 (MDM) 工具，请验证您的部署脚本是否正确安装并信任了证书。

您已配置 Gateway 来解析内部主机名，但用户无法访问它们。例如，连接到 Cloudflare One 客户端的用户尝试访问诸如 jira.mycompany.local 的内部服务，但 DNS 查询失败。