别只装客户端：NetBird 自托管必须有的 Linux、域名和端口配置
自托管 NetBird 需具备公网域名、Linux 虚拟机环境及容器维护能力，责任边界远超客户端安装。
很多人误以为把 NetBird 客户端装好，自托管就算大功告成。其实那只是拿到了钥匙，房子还得你自己盖。真正的责任边界从你点击“下载”那一刻起，就延伸到了公网域名管理、Linux 虚拟机环境搭建以及容器运行维护。
要跑通这套系统，你得先准备好硬性条件：拥有一个可解析的公网域名，一台 Linux 虚拟机，并开放 TCP 80、443 端口以及 UDP 3478 端口。同时，你的服务器必须能运行 Docker 和 Compose v2+ 环境。这不仅仅是安装一个软件包，而是构建一套完整的基础设施。如果你只对比客户端的功能列表，而忽略了控制面及其依赖设施，这种比较本身就是无效的。
别被发布记录里的 management、signal、relay 等组件名称迷惑了。它们只暗示系统是多组件形态，不能替代你对部署拓扑、源码实现和运行时行为的实际核验。README 里提到的最低 1 CPU 和 2 GB 内存只是快速部署的门槛，不代表生产环境的高可用架构或总拥有成本。
自查清单：
- [ ] 是否已配置可解析的公网域名？
- [ ] 是否准备了 Linux 虚拟机环境？
- [ ] 服务器是否开放了 TCP 80⁄443 和 UDP 3478 端口？
- [ ] 是否确认安装了 Docker 与 Compose v2+？
- [ ] 是否将控制面依赖纳入运维计划，而非仅关注客户端？
硬件与基础环境：自托管需要哪些服务器配置？
运行 NetBird 管理平面需满足特定硬件指标与基础 Linux 环境，这是实现一键部署前的硬性门槛。
别被“一键安装”的假象骗了。真正的门槛，首先落在你手里那台服务器的硬指标上。想跑通 NetBird 管理平面，你得先凑齐这套最低配置清单：
- 操作系统：必须是 Linux 虚拟机。
- 计算资源：至少 1 个 CPU 核心 + 2 GB 内存。
- 运行环境：预装 Docker 引擎及 Compose v2+ 版本。
- 网络身份：拥有一个可解析的公网域名。
少一项，部署脚本都会直接报错。这些条件构成了快速部署的基准线，缺一不可。
为什么必须是 Linux 虚拟机且需公网域名？
容器化服务对操作系统的依赖是刚性的。Docker 和 Compose 在 Linux 内核层运行效率最高，而 Windows 或 macOS 桌面端通常作为客户端使用，无法承载服务端的管理逻辑。把 NetBird 跑在 Windows 虚拟机里不仅体验割裂，更违背了官方文档的设计初衷。你必须准备一台纯净的 Linux 虚拟机，把它当作控制面的基座。
公网域名的作用则更为关键。它不是锦上添花，而是连接建立的“钥匙”。WireGuard 自托管环境下的 Signal 服务和 Management 组件需要通过这个域名进行 DNS 解析，才能建立安全的加密通道。如果你只有内网 IP 或没有固定域名，设备之间就无法握手，整个组网计划就会卡死。
| 配置项 | 快速部署基准 | 生产环境潜在需求 |
|---|---|---|
| CPU | 1 核心 | 多核以应对高并发连接 |
| 内存 | 2 GB | 随节点数量线性增长 |
| 系统 | Linux 虚拟机 | 需考虑内核稳定性与隔离 |
| 域名 | 单公网域名 | 需配合负载均衡或泛解析 |
| 数据 | 无明确备份要求 | 必须包含数据库快照策略 |
表格中的数据表明，官方列出的 1 CPU 和 2 GB 内存只是起步价。这仅仅是为了让你跑起来，并不代表你能扛住业务流量。若用于生产环境，你还需要额外考量高可用架构、备份策略、容量模型及升级窗口等因素。最低配置不代表高可用性，这只是你从“能跑”到“好用”的第一道关卡。
检查清单：照着做就行
在敲下 docker compose up 之前，请逐项核对：
- [ ] 已拥有 Linux 虚拟机（Ubuntu/CentOS/Debian 等）
- [ ] 确认分配了至少 1 核 CPU 和 2 GB 内存
- [ ] 安装了 Docker Engine 并验证版本
- [ ] 安装了 Docker Compose v2+ 插件
- [ ] 准备了可全局解析的公网域名
- [ ] 确认该域名指向当前虚拟机的公网 IP
以上五项全部打勾，你的服务器才算具备了 NetBird 自托管配置的入场资格。
新手最容易在这里栽跟头：很多人习惯用云厂商默认的“安全组”规则，却忘了在虚拟机内部再检查一遍防火墙。 比如你在阿里云或 AWS 的安全组里放行了 80 和 443 端口，但 Ubuntu 默认启用了 ufw (Uncomplicated Firewall) 且处于激活状态，或者 CentOS 的 firewalld 正在拦截入站流量。这时候，外部测试工具显示端口通畅，但 NetBird 的容器进程一启动就会因为收不到信号而不断重试甚至崩溃。正确的做法是，在确认云厂商安全组放行后，务必在虚拟机内部执行 sudo ufw status 或 sudo firewall-cmd --list-all，确保系统级防火墙也处于允许状态，或者直接临时关闭系统防火墙进行测试，排除干扰后再按需精细化配置。
网络连通性硬性指标：TCP 与 UDP 端口开放指南
必须开放 TCP 80⁄443 及 UDP 3478 端口，否则防火墙将阻断连接导致自托管网络无法连通。
服务器装好了，防火墙却把路堵死？这是自托管失败最常见的原因。NetBird 官方文档明确列出了三条必须打通的“生命线”，缺一不可。你只需在云服务商的安全组或系统防火墙中放行以下端口，即可满足快速部署的最低门槛。
1. 信令通道：TCP 80 与 TCP 443
这两个端口负责管理平面与控制平面的通信。TCP 80 通常用于初始握手、证书验证及 Let’s Encrypt 自动续期；TCP 443 则承载加密的信令交互，确保节点间能安全地交换拓扑信息和密钥。如果这两个端口被拦截，客户端将无法注册到服务器，整个网格也就无法建立。
2. 数据隧道：UDP 3478
这是穿透 NAT 和防火墙的关键。NetBird 依赖 STUN/TURN 协议来寻找最优路径，而 UDP 3478 正是该协议的标准端口。它负责转发实际的加密流量，一旦关闭，即便控制面连接成功，设备间也无法进行实际的数据传输。
配置核对清单
检查你的防火墙规则时，请对照以下标准，确保每条都放行：
- TCP 80：允许入站，源 IP 设为任意（0.0.0.0/0）
- TCP 443：允许入站，源 IP 设为任意（0.0.0.0/0）
- UDP 3478：允许入站，源 IP 设为任意（0.0.0.0/0）
- 协议类型：确认未错误地将 UDP 3478 限制为 TCP 协议
常见误区与修正
很多用户习惯只开 HTTPS（443），或者误以为内网穿透不需要 UDP。实际上，若缺少 UDP 3478，你在公网环境下几乎无法连通远程节点。下表总结了不同端口组合的后果，帮你快速定位问题：
| 开放端口组合 | 连接状态 | 现象描述 |
|---|---|---|
| TCP 80 + 443 (无 UDP) | 部分连接 | 节点显示在线，但无法 ping 通或传输数据 |
| 仅 TCP 443 (缺 80 & 3478) | 完全失败 | 客户端报错，无法完成初始化注册 |
| 全端口开放 (80+443+3478) | 正常 | 节点上线，数据流通过顺畅 |
| 仅 UDP 3478 (缺 TCP) | 完全失败 | 控制面失联，无法获取配置信息 |
配置完成后，不要急着安装客户端。先用 telnet 或 curl 测试端口连通性，再运行 NetBird 的启动命令。只有这三条通道全部畅通，你的自托管环境才算真正就绪。
从快速部署到生产环境：你需要知道的额外成本
生产环境配置远高于官方速成标准，真实流量承载需额外投入计算资源以应对运维成本。
别把 README 里那行”1 CPU、2 GB 内存”当成生产环境的入场券。那是为了让你十分钟跑通流程的“速成班”标准，不是让你扛住真实流量的“实战配置”。
第一步：认清最低门槛与高可用的鸿沟 最低配置只能保证软件启动，无法支撑业务连续性。你需要的不仅仅是服务器能开机，而是它能在断电、磁盘损坏或流量突增时依然存活。
- 高可用架构：单点故障是常态，生产环境通常需要多节点集群。
- 备份策略：配置数据、密钥和状态文件是否有异地容灾方案？
- 容量模型：随着接入设备增加，CPU 和内存会线性甚至指数级增长。
- 升级窗口：如何在不停服的情况下替换组件并验证新代码？ 这些要素在快速部署指南里通常只字不提，却构成了总拥有成本（TCO）的大头。
第二步：核验源码与运行时行为
不要只看发布记录里挂着 management、signal、relay 这些名字就觉得系统很稳。服务名称的存在不代表逻辑正确，更不代表能抗住压力。
你必须亲自做两件事：
- 源码审查：确认核心控制面逻辑是否符合你的安全预期。
- 行为测试：在模拟高负载下观察进程是否崩溃、内存是否泄漏。 仅凭表面功能列表无法替代对底层实现的独立核验。
第三步：算清隐性维护账 自托管的代价往往藏在运维细节里。控制面及其依赖设施的维护成本常被低估，包括域名续费、虚拟机监控、日志审计以及应对漏洞修复的人力投入。
生产环境自检清单
- [ ] 已规划双节点或多节点冗余方案，而非单机运行
- [ ] 制定了定期备份机制，覆盖配置与状态数据
- [ ] 评估过未来一年用户增长带来的资源扩容预算
- [ ] 阅读过核心组件源码，确认无已知重大隐患
- [ ] 计算了包含人力时间在内的年度总拥有成本（TCO）
FAQ: 关于 WireGuard 自托管环境常见问题
Q: 我可以用 Windows Server 代替 Linux 虚拟机吗？ A: 虽然技术上可能通过 WSL2 或 Docker Desktop 勉强运行，但官方文档明确推荐 Linux 环境。Windows 下的网络栈差异可能导致 UDP 3478 端口穿透不稳定，且缺乏原生内核优化，不建议用于生产级的 WireGuard 自托管环境。
Q: 2GB 内存真的够用吗？会不会经常 OOM（内存溢出）？ A: 对于小规模测试或家庭实验室，2GB 足够。但在接入超过 50-100 个活跃节点后，随着路由表膨胀和加密会话增加，内存占用会显著上升。生产环境建议预留 4GB 以上，并开启 Swap 分区作为缓冲。
Q: 如果我的云服务器没有公网 IP，还能自托管吗？ A: 不行。NetBird 的控制面（Signal 和 Management）必须通过公网域名和端口（80/443）进行初始握手。如果没有公网 IP，你需要借助 Cloudflare Tunnel 或类似的内网穿透工具，但这会增加延迟和复杂度，不符合“开箱即用”的设计初衷。