Sucaddy

背景 sucaddy 从 v1.0 迭代到现在 v12.4，从一个实验性的代理隧道项目，变成了我日常依赖的网络基础设施。跨境流量、内网穿透、博客服务——全部跑在这 5 台节点上。 基础设施多了，运维就得跟上。之前靠手敲命令查状态，既慢又不靠谱。于是有了这套健康巡检系统。 架构 5 个节点，3 种角色： 🇰🇷 Korea — Hub 入站 + NaiveProxy 🇭🇰 HK — Landing+Hub 双栈出口 🇺🇸 Blog — Hub+Blog 站点服务 + NaiveProxy 🇨🇳 成都 — Relay 隧道 + 反向服务器 🐧 Armbian — Proxy 内网代理 + 反向客户端 所有节点运行同一套 sucaddy 二进制（amd64 全一致），配置通过 sync-config 自动同步，部署走 deploy.sh 一键推送 + MD5 校验。 巡检维度 健康检查脚本覆盖 6 个维度： 1. 存活检查 systemctl is-active + ss -tlnp + TCP 握手三重验证。5 节点 × 全部端口，缺一个就标红。 ...

为什么动了 Relay？ sucaddy 的 Relay 模块最初的设计思路很朴素：把边缘节点的流量通过中继节点转发，实现跨网段互通。代码里手写了一套 AES-256-GCM 加密，用 FIFO 队列管理连接，单连接模式跑通信。 用着用着问题就出来了： FIFO 死连接：旧连接不释放，把队列占满，新连接挤不进去 没有多路复用：一个连接只能传一个流，并发能力为零 断线重连有间隙：1 秒空窗期间请求直接丢，实测成功率只有 67% 每次排查这些问题都让我怀疑人生——这些功能 SSH 原生不就自带吗？为什么我要自己写一遍，还写得这么烂？ 方案对比：自建 vs 成熟方案 维度 自建 Relay SSH 反向隧道 加密 手写 60 行 AES-256-GCM SSH 内置 AES-256-GCM 多路复用 ❌ ✅ SSH channels 成功率 67% 100% 延迟 3.5-4.8s 2.3-2.6s 代码量 ~350 行 0 行 保活 自己写心跳 autossh + systemd 结论很明显：删掉它。 具体怎么干的 SSH 反向隧道拓扑 边缘节点 → 中心节点 :端口A → 边缘节点本地服务（直连回内网） 边缘节点 → 中心节点 :端口B → 边缘节点出墙链路 中心节点上用 systemd + autossh 保活，断线自动重连 边缘节点用 cron keepalive 防止 NAT 超时 一条命令搞定：ssh -R [端口]:[目标地址]:[目标端口] user@host NaiveProxy 新增 tcp:ADDR 路由 在 NaiveProxy 里加了一个新的路由类型：route: tcp:ADDR。用户认证成功后，直接转发到本地指定端口（比如 SSH 隧道的入口）。大约 25 行代码，替代了整个 relay 入口模块。 ...