写在前面
这是一套已经在生产环境跑通的中转架构。
目标并不复杂，但很现实：
- 源站不暴露公网
- 公网只开放一个入口
- 支持 Docker / Discourse / Web 应用
- HTTPS 终止在中转机
- 可扩展、可维护、可排错
如果你也有这些需求，这套方案可以直接照搬。
一、为什么需要“中转机”
常见的真实场景：
- 源站在内网 / 弱公网 / 低配 VPS
- 源站 IP 不稳定或不适合暴露
- 想统一 HTTPS / 证书 / 防护策略
- 想把管理后台（Portainer / Admin）彻底隐藏
传统方案的问题：
| 方案 | 问题 |
|---|---|
| 直接暴露源站 | 攻击面大，安全差 |
| SSH 端口转发 | 不稳定，维护成本高 |
| FRP / 内网穿透 | 复杂、依赖中心 |
| 反代直连公网 | 源站仍暴露 |
真正想要的是：源站“彻底不可达”，但业务可达
二、为什么选 WireGuard，而不是别的
WireGuard 在这个架构里解决的是 “可靠的私有网络” 问题。
它的特点非常适合做中转：
- 内核态 VPN，性能好
- 配置简单，几乎零维护
- 点对点，不依赖中心
- 不引入复杂路由
在这里，WireGuard 的职责只有一个：
让中转机像在访问本地内网一样访问源站
三、整体架构图（文字版）
公网用户
│
▼
中转机（VPS）
- 公网 IP
- Nginx（80 / 443）
- HTTPS 终止
- 统一反代
│
▼ WireGuard（10.100.0.0/24）
源站（VPS / 物理机）
- 无公网暴露
- Docker / Discourse
- 端口只绑定 WireGuard IP
关键原则：
- 公网只打到中转机
- 源站完全不可被公网访问
- 所有回源流量走 WireGuard
四、核心设计原则（非常重要）
中转机是唯一公网入口
- 80 / 443 只在中转机开放
- 证书、TLS、HTTP 逻辑都在中转机
- 源站不处理 HTTPS
源站端口只绑定 WireGuard IP
例如：
10.100.0.2:8082 → Discourse
10.100.0.2:9000 → Portainer
而不是：
0.0.0.0:8082 ❌
这一步，决定了源站是否真正“隐身”。
中转机只关心“IP + 端口”
中转机 不关心 Docker 容器名，不关心内部结构：
proxy_pass http://10.100.0.2:8082;
这让职责边界非常清晰：
- 源站：负责跑服务
- 中转机：负责发布服务
五、适用场景与不适用场景
非常适合
- Discourse 论坛
- Docker 应用
- 管理后台（Portainer）
- 个人站点 / 小团队服务
- 低配 VPS（512MB 也足够）
不适合
- 超高并发（需要 CDN）
- 复杂多地域调度
- 对延迟极度敏感的场景
六、你能得到什么
完成整套架构后：
- 源站 完全不暴露公网
- 公网攻击面只有 Nginx
- 管理后台可单独加白名单
- HTTPS、证书统一管理
- Docker / 应用随便换，不影响入口
这是非常接近生产级的中转模型。