Posts Tagged ‘Nginx’

Mimic Apache mod_geoip in Nginx

November 12th, 2010

Maxmind makes a variety of APIs and tools to use their geolocation database and one such tool is the mod_geoip module for Apache. Using the GeoIP module at the apache level means that PHP can access the visitor’s country code simply by means of an environment variable such as this:


To setup Nginx with this capability we’ll need to recompile Nginx if you have not already used the –with-http_geoip_module compile option.

First we’ll need to install the GeoIP API system-wide:

CentOS (yum)

yum install GeoIP-devel

Debian/Ubuntu (aptitude)

apt-get install libgeoip-dev

Mac OS X 10.5+ (via HomeBrew)

brew install geoip
sudo brew link geoip

Once you have the GeoIP library installed you can then proceed to recompile Nginx, this is rather simple if you have installed Nginx from source (this assumes you already have the nginx source unpacked somewhere):

$ cd src/nginx-0.8.53
$ nginx -V 
nginx version: nginx/0.8.53
built by gcc 4.4.4 (Debian 4.4.4-6) 
TLS SNI support enabled
configure arguments: --prefix=/opt --with-pcre=/root/src/pcre-8.02 --with-md5=/usr/lib 
--with-sha1=/usr/lib --with-http_ssl_module --with-http_realip_module --with-http_gzip_static_module 
--with-openssl=/root/src/openssl-1.0.0a/ --without-mail_pop3_module
 --without-mail_imap_module --without-mail_smtp_module
$ ./configure --prefix=/opt --with-pcre=/root/src/pcre-8.02 --with-md5=/usr/lib --with-sha1=/usr/lib \
--with-http_ssl_module --with-http_realip_module --with-http_gzip_static_module \
--with-openssl=/root/src/openssl-1.0.0a/ --without-mail_pop3_module \
--without-mail_imap_module --without-mail_smtp_module --with-http_geoip_module
$ make && sudo make install
$ /etc/init.d/nginx restart

We’ll want to download the Maxmind Geolite Country Database some place Nginx can use it.

$ cd /opt/conf
$ wget
$ gunzip ./GeoIP.dat.gz

Then we need to tell Nginx where to find that file, so in your nginx.conf add this in your http { } block:

geoip_country  /opt/conf/GeoIP.dat;
#geoip_city     /opt/conf/GeoLiteCity.dat;
#Uncomment the above if you also wish to lookup cities

Once that is done you can restart Nginx, you’ll be able to use variables such as $geoip_country_code to obtain the visitor’s country code. Full details of this module can be found at HttpGeoIPModule.

We’re not done yet, now we need to make it so that PHP see’s these results in the same fashion it would with the apache module. In your fastcgi_params or where ever you are passing fastcgi_param values to PHP you’ll wish to add at least these two lines:

	fastcgi_param GEOIP_COUNTRY_CODE $geoip_country_code; 
	fastcgi_param GEOIP_COUNTRY_NAME $geoip_country_name;

Once that is done, restart Nginx. Now you’ll be able to access the visitor’s country code in PHP via $_SERVER[‘GEOIP_COUNTRY_CODE].

You can instead use the module to redirect visitors straight from nginx in the following fashion:

    server {
	root /opt/html/;
        location / {
                try_files /index_$geoip_country_code.html index.html;

If a visitor from Russia visits your site it will try to load index_RU.html, and if that is not found will fall back to index.html, likewise if you created a index_US.html a visitor from the United States will see that page’s content.

Nginx as a Proxy to your Blog

July 23rd, 2010

Some time ago, back when Google Biz Ops were really popular I’ve had quite a number of clients use this method of changing the IP address of their auto-blogs. I once had a server hosted by ServerPronto*. The server was physically located in Panama (despite being advertised as a US hosting provider), the IPs were cheap though.

The Idea

The client had a good number of auto-blogs, landing pages and so forth on the same hosting provider (in this case his own dedicated server with multiple non-class-c IPs). The problem was making one or more of those domains appear not to be on the same server, or datacenter in this case. The solution was to use various class-c and class-b IPs on my own server, and use Nginx to proxy any web request to his own existing websites thus making those sites appear on a server in Panama as opposed to their actual location. The same could work if you wanted to use US IPs on a cheap provider and proxy to an off shore provider with cheaper hardware.

The Solution

For this we’ll need a Dedicated server or VPS to host Nginx on. (I’ll have an article later on how to install Nginx from scratch). You’ll probably want a couple extra IPs on hand, in case you want to proxy multiple sites of the same niche.

For every hostname you wish to proxy you’ll need a server block similar to this in your nginx configuration.

server { 
	#Turns access log off
	access_log off;
	#Set this to the IP on the nginx server you want to represent this proxy
	listen nginx-ip-here:80;
	#Matches the requested hostname
	location / {
		# Tells the destination server the IP of the visitor (some take X-Real-IP, 
		# some take X-Forwarded-For as their header of choice
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $remote_addr;
		# Tells the destination server which hostname you want
		proxy_set_header Host $host;
		# Performs a Proxy Pass to that server
		proxy_pass http://ip-address-of-your-server;

From here you would point your domain name to the Nginx server. If your domain currently uses your existing hosting’s nameservers, the easiest way to change this would be to use your registrar’s DNS such as namecheap or godaddy (via total domain control), or a free DNS provider such as In any of those you would simply change the A record of your domain name to the IP address of the Nginx server.

Once that is setup any request on port 80 (standard http port) will be proxied to the server actually hosting the website or blog.

The Problems

A couple of downsides may exist with this method.

Control panel access via your domain name
When you point your domain to the Nginx IP, you not only direct web traffic there, but all other forms of traffic such as SSH, Cpanel/whm, FTP, and so forth. While you can in theory forward via iptables and other methods for those additional ports, it would be difficult and not without problems. So to get around this you’ll either want to access SSH, Cpanel/DirectAdmin, FTP, and so forth via your actual server’s IP address, or use a non-proxied domain. You can use any of your other domains on the same server especially if using a control panel, since the login is what determines which account you need access to, not the domain itself.

Email access of course will cease if you don’t setup Nginx as mail proxy to that specific domain name. Though the work around would be to add an A record for in the DNS settings, and then change your MX records to point to Course the better alternative if you must have email at that domain would be to use google apps, that way a simple whois or DNS lookup won’t reveal your actual server’s IP address. The best alternative is to simply not use email at proxied domains.

Normally a visitor takes their provided route from their location directly to your server over whatever backbone connects them. But with a proxied domain the visitor is then sent to the nginx server where ever it may be, and then the time is increased by how long it takes for the nginx server to communicate with your own webserver and then back. If the latency between the Nginx server and your destination is short, then the speed difference to visitors may not even be noticeable.

Security Concerns
Some of you no doubt are looking at this configuration and wondering if it could be changed so you don’t have to make a server block for each hostname you have. While it is possible to make server_name and the proxy_pass destination dynamic to the requested hostname, this is a very bad idea. Doing so will allow not only your own domains to be proxied but any domain pointed to your nginx server. This can result in abuse or even bandwidth overload.

For example, don’t do this:

server { 
	access_log off;
	listen nginx-ip-here:80;
	location / {
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $remote_addr;
		proxy_set_header Host $host;
		proxy_pass http://$host;

While it may be easy for you, it opens your server up for a floodgate of abuse using your server as some kind of public proxy point. Instead to tighten security of the nginx box, we should deny (or redirect) any traffic to the nginx server that either does not provide a host name, or does not provide one that has been defined. You can do so like this:

    server {
	#visits not supplying hostname
	server_name _;
	location / { return 444; }

The return 444, sends a forbidden error back to the browser.

* ServerPronto: While I did use them at one point of time for the proxy purpose, I would not recommend them for a hosting provider or dedi reseller.

Apache to Nginx Migration Tips

April 11th, 2010

For a simple beginning example configuration to start with please view my example configuration

Nginx currently holds shy of 6.5% of the known webserver market, which is just roughly shy of 13 million servers. This little lightweight webserver created by a sole Russian developer has been gaining a great deal of popularity over the last few years and is used by sites such as WordPress, Texts from Last Night and Hulu.

This guide will show you common examples in Nginx to make migration from Apache a bit easier.

HTTP Basic Authentication or htpasswd support

If you have been playing with nginx for a the first time you may have noticed that there is no .htaccess support. However Nginx can still utilize HTTP Basic Authenication with existing htpasswd files using the HTTP Auth Basic Module. The module is compiled by default.

If you still have Apache installed (but perhaps turned off or on a different port) you can still use htpasswd to generate a password file. But in the event that you don’t have or don’t want to install Apache you can use Perl or Ruby to generate at least the encrypted passwords. The .htpasswd files should be in the following format.


To generate a password with Ruby in irb:


Likewise to generate with perl from the terminal:

perl -le 'print crypt("your-password", "salt-hash")'

The two commands above will utilize a 56-bit DES encryption which can be used in the htpasswd file.

Once you have your password file saved, store it outside of the web-accessible location like you would have when using Apache (likewise you can ensure that web access to hidden files are denied, more on that later).

Lets say you have a subfolder on your server called ‘admin’ and you wish to protect it. Here is an example configuration:

location  /admin  {
  auth_basic            "Admin Access";
  auth_basic_user_file  conf/;

If the above did not work, check your error logs as sometimes it will notify you if the path to the password file could not be found.

Ignoring robots.txt, favicon.ico and hidden files

Sometimes you may wish to omit commonly accessed files from being recorded in the access log as well as block access to hidden files (filenames beginning with a period such as .htpasswd and .htaccess). Even though nginx doesn’t support htaccess, you may still wish to secure files left behind from the migration. You can easily do this by adding a couple location blocks to your domain’s server block.

location = /favicon.ico { access_log off; log_not_found off; }	
location = /robots.txt { access_log off; log_not_found off; }
location ~ /\. { deny  all; access_log off; log_not_found off; }

The above will not record access to the favicon.ico or robots.txt in the root of your site, as well as ignore the file-not-found error if you do not have either file present. Also the last line will deny access to any file beginning with a period anywhere within the root path. You can actually save the above into a file such as /conf/drop.conf, and include it at the bottom of each of your server blocks like so.

include drop.conf;

Extremely Easy WordPress Migration

Most people now days take advantage of WordPress’ permalink feature which normally requires mod_rewrite enabled in the .htaccess file. However as of Nginx 0.7.26 and above this can be taken care of very easily with a single directive.

location / { 
   try_files $uri $uri/ index.php;

The above will attempt to try the requested URI first as a file, then as a folder, and if both of those come back negative it will fall back to index.php. WordPress can simply parse the request URI sent by the webserver so there is no need to manually add arguments onto index.php. If you instead need to do something further you can change the fallback from index.php to @fallback like so:

location / {
   try_files $uri $uri/ @wordpress;
location @wordpress {
     # Additional rewrite rules or such you need here.

For Nginx versions older than 0.7.26 you can use the older method shown below (however its strongly advised to have 0.7.26 or newer).

location / { 
        if (-f $request_filename) {
            expires 30d;
        #Ultimately 'if' should only be used in the context of rewrite/return :
         if (!-e $request_filename) {
            rewrite ^(.+)$ /index.php?q=$1 last;

The two if blocks replace the common RewriteCond used by wordpress to test if the requested filename is an existing file or folder.

On the next page: Utilizing WP Super Cache, rewrite examples and more.

My Nginx Configuration

March 14th, 2010

I’m creating this page on popular request, as I’ve had to paste my configuration for people a number of times especially on IRC. Below is an example configuration of how is setup with some comments.

My primary nginx.conf file located in /conf

# Normally you don't want to run a webserver as root
# so you set www-data (debian/ubuntu) or nobody (centos/rhel)
# you'll want to make sure your web root is owned by www-data group
user www-data;
# 4 worker processes is usually sufficient for a webserver serving
# both static files and passing dynamic requests back to apache, fastcgi or an app server
worker_processes     4;
# normally you leave this at the default of 1024
events {
    worker_connections  1024;
http {
    # General Settings
    gzip  on;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay off;
    server_tokens off;
    include mime.types;
    keepalive_timeout 5;
    default_type  application/octet-stream;
    # If we set index here, we won't have to anywhere else
    index index.php index.html index.htm;
    # I prefer nginx to show the errors than "No Input Files Specified"
    # If you're using wordpress you want to turn this off so Wordpress
    # Shows the error. You can turn it off at the server or location level.
    # ONLY works if the server block has error pages defined for 4xx/5xx
    fastcgi_intercept_errors on;
    # We don't want someone to visit a default site via IP
    # So we catch all non-defined Hosts or blank hosts here
    # the default listen will cause this server block to be used
    # when no matching hostname can be found in other server blocks
    server {
	# use default instead for nginx 0.7.x, default_server for 0.8.x+
	listen 80 default_server;
	# if no listen is specified, all IPv4 interfaces on port 80 are listened to
	# to listen on both IPv4 and IPv6 as well, listen [::] and must be specified. 
	server_name _;
	return 444; 
    include sites-enabled/*;

A site configuration located inside the /conf/sites_enabled folder

# Wordpress Example
server {
	# The usual names, starting with the base, then www., subdomains or *. wild cards.
	# Keep a root path in the server level, this will help automatically fill
	# Information for stuff like FastCGI Parameters
	root html/;
	# You can set access and error logs at http, server and location level
	# Likewise means you turn them off at specific locations
	access_log logs/kbeezie.access.log;
	error_log logs/kbeezie.error.log;
	# For my wordpress configuration, I prefer try_files
	# It will try for static file, folder, then falls back to index.php
	# The wordpress index.php is capable of parsing the URI automatically
	location / { try_files $uri $uri/ /index.php; }
	# Where I turned off intercept errors for WordPress
	fastcgi_intercept_errors off;
	# Includes my PHP location block and parameters
	include php;
	# My all in one settings to hide stuff like .invisible files
	# or turn off access/error logs to favicon/robots.txt
	include drop;
# Proxy_Pass example (backend server, or in my case Python App)
# For Python WSGI or Ruby/Rails you can check out 
server {
	# You can choose to turn remove this if you wish to
	# See requested URIs
	access_log off;
	# If your application returns any erorrs it can be logged by nginx
	# However if the application fails, or is not stated you'll see
	error_log logs/python.error.log;
	# I usually run my apps from base domains or subdomains rather than
	# folders, though it is possible. 
	# a root definition where you can store static files
	# if not served by the application
	root html/python-static/;
	# Since we have a static root defined, we can check
	# for static files there, otherwise goes to the backend
	location / { try_files $uri $uri/ @backend; }
	# The backend for either backend servers or apps
	location @backend {
		# Lets the app/backend know the visitor's IP
		# otherwise shows
		proxy_set_header X-Real-IP  $remote_addr;
		proxy_set_header X-Forwarded-For $remote_addr;
		# Some app servers need to be made aware of the hostname
		proxy_set_header Host $host;
		# example on how to connect to a unix socket
		proxy_pass	http://unix:/opt/apps/ipn/ipn.sock:/;
		# Example via TCP location of the backend server
		# proxy_pass;
	# you could copy drop into drop_deny to outright deny favicon and robots.txt for apps
	include drop;

A single file called php located in the /conf folder, using this method makes it easy to enable
php on a per-server basis.

location ~ \.php {
	fastcgi_param  QUERY_STRING       $query_string;
	fastcgi_param  REQUEST_METHOD     $request_method;
	fastcgi_param  CONTENT_TYPE       $content_type;
	fastcgi_param  CONTENT_LENGTH     $content_length;
	fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
	fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
	fastcgi_param  REQUEST_URI        $request_uri;
	fastcgi_param  DOCUMENT_URI       $document_uri;
	fastcgi_param  DOCUMENT_ROOT      $document_root;
	fastcgi_param  SERVER_PROTOCOL    $server_protocol;
	fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
	fastcgi_param  SERVER_SOFTWARE    nginx;
	fastcgi_param  REMOTE_ADDR        $remote_addr;
	fastcgi_param  REMOTE_PORT        $remote_port;
	fastcgi_param  SERVER_ADDR        $server_addr;
	fastcgi_param  SERVER_PORT        $server_port;
	fastcgi_param  SERVER_NAME        $server_name;
	# I use a socket for php, tends to be faster
	# for TCP just use
	fastcgi_pass   unix:/opt/php-fpm.sock;
	# Not normally needed for wordpress since you are
	# sending everything to index.php in try_files
	# this tells it to use index.php when the url
	# ends in a trailing slash such as
	fastcgi_index  index.php;

A file called drop in the /conf folder, including this into your server configuration will drop/block
common files you do not wish to be exposed to the web.

# Most sites won't have configured favicon or robots.txt
# and since its always grabbed, turn it off in access log
# and turn off it's not-found error in the error log
location = /favicon.ico { access_log off; log_not_found off; }	
location = /robots.txt { access_log off; log_not_found off; }
# Rather than just denying .ht* in the config, why not deny
# access to all .invisible files 
location ~ /\. { deny  all; access_log off; log_not_found off; }

Further comments will be appended here.

Releasing IP Addresses in WHM/Cpanel

December 28th, 2009

If you are hosted with a WHM/Cpanel based server or VPS, you may have had some difficulties trying to get an alternate webserver such as Nginx or Lighttpd installed especially if you wanted to use the default port 80. This article shows you how you can release extra IP addresses to be used by those services without conflicting with Apache.

There are two areas wee need to address, Apache, and then WHM/Cpanel.


By default Apache listens to every interface coming into the machine by listening to Normally you could edit the httpd.conf file directly in order to change the listen line, however that may cause problems with Cpanel’s automation.

To acheive this more safely, log into Webhost Manager (typically and find Service Configuration followed by Apache Configuration. Then click on Reserved IPs Editor.

Here you will need to check the boxes of the IP addresses you do NOT wish for Apache to use. Once you save your selections, a new configuration file will be configured to listen on all the other IPs that were not checked. This will allow other services such as alternate webbrowsers to listen on those IP addresses without conflicting with Apache.

Webhost Manager

We freed some IP addresses from Apache, but now we have to make sure that WHM/Cpanel doesn’t attempt to use those same IP addresses for other services.

Navigate to IP Functions, followed by Show/Edit Reserved IPs. Here you should check the same IPs that were selected in the Apache Reserve list above. Once this is done WHM/Cpanel will avoid using those IP address when setting up new accounts and services.

Configuring Nginx
Assuming Nginx is already configured you will need to make a minor adjustment to the server blocks in order to start it up.

server {
	listen an-ip-address:80;

Normally you would just have the port number identified, but if you tried to start it as just that, it would conflict with Apache if already running (otherwise vice-versa). So we need to make sure to bind each server block to an available IP address.

While I personally prefer to run Nginx standalone on it’s own server such as the one is running off of. Some may wish to use the benefits of Nginx for certain projects while still having the ease of use of Cpanel for other sites.

On a side note, if PHP is setup as a Fast-CGI executable in WHM you can share the same PHP instance with Nginx or Lighttpd, otherwise you’ll need to make sure to either compile a separate instance of PHP, or launch the fast-cgi daemon manually for the existing installation (spawn-fcgi, php-fpm, etc).

Configuring SNI with NginX

December 28th, 2009

Traditionally for every SSL certificate issued, you needed a separate and unique IP address. However if you compile OpenSSL and NginX with TLS SNI (Server Name Identification) support you can install multiple SSL certificates without having to bind a domain name to a specific IP address or require each certificate to have its own unique IP.

First thing we need to do is actually compile OpenSSL with TLS SNI support. We’ll start by downloading the latest source and unpacking it into a temporary directory. For this article I keep all sources in ~/src.

$ cd ~/src
$ wget
$ tar zxvf ./openssl-0.9.8l.tar.gz
$ cd ./openssl-0.9.8l

We’ll then configure with TLS support:

$ ./config enable-tlsext
$ make
$ make install
$ cd ..

Assuming the Nginx source also resides in ~/src you can add the following option to your configure statement when compiling Nginx from source (you can also instead use an absolute path such as /root/src/openssl-0.9.8l/).


Once compiled and installed you can check to see if TLS SNI is enabled:

[root@host src]# nginx -V
nginx version: nginx/0.8.31
built by gcc 4.1.2 20080704 (Red Hat 4.1.2-46)
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx 
--pid-path=/usr/local/nginx/logs/ --sbin-path=/usr/local/sbin/nginx 
--with-md5=/usr/lib --with-sha1=/usr/lib --with-http_ssl_module 
--with-http_realip_module --with-http_gzip_static_module 

From there you will no longer be required to have an SSL enabled server block on it’s own unique IP. You won’t even have to have the block listening to a specific IP either since now OpenSSL will handle the certificate validation based on the server name.

Path_Info & PHP_SELF woes [NginX]

December 12th, 2009

3/31/2011 This has been updated to reflect a better configuration to be used with Nginx 0.8/0.9.

Over the last couple of years I’ve been constantly researching for a way to get the PHP environment variables to show up correctly. My latest pains were with PATH_INFO and PHP_SELF, which are now finally solved.

My current configuration are PHP-FPM (5.2.10) and NginX (0.8.29) on a CentOS 5.4 x64 VPS. (As of 2011, I’m now using PHP 5.3.6, Nginx 0.9.6 and FreeBSD 8.2)

Traditionally you would use a PHP configuration such as this:

	server {
		location / {
			root html/default;
		location ~ \.php$ {
			include fastcgi_params;
			fastcgi_param  SCRIPT_FILENAME  /usr/local/nginx/html/default$fastcgi_script_name;

Within fastcgi_params would be something like this:

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;
fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;
fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;
# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

While the above method may seem to work at first, you’ll quickly notice problems when it comes to using $_SERVER[‘PATH_INFO’] and $_PATH[‘PATH_TRANSLATED’], and often enough $_SERVER[‘PHP_SELF’] ends up being set incorrectly when you try to adjust for the two environment variables.

Here is a setup I’ve come to prefer, especially when it comes to having multiple virtual hosts that use PHP. Notable tips are commented below the line.

Simple Nginx configuration file with a single virtual host

worker_processes  1;
pid        logs/;
events { worker_connections  1024; }
http {
	include       mime.types;
	default_type  application/octet-stream;
	sendfile        on;
	keepalive_timeout  65;
	index index.html index.htm index.php;
	# Identical to Apache's DirectoryIndex, setting it in
	# the http block set it as a default for all server blocks within
	server {
		listen	80; 
		# since port 80 is set by default, you do not actually need
		# to set this, unless of course you are binding to a specific
		# address such as listen server-ip-address:80 or alternate port; 
		root   html/;
		# You will want to set your root here, since otherwise
		# $document_root within the php block will not work
		# if you set it in the location block you would also have 
		# to set the php block within that location as well
		location / {
			# This would replace the typical mod_rewrite rules for wordpress
			# it can also be try_files $uri $uri/ @rewrites; where it goes to a 
			# location @rewrites { ... } where you can place rewrite rules if a file
			# or folder is not found.
			try_files $uri $uri/ /index.php;
		location = /favicon.ico { access_log off; log_not_found off; }
		# If you haven't created a favicon for your site, you can keep
		# your access and error logs clean by turning off the logs
		# when a browser requests the fav icon (its also a good way
		# to keep your logs from filling with useless information)
		location ~ /\. { access_log off; log_not_found off; deny all; }
		# You want to make sure that Nginx does not serve any .hidden files
		include php.conf;
		# I prefer to keep my php settings in one file, so I can simply
		# paste this single line for each of my virtual hosts

Now the php.conf file (which I’ve created in the /conf folder with nginx.conf)

fastcgi_intercept_errors on;
# this will allow Nginx to intercept 4xx/5xx error codes
# Nginx will only intercept if there are error page rules defined
# -- This is better placed in the http {} block as a default
# -- so that in the case of wordpress, you can turn it off specifically
# -- in that virtual host's server block
location ~ \.php {
	fastcgi_split_path_info ^(.+\.php)(/.+)$;
	# A handy function that became available in 0.7.31 that breaks down 
	# The path information based on the provided regex expression
	# This is handy for requests such as file.php/some/paths/here/ 
	fastcgi_param  PATH_INFO          $fastcgi_path_info;
	fastcgi_param  PATH_TRANSLATED    $document_root$fastcgi_path_info;
        fastcgi_param  QUERY_STRING       $query_string;
        fastcgi_param  REQUEST_METHOD     $request_method;
        fastcgi_param  CONTENT_TYPE       $content_type;
        fastcgi_param  CONTENT_LENGTH     $content_length;
        fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
        fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
        fastcgi_param  REQUEST_URI        $request_uri;
        fastcgi_param  DOCUMENT_URI       $document_uri;
        fastcgi_param  DOCUMENT_ROOT      $document_root;
        fastcgi_param  SERVER_PROTOCOL    $server_protocol;
        fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
        fastcgi_param  SERVER_SOFTWARE    nginx;
        fastcgi_param  REMOTE_ADDR        $remote_addr;
        fastcgi_param  REMOTE_PORT        $remote_port;
        fastcgi_param  SERVER_ADDR        $server_addr;
        fastcgi_param  SERVER_PORT        $server_port;
        fastcgi_param  SERVER_NAME        $server_name;
	fastcgi_index  index.php;

There you have it, PHP should now have correct environment variables. For example would render the following results:

$_SERVER["QUERY_STRING"] -> var=foo
$_SERVER["SCRIPT_NAME"] -> /php.php
$_SERVER["SCRIPT_FILENAME"] -> /usr/local/nginx/html/default/php.php
$_SERVER["REQUEST_URI"] -> /php.php/a/path/string/?var=foo
$_SERVER["DOCUMENT_URI"] -> /php.php/a/path/string/
$_SERVER["DOCUMENT_ROOT"] -> /usr/local/nginx/html/default
$_SERVER["PATH_INFO"] -> /a/path/string/
$_SERVER["PATH_TRANSLATED"] -> /usr/local/nginx/html/default/a/path/string
$_SERVER["PHP_SELF"] -> /php.php/a/path/string/

So there you have it. A simple php block that will correctly assign the path environment variables, without having to use multiple blocks and patterns. And quite easy to simply assign to a new virtual host by simply pasting the include php; line.

Using Namecheap’s Free SSL with Nginx

November 21st, 2009

Most of my domains are registered with Namecheap, and powered by Nginx. The site you are viewing now is one such example. Currently with Namecheap, domain registrations, hosting, transfers and WhoIS protection come with a free PositiveSSL subscription (course even if they eventually stop that special, 9.95/year is still a good price for a PositiveSSL certificate). This section will show you how to generate a certificate request with OpenSSL and how to install the provided certificate into Nginx.

Most hosting providers that allow you to install a SSL certificate will normally be using a Cpanel/WHM setup with the Apache Webserver. In which case SSL installation can be quite and visually straight forward, as its pretty much cut and paste back an forth. While you don’t get this luxery with Nginx, its not that difficult to configure.

What you will need on the server:

A unique IP address. The domain you are getting the certificate for does not have the be the only domain served on the chosen IP address. However Nginx will only serve one certificate per IP. An attempt to install two certificates on the same IP will result in the latter domain serving the previous domain’s certificate.

SSH access. Otherwise known as ‘shell access’, would be required to perform most of the tasks yourself. If you have installed Nginx onto a remote server yourself, then chances are you have shell access. Also if you’re running Nginx you’re not likely using shared hosting, which is normally void of shell access.

OpenSSL In order to actually generate a request and serve the certificate you will need OpenSSL installed. Using a repository such as yum on CentOS you can install this with the package openssl and openssl-devel (depending on the repository the package names could vary).

Nginx webserver configured with SSL. In order for Nginx to serve SSL certificates, Nginx must be built with the option –with-http_ssl_module. To verify you can run nginx -V from the terminal to see all the options your current release was built with. If you installed Nginx from a repository, you may need to see if there exists a SSL variation. is currently running on Nginx 1.0 and hosted by IonVz.

Assuming you have all the above in place, we can start by creating private key followed by the CSR file otherwise known as a Certificate Signing Request.

Nginx and Django

September 14th, 2009

In a previous guide I showed how to use Passenger (aka mod_rails) to work with Python (WSGI) scripts. While this proved effective for simple wsgi applications, a framework such as Django required a bit more love. This guide assume you already have everything installed from the previous guide, and that Python has already been configured with Django and other modules.

Aside from having the usual setup, you will need the original Django source files. One way of going about this is downloading the latest source from the Django Project. The next couple of steps assume you have nginx installed at the /usr/local/nginx/ location, and already have a src folder under your home folder.

# cd ~/src
# wget
# tar zxvf Django-1.1.tar.gz
# cd Django-1.1
# mv ./django /usr/local/nginx/html

I should note, my /html/ folder isn’t publicly accessible because all my sites are subfolders under that location. I use it primarily to store resources for the folders beneath it. You can change where you save the source, just remember where you put it and that the webserver has access to it.

Open up your nginx configuration where you have already setup a passenger app from the previous guide. Should look something like this.

server {
	root /usr/local/nginx/html/;
	passenger_enabled on;

The first thing you have to do to set this up for Django (at the very least), is to modify the server block above to something more like this:

server {
	location / {
		root /usr/local/nginx/html/;
		passenger_enabled on;
	location /media {
		alias /usr/local/nginx/html/django/contrib/admin/media;

Now you have either create or move your django application into the site folder. For example, if your site is defined as /usr/local/nginx/html/ like above, and your django application is called mytest , you will end up having it located in /usr/local/nginx/html/ In the end you should have a folder structure similar to this (based off the Django tutorials).

Directory Structure

Now open up the from the previous guide which may look something like this:

import sys
import os
def application(environ, start_response):
	start_response("200 OK", [])
	ret = ["%s: %s\n" % (key, value)
		for key, value in environ.iteritems()]
	return ret

We’re going to turn this into a WSGI initializer for the Django application like so:

import os, sys
#automatically finds application's current path
nginx_configuration= os.path.dirname(__file__)
project = os.path.dirname(nginx_configuration)
workspace = os.path.dirname(project)
os.environ['DJANGO_SETTINGS_MODULE'] = 'testapp.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

After saving, should restart the nginx server, then load up the site in a browser. If this is a new Django application you’ll be greeted with a “Welcome to Django” page, otherwise the application you had already created.

Static content can be access by creating additional Aliases in Nginx, or by using django.views.static.serve method in your applications url settings.

Using Python with Nginx via Passenger

September 14th, 2009

Since Nginx 0.6.* I been looking for an effective way to run Python (WSGI) applications thru the Nginx Webserver. A couple of options were available at the time:

Update 1/31/2011: There is now an article showing how to deploy Python (namely with Circuits.web) via Nginx + uWSGI.
Deploying circuits.web with Nginx/uwsgi.

Update 9/29/2010: As of version 0.8.40 Nginx now supports wsgi applications running over the uWSGI protocol natively. Click Here for more details. The 0.8.x branch is now the current stable branch.

Apache + mod_wsgi
One possible solution was to run Apache as a backend server listening on (or a port of your choice), which could also be easily used to serve up other dynamic content such as php. Many have used this setup for a great deal of internal load balancing, letting Nginx serve strictly static content, and Apache to handle the dynamic content.

In the sense of a WSGI Python application, you would have a server block like this in Nginx:

server {
	#server_name is what nginx responds to
	location / {
		#setting a Host header is handy if you have apache
		#setup with name-based virtual hosts
		proxy_set_header Host;
		#requires nginx to be compiled with --with-http_realip_module
		proxy_set_header X-Real-IP $remote_addr;
		#This can also be the IP address of another server

With the above method you could go with the easy route of having mod_wsgi (as of this writing, mod_wsgi is available at 2.5 supporting Python 2.6) installed via Apache. However doubling up the number of webservers run, might defeat the purpose of running Nginx for some of us, especially for those less familiar with Apache configuration.

Nginx WSGI Module

There was a port of Apache’s mod_wsgi over to Nginx by Manlio Perillo. However this module had only been tested on Nginx 0.5.34, and patched for 0.6.*.

However even when patched, the module remained quite buggy. Implementing this module went something like this:

In the http { } block

    wsgi_python_optimize 0;
    wsgi_enable_subinterpreters on;

In your server { } block

server {
	listen 80;
        location / {
            wsgi_pass  /var/www/username/domain/application.wsgi;
            include wsgi_vars;
            wsgi_var  SCRIPT_NAME         /var/www/username/domain/application.wsgi;
            wsgi_var  DOCUMENT_ROOT       /var/www/username/domain;
            wsgi_pass_authorization off;
            wsgi_script_reloading on;
            wsgi_use_main_interpreter on;

This module is no longer maintained and is does not to build on modern versions of Nginx (0.7/0.8), and was barely compatible with 0.6 by using a patch. The creator of the Apache mod_wsgi, Graham Dumpleton commented on his blog regarding the Nginx implementation:

The nginx version of mod_wsgi borrows some code from my original Apache version, but obviously since the internals of Apache and nginx are very different, the main parts of the code which interface with the web server are unique. Although I condoned use of the source code, I do wish I had insisted from the outset that it not be called mod_wsgi due to the confusion that has at times arisen.

Although development on the nginx version of mod_wsgi appears to no longer be happening, this isn’t stopping people from using it and many are quite happy with it. The question is whether they really understand anything about how nginx works and the shortcomings in how nginx and mod_wsgi work together.

Admittedly the author of the mod_wsgi module for nginx has been up front in pointing out that because nginx is asynchronous, and with WSGI not designed for such a system, that once the WSGI application is entered all other activity by the web server is blocked. The recommendation resulting from this is that static files should not be served from the same web server. Use of multiple nginx worker processes is also suggested as a way of mitigating the problem.

Source: Graham Dumpleton: Blocking requests and nginx version of mod_wsgi

There is however a far more practical solution fit for production use, especially for those using modern versions of Nginx.