sub_filter仅支持固定字符串替换，无法解析JSON结构；适用于URL前缀等已知格式的精确替换，需禁用gzip、指定MIME类型并确保不破坏JSON语法。
sub_filter 指令本身不支持直接解析或修改 JSON 内容，它只做原始字节流的简单字符串替换。但你可以在 Nginx 代理层用它“安全地”修正 JSON 响应体中已知格式的链接字段，前提是链接结构固定、可预测，且不破坏 JSON 语法。
明确 sub_filter 的能力边界
sub_filter 是正则无关的、逐块（buffer）处理的文本替换工具，对 JSON 这类结构化数据属于“无感知替换”。它不能：
- 识别 key 是否在字符串值里还是注释中
- 自动转义引号或处理嵌套对象中的同名字段
- 校验替换后 JSON 是否仍合法（比如漏掉引号、多出逗号）
所以必须确保替换内容严格匹配目标模式，且前后上下文稳定。
典型适用场景：统一修正 host 或协议前缀
例如后端返回：
{"avatar": "http://old.example.com/u/123.jpg", "cdn_url": "http://old.example.com/static/"}你想把所有 http://old.example.com 替成 https://cdn.new.site，且确认该域名只出现在 URL 值中、不作为其他字段名或普通文本出现。
Nginx 配置示例：
location /api/ {
proxy_pass https://backend/;
proxy_set_header Accept-Encoding "";
sub_filter 'http://old.example.com' 'https://cdn.new.site';
sub_filter_types application/json;
sub_filter_once off;
}
关键点：
- proxy_set_header Accept-Encoding ""：禁用 gzip，避免 sub_filter 无法处理压缩响应
- sub_filter_types application/json：显式启用对 JSON MIME 类型的过滤
- sub_filter_once off：允许多次替换（默认只换第一个匹配）
规避 JSON 格式风险的实操建议
为防止替换破坏 JSON 结构，推荐以下做法：
- 用带引号和斜杠的完整 URL 作匹配，比如 "http://old.example.com/（开头带双引号），比裸域名更安全
- 若需替换路径部分（如 /v1/ → /v2/），优先匹配带前后界定符的片段，例如 "\/v1\/ → "\/v2\/
- 配合 sub_filter_last_modified on 可让 Nginx 保留原响应的 Last-Modified 头（非必需但利于缓存）
- 上线前用 curl + python -m json.tool 验证响应是否仍为合法 JSON
不适合的场景及替代思路
遇到以下情况，sub_filter 就不该硬上：
- 链接字段名不固定（如有的叫 url，有的叫 link，有的叫 href）
- JSON 中混有用户输入内容，可能含相似字符串（如 description 字段里写了 “访问 http://old.example.com”）
- 需要根据请求头（如 Host、Cookie）动态决定替换目标
此时应考虑：
- 后端统一注入 CDN 域名（最可靠）
- 用 ngx_http_sub_module 的增强版（如 OpenResty 的 lua-resty-string + cjson 解析后重写）
- 前端 JS 在加载后遍历修正（适合非关键链接）
