亚马逊云风控解除 AWS RDS 数据库无法连接？Security Group、Subnet Group 与公网属性排查
AWS RDS 数据库无法连接，先按这条顺序排查
遇到 AWS RDS 数据库无法连接，最怕的是一上来就反复改端口、重建实例，最后发现问题根本不在数据库本身。实际排查里，最常见的顺序应该是：先确认账号和资源状态，再看 Security Group，再看 Subnet Group，最后检查公网属性和本地网络出口。这样能少走很多弯路。
如果你是新开账号、刚完成企业认证、正在走支付审核，或者账号有欠费、风控限制、资源配额不足，先别只盯着数据库连通性。很多时候不是连不上，而是实例修改、网络放行或公网开启根本没有真正生效。
先确认是不是账号、账单或资源限制卡住了
这一步经常被忽略，但在实际项目里很关键。尤其是企业新账号、刚充值续费、付款方式还在审核、或者有安全风控时，控制台看起来“能操作”，实际会出现创建受限、修改延迟、资源开不出来的情况。
- 确认账号是否有欠费、账单是否正常、充值是否到账。
- 确认企业认证、实名信息、付款方式审核是否已经完成。
- 亚马逊云风控解除 确认当前区域是否还有可用配额，尤其是实例数、存储、IP 等限制。
- 确认你操作的是正确的 Region，很多人实际连的是另一个区域的 endpoint。
如果你是在企业采购流程里做环境交付，建议先把账单状态和资源权限确认清楚，再开始排查网络。否则会把“审核未通过”误判成“安全组没放行”。
Security Group 排查：最常见，也最容易改错
RDS 连不上，Security Group 先看入站规则。很多问题不是数据库坏了，而是源地址、端口或放行方式不对。
1. 入站端口是否放对
先确认你连的数据库端口是不是实例实际使用的端口。常见错误是：
- MySQL 按 3306 配了，却实际连的是别的端口。
- PostgreSQL 端口写错，或者工具里默认端口没改。
- 修改过端口后，本地客户端还在用旧端口。
2. 源 IP 是否真的等于你的出口 IP
很多人给自己的办公网开了白名单，结果办公室、家里、VPN、手机热点的出口 IP 根本不是同一个。尤其是经过 NAT、代理、跳板机时，RDS 看到的往往不是你电脑的内网地址，而是出口公网地址。
- 亚马逊云风控解除 如果你是本地电脑直连，放行当前公网出口 IP。
- 亚马逊云风控解除 如果你是从 ECS 或服务器访问，最好放行对应的安全组来源，而不是写死单个公网 IP。
- 如果你从 VPN 进来，记得查 VPN 出口地址，不要用本机地址。
3. 规则改了但还是不通，先看是否选对了安全组
实际项目里很常见：实例绑定的是 A 安全组，你改的是 B 安全组。看起来规则已经放开，实际上数据库根本没用上那条规则。修改前先确认 RDS 实例当前关联的安全组，再做调整。
Subnet Group 排查：很多“开了公网”其实卡在这里
Subnet Group 不是只影响“放在哪个子网”，它还决定了实例最终能不能走出你预期的网络路径。很多人只改公网属性，不检查子网组，结果还是连不上。
1. 子网组里是不是放进了合适的子网
如果子网组只包含私有子网，或者选中的子网没有通往互联网网关的路径，即使你把公网属性打开，也未必能从外网直接访问。
2. 路由表有没有把流量送到正确出口
数据库要从公网可达，相关子网的路由和网络出口必须配合好。只在控制台里打开一个“公网访问”开关，不代表路由自动补齐。排查时要一起看路由表、NACL 和子网所属的 AZ。
3. 子网可用 IP 是否足够
在资源紧张的场景里，子网可用 IP 不足也会引发创建、切换或维护异常。很多人看到的是“连接失败”，实际前面已经出现了资源分配问题，只是没有注意到告警。
公网属性怎么判断要不要开
RDS 的公网属性决定你能不能从外网直接连进来，但它不是解决问题的唯一按钮。是否开启公网，取决于你当前是测试、迁移还是生产环境。
| 处理项 | 适用场景 | 直接效果 | 常见风险 |
|---|---|---|---|
| 改 Security Group | 端口被拦、来源 IP 没放行、服务器间互访 | 放开访问来源 | 容易写错源 IP，或者放得过宽 |
| 改 Subnet Group | 实例落在不合适的子网，公网路径不通 | 调整网络落点 | 涉及切换和维护，改完未必立刻可连 |
| 开公网属性 | 临时外网连库、迁移验证、短期排障 | 提供外网入口 | 暴露面变大，生产库要谨慎 |
如果是生产库，通常不建议长期开公网。更稳妥的做法是通过跳板机、VPN 或内网服务器访问。临时排障可以开，但排完最好立刻收回。
常见错误：看起来都开了，实际还是不通
- 只改了安全组，却没改正确的入站源 IP。
- 开了公网属性，但实例还在错误的子网组里。
- 改完配置后还在用旧 endpoint，或者本地 DNS 缓存没刷新。
- 本地网络经过公司代理、VPN 或 NAT，出口 IP 和预期不一致。
- 数据库端口写错，工具默认端口没有改。
- 实例状态还没完全可用，就提前测试连接。
- 把测试环境和生产环境的安全组混在一起改，最后自己也分不清哪条规则生效。
按场景给出处理建议
场景一：本地电脑直连失败
先确认当前公网出口 IP，再看 Security Group 是否放行该 IP 对应的数据库端口。如果你经常切换网络，最好不要长期固定一个不变的白名单，而是用跳板机或 VPN 统一出口。
场景二：同 VPC 里的 ECS 能连，外网不能连
这通常说明数据库本身没问题，问题大概率在公网属性、路由或外部安全组放行上。此时先别改库参数，优先检查外网入口是否真的已经打开。
亚马逊云风控解除 场景三：修改后偶尔能连，过一会儿又不行
这类问题经常出现在动态公网 IP、临时 VPN、公司出口变更、或者多条安全组规则互相覆盖的情况下。建议固定一个访问入口，减少“今天能连、明天不能连”的波动。
场景四：新账号刚开通就连不上
除了网络配置，还要看账号是否完成实名认证、企业认证、支付审核，账单是否正常，以及目标区域是否有资源限制。新账号在资源申请、修改和扩容阶段，更容易碰到额外审核或限制。
怎么做决策：改规则、改子网，还是直接开公网
如果你只是想快速恢复连接，建议按下面的优先级处理：
- 先确认账号、账单、权限、区域和实例状态。
- 再修 Security Group，优先只放行必要源地址和必要端口。
- 如果外网仍然不通，再看 Subnet Group 和路由路径。
- 只有在确实需要外网直连时，才考虑打开公网属性。
对于成本控制来说，临时开公网只是应急手段，不适合长期保留。长期看，使用内网访问、跳板机或 VPN，一般更利于控制安全整改成本和后续维护成本。
FAQ
Q1：Security Group 已经放行了，为什么还是连不上？
A：最常见的是源 IP 写错、端口写错、改的是错误的安全组，或者实例其实还没真正走到公网可达路径。建议按“账号状态 - 安全组 - 子网组 - 公网属性”顺序再核一次。
Q2：Subnet Group 需要改吗，还是只改安全组就够？
A：如果你只是让同一 VPC 里的服务器访问，很多时候只改安全组就够了。但如果你要从外网直连，或者实例原本就落在不合适的子网里，单改安全组往往不够。
Q3：开了公网属性，多久能生效？
A：以控制台状态为准。修改后先确认实例状态已稳定，再重新获取 endpoint 测试。不要拿旧连接、旧 DNS 或缓存结果当成最终结论。
Q4：生产库要不要直接开放 0.0.0.0/0？
A：不建议。排障时临时放开可以理解，但生产环境长期暴露公网，后面通常会带来更高的安全和整改成本。
如果你现在遇到的不是“数据库坏了”，而是“网络路径、账号状态和访问方式没对上”，按这篇的顺序排查，通常能很快把问题缩小到一个明确环节。
