sub_filter不能替换动态生成的敏感字段，因其仅对后端返回的原始响应体做字面量字符串替换，不解析HTML、不执行JS、不处理响应头、不支持正则、无法应对gzip压缩或JSON转义差异，且要求目标字符串必须以完全一致的明文形式存在。
为什么 sub_filter 不能直接替换动态生成的敏感字段
因为 sub_filter 是纯文本流式替换，不解析 HTML 结构，也不执行 JavaScript；它只在 Nginx 将响应体（response body）逐块写入输出缓冲区时做简单字符串查找与替换。如果敏感信息由前端 JS 渲染（比如从 data-user-id 属性或 API 响应中动态插入），sub_filter 完全看不到——它处理的是后端吐出的原始 HTML 文本，不是浏览器最终渲染结果。
常见误判场景包括：sub_filter "api_key=xxx" ""; 失效（因实际响应中是 api_key: "${env.API_KEY}" 或经 JS 拼接）、JSON 响应里嵌套字段未被匹配（因换行/空格/引号格式不一致）、gzip 压缩后内容不可见（sub_filter 不解压）。
- 必须确保目标字符串在原始响应体中以**字面量形式完整存在**，且编码一致（如 UTF-8 不含 BOM）
- 启用前务必用
curl -H "Accept-Encoding: identity" http://host/path抓取未压缩响应，确认要过滤的字符串确实存在 - 若后端返回 JSON，需注意双引号、转义符（如
"token":"abc\ndef"），sub_filter不做转义还原
sub_filter 替换 JSON 中的敏感键值对要加 sub_filter_once off
默认 sub_filter_once on 只替换每个响应中第一次出现的匹配项。而 JSON 响应常含多个同名字段（如用户列表中每个 user 对象都有 "phone" 字段），仅替换首个会导致漏过滤。
正确做法是关闭单次限制，并严格对齐 JSON 键值格式：
location /api/ {
proxy_pass http://backend;
sub_filter '"phone":"[^"]*"' '"phone":"[REDACTED]"';
sub_filter_once off;
sub_filter_types application/json;
# 注意：正则语法不被支持，此处为示意；实际只能用字面量
}⚠️ 实际无法用正则！sub_filter 只支持固定字符串。所以真正可行的是：
- 后端统一用固定占位符，如
"phone":"__REDACTED_PHONE__"，再用sub_filter "__REDACTED_PHONE__" "[REDACTED]" - 或前端请求时加
X-Redact: phone,email头，后端根据该头主动脱敏（更可靠） -
sub_filter_types必须显式包含application/json，否则默认只处理text/html
开启 sub_filter 后页面错乱？检查 Content-Encoding 和 Content-Length
当响应被 gzip 压缩（Content-Encoding: gzip），sub_filter 无法工作——它只处理明文响应体。此时要么禁用压缩，要么让后端不压缩敏感接口。
另一个隐蔽问题是 Content-Length：Nginx 替换后响应体长度变化，但若后端已预设了 Content-Length 头，Nginx 不会自动重算（除非启用 underscores_in_headers on 并手动清除）。浏览器可能截断或报解析错误。
- 强制清除原始长度头：
proxy_hide_header Content-Length; - 禁用压缩：
proxy_set_header Accept-Encoding ""; proxy_http_version 1.0; - 若必须压缩，改用
ngx_http_substitutions_filter_module（第三方模块，支持正则和多轮替换，但需编译安装）
敏感信息藏在 HTTP 响应头里？sub_filter 完全无效
sub_filter 只处理响应体（body），对响应头（headers）完全无感知。像 X-Debug-Info、X-Powered-By、甚至 Set-Cookie 中的 session_id，都无法用它过滤。
这类信息必须用其他机制：
- 用
proxy_hide_header X-Debug-Info;直接屏蔽整个头 - 用
more_set_headers "X-Status: ok";（需headers-more-nginx-module）覆盖或重写头 - Cookie 脱敏需后端控制
HttpOnly/Secure标志，或 Nginx 用map+add_header Set-Cookie重写（复杂且易出错，不推荐）
真正关键的泄露点往往不在 HTML 里，而在开发者忘记删的调试头、未关闭的源码映射（sourceMap）、或后端日志直出到响应体——这些都得靠流程卡点，不是靠 sub_filter 能兜底的。
