用途：该技能面向 PostgreSQL 客户端无法连接或连接被拒绝的排查场景，聚焦认证与连接阶段的错误。资料指出连接被拒分两个阶段：先扫描 pg_hba.conf（自上而下，首条匹配生效），再执行选定的认证方法；通过认证后还可能因连接槽耗尽被拒绝。
主要能力：
- 错误分流。针对 no pg_hba.conf entry（28000）、pg_hba.conf rejects connection、password authentication failed（28P01）、no PostgreSQL user name specified、server does not support SSL、SSL connection is required、too many clients already / remaining connection slots are reserved（53300）给出处理方向；Connection refused 被明确排除在认证问题之外。
- pg_hba.conf 管理。记录需同时匹配连接类型、地址、数据库与用户；改后必须 reload，不重启。可用 SELECT pg_reload_conf(); 应用，并用 pg_hba_file_rules 检查行号、类型、库、用户、地址、认证方法与 error。
- 认证方式选择。本地同 OS 用户用 peer；服务脚本、TCP 密码登录用 scram-sha-256；机器对机器可用 cert（配合 hostssl）；企业 SSO 用 ldap / gss；需硬阻断用 reject。资料明确：绝不在 TCP 主机上用 trust，新部署不用 md5。
- md5 迁移到 scram-sha-256。先设 password_encryption，再重设每个角色密码，最后切换 HBA 行；否则正确密码也会得到 28P01。可用 SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%'; 查找仍为 md5 的角色。
- TLS 与 sslmode。服务端 ssl = on 需重启；hostssl 要求 SSL；客户端生产建议 sslmode=verify-full。资料强调 sslmode=require 只加密、不验证服务器身份，不能防中间人。
- 连接数耗尽。先用 pg_stat_activity 按 state 统计，必要时以超级用户回收空闲后端，再考虑 PgBouncer 事务模式；不建议盲目提高 max_connections。
适用场景：pg_hba.conf 配置或审计、认证方法切换、密码加密方式迁移、TLS 部署、连接数告警。限制：不覆盖角色权限、GRANT、RLS（42501），也不处理未到达 pg_hba.conf 的网络层错误。缺失信息：官方文档、参考链接与具体版本适用性未在本资料中展开。