打开浏览器开发者工具，响应r泄息漏切到 Network 面板，露框刷新页面，架信随便点开一个请求，响应r泄息漏看 Response Headers。露框十有八九你会看到一行：

Server: nginx/1.18.0 (Ubuntu)

或者更离谱的架信：

Server: Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1

这东西看着不起眼，但它等于在脑门上贴了张纸条：我用的响应r泄息漏是什么服务器、哪个版本、露框跑在什么系统上。架信攻击者连扫描都不用，响应r泄息漏直接读你的露框 HTTP 响应头就把底牌摸清了。

这个头是架信怎么来的

HTTP 协议里，Server 响应头本来是响应r泄息漏个可选字段。RFC 7231 写得很清楚，露框服务器“可以”在响应里带上这个字段，架信用来标识处理请求的软件。注意是“可以”，不是“必须”。但绝大多数 Web 服务器和中间件默认就会加上，而且加得特别详细。

Nginx 默认输出 Server: nginx/版本号，Apache 默认输出 Server: Apache/版本号 (操作系统) 附加模块版本。Tomcat、IIS、Jetty 各有各的格式。有些 CDN 和反向代理会在转发时保留或追加这个头，导致一条响应链上暴露好几层软件信息。

我见过一个政府网站，响应头里赫然写着 Server: Apache-Coyote/1.1。这直接说明后端跑的是 Tomcat，而且是比较老的版本。攻击者拿到这个信息，去查对应版本的 CVE 列表，效率比盲扫高太多了。

泄露的不只是“我用了什么”

版本号才是要命的部分。知道你是 Nginx 不稀奇，知道你是 Nginx 1.18.0 就有意义了——这个版本在某些配置下存在特定的解析漏洞。知道你是 Apache 2.4.29 加上 OpenSSL 1.1.1，等于告诉别人去翻这两个组件的已知漏洞库。

还有一种情况更隐蔽：Server 头里带上了内部主机名或路径信息。比如某些应用服务器会输出 Server: MyApp/2.3 (build: 20210315-prod-internal)，这直接把构建时间、环境标识都漏了。攻击者可以据此判断你的补丁周期和部署习惯。

有人觉得“隐藏版本号有什么用，人家照样能扫出来”。这话对了一半。指纹识别确实不止 Server 头一种手段，TCP/IP 栈特征、特定 URL 的响应行为、错误页面格式都能用来判断服务器类型。但 Server 头是最省事的那一种——不需要发畸形包，不需要比对特征库，看一眼就够了。把门槛从“需要点技术”降到“会按 F12”，性质完全不一样。

怎么处理

Nginx 里加一行 server_tokens off;，Server 头就只显示 nginx，版本号和系统信息都没了。Apache 在配置文件里设 ServerTokens Prod 和 ServerSignature Off，效果类似。IIS 需要用 URL Rewrite 模块写出站规则来改写 Server 头，稍微麻烦点。

Tomcat 可以在 server.xml 的 Connector 上加 server=" " 属性，直接把它设成空字符串或者一个无意义的值。应用层面的框架，比如 Spring Boot 内嵌 Tomcat，需要在配置里单独处理。

但光改 Server 头不够。X-Powered-By 头会泄露后端语言和框架版本，X-AspNet-Version 会暴露 .NET 版本，X-Generator 在一些 CMS 里会直接写出建站系统名称和版本。这些头该删的删，该改的改。

有个细节值得说：有些 WAF 或安全网关会主动修改 Server 头，把它替换成自己的标识。这反而暴露了你用了哪家 WAF。安全产品本身成了指纹来源，这事挺讽刺的。

别只盯着一个头

Server 头泄露框架信息是个老问题，老到很多人已经不当回事了。但我在实际渗透测试里，每次看到精确到小版本号的 Server 头，还是会优先把它记下来。因为它省时间。

防守方要做的不是只改一个配置项，而是把所有对外响应里可能暴露技术栈的信息都过一遍。响应头、错误页面、静态资源路径、Cookie 名称、甚至 HTML 注释里的版本号，都是拼图的一部分。攻击者不需要每块拼图都拿到，拿到两三块就够定位方向了。

改起来不费劲，不改就是白送情报。这笔账不用算太久。