橙色云朵不等于完整防护
Cloudflare 代理能隐藏一部分源站信息、提供缓存和基础防护，但如果源站 IP 仍然允许全网访问，攻击者绕过 Cloudflare 直连源站，保护就会失效。
完整链路应该是 DNS 接管、Web 记录开启代理、源站安全组只允许 Cloudflare 官方 IP 访问 80/443，再配合应用层 HTTPS 和日志观察。
- 域名 NS 切到 Cloudflare。
- A / CNAME Web 记录开启代理。
- 源站 80/443 白名单限制为 Cloudflare IP。
- SSH、RDP、数据库端口不要套用 Web 代理思路。
源站安全组怎么配
源站安全组是关键一环。Web 端口只允许 Cloudflare IP 段，管理端口只允许自己的固定出口或 VPN 网段。数据库和 Redis 不应该暴露公网。
Cloudflare 官方 IP 段会更新，生产环境需要定期维护白名单，或者用自动化脚本同步。
- 80/443：Cloudflare IP 白名单。
- 22：个人固定 IP 或 VPN。
- 3306/6379：内网访问。
- 记录变更前后都要测试访问路径。
验收清单
验收时不要只看浏览器能打开。还要测试源站 IP 是否无法直接访问，DNS 是否都在 Cloudflare 管理，证书模式是否正确，日志里真实客户端 IP 是否能通过请求头恢复。
这类基础设施动作一旦做对，后续站点增加业务功能时会安心很多。
- 域名可访问，源站 IP 直连不可访问。
- Nginx 能正确记录 CF-Connecting-IP。
- 证书模式符合源站证书配置。
- 管理端口仍然有单独访问方式。
DNS 接管是第一步
Cloudflare 的防护前提是域名 DNS 由 Cloudflare 管理。仅仅把某条记录指向 Cloudflare 相关地址不够，域名的 NS 需要切到 Cloudflare 提供的 Nameserver。
接管后，Web 访问记录开启代理，也就是常说的橙色云朵。此时用户访问域名会先到 Cloudflare，再由 Cloudflare 回源。
- 在域名注册商处修改 Nameserver。
- Cloudflare 内维护 A / CNAME 等 DNS 记录。
- Web 站点记录开启代理。
- 非 Web 协议不要误开代理。
源站 IP 不能裸奔
如果源站安全组仍然允许全网访问 80/443，攻击者只要知道源站 IP，就可以绕过 Cloudflare。真正的源站保护，是让源站 Web 端口只接受 Cloudflare 官方 IP 段。
这一步在云服务器安全组、防火墙或 Nginx 层都可以做，但云安全组通常更靠前。
- 80/443 只允许 Cloudflare IP 段。
- 22 只允许个人固定 IP 或 VPN。
- 数据库和 Redis 只允许内网。
- Cloudflare IP 段需要定期同步更新。
真实客户端 IP
开启代理后，源站看到的连接 IP 可能是 Cloudflare 节点，而不是真实用户。应用日志、限流、审计如果依赖客户端 IP，就需要正确读取 CF-Connecting-IP 或 X-Forwarded-For，并在 Nginx 中配置可信代理。
否则你会发现日志里大量请求都来自 Cloudflare，排障和风控都会受影响。
- Nginx 配置 real_ip_header CF-Connecting-IP。
- set_real_ip_from 只信任 Cloudflare IP 段。
- 应用层不要盲目信任任意 X-Forwarded-For。
- 检查日志是否恢复真实访问 IP。
Pages 部署的延伸
对于个人知识站这类静态站点，Cloudflare Pages 是很合适的出口。代码推到 GitHub 后，Pages 可以自动构建和发布，并绑定自定义域名。当前这个 hxc-blog 就可以作为静态目录直接部署。
如果后续要加入搜索、RSS、文章生成脚本，也可以先保持静态，再逐步加入构建流程。
- GitHub 仓库连接 Cloudflare Pages。
- 构建命令为空或按后续脚本配置。
- 输出目录指向 hxc-blog 或站点根目录。
- 绑定 my.hxcbox.cn 并开启 HTTPS。