sub_filter_once 不适合全局注入，因其仅替换首次匹配内容、无法处理html压缩与大小写变化、且纯字符串匹配易破坏语义；应关闭sub_filter_once，结合精准锚点、转义处理及csp等加固措施实现稳定注入。
在 Nginx 负载均衡层通过 sub_filter_once on 注入监控脚本是可行的，但需谨慎设计——它仅替换响应体中**第一次匹配到的内容**，不适合注入多处或动态位置的脚本。真正可靠的做法是结合 sub_filter 的全局替换能力与 HTML 结构特征，而非依赖 sub_filter_once。
为什么 sub_filter_once 不适合“全局注入”
sub_filter_once on 表示每个响应只做一次替换（默认值），例如：
- 若页面含多个
，它只在第一个位置插入脚本； - 若 HTML 压缩后无换行、
被写成或大小写混用，替换会失败； - 它不感知 HTML 语法，纯字符串匹配，无法保证插入位置语义正确（如误插在
<script></script>标签内）。
推荐方案：用 sub_filter 实现稳定注入
关闭 sub_filter_once（即设为 off），配合精准锚点和转义处理：
- 定位
前插入（最常用且安全）：sub_filter '' '<script src="https://cdn.example.com/trace.js"></script>';<br> sub_filter_once off;
- 启用
sub_filter_types text/html，确保只处理 HTML 响应； - 若后端返回压缩 HTML，需先解压（加
gunzip off;或由后端统一不压缩）； - 对特殊字符做转义：脚本 URL 中的
&写成&，避免被 Nginx 解析为参数分隔符。
生产环境必须做的加固措施
直接注入脚本存在风险，需配套控制：
-
按域名/路径条件启用：用
map或if控制是否开启 sub_filter，避免测试环境也被注入； -
设置 CSP 兼容性：确保
Content-Security-Policyheader 允许加载对应域名的脚本（如script-src 'self' https://cdn.example.com;）； -
添加版本哈希或时间戳：防止浏览器缓存旧版监控脚本，例如
trace.js?v=20240520； -
监控替换成功率：通过日志检查
$sent_http_content_length变化，或用自定义 header（如add_header X-Trace-Injected "1";）验证是否生效。
替代更健壮的方案（建议长期采用）
若需更高可靠性与灵活性，可考虑：
- 后端模板统一注入：比负载均衡层更可控，支持环境变量判断、异步加载、错误降级；
- Service Worker 注入：适用于 SPA，可拦截所有页面请求并动态注入脚本，但不兼容低版本浏览器；
- 边缘计算方案（如 Cloudflare Workers / AWS CloudFront Functions）：支持 JS 编程式修改 HTML，可解析 DOM、智能插入、容错处理。
