nginx原生不支持动态修改响应体，需依赖sub_filter（轻量字符串替换）或lua（正则、json解析等复杂逻辑）实现；必须禁用压缩、显式声明mime类型、合理配置缓冲与替换范围。
可以在 Nginx 代理层对后端响应内容做二次过滤，但必须明确：Nginx 原生不支持动态修改响应体，需依赖特定模块或扩展机制实现。核心思路是“在响应发往客户端前拦截、解析、改写”，不同复杂度对应不同方案。
用 sub_filter 做轻量级字符串替换
适合替换 HTML、JSON、CSS 等纯文本中的固定字符串（如域名、路径、文案），无需编译额外模块，Nginx 1.9.4+ 默认可用。
- 必须禁用响应压缩：在 location 中添加 proxy_set_header Accept-Encoding ""，并确认后端不返回
Content-Encoding: gzip，否则 sub_filter 会跳过处理 - 显式声明可处理的类型：sub_filter_types text/html application/json text/css text/javascript；默认只处理
text/html - 全局替换需关闭单次限制：sub_filter_once off
- 示例：把后端返回的所有
api.old.com换成api.new.com
用 Lua 脚本实现灵活内容改写
当需要正则匹配、条件判断、JSON 字段提取或大小写不敏感替换时，OpenResty（含 lua-nginx-module）是最实用的选择。
- 在
body_filter_by_lua_block中操作响应体，注意缓冲策略：小响应可用eof判断一次性处理；大响应需流式处理避免内存溢出 - 支持调用
string.gsub、cjson.decode等，例如将 JSON 中所有"error_code": 500统一改为999 - 需确保 proxy_buffering on 且缓冲区足够（如
proxy_buffers 8 64k），否则 body_filter 可能收不到完整 chunk
过滤/隐藏响应头比改写内容更常用也更安全
很多场景下真正需要的不是改内容，而是控制哪些头信息暴露给客户端或透传给后端。
- 用 proxy_hide_header 屏蔽敏感头，如
Server、X-Powered-By、自定义调试头 - 用 proxy_ignore_headers 阻止上游设置的控制类头生效，如
X-Accel-Redirect、X-Accel-Limit-Rate、Set-Cookie（影响缓存） - 若后端返回了
Content-Encoding: gzip但你又必须过滤内容，可考虑在 Nginx 层先解压（需 lua-zlib）再处理，但会增加 CPU 开销
绕过限制的务实建议
遇到压缩响应无法过滤、二进制内容不支持、或逻辑过于复杂时，不硬扛 Nginx 层，可换更可控的前置方式。
- 在后端服务中统一注入占位符（如
{{API_HOST}}），由 Nginx 用 sub_filter 替换——规避编码与压缩问题 - 部署轻量级中间代理（如 Envoy + WASM、或 Node.js 微服务），专责响应改写，Nginx 仅负责路由和负载
- 对 JS/CSS 等静态资源，直接在构建阶段完成替换（如 Webpack DefinePlugin），比运行时过滤更稳定高效
