server_tokens off removes the nginx version number from the Server header and from error pages. It does not remove nginx's other fingerprints, and it does not patch anything. It is a small hygiene step, worth doing, and a poor substitute for knowing which version you run and updating it.
What the directive does
The nginx documentation gives the syntax as server_tokens on | off | build | string, default on, valid in http, server and location. It controls whether the nginx version appears on error pages and in the Server response header. The build value adds the build name alongside the version. Custom strings with variables are a commercial subscription feature, and an empty string disables the Server field.
server_tokens off;
With off, the header reads just nginx and error pages lose the version line.
Myth versus fact
Myth: hiding the version stops attacks. Fact: it removes a free hint. Exploits that need a specific flaw still work if the flaw is present. Fingerprinting by behavior, default pages or TLS details can still find you.
Myth: it is security through obscurity, so it is harmful. Fact: it is not harmful. It costs nothing, and it stops cheap automated matching of version strings to vulnerability lists. It just should not be your only control.
Myth: if a scanner flags your version, the header is the problem. Fact: scanners that read version banners can also be wrong. A distribution may backport fixes without changing the version number. After you hide the banner, a version based finding can disappear without anything having been fixed, which is the opposite of what you want. Our post on scanner version mismatches in nginx UI shows why confirming real exposure matters.
Myth: it applies to proxied responses. Fact: nginx by default does not pass the Date, Server, X-Pad and X-Accel headers from a proxied server's response to the client, per the proxy module documentation. proxy_hide_header lets you drop more, such as an application framework banner. That is a separate setting from server_tokens.
What to do instead, in order
- Keep an inventory of which nginx builds run where, including those inside container images and ingress controllers.
- Track advisories for your version line. The nginx 1.30.3 and 1.31.2 advisory is an example of the kind of release to watch.
- Patch on a schedule and after high severity advisories.
- Set server_tokens off and drop application banners with proxy_hide_header.
- Confirm with a request.
curl -sI https://example.com/ | grep -i -E '^server|^x-powered-by'
curl -s https://example.com/no-such-page | head
If the first command still prints a version or framework banner, something upstream is adding it. If the 404 page shows a version, the setting did not take effect in that server or location.
Where Safeguard fits
The hard part is the inventory in step one. Safeguard provides asset discovery, SBOM and dependency scanning, and reachability analysis that helps rank what is actually exploitable. The free scan is at https://gold.safeguard.sh/scan.
Quick check
What is the default value of server_tokens?
on, which shows the nginx version in the Server header and on error pages.
Can hiding the version make a scanner report look cleaner without a fix?
Yes, banner based findings can disappear while the flaw remains, so confirm the real version and patch level.
Sources
Last reviewed: 19 October 2026.
