Nginx原生不支持响应体动态过滤替换，但可通过三种方案实现：1. 内置sub_module轻量文本替换（需禁用gzip）；2. OpenResty+Lua灵活流式处理；3. 外部服务代理过滤。均需注意Content-Length、编码及二进制内容限制。
在 Nginx 代理中直接对响应内容做动态过滤与替换，原生不支持（Nginx 本身不解析响应体），但可通过模块扩展或外部协作实现。核心思路是：拦截响应体、修改后返回。以下是几种实用、可落地的方案。
使用 ngx_http_sub_module（内置模块，轻量替换）
这是最常用且无需编译额外模块的方式（需确认 Nginx 编译时启用了 --with-http_sub_module，主流发行版通常默认开启）。
适用于简单文本替换，如修改 HTML 中的 URL、版权文字、调试标识等，不支持正则捕获、条件逻辑或二进制内容。
- 只能匹配并替换响应体中的字符串（区分大小写）
- 仅作用于
text/html、text/css、application/javascript等指定 MIME 类型（可通过sub_filter_types扩展） - 替换是流式进行的，不缓存整个响应体，内存友好
示例：将上游返回的 https://api.example.com 替换为 /api
location / {
proxy_pass https://backend;
sub_filter 'https://api.example.com' '/api';
sub_filter_types text/html text/css application/javascript;
sub_filter_once off; # 全局替换（默认只替换第一个）
proxy_set_header Accept-Encoding '';
}⚠️ 注意：proxy_set_header Accept-Encoding '' 是关键——禁用 gzip 可避免压缩导致 sub_filter 失效（因模块无法解压处理）。
启用 ngx_http_headers_more_module + Lua（灵活过滤与重写）
通过 nginx-lua-module（OpenResty 默认集成）配合 body_filter_by_lua_block，可在响应体流式传输过程中逐块读取、修改、输出，支持正则、条件判断、JSON 解析、甚至调用外部 API。
适合需要动态逻辑的场景：按用户身份过滤字段、脱敏敏感信息、注入埋点脚本、重写 JSON API 响应等。
- 需使用 OpenResty 或自行编译 Nginx + lua-nginx-module
- 使用
body_filter_by_lua_block拦截响应体 chunk（注意：需配合lua_need_request_body off和合理缓冲策略） - 建议搭配
set_by_lua_block预处理变量，避免在 body filter 中做耗时操作
示例：将 JSON 响应中的 "email" 字段值替换为 "[REDACTED]"（简化版，生产需更严谨的 JSON 流解析）：
location /api/ {
proxy_pass https://upstream;
proxy_buffering on;
proxy_buffers 8 128k;
proxy_busy_buffers_size 256k;
<pre class="brush:php;toolbar:false;">body_filter_by_lua_block {
local chunk = ngx.arg[1]
if chunk ~= "" then
-- 简单字符串替换（仅作示意；真实 JSON 处理建议用 cjson.safe_decode + encode）
local replaced = string.gsub(chunk, '"email":"[^"]*"', '"email":"[REDACTED]"')
ngx.arg[1] = replaced
end
}}
借助外部程序（如 Nginx 的 pipe + sed / Python 脚本）
利用 Nginx 的 post_action 或 auth_request 不适用此场景，但可通过 proxy_pass 到本地 FastCGI/SOCK 服务，由外部进程完成响应处理。更常见的是：用 Nginx 作为反向代理前端，后端用轻量服务（如 Python Flask + requests）做“带过滤的代理”。
优势：完全自由控制逻辑，易调试、可复用业务代码；劣势：增加延迟与运维复杂度，失去 Nginx 高并发优势。
- 适合规则复杂、需数据库查询或调用微服务决策的场景
- 推荐用异步框架（如 FastAPI + httpx）减少阻塞
- Nginx 配置只需
proxy_pass http://filtering_service，过滤逻辑全在后端
注意事项与避坑指南
无论选哪种方式，以下几点直接影响可用性：
-
Content-Length 头必须清除或重算：任何响应体修改都会使原有
Content-Length失效，Nginx 通常自动删除该头并启用 chunked encoding，但若上游强制设置且未透传，需显式proxy_hide_header Content-Length - 编码兼容性：确保原始响应是 UTF-8；非 UTF-8 内容（如 GBK）做文本替换易乱码，建议先转码或跳过处理
- 二进制响应慎用：图片、PDF、ZIP 等不可直接用 sub_filter 或简单字符串替换，否则损坏文件；如需处理，应基于 MIME type 严格限制作用范围
- 性能开销：Lua 方案在高并发下需注意内存分配和 GC；避免在 body filter 中做 IO 或 sleep；大响应体建议分块处理而非一次性读入
