nginx [emerg] could not build the server_names_hash, you should increase server_names_hash_bucket_size

What’s actually happening

nginx -t fails, or a reload/restart bails out, and the whole service stays down — including every other site on the box. It almost always appears right after you add a new vhost with a long domain or a big list of server_name aliases. The number at the end (32 or 64) is the current bucket size, not the size you need. Nothing serves until the config parses.

Common causes

• A single server_name longer than the default 32-byte bucket — long subdomains or punycode/IDN domains (xn--...) overflow easily.
• Many server_name aliases on one server block, pushing the combined hash past the bucket.
• Default server_names_hash_bucket_size left unset on a platform where it defaults to 32.
• A wildcard plus several explicit names in the same directive, increasing hash pressure.

How to fix it

1. Set server_names_hash_bucket_size in the http blockEdit nginx.conf and inside http { } add server_names_hash_bucket_size 64; (or 128 if 64 still errors). It must be a power of two and a multiple of the CPU cache line — 64 and 128 are the safe values. Don't put it in a server block; it belongs in http.
2. Validate before reloadingRun nginx -t. It either prints "syntax is ok / test is successful" or the same emerg with a bigger required number. Only once -t passes should you systemctl reload nginx. Reloading on a broken config can leave you with no running master.
3. If 128 still fails, raise server_names_hash_max_size tooWith hundreds of vhosts the issue is total table size, not bucket width. Add server_names_hash_max_size 1024; (or higher) alongside the bucket setting. Bucket size handles long individual names; max_size handles having a lot of them.
4. Trim redundant aliasesIf one block lists a dozen near-identical names, consider a wildcard (*.example.com) or splitting into separate server blocks. Fewer/shorter names mean the default hash would've been fine — worth doing if the list grew by accident.