⚠️ 脱敏声明：本文是折腾过程的记录与复盘。所有服务器地址、域名、密码、密钥、token 一律以占位符代替，请勿在公开笔记里保存真实凭据——这是本文最重要的教训之一。

为什么自建

商业机场的问题：节点质量不可控、流量共享、跑路风险。于是从 2026 年 6 月开始，我用三个多月时间搭了一套自己的网络：

• 两个自建出口节点：一台美国 CN2 线路的 VPS（日常主力），一台日本大阪 IIJ 线路的 VPS（兜底）
• 一个自建订阅服务器：跑在美国 VPS 上，一个 URL 管所有客户端
• 客户端矩阵：家里主路由 + 多台店里旁路由（iStoreOS + OpenClash）、两台 Mac（Clash Verge Rev + TUN）、iPhone（Shadowrocket）、一台带电池和蜂窝网络的便携路由（出门即热点）

最终效果：五台路由器全部验证通过，故障切换自动兜底，换 VPS 的 IP 时所有客户端零改动。

架构一句话

美国 VPS ──┐
           ├── 订阅服务器(同一台美国VPS) ── 各客户端拉订阅
日本 VPS ──┘

两个关键设计决定：

1. 节点寻址一律用域名 + DDNS，不写裸 IP。DuckDNS 免费，VPS 上 cron 每 5 分钟同步一次。后来美国 VPS 机房迁移、日本节点换了三台机器，客户端配置一行都没改过。
2. 分组用 fallback（故障切换），美国优先、日本兜底。不用"自动选最快"——日本实测比美国快 3 倍，但我坚持美国优先，理由只有一个：出口 IP 要稳定不飘。登录态、风控都吃频繁换 IP 的亏。

折腾时间线

阶段一：单机起家（6 月上旬）

第一台美国 VPS 上用 3x-ui 管理 VLESS + Reality，监听 TCP 443；后来又装了 Hysteria2，监听 UDP 443。TCP 和 UDP 的 443 是两条独立通道，可以共存——这台机器从此一个端口都不浪费。

很快吃到第一次教训：IP 被墙了。在商家面板里换机房迁移，数据无损、拿到新 IP——这时候才体会到"节点写域名不写 IP"有多值钱：改一条 DDNS 记录，全部设备几分钟内自动跟上。

阶段二：QUIC 与 YouTube 的战争（6 月中旬）

症状很诡异：YouTube 网页视频能放但页面 UI 刷不出来；安卓/iOS 原生 app 直接连不上；手机单独挂代理又一切正常。修好安卓坏 iOS，按下葫芦浮起瓢。

根因是 QUIC（UDP 443，HTTP/3 的底座）与节点传输方式的匹配问题：

“打地鼠现象"就是你在 TCP 节点上反复调 QUIC 开关——那条路上无解，根治只能换 UDP 原生节点。

另一个结论：iOS 是老大难。透明代理下无论怎么调，iOS YouTube app 都时好时坏（它对静默 DROP 不回退）。正解简单粗暴：iOS 别走透明代理，直接 Shadowrocket 连 Hy2 节点。安卓的 Cronet 回退果断，反而没事。

阶段三：DNS 污染，从 Passwall 迁到 OpenClash（6 月中旬）

iStoreOS 升级 24.10 后 Passwall 连环报错，正好顺势搬家。压死骆驼的最后一根稻草其实是 DNS 污染：Passwall 默认的 chinadns-ng 明文 DNS 模式下，www.google.com 这类重污染域名直接被 GFW 投毒解析成假 IP，怎么调代理都没用。

mihomo 系（OpenClash / Clash Verge）的 fake-ip 机制天生免疫：本地只发假 IP，真实解析发生在节点端。迁移后国内外分流正常，google 秒开。

顺带踩坑：OpenClash 核心"一直在更新”，是核心自动更新在墙内反复下载失败，关掉 auto_update 即安。

阶段四：日本节点的血泪史（7 月初）

想加个日本节点做兜底，结果一台机器贡献了三个经典案例：

1. MTU 黑洞。某些"优化线路"本身是隧道，MTU 被压小，1500 字节的大包（恰好是 TLS 握手用的那种）在路上被静默丢弃、反复重传——表现为直连 TLS 握手要 9.6 秒。修复：把 VPS 网卡 MTU 压到 1280 并做成开机服务，握手立刻降到 0.28 秒。诊断口诀：“ping 得通但 TLS 握手巨慢 ≈ 先查 MTU”。
2. TCP 中间盒破坏 Reality。这条线路上有个 TCP 加速盒会重切分段，xray 日志狂刷 processed invalid connection——Reality 的字节级认证扛不住。同样的配置换个机房就好。而 shadow-tls v3 因为做的是真 TLS 握手，反而活下来了。
3. DDNS 抢域名战争（最阴的一个）。换机后服务"时好时坏"查了半天：旧 VPS 的 crontab 里还留着 DDNS 更新脚本，每 5 分钟把域名抢回去指向它自己！客户端一半时间连到旧机器（上面跑的还是旧协议），一半时间连新机器。教训刻进骨头里：复用 DDNS 域名换节点前，先 crontab -l | grep duck 清掉旧机器的定时任务。

8 月终于翻盘：换到一条干净线路的新机器，ping 41ms / 0% 丢包，Hysteria2 直接起飞，下载实测 140Mbps，比美国主力快 3 倍。MTU 都不用压——好线路和烂线路的差距就是这么赤裸裸。

阶段五：自建订阅服务器（6–7 月）

不想手动给每台设备发配置，就在美国 VPS 上用 python3 起了个 HTTPS 小服务，按随机 token 路径提供两份订阅：Clash YAML（给 mihomo 全家）+ base64 分享链接（Shadowrocket 对 YAML 订阅支持差，必须单独喂）。

两个值得记的坑：

1. 服务卡死 bug：最初把 TLS 握手直接包在 accept 主循环里同步做，任何一个境内客户端握手卡住就堵死所有人。改成每个连接在自己的线程里做握手 + 30 秒超时，世界清净了。
2. 非标准端口会被掐：订阅端口不是 443，从家宽/店宽直连时 TCP 都建不起来。所以别指望各路由自动更新订阅，最可靠的方式是 scp 直接推配置文件再重启服务。根治方案（挪到标准 443）还在待办上。

彩蛋功能：给订阅响应注入 Subscription-Userinfo 头，Clash Verge 卡片上就有流量用量进度条，数据来自商家只读 API，缓存 5 分钟。

阶段六：远程管理与自愈（7 月）

路由器散落在不同的内网，现场维护不现实。用 FRP 打通：一台境内云主机当中转，每台路由跑 frpc 反向连接，SSH 随时可达。铁律：境内实名中转机只做管理隧道，绝不跑代理流量——合规红线。

再加一层保险：每台路由装 watchdog，每 5 分钟经节点探测 generate_204，连续两次不通就自动重启代理服务刷新 DNS 解析，15 分钟冷却防抖。VPS 再换 IP，路由器也能自己爬起来。

沉淀下来的设计原则

1. 一切寻址用域名，IP 只是临时状态
2. VPS 无状态化：一份重建脚本，新机器 root 下跑一遍 = 2 分钟还原全套服务（含证书续期、开机自启）
3. 单一真源：订阅服务器是唯一配置源头，本地只留副本
4. fallback 保稳定，不为速度牺牲出口一致性
5. TCP 节点屏蔽 QUIC，UDP 节点放开 QUIC，先看协议再动手
6. 换机先清旧机器的 cron（DDNS 血泪）
7. 远程运维走独立通道，与业务流量物理隔离

安全清单（公开笔记前自查）

这次整理博客顺便做了遍审计：

• 所有密码/密钥/token 是否已从文档移除？（包括"看起来无害"的面板地址）
• 曾在 AI 对话中出现过的凭据，当作已泄露处理，全部轮换
• 管理面板端口用防火墙 DROP 公网访问，仅留 SSH 隧道入口
• SSH 改密钥登录、禁密码（待办清单上的常客，别学我拖了两个月）
• 家宽/店铺拓扑、内部网段不在公开内容里出现

后记

整个过程我是和 AI 结对完成的：让它读交接文档、远程上机器排查、把每次排障结论固化成可复制的 SOP。回头看，最值钱的不是哪条命令，而是"域名寻址、无状态重建、单一真源"这几个原则——它们让后面每一次故障都从"事故"降级成了"练习"。

本文由 ox-alpha（模型 ID：openrouter/stealth/ox-alpha，undisclosed organization 出品）基于作者的项目交接文档协助整理撰写；文中所有敏感信息均已脱敏。