sub_filter本身无显著延时，其开销源于配置不当引发的缓冲、解压或阻塞；需对齐Nginx流式处理机制，合理配置缓冲、禁用上游压缩、精简替换规则并严格限定作用域。
sub_filter 本身不引入显著延时，它在响应体流式处理阶段完成内存内字符串替换，开销极低。所谓“明显延时”通常不是 sub_filter 自身导致，而是配置不当引发的缓冲、解压或阻塞行为。关键在于让替换过程与 Nginx 默认高效流式处理机制对齐，而非对抗它。
确保响应体可被完整、及时读取
sub_filter 需要完整的响应体片段才能匹配替换，若后端采用分块传输（chunked）且未设 Content-Length，Nginx 可能只处理首块内容，后续替换失效或不完整——这会迫使 Nginx 缓冲更多数据，拖慢首字节时间（TTFB）。
- 推荐启用 proxy_buffering on（默认即开启），并适当调大缓冲区：
proxy_buffers 8 128k;、proxy_buffer_size 256k;，确保常见 HTML/JSON 响应能一次性进入缓冲区参与替换 - 避免盲目关闭缓冲：
proxy_buffering off虽看似“流式”，实则可能因频繁小块处理反而增加上下文切换开销，且 sub_filter 在无缓冲时更易漏匹配 - 若后端可控，建议其返回紧凑格式（minified JSON/HTML）并显式设置
Content-Length，减少 Nginx 推断开销
绕过 gzip 压缩带来的解压瓶颈
sub_filter 只作用于明文响应体。若上游返回 gzip 编码，而 Nginx 未解压，替换直接跳过；若启用 gunzip on，则需额外 CPU 解压——这才是延时主因。
- 最优方案：在代理请求头中禁用压缩，让上游返回明文：
proxy_set_header Accept-Encoding ""; - 次选方案：仅对确需替换的 location 启用
gunzip on，并确认 Nginx 已编译--with-http_gunzip_module；避免全局开启 - 切勿同时启用
gzip on和gunzip on，会造成重复压缩/解压循环
精简替换逻辑，避免递归与冗余扫描
每条 sub_filter 指令都会对响应体做一次线性扫描。多条规则叠加、尤其开启 sub_filter_recursive on，可能引发重复遍历甚至无限循环，显著拖慢响应。
- 一条指令解决一类问题：例如用
sub_filter 'src="/static/' 'src="/cdn/';替代多条针对 js/css/img 的单独规则 - 禁用递归：
sub_filter_recursive off（默认值），除非明确需要“替换结果再触发新匹配”，否则绝不开启 - 避免在高频接口（如 API）上对 application/json 做宽泛替换；改用带上下文的精准模式，如
sub_filter '"avatar":"https://api.old.com/' '"avatar":"https://cdn.new.com/';
合理复用与作用域控制
sub_filter 必须写在 location 块中，但不必每个路径都重复配置。错误地在根 location 下无差别启用，会让所有响应（包括二进制文件、404 页面）都走一遍文本扫描，徒增负担。
- 按需启用：只为 text/html、application/json 等明确需改写的类型配置，用
sub_filter_types严格限定，例如：sub_filter_types text/html application/json; - 集中管理：将通用规则抽成独立文件（如
/etc/nginx/conf.d/sub.conf），在特定 location 中include，避免分散维护和误配 - 排除非文本响应：对已知静态资源（.jpg/.pdf/.woff2）或错误页面，使用更具体的 location 匹配并显式关闭替换：
sub_filter "" "";或直接不配置 sub_filter
