DEV Community: brent alexis

4 times the "success" message lied to me

brent alexis — Thu, 29 Oct 2026 15:21:34 +0000

I built and tested Nginx and Apache configs on a small side project, and one lesson kept coming back. A green tick only tells you the part that ran is happy. It doesn't tell you the thing you wanted actually happened.

Here are four times I got caught. All real, all in the last few weeks.

1. Nginx reload exited 0 and kept the old config.

I changed the key on a rate limit zone from $binary_remote_addr to $server_name. nginx -t passed. nginx -s reload exited 0. Nothing looked wrong.

But Nginx was still running the old config. The only sign of trouble was one line in the error log:

[emerg] limit_req "one" uses the "$server_name" key while previously it used the "$binary_remote_addr" key

The reload command just sent a signal. Exit 0 meant the signal got there, not that the new config was accepted. So nauseating. The fix was a full restart, or giving the zone a new name.

Check: look at the error log after every reload.

sudo nginx -t && sudo nginx -s reload && sudo tail -n 5 /var/log/nginx/error.log

2. Git push worked and the site didn't change.

I pushed a change to my page titles. No errors. Opened the site... old titles.

The host's build had failed at the "Cloning" step with "error occurred while fetching repository". A temporary hiccup on their side - "Retry build" fixed it.

A successful push only proves GitHub has your code. It says nothing about the deployment.

Check: open the live page (or view source) after every deploy, not just from the terminal.

3. `nginx -t` said ok, but my block rule never ran.

Nginx checks regex locations in the order they appear and uses the first one that matches. My hidden-file block sat below location ~ \.php$, so a request like /.old/backup.php matched the PHP block first and never reached my rule. The syntax was perfect. The rule just never got a turn.

The fix was moving the protection blocks above the PHP block.

Check: curl the exact paths you meant to block and look at the status code.

4. The request was blocked, just not by me.

Testing on Apache, /.htaccess came back 403. Blocked, great. Except my rule returned 404.

The 403 came from Apache's own built-in rule for .ht* files, which kicked in before any .htaccess rewrites ran. If I'd only checked "blocked or not", I'd have counted it as a pass for my rule.

Check: have your rules return a status you can tell apart (I use 404) so you know which rule actually answered.

Same lesson, four times

Anyway, the lesson learnt - check the result from outside the thing you changed. The command that reports success is usually the part that didn't fail.

After that, I put all of this into small Docker lab scripts that spun up real nginx:1.27 and httpd:2.4 containers and curled every path. The last run was 42/42, after fixing the one expectation from #4. They tested the output of the free config generators I built at ProxyForge.

Which "success" message got you?

This post was drafted with AI help, edited by me.

Nginx reverse proxy + HTTPS in 5 minutes (video + every command)

brent alexis — Thu, 15 Oct 2026 11:53:00 +0000

I recorded a short walkthrough of putting Nginx in front of an app and getting a free Let's Encrypt certificate onto it. Everything in the video runs on a real Ubuntu server, nothing is staged.

Below are the exact commands used, so you can copy them instead of pausing the video.

What you need

A Linux server. I used Ubuntu 24.04, which ships Nginx 1.24.
A domain or subdomain whose A record points at the server. If it's on Cloudflare, keep the record DNS only (grey cloud) while you get the certificate.
An app listening locally, for example on 127.0.0.1:3000.

1. Install Nginx and Certbot. Open the firewall to allow Nginx

sudo apt update
sudo apt install -y nginx certbot
sudo ufw allow 'Nginx Full'

No app installed? Use this to start a test one on port 3000:

mkdir -p ~/app && echo '<h1>Hello from port 3000</h1>' > ~/app/index.html
cd ~/app && python3 -m http.server 3000

Leave it running. Open a second SSH window for the rest of the tutorial.

2. Check your Nginx version

nginx -v

This matters for HTTPS. Nginx 1.25.1 and newer use a separate http2 on; line. Older versions (like 1.24 on Ubuntu 24.04, or 22.04 and Debian 11 packages) need HTTP/2 on the listen line instead:

listen 443 ssl http2;

Get this wrong and nginx -t fails with unknown directive "http2".

3. Generate the config

I used ProxyForge, the free generator I built. Pick Reverse proxy, enter your domain and 127.0.0.1:3000, and tick Redirect HTTP to HTTPS, WebSocket, and Older Nginx if step 2 showed a version before 1.25.1. Any config that does the same job works too. The parts that matter are:

a port 80 block that answers Let's Encrypt's check (/.well-known/acme-challenge/) and redirects everything else to HTTPS (more on this in step 7)
a port 443 block with ssl_certificate / ssl_certificate_key pointing at /etc/letsencrypt/live/<your-domain>/
proxy_pass http://127.0.0.1:3000; plus the usual proxy_set_header lines

Copy the output and keep it handy (I paste it into Notepad++), but I don't install it yet. The certificate files it points to don't exist, so nginx -t would fail.

4. Get the certificate

sudo certbot certonly --webroot -w /var/www/html \
  -d app.example.com -m you@example.com --agree-tos --no-eff-email

The webroot method only drops a file in /var/www/html, which Ubuntu's default site already serves on port 80. Certbot never edits your Nginx config. You should see:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/app.example.com/fullchain.pem

5. Install the config, test, then reload

sudo nano /etc/nginx/sites-available/app.example.com     # paste, Ctrl+O, Enter, Ctrl+X
sudo ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

&& means Nginx only reloads if the test passes, so a typo can't take a running site down.

One gotcha that cost me a few minutes. If the paste into nano silently fails, you end up saving an empty file. nginx -t still passes, but nothing listens on 443. Check with grep -c . /etc/nginx/sites-available/app.example.com. If it prints 0, paste again.

6. Check it

curl -I http://app.example.com     # expect: 301 Moved Permanently -> https://
curl -I https://app.example.com    # expect: HTTP/2 200

Then open it in a browser and click the padlock to see the Let's Encrypt certificate.

7. Make sure renewal works

Certbot renews automatically, but a common trap is the HTTPS redirect itself. If port 80 redirects everything to HTTPS, Let's Encrypt's renewal check gets passed through to your app instead of /var/www/html, and renewal quietly fails about 60 days later.

I recorded the video before I caught this, so the config on screen redirects everything. ProxyForge's output now includes the exception (tested against a real nginx -t before it went live), so regenerate the config if you copied it from the video. If you're using another config, the port 80 block should look like this:

location /.well-known/acme-challenge/ {
    root /var/www/html;
}
location / {
    return 301 https://$host$request_uri;
}

The return has to sit inside location /. A return placed directly in the server block runs before Nginx looks at any location, so the check would still be redirected.

Not sure which folder you gave Certbot? This version serves the file if it's there and otherwise falls back to the redirect, so it can't make things worse. ProxyForge's Redirect Generator uses this form:

location /.well-known/acme-challenge/ {
    root /var/www/html;
    try_files $uri @redirect;
}
location @redirect {
    return 301 https://$host$request_uri;
}
location / {
    return 301 https://$host$request_uri;
}

Either way, test renewal now instead of finding out in two months:

sudo certbot renew --dry-run

Congratulations, all simulated renewals succeeded means you're done.

If you hit an error I didn't cover, paste it in the comments and I'll take a look. The generator is free with no sign-up, and the how-to guide explains every option.

The Apache SSL line that looks right and still won't start

brent alexis — Thu, 08 Oct 2026 12:45:00 +0000

I built a free config generator for Nginx and Apache. Before shipping the SSL part, I ran every output against a real Nginx 1.27 and Apache 2.4 server. Using AI, I built a test sandbox instead of just reading the configs over.

That saved me more than once. The Apache version had two errors, both on the same line, and both looked completely fine on screen.

The setup

The goal was simple enough. Take a Let's Encrypt certificate and produce the Apache config for HTTPS with OCSP stapling turned on. Stapling lets your server send the certificate's "still valid" proof along with the handshake, so the visitor's browser doesn't have to go and ask the certificate authority itself.

On Apache, stapling needs two directives:

SSLUseStapling on turns stapling on.
SSLStaplingCache tells Apache where to keep the stapled responses.

Version 1 put everything inside the site's <VirtualHost *:443> block, the way a lot of snippets online do:

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    SSLUseStapling on
    SSLStaplingCache "shared:SSL:10m"   # two errors on this one line
</VirtualHost>

It reads fine. But it isn't.

Error 1: Wrong place

Apache didn't start. apachectl configtest stopped with a syntax error on the SSLStaplingCache line, saying the directive is "not allowed here".

The reason is scope. In Apache's mod_ssl, SSLUseStapling is allowed inside a <VirtualHost>, but SSLStaplingCache is server config only. It sets up one cache shared by the whole server, so it must sit in the main config: httpd.conf, or ssl.conf / mods-available/ssl.conf on Debian and Ubuntu. Put it inside any <VirtualHost> and Apache refuses the file.

It's an easy mistake to make, because the two directives belong together, so they naturally end up next to each other in the same block.

Error 2: Wrong syntax

After moving the line out of the <VirtualHost>, Apache still rejected it. This time it was the value.

shared:SSL:10m is Nginx syntax, borrowed from Nginx's ssl_session_cache directive. Apache uses its own cache providers, and the common one is shmcb (shared memory, cyclic buffer), written as a path plus a size in bytes:

SSLStaplingCache "shmcb:/tmp/ssl_stapling_cache(32768)"

When you're building something like this, you often write the Nginx and Apache outputs side by side. I was using AI to speed things up, got a bit lazy, and the Nginx habit slipped into the Apache side. A developer who knows Nginx might read shared:SSL:10m and move on. Apache doesn't.

The bug in my own test setup

One more lesson came from the sandbox itself. For a while, Apache seemed to just exit with no error at all. My test container had ErrorLog pointing at a file, so when Apache died during startup, the error was written to a log file inside a container that had already stopped.

Pointing ErrorLog at /dev/stderr for testing fixed it immediately, and the real error messages showed up. If you test Apache in Docker, do that first. Save yourself the headache!

While I was in there, the testing also showed that the Apache output was missing SSLSessionCache, which the Nginx side already had. It's the same kind of directive (server config only), and it uses shmcb too.

The config that works

The fix was to split the output into two clearly labelled parts.

Once, in the main server config (outside any <VirtualHost>):

SSLSessionCache  "shmcb:/tmp/ssl_scache(512000)"
SSLStaplingCache "shmcb:/tmp/ssl_stapling_cache(32768)"

Inside your <VirtualHost *:443> block:

SSLEngine on
SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLUseStapling on

Test before you reload, so a mistake never takes the site down:

sudo apachectl configtest && sudo systemctl reload apache2   # httpd on RHEL/Alma/Rocky/Fedora

The && means the reload only happens if the test passes.

The takeaway

Scope rules are invisible when you read config. Nothing about SSLStaplingCache looks different from SSLUseStapling. Only the server knows which context each one is allowed in.
Writing two servers side by side invites cross-contamination. Nginx and Apache solve the same problems with different syntax, and it's easy to carry one over to the other. If you do it, test both.
"Looks right" isn't a test. Running the actual binary caught two real errors in one line that several careful read-throughs missed.
I wrote this post with help from an AI assistant. The testing and results are my own.

If you'd rather skip the trial and error, my ProxyForge SSL generator gives you the Certbot command plus the matching Nginx or Apache config, with the Apache output already split into the two parts above. It's free, needs no signup and runs in your browser. The how-to guide explains where each piece goes.

Have you hit other Apache directives that are only allowed in one context? I'd like to hear about them, since they're exactly the kind of thing worth checking, and maybe adding to my tool.