Hide the nginx version with server_tokens

The fix/etc/nginx/nginx.conf

http {
    server_tokens off;
}

sudo nginx -t && sudo systemctl reload nginx

Be clear about what this buys you

server_tokens off changes this:

Server: nginx/1.30.4

into this:

Server: nginx

That is the entire effect. It does not remove the Server header, and it does not hide that you’re running nginx. It removes four digits.

This is obscurity, and it is worth doing for one narrow reason: mass scanners match on version strings. A bot working through the internet looking for hosts vulnerable to a specific CVE will read your banner and move on if it doesn’t match. Removing the version drops you out of that particular bucket.

It buys you nothing at all against anyone who has decided to look at you. Response fingerprinting identifies nginx and narrows the version range without the banner, and error page formatting gives it away too. Do not count this as a control — count it as reducing untargeted noise, which is the same value Fail2Ban offers on SSH, and for the same reason it is rated low.

The version number is not the vulnerability. If you’re on 1.30.4 you’re patched regardless of who knows it; if you’re on an unpatched version, hiding the banner does not unpatch the attacker. Patching is the control. This is housekeeping.

Removing the Server header entirely needs a module

Stock nginx cannot delete the Server header — server_tokens is the only lever, and off is as far as it goes. To remove or replace it you need headers-more-nginx-module:

more_clear_headers 'Server';

That module is packaged as nginx-extras on Debian and Ubuntu, and is the same module worth having for security headers, where it solves a genuinely painful problem. Installing a third-party module purely to hide a banner is not a good trade; installing it for header inheritance and getting this as a bonus is.

Don’t forget error pages

server_tokens off also removes the version from nginx’s built-in error page footers, which otherwise print nginx/1.30.4 in the HTML of every 404 and 502. That’s usually where people find it after “removing” it from the header — the directive handles both, but only if it’s in scope.

Put it in the http block so it applies everywhere. A server_tokens on in one server block overrides it for that host.

Verify it worked

Check the header:

curl -sI https://your.site/ | grep -i '^server:'

Expect Server: nginx with no version.

Now check an error page, which is the one people miss:

curl -s https://your.site/definitely-not-a-real-path | grep -i nginx

Expect <center>nginx</center> — not <center>nginx/1.30.4</center>.

Confirm nothing re-enables it in a sub-block:

sudo nginx -T 2>/dev/null | grep -n 'server_tokens'

Every occurrence should be off. A single on in a vhost undoes it for that host only, which is exactly the kind of thing that survives for years.

Before you apply this

No functional risk. Nothing depends on the version banner except monitoring that you control.

The one genuine caution is a false sense of progress. This is the easiest item on the checklist and it produces a visible, satisfying change, which makes it a tempting place to stop. It is the least valuable control in this cluster and it is ordered near the bottom deliberately.

If you have server_tokens off but are running an unpatched nginx, you have done nothing. Check that first:

nginx -v
apt list --upgradable 2>/dev/null | grep -i nginx

nginx 1.30.4 and 1.31.3 (June 2026) fixed a buffer overflow in map with regex, a memory disclosure in the slice module, and a use-after-free. Those matter. The banner does not.

Related

• Add a default server block — the other reconnaissance surface, and a more useful fix.
• Set security headers correctly — where headers-more earns its place.