AWS Fargate ECS Docker服务连接同VPC ElastiCache Redis超时排查

同VPC内EC2实例可正常连通Redis，说明Redis服务本身、VPC基础路由无全局故障，问题集中在Fargate服务的专属配置上，按以下优先级排查：

1. 安全组规则（最高发故障点） #

• 检查Fargate任务绑定的安全组出方向规则：若配置了精细化出站策略，必须放通到Redis对应端口（默认6379）的TCP流量，优先以安全组ID作为目的配置，不要仅靠IP段放行。
• 检查ElastiCache绑定的安全组入方向规则：不要因为EC2能连通就默认规则正确，Fargate使用awsvpc网络模式时，流量源是任务自身绑定的安全组，不存在用户可控的宿主机安全组，必须把Fargate任务的安全组加入Redis安全组的入方向允许列表。
• 避坑：如果Redis安全组入方向仅放通VPC私网网段，需确认Fargate任务实际分配的私网IP确实在放通网段内，没有误将任务调度到其他VPC或网段的子网。

2. 子网与网络ACL配置 #

• 确认Fargate任务部署的子网和Redis子网属于同一VPC：若任务部署在公共子网，必须开启「自动分配公网IP」，否则会出现内网路由异常；优先将任务调度到和验证用EC2相同的私有子网测试，排除子网路由差异。
• 检查子网关联的网络ACL：网络ACL是无状态规则，和有状态的安全组逻辑不同，需同时满足：
  • Fargate所在子网出方向放通到Redis 6379端口的TCP流量，入方向放通Redis返回的1024-65535临时端口流量
  • Redis所在子网入方向放通Fargate网段访问6379端口的TCP流量，出方向放通返回的临时端口流量
    很多场景下EC2所在子网的ACL已经放通对应规则，但Fargate新子网的ACL未配置，会直接导致连接超时。

3. Fargate平台与VPC基础配置 #

• 检查Fargate平台版本：1.3.0及更早版本存在VPC DNS解析、内网路由的已知问题，升级到1.4.0或最新稳定平台版本重试。
• 确认VPC DNS配置：VPC必须开启「DNS解析」「DNS主机名」选项，Fargate awsvpc模式默认使用VPC DNS做内网域名解析，可在任务中临时部署带网络工具的sidecar容器，执行nslookup <你的ElastiCache连接端点>验证解析结果，若返回公网IP则说明解析异常，必然导致连接超时。
• 若开启了Fargate Service Connect、App Mesh等服务网格能力，临时关闭相关功能测试，排除网格路由拦截流量的问题。

4. 容器与应用配置 #

• 检查node-redis连接参数：确认使用的是ElastiCache的私网连接端点，没有误填公网地址；连接超时时间不要设置过短（建议不小于2s，覆盖Fargate冷启动的网络初始化耗时）；如果ElastiCache开启了传输加密，客户端必须配置TLS连接，反之如果Redis没开加密不要强制启TLS，两种配置不匹配都会触发连接超时。
• 检查容器镜像配置：确认Dockerfile或任务定义中没有自定义DNS配置覆盖VPC默认DNS（比如强制指定8.8.8.8等公网DNS），没有配置容器内iptables拦截出站流量。
• 连通性分层验证：将任务镜像临时替换为带nc/telnet工具的基础镜像，启动后执行nc -zv <redis端点> 6379，如果工具都无法连通，说明问题完全在网络层，和node-redis客户端逻辑无关；如果工具可连通但客户端连接失败，再重点排查客户端认证、TLS、库版本兼容问题。

快速定位技巧 #

• 第一步先做规则最小限制测试：Fargate任务安全组临时配置出方向全通，Redis安全组临时放通整个VPC网段的6379入方向流量，若此时可连通，再逐步收紧规则定位具体是哪条策略拦截了流量。
• 检查ElastiCache子网组配置：确认Redis所有节点的私网IP都在预期网段内，排除节点故障漂移到未放通子网的情况。

内容的提问来源于stack exchange，提问作者Snowpanther