Is there a common nginx conf for Drupal 7 sites? I've taken a look at Perusio's drupal-with-nginx repository and while I think it's impressive how extensive it is, it may be a little too advanced for me at the moment, plus I have several Symfony2 based sites live on the server and I don't to start making significant changes until I fully understand the configurations.

So I found this on a blog and figured it might do the job. Are there any common pitfalls with serving drupal 7 over nginx? Also, if the same Drupal installation was to power more than one site, would the configuration be any different? 

server {
    server_name example.org;
    root /home/me/sites/example.org;

    index index.html index.htm index.php;

    access_log /var/log/nginx/example.org.access.log;
    error_log /var/log/nginx/example.org.error.log;

    location = /favicon.ico {
            log_not_found off;
            access_log off;
    }

    location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;
    }

    # For drush
    location = /backup {
            deny all;
    }

    # Prevent user from accessing settings.php directly
    location ~ ^/sites/[^/]+/settings.php$ {
            deny all;
    }

    ## Replicate the Apache &lt;FilesMatch&gt; directive of Drupal standard
    ## .htaccess. Disable access to any code files. Return a 404 to curtail
    ## information disclosure. Hide also the text files.
    location ~* ^(?:.+\.(?:htaccess|make|txt|log|engine|inc|info|install|module|profile|po|sh|.*sql|theme|tpl(?:\.php)?|xtmpl)|code-style\.pl|/Entries.*|/Repository|/Root|/Tag|/Template)$ {
            return 404;
    }

    location ~ \..*/.*\.php$ {
            return 403;
    }

    location / {
            # This is cool because no php is touched for static content
            try_files $uri @rewrite;
    }

    location @rewrite {
            # Some modules enforce no slash (/) at the end of the URL
            # Else this rewrite block wouldn't be needed (GlobalRedirect)
            #rewrite ^/(.*)$ /index.php?q=$1&amp;$args;
            rewrite ^ /index.php last;
    }

    # Use an SSH tunnel to access those pages. They shouldn't be visible to
    # external peeping eyes.
    location = /install.php {
            allow 127.0.0.1;
            deny all;
    }

    location = /update.php {
            allow 127.0.0.1;
            deny all;
    }

    location ~ \.php$ {
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            #NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_intercept_errors on;
            fastcgi_pass unix:/var/run/php5-cgi/php5.sock;
    }

    ## Drupal 7 generated image handling, i.e., imagecache in core. See:
    ## https://drupal.org/node/371374
    location ~* /sites/.*/files/styles/ {
            access_log off;
            expires 30d;
            try_files $uri @rewrite;
    }

    # Fighting with ImageCache? This little gem is amazing.
    location ~ ^/sites/.*/files/imagecache/ {
            try_files $uri @rewrite;
    }

    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
            expires max;
            log_not_found off;
    }
}
The main problem that Drupal 7 has with nginx is that Drupal is designed for Apache, and so many modules assume that Apache is installed (and you will always have a little blue entry on your "Status Report" that tells you that you can't use Upload Progress because mod_php isn't installed — annoying).

That being said, thanks to perusio and others, many modules have been created that deal more with nginx and tap into its functionality well. So far, I haven't run into any problem with nginx that would have been fixed by Apache, and nginx is far faster and has a much lighter footprint. This is shown by many benchmarks, but it's also my experience. It also has better integration with php5-fpm, which also outperforms mod_php.

As Drupal develops, it is becoming more backend agnostic. You can see this with 7's database abstraction layer that allows for more database backends, and so I assume that future releases will be designed with other web servers in mind.

So, there are no pitfalls that I've seen at all. You just have to pay a bit more attention to what some of the modules do, or at least what they say they do. If they mention .htaccess files, then make sure that you have corresponding entries in your nginx files that do the same thing. I haven't actually seen a case where nginx fails with a proper configuration.

Perusio's nginx configuration is absolutely amazing, but it takes quite a while to get through it all and understand it. You WILL need to customize it for yourself, and you might run into some problems that you'll need to fix if you use non-standard setups for things like imagecaching or advagg or some others. It also assumes that you're using more than one php-fpm pool. So you'll need to go through and pull out what isn't needed. But it is worth it to take the time to go through it all because you'll learn so much about how nginx works.

I've also ran into several errors with my nginx/drupal sites because I have a tendency to use php-fpm 5.4 or 5.5. The errors have nothing to do with nginx but with Drupal functions themselves as Drupal is just really finishing a transition to requiring php 5.3. If you look around the issue queues, however, you'll find several patches and other solutions to fix modules to work with newer versions of php.

At the end of the day, I would recommend that anyone who is starting with a fresh server use nginx instead of Apache. It's just better.