连接PostgreSQL时出现password authentication failed，并不一定只是密码输错。连接到了另一台服务器、用户没有LOGIN权限、pg_hba.conf 命中意外规则，或者旧客户端不支持SCRAM，都可能表现成认证失败。
不要第一步就把认证方式改成trust。 这会绕过密码验证，尤其不能把允许远程地址的规则改成trust来换取临时可用。
先确认连接到了哪里
客户端先把主机、端口、数据库和用户全部写明确，避免本地Unix套接字、环境变量或连接池偷偷改变参数：
psql -h 127.0.0.1 -p 5432 -U appuser -d appdb
env | grep '^PG'本地不写 -h 时通常走Unix套接字，可能命中local规则；写 -h 127.0.0.1 后走TCP，命中host规则。两次结果不同，说明重点在连接路径和认证规则，而不是简单重置密码。
同时检查服务端日志，它会比客户端提示更具体。先核对目标IP、端口和数据库实例，避免在错误服务器上修改正确密码。
找到实际使用的pg_hba.conf
能通过本地管理员连接时，直接查询真实配置路径：
sudo -u postgres psql -Atc "SHOW hba_file;"
sudo -u postgres psql -Atc "SHOW config_file;"
sudo -u postgres psql -Atc "SHOW port;"源码安装、发行版软件包、容器和托管环境的路径都可能不同，不要只按网上示例编辑 /var/lib/pgsql/data/pg_hba.conf。容器内修改临时文件，重建容器后还可能丢失。
PostgreSQL按连接类型、客户端地址、数据库和用户选择第一条匹配规则。该规则认证失败后不会继续尝试下面的备用规则，所以顺序与内容同样重要。
检查规则语法和命中顺序
以超级用户查询规则视图，可以看到每行的来源、顺序、地址、认证方法与语法错误：
SELECT rule_number, line_number, type, database, user_name,
address, auth_method, error
FROM pg_hba_file_rules
ORDER BY rule_number NULLS LAST, line_number;error 非空表示该行不能正确应用。需要特别检查是否有更宽的 all all 0.0.0.0/0 规则排在业务专用规则前面，以及IPv4和IPv6地址是否分别覆盖。
规则应使用最小数据库、用户和网段范围。 不要为解决一个应用连接，就把所有数据库对所有公网地址全部放开。
确认角色可以登录并重置密码
通过管理员会话检查角色属性：
SELECT rolname, rolcanlogin, rolvaliduntil
FROM pg_roles
WHERE rolname = 'appuser';用户不存在、rolcanlogin 为false、密码为空或已经超过有效期，都需要针对性处理。重置密码时优先在psql中使用 \password appuser，避免明文密码进入shell历史。
也可以在受控会话执行 ALTER ROLE appuser WITH LOGIN PASSWORD '新密码';，但要确保终端记录和审计策略不会泄露明文。数据库角色密码与Linux系统用户密码相互独立，修改系统密码不会改变PostgreSQL认证。
处理SCRAM与旧客户端兼容问题
当前PostgreSQL官方文档推荐 scram-sha-256，MD5加密密码已经进入弃用阶段。SCRAM更安全，但过旧的驱动或客户端库可能不支持，迁移前要先盘点应用版本。
一个收紧范围的TCP规则示例是：
hostssl appdb appuser 10.20.0.0/16 scram-sha-256设置 password_encryption = 'scram-sha-256' 只影响之后设置的新密码，已有用户通常需要重新设置密码才能获得SCRAM哈希。不要用明文password认证替代SCRAM；若使用password方法，至少必须由可信TLS连接保护。
修改后安全加载配置
保存前可先查询 pg_hba_file_rules 检查当前文件内容，确认没有语法错误后再重载：
SELECT pg_reload_conf();也可以按发行版使用 systemctl reload postgresql。修改 pg_hba.conf 通常只需要reload，不必直接重启数据库；但托管数据库或容器平台可能要求通过参数组、挂载文件或控制面板操作。
重载后用一个新的客户端会话测试，旧连接不会重新认证。需要准备隔离环境演练规则顺序时，可以使用 萤光云 部署测试实例；要验证不同地区应用连接，可通过 LightNode 临时建立客户端。不要复制生产数据库或真实密码到测试机。
修复后的验收标准
使用与应用完全相同的主机、端口、数据库、用户名和TLS参数建立新连接：
psql "host=db.example.com port=5432 dbname=appdb user=appuser sslmode=require"连接成功后执行 SELECT current_user, current_database(), inet_server_addr(), inet_server_port();，确认没有误连其他实例。随后观察服务端日志，确保不再出现该应用的新认证失败。
验收应同时满足目标账户可登录、非授权用户仍被拒绝、规则网段没有扩大，并且应用使用的客户端库兼容当前认证方法。
FAQ
为什么本机psql能连，远程应用却失败？
本机可能走local规则和Unix套接字，远程应用走host或hostssl规则。两者可能采用不同认证方式。
把pg_hba.conf改成trust能快速解决吗？
trust会绕过密码验证，不适合作为公网或生产环境的修复方案。应找到首条命中规则和真实失败原因。
修改pg_hba.conf后必须重启PostgreSQL吗？
通常reload即可，使用 pg_reload_conf() 或发行版提供的reload方式。新规则对之后建立的连接生效。
温馨提示
修改认证规则时始终保留一个已验证的管理员会话和控制台入口。先用规则视图检查语法，再重载并用新会话验证，可以降低把自己锁在数据库外的风险。
