应运行 nginx -t 查看合并后配置，重点关注 listen 行和 server_name；监听冲突按地址精确度匹配，相同端口下 192.168.1.10:80 优先于 *:80；需用 ss -tlnp 验证实际绑定地址，并结合 telnet 测试连通性。
检查 Nginx 的 listen 指令是否因未指定 IP 导致冲突，关键不是“语法错误”，而是配置逻辑重叠引发的隐性覆盖或路由失效。Nginx 不会报错退出，但实际生效的 server 块可能与预期不符。
看最终合并后的配置结构
直接运行：
nginx -T
它会输出所有被加载、合并、去重后的完整配置（含注释），重点关注每个 server 块的 listen 行和 server_name。这是唯一能确认“哪个块真正生效”的方式。
识别 listen 地址粒度冲突
当多个 server 块监听相同端口时，Nginx 按地址精确度匹配：
-
listen 192.168.1.10:80;比listen *:80;优先级高 -
listen 127.0.0.1:80;和listen 0.0.0.0:80;属于不同地址族，不冲突，但前者对外不可达 - 若两个块都写
listen 80;（即默认*:80）且server_name相同，则后加载者被静默忽略
查文件加载顺序与命名规范
Nginx 按字典序读取 /etc/nginx/conf.d/*.conf，名字靠后的文件可能覆盖前面的同名配置：
- 用
ls /etc/nginx/conf.d/查看实际加载顺序 - 推荐统一前缀：如
00-main.conf、10-api.conf、99-default.conf - 避免在多个文件中重复定义
listen 80;+server_name example.com
验证监听行为是否符合预期
仅靠 nginx -t 无法发现 listen 冲突，必须结合系统级监听状态验证：
- 执行
ss -tlnp | grep ':80'，看实际绑定的是0.0.0.0:80还是127.0.0.1:80 - 若只看到
127.0.0.1:80，说明至少有一个 server 块显式绑定了回环地址，且它可能成为唯一生效项 - 从另一台机器执行
telnet 公网IP 80，不通则大概率是监听地址或安全组问题，而非语法错误
