server_name不生效本质是nginx未匹配请求host头，需检查host值是否正确、配置是否被加载、default_server是否拦截、文件名是否含点号干扰加载，以及dns解析与匹配逻辑的区别。
server_name 不生效，本质是 Nginx 没有按预期匹配到请求中的 Host 头。排查重点不在“DNS 解析是否成功”，而在于：**请求发到 Nginx 时，Host 字段值是否正确、Nginx 是否能识别并匹配它、有没有其他配置干扰了匹配逻辑**。域名解析（DNS）只是让浏览器/客户端知道该连哪个 IP，真正决定走哪个 server 块的是 Host 头内容和 Nginx 的匹配规则。
确认请求中 Host 头是否正确
这是最常被忽略的第一步。Nginx 完全依赖 HTTP 请求头里的 Host 字段做匹配，跟 DNS 查询结果无关。
- 用 curl 显式指定 Host 测试：
curl -H "Host: www.example.com" http://你的服务器IP
如果返回预期内容，说明 server_name 配置本身没问题，问题出在客户端发起的请求 Host 不对。 - 用浏览器访问时，打开开发者工具 → Network 标签 → 点开任意请求 → 查看 Request Headers → 找 Host 行，确认值是否为你配置的域名（如 www.example.com，不是 IP 或 localhost）。
- 如果是本地开发，检查 hosts 文件是否把域名指向了正确 IP：
sudo nano /etc/hosts，确保有类似192.168.1.100 www.example.com的条目。
检查 Nginx 是否收到并匹配了该 Host
Nginx 匹配 server_name 是严格且有序的，顺序和 default_server 设置直接影响结果。
- 运行
nginx -t确保配置语法无误，再nginx -s reload重载。 - 查看当前生效的 server 块顺序：
nginx -T 2>&1 | grep -A 5 'server {'（或直接翻看/etc/nginx/sites-enabled/下所有文件内容），确认你的目标 server 块确实被加载，且没有被 default_server 拦截。 - 注意：如果没有显式声明
default_server，Nginx 会把第一个 listen 80 的 server 块当作默认；如果你的配置排在后面，但前面有个server_name _;或没写 server_name 的块，它就会“吃掉”所有不匹配的请求。 - 临时加个日志验证匹配行为，在对应 server 块里加：
access_log /var/log/nginx/example_access.log main;
然后访问域名，看日志是否写入。没写入就说明根本没进这个块。
排除文件名与加载机制干扰
Nginx 会按字母序加载 conf.d/ 或 sites-enabled/ 下的文件，文件名中的点（.）可能引发意外行为。
- 避免在配置文件名中使用点号，比如
example.com.conf可能被某些版本 Nginx 截断解析。改用下划线：example_com.conf更稳妥。 - 确认配置文件确实在启用路径下：
Ubuntu/Debian 看ls /etc/nginx/sites-enabled/；
CentOS/RHEL 看ls /etc/nginx/conf.d/；
软链接是否指向正确的源文件（ls -l查看）。 - 如果有多个监听 80 的 server 块，确保它们的
server_name互不重叠（比如不要同时存在example.com和*.example.com而又没处理好优先级）。
区分“DNS 解析失败”和“server_name 不匹配”
这两者现象相似（打不开网站），但原因完全不同：
-
DNS 解析失败：浏览器地址栏输入域名后，根本连不上服务器（报 ERR_NAME_NOT_RESOLVED 或超时）。此时 ping 域名也失败，
nslookup example.com无响应。解决方法是检查 DNS 设置、hosts、域名解析记录（A/CNAME）。 - server_name 不匹配：域名能解析出 IP，也能建立 TCP 连接（ping 通、telnet IP 80 成功），但返回的是默认页、404 或另一个网站的内容——说明请求到了 Nginx，只是没进你写的那个 server 块。
