Website on a VPS: Nginx and a Let's Encrypt certificate (HTTPS)

Nginx is a fast web server. We'll use it to serve a static website or put it in front of your app as a reverse proxy, and turn on HTTPS with a Let's Encrypt certificate that renews itself.

How it works#

The browser connects to port 80 (HTTP) or 443 (HTTPS) of your VPS. Based on the domain in the request, Nginx picks the right server block (the configuration of one website) and either sends a file from disk (static website) or passes the request to an app running on another port (reverse proxy).

The HTTPS certificate is issued for free by Let's Encrypt. The Certbot program verifies that you control the domain (Let's Encrypt connects to port 80 and downloads a check file), downloads the certificate, sets it up in Nginx and then renews it on its own.

Prerequisites: DNS and ports#

1. Check that the domain points to the VPS. On the VPS, run:

   getent hosts example.cz

   You'll see your VPS's IP address (from the Network tab). If not, fix the DNS and wait for the change to propagate.

2. Open ports 80 and 443:

   • Firewall in the customer area (if you use the Block everything except allowed mode): rule Inbound · Allow · TCP · port 80,443. Guide: Firewall in the customer area.
   • UFW on the VPS (if you use it): ufw allow 80/tcp and ufw allow 443/tcp.

Installing Nginx#

Works on both Ubuntu 24.04 and Debian 13:

apt update
apt -y install nginx

• apt -y install nginx – installs Nginx. The service starts right away and is enabled at VPS boot.

Check: open http://<VPS_IP_ADDRESS> in your browser. Replace <VPS_IP_ADDRESS> with the IPv4 address from the Network tab (for example http://203.0.113.10). You'll see the “Welcome to nginx!” page.

How the configuration is organized#

So you enable a website by creating a file in sites-available and a link to it in sites-enabled. You disable it by deleting the link.

Static website#

A static website is a set of ready-made HTML, CSS, JavaScript and image files.

1. Create the website directory and a test page:

   mkdir -p /var/www/example.cz/html
   echo '<h1>It works</h1>' > /var/www/example.cz/html/index.html

   • mkdir -p – creates the directory including its parents.
   • echo '…' > …/index.html – writes a simple page to index.html.

   Later, upload your own website files into this directory over SFTP (guide) or in the Files tab.

2. Create the website configuration:

   nano /etc/nginx/sites-available/example.cz

   server {
       listen 80;
       listen [::]:80;
       server_name example.cz www.example.cz;
   
       root /var/www/example.cz/html;
       index index.html;
   
       location / {
           try_files $uri $uri/ =404;
       }
   }

3. Enable the website, disable the default welcome page, test the configuration and load it:

   ln -s /etc/nginx/sites-available/example.cz /etc/nginx/sites-enabled/
   rm /etc/nginx/sites-enabled/default
   nginx -t
   systemctl reload nginx

   • ln -s … /etc/nginx/sites-enabled/ – creates the link, so Nginx starts loading the website.
   • rm /etc/nginx/sites-enabled/default – disables the default website (the file stays in sites-available).
   • nginx -t – checks the syntax of all configurations. It must end with syntax is ok and test is successful.
   • systemctl reload nginx – loads the new configuration without dropping connections.

Check: http://example.cz shows the “It works” heading from the test page.

Reverse proxy for an app#

An app (Node.js, Python, Java, a Docker container) usually runs on its own port, for example 3000. You put Nginx in front of it as a reverse proxy: it accepts requests on port 80/443 and forwards them to the app. Benefits: Nginx handles HTTPS, the app doesn't have to be visible from the internet, and one VPS can run several apps under different domains.

Configuration (instead of the static website, or as another file for a different domain, for example app.example.cz):

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    listen [::]:80;
    server_name app.example.cz;

    client_max_body_size 20m;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        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;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_read_timeout 300s;
    }
}

Enabling it works the same as for the static website:

ln -s /etc/nginx/sites-available/app.example.cz /etc/nginx/sites-enabled/
nginx -t
systemctl reload nginx

To keep the app running permanently and start it automatically after a VPS reboot, set it up as a service: Run an app 24/7 with systemd.

HTTPS with Certbot#

Installing Certbot#

apt -y install certbot python3-certbot-nginx

• certbot – the Let's Encrypt client.
• python3-certbot-nginx – a plugin that can verify the domain through Nginx and edit its configuration itself.

Getting a certificate#

certbot --nginx -d example.cz -d www.example.cz

• --nginx – verification through Nginx and automatic editing of its configuration.
• -d example.cz -d www.example.cz – the domains you want the certificate for. Each must have a DNS record pointing to the VPS and must be listed in the server_name of some website.

On the first run, Certbot asks these questions:

Result: Successfully deployed certificate for example.cz to /etc/nginx/sites-enabled/example.cz and Congratulations! You have successfully enabled HTTPS….

What Certbot changed in the configuration#

Open the website configuration (nano /etc/nginx/sites-available/example.cz). Lines marked # managed by Certbot were added by Certbot:

Don't edit these lines by hand unless you know exactly why. Certbot relies on them when renewing.

Automatic renewal#

A Let's Encrypt certificate is valid for 90 days (as of October 2026; Let's Encrypt is gradually shortening the validity). The Certbot package installed a timer that checks the certificates twice a day and renews those with roughly a third of their validity left. The Nginx plugin reloads Nginx after a renewal by itself.

Check that the timer exists and that renewal works:

systemctl list-timers | grep certbot
certbot renew --dry-run

• systemctl list-timers | grep certbot – prints a line with certbot.timer and the time of the next run.
• certbot renew --dry-run – tries a renewal against the staging server without touching the real certificates. It must end with Congratulations, all simulated renewals succeeded.

certbot certificates lists your certificates and their validity.

Cloudflare and SSL modes#

If your website runs through the Cloudflare proxy (orange cloud), two connections are encrypted: between the visitor and Cloudflare, and between Cloudflare and your VPS. The second one is controlled by the SSL/TLS mode in Cloudflare:

After switching to Proxied, run certbot renew --dry-run and check that renewal also works through the Cloudflare proxy. If it fails, make sure you aren't blocking port 80 with your own rules in Cloudflare. A permanent solution for advanced users is to verify the domain via DNS with the python3-certbot-dns-cloudflare plugin (see the Certbot documentation (opens in a new window)).

Basic security#

1. Hide the Nginx version. On Debian 13, /etc/nginx/nginx.conf already contains server_tokens off; by default. On Ubuntu 24.04, open the file (nano /etc/nginx/nginx.conf) and in the http block remove the # in front of # server_tokens off;. Nginx then won't reveal its version in headers or on error pages.

2. Security headers. You can add these to the server block with port 443:

   add_header X-Content-Type-Options nosniff always;
   add_header X-Frame-Options SAMEORIGIN always;
   add_header Referrer-Policy strict-origin-when-cross-origin always;

   • X-Content-Type-Options nosniff – the browser won't guess the file type (protection against disguised scripts).
   • X-Frame-Options SAMEORIGIN – the website can't be embedded in someone else's page in a frame (protection against clickjacking).
   • Referrer-Policy strict-origin-when-cross-origin – other websites only receive the domain, not the full page URL.
   • always – the header is sent with error responses too.

3. After every change, run nginx -t and systemctl reload nginx.

Verification#

curl -I http://example.cz
curl -I https://example.cz

• curl -I – downloads only the response headers.

The first command returns HTTP/1.1 301 Moved Permanently with the header Location: https://example.cz/, the second HTTP/1.1 200 OK (or HTTP/2 200). In the browser you'll see a padlock next to the address.

Troubleshooting#

nginx -t reports an error#

The output contains the file and line number, for example unexpected "}" in /etc/nginx/sites-enabled/example.cz:12. Most often a semicolon is missing at the end of a directive, or there's an extra or missing curly brace. Fix the line and run the test again. Don't restart Nginx with a broken configuration; it wouldn't start.

502 Bad Gateway#

Nginx is running but the app behind it isn't responding. Check that the app is running and listening on the port from proxy_pass:

ss -tlnp | grep 3000

• ss -tlnp – listening TCP ports with program names.

If nothing is printed, the app isn't running or listens elsewhere. Details are in /var/log/nginx/error.log (a line with connect() failed (111: Connection refused)).

504 Gateway Time-out#

The app responded too late. Increase proxy_read_timeout, or find out why the app is slow.

413 Request Entity Too Large#

The uploaded file is larger than client_max_body_size (default 1 MB). Increase the value in the server block and reload the configuration.

“Welcome to nginx!” shows instead of your website#

The default website is still active, or the domain in server_name doesn't match the address in the browser. Delete /etc/nginx/sites-enabled/default and check server_name.

Nginx won't start: Address already in use#

Port 80 or 443 is taken by another program, typically Apache. Find out which one: ss -tlnp | grep -E ':80 |:443 '. Stop and disable Apache (systemctl disable --now apache2), or uninstall it.

Certbot: Could not automatically find a matching server block#

No website has the domain you're requesting a certificate for in its server_name. Add it to server_name, run nginx -t, systemctl reload nginx and Certbot again.

Certbot: Timeout during connect (likely firewall problem) or Connection refused#

Let's Encrypt couldn't reach port 80. Check the DNS (getent hosts example.cz), the firewall in the customer area and UFW. If the domain has an AAAA record, it must point to this VPS's IPv6 address and the website must listen on IPv6 too (listen [::]:80;).

Cloudflare: error 521, 522, 525 or 526#

• 521 – the VPS refused the connection: Nginx isn't running or the firewall blocks port 443.
• 522 – the connection timed out: the VPS is unreachable or the firewall drops packets.
• 525 – the TLS handshake failed: Nginx has no valid HTTPS configuration on port 443.
• 526 – the certificate on the VPS is invalid or expired, in Full (strict) mode. Check certbot certificates.

ERR_TOO_MANY_REDIRECTS#

Typically Cloudflare in Flexible mode combined with the HTTPS redirect. Switch Cloudflare to Full (strict).

Further reading#

• nginx: Beginner's Guide (opens in a new window)
• nginx: WebSocket proxying (opens in a new window)
• nginx: ngx_http_proxy_module (opens in a new window)
• Certbot: User Guide (opens in a new window)
• Let's Encrypt: Rate Limits (opens in a new window)
• Cloudflare: SSL/TLS encryption modes (opens in a new window)