Navicat不支持IPv6 socket连接，遇::1或bind-address=::时不会降级至IPv4，直接报错；解决方法是连接时主机名填127.0.0.1而非localhost，并注释hosts中::1 localhost行。
Navicat（尤其是旧版、免费试用版及多数稳定版）压根不支持 IPv6 socket 连接，遇到 ::1 或 bind-address = :: 时，不会 fallback 到 IPv4，而是直接报“网络不可达”“Connection refused”或无限超时——这不是你配错了，是它根本没实现这个逻辑。
Navicat 填 localhost 就连不上 IPv6 监听的 MySQL
因为系统 /etc/hosts（Linux/macOS）或 C:\Windows\System32\drivers\etc\hosts（Windows）里默认有 ::1 localhost，Navicat 解析 localhost 优先取这一行，然后尝试走 IPv6 连接，失败后不重试 127.0.0.1。
- 临时解法：Navicat 新建连接时，主机名必须填
127.0.0.1，不能填localhost - 长期清理：注释掉 hosts 文件中
::1 localhost这一行（保留127.0.0.1 localhost） - 验证方式：命令行执行
mysql -h ::1 -P 3306 -u root -p失败，但mysql -h 127.0.0.1 -P 3306 -u root -p成功，就确认是这个问题
MySQL 显示 :::3306 但 Navicat 死活连不上
执行 netstat -tuln | grep :3306 如果看到 :::3306，说明 mysqld 正在监听 IPv6 地址（比如 bind-address = * 或未设 bind-address），而 Navicat 完全无视这个监听状态。
- 最稳妥改法：编辑 MySQL 配置文件（如
/etc/mysql/mysql.conf.d/mysqld.cnf），显式设置bind-address = 0.0.0.0 - 重启服务：
sudo systemctl restart mysql - 避免改配置的临时方案：Navicat 连接时填
127.0.0.1+ 确保取消勾选「Use SSL」和「Use SSH tunnel」——这两项会额外触发 DNS 解析或 TLS 协商，加剧 IPv6 路径干扰
远程数据库报 Error 1129，其实是 IPv6 连接失败连带封了 IPv4
当客户端反复用 IPv6（如 2001:db8::1）连失败，MySQL 的 max_connect_errors 机制会把整个 IPv6 段记入 host_cache，后续哪怕你换 127.0.0.1 或公网 IPv4 连，也会被误判为“该 host 已被 block”。
- 立刻清缓存：
mysql -u root -p -e "FLUSH HOSTS;" - 别等自动解锁（默认 1 小时），这个 timeout 是全局的，影响所有来源 IP
- 如果必须支持 IPv6 客户端，建议在 MySQL 配置中加
skip-name-resolve并严格控制max_connect_errors值
真正容易被忽略的一点：Navicat 的「Quick Connect」下拉菜单、连接模板、甚至历史连接记录，都可能悄悄把 localhost 再次塞进主机字段——每次新建连接，务必手动删掉再输 127.0.0.1，别依赖任何自动补全。
