Nginx 中 URL 重写如何将多店铺电商系统的子域名独立店铺访问正确解析

作者：袖梨 2026-08-23

Nginx通过server_name正则捕获子域名中的店铺名（如shop1.example.com→shop1），设为$shop变量，再用proxy_set_header将其透传至后端X-Shop-ID请求头，不重写URI、不跳转，仅入口识别与透传。

Nginx 实现多店铺电商系统的子域名独立访问，关键在于从子域名中准确提取店铺标识，并将其作为上下文透传给后端服务，而不是简单跳转或静态转发。后端据此识别租户、加载对应店铺配置、数据和主题。整个过程不依赖应用层改写，全部由 Nginx 在入口完成。

按子域名自动识别店铺并透传标识

Nginx 本身不存储店铺列表，但可通过正则捕获子域名中的店铺名（如 shop1.example.com → shop1），再通过请求头交给后端。

  1. 使用 if + 正则匹配 $host 提取店铺名，并赋值给自定义变量
  2. 必须用 proxy_set_header 将该标识注入请求头（如 X-Shop-ID）
  3. 同时统一 Host 头为后端真实域名，避免后端因原始 Host 异常出错

示例配置：

server {listen 80;server_name ~^(?<shop>[a-z0-9]+).example.com$;# 提取 shop 名到变量 $shop（已由 server_name 正则自动捕获）set $backend_host "backend.example.com";location / {proxy_set_header Host $backend_host;proxy_set_header X-Shop-ID $shop;proxy_set_header X-Real-IP $remote_addr;proxy_pass http://backend-service;}}

✅ 注意：server_name 使用命名捕获组 (?<shop>...) 更简洁安全，比 if 块更推荐（避免 if 的隐式限制问题）

路径保持干净，不暴露店铺上下文给后端路由

后端通常按 /api/products 这类通用路径设计，不应要求它解析 /shop1/api/products。所以 Nginx 不重写 URI 路径，只透传标识——让后端专注业务逻辑，而非 URL 解析。

  1. 不要用 rewrite ^/... 去动 location / 下的路径
  2. 若后端确实需要原始 Host 或完整请求路径做调试，可额外加：

    proxy_set_header X-Original-Host $host;

    proxy_set_header X-Request-URI $request_uri;

支持 HTTPS 和泛域名 SSL 证书

子域名系统必须启用 HTTPS，否则现代浏览器会拦截混合内容或标记不安全。

  1. 使用通配符证书 *.example.com（由 Let’s Encrypt 或商业 CA 签发）

  2. 在 server 块中监听 443，并加载证书：

    listen 443 ssl http2;ssl_certificate /etc/nginx/ssl/wildcard.example.com.crt;ssl_certificate_key /etc/nginx/ssl/wildcard.example.com.key;

  3. 可选：强制 HTTP 跳转 HTTPS

    server {listen 80;server_name ~^(?<shop>[a-z0-9]+).example.com$;return 301 https://$host$request_uri;}

店铺隔离增强：结合 map 实现差异化后端路由（进阶）

若不同店铺部署在不同集群（如 VIP 店铺走高可用集群，普通店走共享池），可用 map 指令动态绑定 upstream：

# 全局 map 块（放在 http 内）map $shop $upstream_backend {default backend-shared;shop-vipbackend-vip;shop-premium backend-premium;}server {listen 443 ssl;server_name ~^(?<shop>[a-z0-9]+).example.com$;location / {proxy_pass http://$upstream_backend;proxy_set_header X-Shop-ID $shop;proxy_set_header Host backend.example.com;}}

这样既保持配置清晰，又支持灵活扩展，无需为每个店铺写独立 server 块。

不复杂但容易忽略

相关文章

精彩推荐