PostgreSQL认证失败是数据库连接过程中最常见的问题之一，报错信息通常类似password authentication failed for user "postgres"或者no pg_hba.conf entry for host。很多人第一反应是密码输错了，但实际上密码只是其中一个可能的原因，认证失败还涉及pg_hba.conf的规则配置、密码加密方式、用户角色权限等多个层面。本文将从报错定位入手，逐层分析认证失败的常见原因，并给出对应的解决方案。
一、先读懂报错信息，确定问题类型
遇到认证失败时，不要急着改密码，第一步应该是仔细阅读完整的报错内容，因为PostgreSQL的错误提示其实相当明确。常见的认证失败报错有两类，处理思路完全不同。
第一类是FATAL: password authentication failed for user "xxx"。这个报错说明客户端已经成功找到了pg_hba.conf中匹配的规则，认证流程走到了密码校验环节，但密码不正确或者加密方式不匹配。也就是说，这类问题聚焦在密码本身。
第二类是FATAL: no pg_hba.conf entry for host "192.168.1.100", user "xxx", database "xxx", SSL off。这个报错表示客户端的IP地址、用户名、数据库三者组合起来，在pg_hba.conf中找不到任何一条允许通过的规则，连接直接被拒之门外，根本还没到验证密码那一步。这类问题需要修改配置文件增加授权规则。
另外还有一种容易被忽视的情况：FATAL: role "xxx" is not permitted to log in。这表示用户存在，但账号被禁止登录了，需要用超级用户执行ALTER ROLE xxx LOGIN;来解锁。
二、密码错误与加密方式不匹配的处理
如果确认是密码校验环节失败，最直接的办法是重置密码。用本地信任登录（后面会讲到）进入数据库后执行：
-- 重置postgres用户密码 ALTER USER postgres WITH PASSWORD 'new_password_123'; -- 查看用户的密码加密方式 SELECT rolname, rolpassword FROM pg_authid WHERE rolname = 'postgres';
这里有一个非常经典的坑：PostgreSQL 10之后的版本默认密码加密方式改成了scram-sha-256，而旧版本默认是md5。如果服务端的password_encryption参数是scram-sha-256，而客户端驱动版本太老只支持md5，就会出现密码明明正确却始终认证失败的现象。可以查看postgresql.conf中的这个参数：
# 查看当前密码加密方式 SHOW password_encryption; -- 如果显示 scram-sha-256，而老客户端不支持，可以改为 md5（需重启并重设密码） -- postgresql.conf 中设置： -- password_encryption = md5
需要注意的是，修改加密方式后必须重新设置一遍用户密码，因为已经存储的密码哈希是按旧方式生成的，直接改参数不会自动转换已有的密码记录。这也是很多人改了配置还是连不上的原因。
三、pg_hba.conf配置详解
pg_hba.conf是PostgreSQL的客户端认证配置文件，位于数据目录下，比如Linux环境常见路径是/var/lib/pgsql/data/pg_hba.conf，Windows环境则是类似C:\Program Files\PostgreSQL\16\data\pg_hba.conf。所有远程连接失败问题几乎都要回到这个文件来解决。
文件中每一行代表一条规则，格式为：类型 数据库 用户 地址 认证方式。下面是一个典型配置：
# TYPE DATABASE USER ADDRESS METHOD local all all trust host all all 127.0.0.1/32 scram-sha-256 host all all 192.168.1.0/24 scram-sha-256 host all all 0.0.0.0/0 md5
几个关键点要理解清楚。第一，规则的匹配是从上到下的，命中第一条匹配的规则就停止，所以更具体的规则要放在前面。第二，ADDRESS列写客户端的IP段，0.0.0.0/0表示允许任意IP，生产环境不建议这么放开。第三，认证方式trust表示免密登录，reject表示明确拒绝，md5和scram-sha-256都需要密码。
如果只是本地调试图省事，可以把本地连接设为trust，但生产环境绝对不要这么做，否则任何能访问服务器的进程都可以无密码操作数据库。改完pg_hba.conf后不需要重启数据库，执行重载即可生效：
# 查找pg_hba.conf的位置 SHOW hba_file; # 重载配置（不中断现有连接） SELECT pg_reload_conf(); # 或者用命令行 pg_ctl reload
一个常见的细节问题：如果客户端IP是IPv6地址，而规则里只写了IPv4段，同样会报no pg_hba.conf entry。此时需要增加IPv6规则，例如host all all ::1/128 scram-sha-256。
四、其他容易被忽略的排查点
除了密码和认证规则，还有几个地方值得检查。首先是listen_addresses参数，如果它默认是localhost，PostgreSQL只监听本机回环地址，远程连接会直接失败，报错通常是connection refused而不是认证失败，但经常被混淆在一起排查。需要在postgresql.conf中改为：
listen_addresses = '*' port = 5432
改完这个参数需要重启数据库服务才能真正生效，这点和pg_hba.conf的重载不同。
其次是防火墙问题，Linux环境可以用firewall-cmd --list-ports或者iptables -L -n确认5432端口是否放行。如果报错是连接超时，大概率是防火墙拦截，而不是PostgreSQL本身的问题。
最后是连接字符串写法问题。有些图形化工具或者ORM框架在连接串里没有指定密码或者指定了错误的端口，也会触发认证失败。建议先用psql命令行验证一遍，排除客户端工具自身的因素：
psql -h 192.168.1.50 -p 5432 -U postgres -d mydb
如果命令行能连通而程序连不上，那问题就出在程序的连接配置上，而不是数据库的认证体系。按照报错类型、密码加密方式、认证规则、网络监听这个顺序逐层排查，绝大多数PostgreSQL认证失败问题都能在十几分钟内定位并解决。
postgresql认证失败pg_hba.conf密码认证修改时间：2026-09-14 03:48:39