Configuring Apache and Nginx

Exclusive offer: get 50% off this eBook here
Nginx HTTP Server

Nginx HTTP Server — Save 50%

Adopt Nginx for your web applications to make the most of your infrastructure and serve pages faster than ever

$26.99    $13.50
by Clément Nedelcu | July 2010 | Open Source Web Development

In this article by Clément Nedelcu, author of the book Nginx HTTP Server, we will see the following:

  • Configuring Nginx to work with Apache
  • Reconfiguring Apache to work as a backend server

(For more resources on Nginx, see here.)

There are basically two main parts involved in the configuration, one relating to Apache and one relating to Nginx.

Note that while we have chosen to describe the process for Apache in particular, this method can be applied to any other HTTP server. The only point that differs is the exact configuration sections and directives that you will have to edit. Otherwise, the principle of reverse-proxy can be applied, regardless of the server software you are using.

Reconfiguring Apache

There are two main aspects of your Apache configuration that will need to be edited in order to allow both Apache and Nginx to work together at the same time. But let us first clarify where we are coming from, and what we are going towards.

Configuration overview

At this point, you probably have the following architecture set up on your server:

  • A web server application running on port 80, such as Apache
  • A dynamic server-side script processing application such as PHP, communicating with your web server via CGI, FastCGI, or as a server module

The new configuration that we are going towards will resemble the following:

  • Nginx running on port 80
  • Apache or another web server running on a different port, accepting requests coming from local sockets only
  • The script processing application configuration will remain unchanged

As you can tell, only two main configuration changes will be applied to Apache as well as the other web server that you are running. Firstly, change the port number in order to avoid conflicts with Nginx, which will then be running as the frontend server. Secondly, (although this is optional) you may want to disallow requests coming from the outside and only allow requests forwarded by Nginx. Both configuration steps are detailed in the next sections.

Resetting the port number

Depending on how your web server was set up (manual build, automatic configuration from server panel managers such as cPanel, Plesk, and so on) you may find yourself with a lot of configuration files to edit. The main configuration file is often found in /etc/httpd/conf/ or /etc/apache2/, and there might be more depending on how your configuration is structured. Some server panel managers create extra configuration files for each virtual host.

There are three main elements you need to replace in your Apache configuration:

  • The Listen directive is set to listen on port 80 by default. You will have to replace that port by another such as 8080. This directive is usually found in the main configuration file.
  • You must make sure that the following configuration directive is present in the main configuration file: NameVirtualHost A.B.C.D:8080, where A.B.C.D is the IP address of the main network interface on which server communications go through.
  • The port you just selected needs to be reported in all your virtual host configuration sections, as described below.

The virtual host sections must be transformed from the following template

<VirtualHost A.B.C.D:80>
ServerName example.com
ServerAlias www.example.com
[...]
</VirtualHost>

to the following:

<VirtualHost A.B.C.D:8080>
ServerName example.com:8080
ServerAlias www.example.com
[...]
</VirtualHost>

In this example, A.B.C.D is the IP address of the virtual host and example.com is the virtual host's name. The port must be edited on the first two lines.

Accepting local requests only

There are many ways you can restrict Apache to accept only local requests, denying access to the outside world. But first, why would you want to do that? As an extra layer positioned between the client and Apache, Nginx provides a certain comfort in terms of security. Visitors no longer have direct access to Apache, which decreases the potential risk regarding all security issues the web server may have. Globally, it's not necessarily a bad idea to only allow access to your frontend server.

The first method consists of changing the listening network interface in the main configuration file. The Listen directive of Apache lets you specify a port, but also an IP address, although, by default, no IP address is selected resulting in communications coming from all interfaces. All you have to do is replace the Listen 8080 directive by Listen 127.0.0.1:8080; Apache should then only listen on the local IP address. If you do not host Apache on the same server, you will need to specify the IP address of the network interface that can communicate with the server hosting Nginx.

The second alternative is to establish per-virtual-host restrictions:

<VirtualHost A.B.C.D:8080>
ServerName example.com:8080
ServerAlias www.example.com
[...]
Order deny,allow
allow from 127.0.0.1
allow from 192.168.0.1
eny all
</VirtualHost>

Using the allow and deny Apache directives, you are able to restrict the allowed IP addresses accessing your virtual hosts. This allows for a finer configuration, which can be useful in case some of your websites cannot be fully served by Nginx.

Once all your changes are done, don't forget to reload the server to make sure the new configuration is applied, such as service httpd reload or /etc/init.d/ httpd reload.

Configuring Nginx

There are only a couple of simple steps to establish a working configuration of Nginx, although it can be tweaked more accurately as seen in the next section.

Enabling proxy options

The first step is to enable proxying of requests from your location blocks. Since the proxy_pass directive cannot be placed at the http or server level, you need to include it in every single place that you want to be forwarded. Usually, a location / { fallback block suffices since it encompasses all requests, except those that match location blocks containing a break statement.

Here is a simple example using a single static backend hosted on the same server:

server {
server_name .example.com;
root /home/example.com/www;
[...]
location / {
proxy_pass http://127.0.0.1:8080;
}
}

In the following example, we make use of an Upstream block allowing us to specify multiple servers:

upstream apache {
server 192.168.0.1:80;
server 192.168.0.2:80;
server 192.168.0.3:80 weight=2;
server 192.168.0.4:80 backup;
}
server {
server_name .example.com;
root /home/example.com/www;
[...]
location / {
proxy_pass http://apache;
}
}

So far, with such a configuration, all requests are proxied to the backend server; we are now going to separate the content into two categories:

  • Dynamic files: Files that require processing before being sent to the client, such as PHP, Perl, and Ruby scripts, will be served by Apache
  • Static files: All other content that does not require additional processing, such as images, CSS files, static HTML files, and media, will be served directly by Nginx

We thus have to separate the content somehow to be provided by either server.

Separating content

In order to establish this separation, we can simply use two different location blocks—one that will match the dynamic file extensions and another one encompassing all the other files. This example passes requests for .php files to the proxy:

server {
server_name .example.com;
root /home/example.com/www;
[...]
location ~* \.php.$ {
# Proxy all requests with an URI ending with .php*
# (includes PHP, PHP3, PHP4, PHP5...)
proxy_pass http://127.0.0.1:8080;
}
location / {
# Your other options here for static content
# for example cache control, alias...
expires 30d;
}
}

This method, although simple, will cause trouble with websites using URL rewriting. Most Web 2.0 websites now use links that hide file extensions such as http://example.com/articles/us-economy-strengthens/; some even replace file extensions with links resembling the following: http://example.com/useconomy- strengthens.html.

When building a reverse-proxy configuration, you have two options:

  • Port your Apache rewrite rules to Nginx (usually found in the .htaccess file at the root of the website), in order for Nginx to know the actual file extension of the request and proxy it to Apache correctly.
  • If you do not wish to port your Apache rewrite rules, the default behavior shown by Nginx is to return 404 errors for such requests. However, you can alter this behavior in multiple ways, for example, by handling 404 requests with the error_page directive or by testing the existence of files before serving them. Both solutions are detailed below.

Here is an implementation of this mechanism, using the error_page directive :

server {
server_name .example.com;
root /home/example.com/www;
[...]
location / {
# Your static files are served here
expires 30d;
[...]
# For 404 errors, submit the query to the @proxy
# named location block
error_page 404 @proxy;
}

location @proxy {
proxy_pass http://127.0.0.1:8080;
}
}

Alternatively, making use of the if directive from the Rewrite module:

server {
server_name .example.com;
root /home/example.com/www;
[...]
location / {
# If the requested file extension ends with .php,
# forward the query to Apache
if ($request_filename ~* \.php.$) {
break; # prevents further rewrites
proxy_pass http://127.0.0.1:8080;
}
# If the requested file does not exist,
# forward the query to Apache
if (!-f $request_filename) {
break; # prevents further rewrites
proxy_pass http://127.0.0.1:8080;
}
# Your static files are served here
expires 30d;
}
}

There is no real performance difference between both solutions, as they will transfer the same amount of requests to the backend server. You should work on porting your Apache rewrite rules to Nginx if you are looking to get optimal performance.

Nginx HTTP Server Adopt Nginx for your web applications to make the most of your infrastructure and serve pages faster than ever
Published: July 2010
eBook Price: $26.99
Book Price: $44.99
See more
Select your format and quantity:

(For more resources on Nginx, see here.)

Advanced configuration

For now, we have only made use of one directive offered by the Proxy module. There are many more features that we can employ to optimize our design. The table below lists a handful of settings that are valid for most of your reverse-proxy configurations, although they need to be verified individually. And since they can be employed multiple times, you can place them in a separate configuration file that you will include in your location blocks.

Start by creating a proxy.conf text file that you place in the Nginx configuration directory. Insert the directives described below in that file. Then for each location of your if blocks that forward requests to a backend server or upstream block, insert the following line after the proxy_pass directive:

include proxy.conf;

Suggested values for some of the settings:

Setting

Description

proxy_redirect off;

It lets Nginx forward redirections to the client "as it is" without processing the response itself.

proxy_set_header Host

$host;

The Host HTTP header in the request forwarded to the backend server defaults to the proxy hostname, as specified in the configuration file. This setting lets Nginx use the original Host from the client request instead.

proxy_set_header X-Real-

IP $remote_addr;

Since the backend server receives a request from Nginx, the IP address it communicates with is not that of the client. Use this setting to forward the actual client IP address into a new header, X-Real-IP.

proxy_set_header XForwarded-

For $proxy_

add_x_forwarded_for;

Similar to the header above, except that if the client already uses a proxy on his/her own end, the actual IP address of the client should be contained in the X-Forwarded-For request header. Using $proxy_ add_x_forwarded_for ensures that both the IP address of the communicating socket and possibly the original IP address of the client (behind a proxy) gets< forwarded to the backend server.

client_max_body_size

10m;

Limits the maximum size of the request body to 10 megabytes. Actually, this setting is referenced here to make sure that you adjust the value to the same level as your backend server. Otherwise a request that is correctly received and processed by Nginx may not be successfully forwarded to the backend.

client_body_buffer_size

128k;

Defines the minimum size of the memory buffer that will hold a request body. Past this size, the content is saved in a temporary file. Adjust it according to the expected size of requests your visitors will be sending, similar to client_max_body_size.

proxy_connect_timeout

15;

If you are working with a backend server on a local network, make sure to keep this value reasonably low (15 seconds here, but it depends on the average load). The maximum value for this directive is 75 seconds anyway.

proxy_send_timeout 15;

Make sure you define a timeout for write operations (timeout between two write operations during a communication to the backend server).

proxy_read_timeout 15;

Similar to the directive above, except for read operations.

Many other directives may be configured here. However, default values are appropriate for most setups.

Summary

In this article, we saw how to configure Nginx to work with Apache and also reconfiguring Apache to work as a backend server.


Further resources on this subject:


Nginx HTTP Server Adopt Nginx for your web applications to make the most of your infrastructure and serve pages faster than ever
Published: July 2010
eBook Price: $26.99
Book Price: $44.99
See more
Select your format and quantity:

About the Author :


Clément Nedelcu

Clément Nedelcu was born in France and studied in UK, French, and Chinese universities. After teaching computer science and programming in several eastern Chinese universities, he worked as a Technology Consultant in France, specializing in web and Microsoft .NET programming as well as Linux server administration. Since 2005, he has also been administering a major network of websites in his spare time. This eventually led him to discover Nginx: it made such a difference that he started his own blog about it. One thing leading to another…

Books From Packt

Blender 2.49 Scripting
Blender 2.49 Scripting

Moodle 1.9 for Design and Technology
Moodle 1.9 for Design and Technology

FreeSWITCH 1.0.6
FreeSWITCH 1.0.6

iReport 3.7
iReport 3.7

Drupal 7 First look
Drupal 7 First look

Building Websites with DotNetNuke 5
Building Websites with DotNetNuke 5

Grok 1.0 Web Development
Grok 1.0 Web Development

Apache MyFaces 1.2 Web Application Development
Apache MyFaces 1.2 Web Application Development

Your rating: None Average: 5 (1 vote)

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
G
5
1
G
9
W
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software