必须关闭proxy_request_buffering并协同配置client_max_body_size（设于server块）、超时参数及临时文件路径，才能实现Nginx代理Python应用大文件的流式上传；单改一项无效。
要让 Nginx 正确代理 Python 应用（如 Flask、FastAPI、Django）的大文件上传，核心不是“加大所有超时值”，而是建立一套协同生效的流式转发机制。Python 后端天然支持分块读取和流式处理，但 Nginx 默认行为会破坏这一能力——必须主动关闭缓冲、精准设限、对齐超时。
必须关闭 proxy_request_buffering
这是最易忽略也最关键的一步。Nginx 1.12+ 默认开启该功能，会把整个上传文件（比如 500MB 视频）先收全、缓存到内存或磁盘，再发给 Python 进程。这会导致：
- 上传卡在 99%，前端显示“正在上传”却无进展
- worker 进程内存飙升，甚至触发 OOM Kill
- 与 Flask 的
request.stream或 FastAPI 的StreamingResponse冲突，返回 400 或连接重置
✅ 正确做法：只在上传路径的 location 块中关闭：
proxy_request_buffering off;
proxy_pass http://python_backend;
}
client_max_body_size 要设在 server 层
它决定请求能否进入 Nginx 处理流程。如果写在 location 里，且值大于默认 1MB，而 server 块没显式声明，Nginx 仍按默认 1MB 拦截，直接返回 413 错误，根本不会走到 proxy_pass。
立即学习“Python免费学习笔记（深入）”；
✅ 推荐配置（写在 server 块内）：
listen 80;
client_max_body_size 2G;
# 其他配置...
}
⚠️ 注意单位格式：支持 2g、2G、2048m，但不识别 2G（缺空格）或 2gb（单位错误）。
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
同步检查 Python 后端限制：
- Flask：
app.config['MAX_CONTENT_LENGTH'] = 2 * 1024 * 1024 * 1024 - FastAPI：
UploadFile本身不限，但需确保 Uvicorn 的--limit-concurrency和--limit-max-requests不干扰长连接 - Django：
DATA_UPLOAD_MAX_MEMORY_SIZE和FILE_UPLOAD_MAX_MEMORY_SIZE需调高或设为 0（慎用）
超时参数必须分级匹配
大文件上传是多阶段耗时过程，每个环节对应不同超时项，不能统一填 3600：
- client_body_timeout 1800; —— 客户端上传整个文件体的最大允许空闲时间（弱网分段上传场景关键）
- proxy_send_timeout 1800; —— Nginx 向 Python 进程转发请求体时，两次数据包间的最大空闲等待（后端解析慢、校验耗时、IO 写入卡顿时触发）
- proxy_read_timeout 1800; —— Nginx 等待 Python 返回响应（如上传成功 JSON、进度回调）的最大空闲时间（导出类接口也适用）
⚠️ 三者关系建议：client_body_timeout ≥ proxy_send_timeout ≥ proxy_read_timeout，否则前一阶段已断，后一阶段无从生效。
✅ 示例（放在同一 location 中）：
proxy_request_buffering off;
client_body_timeout 1800;
proxy_send_timeout 1800;
proxy_read_timeout 1800;
proxy_pass http://python_backend;
}
临时文件与系统级准备不可少
当上传体超过 client_body_buffer_size（默认 8k～16k），Nginx 会写临时文件。若路径不可写或磁盘满，上传直接失败。
✅ 必做配置：
- 显式指定临时目录：
client_body_temp_path /var/tmp/nginx/upload 1 2; - 确保该路径存在、属主为 nginx worker 用户（如
www-data）、剩余空间 ≥ 最大预期上传文件 - 调大内存缓冲区（避免频繁落盘）：
client_body_buffer_size 512k;
系统层面补充检查：
- 确认
ulimit -n≥ 65535（防止连接数耗尽） - 检查
net.core.somaxconn和net.ipv4.tcp_max_syn_backlog≥ 65535（防握手队列溢出） - 若走 HTTPS，启用 TLS session reuse 减少握手开销
