企业官网建设流程全解析

给自己维护的站点做统一改造时，我最大的体会是：现在的网络服务，真正需要管的不是一台服务器，而是链路里一串环节——域名解析、边缘缓存、安全过滤、访问控制、甚至一部分业务逻辑。我最后把这些环节全部叠到了 Cloudflare 上，这个东西在我这儿有个内部代号叫 cloudflare-os。它不是一个新操作系统，而是一套把“边缘当系统”的底座，DNS、CDN、WAF、边缘函数、存储都成了这套系统里的组件。这篇就讲讲我搭这套东西的过程，哪些配置值得学、哪些坑值得绕。适合正在做个人网站、小团队服务，或者想理清整套网络链路的人看。

1. 为什么是 Cloudflare：把网络链路叠成一套“系统”

1.1 Cloudflare 生态里的组件，各扮演什么角色

很多人对 Cloudflare 的印象停留在“换一下 NS 就能用”，然后看到橙色云朵亮了就觉得完事。但只要你想把它当“操作系统”用，就得把里面的组件逐一对应到传统架构里：

把这几个组件并排看，会发现一个很有意思的事实：传统架构里的“操作系统”是跑在服务器上的 Linux，而 cloudflare-os 是跑在全球网络上的“控制层”。你不再需要分别盯着 DNS 厂商、CDN 厂商、防火墙厂商的多个控制台，一套后台里能把请求从“用户输入网址”一路管到“源站返回内容”。

这也是我把它叫 OS 的核心理由：它提供了“进程管理”（请求路由）、 “文件系统”（R2/KV）、 “安全内核”（WAF/限速）、 “用户权限”（Access）这些操作系统才有的抽象能力。

1.2 三种常见落地形态，按需取用

不要一上来就把全家桶全开。根据业务复杂度，cloudflare-os 一般有三种玩法：

• 轻量形态：只做 DNS + CDN + 免费证书。静态站点、落地页、下载站用这套就够了，全部配置加起来不到半小时。
• 中间形态：轻量形态 + WAF + Cache Rules + 少量 Workers。适合有动态接口、需要登录鉴权、要考虑攻击防护的中型站点。
• 完整形态：中间形态 + Zero Trust + KV/R2 + Load Balancing。适合多个后端服务、多区域部署、需要统一身份认证的业务系统。

我自己是先把静态流量切到 CDN 观察了一周，再逐步开 WAF，最后才上 Workers。保险起见，每加一层都要留回滚方案。比如 Workers 脚本上线前先在预览环境模拟请求，WAF 规则先设成 Log 模式跑两天——这些细节后面都会讲到。

2. 基础接入：域名、DNS 与证书层的一次到位配置

2.1 域名迁移的第一步：改 NS

要把一个域名纳入 cloudflare-os，绕不开的一步就是把域名的 NS（Name Server）改成 Cloudflare 分配的 NS。具体操作很机械：

1. 在 Cloudflare 控制台添加站点，输入域名。
2. 选择合适的套餐（个人项目免费版往往够用，但注意免费版有的规则条数有限制）。
3. 控制台会给出两个形如xxx.ns.cloudflare.com的 NS 地址。
4. 去域名注册商的后台，把默认 NS 替换成这两个地址。
5. 回到 Cloudflare 控制台等待状态变为 Active。

这里有个容易迷惑的点：为什么不能只加一条 A 记录或 CNAME？因为 Cloudflare 边缘代理的机制是，它必须能“看到”你的 DNS 查询，才能把用户流量引导到最近的边缘节点，并在中间插入 WAF、缓存等能力。只做解析接入（灰云 DNS Only）也可以，但那就退化成普通 DNS 服务商了，橙色云朵的代理效果全部失效。

如果你用的域名本身就是在 Cloudflare 注册的，可以跳过改 NS，直接管理。域名转出/转入另说，但日常使用中这一步是最容易卡住新手的地方。改完 NS 以后，生效时间从几分钟到几十小时不等，我实测一般在 5～30 分钟内全球逐步生效。这段时间不要反复改 NS，等它收敛即可。

2.2 边缘证书：SSL/TLS 模式四选一

域名接入后，默认会发一张边缘证书，用户访问 HTTPS 时浏览器那侧是加密的。但“边缘到源站”这一段的加密程度，取决于你选的 SSL/TLS 模式：

我建议生产环境直接选Full (Strict)。理由很简单：Flexible 模式下，用户到边缘是加密的，但边缘到源站是明文，等于把后半段链路敞开。对需要登录态或涉及用户数据的系统，这不能接受。Full 模式虽然两端都加密，但源站证书可以无效，容易让 TLS 证书过期的问题被掩盖，等你排查半天才发现在源站。Full (Strict) 会强制校验源站证书的有效性，问题能尽早暴露。

顺带一提，边缘证书默认是自动续期的，免费额度够用。源站自己的证书如果用的 Let's Encrypt，记得配好自动续期，否则 Full (Strict) 模式下每个月都能收到一次监控告警。

2.3 渐进式接入：先灰云，再橙云

这是我最想强调的实操习惯。很多人第一次接入就立刻点亮橙色云朵（Proxied），结果出现白屏先怀疑 CDN，再怀疑源站，最后才发现是源站本身的路径配错，白白浪费两小时。

正确的渐进式接入流程：

1. 先在 DNS 记录里保持“DNS Only”（灰云），让域名直接解析到源站 IP。
2. 确认源站 HTTP/HTTPS 都能正常访问，各主要路径返回 200。
3. 再把默认记录切到“Proxied”（橙云），此时再访问域名，确认边缘证书、回源链路正常。
4. 最后逐条加上缓存规则、WAF 规则。

这样做的好处是可以把故障面一步步收窄。灰云阶段出错，基本就是源站问题或 DNS 解析问题；橙云阶段出错，才开始查边缘证书、回源设置、缓存策略。我自己给多个项目迁移时都用这套路，从来没出现过“切过去就崩、崩了不知道从哪查”的情况。

3. 调度规则：代理、缓存与边缘计算的分工协作

3.1 代理规则：把请求往对的方向赶

基础接入完成，流量已经能走边缘。接下来要解决的是“哪些请求走缓存、哪些请求回源、哪些请求要改写”。Cloudflare 的 Rules 引擎里有一组很顺手的工具：Redirect Rules、Origin Rules、Cache Rules、Configuration Rules。它们本质上是同一套规则引擎的不同动作，可以在一个界面里编排。

我常用的几种规则场景：

• HTTP 跳 HTTPS：所有请求匹配http协议，动作选“Redirect”，状态码 301，目标 URL 保留原路径。Cloudflare 也有全局的 Always Use HTTPS 开关，但用规则能精准控制特定路径。
• 裸域跳 www（或反过来）：匹配example.com域名，跳转到www.example.com，保留路径和查询参数。对 SEO 友好，也避免以后改 cookie domain 时出问题。
• API 路径不走缓存：匹配/api/*，设置 Cache Level 为 Bypass，直接回源。
• 指定路径走特定源站：如果你有多台后端，用 Origin Rule 按路径把/admin/*指向内网管理服务器的 Host Header。

写规则时有个细节：路径匹配用*通配时要注意泛匹配的范围。比如/api/*匹配/api/users，但如果你写/api*，那/api-docs也会被匹配进去，容易踩雷。建议在控制台用“Test”功能先验证匹配结果，再保存部署。

3.2 缓存规则怎么定：区分动态和静态

缓存是 CDN 的核心，但很多人要么不敢开，要么乱开。我总结的默认策略是“静态狠缓存，动态少缓存，HTML 看情况”。

一个可参考的基础配置：

配置里最容易忽略的是“Edge Cache TTL”和“Browser Cache TTL”的区别。Edge Cache TTL 指边缘节点缓存多久，Browser Cache TTL 指浏览器本地缓存多久。前者控制回源频率，后者控制用户二次访问时是否发请求。静态资源可以两端都拉长，但对动态接口，如果 Edge 不缓存但浏览器缓存了，用户仍然可能拿到旧数据。所以我会在动态接口的响应头里显式加Cache-Control: no-store，从源头掐掉浏览器缓存。

源站返回的 header 也很关键：开启 Cache Everything 后，边缘缓存规则会覆盖源站 header，但如果没有开 Cache Everything，默认行为基本是“尊重源站 header”。所以设计接口时，建议让后端口径统一：静态资源返回Cache-Control: public, max-age=31536000；动态接口返回no-store。这样即使未来某个边缘配置写漏了，缓存行为也不会太离谱。

3.3 Workers：只能轻，不能重

Workers 是 cloudflare-os 里最像“程序”的部分，也是最有意思的部分。它跑在边缘节点上，每个请求经过时都可以执行 JavaScript。我用它做过几件事：

• 给响应注入自定义 Header，例如标识环境的X-Env: staging。
• 把某些外部 API 的响应做格式转换，边缘直接改 JSON 结构。
• 对特定请求做地域维度的内容分发，给不同区域返回不同页面文案。
• 做一个简单的 AB 实验，按请求比例把流量切到不同源站 URL。

一个最简单的 Workers 脚本大概是这种感觉：

export default { async fetch(request, env, ctx) { const url = new URL(request.url); // 路径匹配：对 /v2/* 做改写 if (url.pathname.startsWith("/v2/")) { url.pathname = url.pathname.replace("/v2/", "/api/"); request = new Request(url, request); } const response = await fetch(request); const newHeaders = new Headers(response.headers); newHeaders.set("X-Owner", "cloudflare-os"); return new Response(response.body, { status: response.status, headers: newHeaders, }); }, };

部署方式用 Wrangler CLI 最顺手，wrangler.toml里指定路由匹配规则，然后wrangler deploy就上线了。

但我要给一个很实在的提醒：Workers 不是万能业务容器。它适合做轻量胶水层，不适合承载重逻辑。数据库长连接、大文件处理、复杂计算这些不要塞进去，否则你会被 CPU 时长限制和冷启动问题折磨。我遇到过团队把图片处理逻辑整个放进 Workers，结果边缘 CPU 时间跑满，请求大量超时。后来把图片处理拆成“生成后入 R2，边缘只做读取”，问题立刻解决。

4. 安全防线：WAF、限速与访问控制的落地配置

4.1 托管 WAF 规则集：开箱即用但要防误伤

Cloudflare 的 WAF 有托管规则集，默认包含 Cloudflare 托管规则集和 OWASP 核心规则集。它们能识别常见的 SQL 注入、XSS、文件包含、恶意 Bot 等请求。对大多数中小业务来说，直接开启默认规则集就能挡掉一批低质量攻击。

但这里有个大坑：托管规则集的泛化检测会误伤合法流量。尤其当你的系统自己会在 URL 里传一些攻击特征字符串（比如搜索框里搜“select * from users”），很可能被判定为 SQL 注入拦截。

所以我的流程是：

1. 先打开 WAF 规则集，状态设为Log（只记录，不拦截）。
2. 观察 24～48 小时，去 Security Events 里看匹配记录。
3. 确认没有误伤正常业务后，再把规则集切到Block。
4. 之后定期回看日志，发现新的误伤时，通过“加白名单规则”或“例外规则”处理，而不是直接关掉规则集。

另外，托管规则集是全局生效的，如果你只想保护登录接口，建议单独加一条“按路径”的自定义规则。比如：

• 匹配：uri-path contains /wp-login.php或/api/login
• 动作：Block + 挑战（Managed Challenge 或 JS Challenge）
• 理由：登录接口面对的是全互联网的暴力破解，值得单独加重防护。

4.2 速率限制：从登录接口开始

速率限制规则的作用是防止单 IP 短时间大量请求。典型的配置是：

配置时注意：单纯按 IP 限速会误伤 NAT 之后的用户，尤其是学校、公司这种出口 IP 是共享的场景。更稳妥的做法是加维度的组合，比如“IP + User-Agent + 路径”。Cloudflare 控制台里可以自定义匹配表达式，把 UA 或 ASN 放进去，精确度会明显提高。

我踩过的坑是：刚上线一条“整站 60 秒内 200 次请求就封锁”的规则，结果一个办公室出口 IP 下几十人同时访问，直接集体 429。后来我把阈值调高，并且给静态资源路径排除掉，只对动态 API 限速，才算稳定。

4.3 后台入口的零信任保护

如果系统里有管理后台或内部工具，建议不要让它裸奔在公网。Cloudflare 的 Zero Trust Access 可以做一层身份代理：没有通过身份认证的请求直接被挡在边缘之外。

我常用的配置是管理员后台访问策略：

1. 在 Zero Trust 控制台创建应用，添加后台域名和路径。
2. 配置 Access Group，例如只允许特定邮箱后缀或特定身份提供商的成员访问。
3. 设置策略动作：允许/拒绝/Require。
4. 可选开启一次性的 PIN 邮件验证码，或对接已有的企业 SSO。

流程走一遍之后，即使后台 IP 暴露在公网，没有通过身份代理的请求也到不了源站。这套方案比传统“把后台锁在固定 IP 白名单里”更灵活：管理员出差换网络也不用临时加 IP。

5. 真实环境里的坑：缓存、误杀与排错实战

5.1 改了源站但页面死活不更新的缓存问题

这是 cloudflare-os 使用者最容易崩溃的问题。现象是：源代码部署了，刷新浏览器还是旧页面。

常见原因：

• 浏览器缓存：旧页面 / 静态资源被浏览器本地缓存，优先在 DevTools 里勾选 Disable cache 再判断。
• 边缘缓存：Edge Cache TTL 太长，节点上的旧内容没过期。
• Cache Everything 规则覆盖：你把一个动态路径设成了 Cache Everything，源站更新后边缘仍然返回旧响应。

排查顺序是：

1. 看响应头里的cf-cache-status：HIT表示边缘缓存命中，EXPIRED表示过期但可能返回旧数据，REVALIDATED表示重新校验过。
2. 临时开启 Cloudflare 的“Development Mode”，让边缘缓存全局失效半小时，确认是否边缘问题。
3. 如果确认是边缘缓存，手动 Purge。Purge 有按 URL 清除、按 Cache Tag 清除、全站清除三种。生产环境建议用 Cache Tag，因为它可以精准清除某类资源，不误伤全站。
4. 长期解法是“资源版本化”：给静态资源文件名加 hash（app-3f2a1c.js），或用 URL 查询参数?v=20240601。这样即使缓存策略很激进，版本一变就相当于新 URL，不会命中旧缓存。

我现在的习惯是：凡是需要更新后立刻生效的页面，一律不做长缓存；凡是能长期缓存的资源，一律文件名 hash 化。两条规则各管一边，互不冲突。

5.2 被边缘节点“误杀”的访客：Security Events 排错

运营一段时间后，不可避免会遇到“用户反馈访问不了，但你自己打开正常”的情况。这类问题的典型原因是被 WAF 或 Bot 管理拦截了。

第一件事不是改代码，而是去Security Events页面查看拦截记录。按时间过滤、按域名过滤，很快能找到被 Block 的请求。界面里会显示命中规则的名字、规则 ID、攻击类型，以及对应的访问者 IP / ASN / Country。

如果确认是误杀：

• 把对应规则从 Block 改成 Log，观察是否恢复。
• 或者加一条 Exception，把特定路径、特定 IP 段、特定 UA 排除出去。
• 不要一上来就关闭 WAF 全局开关，那等于把之前积累的规则全部作废。

还有一个小技巧：访问者被拦截后，响应里往往带有一个cf-ray值，格式类似LHR-1234-ABCD。让用户把这个值发给你，配合 Security Events 搜索 Ray ID，就能精准定位到那一瞬间的请求记录。这个信息比“我打不开网页”有效一百倍。

5.3 从边缘到源站的完整排错链路

一套系统跑久了，总要遇到“时好时坏”的玄学问题。我现在排错基本按这条链路走：

1. 浏览器 DevTools → Network 面板，看响应头。重点看cf-cache-status、server、cf-ray三兄弟。
2. 如果server: cloudflare且状态正常，说明边缘层没问题，继续往下查。
3. 在 Cloudflare Analytics 里看该路径的请求量、缓存命中率、状态码分布。如果发现大量 5xx，大概率是源站或回源链路问题。
4. Workers 有脚本的话，可以在 dashboard 的 Workers Logs 看打印日志，或wrangler tail实时看请求进入 Workers 后的执行情况。
5. 最后看源站自己的 Nginx/应用日志，确认是不是应用崩溃、数据库连接超时。

表格总结一下：

有了这条链路，大多数问题都能在十分钟内定位到具体层级，而不是到处乱翻。

6. 面向边缘做架构：从“跑在服务器上”到“跑在整套云上”

6.1 Cache-First：把边缘当成读层

只要系统接入了 cloudflare-os，设计接口时就要开始考虑“这个请求能不能让边缘帮我挡一挡”。最直接的设计是 Cache-First：能缓存的先缓存，不能缓存的再回源。

一个务实的实践是对只读接口做“短缓存 + 异步失效”：

• 接口返回头写Cache-Control: public, s-maxage=60
• 边缘节点 60 秒内不再回源，直接返回缓存
• 数据更新后，调用 Cache Purge API 按 URL 清掉该接口缓存，或者等 60 秒自然过期

这样做的好处是：即使某个接口被刷爆，源站压力也被限制在“每 60 秒最多一次回源”，而不是“每秒几十次回源”。对数据库和带宽都比较友好。

但要注意隐私：带用户信息的接口不要盲目缓存。哪怕设了短 TTL，也要确认响应里没有用户 A 的数据缓存给用户 B。我一般只对全站公共内容做 Cache-First，用户维度数据一律no-store。

6.2 把状态搬上边缘：KV 与 Durable Objects

Workers 本身是无状态的，所以有人觉得做不了有状态系统。其实 Cloudflare 提供了 KV、Durable Objects 这类边缘存储。KV 的用法像全局字典，读写简单，适合存配置开关、公告内容、AB 实验标记：

// 读取 KV const content = await env.CONFIG.get("homepage_banner"); // 写入 KV await env.CONFIG.put("homepage_banner", JSON.stringify({text: "hello"}, {expirationTtl: 3600}));

KV 是最终一致性的，写入后有短暂的传播延迟。我刚才说适合存“配置开关、公告、实验标记”，绝不是让你把订单状态、余额这种强一致要求的数据放进去。真要强一致，得考虑 Durable Objects。不过 Durable Objects 的学习曲线稍陡，我建议先用 KV 解决 80% 的边缘状态需求，保持简单。

6.3 指标与日志：怎么知道这套“系统”还健不健康

组件越多，可观测性越重要。我的监控面板里常看几个指标：

• 缓存命中率：免费版即可在 Caching 页面看到，长期低于 50% 说明缓存策略太保守或有大量不可缓存请求。
• 5xx 状态码分布：关注 521/522/523/524 这几种。521 表示源站拒绝连接，524 表示回源超时，基本都能明确指向源站问题。
• 安全事件趋势：Security Events 里看拦截量有没有突增，突然暴涨往往意味着有人在扫端口或试密码。
• 请求量带宽：Cloudflare 的 Analytics 首页就能看，设置告警阈值后可以掌握突发的流量。

Cloudflare 还提供了 GraphQL Analytics API，可以拉取 httpRequests1dGroups 这类数据，做自定义报表。如果你有内部运维面板，直接把这个 API 接进去，比每天手抄数据高效得多。

我最喜欢的一点是，所有指标在同一个控制台里聚合，不用再在 DNS 厂商、CDN 厂商、WAF 厂商之间来回切换。这也是 cloudflare-os 这个名字在我心里越来越有说服力的原因：它把不同层面的基础设施抽象成一个统一界面，你管理的是“系统”，而不是一组彼此割裂的单点工具。

这套东西不是一两天搭完的。我最早只是给一个静态博客换 NS，后面慢慢加了 WAF、速率限制、Workers、KV，最后发现整个技术栈的入口都被这套边缘架构收拢了。现在再让我回退到“一台 VPS 裸奔 + 一个 DNS 控制台”的状态，我会觉得浑身难受。如果你也想往这个方向走，我唯一的建议是别贪多，先把最核心的静态流量切过去跑两周，稳定后再逐步加动态规则和边缘逻辑。等哪天你习惯在控制台里一次看完缓存命中率、安全事件和回源状态时，大概也就理解为什么我说它像一套 OS 了。