做过网站运维的朋友应该都有印象：需求方嘴上说“帮我部署个网站”，可落到手上的往往是一台什么服务都要往上堆的小机器。因为多域名、多证书、多服务配置乱掉导致的线上事故，我见过不少：证书串站、服务回源到错误端口、用户明明访问的是A域名，页面里却渲染出B站的内容。其实Nginx天生就适合“一台服务器，多个域名，多个证书，多个服务”这种玩法，完全不需要一个服务配一台机器。这篇文章我把它从端口规划、server块匹配、SSL证书挂载、反向代理分流到排错验证，完整梳理一遍，顺便把那些配置文件之外才踩得到的坑交代清楚。适合正在管理多站点服务器、想在一台机器上跑多个服务的研发和运维同学直接参考。
1. 动手之前，先把端口、目录和域名规划明白
很多人配置多域名一上来就写 server 块，写到一半发现证书路径乱、端口冲突、日志混在一起，最后整个 nginx.conf 变成一坨没人敢动的“祖传配置”。我强烈建议先花十分钟做规划，这部分省下来的时间，后面排查故障时全都能赚回来。
1.1 端口规划：别让后端服务在公网裸奔
先立一个总原则：对外只暴露 80 和 443 两个端口，后端服务不要直接用公网接口监听。Nginx 在这里的角色是“入口总调度”，它根据域名把请求转发到本机的不同内部端口。
比如我要在一台服务器上同时跑三个服务：
| 服务 | 对外访问方式 | 实际运行位置 |
|---|---|---|
| 官网静态站 | https://www.example.com | /var/www/example-site，Nginx 直接读文件返回 |
| API 后端 | https://api.example.com | 127.0.0.1:8080，Java 或 Python 写的服务 |
| 文档站点 | https://docs.example.org | 127.0.0.1:3000，本地跑的一个文档服务 |
注意看后面两列：API 和文档服务都监听在 127.0.0.1，而不是 0.0.0.0。这里有个很多人忽视的安全细节：一旦后端监听 0.0.0.0，而云平台安全组配得比较宽，外部请求就能绕过 Nginx 直接打到你的 8080 端口。你的鉴权、限流、日志全在 Nginx 层，绕过它等于把这些保护全丢弃了。监听 127.0.0.1 之后，外部只能通过 Nginx 反代访问，路径完全收口，排查问题也只要盯 Nginx 日志和后端日志两头就行。
1.2 目录规划：每个域名各归各，别堆在一团
目录规划我习惯按域名分文件夹，虽然一开始稍微多点目录，但后续维护非常清爽：
/var/www/example-site # 官网静态文件 /var/www/docs-app # 文档站静态文件 /etc/nginx/certs/www.example.com/fullchain.pem /etc/nginx/certs/www.example.com/privkey.pem /etc/nginx/certs/api.example.com/fullchain.pem /etc/nginx/certs/api.example.com/privkey.pem /var/log/nginx/www.example.com.access.log /var/log/nginx/api.example.com.access.log证书文件按“域名目录”存放，是我踩过坑之后才养成的习惯。早先我把所有证书堆在 /etc/nginx/ssl/ 下，文件名也起得模模糊糊，到续期的时候对着几十个文件完全认不出谁是谁，只能一张张用 openssl 去读，非常痛苦。日志同理，分开写才能在出问题的时候一眼定位到具体站点的流量特征。
最后提醒一句：域名解析也提前做好。把 www.example.com、api.example.com、docs.example.org 的 A 记录全部指到这台服务器 IP，本地测试临时加 hosts 也行，但线上必须等 DNS 生效再动手，否则配置半天访问的还是旧地址。
2. 多域名的骨架：server 块与请求匹配规则
Nginx 的多域名能力，本质上就是多个 server 块各管各的域名。这个过程理解透，后面挂证书、加反代都是往里填东西而已。
2.1 server_name 就是 Nginx 的路由表
把 server 块想象成街边一排店铺，每个店门口挂一块招牌，写着店名。Nginx 收到一个 HTTP 请求时，会先看请求头里的 Host 字段，然后拿着这个名字去比对所有招牌，找到匹配的那家店就把请求交给它处理。
比如下面这个最朴素的配置：
server { listen 80; server_name www.example.com; root /var/www/example-site; } server { listen 80; server_name api.example.com; location / { proxy_pass http://127.0.0.1:8080; } }访问 www.example.com 时，Nginx 看到 Host 是 www.example.com，走到第一个 server 块，直接读 /var/www/example-site 下的文件；访问 api.example.com 时，走到第二个 server 块，把请求反向代理到本机 8080 端口。
这里有个容易让新手困惑的点：如果两个 server 块都监听 80，而访问的域名两个都没匹配上，Nginx 会选第一个“监听相同端口的 server 块”作为默认处理者。严格说这是默认 server 的行为，我建议显式声明：
server { listen 80 default_server; server_name _; return 444; }默认 server 可以用来兜底，直接丢弃无法识别的请求，返回 444 状态码比随手给个页面更干净，也能挡掉一部分扫描流量。
2.2 server_name 匹配优先级：精确、通配、正则
server_name 的匹配规则很重要，很多诡异的“串站”问题都源于此。Nginx 的顺序是：
- 精确匹配优先，写的什么域名就匹配什么域名。
- 其次是以
*.开头的通配符，比如*.example.com。 - 再来是形如
www.*的前置通配符。 - 最后是正则表达式，多个正则按配置出现顺序匹配。
这意味着，如果你同时配置了api.example.com和*.example.com两个 server，访问 api.example.com 时一定走精确匹配那条，通配符不会抢。反过来，如果你的配置里只有一个*.example.com，访问 blog.example.com 会正常命中，但访问 example.org 就一定不会进这个块。不少人以为“通配符域名能覆盖所有”，其实它只覆盖符合模式的子域名。
2.3 先跑通 HTTP 骨架，再叠加证书
第一次配置多域名时，我建议先不要碰证书，让所有域名走 HTTP 都能正常访问，再加 443。这一步的意义是把问题分层：如果 HTTP 都有问题，说明是 server 块或路由的问题；加证书后才出现的毛病，才是证书链路的问题。
把上一节的两个 server 块放到 /etc/nginx/conf.d/multi-site.conf 里，然后执行：
nginx -t systemctl reload nginxnginx -t 会先检查配置语法和证书文件是否存在，报错会直接告诉你第几行有问题。这个命令是后面所有操作的安全网，改完配置必须跑一次。
3. 多证书实战：一张 Nginx 挂多张 SSL 证书
多证书配置本身不复杂，复杂的是很多细节只有真正配过的人才知道。下面按我自己的操作顺序完整讲一遍。
3.1 证书文件就位：fullchain.pem 才是正确的选择
从证书服务商那里申请成功后，通常会拿到几个文件：
- cert.pem：叶子证书，只包含你的域名证书本身。
- chain.pem：中间证书链。
- fullchain.pem：叶子证书加中间证书链合并后的完整文件。
- privkey.pem：私钥，非常重要，不能泄露。
Nginx 配置中我推荐用fullchain.pem配privkey.pem的组合。如果你只写了 cert.pem，不少纯手机端 App、老版本浏览器会报“证书链不完整”，因为客户端只拿到叶子证书，无法向上验证到受信任的根证书。如果用 fullchain.pem，服务端会把中间证书一起下发，客户端验证链路就完整了。
如果服务商没给合并好的 fullchain，一行命令就能自己拼：
cat cert.pem chain.pem > fullchain.pem注意顺序不能反：自己的叶子证书要在前面，中间证书跟在后面。拼好后记得把 fullchain.pem 权限调整到 Nginx worker 进程能读到的程度，证书私钥建议设为 600，属主改为 root 或 nginx 用户。
3.2 每个 server 块各挂各的证书：最直观的多证书写法
多证书的核心思路，一张证书管一个 server 块。两个域名、两张证书的完整写法如下：
server { listen 443 ssl http2; server_name www.example.com; ssl_certificate /etc/nginx/certs/www.example.com/fullchain.pem; ssl_certificate_key /etc/nginx/certs/www.example.com/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; root /var/www/example-site; } server { listen 443 ssl http2; server_name api.example.com; ssl_certificate /etc/nginx/certs/api.example.com/fullchain.pem; ssl_certificate_key /etc/nginx/certs/api.example.com/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }listen 443 ssl http2这行是目前主流 Nginx 版本都能用的写法。1.25.1 之后的版本官方推荐单独写http2 on;，但我实测旧写法依然兼容，如果你所在的环境版本较旧，就用我这种最稳的写法。
ssl_protocols TLSv1.2 TLSv1.3建议写上，这直接关掉了 TLSv1.0、TLSv1.1 这些已经不安全的老协议。至于ssl_prefer_server_ciphers，现代客户端基本不太依赖服务端决定的 cipher 顺序，保留这个配置主要是出于兼容旧设备的考虑，加上也没坏处。
我见过一个常见错误：有人的 server_name 写成api.example.com www.example.com，想用一张证书同时服务两个域名。如果这张证书是 SAN 证书，确实可以这么做，但配置上会带来“入口宽泛化”的问题——所有域名共用一套证书和一套 location，之后想单独调整某个域名就难了。因此我建议保持“一个业务域名一个 server 块”的边界，各管各的。
3.3 单域名、通配符、SAN 证书到底怎么选
证书选型会直接影响后面的维护成本。这里放一张我常用的对比表：
| 证书类型 | 覆盖范围 | 典型场景 | 维护成本 |
|---|---|---|---|
| 单域名证书 | 仅一个域名，如 www.example.com | 单独一个核心站点 | 每张独立申请、续期，站点多时会比较繁琐 |
| 通配符证书 | 一个主域名下的所有子域，如 *.example.com | 子域名很多，且都归同一主体管 | 一张管全部子域，私钥泄露影响面也更大 |
| SAN 证书 | 多个指定域名，如 example.com 和 example.org | 域名数量少但跨多个顶级域 | 一张证书多个名字，续期一次即可 |
实际场景里我建议：如果你的服务就是“一个官网 + 一个 API”，用两张单域名证书最清晰，互不干扰；如果 sub1.example.com、sub2.example.com 这类子域名有七八个，一张通配符证书最省事；SAN 证书适合域名不多但主体一致的场景。证书不是越多越复杂，而是要和你的域名结构匹配。
3.4 HTTP 自动跳 HTTPS 与 HSTS 的注意点
多域名场景下的 HTTP 跳转，不一定要给每个域名写一个独立的 80 server 块，把没上证书的域名排除在外，可以合并：
server { listen 80; server_name www.example.com api.example.com; return 301 https://$host$request_uri; }这里有一个非常实用的变量：$host会自动替换成用户实际访问的域名，所以只要 server_name 列进去的域名，跳转后都会去到自己对应的 HTTPS 地址，不会跳错。
说 HSTS 要格外谨慎，是因为一旦你给某个域名下发Strict-Transport-Security响应头，浏览器会在一定时间内记住“这个域名只能走 HTTPS”，中途你哪怕想临时改成 HTTP 排查问题，浏览器也会直接拒绝访问。稳妥做法是先让多站点稳定跑上一段时间，再决定要不要开 HSTS，开了之后也要把 max-age 设得保守一点。
3.5 证书续期与 reload 操作
证书续期后，Nginx 不会自动感知新证书。无论你用 certbot 自动续期还是手动替换，最后都要执行一次 reload 让新证书生效。certbot 场景最省事的写法是在续期钩子里带上 reload：
certbot renew --renew-hook "systemctl reload nginx"意思很直白：证书只要成功续了一次，就顺手把 Nginx reload 一下，不需要人工登录服务器去折腾。配合 crontab 或者 systemd timer 每周跑一次 renew 检查，基本能做到证书不裸奔。
4. 多服务分流：一个入口，多个后端
域名和证书都到位后，剩下的核心工作就是“分流”。分流有两条路：按域名分，按路径分。实际项目里两者经常混用。
4.1 按域名分流到不同后端服务
这是最直观的方式，我已经在上面的配置里展示过。每个 server 块里的 location 把请求转发给对应端口即可。关键是下面这几个头部不能漏：
proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme;为什么后端需要这几个头？举个常见例子：后端代码里要根据请求域名生成绝对链接，如果拿不到真实 Host，生成出来的 URL 就会是http://127.0.0.1:8080/xxx这种用户根本点不开的地址。再比如登录日志、风控系统要记录访客真实 IP，如果没传 X-Real-IP 和 X-Forwarded-For，后端看到的全是 127.0.0.1，等于把所有用户都识别成“本机访问”。X-Forwarded-Proto 则是告诉后端“用户当时用的是 HTTPS 还是 HTTP”，很多框架以此判断是否启用安全 Cookie。
4.2 同一域名下按路径分流：location 才是重头戏
如果多个服务实在不想拆域名，只想用同一个域名下的不同路径来区分，也是可以的：
server { listen 443 ssl http2; server_name www.example.com; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; } location /docs/ { proxy_pass http://127.0.0.1:3000; } location / { root /var/www/example-site; } }这里有个非常容易踩的坑，就是 proxy_pass 后面是否以斜杠结尾。不带斜杠时，Nginx 会把请求的完整 URI 原样传给后端；带斜杠时，location 里匹配到的前缀部分会被替换掉。比如请求/api/users，如果是proxy_pass http://127.0.0.1:8080;，后端收到的还是/api/users；如果是proxy_pass http://127.0.0.1:8080/;，后端收到的会变成/users。后端路由按完整路径写还是按去掉前缀写，决定着你该用哪种。改配置前一定先确认后端接口的期望路径，这一条我能单独讲一节课的反例。
location 匹配本身也有优先级：精确匹配=最高，其次^~前缀匹配，再次正则~，最后普通前缀匹配。混用正则和普通前缀时，正则往往会“抢”掉普通前缀的请求，所以新手上路我不建议在一个 server 块里同时出现多个正则 location，很容易把自己绕晕。
4.3 WebSocket 和长连接的坑
如果你用 Nginx 反代的是一个带实时推送功能的后端，比如在线聊天、协作白板、热更新 dev server，那默认的反代配置大概率连不上，因为 WebSocket 握手依赖 Upgrade 机制，而 Nginx 默认用的是 HTTP/1.0。
需要额外加这几行：
proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 3600s;proxy_http_version 1.1让 Nginx 与后端之间使用 HTTP/1.1，从而支持 Upgrade 头；Connection 设为 upgrade，Nginx 才会把升级请求原样传过去。proxy_read_timeout是针对长连接闲置时间的设置，如果后端允许长时间没有消息的空闲连接，这个值不调大，连接会被切断，表现就是前端每隔几分钟自动断开一次。
4.4 收口思路：只暴露 80 和 443
多服务方案改完，最后一步是“收口”。在云平台安全组里，通常只需要放行 80、443 两个公网入方向端口，其余端口一律不开放。Nginx 监听 443，内部端口全部只在回环地址上接受请求。这样外部能触达的入口只有 Nginx，所有风险面都在它的控制范围内。
反过来，如果为了省事把 8080 也加到安全组，那等于把后端服务直接晾在公网上，别人可以绕过 Nginx 探测你的 API、尝试攻击，而你在 Nginx 里配的限流、拦截规则全部失效。这个口子无论如何都不能开。
5. 我踩过的坑，也是排查多站点服务器的标准动作
配置层面的东西讲完之后，这些是我实际运维中反复遇到的问题。每个坑背后都是一次线上事故的教训。
5.1 nginx -t 通过，线上访问却 502
配置文件语法完全没问题，一访问 api.example.com 就 502 Bad Gateway。这是最让人头疼的情况，因为它不是配置语法错误，而是运行链路问题。
我自己的排查顺序是固定的：
- 先在本机直接 curl 后端端口，确认服务本身是否存活：
curl -v http://127.0.0.1:8080/health- 如果直接访问也失败，去后端的启动日志里找原因，可能是端口没起来、进程被杀、依赖的数据库断了。
- 如果本地访问正常，看 Nginx 的 error log：
tail -f /var/log/nginx/error.log- 检查 proxy_pass 是否写错，比如域名拼写、端口数字、末尾斜杠问题。
还有一个容易被忽略的元凶：CentOS 系服务器默认开 SELinux，它可能拦截 Nginx 向本地其他端口发起代理请求，这时 access log 里看不到任何错误，error log 里会有connect() to 127.0.0.1:8080 failed (13: Permission denied)。解决方法是在 SELinux 里放行 Nginx 的网络连接：
setsebool -P httpd_can_network_connect 1这个问题不常遇到，但一旦遇到，排查时间极长。我建议排到 502 时先看一眼 error log，是不是这一句话。
5.2 证书明明配了，浏览器还是提示不安全
这种问题通常不是“证书文件不存在”，而是“证书下发的对象不对”。按可能性从高到低排列：
- ssl_certificate 写成了 cert.pem 而不是 fullchain.pem，导致证书链不完整。
- server_name 写错，请求落到了默认 server 块，默认块里挂的是另一张证书。
- 证书和域名本身不匹配，比如把 api.example.com 的证书配给了 api.example.org。
验证证书是否下发正确，一条命令就够：
echo | openssl s_client -connect 127.0.0.1:443 -servername api.example.com 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName这条命令让 openssl 拿着你要测的域名去连服务器，然后打印出实际收到证书的 subject、有效期和 SAN 扩展。打印出来的域名和访问域名对不上，问题就定位到 server 块或证书选型上。
5.3 端口被占用，Nginx 根本起不来
启动时报bind() to 0.0.0.0:80 failed (98: Address already in use)，第一反应不是改配置，而是看谁占了这个端口：
ss -lntp | grep :80常见占端口的是 Apache、另一个 Nginx 实例或者 Docker 端口映射。处理方案无非两条：停掉占用进程，或者把自己的 80 端口换掉。多数业务场景没有换端口的空间，因为用户默认走 80/443，所以正确动作通常是处理掉冲突进程。注意，如果服务器上已经跑了一个 Nginx 且配置里有多个 include 目录，你的新配置可能被重复载入，这也会造成端口被“自己”占用。
5.4 改了配置忘了 reload，出现“幽灵问题”
这是最经典的线上事故：改完 nginx.conf，觉得语法没问题，执行了 nginx -t 看到提示就以为完事了，结果线上行为完全没变化，折腾半天才发现根本没 reload。配置文件的修改对 Nginx 主进程是“待生效”状态，必须通过 reload 让 worker 重新加载。
我给自己定了一个死规矩：一切改配置的流程，最后两步永远是nginx -t然后systemctl reload nginx，中间不夹任何其他动作。人总会犯懒，形成肌肉记忆就不会漏。
5.5 访问日志混在一起，出问题要翻半天
多站点共用一份 access_log 时，排查某个域的异常流量就像在一片大海里捞针。正确做法是在每个 server 块里单独写日志：
server { listen 443 ssl http2; server_name www.example.com; access_log /var/log/nginx/www.example.com.access.log main; error_log /var/log/nginx/www.example.com.error.log; }main 是 Nginx 默认的日志格式，也可以在 http 层自定义。之后查任何域名的问题，直接看对应日志，不用再加 grep 过滤，效率完全不同。
6. 上线验证与日常维护清单
配置全部完成后，别急着宣布“已经上线”，按下面这套流程过一遍，稳妥得多。
6.1 一套完整的验证命令
# 1. 检查配置语法 nginx -t # 2. 验证各域名 HTTP 响应 curl -I http://www.example.com # 3. 验证 HTTPS 与证书链 curl -I https://api.example.com # 4. 验证证书内容和有效期 echo | openssl s_client -connect 127.0.0.1:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -subject -dates # 5. 验证后端 API 能通过 Nginx 正常返回 curl -I https://api.example.com/api/health我通常还会拿手机流量关掉 Wi-Fi 再访问一遍，因为本地可能配了 hosts 或代理，只有真实公网流量才能验证 DNS 和证书链的完整状态。
6.2 证书到期检查与提醒脚本
证书续期可以交给 certbot，但人工巡检也不能省。我写过一个很小的脚本，放到 crontab 里每周跑一次：
#!/bin/bash # 用法: ./check_cert.sh www.example.com domain=$1 enddate=$(echo | openssl s_client -servername "$domain" -connect 127.0.0.1:443 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2) expire_ts=$(date -d "$enddate" +%s) now_ts=$(date +%s) left=$(( (expire_ts - now_ts) / 86400 )) echo "$domain 证书剩余 $left 天" if [ "$left" -lt 15 ]; then echo "警告: $domain 证书将在 $left 天后到期" >> /var/log/nginx/cert-check.log fi脚本其实非常简单，也能手动用。有了这个，证书到期就不再是“突然发现访问挂了”的惊吓事件。
6.3 日常改配置的固定流程与回滚思路
多站点服务器上最怕“手一抖改错了”，所以每次动配置我会走四步流程：
- 改前备份：
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak-$(date +%F) - 修改完立刻
nginx -t检查语法。 - 确认无误后
systemctl reload nginx。 - 用 curl 或者浏览器实际访问所有受影响域名，验证行为符合预期。
如果要改动的是大版本升级或者可能要回滚的高风险变更，光备份还不够，我习惯先把新的 server 配置写在单独的 conf.d 文件里，通过 include 方式挂进来，出问题只需删掉 include 那行再 reload 就能回滚。别直接去改全局 nginx.conf 里的主体段落，一旦哪里改断，恢复起来会非常痛苦。
最后再分享一个坚持了很多年的习惯：做完多域名、多证书、多服务这套配置后，我会在 /etc/nginx/ 下放一个 README 文件，简单记录这台服务器上有哪些域名、每张证书对应哪个路径、后端端口分别是什么、续期时间约定在哪天。别小看这几行备注，半年后服务器上的服务可能已经换了好几轮，你当时的大脑缓存早就清空了。Nginx 配置本身不算难，难的是让配置在漫长的运行周期里始终清晰、可控、可维护，这些看起来不起眼的记录和流程，才是长治久安的关键。
