In earlier posts I’ve introduced the benefits of Nginx as a lightweight web server that can be used as a reverse proxy and even to load balance. After using Nginx more extensively, I want to share one lesson that was extremely important for me to get a better understanding of how to configure my reverse proxies to work as intended without wasting hours debugging or needlessly over-configuring.
Let’s take a look at a very basic reverse proxy configuration:
1 2 3 4 5 6 7 8 9 10 11 12 13 | #nginx configuration server { listen 80; server_name www.mysite.com; # pass along header with reverse proxy requests proxy_set_header Host $host; # pass along all requests to apache waiting at localhost:8080 location / { proxy_pass http://localhost:8080; } } |
Apache’s configuration then would look like
1 2 3 4 5 6 | #apache httpd configuration Listen localhost:8080 <VirtualHost localhost:8080> DocumentRoot /path/to/webroot ServerName www.mysite.com </VirtualHost> |
I want to point along two important lines. First “proxy_set_header Host $host” in the Nginx configuration and “ServerName www.mysite.com” in the Apache configuration. The first line instructs Nginx to pass along the original host header to Apache in essence tricking Apache into believing the request came directly from the end user.
And because we want Apache to believe it received the request directly, we repeat the server name that was defined in the Nginx configuration. This might seem obvious to some of you, but at first I was tripped up because I did not realize I could pass along the host header request and match it to Apache’s intended Server Name.
Without doing so, it was very difficult to use the same Apache instance as the backend for multiple reverse proxied websites. That was because Apache had no way to differentiate a request for website A from a request for website B. However, once you pass along the requested host, Apache now has a piece of information that it can use to differentiate requests by matching the host to its defined server name.
In a previous post we saw how simple it is to set up nginx in front of apache, and in this post I’ll show you it’s just as easy to use nginx as a load balancer.
Load balancing can be left to either hardware or software. For most of us, the expensive hardware is out of the question, but cheap (free) software will solve our needs just fine. Here’s a look at how nginx does load balancing
upstream mysite {
server www1.mysite.com;
server www2.mysite.com;
}
server {
server_name www.mysite.com;
location / {
proxy_pass http://mysite;
}
}
The above configuration will send 50% of requests for www.mysite.com to www1.mysite.com and the other 50% to www2.mysite.com. However, if you add a “weight” tag onto the end of the “server” definition you can modify the percentages. Other useful options include max_fails and fail_timeout. For sticky sessions use ip_hash. Refer to the full documentation for further details.
Now that you know how to load balance, you will need to learn how to sync your files between multiple web servers.
I’ve been evaluating nginx, a lightweight web server, for the last week and I am coming away impressed. Over the last year or so nginx seems to have overtaken lighttpd for the crown of lightweight web servers.
In our case nginx is used to serve static files while apache is used to serve dynamic content (we also use nginx for simple load balancing). A request for http://www.mysite.com/file.extension will first be sent to nginx which will determine whether to serve the file itself (if its static) or if not it will request the url http://localhost:8080/file.extension from apache and pass back the result seamlessly to the end user.
