FastAPI+Socket.IO（Uvicorn部署）微服务中CLOSE_WAIT状态TCP连接无法关闭导致就绪探针失败的解决方案咨询

背景信息 #

先帮你梳理下当前的服务环境，确保我们对齐上下文：

• 服务基于FastAPI+Socket.IO构建，用Uvicorn作为ASGI服务器部署，单worker模式运行
• 核心特性：
  • 以Socket.IO事件处理为主，搭配少量REST API；事件通过异步任务+await编排，确保单worker调度所有请求
  • 自定义15秒心跳机制，防止15分钟级别的长任务执行完成后无法推送结果
• K8s资源配置：内存请求8GB/上限16GB，CPU请求800m/上限4核，事件循环采用asyncio
• Uvicorn启动配置：

  uvicorn.run(socket_app, host="0.0.0.0", port=8000, workers=1, limit_max_requests=1000, limit_concurrency=100, timeout_graceful_shutdown=30)
  

• K8s就绪探针：通过curl localhost:8000/healthz检查，初始延迟60s，超时30s，检查周期30s，失败阈值4

问题回顾 #

随着服务负载攀升，K8s就绪探针频繁失败，Pod被标记为不健康，导致Socket.IO客户端彻底无法收发消息。排查后发现：

• 大量TCP连接处于CLOSE_WAIT状态，且线性增长直至Pod无法响应现有连接
• 多数CLOSE_WAIT连接是本地127.0.0.1:8000与随机端口的本地连接，无关联进程ID
• 存在少量FIN_WAIT2本地连接，以及跨Pod的CLOSE_WAIT连接（推测是服务间API调用导致）

根据你的排查，核心问题是应用（大概率是Uvicorn或Socket.IO层）未主动关闭已收到FIN包的连接，进而引发资源耗尽和探针失败。下面是我结合你的环境给出的具体优化方案和排查方向：

一、Uvicorn配置优化 #

针对单worker+asyncio的场景，调整Uvicorn参数来优化连接生命周期管理：

1. 细化超时与连接回收配置

   • 增加timeout_keep_alive参数：默认5秒的超时对于15分钟的长任务来说太短，建议调至30-60秒，避免连接被误判为空闲。启动命令更新为：

     uvicorn.run(
         socket_app,
         host="0.0.0.0",
         port=8000,
         workers=1,
         limit_max_requests=5000,  # 调高请求数阈值，减少单worker重启频率
         limit_concurrency=80,      # 结合长任务占比适当降低，避免事件循环过载
         timeout_graceful_shutdown=900,  # 延长优雅关闭超时至15分钟，覆盖最长任务时间
         timeout_keep_alive=60
     )
     

   • 评估是否保留limit_max_requests：单worker模式下，频繁重启会导致长任务中断，且可能加剧连接泄漏。如果必须保留，务必调大阈值并配合足够长的优雅关闭时间。

2. 启用异步连接清理

   • 确保Uvicorn使用的是纯异步的ASGI适配层，避免混合同步代码导致事件循环阻塞。检查所有自定义中间件是否为异步实现，防止阻塞连接关闭逻辑。

二、Socket.IO层优化 #

Socket.IO的连接管理是核心，调整内置机制替代自定义逻辑，确保连接正确释放：

1. 替换自定义心跳为Socket.IO内置机制
   自定义15秒心跳可能和Socket.IO内置心跳冲突，建议统一使用内置配置：

   from socketio import AsyncServer
   
   sio = AsyncServer(
       async_mode="asgi",
       ping_interval=10,  # 服务端每10秒发送ping包
       ping_timeout=30,    # 30秒未收到pong则主动断开连接
       max_http_buffer_size=10*1024*1024,  # 按需调整，防止大消息阻塞
       cors_allowed_origins="*"  # 按需配置允许的源
   )
   

   内置心跳会自动处理连接存活状态，避免自定义逻辑遗漏连接关闭场景。

2. 强制清理断开连接的资源
   监听disconnect事件，主动清理关联任务与连接：

   # 全局存储活跃长任务
   active_long_tasks = {}
   
   @sio.on("disconnect")
   async def handle_disconnect(sid):
       # 取消该连接关联的所有长任务
       if sid in active_long_tasks:
           active_long_tasks[sid].cancel()
           del active_long_tasks[sid]
       # 强制释放Socket.IO连接
       await sio.disconnect(sid)
   
   @sio.on("start_long_task")
   async def start_long_task(sid, task_data):
       # 用create_task封装长任务，并存储引用
       task = asyncio.create_task(run_long_task(sid, task_data))
       active_long_tasks[sid] = task
       try:
           await task
       except asyncio.CancelledError:
           await sio.emit("task_cancelled", room=sid)
       finally:
           if sid in active_long_tasks:
               del active_long_tasks[sid]
   

   这样可以避免连接断开后任务仍在后台运行，占用资源导致连接无法释放。

三、Kubernetes与网络层面优化 #

从基础设施层面减少连接泄漏的影响：

1. 优化就绪探针实现
   替换curl为K8s原生httpGet探针，减少额外进程开销，同时缩短超时时间：

   readinessProbe:
     httpGet:
       path: /healthz
       port: 8000
     initialDelaySeconds: 60
     timeoutSeconds: 10  # 原30秒过长，探针连接会占用服务连接数
     periodSeconds: 30
     successThreshold: 1
     failureThreshold: 4
   

   同时确保/healthz接口是纯轻量实现，比如直接返回200 OK，不要包含任何数据库查询或耗时操作，确保负载高时探针能快速响应。

2. 调整内核TCP参数加速连接回收
   通过InitContainer修改Pod内核参数，加快闲置连接的回收：

   initContainers:
   - name: sysctl-tcp
     image: busybox:1.36
     command:
     - sysctl
     - -w
     - net.ipv4.tcp_fin_timeout=30  # 缩短FIN_WAIT2超时，默认60秒
     - net.ipv4.tcp_tw_reuse=1     # 允许复用TIME_WAIT连接
     - net.ipv4.tcp_keepalive_time=120  # 120秒发送一次keepalive探测
     - net.ipv4.tcp_keepalive_intvl=30  # 探测重试间隔30秒
     - net.ipv4.tcp_keepalive_probes=3  # 重试3次后断开
     securityContext:
       privileged: true
   

   这些参数能显著减少CLOSE_WAIT和FIN_WAIT2连接的堆积时间。

四、其他排查与优化方向 #

1. 升级Uvicorn版本
   你当前使用的uvicorn==0.30.5存在一些已知的连接管理bug（比如某些场景下未正确处理FIN包），建议升级到近期的稳定版本（如0.31.0或0.29.0），修复已知的连接泄漏问题。

2. 排查事件循环阻塞
   如果事件循环被长时间阻塞，Uvicorn无法处理连接关闭的FIN包，会导致CLOSE_WAIT连接堆积。添加事件循环监控任务：

   import asyncio
   import time
   
   async def monitor_event_loop():
       while True:
           start_time = time.perf_counter()
           await asyncio.sleep(1)
           elapsed = time.perf_counter() - start_time
           if elapsed > 1.2:  # 正常sleep 1秒，若耗时超过1.2秒说明有阻塞
               print(f"WARNING: Event loop blocked for {elapsed:.2f} seconds!")
   

   在服务启动时创建该任务：

   # 在Uvicorn启动前添加
   asyncio.create_task(monitor_event_loop())
   

   帮助定位导致事件循环阻塞的长任务或同步代码。

3. 检查跨服务API调用的连接管理
   对于跨Pod的CLOSE_WAIT连接，检查服务间API调用是否使用了异步客户端（如httpx.AsyncClient），并确保用async with上下文管理器正确关闭：

   import httpx
   
   async def call_other_service():
       async with httpx.AsyncClient() as client:
           response = await client.get("http://other-service/api/endpoint")
           return response.json()
   

   避免长期持有客户端连接导致泄漏。

备注：内容来源于stack exchange，提问作者Jeyshiv