目录保护防wp-login.php暴力破解需精准匹配路径:保护目录填/wp-login.php(不带斜杠或/),手动编辑生成的.conf文件修正正则为location ~ ^/wp-login.php {,重载nginx后用curl -i测得401即生效。

宝塔面板里怎么用目录保护防 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 配置生命周期、正则优先级、日志采集机制绑得太紧——改一行,漏一环,就等于没防。











