当Flask应用返回413状态码时，通常是因为请求体大小超过了默认限制。Flask默认的最大请求体大小为16MB，如果你需要上传更大的文件，比如视频或大型压缩包，就会触发这个错误。检查nginx或uwsgi的日志可以确认是否是Flask层限制，还是前端代理的限制。在Flask开发服务器中，错误直接显示在控制台，而生产环境需查看应用日志。确认错误来源是调整配置的第一步。

在Flask应用中可以简单通过`app.config['MAX_CONTENT_LENGTH']`设置允许的最大上传大小。例如设置为100MB：`app.config['MAX_CONTENT_LENGTH'] = 100 * 1024 * 1024`。这个值以字节为单位，注意不要设置过大，以免导致内存溢出或请求超时。修改后重启应用即可生效。如果同时使用nginx反向代理，还需同步调整nginx的`client_max_body_size`，否则nginx会先拒绝上传。

如果日志确认是Flask自身的限制，修改很简单。在Flask应用中可以简单通过app.config['MAX_CONTENT_LENGTH']设置允许的最大上传大小。例如设置为100MB：app.config['MAX_CONTENT_LENGTH'] = 100 * 1024 * 1024。这个值以字节为单位，注意不要设置过大，以免导致内存溢出或请求超时。修改后重启应用即可生效。如果同时使用nginx反向代理，还需同步调整nginx的client_max_body_size，否则nginx会先拒绝上传。

如果你在Flask前面使用了nginx，需要在nginx配置中增加或修改client_max_body_size指令。该指令可以放在http、server或location块中。例如在server块添加client_max_body_size 100m;表示允许100MB的上传。设置后执行nginx -s reload重新加载配置。注意：如果后端有多个location，要确保该配置覆盖到上传接口对应的location。另外，若开启了proxy_request_buffering，也可能影响大文件上传。

调整完Flask和nginx后，如果413错误仍然出现，需要检查WSGI服务器（如Gunicorn或uWSGI）自身的限制。Gunicorn默认限制请求体为1MB，可以通过--limit-request-line和--limit-request-fields微调，但直接设置--limit-request-body较大值可能不稳定；uWSGI则用buffer-size和limit-post参数控制。组合使用三层（nginx → WSGI → Flask）时，任何一层的限制小于上传文件大小都会导致413，建议从最外层向内逐层放宽，并观察日志确认具体哪一层拒绝。

对于超大文件（例如超过500MB），直接调大MAX_CONTENT_LENGTH可能导致内存耗尽。可以考虑使用流式上传：在Flask中通过request.stream逐步读取，配合shutil.copyfileobj写入磁盘，此时可以不依赖Flask的请求体限制，但需要在代码中自行检查文件大小。同时nginx的client_max_body_size仍然需要设置，并关闭proxy_request_buffering以支持流式传输。这种方法适用于上传长期运行、不需要等待完整请求的场景，但后端代码和代理配置都需要配合调整。

另一个容易忽略的点是前端校验。有时浏览器或前端代码在上传文件过大时会主动中止请求，造成413假象。建议在前端用JavaScript提前检查文件大小，超过预期就直接提示，避免无效上传。同时检查Flask视图函数是否正确处理request.files，不要误用request.data。如果使用了Flask-WTF或Flask-Uploads等扩展，也要查看其默认限制是否覆盖了MAX_CONTENT_LENGTH。排查时从日志入手，按nginx → WSGI → Flask → 前端的顺序确认，每一步调整后都重启服务并测试，最后再看上传接口的响应头和错误详情。