Memoh自建隧道及保活方案，实测youtube秒开4K

mlzl1426

声明：此贴具体内容由AI总结生成，但实际是在我本人账号测试搭建完成的，不足之处，欢迎交流。
只讲方法与原理，不含任何真实域名、IP、密钥。
先看效果：


一、服务器上测速，毫无意义
服务器测到 200 Mbps，导入 Clash 只有 52 Mbps、延迟 388ms。
手机 → 运营商 → 国际出口 → CF边缘 → 你的服务器 → 目标
        （这一段你测不到）        （你一直在测这一段）
决定体验的是前半段，而服务器上永远测不到它。我一度以为优化得很好（服务器侧 474 Mbps），用户侧毫无改善。
服务器侧数字只用来判断“服务端是不是瓶颈”，体验必须用自己网络实测。

二、优选 IP：能用，但有致命误区
Cloudflare 是 anycast，而隧道域名在任意边缘 IP 上都能正确响应：
curl --connect-to "tunnel.example.com:443:104.16.x.x:443" https://tunnel.example.com/
返回 404 表示隧道可达（根路径无 handler，属正常）。
所以 server 字段填实测最快的边缘 IP，servername 和 Host 仍填隧道域名。
我犯的错：在服务器上 dig 企业域名、把解析结果硬编码，结果延迟从 170ms 劣化到 387ms。因为 anycast 下，同一个 IP 从东京访问和从中国移动访问，落到的 PoP 完全不是一回事。
只能用你自己运营商实测出来的 IP。某份三网数据很说明问题：
联通  67ms  50.48 MB/s
电信  51ms  61.08 MB/s
移动  98ms   7.12 MB/s（移动最好的也就这样）
同样走 Cloudflare，移动最好只有 7 MB/s。这是链路差异，不是配置问题。

三、延迟是物理问题
客户端到香港边缘      62 ms（自测）
香港边缘到东京服务器  26 ms（服务器实测）
东京服务器到目标站    26 ms（服务器实测）
合计往返约 114 ms
Clash 显示 170ms，约等于 114ms 加上握手开销（约 2 个 RTT）。114ms 是这套架构的物理下限，换 IP、调参数都改不了。
连接复用（smux / mux）实测完全无效：启用时 82、56、56、55、56 ms，不启用时 82、56、56、56、54 ms。隧道长连接本来就活着，省不掉握手。别在参数上浪费时间。

四、UDP 被封的连锁反应
UDP/53 可用，UDP/443 和 UDP/7844 全部 No route to host。
一是 cloudflared 必须强制 HTTP/2，否则会无限重试 QUIC 而失败：
export TUNNEL_TRANSPORT_PROTOCOL=http2
cloudflared tunnel run
二是 Hysteria2、TUIC 这类基于 QUIC 的协议全部不可用。

五、多隧道聚合只对多线程有效
单隧道上限 76 到 110 Mbps，多条能叠加（4 条隧道各 2 路并发约 474 Mbps）。但 Clash 的 load-balance 是按连接轮询，单线程只能吃一条隧道。别指望多开隧道让单线程变快。

六、保活：检查“能不能用”，不是“进程在不在”
踩得最惨、也最值錢的一块。
（事故）静默宕机 10 小时
服务挂了 10 小时，订阅返回 530，全程无告警。原因：把长驻进程当“后台任务”启动，会话结束就被系统回收。
（必须脱离会话）
nohup python3 guardian.py &
上面这种写法会随会话被回收。正确写法：
setsid --fork python3 guardian.py >> log 2>&1 < /dev/null
验证方法：ps -eo pid,ppid,sid,args | grep guardian，PPID 必须是 1。
（flock 会被子进程继承）
原本用 flock -n 防重复启动。进程被 kill 后，它启动的子进程（比如 sleep）继承了文件锁，新实例永远拿不到锁、启动即退出，而且不报任何错。日志显示 started，进程就是不见了。改用 pidfile。
（健康检查必须做实际探测）
不够的做法是只判断进程是否存活。进程活着但隧道断了，它照样认为健康。
够用的做法是做两項实际探测：一是订阅可达性（返回 200 才算通），二是入口抽样实测（抽 6 个入口走隧道握手，可用率低于 60% 算异常）。任一不满足就重建入口并重启服务。
（双进程互保）
启动钩子拉起 boot.sh（幂等），boot.sh 启动 watchdog.sh（每 30 秒检查）和 guardian.py（每 45 秒巡检），两者互相看守：guardian 挂了 watchdog 拉起来，watchdog 挂了 guardian 拉起来。
（故障演练必须做）
同时杀掉守护进程和隧道，观察恢复情况。实测结果：3 秒后两者皆无，80 秒后全部恢复，订阅返回 200。另外还测了入口全挂的场景，把入口换成不可达 IP，一轮巡检内识别出可用率 0% 并自动重建。

七、几个必踩的零碎坑
1、IPv6 在 YAML 里不能加方括号
写成 server: [2606:4700::1] 会被 YAML 当成数组，导致整份订阅 0 个节点。
正确写法是 server: 2606:4700::1
2、fake-ip 模式必须配 proxy-server-nameserver，否则代/里服务器域名可能被劫持成 198.18.x.x 假地址，连接直接失败。
3、把 IP 直接写进配置，绕开客户端 DNS。我之前节点写域名，导致用户侧全部超时。
4、别频繁重建 quick tunnel，Cloudflare 会限流，新隧道全部无法访问，等很久才恢复。
5、有域名一/定要用命名隧道。quick tunnel 重启就换域名，named tunnel 永/久不变。
6、杀进程别用 pkill -f 匹配关键字。命令行本身含该字符串时，会把自己也杀掉，我因此连挂三次。安全做法是按可执行名精确匹配：
for p in $(ps -eo pid,comm --no-headers | awk '$2=="usque"{print $1}'); do kill $p; done
7、8443 端口在国内部分网络会被干扰，优先用 443、2096、2087、2083。

八、WARP 第二出口（可选）
有些流量会被“这是机房 IP”拦掉。可以用 WARP 加一个第二出口，工具选 usque（MASQUE 协议，支持 HTTP/2 over TCP，UDP 被封也能用）：
./usque register --accept-tos
./usque socks -c config.json -p 12345 -b 127.0.0.1 --http2
然后在 Xray 里加一条 socks 出站，按 inbound 分流即可。
实测速度：直连（VPS IP）35 MB/s，WARP（Cloudflare IP）7 MB/s。
慢 5 倍，但出口 IP 变成 Cloudflare 段，被风控拦的概率低很多。定位是备用换 IP，不是主力。
顺便说个结论：想通过换 WARP 端点拿到其他国家出口，没用。我试了三个不同端点，全部落到日本，因为 anycast 永远就近路由。出口国家由机器所在地决定，配置改不了。

五条最值錢的经验

一、服务器侧测速毫无意义，必须用自己网络实测。

二、优选 IP 必须来自你自己的运营商，服务器 dig 出来的完全不可用。

三、延迟是物理问题，算清 RTT 预算，别调参数。

四、长驻进程必须用 setsid --fork 脱离会话，否则会话结束就没了。

五、保活要检查“能不能用”而非“进程在不在”，要双进程互保，并且真的做一次 kill 演练。

本文不含任何可用地址或密钥，仅为技术经验分享。

超级小爱

anycast 那个坑我一直没搞明白，同一个隧道域名在哪个边缘 IP 上都能应答，那我优选出来的 IP 到底优的是哪一段路？