在自建服务器或私有云环境中，常常需要将多个 Web 服务整合到同一个公网 IP 上对外提供访问。常见的服务如 Rocket.Chat、Nextcloud、Proxmox VE、Mailcow 等，如何设计访问方式成为系统架构中一项重要决策。本文详细总结三种典型方案，并进行全面对比，帮助选择最适合的部署方式。
💡 三种典型方案
方案一：不同端口访问
思路
每个服务占用一个独立的端口，用户通过域名加端口号访问，如：
https://example.com:3000https://example.com:8081https://example.com:8006
优点
- 配置简单，无需对后端做任何修改。
- 不需要设置子域名或路径前缀。
缺点
- 用户体验差，需要输入端口号，记忆负担大。
- 某些 ISP 或防火墙可能屏蔽非标准端口。
- URL 不美观，不利于对外展示。
方案二：同域名 + 路径前缀
思路
多个服务共享同一个域名，通过路径前缀区分，如：
https://example.com/rocketchat/https://example.com/nextcloud/https://example.com/pve/
优点
- 域名统一，所有服务都可走标准 443 端口。
- 用户体验较好，不需要输入端口。
缺点
- 后端服务必须支持路径前缀部署（如修改
base path、ROOT_URL等），否则前端静态资源路径、API 调用会失败。 - 存在 Cookie 作用域和跨服务 Session 冲突风险。
- 配置 rewrite 规则复杂，维护成本高。
方案三：子域名
思路
为每个服务配置一个独立子域名，如：
https://rocketchat.example.com/https://nextcloud.example.com/https://pve.example.com/
优点
- 所有服务都使用根路径
/，无需修改后端配置，兼容性最好。 - 每个服务独立，Cookie、Session、CORS 不冲突。
- 所有服务对外可统一走 443 端口，用户体验最佳。
- 结构清晰，后期迁移或扩展更灵活。
缺点
- 需要配置多个子域名 DNS 记录，并为每个子域名申请证书（但可以用 Let’s Encrypt 自动签发，无额外成本）。
⚖️ 总体对比总结
| 不同端口访问 | 同域名 + 路径前缀 | 子域名 | |
|---|---|---|---|
| 域名数量 | 1 | 1 | 多个子域名 |
| 端口体验 | 差（需手动输入） | 好 | 好 |
| 兼容性 | 中 | 差 | 最好 |
| 用户体验 | 差 | 一般 | 最佳 |
| 配置复杂度 | 最简单 | 复杂 | 一般 |
| 安全性 | 中 | 差 | 最好 |
✅ 最佳实践推荐
如果追求最佳的稳定性和扩展性，子域名方案是最优选择。每个服务对应独立的子域名，内部使用根路径，既保证后端服务的原生兼容性，又能带来最好的用户体验和安全性。
💬 实际配置要点
在 Nginx 中，子域名方案的核心是根据 server_name 区分不同服务，例如：
nginxCopyEditserver {
listen 443 ssl;
server_name rocketchat.example.com;
ssl_certificate /etc/letsencrypt/live/rocketchat.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/rocketchat.example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
只需在 DNS 中配置子域名指向服务器公网 IP，后续扩展任何服务都非常方便。
🔥 总结
- 不同端口方式适合测试或内网环境，最简单，但体验差。
- 同域名路径前缀方式适用于少数对前缀有良好支持的服务，配置复杂，风险大。
- 子域名方式则是综合体验、兼容性和安全性最佳的方案，推荐作为生产环境的首选。
✅ 本文总结了三种方案的特点及优劣势，帮助在多服务自建部署中做出最适合自身场景的选择。