应配置 server_names_hash_max_size 和 server_names_hash_bucket_size：前者设为不小于域名总数的2的幂（如1024/2048），后者按最长域名字节向上取最近2的幂（如128/256），二者均需置于http块顶层且满足 max_size ≥ bucket_size。
要提升海量虚拟主机（server_name）的路由检索速度，关键不是调 types_hash_max_size 或 map_hash_max_size，而是正确配置 server_names_hash_max_size 和 server_names_hash_bucket_size 这两个专用于域名匹配的哈希参数。
为什么 server_name 匹配会变慢？
Nginx 启动时会把所有 server_name 指令声明的域名构建成哈希表，用于快速查找匹配的 server 块。当域名数量多、名称长（如含端口、泛域名、国际化域名），或哈希桶太小导致冲突严重时，原本 O(1) 的查找就会退化为链表遍历，拖慢请求接入速度——尤其在万级域名或高并发场景下可被观测到。
怎么判断是否需要调参？
- 启动 Nginx 时报错：
could not build the server_names_hash, you should increase server_names_hash_bucket_size或server_names_hash_max_size overflow - 配置中显式定义了数百个
server_name（含通配符、正则、带端口的域名等） - 使用了大量子域名服务（如 SaaS 多租户：tenant1.example.com、tenant2.example.com…）
- nginx -t 验证失败，且错误指向 server_names_hash 构建失败
怎么设才合理？
两个参数必须协同设置，且都放在 http{} 块顶层：
-
server_names_hash_bucket_size：单个桶能容纳的最长域名长度（单位：字节）。默认 64，若最长域名（如
api.internal.prod-us-west-2.my-company-platform-v2.example.com）超长，就设为 128 或 256 —— 必须是 2 的幂 - server_names_hash_max_size：哈希表最多允许多少个桶。它不等于域名总数，而是影响冲突率的关键。默认 512，若你有 800+ 个唯一生效域名，建议设为 1024 或 2048；若达 3000+，可设为 4096
- 二者需满足：
server_names_hash_max_size ≥ server_names_hash_bucket_size，否则启动失败
配套动作不能少
光调哈希参数不够，还需：
- 精简冗余
server_name：删除重复、未使用的域名，合并泛域名（*.example.com比逐条写更高效） - 避免过度使用正则域名（
~^www\d+\.example\.com$）：正则匹配不走哈希表，而是运行时逐条比对，性能开销大 - 启用
listen 80 reuseport（Linux 3.9+）：让多个 worker 进程各自监听同一端口，减少 accept 锁争用，配合哈希优化效果更明显 - 确认系统 ulimit -n 足够：每个 server 块可能占用文件描述符，海量虚拟主机需同步提高限制
