Nginx server_name响应慢本质是请求路由阶段匹配开销大，主因是通配符/正则导致线性扫描、哈希参数不足、DNS干扰proxy_pass或worker负载不均；需统计数量、优化写法、调大hash参数、检查DNS、启用reuseport。

排查 server_name 响应慢，本质是定位 Nginx 在请求路由阶段的匹配开销。这不是 DNS 解析慢（那是启动或 nginx -t 卡顿的原因），而是每次收到 HTTP 请求后，Nginx 查找对应 server{} 块时效率低下。

检查 server_name 匹配方式是否退化为线性扫描

Nginx 默认用哈希表快速查找 server_name，但一旦配置中含通配符（*.example.com）或正则（~^www\.），就会触发逐个比对，尤其在虚拟主机超百个时延迟明显。

• 运行 nginx -T 2>&1 | grep "server_name" | wc -l 统计总数量，若超过 500，需重点关注
• 搜索配置中所有 server_name 行，确认是否含 * 或 ~ 开头的写法
• 把多个域名合并写在同一行：用空格分隔，如 server_name a.com b.com c.com;，而非拆成三个 server{} 块

验证并调优哈希参数

哈希桶大小或最大容量不足，会导致哈希冲突增多，查找变慢。尤其当域名字符长、数量多时容易触发。

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• 在 http{} 块顶部添加：
  server_names_hash_bucket_size 256;
server_names_hash_max_size 4096;
• 修改后必须执行 nginx -t 检查语法，再 nginx -s reload
• 若仍报错 could not build the server_names_hash，说明值还不够大，可逐步翻倍尝试

确认 DNS 查询不干扰运行时匹配

注意：DNS 问题不会拖慢单次请求的 server_name 匹配，但它会影响 proxy_pass 后端域名解析（如 proxy_pass http://api.example.com）。若你在 location 中用了域名而非 IP，且该域名解析慢，会表现为整个请求延迟高，但 $request_time 和 $upstream_response_time 差值大。

• 用 dig api.example.com @8.8.8.8 +short 测试后端域名解析是否快
• 生产环境建议后端地址统一用 IP 或内网 DNS，避免依赖外部 nameserver
• 检查 /etc/resolv.conf 是否存在不可达的 nameserver（首行不通会导致 10 秒级阻塞）

启用 reuseport 减轻单 worker 压力

当虚拟主机规模极大（如数千个域名），单个 worker 进程处理所有连接请求时，server_name 查找可能成为瓶颈。启用 reuseport 让内核在连接建立阶段就分发到不同 worker，分散匹配负载。

• 在 listen 指令后加 reuseport：
  listen 80 reuseport;（需 Linux 内核 ≥ 3.9）
• 配合 worker_processes auto; 使用效果更佳
• 注意：该特性对 TLS 握手也有加速作用，但不改变 server_name 本身匹配逻辑