uWSGI启动报错“invalid request block size”是因Nginx与uWSGI协议不匹配：Nginx用uwsgi://但uWSGI默认走HTTP，应统一为uwsgi协议（uWSGI加--protocol uwsgi和--socket）或改Nginx为http://并配--http。
uWSGI启动报错invalid request block size怎么修
这是配置不匹配最典型的症状：Nginx发来的请求头被uWSGI当成请求体解析了，根本原因是socket协议没对齐。默认uWSGI走的是http协议，但Nginx upstream里写的是uwsgi://，两边压根不在一个频道上。
实操建议：
- 要么让uWSGI切到
uwsgi协议（推荐）：启动时加--protocol uwsgi，并确保用--socket而非--http - 要么让Nginx改用
http://转发：把upstream里的uwsgi://换成http://，同时uWSGI必须带--http :8000 - 检查uWSGI日志里是否出现
your processes number limit is 128这类提示——它常和协议错配一起出现，别被它带偏
Nginx配置里proxy_pass和uwsgi_pass该用哪个
取决于uWSGI跑在什么协议上。用错就502，没商量。
判断逻辑很简单：
立即学习“Python免费学习笔记（深入）”；
- uWSGI监听的是
--socket /tmp/uwsgi.sock或--socket 127.0.0.1:3031→ 用uwsgi_pass+uwsgi_param系列配置 - uWSGI监听的是
--http :8000→ 用proxy_pass http://127.0.0.1:8000，不用uwsgi_param -
uwsgi_param UWSGI_SCRIPT这种只在uwsgi_pass场景下生效，HTTP模式下写了也白写
Python项目里os.environ读不到Nginx传的环境变量
因为uWSGI默认不透传环境变量，Nginx设的fastcgi_param或uwsgi_param只影响WSGI层面的environ字典，不会注入到系统级os.environ。
要让Python代码能用os.environ.get('DEBUG')，得两步走：
- 在uWSGI配置里加
--env DEBUG=true，或在ini文件里写env = DEBUG=true - 如果依赖Nginx动态传值（比如不同域名对应不同配置），改用
uwsgi_param传进WSGIenviron，然后在Django/Flask入口里手动塞进os.environ，例如：os.environ['DOMAIN'] = environ.get('HTTP_HOST', '') - 注意：uWSGI的
--env只在master进程启动时读一次，热重载不会刷新
静态文件404，但collectstatic明明跑过了
不是Django没生成，是Nginx根本没去那个目录找。uWSGI只管Python逻辑，静态文件得Nginx直出。
关键检查点：
- 确认Nginx的
location /static/块里alias路径末尾有没有多加/：写成alias /var/www/myapp/static/;是对的，写成alias /var/www/myapp/static;会导致路径拼接错误 - Django的
STATIC_ROOT和Nginx的alias必须指向同一物理路径，大小写、软链接、挂载点都要对得上 - 权限问题常被忽略：Nginx worker进程用户（如
www-data）必须对STATIC_ROOT有读+执行权限，ls -ld /var/www/myapp/static看一眼就知道
uWSGI日志和Nginx error.log里第一行报错，别急着改Python代码。 
