Elastic Beanstalk部署的FastAPI应用HTTPS请求间歇性无响应排查求助

关键线索分析 #

你日志中反复出现的refresh-policy-routes@ens5.service是核心关联点：这个系统服务负责刷新EC2实例的网络策略路由，执行过程中会临时重置实例的网络栈，可能导致：

• 负载均衡器（LB）的健康检查短暂失败
• 外部API请求出现超时或无响应
• 服务执行完成后网络自动恢复，应用随之恢复正常

结合单实例无HTTPS环境正常、多实例带LB环境异常的差异，网络配置和负载均衡器层面的问题概率更高，以下分模块拆解并给出排查方案：

1. 网络配置层面的可能原因 #

• 路由表临时波动：默认VPC子网虽关联了IGW，但refresh-policy-routes触发时会修改实例本地路由规则，导致实例与LB间的流量短暂中断
• t3.micro实例网络性能限制：该实例类型的网络带宽有限，路由刷新时易出现数据包丢失，放大无响应现象

2. 负载均衡器层面的可能原因 #

• 健康检查配置过严：若LB健康检查的超时时间过短（如默认5秒），实例因路由刷新出现的短暂无响应会被判定为不健康，LB会将其踢出目标组；剩余实例流量过载导致全部请求失败，实例恢复后又被重新加入，表现为周期性恢复
• LB迁移遗留问题：从经典LB迁移到应用/网络LB后，可能存在监听器规则、SSL协商参数的配置不一致，引发HTTPS请求在网络波动时失败

3. 应用环境层面的排查点 #

虽然单实例正常，但多实例环境下仍需排查：

• Gunicorn worker配置过载：t3.micro为1核实例，--workers=4会导致CPU/内存资源竞争，网络波动引发请求堆积时，worker无法及时处理
• 异步操作阻塞：若FastAPI存在未正确处理的异步阻塞逻辑，多实例流量分发会放大阻塞问题，结合网络波动出现间歇性无响应

针对性修复与排查步骤 #

• 优化网络刷新配置：
  • 检查EC2实例的ec2net服务配置，调整路由刷新的触发频率（部分AWS AMI会周期性执行该操作）
  • 配置弹性网卡（ENI）的稳定路由规则，减少不必要的路由刷新
• 调整负载均衡器设置：
  • 将健康检查的超时时间调整为10-15秒，间隔时间设为30秒，给实例留出网络恢复的缓冲期
  • 检查HTTPS监听器的SSL协商超时，设置为至少5秒，避免握手失败导致请求丢弃
• 调整应用资源配置：
  • 修改Procfile中的Gunicorn配置为web: gunicorn main:app --workers=2 --worker-class=uvicorn.workers.UvicornWorker（遵循1核实例推荐2-3个worker的原则）
  • 为FastAPI添加请求超时中间件，避免请求长时间阻塞占用worker资源
• 验证HTTPS单实例环境：临时给单实例EB环境配置HTTPS（复用现有证书和监听器配置），确认是否出现相同问题，以此排除LB的影响

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