PostgreSQL密码认证失败：从“连不上”到“秒解决”的排查指南
遇到 ERROR: password authentication failed for user "xxx" 这个报错，先别急着反复重输密码。这通常不是Na vicat的“锅”，而是PostgreSQL服务端直接拒绝了密码认证请求。问题的核心，在于确认三件事：这个用户是否存在、密码是否匹配、以及当前的认证方式是否允许密码登录。
一个很常见的迷惑现象是：用 psql 命令行能连上，但Na vicat死活报错；或者换一台机器就连接失败。这其实已经指明了方向——问题大概率出在服务端的配置或用户权限上，而非客户端输入的密码本身有误。
PostgreSQL报错 ERROR: password authentication failed for user "xxx" 怎么查
排查的第一步，是模拟真实环境。别用本地socket直连，那会绕开很多关键检查。请打开终端，执行：
应先用psql -U xxx -h 127.0.0.1测试TCP连接，再查pg_hba.conf认证方式是否为md5/password、用户密码是否存在且非NULL、listen_addresses是否包含127.0.0.1或*、SSL设置是否匹配，并查看PostgreSQL日志定位具体失败原因。
具体来说，可以遵循以下流程：
- 模拟连接：使用
psql -U xxx -h 127.0.0.1 -d postgres命令。这正是在模拟Na vicat通过TCP/IP进行连接的方式，能有效排除本地直连的干扰。 - 检查认证规则：查看
pg_hba.conf文件。找到对应你客户端IP地址和数据库的那一行，确认其认证方法（METHOD）是md5或password。如果显示的是trust（无条件信任）或peer（系统用户认证），那么密码认证自然无法进行。 - 确认密码状态：在数据库内执行
SELECT usename, passwd IS NOT NULL FROM pg_shadow WHERE usename = 'xxx';。只有当查询结果返回true时，才说明该用户确实设置了密码。如果为NULL，那么任何密码都无法匹配。
ALTER USER ... PASSWORD 之后还是连不上？
这里有个关键认知：在PostgreSQL里，执行 ALTER USER ... PASSWORD 成功，绝不意味着新密码立刻就能用于登录。服务端不会自动重载所有配置，它只认两个东西：pg_hba.conf 文件中的认证规则，以及 pg_authid 系统表里存储的密码哈希值。
最容易踩的坑有两个：一是修改了 pg_hba.conf 后，忘记执行 SELECT pg_reload_conf(); 让配置生效；二是虽然改了密码，但没搞清楚这个用户连接时，实际匹配的是 pg_hba.conf 中的哪一条 host 规则。
- 规则匹配是前提：修改密码后，务必确认
pg_hba.conf中对应连接类型（比如host all all 0.0.0.0/0 md5）的认证方式支持密码（如md5）。 - 重载配置是关键：任何对
pg_hba.conf的修改，都必须通过执行SELECT pg_reload_conf();来通知PostgreSQL服务进程。单纯重启服务在某些部署方式下可能不会触发配置重载。 - 警惕NULL密码：如果用户最初是通过
CREATE USER创建且未指定密码，那么其passwd字段就是NULL。之后即使执行了ALTER USER ... PASSWORD，也可能因为底层机制问题导致认证失败，这时可能需要重建用户。
Na vicat里填对了密码，为什么还提示1045？
Na vicat默认使用TCP/IP连接，但许多本地安装的PostgreSQL为了安全，默认只监听 localhost 或仅接受Unix socket连接。如果你的Na vicat配置里填的是 127.0.0.1，但 postgresql.conf 中的 listen_addresses 参数是空的，那么连接请求在第一步就会被拒绝。
另一个高频“背锅侠”是SSL。Na vicat可能默认尝试使用SSL加密连接，而服务端要么没开启SSL，要么证书配置不匹配。这些复杂的握手错误，有时会被前端笼统地显示为“密码错误”。
- 检查监听地址：查看
postgresql.conf中的listen_addresses参数。确保它包含了'127.0.0.1'（针对本地）或'*'（针对所有IP，谨慎使用）。修改后需要重启服务或执行pg_reload_conf()。 - 尝试关闭SSL：在Na vicat的连接设置中，暂时取消勾选
Use SSL选项进行测试。如果连接成功，再回头检查服务端的ssl = on配置及证书路径是否正确。 - 查看终极日志：最权威的信息永远在PostgreSQL的日志文件里（通常在
pg_log/目录下）。搜索authentication failed关键词，日志会明确告诉你，究竟是「no pg_hba.conf entry」（没有匹配的规则）还是「password mismatch」（密码不匹配）。
用pgAdmin能连，Na vicat连不上：兼容性细节
这往往不是软件本身的Bug，而是协议升级带来的“代沟”。Na vicat对PostgreSQL的协议版本和密码哈希格式更为敏感。例如，PostgreSQL 9.6及以上版本默认采用更安全的SCRAM-SHA-256加密，而较老版本的Na vicat（如12.x之前）可能只支持传统的MD5哈希方式。
强行降低服务端的加密标准并非上策，优先调整客户端才是更合理的思路。
- 确认加密方式：PostgreSQL 10及以上版本，默认
password_encryption参数设置为scram-sha-256。如果Na vicat版本较旧，可以尝试在postgresql.conf中将其改为md5。 - 密码需要重置：重要！修改
password_encryption后，必须使用ALTER USER xxx PASSWORD 'xxx';命令重新设置一遍用户密码。否则，数据库仍会使用旧的哈希值进行验证。 - 检查客户端组件：Na vicat 15及以上版本已支持SCRAM，但在安装时，SSL或SCRAM相关组件可能未被默认勾选。如果遇到问题，可以尝试修复安装，并确保所有功能组件都已安装完整。
在实际排查过程中，最耗费时间的往往不是修改某一行配置，而是无法准确定位错误发生的层面：是网络根本不通？是认证规则没匹配上？还是密码哈希算法不兼容？此时，请务必相信日志。日志中类似 connection matched pg_hba.conf line 83 这样的信息，比任何猜测都更加直接和管用。顺着它指明的路线去检查，问题通常都能迎刃而解。
