2003错误本质是TCP连接被拒绝，需依次排查：服务是否运行、bind-address是否限制为127.0.0.1、防火墙/安全组是否放行3306端口、Navicat主机名填写是否正确（优先用127.0.0.1而非localhost）。
2003 错误本质是 navicat 根本没连上 mysql 服务端，不是密码错、不是用户名错，是 tcp 连接被拒绝。先别急着改权限或重装，按顺序排查这四点，90% 的情况能在 5 分钟内解决。
MySQL 服务到底启动了没有？
这是最常被忽略的一步。Windows 上服务名不一定是 MySQL，可能是 MySQL80、MySQL57 或自定义名。
- 打开
services.msc，搜索所有含 “MySQL” 的服务，看状态是不是“正在运行” - 用管理员权限运行 cmd，执行
sc query | findstr MySQL，确认服务存在且 STATE 是 4 RUNNING - 如果服务不存在：进 MySQL
bin目录，运行mysqld.exe -install注册服务，再net start MySQL80 - Linux 下执行
systemctl status mysql或systemctl status mysqld（注意服务名差异）
MySQL 监听地址是不是只绑定了 127.0.0.1？
本地 Navicat 连 localhost 失败，但命令行 mysql -u root -p 能进，大概率是这个原因。MySQL 默认只监听本地回环，不接受外部连接（包括本机其他进程）。
- Linux 查监听状态：
sudo netstat -anptu | grep :3306，如果看到127.0.0.1:3306就是问题所在 - 修改配置文件（Ubuntu 常见路径：
/etc/mysql/my.cnf；CentOS 可能是/etc/my.cnf），找到或添加一行：bind-address = 0.0.0.0 - 重启服务：
sudo systemctl restart mysql（或mysqld） - Windows 配置文件通常是
C:\ProgramData\MySQL\MySQL Server X.X\my.ini，同样改bind-address
防火墙或安全组有没有拦住 3306 端口？
即使服务在跑、监听正确，中间的网络策略也可能直接丢包。尤其在虚拟机、云服务器、Docker 环境下，这点极易被绕过。
- Windows 防火墙：控制面板 → Windows Defender 防火墙 → 允许应用通过防火墙 → 勾选
mysqld.exe或手动放行端口 3306 - Ubuntu：
sudo ufw status，若为 active，运行sudo ufw allow 3306 - CentOS 7+：
sudo firewall-cmd --permanent --add-port=3306/tcp，再sudo firewall-cmd --reload - 云服务器（阿里云/腾讯云）：必须进控制台安全组规则，添加入方向 3306 TCP 规则，源 IP 可设为
0.0.0.0/0（测试用）或具体客户端 IP
Navicat 连接参数里填的是 localhost 还是 127.0.0.1？
看着一样，但某些 MySQL 配置下行为不同。比如 skip-name-resolve 开启时，localhost 会走 socket 连接，而 127.0.0.1 强制走 TCP。一旦 socket 文件路径不对或权限异常，localhost 就会失败，报 2003。
- Navicat 连接设置中，“主机”字段明确填
127.0.0.1，而不是localhost - 如果必须用
localhost，检查 MySQL 配置是否有socket=/var/run/mysqld/mysqld.sock（Linux）或对应 Windows 路径，并确认文件存在且可读 - Docker 场景下，宿主机连容器 MySQL，主机必须填容器 IP 或
host.docker.internal（Mac/Win），不能填localhost
真正卡住的地方往往不是某一个配置，而是多个环节叠加：服务起来了但没监听外网、监听开了但防火墙挡着、防火墙放行了但 Navicat 填了错误的主机名。每次改完一点，都用 telnet 127.0.0.1 3306（Windows）或 nc -zv 127.0.0.1 3306（Linux/macOS）验证端口是否真通——这是最直接的判断依据。
