Nginx – Why is 14 characters the maximum length for the nginx server_name directive

configurationnginx

I have the following virtual host

server
{
  server_name abc.example.com;
  root /var/www/test/;
  index index.html;
}

When running nginx -s reload I get the following error:

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

Same happens for any server_name that has 15 or more characters.

If I set the server_name to ab.example.com (or any name under 15 characters) the problem stops manifesting.

To fix this I added the following to /etc/nginx/nginx.conf (it wasn't defined before):

server_names_hash_bucket_size 64;

Setting it to 33 worked as well, but not 32.

Why is the default maximum length 14 characters for server_name?

Is this limit imposed by nginx's default settings or by the system it runs on?

How does a server_name of 15 affect the maximum hash bucket size? (there are only 4 virtual hosts defined on the system)

Best Answer

This error occurs when the server_name is too large to fit in the hash bucket.

The default for server_names_hash_bucket_size is chosen depending on the CPU cache line size of the server. In particular it's meant to be as small as possible, to reduce CPU cache misses, as server_names must be looked up on every request.

As for why you're limited to 14 characters instead of the expected 31, I suspect one of two possibilities:

Your configuration file is in UTF-16 encoding (or some other encoding) instead of UTF-8, which causes nulls to appear before or after every character in the raw data, and doubling its size. This might happen if you edit the file on Windows. If this is the case, use something like iconv to fix it.
You've run into an unknown bug in nginx.

Related Solutions

Nginx – can’t access nginx server from IP

Nginx will try to find a suitable virtual host by matching the hostname. If no match is found, it will either use the first defined one, or the one called default. To define a default virtual host, use

server {
   # The default/fallback server must have 'default' in the listen line:
   listen       80 default; 

   # Catch all non-matching requests
   server_name _; 
   access_log  /var/log/nginx/localhost.access.log;

   location / {
        root   /var/www/nginx-default;
        index  index.html index.htm;
   }

   #etc ...

}

Nginx – need Nginx and something like Gunicorn

Overly simplified: You need something that executes Python but Python isn't the best at handling all types of requests.

[disclaimer: I'm a Gunicorn developer]

Less simplified: Regardless of what app server you use (Gunicorn, mod_wsgi, mod_uwsgi, cherrypy) any sort of non-trivial deployment will have something upstream that will handle the requests that your Django app should not be handling. Trivial examples of such requests are serving static assets (images/css/js).

This results in two first tiers of the classic "three tier architecture". Ie, the webserver (Nginx in your case) will handle many requests for images and static resources. Requests that need to be dynamically generated will then be passed on to the application server (Gunicorn in your example). (As an aside, the third of the three tiers is the database)

Historically speaking, each of these tiers would be hosted on separate machines (and there would most likely be multiple machines in the first two tiers, ie: 5 web servers dispatch requests to two app servers which in turn query a single database).

In the modern era we now have applications of all shapes and sizes. Not every weekend project or small business site actually needs the horsepower of multiple machines and will run quite happily on a single box. This has spawned new entries into the array of hosting solutions. Some solutions will marry the app server to the web server (Apache httpd + mod_wsgi, Nginx + mod_uwsgi, etc). And its not at all uncommon to host the database on the same machine as one of these web/app server combinations.

Now in the case of Gunicorn, we made a specific decision (copying from Ruby's Unicorn) to keep things separate from Nginx while relying on Nginx's proxying behavior. Specifically, if we can assume that Gunicorn will never read connections directly from the internet, then we don't have to worry about clients that are slow. This means that the processing model for Gunicorn is embarrassingly simple.

The separation also allows Gunicorn to be written in pure Python which minimizes the cost of development while not significantly impacting performance. It also allows users the ability to use other proxies (assuming they buffer correctly).

As to your second question about what actually handles the HTTP request, the simple answer is Gunicorn. The complete answer is both Nginx and Gunicorn handle the request. Basically, Nginx will receive the request and if it's a dynamic request (generally based on URL patterns) then it will give that request to Gunicorn, which will process it, and then return a response to Nginx which then forwards the response back to the original client.

So in closing, yes. You need both Nginx and Gunicorn (or something similar) for a proper Django deployment. If you're specifically looking to host Django with Nginx, then I would investigate Gunicorn, mod_uwsgi, and maybe CherryPy as candidates for the Django side of things.

Best Answer

Related Solutions

Nginx – can’t access nginx server from IP

Nginx – need Nginx and something like Gunicorn

Related Topic