Navicat连接MariaDB报10060错误本质是TCP连接超时，需依次排查网络连通性、bind-address配置、云服务器安全组、max_connect_errors封禁及Navicat客户端设置。
Navicat连接MariaDB报10060超时：先确认端口是否真通
10060错误本质是客户端根本没连上服务器，不是认证失败，也不是权限问题——它卡在tcp握手阶段。所以别急着改用户权限或密码，先验证网络层是否通畅。
- 在Navicat所在机器（比如你的Windows笔记本）上运行：
ping -n 4 <MariaDB服务器IP>，能通≠端口通，但不通就不用往下看了 - 接着用
telnet <IP> 3306（Windows需启用Telnet客户端）或nc -zv <IP> 3306（Linux/macOS），看是否显示“Connected”；如果提示“Connection refused”或超时，说明服务没监听、防火墙拦了、或bind-address锁死了 - 注意：有些云服务器（如阿里云、腾讯云）安全组默认**不放行3306**，即使本地防火墙开了也没用，必须进控制台配白名单
bind-address=127.0.0.1 是最大隐形杀手
MariaDB默认只监听本地回环地址，哪怕你开了防火墙、设了远程用户，外部请求也根本进不来。这个配置藏得深，且不同系统路径不同，容易改错位置。
- Ubuntu/Debian系通常在
/etc/mysql/mariadb.conf.d/50-server.cnf里找bind-address=127.0.0.1，把它改成bind-address=0.0.0.0或直接注释掉（加#） - CentOS/RHEL系可能在
/etc/my.cnf.d/server.cnf的[mysqld]段下；群晖则要进/usr/local/mariadb10/etc/my.cnf - 改完必须重启服务：
sudo systemctl restart mariadb（不是mysql，别手滑） - 重启后立刻验证：
sudo ss -tln | grep :3306，看到*:3306或:::3306才算成功；若仍是127.0.0.1:3306，说明改错了文件或没生效
max_connect_errors 触发后会静默拒绝连接
反复输错密码、Navicat自动重试失败，会导致MySQL记录失败次数，达到max_connect_errors阈值（默认100）后，直接封禁该IP，报错还是10060——但日志里写的是“Host is blocked”，极易误判为网络问题。
- 登录MariaDB执行：
SHOW VARIABLES LIKE 'max_connect_errors';，再查当前状态：SHOW STATUS LIKE 'Aborted_connects'; - 临时解封：
FLUSH HOSTS;（全局清空黑名单）或用mysqladmin -u root -p flush-hosts - 永久放宽（仅限内网环境）：
SET GLOBAL max_connect_errors = 1000;，并写入配置文件[mysqld]段：max_connect_errors = 1000 - 注意：主从架构下，
FLUSH HOSTS要在主库和所有从库都执行一遍，否则从库仍可能拒绝连接
Navicat自身配置与驱动兼容性陷阱
有时候服务器全通，但Navicat就是连不上，问题出在客户端侧：协议选错、驱动过旧、甚至DNS解析卡住。
- 连接设置里，“Host name/IP address”别填
localhost——它会走socket而非TCP，而远程场景必须用真实IP；同时确认端口是3306，不是3307或空着 - 如果服务器启用了
skip-name-resolve（推荐加），Navicat首次连接可能因反向DNS查询卡顿，此时在/etc/mysql/mariadb.conf.d/50-server.cnf的[mysqld]段加一行：skip-name-resolve，再重启 - 旧版Navicat（尤其v12及以前）对MariaDB 10.5+的默认认证插件
unix_socket或ed25519支持不佳，可临时切回mysql_native_password：ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'yourpass';
真正卡住人的，往往不是单个步骤，而是几个点叠在一起：bind-address没放开 + 安全组没开 + max_connect_errors已满 + Navicat还连着localhost。排查时别跳步，一个一个验证输出，比瞎试十次有用。
