连接超时与密码错误无关，是tcp握手未响应所致，需逐层排查网络链路、端口可达性（用telnet/nc测试）、mysql监听地址（确保bind-address=0.0.0.0）、防火墙及安全组规则，并调高navicat的connection timeout至60或120秒。
连接超时不是密码错，先别反复点“测试连接”
连接超时（错误码通常不显示具体数字，或伴随 Connection timed out）和认证失败（如 Access denied）是两类完全不同的问题。前者说明 Navicat 的 TCP 握手请求压根没收到响应，根本还没走到验证用户名密码那步。反复改密码、重输端口、切换连接名，对这类问题无效。必须从网络链路开始逐层确认。
用 telnet 或 nc 测试端口是否真可达
这是最直接的判断依据：Navicat 连不上，但系统命令能连上，说明问题在 Navicat 配置或驱动；连不上，说明问题在中间链路。执行前确认目标 MySQL 5.7 实际监听端口（不一定是 3306）：
-
telnet 192.168.1.100 3306（Windows）或nc -zv 192.168.1.100 3306（Linux/macOS） - 若返回
Connected to ...，说明端口通，继续查 Navicat 配置或 MySQL 用户权限 - 若卡在
Trying ...后超时，说明防火墙、安全组或路由拦截了该端口 - 若明确提示
Connection refused，说明 MySQL 服务未运行，或监听地址不对（比如只绑了127.0.0.1）
检查 MySQL 5.7 是否监听外网地址
Docker 容器或 CentOS 7 默认配置常导致 MySQL 只监听本地回环，远程 Navicat 必然超时。登录服务器后确认：
- 执行
netstat -tuln | grep :3306，看输出中第二列是否含*:3306或0.0.0.0:3306；若只有127.0.0.1:3306，则需修改my.cnf - 编辑
/etc/my.cnf或/etc/mysql/my.cnf，确保有bind-address = 0.0.0.0（或注释掉bind-address行） - 重启 MySQL：
systemctl restart mysqld（CentOS）或docker restart mysql-container（Docker） - 注意：Docker 启动时若没加
--sysctl net.ipv4.tcp_keepalive_time=60，长期空闲后仍可能被中间设备断连
Navicat 自身超时设置太短，尤其在高延迟或容器环境
默认连接超时（Connection Timeout）是 30 秒，但在跨公网、走 SSH 隧道、或 MySQL 5.7 运行在资源紧张的 Docker 容器里时，握手耗时很容易突破这个阈值。调整位置在连接属性 → 高级 页：
- 把
Connection Timeout改成60或120 - 如果已启用 SSH 隧道，
Read Timeout也建议同步调高到60 - 改完务必点
测试连接，而不是直接保存后尝试双击连接——后者不会触发新参数校验 - 注意：这个设置只影响当前连接，不同环境（开发/测试/生产）建议建多个独立连接并命名区分
真正卡住的地方，往往不是 Navicat 界面里的那个“主机”框填错了 IP，而是 MySQL 5.7 进程自己拒绝被远端看见，或者云服务器的安全组规则比你想象中更严格。每次改完任何一项，都用 telnet 复测一次，比盲调配置高效得多。
