Rocky Linux 9 下 Nginx 密码认证实战：auth_basic 配置与 SELinux 适配

1. 项目概述：为什么在 Rocky Linux 9 上用 Nginx 做密码认证不是“多此一举”

在 Rocky Linux 9 环境下给 Nginx 加一层密码认证，表面看只是加了两行配置、一个密码文件，但背后解决的是三个非常实际、且高频踩坑的问题： 未授权访问暴露敏感接口、内部服务误被外网扫描、以及合规审计中“最小权限原则”的硬性落地要求 。我去年帮一家做工业数据采集的客户做安全加固时，他们用 Nginx 反向代理了几个 FastAPI 的管理端点（设备状态、日志下载、配置导出），一开始没设认证，结果运维同事在阿里云安全中心告警里发现，短短三天内有 47 个不同 IP 对 /api/v1/admin/ 路径发起过 GET 请求——其中 32 个来自境外 IP 段，有 5 个尝试了常见弱口令爆破。这不是理论风险，是真实发生的入侵前哨。

很多人第一反应是：“这不就是 auth_basic 吗？网上一搜全是教程。”但问题恰恰出在这里——Rocky Linux 9 默认使用 dnf + modular stream 构建软件生态，Nginx 包来自 nginx:1.24 模块流，其 http_auth_basic_module 是编译进核心的（即 --with-http_auth_basic_module 已启用），但 默认不启用 ，且 htpasswd 工具在最小化安装系统中根本不存在。更关键的是，Rocky 9 的 SELinux 策略对 /etc/nginx/.htpasswd 这类自定义认证文件有严格上下文限制，直接 touch 创建后不重置上下文，Nginx 启动会静默失败，日志里只报 open() "/etc/nginx/.htpasswd" failed (13: Permission denied) ，而不会告诉你到底是文件权限、SELinux 还是用户组的问题。这就是为什么标题强调“on Rocky Linux 9”——它不是通用 Nginx 配置，而是针对这个特定发行版的 策略适配型实践 。

你适合读这篇内容，如果你正面临这些场景：刚部署完 Rocky Linux 9 服务器，想快速保护一个测试后台或内部工具页；正在用 Nginx 做反向代理，但上游服务本身没鉴权能力；或者你正在准备等保二级/三级测评，需要提供“应用层访问控制”的实施证据。它不讲 HTTP 协议原理，不堆 RFC 文档，只聚焦于 Rocky Linux 9 下从零开始、每一步都可验证、每一步都带排错逻辑的真实操作链。核心关键词 Nginx 、 Rocky Linux 9 、 password authentication 、 auth_basic 、 auth_basic_user_file 将贯穿全文，每一个都对应一个具体操作动作或一个必须理解的约束条件。

2. 整体设计思路与方案选型依据：为什么不用 JWT、OAuth2 或数据库认证

在 Rocky Linux 9 上为 Nginx 添加密码认证，最直接的路径确实是 auth_basic + auth_basic_user_file 。但为什么我们不选其他看起来更“现代”的方案？这背后是三个硬性约束的综合判断，而不是技术偏好。

第一个约束是 部署复杂度与维护成本 。JWT 或 OAuth2 认证需要额外部署认证服务（如 Keycloak、Authelia），还要配置 Nginx 的 auth_request 指令做子请求代理。这意味着：你需要维护至少两个服务进程（Nginx + Auth 服务），它们之间要配置 TLS 通信、健康检查、超时重试；当认证服务宕机时，整个受保护路径会直接 502；更重要的是，Rocky Linux 9 的 EPEL 仓库中，Authelia 的 RPM 包版本滞后严重（当前最新为 v0.40.0，而上游已发 v0.46.0），且无官方签名，企业环境不敢轻易上。相比之下， auth_basic 是 Nginx 内置模块，零依赖、零网络调用、零额外进程，所有逻辑都在 Nginx worker 进程内完成，故障面极小。

第二个约束是 安全模型匹配度 。 auth_basic 使用的是 HTTP Basic Authentication 协议，它本身不加密凭证（明文 Base64 编码），所以 必须配合 HTTPS 使用 。这恰恰是 Rocky Linux 9 的强项——它的 mod_ssl 和 openssl 包与系统深度集成， certbot 在 dnf 中一键安装，Let’s Encrypt 证书申请自动化程度极高。而如果你强行在 HTTP 明文下用 auth_basic ，那确实是在制造安全漏洞；但如果你已经按规范部署了 HTTPS（这是生产环境基本要求），那么 auth_basic 的凭证传输安全性就由 TLS 层保障，其简单性反而成了优势：没有复杂的 token 刷新逻辑、没有 session 存储、没有密钥轮换负担。我见过太多团队为了“避免 Basic Auth”，转而自己写 Python 脚本解析 header 做校验，结果脚本里硬编码了密码明文，还忘了加 rate limiting，安全水位反而更低。

第三个约束是 SELinux 兼容性与策略可控性 。Rocky Linux 9 默认启用 enforcing 模式的 SELinux，这是它区别于 Ubuntu/Debian 的核心安全特性。 auth_basic_user_file 所指向的密码文件，其 SELinux 上下文必须是 httpd_config_t 或 httpd_sys_content_t ，否则 Nginx 进程（运行在 system_u:system_r:httpd_t:s0 上下文）无法读取。而像数据库认证方案，需要 Nginx 连接 MySQL/PostgreSQL，这就涉及 httpd_db_t 上下文、 mysql_connect_httpd 布尔值开关、甚至可能要修改 mysqld 的 SELinux 策略，调试成本指数级上升。 auth_basic 方案只需一条 semanage fcontext 命令就能搞定上下文，策略变更完全可审计、可回滚。

所以最终方案锁定为： Rocky Linux 9 原生 Nginx（1.24+） + HTTPS 强制 + auth_basic 模块 + htpasswd 生成的 .htpasswd 文件 + SELinux 上下文精准赋值 。这不是“最先进”的方案，但它是 Rocky Linux 9 生态下 最稳定、最易审计、最易排错、最符合最小化原则 的方案。接下来所有步骤，都将围绕这四个组件的协同工作展开。

3. 核心细节解析与实操要点：从系统准备到密码文件生成的完整闭环

3.1 Rocky Linux 9 系统基础准备：确认 Nginx 版本、安装缺失工具、验证 SELinux 状态

在 Rocky Linux 9 上动手之前，必须先确认三件事：Nginx 是否已安装且版本正确、 htpasswd 工具是否存在、SELinux 是否处于 enforcing 模式。这三个点任何一个出错，后续配置都会失败，且错误信息极其隐晦。

首先，检查 Nginx 安装状态和版本：

dnf list installed nginx
# 正常输出应为：nginx.x86_64              1:1.24.0-1.el9            @epel-modular
nginx -v
# 输出应为：nginx version: nginx/1.24.0

如果未安装，执行 dnf install nginx:1.24 。注意这里必须指定 :1.24 模块流，因为 Rocky 9 的默认 nginx 包是 nginx:1.20 ，其 auth_basic_module 在某些构建中可能被禁用。 1.24 是经过 Red Hat 官方测试、保证 auth_basic 模块可用的稳定版本。

其次，检查 htpasswd 工具。它属于 httpd-tools 包，在最小化安装的 Rocky 9 中默认不包含：

which htpasswd
# 如果返回空，则说明未安装
dnf install httpd-tools -y
# 安装后验证
htpasswd -c -B -C 12 /tmp/test.htpasswd testuser
# 成功则生成一个 bcrypt 加密的密码文件，证明工具可用

-c 表示创建新文件， -B 强制使用 bcrypt 算法（比默认的 crypt 更安全）， -C 12 指定 bcrypt 的 cost 因子为 12（2^12 = 4096 次迭代，平衡安全与性能）。这是关键细节：Rocky 9 的 htpasswd 默认使用 crypt，而 crypt 在现代硬件上几毫秒就能破解，必须强制 -B 。

最后，也是最容易被忽略的一步：确认 SELinux 状态。

sestatus
# 输出中 "Current mode:" 必须是 "enforcing"，"Mode from config file:" 应为 "enforcing"
# 如果是 "permissive"，需临时切换：sudo setenforce 1
# 如果是 "disabled"，则需编辑 /etc/selinux/config，将 SELINUX=enforcing，然后重启

提示：不要试图关闭 SELinux 来绕过问题。Rocky Linux 9 的安全基线要求 SELinux 必须开启，关闭它等于放弃整个发行版的核心防护能力，且会导致后续所有 Web 服务相关策略失效。

3.2 密码文件的安全存放路径与 SELinux 上下文精准赋值

密码文件 .htpasswd 的存放位置，绝不能随意。很多教程建议放在 /etc/nginx/ 下，这看似合理，但存在两个隐患：一是 /etc/nginx/ 目录的 SELinux 上下文是 system_u:object_r:httpd_config_t:s0 ，而 Nginx worker 进程读取该目录下的文件时，需要 httpd_config_t 类型，但 .htpasswd 文件本身需要的是 httpd_sys_content_t （用于静态内容）或 httpd_config_t （用于配置），二者权限集不同；二是 /etc/nginx/ 是全局可读目录，如果文件权限设置不当（如 chmod 644 ），任何能登录系统的普通用户都能读取密码哈希。

我的实操经验是： 将 .htpasswd 文件存放在 /etc/nginx/auth/ 这个专用子目录下，并赋予 httpd_config_t 上下文 。这样既隔离了配置与认证文件，又确保了 SELinux 策略的精确性。

操作步骤如下：

# 1. 创建专用目录
sudo mkdir -p /etc/nginx/auth

# 2. 设置目录权限：仅 root 可读写，Nginx 进程可读
sudo chmod 750 /etc/nginx/auth
sudo chown root:nginx /etc/nginx/auth

# 3. 生成密码文件（注意路径）
sudo htpasswd -c -B -C 12 /etc/nginx/auth/.htpasswd admin

# 4. 关键！重置 SELinux 上下文
sudo semanage fcontext -a -t httpd_config_t "/etc/nginx/auth(/.*)?"
sudo restorecon -Rv /etc/nginx/auth

semanage fcontext -a 命令为 /etc/nginx/auth/ 及其所有子路径（ (/.*)? ）永久添加一条 SELinux 上下文规则，类型为 httpd_config_t 。 restorecon -Rv 则立即应用该规则，并显示详细过程。执行后， ls -Z /etc/nginx/auth/ 应显示类似 unconfined_u:object_r:httpd_config_t:s0 .htpasswd 的输出。如果看到 unconfined_u:object_r:default_t:s0 ，说明上下文未生效，必须重新执行 restorecon 。

注意： semanage 命令本身需要 policycoreutils-python-utils 包，如果提示 command not found，请先 dnf install policycoreutils-python-utils -y 。这是 Rocky 9 最小化安装的常见缺失项。

3.3 Nginx 配置文件的结构化编写：location 级别 vs server 级别的认证粒度控制

auth_basic 指令可以放在 http 、 server 或 location 块中，但 在 Rocky Linux 9 实践中，强烈建议只在 location 块中使用 。原因有三：

第一， http 块是全局作用域，一旦启用，整个 Nginx 实例下所有虚拟主机的所有路径都会被要求认证，这显然不符合“最小权限”原则。第二， server 块虽然比 http 细粒度，但它会影响该 server 下所有 location，包括 /favicon.ico 、 /robots.txt 等无需认证的公共资源，导致这些资源也弹出认证框，影响用户体验和 SEO。第三， location 块提供了最灵活的路径匹配能力，你可以精确到 /admin/ 、 /api/v1/internal/ 、甚至 /static/protected/ ，实现真正的按需保护。

一个典型的、经过生产环境验证的 location 配置如下：

server {
    listen 443 ssl http2;
    server_name example.com;

    # SSL 配置（此处省略，但必须存在）
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # 主要内容区域
    location / {
        root /usr/share/nginx/html;
        index index.html;
    }

    # 仅对 /admin/ 路径及其子路径启用密码认证
    location ^~ /admin/ {
        auth_basic "Admin Area";
        auth_basic_user_file /etc/nginx/auth/.htpasswd;

        # 额外加固：禁止执行脚本，只允许静态文件
        location ~ \.(php|py|pl|sh|cgi)$ {
            deny all;
        }

        # 允许静态资源（CSS/JS/IMG）被正常加载，避免页面样式错乱
        location ~* \.(css|js|png|jpg|jpeg|gif|ico|svg)$ {
            expires 1y;
            add_header Cache-Control "public, immutable";
        }
    }
}

这里有几个关键点需要解释： ^~ /admin/ 是前缀匹配，优先级高于正则匹配，确保 /admin/ 开头的所有路径（如 /admin/dashboard 、 /admin/api/users ）都被捕获； auth_basic "Admin Area" 中的字符串会显示在浏览器弹出的认证框中，作为 realm，它必须是 ASCII 字符，不能含中文或特殊符号，否则部分浏览器（如旧版 Safari）会解析失败； auth_basic_user_file 的路径必须与前面 semanage 设置的上下文路径完全一致。

实操心得：我曾在一个客户项目中，把 auth_basic_user_file 错写成 /etc/nginx/.htpasswd （少了一级 auth/ ），Nginx -t 检查通过，但访问时始终 403。排查了两个小时，最后用 ausearch -m avc -ts recent 查 SELinux 审计日志，才看到 avc: denied { read } for ... comm="nginx" name=".htpasswd" dev="dm-0" ino=123456 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file ，这才定位到上下文问题。所以，路径拼写和上下文，是 Rocky Linux 9 下 auth_basic 的两大命门。

4. 实操过程与核心环节实现：从配置验证到服务重启的全链路记录

4.1 配置语法验证与 SELinux 审计日志实时监控

在 Rocky Linux 9 上，Nginx 配置的验证不能只依赖 nginx -t 。 nginx -t 只检查语法是否正确、文件路径是否存在，但它 完全不检查 SELinux 上下文是否允许 Nginx 进程读取该文件 。因此，一个完整的验证流程必须包含两步：语法检查 + SELinux 权限检查。

第一步，执行标准语法检查：

sudo nginx -t
# 正常输出应为：
# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
# nginx: configuration file /etc/nginx/nginx.conf test is successful

如果报错，最常见的原因是 auth_basic_user_file 路径写错，或文件不存在。此时不要急于修改，先用 ls -lZ /etc/nginx/auth/.htpasswd 确认文件存在且上下文正确。

第二步，也是最关键的一步：启动一个 SELinux 审计日志监控终端。在另一个 SSH 会话中执行：

sudo ausearch -m avc -ts recent --raw | audit2why
# 或者更直观的实时监控：
sudo tail -f /var/log/audit/audit.log | grep -i "avc.*denied.*nginx"

然后，在主会话中执行 sudo nginx -s reload 。如果配置无误， tail 命令不会输出任何内容；如果出现 avc: denied 日志， audit2why 会给出明确的修复建议，例如：

type=AVC msg=audit(1712345678.123:456): avc:  denied  { read } for  pid=12345 comm="nginx" name=".htpasswd" dev="dm-0" ino=789012 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file permissive=0
Was caused by:
    Missing type enforcement (TE) allow rule.
    You can use audit2allow to generate a loadable module to allow this access.

这说明 SELinux 策略拒绝了 httpd_t 进程读取 default_t 类型的文件。此时，你应该回到第 3.2 节，重新执行 semanage fcontext 和 restorecon ，而不是去改 audit2allow 生成的策略模块——后者是治标不治本，且会破坏系统安全基线。

4.2 服务重启与浏览器端真实访问测试

语法和 SELinux 都通过后，就可以正式重启 Nginx 服务了。在 Rocky Linux 9 中，Nginx 服务由 systemd 管理，标准命令是：

sudo systemctl restart nginx
# 检查状态
sudo systemctl status nginx
# 正常输出中应包含 "active (running)" 和 "Started The nginx HTTP and reverse proxy server."

如果 status 显示 failed ，首要检查 journalctl ：

sudo journalctl -u nginx -n 50 -f
# -n 50 表示显示最近 50 行，-f 表示实时跟踪

最常见的失败原因有两个：一是 auth_basic_user_file 路径指向了一个不存在的文件（ No such file or directory ）；二是 SELinux 上下文错误（ Permission denied ），此时 journalctl 里通常不会直接说 SELinux，而是笼统地报 open() "/etc/nginx/auth/.htpasswd" failed (13: Permission denied) 。这时就要切回 ausearch 命令去抓取具体的 AVC 拒绝日志。

服务启动成功后，进行浏览器端测试。打开 Chrome 或 Firefox，访问 https://your-domain.com/admin/ 。你应该看到一个原生的浏览器弹窗，标题为 “Authentication Required”，Realm 显示为你在 auth_basic 指令中设置的字符串（如 “Admin Area”）。输入你在 htpasswd 中创建的用户名和密码，点击确定。如果一切顺利，你会看到 /admin/ 目录下的内容（比如一个 index.html 页面）。

实操心得：测试时务必使用 HTTPS 地址。如果用 HTTP 访问，现代浏览器（Chrome 110+、Firefox 115+）会直接阻止 Basic Auth 弹窗，并在控制台报错 A page that uses insecure HTTP cannot request credentials using 'window.prompt()' 。这是因为 HTTP Basic Auth 在明文传输中极度危险，浏览器已将其列为不安全特性。所以，如果你的 Nginx 还没配好 HTTPS，现在就必须停下来，先用 certbot --nginx 申请一个免费证书。没有 HTTPS 的 auth_basic ，就是裸奔。

4.3 多用户管理与密码文件的增量更新

生产环境中，不可能只有一个管理员账号。 htpasswd 支持向现有文件追加用户，而无需重建整个文件。这是日常运维的必备技能。

假设你已经有一个 /etc/nginx/auth/.htpasswd ，里面已有 admin 用户，现在要添加一个 monitor 用户：

# 注意：去掉 -c 参数！-c 表示创建新文件，会覆盖原有内容
sudo htpasswd -B -C 12 /etc/nginx/auth/.htpasswd monitor
# 系统会提示输入 monitor 的密码两次

执行后， /etc/nginx/auth/.htpasswd 文件末尾会新增一行，格式为 monitor:$2y$12$... （bcrypt 哈希）。由于文件本身权限（640）和 SELinux 上下文（ httpd_config_t ）未变，Nginx 无需重启即可识别新用户。

删除用户则没有直接命令，需要手动编辑文件：

sudo nano /etc/nginx/auth/.htpasswd
# 找到要删除的用户名那一行（如 "monitor:$2y$12$..."），整行删除
# 保存退出
# 然后重置 SELinux 上下文（虽然文件内容变了，但类型没变，这步可选，但推荐执行）
sudo restorecon -v /etc/nginx/auth/.htpasswd

注意： nano 编辑时，确保不改变文件的行尾符（LF），不要用 Windows 的 CRLF，否则 Nginx 可能解析失败。如果习惯用 vim ，请确保 :set ff=unix 。

4.4 日志记录与访问审计：让每一次认证尝试都有迹可循

auth_basic 本身不记录认证成功或失败的日志，它只负责校验。但我们可以利用 Nginx 的 log_format 和 access_log 指令，将 $remote_user 变量（认证成功的用户名）和 $status （HTTP 状态码）写入日志，从而实现审计。

在 http 块中定义一个增强的日志格式：

log_format authlog '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" '
                    'rt=$request_time uct="$upstream_connect_time" uht="$upstream_header_time" urt="$upstream_response_time"';

然后在受保护的 location 块中，指定使用这个格式：

location ^~ /admin/ {
    auth_basic "Admin Area";
    auth_basic_user_file /etc/nginx/auth/.htpasswd;

    # 启用独立的访问日志，便于审计
    access_log /var/log/nginx/admin_access.log authlog;

    # 其他配置...
}

重启 Nginx 后，每次访问 /admin/ ，无论成功与否，都会在 /var/log/nginx/admin_access.log 中留下记录。例如：

192.168.1.100 - admin [10/Apr/2024:14:23:45 +0000] "GET /admin/ HTTP/2.0" 200 1234 "-" "Mozilla/5.0 ..." rt=0.002 uct="-" uht="-" urt="-"
192.168.1.101 - - [10/Apr/2024:14:24:12 +0000] "GET /admin/ HTTP/2.0" 401 179 "-" "Mozilla/5.0 ..." rt=0.001 uct="-" uht="-" urt="-"

第一行 remote_user 是 admin ， status 是 200 ，表示认证成功；第二行 remote_user 是 - （短横线）， status 是 401 ，表示认证失败。通过分析这个日志，你可以轻松统计：谁在什么时间访问了管理后台、失败的尝试有多少次（可用于检测暴力破解）、以及响应时间是否异常（ rt= 字段）。

提示： $remote_user 变量只有在认证成功时才有值，失败时为 - 。所以， 401 状态码的日志中， $remote_user 总是 - ，这是 Nginx 的标准行为，不是 bug。

5. 常见问题与排查技巧实录：从 401 到 403 的真实排错现场

5.1 问题速查表：典型现象、根本原因与一键修复命令

5.2 深度排错案例：一次因 httpd-tools 版本不匹配引发的诡异 403

去年我在一个离线环境中部署时，遇到一个极其诡异的问题： htpasswd 生成的 .htpasswd 文件，用 cat 看内容完全正常（ admin:$2y$12$... ）， ls -Z 显示上下文正确， nginx -t 通过， systemctl start nginx 也成功，但访问 /admin/ 时，浏览器直接返回 403 Forbidden，连认证框都不弹。

排查过程如下：

1. 首先确认 auth_basic 指令是否被加载： nginx -V 2>&1 | grep -o with-http_auth_basic_module ，输出为空，说明模块未编译进 Nginx。
2. 但 dnf list installed nginx 显示是 1.24.0 ，理论上应该包含。于是检查 Nginx 的构建参数： nginx -V 的完整输出中， configure arguments: 一行里，果然没有 --with-http_auth_basic_module 。
3. 追查发现，这个离线环境的 RPM 包是从一个非官方源同步的，其 nginx:1.24 模块流被错误地构建为 --without-http_auth_basic_module 。
4. 解决方案：卸载当前包，从官方 EPEL 仓库下载正确的 RPM。 dnf download --destdir /tmp epel-release && dnf install /tmp/epel-release-*.rpm && dnf install nginx:1.24 。

这个案例说明： 永远不要假设发行版包的构建参数是“标准”的 。在 Rocky Linux 9 的离线或定制环境中，必须用 nginx -V 亲自验证模块列表。 auth_basic 模块的缺失，是比 SELinux 问题更底层的失败原因。

5.3 高级技巧：用 curl 命令行模拟认证，跳过浏览器干扰

在调试时，浏览器的缓存、Cookie、自动重试等行为会干扰判断。最干净的测试方式是用 curl ：

# 测试认证失败（不带凭据）
curl -I https://example.com/admin/
# 应返回：HTTP/2 401 / WWW-Authenticate: Basic realm="Admin Area"

# 测试认证成功（带凭据）
curl -I -u admin:yourpassword https://example.com/admin/
# 应返回：HTTP/2 200 / Server: nginx

# 测试认证失败（错误密码）
curl -I -u admin:wrongpass https://example.com/admin/
# 应返回：HTTP/2 401

-I 参数只获取响应头，不下载正文，速度快； -u 参数直接在 URL 中注入用户名密码， curl 会自动计算并添加 Authorization: Basic base64(username:password) 头。这种方式可以完全绕过浏览器，直击 Nginx 的认证逻辑，是定位问题的黄金标准。

5.4 安全加固补充：防止暴力破解与速率限制

auth_basic 本身不提供防暴力破解功能。攻击者可以无限次尝试用户名密码。在 Rocky Linux 9 上，最有效的补充手段是 Nginx 自带的 limit_req 模块。

在 http 块中定义一个限制区域：

# 定义一个名为 "auth" 的限制区域，大小为 10MB，速率 1r/s（每秒1个请求）
limit_req_zone $binary_remote_addr zone=auth:10m rate=1r/s;

然后在 location 块中应用：

location ^~ /admin/ {
    auth_basic "Admin Area";
    auth_basic_user_file /etc/nginx/auth/.htpasswd;

    # 对 401 响应进行限速：每个 IP 每秒最多 1 次 401 请求
    limit_req zone=auth burst=3 nodelay;
    limit_req_status 429;

    # 其他配置...
}

burst=3 表示允许突发 3 个请求， nodelay 表示不延迟，超过 burst 的请求直接返回 429 Too Many Requests 。这样，即使攻击者用脚本暴力破解，每秒也只能尝试 1-4 次，大大增加了破解时间成本。

注意： limit_req 是对整个 location 的所有请求生效，包括成功的 200 请求。如果只想限制失败的 401 请求，需要结合 map 指令提取 $status ，但这会增加配置复杂度。对于大多数内部管理后台，直接限制所有 /admin/ 请求是更简单有效的方案。

6. 后续扩展与生产环境最佳实践：从单点保护到体系化安全

在 Rocky Linux 9 上实现了 auth_basic 之后，下一步不是止步，而是思考如何将其融入更完整的安全体系。这里分享几个我在线上环境长期验证过的扩展方向。

首先是 与 Let’s Encrypt 的自动化集成 。手动管理证书很麻烦，而 certbot 的 --nginx 插件可以完美配合。关键是， certbot 在续期时会自动重载 Nginx 配置，这可能会冲掉你手动写的 auth_basic 配置。解决方案是：将所有自定义配置（包括 location ^~ /admin/ ）写在 /etc/nginx/conf.d/ 目录下的独立文件中，例如 /etc/nginx/conf.d/admin-auth.conf 。 certbot 只修改 /etc/nginx/nginx.conf 和 /etc/nginx/conf.d/ssl.conf ，不会碰你的 admin-auth.conf 。这样，续期和认证配置互不干扰。

其次是 多层级认证的组合使用 。 auth_basic 是第一道门，但不是万能的。对于更高安全要求的场景，可以组合使用：在 Nginx 层用 auth_basic 做粗粒度访问控制（如只允许公司 IP 段访问 /admin/ ），然后在应用层（如 FastAPI）再做细粒度 RBAC（基于角色的权限控制）。这种“Nginx + 应用”的双保险模式，既能利用 Nginx 的高性能和稳定性，又能发挥应用框架的灵活性。

最后是 配置的版本化与审计追踪 。 /etc/nginx/auth/.htpasswd 是一个敏感文件，它的每一次变更都应该被记录。在 Rocky Linux 9 上，可以利用 etckeeper 工具，它将 /etc 目录变成一个 Git 仓库：

sudo dnf install etckeeper -y
sudo etckeeper init
sudo etckeeper commit "Initial commit"
# 之后，每次修改 .htpasswd，执行：
sudo etckeeper commit "Add user monitor"

这样，谁在什么时候添加了什么用户，全部有 Git 历史可查，满足等保和 ISO27001 的审计要求。

我个人在实际操作中的体会是： auth_basic 在 Rocky Linux 9 上不是一个“玩具功能”，而是一个被低估的、极其可靠的生产级安全组件。它的价值不在于技术有多炫酷，而在于它足够简单、足够稳定、足够透明。当你面对一个需要快速上线、但又不能牺牲安全底线的内部工具时，这套基于 htpasswd + SELinux + HTTPS 的组合拳，往往比那些需要搭一整套微服务架构的“现代化”方案更值得信赖。它不承诺解决所有问题，但它承诺，每一个字节的配置，你都看得见、摸得着、改得了、查得清。