公开摘要
这篇文章把一次域名防护与静态站部署笔记公开化：不保留真实域名、服务器地址、仓库名称或内部配置值，只抽象出可复用的配置顺序和排障思路。你可以把它当成一份上线 runbook：先确认谁是权威 DNS，再决定哪些记录走代理，最后把源站、防火墙、Pages 和 SSL 状态串成闭环。
整体架构：先定义流量应该怎么走
接入 Cloudflare 的目标不是“多一个 DNS 面板”，而是把公网访问路径改造成可控链路。静态站可以直接落在 Cloudflare Pages；需要访问云服务器的业务，则由 Cloudflare 代理到源站。两类流量都应由 Cloudflare 统一承接证书、缓存、防火墙和访问策略。
访客浏览器 → Cloudflare DNS → Cloudflare Pages →（CNAME / 自动记录）静态站
因此，域名接入后需要同时完成三件事：注册商处的 NS 切换、Cloudflare DNS 记录补齐、源站防火墙收口。缺少任意一环，都可能出现“看起来接入了，但源站仍可被直连”或“静态站绑定成功但 HTTPS 不稳定”的问题。
| 层级 | 负责内容 | 公开示例 | 上线判断 |
|---|---|---|---|
| 注册商 | 设置权威 NS | Cloudflare 分配的两组 NS | 权威查询返回 Cloudflare NS |
| Cloudflare DNS | 维护 A / CNAME / TXT 等记录 | @、www、docs | 记录不再散落在旧 DNS 面板 |
| Cloudflare Proxy | 代理、WAF、证书、缓存 | 橙色云朵 | Web 流量显示经过 Cloudflare |
| 源站防火墙 | 限制直连入口 | 仅放行 Cloudflare 官方 IP 段 | 非代理来源不能访问 Web 端口 |
DNS 接管：让 Cloudflare 成为权威来源
Cloudflare 防护的入口是 DNS 接管。添加站点后，Cloudflare 会给出两组 Name Server；需要到域名注册商或云厂商域名管理处，把原 DNS 服务商的 NS 替换掉。切换后，旧云厂商解析面板出现“未接管”“DNS 服务器不正确”之类提示是正常现象，因为它已经不再是权威解析来源。
- 在 Cloudflare 添加站点，选择合适计划，先让系统扫描现有记录。
- 核对扫描出的记录：保留 Web、邮箱、验证类必要记录；删除明显过期或未知用途记录。
- 到注册商处修改 NS，只填写 Cloudflare 提供的两组 NS，不混用旧服务商 NS。
- 等待权威 NS 生效后，再统一到 Cloudflare DNS 面板维护后续记录。
- 用多个网络环境访问根域名和关键子域名，确认解析来源和页面表现一致。
DNS 生效具有缓存和递归链路差异，不同地区、运营商、终端可能先后不一致。上线窗口里不要一边在旧 DNS 面板改记录、一边在 Cloudflare 改记录，否则排障时无法判断到底是哪一层返回了旧值。
| 记录类型 | 用途 | 适合场景 | 常见错误 |
|---|---|---|---|
| A | 域名指向 IPv4 地址 | 根域名或子域名访问云服务器 | 开启代理后仍未收口源站防火墙 |
| CNAME | 域名指向另一个域名 | Pages、GitHub Pages、Vercel 等托管服务 | 把目标误写成 IP，或自行添加 www 前缀 |
| TXT | 保存文本验证信息 | 域名所有权、证书、搜索平台、邮件 SPF | 复制时遗漏引号、空格或分段内容 |
| NS | 指定权威 DNS 服务器 | 整站接管或子域委派 | 注册商 NS 与 Cloudflare NS 混填 |
解析记录设计：A、CNAME、TXT 与 NS 的边界
根域名和需要访问云服务器的子域名通常用 A 记录，指向抽象的 <origin-ip>。如果该服务需要隐藏源站并走 Cloudflare 防护，就开启橙色云朵；如果只是内部验证、邮件或某些不支持代理的服务，则保持 DNS only。静态托管平台一般要求 CNAME，目标必须严格使用平台给出的域名。
| 名称 | 类型 | 内容 | 代理状态 | 说明 |
|---|---|---|---|---|
@ | A | <origin-ip> | 已代理 | 根域名访问云服务器业务 |
www | A 或 CNAME | <origin-ip> 或根域名 | 已代理 | 按实际架构决定是否跟随根域名 |
blog | CNAME | <project>.pages.dev | 按 Pages 提示 | 优先从 Pages 自定义域入口自动创建 |
_verify | TXT | <verification-token> | 不适用 | 用于平台验证，不承载访问流量 |
不要把 CNAME 目标、TXT 验证值和真实项目名称原样写入公开文档；对外分享时用 <project>、<verification-token> 这类占位符即可。配置时则以服务商控制台展示的值为准，不自行补前缀、不删后缀。
橙色云朵与源站防火墙要成对出现
A 记录开启橙色云朵后，访问流量才会先经过 Cloudflare。灰色云朵只提供解析，不提供代理、防火墙和隐藏源站能力。但仅开启代理仍不够：如果云服务器 Web 端口仍允许任意来源访问，攻击者拿到源站地址后仍能绕过 Cloudflare 直连。
- 确认所有对公网开放的 Web 入口，例如 HTTP 与 HTTPS。
- 从 Cloudflare 官方文档获取最新 IPv4 / IPv6 段，不从二手文章复制陈旧列表。
- 在云服务器安全组或轻量服务器防火墙中，把 Web 端口来源改为 Cloudflare 官方 IP 段。
- 保留健康检查、对象存储回源、第三方回调等必要来源，并单独备注业务用途。
- 用非白名单网络尝试直连源站地址，确认不能绕过 Cloudflare 访问业务页面。
管理端口不要套用 Cloudflare Web 白名单。SSH、远程桌面、数据库管理、面板后台等入口应走可信办公网络、VPN、堡垒机或单独的最小化白名单。把 Cloudflare IP 段误套到管理端口，轻则无法登录，重则把管理面暴露给错误的来源集合。
Cloudflare Pages 部署与自定义域
Cloudflare Pages 适合博客、文档站、前端静态项目和构建产物明确的单页应用。推荐从 Pages 的“连接到 Git”开始，把仓库授权、构建命令、输出目录和分支策略一次配置清楚。纯静态 HTML 可以不选择框架预设；有构建步骤的项目，则应明确构建命令和产物目录。
- 进入 Workers 和 Pages，创建 Pages 应用并连接 Git 仓库。
- 选择生产分支，设置框架预设、构建命令与输出目录；静态 HTML 可使用空构建或
None类预设。 - 首次部署完成后，先访问默认
.pages.dev域名，确认构建产物正确。 - 进入项目的 Custom Domains 添加完整自定义域名，让 Pages 自动生成或校验 DNS 记录。
- 等待自定义域状态变为有效，再切换外部入口或正式发布链接。
自定义域不要优先手动去 DNS 面板拼 CNAME。Pages 项目入口能感知项目、域名和证书状态，会给出更准确的目标值和初始化状态。若确实需要手工记录，也必须完全复制平台提供的 CNAME 目标。
SSL 模式选择与常见排障
SSL/TLS 模式取决于 Cloudflare 到源站之间是否有可用 HTTPS。Pages 自身由 Cloudflare 托管，证书通常由平台处理；云服务器源站则要确认是否部署了证书、是否存在强制跳转、是否支持 Cloudflare 回源。
| 现象 | 优先检查 | 处理思路 |
|---|---|---|
| 自定义域初始化中 | Pages Custom Domains 状态 | 等待证书签发和 DNS 生效，通常不要反复删除重建 |
| 部分网络可访问，部分失败 | 本地 DNS 缓存、递归 DNS、运营商链路 | 换移动网络、刷新 DNS 缓存、使用权威查询交叉验证 |
| CNAME 后打不开 | CNAME 目标是否精确 | 不要自行添加 www，不要把目标写成 IP |
| 反复 301 / 302 跳转 | Cloudflare SSL 模式与源站跳转规则 | 源站有 HTTPS 时倾向 Full；未完整配置前避免误用 Strict |
| 源站仍被直连 | 安全组是否仍放行全网 | Web 端口仅放行 Cloudflare 官方 IP 段和必要例外 |
一般来说，源站没有 HTTPS 时不要盲目使用“完全（严格）”；源站已有有效证书并希望端到端加密时，再使用更严格的模式。出现循环重定向时，要同时看 Cloudflare 的 SSL 模式、源站 Web 服务器的 HTTPS 跳转、应用层生成 URL 的协议判断。
- 权威 NS 已切到 Cloudflare，旧 DNS 面板不再维护生产记录。
- A / CNAME / TXT / NS 记录用途清晰，Pages 域名从项目入口绑定。
- 需要防护的 Web 记录已开启橙色云朵，非 Web 验证类记录保持合适状态。
- 源站 Web 端口仅允许 Cloudflare 官方 IP 段，管理端口保留独立可信访问路径。
- Pages 默认域名、自定义域、证书状态和移动网络访问均已验证。
- SSL 模式、源站 HTTPS、应用跳转规则没有互相打架。