很多跨境电商站点一开始上香港服务器，配上 100M BGP 带宽，直觉上会觉得“带宽够大、离用户也不算远”，图片和静态资源应该会更快。于是顺手把 Cloudflare CDN 也开了，想着再加一层加速，体验肯定起飞。结果上线后发现一个很反直觉的现象：有些地区确实更快了，但更多用户的反馈变成了“图片时快时慢”“首屏偶尔卡死”“越加速越慢”。更麻烦的是，你看源站 CPU 不高、磁盘也不爆、带宽似乎也没跑满，Cloudflare 控制台里缓存命中率还不算差，但页面就是不稳定。

这类问题的本质通常不在“带宽大小”，而在于CDN 回源链路、缓存策略、回源握手/连接复用三件事叠加在一起：只要其中一项配置不对，Cloudflare 的 MISS / BYPASS 就会把请求反复打回香港源站，回源路径一绕、握手一重连、缓存一碎片化，就会把用户体验拖成“时好时坏”。A5数据直接按真实排障路径来：先把慢点拆解成可复现样本，再用可量化的方法定位瓶颈，最后给出 Cloudflare + Nginx 的逐条落地配置与验收指标，确保你改完之后不是“感觉更快”，而是数据明确更快、并且稳定。

一、问题复现：把“慢”做成可重复的样本（不然你改一万次也不知道对没对）

1）准备一组“慢资源清单”

挑 10～20 个最典型的静态资源（图片/JS/CSS/字体），建议覆盖三类：

• 无 Query：/assets/app.8c31c2.js
• 带版本 Query：/assets/app.js?v=20260113
• 带营销参数 Query：/images/banner.jpg?utm_source=xx

2）用 curl 固化每个资源的“分段耗时 + Cloudflare 缓存状态”

URL="https://yourdomain.com/assets/app.js?v=20260113"

curl -svo /dev/null "$URL" \
  -w "dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" \
  -D - | egrep -i "HTTP/|cf-cache-status|age|cache-control|cf-ray|server|content-type"

你要盯两个关键响应头：

• CF-Cache-Status：判断 HIT / MISS / BYPASS / DYNAMIC（Cloudflare 官方把这些状态用于缓存排查）
• CF-RAY：定位这次请求落在哪个 Cloudflare 边缘数据中心、也能用来和源站日志关联

3）再做一次“直连源站对照”

对同一资源，绕开 Cloudflare（例如临时加一个仅 DNS 的灰度子域 origin.yourdomain.com 指到源站公网 IP，不走代理），测同样一轮。

这一步能直接把问题切成两半：

• 直连也慢：源站/Nginx/磁盘/路径本身就慢
• 直连不慢、走 Cloudflare 慢：几乎肯定是“回源链路/回源握手/缓存策略”问题

二、诊断方法：10 分钟把慢点拆到“可下手”的模块

诊断总览

1. 看 CF-Cache-Status：是否大量 MISS/BYPASS/DYNAMIC
2. MISS 时看 TTFB：如果 TTFB 明显拉长，多半是回源耗时（不是下载慢）
3. 把 MISS 的请求，用 CF-RAY 对齐到源站 Nginx 日志：确认源站处理耗时、连接情况
4. 如果 BYPASS：优先查 Cache-Control / Set-Cookie / Authorization（Cloudflare 明确说明：源站的缓存指令或 Cookie 可能导致 BYPASS）

三、三大根因：为什么会“越加速越慢”

根因 1：回源路径不稳定（香港 100M BGP 最常见）

你以为 CDN 回源是“就近回香港”，但真实情况是：Cloudflare 的边缘节点在 MISS 时，会从该节点（或上层节点）回源到香港。如果这条路径在某些运营商/时段绕路，MISS 的 TTFB 就会被拉爆。

解决方向不是“加带宽”，而是：

• 减少 MISS 的数量
• 让 MISS 的回源更“近”或更稳定

Cloudflare 的 Tiered Cache/Smart Tiered Cache 就是为这个场景设计：通过分层缓存提升命中率、减少边缘直打源站的回源次数

根因 2：缓存策略错误（命中率看着不低，实际在命中“碎片缓存/无效缓存”）

典型坑位：

• Query 参数太乱：?v=时间戳、utm_* 这种每次都变，导致 Cache Key 被打碎
• 静态资源误带 Set-Cookie：Cloudflare 可能因此 BYPASS（直接不缓存）
• 源站返回 Cache-Control: private/no-cache/max-age=0：导致 Cloudflare 绕过缓存或不缓存

Cloudflare 允许你精细化 Cache Key：可以 include/exclude query string 参数，甚至直接忽略 query

根因 3：回源握手/连接复用没配好（MISS 变成“每次都重连 + 重握手”）

静态资源通常是“小文件、高并发、连接数多”。如果 Cloudflare 回源到你 Nginx 时：

• 只能走 HTTP/1.1，且 keepalive 不稳定
• TLS 会话复用差
• 源站连接上限/队列配置偏保守

就会出现“带宽没跑满，但响应慢”的典型症状。

Cloudflare 官方在 HTTP/2 to Origin 里明确提到：Cloudflare 会维护到源站的持久连接（keep-alive），并描述了连接复用和 idle timeout 等机制

四、逐条改配置（Cloudflare + Nginx）：按成本从低到高，先做 80/20

下面我给你一套“可直接落地”的配置清单，默认你的业务是跨境电商（HTML 动态、静态资源多）。

0）源站规格参考

你可以把它写进文章的“实验环境”，读者更信服：

这套配置的重点不是“跑分”，而是“静态资源回源的并发承载 + IO 稳定性”。

1）Nginx：把静态资源的缓存头写对，并确保“静态永远不带 Cookie”

1.1 静态资源独立 location（强建议）

# 静态资源：强缓存 + immutable（配合文件名 hash）
location ^~ /assets/ {
    access_log  /var/log/nginx/assets.access.log  main;

    # 让浏览器强缓存 1 年
    add_header Cache-Control "public, max-age=31536000, immutable";

    # 避免 Vary 撕裂缓存（按需保留，别乱加 UA）
    add_header Vary "Accept-Encoding";

    # 静态资源不应该下发 cookie（如果上游有，直接清掉）
    proxy_hide_header Set-Cookie;

    try_files $uri =404;
}

1.2 图片目录（同理）

location ^~ /images/ {
    add_header Cache-Control "public, max-age=2592000"; # 30 天
    add_header Vary "Accept-Encoding";
    try_files $uri =404;
}

为什么要强调 cookie？因为 Cloudflare 的缓存状态里，源站响应带 cookie会导致 BYPASS 的情况非常常见（等于“你以为在 CDN，其实每次都回源”）

2）Cloudflare：用 Cache Rules 做“静态资源强缓存 + 正确 Cache Key”

不要用“全站 Cache Everything”去赌，跨境电商的 HTML 动态页面一旦被误缓存，后果更大。更稳的做法是：只对静态资源做强缓存，并把 Cache Key 统一起来。

2.1 Cache Rule：静态资源 Eligible for cache + Edge TTL

规则示例（表达式按你站点路径调整）：

When：(http.request.uri.path starts_with "/assets/") or (http.request.uri.path starts_with "/images/")

Then：

• Cache eligibility：Eligible for cache
• Edge TTL：例如 30 天（或遵循源站 cache-control）
• Browser TTL：例如 7～30 天

Cloudflare 的 Cache Rules 支持直接配置 Cache Key，并说明 query string include/exclude 的用法

2.2 Cache Key：把“无意义 query”踢出去，把“有意义 query”白名单化

你有两种策略：

策略 A（推荐）：只允许少数必要参数参与缓存

• Query string：include 只保留 w,h,fit,format（如果你做图片裁剪/格式协商）
• 其他一律不进 Cache Key

策略 B：完全忽略 query（适用于你已经做了文件名 hash 版本化）

• Query string：exclude "*"（等价于忽略所有 query）

3）Cloudflare Transform Rules：从源头把 utm_* 之类的参数“去掉”，防止缓存碎片

如果你站点很多外链带 utm_source、utm_campaign，哪怕你 Cache Key 忽略了 query，回源请求仍可能带着 query（影响源站命中、日志、甚至触发应用层逻辑）。

Transform Rules 可以修改 query string/headers 等
你可以用 Rules 语言函数 remove_query_args() 来移除特定参数

思路示例：移除 utm_source/utm_medium/utm_campaign
（具体怎么在控制台点不展开写概念，你文章里直接截图规则即可）

4）把“MISS 的回源代价”压下来：Tiered Cache / Smart Tiered Cache

当你的业务图片量大、SKU 多、长尾资源多时，MISS 永远存在，关键是让 MISS 不要每次都从香港拉。

• Tiered Cache：通过层级缓存减少回源到 origin 的次数，提高整体命中率
• Smart Tiered Cache：会基于 Cloudflare 收集的延迟数据，为每个 origin 选择更优的上层节点（本质是让“上层缓存离你的香港源站更近、更稳”）

文章里你可以这么写结论：
“别把优化全押在香港 BGP 的回源路径上，先让回源次数下降一个数量级。”

5）回源协议栈：开启 HTTP/2 to Origin + 保证 Nginx 端 keepalive 友好

Cloudflare 的 HTTP/2 to Origin 文档明确写了连接复用与 idle timeout 等细节，说明它会维护到源站的持久连接、并在一定条件下复用
同时 Cloudflare 也建议确保 origin 的 keep-alive 启用，以避免连接被频繁重置

5.1 Nginx 侧（HTTPS + HTTP/2）

server {
    listen 443 ssl http2;
    server_name yourdomain.com;

    # 证书略…

    # 让连接复用更充分
    keepalive_timeout  65;
    keepalive_requests 10000;

    # 静态文件更友好
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # 记录 CF-RAY，方便和 Cloudflare 排障对齐
    log_format main '$remote_addr - $request '
                    'status=$status rt=$request_time '
                    'cf_ray=$http_cf_ray cf_ip=$http_cf_connecting_ip '
                    'ua="$http_user_agent"';
}

Cloudflare 官方也建议在排障时把 CF-RAY 加进日志，用来关联请求链路

6）图片优化：二选一，不要“重复优化”导致链路变复杂

Cloudflare 有两条路：

1. Polish：自动压缩/去元数据，减少图片体积
2. Image Transformations（/cdn-cgi/image/）：按 URL 参数做裁剪/格式转换，可输出 WebP/AVIF

官方明确提示：不要同时开启 Polish 和 Image Transformations，因为 transformations 已经做了有损压缩，Polish 会变得冗余、甚至让链路更难控

跨境电商更推荐的套路：

• 商品主图：用 Transformations 统一裁剪尺寸 + 输出 WebP/AVIF（减少首屏体积）
• 活动图/长图：Polish（简单省心）
• 但不要两者叠加

7）防穿透：把 404/403 也“短缓存”，避免被打回源

跨境电商常见“图片链接失效/改版路径变更”，如果这些请求不缓存，热点一来会疯狂打回源。

Cloudflare 支持按状态码设置缓存 TTL（Cache by status code）
你可以给：

• 404：缓存 60～300 秒
• 403：缓存 30～60 秒（视业务而定）

目的只有一个：挡住无效请求对回源的冲击。

五、验收指标：用数据证明“没有越加速越慢”

1）改前/改后评测表

下面是“模板写法”，你上线后把真实数据填进去即可。

2）验收动作（上线后 1 小时内就能完成）

• 用 curl 抽查 20 个资源：必须看到大量 CF-Cache-Status: HIT
• 抽 5 个曾经“很慢”的图片资源：MISS 的 TTFB 要明显下降
• 源站日志按 cf_ray 抽样：确认回源集中在少量请求，而不是每次都回源
• Cloudflare 控制台观察：回源请求数、回源耗时 P95 是否下降（配合 Tiered Cache）

这类“越加速越慢”不是 CDN 的问题，而是回源链路、缓存 Key、回源协议三者互相叠加的结果。正确的做法是：先把静态资源缓存规则做成“白名单强缓存”，再用 Transform Rules 消灭无意义参数，最后用 Tiered/Smart Tiered Cache 把 MISS 的代价压到最低，同时确保 Nginx 对 Cloudflare 的回源连接足够友好。