wangwanjie/gately

如果你有 NAS 或家用服务器，想用域名加 HTTPS 暴露服务，又不想自己拼 haproxy、nginx、DDNS 脚本和证书续期任务，Gately 用一个二进制把这些事装在一起。它最适合已经在维护好几个网络小工具的人；但它也是个年轻项目，没有长期运行记录。

解决什么问题

以前：想让 nas.example.com 指向家里的服务，要先让动态 DNS 跟着路由器地址更新，再在 NAT 上打洞或开端口，然后找地方终止 TLS，还得记得续期泛域名证书。每一步往往是不同工具、不同配置格式，反向代理还要知道哪个域名对应哪个后端。现在：Gately 站在网络出口，发现公网地址，通过 ACME 申请证书，再按 SNI 把进来的 TLS 连接分给对应的内网目标，多个服务可以共用 443 端口。最终换来一个管理后台和一个配置目录，而不是一堆各自为政的组件。

有什么不同

真正区别开它的是端口转发模块里的 SNI 路由：按域名透传 TLS，可设默认目标，每条路由可单独启用 PROXY protocol。正因如此，一个入口端口能服务多个后端，而这通常正是 haproxy 加 nginx 这套组合干的活。README 的性能表在作者自己的机器上比较了两者（90 个 SNI 域名、PROXY protocol v2、ECDSA P-256、TLS 1.3），报告 Gately 吞吐更高、p99 更低，另外给出了 Gately 的 HTTP/2 数据，而 nginx 那套没有测。这些数字是作者的基准测试，不是独立结论。

功能多本身也是取舍。DDNS 各服务商、STUN 与 UPnP/NAT-PMP 穿透、DNS-01 或 HTTP-01 申请证书、Tailscale、frp 客户端与服务端、WAF、网页终端，全在同一个进程里。集中起来减少了活动部件，但也意味着一个工具同时握着你的 DNS 密钥和证书私钥，任何一个模块出问题，都发生在网络边缘这个关键位置。项目主张以 Apache-2.0 开源和可编辑的出站地址列表来保证可审计；但审计本身仍是你需要投入的工作。

谁值得试

适合已经在同一台机器上跑几个服务、想按域名做 HTTPS 路由、又不想分别维护 haproxy 和 nginx 的自建用户。fnOS 这条路尤其省事：Gately 作为原生应用出现，fnOS 管理员可以直接用 fnOS 会话登录，不需要单独的 Gately 密码。OpenWrt 安装包也让装在路由器上变得可行。

不适合需要经过多年打磨、部署广泛的成熟边缘代理的人，也不适合只想要 DDNS 这一个小功能的人。如果只有一个服务、IP 又固定，整套栈带来的复杂度省不了多少。同样，如果你不能接受由一个年轻项目掌管证书和 DNS 凭据，就别把它放在出口位置。

使用条件与边界

Docker 方式需要 host 网络、NET_ADMIN 和挂载 Docker socket，容器因此对宿主机有较大权限。二进制方式需要一个配置目录，管理后台的默认账号是 admin、密码是 gately.cn，必须改掉，设置里可开启两步验证。API token 只在创建时显示一次，可按模块授予权限，这点在写脚本调用管理 API 时很重要；账号、备份、恢复、重启等接口只接受登录会话。

安装之后的日常维护比安装本身更要紧：证书续期、DNS 服务商凭据、以及通过 SSH 推送证书的目标都要一直可用；fnOS 的 .fpk 包需要在 App Center 里手动安装，不在官方商店。现有材料里没有独立的代码安全审查，也没有生产环境的长期使用记录。

HotRepo 点评

HotRepo 从 2026-10-24 开始跟踪这个项目，当时它只有 9 天。2026-10-25 它出现在新项目榜（不是总榜）第 5 名，总星数 362。这只是单次带日期的快照，没有可比的每日榜单历史，因此无法判断热度能否持续。它的功能面够宽，若你正好想替换 haproxy 加 nginx，值得一看；但在把它放到网络出口之前，先针对自己的后端验证 SNI 路由和证书续期的实际表现。