navicat 17原生支持scram-sha-256，连不上主因是服务端pg_hba.conf未显式配置scram-sha-256认证规则、用户密码未以scram格式重设，或ssl强制策略不匹配；需检查并修正这三项。
Navicat 17 原生支持 SCRAM-SHA-256，但连不上不是客户端问题，而是服务端 pg_hba.conf 认证规则没配对、或用户密码没按 SCRAM 重新设置。
pg_hba.conf 必须显式启用 scram-sha-256 认证
PostgreSQL 16 默认用 scram-sha-256 存储密码，但不会自动在 pg_hba.conf 中启用它——你得手动改规则。否则 Navicat 发起 SCRAM 握手，服务端直接拒绝。
- 找到
pg_hba.conf，在 IPv4 远程连接段（比如# IPv4 local connections下方）添加一行：host all all 0.0.0.0/0 scram-sha-256（若只允许特定 IP，把0.0.0.0/0换成实际网段） - 不能写成
md5或password，那会导致 “authentication method 10 not supported” 错误 - 改完必须执行
SELECT pg_reload_conf();或重启 PostgreSQL 服务，pg_reload_conf()就够了，不用重启
用户密码必须是 SCRAM-SHA-256 格式存储
即使 pg_hba.conf 配对了，如果用户密码还是旧的 MD5 格式（比如 PostgreSQL 12 之前创建的），服务端仍会返回 method 10 不支持——因为密码哈希不匹配认证流程。
- 检查密码是否为 SCRAM 格式：
SELECT rolname, rolpassword FROM pg_authid WHERE rolname = 'your_user';
返回值应以SCRAM-SHA-256$开头，而不是md5 - 如果不是，重设密码：
ALTER USER your_user PASSWORD 'your_new_password';
注意：必须用单引号，且密码不能太简单（SCRAM 要求最小长度，默认 8 位） - 如果用户是用
CREATE USER ... ENCRYPTED PASSWORD 'md5xxx'手动插入的，必须删掉重建或用ALTER USER ... PASSWORD触发重哈希
Navicat 17 连接参数里不需要额外勾选 SSL，但得确认服务端没强制 SSL
SCRAM-SHA-256 本身不要求加密通道，它能在明文 TCP 上安全运行（靠挑战-响应防窃听）。但如果你的服务端启用了 ssl = on 且 pg_hba.conf 规则写了 hostssl，那 Navicat 就必须配 SSL mode；否则连不上是报 SSL 相关错误，不是认证失败。
- 先查服务端是否强制 SSL：
SELECT name, setting FROM pg_settings WHERE name = 'ssl';—— 若为on，再查pg_hba.conf对应规则是否是hostssl而非host - 若只是普通
host+scram-sha-256，Navicat 连接时 SSL mode 选disable即可，不用填证书路径 - 若服务端是云数据库（如阿里云 PolarDB、AWS RDS），它们通常强制
hostssl，此时 Navicat 必须选require或更高，并确保服务端证书链可信
Navicat 17 的“Save Password”勾选与否不影响 SCRAM 连接逻辑
这个选项只控制本地是否缓存密码明文（加密后存进 Navicat 自己的密钥库），和 SCRAM 握手过程完全无关。哪怕不勾，每次连也只是弹窗输密码，认证流程一模一样。
- 不勾选时，Navicat 仍会正常发送 SASLInitialResponse 和后续 challenge-response 数据包
- 真正影响连接成败的只有三件事：pg_hba.conf 规则、用户密码哈希格式、SSL 强制策略是否匹配
- 容易被忽略的是：有些团队在 Docker 启动 PG 时挂载了旧版
pg_hba.conf，覆盖了新配置，导致反复改文件却无效
最常卡住的地方其实是：以为改了 pg_hba.conf 就万事大吉，忘了用户密码还停在 MD5 阶段；或者服务端开了 SSL，但 Navicat 连接配置页根本没点开 SSL 设置区，导致 mode 一直卡在默认的 disable，而服务端等的是加密连接。
