根本原因是防火墙（含云安全组）在TCP连接建立前拦截请求，导致数据库未收到握手包；表现为Connection refused或超时，需通过telnet验证并逐层检查安全组、系统防火墙及端口协议配置。
navicat 连不上启用了防火墙限制的远程数据库，根本原因不是“连不上”，而是连接请求在抵达数据库进程前就被拦截了——防火墙拦在中间，数据库压根没收到握手包。
防火墙拦截导致 Connection refused 或超时
常见现象是：Navicat 报错 Connection refused、Can't connect to MySQL server on 'x.x.x.x'，或卡在“正在连接…”长达 30 秒后失败。
这不是密码错、用户不存在，也不是数据库没启动，而是 TCP 连接根本建立不了。
关键判断依据：在本地执行
telnet <strong><font color="green">remote_ip</font></strong> 3306如果显示
Connection refused，说明数据库服务没监听或端口未开放；
如果卡住几秒后提示 Unable to connect to remote host，大概率是防火墙丢包（没拒绝，直接无视）。
- Linux 服务器常用防火墙有
ufw和firewalld，不是所有系统都默认启用iptables（尤其新发行版） - 云服务器（阿里云/腾讯云/华为云）必须额外配置安全组规则，它比系统防火墙更前置，即使
ufw全开，安全组没放行照样不通 - Windows Server 自带防火墙默认会拦截入站
3306，且规则名不显眼（叫“MySQL”还是“TCP 3306”取决于安装方式）
ufw 和 firewalld 开放端口的操作差异
ufw（Ubuntu/Debian 常用）：
- 查状态：
sudo ufw status verbose - 开 3306：
sudo ufw allow 3306/tcp（必须加/tcp，否则只开 UDP） - 别忘了 reload：
sudo ufw reload
firewalld（CentOS/RHEL/Fedora）：
- 查区域：
sudo firewall-cmd --get-active-zones - 永久加端口（以 public 区域为例）：
sudo firewall-cmd --permanent --add-port=3306/tcp - 重载：
sudo firewall-cmd --reload
⚠️ 容易踩的坑：
- 执行
ufw allow 3306没加/tcp→ 实际开了 UDP 端口，MySQL 用不上 -
firewalld忘记加--permanent→ 重启后规则丢失 - 只开了系统防火墙，没配云平台安全组 → 白忙活
云服务器安全组必须单独配，且优先级最高
安全组是云厂商在物理网络层做的访问控制，比操作系统防火墙还早一步拦截流量。
哪怕你把服务器防火墙全关了，安全组没放行，telnet 依然不通。
- 规则方向选“入方向”
- 协议类型选
TCP - 端口范围填
3306（MySQL）或5432（PostgreSQL） - 源 IP 建议不要填
0.0.0.0/0，至少限制为你的办公公网 IP（可查curl ifconfig.me）
有些云平台安全组默认拒绝所有入向，连 SSH（22）都要手动加——别假设“SSH 能连，数据库就能连”。
Navicat 本身不触发防火墙，但会暴露配置漏洞
Navicat 是纯客户端，不参与防火墙决策。但它填错的参数会让问题更难排查：
- 主机填了内网 IP（如
10.0.0.5），而你从公网连 → 防火墙没拦，但路由根本走不通 - 端口填成
3307，而数据库只监听3306→telnet直接Connection refused，容易误判为防火墙问题 - SSL 设置选了“要求 SSL”，但数据库没配证书 → 连接被拒绝，日志里报的是 TLS 错误，和防火墙无关
真正要盯住的，是三层通路：
你的电脑 → 云安全组 → 服务器系统防火墙 → 数据库监听 socket
任何一层断掉，Navicat 都连不上，但只有中间两层是防火墙干的事。
别一报错就改数据库配置或重装 Navicat，先 telnet 两下，5 秒确认是不是防火墙的事。
