永远雪山1. 先把这个报错拆开看：pgsql 到底在哪个环节连不上
先别被这串英文吓到。pgsql 的连接失败错误提示虽然长，但绝大多数 connection failed、port 5432 failed 的现象都可以归结到三个层面：网络层、服务配置层、认证层。很多新手第一眼看到“connection failed”就以为是服务挂了，接着开始查防火墙、重启服务，折腾半天才发现，服务端日志里明明写的是角色不存在，或者 IP 根本没被 pg_hba.conf 放行。
真正有价值的报错信息往往在冒号后面。比如标题里截断的这段，完整形态通常是：
text复制psql: error: connection to server at "localhost" (:1), port 5432 failed:
FATAL: role "postgres" does not exist
这串内容里，“localhost”“(:1)”“5432”都只是连接目标描述，告诉你客户端在往本机的 IPv6 回环地址 ::1 的 5432 端口发起连接。看到 FATAL: 开头的内容，说明 TCP 连接其实已经建立起来了，是 PostgreSQL 服务端返回了明确的错误信息。“role 'postgres' does not exist”才是真正的根因，和网络通不通、端口通不通没有任何关系。
经常有朋友拿着类似报错来问我，第一句话就是“我密码是不是错了”。不是。角色不存在跟密码错误是两码事。密码错误会提示 password authentication failed，而角色不存在说明服务端在做用户认证时，压根没找到这个登录名。所以排查时，我习惯先把问题分类：连接被拒、超时、SSL 中断属于网络/服务层；FATAL: 后面跟的认证相关消息属于认证层；客户端自己报一堆看不懂的网络请求错误，则往往要先看是不是驱动或环境变量问题。
1.1 FATAL 后面的内容才是数据库给你的“结论”
如果报错里出现了 FATAL:，就要把注意力从前半段挪到后半段。因为连接请求已经到达 PostgreSQL 服务端，数据库完成了 TCP 握手并开始处理认证请求，然后才拒绝了你。这种“能连上但被拒”的情况，排查思路和“根本连不上”完全不同。
常见几种 FATAL：
FATAL: role "postgres" does not exist
数据库里没有叫 postgres 的登录角色。要么用户名写错了，要么初始化数据目录时指定了其他超级用户名。FATAL: password authentication failed for user "xxx"
角色存在，但密码不匹配。重点是检查密码，并确认当前pg_hba.conf用的认证方式是scram-sha-256还是md5。FATAL: no pg_hba.conf entry for host "::1", user "postgres", database "postgres", no encryption
客户端的来源 IP 不在访问白名单里。你可能改了监听地址，却忘了给对应 IP 网段加一条 host 规则。FATAL: database "xxx" does not exist
这更常见，用户和端口都对，但连接的数据库名写错了。
所以第一步，永远是把服务端返回的 FATAL 完整抄下来，再决定下一步。别只看开头几十个英文字母就开始重启服务，那大概率白忙。
1.2 三层定位法：网络层、服务配置层、认证层
我自己排障时习惯不按“现象”走，而是按“阶段”走。连接失败可以理解为一次快递派送：快递员要先把包裹送到小区门口，再让门卫核对身份，最后确认收件人存在。对应到 PostgreSQL 上，就是网络层、服务层、认证层。
第一层，网络能不能到。如果报错是 Connection refused、No route to host、Operation timed out，那问题出在“小区门口”。先查服务有没有启动、端口有没有监听、防火墙有没有放行。
第二层，服务愿不愿意收。如果报错是 server closed the connection unexpectedly、SSL SYSCALL error，一般是 PostgreSQL 的服务配置、SSL 握手或客户端驱动协议出了问题。这一层容易被忽略，因为错误信息不直观，很多经验不足的人会误以为是网络问题。
第三层，身份和权限。只要报错里出现 FATAL:，就说明包裹已经递到门卫手里了。这时候看 `pg_hb