Nginx正向代理本身不处理字符集转换，其对多语言的支持依赖客户端、服务器及传输过程的编码一致约定；关键在于禁用sub_filter等破坏性模块、不强制改写charset、确保body大小足够、正确透传Host与路径，并启用proxy_connect支持HTTPS隧道。
Nginx 本身不处理字符集编码转换，也不主动解析或修改请求/响应体中的多语言内容（如 UTF-8、GBK、Big5 等）。正向代理的核心职责是转发 HTTP/HTTPS 请求与响应，保持原始字节流不变。因此，“支持多语言字符集”不是靠 Nginx 配置字符集参数实现的，而是依赖客户端、目标服务器和传输过程三方对编码的一致约定与正确处理。
正向代理对多语言字符集的实际影响
只要客户端发送的请求头（如 Content-Type: text/html; charset=UTF-8）、URL 中的非 ASCII 字符（需已做 URI 编码）、以及响应体内容本身未被 Nginx 意外截断或篡改，Nginx 正向代理就能透明传递多语言数据。关键在于避免引入破坏性操作：
- 不启用
sub_filter或其他响应体重写模块——它们可能误解 UTF-8 多字节序列 - 不设置
charset指令强制改写响应头——这会覆盖源站真实声明的编码 - 确保
client_max_body_size足够大，避免因上传含中文/日文等大体积表单而被截断 - 禁用
underscores_in_headers off（默认关闭），防止某些带下划线的自定义头（如部分 SDK 使用）被丢弃
适配各类应用客户端的关键配置项
不同客户端（浏览器、curl、Postman、移动 App、企业 OA 客户端等）行为差异较大。正向代理需兼容其常见请求模式：
-
允许任意 HTTP 方法：部分客户端用
PATCH、OPTIONS或自定义方法，需放开限制if ($request_method !~ ^(GET|HEAD|POST|PUT|DELETE|CONNECT|PATCH|OPTIONS)$) { return 405; }→ 建议删掉或放宽 -
支持 CONNECT 方法（HTTPS 代理必需）：必须加载
ngx_http_proxy_connect_module，并显式启用proxy_connect;proxy_connect_allow 443 80; -
正确透传 Host 与原始请求路径：使用
$scheme://$host$request_uri而非硬编码地址，确保重定向、Cookie 域名、前端路由（如 Vue Router history 模式）正常工作 -
保留原始客户端 IP 可选但非必须：正向代理中目标服务器看到的是代理 IP；若需记录真实 IP，客户端应主动发送
X-Forwarded-For，代理可信任并透传（不建议伪造）
HTTPS 正向代理的特殊注意事项
客户端访问 HTTPS 网站时，实际先发 CONNECT host:443 建立隧道，之后所有流量为加密二进制流。Nginx 无法也不应解密或检查其中字符集：
- 必须使用支持 CONNECT 的编译模块（如 chobits 的
proxy_connect），官方 Nginx 不原生支持 - 隧道建立后，Nginx 仅做 TCP 层转发，UTF-8 / GBK 等完全由客户端和目标网站协商处理
- 浏览器地址栏显示
https://且锁图标正常，即表示隧道成功，字符集问题与代理无关
验证是否真正“支持多语言与多客户端”
不要只测网页，要覆盖典型场景：
- 用 curl 发送含中文参数的 GET 请求：
curl -x http://proxy:8080 "https://httpbin.org/get?name=张三" - 用 Postman 发送 UTF-8 编码的 JSON Body，检查响应中中文是否原样返回
- 用手机 App 访问含日文路径的 API（如
/api/記事一覧），确认 404 是否来自后端而非代理截断 - 上传含中文文件名的 multipart 表单，观察
Content-Disposition头是否完整透传
