要让nginx快速匹配大量虚拟主机，关键在于优化server_names_hash_bucket_size和server_names_hash_max_size两个哈希表参数：前者需设为128或256以避免长域名溢出，后者建议设为4096及以上以支撑数千域名，二者均需置于http块顶部并配合nginx -t验证。
要让 Nginx 快速匹配大量虚拟主机（尤其是成百上千甚至上万的 server_name），关键在于优化其内部用于域名查找的散列表（hash table）。默认配置在站点数量增多时容易出现哈希冲突，导致检索变慢、CPU 升高，甚至启动失败。高效配置的核心是两个指令：`server_names_hash_bucket_size` 和 `server_names_hash_max_size`。
明确散列表的作用与瓶颈
Nginx 启动时会把所有 server_name 值构建成哈希表，用以 O(1) 时间完成 Host 头匹配。但如果域名过长或数量过多，而散列表桶（bucket）太小或总容量不足，就会频繁发生哈希冲突——Nginx 被迫退化为线性遍历，性能断崖式下降。
设置合适的 bucket_size
该值决定每个哈希桶能容纳的字符长度上限。若域名含长泛解析名（如 ~^([a-z0-9\-]+)\.example\.com$）或带下划线的子域名，容易超出默认 32/64 字节限制，触发 “could not build the server_names_hash” 错误。
- 先观察错误日志：启动失败时提示 “hash bucket size … too small”，说明当前值不够
- 推荐起步值设为
128或256，尤其当域名平均长度超 20 字符时 - 不要盲目设过大（如 1024），会浪费内存且无收益；按需递增即可
扩大 hash 表整体容量
server_names_hash_max_size 控制整个散列表最多能存多少个条目（即不同 server_name 的总数）。默认 512 完全不够支撑数百虚拟主机。
- 若你有 2000 个独立域名，建议设为
4096（2 的幂次更利于哈希效率） - 阿里云百万级虚拟主机实践常用
8192～16384，配合动态 map 使用效果更稳 - 该值增大后，内存占用略升，但换来的是几乎零冲突的快速匹配
配套调整与验证方式
单独调这两个参数还不够，需同步检查并确保其他环节不拖后腿：
- 把它们放在
http{ }块顶部（全局生效），不能写在server{ }内 - 修改后必须执行
nginx -t验证语法，再nginx -s reload生效 - 用
nginx -V 2>&1 | grep -o 'server_names_hash.*'可确认实际加载值 - 结合
map指令做泛域名路由时，也要注意map自身的 hash 参数（如map_hash_bucket_size）
