Apache HTTP Server 的 mod_status 模块默认会注册一个名为 server-status 的状态处理器，通过该处理器，管理员可以查看服务器当前的请求处理情况、工作进程状态和资源占用。该页面一旦对公网开放，就相当于把服务器内部运行细节直接展示给了任何访客。许多攻击者会在扫描阶段主动请求 /server-status，如果返回 200，他们就能获取大量可用于后续渗透的敏感信息。因此，对 server-status 页面做访问控制和安全加固是 Apache 上线前必须完成的一项工作。
下面结合 Apache 2.4 的配置语法，从信息泄露风险、来源限制、路径隐藏、信息裁剪和验证排查几个维度展开说明。
一、server-status 页面会泄露哪些信息
当 mod_status 模块被启用时，访问 /server-status 会输出一个 HTML 页面。默认情况下，页面中会包含服务器版本、启动时间、当前运行时间、总访问量、CPU 使用率，以及每个工作进程的 PID、状态、客户端 IP、正在请求的 URL、虚拟主机和传输字节数等信息。如果开启了 ExtendedStatus，还会展示更详细的请求头、处理时间和最近请求列表。这些内容对运维监控很有价值，但对攻击者而言，等于直接提供了一张服务器内部拓扑和业务请求清单。
例如，攻击者可以从当前请求列表中看到后台管理地址、API 路径、用户正在访问的文件名，甚至带有会话参数的 URL。服务器版本和模块列表还能帮助攻击者快速匹配已知漏洞，例如 Apache 特定版本或 OpenSSL 版本的弱点。即使没有立即利用，这些信息也大幅降低了攻击者的侦察成本。因此，将 server-status 默认设置为仅本机或内网可访问是基本安全要求。
下面是一个未做任何限制的常见配置片段，它会让 /server-status 对任意来源开放：
<Location /server-status>
SetHandler server-status
Require all granted
</Location>
这种配置在测试环境中很常见，但如果不加修改直接部署到生产环境，风险会直接暴露。
二、基于来源 IP 限制访问
Apache 2.4 使用 Require 指令进行访问控制。要限制 server-status 页面只允许可信 IP 或内网访问，需要在 <Location> 块中明确指定允许的地址，并将默认策略改为拒绝。常用的写法如下：
<Location /server-status>
SetHandler server-status
Require ip 127.0.0.1
Require ip 192.168.0.0/16
Require ip 10.0.0.0/8
Require ip 172.16.0.0/12
Require ip 203.0.113.10
</Location>
多个 Require ip 指令是逻辑或的关系，只要客户端来源 IP 匹配其中任意一个即允许访问。最后没有加 Require all denied 时，Apache 默认会拒绝未匹配的请求，但显式写上可以让策略更清晰，也便于后续维护。对于只有固定公网 IP 的办公网络，可以将其添加到允许列表；对于通过堡垒机访问的情况，只需放行堡垒机 IP。
另一个容易忽略的问题是反向代理。当 Apache 位于 Nginx、负载均衡或 CDN 之后时，Apache 看到的来源 IP 是代理服务器的 IP，而不是真实客户端 IP。此时如果只放行内网代理 IP，可能导致所有通过代理的请求都能访问状态页，或者误拦来自内网的真实管理请求。正确做法是启用 mod_remoteip，将代理服务器地址加入可信代理列表，让 Apache 识别 X-Forwarded-For 中的真实 IP，然后再使用 Require ip 控制来源。这样可以避免因为代理架构而削弱访问控制。
三、隐藏状态页路径与减少信息输出
默认的 /server-status 路径很容易被扫描器发现。即使配置了 IP 限制，也仍然会返回 403，从而暴露该站使用了 Apache 且存在这个状态页。更好的做法是将状态页路径修改为一个难以猜测的随机字符串，例如 /server-status-8f3a2b 或 /internal-health-9d41c2。配置方式如下：
<Location /server-status-8f3a2b>
SetHandler server-status
Require ip 127.0.0.1
Require ip 192.168.0.0/16
</Location>
路径隐藏本身不能替代访问控制，但可以增加攻击者发现和利用的难度。如果扫描器不知道这个随机路径，自然不会收到 403 响应，也就无法确认状态模块的存在。配合防火墙层面的端口限制，可以形成纵深防御。
此外，Apache 的 ExtendedStatus 选项默认在部分发行版中是开启的，它会输出更详细的请求表和客户端信息。如果只需要基础负载数据，可以在全局配置中关闭扩展状态：
# 关闭扩展状态，减少请求细节输出 ExtendedStatus Off
关闭后，状态页仍会显示服务器运行时长、总请求数、每秒请求数和进程状态，但不会列出每个请求的完整 URL、客户端地址和请求头，从而在需要保留状态页时进一步降低信息泄露风险。对于必须保留详细请求信息的场景，建议将状态页访问范围控制在极少数管理 IP，并通过 HTTPS 访问。
四、常见配置错误与验证方法
很多配置不生效的根因是使用了错误的配置块。比如将 Require ip 放在 <Directory> 中，而不是 <Location> 中。<Directory> 针对的是文件系统路径，而 server-status 是虚拟 URL，不映射到实际目录，因此基于目录的限制不会对它生效。下面是一个错误示例和正确示例的对比：
# 错误：Directory 不会拦截 server-status URL
<Directory /var/www/html>
Require all granted
</Directory>
# 正确：使用 Location 精确匹配状态页
<Location /server-status>
SetHandler server-status
Require ip 127.0.0.1
</Location>
另一个常见问题是 Apache 2.2 与 2.4 语法混用。部分旧资料中会出现 Order allow,deny 和 Allow from 127.0.0.1，这些指令在 2.4 版本中虽然仍可能被兼容，但容易出现逻辑反转问题。建议统一使用 Require 指令，并在测试环境验证后再上线。
完成配置后，可以从外部服务器执行以下命令验证：
curl -I http://your-domain.com/server-status # 预期返回 HTTP/1.1 403 Forbidden
如果返回 200，需要检查 mod_status 是否被加载、Location 路径是否匹配、以及 Require 是否覆盖了所有来源。还可以查看 Apache 错误日志中的 access 记录，确认状态页的访问来源。对于已上线站点，建议使用自动化脚本定期从不同来源探测 /server-status，一旦检测到非 403 状态立即触发告警。
综合来看，server-status 信息泄露风险可以通过来源限制、路径隐藏、信息裁剪和持续监控四层措施得到有效控制。管理员应根据业务实际决定是否保留该页面，并在每次更新 Apache 版本或调整代理架构后重新验证配置是否仍然生效。安全配置不是一次性动作，而是需要与运维流程结合持续维护。
Apache server-status信息泄露安全防护配置修改时间：2026-10-02 16:08:25