域名访问异常若由server_name冲突引起，本质是Nginx无法准确识别请求应归属哪个站点；解决关键在于理清匹配逻辑、消除歧义、验证路由路径，包括检查Host头匹配、清理重复定义、分离HTTP/HTTPS配置并完整验证。

域名访问异常若由 server_name 冲突引起，本质是 Nginx 无法准确识别请求应归属哪个站点。解决关键不在于删配置，而在于理清匹配逻辑、消除歧义、验证路由路径。

确认 server_name 是否被真实匹配

Nginx 不看“写了什么”，只看“Host 请求头是否命中”。浏览器实际发出的 Host 值（如 www.example.com）必须与某个 server_name 条目完全一致，或符合通配符规则（仅支持 *.example.com，不支持 www.*.com 或 example.*）。

• 用 curl -H "Host: www.example.com" http://服务器IP 模拟请求，绕过 DNS，直测 Nginx 路由逻辑
• 检查 Nginx 错误日志（error.log），搜索 no suitable server found 或 could not be resolved 类提示
• 若所有 server_name 都未匹配，Nginx 会退回到该端口下第一个 server 块（或标记为 default_server 的块）——这常导致“总是打开默认页”或“打开错误站点”

清理重复与模糊的 server_name 定义

多个 server 块共用相同或重叠的 server_name，是冲突高发区。尤其警惕以下写法：

• server_name _; 出现在不止一个 server 块中：下划线是通用占位符，多个同时存在会让 Nginx 无法判定优先级
• server_name "";（空字符串）和 server_name _; 混用：二者语义不同，但都属兜底类型，不宜并存
• 遗漏 www 主域组合：仅写 server_name example.com;，则 www.example.com 请求会被其他块或默认块捕获

正确做法是：每个站点明确列出全部合法域名，例如 server_name example.com www.example.com;；兜底块仅保留一个，且显式加 default_server 标识。

确保 listen 与协议、端口严格对齐

server_name 生效的前提是请求先抵达正确的 listen 端口。常见错配包括：

• HTTPS 请求（https://example.com）发往 listen 80; 块，必然失败
• HTTP 和 HTTPS 配置混在同一 server 块中，未分离协议处理逻辑
• 两个 server 块都写 listen 443 ssl; 且 server_name 相同，Nginx 启动直接报错

建议将 HTTP 和 HTTPS 分开配置：一个块专注 listen 80; 并做 301 跳转；另一个块专注 listen 443 ssl;，并确保包含有效证书路径。

验证与快速回滚手段

修改后务必执行完整验证链，避免引入新问题：

• 运行 nginx -t 检查语法，再 nginx -s reload 生效
• 用 nginx -T 输出全部生效配置，人工核对各 server 块的 listen、server_name、root 是否符合预期
• 临时在各 server 块的 location / 中加入唯一标识响应头，例如 add_header X-Site "example-com";，再用 curl -I 查看实际响应头，确认路由无误
• 保留一份干净的最小化配置备份，故障时可秒级切回