How to Expose Services with the Nginx Proxy Manager

Modern applications can handle many requests simultaneously, and even under heavy load, they must return correct information to users. There are different ways to scale applications: Vertical Scaling: add more RAM or CPU power by renting or purchasing a more powerful server. It is easy during the early stages of the application’s development, but it has drawbacks, such as cost and the limitations of modern hardware. Horizontal Scaling: add more instances of the application. Set up a second server, deploy the same application on it, and somehow distribute traffic between these instances. Horizontal scaling, on the one hand, can be cheaper and less restrictive in terms of hardware. You can simply add more instances of the application. However, now we need to distribute user requests between the different instances of the application. Load Balancing is the process of distributing application requests (network traffic) across multiple devices. A Load Balancer is a middleware program between the user and a group of applications. The general logic is as follows: The user accesses the website through a specific domain, which hides the IP address of the load balancer. Based on its configuration, the load balancer determines which application instance should handle the user's traffic. The user receives a response from the appropriate application instance. Load Balancing Advantages Improved Application Availability: Load balancers have the functionality to detect server failures. If one of the servers goes down, the load balancer can automatically redirect traffic to another server, ensuring uninterrupted service for users. Scalability: One of the main tasks of a load balancer is to distribute traffic across multiple instances of the application. This enables horizontal scaling by adding more application instances, increasing the overall system performance. Enhanced Security: Load balancers can include security features such as traffic monitoring, request filtering, and routing through firewalls and other mechanisms, which help improve the application's security. Using Nginx for Network Traffic Load Balancing There are quite a few applications that can act as a load balancer, but one of the most popular is Nginx.  Nginx is a versatile web server known for its high performance, low resource consumption, and wide range of capabilities. Nginx can be used as: A web server A reverse proxy and load balancer A mail proxy server And much more. You can learn more about Nginx's capabilities on its website. Now, let's move on to the practical setup. Installing Nginx on Ubuntu Nginx can be installed on all popular Linux distributions, including Ubuntu, CentOS, and others. In this article, we will be using Ubuntu. To install Nginx, use the following commands: sudo apt updatesudo apt install nginx To verify that the installation was successful, you can use the command: systemctl status nginx The output should show active (running). The configuration files for Nginx are located in the /etc/nginx/sites-available/ directory, including the default file that we will use for writing our configuration. Example Nginx Configuration First, we need to install nano: sudo apt install nano Now, open the default configuration file: cd /etc/nginx/sites-available/sudo nano default Place the following configuration inside: upstream application { server 10.2.2.11; # IP addresses of the servers to distribute requests between server 10.2.2.12; server 10.2.2.13; } server { listen 80; # Nginx will open on this port location / { # Specify where to redirect traffic from Nginx proxy_pass http://application; } } Setting Up Load Balancing in Nginx To configure load balancing in Nginx, you need to define two blocks in the configuration: upstream — Defines the server addresses between which the network traffic will be distributed. Here, you specify the IP addresses, ports, and, if necessary, load balancing methods. We will discuss these methods later. server — Defines how Nginx will receive requests. Usually, this includes the port, domain name, and other parameters. The proxy_pass path specifies where the requests should be forwarded. It refers to the upstream block mentioned earlier. In this way, Nginx is used not only as a load balancer but also as a reverse proxy. A reverse proxy is a server that sits between the client and backend application instances. It forwards requests from clients to the backend and can provide additional features such as SSL certificates, logging, and more. Load Balancing Methods Round Robin There are several methods for load balancing. By default, Nginx uses the Round Robin algorithm, which is quite simple. For example, if we have three applications (1, 2, and 3), the load balancer will send the first request to the first application, then the second request to the second application, the third request to the third application, and then continue the cycle, sending the next request to the first one again. Let’s look at an example. I have deployed two applications and configured load balancing with Nginx for them: upstream application { server 172.25.208.1:5002; # first server 172.25.208.1:5001; # second } Let’s see how this works in practice: The first request goes to the first server. The second request goes to the second server. Then it goes back to the first server, and so on. However, this algorithm has a limitation: backend instances may be idle simply because they are waiting for their turn. Round Robin with Weights To avoid idle servers, we can use numerical priorities. Each server gets a weight, which determines how much traffic will be directed to that specific application instance. This way, we ensure that more powerful servers will receive more traffic. In Nginx, the priority is specified using server weight as follows: upstream application { server 10.2.2.11 weight=5; server 10.2.2.12 weight=3; server 10.2.2.13 weight=1; } With this configuration, the server at address 10.2.2.11 will receive the most traffic because it has the highest weight. This approach is more reliable than the standard Round Robin, but it still has a drawback. We can manually specify weights based on server power, but requests can still differ in execution time. Some requests might be more complex and slower, while others are fast and lightweight. upstream application { server 172.25.208.1:5002 weight=3; # first server 172.25.208.1:5001 weight=1; # second } Least Connections What if we move away from Round Robin? Instead of simply distributing requests in order, we can base the distribution on certain parameters, such as the number of active connections to the server. The Least Connections algorithm ensures an even distribution of load between application instances by considering the number of active connections to each server. To configure it, simply add least_conn; in the upstream block: upstream application { least_conn; server 10.2.2.11; … } Let’s return to our example. To test how this algorithm works, I wrote a script that sends 500 requests concurrently and checks which application each request is directed to. Here is the output of that script: Additionally, this algorithm can be used together with weights for the addresses, similar to Round Robin. In this case, the weights will indicate the relative number of connections to each address — for example, with weights of 1 and 5, the address with a weight of 5 will receive five times more connections than the address with a weight of 1. Here’s an example of such a configuration: upstream application { least_conn; server 10.2.2.11 weight=5; … } nginx upstream loadbalancer { least_conn; server 172.25.208.1:5002 weight=3; # first server 172.25.208.1:5001 weight=1; # second } And here’s the output of the script: As we can see, the number of requests to the first server is exactly three times higher than to the second. IP Hash This method works based on the client’s IP address. It guarantees that all requests from a specific address will be routed to the same instance of the application. The algorithm calculates a hash of the client’s and server’s addresses and uses this result as a unique key for load balancing. This approach can be useful in blue-green deployment scenarios, where we update each backend version sequentially. We can direct all requests to the backend with the old version, then update the new one and direct part of the traffic to it. If everything works well, we can direct all users to the new backend version and update the old one. Example configuration: upstream app { ip_hash; server 10.2.2.11; … } With this configuration, in our example, all requests will now go to the same application instance: Error Handling When configuring a load balancer, it's also important to detect server failures and, if necessary, stop directing traffic to "down" application instances. To allow the load balancer to mark a server address as unavailable, you must define additional parameters in the upstream block: failed_timeout and max_fails. failed_timeout: This parameter specifies the amount of time during which a certain number of connection errors must occur for the server address in the upstream block to be marked as unavailable. max_fails: This parameter sets the number of connection errors allowed before the server is considered "down." Example configuration: upstream application { server 10.2.0.11 max_fails=2 fail_timeout=30s; … } Now, let's see how this works in practice. We will "take down" one of the test backends and add the appropriate configuration. The first backend instance from the example is now disabled. Nginx redirects traffic only to the second server. Comparative Table of Traffic Distribution Algorithms Algorithm Pros Cons Round Robin Simple and lightweight algorithm. Evenly distributes load across applications. Scales well. Does not account for server performance differences. Does not consider the current load of applications. Weighted Round Robin Allows setting different weights for servers based on performance. Does not account for the current load of applications. Manual weight configuration may be required. Least Connection Distributes load to applications with the fewest active connections. Can lead to uneven load distribution with many slow clients. Weighted Least Connection Takes server performance into account by focusing on active connections. Distributes load according to weights and connection count. Manual weight configuration may be required. IP Hash Ties the client to a specific IP address. Ensures session persistence on the same server. Does not account for the current load of applications. Does not consider server performance. Can result in uneven load distribution with many clients from the same IP. Conclusion In this article, we explored the topic of load balancing. We learned about the different load balancing methods available in Nginx and demonstrated them with examples.

The location directive in Nginx configuration is a powerful tool for defining how different types of requests are processed. By specifying rules in the location directive, you can direct requests to various parts of your application, apply specific configurations, or block certain requests altogether. This directive enables fine-grained control over request handling, making it essential for optimizing performance, security, and functionality of web applications. Basic Syntax The location directive is defined in the nginx.conf configuration file. Its basic syntax is as follows: location [modifier] uri { ... } modifier: An optional parameter that defines the type of match (e.g., exact, prefix, regex). uri: The URI to be matched. Inside the curly braces, you can define various settings and instructions (e.g., proxy_pass, root, index). Exact Match Example An exact match occurs when the requested URI exactly matches the specified string. location = /exact-match { root /var/www/html; index index.html; } In this example, only requests to /exact-match will be processed by this location block. You can also add a condition with if statement. Please note that in Nginx, there isn't a direct equivalent to the traditional if-else statement found in many programming languages. However, you can achieve similar functionality by using multiple if statements and combining them with other directives to simulate conditional branching.  location = /exact-match { root /var/www/html; index index.html; if ($http_user_agent ~* "Chrome") { add_header X-Browser "Chrome"; } } Here, if the user agent is Chrome, an additional header X-Browser is added to the response. Prefix Match Example A prefix match is the most common type and matches any URI that starts with the specified string. location /prefix { root /var/www/html; index index.html; if ($request_method = POST) { return 405; # Method Not Allowed } } Here, any request starting with /prefix (like /prefix/page1 or /prefix/page2) will be handled by this location block. If the request method is POST, Nginx returns a 405 Method Not Allowed status. Regular Expression Match Example You can use regular expressions for more complex matching scenarios. In Nginx, the regular expression match can include wildcards, which are characters that match any character or set of characters. Here are some common wildcards used in regular expressions: .: Matches any single character. .*: Matches any sequence of characters (including no characters). ^: Matches the beginning of a string. $: Matches the end of a string. location ~* \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; if ($request_uri ~* "/admin") { return 403; # Forbidden } if ($request_uri !~* "/admin") { add_header X-Admin "Not Admin"; } } In this example: The ~* modifier indicates a case-insensitive regular expression match. The pattern \.php$ matches any URI ending with .php (e.g., index.php, test.PHP). If the requested URI contains /admin, Nginx returns a 403 Forbidden status. If the requested URI does not contain /admin, an X-Admin header is added indicating "Not Admin". Case Insensitive Match Example To perform case-insensitive matching, you can use the ~* modifier in a regular expression. location ~* \.jpg$ { root /var/www/images; if ($http_referer !~* "^https?://(www\.)?example\.com") { return 403; # Forbidden } } This matches any URI ending with .jpg, .JPG, .Jpg, etc., and only serves the image files if the referer is from example.com. Otherwise, it returns a 403 Forbidden status. Managed solution for Backend development Priority and Order The priority and order of location blocks are critical for correctly processing requests. Nginx follows these rules: Exact match (=): These have the highest priority. Regular expressions (~ or ~*): Evaluated in the order they are defined in the configuration file. Prefix matches without modifier: These have the lowest priority, but among them, the longest prefix has the highest priority. Example location = /exact { # highest priority } location ~* \.jpg$ { # lower priority than exact match } location / { # lowest priority } Nesting Location Blocks Nginx allows nesting of location blocks within other location blocks for more granular control. location /nested { location /nested/subnested { root /var/www/html; } root /var/www/html; } In this example, requests to /nested/subnested will be processed by the inner location block, while /nested (but not /nested/subnested) will be processed by the outer location block. Real Web Server Example Let's consider a practical example of configuring a local web server with multiple location blocks. server { listen 80; server_name localhost; # Root location block location / { root /var/www/html; index index.html; } # Exact match for a specific page location = /about { root /var/www/html; index about.html; } # Prefix match for an API endpoint location /api { proxy_pass http://localhost:3000; 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-Proto $scheme; } # Regular expression match for PHP files location ~ \.php$ { root /var/www/html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; } # Case insensitive match for image files location ~* \.(jpg|jpeg|png|gif|ico)$ { root /var/www/images; } # Nested location blocks for admin section location /admin { root /var/www/admin; index index.html; location /admin/stats { proxy_pass http://localhost:8080/stats; } } } In this configuration: The root location serves static files from /var/www/html. Requests to /about are served by the exact match block pointing to about.html. The /api prefix is proxied to a backend service running on port 3000. PHP files are processed by a FastCGI server. Image files are served from /var/www/images. Nested location blocks are used to handle /admin and /admin/stats with different settings. The main configuration file for Nginx is usually located at /etc/nginx/nginx.conf. This file contains the core configuration directives for the Nginx server. After making changes to the Nginx configuration, you need to reload the Nginx service to apply the changes. This can be done without interrupting the current connections by using the following command: sudo systemctl reload nginx Conclusion Understanding and effectively using the location directive in Nginx is key to fine-tuning request handling for your web server. By mastering exact, prefix, regex, and case-insensitive matches, as well as the priority and order of these directives, you can ensure your Nginx configuration is robust and efficient. Moreover, leveraging nested location blocks allows for precise and granular control over request processing, further enhancing your server’s capabilities.

Nginx is one of the most popular open-source web servers. It is often used as a web server, reverse proxy, or mail proxy. This article will describe how to install Nginx on Ubuntu and make its basic configuration. Installing Nginx You will need a local machine or a cloud server with the Ubuntu operating system installed to install the Nginx server.  Nginx is available in the official Ubuntu repositories, so you can install it using the apt package management system. First, you need to update the package lists from the repositories: sudo apt update After the update is finished, you can install Nginx on the machine: sudo apt install nginx Wait for the installation to finish, and then use this command to start up the service at boot: sudo systemctl enable nginx Now check that the web server is running and configured to start at boot. Check the status of the web server: sudo service nginx status The line "Active: active (running)..." indicates the successful operation of the server.  There is another way to check it. Paste the server's IP address into the browser's address bar. If the result is the same as in the picture below, the web server is running. Now let's check that it's configured to start at boot: sudo systemctl is-enabled nginx If the output shows "enabled", the web server has been added to startup. Below are the basic commands to manage your web server. Action Command Start sudo systemctl start nginx Shutdown sudo systemctl stop nginx Restart sudo systemctl restart nginx Reload sudo systemctl reload nginx Status check sudo systemctl status nginx Configuration testing sudo nginx -t Firewall settings Installing and configuring a firewall will allow you to close all ports except those that we need: 22 (SSH), 80 (HTTP), 443 (HTTPS). The first one is required to connect to a remote server. The second and third are necessary for communication between the client and the site.  Install UFW: sudo apt install ufw Then add the web server to the available applications list: sudo nano /etc/ufw/applications.d/nginx.ini Let's fill the file like this: [nginx HTTP]title=Web Serverdescription=Enable NGINX HTTP trafficports=80/tcp[nginx HTTPS]\title=Web Server (HTTPS) \description=Enable NGINX HTTPS trafficports=443/tcp[nginx full]title=Web Server (HTTP,HTTPS)description=Enable NGINX HTTP and HTTPS trafficports=80,443/tcp Check the list of available applications: sudo ufw app list If there is a web server among them, everything is done correctly. Now you need to start the firewall and allow traffic on the ports we mentioned above: sudo ufw enablesudo ufw allow 'Nginx Full'sudo ufw allow 'OpenSSH' To check the changes, enter the command: sudo ufw status The output should list all the ports we need. - Setting up Nginx Web server administration is the modification and maintenance of configuration files. Among them are one configuration file and two directories. These are nginx.conf, sites-available, and sites-enabled, respectively. All of them are in the /etc/nginx directory. The nginx.conf file is the main configuration file. The sites-available directory contains virtual host configuration files. Each file stores a specific site's name, IP address, and other data. The sites-enabled directory, in turn, consists of active site configurations only. Only the sites-enabled directory reads configuration files for virtual hosts. It also stores links to the sites-available. This structure allows you to temporarily disable sites without losing their configurations. Let's take a closer look at the main configuration file. To do this, open it using the editor: sudo nano /etc/nginx/nginx.conf After executing the command, a file divided into modules will open. By default, it looks like in the image below: Each module is a directive responsible for specific web server settings. There are simple directives and block ones. In addition to the name and parameters, block directives store additional instructions placed inside curly brackets. Let's list some of the directives of the main configuration file: user is the user that runs all the worker processes. worker_processes is the number of server worker processes. It shouldn't exceed the number of processor cores. The auto option will set the number automatically. pid is a file showing the main process's ID. include is responsible for including other configuration files matching the specified mask. events consists of directives that manage the network connection. worker_connections is the maximum number of concurrent connections for a single worker process. multi_accept is a flag that can be either enabled (on) or disabled (off). If enabled, the worker process will accept all new connections; otherwise, only one. use specifies the connection handling method. By default, the server chooses the most efficient. http consists of directives responsible for the operation of the HTTP server. sendfile enables (on) or disables (off) the sendfile() data sending method. tcp_nopush, tcp_nodelay are parameters that affect the performance. The first forces the server to send HTTP response headers in one packet, and the second allows you not to buffer the data and send it in short bursts. keepalive_timeout is responsible for the keep-alive connection timeout before the server terminates it. keepalive_requests is the maximum number of requests in one keep-alive connection. error_log is a web server error log. To collect errors for a specific section (http, server, etc.), you need to place the directive inside that section. gzip is for content compression. Setting up virtual hosts A server can host multiple sites. All requests come to its IP address, and the web server determines how to respond, depending on the domain. Virtual hosts ensure that the server understands what data belongs to which domain.  For example, we'll create the site testsite.dev. Let's create a folder for the site: sudo mkdir -p /var/www/testsite.dev/html Then add the index file: sudo nano /var/www/testsite.dev/html/index.html Let's fill it with the basic data needed to display the site: <!DOCTYPE html><html lang="en"><head>     <title>testsite.dev</title>     <metacharset="utf-8"></head><body>     <h1>Hello, user</h1></body></html> Then we'll create a site configuration file in the sites-available folder: sudo nano /etc/nginx/sites-available/testsite.dev.conf Let's fill it with the simplest configuration: server {     listen 80;     listen[::]:80;     server_name testsite.dev www.testsite.dev;     root /var/www/testsite.dev/html;     index index.html index.xml;} The last thing to do is create a link in the sites-enabled directory to the testsite.dev site configuration, so it is added from available to enabled: sudo ln -s /etc/nginx/sites-available/testsite.dev.conf /etc/nginx/sites-enabled/ Now let's test the configuration: sudo nginx -t Disable the default site by deleting the default virtual host entry: sudo rm /etc/nginx/sites-enabled/default It is worth clarifying that after we disable the default site, Nginx will use the first server block it encounters as a fallback site (that is, the very first site from the Nginx configuration will open at the server IP address). Restart the web server: sudo systemctl restart nginx Let's check that the site works. To do this, you can paste the server IP address or domain, if it is registered, into the address bar of the browser: Another option is to use the curl command: Conclusion In this article, we have shown the process of installing Nginx on Linux, namely on the Ubuntu distribution.  Using this guide you can set up the web server and deploy your first website. We have also prepared the server to use the encrypted HTTPS protocol. Remember that to set up a secure connection, you will need an SSL certificate.