4 次「成功」訊息騙了我

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.