“Communications link failure”卡在TCP连接层，本质是JDBC驱动无法完成socket建立或收发数据包，与认证、SQL、SSL无关；需优先用telnet/nc验证目标IP和端口的网络可达性，并排查IPv6栈、防火墙、安全组等底层网络问题。
“Communications link failure”到底卡在哪一层
这个报错不是数据库拒绝你，而是 DBeaver 根本没把 TCP 包发出去，或者发出去后没收到任何响应。它出现在 JDBC 驱动尝试建立 socket 连接的最底层，和认证、SQL、SSL 都无关——那些都得等连接建起来之后才轮得到。所以看到这个错误，第一反应不该是改密码或加 SSL 参数，而是确认：目标地址+端口是否真能被当前机器访问。
用 telnet 或 nc 直接验证端口连通性
别信 ping，PostgreSQL 默认不响应 ICMP；也别依赖 DBeaver 的“测试连接”按钮，它会裹一堆 JDBC 封装逻辑。直接用系统级工具测：
-
telnet 192.168.1.100 5432—— 如果返回Connected to ...，说明网络和端口没问题；如果卡住或报Connection refused，说明服务没监听、防火墙拦了、或 IP 写错了 -
nc -zv 192.168.1.100 5432（macOS/Linux）或Test-NetConnection 192.168.1.100 -Port 5432（PowerShell）效果一样，更明确输出成功/失败 - 若本地连自己
localhost失败，重点查 PostgreSQL 是否监听localhost：看postgresql.conf中listen_addresses是否包含'localhost'或'*'，再看pg_hba.conf是否允许local或host连接
驱动层干扰：JDK IPv6 优先导致连接超时
尤其在 JDK 17+ 环境下，DBeaver 启动时默认走 IPv6 地址解析（比如把 localhost 解成 ::1），而很多 PostgreSQL 实例只绑定了 IPv4 的 127.0.0.1，结果就是 telnet ::1 5432 必然失败，但你根本看不到这个过程。
- 打开 DBeaver 安装目录下的
dbeaver.ini - 在
-vmargs下一行添加：-Djava.net.preferIPv4Stack=true - 保存后**必须完全退出 DBeaver 进程**（任务管理器里确认无残留 java.exe），再重启
- 这招对远程库也有效——某些云厂商的 PostgreSQL 实例禁用了 IPv6 入口，但客户端仍尝试先连 IPv6 地址，导致看似“网络通但连不上”
防火墙与安全组常被忽略的两个细节
即使你能 telnet 通，也可能在后续握手阶段被掐断，尤其是启用了 SSL 或自定义协议的场景：
- DBeaver 的 JDBC 连接不是一次 TCP 握手完事，它可能触发多次子连接（比如 SSL 重协商、GSSAPI 认证），这些流量可能被企业防火墙按“非常规协议”拦截，表现就是连接闪断或超时
- 云数据库（如阿里云 RDS、腾讯云 CDB）的安全组规则里，“入方向”允许的是**客户端出口 IP**，不是你本机显示的公网 IP——如果你在公司内网、用 NAT 上网，得填整个内网段（如
192.168.0.0/16）或找出口网关真实 IP - Windows 自带防火墙有时会静默丢弃 Java 进程的出站连接，临时关闭它测试一下，比反复调参数快得多
真正难排查的从来不是“连不上”，而是“看起来能连上但就是报 Communications link failure”——这时候大概率是 IPv6 栈、中间设备策略、或 JDBC 驱动与 JDK 网络栈的隐式交互出了问题，而不是你填错了密码或端口。
