Introduction
NGINX is a free and open-source web server software. It is also a reverse proxy, load balancer, HTTP cache, and web server. It provides a high-performance web infrastructure solution for many organizations worldwide.
Not only that, but it's easy to deploy and maintain on your own servers or in the cloud.
This software is not only known for its speed and performance, but also for its ability to handle more concurrent connections than Apache. It's a great solution for high traffic sites due to its scalability and ease of configuration.
You should also use NGINX when you need to serve static content that needs to be refreshed periodically, such as videos, images, and PDFs.
This article will cover the basics of NGINX, including how it works as a reverse proxy, how it's configured, best practices for using NGINX in production environments and why you would want to use it in the first place.
What's a reverse proxy?
A reverse proxy provides an abstraction layer for your servers, adding more protection and not exposing them to the client directly.
It's a type of proxy server that retrieves resources from one or more servers, then presents them to the client as if it had served them itself.
The reverse proxy can be used for many reasons, but mainly for security and load balancing. Reverse proxies are a great way to protect your server from outside requests and filter out undesirable content. They can also be used to distribute traffic among different servers in order to balance the workload.
Best practices and what to avoid
Best practices in NGINX configuration are usually divided into two categories: best practices to avoid and best practices to follow (e.g. refresh timeouts).
Avoid the following best practices if possible:
- Using the same server name for different domains.
- Allowing client connections without limits.
- Disabling buffering in NGINX configuration file.
- Accidentally exposing sensitive files or directories to the internet.
- Using too many worker processes, which can overload your server and cause it to crash.
- Make sure you test your configuration thoroughly before putting it into production.
Best practices to follow:
- Always deploy NGINX in a reverse proxy configuration.
- Use the upstream module to manage your upstream servers.
- Use the least amount of modules as possible.
- Place your static files in a separate location from your dynamic content.
- Optimize your NGINX configuration for performance.
Some examples
The NGINX configuration file is called nginx.conf
and it's located in the /etc/nginx
directory on Linux distributions.
This guide will show you how to configure NGINX to serve static files by default and also serve dynamic content when requested by the client.
Let's go through a simple example to understand how reverse proxy works.
Let's say we have 2 web servers running locally, serverOne running on port 8080
and serverTwo running on 8081
. First, we can easily setup NGINX proxy listening to the default http port 80
, meaning we can just execute http://localhost and go through the proxy to evaluates the different rules we declare in order to access our content.
Then, we configure NGINX rules to resolve internal routing for 8080
and 8081
, where http://localhost/one can respond to serverOne and http://localhost/two can respond to serverTwo.
With NGINX your machine should not expose both port 8080 and 8081 and make them public, this will be resolved internally by NGINX and the server just need to expose port 80, and keep all the other ports safe through private access only.
this is a very basic configuration we can use to cover the case mentioned above:
nginx.conf
http {
server {
listen 80;
location /one {
proxy_pass http://localhost:8080;
}
location /two {
proxy_pass http://localhost:8081;
}
}
}
This is not a code we would put in production, but it works, and it's a very simple example. For more advanced and safety features, NGINX provides upstream modules for more complex routing configuration, traffic limitations, redirecting, load balancer configuration, and much more.
For more information, see the following resources:
The NGINX website: https://nginx.org/en/
The NGINX Wiki: https://wiki.nginx.org/Nginx
NGINX documentation: https://docs.nginx.com/