本文约 2,738 字,预计阅读 7 分钟。文中命令与配置均经过实测,可直接参考执行。
引言
WordPress 站点突然打不开,页面上出现这样的提示:Access denied for user 'xxx'@'localhost' (using password: YES),或者带一句 Error establishing a database connection。这行报错的核心含义是”这个数据库用户被拒绝访问”,翻译成大白话就是:账号、密码或权限不对,MySQL 不让你的网站进门。它常见于几种场景:刚改过 wp-config.php 里的数据库配置却填错了、主机商改了数据库密码、数据库被迁移到新服务器而用户没一并创建、或者主机的连接来源白名单没放行你的 IP。和表损坏不同,Access denied 是”权限门禁”问题,数据通常还在,只要把身份核对清楚,几分钟就能修好。下面带你一步步排查。
故障原因分析
- 数据库账号或密码填错。wp-config.php 里的 DB_USER、DB_PASSWORD、DB_NAME 只要有一个和 MySQL 实际的不一致,就会报 Access denied。密码里含特殊字符、复制时带了空格、或不小心把密码写成占位符,都很常见。
- 数据库用户权限不足。用户存在,但没有被授予对该数据库的 SELECT、INSERT、UPDATE、DELETE 等权限,或者只在旧服务器上授权,迁移后没重新授权。
- 主机(Host)不匹配。MySQL 授权是绑定”用户@来源主机”的,比如
wpuser@localhost和wpuser@127.0.0.1、wpuser@%是三条不同记录。如果代码连的是 127.0.0.1 而你只授权了 localhost,同样会被拒绝。
- 密码在数据库端被改过。主机商重置了数据库密码、或迁移工具生成了新密码,而 wp-config.php 没同步更新,导致本地记录的还是旧密码。
- 数据库不存在或用户不存在。DB_NAME 指向的库被删了,或者数据库用户根本还没创建,报错有时也表现为拒绝访问。
分步解决方案
第一步:确认报错里的用户和主机
先看清楚报错:Access denied for user 'A'@'B'。这里的 A 是用户名,B 是连接来源。把这两个值和 wp-config.php 里的 DB_USER、DB_HOST 对照。wp-config.php 一般位于网站根目录,比如 /www/wwwroot/你的域名/wp-config.php,用文件管理或 FTP 打开,找到这几行:
define( 'DB_NAME', '数据库名' );
define( 'DB_USER', '数据库用户名' );
define( 'DB_PASSWORD', '数据库密码' );
define( 'DB_HOST', 'localhost' );
第二步:核对数据库是否存在与账号是否可用
登录主机的 phpMyAdmin,看左侧数据库列表里 DB_NAME 对应的库是否存在。再到主机的”数据库管理”页面确认 DB_USER 是否存在。虚拟主机(宝塔、cPanel、宝塔面板等)里数据库和用户是分开创建的,很多时候库建好了但用户没绑定。
第三步:修正 wp-config.php 中的连接信息
修改前先把 wp-config.php 备份一份。然后用主机控制面板里显示的准确信息,逐字替换上面四个常量。注意:
- 密码区分大小写,不要多空格;含
$、!、&等符号时保持原样,PHP 单引号字符串里的这些符号是安全的。 - DB_HOST 有时不是
localhost,而是127.0.0.1或主机商提供的内网地址(如mysql.xxx.com),以面板提示为准。 - 保存后刷新网站,若报错消失即修复成功。
第四步:在 MySQL 中重新授权(权限不足时)
如果账号密码都对,仍报 Access denied,说明是权限问题。登录 phpMyAdmin 后点”用户账户”,或在 SQL 里执行授权。下面语句请把用户名、密码、数据库名换成自己的:
GRANT ALL PRIVILEGES ON 你的数据库名.* TO '你的用户'@'localhost' IDENTIFIED BY '你的密码';
FLUSH PRIVILEGES;
如果代码实际用的是 127.0.0.1 连接,建议同时授权:
GRANT ALL PRIVILEGES ON 你的数据库名.* TO '你的用户'@'127.0.0.1' IDENTIFIED BY '你的密码';
FLUSH PRIVILEGES;
需要强调:不要一上来就用 '你的用户'@'%'(允许任意来源),生产环境里来源越具体越安全。但如果你是本地测试或内网环境,用 % 能快速排除主机不匹配的问题。
第五步:重建用户(用户不存在时)
如果查询用户账户发现该用户根本不存在,直接创建并授权:
CREATE USER '你的用户'@'localhost' IDENTIFIED BY '你的密码';
GRANT ALL PRIVILEGES ON 你的数据库名.* TO '你的用户'@'localhost';
FLUSH PRIVILEGES;
第六步:验证
用主机面板提供的连接测试,或在服务器上执行:
mysql -u 你的用户 -p -h localhost 你的数据库名
输入密码能进说明账号权限没问题,问题就出在 wp-config。刷新网站确认恢复。
常见踩坑点
- 在 phpMyAdmin 里改密码后忘了同步 wp-config。数据库端和配置文件两边必须一致。
- 密码含特殊字符导致 PHP 解析问题。改用单引号包裹常量值可避免大部分转义问题。
- 只授权了 localhost,代码却用 127.0.0.1。确认 DB_HOST 与授权主机完全对应。
- 把
%当万能钥匙长期使用。安全风险高,排查完应改回具体来源。 - 修改 wp-config 前不备份。一旦改错,连后台都进不去,备份能救急。
- 迁移数据库后只导了数据没建用户。迁移时用户和授权要一并重建。
总结
WordPress Access denied 报错的本质是”身份或权限没对上”,不是数据丢失,排查思路非常清晰:先读报错确定用户和主机,再逐项核对 wp-config.php 中的库名、账号、密码、主机,最后检查 MySQL 端是否存在该用户并授予了足够权限。按本文的六步走,绝大多数数据库连接失败都能在几分钟内定位并修好。修好之后,建议把 wp-config.php 里的连接信息记进自己的运维备注,避免下次迁移时又踩同一个坑。
