3v-Hosting Blog

Installing Nginx on AlmaLinux 9

Administration

8 min read


AlmaLinux 9 has quickly established itself in users’ minds as a replacement for good old CentOS, especially in scenarios where a predictable server is needed - where stability is key and there are no surprises after updates. You install the system, and it runs smoothly and predictably throughout its entire lifespan. For any production environment, this makes life much easier.

The next step after installing the OS is almost always installing a web server, because it doesn’t matter whether it’s a website, an API, a standard proxy in front of containers, or you just want to serve static content to the frontend. In reality, there aren’t that many options, and most often people choose the Nginx web server, due to its low resource consumption and speed when handling specific tasks, which allows it to handle loads that would already be a problem for Apache. This is especially significant for projects on small VPS, where such a difference is immediately noticeable. At the same time, it handles a host of auxiliary, non-core tasks, such as proxying, load balancing, or serving static files.

So, in this brief article, let’s walk through the process of installing Nginx on AlmaLinux 9 - the most popular distribution - as well as its basic setup and common configuration mistakes.

 

 

 

 

Standard Nginx Installation on AlmaLinux 9

Nginx is not installed by default on a clean AlmaLinux system, so the logical first step is to install it. In AlmaLinux, this is straightforward, as the base repositories already contain the necessary package and no additional repositories need to be added.

AlmaLinux uses the standard DNF package manager, through which almost any additional software can be installed.

The installation is performed with a single command:

sudo dnf install nginx -y

 

The required package will be pulled in along with all its dependencies. This usually happens quickly, within a few seconds.

After installation, Nginx does not start on its own, and this is normal behavior, since it’s not advisable to run a web server that hasn’t been configured yet. The system simply places the binaries and configuration files where they belong, and then it’s up to you to decide when and how to enable it.

 

 

 

 

Installation from the official Nginx repository

The standard AlmaLinux repository contains the stable version of the web server, since we know that AlmaLinux is a stable distribution. The stable version works fine, but it may lag slightly behind the very latest updates. Therefore, if your project needs access to the newest features, then it makes sense to install Nginx from the official repository.

This is not difficult to do; we simply connect to the external repository first, and then install the desired package as usual. Only then will the system fetch updates not from the native AlmaLinux repository but from the external nginx.org repository.

First, install the utilities for working with repositories and create a file in which we’ll specify the new repo:

sudo dnf install dnf-utils -y

sudo nano /etc/yum.repos.d/nginx.repo

 

Insert the following configuration into this file:

[nginx-mainline]
name=nginx mainline repo
baseurl=http://nginx.org/packages/mainline/centos/9/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key

 

This is the mainline branch, where new features appear faster. Sometimes changes are included there that haven’t been tested in the stable branch yet. For most tasks, this works fine, but proceed with caution and don’t take unnecessary risks - after all, you didn’t choose a stable OS just to clutter it with unstable and untested software.

 

After that, save the file and proceed with the standard installation:

sudo dnf install nginx -y

 

If Nginx was already installed from the standard repository, the package will be updated to the version from the official source. In such cases, a version conflict may sometimes occur. This can be resolved by simply removing the old package before installing the new one.

 

 

 

Starting and Autoloading

If the command output includes the line active (running), usually highlighted in green, it means Nginx has started successfully and is running. This means everything is fine, the service has started, systemd sees no errors, and your web server is ready to accept requests.

If instead you see the text inactive (dead), this means that Nginx is installed but is not currently running. This happens either immediately after installation, before you have started it, or after manually stopping the service. In this case, try starting it again with the command:

sudo systemctl start nginx

 

The failedstatus, usually highlighted in red, indicates that Nginx attempted to start but encountered an error.

Sometimes you may see activating. This means the service is still attempting to start. If this status persists for more than a few seconds, something is preventing a normal startup. For example, a hung process, a network issue, or an incorrect configuration.

The deactivating status appears while the service is stopping. It usually disappears quickly. If Nginx remains in this state for a long time, check the processes and logs.

For detailed diagnostics, use the following command, which will display system log entries specifically related to Nginx:

journalctl -u nginx -xe

 

This command will display the latest systemd messages regarding Nginx, and in most cases, it will already be clear what exactly went wrong, whether it’s a busy port, a syntax error, an access denial, or a problem with the configuration file.

 

 

Checking if Nginx is listening on the port

So, we’ve started the Nginx web server on your server. But just because the service is running doesn’t mean it’s actually accepting incoming connections. This happens more often than you might think, so right after startup, you should check whether Nginx is listening on the correct port.

First, check if the process is bound to port 80:

ss -tulnp | grep nginx

 

The output should include a line listing the ports :80 or :443 and the nginx process. If it’s not there, it means the server isn’t listening on the port, which means either it didn’t start properly or the port is already occupied by another service.

In that case, go back to the previous step and check the system log and the service status.

If the port is listening, then check the web server’s response by accessing port 80 directly from the console using the curl utility:

curl -I http://localhost

 

If everything is fine, you will receive an HTTP response, either the code 200 OKor the code 403 Forbidden. If you see the second option, don’t despair; this is also normal and means that Nginx is running but cannot serve the content (for example, it lacks the necessary permissions or the requested file is missing).

If there is no response at all or the connection cannot be established, then the problem is clearly more serious. Since we’ve determined that the service is running and the port is listening, we need to check the firewall, web server configuration, or listening interfaces, as the server may sometimes be configured to listen only on localhost. But let’s take it step by step.

 

 

 

 

Firewall Configuration

So, Nginx may be running and even listening on the correct port, but the server will still be inaccessible from the outside. The system firewall may be the cause. In AlmaLinux, firewalld runs by default, and it blocks incoming connections unless they are explicitly allowed. And we haven’t allowed them yet. Let’s fix this oversight.

You need to open the ports for HTTP and HTTPS, and the easiest way to do this is through the built-in system services:

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

 

As you might have guessed, the first command allows connections on port 80, and the second on port 443. The --permanent flag saves the rule so it doesn’t disappear after a reboot. Reloading the firewall, the last command, applies the changes.

If you don’t do this, you’ll encounter a strange situation where everything works locally - curlreturns a normal response code - but the web server is inaccessible from another computer. Almost always, the issue is with the firewall.

 

After adding the necessary rules, open your server’s IP address in a browser or run the following command on another computer:

curl -I http://YOUR_SERVER_IP

 

If you receive a response and the page loads, everything is fine. If you get an error, go through the previous steps again.

 

 

 

 

Configuration Structure

Now let’s briefly review the main configuration files and working directories you’ll be working with initially. It’s all quite simple:

Path Purpose
/etc/nginx/nginx.conf main configuration of the web server
/etc/nginx/conf.d/ configuration files for individual websites
/var/log/nginx/ web server logs
/usr/share/nginx/html/ default directory for website files

Later, as you become more familiar with Nginx, you’ll learn about other useful files and directories required for other web server functions.

If you’re already an experienced Nginx user, you might notice something missing here, such as the sites-available and sites-enabled directories.

This structure is used in Debian and Ubuntu distributions. There, the config files are stored in sites-available, while sites-enabled contains symbolic links to these config files - only for active sites. This is convenient when you need to quickly enable and disable projects.

AlmaLinux doesn’t include this out of the box. But if you wish, you can set up this structure manually if you’re already used to it or manage dozens of sites.

By the way, you can read about how to install Nginx on an Ubuntu server here.

 

 

 

Virtual host example

After installation and startup, Nginx serves its standard page, which is located in the default directory (see above), and is completely useless for a real website. For the server to start working with your domain, you need a separate configuration file called a virtual host.

In this configuration - in this separate file - you tell Nginx which domain it should respond to, where to fetch the website files from, and how to handle incoming requests. One file equals one website. You can have multiple websites on a single server, all served by the same web server, and you can have as many of these configurations as you like.

Here is a minimal example of a website configuration file, which you can name whatever you like and give it the .conf extension:

server {
    listen 80;
    server_name example.com;

    root /var/www/example;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

 

Let’s briefly go over what’s happening here.

listen 80 - this directive specifies which port the server should listen on; in our case, the server listens on port 80 (HTTP); server_name - to the right of this directive, we must specify the domain to which the web server should respond. If the domain in the request header does not match the one specified in this block, then this block will not work, and the request will be handled by another virtual host with the correct domain; root - this directive specifies the path to your website’s files; index - this directive specifies which file should be served by default.

The location / block is the basic rule for handling requests. First, Nginx searches for the file at the specified path; if the file is not found, it returns a 404 error code.

 

Files with such configurations - virtual hosts - are usually placed in the directory /etc/nginx/conf.d/, after which the configuration is checked and a reload is performed. And if the DNS already points to your server, the website will open immediately.

 

Finally, it’s definitely worth mentioning how to check the configuration. This is done with the command:

sudo nginx -t

 

To apply the configuration after any changes, use the command:

sudo systemctl reload nginx

 

That’s it - at this stage, you’ve installed the Nginx web server on a server running AlmaLinux 9 and launched your first website. If you’d like to explore all of Nginx’s features in more depth, be sure to visit their official website.

 

 

FAQ

Why won’t Nginx open in the browser?

Check if the firewall (firewalld) is active and if port 80 is open for HTTP, and also make sure that the Nginx service itself is running and isn’t bound to the local address (127.0.0.1) instead of a public IP.

 

How do I change the port?

Open your website’s configuration file, find the directive listen 80; and replace 80 with the desired port; then don’t forget to restart Nginx and allow the new port in the firewall.

 

How do you verify that the Nginx configuration is error-free?

Use the command sudo nginx -t; it will check the syntax of all configuration files and display the exact file and line containing the error, if any, which is especially useful before restarting the server.

 

What should you do if Nginx fails to start after installation due to the "address already in use" error?

Most likely, port 80 is already in use by another program (such as Apache or Varnish), so you need to find the relevant process using the command sudo ss -tlnp | grep :80 and either stop it or change the port for Nginx to a different one, as described above.

 

How do you enable Nginx to start automatically at system boot?

Run the command sudo systemctl enable nginx - this will add Nginx to the startup list - and then use the command sudo systemctl start nginxto start it now, so that the website will be immediately available the next time the server reboots.

 

 

 

 

Conclusions

As you have seen, installing Nginx on AlmaLinux 9 is fairly straightforward, but for it to work correctly, it is important to immediately check several parameters, such as firewall settings, configuration syntax, and the status of the service itself.

In this article, we’ve covered common issues, briefly touched on why the server might not open in a browser, how to change the port in case of conflicts, as well as how to check the configuration before rebooting the system and set up the web server to start automatically. By following these recommendations, you’ll quickly get a stable web server up and running without any unnecessary complications.

And if you plan to host your site through CloudFlare, then you’ll find this article helpful as well.

3v-Hosting Team

Author

3v-Hosting Team

The 3v-Hosting Team is made up of a dedicated group of engineers and operators who are all about building and maintaining the backbone of our services. Every day, we dive into the world of virtual and dedicated servers, handling everything from deployment and monitoring to troubleshooting real-world issues that pop up in production environments. Most of our articles stem from hands-on experience rather than just theory. We share insights on the challenges we face: performance hiccups, configuration missteps, networking intricacies, and architectural choices that impact stability and reliability. Our mission is straightforward – we want to share knowledge that empowers you to manage your projects with fewer surprises and a lot more predictability.