最稳妥的UA拦截方案是在Nginx server块顶层用map定义$blocked_ua变量并匹配可疑UA，再通过if($blocked_ua)返回403，配合日志记录、限流及针对性location强化规则。
直接在 nginx（或 apache）层拦截恶意 user-agent，比在 php 或 phpmyadmin 内部做判断更可靠、更早生效——因为请求根本不会到达 phpmyadmin 的 php 脚本。
为什么不能只靠 phpMyAdmin 自身配置
phpMyAdmin 本身不提供 UA 黑名单功能；它依赖 Web 服务器传递请求。一旦恶意扫描器（如 sqlmap、nikto、python-requests）发来请求，PHP 进程就得启动、解析、路由、加载配置……这本身就会消耗资源。等它走到 phpMyAdmin 的登录页再拒绝，已经晚了。
- phpMyAdmin 没有内置 UA 过滤开关，所有“限制”都得靠外围 Web 服务器实现
- 试图用
.htaccess或 PHP 的$_SERVER['HTTP_USER_AGENT']做拦截，容易被绕过（比如加空格、编码、大小写混淆） - 某些 UA（如
curl、wget）常被运维工具使用，误封会导致自己无法调试
Nginx 中精准拦截 phpMyAdmin 路径的 UA
不要全局拦截所有可疑 UA——那样可能误伤监控探针或内部健康检查。应聚焦在 phpMyAdmin 的实际访问路径上，例如 /mysecretadmin（你已改过的路径）或默认的 /phpmyadmin。
- 在对应
server块中，为 phpMyAdmin 路径单独加location块，避免影响其他服务 - 用
if ($http_user_agent ~* "...")判断，但必须放在location内部（此处if是安全的，因不涉及fastcgi_pass等重写指令） - 推荐返回
444（Nginx 特有“关闭连接”状态），比403更安静，不暴露后端存在
示例配置：
location ^~ /mysecretadmin {
if ($http_user_agent ~* "(sqlmap|nikto|gobuster|nuclei|acunetix|whatweb|zmap|masscan|python-requests|curl|wget|Go-http-client|scanner|exploit|pentest)") {
return 444;
}
alias /www/phpmyadmin/;
index index.php;
# 后续 fastcgi 配置保持不变
}Apache 下等效实现（.htaccess 或 httpd.conf）
Apache 不支持 return 444，但可用 deny 或 redirect 实现类似效果。关键是把规则限定在 phpMyAdmin 目录内，而非全站。
立即学习“PHP免费学习笔记（深入）”；
- 若用
.htaccess，把它放在 phpMyAdmin 根目录（如/www/mysecretadmin/.htaccess），内容如下：
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (sqlmap|nikto|gobuster|acunetix|masscan|python-requests|curl|wget) [NC]
RewriteRule ^ - [F]-
[F]返回 403，日志里会记为client denied by server configuration - 注意：Apache 的
RewriteCond默认区分大小写，必须加[NC]；正则中不要用^$匹配空 UA，Apache 处理不稳定 - 如果 phpMyAdmin 是通过别名（Alias）挂载的，
.htaccess可能不生效，此时必须改httpd.conf中对应<directory></directory>块
容易被忽略的三个坑
很多配置看似生效，实则形同虚设——问题往往出在细节上：
-
map方式虽好，但若没在http块声明，只在server块里写，Nginx 会报错：unknown directive "map" - 测试时用
curl -H "User-Agent: sqlmap/1.7"，但真实扫描器可能带空格或换行符，建议额外匹配\s*或用~*保证大小写与空白鲁棒性 - 宝塔面板用户注意：修改的配置可能被面板自动覆盖，务必在「网站 → 设置 → 配置文件」中编辑，而非直接改
nginx.conf原始文件
真正起作用的不是关键词多寡，而是拦截位置是否足够前置、是否覆盖了扫描器的真实 UA 变体、以及是否和你的路径改名策略对齐。
