Docker环境下Celery任务调用长耗时Cloud Run端点遇RemoteDisconnected错误

1. 检查Celery Worker的任务超时配置 #

Celery的task_time_limit（硬超时，到点直接终止进程）和task_soft_time_limit（软超时，发送信号提醒）是常见的超时触发点，大概率你的worker配置了60秒左右的超时：

• 查看Docker Compose中Celery服务的环境变量，是否存在CELERY_TASK_TIME_LIMIT=60或CELERY_TASK_SOFT_TIME_LIMIT=60这类配置
• 检查任务的装饰器，比如@app.task(time_limit=60)，是否给单个任务直接设置了超时限制
• 临时测试验证：在任务代码里手动覆盖超时，比如@app.task(time_limit=300)，观察是否还会在61秒左右报错

2. 确认Cloud Run的前端请求超时设置 #

你提到Cloud Run服务超时设为300秒，但Cloud Run的前端负载均衡默认请求超时是60秒，这和服务运行超时是两个独立配置：

• 登录Cloud Run控制台，找到对应服务，进入「容器」→「请求超时」页面，确认是否将该值设为300秒（与服务运行超时保持一致）
• 如果用gcloud命令部署，检查部署指令是否携带--http2-max-request-timeout=300s参数，否则前端负载均衡会在60秒时主动切断请求连接

3. 排查中间代理/网关的超时 #

如果Celery任务的请求经过Nginx、公司内部代理或其他网关组件，这些服务的默认超时通常为60秒：

• 若存在Nginx反向代理（比如全局代理场景），检查proxy_read_timeout、proxy_connect_timeout配置项，是否设置为60秒
• 查看Docker容器的代理环境变量（HTTP_PROXY/HTTPS_PROXY），如果走代理服务，确认代理服务器的超时规则

4. 检查宿主机/云平台的网络超时 #

• 查看宿主机的TCP keepalive参数：执行cat /proc/sys/net/ipv4/tcp_keepalive_time，默认值为7200秒，若被修改为远小于60秒的数值，可能导致连接被提前回收
• 检查云平台的安全组/防火墙规则：比如GCP的VPC防火墙、AWS的安全组，是否存在设置TCP连接超时为60秒的规则
• 确认Docker daemon的网络配置：是否修改过默认的TCP超时参数

5. 抓包定位连接断开发起方 #

最直接的方式是在Celery容器内抓包，明确是哪一端主动断开了连接：

• 进入Celery容器：docker exec -it <celery-container-name> bash
• 安装tcpdump（若未预装）：apt-get update && apt-get install tcpdump
• 启动抓包：tcpdump -i any host <cloud-run-endpoint-ip> -w cloud-run-capture.pcap
• 触发任务，报错后停止抓包，用Wireshark分析pcap文件：
  • 如果FIN/RST包来自Cloud Run的IP，说明是Google负载均衡或服务端主动断开
  • 如果来自Celery容器的IP，说明是Worker进程因超时主动终止连接
  • 如果来自其他IP，说明是中间网络设备（如防火墙、代理）断开了连接

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