Apache的mod_status模块会生成一个HTML页面，默认路径是/server-status。启用后，访问该地址可以看到服务器版本、当前时间、运行时长、总访问量、CPU使用率、每秒请求数、当前连接和空闲工作进程等数据。更关键的是，页面中会列出正在处理的请求列表，包括客户端IP、请求方法、URL路径、协议版本、处理阶段和耗时。如果Web应用把会话标识、临时令牌或内部接口名称拼在URL里，这些信息会直接出现在状态页上。攻击者通过反复刷新，可以拼出后端路由结构，甚至捕捉到其他用户正在访问的敏感路径。
除了请求详情，Server Version字段还会暴露Apache的具体版本号以及编译模块列表。结合已知漏洞库，攻击者可以快速筛选可用的利用脚本。另外，状态页默认可能允许刷新频率很高，如果未做限制，频繁请求server-status本身也会消耗服务器资源。因此保护该页面不只是避免信息泄露，也是防止被用作简单的拒绝服务放大点。要判断风险等级，可以先在本地执行curl -I http://127.0.0.1/server-status观察返回码。如果出现200或404以外的异常，都值得检查配置。
一、server-status页面泄露了哪些敏感信息
server-status页面由mod_status模块生成，它的本意是方便运维人员观察Apache工作进程的实时状态。页面内容分为几个区域，包括服务器运行时间、启动时间、总请求数、空闲工作进程数、当前连接数以及正在被处理的请求详情。请求详情部分会显示每个连接的客户端来源地址、请求方法、请求的URL路径、协议版本和处理状态。这些信息在多人共享的Web服务器上尤其敏感，因为一个普通访问者的请求路径很可能包含登录令牌、下载凭证或内部API名称。
另一个容易被忽视的问题是服务器版本信息。server-status页面顶部通常会显示Apache的精确版本号以及加载的模块列表，例如Apache/2.4.54 (Unix)。攻击者看到这些信息后，可以直接根据对应版本的已知漏洞进行尝试，省去了大量探测时间。即使没有直接漏洞，模块列表也能帮助判断服务器是否启用了PHP、SSL、重写等模块，从而推测可能的攻击面。因此，未加保护的server-status页面相当于把服务器内部结构主动展示给任何人。
除了信息泄露，频繁刷新server-status页面还会增加服务器开销。因为每次请求都要遍历活动连接、统计请求计数和CPU负载，如果攻击者以较高频率抓取，可能加剧CPU和内存消耗。虽然单次请求开销不大，但在高并发攻击场景下，这种状态页可能被用作消耗资源的辅助手段。所以即便是内网环境，也建议对状态页的访问频率做适当控制，或直接禁用不必要的状态展示。
二、使用Location指令实现基于IP的访问控制
Apache控制server-status访问最常用的方式是借助Location容器。它按URL路径匹配，而不是按文件系统路径匹配，非常适合处理这种虚拟路径。配置片段如下：
<Location /server-status>
SetHandler server-status
Require ip 127.0.0.1
Require ip 192.168.1.0/24
Require ip 10.0.0.0/8
</Location>
上面这段配置把状态页限制为仅允许本机回环地址、192.168.1.0/24网段和10.0.0.0/8私网网段访问。Require指令来自mod_authz_core，在Apache 2.4及以上版本中替代了旧的Allow from和Deny from语法。多个Require ip行默认是或的关系，只要来源IP命中其中一条就放行。若希望同时满足多个条件，可用RequireAll包裹。IP段写CIDR格式即可，不需要额外的子网掩码参数。
如果服务器处于NAT之后，或者在负载均衡器后面，直接限制来源IP会遇到问题：Apache看到的来源地址是反向代理的内网地址，而不是真实客户端。此时需要先加载mod_remoteip模块，把代理传递的X-Forwarded-For还原成真实客户端IP，再执行Require控制。否则配置成只允许192.168.1.0/24后，所有经过代理的请求都可能被误拦或误放。配置示例如下：
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 10.0.0.0/8
<Location /server-status>
SetHandler server-status
Require ip 203.0.113.0/24
</Location>
上面的RemoteIPHeader指定了从哪个请求头读取真实地址，RemoteIPInternalProxy声明哪些代理地址可以被信任。修改后需要重启或重载Apache服务。对于Windows环境，重载命令可能是httpd.exe -k restart；对于Linux环境，常用systemctl reload httpd或apachectl graceful。注意不要把RemoteIPInternalProxy配置成0.0.0.0/0，否则攻击者可以伪造X-Forwarded-For绕过IP限制。
三、叠加基础认证提升保护强度
仅靠IP白名单有时不够。例如运维人员需要从咖啡厅、机场等动态IP环境临时查看状态页，或者公司出口IP不固定，此时可以在IP限制之外叠加HTTP基础认证。基础认证会要求访问者输入用户名和密码，即便来源IP发生变化，也能保证只有掌握凭据的人可以查看。配置方式需要在Apache中创建密码文件，并在Location容器中增加认证指令。
先用htpasswd工具生成密码文件，命令如下。注意htpasswd位于Apache的bin目录，Windows下路径可能是C:\Apache24\bin\htpasswd.exe，Linux下通常为/usr/bin/htpasswd。生成密码文件时建议使用bcrypt算法，避免使用已经过时的crypt或MD5。
# 创建密码文件并新增用户opsviewer htpasswd -c -B /etc/apache2/status-passwd opsviewer # 如果文件已存在，去掉-c避免覆盖 htpasswd -B /etc/apache2/status-passwd anotheruser
然后在配置中同时使用Require ip和认证。注意Apache的认证和授权是分层的：AuthType设置认证方式，AuthName是提示信息，AuthUserFile指向密码文件，Require valid-user表示通过认证的合法用户即可访问。若还要叠加IP限制，可以用RequireAll把多个条件组合成与的关系。
<Location /server-status>
SetHandler server-status
AuthType Basic
AuthName "Server Status Area"
AuthUserFile /etc/apache2/status-passwd
<RequireAll>
Require ip 127.0.0.1
Require valid-user
</RequireAll>
</Location>
这样表示来源IP必须是127.0.0.1，同时必须通过密码认证。如果希望同网段内任意一台机器访问但需要密码，可以把Require ip改成网段。如果临时需要从公网访问，可以在RequireAll中增加一条公网IP白名单，但更安全的做法是使用VPN接入内网后再访问，避免在公网上暴露密码提示窗口。
四、修改路径、禁用模块与验证方法
如果团队根本不使用server-status，最彻底的方案是直接禁用mod_status模块。在Apache配置中注释掉或删除LoadModule status_module modules/mod_status.so这一行，然后重启服务即可。这样即使有人猜测/server-status路径，也会得到404响应。但需要注意的是，某些监控系统或面板可能依赖mod_status，禁用前最好确认没有采集任务。对于必须保留状态页的场景，也可以把默认路径改为不易猜测的地址，例如/internal-status-9f3k2，降低被扫描器发现的概率。
修改路径的方法是在配置中写入新的Location路径，并设置SetHandler server-status。修改后旧的/server-status不会自动跳转，而是直接404。示例如下：
<Location /internal-status-9f3k2>
SetHandler server-status
Require ip 127.0.0.1
</Location>
隐藏路径只是提高发现成本，不能替代访问控制。搜索引擎、日志泄露、浏览器历史、Referer头都可能把新路径暴露出去。因此即使改了路径，仍然要保留IP限制或认证。配置完成后，应使用curl配合自定义Host头和来源模拟来验证保护是否生效。下面几条命令可以检查不同场景：
# 本机回环地址访问，应返回200 curl -I http://127.0.0.1/server-status # 使用伪造的X-Forwarded-For绕过测试，若未启用mod_remoteip则可能被误判 curl -I -H "X-Forwarded-For: 127.0.0.1" http://10.0.0.5/server-status # 查看是否出现403 Forbidden curl -I http://10.0.0.5/server-status
其中curl -I只请求响应头，适合快速判断状态码。如果要看页面内容是否包含服务器版本，可以改用curl http://127.0.0.1/server-status | head -n 20。在公网VPS上测试时，务必确认防火墙或安全组没有把Apache端口暴露给0.0.0.0/0，否则仅靠Apache配置可能还不够。最后，建议把server-status保护配置纳入自动化巡检，定期用脚本请求状态页并检查返回码是否为预期值，防止因配置回滚或迁移导致防护失效。
Apache server-status访问控制服务器安全修改时间：2026-09-27 17:24:00