代理响应乱码主因是nginx未透传或覆盖后端content-type及charset声明；应禁用charset、default_type、add_header等指令，确保响应头原样透传，必要时用proxy_hide_header+add_header谨慎重写。
代理后响应内容乱码，通常不是编码被“改错”，而是 Nginx 没有透传或覆盖了后端返回的 Content-Type 和字符集声明（如 charset=utf-8），导致浏览器按错误编码解析。重点看响应头和原始字节流是否一致。
检查后端实际返回的 Content-Type 和 charset
用 curl -v http://localhost:59200/api/xxx 直连后端服务，观察响应头中是否有：
Content-Type: application/json; charset=utf-8- 或
text/html; charset=gbk等明确声明
如果后端没带 charset，Nginx 默认不会补，浏览器可能按 ISO-8859-1 或系统默认编码解析，造成中文显示为 或乱码。
确认 Nginx 是否无意覆盖了 Content-Type
检查配置中是否用了以下容易引发问题的指令：
-
charset utf-8;—— 全局强制设置，会覆盖后端的 charset，且对二进制响应（如图片、PDF）有害 -
default_type application/json;—— 错误指定类型，尤其当后端返回 HTML 或 XML 时 -
add_header Content-Type ...;—— 手动添加会覆盖原响应头（Nginx 1.13.5+ 默认覆盖，不可并存）
✅ 正确做法是：不设 charset 指令，也不手动加 Content-Type，让后端自己决定。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
验证代理是否透传了响应头
对比直连后端与走 Nginx 代理的响应头差异：
- 执行
curl -v http://localhost:22222/api/xxx（走 Nginx） - 执行
curl -v http://localhost:59200/api/xxx（直连后端） - 逐行比对
Content-Type、Content-Length、Transfer-Encoding
若发现代理后丢失 charset，大概率是后端本身未返回（需修复后端），或 Nginx 配置了 charset 强制干预。
特殊场景：后端不返回 charset，但内容确实是 UTF-8
如果确认后端稳定返回 UTF-8 编码字节，只是忘了写 charset=utf-8，可谨慎使用：
-
proxy_hide_header Content-Type;（先隐藏） -
add_header Content-Type 'application/json; charset=utf-8' always;（再重写，always确保对 200/404/500 都生效）
⚠️ 注意：只对明确知道响应类型的接口使用，避免误用于下载文件或图片。
