Configuring Nginx to Serve Static Content on RHEL

Serving static files with Nginx on Red Hat Enterprise Linux is a straightforward way to deliver HTML, CSS, JavaScript, images, fonts, and downloadable documents efficiently. Nginx handles these resources with low overhead, making it suitable for personal websites, internal dashboards, documentation portals, and small Australian business sites.

This guide uses a dedicated document root and a separate server block, following a layout that is easy to maintain on RHEL 8, RHEL 9, CentOS Stream, and Fedora-based systems. It also covers SELinux, firewall access, file permissions, and safe configuration testing before changes reach production.

Install The Required Packages

Install Nginx with the standard package manager:

sudo dnf install -y nginx

Enable the service at boot and start it immediately:

sudo systemctl enable --now nginx
sudo systemctl status nginx

If Nginx is not installed yet, the Nginx installation guide provides a broader RHEL configuration walkthrough, including repository and service considerations.

Allow HTTP and HTTPS traffic through firewalld:

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

Create A Dedicated Document Root

A separate directory keeps website content independent from Nginx’s package files. Create a document root for a sample domain:

sudo mkdir -p /var/www/example.com/html
sudo chown -R nginx:nginx /var/www/example.com
sudo chmod -R 755 /var/www/example.com

Create a simple test page:

sudo tee /var/www/example.com/html/index.html > /dev/null <<'EOF'
<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Example Static Site</title>
</head>
<body>
  <h1>Nginx is serving static content</h1>
</body>
</html>
EOF

Australian organisations often host websites for customers in Sydney, Melbourne, Brisbane, or regional areas. A lightweight static site can reduce server resource use, which is useful when visitors connect through variable NBN speeds or mobile networks.

Apply Permissions And SELinux Contexts

Nginx needs permission to traverse each parent directory and read the files below the document root. The 755 directory mode and ownership shown above are suitable for basic public content, while private source files should remain outside the web root.

On an enforcing SELinux system, assign the correct web-content context:

sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/example.com(/.*)?"
sudo restorecon -Rv /var/www/example.com

If semanage is unavailable, install the supporting package:

sudo dnf install -y policycoreutils-python-utils

Reviewing file permissions guidance helps explain how ownership, modes, and the default umask affect files copied into the site directory.

Create The Nginx Server Block

Create a virtual host configuration under /etc/nginx/conf.d/:

sudo vi /etc/nginx/conf.d/example.com.conf

Add this configuration:

server {
    listen 80;
    listen [::]:80;

    server_name example.com www.example.com;

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

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

    location ~* \.(css|js|jpg|jpeg|png|gif|svg|ico|webp|woff2?)$ {
        expires 7d;
        add_header Cache-Control "public, immutable";
    }

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;
}

Replace the domain with a registered name or an internal DNS record. The try_files directive returns a 404 response for missing resources instead of forwarding requests unexpectedly.

Validate And Reload The Service

Always check syntax before applying a configuration change:

sudo nginx -t

A successful result should report that the syntax is valid and the test is successful. Reload Nginx without interrupting existing connections:

sudo systemctl reload nginx

Test locally with curl:

curl -I http://example.com
curl http://127.0.0.1

If DNS has not been configured, map the hostname temporarily in /etc/hosts or test with the server’s IP address. Check service logs when the response is unexpected:

sudo journalctl -u nginx -n 50 --no-pager
sudo tail -f /var/log/nginx/example.com.error.log

Operational Recommendations

Use these practices when preparing a static Nginx host for production:

• Keep application code, backups, and environment files outside /var/www/example.com/html.
• Use HTTPS with a trusted certificate before serving login pages or personal information.
• Test nginx -t before every reload and retain a copy of the previous configuration.
• Set cache lifetimes according to how often assets change, using versioned filenames for long-lived files.
• Review logs in Australian Eastern Time when coordinating maintenance with local teams.

For Australian businesses collecting names, addresses, or customer enquiries, consider obligations under the Privacy Act 1988. Static hosting does not remove the need to protect forms, analytics data, access logs, and any third-party services that process personal information.

Maintain Reliable Static Hosting

Monitor disk usage, certificate expiry, system updates, and error rates. A small static site may need little CPU or memory, but an unexpected traffic spike from an Australian retail campaign or local event can still exhaust bandwidth or expose an unoptimised image collection.

Use package updates regularly:

sudo dnf update -y

After updates, confirm that Nginx remains enabled and verify the site from an external network. For sites serving visitors nationwide, test from more than one location because a page that loads quickly in Sydney may behave differently for users in Perth or rural areas.

A dependable setup comes down to a readable server block, correct SELinux labels, restrictive file placement, working firewall rules, and repeatable validation. Create the document root, test the configuration, reload safely, and verify the public response before treating the RHEL host as ready for everyday traffic.