Take the 2-minute tour ×
Drupal Answers is a question and answer site for Drupal developers and administrators. It's 100% free, no registration required.

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 <FilesMatch> 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&$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;
    }
}
share|improve this question
    
no pitfalls that i'm aware of. That nginx configuration is already treating each /sites/*/ multisite directory discretely ... –  tenken Jan 10 '13 at 21:10
    
@tenken nice. I'll certainly try it out. Most of the configurations I found on the net were assuming that nginx was not installed or no sites have been already configured, which is why I'm a little cautious. Thanks –  Adam-E Jan 12 '13 at 16:15

3 Answers 3

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.

share|improve this answer

I've read that Nginx can't do everything, it's limited compared with Apache. "Apache has a module for every task". In my short experience I've been using Nginx for a couple of months with Drupal and everything works fine. If you are using a multisite install for Drupal and Nginx you can set multiple server names on the same server config, but you will not be able to have different logs for each site. I use this config without (almost) any problem: http://wiki.nginx.org/Drupal

share|improve this answer
    
Apache is like Microsoft Word, it has a million options but you only need six. Nginx does those six things, and it does five of them 50 times faster than Apache. — Chris Lea on nginx and Wordpress –  SGhosh May 27 '13 at 10:28

I completely agree with you that Perusio's nginx configuration for Drupal is impressive, but perhaps overkill for a local instance of nginx. I have found Mulkave's nginx configuration file on GitHub to be the most practical, lightweight configuration for running Drupal 7 on nginx.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.