Hide the nginx version with server_tokens

The fix/etc/nginx/nginx.conf

http {
    server_tokens off;
}

sudo nginx -t && sudo systemctl reload nginx

Note the semicolon. server_tokens off without one is a config that will not load, and it is the most common way this single line fails.

Directives on this page

server_tokens

Controls whether the nginx version appears on error pages and in the Server response header. off removes the version but not the word nginx; build adds the build name; a literal string is commercial-only.

• acceptson | off | build
• defaultserver_tokens on;
• valid inhttp, server, location

nginx.org ngx_http_core_module docs

If you see this

nginx: [emerg] directive "server_tokens" is not terminated by ";" in /etc/nginx/nginx.conf:5

The line is missing its trailing semicolon. Every nginx directive needs one — `server_tokens off` is not valid, `server_tokens off;` is. — nginx/src/core/ngx_conf_file.c

nginx: [emerg] invalid value "false" in /etc/nginx/nginx.conf:5

The value is not one of the three the directive accepts. It takes off, on or build — not true/false, not 0/1, and not a version string to display. — nginx/src/core/ngx_conf_file.c

nginx: [emerg] "server_tokens" directive is not allowed here in /etc/nginx/nginx.conf:5

The directive is outside the contexts it is valid in. It belongs in http, server or location — not at the top level of the file, not in events, and not in an if block. — nginx/src/core/ngx_conf_file.c

The three values

Open-source nginx accepts exactly three, and no others:

Value	Server header	Notes
on	Server: nginx/1.30.4	The default
off	Server: nginx	What you want
build	Server: nginx/1.30.4 (build-name)	Reveals more, never less

build is the one worth understanding, because its name suggests a middle ground and it is the opposite. Internally the build string is defined as the full version plus the build name, so build is on with something extra appended — and if the packager never set a build name, it is byte-for-byte identical to on. There is no configuration in which build discloses less than on does.

Values are matched case-insensitively, so Off and OFF work. Anything outside the set — true, false, 0, 1, none, hide — is a fatal config error, not a silently ignored line.

Where the directive is valid

server_tokens is valid in three contexts: http, server and location. It takes exactly one argument.

http {
    server_tokens off;          # applies to every server and location below

    server {
        listen 443 ssl;
        server_tokens off;      # valid, but redundant if http already says off
    }
}

Put it in the http block. That single placement covers every virtual host and every location, which is the behaviour you want and the reason the fix above shows it there.

It is not valid at the top level of nginx.conf, nor inside events, nor inside an if block — all three produce a fatal directive is not allowed here. Placing it at the top of the file, above http, is the usual mistake, because that is where user, worker_processes and pid live and it looks like a global setting.

Unlike add_header, this directive inherits normally: a nested block that does not mention server_tokens keeps whatever the enclosing block set. The trap is the reverse one — an explicit server_tokens on; in a single server block silently overrides the global off for that host only.

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.

Every server has a version of this directive and the reasoning transfers intact — Apache’s equivalent is ServerTokens Prod, and that page reaches the same conclusion for the same reason: the real disclosure on a web server is directory listings, not the banner.

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'

nginx -T dumps the fully assembled configuration, every include resolved, which is the only way to see a stray directive in a vhost file you forgot about. Every occurrence should be off. A single on in one vhost undoes it for that host only, which is exactly the kind of thing that survives for years.

If the config won’t load at all, the parse check names the file and line:

sudo nginx -t

Expect syntax is ok and test is successful. Anything else is one of the three errors at the top of this page.

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, and the directive that does not inherit normally.
• Apache: disable information disclosure — ServerTokens Prod, the same trade-off on the other web server.
• Hardening nginx — the full checklist, in the order worth applying it.