验证码对phpMyAdmin几乎无效，因攻击者绕过登录页直连MySQL或OCR识别率超95%；仅在无法IP白名单、已用cookie+Nginx认证且愿承担维护成本时才考虑轻量级Nginx前置验证码。
phpMyAdmin 后台登录入口加验证码，并不能有效防住自动化爆破——这是最常被误解的一点。真正需要它的场景，只在特定条件下成立。
验证码对 phpMyAdmin 几乎无效的典型表现
- 攻击者根本不会卡在登录页：他们直接扫
/phpmyadmin/、/pma/、/dbadmin/等路径，拿到入口后直连 MySQL 协议层或用已知弱口令撞库 - OCR 识别率在现代工具（如 tesseract + 自定义训练）下已超 95%，图形验证码形同虚设
-
phpMyAdmin自身无原生验证码支持，所有“加验证码”方案都需外部干预，极易引发：-
session冲突导致登录态丢失 -
blowfish_secret加密上下文与验证码 token 生命周期不一致，校验随机失败 - 升级后所有修改被覆盖，且无提示
-
哪些情况才值得考虑加（轻量级）验证码？
- 你无法控制访问来源（比如必须对外开放给多个合作方，又不能做 IP 白名单）
- 你已启用
auth_type = 'cookie'，且 Nginx 层已做了auth_basic，但还想再拦一道低速人工试探 - 你愿意承担维护成本，并接受它只对“非定向、低频、无OCR能力”的试探有效
此时推荐做法是：
- 在 Nginx 认证通过后、请求到达
phpMyAdmin前，挂一个独立 PHP 脚本（如/verify-captcha.php） - 用
ext-gd生成简单数字图，$_SESSION存 hash，过期时间设为 3 分钟 - 校验通过后用
header('Location: /phpmyadmin/')跳转，绝不嵌入 phpMyAdmin 模板
更关键的防护点，90% 的人会忽略
-
fail2ban必须监控access.log中POST /phpmyadmin/index.php的 401/403 状态码，而不是只看 200 -
$cfg['Servers'][$i]['AllowRoot'] = false;这一行必须存在，否则攻击者爆破到 root 就等于拿下数据库全部权限 - 所有自定义脚本（包括验证码）的目录权限必须是
640，且不能放在 Web 可写路径下，否则可能被上传 webshell
验证码不是盾牌，只是门帘。真正起作用的，永远是路径隐藏、IP 限频、root 禁用和日志联动这四件套。
