企业官网建设流程全解析

1. 先把"连不上"拆成三层，别一上来就改配置

装完 PostgreSQL 本地跑得好好的，换一台机器连就报错，这个场景几乎每个运维和后端都撞上过。PostgreSQL 设置允许其他 IP 访问数据库这件事，本质上是三道门同时打开才行：网络能通、服务在听、认证放行。少任何一道，客户端看到的都是一句冷冰冰的连不上，但背后的原因完全不同。

我见过太多人一碰到连不上就直奔pg_hba.conf，在里面加一行host all all 0.0.0.0/0 md5，重启，还是连不上，然后开始怀疑人生。问题往往根本不在认证层——pg_hba.conf的报错和端口不通的报错，长得完全不一样，只是没仔细看那一行错误信息而已。

这篇内容适合三类人：刚把数据库从本机搬到内网服务器的开发者、要给测试环境开放远程访问的运维、以及在容器里跑 PostgreSQL 却连不进去的同学。我会按"从下往上"的顺序拆：先讲清楚默认配置为什么这么保守，再一步步改监听、改认证规则、打通网络，最后给一份排错速查表和几个真金白银换来的坑。有基础的同学可以直接跳到第 3 章的规则写法，新手建议按顺序看，中间跳步会漏掉关键点。

1.1 默认配置为什么这么"保守"

PostgreSQL 出厂默认把listen_addresses设成localhost，意思是进程只在回环地址 127.0.0.1 和 ::1 上绑 5432 端口。同时pg_hba.conf里只有针对本机回环的几条记录，认证方式在 Debian 系上通常是peer（本地 socket 用系统用户名匹配）加scram-sha-256，在 RHEL 系上本地是peer或ident、回环是ident。

这套默认值的出发点很朴素：单机开发，只有自己用，最小暴露面。数据库产品没法假设你的网络环境是安全的，所以默认一律"只开本地"，剩下的交给使用者自己判断。这个设计我挺认可——比起某些中间件默认监听0.0.0.0还带默认弱密码，PostgreSQL 的做法是把门槛放在明面上，逼你想清楚再开。

理解了这个前提，你就明白改动不是"修 bug"，而是"主动放开限制"。既然是主动放开，就得知道每放开一层会带来什么后果，而不是照着某篇帖子抄一行配置了事。

1.2 三道门：网络可达、端口监听、认证放行

我把这三道门的分工说清楚，后面排查就按这个顺序来。

第一道，网络可达。从客户端到服务器之间，有没有防火墙规则、安全组策略、NAT 转发把你挡在外面。这道门的典型症状是连接超时（timeout）或者目标不可达（no route to host）。

第二道，端口监听。postmaster 进程到底有没有在那个网卡地址上 listen 5432。这道门的典型症状是"Connection refused"，意思是包到了服务器，但那个地址那个端口上没有进程接收，内核直接回了 RST。

第三道，认证放行。连接能建立，握手阶段服务端检查pg_hba.conf，找不到匹配记录就拒绝，报no pg_hba.conf entry for host ...；找到了但密码或认证方式不对，报password authentication failed。

排查顺序应该是从下往上：ss看监听，nc或telnet测端口，最后才翻pg_hba.conf。反过来做，你会在一堆正确的配置里找一个不存在的错误。

注意：Connection refused和连接超时是两回事。前者说明网络通了但没服务，后者说明网络本身不通。这个区分能省掉你至少半小时。

2. 第一步：让进程真的在外部地址上监听

2.1 listen_addresses 的四种写法与取舍

这个参数决定了 postmaster 在哪些地址上 bind 端口，取值有几种常见形态，安全性差别很大。

生产环境我更推荐最后一种：把内网网卡的具体地址写上去，而不是图省事用*。原因很实际——一台服务器上经常有好几张网卡，一张内网、一张带公网地址、可能还有一张专线或管理网。写*等于在所有网卡上全开，包括那张你根本没打算让数据库跑的。

写成具体地址之后，即使pg_hba.conf误放了某个网段，攻击面也被限制在那一张网卡上，多一层保险。代价是换机器、改 IP 的时候要记得同步改配置，这个用配置管理工具或者启动时的环境变量注入都能解决。

还有个容易忽略的点：listen_addresses只影响 TCP 监听，Unix socket 是另一个参数unix_socket_directories控制的。有人把listen_addresses设成空字符串''，以为彻底禁掉网络访问，结果本地psql还能连——因为走的是 socket。这个特性在"只想允许本地 socket 连接"的场景里反而很有用。

2.2 先确认你改的到底是哪个文件

这是我最想强调的一条。同一台机器上可能存在多个 PostgreSQL 实例、多个版本，甚至一个是用包管理器装的、一个是编译装的。你改的那个/etc/postgresql/14/main/postgresql.conf很可能根本不是服务正在读的那个。

先用超级用户登进去，问数据库自己：

SHOW config_file; SHOW hba_file; SHOW data_directory; SELECT version();

返回的路径才是真相。不同安装方式下路径差别很大：

Debian 系还有个细节：/etc/postgresql/下面按版本和集群名分目录，一台机器上可以同时有 14 和 16，各自独立。改错目录的话，reload会成功（因为改的是没人读的文件），但你想要的规则一条都没生效，这种"静默失败"最耗时间。

2.3 改完要重启还是重载，这个别搞混

两个配置文件的性质不一样，生效方式也不一样：

• postgresql.conf里的listen_addresses是 postmaster 级别参数，改完必须重启服务进程，reload不起作用。
• pg_hba.conf是每次连接时读取的，改完reload就够，不需要断开现有连接。

重启命令按发行版来：

# systemd 通用 sudo systemctl restart postgresql # Debian/Ubuntu 多集群管理 sudo pg_ctlcluster 14 main restart # 老式 init 脚本 sudo service postgresql restart

只改pg_hba.conf的话用重载更温和：

# 命令行方式 sudo pg_ctlcluster 14 main reload # 或 sudo systemctl reload postgresql # SQL 方式，不需要操作系统权限 SELECT pg_reload_conf();

提示：reload之后养成看好习惯——查一下日志有没有pg_hba.conf was not reloaded这类提示。语法错的时候 PostgreSQL 会拒绝新配置并继续用旧的，服务看起来一切正常，实际上你改的东西一个字都没生效。

重启前记得确认没有长事务在跑，生产库上直接 restart 会把正在执行的查询全部打断。干净的做法是先看pg_stat_activity里有没有长时间运行的语句，选个低峰期再动。

3. pgb_hba.conf 的规则：五个字段决定一切

（小节标题保持编号规范）

3.1 一条记录到底由哪些部分组成

pg_hba.conf每行一条规则，字段之间用空格或制表符分隔，格式是：

类型 数据库 用户 地址 认证方式 [认证选项]

逐字段拆开看：

类型（TYPE）：local走 Unix socket，host走 TCP（IPv4 和 IPv6 都可以），hostssl要求必须是 SSL 加密连接，hostnossl反过来只接受非加密连接，hostgssenc是 GSSAPI 加密。想强制加密就用hostssl，这条比在应用侧配sslmode=require更可靠，因为它在服务端拦。

数据库（DATABASE）：可以写具体库名、逗号分隔的库名列表、all（除replication外所有库）、sameuser（用户名和库名相同时匹配）、samerole、replication（物理复制连接专用）。

用户（USER）：具体角色名、逗号列表、all，或者用+前缀引用一个角色组。注意all不包含保留角色。

地址（ADDRESS）：CIDR 格式，比如192.168.10.0/24、10.0.0.5/32、0.0.0.0/0（所有 IPv4）、::/0（所有 IPv6）。也可以写成IP 掩码的旧式写法，比如192.168.10.0 255.255.255.0。local类型不写这个字段，写all或具体用户名也可以。

认证方式（METHOD）：trust、reject、md5、scram-sha-256、password、peer、ident、cert、gss、sspi、ldap、radius、pam、bsd。后面还可以跟选项，比如ldap的ldapserver=、pam的pamservice=。

这五个字段理解了，剩下的就只是排列组合。

3.2 匹配顺序：第一条命中就停，后面的规则根本不看

这是pg_hba.conf最容易被误解的地方。规则是从上往下逐条比对的，第一条完全匹配的连接类型、数据库、用户、来源地址的规则生效，匹配成功后立刻停止，后面的规则一律不看；如果一条都没匹配上，连接被拒绝，日志里打no pg_hba.conf entry。

所以规则顺序本身就是安全策略。举个反面教材：

# 顺序错了，后面两条形同虚设 host all all 0.0.0.0/0 trust host app app 10.0.3.0/24 scram-sha-256 host all all 10.0.3.0/24 reject

第一条把所有来源都放了，还免密，后面两条永远不会被执行。正确写法是把范围小的放前面：

# 先精确匹配，再逐级放宽 host app app 10.0.3.0/24 scram-sha-256 host all all 10.0.3.0/24 scram-sha-256 host all all 0.0.0.0/0 reject

最后那条reject是兜底，明确拒绝所有未在上面列出的来源。有这个兜底的好处是，一旦有人在上面的规则里写了个过宽网段，你至少能通过日志看到真实的连接尝试，而不是全都被一条trust悄悄放过。

我个人习惯在文件末尾留一行reject兜底。它不会改变任何已有行为，只是把"默认拒绝"这件事写明白，让后来接手的人一眼看出这是有意为之的策略，而不是漏配。

3.3 认证方式怎么选：别图省事用 trust

认证方式的选择直接影响安全边界，这里逐个说清楚。

trust：无条件放行，不验证任何凭据。只能用在完全可控的环境，比如容器内部服务间通信，或者干脆只监听回环。放在0.0.0.0/0上等于把数据库裸奔，任何能扫到端口的人都可以直接进去，改表、删库、读全量数据。这个绝对不能用于任何对外网络。

peer：只能用于local类型，拿操作系统用户名匹配数据库用户名。本地 socket 连接的默认方式，安全性不错，因为要和系统账号对上。

ident：通过 identd 服务反查客户端系统用户，跨网络场景基本不可靠，现代环境很少用。

md5：密码用 MD5 哈希传输验证。历史上是主流，缺点是 MD5 本身已不安全，而且存储的也是 MD5 哈希。

scram-sha-256：基于 SCRAM 的挑战应答，密码不落地明文、传输过程也不能被重放。PostgreSQL 10 引入，14 之后成为默认。新环境一律用这个。

cert：基于客户端证书，配合 SSL 使用，适合机器间强认证。

password：明文密码传输，只在 SSL 加密通道里才勉强可用，否则等同裸奔，不建议。

reject：显式拒绝，配合顺序控制做兜底。

选型上有个坑得提前说：scram-sha-256对客户端版本有要求。老版本的驱动、老版本的libpq、某些嵌入式设备的数据库客户端可能只支持md5，连上来会握手失败。这时候你有两个选择——升级客户端，或者给特定的老客户端单独开一条md5规则。

后者可以用来源地址精确限制：

# 只对某台老设备放行 md5，其余全部强制 scram host app app 10.0.3.66/32 md5 host all all 10.0.3.0/24 scram-sha-256

但用md5之前必须确认一件事：数据库里存的密码哈希是什么算法。password_encryption参数决定新建或修改密码时用哪种算法加密，它和pg_hba.conf里写的认证方式是两回事。如果password_encryption = scram-sha-256，而库里用户的密码也是按 SCRAM 存的，你把它改成md5规则也没用——服务端没法用 MD5 去验证 SCRAM 哈希。

查一下当前状态：

SHOW password_encryption; SELECT rolname, substr(rolpassword, 1, 14) AS prefix FROM pg_authid WHERE rolcanlogin;

前缀是SCRAM-SHA-256$说明是 SCRAM 存的，是md5开头说明是老格式。老格式的密码要转成 SCRAM，只能让用户重设一次密码（或者你用超级用户ALTER USER ... PASSWORD '...'重设），哈希是单向的，没办法原地转换。

3.4 一份可以直接抄的配置片段

假设场景是这样：数据库服务器内网地址 10.0.3.15，应用服务器网段 10.0.3.0/24，运维跳板机 10.0.8.20，其他一律拒绝。

postgresql.conf里：

listen_addresses = '127.0.0.1,10.0.3.15' port = 5432 password_encryption = scram-sha-256

pg_hba.conf里：

# 类型 数据库 用户 来源地址 认证方式 local all all peer host all all 127.0.0.1/32 scram-sha-256 host all all ::1/128 scram-sha-256 # 应用服务器网段 host appdb app 10.0.3.0/24 scram-sha-256 # 跳板机，允许连所有库做运维 host all dba 10.0.8.20/32 scram-sha-256 # 兜底拒绝 host all all 0.0.0.0/0 reject host all all ::/0 reject

改完执行：

# 确认改的是对的文件 sudo -u postgres psql -c "SHOW hba_file;" # 重载 sudo systemctl reload postgresql

这套配置的逻辑是：本地 socket 走 peer，本机 TCP 和远程都必须密码认证，来源按网段精确划分，最后两条把剩余空间全堵死。要说缺点，就是新增一个来源就得改一次文件，纯内网环境还能接受，规模大了就该考虑换成统一的认证服务（LDAP 或证书），把来源管理从文件里挪出去。

注意：reject那两行必须放在最后。放前面的话，所有连接都会被立刻拒绝，包括你自己的。

4. 网络层：防火墙、安全组、容器，一个都不能漏

4.1 主机防火墙放行

配置改对了，端口也监听了，ss -lntp | grep 5432能看到0.0.0.0:5432或具体地址，但客户端还是超时——那基本就是防火墙的问题。

看当前状态：

# firewalld（RHEL/CentOS 系） sudo firewall-cmd --list-all sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.3.0/24" port port="5432" protocol="tcp" accept' sudo firewall-cmd --reload # ufw（Ubuntu 系） sudo ufw status sudo ufw allow from 10.0.3.0/24 to any port 5432 proto tcp # 直接操作 iptables sudo iptables -A INPUT -p tcp -s 10.0.3.0/24 --dport 5432 -j ACCEPT

我建议一律用带来源限制的规则，不要图快写--add-port=5432/tcp。后者会把端口对所有来源开放，等于你在pg_hba.conf里做的来源限制只剩下认证这一道防线，防火墙这一层白设了。两层防护的意义就在于，任何一层配错，另一层还能兜住。

ufw有个小坑：allow 5432会同时开 IPv4 和 IPv6，如果你只想要 IPv4，得写proto tcp from 10.0.3.0/24并显式指定family。iptables 那边则要注意规则顺序，-A是追加到末尾，如果前面已经有一条DROP，你追加的ACCEPT永远不会命中，得用-I插到前面去。

4.2 云主机安全组与端口映射别忘了

云上的虚拟机，主机防火墙之外还有一层安全组（有的叫网络 ACL）。这层的规则在控制台上配，firewall-cmd看不到，也很容易被忽略——尤其是换了个云厂商，习惯了两层防护的人容易只改系统防火墙，然后对着"配置全对但就是连不上"发呆。

排查方法很简单：先在服务器本机curl或者nc测自己的 5432，通了说明服务端一切正常；再从同网段的另一台机器测，通了说明安全组和防火墙都放行了；再从外部测，这时候还不行，问题就锁定在外层网络策略或者 NAT 上。

还有个特殊情况：如果数据库是通过端口映射对外提供的，比如把 15432 映射到内网的 5432，那客户端的连接地址端口要写映射后的，而pg_hba.conf里看到的来源地址会是映射设备的地址，不是你客户端自己的地址。这时候按客户端网段写的规则全部匹配不上，得按映射设备的地址来写，或者在映射设备上做透明代理。这个坑在网络架构稍微复杂一点的环境里很常见。

4.3 容器里跑 PostgreSQL 的两个差异

官方镜像和裸机安装有两处关键差异，不了解的话很容易卡住。

第一，官方镜像默认把listen_addresses设成了'*'，因为这个镜像本身要能在容器的随机 IP 上被访问。所以你不用改这个参数，改了反而可能出问题。

第二，镜像的启动脚本会根据环境变量生成pg_hba.conf。你手工改容器里的文件，容器重启后会被覆盖回去。正确的做法是把完整的pg_hba.conf用卷挂载进去，或者在启动命令里指定认证方式。

# 挂载自己的配置，注意路径和权限 docker run -d --name pg \ -p 127.0.0.1:5432:5432 \ -e POSTGRES_PASSWORD=*** \ -v /opt/pgconf/pg_hba.conf:/var/lib/postgresql/data/pg_hba.conf:ro \ postgres:16

端口映射那一行值得单独说：-p 5432:5432会把端口绑到宿主机的所有网卡上，和直接用*监听的效果一样。写成-p 127.0.0.1:5432:5432就只绑回环，外部连不上，安全性高得多。需要对外提供的场景，建议前面放个反向代理或者只映射到内网地址。

另外，POSTGRES_HOST_AUTH_METHOD=trust这个环境变量用起来很爽，但它会对所有连接生效，包括来自容器网络的任意地址。非一次性测试环境别用，改用挂载pg_hba.conf的方式精细控制。

5. 验证方式与报错速查

5.1 分层次验证，每一步都要有明确的判断标准

配置改完别急着让应用去试，按层次自己先验一遍，出问题能立刻定位。

第一层，监听状态：

ss -lntp | grep 5432 # 期望看到类似：LISTEN 0 244 10.0.3.15:5432 0.0.0.0:* # 如果只有 127.0.0.1:5432，说明 listen_addresses 没生效或改错了文件

第二层，进程参数：

SELECT name, setting, source, sourcefile FROM pg_settings WHERE name IN ('listen_addresses','port','hba_file');

sourcefile这一列特别有用，直接告诉你这个值是从哪个文件读来的，能立刻发现改错文件的情况。

第三层，端口连通性：

# 从客户端机器测，注意要测真实的服务地址 nc -vz 10.0.3.15 5432 # 或者 timeout 3 bash -c "</dev/tcp/10.0.3.15/5432" && echo ok

第四层，数据库连接：

psql -h 10.0.3.15 -p 5432 -U app -d appdb -c "select inet_server_addr(), current_user, version();"

这条命令返回的inet_server_addr()能确认你连的确实是目标服务器，而不是某台同名机器。

第五层，看日志：

sudo tail -f /var/log/postgresql/postgresql-16-main.log # 或 sudo journalctl -u postgresql -f

验证时一边操作一边开着日志，比事后猜要快十倍。

5.2 爆款报错速查表

这张表里最容易被误判的是第二行和第三行。timed out和refused混着看的人不少，白白在pg_hba.conf里翻半天。记住一句话就够：refused 是服务端的问题，timeout 是网络的问题。

5.3 我踩过的几个坑

第一个坑：改完pg_hba.conf忘了 reload，坚信配置已经生效。后来又改了三遍还是不行，最后发现日志里早就警告过pg_hba.conf was not reloaded——文件里有一行我把 IP 写成了192.168.1.0/33，掩码越界，解析失败。PostgreSQL 的容错策略是"保留旧配置继续跑"，服务不会挂，但你的新规则一条都没上。

第二个坑：0.0.0.0/0以为包含了 IPv6。客户端的 DNS 解析优先返回 AAAA 记录，于是它走了 IPv6 来连，0.0.0.0/0完全匹配不到，报no pg_hba.conf entry。补一行::/0就好了，或者干脆让客户端强制走 IPv4。

第三个坑：规则写对了，但位置放错了。手册里的示例是编辑文件中间的部分，我直接加在了末尾，而末尾前面有一条host all all 10.0.0.0/8 reject。规则从上往下匹配，我的新规则永远轮不到。后来养成习惯：所有新规则都插在兜底reject的上面，并且在文件里用注释标清楚分区。

第四个坑：容器重启后配置被覆盖。在容器里exec进去改了pg_hba.conf，当场生效，第二天容器重启，一切回到原点。容器无状态，任何手工改动都不是配置。要么做成镜像的一部分，要么用卷挂载，要么用初始化脚本，总之别指望docker exec改的东西能活过重启。

第五个坑：用trust图省事，测试环境搬到了预发。这套环境后来被接进了更大的网络，扫描器一跑就发现了无密码的数据库端口。教训是：trust只能活在一次性环境里，任何有名字的环境都不该出现它。现在我的习惯是，只要写trust就一定配一条注释说明为什么，一个月后回来看，这条注释往往会让我把它删掉。

6. 放开之后要补的安全功课

6.1 最小放行原则怎么落地

把数据库开放给其他 IP，本质是扩大了攻击面。"最小放行"这个词听烂了，落到具体操作上是三件事。

第一，来源精确到网段甚至单机。能写/27就别写/24，能写/32就别写网段。应用服务器只有三台，就写三个/32，虽然配置文件长一点，但任何一台不在名单里的机器都连不进来。

第二，权限也要最小。应用账号只给业务库的CONNECT和必要的表权限，不要图省事用超级用户。即使凭据泄漏，能造成的破坏也被限制在那个库的范围里：

CREATE ROLE app LOGIN PASSWORD '***'; GRANT CONNECT ON DATABASE appdb TO app; GRANT USAGE ON SCHEMA public TO app; GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app;

第三，认证方式别降级。用scram-sha-256，别用trust，password明文方式除非整条链路有别的加密保护，否则不要用。

6.2 密码策略与传输加密

认证方式解决了"谁连"的问题，密码强度解决了"凭据好不好猜"的问题。数据库端口一旦对外开放，撞库和暴力破解就会找上来，这不是危言耸听，对着5432端口扫描的流量在任何对外开放的地址上都是常态。

pg_hba.conf里可以配置失败重试限制：

# 同一来源连续失败后延迟响应，降低暴力破解速度 host all all 0.0.0.0/0 scram-sha-256

配合postgresql.conf里的authentication_timeout（默认 60 秒）和日志审计，把失败的登录尝试记录下来。真正的密码强度控制建议放在账号创建流程里用脚本校验，别指望数据库自己做。

传输加密这块，ssl = on打开配置证书，客户端连的时候带sslmode=require（或更严格的verify-full）。pg_hba.conf里用hostssl替代host，可以强制所有远程连接必须走加密，非加密的直接拒绝。这个改动对已有应用是破坏性的，所以要在业务低峰期做，改之前确认客户端驱动都支持 SSL。

6.3 日志与审计，出事了能查

开放访问之后，日志的价值会被放大。至少要保证这几点：

# postgresql.conf log_connections = on log_disconnections = on log_line_prefix = '%m [%p] %q%u@%d %h ' log_min_duration_statement = 1000

%h是客户端地址，%u@%d是用户和库名。这三样组合起来，任何一次连接尝试都能追溯到来源。log_min_duration_statement记录慢查询，配合连接日志能还原出问题时间点前后的完整现场。

日志轮转和保留周期要提前规划。有些发行版默认只保留一周，出了安全事故想回溯一个月前的访问记录就抓瞎了。日志文件也可能包含敏感信息（比如某些场景下的错误语句内容），权限和归档策略要一起考虑。

最后说个实操建议：所有涉及远程访问的改动，先在测试环境完整走一遍"改配置、重启、验证、回滚"的流程。回滚方案提前准备好——备份原文件、知道怎么快速还原、确认重启窗口。我见过不止一次改完连不上、又没有备份、最后从别的机器拷贝一份默认配置硬顶的情况，那种时候人是慌的，很容易按错键。提前十分钟备份，能省掉后面两小时的抢救。