“Connection refused”通常因MySQL服务未运行或监听配置错误，应先检查服务状态、端口绑定及bind-address设置；Access denied则需核对user@host组合与认证插件兼容性；远程连接失败需排查防火墙、安全组及Docker网络；GRANT后须执行FLUSH PRIVILEGES生效权限。
连接被拒绝：先确认 MySQL 服务是否在运行
“Connection refused” 错误绝大多数情况下不是权限问题，而是 mysqld 根本没起来，或者监听地址/端口不对。别急着改用户权限，先看服务状态。
- Linux 上执行
systemctl status mysql或systemctl status mysqld（取决于发行版和安装方式） - 检查监听端口：
ss -tlnp | grep :3306（或netstat -tlnp | grep :3306），确认有进程绑定在0.0.0.0:3306或127.0.0.1:3306，而不是只绑定了127.0.0.1却从远程连 - 查看 MySQL 配置文件（通常是
/etc/mysql/my.cnf或/etc/my.cnf）中bind-address的值：若为127.0.0.1，则仅本地 socket 可连；需远程访问时应设为0.0.0.0或具体网卡 IP（注意防火墙）
ERROR 1045 / Access denied：重点查 host 和 authentication plugin
能连上服务但报 Access denied for user 'xxx'@'yyy'，说明认证失败。MySQL 判断用户的依据是 user + host 组合，且 8.0+ 默认用 caching_sha2_password 插件，老客户端可能不兼容。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 登录 MySQL 后执行：
SELECT user, host, plugin FROM mysql.user WHERE user = 'your_username';
- 如果
host是localhost，那通过 TCP（比如mysql -h 127.0.0.1）连接时匹配的是'user'@'127.0.0.1'，而非'user'@'localhost'—— 这俩是不同账户 - 若需通配所有来源，创建用户时用
'user'@'%'，但务必配合强密码，并确保skip-networking未启用 - 遇到
Client does not support authentication protocol，临时方案是改插件：ALTER USER 'your_user'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password';
远程连接失败但本地 OK：检查系统级网络限制
MySQL 用户权限、服务监听都对了，还是连不上？大概率卡在中间层。
- 确认服务器防火墙放行 3306 端口：
ufw status（Ubuntu）或firewall-cmd --list-ports（CentOS/RHEL） - 云服务器（如阿里云、AWS）必须检查安全组规则，开放对应端口和源 IP 段
- 若用 SSH 隧道连接，确保本地端口转发命令正确，例如：
ssh -L 3307:127.0.0.1:3306 user@remote_host，然后连127.0.0.1:3307 - 某些 Docker 部署中，容器未暴露端口或 network mode 设为
host以外模式，也会导致外部无法访问
GRANT 后仍无效：别忘了 FLUSH PRIVILEGES
执行 GRANT 语句后权限没生效，最常见原因是没刷新权限表。MySQL 不会自动重载内存中的权限缓存。
- 每次修改
mysql.user表或使用GRANT/REVOKE后，必须执行：FLUSH PRIVILEGES;
- 注意：直接
INSERT或UPDATEmysql.user表后也必须FLUSH，否则变更仅存在磁盘，不生效 - MySQL 8.0+ 中部分操作（如
CREATE USER）会自动触发刷新，但GRANT仍需手动FLUSH（除非用CREATE USER ... IDENTIFIED BY一步到位）
host 匹配细节和 plugin 兼容性最容易被忽略，尤其是从 5.7 升级到 8.0 后，很多脚本和连接池默认不支持新认证方式。 
