基于Nginx实现子域名式用户空间配置方案咨询

DevOps 小满

2026-8-13

子域名用户空间配置方案评估与最优建议

核心需求回顾

实现*.myportal.com泛子域名映射到对应用户空间，同时通过Nginx托管Angular静态资源并转发Node.js API请求，部署环境为AWS。

各方案评估

方案A（单域名Nginx正则配置）

完全可行，且是最优选择
如果你的方案A是用Nginx正则server_name捕获子域名（比如~^(?<user>.+)\.myportal\.com），这种方式是Nginx原生支持的核心能力，能完美适配你的需求。

优势：

扩展性拉满：新增用户无需修改Nginx配置，仅需创建对应用户的Angular部署目录即可
性能最优：Nginx直接托管静态资源，效率远高于通过Node.js转发静态文件
配置简洁：单个server块搞定所有子域名，维护成本极低

方案B（多域名独立配置）

不推荐
每个用户单独写一个server_name块的方式，仅适用于用户数极少（个位数）的场景。用户量上来后，Nginx配置会臃肿不堪，新增/删除用户都要改配置重启服务，扩展性和维护性极差。

express-subdomain工具

适合API补充，但不适合全局处理
用Express中间件捕获子域名的方式，仅能处理Node.js API部分的路由。若Angular静态资源也通过Node.js服务，会额外消耗服务器资源，性能远不如Nginx直接托管。如果API需要更灵活的子域名逻辑，可以配合Nginx使用，但全局子域名映射交给Nginx更高效。

最优方案落地（优化版方案A）

Nginx配置示例

server {
    listen 80;
    listen [::]:80;
    # 正则捕获子域名作为$user变量
    server_name ~^(?<user>.+)\.myportal\.com;

    # 每个用户的Angular打包文件放在对应目录
    root /var/www/myportal/users/$user/dist;
    index index.html;

    # Angular路由重写，解决刷新404问题
    location / {
        try_files $uri $uri/ /index.html;
    }

    # 转发API请求到Node.js，通过header传递用户标识
    location /api {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        # 把捕获的子域名传给Node.js服务
        proxy_set_header X-User $user;
    }

    # 静态资源缓存策略，提升加载速度
    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # 校验用户目录是否存在，避免无效子域名返回异常
    if (!-d /var/www/myportal/users/$user) {
        return 404;
    }
}

AWS部署关键步骤

DNS泛解析：在Route 53中创建*.myportal.com的A/AAAA记录，指向EC2实例公网IP或Application Load Balancer（推荐用ALB，方便后续扩容和SSL管理）
SSL证书：用AWS Certificate Manager申请*.myportal.com的泛域名证书，绑定到ALB或直接配置到Nginx（若为EC2部署）
目录结构：在EC2上创建统一用户目录/var/www/myportal/users/，每个用户对应一个子目录，Angular打包后将dist文件放入对应目录
Node.js适配：在Node.js服务中读取X-User请求头，以此识别当前请求所属用户，处理对应业务逻辑
权限配置：确保Nginx进程（通常是www-data用户）拥有用户目录的读取权限，避免403错误

内容的提问来源于stack exchange，提问作者Nah