没有公网 IP 也能远程连 PostgreSQL——从本地数据库到固定 TCP 地址的配置、安全与排错全流程-171主机测评

PostgreSQL	数据库	内网穿透	TCP	远程访问
Rocky Linux	Linux运维	网络安全	cpolar	数据库运维

没有公网 IP、路由器无法端口映射，也能让 PostgreSQL 稳定被异地访问。本文以 Rocky Linux 9、PostgreSQL 18 与 cpolar TCP 隧道为例，从安装、最小权限账号、SCRAM-SHA-256、本机验证，到随机 TCP、固定公网 TCP、psql 与 DBeaver 异地连接，完整跑通可复现链路。同时补充 TLS、无需对公网开放 5432 的安全基线、常见报错与五层排障命令，帮助你把“临时能连”升级为边界清楚、可诊断、可长期维护的远程数据库方案。

先看结论：最安全的主线，不是把 5432 直接扔到公网

一句话方案如果 cpolar 与 PostgreSQL 安装在同一台机器上，PostgreSQL 完全可以继续只监听 localhost。公网访问由 TCP 隧道接入，再转发到 127.0.0.1:5432。这样既不需要公网 IP，也不需要路由器端口映射，更不需要把系统防火墙的 5432 暴露给整个互联网。

很多教程一提“远程连接 PostgreSQL”，第一反应就是把 listen_addresses 改成 *，再在 pg_hba.conf 里放开 0.0.0.0/0。这个做法确实容易“立刻连通”，但它把数据库直接变成互联网扫描目标，尤其当账号还是 postgres 超级用户时，风险会被成倍放大。

本文采用的是另一条更稳的路线：先把数据库本机闭环跑通，再建立 TCP 隧道，最后把随机公网入口升级为固定 TCP 地址。每一步都有明确的验证点；一旦失败，只需要定位到第一处断点，而不是盲目改配置。

图 1 推荐链路：公网只暴露隧道入口，数据库仍保持本机监听

你最终会得到什么

一个可长期运行的 PostgreSQL 18 本地数据库，使用独立远程账号而不是超级用户。
一条不依赖公网 IP、不依赖路由器端口映射的 TCP 访问链路。
一个可供 psql、DBeaver、DataGrip 或应用程序使用的固定“域名 + 端口”。
一套从数据库服务、监听、认证、隧道到客户端的分层排错方法。
一组适合长期使用的安全基线：SCRAM、TLS、最小权限、连接限制与可选 IP 白名单。

快速路线图

阶段	做什么	成功标志
① 本机数据库	安装 PostgreSQL、创建数据库与独立账号	127.0.0.1:5432 可正常登录
② 安全认证	SCRAM-SHA-256 + 精确 HBA 规则	错误账号/数据库会被拒绝
③ 随机 TCP	cpolar 映射 127.0.0.1:5432	获得临时公网域名与端口
④ 异地验证	从另一网络用 psql / DBeaver 登录	可查询并写入测试表
⑤ 固定 TCP	保留并绑定固定公网 TCP 地址	公网地址不再随重连变化
⑥ 安全加固	PostgreSQL TLS、IP 白名单、日志审计	公网链路具备明确安全边界

1. 环境与版本：先把“时效边界”说清楚

本文主线环境选择 Rocky Linux 9.x + PostgreSQL 18。之所以不再把 CentOS 7 作为默认示例，是因为 CentOS Linux 7 已于 2024 年 6 月 30 日结束生命周期，不再获得官方更新；继续用旧系统做新部署，会让后续安全维护和软件仓库管理变得更麻烦。

截至 2026 年 9 月，PostgreSQL 当前稳定文档系列为 18；官方在 2026 年 8 月 13 日发布了 18.6。本文使用“postgresql18”这一主版本包名，未来 18.x 的小版本安全更新可以继续通过包管理器获得。

项目	本文示例	说明
操作系统	Rocky Linux 9.x（x86_64）	AlmaLinux / RHEL 9 同族系统可参考
数据库	PostgreSQL 18.x	示例按官方 PGDG RPM 仓库组织
默认端口	5432	正文保持本机监听，不对公网直接开放
认证	SCRAM-SHA-256	PostgreSQL 18 默认 password_encryption 即为该方式
穿透工具	cpolar Linux 客户端	使用 TCP 隧道；固定 TCP 需满足对应套餐条件
远程客户端	psql / DBeaver	任何支持 PostgreSQL 协议的客户端均可

已有数据库？如果你已经在 CentOS 7、Ubuntu 或其他系统上装好了 PostgreSQL，不必重装。直接从“第 4 节：创建远程专用账号”继续，核心思路完全一致。

2. 安装 PostgreSQL 18：用官方仓库保持后续可更新

下面以 Rocky Linux 9 x86_64 为例。生产环境建议先做系统更新窗口评估；个人开发机可以直接更新软件索引。

安装 PostgreSQL 18

sudo dnf update -y # 安装 PostgreSQL 官方 Yum 仓库 sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm # 避免系统自带模块与 PGDG 主版本冲突 sudo dnf -qy module disable postgresql # 安装 PostgreSQL 18 服务端与客户端 sudo dnf install -y postgresql18-server postgresql18

安装完成后初始化数据库集群，并设置开机自启：

sudo /usr/pgsql-18/bin/postgresql-18-setup initdb sudo systemctl enable –now postgresql-18 sudo systemctl status postgresql-18

看到 active (running) 后，先不要碰远程访问。先确认数据库版本、监听端口和配置文件位置：

sudo -iu postgres psql -Atqc "SELECT version();" sudo -iu postgres psql -Atqc "SHOW config_file;" sudo -iu postgres psql -Atqc "SHOW hba_file;" sudo -iu postgres psql -Atqc "SHOW listen_addresses;" sudo -iu postgres psql -Atqc "SHOW port;" sudo ss -lntp | grep 5432

不要急着改为 * 默认 listen_addresses 为 localhost，这正是本文希望保留的状态。只要穿透客户端和 PostgreSQL 在同一台机器上，就没有必要为了“公网访问”把数据库改成监听所有网卡。

3. 创建远程专用账号：不要拿 postgres 超级用户长期公网登录

远程访问最容易被忽略的风险，不是“端口长什么样”，而是“暴露出去的账号拥有什么权限”。postgres 是数据库集群超级用户，日常远程开发没有必要使用它。

进入 psql，创建一个只负责业务库登录的账号。密码建议用 \\password 交互式设置，避免明文出现在 Shell 历史记录里。

sudo -iu postgres psql CREATE ROLE remote_app WITH LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE NOREPLICATION CONNECTION LIMIT 10; \\password remote_app CREATE DATABASE appdb OWNER remote_app; \\q

再确认 PostgreSQL 当前密码加密方式：

sudo -iu postgres psql -Atqc "SHOW password_encryption;"

在 PostgreSQL 18 中，默认值应为 scram-sha-256。SCRAM-SHA-256 比旧的 MD5 认证更安全；PostgreSQL 官方文档也已明确说明 MD5 密码支持处于弃用路径。

升级环境常见坑如果是从旧版本升级过来的数据库，即使 SHOW password_encryption 已经是 scram-sha-256，旧账号的密码仍可能保留为 MD5 哈希。最稳妥的处理方式是确认客户端支持 SCRAM 后，为远程账号重新设置一次密码。

4. 配置 pg_hba.conf：只允许“这个库 + 这个账号 + 本机回环地址”

pg_hba.conf 是 PostgreSQL 的客户端认证规则文件。规则按顺序匹配，所以越精确、越靠前的规则越容易审计。本文不使用 all / all / 0.0.0.0/0 这种“一把梭”的配置。

先获取实际 HBA 文件路径：

sudo -iu postgres psql -Atqc "SHOW hba_file;"

编辑返回的 pg_hba.conf，在现有 host 规则前加入：

# 只允许 remote_app 访问 appdb，并且来源必须是本机回环地址 host appdb remote_app 127.0.0.1/32 scram-sha-256 host appdb remote_app ::1/128 scram-sha-256

保存后重新加载认证配置即可，不需要完整重启：

sudo systemctl reload postgresql-18 # 检查 HBA 是否存在语法错误 sudo -iu postgres psql -c "SELECT line_number, type, database, user_name, address, auth_method, error FROM pg_hba_file_rules WHERE error IS NOT NULL;"

可验证配置如果查询结果为 0 行，说明 PostgreSQL 没发现 HBA 语法错误。这个检查非常值得保留在每次修改后的验证步骤里。

5. 第一处关键断点：本机 TCP 登录必须先成功

先在服务器本机走 TCP，而不是 Unix Socket。这样测试到的正是后面 cpolar 会访问的那条路径。

psql -h 127.0.0.1 -p 5432 -U remote_app -d appdb

输入 remote_app 的密码后，执行一组最小读写验证：

SELECT current_user, current_database(), inet_server_addr(), inet_server_port(); CREATE TABLE connection_test ( id bigserial PRIMARY KEY, source text NOT NULL, created_at timestamptz NOT NULL DEFAULT now() ); INSERT INTO connection_test(source) VALUES ('local-loopback'); SELECT * FROM connection_test ORDER BY id DESC LIMIT 5;

排错顺序很重要到这里如果都失败，先不要安装或排查内网穿透。隧道只是“转发连接”，它不会修复数据库服务、账号、密码或 HBA 本身的问题。

6. 可选：如果你一定要先测局域网，怎样临时放开而不暴露公网

这一节不是后续 cpolar 的必要条件。只有你想让同一局域网里的另一台电脑直接连接 PostgreSQL 时才需要。测试完成后，可以恢复为 localhost。

假设数据库服务器局域网地址是 192.168.42.140，局域网为 192.168.42.0/24。把 postgresql.conf 的监听地址改为：

listen_addresses = 'localhost,192.168.42.140' port = 5432

再在 pg_hba.conf 增加精确网段：

host appdb remote_app 192.168.42.0/24 scram-sha-256

如果 firewalld 已启用，仅允许该网段访问 5432：

sudo firewall-cmd –permanent –add-rich-rule='rule family="ipv4" source address="192.168.42.0/24" port port="5432" protocol="tcp" accept' sudo firewall-cmd –reload sudo systemctl restart postgresql-18

局域网客户端测试：

psql -h 192.168.42.140 -p 5432 -U remote_app -d appdb

测试后收口后面改用同机 cpolar 隧道后，建议把 listen_addresses 恢复为 localhost，并删除这条局域网防火墙规则。这样数据库再次回到“只有本机代理能碰到”的状态。

7. 安装 cpolar：把本机 5432 转成公网 TCP 入口

cpolar 的 Linux 官方文档提供一键安装脚本，并使用 systemd 管理服务。下面的命令按当前文档整理：

curl -L https://www.cpolar.com/static/downloads/install-release-cpolar.sh | sudo bash cpolar version # 将这里替换为你账户后台的认证 Token cpolar authtoken YOUR_AUTHTOKEN sudo systemctl enable cpolar sudo systemctl start cpolar sudo systemctl status cpolar

cpolar Web UI 默认可通过本机 9200 端口访问。服务器有桌面时直接打开：

http://127.0.0.1:9200/

如果是无桌面的 Linux 服务器，优先从同一局域网访问服务器的 9200，或使用现有 SSH 做本地端口转发；不要为了方便把管理面板再随意公开到互联网。

8. 创建随机 TCP 隧道：先验证链路，再谈固定地址

在 cpolar Web UI 中进入“隧道管理 → 创建隧道”，建议使用下面的参数：

参数	推荐值	为什么
隧道名称	postgresql	便于识别，避免与其他隧道混淆
协议	TCP	PostgreSQL 是原生 TCP 协议，不是 HTTP
本地地址	127.0.0.1:5432	明确把流量送到本机回环地址
地址类型	随机 TCP	先验证，不急着购买/绑定固定入口
地区	选择离主要客户端较近的节点	降低额外网络延迟

创建成功后，在“状态 → 在线隧道列表”中会看到类似下面的公网地址：

tcp://6.tcp.cpolar.top:10577

真正给 PostgreSQL 客户端填写时，不要带 tcp://。拆成两个字段：

客户端字段	填写示例
Host	6.tcp.cpolar.top
Port	10577
Database	appdb
User	remote_app

9. 第二处关键断点：换到“另一张网”做真实异地测试

不要在同一台服务器上拿公网地址自测后就宣布成功。真正的验证应该来自另一台设备、另一张网络，例如手机热点、公司网络或家外网络。

先用 nc 检查公网 TCP 端口是否可达：

nc -vz 6.tcp.cpolar.top 10577

端口可达后再用 psql：

psql -h 6.tcp.cpolar.top -p 10577 -U remote_app -d appdb

登录后写入一条“remote”记录：

INSERT INTO connection_test(source) VALUES ('remote-tunnel'); SELECT * FROM connection_test ORDER BY id DESC LIMIT 5;

如果能看到 local-loopback 和 remote-tunnel 两条记录，说明从数据库到公网隧道再到远程客户端的整条链路已经闭环。

10. DBeaver 连接参数：把“域名”和“公网端口”拆开填

DBeaver 项	填写内容
Host	固定或随机 TCP 地址中的域名部分
Port	公网 TCP 地址中的端口部分，不是 5432
Database	appdb
Username	remote_app
Password	remote_app 的数据库密码
SSL	未启用 PostgreSQL TLS 时先关闭；启用后按第 12 节配置

DBeaver 常见坑最常见的低级错误是：Host 填完整的“域名:端口”，同时 Port 又填一次；或者仍把 Port 写成 5432。公网入口端口由隧道分配，它通常与本机 5432 不同。

11. 从随机地址升级为固定 TCP：让连接串真正可长期使用

随机 TCP 适合功能验证，但地址可能变化。需要长期使用时，应保留固定公网 TCP 地址，并把它绑定到已经验证通过的 postgresql 隧道。

前置条件 cpolar 当前官方文档说明：保留固定 TCP 端口地址需要满足相应付费套餐条件。先确认账户套餐，再做下面的配置。

选择合适地区并填写描述，例如 postgresql-prod-dev。

保存后复制系统生成的固定“域名:端口”。

回到本机 9200 Web UI，打开“隧道管理 → 隧道列表 → postgresql → 编辑”。

将端口类型改为“固定 TCP 端口”，填入刚刚保留的公网 TCP 地址，然后更新。

进入“状态 → 在线隧道列表”，确认 postgresql 隧道已经显示新的固定地址。

如果更习惯配置文件，也可以在 /usr/local/etc/cpolar/cpolar.yml 中给隧道加入 remote_addr：

authtoken: YOUR_AUTHTOKEN tunnels: postgresql: proto: tcp addr: 127.0.0.1:5432 remote_addr: 1.tcp.vip.cpolar.cn:23539 region: cn_vip

保存后重启服务：

sudo systemctl restart cpolar sudo systemctl status cpolar

再从异地网络用固定地址执行一次 psql 登录和 INSERT 测试。只有这一步也成功，固定地址才算真正完成。

12. 公网长期使用建议再加一层：启用 PostgreSQL 原生 TLS

SCRAM-SHA-256 能保护密码认证过程，但它并不等价于“所有 SQL 与查询结果都被端到端加密”。当数据库连接跨越公共网络时，长期使用建议开启 PostgreSQL 原生 TLS。

下面给出一个适合测试/个人环境的最小自签名方案。正式生产环境应改用组织内部 CA 或受信任证书体系。

cd /var/lib/pgsql/18/data sudo -u postgres openssl req -new -x509 -days 825 -nodes -out server.crt -keyout server.key -subj "/CN=postgres-tunnel" sudo chown postgres:postgres server.crt server.key sudo chmod 600 server.key

编辑 postgresql.conf：

ssl = on ssl_cert_file = 'server.crt' ssl_key_file = 'server.key'

把前面的 HBA 规则从 host 改为 hostssl，强制 remote_app 只能通过 TLS 登录：

hostssl appdb remote_app 127.0.0.1/32 scram-sha-256 hostssl appdb remote_app ::1/128 scram-sha-256

重启 PostgreSQL：

sudo systemctl restart postgresql-18

把 server.crt 通过安全方式复制到远程客户端，然后使用：

psql "host=1.tcp.vip.cpolar.cn port=23539 dbname=appdb user=remote_app sslmode=verify-ca sslrootcert=/path/to/server.crt"

TLS 边界说明 verify-ca 会验证服务器证书是否来自你信任的证书链，但不校验连接主机名。要做到 verify-full，服务器证书的 SAN/CN 必须与客户端连接的主机名匹配；当你使用的是第三方隧道域名时，通常需要自有域名/网关或 VPN 才更容易做到完整主机名验证。

13. 长期使用的安全基线：把“能连上”升级为“可控地连上”

控制点	推荐做法	不要这样做
监听范围	cpolar 同机时保留 localhost	为穿透直接改成 listen_addresses='*'
HBA	精确到数据库、账号、回环地址	all / all / 0.0.0.0/0
账号	独立 LOGIN、NOSUPERUSER、限制连接数	长期使用 postgres 超级用户
密码认证	SCRAM-SHA-256	继续新建 MD5 密码
传输加密	公网长期连接启用 PostgreSQL TLS	认为“有隧道”就自动等于端到端 TLS
防火墙	无需向公网开放 5432	开放 5432/tcp 给所有来源
来源限制	来源 IP 固定时可使用隧道 IP 白名单	把固定公网入口当作秘密地址
管理面	9200 仅本机/可信内网使用	再把 cpolar 管理面板公开到公网
审计	定期看 PostgreSQL / cpolar 日志	出问题只反复重启

如果你的远程出口 IP 是固定的，可以考虑在 cpolar 账户侧增加 IP 白名单。需要注意：当前官方文档说明该白名单是账户级全局规则，会作用于所有隧道端点；如果同一账户还跑着其他公网服务，先评估影响再启用。

14. 连不上怎么查：按 5 层排障，比“重装一遍”快得多

图 2 五层排障模型：永远先找第一处失败点

14.1 第一层：PostgreSQL 服务是否真的在运行

sudo systemctl status postgresql-18 sudo journalctl -u postgresql-18 -n 100 –no-pager

14.2 第二层：数据库监听与 HBA 是否正确

sudo ss -lntp | grep 5432 sudo -iu postgres psql -Atqc "SHOW listen_addresses;" sudo -iu postgres psql -Atqc "SHOW port;" sudo -iu postgres psql -Atqc "SHOW hba_file;" sudo -iu postgres psql -c "SELECT line_number, type, database, user_name, address, auth_method, error FROM pg_hba_file_rules ORDER BY line_number;"

14.3 第三层：本机 127.0.0.1 登录是否成功

psql -h 127.0.0.1 -p 5432 -U remote_app -d appdb

14.4 第四层：cpolar 服务和隧道是否在线

sudo systemctl status cpolar sudo journalctl -u cpolar -n 100 –no-pager

14.5 第五层：远程地址和客户端参数是否正确

nc -vz 1.tcp.vip.cpolar.cn 23539 psql -h 1.tcp.vip.cpolar.cn -p 23539 -U remote_app -d appdb

15. 高频报错对照表：看到报错先定位层级

现象 / 报错	最可能原因	优先检查
connection refused	PostgreSQL 未运行、未监听 5432，或隧道本地地址写错	systemctl、ss -lntp、127.0.0.1 本机测试
no pg_hba.conf entry	没有匹配到 HBA 规则，或 hostssl/host 条件不符	pg_hba_file_rules、规则顺序、地址与数据库名
password authentication failed	密码错误、旧账号仍是 MD5、客户端兼容问题	重设 remote_app 密码、确认 SCRAM
timeout / nc 超时	公网端口未在线、地址/端口抄错、网络侧阻断	cpolar 在线隧道列表、nc -vz
随机地址能用，固定地址不能用	预留地址没有正确绑定到当前隧道	remote_addr / 固定 TCP 端口配置
DBeaver 端口错误	仍填写本地 5432，或 Host 中重复带端口	Host/Port 分开填写
SSL is required	HBA 使用 hostssl，但客户端未启用 TLS	sslmode=require/verify-ca，检查证书
certificate verify failed	根证书路径不对、证书链不受信任	sslrootcert、server.crt、系统时间
9200 打不开	cpolar 服务没启动或管理端口被改	systemctl status cpolar、配置文件
连上但权限不足	remote_app 不是对象所有者或未获得业务权限	GRANT、对象 owner、schema 权限

16. 一键自检清单：上线前 2 分钟把关键状态扫一遍

echo "===== PostgreSQL =====" systemctl is-active postgresql-18 ss -lntp | grep 5432 || true sudo -iu postgres psql -Atqc "SHOW listen_addresses;" sudo -iu postgres psql -Atqc "SHOW port;" sudo -iu postgres psql -Atqc "SHOW password_encryption;" echo "===== HBA errors =====" sudo -iu postgres psql -Atqc "SELECT COALESCE(string_agg(error, E'\\n'), 'NO HBA ERROR') FROM pg_hba_file_rules WHERE error IS NOT NULL;" echo "===== cpolar =====" systemctl is-active cpolar systemctl –no-pager –full status cpolar | sed -n '1,18p'

这段脚本不会修改配置，只读取核心状态。把它保存成 pg_tunnel_check.sh，故障时先跑一次，通常比“猜是不是防火墙”有效得多。

17. 最终配置长什么样：把关键参数收束到一页

位置	关键值	目的
postgresql.conf	listen_addresses = 'localhost'	不接受外部网卡直接连接
postgresql.conf	port = 5432	保留 PostgreSQL 默认端口
postgresql.conf	ssl = on（长期公网建议）	让 PostgreSQL 协议本身加密
pg_hba.conf	appdb + remote_app + 127.0.0.1/32 + SCRAM	精确认证边界
cpolar	TCP → 127.0.0.1:5432	把公网连接送到本机数据库
cpolar 固定入口	域名:公网端口	客户端长期稳定连接地址
远程客户端	固定域名 + 固定端口 + appdb + remote_app	最终连接参数

最终原则如果你只记住一条：数据库端口不是越开放越“方便”。真正稳的做法，是让数据库只服务最小可信网络面，把公网入口、认证、加密和权限分别控制。

18. 常见问题

18.1 为什么不直接做路由器端口映射？

如果你有独立公网 IPv4、能控制路由器并且愿意维护防火墙与访问控制，端口映射当然可以使用。但在家庭宽带、校园网、公司 NAT、运营商 CGNAT 等环境里，公网入口往往不可控，TCP 隧道更容易跨过这些限制。

18.2 固定 TCP 地址是不是等于固定公网 IP？

不是。对客户端来说，你拿到的是一个长期稳定的“公网域名 + 公网端口”入口；真正的转发节点和底层 IP 由服务提供方维护。应用连接串通常只需要固定主机名和端口，不需要依赖某个固定公网 IPv4。

18.3 为什么本文不要求 firewalld 开 5432？

因为 PostgreSQL 只监听 127.0.0.1，cpolar 客户端又与数据库同机，二者通过本机回环网络通信。外部请求从隧道进来，而不是直接命中主机网卡上的 5432，所以无需给公网开放数据库端口。

18.4 能直接给业务程序用吗？

可以，但建议先把 TLS、最小权限账号、连接池、超时与重连策略补齐。短时开发联调与长期生产运行的可靠性要求不同；如果业务对 SLA、合规或带宽有明确要求，应评估专线、VPN、云数据库或受控网关。

18.5 数据库重启后固定地址会不会变？

固定 TCP 地址由隧道服务侧预留，只要该固定地址仍然有效并正确绑定到隧道，PostgreSQL 或本机重启不会主动改变这个公网入口。需要确保 postgresql-18 与 cpolar 都设置为开机自启。

19. 总结：从“能连上”到“可长期维护”，关键是闭环

没有公网 IP 时，远程访问 PostgreSQL 的难点其实不在 SQL，而在网络入口、认证、安全边界和排错顺序。把问题拆开后，链路并不复杂：PostgreSQL 先在本机跑通，remote_app 通过 SCRAM 登录；cpolar 只负责把固定公网 TCP 入口转发到 127.0.0.1:5432；异地客户端使用固定域名和端口完成连接。

更重要的是，这条路线不要求把 PostgreSQL 改成监听所有网卡，也不要求对互联网开放 5432。配合 TLS、最小权限、连接限制和按需 IP 白名单后，整个方案从“临时穿透”变成了一套边界清楚、能验证、能排错、能长期维护的远程数据库访问方法。

以后换成 MySQL、Redis、SSH 或其他 TCP 服务时，同样可以沿用这套思路：先本机闭环，再做隧道，再做固定入口，最后补齐协议自身的认证和加密。网络层负责“到得了”，应用层负责“认得出、看得懂、权限刚刚好”。

参考资料（官方）

PostgreSQL 18：Connections and Authentication
PostgreSQL 18：The pg_hba.conf File
PostgreSQL 18：Password Authentication
PostgreSQL 18：Secure TCP/IP Connections with SSL
PostgreSQL：Linux downloads（Red Hat / Rocky / AlmaLinux）
cpolar：官方在线文档
CentOS Project：CentOS Linux 生命周期说明