nginx -t 显示语法通过，却同时警告 conflicting server name ... ignored，这时网站可能仍能打开，但请求并未落到你以为的站点配置上。警告通常说明同一监听地址和端口上的域名匹配发生重复，其中一个名称定义没有按预期参与选择。
遇到这个问题，不要直接删除整个站点配置，也不要因为语法测试通过就当作没有风险。
先看警告里的域名和监听地址
运行测试并记录警告给出的域名、IP与端口：
nginx -t0.0.0.0:80、指定IP的80端口与443端口不应混为一谈。先确定冲突发生在哪个监听组合，再去找该组合内重复的 server_name。 Nginx维护者说明，此类警告通常不会让全部配置加载失败，但被忽略的名称会造成预期外路由。
用有效配置找出重复的server块
nginx -T 会测试并输出实际加载的完整配置，包括通过 include 引入的文件：
nginx -T 2>&1 | less搜索警告中的域名，沿着每个匹配位置往上看所在的 server {} 和 listen。发行版常同时加载 sites-enabled、conf.d 或面板生成文件。只改自己正在编辑的文件，却没发现另一个仍在生效的副本，是最常见的漏项。 输出可能包含凭据，请只在可信终端查看。
明白为什么落到了意料之外的站点
Nginx先按请求到达的IP和端口选择监听组，再按请求中的主机名匹配server块；HTTPS还会在握手期间考虑SNI。没有匹配的主机名会交给该监听组的默认server处理。
因此出现错误页面不一定是DNS故障：两份站点配置都写了相同域名、同样的监听组合时，应确认真正参与匹配的是哪一份。default_server 控制没有匹配时的默认站点，不能代替修复重复域名定义。
修改前验证Host和HTTPS的SNI
本地DNS仍在传播时，可以将域名直接指向目标服务器做请求验证。把示例IP替换为实际服务器地址：
curl -I --resolve example.com:80:203.0.113.10 http://example.com/
curl -I --resolve example.com:443:203.0.113.10 https://example.com/--resolve 只改变此次请求的解析目标，URL中的域名仍用于Host与HTTPS连接。不要为了测试而关闭TLS证书校验；证书不匹配本身就是需要查明的线索。
只保留预期的域名归属
明确哪个server块应该处理该域名，然后在重复配置中移除或更正多余的 server_name；若两个站点确实需要共存，应给它们不同域名或区分监听地址与端口。修改前备份相关配置文件，并检查面板或自动部署工具是否会再次生成重复块。
不要把两个 default_server 都放在同一监听地址和端口上。 这与域名冲突警告不同，可能导致配置测试直接失败。
在隔离环境复现复杂站点配置
涉及多域名、反向代理和证书时，可以在 萤光云 或 LightNode 的隔离VPS复现server块选择逻辑。不要复制生产私钥或真实访问令牌到测试机。
复现时尤其要保持相同的 listen、server_name 与 include 关系，否则测试结果不能解释生产上的冲突。
测试和重载后如何验收
配置修改完先运行测试，确认冲突警告消失，再平滑重载：
nginx -t
systemctl reload nginx重载后分别验证HTTP、HTTPS及实际域名访问，检查证书、响应头与站点内容。验收标准是目标域名在正确监听地址上稳定进入预期站点，且Nginx测试不再提示该域名冲突。
FAQ
语法测试显示successful，为什么网站还是错的？ 冲突是警告，Nginx可能继续加载配置，但其中一个名称定义不会按你预期用于匹配。
把冲突站点设成default_server能解决吗？ 不能。默认站点只处理未命中合适名称的请求，仍应先清理重复的域名定义。
温馨提示
先用 nginx -T 查清全部生效配置，再用真实域名测试。 一次修复后如果警告重现，应排查自动部署工具是否又生成了相同的server块。
