有关 Load Balancing 的更多详细信息——包括操作指南、教程和其他参考信息——请查阅我们的产品文档。
此问题可能是两个问题的组合导致的。
当您将监视器附加到池时，可以指定 Cloudflare 用于监控端点健康的 Health Monitor Regions（健康监视器区域）。
如果您选择多个区域或选择 All Data Centers (Enterprise Only)（所有数据中心，仅 Enterprise），可能会大幅增加该池及其关联端点的流量。每个区域从 3 个数据中心发送单独的健康监视器请求。使用 All Data Centers（所有数据中心） 会从所有现有 Cloudflare 数据中心（且数据中心数量一直在增长）发送单独的健康监视器请求。
要减少流量，请减少所选区域的数量或选择 All Data Centers（所有数据中心） 以外的选项。
如果健康监视器请求间隔较短，可能会增加发送到端点的流量。
要了解端点和池如何变为不健康，请参阅端点与池健康状态。
如果您知道端点是健康的但负载均衡报告其为不健康，请检查监视器 上的以下设置：
- 对配置的端点执行
curl请求。确保您看到的响应与监视器的设置匹配。 - 确保防火墙或 Web 服务器不会阻止或限速我们的健康监视器，并接受来自 Cloudflare IP 地址的请求。
- 如果您在 Response Body（响应正文） 中查找特定值，请确保该值相对静态且在 HTML 页面的前 10 KB 内。
- 如果端点以
301或302状态码响应，请确保选择了 Follow Redirects（跟随重定向）。 - 尝试增加 Timeout（超时） 值。
- 检查健康监视器的 Host Header（主机标头）。
- 如果您使用 Authenticated Origin Pulls (mTLS)、Argo Smart Routing、Bring your own CA (mTLS)、Dedicated CDN Egress IPs，或需要 HTTP/2 to Origin，请确保为 Simulate Zone（模拟区域） 输入了与配置了这些功能的 zone 对应的 zone 值。
您偶尔可能会看到流量从池被路由离开，如果特定数据中心的健康监视器请求失败（即使端点仍然健康）。该数据中心可能会将少量请求导向另一个被该数据中心视为健康的池。
要了解端点和池如何变为不健康，请参阅端点与池健康状态。
当池或端点变为不健康时，流量可能会根据您的配置重新路由到其他健康的池或端点。使用以下配置时可能会遇到此行为：
1 - 使用 All-Datacenters（所有数据中心） 监控的池，且监视器在特定数据中心失败。在此情况下，所有流量将从该数据中心受影响的端点导向离开，直到监视器再次成功。这些实例在 LB 请求分析中反映为从不健康端点或池导向离开。
2 - 使用 FQDN 端点地址的池，且递归 DNS 查找在特定数据中心失败。在此情况下，仅 DNS 请求失败的请求将从受影响的端点导向离开。这可能零星发生，尤其是当上游权威解析器偶尔超时或失败，且本地 DNS 缓存 TTL 过期并在热路径中需要远程查找时。这也会在 LB 请求分析中显示为从不健康端点导向离开，且解析的端点 IP 将缺失于请求日志中。
要避免这些场景：
1 - 不要使用 All-Datacenters（所有数据中心） 监控。
2 - 对端点配置使用 IP 地址。如果不可行，使用 Cloudflare 作为权威（主或辅）的域。
要了解端点和池如何变为不健康，请参阅端点与池健康状态。
Cloudflare Load Balancing 帮助监控端点健康状态，并——基于此和其他信息——相应地路由传入请求。各个端点附加监视器，定期发出监视器请求。
Cloudflare Health Checks 与负载均衡器内的监视器相同，但仅用于探测服务器健康状态（不分发流量）。
查看 Load Balancing Analytics 时，您可能会看到不同的请求数量，尤其是与其他 Cloudflare 仪表板（Caching 等）比较时。
负载均衡 requests（请求） 是负载均衡器发出的未缓存请求数量。默认情况下，Cloudflare 将解析的 IP 地址缓存最多五秒。此内置缓存通常是差异的原因。
有关特定错误代码和后续步骤的列表，请参阅 Load Balancing 故障排查。