Cloudflare 网站加速实战：从缓存策略到 Worker 源码配置

发布人：慈云数据-客服中心发布时间：1 天前阅读量：4

Cloudflare 性能优化教程｜附源码

在网站性能优化中，Cloudflare 是一个非常常见且强大的工具。它不仅可以作为 CDN 加速静态资源，还能提供 DNS 解析、缓存、页面规则、安全防护、边缘计算、图片优化、HTTP/3、Brotli 压缩等能力。对于个人博客、企业官网、电商站点、API 服务甚至前端应用来说，合理配置 Cloudflare，往往可以显著降低源站压力，提高访问速度，并增强安全性。

本文将以实战角度，系统讲解如何使用 Cloudflare 对网站进行性能优化，并附上常用配置源码，包括 Nginx 配置、Cloudflare Worker 缓存代码、前端缓存头设置示例等。

一、Cloudflare 性能优化的核心思路

Cloudflare 的性能优化并不是单纯“打开 CDN”这么简单。真正有效的优化通常包含以下几个层面：

DNS 优化
使用 Cloudflare 的全球 Anycast DNS，提高域名解析速度。
静态资源缓存
将 CSS、JavaScript、图片、字体等静态资源缓存到 Cloudflare 边缘节点。
HTML 页面缓存
对适合缓存的页面进行边缘缓存，减少源站动态请求。
压缩与协议优化
开启 Brotli、HTTP/2、HTTP/3、0-RTT 等功能，降低传输开销。
图片优化
使用 WebP、AVIF、Polish、Mirage 或自定义图片压缩方案。
源站优化
配合 Nginx、Node.js、PHP、Java 等后端服务设置合理的缓存头。
边缘计算优化
使用 Cloudflare Workers 在边缘节点处理缓存逻辑、重定向、鉴权和接口代理。
安全与性能平衡
通过防火墙规则、Bot Fight Mode、WAF 等功能减少恶意流量，降低服务器压力。

二、接入 Cloudflare 的基础步骤

1. 添加站点

首先进入 Cloudflare 控制台，添加你的域名，例如：

example.com

Cloudflare 会扫描当前 DNS 记录。确认无误后，继续下一步。

2. 修改域名 NS 服务器

Cloudflare 会分配两个 Nameserver，例如：

ada.ns.cloudflare.com
bob.ns.cloudflare.com

你需要前往域名注册商后台，将原来的 NS 服务器修改为 Cloudflare 提供的 NS。

通常生效时间为数分钟到 24 小时不等。

3. 开启代理模式

在 Cloudflare 的 DNS 页面中，记录旁边有一个云朵图标：

灰色云朵：仅 DNS 解析，不经过 Cloudflare 代理。
橙色云朵：流量经过 Cloudflare，可使用 CDN、缓存、安全等功能。

对于网站主域名和常用子域名，建议开启橙色云朵。

例如：

类型	名称	目标	状态
A	@	1.2.3.4	Proxied
A	www	1.2.3.4	Proxied
CNAME	static	example.com	Proxied

三、基础性能功能设置

进入 Cloudflare 控制台后，可以从以下几个位置进行优化。

1. 开启 Brotli 压缩

路径：

Speed -> Optimization -> Content Optimization -> Brotli

开启 Brotli 后，Cloudflare 会对支持压缩的文本资源进行更高效压缩，例如：

HTML
CSS
JavaScript
JSON
SVG
XML

Brotli 通常比 Gzip 有更高的压缩率，尤其适合前端静态资源。

2. 开启 HTTP/2 与 HTTP/3

路径：

Network -> HTTP/2
Network -> HTTP/3

建议开启：

HTTP/2
HTTP/3 QUIC
0-RTT Connection Resumption

HTTP/2 可以复用连接，减少多个资源请求时的连接开销。HTTP/3 基于 QUIC，在移动网络、弱网环境下通常表现更好。

不过需要注意，0-RTT 对部分存在重放风险的接口可能不适合。如果网站包含重要的支付、下单、鉴权接口，应谨慎评估。

3. 开启 Auto Minify

路径：

Speed -> Optimization -> Content Optimization -> Auto Minify

可以选择压缩：

JavaScript
CSS
HTML

如果你的前端项目已经通过 Vite、Webpack、Rollup 等工具完成了压缩构建，那么 Cloudflare 的 Auto Minify 收益有限，甚至可能对某些特殊代码造成兼容问题。

建议：

普通网站：可以开启。
现代前端工程：优先在构建阶段压缩，不一定需要开启。
出现 JS 异常时：先关闭 Auto Minify 排查。

4. 开启 Rocket Loader 需谨慎

Rocket Loader 会尝试延迟加载 JavaScript，提高首屏加载速度。但它可能影响某些依赖执行顺序的脚本，例如统计代码、广告代码、地图组件、登录 SDK 等。

建议：

简单博客、静态网站可以尝试。
复杂 SPA、后台系统、电商网站不建议盲目开启。
如果开启后页面功能异常，应立即关闭。

四、缓存策略设计

Cloudflare 性能优化的关键在于缓存。缓存策略设计合理，源站压力可以明显下降；设计不合理，则可能导致用户看到旧页面、登录状态错乱，甚至数据泄露。

1. 静态资源缓存

静态资源一般包括：

.css
.js
.png
.jpg
.jpeg
.gif
.webp
.avif
.svg
.ico
.woff
.woff2
.ttf
.eot

这些资源通常适合长期缓存，尤其是带有 hash 的构建文件，例如：

/app.8f3a1c2.js
/style.92fae1.css
/logo.1df23.webp

这种文件名一旦内容变化，文件名也会变化，因此可以放心设置长缓存。

推荐缓存头：

Cache-Control: public, max-age=31536000, immutable

含义：

public：允许 CDN 和浏览器缓存。
max-age=31536000：缓存一年。
immutable：表示文件内容不会变化，浏览器无需重复验证。

2. HTML 页面缓存

HTML 页面是否缓存，需要看网站类型。

适合缓存 HTML 的场景

静态博客
文档网站
新闻详情页
产品介绍页
营销活动页
不含用户个性化内容的页面

不适合直接缓存 HTML 的场景

用户中心
后台管理
购物车
订单页
支付页
个性化推荐页面
登录后根据用户显示不同内容的页面

对于动态页面，可以使用更精细的规则，例如：

只缓存未登录用户访问的页面。
带 Cookie 时不缓存。
指定路径不缓存。
API 接口单独设置缓存策略。

五、Cloudflare Cache Rules 配置建议

Cloudflare 新版本中推荐使用 Cache Rules 来代替旧版 Page Rules。

进入：

Rules -> Cache Rules

规则一：静态资源长期缓存

匹配条件示例：

URI Path ends with .css
OR URI Path ends with .js
OR URI Path ends with .png
OR URI Path ends with .jpg
OR URI Path ends with .jpeg
OR URI Path ends with .gif
OR URI Path ends with .webp
OR URI Path ends with .avif
OR URI Path ends with .svg
OR URI Path ends with .ico
OR URI Path ends with .woff
OR URI Path ends with .woff2

配置建议：

Cache eligibility: Eligible for cache
Edge TTL: 1 month 或 1 year
Browser TTL: Respect origin 或 1 month

如果你的静态资源文件名带 hash，Edge TTL 可以设置为一年。

规则二：后台和登录页面不缓存

匹配路径：

/admin*
/login*
/user*
/account*
/cart*
/checkout*
/payment*
/api/*

配置建议：

Cache eligibility: Bypass cache

尤其是后台、购物车、订单、支付页面，必须避免缓存，否则可能造成严重问题。

规则三：博客文章页面缓存

如果你的网站是博客，可以为文章详情页设置缓存：

/blog/*
/post/*
/article/*

配置建议：

Cache eligibility: Eligible for cache
Edge TTL: 1 hour 到 1 day
Browser TTL: Respect origin

如果文章更新频率较低，可以设置更长时间。但如果经常更新文章，建议配合手动清缓存或自动清缓存机制。

六、源站 Nginx 缓存头配置源码

Cloudflare 是否缓存资源，很大程度上取决于源站返回的响应头。下面给出一个常用 Nginx 配置示例。

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.html index.htm;

    # HTML 页面：短缓存或不缓存
    location / {
        try_files $uri $uri/ /index.html;

        add_header Cache-Control "public, max-age=300" always;
    }

    # 静态资源：长期缓存
    location ~* \.(?:css|js|mjs|png|jpg|jpeg|gif|webp|avif|svg|ico|woff|woff2|ttf|eot)$ {
        expires 365d;
        add_header Cache-Control "public, max-age=31536000, immutable" always;
        access_log off;
    }

    # API 接口：不缓存
    location /api/ {
        proxy_pass http://127.0.0.1:3000;

        add_header Cache-Control "no-store, no-cache, must-revalidate, proxy-revalidate" always;
        add_header Pragma "no-cache" always;
        add_header Expires "0" always;
    }

    # 后台：不缓存
    location /admin/ {
        try_files $uri $uri/ /admin/index.html;

        add_header Cache-Control "no-store, no-cache, must-revalidate" always;
    }
}

这个配置的重点是：

静态资源使用长期缓存。
HTML 页面设置较短缓存。
API、后台、登录等敏感路径禁止缓存。
静态资源关闭 access log，减少日志压力。

七、Node.js / Express 缓存头源码

如果你的后端使用 Node.js Express，可以通过中间件设置缓存头。

import express from "express";
import path from "path";

const app = express();
const port = 3000;

// 静态资源长期缓存
app.use(
  "/assets",
  express.static(path.join(process.cwd(), "dist/assets"), {
    maxAge: "365d",
    immutable: true,
    setHeaders: (res) => {
      res.setHeader("Cache-Control", "public, max-age=31536000, immutable");
    },
  })
);

// HTML 页面短缓存
app.get("/", (req, res) => {
  res.setHeader("Cache-Control", "public, max-age=300");
  res.sendFile(path.join(process.cwd(), "dist/index.html"));
});

// API 不缓存
app.get("/api/user", (req, res) => {
  res.setHeader("Cache-Control", "no-store, no-cache, must-revalidate");
  res.json({
    id: 1,
    name: "demo",
  });
});

app.listen(port, () => {
  console.log(`Server running at http://localhost:${port}`);
});

如果是 SSR 项目，例如 Next.js、Nuxt、SvelteKit，也应根据页面类型设置不同缓存头。

八、Cloudflare Worker 边缘缓存源码

Cloudflare Workers 可以在边缘节点执行 JavaScript，非常适合实现更灵活的缓存逻辑。例如：

缓存 HTML 页面。
忽略部分查询参数。
登录用户绕过缓存。
对指定路径设置不同 TTL。
自定义缓存 Key。

下面是一个可直接参考的 Worker 示例。

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);

    // 只处理 GET 请求，其他请求直接回源
    if (request.method !== "GET") {
      return fetch(request);
    }

    // 后台、API、登录、用户中心不缓存
    const bypassPaths = [
      "/api/",
      "/admin",
      "/login",
      "/user",
      "/account",
      "/cart",
      "/checkout",
      "/payment",
    ];

    if (bypassPaths.some((path) => url.pathname.startsWith(path))) {
      return fetch(request, {
        cf: {
          cacheTtl: 0,
          cacheEverything: false,
        },
      });
    }

    // 如果请求包含登录 Cookie，则不缓存
    const cookie = request.headers.get("Cookie") || "";
    const isLoggedIn =
      cookie.includes("session=") ||
      cookie.includes("token=") ||
      cookie.includes("auth=");

    if (isLoggedIn) {
      return fetch(request, {
        cf: {
          cacheTtl: 0,
          cacheEverything: false,
        },
      });
    }

    // 静态资源长期缓存
    const staticExt = /\.(css|js|mjs|png|jpg|jpeg|gif|webp|avif|svg|ico|woff|woff2|ttf|eot)$/i;

    if (staticExt.test(url.pathname)) {
      return fetch(request, {
        cf: {
          cacheEverything: true,
          cacheTtl: 31536000,
        },
      });
    }

    // HTML 页面缓存 10 分钟
    const response = await fetch(request, {
      cf: {
        cacheEverything: true,
        cacheTtl: 600,
      },
    });

    const newResponse = new Response(response.body, response);

    newResponse.headers.set("Cache-Control", "public, max-age=300");
    newResponse.headers.set("X-Worker-Cache", "html-cache-600s");

    return newResponse;
  },
};

这个 Worker 的策略比较稳妥：

只缓存 GET 请求。
登录用户不缓存。
API 和敏感路径不缓存。
静态资源缓存一年。
普通 HTML 缓存 10 分钟。

如果你是博客或文档站，可以将 HTML 缓存时间提高到 1 小时甚至 1 天。

九、忽略无意义查询参数，提高缓存命中率

很多网站 URL 中会带有统计参数，例如：

?utm_source=google
?utm_medium=email
?fbclid=xxx
?gclid=xxx

这些参数通常不会影响页面内容，但会影响缓存 Key，导致同一个页面被缓存成多个版本，从而降低命中率。

可以使用 Worker 清理这些参数。

export default {
  async fetch(request) {
    const url = new URL(request.url);

    const removeParams = [
      "utm_source",
      "utm_medium",
      "utm_campaign",
      "utm_term",
      "utm_content",
      "fbclid",
      "gclid",
    ];

    for (const param of removeParams) {
      url.searchParams.delete(param);
    }

    const newRequest = new Request(url.toString(), request);

    return fetch(newRequest, {
      cf: {
        cacheEverything: true,
        cacheTtl: 600,
      },
    });
  },
};

这样可以减少重复缓存，提高 Cloudflare 缓存命中率。

十、使用 Cache API 精细控制缓存

如果你需要完全控制缓存读取和写入，可以使用 Cloudflare Workers 的 Cache API。

export default {
  async fetch(request, env, ctx) {
    const cache = caches.default;
    const url = new URL(request.url);

    if (request.method !== "GET") {
      return fetch(request);
    }

    if (url.pathname.startsWith("/api/")) {
      return fetch(request);
    }

    const cacheKey = new Request(url.toString(), request);
    let response = await cache.match(cacheKey);

    if (response) {
      const cachedResponse = new Response(response.body, response);
      cachedResponse.headers.set("X-Cache-Status", "HIT");
      return cachedResponse;
    }

    response = await fetch(request);

    // 只缓存 200 响应
    if (response.status === 200) {
      const responseToCache = new Response(response.body, response);
      responseToCache.headers.set("Cache-Control", "public, max-age=600");

      ctx.waitUntil(cache.put(cacheKey, responseToCache.clone()));

      responseToCache.headers.set("X-Cache-Status", "MISS");
      return responseToCache;
    }

    return response;
  },
};

这个示例可以帮助你判断缓存状态：

X-Cache-Status: HIT 表示命中边缘缓存。
X-Cache-Status: MISS 表示未命中，已回源并写入缓存。

十一、图片优化方案

图片通常是网页中体积最大的资源。Cloudflare 对图片优化有多种方式。

1. 使用 WebP / AVIF

如果你使用 Cloudflare Pro 或更高套餐，可以使用 Polish 自动优化图片。普通用户也可以在源站自行生成 WebP 或 AVIF。

前端示例：

优先级通常是：

AVIF > WebP > JPG/PNG

2. 图片懒加载

浏览器原生 loading="lazy" 可以减少首屏外图片加载。

3. 设置图片尺寸，避免 CLS

图片标签建议明确设置 width 和 height，避免页面加载过程中布局抖动。

错误示例：

推荐示例：

十二、前端项目构建优化

Cloudflare 可以优化网络传输，但前端资源本身也要足够合理。

以下是 Vite 项目的配置示例。

import { defineConfig } from "vite";

export default defineConfig({
  build: {
    target: "es2018",
    minify: "terser",
    cssCodeSplit: true,
    sourcemap: false,
    rollupOptions: {
      output: {
        entryFileNames: "assets/[name].[hash].js",
        chunkFileNames: "assets/[name].[hash].js",
        assetFileNames: "assets/[name].[hash].[ext]",
      },
    },
  },
});

这个配置的重点是生成带 hash 的文件名，便于长期缓存。

十三、缓存清理策略

缓存不是设置得越长越好，还必须配合清理策略。

Cloudflare 支持几种清缓存方式：

Purge Everything
清除全部缓存，简单但影响较大。
Purge by URL
只清除指定 URL，适合文章更新、产品更新。
Purge by Cache-Tag
企业级或高级场景适用，可以按标签清理。
API 自动清理
网站发布后自动调用 Cloudflare API 清缓存。

十四、Cloudflare API 清缓存源码

下面是使用 Node.js 调用 Cloudflare API 清除指定 URL 缓存的示例。

const zoneId = "你的 Zone ID";
const apiToken = "你的 Cloudflare API Token";

async function purgeCache(urls) {
  const response = await fetch(
    `https://api.cloudflare.com/client/v4/zones/${zoneId}/purge_cache`,
    {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiToken}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        files: urls,
      }),
    }
  );

  const result = await response.json();

  if (!result.success) {
    console.error("清除缓存失败：", result);
    return false;
  }

  console.log("清除缓存成功：", result);
  return true;
}

purgeCache([
  "https://example.com/",
  "https://example.com/blog/cloudflare-performance.html",
]);

如果你想清除全部缓存，可以使用：

body: JSON.stringify({
  purge_everything: true,
})

但不建议频繁使用全站清理，因为会导致大量请求回源，短时间内增加服务器压力。

十五、如何查看缓存是否生效

可以通过浏览器 DevTools 或 curl 查看响应头。

curl -I https://example.com/assets/app.abc123.js

重点关注以下响应头：

CF-Cache-Status: HIT
Cache-Control: public, max-age=31536000, immutable
Age: 12345

常见 CF-Cache-Status 含义：

状态	含义
HIT	命中 Cloudflare 缓存
MISS	未命中缓存，已回源
BYPASS	被规则或响应头绕过缓存
EXPIRED	缓存过期，重新回源
DYNAMIC	动态内容，未缓存
REVALIDATED	重新验证后使用缓存
STALE	使用过期缓存响应

如果你发现资源一直是 DYNAMIC 或 BYPASS，通常要检查：

是否开启了缓存规则。
源站是否返回了 no-cache 或 no-store。
请求是否带有 Cookie。
是否是非 GET 请求。
是否命中了 Bypass Cache 规则。
是否路径不符合缓存条件。

十六、SSL/TLS 优化设置

Cloudflare 的 SSL/TLS 模式建议使用：

Full 或 Full(strict)

不建议使用 Flexible，因为 Flexible 是浏览器到 Cloudflare 使用 HTTPS，而 Cloudflare 到源站可能使用 HTTP，容易产生重定向循环和安全隐患。

推荐配置：

SSL/TLS encryption mode: Full(strict)
Always Use HTTPS: On
Automatic HTTPS Rewrites: On
Minimum TLS Version: TLS 1.2
TLS 1.3: On

源站也应该配置有效证书。可以使用 Let’s Encrypt 免费证书，或者使用 Cloudflare Origin Certificate。

十七、源站真实 IP 获取配置

由于访问经过 Cloudflare，源站看到的 IP 可能是 Cloudflare 节点 IP。为了获取用户真实 IP，需要在 Nginx 中配置 real_ip_header。

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

real_ip_header CF-Connecting-IP;

配置后，Nginx 日志中就能更准确地记录用户真实 IP。

十八、减少源站暴露，提高稳定性

性能优化不仅是加速，也包括减少无效流量。建议：

只允许 Cloudflare IP 访问源站
防止攻击者绕过 Cloudflare 直接打源站 IP。
开启基础 WAF 规则
阻挡常见攻击请求。
限制 API 请求频率
对登录、注册、搜索等接口设置 Rate Limiting。
隐藏源站真实 IP
避免将源站 IP 暴露在 DNS 历史记录、邮件头、第三方接口中。

十九、常见问题排查

1. 为什么 Cloudflare 没有缓存我的页面？

可能原因包括：

页面返回 Cache-Control: no-store。
请求带有 Cookie。
页面是 POST 请求。
没有启用 Cache Everything。
命中了 Bypass Cache 规则。
URL 参数导致缓存 Key 不一致。

2. 为什么修改 CSS 后用户仍看到旧样式？

这通常是因为缓存时间较长。最佳解决方案不是缩短缓存，而是使用文件 hash。

例如：

style.abc123.css

修改后变成：

style.def456.css

这样浏览器和 Cloudflare 会认为它是新文件。

3. 是否应该缓存 API？

大多数用户相关 API 不应该缓存，例如：

/api/user
/api/order
/api/cart

但部分公共 API 可以缓存，例如：

/api/posts
/api/categories
/api/products/public

推荐设置短缓存，例如 30 秒到 5 分钟。

4. 是否需要同时使用源站 CDN 和 Cloudflare？

一般不建议多层 CDN 叠加，除非你很清楚缓存策略和回源逻辑。多层 CDN 可能导致：

缓存难以清理。
响应头混乱。
排查问题复杂。
回源链路变长。

二十、推荐的整体配置模板

如果你是普通博客、文档站或企业官网，可以采用以下模板：

DNS:
- 主域名和 www 开启 Proxied

SSL/TLS:
- Full(strict)
- TLS 1.3 开启
- Always Use HTTPS 开启

Speed:
- Brotli 开启
- HTTP/2 开启
- HTTP/3 开启
- Auto Minify 可选
- Rocket Loader 谨慎开启

Cache:
- 静态资源缓存 1 年
- HTML 页面缓存 5 到 60 分钟
- API、后台、登录、用户中心不缓存

Security:
- WAF 基础规则开启
- Rate Limiting 保护登录和 API
- 源站限制只允许 Cloudflare IP 访问

二十一、优化效果评估

配置完成后，可以使用以下工具测试：

Chrome DevTools Network 面板
Lighthouse
PageSpeed Insights
WebPageTest
GTmetrix
curl -I
Cloudflare Analytics

重点指标包括：

指标	优化目标
TTFB	越低越好，缓存命中后通常明显下降
FCP	首次内容绘制更快
LCP	最大内容绘制优化到 2.5 秒以内
CLS	尽量小于 0.1
缓存命中率	静态站点越高越好
回源请求数	越少越好
带宽消耗	源站带宽明显下降

如果优化后 TTFB 仍然很高，建议重点检查：

是否命中 Cloudflare 缓存。
源站是否响应过慢。
数据库查询是否存在瓶颈。
是否有大量第三方脚本阻塞页面。
首屏图片是否过大。

结语

Cloudflare 的性能优化并不是单个开关就能完成的事情，而是一套完整的缓存、压缩、协议、图片、源站和安全策略。对于大多数网站来说，最重要的优化方向是：静态资源长期缓存、HTML 页面按需缓存、敏感路径绕过缓存、开启 Brotli 和 HTTP/3、合理设置源站缓存头，并通过 Worker 实现更灵活的边缘逻辑。

如果你的网站是博客或文档站，Cloudflare 可以让大部分请求在边缘节点直接完成，极大减少源站压力。如果你的网站是电商、后台系统或会员站点，则需要更谨慎地处理 Cookie、登录状态和动态接口，避免错误缓存带来的数据风险。

最终建议是：先从基础优化开始，再逐步引入 Cache Rules、Workers 和 API 自动清缓存。每一步配置后都要通过响应头和性能工具验证效果，而不是凭感觉判断。只要缓存策略设计合理，Cloudflare 可以成为提升网站速度、稳定性和安全性的核心组件。

文章标签： Cloudflare 性能优化缓存策略 Workers

上一篇：站长必看：Cloudflare 加速、缓存与安全优化实战指南

下一篇：Cloudflare 加速实战：从缓存规则到 Worker 边缘优化源码指南

更多栏目