树莓派4B自建网页服务器指南（7.1）· 番外篇：Cloudflare Tunnel + 阿里云 CDN —— 零 ECS 备案保壳方案

一、引言

1.1 为什么还需要这个番外篇？

第7篇介绍的 ECS 反向代理方案虽然成熟合规，但需要每月支付云服务器费用（最低约 30 元/月）。对于预算敏感或纯实验性质的场景，能否零成本实现“域名直接访问 + 备案保壳”？

答案是：可以，但存在诸多限制与风险。本方案借助 Cloudflare Tunnel 和 阿里云 CDN 的组合拳，理论上可以实现：

免 ECS：无需购买云服务器，完全利用 Cloudflare 免费套餐
备案合规（存量域名）：通过阿里云 CDN 作为接入商，域名备案在阿里云，源站 IP 为 Cloudflare Anycast（非家宽）
隐藏端口：用户访问 https://pi.jiejinx.cn 无需加端口号
公网直访子域：pi-cf.jiejinx.cn 经 NS 委派 + 橙云，可手机流量直访（B 标准版）

1.2 ⚠️ 重要免责声明

本方案存在以下已知限制与风险，请务必阅读后再决定是否采用：

国内域名首次备案无法绕过：如果你的域名尚未完成 ICP 备案，必须先通过云厂商（如阿里云）完成首次备案，且首次备案必须使用国内云服务器（ECS 或轻量应用服务器）作为接入资源。本方案仅适用于已有备案号的域名进行接入变更，无法替代首次备案流程。
云厂商官方不推荐此做法：阿里云 CDN 的备案审查机制要求源站 IP 归属清晰。将源站指向 Cloudflare Anycast IP（非阿里云资源）属于非标准用法，阿里云官方不推荐作为长期备案保壳策略。备案系统可能不定期抽查，存在掉壳风险（即备案被注销）。
Cloudflare Free 版稳定性风险：Free 版要求主域 NS 指向 Cloudflare，否则子域橙云功能可能在 28 天后被清理。NS 委派形态依赖此窗口，需定期续命或升级 Business 计划（$20/月）使用 Partial Setup。
CDN 回源 ULA 坑：阿里云递归解析 cfargotunnel.com时可能返回 ULA 地址（fd10:），导致回源失败。CDN 回源建议直写 CF Anycast IP + SNI 避开。

边界说明: 无需 ICP 备案即可采用本方案的情形
当同时满足以下所有条件时，域名 → Cloudflare Tunnel → 树莓派公网 IPv6 的访问链路在技术与 DNS 层面可跑通，且不依赖国内云厂商备案审查：
域名 DNS 解析权已托管到 Cloudflare（NS 改为 CF），子域 CNAME 到 xxx.cfargotunnel.com 并开启橙云代理，流量第一跳落在 Cloudflare 海外边缘节点，不经过任何国内云服务器（ECS/轻量等）；
树莓派侧运行 cloudflared，主动出网建立隧道，不依赖家宽 IPv6 入站端口开放（光猫/路由器 IPv6 防火墙可全开，与第 6 篇直连方案相反）；
访问者主要通过 Cloudflare 边缘节点访问，接受境外节点延迟（国内直连速度一般）；
服务定位为自用、非经营、非面向公众的技术验证/远程自访，而非对外发布的商业站点。
此情形下“免备案”成立的原因是：请求终结在 Cloudflare 海外节点，源站（树莓派）通过仅出站隧道回源，国内备案系统按“域名解析到境内 IP 提供 Web 服务”的审查逻辑不会被触发。但需注意两点硬边界：
合规边界仍受家宽用户协议约束（不得经营/不得面向公众），Cloudflare Tunnel 不改变家宽协议限制，只是把入站暴露面收敛为出站隧道；
若后续把同一域名 A 记录指向国内 ECS 做生产发布，仍必须先完成 ICP 备案，本边界说明不适用。
简言之：“域名托管 CF + Tunnel 回源树莓派（IPv6 或 IPv4 均可） + 不解析到国内服务器 + 自用” 这四种情形叠加时，无需备案即可获得带 HTTPS 的域名访问；一旦转为“对外服务/解析回国/用国内 CDN 保壳”，备案义务立即恢复。

综上，本方案仅供技术学习与研究，生产环境请优先采用第七篇的 ECS 反代方案。

1.3 适用人群

已有备案域名，希望尝试零成本方案的进阶玩家
对 Cloudflare Tunnel 和 DNS 委派有充分了解的爱好者
愿意承担掉壳风险，并定期维护的实验者

二、方案原理（两档）

简化版（CNAME 灰云）

由于ULA 坑（IPv6 的内网地址，公网不能用），实机验证失败，后续cdn回源是否能真实打通需自行验证，只做思路介绍

用户浏览器
 ↓ HTTPS (443)
阿里云 CDN（已备案域名 www.jiejinx.cn）
 ↓ 回源 HTTPS :443, Host: pi-cf.jiejinx.cn
 ↓ CNAME 展开 cfargotunnel.com 时阿里云递归可能返 ULA → 回源失败
Cloudflare Edge（Anycast IP）→ Tunnel → 树莓派

阿里云 NS 全权管 jiejinx.cn
pi-cf CNAME → TunnelID.cfargotunnel.com（灰云，NS 在阿里云开不了橙云）
公网直访 pi-cf 不通（ULA 坑），Tunnel 本身活
生产形态：ECS/CDN 回源直写 CF Anycast IP + SNI = pi-cf 可通，备案壳在阿里云

标准版（NS 委派 + 橙云，实机验证通过）

用户浏览器
 ↓ HTTPS (443)
阿里云 CDN（已备案域名 www.jiejinx.cn）
 ↓ 回源 HTTPS :443, Host: pi-cf.jiejinx.cn（建议直 IP + SNI 避 ULA，见 6.1）
 ↓ 或 手机 4G 直访 pi-cf.jiejinx.cn
Cloudflare Edge（Anycast IP，递归经 NS 委派到 CF NS，展开 cfargotunnel.com 返 Anycast 非 ULA ✅）
 ↓ Tunnel（QUIC/HTTP2）
树莓派 cloudflared → Nginx 9133

主域： jiejinx.cn的NS服务器留阿里云（备案）
pi-cf 子域： 阿里云解析设置 NS委派 → CF（xxx.ns.cloudflare.com/ yyy.ns.cloudflare.com）
CF侧： jiejinx.cn zone 内 pi-cf 的CNAME → TunnelID.cfargotunnel.com☁️ 橙云开
公网直访： pi-cf通 ✅（递归走 NS 委派 → CF NS → 返 Anycast）
光猫： IPv6 SPI 开启状态下仍可通（流量走 CF Edge，不入家宽 IPv6 入站）

三、DNS 架构（NS 委派，标准版）

⚠️ Cloudflare Free 不允许 "Add Site" 加子域独立 zone（Free 只允许加主域）。所以 pi-cf.jiejinx.cn不能建独立 zone，只能借 jiejinx.cn 主域 zone 还在的 28 天宽容期（主域 NS 已切回阿里云但 CF zone 未删）来管 pi-cf 的 CNAME + 橙云。要长稳需升 Business $20/mo 走 Partial Setup，或回简化版方案。

主域 jiejinx.cn → NS: 阿里云（dns1.hichina.com, dns2.hichina.com）
 ├── www     → CNAME → 阿里云 CDN 加速域名（备案用）
 ├── pi-cf   → NS: xxx.ns.cloudflare.com, yyy.ns.cloudflare.com
                   （委派给 Cloudflare，实际dns服务地址在cloudflare控制台dns设置里查看）
 └── 其他记录（@ / pi / pi-source 等）仍由阿里云管理

阿里云 DNS 控制台为 pi-cf 加两条 NS 记录，指向 CF 分配的那两个 NS。 CF 侧（主域 jiejinx.cn zone，28 天窗口内）：

pi-cf  CNAME  <tunnel-id>.cfargotunnel.com  ☁️ 橙云开

四、Cloudflare Tunnel 配置（注册 / 建域 / 登录授权 / 隧道创建）

4.1 注册 Cloudflare 账号

打开 https://www.cloudflare.com ，点击右上角 Sign Up。
使用 QQ 邮箱 注册（国内收验证最快），设置密码。
登录 QQ 邮箱，找到 Cloudflare 发送的 Verify Email Address 邮件，点击 Verify Email。
⚠️ 关键坑：点击验证后页面会自动跳转到 Cloudflare 首页，但此时登录状态并不稳定。必须手动退出当前账号（Log Out），然后重新登录一次，确保 Dashboard 页面能正常显示“Add a Site”按钮。否则后续操作会因 session 问题失败。

4.2 添加主域名（使 Tunnel 可创建）

在 Cloudflare Dashboard 点击 Add a Site，输入你的主域名（例如 jiejinx.cn ），选择 Free 套餐。
Cloudflare 会分配两个名称服务器地址（例如 xxx.ns.cloudflare.com、yyy.ns.cloudflare.com）。前往你的域名注册商（阿里云）将 jiejinx.cn的 NS 记录修改为这两个地址。
等待 NS 生效（可通过 nslookup -type=ns jiejinx.cn 8.8.8.8 确认返回 Cloudflare 的 NS）。
生效后，进入 Cloudflare 左上角九宫格 → Zero Trust → Networks → Tunnels，此时才能看到“Create Tunnel”按钮（若未添加主域名，此页面为空或无法操作）。

4.3 绑定支付方式（Zero Trust 面板要求）

Cloudflare Zero Trust 免费版需要额外开通，需绑定支付方式才能启用隧道配置功能。推荐使用 PayPal 绑定，无需充值。

注册 PayPal（国内用户可用邮箱注册），注意接收短信验证码可能有延迟，可多次点击“重新发送”。
在 Cloudflare Zero Trust 面板的 Settings → Billing 中绑定 PayPal。
⚠️ 安全建议：绑定成功后，建议立即在 PayPal 中解绑该信用卡/银行卡（PayPal 设置 → 付款 → 管理自动付款 → 移除），避免后续意外扣款。由于 PayPal 国内网络访问不稳定，操作时可能需要多次刷新页面。

4.4 树莓派端安装 cloudflared 并授权

bash

# 树莓派 Pi OS (ARM64)
wget https://gh.llkk.cc/https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-arm64.deb
sudo dpkg -i cloudflared-linux-arm64.deb
cloudflared --version

授权登录（关键步骤）：

bash

cloudflared tunnel login

终端会输出一个 URL，类似：

https://dash.cloudflare.com/argotunnel?aud=...

必须在你的 Windows/Mac 浏览器中打开此 URL（树莓派无桌面环境，不能直接点击）。

打开 URL 前的浏览器状态检查：

确保浏览器已经登录 Cloudflare 账号（建议先手动登录一次 Dashboard，确认能看到你的域名）。
如果之前只验证了邮箱而未重新登录，请先退出再重新登录，否则授权会失败。
点击 URL 后，页面会显示 Authorize 按钮，点击后选择你的域名（jiejinx.cn），授权成功。

验证授权：

bash

cloudflared tunnel list
# 应返回空列表（还未创建隧道），无 401/403 错误即表示授权成功。
# 证书文件已保存在 ~/.cloudflared/cert.pem

4.5 创建隧道并配置

bash

cloudflared tunnel create pi-tunnel

记录输出的 Tunnel ID（例如 4a4a5eb6-359e-467b-ab74-96d91af83f23），后续配置需要使用。

编辑 ~/.cloudflared/config.yml：

tunnel: 4a4a5eb6-359e-467b-ab74-96d91af83f23
credentials-file: /home/pi/.cloudflared/4a4a5eb6-359e-467b-ab74-96d91af83f23.json

ingress:
  - hostname: pi-cf.jiejinx.cn
    service: https://localhost:9133
    originRequest:
      noTLSVerify: true
  - service: http_status:404

4.6 启动隧道并设置开机自启

bash

sudo cloudflared service install
sudo systemctl enable cloudflared
sudo systemctl start cloudflared

查看运行状态：

bash

sudo journalctl -u cloudflared -f

出现 Registered tunnel connection protocol=http2表示隧道正常运行。

4.7 迁移到 Zero Trust 面板（重要）

本地 config.yml的 ingress 规则仅在未迁移时有效。
一旦在 Zero Trust 面板中配置了“已发布应用程序路由”（中文名：已发布应用程序路由，英文为 Published Application Routes），本地 ingress 将被覆盖，面板配置优先。
此后修改域名指向只需在面板操作，无需再编辑本地文件。

迁移步骤：

登录 Zero Trust 面板 → Networks → Tunnels → 点击你的隧道（pi-tunnel）。
点击 Configure 标签页，找到 已发布应用程序路由（Published Application Routes）。
点击添加，填写：
- 子域：pi-cf
- 域：jiejinx.cn
- 服务：https://localhost:9133
- 不验证 TLS：✅ 开启

保存后，Cloudflare 会自动将配置下发到树莓派，本地 config.yml的 ingress 规则将不再生效。

⚠️ 坑点：面板菜单名称“已发布应用程序路由”与旧版“Public Hostname”不同，初次使用可能找不到。记住这个中文名称即可。

本节坑点总结：

注册邮箱验证后必须重新登录，否则授权会失败。
cloudflared tunnel login的 URL 必须在已登录 Cloudflare 的浏览器中打开，且域名必须先添加到 Dashboard。
Zero Trust 面板需要绑定支付方式（推荐 PayPal），注册 PayPal 时短信可能有延迟，绑定后建议解绑银行卡。
迁移到面板后，本地 ingress 失效，后续配置在“已发布应用程序路由”中操作。

五、阿里云 CDN 配置

5.1 添加加速域名

域名： www.jiejinx.cn （你的主站域名）
源站类型： 源站域名 或 源站 IP
源站地址：
- ❌ 不推荐：pi-cf.jiejinx.cn（阿里云 CDN 节点递归走 NS 委派 → CF NS → 理论上返 Anycast，但 CDN 回源链稳定性未经充分验证，且若未来 jiejinx.cnCF zone 被删则断）
- ✅ 推荐：CF Anycast IP + SNI = pi-cf.jiejinx.cn（避 ULA 坑、不依赖 CF zone 存活）→ 例如 104.21.28.47，IP 轮换时需更新
回源 Host：pi-cf.jiejinx.cn
回源协议：HTTPS（因为 Cloudflare Edge 只接受 443 入站）

5.2 证书配置

用户端： 阿里云 CDN 提供免费 HTTPS 证书（自动申请或上传）
回源端： Cloudflare 侧 pi-cf 已有 Universal SSL 证书（因 NS 在 Cloudflare），无需额外配置；若 CF zone 被删，回源需用树莓派 acme.sh *.jiejinx.cn 证书（SAN 需含 pi-cf）

5.3 备案要求

www.jiejinx.cn （你的主站域名）必须在阿里云完成 ICP 备案
备案过程中，阿里云会检测源站 IP，此处源站 IP 为 Cloudflare Anycast（104.x.x.x或 2606:4700::），不属于家宽，备案可通过
⚠️ 如前所述，云厂商不推荐此做法，存在掉壳风险

六、潜在风险与注意事项

6.1 Cloudflare Free 版稳定性风险（三档拆清）

风险	归属	说明
主域 NS 不在 CF 时子域橙云 28 天可能被回收	标准版（NS 委派）也踩	主域 jiejinx.cn NS 已切阿里云，CF jiejinx.cn zone 仅 28 天宽容期，期内 pi-cf CNAME + 橙云 + Tunnel 活；期满 CF 清理 job 可能扫掉。续命：每 28 天 NS 短暂切回 CF 晃 1 小时；或升 Business $20/mo 走 Partial Setup（子域独立 zone 不受主域 NS 约束）
阿里云递归展开 cfargotunnel.com 返 ULA fd10:	仅简化版（CNAME 灰云）踩	阿里云 NS + pi-cf CNAME → TunnelID.cfargotunnel.com，阿里云递归自己去展开 cfargotunnel.com 时可能返 ULA → 手机 4G 直访超时。NS 委派版（B 标准）递归走 CF NS 展开，返 Anycast（2606:4700 / 104.x），不踩 ULA ✅
CDN 回源走 pi-cf 域名也可能遇 ULA	两版都需注意	CDN 节点递归同路径，建议 CDN 回源直写 CF Anycast IP + SNI=pi-cf 避 ULA，IP 轮换时更新
Tunnel 流量限制	共通	Free 版无明确上限，大量 CDN 回源可能触发限速，个人小流量 OK

6.2 备案审查风险

虽然源站 IP 非家宽，但备案系统可能抽查域名解析链路。如果发现 www.jiejinx.cn 的 CNAME 链最终指向 Cloudflare，而 Cloudflare 未在国内备案，极少数情况下可能被要求整改。
本方案仅供学习研究，生产环境请使用第7篇的 ECS 反代方案。

七、标准版（NS 委派）实机验证闭环

为了确保本文的核心进阶方案（纯出站穿透、无视光猫防火墙）真正可用，以下所有验证均基于 标准版（NS 委派 + Cloudflare Tunnel） 进行。

⚠️ 常见误区澄清：在调试过程中，你可能会尝试访问 http://cfargotunnel.com、http://dns1.hichina.com 或 http://ns1.cloudflare.com 等地址，这些都会返回“资源解析服务请求失败”。这是正常的——它们分别是 Cloudflare Tunnel 的内部域名和 DNS 服务器地址，本身不提供网页服务。你只需要关心 pi-cf.jiejinx.cn（你的橙云隧道域名）能否正常访问即可。

7.1 DNS 解析链路确权（排除 ULA 隐患）

首先验证子域名的 DNS 解析权是否完全移交给了 Cloudflare，防止阿里云递归解析返回内网 ULA 地址导致移动端无法访问。

7.1.1 验证 A/AAAA 记录是否直接返回 Cloudflare 的 Anycast 节点（关键：必须看到 104.x 或 2606:4700 段）

在本地电脑（非树莓派网络环境）执行查询：

powershell

nslookup pi-cf.jiejinx.cn 8.8.8.8

预期输出：

非权威应答:
名称:    pi-cf.jiejinx.cn
Addresses:  2606:4700:3030::6815:1c2f  <-- ✅ Cloudflare IPv6
2606:4700:3033::ac43:903d  <-- ✅ Cloudflare IPv6
172.67.144.61             <-- ✅ Cloudflare IPv4
104.21.28.47              <-- ✅ Cloudflare IPv4

7.1.2 验证 NS 记录是否生效（确认委派成功）

powershell

nslookup -type=ns pi-cf.jiejinx.cn 8.8.8.8

预期输出：

非权威应答:
名称:    pi-cf.jiejinx.cn
pi-cf.jiejinx.cn 的权威名称服务器是:
ns1.cloudflare.com
ns2.cloudflare.com

注：若此处返回的是 dns1.hichina.com，则说明阿里云 NS 记录未生效，需等待 TTL 过期或检查拼写。

7.2 穿透能力极限测试（光猫 IPv6 防护全开）

这是本方案最大的价值所在：完全不依赖家宽的入站能力，也不依赖 IPv6 前缀的稳定性。

测试环境：

光猫端： 已开启 IPv6 SPI 防护（拦截所有未经允许的 IPv6 入站连接）。
客户端： 手机 4G 网络（关闭 WiFi，模拟公网陌生访问）。
服务端： 树莓派部署了 Nginx + Cloudflare Tunnel。

测试步骤与结果：

手机 4G 浏览器访问：https://pi-cf.jiejinx.cn
结果：页面成功加载，显示 Nginx 欢迎页及访客的 IPv6 地址。
树莓派后台日志验证：

bash

sudo journalctl -u cloudflared -f
# 输出：Registered tunnel connection ... Incoming request ...

💡 原理复盘：为何光猫 IPv6 防护开启仍能通？

这是一个典型的“明修栈道，暗度陈仓”模型：

明线（受保护）：外部用户访问 pi-cf.jiejinx.cn，DNS 解析指向 Cloudflare 的全球边缘节点（104.x / 2606:4700）。流量到达 CF Edge 后，发现域名绑定了 Tunnel，于是通过加密的 QUIC 协议向你的家宽发起出站连接。
暗线（隧道）：你的树莓派 cloudflared服务持续维持着与 CF Edge 的出站长连接。当 CF Edge 收到外部请求时，通过这个已有的“管道”将数据推送进你的内网。
结论：光猫的 IPv6 SPI 防火墙只拦截主动入站的连接请求。而 Cloudflare Tunnel 的流量是设备主动出站建立的，完全绕过了光猫的入站拦截规则。

7.3 容灾能力测试（IPv6 前缀变更）

断开家庭宽带光猫电源，重新拨号获取新的 IPv6 前缀：

结果：等待 5-10 分钟后，手机 4G 再次访问 pi-cf.jiejinx.cn，页面依然秒开。
原因：Tunnel 连接基于 UUID 建立，与公网 IP 无关。只要树莓派在线，无论 IP 怎么变，服务都能自动适配。

八、总结

维度	ECS 反代（主线·生产推荐）	简化版（CNAME 灰云）	标准版（NS 委派·实测）
💰 月度成本	30-50 元	免费	免费（需 28 天续命）
📜 备案合规	✅ 完全合规（ECS 在白名单）	✅ 形式合规（CDN 已备案）	⚠️ 灰色地带（CF 未国内备案）
🌐 公网直连支持	✅ 稳定直连（ECS 固定 IP）	❌ 受限（ULA 或 CDN 漂移）	✅ 全球直连（Anycast）
🔒 SSL 证书支持	✅ 全自动（阿里云证书或开源均可）	❌ 无（灰云）	✅ 全自动（CF 泛域名）
🚀 穿透能力	✅ 反代主线（ECS 固定 IP 收口）+ 自建 frp/nps 穿透，无视家宽入站限制（光猫 IPv6 防护开也能通）	⚠️ 依赖 IPv6 前缀 + CDN 回源（光猫 IPv6 防护若开则直连死，CDN 还可能踩 ULA）	✅ QUIC 出站，无视家宽入站限制（光猫 IPv6 防护开也能通）
⏳ 长期稳定性	极高（SLA）	中（无 28 天问题，依赖 CDN 回源）	中（28 天窗口）
⚙️ 配置复杂度	低（Nginx 反代标准操作）	中（橙云注册+隧道端安装+隧道配置）	高（橙云注册+隧道端安装+隧道配置+NS 委派 + Token）
🎯 适用场景	生产 / 主力服务	纯静态展示 / 无备案妥协	技术探索 / 私人实验室

综上所述：

建议：除非你对 Cloudflare 和 DNS 委派有充分了解，且愿意承担掉壳风险和 28 天续命成本，否则请优先采用第7篇的 ECS 反代方案。
标准版 为本番外篇实机验证闭环形态，供进阶读者参考。
简化版 为探索未闭环的备案免 ECS 灰色备选（CDN/ECS 回源直 IP）。

树莓派4B自建网页服务器指南 （7.1）· 番外篇：Cloudflare Tunnel + 阿里云 CDN —— 零 ECS 备案保壳方案 ​

一、引言 ​

1.1 为什么还需要这个番外篇？ ​

1.2 ⚠️ 重要免责声明 ​

1.3 适用人群 ​

二、方案原理（两档） ​

简化版（CNAME 灰云） ​

标准版（NS 委派 + 橙云，实机验证通过） ​

三、DNS 架构（NS 委派，标准版） ​

四、Cloudflare Tunnel 配置（注册 / 建域 / 登录授权 / 隧道创建） ​

4.1 注册 Cloudflare 账号 ​

4.2 添加主域名（使 Tunnel 可创建） ​

4.3 绑定支付方式（Zero Trust 面板要求） ​

4.4 树莓派端安装 cloudflared 并授权 ​

4.5 创建隧道并配置 ​

4.6 启动隧道并设置开机自启 ​

4.7 迁移到 Zero Trust 面板（重要） ​

五、阿里云 CDN 配置 ​

5.1 添加加速域名 ​

5.2 证书配置 ​

5.3 备案要求 ​

六、潜在风险与注意事项 ​

6.1 Cloudflare Free 版稳定性风险（三档拆清） ​

6.2 备案审查风险 ​

七、标准版（NS 委派）实机验证闭环 ​

7.1 DNS 解析链路确权（排除 ULA 隐患） ​

7.1.1 验证 A/AAAA 记录是否直接返回 Cloudflare 的 Anycast 节点（关键：必须看到 104.x 或 2606:4700 段） ​

7.1.2 验证 NS 记录是否生效（确认委派成功） ​

7.2 穿透能力极限测试（光猫 IPv6 防护全开） ​

💡 原理复盘：为何光猫 IPv6 防护开启仍能通？ ​

7.3 容灾能力测试（IPv6 前缀变更） ​

八、总结 ​

树莓派4B自建网页服务器指南（7.1）· 番外篇：Cloudflare Tunnel + 阿里云 CDN —— 零 ECS 备案保壳方案

一、引言

1.1 为什么还需要这个番外篇？

1.2 ⚠️ 重要免责声明

1.3 适用人群

二、方案原理（两档）

简化版（CNAME 灰云）

标准版（NS 委派 + 橙云，实机验证通过）

三、DNS 架构（NS 委派，标准版）

四、Cloudflare Tunnel 配置（注册 / 建域 / 登录授权 / 隧道创建）

4.1 注册 Cloudflare 账号

4.2 添加主域名（使 Tunnel 可创建）

4.3 绑定支付方式（Zero Trust 面板要求）

4.4 树莓派端安装 cloudflared 并授权

4.5 创建隧道并配置

4.6 启动隧道并设置开机自启

4.7 迁移到 Zero Trust 面板（重要）

五、阿里云 CDN 配置

5.1 添加加速域名

5.2 证书配置

5.3 备案要求

六、潜在风险与注意事项

6.1 Cloudflare Free 版稳定性风险（三档拆清）

6.2 备案审查风险

七、标准版（NS 委派）实机验证闭环

7.1 DNS 解析链路确权（排除 ULA 隐患）

7.1.1 验证 A/AAAA 记录是否直接返回 Cloudflare 的 Anycast 节点（关键：必须看到 104.x 或 2606:4700 段）

7.1.2 验证 NS 记录是否生效（确认委派成功）

7.2 穿透能力极限测试（光猫 IPv6 防护全开）

💡 原理复盘：为何光猫 IPv6 防护开启仍能通？

7.3 容灾能力测试（IPv6 前缀变更）

八、总结