数据库连接失败，不一定是账号或密码错误。云端数据库与应用实例网络互通，首先取决于两端是否有可达的网络路径，其次才是端口和数据库配置。建议从应用实例所在环境逐层检查，避免只在个人电脑上测试后就判断数据库正常。
步骤一：确认连接地址解析正确
先核对应用使用的数据库域名、端口和目标实例，区分公网地址与私网地址。若数据库提供私网域名，应从应用实例查询解析结果，确认它指向预期的私网地址；本地电脑解析成功，不代表云内解析一致。
可在实例上使用 dig 或 nslookup 查询域名，并与云控制台显示的连接地址比对。若解析到旧地址，检查应用配置、DNS 缓存和私有 DNS 关联。排查期间也可用数据库私网 IP 做一次对照测试，但正式配置优先使用服务提供的域名，避免地址变更后连接失效。
步骤二：检查网络归属与路由
确认应用实例和数据库位于同一 VPC（虚拟私有云），还是分属不同网络。如果跨 VPC，需要配置网络对等连接、云企业网等可用连接方式，并检查两端路由表是否都包含对方网段。只建立连接而缺少回程路由，仍可能出现超时。
同时核对网段是否重叠。两个 VPC 使用相同或冲突的 CIDR 网段时，路由可能无法明确指向目标，通常需要调整网段设计或采用合适的网络转换方案。不要把公网出口能访问互联网，误认为应用实例已具备访问数据库私网地址的路径。
步骤三：逐项核对安全策略
在数据库侧的安全组或访问白名单中，允许应用实例的来源地址访问数据库端口；在应用侧检查出站规则及相关网络 ACL。规则应尽量限定到必要的源网段和端口，而不是临时开放所有来源。
常见默认端口包括 MySQL 的 3306、PostgreSQL 的 5432，但端口可能被修改，应以实例实际配置为准。安全组通常是有状态规则，网络 ACL 常按进出方向分别控制；若只放行入站而回程流量被拦截，连接仍无法完成。
步骤四：确认数据库确实在目标地址监听
网络路径允许，不代表数据库服务已经准备好。检查实例状态、监听地址、端口和连接白名单；如果服务只监听本机回环地址，远程应用无法连接。托管数据库则应确认实例可用状态、私网访问方式已启用，并且应用来源符合访问条件。
还要核对应用配置中的主机名、端口、数据库名称及凭据。连接超时更常见于路由或策略问题；收到“拒绝连接”则可能是端口未监听或目标地址错误；认证失败通常说明网络已到达数据库，应转查账号权限和密码。错误提示只能作为线索，不能替代逐层验证。
步骤五：从应用实例执行端到端验证
登录应用实例，确认它的私网地址、网卡和所在子网与预期一致。
先查询数据库域名解析，再检查实例路由表中是否存在到数据库网段的有效路由。
使用 nc 对数据库实际端口做连接探测，例如针对 MySQL 的 3306 或 PostgreSQL 的 5432；端口可达只说明网络层接通，不代表数据库认证成功。
通过数据库客户端使用应用配置进行连接，分别记录超时、拒绝连接或认证错误，按对应层级继续排查。
若端口探测失败，优先回看路由、安全组、访问白名单和网络 ACL；若探测成功但客户端失败，再检查账号权限、连接数限制、TLS 要求及驱动配置。每次只改一类设置并复测，便于定位真正原因。
常见问题
应用和数据库在不同 VPC，能直接用私网地址连接吗？
不能仅凭私网地址判断。两端必须通过对等连接或其他网络连接方式建立路径，并配置双向路由和访问规则。
本地电脑能连数据库，为什么应用实例不行？
本地电脑可能使用公网入口，而应用访问的是私网地址；两者的 DNS 解析、来源地址和安全策略都可能不同，应以实例内测试结果为准。
端口探测成功就表示数据库连接正常吗？
不表示。它只能证明指定地址和端口可建立网络连接，数据库账号、权限、协议及 TLS 配置仍需单独验证。
按地址解析、路由、安全策略、监听状态和实例侧验证依次排查，通常能把问题定位到具体一层。云端数据库与应用实例网络互通应以应用所在子网的实际路径和规则为准，而不是只看控制台中的连接状态。