上周接手一个排查任务客户的 Odoo 系统跑在内网服务器上研发同事想从办公室直连 PostgreSQL 数据库做数据核对结果 psql 一执行就是 Connection refused试了几次换端口、改密码都不行。这类问题我处理过很多次说穿了就三个环节没对齐PostgreSQL 服务端没对外监听、认证规则没放行、防火墙或安全组把端口挡了。今天就把以 Odoo 数据库为实例的 PostgreSQL 远程连接配置从原理到实操完整走一遍适合刚接触 PostgreSQL 运维、或者正在部署 Odoo 但被数据库连接卡住的人参考。1. 动手前的路线图远程连接请求要过几道关卡1.1 一条连接请求从客户端到 PostgreSQL 的完整链路远程连接 PostgreSQL 不是改一个文件就能搞定的事它是一条链路客户端发请求 → 操作系统网络层 → PostgreSQL 监听端口 → 认证规则校验 → 数据库权限校验。任何一环断了表现出来都是连不上。客户端可能是 Odoo 应用服务器也可能是你电脑上的 psql 或 DBeaver。请求首先到达目标服务器的 5432 端口PostgreSQL 默认端口这一步要求 PostgreSQL 进程真的在监听这个端口而不是只监听本机的 127.0.0.1。走到端口之后PostgreSQL 的 postmaster 进程会读取 pg_hba.conf 里的规则按顺序匹配客户端 IP、数据库名、用户名决定是否接受这个连接以及用什么方式验证密码。全部通过后再检查用户对目标数据库是否拥有 CONNECT 权限。很多人只改了一个配置就觉得应该通了其实后面还有两三层在把关。所以排查时我习惯按链路顺序走先看监听、再看认证规则、最后看防火墙而不是拿着报错信息瞎猜。1.2 为什么 Odoo 的场景特别需要远程数据库访问Odoo 本身是典型的应用与数据库分层架构应用服务器负责业务逻辑数据全部存在 PostgreSQL 里。实际部署中把 Odoo 应用和 PostgreSQL 放在同一台机器是最省事的方式但生产和测试环境一旦分开就会遇到以下情况开发人员需要连生产库查数据ETL 工具要定时抽取业务表数据分析师需要用外部 BI 工具读取视图这些需求全部指向同一件事允许 PostgreSQL 被远程访问。Odoo 还有一个特点它会自动创建和管理数据库。当你打开 Odoo 的数据库管理页面看到的是一个数据库列表而不是单独的库。这意味着如果你要远程连接 Odoo 的数据通常不是只连一个库而是可能同时连生产库、测试库甚至多个客户的独立库。这种情况下pg_hba.conf 里的认证规则设计就尤其重要既要让合法用户连上又不能把所有库和所有用户全部暴露给任意 IP。1.3 本次实践的环境与准备工具我这次以一套常见环境为例Ubuntu 服务器上装了 PostgreSQL 14Odoo 16 应用也在运行目标是让办公室网络比如 192.168.1.0/24 网段能够通过 TCP 远程连接数据库。这套步骤在 Debian、CentOS、Rocky Linux 上同样适用只是配置文件路径略有差异后面会专门说明。准备工具只需要三样服务器上的 psql 命令行、客户端电脑上的 psql 或者 DBeaver、以及一个能打开配置文件的编辑器。我建议至少先用 psql 做链路验证因为它能帮你精确区分问题出在哪一层。DBeaver 这类图形工具虽然好操作但它的报错信息有时候会被包装反而不如终端输出来得直接。2. 服务端配置postgresql.conf 和 pg_hba.conf 的正确改法2.1 先让 PostgreSQL 监听外部地址PostgreSQL 安装后默认只监听 localhost也就是仅接受本机连接这是它安全保守的设计。要让远程能连第一步是修改 postgresql.conf 里的 listen_addresses 参数。打开 postgresql.conf找到这一行#listen_addresses localhost默认是注释状态说明采用内置默认值 localhost。改成星号表示监听所有网卡接口listen_addresses *如果你不希望开放所有接口只想让某个内网 IP 能连也可以写成listen_addresses 192.168.1.100, 10.0.0.5这里有个很多人忽略的点listen_addresses 属于启动参数不是热加载参数改完必须重启 PostgreSQL 才生效。我碰过有人用 SELECT pg_reload_conf(); 想让它生效结果等了半天还是连不上最后发现根本没重启。后面我会把重启命令统一列出来。2.2 再写认证规则pg_hba.conf 的字段与顺序postgresql.conf 决定的是在哪里监听pg_hba.conf 决定的才是让谁进来、怎么验证身份。这个文件的名字叫 Host-Based Authentication看到 HBA 就应该明白它能精确控制到主机、数据库、用户的组合。pg_hba.conf 里一行的基本格式是TYPE DATABASE USER ADDRESS METHOD其中 TYPE 通常有四种localUnix 套接字连接、hostTCP 连接、hostssl强制 SSL 的 TCP 连接、hostnossl不带 SSL 的 TCP 连接。远程连接走的是 host 这一类型所以我们关心的是以 host 开头的规则。比如我要允许 192.168.1.0/24 网段的机器使用 odoo_user 连接 odoo_db 这个数据库用密码验证添加这样一行host odoo_db odoo_user 192.168.1.0/24 scram-sha-256如果希望这个网段能连接这台 PostgreSQL 上的所有数据库、所有用户可以用 all 简化host all all 192.168.1.0/24 scram-sha-256需要注意的是pg_hba.conf 是会从上往下顺序匹配的第一条匹配到的规则先生效。这意味着更严格的规则要放在更宽泛的规则前面。很多安全问题的根源就是有人把 host all all 0.0.0.0/0 md5 写在最前面等于直接给全互联网开放了数据库端口。2.3 不同 Linux 发行版的配置文件位置与重启方式不同发行版的 PostgreSQL 配置文件路径差异挺大很多人第一次找文件时就卡住了。Ubuntu 和 Debian 系的路径是/etc/postgresql/14/main/postgresql.conf /etc/postgresql/14/main/pg_hba.conf其中 14 是 PostgreSQL 的主版本号main 是集群名。RHEL、CentOS、Rocky Linux 系的路径一般是/var/lib/pgsql/14/data/postgresql.conf /var/lib/pgsql/14/data/pg_hba.conf注意 RHEL 系通常默认数据目录归 postgres 用户所有编辑文件时可能需要先切到 postgres 用户或者用 sudo 加权限。重启服务的命令在不同发行版也不一样Ubuntu 是sudo systemctl restart postgresqlRHEL 系可能是sudo systemctl restart postgresql-14不确定服务名的话先执行 systemctl list-units | grep postgres 看看实际名称。如果你只是改了 pg_hba.conf不需要重启执行重载即可sudo systemctl reload postgresql或者直接用 SQL 命令在数据库里重载SELECT pg_reload_conf();3. 网络层与防火墙一半的远程故障都卡在这一层3.1 监听地址、端口和网卡的关系服务端配置改完很多人以为就能通了结果在客户端一测还是超时。这时候大概率问题出在网络层。先明确一个概念PostgreSQL 监听 5432 端口不等于防火墙放行了 5432 端口。系统收到请求后要先过防火墙规则通过之后才会把数据包交给 PostgreSQL 进程。在服务器上检查 PostgreSQL 到底在监听什么用这条命令ss -tlnp | grep 5432正常输出应该类似LISTEN 0 244 0.0.0.0:5432 0.0.0.0:* users:((postgres,pid12345,fd8))注意看 0.0.0.0:5432 这一部分出现 0.0.0.0 说明监听了所有 IPv4 接口如果出现的是 127.0.0.1:5432说明 listen_addresses 没生效或者服务没重启。如果只有 ::1:5432那你可能陷入了 IPv6 的回环地址远程 IPv4 请求自然永远到不了。3.2 firewalld、UFW 与云安全组的放行方法服务器上的防火墙通常有两种常见实现RHEL 系大部分用 firewalldUbuntu 上最常见的 ufw。firewalld 添加放行规则的方式是sudo firewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.168.1.0/24 port protocoltcp port5432 accept sudo firewall-cmd --reloadUFW 的写法相对简单指定来源网段和端口即可sudo ufw allow from 192.168.1.0/24 to any port 5432 proto tcp除了服务器自身防火墙还有一个最容易忽略的地方云平台的安全组。现在部署服务器基本都会用某云厂商的云主机安全组是在操作系统外部做隔离的一道虚拟防火墙就算你在服务器里把 ufw 全部放行只要安全组没开放 5432外部照样连不进来。安全组的规则通常在云平台控制台的网络与安全组件里配置添加一条入方向规则协议 TCP端口 5432来源设为 192.168.1.0/24 或者你的办公网 IP。3.3 放行策略怎么收窄才安全防火墙和 pg_hba.conf 有个共同原则授权范围越窄越好。我在给客户配置时至少会确认三个问题你从哪个 IP 段访问需要访问哪些库用哪个用户如果回答都是全部、全部、所有用户那就要引起警惕了。比较推荐的策略是先在防火墙层放行你当前的办公网 IP比如sudo firewall-cmd --permanent --add-rich-rulerule familyipv4 source address203.0.113.10 port protocoltcp port5432 accept sudo firewall-cmd --reload再在 pg_hba.conf 里配合一个更细的授权让权限收敛到具体用户和库。层层收窄之后即使某层配置失误剩余的防线也能兜住。4. 客户端测试与 Odoo 侧的连接配置4.1 用 psql 先验证链路再动 Odoo在去动 Odoo 配置之前我强烈建议先用客户端工具验证一下数据库远程连接本身是否正常。这一步能帮你把数据库链路问题和ODoo 配置问题分开避免两个变量混在一起无法排查。在客户端电脑上执行psql -h 192.168.1.100 -p 5432 -U odoo_user -d odoo_db -W-h 指定数据库服务器 IP-U 指定用户-d 指定数据库-W 表示连接时提示输入密码。如果一切正常你会进入 psql 的交互界面看到类似 odoo_db 的提示符。如果连不上psql 会给出明确报错后面的排查章节会详细处理这些报错。有的人不喜欢交互输密码想一条命令直接验证也可以用 PGPASSWORD 环境变量但注意这种方式会把明文密码留在 shell 历史里仅限测试环境使用不要写进脚本或生产环境PGPASSWORD某密码 psql -h 192.168.1.100 -U odoo_user -d odoo_db -c SELECT version();4.2 Odoo 配置文件里的数据库连接参数Odoo 默认通过 Unix socket 连接本机 PostgreSQL所以安装完通常不需要专门配置数据库连接。但当你把数据库迁移到独立服务器或者分配了专门的数据库主机给 Odoo就需要修改 Odoo 的配置文件。Odoo 的配置文件通常位于 /etc/odoo/odoo.conf也有部署方式会用到 /etc/odoo-server.conf。在 [options] 段下关注这几个参数db_host 192.168.1.100 db_port 5432 db_user odoo_user db_password 你设置的密码 db_name odoo_prod如果 db_name 不填Odoo 默认会连接并管理 PostgreSQL 实例里所有的数据库这就是为什么 Odoo 的数据库列表页面能看到多个库。db_host 留空表示走 Unix socket一旦你填了 IP 或主机名Odoo 就会通过 TCP 方式连接这时候前面配置的远程连接能力就派上用场了。改完配置文件之后重启 Odoo 服务让配置生效sudo systemctl restart odoo重启之后打开 Odoo 登录页如果配置正确应该能正常展示数据库列表并登录业务系统。如果一直显示数据库连接错误或者转圈卡住大概率是数据库链路本身还有问题。4.3 连接多数据库实例时的注意事项Odoo 环境里经常存在多个数据库比如生产库、测试库、干库。远程连接时pg_hba.conf 的规则匹配顺序就特别重要。比如你想让办公网 IP 只能连 odoo_prod但配置里写了 host all all ...后写的限定规则因为排在被 all 匹配的规则之后永远没有机会生效。我建议把最具体的规则放在文件最前面比如先放只针对 odoo_prod 和 odoo_user 的规则再放针对测试环境的规则最后才考虑兜底规则。另一个容易踩的坑是Odoo 的 db_user 如果在 PostgreSQL 里没有 createdb 权限Odoo 创建新数据库时会失败。远程连接数据库时建议给 Odoo 专用用户赋予适当的 createdb 权限但不要让它拥有 superuser 权限够用就好。5. 错题本高频故障的现象、原因与排查步骤5.1 认证失败类问题认证失败是最常见的一类报错通常是FATAL: password authentication failed for user odoo_user这个报错意思是 PostgreSQL 已经接收了连接请求也匹配到了 pg_hba.conf 中的规则但密码校验没通过。首要排查的当然是密码是否正确但还有一个隐蔽原因用户密码在数据库里的加密存储格式和 pg_hba.conf 指定的认证方式不匹配。PostgreSQL 14 之后密码默认用 scram-sha-256 算法加密但如果你把 pg_hba.conf 里的认证方式写成了 md5而用户密码还是老旧的 md5 格式就会出现认证失败。这种情况下重新设置一次密码可以解决问题ALTER USER odoo_user PASSWORD 新密码;修改之后确保 pg_hba.conf 里对应的认证方式是 scram-sha-256而不要继续用 md5。如果报错是FATAL: no pg_hba.conf entry for host 192.168.1.50, user odoo_user, database odoo_db, no encryption这说明服务器接受了连接但在 pg_hba.conf 里根本找不到一条匹配的规则。解决办法就是对照第 2.2 节的格式检查规则内容确认网段、数据库、用户名都写对了。5.2 连接拒绝与超时先分清层级Connection refused 和 Connection timed out 是两个完全不同的问题。前者说明请求已经到达服务器对方主动拒绝了连接后者说明请求根本还没到服务器中途被丢弃了。遇到 Connection refused先看 PostgreSQL 是否在监听ss -tlnp | grep 5432如果监听的是 127.0.0.1:5432 而不是 0.0.0.0:5432多半是 listen_addresses 没改或者没重启。还有一种情况是 PostgreSQL 进程没起来检查一下服务状态。如果是 Connection timed out优先怀疑防火墙和安全组。在服务器本机测试端口是否开放timeout 2 bash -c echo /dev/tcp/192.168.1.100/5432 echo open || echo closed在客户端电脑上用 telnet 或者 nc 测一下从外部到端的可达性nc -vz 192.168.1.100 5432通的话会返回 open 或 success不通则会提示超时或拒绝。这一步能帮你快速判断问题在操作系统防火墙还是云安全组还是更上层的网络策略。5.3 本地能连远程不能连本地能连、远程连不上是另一个高频组合。这种场景里的典型原因是你确认了 pg_hba.conf 有 host 规则listen_addresses 也改了服务也重启了但远程 telnet 端口还是不通。这时候把思路从PostgreSQL 配置转向操作系统和网络层检查是不是本机防火墙拦截了外部请求或者云安全组没有放行。还有一个不那么显眼的因素服务器如果开了 IPv6而客户端用 IPv4 连接或者反过来都会导致本地能连远程不能连的怪异现象。测试时可以强制指定协议族例如psql -h 192.168.1.100 -U odoo_user -d odoo_db -W如果是 IPv6 问题可以看看服务器上 PostgreSQL 是否同时监听了 :: 和 0.0.0.0用 ss -tlnp 就能看到。5.4 常见问题速查表报错或现象可能原因排查/解决方式Connection refused监听地址没改或服务没重启检查 ss -tlnp 输出确认监听 0.0.0.0:5432Connection timed out防火墙或安全组拦截用 nc 测试端口检查 ufw、firewalld、云安全组password authentication failed密码错误或认证方式不匹配重置密码将认证方式改为 scram-sha-256no pg_hba.conf entry规则缺失或顺序错误检查 pg_hba.conf 的 host 规则及顺序peer authentication failed本地 Unix socket 认证用了 peer强制走 TCP即指定 -h 为 IP 地址FATAL: database xxx does not exist数据库名拼错或未创建确认数据库名createdb 创建本地能连远程不能连防火墙、安全组、IPv4/IPv6 不匹配逐层检查监听、防火墙、安全组6. 安全加固远程连接不等于把数据库暴露在公网6.1 隔离账号与最小权限远程连接配置完成后第一件事应该是检查你用什么用户连数据库。我见过不少项目为了方便直接用 postgres 超级用户远程连接这是十分危险的做法。postgres 用户拥有数据库实例的全部权限一旦账号泄露等于把整个服务器上的所有数据库都交给了攻击者。正确的做法是单独创建一个应用专用账号只授予它需要的权限。比如 Odoo 需要的权限通常是对指定库的 CONNECT 和读写权限CREATE USER odoo_user WITH PASSWORD 强密码; GRANT CONNECT ON DATABASE odoo_db TO odoo_user; GRANT USAGE ON SCHEMA public TO odoo_user;如果 Odoo 需要管理数据库比如建库、删除库再额外赋予 createdb 权限但依然不建议给它 superuser。隔离账号的思路是把应用需要的权限和运维需要的权限分开这样即使应用侧被攻破影响面也不会扩散。6.2 限定来源地址与连接监控远程连接开启之后我建议在 pg_hba.conf 里做来源 IP 的严格限定。比如只允许你的办公网段或跳板机 IP 连接而不是写 0.0.0.0/0。配合防火墙规则让数据库端口只对必要的 IP 开放这层工作做好之后日常压力会小很多。与此同时建议定期检查数据库连接来源用这条 SQL 可以实时看到当前所有连接是谁发起的、来自哪个 IP、处于什么状态SELECT usename, client_addr, state, count(*) FROM pg_stat_activity GROUP BY usename, client_addr, state ORDER BY count(*) DESC;如果你定期执行这条查询发现某个 IP 频繁连接但请求模式明显不像 Odoo 应用就需要警惕考虑是不是有异常扫描或暴力破解尝试。配合 PostgreSQL 日志一起看能获得更完整的判断依据。6.3 日志与备份的日常节奏最后再提醒一个容易被忽略的点开启远程连接后PostgreSQL 日志的价值会大幅上升。默认情况下认证失败和连接请求都会记录在日志里路径一般是 /var/log/postgresql/postgresql-14-main.log。当远程连接出现问题时日志里能看到比客户端更详细的错误信息排查效率会高很多。备份节奏也要重新审视远程连接意味着数据访问面变宽了但备份策略不应该因此改变反而要更严格。我的习惯是数据库主机上保留每日自动备份同时把备份文件同步到独立存储防止主机故障导致备份也没了。远程连接只是方便了访问不能代替备份这层保险。说到这里其实整个流程已经完整了先改 listen_addresses 让 PostgreSQL 监听外部地址再改 pg_hba.conf 放行认证规则最后打通防火墙和安全组并用 psql 做逐层验证最后把 Odoo 的应用配置指到远程数据库。整个过程看着步骤多但每层都是独立问题按链路顺序排查基本不会跑偏。我个人在实际操作中最后再分享一个小技巧每次改完 pg_hba.conf不要急着关文件走人顺手执行一下 SELECT pg_reload_conf(); 并在本机跑一条 psql 验证确认规则确实生效了再去动 Odoo 配置。这套动作看上去多花几秒钟但常常能帮你免掉一次远程改配置改到一半连自己都进不去的尴尬局面。
