+nginx is a fast and modern HTTP server with a small footprint. It is
+a popular choice as a reverse proxy to application servers such as
+This section will not cover the whole range of features nginx provides.
+Instead, it will simply provide you with a basic configuration that can
+be a good starting point.
+ gzip_disable "MSIE [1-6]\.";
+ gzip_types text/plain text/xml text/css
+ server_name www.example.com;
+ access_log /app/logs/www.example.com.log combined;
+ error_log /app/logs/www.example.com.log;
+ proxy_pass http://apps;
+ proxy_set_header Host $host;
+ proxy_set_header X-Real-IP $remote_addr;
+ proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+ proxy_set_header X-Forwarded-Host $server_name;
+Edit this configuration to match your own paths. Then, save this configuration
+into a file under ``/etc/nginx/conf.d/`` (assuming Ubuntu).
+The filename is irrelevant. Then run the following commands:
+ $ sudo service nginx stop
+ $ sudo service nginx start
+Hopefully, this will be enough to forward requests hitting
+the nginx frontend to your CherryPy application. The ``upstream``
+block defines the addresses of your CherryPy instances.
+It shows that you can load-balance between two application
+servers. Refer to the nginx documentation to understand
+Later on, this block is used to define the reverse
+Now, let's see our application:
+ if __name__ == '__main__':
+ 'server.socket_port': 8080,
+ 'tools.proxy.on': True,
+ 'tools.proxy.base': 'http://www.example.com'
+If you run two instances of this code, one on each
+port defined in the nginx section, you will be able
+to reach both of them via the load-balancing done
+Notice how we define the proxy tool. It is not mandatory and
+used only so that the CherryPy request knows about the true
+client's address. Otherwise, it would know only about the
+nginx's own address. This is most visible in the logs.
+The ``base`` attribute should match the ``server_name``
+section of the nginx configuration.