2026年自建节点CDN中转完全指南：用 Cloudflare 藏住源站 IP、泛域名证书与优选IP实操

自建节点最怕的不是"墙的算法有多聪明"，而是"你的 IP 已经被人知道了"。只要真实 IP 落进任何一份公开扫描结果，后面的事几乎是自动发生的：全网扫端口、探协议特征、封 IP，然后你重买机器、重配节点、挨个通知客户端改配置。CDN 中转要解决的就是这个起点问题——让客户端永远只连到 CDN 的地址，源站的真实 IP 从公开视野里消失。

这一篇讲的是入口层：域名怎么解析、证书怎么签、源站怎么配、优选 IP 怎么挑，以及什么人根本不该碰这套方案。如果你的 IP 已经被封、现在正在救火，顺序反过来——先看VPS 被墙后的诊断与救活三板斧，那篇是事故响应，本篇是事前的架构设计。

先把丑话说在前面：CDN 中转不是免费午餐，它多一跳、对 UDP 协议不友好，而且 Cloudflare 对"代理套 CDN"的态度写在条款里。三件事都摊开之后，结论会很清楚——对一部分人很值，对另一部分人纯属给自己找麻烦。如果算完发现不值得，直接用自由猫这类 IEPL 专线机场月付十几块，把折腾的时间省下来更划算。

一、CDN 中转解决什么、不解决什么

先把原理压缩成一句话：客户端连的是 CDN 的任意播 IP，CDN 再把流量转发（回源）到你的源站服务器，源站只跟 Cloudflare 的网段通信。对客户端来说，你的"服务器地址"永远是 CDN，而不是那台 VPS。

它能解决的：

源站 IP 隐藏。这是唯一真正不可替代的价值。IP 藏住了，针对 IP 的扫描、封禁、DDoS 都打在 CDN 身上。
被封后的"续命"效率。单 IP 被封时，只要换一个优选 IP 写进客户端，不用重装服务器、不用重新签证书、不用改服务端配置。
建站与代理共用一套入口。同一张证书、同一个域名，博客和节点各占一个路径，运维复杂度只增加一点点。

它解决不了的：

落地 IP 的质量。CDN 只改入口，出口还是那台机房 VPS。流媒体风控、平台多账号关联、需要原生或住宅 IP 的场景，CDN 帮不上任何忙。
总延迟。数据包多走一跳，还是免费套餐的公共线路，晚高峰的三网质量参差不齐。
UDP 协议。Cloudflare 代理的是 HTTP/HTTPS，Hysteria2、TUIC、QUIC 这类基于 UDP 的协议套不上去。
带宽上限。免费套餐对非 HTML 的大流量内容并不友好，这条后面单独说。

二、源站 IP 是怎么被找到的：五条常见路径

很多人以为"我买了域名、解析到 CDN 就安全了"，实际上 IP 泄露往往发生在你完全没注意的角落。下面五条按排查难易度排序，每条都给出对应的检查动作。

路径 1：DNS 历史记录。域名解析到 CDN 之前，如果曾经直接解析到 VPS，那条 A 记录会被各家历史解析库长期保存。搜索引擎、安全公司、爬虫都在收集这些数据。检查动作：换到 CDN 之前先确认域名从未直接解析过源站 IP；如果解析过，最干净的做法是换 IP 或换域名，而不是指望记录会消失。

路径 2：灰云记录与 DNS 里的杂项记录。同一张 DNS 里只要有一条灰云（DNS only）的 A 记录指向源站，或者 SPF、TXT、DMARC 里带上了源站的 IP，前面所有的隐藏工作归零。Cloudflare 官方在"保护源站"文档里明确要求：审计所有 DNS-only 记录，确认不含源站 IP 信息。检查动作：逐条过一遍域名下的记录，SPF 里的 ip4: 字段重点看。

路径 3：同机邮件服务。在源站上跑邮件服务是个隐藏地雷——向不存在的地址投递会被退信，退信过程会把邮件服务器的 IP 暴露出去。官方建议：能分开就分开，别让邮件服务和要保护的资源在同一台机器上。

路径 4：证书透明日志。任何公开 CA 签发的证书都会进证书透明（CT）日志，日志里带域名。这不直接暴露 IP，但会把你的子域名清单摊在阳光下，等于把扫描目标列表免费送人。检查动作：别用有意义的前缀命名节点子域，泛域名证书是更稳妥的选择（下一节讲）。

路径 5：端口扫描与推断。上面四条都堵住之后，剩下的风险来自"扫到你之后被贴出来"。缓解手段是三件事：只放行 Cloudflare 网段（第七节的闸门一）、源站只跑必要的服务、被封时不要在原 IP 上反复折腾。

三、Cloudflare 代理的边界：端口、协议与三个硬限制

能不能套 CDN，第一步是看你的服务能不能落进 Cloudflare 允许的端口和协议里。官方"Network ports"文档（2026 年 4 月更新）给的口径是固定的两串端口：

类型	支持的端口
HTTP 端口	80、8080、8880、2052、2082、2086、2095
HTTPS 端口	443、2053、2083、2087、2096、8443
支持但禁用缓存的端口	2052、2053、2082、2083、2086、2087、2095、2096、8880、8443

从这张表里能读出三个硬限制，它们决定了你的节点能做到什么程度：

限制一：只代理 HTTP/HTTPS，也就是 TCP。官方文档的措辞是"代理发往下列 HTTP/HTTPS 端口的流量"。想代理任意端口的 TCP 或 UDP，需要 Spectrum 产品，而全端口 Spectrum 只对企业版开放。这直接判了 UDP 协议"死刑"——Hysteria2、TUIC、QUIC 全都不能走 CDN 代理，只有基于 TCP 的 WebSocket、HTTPUpgrade、gRPC 这类传输层能套上去。如果你已经在用 UDP 协议并在那份 Hysteria2 调优指南里把 BBR 和端口跳跃都调过了，套 CDN 反而会让你回到 TCP，这部分收益要重新算。

限制二：中国线路只有 80 和 443。文档明确写着，80 和 443 是"China Network 启用后中国数据中心内 HTTP/HTTPS 流量"唯一兼容的端口。也就是说，如果你在意国内访问质量，非标准端口（2053、2083 这些）基本不用考虑，老老实实占 443。

限制三：非标准端口没有缓存。2052、2053、2082 等十个端口被官方标注为"支持但禁用缓存"。对代理节点来说缓存本来也无意义，但它侧面说明这些端口不是主力路径，稳定性和优化程度不如 443。

还有一条容易被忽略的成本：UDP 协议不支持 + 端口选择受限，意味着自建这条路在"协议灵活性"上被砍掉了一半。如果你的核心需求只是稳定的日常访问，而不是非要用某个特定协议，那买机场的实际成本可能比自建 + CDN 更低——比如瑶瑶领先的入门档是月付 9.9 元 384GB、3 台设备，这类价格档位下，自建的边际收益主要来自"完全可控"，而不是省钱。

四、证书两条路线：acme.sh 泛域名 vs Cloudflare Origin CA

套 CDN 之后证书这件事会被拆成两段：客户端到 CDN 这一段用的是 Cloudflare 的证书，自动签发、你不用管；Cloudflare 到源站这一段（回源）需要你自己的证书，这叫源站证书。这一段有两条常见路线。

对比项	acme.sh + DNS 验证（泛域名）	Cloudflare Origin CA
签发方	Let's Encrypt 等公开 CA	Cloudflare
验证方式	DNS-01，用 Cloudflare API Token 自动加 TXT 记录	在控制台或 API 直接生成
客户端是否信任	信任（公开 CA）	不信任，只有 Cloudflare 认
有效期与续期	90 天，靠定时任务自动续	可自选长期限
通配符	支持，一条命令签全域	支持，但只覆盖一级
适用场景	同一域名还要灰云直连、或挂别的 CDN	域名只走 Cloudflare 橙云

泛域名证书的申请命令在 acme.sh 文档里写得很直白，核心就是把域名和通配符一起列出来、并指定 DNS 服务商：

export CF_Token="你的Cloudflare-API-Token"
export CF_Account_ID="你的Account-ID"
acme.sh --issue -d example.com -d '*.example.com' --dns dns_cf

# 安装到指定路径，供 Nginx / Xray 使用
acme.sh --install-cert -d example.com \
  --key-file       /etc/ssl/private/example.key \
  --fullchain-file /etc/ssl/example.crt \
  --reloadcmd      "systemctl reload nginx"

用 DNS-01 验证的好处是：签证书的过程不需要域名已经指向任何地方，也不用开 80 端口，签完再改解析都来得及。通配符的含义是任何一级子域自动覆盖，这样以后加节点子域时不必重新签证书，也就不会在证书透明日志里多留一条记录。

Origin CA 的路线更省事，官方文档里几条细节值得记住：免费套餐即可用；证书与 Full (strict) 模式兼容；一张证书最多 200 个 SAN；通配符只能覆盖一级（*.example.com 和 *.secure.example.com 可以同时存在，但不能用一个通配符吃掉两级）；不能用 IP 地址做 SAN；创建时默认就包含域名本身和一级通配符。一个坑必须提醒：官方明确表示不会发送 Origin CA 证书的到期通知，所以要把它记进自己的证书清单或监控里。另外，Origin CA 证书只有 Cloudflare 信任，客户端拿它直连源站会报不受信任——这正是它的设计目的。

选择结论很实用：如果这个域名只走 Cloudflare 橙云，用 Origin CA，省掉续期这件事；如果同一个域名还要灰云直连、或者将来可能换 CDN，用 acme.sh 签公开证书，兼容性更好。

五、CDN 中转改变不了什么：出口 IP、延迟与条款风险

入口层做完了，接下来要认清这套架构的天花板。它有三处上限，其中第三处不是技术问题。

上限一：出口 IP 的属性没变。CDN 藏的是"你的服务器在哪"，不是"你的出口是什么 IP"。机房 IP 依旧是机房 IP，做流媒体解锁会撞上风控，做多账号运营容易触发关联。这类需求属于 IP 类型问题，得从出口侧解决——需要原生或住宅 IP 的话，仙路湾这类原生/住宅 IP 机场对 4 台设备、50GB 月付 9.9 元起，走的正是这条路子。想同时要"入口隐藏 + 出口纯净"，正确做法是自建做前置、机场做落地，也就是机场与自建 VPS 的混合架构那套思路，而不是把 CDN 当成万能药。

上限二：延迟只会变高。多一跳就是多一跳。CDN 的节点位置、回源线路、以及节点到源站的那段"最后一公里"，都会叠加到延迟上。对实时性敏感的场景——跨市场交易的盘口刷新、竞技游戏、远程桌面——CDN 中转不是优化手段，而是额外的抖动来源。

上限三：条款风险，这条必须自己判断。Cloudflare 对"用 CDN 代理流量"有明确限制。CloudflareSpeedTest 这个几乎人手一个的优选 IP 工具，README 顶部就挂着一句警告：Cloudflare CDN 已明文禁止代理方式使用，对于"代理套 CDN"的请自行承担风险，不要过度依赖。这句话不是社区传言，是工具作者写在自己项目首页的风险提示。也就是说，这套方案随时可能因为对方策略调整而失效——所以它只能是"提高生存概率"的一环，不能是唯一依赖。真正被针对时能救你的，还是换 IP、换协议、换入口那一套应急预案。

六、源站配置实战：三条能套 CDN 的传输路线

能被 Cloudflare 代理的传输方式，本质都是"长得像 HTTP"的那几种。三种主流做法的差异集中在下表：

传输方式	协议要求	官方注意点	适合谁
WebSocket	HTTP/1.1 升级请求	特征明显（ALPN 为 http/1.1），官方建议迁往 XHTTP	兼容性最好的默认选择，客户端支持最广
HTTPUpgrade	HTTP/1.1 升级，实现比 WS 轻	效率更高，但设计上不建议单独使用，需配合 TLS	想在 WS 与 gRPC 之间取平衡
gRPC	必须 443 + TLS + HTTP/2 且 ALPN 通告	WAF 只检查头部，不检查流内容；未开启时返回 403	已用 gRPC 客户端、要求 HTTP/2 的场景

WebSocket 的实际配置要点，客户端和服务端两边都要对齐三样东西：路径（path）、Host 头、以及心跳。Xray 的 wsSettings 里除了 path 和 host，还有一个 heartbeatPeriod 参数用于保持连接活跃，这在套 CDN 时比直连更重要——Cloudflare 会在连接双向都没有数据传输一段时间后主动断开，长连接靠的就是心跳。

服务端通常还会在前面放一层 Nginx，把某个路径反代到本地监听端口，回源链路就变成了"Nginx(443) → 本地 127.0.0.1:某端口"：

server {
    listen 443 ssl http2;
    server_name node.example.com;

    ssl_certificate     /etc/ssl/example.crt;
    ssl_certificate_key /etc/ssl/private/example.key;

    location /ws-path/ {
        proxy_pass http://127.0.0.1:10000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这里有三个实践细节。第一，路径别用 /ws 这种一眼能认出来的名字，随机长路径能顺手挡掉一部分批量扫描。第二，如果服务端是多用户、多协议的面板化管理（比如3X-UI 面板的多协议与用户管理那套），反代路径要和面板里的入站配置严格一致，路径写错的表现是 400 或直接断连，不是报错日志。第三，如果不想碰域名和证书，还有一条完全不同的路——REALITY 协议借用别人网站握手、不需要自己签证书，代价是无法使用 CDN 中转；这两套方案在"防探测"上的思路是互斥的，选一套走到底，别混搭。

还有一笔账要算清楚：CDN 只优化了入口，回程那一段（CDN 到源站）的线路质量完全由机房决定。对延迟敏感、或者需要长时间稳定连接的用途，与其在优选 IP 上反复试，不如直接用纯专线出口——SS-ID 是全 IEPL 专线的做法，100GB 月付 20 元、5 台设备，走的是"不经过公网绕行"的思路，和 CDN 中转解决的不是同一个问题。两者甚至可以同时存在：CDN 入口用来抗封锁，专线用来保证质量。

七、优选IP：从公开网段里挑一条好走的回程

套 CDN 之后会遇到一个新问题：域名解析出来的那个 CDN IP，对你的运营商不一定是好走的。Cloudflare 的机位是任意播，同一域名在不同地区、不同运营商解析到的地址可能不同，而免费套餐的公共地址在晚高峰经常出现某一条特别慢的情况。解决办法是从 Cloudflare 公开的地址段里自己挑一个更快的 IP——这就是"优选 IP"。

先把规模量化一下。今天从 Cloudflare 官方公开的 IP 列表（ips-v4 / ips-v6）统计出来：IPv4 共 15 个网段、合计约 152 万个地址（按 /24 切开大约是 5956 个网段），另有 7 个 IPv6 网段。这么多地址靠手工 ping 是不现实的，所以才需要工具。

社区里最常用的是 CloudflareSpeedTest（XIU2 的开源项目），它的做法是：批量测这些地址的延迟，再对通过延迟阈值的地址做下载测速，最后按速度排序输出一个结果文件。典型用法是先测延迟、再用结果做下载测速，最后把胜出的 IP 填进客户端：

# 一次跑完：延迟测速 → 对延迟最低的若干个做下载测速 → 结果写入 result.csv
# -n 并发线程数（默认 200）、-t 每个 IP 的延迟测速次数（默认 4）
# -tl 平均延迟上限、-sl 下载速度下限、-dn 下载测速数量（默认 10 个）
./cfst -n 200 -t 4 -tl 200 -sl 5 -dn 10 \
  -url https://speed.cloudflare.com/__down?bytes=100000000 \
  -o result.csv

# 只想看延迟、不做下载测速：加 -dd（结果按延迟排序）
./cfst -dd -n 200 -t 4 -tl 150 -o result.csv

# 客户端里：server 填优选 IP，SNI/Host 仍填自己的域名
#   server: 104.16.x.x
#   servername: node.example.com
#   ws path: /your-random-path/

它的默认抽样策略也值得知道：每个 /24 段随机挑一个 IP 测，所以对着上面统计出的约 5956 个 /24 段跑一遍，其实是"每个段抽一个代表"，想全量测要显式加参数。另外两条来自工具作者的风险提示要记住：在服务器上跑 HTTPing 本质上算网络扫描行为，并发（-n）开太高可能被商家暂停服务；如果出现"第一次测得可用 IP 正常、后面越测越少甚至为 0，过一会儿又恢复"，那是被运营商或 Cloudflare 判定为扫描触发了临时限制，降并发就够了。

三个关键认知，缺一个都会踩坑：

优选 IP 换的是"入口地址"，不是"身份"。客户端的 server 填优选 IP，但 SNI 和 Host 必须还是你自己的域名，否则证书和路由都对不上，表现就是连得上但打不开。
结果会过期。CF 的地址是共享的，路由和负载随时在变，今天测出来最快的 IP，可能几天后变成最慢的甚至不通。要把它当"耗材"看待，定期重跑，最好在客户端里准备多个候选地址并配上故障切换——这就是多节点热备与 DNS 级切换要解决的问题。
优选解决不了源站瓶颈。如果源站本身带宽小、或者回程线路差，客户端到 CDN 这一段再快也没用。测速前先确认瓶颈在哪一段。

八、四道闸：别让 CDN 白套

隐藏 IP 这件事，成败往往不在"有没有套 CDN"，而在"有没有漏"。下面四道闸，缺任何一道都可能把前面的工作归零。

闸门一：源站只放行 Cloudflare 网段。源站的防火墙应只允许来自 Cloudflare 公开地址段的入站连接（也就是上面统计的那 15 个 IPv4 段和 7 个 IPv6 段），其余一律拒绝。这一条同时解决两个问题：扫描器扫不到端口，即使有人偶然猜到源站 IP 也连不上。用安全组或主机防火墙都能做，关键是要定期同步官方列表，因为地址段是会变的。

闸门二：Authenticated Origin Pulls（双向 TLS）。只放行 IP 段仍然有一个假设——"来自这个 IP 的请求就是 Cloudflare 转发的"。Authenticated Origin Pulls 用客户端证书把这层校验做实：源站验证请求确实由 Cloudflare 发起，否则拒绝。官方文档对它的描述就是"确保发往源站的请求来自 Cloudflare 网络"。开启之后，任何伪造源 IP 的尝试都会在 TLS 握手阶段失败。

闸门三：头部与路径校验。Cloudflare 支持用转换规则给回源请求追加自定义请求头，源站侧校验这个头存在且值正确，不匹配的直接拒绝。配合随机化的 WS 路径，批量扫描工具即使摸到了源站，也很容易在第一步就被筛掉。这类做法的安全等级官方给的评价是"中等"，够用但不是终点。

闸门四：收敛暴露面。源站上不要同时跑邮件、面板、网站和节点；管理端口改到非标准端口并只对自己的办公 IP 或跳板机开放；面板能关掉公网访问就关掉。加固这件事有一整套清单，VPS 安全加固实战那篇里的 fail2ban、SSH 加固、最小权限部分可以直接照搬，不需要为 CDN 场景重写一遍。

九、决策框架：什么情况该套 CDN，什么情况不该

你的情况	判断	更合适的做法
源站 IP 曾在公开渠道出现过，或所在机房被重点关照	该套	CDN 中转 + 全套闸门，优先解决"IP 不再暴露"
只要日常稳定访问，不想折腾	不该套	直接月付机场，省下的时间成本远超差价
必须用 Hysteria2 / TUIC 等 UDP 协议	套不上	国内中转机方案，或改用 TCP 系传输
需要原生 IP / 住宅 IP（流媒体、多账号）	套了也没用	从出口侧解决，或自建前置 + 机场落地
延迟敏感（交易、游戏、远程桌面）	谨慎	纯专线出口优先，CDN 只作为备用入口
想省掉域名和证书的整个环节	不该套	REALITY 路线，或直接用机场订阅

再补一个容易被忽略的时间成本账：CDN 中转要维护的东西比裸奔的自建节点多了一整层——域名续费、证书续期、优选 IP 定期重测、防火墙 IP 段同步、以及故障时"到底是 CDN 的问题还是源站的问题"的排查成本。这些成本不会出现在账单上，但会持续消耗你的注意力。所以判断标准不是"能省多少钱"，而是"你愿不愿意长期为这套东西负责"。如果答案是不愿意，把入口层直接外包给机场是更理性的选择，自建就留给那些确实需要完全可控的场景。

十、八个高频故障

Q1：解析改成橙云后，客户端连上了却打不开网页，或者提示证书错误。几乎都是 SNI/Host 与域名对不上。用优选 IP 时尤其容易犯——server 字段写了 IP，却忘了 servername 还是自己的域名；或者服务端监听域名与证书覆盖的域名不一致。先核对这三处字符串完全一致。

Q2：访问返回 522 或 524。522 表示 CDN 连不上源站，524 表示连上了但等回应超时。按顺序排查：源站本地端口是否在监听、防火墙是否放行了 Cloudflare 网段、Nginx 是否真的在跑。注意：此时从你自己的机器直连源站是通的，不代表 CDN 能通——因为闸门一可能把你的 IP 也挡了，这类"自己通、CDN 不通"的对照最容易把人带偏。

Q3：返回 1016。源站域名解析失败，常见于源站地址写成了内网名、或者 DNS 记录被误删。检查 CDN 侧配置的源站主机名能不能解析。

Q4：WebSocket 每隔几分钟断一次，重连后又能用。这是空闲超时，不是配置错误。Cloudflare 会在双向都没有数据一段时间后关闭连接，解决办法是打开客户端心跳（Xray 侧的 heartbeatPeriod），或者让上层应用周期性地发一个小包。

Q5：配了优选 IP，速度却没变化。先分清瓶颈在哪一段：用同一 IP 换不同 SNI 测，如果都很慢，问题在回程或源站带宽；如果只有某些 IP 慢，是优选结果过期。另一个常见原因是优选时用的测速地址与实际业务不同，运营商对不同目标的回程路由并不一样。

Q6：gRPC 线路返回 403。官方口径很明确：当 zone 没有开启 gRPC 时，Cloudflare 会对 gRPC 请求返回 403。另外三条要求也要同时满足——源站监听 443、支持 TLS 与 HTTP/2 并在 ALPN 中通告、Content-Type 为 application/grpc 系列，且主机名必须是橙云。

Q7：Hysteria2 套 CDN 一直连不上。不用查了，Cloudflare 代理的是 HTTP/HTTPS（TCP），UDP 不在支持范围内。要用 UDP 协议就别套 CDN，或者换回 WebSocket / HTTPUpgrade / gRPC。

Q8：开了防火墙只剩 Cloudflare 网段之后，自己的 SSH 也进不去了。顺序错了。加固之前先给自己留一条管理通道：单独放行管理端口给自己的固定出口 IP，或者从云厂商控制台进，改完再确认一遍规则顺序。这类"把自己锁在门外"的事故在加固类操作里出现频率最高。

十一、一页速查卡

端口：HTTP 用 80、8080、8880、2052、2082、2086、2095；HTTPS 用 443、2053、2083、2087、2096、8443；国内线路只认 80 和 443。
协议：能套 CDN 的只有 TCP 系（WS / HTTPUpgrade / gRPC），UDP 系（Hysteria2、TUIC、QUIC）不行。
证书：只走橙云选 Origin CA（免费、无到期提醒）；还要灰云直连就用 acme.sh 签泛域名，90 天一续。
配置三段式：客户端（server=优选 IP、SNI=域名、path=随机路径）→ CDN（橙云、SSL 至少 Full）→ 源站（Nginx 443 反代本地端口、只放行 CF 段）。
四道闸：只放行 CF 网段 → Authenticated Origin Pulls → 自定义头校验 → 收敛暴露面。
定期做三件事：重跑优选 IP、同步 CF 地址段、检查证书与域名到期。
红线：Cloudflare 不欢迎用 CDN 代理流量，优选 IP 工具作者也明确提醒自行承担风险——把它当提高生存率的一环，别当唯一依赖。