<p>目录保护防wp-login.php暴力破解需精准匹配路径：保护目录填/wp-login.php（不带斜杠或/），手动编辑生成的.conf文件修正正则为location ~ ^/wp-login.php {，重载Nginx后用curl -I测得401即生效。</p>
宝塔面板里怎么用目录保护防 wp-login.php 暴力破解
直接生效、不依赖插件、Nginx 层拦截——这是最轻量也最可靠的登录入口防护方式。关键不是“装了没”，而是路径匹配是否精准、配置是否被 Nginx 实际加载。
- 在宝塔面板「网站」列表中，找到目标站点，点击右侧「设置」→ 左侧菜单选「目录保护」→ 点击「添加目录保护」
- 「名称」填
wp-login（仅标识用，无实际影响）；「保护的目录」必须填/wp-login.php（注意结尾不带斜杠，也不加/*） - 保存后，宝塔会自动生成一个
wp-login.php.conf文件，路径类似：/www/server/panel/vhost/nginx/dir_auth/your-domain.com/wp-login.php.conf - 务必手动编辑该文件：把原配置中
location ~* ^/wp-login.php/* {改成location ~* ^/wp-login.php {，删掉/*——否则正则不匹配，整个防护失效 - 改完立刻点 Nginx 的「重载配置」，别只点「保存」；用
curl -I http://your-domain.com/wp-login.php测试，返回401 Unauthorized才算成功
为什么 /wp-admin 不能照搬 /wp-login.php 的保护方式
/wp-admin 是个目录，不是单个脚本文件，直接套用 /wp-login.php 那套正则会漏掉大量请求，比如 /wp-admin/admin-ajax.php 或 /wp-admin/post-new.php 这类真实后台接口。
- 若强行对
/wp-admin目录启用目录保护，会导致 WordPress 后台所有功能（包括媒体上传、文章保存、插件更新）全部 401 报错 - 真正可行的做法是：只保护
/wp-login.php和/wp-admin/admin-ajax.php（后者常被暴力扫描利用），其他后台路径由 WAF 或登录逻辑本身控制 - 如果硬要加
/wp-admin保护，必须配合白名单 IP，且需额外在配置里显式放行.php和.js等静态资源，否则后台 JS 加载失败，页面直接空白
目录保护和 WAF 拦截暴力请求的区别在哪
目录保护是 HTTP 认证层拦截，WAF 是内容规则层拦截，两者触发时机、日志位置、绕过可能性完全不同。
- 目录保护触发时，Nginx 在
access phase就返回 401，根本不会进 PHP，所以wp-login.php里的登录逻辑、插件钩子、fail2ban 日志都收不到这次请求 - WAF（如宝塔的 luawaf）是在请求进入 PHP 前解析 body 和 query，能识别
log=admin&pwd=123这类参数特征，但前提是请求没被前面的认证拦住 - 如果你同时开了目录保护和 WAF，WAF 对
/wp-login.php的暴力请求基本收不到数据——因为 401 已提前返回。想让 WAF 生效，得关掉目录保护，或改用 IP 白名单 + WAF 组合 - 日志也分家：
/www/wwwlogs/your-domain.com.log里看不到 401 请求（Nginx 默认不记 access log 中的 auth 失败），而 WAF 日志在/www/wwwlogs/waf/下
路径写错或重载失败后，怎么快速验证是否生效
别只看面板提示“保存成功”，暴力破解工具几秒就能测出漏洞。验证必须走真实请求链路。
- 用浏览器隐身窗口访问
http://your-domain.com/wp-login.php，出现弹窗要求输入用户名密码（不是 WordPress 登录页），说明目录保护已生效 - 用命令行测试：
curl -v http://your-domain.com/wp-login.php 2>&1 | grep "WWW-Authenticate"，有输出才对；没输出说明配置没加载或正则写错了 - 检查 Nginx 错误日志：
tail -f /www/wwwlogs/nginx_error.log，如果看到no resolver defined to resolve或directive is not allowed here，大概率是wp-login.php.conf里混进了不支持的指令（比如写了deny all） - 最隐蔽的坑：云服务器安全组或宝塔防火墙没放行新生成的认证端口（虽然目录保护不占新端口，但部分用户会误配成 https+auth，导致 443 被拦）
路径保护本身很简单，但和 Nginx 配置生命周期、正则优先级、日志采集机制绑得太紧——改一行，漏一环，就等于没防。
