应调大 server_names_hash_bucket_size 和 server_names_hash_max_size：取所有 server_name 最长长度，向上取最近2的幂并留余量（如47字符设64、近120设128），在http块顶层配置，配合max_size按需调整（如数百域名设2048），改后执行nginx -t验证。
遇到 Nginx 启动失败、reload 卡住或部分 server 块不生效，且错误日志里反复出现类似 server_names_hash_bucket_size may be increased 或 could not build the server_names_hash 的提示，基本可以锁定是散列表（hash table）桶大小不足导致的域名加载失败。
看错误日志确认是否为 hash 桶问题
这是最直接可靠的判断方式。启动或重载时检查 /var/log/nginx/error.log：
- 出现
server_names_hash_bucket_size may be increased→server_names_hash_bucket_size不够 - 出现
could not build the server_names_hash或hash bucket size too small→ 同样指向该参数，也可能是server_names_hash_max_size达到上限 - 报错中明确提到
map_hash或proxy_headers_hash→ 分别对应map指令或proxy_set_header场景，不是域名本身问题，但排查逻辑相似
查最长 server_name 长度来定 bucket_size
域名加载失败的核心原因是：Nginx 用哈希表存所有 server_name，每个桶有固定字节数；如果某个域名字符串（不含通配符、正则）长度超过桶容量，就放不进去。
- 用命令提取所有
server_name并找最长值：grep -oP 'server_name\s+\K[^;]+' /etc/nginx/nginx.conf | sed 's/^[[:space:]]*//; s/[[:space:]]*$//' | awk '{print length, $0}' | sort -nr | head -n1 - 假设最长是
app-v2.internal.api.company.example.com（共 42 字节），默认值 32 就不够；应向上取最近的 2 的幂并留余量 → 64 是合理选择 - 若最长达 110 字节，直接设为 128；接近 240，设 256 更稳妥
在 http 块中正确配置并验证
这两个参数必须写在 http{} 最外层，不能嵌套在 server 或 location 里，否则无效。
- 添加配置：
http {<br> server_names_hash_bucket_size 128;<br> server_names_hash_max_size 2048;<br> # 其他配置...<br>} -
server_names_hash_max_size控制哈希表最多容纳多少个域名项（不是字节数），默认 512；如果你定义了上百个server块，建议同步调大到 1024 或 2048 - 改完立刻执行
nginx -t，通过才代表配置被识别；失败则说明值仍不够或语法有误
排除干扰项，避免误判
不是所有“域名不生效”都源于 hash 桶。先快速排除常见混淆点：
- 确认不是 DNS 解析问题：用
curl -H "Host: your-domain.com" http://localhost绕过 DNS 直接测试 - 检查
server_name是否拼错、是否漏写分号、是否被注释掉 - 多个
server块监听同一端口时，确保没有重复或冲突的server_name（如同时写了example.com和*.example.com） - 若用了正则匹配（
~^...），注意它不参与哈希表构建，但会降低匹配效率，不引发上述报错
