Nginx 不执行 Python，仅反向代理请求，多线程/进程由 uWSGI 或 Gunicorn 实现；uWSGI 通过 processes 和 threads 配合 enable-threads 控制并发，Nginx 需用 uwsgi_pass 并调优 worker_connections 与超时参数。
Nginx 本身不直接执行 Python，也不原生支持 FastCGI 或 uWSGI 的线程/进程调度——它只负责反向代理请求。真正的多线程与多进程配置，全部落在后端服务（如 uWSGI、Gunicorn）上。Nginx 的作用是高效分发连接，而并发能力由 Python 应用服务器决定。
下面按两种主流方式分别说明关键配置逻辑和协同要点：
uWSGI 多进程 + 多线程配置
uWSGI 是最常用于 Nginx + Python 部署的 WSGI 容器，支持灵活的进程与线程组合：
-
processes控制 worker 进程数（绕过 GIL，适合 CPU 密集型） -
threads控制每个进程内的线程数（适合 IO 等待释放 GIL） -
enable-threads = true必须显式开启线程支持 -
master = true推荐启用主进程管理（自动重启、平滑 reload）
示例 uwsgi.ini：
立即学习“Python免费学习笔记（深入）”；
[uwsgi] socket = 127.0.0.1:8001 chdir = /opt/myapp wsgi-file = myapp/wsgi.py callable = application master = true processes = 4 threads = 2 enable-threads = true max-requests = 2000 vacuum = true pidfile = /tmp/uwsgi.pid daemonize = /var/log/uwsgi.log
Nginx 对应配置只需正确转发：
location / {
include uwsgi_params;
uwsgi_pass 127.0.0.1:8001;
uwsgi_read_timeout 30;
}注意：uWSGI 默认使用
uwsgi协议（非 HTTP），Nginx 必须用uwsgi_pass而非proxy_pass；若改用http模式，则需配protocol = http并改用proxy_pass，但性能略低。
FastCGI 方式（已基本淘汰，仅作兼容说明）
FastCGI 在 Python 场景中极少使用，因需依赖 flup 或 spawn-fcgi，且无现代进程管理能力。若必须用（如旧系统迁移），典型流程是：
- 启动多个
spawn-fcgi实例监听不同端口（如127.0.0.1:9001,9002） - Nginx 使用
fastcgi_pass分发请求 - 无法在单个实例内配置“线程”，只能靠多个独立进程模拟并发
示例 Nginx 片段：
location / {
fastcgi_pass 127.0.0.1:9001;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}⚠️ 不推荐新项目采用 FastCGI：无健康检查、无自动重启、无优雅关闭、不支持异步，且 Python 生态已全面转向 WSGI/ASGI。
Nginx 与后端的并发协同要点
光调 uWSGI 的 processes 和 threads 不够，Nginx 层也要对齐，否则会卡在连接环节：
-
worker_processes auto;—— 通常设为 CPU 核心数 -
worker_connections 1024;—— 每 worker 最大连接数，建议 ≥ 后端总 worker 数 × 2 -
upstream块启用 keepalive（如果后端支持）：upstream backend { server 127.0.0.1:8001; keepalive 32; } location / { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ''; } - 超时参数需大于后端处理时间：
proxy_read_timeout、uwsgi_read_timeout至少设为 30 秒起
如何选进程还是线程？
-
纯 IO 密集型（API、数据库查询、HTTP 调用）：优先用异步模型（Uvicorn + ASGI），或 uWSGI
processes=2~4+threads=8~16 -
CPU 密集型（图像处理、计算任务）：禁用线程，专注
processes = CPU核心数，避免线程竞争 -
混合型或 Django 项目：
processes=3+threads=4是较稳妥起点，再根据监控（CPU、内存、响应延迟）微调
不复杂但容易忽略
