开启Basic Auth后，/nginx_status页面需认证导致监控失效，应通过auth_basic off配合IP白名单或专用认证账号解决，并注意Nginx访问控制顺序与测试验证。
开启 Basic Auth 后，Nginx 的
页面会要求认证，导致 Zabbix、Prometheus 等监控系统无法直接拉取指标。这不是配置错误，而是认证机制与自动化采集逻辑天然冲突——监控工具默认不带认证头，会收到 401 响应，指标采集就断了。
单独为状态页面绕过 Basic Auth
最稳妥的做法是：在启用全局 Basic Auth 的前提下，对
路径做例外处理，允许监控服务器 IP 直接访问，不弹认证框。
确保
已编译启用（主流发行版默认包含）
在对应 server 或 location 块中明确声明 status 路径，并用
关闭认证
配合 IP 白名单进一步限制，只放行 Zabbix Server、Prometheus 实例等可信来源
示例配置：
location /nginx_status {stub_status on;access_log off;auth_basic off;allow 192.168.10.5; # Zabbix Server IPallow 192.168.10.12; # Prometheus IPdeny all;}
用专用账号+基础认证头供监控系统使用
如果安全策略强制所有路径必须认证（例如审计要求），那就给监控系统配一个只读专用账号，让它带上
请求头。
用
创建独立账号，比如
，密码单独保管
Zabbix 中配置 Web scenario 时，在 HTTP headers 里添加
Prometheus 配合
时，通过
指定带认证的 URL，如
注意：URL 中明文写密码仅适用于本地回环或内网可信环境；生产环境建议改用 bearer token 或反向代理前置认证。
Nginx
在宝塔面板中轻松管理Nginx高性能Web服务器。提供可视化配置反向代理、负载均衡、SSL证书及HTTP缓存功能，一键优化高并发性能，助您高效搭建稳定、快速的网站运行环境。
下载
避免混用 auth_basic 和 allow/deny 的逻辑陷阱
Basic Auth 和 IP 访问控制不是互斥的，但顺序和作用域容易出错。Nginx 按 location 匹配优先级执行，且
在 access 阶段生效，早于
判断。
不要在一个 location 里既写
又写
，除非你明确需要“先认证再校验IP”
更推荐分层设计：外层用 IP 控制谁有资格发起请求，内层（如 API 路径）再加 Basic Auth 做身份区分
测试时用
查看响应头，确认返回的是 200 还是 401/403
验证监控连通性前先手动模拟采集行为
别等 Zabbix 报警才排查。上线前，用监控系统实际使用的身份去测一次：
Zabbix Server 上执行：
（若走本机采集）
或者模拟远程采集：
检查输出是否为标准 stub_status 格式（含
等字段），而非 HTML 登录页或 401 响应体
只要返回原始文本指标，监控系统就能正常解析。格式不对或被重定向，基本就是认证或路由配置没对上。
/nginx_status/nginx_statushttp_stub_status_moduleauth_basic offAuthorization: Basic xxxhtpasswdmonitorAuthorization: Basic base64(“monitor:xxx”)nginx_exporter--nginx.scrape-urihttp://monitor:pass@localhost/nginx_statusauth_basicallow/denyauth_basic onallowcurl -I http://host/nginx_statuscurl -s http://127.0.0.1/nginx_statuscurl -s --user monitor:xxx http://nginx-host/nginx_statusActive connections