Nginx配置多域名怎么写，Nginx多域名如何配置

在现代Web服务器架构中，Nginx凭借其高性能、低内存占用及灵活的反向代理能力，已成为部署多域名服务的首选方案，实现Nginx配置多域名的核心逻辑在于利用基于名称的虚拟主机技术，即通过server_name指令在同一IP地址和端口上区分不同的域名请求，这不仅能够大幅降低服务器运维成本，还能有效提升资源利用率，对于企业而言，掌握这一配置是构建高可用、多业务线网络基础设施的关键一步。

基础配置架构与核心指令

Nginx处理多域名请求的流程主要依赖于配置文件中的server块，每一个独立的域名（或子域名）都应该对应一个独立的server配置块，在Nginx的主配置文件nginx.conf中，通常使用include指令来引入外部配置文件,以保持主文件的整洁。

最核心的配置指令是server_name，Nginx在接收到HTTP请求头中的Host字段后，会将其与所有server块中的server_name进行匹配，一旦匹配成功，即使用该server块内的配置（如根目录、反向代理路径、SSL证书等）来处理请求。

以下是一个标准的多域名基础配置示例：

http {
    # ... 其他全局配置 ...
    # 域名 A 的配置
    server {
        listen 80;
        server_name www.example.com example.com; # 支持多域名写在一行
        root /var/www/site_a;
        index index.html;
        location / {
            try_files $uri $uri/ =404;
        }
    }
    # 域名 B 的配置
    server {
        listen 80;
        server_name www.api.com;
        # 反向代理到后端服务
        location / {
            proxy_pass http://127.0.0.1:8080;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }
}

在上述配置中，精确匹配优先级最高，如果请求的Host头完全等于www.example.com，Nginx会直接选择对应的server块，这种配置方式简单直接,适用于绝大多数静态网站和简单的反向代理场景。

高级匹配规则与通配符应用

在实际的企业级应用中，业务往往涉及大量的二级域名或动态域名，仅靠硬编码server_name已无法满足需求，Nginx提供了强大的通配符和正则表达式支持,极大地增强了多域名配置的灵活性。

通配符匹配主要用于处理所有子域名或特定前缀的域名，使用*.example.com可以匹配mail.example.com、bbs.example.com等任意子域名,这在企业统一入口或泛域名解析场景中非常有用。

正则表达式匹配则提供了更动态的控制能力，通过在server_name中使用开头,可以捕获域名中的特定变量并加以利用。

server {
    listen 80;
    server_name ~^(?<subdomain>.+).example.com$;
    root /var/www/$subdomain;
}

在这个例子中，(?<subdomain>.+)是一个命名捕获组，当用户访问shop.example.com时，变量$subdomain的值即为shop，Nginx会自动将根目录指向/var/www/shop。这种配置方式极大地减少了重复代码，实现了基于域名的动态目录映射,是SaaS平台或多租户系统的常见配置策略。

需要注意的是，正则匹配的优先级低于通配符匹配，而通配符匹配又低于精确匹配，在配置复杂环境时，必须清晰理解这一优先级逻辑，避免流量被错误的server块截获。

HTTPS与SSL证书的自动化处理

随着搜索引擎对HTTPS权重的提升，多域名配置必须包含SSL/TLS的安全加固，在多域名环境下配置SSL，主要面临两个挑战：证书的部署与HTTP到HTTPS的强制跳转。

对于多域名SSL证书，通常有两种选择：多域名证书（SAN）或通配符证书，如果业务域名数量较少且固定，SAN证书是首选；如果涉及大量二级域名，通配符证书（如*.example.com）则更具成本优势。

在Nginx配置中，建议为每个server块指定特定的证书路径,并配置强制跳转：

server {
    listen 80;
    server_name www.example.com;
    # 强制将HTTP重定向至HTTPS
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    # SSL优化配置
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    # ... 业务配置 ...
}

在现代Nginx版本中，利用SSL变量可以实现不同域名动态加载证书，但这需要OpenSSL的支持，且配置较为复杂，对于追求稳定性的生产环境，明确指定每个域名的证书路径依然是最佳实践,能够有效避免证书链混乱导致的握手失败。

酷番云实战案例：高并发电商多域名架构

在处理复杂的云原生架构时，Nginx的多域名配置往往需要结合云厂商的底层特性进行优化。酷番云在近期服务一家大型跨境电商客户时，遇到了极具代表性的挑战：该客户拥有五个独立品牌站点，日均访问量超过千万级,且在促销期间面临突发流量冲击。

初期痛点：客户原本采用单台服务器部署所有站点，通过Nginx简单的server_name区分，随着业务扩展，单机资源已耗尽，且SSL证书管理混乱,导致部分站点出现间歇性访问延迟。

解决方案：酷番云技术团队为客户设计了基于负载均衡（SLB）+ 多组弹性计算实例的架构，在Nginx配置层面，我们并未局限于简单的域名区分，而是引入了分层反向代理策略。

在入口层的Nginx（部署于酷番云负载均衡器后端）仅负责域名路由和SSL卸载：

upstream brand_a_cluster {
    server 10.0.1.5:8080;
    server 10.0.1.6:8080;
}
server {
    listen 443 ssl;
    server_name brand-a.com;
    ssl_certificate /cloud/ssl/brand-a.pem;
    ssl_certificate_key /cloud/ssl/brand-a.key;
    location / {
        proxy_pass http://brand_a_cluster;
        # 酷番云内网链路优化
        proxy_set_header Connection "";
        proxy_connect_timeout 1s;
    }
}

独家经验：在酷番云的内网环境中，我们建议将proxy_pass的目标地址指向内网IP，而非公网IP，这不仅大幅降低了网络延迟，还避免了公网流量流出产生的额外费用，利用酷番云的对象存储服务（OSS），我们将静态资源（图片、JS、CSS）剥离，通过Nginx的rewrite规则直接回源至OSS,减轻了后端ECS实例的压力。

经过架构调整，该客户在“黑色星期五”大促期间，系统成功扛住了平时5倍的QPS峰值，且域名响应时间稳定在50ms以内，这一案例充分证明，优秀的Nginx多域名配置不仅仅是修改配置文件，更是与底层云资源深度结合的系统工程。

日志分离与运维监控

在多域名环境下，日志管理是容易被忽视但至关重要的一环，如果所有域名的访问日志都写入同一个文件,后续的日志分析与故障排查将变成噩梦。

最佳实践是为每个server块定义独立的access_log和error_log路径。

server {
    server_name www.site1.com;
    access_log /var/log/nginx/site1.access.log main;
    error_log /var/log/nginx/site1.error.log warn;
    # ...
}

通过这种方式，运维人员可以快速定位特定域名的流量异常或报错情况，结合ELK（Elasticsearch, Logstash, Kibana）等日志分析工具，对不同域名的日志进行索引，可以直观地对比各业务线的流量趋势,为运营决策提供数据支持。

相关问答

Q1：在Nginx配置多域名时，如何设置一个默认的备用域名？

A：在Nginx中，可以使用server_name _（下划线）作为默认的匹配规则，将包含server_name _的server块放置在配置文件的最后，或者使用default_server参数在listen指令中指定，当用户通过IP直接访问，或者请求的Host头在配置中找不到匹配项时，Nginx将自动使用该配置块，通常建议在该默认块中返回444状态码（直接关闭连接）或返回自定义的404页面,以避免暴露服务器信息或被恶意域名解析利用。

Q2：同一个IP配置了过多域名会影响Nginx性能吗？

A：Nginx处理多域名的性能开销主要在于哈希表的查找，理论上，域名数量越多，查找时间会略微增加，但Nginx使用了高效的哈希算法，即使配置数百甚至上千个域名，性能损耗也是微乎其微的，几乎可以忽略不计，真正的性能瓶颈通常在于业务逻辑的处理（如PHP、Java应用）或带宽资源，为了保持配置文件的可维护性，建议使用include指令将不同域名的配置分散到独立的文件中，而不是全部塞进nginx.conf主文件。

希望本文的配置方案与实战经验能为您的服务器运维带来实质性的帮助，如果您在配置过程中遇到棘手的兼容性问题或性能瓶颈，欢迎在评论区分享您的具体场景,我们将共同探讨解决方案。