MySQL服务未监听正确端口或防火墙拦截是Navicat连接超时的主因；需检查netstat监听状态、bind-address配置、防火墙及安全组规则，并验证网络连通性。
检查 MySQL 服务是否真正运行并监听正确端口
navicat 连接超时，第一反应不是网络问题，而是 mysql 根本没在监听你填的端口（默认 3306）。常见情况是服务启动了但绑定了 127.0.0.1 或 localhost，导致远程（包括 navicat 所在机器）无法访问。
- 在 MySQL 服务器上执行
sudo netstat -tuln | grep :3306（Linux/macOS）或netstat -ano | findstr :3306（Windows），确认有LISTEN状态且监听地址不是仅127.0.0.1:3306 - 检查 MySQL 配置文件（通常是
/etc/mysql/mysql.conf.d/mysqld.cnf或C:\ProgramData\MySQL\MySQL Server X.X\my.ini），确认bind-address不是127.0.0.1（若需远程连接，可设为0.0.0.0或具体 IP；设为127.0.0.1时 Navicat 必须和 MySQL 同机且用localhost连） - 改完配置必须重启 MySQL：
sudo systemctl restart mysql（Linux）或 Windows 服务里重启MySQL80服务
验证防火墙是否放行了 MySQL 端口
即使 MySQL 监听了 0.0.0.0:3306，系统防火墙或云平台安全组仍可能拦截连接请求，表现就是 Navicat 卡在“正在连接…”几秒后报超时，而非明确拒绝。
- Linux 上检查：
sudo ufw status（若启用），确保3306在允许列表；或临时关闭测试：sudo ufw disable - Windows 上打开“高级安全 Windows 防火墙” → 入站规则 → 确认有允许
TCP 3306的规则（非仅“域”配置，要“专用/公用”都生效） - 阿里云、腾讯云等平台，务必检查实例绑定的安全组，添加入方向规则：协议类型
TCP，端口范围3306，源 IP 可先设为0.0.0.0/0测试（后续收紧）
Navicat 连接参数中 host 和 port 的实际含义
很多人以为填了 localhost 就一定走本地 socket，其实 Navicat 默认走 TCP。这会导致两个典型问题：一是 localhost 被解析成 127.0.0.1，而 MySQL 若只监听 ::1（IPv6）就会失败；二是端口填错或被代理劫持。
- 尝试把 host 改为
127.0.0.1（强制 IPv4 TCP）或::1（IPv6），避开 DNS 解析和 localhost 特殊处理逻辑 - 确认 Navicat 连接窗口里
Port填的是真实 MySQL 监听端口，不是 SSH 转发端口或容器映射端口（比如 Docker 启动时写了-p 3307:3306，那 Navicat 就该填3307） - 如果用了 SSH 隧道，Navicat 的连接方式要选
SSH，host 填的是跳板机地址，MySQL host 填的是内网地址（如127.0.0.1），此时实际走的是隧道，不直连 MySQL 端口
排查中间设备（路由器、NAT、代理）干扰
局域网直连一般没问题，但一旦跨子网、走无线桥接、或公司网络有透明代理/上网行为管理设备，TCP 握手包可能被静默丢弃，现象就是 Navicat 超时，而 ping 通、telnet ip 3306 却无响应（注意：现代系统默认禁用 telnet，可用 nc -zv ip 3306 替代）。
- 在 Navicat 所在机器执行：
nc -zv 192.168.1.100 3306（把 IP 换成你的 MySQL 地址），看是否显示succeeded!；失败则说明链路不通，不是 MySQL 配置问题 - 家用路由器检查是否开启“AP 隔离”或“客户端隔离”，这会阻止同一 WiFi 下设备互访
- 企业环境优先联系 IT 部门确认：出口防火墙是否放行 MySQL 端口、是否有 DPI 设备识别并阻断数据库流量
真正卡住的地方，往往不是 Navicat 设置，而是 MySQL 绑定地址和防火墙策略这两层。尤其当服务器重装或升级 MySQL 后，默认 bind-address 很可能被重置为 127.0.0.1，而人却只盯着 Navicat 的连接界面反复试密码。
