psql 或应用提示 could not translate host name to address，表示客户端在把数据库主机名解析成 IP 时失败。此时连接通常还没有到达 PostgreSQL，因此修改密码、pg_hba.conf 或数据库用户不会解决问题。
正确顺序是先确认应用实际使用的主机名，再从同一运行环境测试解析，最后才检查端口和数据库就绪状态。容器、宿主机和开发电脑可能使用完全不同的 DNS 视图。
确认应用实际使用的连接参数
先检查连接串中的 host、端口和是否含有多余空格、引号或协议前缀。libpq 接受关键字格式和 URI，例如：
psql "host=db.internal port=5432 dbname=app user=appuser"
psql "postgresql://appuser@db.internal:5432/app"环境变量场景可查看是否存在覆盖：
env | grep -E '^PG(HOST|PORT|DATABASE|USER)='输出连接信息时应隐藏密码。不要把 https:// 写入 PostgreSQL 的主机名字段，也不要把整个带密码 URI 复制到工单或日志。
从同一运行环境测试DNS
在报错应用所在的主机或容器中执行：
getent ahosts db.internal
resolvectl query db.internalgetent 会遵循系统名称服务配置，比只使用某个独立 DNS 工具更接近多数应用的解析路径。检查 /etc/resolv.conf 和 /etc/nsswitch.conf，确认名称服务器、搜索域和 hosts 顺序符合预期。
容器环境必须进入同一容器验证：
docker exec app getent ahosts db
docker exec app cat /etc/resolv.conf宿主机能够解析，不代表容器、Kubernetes Pod 或 systemd 服务使用相同的 DNS 配置。
区分短主机名、完整域名和搜索域
db 这类短名称常依赖 DNS 搜索域；离开原网络、容器网络或 VPN 后可能无法解析。优先使用环境明确提供的服务名或完整域名，并确认记录类型、TTL 和作用范围。
Docker Compose 的服务名只在相应用户定义网络中有效，Kubernetes Service 名称也依赖集群 DNS。把内部服务名复制到宿主机或公网测试工具，解析失败是预期现象。
临时写入 /etc/hosts 可以帮助验证，但容易在 IP 变化后留下陈旧映射。除非地址由运维流程稳定管理，否则不要把手工 hosts 记录当作长期 DNS 修复。
谨慎使用hostaddr绕过解析
PostgreSQL 官方文档说明，hostaddr 可以直接提供数字 IP，避免主机名查找：
psql "host=db.example.com hostaddr=192.0.2.10 port=5432 dbname=app user=appuser"但 host 仍可能用于密码文件匹配、GSSAPI、SSPI 以及 sslmode=verify-full 的证书主机名验证。只填写 hostaddr 时，某些认证方式会失败；IP 变化时硬编码地址也会绕过服务发现和故障切换。
hostaddr 适合受控诊断或明确设计的固定地址，不应为了绕过 DNS 就长期替换主机名。 使用 TLS 时还必须确保验证策略没有被削弱。
解析成功后检查端口与数据库状态
DNS恢复后，再验证 PostgreSQL 是否接受连接：
pg_isready -h db.internal -p 5432 -t 5
nc -vz db.internal 5432官方文档说明，pg_isready 返回 0 表示正常接受连接，1 表示服务器拒绝连接，2 表示没有响应，3 表示参数无效或未发起尝试。解析失败、端口不通和认证失败属于不同阶段，应分别处理。
需要复现私有 DNS 与连接串时，可在 萤光云 创建隔离网络，或在 LightNode 的临时环境测试多地区解析。测试时只使用脱敏域名和最低权限账号。
修复后验证应用和故障切换
解析恢复后，从应用运行环境重新连接，检查连接池日志、TLS证书验证和数据库端连接记录。使用多个主机名时，libpq 会按列表依次尝试；单个名称解析到多个地址时，也会按地址顺序连接，直到成功或全部失败。
psql "host=db1.internal,db2.internal port=5432 dbname=app user=appuser" -c 'select 1;'不要只验证 ping。主机可能禁止 ICMP，但数据库端口正常；反过来，能 ping 通也不能证明 5432 端口、TLS 和认证可用。
验收标准是同一运行环境能稳定解析预期地址、pg_isready 状态正确、应用连接成功，并且证书验证与故障切换没有被临时 IP 配置破坏。
FAQ
修改pg_hba.conf能解决主机名解析失败吗？
不能。解析失败发生在客户端找到服务器之前；pg_hba.conf 只有连接到达 PostgreSQL 后才参与认证判断。
为什么用IP能连，用域名不能连？
这通常说明数据库与端口可达，而 DNS 记录、搜索域、容器解析或本地缓存存在问题。还要核对使用 IP 后是否绕过了 TLS 主机名验证。
host为空时会发生什么？
在 Unix 系统上，libpq 默认尝试本地 Unix-domain Socket；Windows 默认尝试 localhost。这与连接远程数据库是不同路径。
温馨提示
先修复名称解析的根因，再恢复使用稳定主机名。 不要通过关闭证书校验、长期硬编码漂移 IP 或共享带密码连接串来换取暂时可用；这些做法会把 DNS 故障变成安全和可维护性问题。
