Running Nginx 1.18 on Ubuntu gives system administrators a stable, high-performance foundation for handling heavy traffic loads and securing modern web applications. Whether you're migrating from an older stable branch or deploying a fresh LEMP stack, Nginx 1.18 brings crucial TLS improvements, better HTTP/2 handling, and refined configuration directives that optimize resource usage on Ubuntu server environments.
Getting maximum throughput requires more than a default installation package. By tuning worker processes, implementing robust SSL configurations, and configuring precise caching rules, you can turn a standard Ubuntu virtual private server into a high-speed web delivery engine. Let's look at how to install, configure, and secure Nginx 1.18 on Ubuntu to get the best possible results.
Installing Nginx 1.18 on Ubuntu
Before installing any web server packages, update your local package index to ensure you pull the correct dependencies from official repositories. Ubuntu's official package repositories for stable releases often include tested versions of Nginx that match your specific operating system release.
Run these terminal commands to refresh your package list and install the web server:
- Update your system package repository list by running
sudo apt update && sudo apt upgrade -y. - Install the Nginx package using
sudo apt install nginx. - Verify the installed version by executing
nginx -v. This should output the exact 1.18 release build.
If your Ubuntu release version includes an older repository package, you can add the official Nginx mainline or stable repository by following the guidelines on the Nginx Official Site.
Once installed, manage the service using systemd. Start the daemon and enable it to launch automatically on system boot:
sudo systemctl start nginx
sudo systemctl enable nginx
Check the current status with sudo systemctl status nginx. You should see an active, running process. Open your server's IP address in a browser to confirm the default welcome page loads successfully.
Configuring Ubuntu Firewall and Network Ports
Before opening your web server to public traffic, you must configure the UFW firewall to allow HTTP and HTTPS connections. Nginx registers application profiles with UFW during installation, making it simple to permit web traffic without manually specifying individual ports.
List the available application profiles by running:
sudo ufw app list
You'll typically see profiles for Nginx Full, Nginx HTTP, and Nginx HTTPS. To allow both standard unencrypted web traffic and secure TLS traffic, apply the Nginx Full profile:
sudo ufw allow 'Nginx Full'
Verify your firewall rules are active by running sudo ufw status. You should see rules allowing traffic on ports 80 and 443 from anywhere. If you're running a cloud server, make sure your cloud provider's security group or network ACLs also permit inbound traffic on these ports.
Performance Tuning for High-Traffic Workloads
Default Nginx configurations are designed for broad compatibility, not maximum performance. Tuning key parameters in your /etc/nginx/nginx.conf file allows the server to handle thousands of concurrent connections efficiently.
Adjusting Worker Processes and Connections
The worker_processes directive tells Nginx how many worker threads to spawn. A common practice is setting this to match the number of available CPU cores on your Ubuntu server. You can check your core count using the nproc command.
Open your main configuration file:
sudo nano /etc/nginx/nginx.conf
Adjust the core directives inside the main context:
worker_processes auto;
worker_rlimit_nofile 65535;
events {
worker_connections 10240;
use epoll;
multi_accept on;
}
Setting worker_connections to 10,240 combined with epoll lets the event-driven architecture handle massive spikes in simultaneous users. The multi_accept directive instructs workers to accept all new connections at once instead of one by one.
Enabling Gzip Compression
Compressing text-based assets like HTML, CSS, JavaScript, and JSON significantly reduces bandwidth usage and speeds up page load times for visitors. Add these compression rules inside the http block of your nginx.conf:
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_min_length 256;
gzip_types
application/atom+xml
application/javascript
application/json
application/rss+xml
application/vnd.ms-fontobject
application/x-font-ttf
application/x-web-app-manifest+json
application/xhtml+xml
application/xml
font/opentype
image/svg+xml
text/css
text/plain
text/vcard
text/vnd.rim.location.xloc
text/vtt
text/x-component
text/x-cross-domain-policy;
Level 6 compression offers an ideal balance between CPU usage and file size reduction. Test your configuration for syntax errors using sudo nginx -t before restarting the service.
Securing Nginx 1.18 on Ubuntu
Web server security requires hardening transport layers, hiding version numbers, and protecting against common web exploits like clickjacking and cross-site scripting.
Hardening TLS and Cipher Suites
Modern web security demands strong encryption protocols. Disable outdated TLS protocols like TLSv1 and TLSv1.1, restricting your server exclusively to TLSv1.2 and TLSv1.3.
Create a dedicated snippet file for SSL parameters at /etc/nginx/snippets/ssl-params.conf:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_session_cache shared:MozSSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
You can obtain free, automated SSL certificates by integrating Let's Encrypt tools from the Certbot Official Site to generate your keys and handle automatic renewals.
Adding Essential Security Headers
Protecting your visitors from malicious browser injection attacks requires sending strict HTTP security headers with every response. Include these headers inside your server block configuration:
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;
Additionally, hide your Nginx version string to prevent attackers from identifying specific software builds. Inside the http block of nginx.conf, add:
server_tokens off;
Common Configuration Mistakes to Avoid
Even experienced administrators occasionally run into frustrating configuration pitfalls when setting up Nginx on Ubuntu. Watch out for these common errors:
- Forgetting to test configuration syntax with
sudo nginx -tbefore runningsudo systemctl reload nginx, which can cause silent failures or downtime if an error exists. - Leaving default server blocks enabled in
/etc/nginx/sites-enabled/default, which can intercept requests intended for your custom domain names. - Setting overly aggressive file descriptor limits in the systemd service file without adjusting system-wide limits in
/etc/security/limits.conf. - Failing to set proper file permissions on web root directories, forcing Nginx to run processes with insecure permissions or throw 403 forbidden errors.
Frequently Asked Questions
How do I check if Nginx is successfully using HTTP/2?
You can test HTTP/2 support using browser developer tools by inspecting the protocol column in the Network tab, or by running a command-line test using curl -I -s -k --http2 [https://your-domain.com](https://your-domain.com).
What is the difference between worker_processes and worker_connections?
worker_processes defines how many independent worker instances Nginx spawns, typically matched to your CPU cores. worker_connections defines how many simultaneous connections each individual worker process can handle at once.
How do I safely reload Nginx without dropping active client connections?
Use sudo systemctl reload nginx instead of restart. The reload command instructs the master process to check the new configuration, start new worker processes with the updated settings, and gracefully shut down old workers once they finish serving current requests.
Where should I store custom SSL certificates on Ubuntu?
Standard Ubuntu conventions place custom SSL certificate files inside /etc/ssl/certs/ for public certificates and /etc/ssl/private/ for private keys, ensuring restricted file permissions protect sensitive key data.
/https://tf-cmsv2-smithsonianmag-media.s3.amazonaws.com/filer_public/2d/4c/2d4c3af7-5c39-4377-8564-abd17144ae54/2016_megalodon.jpg)