FastAPI经Nginx反向代理后性能骤降，求排查方向

从你的配置和现象来看，性能骤降的核心原因大概率是Nginx的连接复用配置缺失，但也需要结合FastAPI/uvicorn的配置做验证和优化，以下是具体分析：

一、Nginx侧的关键问题与优化 #

你的Nginx配置仅设置了keepalive 16，但缺少HTTP/1.1协议支持和连接复用的核心参数，导致每次请求都新建TCP连接——LLM推理请求通常是大流量或长连接场景，TCP握手的开销会被大幅放大，直接拉低RPS。

优化后的Nginx配置 #

events {
    worker_processes auto;  # 自动匹配服务器CPU核心数，充分利用资源
    worker_connections 1000000;
    use epoll;  # Linux环境下启用epoll提升高并发性能
    multi_accept on;  # 让worker进程一次性接收所有新连接
}

http {
    upstream backend {
        server server_ip1:8000;
        server server_ip2:8000;
        
        keepalive 64;  # 调高连接池大小，匹配后端的keepalive上限
        keepalive_timeout 60s;
        keepalive_requests 1000;  # 单个连接可处理的请求数，减少重建次数
    }
    
    server {
        listen 80;
        
        location / {
            proxy_pass http://backend/;
            proxy_buffering off;
            
            # 开启连接复用的核心参数
            proxy_http_version 1.1;
            proxy_set_header Connection "";
            
            # 适配LLM推理的超时设置
            proxy_connect_timeout 30s;
            proxy_send_timeout 300s;
            proxy_read_timeout 300s;
        }
    }
}

额外验证点 #

• 虽然使用了--network host，但Docker容器的网络栈仍可能存在隐性开销，建议直接在宿主机安装Nginx测试，排除容器化带来的性能损耗。
• 检查Nginx的error.log，确认是否存在连接超时、后端拒绝连接等异常日志。

二、FastAPI/uvicorn侧的配套优化 #

你的后端配置存在两个可能的瓶颈点，需要同步调整：

1. uvicorn worker数量配置
   默认uvicorn是单worker进程，无法充分利用多核CPU处理请求，启动命令应调整为：

uvicorn.run(
    app, 
    host=args.host, 
    port=args.port, 
    log_level="debug", 
    timeout_keep_alive=70,  # 需大于Nginx的keepalive_timeout，避免后端先断开连接
    workers=4  # 设为服务器CPU核心数的1-2倍
)

2. vLLM并发参数验证
   虽然直接请求后端能达到100RPS，但仍需确认vLLM的max_num_batched_tokens和max_num_seqs参数是否适配高并发场景，避免后端因批量处理能力不足成为瓶颈。

三、排查步骤 #

1. 先应用上述Nginx优化配置，重启后测试性能变化
2. 在Nginx服务器上用wrk或ab工具直接压测后端节点，确认跨服务器网络能支撑100RPS，排除网络链路问题
3. 用tcpdump抓包，查看Nginx与后端之间的连接是否被复用（是否有频繁的TCP握手包）

结论 #

当前配置下，Nginx缺少连接复用的核心配置是性能骤降的主要原因，补充proxy_http_version 1.1和proxy_set_header Connection ""后，连接复用机制生效，性能应能大幅回升。

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