Nginx 的 sub_filter 默认仅处理 text/html，需通过 sub_filter_types 显式扩展 MIME 类型（如 application/javascript、text/css、application/json 等）才能替换 JS/CSS/JSON 中的动态域名，并注意保留 text/html、精确匹配 Content-Type、禁用 gzip 等关键配置要点。
Nginx 的 sub_filter 默认只对 text/html 类型响应生效，若需在 JS、CSS、JSON 或其他文本类资源中替换动态域名（如将 http://localhost:3000 替换为 https://api.example.com），必须显式配置 sub_filter_types 指令来扩展 MIME 类型范围。
明确支持的 MIME 类型范围
sub_filter_types 用于声明哪些响应类型允许被 sub_filter 处理。它不继承父级配置，需与 sub_filter 同级或更内层作用域中设置。常见需启用的类型包括：
-
application/javascript（现代 JS 文件） -
text/css（样式表） -
application/json（API 响应或内联配置） -
text/plain（纯文本接口或调试输出） -
text/xml或application/xml（部分旧版配置）
避免常见配置陷阱
仅添加类型还不够，还需注意以下关键点：
-
必须保留
text/html：即使只处理 JS，也建议显式包含text/html，否则原始 HTML 中的替换会失效 -
响应头
Content-Type必须精确匹配：Nginx 不做 MIME 类型推断，application/json; charset=utf-8与application/json视为不同，建议用通配符application/*或完整列出带 charset 的变体（但 Nginx 本身不支持 charset 解析，推荐统一后端输出无 charset 的标准类型） -
gzip 压缩会阻断 sub_filter：确保
sub_filter生效前响应未被压缩，可在 location 中添加gzip off;或使用gzip_vary off;配合sub_filter（需 Nginx ≥ 1.11.6）
典型配置示例
以下配置在反向代理场景中，对 HTML、JS、CSS 和 JSON 响应统一替换本地开发域名：
location / {
proxy_pass https://backend;
proxy_set_header Host $host;
sub_filter 'http://localhost:3000' 'https://api.example.com';
sub_filter 'http://127.0.0.1:3000' 'https://api.example.com';
sub_filter_once off;
sub_filter_types text/html application/javascript text/css application/json;
gzip off;
}
注意：sub_filter_once off 启用全局多次替换；若资源含大量重复字符串，可考虑开启 sub_filter_last_modified on 避免缓存干扰。
验证是否生效的实用方法
直接检查响应头与内容：
- 用
curl -I查看Content-Type是否符合预期类型 - 用
curl -H "Accept-Encoding:"绕过 gzip，再配合grep检查替换结果 - 浏览器开发者工具中查看 Network → Response，确认目标字符串已更新且无双写（如
https://https://...） - 对 JSON 接口，注意引号和转义：替换值应保持合法 JSON 格式，避免破坏结构
