sub_filter_types指令用于扩展sub_filter的作用范围至非text/html类型，需显式配置如application/json等MIME类型，支持通配符如text/，但不可设为；须与sub_filter同作用域，且响应不能压缩。
Nginx 的 sub_filter_types 指令用于扩展 sub_filter 的作用范围，使其不仅作用于默认的 text/html 响应，还能处理其他 MIME 类型（如 JSON、XML、CSS、JS 等）的内容替换。
sub_filter_types 的基本用法
默认情况下，sub_filter 只对响应头中 Content-Type 为 text/html 的内容生效。要让它也处理其他类型，必须显式配置 sub_filter_types，并列出允许的 MIME 类型。
- 该指令必须放在与
sub_filter相同的作用域（如http、server或location块）内 - 支持通配符，例如
application/*或text/* - 若设置为
*（带空格），Nginx 会报错；正确写法是明确列出或使用通配符（如text/* application/json）
常见需要替换的非 HTML 类型及配置示例
实际场景中，常需在 API 返回的 JSON 中替换域名、路径或调试标识，或在内联 JS/CSS 中修正资源引用：
-
JSON 接口内容替换：添加
application/json到sub_filter_types，再配合sub_filter替换 URL 或占位符 -
内联 JavaScript 修改：加上
application/javascript或text/javascript（注意 Nginx 1.19+ 推荐用前者） -
XML 或 SVG 响应：添加
application/xml或image/svg+xml
示例配置：
location /api/ {
proxy_pass http://backend;
sub_filter '"https://old.example.com"' '"https://new.example.com"';
sub_filter_types application/json application/javascript text/css;
sub_filter_once off;
}注意事项与限制
sub_filter 是流式处理，不缓存完整响应体，因此对大文件或分块传输（chunked）响应仍有效，但有几点必须留意：
- 响应必须是未压缩的（即不能启用
gzip或brotli），否则sub_filter无法解析明文内容 -
sub_filter_types不影响Content-Encoding，只匹配Content-Type响应头 - 若后端返回了
Content-Type: text/plain但实际是 JSON，需在 Nginx 中用add_header Content-Type application/json;覆盖，才能触发替换 -
sub_filter_once off表示全局替换（不止首次匹配），搭配多类型时建议开启
验证是否生效的方法
最直接的方式是用 curl -I 查看响应头中的 Content-Type，再用 curl -s 获取实际响应体，确认替换结果：
- 检查 Nginx error log 是否有
sub filter: type not allowed类警告（说明类型未包含在sub_filter_types中） - 临时关闭 gzip：
gzip off;，避免干扰 - 用
tcpdump或浏览器开发者工具 Network 面板确认响应原始内容和最终渲染效果是否一致
