Steps to troubleshoot new Nginx installation

Andrew asked:

I am setting up Nginx on a new server running Ubuntu 12.04. Here’s what I’ve done so far:

  1. Installed nginx:

    aptitude -y install nginx
  2. Removed the default vhost config:

    rm /etc/nginx/sites-enabled/*
  3. Added my own vhost config:

    mv myapp.conf /etc/nginx/sites-enabled/
  4. Started nginx:

    service nginx start

The vhost file looks something like this:

upstream unicorn_server {
  server unix:/tmp/APP_NAME.sock fail_timeout=0;

server {
  listen 80 default deferred;
  client_max_body_size 4G;
  server_name _;
  keepalive_timeout 5;
  access_log  /var/log/nginx/APP_NAME.access.log;

  root /var/www/APP_NAME/current/public;

  # auth

  try_files $uri/index.html $uri.html $uri @app;

  location @app {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    # proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://unicorn_server;

  error_page 500 502 503 504 /500.html;
  location = /500.html {
    root /var/www/APP_NAME/current/public;

I can confirm that Nginx is running:

service nginx status
 * nginx is running

However, I can’t seem to access it:

curl 123.456.789.0 # example IP
curl: (7) couldn't connect to host

I have not yet started the unicorn server, but that should not be a problem. I would expect to see a 502 error if Unicorn isn’t running. There is no output in the error or access logs. What steps should I take to troubleshoot the issue?

My answer:

The only thing really unusual about this configuration you’ve posted is the use of deferred in your listen directive.

It seems some web sites provide this in their sample configurations and “recommend” it but don’t actually explain what it does. (Which is not very much, unless it’s set on both ends, and if it isn’t, then things get really weird really fast, since this technically subtly breaks the TCP protocol.)

The absolute first thing I would do would be to remove this deferred option from your listen directive.

Even if this does not solve the problem, I would not put it back. If you want to investigate its supposed performance benefits later, you can do so in a carefully controlled test environment.

View the full question and any other answers on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.