Cloudflare 最新更新内容汇总｜附配置文件

Cloudflare 近几年已经不再只是传统意义上的 CDN 服务商，而是逐步发展成覆盖 CDN 加速、安全防护、边缘计算、对象存储、数据库、零信任访问、AI 网关、开发者平台 等多个方向的一体化云平台。对于站长、开发者、企业运维团队来说，Cloudflare 的更新频率非常高，如果不定期梳理，很容易错过一些能够显著提升网站性能、安全性和开发效率的新功能。

本文将围绕 Cloudflare 近期重点更新内容进行系统汇总，并附上常用配置文件示例，方便你快速用于实际项目中。

一、Cloudflare 更新方向总览

从整体趋势来看，Cloudflare 的最新更新主要集中在以下几个方面：

1. 安全能力持续增强
   包括 WAF 托管规则、Bot 管理、DDoS 防护、API Shield、Turnstile 验证、零信任访问等。

2. 开发者平台能力扩展
   Workers、Pages、R2、D1、Queues、Durable Objects、KV、Hyperdrive 等产品不断完善，越来越接近完整的边缘应用开发平台。

3. AI 相关服务加速布局
   Workers AI、AI Gateway、Vectorize 等服务逐渐成为 Cloudflare 生态中的重要组成部分。

4. 规则系统统一与现代化
   Page Rules 逐步被 Cache Rules、Redirect Rules、Origin Rules、Configuration Rules 等新规则体系替代，配置逻辑更清晰。

5. 零信任与企业网络能力增强
   Cloudflare Zero Trust、Access、Gateway、Tunnel 等功能持续升级，帮助企业减少公网暴露面。

6. 性能优化更加精细化
   Brotli、HTTP/3、Early Hints、Argo Smart Routing、Tiered Cache、Cache Reserve 等功能持续优化站点访问速度。

二、Cloudflare CDN 与缓存规则更新

Cloudflare 最核心的能力依然是 CDN 加速。过去很多用户主要依赖 Page Rules 来配置缓存、重定向和安全策略，但现在 Cloudflare 正在推动更细分的规则体系，例如：

• Cache Rules
• Redirect Rules
• Origin Rules
• Configuration Rules
• Transform Rules
• Compression Rules

这些规则相比旧版 Page Rules 更灵活，也更适合大型站点或复杂业务。

1. Cache Rules 替代传统 Page Rules

以往我们可能通过 Page Rules 设置：

example.com/*
Cache Level: Cache Everything
Edge Cache TTL: 1 month

现在更推荐使用 Cache Rules。

常见配置策略如下：

2. 推荐缓存策略

对于普通网站，可以采用以下思路：

• 静态资源：缓存 30 天或更久；
• 图片、CSS、JS：开启浏览器缓存；
• API 接口：默认不缓存；
• 登录页、后台页：不缓存；
• 首页和文章页：如果内容不频繁变化，可以适度缓存；
• 使用版本号文件名，例如 app.a8f3c2.js，方便长期缓存。

三、Cloudflare Workers 更新

Cloudflare Workers 是 Cloudflare 开发者平台中最重要的产品之一。它允许开发者在 Cloudflare 边缘节点运行 JavaScript、TypeScript、Rust、Python 等代码，从而实现 API 网关、边缘鉴权、请求改写、A/B 测试、反向代理、轻量后端服务等能力。

近年来 Workers 的重点更新包括：

• 更完善的运行时支持；
• 与 R2、D1、KV、Queues、Durable Objects 深度集成；
• 本地开发体验增强；
• wrangler 工具不断升级；
• 支持更复杂的全栈应用部署；
• 与 AI Gateway、Workers AI 结合构建 AI 应用。

1. Workers 常见使用场景

Cloudflare Workers 可以用于：

1. 接口转发；
2. 隐藏源站地址；
3. 动态修改响应头；
4. 实现鉴权逻辑；
5. 根据地区返回不同内容；
6. 静态站点增强；
7. 构建轻量级 API；
8. 调用 AI 模型接口；
9. 作为边缘中间层；
10. 实现自定义缓存逻辑。

四、Workers 配置文件示例

以下是一个常用的 wrangler.toml 配置文件示例。

name = "cloudflare-demo-worker"
main = "src/index.ts"
compatibility_date = "2025-01-01"

workers_dev = true

[vars]
ENVIRONMENT = "production"
API_BASE_URL = "https://api.example.com"

[[kv_namespaces]]
binding = "CACHE_KV"
id = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

[[r2_buckets]]
binding = "ASSETS_BUCKET"
bucket_name = "demo-assets"

[[d1_databases]]
binding = "DB"
database_name = "demo-db"
database_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

如果你更习惯使用 wrangler.jsonc，也可以这样写：

{
  "name": "cloudflare-demo-worker",
  "main": "src/index.ts",
  "compatibility_date": "2025-01-01",
  "workers_dev": true,
  "vars": {
    "ENVIRONMENT": "production",
    "API_BASE_URL": "https://api.example.com"
  },
  "kv_namespaces": [
    {
      "binding": "CACHE_KV",
      "id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    }
  ],
  "r2_buckets": [
    {
      "binding": "ASSETS_BUCKET",
      "bucket_name": "demo-assets"
    }
  ],
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "demo-db",
      "database_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
    }
  ]
}

Workers 示例代码

下面是一个简单的 Workers 反向代理示例：

export default {
  async fetch(request: Request, env: Env): Promise {
    const url = new URL(request.url)

    if (url.pathname.startsWith('/api/')) {
      const targetUrl = env.API_BASE_URL + url.pathname + url.search

      const proxyRequest = new Request(targetUrl, {
        method: request.method,
        headers: request.headers,
        body: request.body
      })

      const response = await fetch(proxyRequest)

      return new Response(response.body, {
        status: response.status,
        headers: {
          ...Object.fromEntries(response.headers),
          'X-Proxy-By': 'Cloudflare Workers'
        }
      })
    }

    return new Response('Hello Cloudflare Workers!', {
      headers: {
        'Content-Type': 'text/plain;charset=UTF-8'
      }
    })
  }
}

五、Cloudflare Pages 更新

Cloudflare Pages 是面向前端项目的部署平台，适合部署静态网站、文档站、博客、单页应用以及前后端一体项目。它支持与 GitHub、GitLab 集成，可以在代码提交后自动构建并部署。

Cloudflare Pages 近期重点变化主要体现在：

• Pages Functions 与 Workers 的能力进一步靠拢；
• 支持更多框架适配；
• 构建和预览环境更加清晰；
• 支持与 D1、R2、KV 等绑定；
• 更适合部署全栈前端项目；
• Pages 与 Workers 的边界逐渐模糊。

Pages 项目常用配置

假设你使用 Vite、Vue、React 或 Astro 构建项目，常见构建配置如下：

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  }
}

Cloudflare Pages 控制台中可设置：

Build command: npm run build
Build output directory: dist
Root directory: /

六、Pages 的 _headers 配置文件

Cloudflare Pages 支持在项目根目录或输出目录中使用 _headers 文件配置响应头。

示例：

/*
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()

/assets/*
  Cache-Control: public, max-age=31536000, immutable

/*.html
  Cache-Control: public, max-age=300

这个配置适合大多数前端项目：

• 给全站添加基础安全响应头；
• 对静态资源设置长期缓存；
• 对 HTML 文件设置短缓存，避免页面更新不及时。

七、Pages 的 _redirects 配置文件

如果你需要做重定向，可以使用 _redirects 文件。

# HTTP 301 永久重定向
/old-page /new-page 301

# 单页应用路由回退
/* /index.html 200

# 外部跳转
/github https://github.com/example 302

对于 React Router、Vue Router、SvelteKit 等前端路由应用，通常需要添加：

/* /index.html 200

否则用户刷新二级页面时可能出现 404。

八、Cloudflare R2 更新

Cloudflare R2 是对象存储服务，最大的特点之一是没有传统对象存储中常见的出口流量费用。它非常适合用于：

• 图片存储；
• 视频文件存储；
• 静态资源托管；
• 备份文件；
• 用户上传文件；
• 软件分发；
• 与 Workers 结合构建文件服务。

R2 支持 S3 兼容 API，因此很多现有工具可以直接迁移使用。

R2 与 Workers 绑定配置

name = "r2-file-service"
main = "src/index.ts"
compatibility_date = "2025-01-01"

[[r2_buckets]]
binding = "BUCKET"
bucket_name = "my-public-assets"

R2 文件读取示例

export default {
  async fetch(request: Request, env: Env): Promise {
    const url = new URL(request.url)
    const key = url.pathname.slice(1)

    if (!key) {
      return new Response('Missing file key', { status: 400 })
    }

    const object = await env.BUCKET.get(key)

    if (!object) {
      return new Response('File not found', { status: 404 })
    }

    return new Response(object.body, {
      headers: {
        'Content-Type': object.httpMetadata?.contentType || 'application/octet-stream',
        'Cache-Control': 'public, max-age=86400'
      }
    })
  }
}

九、Cloudflare D1 更新

D1 是 Cloudflare 提供的无服务器 SQL 数据库，基于 SQLite，适合轻量级后端、博客系统、配置系统、小型 SaaS、边缘 API 等场景。

D1 的优势在于：

• 与 Workers 原生集成；
• 使用 SQL，学习成本低；
• 不需要维护数据库服务器；
• 适合边缘应用；
• 适合中小规模数据场景。

D1 配置示例

name = "d1-api-demo"
main = "src/index.ts"
compatibility_date = "2025-01-01"

[[d1_databases]]
binding = "DB"
database_name = "blog-db"
database_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

D1 查询示例

export default {
  async fetch(request: Request, env: Env): Promise {
    const result = await env.DB.prepare(
      'SELECT id, title, created_at FROM posts ORDER BY created_at DESC LIMIT 10'
    ).all()

    return Response.json({
      success: true,
      data: result.results
    })
  }
}

十、Cloudflare Zero Trust 与 Tunnel 更新

Cloudflare Zero Trust 是企业安全访问的重要组成部分。它可以帮助团队在不暴露源站公网 IP 的情况下访问内部服务。

常见使用场景包括：

• 内网服务远程访问；
• 替代传统 VPN；
• SSH/RDP 安全访问；
• 后台管理系统访问控制；
• 内部 API 保护；
• 公司设备访问策略管理。

Cloudflare Tunnel 则可以让你的本地服务或内网服务通过 Cloudflare 安全暴露到公网，无需开放服务器端口。

cloudflared 配置文件示例

文件路径通常为：

~/.cloudflared/config.yml

示例配置：

tunnel: my-demo-tunnel
credentials-file: /root/.cloudflared/my-demo-tunnel.json

ingress:
  - hostname: app.example.com
    service: http://localhost:3000

  - hostname: api.example.com
    service: http://localhost:8080

  - hostname: ssh.example.com
    service: ssh://localhost:22

  - service: http_status:404

启动命令：

cloudflared tunnel run my-demo-tunnel

如果配合 Cloudflare Access，可以对 app.example.com 添加登录验证，只允许指定邮箱、组织成员或身份提供商用户访问。

十一、Cloudflare Turnstile 更新

Turnstile 是 Cloudflare 推出的验证码替代方案。相比传统验证码，Turnstile 更注重用户体验，很多情况下用户无需点击图片或输入字符即可完成验证。

它适合用于：

• 登录页；
• 注册页；
• 评论系统；
• 表单提交；
• API 防刷；
• 下载页；
• 联系表单。

前端示例：

  

  

  

  提交

服务端需要校验 cf-turnstile-response，不能只在前端展示组件，否则容易被绕过。

十二、Cloudflare WAF 与安全规则更新

Cloudflare WAF 是网站安全防护的重要模块。新版 WAF 更强调托管规则、表达式规则和规则集管理。

推荐开启或配置：

1. Cloudflare Managed Rules；
2. OWASP Core Ruleset；
3. Bot Fight Mode 或 Bot 管理；
4. Rate Limiting；
5. API Shield；
6. IP、ASN、国家或地区访问控制；
7. 后台路径保护；
8. User-Agent 过滤；
9. 挑战可疑请求；
10. 阻止高风险请求方法。

WAF 表达式示例

拦截后台路径的异常访问：

(http.request.uri.path starts_with "/admin" and ip.geoip.country not in {"CN" "SG"})

拦截可疑 User-Agent：

(http.user_agent contains "sqlmap" or http.user_agent contains "nikto")

限制非必要请求方法：

not http.request.method in {"GET" "POST" "HEAD"}

针对 API 路径启用更严格规则：

http.request.uri.path starts_with "/api/"

十三、Cloudflare AI Gateway 与 Workers AI 更新

Cloudflare 近年在 AI 基础设施方向投入明显增加。AI Gateway 可以作为 AI 请求的统一网关，用于监控、缓存、限流和分析模型调用情况。Workers AI 则允许开发者直接在 Cloudflare 平台调用部分 AI 模型。

这些服务适合：

• AI 聊天应用；
• 文本摘要；
• 文本分类；
• 向量搜索；
• 图片理解；
• 内容审核；
• 智能客服；
• 多模型代理；
• 控制 AI API 成本。

AI Gateway 使用思路

传统调用方式可能是：

应用服务器 -> OpenAI / Anthropic / 其他模型服务

使用 AI Gateway 后可以变成：

应用服务器或 Workers -> Cloudflare AI Gateway -> 模型服务

这样可以统一管理请求日志、缓存策略和调用分析。

十四、Terraform 配置 Cloudflare 示例

对于企业团队而言，手动在控制台配置规则并不利于长期维护。更推荐使用 Terraform 管理 Cloudflare DNS、规则、Zero Trust 或 Workers 相关资源。

下面是一个简化版 DNS 配置示例：

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 4.0"
    }
  }
}

provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

variable "cloudflare_api_token" {}
variable "zone_id" {}

resource "cloudflare_record" "www" {
  zone_id = var.zone_id
  name    = "www"
  value   = "example.pages.dev"
  type    = "CNAME"
  proxied = true
}

resource "cloudflare_record" "api" {
  zone_id = var.zone_id
  name    = "api"
  value   = "192.0.2.10"
  type    = "A"
  proxied = true
}

使用 Terraform 的好处是：

• 配置可版本化；
• 方便回滚；
• 便于多人协作；
• 避免人为误操作；
• 适合多环境部署。

十五、推荐的 Cloudflare 基础配置清单

如果你正在搭建一个新站点，可以参考以下基础配置。

1. DNS

• 将主域名和 www 接入 Cloudflare；
• 静态站点可使用 CNAME 指向 Pages；
• 后端服务可以使用 Tunnel 或源站 IP；
• 能开启代理的记录尽量开启橙云代理。

2. SSL/TLS

推荐配置：

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

如果源站有有效证书，建议使用：

Full (strict)

不要长期使用 Flexible 模式，因为它可能导致源站与 Cloudflare 之间不是 HTTPS，存在安全隐患。

3. 缓存

推荐：

Brotli: On
HTTP/3: On
Early Hints: On
Tiered Cache: On

静态资源建议：

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

API 和后台页面建议：

Cache-Control: no-store

4. 安全

建议开启：

WAF Managed Rules: On
Bot Fight Mode: On
Rate Limiting: 按需开启
Turnstile: 表单场景开启
Cloudflare Access: 后台系统开启

5. 源站保护

接入 Cloudflare 后，不应让攻击者绕过 Cloudflare 直接访问源站。建议：

• 源站防火墙只允许 Cloudflare IP；
• 使用 Cloudflare Tunnel 隐藏源站；
• 后台系统增加 Access；
• API 增加 Token 鉴权；
• 定期检查 DNS 历史泄露；
• 禁止源站直接暴露管理端口。

十六、完整示例：前端 Pages + API Workers + R2 + D1

下面给出一个较完整的项目结构示例：

my-cloudflare-app/
├── public/
│   ├── _headers
│   └── _redirects
├── src/
│   ├── index.ts
│   └── worker.ts
├── package.json
├── wrangler.toml
└── README.md

wrangler.toml

name = "my-cloudflare-app"
main = "src/worker.ts"
compatibility_date = "2025-01-01"

[vars]
APP_ENV = "production"

[[r2_buckets]]
binding = "UPLOAD_BUCKET"
bucket_name = "my-upload-bucket"

[[d1_databases]]
binding = "DB"
database_name = "my-app-db"
database_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

_headers

/*
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin

/assets/*
  Cache-Control: public, max-age=31536000, immutable

/api/*
  Cache-Control: no-store

_redirects

/* /index.html 200

worker.ts

export default {
  async fetch(request: Request, env: Env): Promise {
    const url = new URL(request.url)

    if (url.pathname === '/api/posts') {
      const result = await env.DB.prepare(
        'SELECT id, title, created_at FROM posts ORDER BY created_at DESC LIMIT 20'
      ).all()

      return Response.json({
        success: true,
        data: result.results
      })
    }

    if (url.pathname.startsWith('/files/')) {
      const key = url.pathname.replace('/files/', '')
      const object = await env.UPLOAD_BUCKET.get(key)

      if (!object) {
        return new Response('Not Found', { status: 404 })
      }

      return new Response(object.body, {
        headers: {
          'Cache-Control': 'public, max-age=86400'
        }
      })
    }

    return new Response('Cloudflare App Running', {
      headers: {
        'Content-Type': 'text/plain;charset=UTF-8'
      }
    })
  }
}

十七、升级与迁移建议

如果你已经使用 Cloudflare 较长时间，可以重点检查以下内容：

1. 将旧 Page Rules 逐步迁移到新 Rules 系统
   新规则体系更灵活，也更符合 Cloudflare 后续发展方向。

2. 检查 SSL/TLS 模式
   尽量使用 Full 或 Full Strict，不建议继续依赖 Flexible。

3. 为后台系统添加 Access
   即使后台本身有账号密码，也建议增加一层 Cloudflare Access。

4. 为表单增加 Turnstile
   登录、注册、评论、联系表单都适合接入。

5. 使用 R2 替代部分对象存储场景
   尤其是图片、附件、下载文件等场景。

6. 使用 Workers 构建边缘逻辑
   不必所有请求都回源，可以把鉴权、缓存、转发、轻量 API 放在边缘处理。

7. 使用 Terraform 管理重要配置
   对企业项目尤其重要，可以减少配置漂移。

十八、总结

Cloudflare 的最新更新体现出一个非常清晰的趋势：它正在从 CDN 和安全防护平台，升级为面向现代应用的全球边缘云平台。对于普通站长来说，Cloudflare 可以帮助网站获得更好的访问速度、更强的 DDoS 防护和更简单的 HTTPS 配置；对于开发者来说，Workers、Pages、R2、D1、KV、Queues 等服务已经可以支撑不少轻量级全栈应用；对于企业来说，Zero Trust、Tunnel、WAF、Access 和 Gateway 则可以显著提升整体安全架构。

如果你只是搭建普通网站，建议优先配置好 DNS、SSL、缓存、安全规则和 Turnstile。如果你是开发者，则可以进一步尝试 Workers + R2 + D1 + Pages 的组合。对于企业团队，建议引入 Zero Trust、Tunnel、WAF 托管规则和 Terraform，将 Cloudflare 配置纳入长期工程化管理。

总体来看，Cloudflare 的价值已经不只是“给网站套一层 CDN”，而是可以成为网站性能优化、安全防护、边缘开发和企业访问控制的重要基础设施。合理使用这些最新功能，可以让你的应用更快、更安全，也更容易维护。