PostgreSQL 默认监听地址为 localhost，需修改 postgresql.conf 中 listen_addresses 为 '0.0.0.0' 或局域网段并重启服务；同时在 pg_hba.conf 添加对应网段的 host 认证规则，开放防火墙及云安全组 5432 端口，并确保 Navicat 使用服务器真实 IP 和有权限的用户连接。
PostgreSQL 默认监听地址不是 0.0.0.0
装完 postgresql 后，navicat 在局域网其他机器连不上，最常见原因是 postgresql.conf 里 listen_addresses 没放开。默认值通常是 'localhost'，只允许本机连接。
实操建议：
- 编辑
/etc/postgresql/*/main/postgresql.conf（Linux）或data/postgresql.conf（Windows），找到listen_addresses行，改成listen_addresses = '0.0.0.0'或更安全的'192.168.1.0/24'（按实际局域网段填） - 改完必须重启服务：
sudo systemctl restart postgresql（Linux）或用 Windows 服务管理器重启postgresql-x64-*服务 - 别只改了 conf 就以为好了——漏掉重启，配置完全不生效
pg_hba.conf 没加局域网客户端的认证规则
即使监听开了，PostgreSQL 还会按 pg_hba.conf 逐条匹配客户端 IP 和用户权限。局域网新设备不在白名单里，直接被拒，错误常是 FATAL: no pg_hba.conf entry for host "192.168.1.100"。
实操建议：
- 在
pg_hba.conf文件末尾追加一行（注意位置：规则从上到下匹配，已有 reject 规则可能拦住你新加的）：host all all 192.168.1.0/24 md5
- IP 段要和客户端真实网段一致，比如 Mac 笔记本用 Wi-Fi 可能是
192.168.0.0/24，手机热点可能是172.20.10.0/28，用ipconfig（Windows）或ifconfig（macOS/Linux）确认 - 认证方式选
md5而非trust，后者等于裸奔；如果 Navicat 报密码错误，先检查是不是这里用了trust却没输密码
防火墙或云服务器安全组拦截了 5432 端口
PostgreSQL 默认走 5432 端口，但系统防火墙或云平台（阿里云、腾讯云等）的安全组默认不放行该端口，导致连接超时，Navicat 卡在“正在连接…”或报 Connection refused。
实操建议：
- Linux 上检查并开放端口：
sudo ufw allow 5432（Ubuntu）或sudo firewall-cmd --permanent --add-port=5432/tcp（CentOS） - Windows 防火墙需新建入站规则，协议选 TCP，端口填
5432，作用域设为“本地子网” - 云服务器务必去控制台查安全组——光配本地防火墙没用，安全组才是第一道门；规则方向选“入方向”，源 IP 填客户端 IP 段（如
192.168.1.0/24），协议端口填TCP:5432
Navicat 连接参数填错或用户没远程权限
有时候所有服务端配置都对了，但 Navicat 里填的主机名、端口、数据库名或用户名不对，或者该用户根本没被授权登录远程库。
实操建议：
- 主机名别写
localhost或127.0.0.1——这是指向 Navicat 所在机器自己，应填 PostgreSQL 服务器的真实局域网 IP，比如192.168.1.50 - 确认 PostgreSQL 用户有登录权限：
SELECT usename, usesuper, valuntil FROM pg_user WHERE usename = 'your_user';，如果valuntil是过去时间，说明密码过期，需用ALTER USER your_user PASSWORD 'xxx';重设 - 如果用的是
postgres超级用户，有些生产环境会禁用其远程登录，建议新建专用用户：CREATE USER navuser WITH PASSWORD 'strongpass'; GRANT CONNECT ON DATABASE yourdb TO navuser;
最容易被忽略的是 pg_hba.conf 规则顺序和防火墙双重拦截——改完配置不 reload，或只关了系统防火墙却忘了云平台安全组，都会让前面所有操作白忙。
