关联主题::
同级:: 2025-09-01_星期一
下一级::
背景介绍
我有一台绿联DX4600的Nas，本地环境下只有公网ipv6，无公网ipv4。
Nas里的Docker部属了一堆容器，比如OpenList，我希望可以发布到Web实现ipv4和ipv6均可访问。
所以今天来分享一下Cloudflare Tunnel+优选域名内网穿透的方案。
1、添加两个公共主机名，需要两个域名。
主：open.brmys.cn
辅：opentest.brmysss.top
接下来，配置自定义主机回退源实现优选ip
2、取消主域名的DNS解析
删掉类型为CNAME，名称为open的这个DNS解析。
让主域名和Tunnel解绑
3、进入辅助域名-SSL/TLS-自定义主机名
添加回退源，就是上面的辅助域名地址：opentest.brmysss.top （等待初始化）
添加自定义主机名填写主域名：open.brmys.cn （下面选项都默认）
展开以后会提示去辅助域名DNS里添加TXT解析记录
4、回到辅助域名的DNS记录 ，添加优选域名
类型：CNAME；
名称：cdn；
目标：优选域名
关于小黄云代理
5、回到主力域名，添加主力域名（第二步被删掉的）
类型：CNAME
名称：open
目标：cdn.brmysss.top
关闭小黄云代理
访问地址： https://open.brmys.cn
- 缺点：这只对cf到用户有效，cf到内网服务还是慢
接下来是我的一些探索和学习🤔
一些延迟测速指令
IPV4测试
ping open.brmys.cn结果:
PING cmcc.877774.xyz (162.159.152.9): 56 data bytes 64 bytes from 162.159.152.9: icmp_seq=0 ttl=51 time=58.227 ms 64 bytes from 162.159.152.9: icmp_seq=1 ttl=51 time=55.918 ms 64 bytes from 162.159.152.9: icmp_seq=2 ttl=51 time=54.626 ms 64 bytes from 162.159.152.9: icmp_seq=3 ttl=51 time=53.766 ms 64 bytes from 162.159.152.9: icmp_seq=4 ttl=51 time=54.638 ms 64 bytes from 162.159.152.9: icmp_seq=5 ttl=51 time=59.452 ms 64 bytes from 162.159.152.9: icmp_seq=6 ttl=51 time=54.270 ms 64 bytes from 162.159.152.9: icmp_seq=7 ttl=51 time=55.752 msIPV6测试
ping6 open.brmys.cn结果：
getaddrinfo -- nodename nor servname provided, or not known
ping open.brmys.cn→ 正常有延迟结果（IPv4 已经解析成功，有 A 记录）ping6 open.brmys.cn→ 报错：nodename nor servname provided, or not known
👉 说明域名 没有配置 AAAA 记录，也就是没有 IPv6 地址，所以 ping6 找不到目标。目前你的
open.brmys.cn已经 绑定了一个 CNAME（Cloudflare Tunnel 指向的 cfargotunnel.com 域名）。
所以 不能再加 AAAA 记录，因为：DNS 标准规定：一个主机名要么是 CNAME，要么是 A/AAAA/MX/TXT 等记录，不能混用。
简单说就是，所有用户访问open.brmys.cn走的都是IPV4。
而辅助域名opentest.brmysss.top走的是cf代理。命令 1：查 IPv4 (A) 记录
dig open.brmys.cn A +short命令 2：查 IPv6 (AAAA) 记录
dig open.brmys.cn AAAA +short
为什么cf Tunnel的方法没有ipv6+DDNS的方式快？
🔍 原因分析
1、数据路径不同
IPv6 + DDNS（直连）
用户 → ISP → 你的公网 IPv6 地址 → NAS
👉 路径最短，只要运营商网络质量好，延迟和带宽几乎就是你家宽带的极限。Cloudflare Tunnel + 优选
用户 → 最近的 Cloudflare 节点（IPv4 优选好了） → Cloudflare 内部专线 → 你的 NAS（通过隧道容器）
👉 虽然入口节点快，但数据还要「多绕一跳」走 Cloudflare 网络，再回到你家里。所以，即使优选了入口 IP，Tunnel 也始终比不上原生直连。
2、 隧道协议的额外开销
Cloudflare Tunnel 实际是一个 长连接隧道：
- 你的 NAS ↔ Cloudflare Tunnel Server 之间跑着加密传输。
- 每个请求都需要封装/解封装，多一层开销。
- 这在高并发/大流量场景下会明显影响性能。
而 原生 IPv6 + DDNS 没有这层开销，就是最干净的 TCP/UDP 直连。
3、优选只解决了入口，不解决 Cloudflare 内部路由
- 你用的优选域名，实际上只是找了 用户 → Cloudflare 的入口节点最快的 IP。
- 但是从「Cloudflare 节点 → 你家 Tunnel」这一段，还是走 Cloudflare 的私有骨干网。
- 如果这段链路（比如 Cloudflare 中国 → 日本 → 你家宽带）不理想，延迟依然高。
所以你会发现：
👉 优选只能优化前半段，不等于全链路最优。
4、Cloudflare 的 QoS / 限速策略
- 免费的 Cloudflare Tunnel 并不是专线，Cloudflare 可能会对隧道流量有一定的调度或限速。
- 而 IPv6 原生直连就完全不受这个影响。
✅ 总结
- IPv6 + DDNS：直连，延迟低，带宽高 → 性能最好，但安全性要自己处理（端口暴露、DDoS 风险）。
- Cloudflare Tunnel + 优选：更安全（隐藏真实 IP，带防护），能绕过 IPv4 NAT，但延迟/带宽一定打折扣。
一句话：Tunnel 永远跑不过原生直连，它的卖点是「安全 + 稳定 + 穿透」，而不是极致性能。
虽然当前的教程里使用了优选域名，但是cf tunnel到nas的链接速度还是无法控制的。
所有我在想有没有更好的方案：IPv6 + DDNS似乎是更优的方案，但是唯一缺点是不支持ipv4访问，可否将ipv6转为ipv4呢？有ipv6优先用ipv6，没有ipv6则使用ipv4。