ssh页主机填跳板机公网ip或域名，常规页主机填127.0.0.1（同机）或内网ip（跨机），且pg_hba.conf须显式允许127.0.0.1/32，sshd_config中allowtcpforwarding必须为yes。
Navicat里SSH和数据库的主机地址分别填什么
填错主机地址是连接失败最常见原因。关键在于：SSH页面的主机必须是跳板机（即能SSH登录的那台公网服务器）的IP或域名；而常规页面的主机必须是PostgreSQL实际监听的地址——对跳板机而言，它看到的就是127.0.0.1或localhost，不是你本地机器的IP，也不是数据库所在内网服务器的公网IP。
如果PostgreSQL和SSH服务在同一台服务器上，常规页主机填127.0.0.1即可；如果PostgreSQL在另一台内网机器（比如192.168.1.100），那常规页主机就得填这个内网地址，前提是跳板机能直接路由到它（且防火墙放行）。
- 错误示范：
常规 → 主机 = 服务器公网IP→ 隧道建立后，Navicat会尝试从跳板机去连那个公网IP，但通常不通 - 正确逻辑：Navicat →（SSH加密通道）→ 跳板机 →（本地网络）→ PostgreSQL
- 验证方式：登录跳板机后，手动执行
psql -h 127.0.0.1 -U your_user -d postgres，能连上才说明常规页地址填得对
pg_hba.conf没配好会导致“FATAL: no pg_hba.conf entry”
这个错误不是SSH问题，而是PostgreSQL明确拒绝了来自127.0.0.1的连接请求。即使SSH隧道通了，PostgreSQL仍按自己的访问控制规则拦人。
必须在跳板机的pg_hba.conf中添加一条显式允许127.0.0.1/32的规则，不能只写localhost（某些系统解析不一致），也不能依赖0.0.0.0/0（可能被更早的local规则覆盖）。
- 推荐添加这一行：
host all your_db_user 127.0.0.1/32 md5 - 改完必须重载配置：
sudo systemctl reload postgresql或pg_ctl reload，不要用restart - 检查是否生效：用
psql -h 127.0.0.1 -U your_db_user -d postgres在跳板机上直连测试 - 注意顺序：新规则要放在所有
local行之后、更宽泛的host规则之前
SSH隧道连得上但查询卡顿或超时
本质是TCP长连接被中间设备（如NAT网关、企业防火墙）静默断开，而SSH客户端默认不发保活包，PostgreSQL客户端也感知不到底层断连，结果就是卡住几秒后报server closed the connection unexpectedly。
解决方法是在Navicat的SSH配置里启用保活机制，或者改用命令行隧道配合参数（当Navicat内置隧道不稳定时）。
- Navicat SSH页 → 勾选
使用SSH隧道后，点右下角高级→ 填入ServerAliveInterval=30和ServerAliveCountMax=3 - 若高级选项不可用，可手动建隧道：
ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -L 5433:127.0.0.1:5432 user@jump-host，然后Navicat常规页主机填127.0.0.1、端口填5433 - 笔记本休眠或Wi-Fi切换后，旧隧道大概率失效，别等自动重连，手动中断再重建更可靠
群晖或限制严格的Linux服务器要额外开权限
群晖DSM、某些云主机或加固过的Linux系统，默认禁用TCP端口转发，这时即使SSH密码正确、隧道参数无误，也会在Navicat测试连接时卡住或报channel X: open failed: administratively prohibited。
必须修改SSH服务端配置并重启sshd，不是客户端能解决的问题。
- 编辑
/etc/ssh/sshd_config，确认AllowTcpForwarding yes（不是注释状态） - 有些系统还需设
GatewayPorts yes（仅当需从其他机器通过该隧道访问时） - 群晖用户：进DSM控制面板 → 终端机和SNMP → 关闭SSH → 再开启，等同于重启sshd服务
- 改完务必验证：
ssh -O check user@jump-host看是否仍能维持连接
AllowTcpForwarding开关一旦关闭，任何客户端参数都无效——这两处不调通，其他设置全是白搭。**
