Cloudflare 的边缘有两个高频玩法:一是给已经套好的 CDN 入口做优选,从 CF 几千个 IP 里挑出对你这条线路最快的几个;二是用 Cloudflare Tunnel 把内网服务零端口暴露到公网。前者解决“入口慢”,后者解决“没有公网入口”。本文先讲优选,再讲 Tunnel。
一、三种“优选”的区别
把节点套上 Cloudflare CDN 之后,速度往往比直连还慢——因为 CF 默认分配给你的 IP 不一定离你近。这时候就需要“优选”:从 CF 的几千个 IP 里挑出对你这条线路最快的几个,让客户端只连这些 IP。
但“优选”这个词在社区里被用得很乱,官方优选 IP、反代优选 IP、优选域名是三个不同的东西:
graph TD
C[客户端] --> Q{填什么入口?}
Q -->|CF 官方 IP| O[官方优选
挑 CF 自家 IP]
Q -->|别人 VPS 的反代 IP| R[反代优选
挑别人架的反代]
Q -->|一个域名| D[优选域名
域名背后是一堆 IP]
O --> CF[Cloudflare CDN]
R --> VPS[云厂商 VPS
跑着 Nginx 反代] --> CF
D --> X{解析出的是?}
X -->|官方 IP| CF
X -->|反代 IP| VPS
CF --> S[你的源站 VPS]
VPS --> CF| 类型 | 入口 IP 来源 | 端口要求 | 稳定性 |
|---|---|---|---|
| 官方优选 IP | Cloudflare 自家 IP 段 | 13 个端口通吃(80/443/2052/…) | 最稳 |
| 反代优选 IP | 别人 VPS 跑反代的 IP | IP 和端口强绑定,扫到啥端口用啥 | 一般,反代主人随时可能停 |
| 优选域名 | 大厂域名解析出来的 IP | 看域名后面挂的是官方 IP 还是反代 IP | 取决于背后 |
关键认知:CF CDN → 你的源站这一段路由是固定的,优选只能优化“你 → CF 入口”这一段。
二、CF 官方 IP 段
所有 CF 公网 IP 的完整列表:
https://www.cloudflare.com/ips/主要是这几个段(IPv4):
173.245.48.0/20
103.21.244.0/22
103.22.200.0/22
103.31.4.0/22
141.101.64.0/18
108.162.192.0/18
190.93.240.0/20
188.114.96.0/20
197.234.240.0/22
198.41.128.0/17
162.158.0.0/15
104.16.0.0/13
104.24.0.0/14
172.64.0.0/13
131.0.72.0/22任意 CF 官方 IP 都能做你域名的入口(前提是你的域名套了 CF CDN)。
三、官方优选 IP 实操
3.1 用 CloudflareSpeedTest
https://github.com/XIU2/CloudflareSpeedTest下载对应平台的二进制(Windows/macOS/Linux 都有)。基本用法:
# Linux / macOS
./CloudflareST
# Windows
.\CloudflareST.exe常用参数:
| 参数 | 含义 |
|---|---|
-n 200 |
延迟测试线程数(默认 200) |
-t 4 |
每个 IP 测延迟次数 |
-dn 10 |
下载测速数量(最快的几个进入下载阶段) |
-dt 10 |
下载测速时间(秒) |
-tl 200 |
平均延迟上限(ms),超过的不要 |
-tll 40 |
平均延迟下限(避免数据中心间假快) |
-tlr 0.2 |
丢包率上限 |
-p 10 |
输出前 N 个结果 |
-f ip.txt |
指定 IP 段文件 |
-o result.csv |
输出 CSV |
实战示例:
# 标准跑法
./CloudflareST -n 500 -t 4 -dn 20 -dt 10 -tl 200 -tll 40
# 限定国家段(手动准备 ip.txt 只放某个段的)
./CloudflareST -f ip.txt -p 10 -o result.csv测速结果取决于本机到各 CF 数据中心的路由,在你的常用网络环境各测一遍再固定优选 IP。
3.2 输出示例
IP 地址 已发送 已接收 丢包率 平均延迟 下载速度 (MB/s)
104.20.157.18 4 4 0.00 35.21 12.45
172.67.128.45 4 4 0.00 38.10 10.21
104.18.32.99 4 4 0.00 41.50 9.873.3 写进客户端
跑完输出 IP 列表 + 延迟 + 下载速度。把最快的几个填到客户端节点配置里,替换 CDN 入口域名。把 CF 入口 IP 写到节点 server 字段:
# mihomo 节点示例
proxies:
- name: CF-Fast
type: vless
server: 104.20.157.18 # 优选出来的 IP
port: 443
uuid: your-uuid-here
tls: true
servername: your-cdn-domain.com # 真实的 CDN 域名(SNI 不能改)
network: ws
ws-opts:
path: /your-path
headers:
Host: your-cdn-domain.com核心:server 换成优选 IP,但 servername(SNI)和 Host 头必须保留原域名——否则 CF 不知道你要访问哪个域名。
四、反代优选 IP 是什么
反代优选 IP 是别人的 VPS 在帮你“转发到 Cloudflare”:
- 某人在云厂商(甲骨文 / AWS / 阿里 / 腾讯)开了台 VPS
- 在上面架了 Nginx,把
443转发到一个 CF 域名 - 你通过扫描发现“这台 VPS 的 IP + 这个端口可以当 CF 入口”
- 你把它当 CF 入口 IP 用
特征:
- IP 常见
8.x.x.x、47.x.x.x这类常见云厂商段 - IP 和端口强绑定:扫到 443 就只能用 443
- 稳定性差:反代主人随时可能关掉 / 改配置
反代 IP 本质是借用别人的带宽,不建议长期依赖。商业行为甚至涉及法律风险,重要服务不要押注在这上面。
五、优选域名
优选域名本身算不上一门新技术,本质是用域名把一堆 IP 打包起来。
5.1 类型 A:解析为 CF 官方 IP
典型的“大厂套 CF 域名”,比如某些跨国公司用了 CF:
visa.com ← 解析出来是 CF 官方 IP
wto.org ← 同上用法:
- 客户端
server字段填这个大厂域名 servername/Host仍然填你自己的 CDN 域名
效果跟“官方优选 IP”等价,只是入口换成了“这个域名当前解析到的 CF 官方 IP”。
5.2 类型 B:解析为一堆反代 IP
域名的 A 记录是一池子反代 VPS 的 IP:
cdn-fast.example.com A 8.1.2.3
cdn-fast.example.com A 47.4.5.6
cdn-fast.example.com A 103.7.8.9客户端每次连接,DNS 轮询选一个。两个关键注意点:
- IP 地区要尽量一致:如果日本/新加坡/美国混在一起,每次连可能国家在跳,敏感站会触发风控。
- 所有 IP 的端口要统一:如果节点写 443,A 记录里每个 IP 都必须在 443 上跑有效反代。
5.3 优选域名列表
社区维护的现成列表:
https://www.wetest.vip/page/cloudflare/cname.html里面给了一堆“扫好的”域名,标注了对应的运营商 / 地区。
六、DNS 知识补课:一域名多 IP 是怎么实现的
理解优选域名要先理解 DNS 多记录:
cdn.example.com A 1.1.1.1
cdn.example.com A 2.2.2.2
cdn.example.com A 3.3.3.3DNS 解析时一次返回所有 IP,客户端选一个连(不同系统策略不同:轮询、按顺序、最快)。
也可以 IPv4 + IPv6 同时挂:
cdn.example.com A 1.1.1.1
cdn.example.com AAAA 2400:xxxx::xxx或者用 CNAME 指向另一个域名,间接拥有一堆 IP:
cdn.example.com CNAME fast-pool.cdn-provider.xyzfast-pool.cdn-provider.xyz 下面挂着十几个 IP,由 CDN 提供方维护。
七、自动化:定时优选 + 自动写回 DNS
进阶玩法:用脚本定时跑 CloudflareST,把 Top N 的 IP 写到自己 CF 域名的 A 记录里:
#!/usr/bin/env bash
set -e
# 1. 跑优选
./CloudflareST -n 500 -t 4 -dn 10 -dt 10 -tl 200 -p 5 -o result.csv
# 2. 解析前 5 个 IP
IPS=$(awk -F, 'NR>1 {print $1}' result.csv | head -5)
# 3. 调 CF API 把这些 IP 写到 DNS(伪代码)
for ip in $IPS; do
curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
-H "Authorization: Bearer $CF_TOKEN" \
-H "Content-Type: application/json" \
--data '{"type":"A","name":"fast","content":"'$ip'","ttl":120,"proxied":false}'
done挂到 cron:
0 4 * * * /path/to/auto-optimize.sh > /var/log/cf-optimize.log 2>&1每天凌晨 4 点重新优选 + 更新 DNS。
这个脚本是示意,实际需要先清除旧 A 记录再加新的。CF API 文档:Cloudflare API Docs。
八、Cloudflare Tunnel:零端口暴露的内网穿透
把内网服务发布到公网,传统方案是 frp / ngrok / 端口转发——都需要一台公网 VPS 当跳板、花钱买套餐或在路由器开端口。Cloudflare Tunnel 提供免费解法:装一个客户端(cloudflared),它主动和 CF 的边缘建立反向连接,外网通过你的域名访问,全程 HTTPS,没有任何入站端口暴露。
8.1 为什么用 CF Tunnel
| 方案 | 公网 IP | 端口转发 | 费用 | HTTPS | DDoS 防护 |
|---|---|---|---|---|---|
| frp 自建 | 需要跳板 VPS | 是 | VPS 费用 | 需手动 | 无 |
| ngrok 免费版 | 不需要 | 否 | 免费但限速/限连接 | 自动 | 无 |
| 端口转发(路由器) | 需要 | 是 | 0 | 需手动 | 无 |
| CF Tunnel | 不需要 | 否 | 0 | 自动 | 有 |
适用场景:
- 家里跑 NAS / Jellyfin / HomeAssistant,想在外面访问
- 小公司内网服务给远程同事用,但没有公网 IP
- 临时把开发环境 demo 给别人看
- 树莓派跑几个服务想公开
8.2 工作原理
graph LR
U[外网用户] -->|HTTPS 访问 your-app.example.com| CF[Cloudflare 边缘节点]
CF <-->|加密长连接
主动从内网发起| CL[cloudflared 客户端
跑在你内网机器上]
CL --> S[内网服务
localhost:8080]关键点:
- cloudflared 主动连 CF,不需要内网开任何端口
- 流量走 CF → cloudflared → 本地服务
- 全程 TLS 加密,外网看到的是 CF 的 IP,看不到你的真实 IP
8.3 准备工作
| 项目 | 要求 |
|---|---|
| 域名 | 已托管到 Cloudflare(必须) |
| 内网机器 | Linux / macOS / Windows / 路由器 / Docker 都能跑 |
| Cloudflare 账号 | 免费版就够 |
域名还没在 CF 的话,先去 dash.cloudflare.com → Add Site → 跟着指引改 NS。
8.4 操作步骤(推荐 Dashboard 方式)
CF 现在主推 Zero Trust Dashboard 配置 Tunnel,比命令行直观。
进入 Zero Trust
CF 控制台 → 左侧 Zero Trust → 第一次会让你选个 Team 名(随便起)。
创建 Tunnel
Networks → Tunnels → Create a tunnel:
| 步骤 | 操作 |
|---|---|
| Connector type | 选 Cloudflared |
| Tunnel name | 随便起,如 home-nas |
| Save | 保存后会给你安装命令 |
在内网机器上跑 cloudflared
CF 会给一段类似这样的命令(不同平台不一样):
# Linux (Debian/Ubuntu)
curl -L --output cloudflared.deb \
https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb
# 服务化 + 用 CF 给你的 token 注册
sudo cloudflared service install <YOUR-TUNNEL-TOKEN># Windows
# 下载 https://github.com/cloudflare/cloudflared/releases 里的 .msi 安装
cloudflared.exe service install <YOUR-TUNNEL-TOKEN># Docker
docker run -d \
--name cloudflared \
--restart unless-stopped \
cloudflare/cloudflared:latest \
tunnel --no-autoupdate run --token <YOUR-TUNNEL-TOKEN>跑起来后回到 Dashboard,Connector 状态变成 HEALTHY。
配置 Public Hostname
Public Hostname → Add a public hostname:
| 字段 | 值 |
|---|---|
| Subdomain | nas(最终是 nas.your-domain.com) |
| Domain | 选你的域名 |
| Service Type | HTTP / HTTPS / SSH / RDP / TCP 等 |
| URL | localhost:8080(内网服务的地址) |
保存后 CF 会自动给你的子域名添加 CNAME 记录。
验证
curl -I https://nas.your-domain.com返回 200 / 301 等正常响应,整个流程就跑通了。
8.5 命令行方式(高级 / 想懂原理)
命令行方式每一步都看得见,适合想懂原理的情况。
安装
curl -L --output cloudflared.deb \
https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb
cloudflared --version登录 + 授权
cloudflared tunnel login会打开浏览器让你选 zone,授权完后凭证存在 ~/.cloudflared/cert.pem。
创建 tunnel
cloudflared tunnel create home-nas会输出 tunnel UUID,并把凭证存到 ~/.cloudflared/<UUID>.json。
写配置文件
~/.cloudflared/config.yml:
tunnel: <你的 UUID>
credentials-file: /home/youruser/.cloudflared/<UUID>.json
ingress:
- hostname: nas.your-domain.com
service: http://localhost:8080
- hostname: jellyfin.your-domain.com
service: http://localhost:8096
- hostname: ssh.your-domain.com
service: ssh://localhost:22
- service: http_status:404 # 兜底绑定域名 DNS
cloudflared tunnel route dns home-nas nas.your-domain.com
cloudflared tunnel route dns home-nas jellyfin.your-domain.com
cloudflared tunnel route dns home-nas ssh.your-domain.comCF 会自动加 CNAME。
跑 + 服务化
# 前台跑(测试)
cloudflared tunnel run home-nas
# 服务化
sudo cloudflared service install
sudo systemctl status cloudflared8.6 典型应用场景
把家里的 Jellyfin 发布到公网
ingress:
- hostname: video.your-domain.com
service: http://localhost:8096
- service: http_status:404外网浏览器访问 https://video.your-domain.com 看 NAS 上的电影。
SSH 到内网机器(不用 frp)
服务端配置:
ingress:
- hostname: ssh.your-domain.com
service: ssh://localhost:22客户端要装 cloudflared 做转发:
# 本地 cloudflared
cloudflared access ssh --hostname ssh.your-domain.com
# 或者写到 ~/.ssh/config
Host my-home
HostName ssh.your-domain.com
ProxyCommand cloudflared access ssh --hostname %h之后 ssh my-home 就能通到内网机器。
给路由器后台开公网入口
ingress:
- hostname: router.your-domain.com
service: https://192.168.1.1
originRequest:
noTLSVerify: true # 路由器自签名证书要加这条把路由器后台暴露公网风险很大,建议配合下面的 Access 鉴权。
8.7 加上 Access 鉴权(必看)
CF Tunnel 默认任何能访问域名的人都能进,一定要加访问控制。
Zero Trust → Access → Applications → Add an application:
| 设置 | 推荐 |
|---|---|
| Type | Self-hosted |
| Application domain | nas.your-domain.com |
| Policy → Action | Allow |
| Include | Emails / Email domains / Country / Device posture |
常用策略:
- Emails:只允许特定邮箱(输入 OTP 邮件验证码登录)
- Email domains:只允许
@your-company.com结尾 - Country:仅允许中国 / 美国
- Service Token:给 API/脚本访问用
加完之后,访问域名会先跳到 CF 的登录页,验证通过才进得去,免去自己写鉴权。
8.8 和 frp 对比
| 维度 | CF Tunnel | frp |
|---|---|---|
| 公网入口 | CF 边缘 IP | 你自己的 VPS IP |
| 协议 | HTTP/HTTPS(主)、TCP/SSH/RDP | 全协议 TCP/UDP |
| 配置复杂度 | 低(Dashboard 点点) | 中(写 ini 文件) |
| 自定义域名 | 必须用 CF 托管 | 任意 |
| 性能 | 走 CF 边缘,国内访问需绕 | 直连跳板 VPS,可选近 |
| 鉴权 | 内置 Access | 需自己加 |
| 国内访问 | CF 国内段速度不稳 | 选国内 VPS 跳板更快 |
国内访问 NAS / 自部署服务,有时候 frp + 国内 VPS 反而更快。CF Tunnel 的优势在于零配置 + 自带鉴权 + DDoS 防护。
九、优选 IP 与 Tunnel 的取舍
两份能力各自有边界,选型时留意:
- 优选优化的对象是你自己的 CF 接入端点;Tunnel 的 hostname 由 CF 托管解析(指向
<tunnel-id>.cfargotunnel.com),无法手动换成优选 IP,国内出口不稳时只能靠换机房、反代或换方案缓解。 - 优选 IP 适合已有 CF CDN 入口、想压满带宽的场景;Tunnel 适合家里 / 内网没有公网入口、想零暴露发布的场景。
- Tunnel 一个连接可以挂多个域名,每个服务单独建 Tunnel 没有必要;跑在 NAS 或一台独立小主机上比跑主路由稳,和软路由 / OpenWrt 混用容易 NAT 链路混乱。
- cloudflared 升级很重要:CF 偶尔会让旧版客户端失效,建议开
--no-autoupdate关掉自动升级、自己定期手动升级,避免半夜被自动重启打断。
十、常见问题
| 现象 | 原因 | 解决 |
|---|---|---|
| 优选完速度反而更慢 | servername/Host 没保留原域名 |
改回原域名 |
| 测的快用起来慢 | CF IP 是数据中心的 anycast,测速好但实际可能绕远路 | 多测几次 + 看下载速度而不只看延迟 |
| 反代 IP 用着用着失效 | 反代主人停了/改了 | 找新的,或转回官方 IP |
| 优选域名忽快忽慢 | A 记录里 IP 来自不同地区 | 选地区一致的 |
| 公司网/校园网测不准 | 公网出口走的代理/CDN | 用家庭网络测,或者用 VPS 测 |
| CF 反 DDoS 时优选 IP 全废 | CF 紧急情况下会临时切流 | 等几小时 |
cloudflared service install 报错 |
systemd 没启动 / 权限不够 | 用 sudo |
| Connector HEALTHY 但访问 502 | 内网服务没起 / 端口错 | curl localhost:端口 验证 |
| 自签名证书报错 | TLS 验证失败 | originRequest: noTLSVerify: true |
| 国内访问极慢 | CF 国内段不稳 | 考虑反代或换方案 |
| 配置了 Access 但还能匿名访问 | Policy 没启用 | Dashboard 双检 |
| Docker 跑的 cloudflared 连不上本机 | 默认 bridge 网络不通 host | 用 --network host |
| 改 config.yml 没生效 | 没 reload | cloudflared tunnel run 自动 / 服务化要 restart |
十一、实用经验
- 测速看下载速度,不只看延迟——延迟 30ms 但下载只有 200KB/s 的 IP 没意义。
-tll 40加上:CF 数据中心之间偶尔会出现 10ms 以下的“假延迟”,但实际拉不动文件,过滤掉。- 优选 IP 别贪多:写 3-5 个就够,客户端会自动选最快的。
- 官方 IP 优于反代 IP:稳定性差太多,重要服务永远首选官方。
- 不同时段测速结果不一样:晚上 8-11 点高峰期测最准。
- CF Workers/Pages 加速不需要优选:它们走 Cloudflare 自己的边缘网络,比走 CDN 入口更快。
- Tunnel 能用 Dashboard 就别命令行,CF 现在主推 Dashboard,文档更新也更勤。
- 配 Access 是基操,没有 Access 等于把内网门户公开。
- 国内访问 Tunnel 要实测速度,出口不稳时有其他方案可用。
把这套理解透,CF 节点能压满线路带宽,家里的任何内网服务也都能用域名 + HTTPS 访问,不用再折腾路由器端口转发。
← 返回文章