DBeaver连接PostgreSQL失败怎么办？常见报错原因与解决方法详解

DBeaver是一款免费开源的数据库管理工具，凭借对PostgreSQL的友好支持，它成了很多开发和运维人员的日常工具。不过在实际连接PostgreSQL时，报错的情况相当常见，有的是网络层面连不通，有的是数据库配置拒绝访问，还有的是驱动或SSL设置导致的隐蔽问题。这篇文章把高频出现的几类连接故障整理出来，逐个分析原因并给出对应的解决办法，帮你快速恢复工作。

连接被拒绝：Connection refused排查思路

这是最典型的一类报错，完整信息通常是Connection to xxx:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections。出现这个错误说明客户端发出的TCP请求根本没被数据库接收，问题一般出在三个地方。

第一，PostgreSQL服务本身没有启动。可以在服务器上执行systemctl status postgresql或者ps -ef | grep postgres确认进程状态。如果是Windows环境，检查服务列表里PostgreSQL服务是否处于运行状态。第二，端口没监听或者端口写错。用netstat -anp | grep 5432（Windows下用netstat -ano | findstr 5432）确认端口是否在监听。注意PostgreSQL默认监听的是IPv4和IPv6中的localhost，如果你在DBeaver里填的是服务器内网IP，而数据库只监听127.0.0.1，连接自然会被拒绝。

第三，防火墙拦截。云服务器的安全组规则经常是罪魁祸首，需要在控制台放行5432端口。Linux本机的firewalld或iptables也要检查，执行firewall-cmd --list-ports查看是否放行。建议按照先确认服务、再确认监听、最后确认防火墙的顺序排查，能少走很多弯路。

数据库配置导致连接失败：pg_hba.conf与postgresql.conf

如果网络是通的，但DBeaver提示FATAL: no pg_hba.conf entry for host，说明问题出在PostgreSQL自身的访问控制上。PostgreSQL通过pg_hba.conf文件控制哪些IP可以用什么方式连接，这个文件通常位于数据目录下，比如/var/lib/pgsql/data/pg_hba.conf或Windows下的C:\Program Files\PostgreSQL\16\data\pg_hba.conf。

要让远程机器能连上来，需要在pg_hba.conf中添加一行规则：

# TYPE  DATABASE  USER      ADDRESS         METHOD
host    all       all       192.168.1.0/24  md5
host    all       all       0.0.0.0/0       scram-sha-256

第一行表示允许192.168.1.0网段的所有用户用md5密码认证连接所有库，第二行是全网段放行，生产环境不建议这么宽。METHOD列建议使用scram-sha-256，这是PostgreSQL 14之后的默认认证方式，安全性比md5更好。改完配置后需要重启或重新加载服务：systemctl reload postgresql即可，reload不会中断现有连接。

另一个关键配置是postgresql.conf中的listen_addresses参数。默认值是localhost，只接受本机连接。要支持远程访问需要改成listen_addresses = '*'，然后重启服务。如果只改了pg_hba.conf而没改这个参数，远程连接依旧会失败。此外还要确认端口参数port = 5432与DBeaver中填写的一致。用户还容易忽略一点：新创建的数据库用户如果没有授权，会报permission denied，需要用超级用户执行GRANT ALL ON DATABASE mydb TO myuser;进行授权。

SSL与驱动相关的报错处理

DBeaver连接PostgreSQL时偶尔会碰到SSLSocketFactory or sslrootcert must be configured或者SSL握手失败的提示。这通常是因为驱动尝试用SSL连接，而服务器端没有启用或证书配置不匹配。解决办法是在DBeaver的连接设置里找到Driver properties标签页，把ssl参数设为false，或者把SSL Mode改为disable。如果服务器确实启用了SSL，就需要在sslmode中选择verify-ca或verify-full，并在Advanced settings里指定证书路径。

驱动下载失败也时有发生。DBeaver第一次连接时会自动下载JDBC驱动，如果网络受限，下载会卡住或直接失败，界面提示类似Error resolving driver artifacts。可以手动处理：进入Database菜单下的Driver Manager，找到PostgreSQL驱动，切换到Libraries标签，删掉失败的下载项，然后点Download/Update重新获取。如果公司内网有私服，可以在Download标签页配置Maven仓库地址。也可以从官方地址手动下载postgresql的jar包，通过Add File导入，导入后驱动就能正常加载了。

还有一类身份认证问题表现为FATAL: password authentication failed for user。这里要留意认证方式的匹配：如果pg_hba.conf里配置的是scram-sha-256，而用户密码是按md5方式设置的，或者反过来，都会认证失败。PostgreSQL 14以后默认使用scram-sha-256，老版本升级上来的库容易出现这种不匹配。处理办法是在psql里执行ALTER USER myuser WITH PASSWORD 'newpass';重新设置密码，让密码按当前认证方式重新生成即可。

其他细节问题与时区编码

有些连接成功了但行为异常的情况，也值得留意。比如查询返回的时间字段和预期差了8小时，多半是客户端时区设置问题，可以在连接属性的Driver properties里设置options -Duser.timezone=Asia/Shanghai，或者在URL参数里追加?options=-c%20timezone%3DAsia/Shanghai来固定时区。

编码问题在中文环境下也偶有出现，如果数据库初始化时用的是SQL_ASCII编码，中文数据显示乱码，DBeaver端设置编码是无济于事的，根本解决要靠建库时选择UTF8编码。另外，如果连接突然全部超时，而配置没做任何改动，优先检查服务器磁盘是否写满，PostgreSQL在磁盘满的情况下会拒绝新连接，这个原因非常容易被忽略。

总结一下排查顺序：先看服务是否运行、端口是否监听、防火墙是否放行，再看pg_hba.conf和listen_addresses配置，然后检查SSL参数和驱动状态，最后关注认证方式匹配与时区编码。养成按层次排查的习惯，绝大多数DBeaver连接PostgreSQL的问题都能在几分钟内定位并解决。

DBeaverPostgreSQL数据库连接修改时间：2026-09-09 00:54:49