§5 落地配置：把优选真正接到自己的站点
状态：架构与官方边界已可用。官方 SaaS 事实来自官方文档 [DOC]；架构素材来自 M-002 / M-004（社区）。 仍待确认：两条 TXT 的字段级官方表述（
F-031）。
5.0 前提
- 要加速的 Host 必须是 Cloudflare 上的橙云（代理）记录（§0.2）
- 需要 Cloudflare for SaaS 的自定义主机名能力。官方口径（[DOC]）："bundled with non-Enterprise plans"（非企业计划内置），企业版为 add-on
- 社区经验（M-004）另称"需要账号绑定了 payment method"——两说并列陈述，以官方口径为主（
F-027） - 已有一个能正常访问的回源站点
- 若采用分地区解析方案：还需要一个支持分地区解析（region-based resolution）的 DNS 服务商（阿里云 / 腾讯云 / 华为云等）
5.1 官方标准模型：自定义主机名 → 回退源
官方（[DOC]）："Custom hostnames are routed to a default origin server called fallback origin. This configuration is available on all plans."
用户访问业务域名
↓
Cloudflare 边缘（识别该 hostname 是"某账号下的自定义主机名"）
↓
回退源（fallback origin，指向你的源站）
↓
你的服务器官方还给出两条容易被忽略的硬约束（[DOC]）：
| 约束 | 说明 |
|---|---|
| 默认不支持 A 记录指向 target | 标准链路是「客户域 CNAME → CNAME target → fallback origin」；若必须用 A 记录，需要 Apex Proxying（企业版 add-on）。因此"把业务域 A 到筛出的优选 IP"不是官方支持方案（F-043） |
| custom origin 不能填 IP | 若为不同 hostname 配不同源站，custom origin 必须是账号内已存在的、带代理的 hostname（A/AAAA/CNAME），不能直接填 IP（F-044） |
回源身份细节（[DOC]）：CF 默认不修改客户端发送的 Host；发往 fallback host 时，源站 TLS SNI 与客户 Host（即 custom hostname）匹配；发往 custom origin 时 SNI 改为 custom origin。这解释了为什么"只替换 DNS 里的 A 记录"无法复现正确的 Host/SNI 与 hostname 状态机（F-045）。
5.2 三种落地架构（必须区分，不能混讲）
| 架构 | 谁走优选 | 做法 | 出处 |
|---|---|---|---|
| A. 全量 CNAME 到优选域名 | 所有人 | 业务域名 CNAME 到优选域名（关黄云），海外用户也被带去优选节点 | M-002 |
| B. 分地区解析 | 仅中国大陆用户 | 子域名 NS 委派给国内 DNS 商，按"解析请求来源"分流：境外 → 回源域名 / 中国 → 优选域名 | M-004 |
| C. 本地 hosts / 本地 DNS | 只有自己那几台设备 | 直接改本机解析，零侵入、随时可撤 | 通用实践 |
| D. A 记录直写优选 IP | ❌ 不推荐 | 不在官方机制内（5.1 已证）；IP 一变全站挂 | — |
架构 B 的完整操作（M-004，推荐给有大陆用户的站点）
- 主域托管在 CF，为回源加一条 A 解析（如
origin.example.com→ 你的服务器，开黄云） - CF → SSL/TLS → 自定义主机名：配置默认回源 = 上述回源域名；再添加自定义主机名 = 业务域名
- 把要优选的子域名添加到国内 DNS 商（示例用阿里云）：
- 按提示先加
alidnscheck.<你的域名>的 TXT 授权验证 - 验证通过后，国内 DNS 商分配 NS 地址
- 回到原 DNS 服务商，为该子域添加 NS 记录指向这些地址
- 在该国内 DNS 商里按 CF 要求添加记录（5.3），并配置两条按来源分流的 CNAME：
- 解析请求来源 = 境外 → 回源域名
- 解析请求来源 = 中国地区 → 优选域名（社区推荐
saas.sin.fan） - 回 CF 自定义主机名页面刷新，两个"待定"全部变为有效即成功
大陆用户 ─（国内 DNS 分地区解析）─> 优选域名解析出的 CF 边缘 IP ─
海外用户 ─（国内 DNS 分地区解析）─> 回源域名对应的 CF 边缘 IP ──┤
└─> CF 边缘（自定义主机名）─> 回退源 ─> 源站为什么 B 优于 A：A 让海外用户也被拉去"为大陆优化过的"节点；B 只把大陆流量导向优选节点。代价是多一个 DNS 商、多一层 NS 委派。
5.3 需要添加的记录清单
| 记录 | 用途 | 来源 |
|---|---|---|
TXT _acme-challenge.<业务域名> | 证书签发验证 | M-004（F-031） |
TXT _cf-custom-hostname.<业务域名> | 自定义主机名归属验证 | M-004（同上） |
| CNAME（境外来源）→ 回源域名 | 海外用户的路径 | M-004 |
| CNAME（中国来源）→ 优选域名 | 大陆用户的优选路径 | M-004 |
| NS（子域委派）→ 国内 DNS 商分配的 NS | 让国内 DNS 商有权回答该子域解析 | M-004 |
验收判据：CF 自定义主机名页面上的两个"待定（Pending）"状态全部变为有效（Active）。
5.3.1 官方验证契约（社区做法与官方契约的张力所在）
官方 Hostname validation 文档（[DOC]）给出四条硬事实：
- 归属验证与证书验证是两套 token、两个状态：
ownership_verification/ownership_verification_http→ 影响自定义主机名status；ssl.validation_records→ 影响ssl.status - 生产环境要求三者同时成立：
status: active+ssl.status: active+ DNS 指向你的 SaaS target - 使用其他 CDN 会导致验证失败：官方明确 "Custom hostnames using another CDN are not compatible with Cloudflare for SaaS"——若客户使用其他 CDN 且 DNS 记录被混淆，归属验证会失败（
F-048） - 同一域名可被多个 SaaS 提供方同时持有 active 状态；CF 按 DNS CNAME 指向谁决定哪个 SaaS zone 收流量（
F-049）——这也是"换了 CNAME 目标就换路由"的机制来源
⚠️ 张力必须写清：官方生产要求是"DNS 指向你的 SaaS target"，而社区优选做法是把业务域名 CNAME 到第三方优选域名。两者不是同一件事：
- 优选域名（
saas.sin.fan→104.18.42.163）解析出的是边缘 IP，不是另一个 SaaS 提供方的 target - 实测证明边缘按 SNI/Host 路由后确实能返回站点（E-01），但官方文档未把"自有域 CNAME/A 到第三方共享边缘 IP"定义为受支持的生产接入契约（
F-042）
教程写法：先给官方契约，再给社区做法，并标注后者"实测可行、非官方承诺"。
5.4 根域名（apex）怎么办
| 路径 | 条件 | 说明 |
|---|---|---|
| 标准自定义主机名 | 所有计划 | 基于 CNAME，不覆盖根域名 |
| Apex Proxying（官方方案） | 企业版 add-on | 官方为"客户使用不支持 apex CNAME 的 DNS 商"提供根域名支持 |
| 外置 DNS 绕行（社区） | 非企业计划 | 再 import 一个域名：回源域名托管 CF，业务根域名托管到 DNSPOD / 华为云等，最后业务域名 CNAME 到优选域名（M-002） |
5.5 能力边界（两面都要说）
A. 客户 zone 侧的限制（官方 Limitations，[DOC]）：如果客户自己的应用已在 Cloudflare 上，那么对被你的自定义主机名接管的 hostname，他们无法控制：Argo、Early Hints、Client-side security（Page Shield）、Spectrum、Wildcard DNS（F-026）。
B. 服务商侧确实有对应能力（官方专页，[DOC]）：Argo for SaaS、Cache for SaaS、Early Hints for SaaS、Secure with Cloudflare Access、WAF for SaaS（F-046）。
两件事并存：服务商侧有这些能力，客户端 zone 侧的控制权受限。所以"走优选后 CF 能力全失效"是错的，"和全球 zone 完全等同"也是错的。
5.6 必读风险清单
| 风险 | 说明 | 建议 |
|---|---|---|
| 第三方掌握你的流量路径 | 业务域名 CNAME 到别人的域名，对方随时可改其解析目标（E-09：saas.sin.fan 只返回 1 个 IP，改一下全站换路） | 优先自建优选（§4）；至少定期核查解析结果 |
| 单 IP 型优选域名是单点 | E-09 对比 | 关键业务别押在单一第三方 IP 上 |
| 优选结果会失效 | E-06 与 20 分钟后重跑：可用集合明显变化 | 定期重跑；不要写死 IP |
| 受限 IP 混入 | 403 + error code: 1034（E-07） | 用 §4.3 判据剔除 |
| TOS 争议 | M-002 自陈"可能违反 TOS"，又称"没见大规模封号" | 只陈述争议，不替读者下结论 |
| 官方契约差异 | 5.3.1：官方要求 DNS 指向你的 SaaS target | 自行评估风险 |
| 能力取舍 | 客户 zone 无法控制 Argo / Early Hints / Spectrum / Page Shield / 通配 DNS（5.5） | 先算"优选收益 vs 失去的控制权" |
| 与 Access 策略冲突 | 同账号下 SaaS 回源优选与 Access 应用策略不能同时生效（5.8，M-026） | 业务域名与回源域名分账号 |
| 回源域名可被直连 | 直连回源域名会绕过 Access 与优选（5.8） | 安全规则对回源域名下阻止 |
| 回源证书链 | 回源 TLS 失败会得到 525（E-05） | SSL 模式与源站证书状态要匹配 |
5.8 【重点踩坑】优选与 Access 应用策略的账号级冲突（M-026）
社区有作者记录了一次完整踩坑（idcflare 主题，2026-01-31）：配好 SaaS 回源优选之后，域名的邮箱验证（Access）策略失效了。
| 结论 | 内容 | 等级 |
|---|---|---|
| 冲突现象 | 同一账号下无法同时生效 SaaS 回源优选 与 Access 应用策略 | [COMMUNITY] |
| 机制解释 | 被访域名与回源域名需分离到不同账户；否则策略失效（作者转述 CF 的防滥用机制） | [COMMUNITY]，官方原文待核验 |
| 衍生坑 | 换账号后反代域名 404 → 实际不需要改本地配置，是隧道面板的 CatchAll 没设 | [COMMUNITY] |
| 正解（关键） | 在安全规则里对「回源域名」下“阻止” → 优选依旧生效，同时阻断直连回源与恶意流量 | [COMMUNITY]，强烈建议采纳 |
为什么“阻止回源域名”是正确设计：优选架构里，回源域名（SaaS target / fallback origin 那条）本身就是一个可被公网直接解析访问的入口。若不拦，任何人都能绕过：
用户 → 你的业务域名（经优选，受 Access 保护） ← 正常路径
攻击者 → 回源域名（直连，绕过 Access 与优选） ← 必须“阻止”落地清单：
- 业务域名与回源域名分账号（若你确实要同时用 Access 策略）
- 安全规则 / WAF 对回源域名下
Block - 隧道面板确认 CatchAll 规则（避免“配好了却 404”）
- 回归验证：用一条真实未授权写请求确认返回 401（见 §5.6 与附录 A）
5.7 给小白的选择顺序
- 先用架构 C（hosts） 在自己机器上验证"这个 IP 确实更快"——不碰生产 DNS，随时可撤
- 确认收益后：站点有大陆用户 → 架构 B；只有海外用户 → 大概率不需要优选，先看 §7
- 永远不要选架构 D