排查网站缓慢问题

本指南帮助你识别并解决影响网站的性能问题。内容从基础诊断开始，逐步深入到高级排查技巧。

在排查性能问题之前，请确认你的流量确实经过 Cloudflare。如果请求绕过了 Cloudflare，问题与 Cloudflare 无关，本指南也无法提供帮助。

经过 Cloudflare 提供的每个响应都包含 cf-ray 请求头。检查该请求头：

curl -s -D- -o /dev/null https://www.example.com | grep -i cf-ray

(Invoke-WebRequest -Uri "https://www.example.com" -Method Head).Headers["cf-ray"]

如果你看到 cf-ray 请求头（例如 cf-ray: 8a1b2c3d4e5f6g7h-SJC），说明流量正在经过 Cloudflare。如果没有，请检查 DNS 配置。

域名必须解析到 Cloudflare IP 地址，流量才会被代理：

dig +short www.example.com

Resolve-DnsName -Name www.example.com | Select-Object -ExpandProperty IPAddress

返回的 IP 地址应为 Cloudflare IP ↗。如果它们直接指向你的源站服务器，说明 DNS 记录未被代理。

修复方法：

1. 前往 Cloudflare 仪表板 ↗。
2. 找到缓慢主机名的 DNS 记录。
3. 确保 Proxy status（代理状态） 设为 Proxied（橙色云图标）。

当能精确定位缓慢之处时，性能问题更容易解决。先收集以下信息：

1. 识别具体的缓慢请求 — 确定哪些 URL、资源或 API 端点缓慢。
2. 衡量缓慢程度 — 量化延迟（例如“此图片加载需要 5 秒”）。
3. 复现问题 — 确认缓慢是持续现象，而非一次性情况。

Observatory 提供合成测试与真实用户监控 (RUM) 数据，用于评估网站性能。

RUM 尤其重要，因为这些指标来自实际访客的浏览器，客观反映他们体验网站的方式；而实验室数据通常更详细（便于调试），但并不总能与真实用户可用的设备或网络条件对应。

1. 前往 Cloudflare 仪表板。

   Go to Observatory ↗

2. 选择 Observatory（观测站）。

3. 输入要测试的 URL，然后选择 Run test（运行测试）。

Observatory 会报告关键指标：

真实用户监控会报告类似指标，但你会看到 Interaction to Next Paint (INP)，而不是 Total Blocking Time (TBT)。

TBT 仅在页面加载期间测量，而 INP 会测量真实访客与网站的每一次交互。

根据 Observatory 结果，启用相关的 Speed 优化：

• Brotli 压缩 — 压缩响应以加快传输
• Early Hints — 预加载关键资源
• HTTP/2 与 HTTP/3 — 使用支持多路复用的现代协议，允许多个请求共享单个连接，而不是为每个资源单独打开连接
• 图像优化 — 自动优化并调整图像大小
• Rocket Loader — 延迟加载 JavaScript，以改善绘制时间

如果 Observatory 与 RUM 数据指向具体问题，请使用浏览器开发者工具调查各个资源。

1. 打开浏览器的开发者工具。
2. 前往 Network（网络） 选项卡。
3. 重新加载页面，观察哪些请求耗时最长。
4. 按 Time（时间） 或 Duration（持续时间） 排序，以识别最慢的资源。
5. 记录缓慢资源的具体 URL。

关注：

• 大型图像或视频
• 缓慢的 API 调用
• 第三方脚本
• 渲染阻塞资源

如果网站缓慢，问题可能出在源站服务器。使用 Origin Analytics 了解源站的表现。

在 Cloudflare 仪表板中：

1. 前往 Speed（速度） > Origin Analytics（源站分析）。

   Go to Origin Analytics ↗

2. 查看 Origin Response Time（源站响应时间） 指标。

3. 寻找缓慢响应中的模式（特定路径、时段或地理区域）。

较高的源站响应时间表明源站服务器吃力。可考虑：

• 升级托管计划
• 优化数据库查询
• 实施服务端缓存

有关可用指标、诊断流程以及如何解读源站状态码的完整指南，请参阅 Origin Analytics。

如果你的 zone 部署了 Cloudflare Workers，它们会在每个匹配请求上执行，并增加总响应时间。缓慢的 Worker 是高 TTFB 的常见原因。

要检查 Workers 是否影响性能：

1. 在 Cloudflare 仪表板中前往 Workers & Pages。
2. 查看部署在你 zone 上的 Workers。
3. 检查每个 Worker 的 Analytics（分析），查看执行时间。
4. 临时禁用 Workers，以隔离它们是否导致缓慢。

如果某个 Worker 缓慢，请检查其代码中是否存在：

• 缓慢的外部 API 调用或 fetch() 请求
• 低效的循环或数据处理
• 缺失的 await 语句导致串行而非并行执行

若需针对特定请求获取详细时序指标，可使用命令行工具测量性能。

curl -w "\n\nDNS Lookup: %{time_namelookup}s\nTCP Connect: %{time_connect}s\nTLS Handshake: %{time_appconnect}s\nTime to First Byte: %{time_starttransfer}s\nTotal Time: %{time_total}s\n" -o /dev/null -s https://www.example.com/slow-asset.jpg

$url = "https://www.example.com/slow-asset.jpg"
try {
    $timing = Measure-Command { 
        $response = Invoke-WebRequest -Uri $url -ErrorAction Stop
    }
    Write-Host "Total Time: $($timing.TotalSeconds)s"
    Write-Host "Status: $($response.StatusCode)"
} catch {
    if ($_.Exception.Response) {
        $statusCode = $_.Exception.Response.StatusCode.value__
        Write-Host "Error Status: $statusCode"
    }
    Write-Host "Error: $($_.Exception.Message)"
}

示例输出 (bash)：

DNS Lookup: 0.025s
TCP Connect: 0.045s
TLS Handshake: 0.120s
Time to First Byte: 0.350s
Total Time: 1.250s

curl 时序分解显示如下内容：

要从不同地理位置测试，可使用在线工具，例如：

• KeyCDN Tools ↗
• Uptrends ↗
• Dotcom-Tools ↗

缓存是改善网站性能最有效的方法之一。内容被缓存后，Cloudflare 会直接从靠近访客的数据中心提供内容，从而省去往返源站服务器的过程。这可将响应时间从数百毫秒缩短到几毫秒。

未缓存的内容必须从访客到达 Cloudflare，再到你的源站服务器，然后返回。使用 Cache Analytics 了解缓存表现，并识别可缓存更多内容的机会。

检查特定资源的缓存状态：

curl -s -D- -o /dev/null https://www.example.com/asset.jpg | grep -i "cf-cache-status"

(Invoke-WebRequest -Uri "https://www.example.com/asset.jpg" -Method Head).Headers["cf-cache-status"]

可能的值：

完整列表请参阅 Cloudflare 缓存响应。

1. 前往 Cloudflare 仪表板。

   Go to Overview ↗

2. 查看 Cache Performance（缓存性能） 部分。

3. 按 Cache status equals MISS（缓存状态等于 MISS） 或 DYNAMIC 过滤，以识别未缓存内容。

如果静态资源（图像、CSS、JavaScript）显示缓存状态为 DYNAMIC、BYPASS 或 MISS，请调查原因：

默认情况下，Cloudflare 仅缓存某些 文件扩展名。要缓存更多静态内容：

1. 前往 Caching（缓存） > Cache Rules（缓存规则）。
2. 创建规则以 缓存特定内容。
3. 设置合适的 Edge TTL。

如果缓存规则未按预期生效，请使用 Cloudflare Trace 模拟请求，并查看究竟哪些规则会匹配。Trace 会显示你的 Cloudflare 配置（包括缓存规则、页面规则及其他设置）将如何影响特定 URL。

在以下情况中尤其有用：

• 缓存规则应缓存内容，但响应显示 DYNAMIC 或 BYPASS
• 你不确定哪条规则优先
• 你想在更改前测试“假设”场景

如果 curl 显示较高的 TCP Connect 或 TLS Handshake 时间，问题可能与网络相关，而非应用相关。

访问 speed.cloudflare.com ↗ 测试：

• 下载与上传速度
• 延迟（ping）
• 抖动
• 丢包

结果较差表明本地网络或 ISP 存在问题。

MTR 结合 traceroute 与 ping，显示每个网络跃点的延迟与丢包。

mtr -rw www.example.com

关注：

• 特定跃点的 高延迟（表示网络段缓慢）
• 丢包（表示网络拥塞或故障）
• 超时（可能表示防火墙或路由问题）

更多详情请参阅 如何阅读 MTR ↗。

如果你能访问源站服务器，请从源站向某个 Cloudflare IP 地址 ↗ 运行 MTR，以测试源站与 Cloudflare 之间的网络路径。

mtr -rw 104.16.132.229

此路径上的高延迟或丢包会影响所有未命中缓存的请求。

请求如何路由到 Cloudflare 数据中心，会显著影响性能。

在域名后添加 /cdn-cgi/trace，可查看哪个 Cloudflare 数据中心正在为你的请求提供服务：

curl https://www.example.com/cdn-cgi/trace

Invoke-RestMethod -Uri "https://www.example.com/cdn-cgi/trace"

colo 字段显示提供服务的数据中心的三字母机场代码（例如 colo=SJC 表示圣何塞）。可在 Cloudflare 状态页面 ↗ 上查看 Cloudflare 数据中心及其代码的完整列表。

当请求到达 Cloudflare 时：

1. 请求会根据 anycast 路由 ↗ 被路由到附近的 Cloudflare 数据中心。
2. 若内容已缓存，会立即提供。
3. 若未缓存，Cloudflare 会从你的源站服务器获取。

如果你的源站服务器在地理上距离为用户提供服务的 Cloudflare 数据中心较远，未缓存的请求会变慢。

如果请求被路由到似乎远离用户的数据中心，这可能是由于 Cloudflare 的自动化流量工程，或用户 ISP 的流量路由。

虽然 Cloudflare 始终力求通过从最近的位置提供流量来实现最佳性能，但可靠性是首要目标。在性能与可靠性冲突时，Cloudflare 的系统会优先选择稳定连接，而不是本地连接。

更多详情请参阅 Cloudflare 流量未发送到地理上最近的数据中心。

意外路由的常见原因：

根据需求考虑这些方案：

Argo Smart Routing 实时分析网络状况，并通过最快路径路由流量，平均可将延迟降低 30%。

Argo Smart Routing 是 Smart Shield 的一部分，后者捆绑了多种 Cloudflare 性能与可靠性功能。

要启用 Argo Smart Routing：

1. 前往 Cloudflare 仪表板 ↗。
2. 按照 Smart Shield 设置指南 启用该功能。

Argo 在以下情况下尤其有效：

• 源站远离用户
• 网络拥塞影响某些路径
• 你需要全球范围内的一致性能

有关 Argo Smart Routing 工作原理的详细信息，请参阅 Argo Smart Routing 文档。

如果你已按上述步骤操作，但性能问题仍然存在，请 联系 Cloudflare 支持 寻求帮助。

联系支持时，请尽可能提供证据，以帮助诊断问题：

• HAR 文件 — 生成 HAR 文件，捕获缓慢请求。这会为每个请求提供详细的时序信息。
• Observatory 结果 — 分享 Observatory 测试结果的截图或链接。
• RUM 数据 — 若已启用 Web Analytics，请分享显示性能问题的相关指标。
• curl 输出 — 包含对缓慢资源使用 curl --write-out 的时序分解。
• MTR 结果 — 若怀疑网络问题，请包含从你的位置到受影响域名的 MTR 输出。
• 具体 URL — 列出缓慢的确切 URL，以及预期与实际响应时间。

你提供的证明缓慢的证据越多，支持团队就能越快识别并解决问题。

• Observatory — 测试并监控网站性能
• Cache Analytics — 分析缓存命中率
• Cache Rules — 控制缓存内容
• Argo Smart Routing — 优化网络路由
• 为排查收集信息 — 收集诊断数据