
1. Know what you actually run
The single most useful fact, and the one most often wrong. Your package manager’s opinion is not the same as the binary on disk, which is not the same as the code in memory.2. Inventory every nginx you forgot about
The nginx you patch is rarely the only one you run. Containers pin their own copies, and pinned tags never move on their own.nginx:1.30.1 is frozen until you rebuild. If your compose files pin exact patch versions, patching is a code change and belongs in your deployment routine, not your server routine.
3. Shrink what is exposed
Most nginx advisories affect a specific module or directive. The fewer of them you use, the fewer advisories are yours. Start by seeing what your build even includes:map, rewrite, and regex captures:
map — it is a good directive. It is a reason to know whether an advisory naming it concerns you, in seconds rather than an afternoon.
4. Stop advertising your version
nginx returns its exact version in every response header and error page by default. That turns any scan into a targeted list.5. Set the headers that cost you nothing
Four headers, no downside for the vast majority of sites:always keyword matters: without it, the headers are dropped on error responses, which are exactly the ones an attacker sees most.

