根本原因是AWS安全组未放行入站流量,导致TCP握手卡在SYN阶段;须在安全组中精确配置源IP、端口及协议,同时确认RDS实例设为Publicly accessible、所在子网有IGW路由且终端节点解析为公网IP。
Navicat连接RDS提示“Connection timed out”根本原因
这不是navicat的问题,也不是密码或用户名输错了——而是流量在到达rds前就被拦下了。aws安全组默认拒绝所有入站流量,哪怕你本地ip、端口、主机名全对,只要安全组没放行,tcp握手就卡在syn阶段,最终超时。
必须配置的入站规则:源IP + 端口 + 协议三者缺一不可
进VPC控制台 → 找到RDS关联的安全组 → 编辑入站规则。常见错误是只填了端口,却忽略了源:
-
类型选对应数据库协议:MySQL/Aurora 用MySQL/Aurora(端口3306),PostgreSQL 用PostgreSQL(端口5432),SQL Server 用MS SQL(端口1433) -
源不能写0.0.0.0/0图省事(尤其生产环境),应填你本地机器的公网IP,格式如203.0.113.42/32 - 如果用的是动态IP(比如家庭宽带),可临时用
203.0.113.0/24范围,但务必事后收紧 - 确认规则状态是
已启用,且规则列表里没有更高优先级的拒绝规则(AWS不支持显式拒绝,但旧规则可能被覆盖)
为什么telnet通了,Navicat还是超时?
telnet能连上只说明端口可达,不代表数据库服务真在监听或允许你登录。此时要排查:
- RDS实例的
Publicly accessible必须为Yes(在修改实例页面的Connectivity区域设置) - RDS所在子网必须是
Public Subnet,且该子网的路由表有指向igw-xxxxx的0.0.0.0/0路由 - 检查RDS终端节点域名是否解析出公网IP:
dig your-db.xxxxxxx.us-east-1.rds.amazonaws.com,若返回的是内网地址(如10.x.x.x),说明它没走公网路径 - Navicat连接时勾选了SSL但RDS没开强制SSL,或证书路径不对,也会表现为超时而非明确报错
安全组规则生效后仍失败的隐藏检查点
规则保存后不是立即生效,但通常几秒内就 OK;如果等了一分钟还不行,重点看这几个地方:
- 本地防火墙是否拦截了出站连接(尤其是Windows Defender防火墙默认会拦新应用)
- 公司网络或校园网是否屏蔽了非标准端口(3306/5432常被封),可换手机热点再试
- RDS参数组里
max_connections是否已满,或login_timeout设置过短(PostgreSQL需查postgresql.conf中的tcp_keepalives_idle) - Navicat连接配置里的
Host填的是终端节点全名,不是别名或内网地址;Port和RDS实际监听端口一致(注意:有些RDS自定义了非标端口)
真正卡住人的,往往不是规则没加,而是加了但没加对——源IP写成内网段、子网没配IGW路由、或者以为开了“Publicly accessible”就等于有了公网IP。这些点漏掉一个,Navicat就只能干等超时。











