Nginx不直接运行Python代码，而是通过反向代理（如转发至Uvicorn/Gunicorn）协同工作；其并发调优本质是Nginx连接管理与Python后端并发模型的联合优化，需对齐超时、启用keepalive、统一文件描述符限制并匹配业务类型选型。
Nginx 本身不直接运行 Python 代码，它和 Python 的协作通常是通过反向代理（如将请求转发给 Gunicorn/Uvicorn/Waitress 等 Python 应用服务器）或嵌入式模块（如 nginx-python、nginScript，但已基本弃用）实现。因此，“Nginx 中 Python 部署”的并发调优，本质是 **Nginx + Python 后端服务**的联合调优，重点在两层解耦协同：Nginx 做连接管理与负载分发，Python 服务做业务处理。
明确角色分工：Nginx 不负责 Python 并发，只放大其能力
Nginx 是事件驱动、单线程非阻塞的 C 实现，天生适合高连接数低开销的调度；而 Python 应用（如 Flask/Django/FastAPI）默认是同步阻塞模型，必须依赖外部进程/线程/协程模型来应对并发。所以：
- Nginx 的
worker_processes和worker_connections决定它能同时“接住”多少请求，但不决定这些请求被 Python 处理得多快 - 真正影响 Python 请求吞吐的是后端服务的并发模型（多进程？多线程？异步？）及其资源配置
- 两者之间通过 upstream 连接池（如
proxy_pass）、keepalive、超时等参数紧密耦合——调优必须成对进行
Python 后端选型与并发模型匹配
根据业务类型选择合适的服务容器，并配置对应并发规模：
-
IO 密集型（如 API 调用、数据库查询、文件上传）：优先用异步框架（FastAPI + Uvicorn）或协程驱动服务（Uvicorn 默认使用
uvloop），启动多个 worker 进程（--workers 4），每个 worker 内部用异步事件循环处理数千并发 -
CPU 密集型（如图像处理、数值计算）：避开 GIL 限制，用多进程模型——Gunicorn 启动多个 sync worker（
--workers 4 --worker-class sync），或搭配multiprocessing在业务层并行化 -
混合型或遗留系统（如 Django）：推荐 Gunicorn + 多进程 + 适度线程（
--workers 3 --threads 4），线程用于 IO 等待释放 GIL，进程用于 CPU 并行
Nginx 与 Python 后端的连接协同调优
避免“Nginx 接得进、Python 吐不出”的瓶颈，关键在 upstream 连接复用与超时对齐：
立即学习“Python免费学习笔记（深入）”；
- 启用 upstream keepalive：防止每次请求都重建 TCP 连接
upstream backend {
server 127.0.0.1:8000;
keepalive 32;
} - 在 location 中复用连接：
proxy_http_version 1.1;
proxy_set_header Connection ''; - 超时设置需小于 Python 服务的 timeout，且彼此匹配：
proxy_connect_timeout 5s;
proxy_send_timeout 30s;
proxy_read_timeout 30s;
# 同时 Python 侧（如 Uvicorn）设 --timeout-keep-alive=5s - 限制单个 upstream server 的并发连接数，防打垮后端：
proxy_max_temp_file_size 0;
proxy_buffering off; # 若后端已流式响应，可关缓冲减延迟
系统级协同：文件描述符与内存一致性
Nginx 和 Python 进程共享系统资源，必须统一调整：
- 确认 ulimit -n ≥ Nginx 最大连接 × 1.2 + Python worker 总连接数（例如：Nginx 4×10240 = 40960，Gunicorn 4 workers × 1000 conn ≈ 4000 → 建议 ulimit -n 65535）
- Nginx 配置中补全：
worker_rlimit_nofile 65535; - Python 服务启动时显式指定文件描述符上限（如 Uvicorn 加
--limit-concurrency 1000 --limit-max-requests 10000） - 禁用不必要的日志刷盘（如 Gunicorn
--access-logfile -+--log-level warning），减少 IO 竞争
