Make Nginx Listen on a Specific Interface

1. Introduction

As system administrators, we may need to limit the exposure of application and other servers to the network to enhance security. Additionally, optimizing network performance through dedicated network paths improves throughput and enhances the overall efficiency of the services.

In this tutorial, we’ll discuss the steps involved in changing the Nginx configuration to listen on a specific interface.

Notably, we’ve tested the commands and code on Ubuntu 22.04 LTS with Bash 5.1.16.

2. Nginx Webserver Installation

Let’s quickly look into the steps for installing the Nginx Web server.

First, we run the install command:

$ sudo apt update -y && sudo apt install nginx iproute2 -y

Here, we execute two commands in sequence using the logical AND (&&) operator. The first part of the command updates the repositories on the system. Following the update, the second part of the command installs the nginx and iproute2 packages. Notably, the -y flag automatically confirms any prompts during the update process, allowing it to proceed without requiring manual intervention. It ensures that the package lists are updated without interruption.

Importantly, the iproute2 package provides essential networking utilities, which we later use for verification and testing.

So, let’s enable the Nginx Web server to start automatically during system boot:

$ sudo systemctl enable nginx
Synchronizing state of nginx.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable nginx

Further, the output confirms that the Nginx is integrated into the systemd service management. Also, it should start automatically during system boot.

Next, let’s get the current status of Nginx using the systemctl status nginx command:

$ sudo systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2024-02-11 07:40:40 PST; 4min 19s ago
       Docs: man:nginx(8)
   Main PID: 3061 (nginx)
      Tasks: 9 (limit: 5655)
     Memory: 8.4M
        CPU: 74ms
     CGroup: /system.slice/nginx.service
             ├─3061 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─3064 "nginx: worker process" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""
...
... output truncated ...
...
Feb 11 07:40:40 labenv systemd[1]: Starting A high performance web server and a reverse proxy server...
Feb 11 07:40:40 labenv systemd[1]: Started A high performance web server and a reverse proxy server.

As a result, we see that the service is currently active and running. Additionally, it displays details such as the process ID, the number of tasks, memory, and CPU usage. This command helps check the operational status and resource usage of the Nginx service on the system.

3. Configuring Nginx Network Settings

Now, let’s configure Nginx by changing the parameters in the configuration file at /etc/nginx/sites-available/default. These settings decide how Nginx handles incoming requests, manages server resources, and interacts with backend services.

As a simple example, let’s take a server with an IP address of 172.20.142.23, which is configured on the ens160 server interface:

$ ip address show ens160
3: ens160:  mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:54:c2:2f brd ff:ff:ff:ff:ff:ff
    inet 172.20.142.23/24 brd 172.20.142.255 scope global dynamic noprefixroute ens160
       valid_lft 591sec preferred_lft 591sec
...
... output truncated ...
...

Thus, we use the ip command to extract the server IP configuration.

Next, let’s change the IP of the specific interface on the server block in the Nginx configuration file.

In our case, the configuration specifies that Nginx should listen for incoming connections on the IP address 172.20.142.23 and port 8081. Further, the default_server parameter indicates that it uses this server block as the default server if no other server blocks match the requested hostname:

$ sudo vi /etc/nginx/sites-available/default
server {
        listen 172.20.142.23:8081 default_server;
...
... output truncated ...
...
}

Also, this configuration instructs Nginx to accept incoming requests on the specified IP address and port, effectively defining a socket for handling Web traffic directed to this address and port combination.

When executed with -t, Nginx checks its files for syntax errors or misconfigurations. If the settings are valid, we see the outputs syntax is ok and test is successful:

$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Thus, this command is useful and sometimes vital for verifying the integrity of the Nginx configuration before applying changes to the Web server.

Lastly, we restart the Nginx services to apply the new configuration settings:

$ sudo systemctl restart nginx

Here, we’ve successfully modified the Nginx configuration changes and implemented the changes into the system.

4. Verifying Nginx Listening Interface

So, let’s test the deployed Nginx configuration using the telnet command:

$ telnet 172.20.142.23 8081
Trying 172.20.142.23...
Connected to 172.20.142.23.
Escape character is '^]'.

This command establishes a TCP connection to the IP address 172.20.142.23 and port 8081. If Nginx is configured correctly and listening on that IP address and port, it won’t go to the next prompt.

On the other hand, we can also test our settings using the nmap command:

$ nmap -p 8081 172.20.142.23 | grep 8081
8081/tcp open  unknown

Here, nmap scans the IP address 172.20.142.23 on port 8081 and lets us know whether the port is open or closed. Also, commands like lsof, ss, and so on can check which TCP ports are open on the system.

5. Conclusion

In the article, we’ve discussed the steps to make Nginx listen to a specific interface address.

In conclusion, Nginx provides the flexibility to specify the network interface it can listen on via its current settings, thus improving an organization’s ability to create robust, high-performance Web environments that are secure, flexible, and capable of meeting evolving business needs.