“拒绝连接”说明数据库服务已在目标端口监听，但主动拒绝连接，常见于bind-address配置为127.0.0.1、listen_addresses未设为*、TCP/IP协议未启用或IPv4/IPv6协议栈不匹配。
telnet remote_ip port 返回“拒绝连接”说明什么
这表示数据库服务进程确实在目标端口上监听，但主动拒绝了你的连接请求——不是防火墙拦截，也不是服务没起，而是数据库自身拒绝了这次握手。常见于：
• mysql 的 bind-address 仍为 127.0.0.1，只接受本地回环连接
• postgresql 的 postgresql.conf 中 listen_addresses 没设成 '*' 或具体公网ip
• sql server 的 tcp/ip 协议在 sql server configuration manager 中未启用
• 数据库服务虽运行，但监听的是 ipv6 地址而客户端走 ipv4（或反之）
Linux 服务器上确认数据库是否真正在监听外部端口
别只信配置文件，用系统命令看真实状态：
- MySQL：运行
sudo ss -tuln | grep :3306，输出中若含*:3306表示监听所有接口；若只有127.0.0.1:3306，说明配置没生效或服务没重启 - PostgreSQL：执行
sudo netstat -tuln | grep :5432，检查Local Address列是否为*:5432 - 注意：
ss比netstat更可靠，尤其在较新内核上；若命令不存在，先装iproute2
云服务器安全组和本地防火墙要分开查
很多人只改了云平台安全组，却忘了关本地 Windows 防火墙或 macOS 防火墙的出站规则：
- Windows：打开「高级安全 Windows Defender 防火墙」→「入站规则」里找对应端口（如 3306），确认状态是「已启用」；同时检查「出站规则」是否误拦了 Navicat 进程
- macOS：终端执行
sudo pfctl -sr查当前 pf 规则；若启用了 Little Snitch 等第三方防火墙，需单独放行 Navicat - 云平台（阿里云/腾讯云/AWS）：安全组规则必须是「入方向」+「TCP」+「端口精确匹配」（如 3306，不是 3300-3310）+「源 IP 明确或 0.0.0.0/0」
Navicat 测试连接失败时，错误码比弹窗文字更关键
点击【测试连接】后弹出的错误框里，拉到底部看完整报错文本——里面藏着真实线索：
-
10061（Windows）或Connection refused（Mac/Linux）：基本可锁定为服务未监听外部地址或端口被系统级防火墙 DROP -
2003（MySQL）：通常意味着服务根本没响应，优先查systemctl status mysql和端口监听状态 -
SSL connection error：不是端口问题，而是 Navicat 的 SSL 页签里勾了「强制使用 SSL」但服务端没配证书，此时应先取消勾选再试
跨平台连接最易忽略的一点：不同操作系统对 DNS 解析、IPv6 fallback、本地 hosts 映射的处理逻辑不一致。哪怕 telnet 通了，Navicat 仍可能因解析到 ::1 而连不上 IPv4 监听的服务。遇到怪异现象，直接在 Navicat 主机栏填 IP 而非域名，绕过所有解析环节。
