当Nginx server_name域名总数超阈值或含大量通配符/正则时，必须调大server_names_hash_max_size以避免哈希构建失败；其最小值应取域名总数×1.5后向上取最近2的幂，且须同步设置server_names_hash_bucket_size≥最长域名字节数+1。

当 Nginx 托管大量静态站点（比如数百个子域名、泛域名或微前端独立部署站点）时，server_name 匹配效率会显著影响请求分发性能。核心瓶颈常出在 server_names_hash 哈希表构建失败或低效探测上，而 server_names_hash_max_size 是关键调优参数之一。

什么时候必须调大 server_names_hash_max_size

出现以下任一情况，说明当前值已不足：

• [emerg] could not build the server_names_hash, you should increase server_names_hash_max_size: 512
• [warn] could not build optimal server_names_hash, you should increase either server_names_hash_max_size: 512 or server_names_hash_bucket_size: 64
• 配置了 50+ 个 server 块，且每个含多个 server_name（如 www.a.com a.com *.a.com）
• 使用了大量通配符（*.example.com）或正则（~^.*\.test\..*$），Nginx 会为每个显式声明的 name 单独建哈希项

怎么算出合适的最小值

不是越大越好，而是要满足哈希表“不溢出、少冲突”的双重约束。推荐按实际域名总数估算下限：

• 统计所有 server 块中显式声明的 server_name 字符串总个数（不含注释和空行）
• 若总数为 N，取最小的 2 的幂 ≥ N × 1.5（留 50% 冲突余量）
• 例如：共 320 个域名 → 320 × 1.5 = 480 → 最近的 2 的幂是 512；若达 800 个，则选 1024 或 2048

必须同步调整 bucket_size 才有效

server_names_hash_max_size 单独调大无效，它只控制桶数量；真正决定能否存下长域名的是 server_names_hash_bucket_size：

• 该值需 ≥ 当前最长 server_name 字符串字节数 + 1（含结尾 \0）
• 常见错误：server_name api.v2.super-long-project-name.example.org; 共 47 字符 → 至少设为 64，默认 32 或 64 可能不够
• 生产环境建议统一设为 128，兼顾兼容性与内存开销

配置位置与验证方法

必须放在 http 块顶层，不能写在 server 或 location 内：

nginx.conf 示例：

http {<br>  server_names_hash_max_size 2048;<br>  server_names_hash_bucket_size 128;<br>  ...<br>}

修改后执行：nginx -t 验证语法，成功即表示哈希表可正常构建；再用 nginx -s reload 生效。观察日志不再报 [emerg] 或 [warn] 即为生效。