Nginx多站点配置后反向代理失效问题求助

看起来你遇到了一个很典型的Nginx多站点配置冲突问题，别慌，咱们一步步拆解排查：

首先，最可能的原因：默认服务器优先级覆盖了你的配置 #

Nginx在处理请求时，会优先匹配第一个找到的符合条件的server块，如果你的sites-enabled目录里还保留着默认的default配置（比如Ubuntu默认的00-default），它会排在你的app1、app2配置前面（因为按文件名字母排序），而且默认配置里通常会设置listen 80 default_server;，这会导致所有请求都被默认服务器接管，不管你的server_name是什么。

排查步骤：

1. 先看看sites-enabled下的文件列表：

ls -l /etc/nginx/sites-enabled/

如果看到default或者00-default这类文件，先禁用它：

sudo unlink /etc/nginx/sites-enabled/default

然后重启Nginx：

sudo systemctl restart nginx

之后再测试app1.mydomain.com和app2.mydomain.com是否恢复。

其次，检查配置加载的细节问题 #

虽然nginx -t测试通过，但还有几个隐藏点需要确认：

• 监听端口是否明确：你的两个server块都没写listen指令，Nginx会默认监听80，但如果有其他配置（比如之前的默认配置）已经占用了80端口并设置了default_server，就会优先匹配。建议给每个server块加上明确的监听配置：

server {
    listen 80; # 明确监听80端口
    server_name app1.mydomain.com;
    # 其他反向代理配置...
}

app2的配置也做同样修改。

• 符号链接是否正确：确认两个配置的软链接都正确创建且有权限：

ls -l /etc/nginx/sites-enabled/

要确保app1.mydomain.com和app2.mydomain.com的链接都指向/etc/nginx/sites-available下的对应文件，并且Nginx进程能读取这些文件（权限通常是root:root或者root:www-data）。

第三，查看日志找线索 #

Nginx的日志能帮你定位具体问题：

• 查看错误日志，看看重启或请求时有没有报错：

tail -n 20 /var/log/nginx/error.log

比如后端服务不可达、权限不足、配置语法的隐性问题（虽然nginx -t过了，但可能有逻辑冲突）。

• 查看访问日志，看看请求到底被哪个server块处理了：

tail -n 20 /var/log/nginx/access.log

日志里会显示请求的Host头和对应的server名称。

第四，直接测试反向代理逻辑 #

绕过DNS缓存，直接在本地或反向代理服务器上测试请求：

# 测试app1
curl -v -H "Host: app1.mydomain.com" http://10.0.0.1
# 测试app2
curl -v -H "Host: app2.mydomain.com" http://10.0.0.1

看看返回的内容是否符合预期，有没有后端服务的响应，还是Nginx返回了默认页面/404。

最后，确认后端服务可达 #

在反向代理服务器上测试能否直接访问后端服务：

curl http://10.0.0.2
curl http://10.0.0.3

如果后端服务本身不可达，那反向代理肯定也无法返回内容，这时候要检查后端服务器的防火墙、服务状态。

按这个顺序排查，大概率能找到问题所在～

备注：内容来源于stack exchange，提问作者Shadow1349