Wiredoor：自托管的内网穿透 Ingress 平台
阅读时间: 大约 11 分钟
Wiredoor：自托管的内网穿透 Ingress 平台
如果你用过 ngrok、frp 或花生壳，就会熟悉「把家里 / 公司内网的服务临时暴露到公网」这个需求。Wiredoor 走的是另一条路：它不是一个你 ngrok http 3000 就完事的命令行小工具，而是一套自托管的 Ingress-as-a-Service 平台——你自己部署一台公网 Server，私有网络里的节点主动拨出一条 WireGuard 隧道连回来，由 Server 统一做域名路由、TLS 终止和访问控制。截至本文撰写，其最新版本为 v1.8.0（官方 release 页共 22 个发布），主仓库以 TypeScript（约 65%）+ Vue（约 29%）写成，采用 Apache-2.0 协议（1.5.1 及以后版本；此前为 MIT）。本文基于官方 GitHub 仓库与 wiredoor.net 文档，分析它的机制、适用场景与官方自己承认的边界。
一、背景：为什么需要「自己的」内网穿透
公共隧道服务（ngrok 等）上手极快，但有几个绕不开的问题：公网入口在别人手里，域名、带宽、TLS 证书、访问日志都受限于对方的套餐与政策；免费版有连接数、带宽和随机域名限制；对企业或自托管爱好者来说，把生产服务的入口放在第三方 SLA 下也并不安心。
反过来，自己搭 frp 这类方案虽然可控，但要自己维护隧道进程、证书续签、域名路由和访问策略，组件零散。Wiredoor 的定位就是把这些收敛成一个「装好 Server、在私有侧装个 CLI、网页点点配置」的一体化平台——你保留公网入口、隧道、路由配置和运营数据的完全控制权。
二、是什么：Server + 节点的两层模型
Wiredoor 由两部分组成：
- Wiredoor Server：跑在一台有公网可达地址的 Linux 服务器上，是公网入口与控制面。它提供 Web 控制台与 API，管理节点、域名、证书和暴露的服务，接收来自节点的 WireGuard 连接，并自动生成 NGINX 配置来路由公网 HTTP/TCP/UDP 流量。
- 节点（Node）：跑在私有网络一侧，主动向 Server 发起出站 WireGuard 连接。节点又分三种：
| 节点类型 | 与 Server 的连接 | 能触达的服务 |
|---|---|---|
| Local Node | 无远程隧道 | 与 Server 本机直接可达的服务 |
| Client Node | 出站 WireGuard 隧道 | 与 CLI 同一台机器上的服务 |
| Gateway Node | 出站 WireGuard 隧道 | 一个已授权私网 / 子网内的多个服务 |
关键点在于连接方向：私有网络不需要为 Wiredoor 开放任何入站端口，隧道是私有侧节点「主动打出去」的。这意味着在 NAT、公司防火墙或严格出网策略后面，只要能访问公网，就能把服务接进来，而不必在路由器上做端口映射。
三、技术机制：WireGuard 隧道 + NGINX 路由
官方在 README 里用一张 mermaid 流程图描述了核心拓扑（上图即据官方源码重绘）：用户 → Wiredoor Server ⇄（WireGuard 隧道）⇄ Client/Gateway Node → 私有服务。
对一个 HTTP 服务，一次请求的完整流程如下（据官方文档整理）：
几个工程细节值得注意：
- 隧道用 WireGuard：内核级、加密、性能较好，且由私有侧主动发起，规避了入站端口问题。
- 路由用 NGINX：Server 侧按域名、路径选择路由，支持 WebSocket；TCP/UDP 服务则监听指定公网端口后转发流。
- 证书自动化：公网域名在 DNS 指向 Server 后可自动申请 Let’s Encrypt 证书；本地 / 内部域名用自签名证书，客户端需手动信任。官方明确说不强制要求公网 DNS——你可以用内部 DNS 或 hosts 文件。
- 访问控制：内置 OAuth2 认证和基于 IP 的访问限制。
部署要求方面，Server 需要一台可达的 Linux 服务器（装 Docker Engine + Compose + Git），开放 TCP 80/443 和 UDP 51820（WireGuard，可改）。典型三步：docker compose up -d 起 Server；在私有侧 wiredoor login --url https://你的域名 注册节点；再 wiredoor http first-app --domain app.example.com --port 3000 把本机 3000 端口的服务暴露出去。
四、关键数据与能力清单
官方并未发布吞吐量、时延这类 benchmark 数字（这是这类自托管工具的常见情况），可核对的是能力与部署约束：
| 维度 | 官方口径 |
|---|---|
| 传输协议 | HTTP、TCP、UDP 暴露 |
| 节点系统 | Client Node 支持 Linux / Windows / macOS |
| Gateway 形态 | Linux 原生、Docker Gateway、Kubernetes（官方 Helm Chart） |
| 端口（Server 侧） | TCP 80/443，UDP 51820（WireGuard） |
| 证书 | 公网域名自动 Let’s Encrypt；本地域名自签名 |
| 访问控制 | OAuth2 + IP 白名单 |
| 监控 | 可选 Prometheus + Grafana |
| 协议 | Apache-2.0（≥1.5.1） |
五、官方自己强调的局限与口径偏差
这一节是本文不做软文的关键。官方在文档里白纸黑字写了几条需要使用者自己负责的边界：
- Gateway 路由依赖 Linux iptables：Gateway Node 的转发与 NAT 基于 Linux iptables 规则。因此 Windows / macOS 上的原生 CLI 只能跑 Client Node 模式；想在 Win/macOS 上跑本地 Gateway，只能通过 Docker Desktop 里的 Docker Gateway 间接实现。这意味着「跨平台 Gateway 」其实并不跨平台。
- Server 不替你配置防火墙：文档明确「Wiredoor does not configure the host or cloud firewall for you」——80/443/51820 要不要开、开给谁，全靠你自己在主机和云安全组上配。
- 它降低暴露面，但不替代安全控制：官方专门有「Security Responsibilities」一节，要求你用 OAuth2 或严格 IP 白名单保护管理面、妥善保管管理员凭据与节点 token、只暴露必要端口与子网、保持组件更新、升级前备份。换句话说，「隧道加密」不等于「服务可以裸奔」。
- 无公开性能基准：官方没有给出隧道吞吐、并发或端到端时延数据，所谓「性能好」只能理解为 WireGuard 本身的工程特性，而非 Wiredoor 平台实测结论。
六、适用 / 不适用场景
适合：
- 家庭实验室（Home Lab）和私有 LAN，想把树莓派、NAS 上的服务通过固定 HTTPS 域名对外；
- 本地开发团队，需要把 Docker Compose / 私有 K8s 里的服务临时给外部演示或 Webhook 回调；
- 对数据主权敏感、不愿把入口交给 ngrok 这类托管服务的自托管爱好者与小企业；
- 工业 / IoT 场景里节点在受限网络内、只能出网不能入站的环境。
不太适合：
- 只想临时给同事发一个临时公网链接、用完即走——ngrok / cloudflared 仍更省事；
- 需要在 Windows / macOS 上直接把整个子网的一堆服务批量暴露（Gateway 仍需 Linux 或 Docker）；
- 需要托管方兜底 SLA、带宽和全球加速的生产级公网服务——那更该用正经的反向代理 / CDN 方案。
七、它意味着什么
Wiredoor 的价值不在「又一个 frp」，而在于把内网穿透这件运维味很重的事，封装成了带 Web 控制台、节点管理、自动证书和访问控制的自托管 Ingress 产品。它用「私有侧主动出站」解决了 NAT 穿透，用 WireGuard 解决了加密，用 NGINX 解决了路由，再用 OAuth2/IP 白名单补上了入口的访问控制。对已经有一台小 VPS、又厌倦了公共隧道的限速和随机域名的人来说，这是一个值得上手的开源替代。但请务必记住官方的提醒：它给你的是「自己掌控的入口」，不是「替你负责的安全」——防火墙、凭据保管和最小暴露面，仍然是部署者自己的功课。