星影的博客

用 Cloudflare、Caddy 和 UFW 保护源站：只接受可信回源

Sat, 16 May 2026 00:00:00 GMT

这篇是一次源站保护折腾记录。环境很普通：东京 AWS EC2，Ubuntu 24.04，1C1G，业务主要跑在 Docker 里，入口交给 Cloudflare。

我的目标不是“让源站 IP 永远不泄露”。IP 可能出现在历史解析、扫描记录、日志、误配置里。真正要做的是：即使别人知道源站 IP，也尽量不能绕过 Cloudflare 直接访问网站。

最终思路可以压成一句话：

让公网访问只走 Cloudflare，让源站同时校验来源 IP、Host、源站证书和 Cloudflare 客户端证书。

整体链路

这套保护大概分成五层：

Cloudflare DNS 开橙云，让正常访问先进入 Cloudflare。
UFW 只允许 Cloudflare IP 访问源站的 80/443。
Docker 发布端口后，用 ufw-docker 把容器转发流量纳入 UFW。
Caddy 使用 Cloudflare Origin CA 证书，Cloudflare SSL/TLS 模式改成 Full Strict。
Caddy 严格匹配 Host，并开启 Authenticated Origin Pulls，让源站只接受 Cloudflare 带客户端证书的回源请求。

我这次为了教程演示，AWS 安全组一开始放得比较开，方便对比“保护前”和“保护后”的效果。生产环境不建议这样做，安全组也应该尽量只开放需要的端口，SSH 最好限制为自己的固定 IP。

基础环境

服务器上只需要准备几个基础组件：

git：拉取工具或项目。
docker / docker compose：跑 Caddy 和后续业务。
ufw：做主机防火墙。
fail2ban：可选。AWS 默认密钥登录时 SSH 爆破风险小一些，但装上也没坏处。

Docker 建议用官方 apt 仓库安装 Docker Engine，不要直接用 Ubuntu 源里的 docker.io。这部分按官方文档走就好，文章里不展开完整命令。

这次用 Caddy 做一个最小测试站点。Docker Compose 里只发布 TCP 的 80 和 443：

services:
  caddy:
    image: caddy:2-alpine
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./site:/srv:ro
      - ./certs:/certs:ro
      - caddy_data:/data
      - caddy_config:/config

volumes:
  caddy_data:
  caddy_config:

这里我没有发布 443:443/udp。Caddy 支持 HTTP/3 时会用到 UDP 443，但如果把 UDP 也暴露出来，防火墙和验证逻辑也要一起处理。为了把教程重点放在源站保护上，我先只保留 TCP。

刚部署完时，直接访问源站 IP 可以看到测试页面：

这就是要解决的问题：只要别人知道源站 IP，就可能绕过 Cloudflare 访问到后面的服务。

Cloudflare DNS 先接管入口

先把域名的 DNS 解析到 EC2 公网 IP，并开启橙云代理。

这一步只能保证正常用户会先进入 Cloudflare，不代表源站已经安全。因为源站 IP 一旦被发现，别人仍然可以直接请求 http://源站IP，或者伪造 Host / SNI 去试探源站。

UFW 只放行 Cloudflare IP

Cloudflare 官方公开了自己的 IP 段，可以用脚本定期同步到 UFW。因为这次 Caddy 跑在 Docker 里，脚本同时加普通 allow 和 Docker 转发用的 route allow：

cat << 'EOF' > /root/update_cf_ips.sh
#!/bin/bash
# 专为 ufw-docker 环境设计的 Cloudflare IP 安全更新脚本

CF_V4_URL="https://www.cloudflare.com/ips-v4"
CF_V6_URL="https://www.cloudflare.com/ips-v6"

echo "开始更新 Cloudflare IPv4 规则..."
for ip in $(curl -s $CF_V4_URL); do
    # 允许访问宿主机本身
    ufw allow proto tcp from $ip to any port 80 comment 'CF-HOST'
    ufw allow proto tcp from $ip to any port 443 comment 'CF-HOST'
    # 允许流量转发到 Docker 容器 (ufw-docker 必须)
    ufw route allow proto tcp from $ip to any port 80 comment 'CF-DOCKER'
    ufw route allow proto tcp from $ip to any port 443 comment 'CF-DOCKER'
done

echo "开始更新 Cloudflare IPv6 规则..."
for ip in $(curl -s $CF_V6_URL); do
    ufw allow proto tcp from $ip to any port 80 comment 'CF-HOST'
    ufw allow proto tcp from $ip to any port 443 comment 'CF-HOST'
    ufw route allow proto tcp from $ip to any port 80 comment 'CF-DOCKER'
    ufw route allow proto tcp from $ip to any port 443 comment 'CF-DOCKER'
done

echo "重新加载 UFW..."
ufw reload
echo "更新完成！"
EOF

chmod +x /root/update_cf_ips.sh
(crontab -l 2>/dev/null | grep -v "/root/update_cf_ips.sh"; echo "0 4 * * 1 /bin/bash /root/update_cf_ips.sh >> /var/log/update_cf_ips.log 2>&1") | crontab -
/root/update_cf_ips.sh

这段命令会创建 /root/update_cf_ips.sh，每周一凌晨 4 点自动执行，并立即手动跑一次。CF-HOST 负责宿主机本身的 80/443，CF-DOCKER 负责转发到 Docker 容器的流量；脚本只追加规则并 reload，不会重置 UFW，也不会覆盖 /etc/ufw/after.rules。正式长期使用时，可以再加上错误处理、日志和旧规则清理，避免脚本失败时悄悄跳过。

[!WARNING] 远程服务器启用 UFW 之前，先确认 SSH 已经放行。最好保留当前 SSH 会话，再开一个新终端测试能否重新登录，避免把自己锁在外面。

到这里看起来已经像是“80/443 只允许 Cloudflare IP”了，但如果服务跑在 Docker 里，还没结束。

把 Docker 转发流量纳入 UFW

Docker 发布端口时会改 iptables / NAT 规则。结果是：你在 UFW 里看见 80/443 只允许 Cloudflare，但外部直接访问源站 IP 可能仍然能打到容器。

这也是这篇文章里最容易踩坑的地方。解决办法是把 Docker 转发流量也纳入 UFW 管理，我这里用的是 <a href="https://github.com/chaifeng/ufw-docker" target="_blank" rel="noopener noreferrer">ufw-docker</a>。

这里不建议把 Docker 转发规则硬塞进 Cloudflare IP 更新脚本，因为 Docker 网络、容器名和要暴露的端口在每台机器上都不一样。更稳妥的做法是按 ufw-docker 官方 README 先安装规则，再用它提供的 check、status、allow、reload 等命令确认 Docker 转发流量已经进入 UFW 管理。

也就是说，Cloudflare IP 脚本维护的是“哪些来源 IP 可以访问源站 80/443”；Docker 这一层由 ufw-docker 接管。只要你的 IP 更新脚本没有 ufw reset，也没有覆盖 /etc/ufw/after.rules，一般不会把 ufw-docker 的接入配置冲掉。真正需要重新处理的是：你重置了 UFW、手动改了 after rules、或者新增/删除了 Docker 网络。

修复后，再直接访问源站 IP，浏览器应该打不开，或者超时：

这时通过 Cloudflare 域名访问仍然正常，说明防火墙没有误伤正常链路。

源站 TLS：Origin CA + Full Strict

下一步是把 Cloudflare 到源站的连接从临时测试状态切到 Full Strict。

Cloudflare Origin CA 的作用是给源站提供一个 Cloudflare 信任的证书。Caddy 使用这张证书，Cloudflare 回源时校验证书有效且主机名匹配。

证书文件放在源站，例如：

/opt/caddy/certs/origin.pem
/opt/caddy/certs/origin.key

私钥权限要收紧：

chmod 600 /opt/caddy/certs/origin.key
chmod 644 /opt/caddy/certs/origin.pem

然后 Caddy 只响应自己的正式域名，其他 Host 直接返回 403：

http://aaa.454849.xyz {
  redir https://aaa.454849.xyz{uri} 301
}

https://aaa.454849.xyz {
  tls /certs/origin.pem /certs/origin.key
  root * /srv
  file_server
}

:80 {
  respond "Forbidden" 403
}

:443 {
  tls /certs/origin.pem /certs/origin.key
  respond "Forbidden" 403
}

Cloudflare 后台里把 SSL/TLS encryption mode 改成 Full (strict)。这里不要继续用 Flexible，否则 Cloudflare 到源站仍然不是严格 HTTPS 回源，后面的 AOP 也不适合放在这个状态下使用。

Host 校验生效后，直接请求 127.0.0.1 或伪造别的域名，会得到 403：

这一层解决的是“伪造 Host 访问源站”的问题。它还不是 mTLS，不能证明请求一定来自 Cloudflare。

再加一层 mTLS：Authenticated Origin Pulls

Cloudflare 的 Authenticated Origin Pulls，简称 AOP，可以让 Cloudflare 回源时带上客户端证书。源站 Caddy 再验证这个客户端证书，验证不通过就直接在 TLS 阶段拒绝。

这里有两个证书概念，别混在一起：

Origin CA 证书：装在源站上，给 Cloudflare 校验证源站身份。
AOP 客户端证书：由 Cloudflare 回源时提供，给源站校验“这次请求来自 Cloudflare”。

先下载 Cloudflare Global AOP CA 证书：

curl -fsSL https://developers.cloudflare.com/ssl/static/authenticated_origin_pull_ca.pem \
  -o /opt/caddy/certs/cloudflare-origin-pull-ca.pem

然后把 Caddy 的 TLS 配置改成要求客户端证书：

(origin_tls) {
  tls /certs/origin.pem /certs/origin.key {
    client_auth {
      mode require_and_verify
      trust_pool file /certs/cloudflare-origin-pull-ca.pem
    }
  }
}

http://aaa.454849.xyz {
  redir https://aaa.454849.xyz{uri} 301
}

https://aaa.454849.xyz {
  import origin_tls
  root * /srv
  file_server
}

:80 {
  respond "Forbidden" 403
}

:443 {
  import origin_tls
  respond "Forbidden" 403
}

重启 Caddy 后，先不要急着开 Cloudflare 后台。直接从源站本机模拟访问，应该失败：

curl -kI --resolve aaa.454849.xyz:443:127.0.0.1 https://aaa.454849.xyz

如果看到类似 tlsv13 alert certificate required，说明 Caddy 已经在要求客户端证书。

最后到 Cloudflare 后台开启 Global Authenticated Origin Pulls：

开启后，正常域名访问依然走 Cloudflare，Cloudflare 带客户端证书回源，所以可以访问；直接打源站 IP 或本地伪造解析，因为没有 Cloudflare 客户端证书，会在 TLS 阶段失败。

[!NOTE] Global AOP 用的是 Cloudflare 共享客户端证书，它证明“请求来自 Cloudflare 网络”，不是证明“请求来自我的这个 Cloudflare zone”。不过普通套餐下，别人通常不能随意指定回源端口、改写 Host/SNI 再打到你的源站；这类更强的回源改写能力一般需要 Enterprise 或更高权限配置。对个人站来说，Global AOP + 严格 Host 校验 + Cloudflare IP 白名单已经够用了。

验证清单

我最后按这个顺序检查：

https://aaa.454849.xyz 正常打开。
http://aaa.454849.xyz 会跳转到 HTTPS。
http://源站IP 无法直接打开。
伪造 Host 请求源站，不会返回真实站点内容。
没有 Cloudflare 客户端证书时，直接打源站 HTTPS 会失败。
UFW 里能看到 Cloudflare IP 白名单，ufw-docker 也能确认 Docker 转发流量已经接入 UFW。
自动更新 Cloudflare IP 的 systemd timer 正常运行。

验证时不要只看“能不能访问域名”。源站保护最重要的是反向测试：绕过 Cloudflare 的路径是不是被挡住了。

限制和取舍

这套方案不是万能的。

首先，Cloudflare IP 白名单依赖 IP 段同步，脚本要能稳定更新。如果脚本只是追加 Cloudflare allow 规则并 ufw reload，通常不会影响 ufw-docker；如果脚本用了 ufw reset，或者覆盖了 /etc/ufw/after.rules，才需要把 SSH、Cloudflare 主机规则和 ufw-docker 接入配置一起恢复回来。

其次，Global AOP 仍然是共享信任。它适合个人站和普通项目，因为普通 Cloudflare 配置下，攻击者很难同时做到“让 Cloudflare 回源到你的 IP、伪造正确 Host/SNI、并绕过你的源站校验”。如果你的安全模型要求“只有我这个 zone 可以访问源站”，再考虑自定义 AOP。

另外，教程里的 AWS 安全组开放是为了演示对比。正式服务器不要这样配置。安全组、系统防火墙、Caddy Host 校验、mTLS 都是不同层的保护，能叠加就叠加。

最后，实际部署时通常让 Caddy 作为唯一公网入口，绑定宿主机的 80/443 就够了。其它业务容器不需要直接绑定宿主机公网端口，可以只监听本机或 Docker 内网，再由 Caddy 反向代理过去。即使已有服务绑定了宿主机端口，也要用 UFW / ufw-docker 管住入口，不要让它绕过 Cloudflare 暴露在公网。

参考资料

<a href="https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/" target="_blank" rel="noopener noreferrer">Cloudflare IP ranges</a>
<a href="https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/" target="_blank" rel="noopener noreferrer">Cloudflare Full (strict) SSL/TLS mode</a>
<a href="https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/" target="_blank" rel="noopener noreferrer">Cloudflare Authenticated Origin Pulls</a>
<a href="https://docs.docker.com/engine/install/ubuntu/" target="_blank" rel="noopener noreferrer">Docker Engine on Ubuntu</a>
<a href="https://caddyserver.com/docs/caddyfile/directives/tls" target="_blank" rel="noopener noreferrer">Caddy TLS directive</a>
<a href="https://github.com/chaifeng/ufw-docker" target="_blank" rel="noopener noreferrer">ufw-docker</a>

用 Cloud Mail + Resend 搭建域名邮箱：收信、发信和 Gmail 代发

Wed, 13 May 2026 00:00:00 GMT

域名邮箱最实用的地方，是把不同网站、不同服务的注册邮箱隔离开来。比如给购物、订阅、测试项目、临时服务分别准备不同的邮箱地址，后续如果某个地址开始收到垃圾邮件，也更容易判断泄露来源并停用。

这篇记录的是我目前使用的一套轻量方案：用 Cloud Mail 搭建邮箱面板和收信逻辑，用 Resend 负责 SMTP 发信，再把 Gmail 作为可选的收发客户端。它不适合替代企业邮箱，但很适合作为个人域名邮箱、注册别名邮箱、项目测试邮箱来用。

[!NOTE] 批量管理账号邮箱别名时，仍然要遵守对应网站的服务条款。有些平台会限制自定义域名邮箱，特别是免费域名、低价域名、新注册域名，可能会触发风控或直接不支持。

整体方案

这套方案可以拆成两条链路：

收信：外部服务发邮件到你的域名邮箱，Cloudflare / Cloud Mail 接收后，转发到 Cloud Mail 面板、Telegram 或 Gmail。
发信：Cloud Mail 或 Gmail 通过 Resend 的 SMTP 服务，以你的域名邮箱身份发出邮件。

需要准备：

一个已经接入 Cloudflare 的域名
一个 Cloudflare 账号
一个 GitHub 账号，用来部署 Cloud Mail
一个 Resend 账号，用来发信
一个 Gmail 账号，可选，用来当日常收发客户端

Cloud Mail 项目地址：<a href="https://github.com/maillab/cloud-mail" target="_blank" rel="noopener noreferrer">maillab/cloud-mail</a>

Cloud Mail 官方部署文档：<a href="https://doc.skymail.ink/guide/dashboard.html" target="_blank" rel="noopener noreferrer">界面部署</a>

先完成 Cloud Mail 收信

Cloud Mail 的基础部署建议直接按官方文档走。核心步骤是：

Fork 或克隆 Cloud Mail 项目到自己的 GitHub。
在 Cloudflare Workers & Pages 里从 GitHub 导入项目。
按文档配置环境变量、D1、KV 和自定义域。
初始化数据库，注册管理员账号并登录 Cloud Mail 面板。
在 Cloudflare 邮件路由里配置目标地址或 Workers，让邮件能进入 Cloud Mail。

做到这里，通常已经可以完成收信。但如果想从 Cloud Mail 或 Gmail 发出域名邮箱邮件，还需要继续配置 Resend。

配置 Resend 发信

打开 <a href="https://resend.com/" target="_blank" rel="noopener noreferrer">Resend</a> 官网，注册并登录账号，然后进入 Domains 页面，点击 Add domain 添加自己的域名。

Resend 会要求你添加 DNS 记录来验证域名。按页面提示跳转到 Cloudflare，添加对应解析记录，等待状态变成 Verified。

[!NOTE] 我这里直接添加主域名。如果你更在意发信信誉隔离，也可以用类似 mail.example.com 这样的子域名。

Resend 自动添加的 DNS 记录通常会覆盖 SPF / DKIM 等发信认证，但不会替你补主域名的 DMARC。为了防止别人伪造你的域名发信，建议在 Cloudflare DNS 里手动加一条：

类型	名称	内容	代理状态	TTL
TXT	`_dmarc`	`"v=DMARC1;p=reject"`	仅 DNS	自动

p=reject 是比较严格的策略：当邮件没有通过 SPF / DKIM 对齐时，收件方可以直接拒收。对于刚开始测试的新域名，这样比较干净；如果你的域名之前已经接入过其它发信服务，要先确认所有合法发信服务的 SPF / DKIM 都配置正确，再切到 reject。

域名验证完成后，进入 API keys 页面，创建一个新的 API Key。这个 Key 只会完整显示一次，一定要立刻保存好。

回到 Cloud Mail 的系统设置，找到 Resend Token，把刚才保存的 API Key 填进去并保存。

到这里，Cloud Mail 端的收信和发信能力就基本完成了。可以先在 Cloud Mail 面板里发一封测试邮件，确认外部邮箱能正常收到。

可选：把邮件转发到 Gmail

如果你希望继续用 Gmail 作为主收件箱，可以把 Cloud Mail 收到的邮件再转发到 Gmail。

先进入 Cloudflare 的邮件路由页面，在 目标地址 中添加自己的 Gmail 地址，并到 Gmail 收件箱里点击 Cloudflare 发来的验证链接。

然后回到 Cloud Mail，进入系统设置里的 邮件推送，在 第三方邮箱 中填入刚刚验证过的 Gmail 地址，启用并保存。

在下方的转发规则里，可以指定哪些域名邮箱需要转发到 Gmail。比如只把 admin@你的域名 转发过去，其它临时地址仍然留在 Cloud Mail 面板里。

可选：让 Gmail 代发域名邮箱

转发解决的是收信。如果还想直接在 Gmail 里选择域名邮箱作为发件地址，需要给 Gmail 添加 Resend 的 SMTP 信息。

在电脑浏览器打开 Gmail，点击右上角设置，选择 查看所有设置。

进入 账号和导入，在 用这个地址发送邮件 一栏里点击 添加其他电子邮件地址。

在弹出的窗口里填入你想显示的名称和域名邮箱地址。

下一步会要求填写 SMTP 信息。Resend 的 SMTP 参数如下：

SMTP 服务器：smtp.resend.com
端口：465
用户名：resend
密码：你的 Resend API Key
安全连接：选择 SSL

这些信息也可以在 Resend 的 Settings -> SMTP 页面找到。

把 SMTP 信息填入 Gmail，点击 添加账号。

Gmail 会向这个域名邮箱发送一封确认邮件。你可以在 Cloud Mail 里复制确认链接，也可以等它转发到 Gmail 后直接点击链接完成验证。

验证成功后，回到 Gmail 设置页，按 F5 刷新。然后把域名邮箱设置成默认发件地址。这样以后在 Gmail 写邮件时，就可以默认用域名邮箱发出。

验证一下

配置完成后，我建议至少做三次测试：

从外部邮箱发信到 admin@你的域名，确认 Cloud Mail 能收到。
如果启用了转发，确认 Gmail 也能收到同一封邮件。
从 Cloud Mail 或 Gmail 使用域名邮箱发信给外部邮箱，确认对方看到的发件人是你的域名邮箱。

如果 Gmail 迟迟收不到确认邮件，可以先检查 Cloud Mail 是否已经收到，再检查 Cloudflare 邮件路由的目标地址是否完成验证。

常见问题

Gmail 添加 SMTP 时提示无法连接

优先确认端口和加密方式是否对应：465 选择 SSL，587 选择 TLS 或 STARTTLS。如果你按本文使用 465，Gmail 里就选 SSL。

发出去的邮件进垃圾箱

先检查 Resend 的域名验证状态，确认 SPF、DKIM、DMARC 记录都已经正确生效。DNS 刚添加后可能需要等一会儿，Cloudflare 一般很快，但不同收件方缓存时间不一样。

Gmail 收不到确认邮件

先看 Cloud Mail 面板是否已经收到确认邮件。如果 Cloud Mail 收到了但 Gmail 没有收到，再检查 Cloudflare Email Routing 的目标地址是否完成验证，以及 Cloud Mail 的第三方邮箱推送是否开启。

为什么不直接用 Cloudflare 发信？

传统的 Cloudflare Email Routing 主要负责收信和转发，并不提供常规 SMTP 发信服务器。Cloudflare 现在也在推进 Email Service，可以通过 REST API 或 Workers 发信；但如果只是想接入 Gmail 的“用其他地址发送邮件”，Resend 的 SMTP 配置会更简单。

限制和注意事项

Resend 免费档适合个人低频使用。目前免费额度是 100 封/天、3000 封/月、1 个自定义域。如果你使用 Resend 的接收功能，收到的邮件也会计入额度；但这篇方案主要使用 Resend 发信。

传统的 Cloudflare Email Routing 主要负责收信转发，不提供常规 SMTP 发信服务器。Cloudflare Email Service 已经提供 REST API / Workers 发信能力，但本文选择 Resend，是因为它有标准 SMTP，直接接入 Gmail 更省事。

这套方案也不是“完全私密邮箱”。从信任模型上，你仍然要信任 Cloudflare、Cloud Mail 的部署环境，以及 Resend 的发信服务。普通注册、通知、项目测试没有太大问题，但高度敏感的邮件不建议放在这类免费组合方案里。

最后，域名邮箱不一定能通过所有平台的验证。以 OpenAI 这类风控更严格的服务为例，免费域名、低价域名、新注册域名或信誉较弱的自定义域名邮箱，都可能被拒绝。

参考资料

<a href="https://doc.skymail.ink/guide/dashboard.html" target="_blank" rel="noopener noreferrer">Cloud Mail 官方文档</a>
<a href="https://resend.com/pricing" target="_blank" rel="noopener noreferrer">Resend 价格与免费额度</a>
<a href="https://resend.com/docs/send-with-smtp" target="_blank" rel="noopener noreferrer">Resend SMTP 文档</a>
<a href="https://resend.com/docs/dashboard/domains/dmarc" target="_blank" rel="noopener noreferrer">Resend DMARC 文档</a>
<a href="https://resend.com/docs/knowledge-base/account-quotas-and-limits" target="_blank" rel="noopener noreferrer">Resend 账号额度说明</a>
<a href="https://developers.cloudflare.com/email-routing/" target="_blank" rel="noopener noreferrer">Cloudflare Email Routing 文档</a>
<a href="https://developers.cloudflare.com/email-service/api/send-emails/rest-api/" target="_blank" rel="noopener noreferrer">Cloudflare Email Service REST API 文档</a>
<a href="https://support.google.com/mail/answer/22370" target="_blank" rel="noopener noreferrer">Gmail：使用其他地址发信</a>

我的博客开始了

Wed, 06 May 2026 00:00:00 GMT

这是这个博客的第一篇文章。

现在它还很简单，但已经具备一个个人博客最重要的能力：

可以在本地预览
可以用 Markdown 写文章
可以提交到 GitHub
可以通过 Cloudflare Pages 自动发布

以后我会把学到的东西、踩过的坑、项目记录和一些生活想法慢慢写在这里。