应将 rewrite 仅限于 location 块内使用，避免在 server 或 http 块中滥用 if + rewrite；正确做法是用精确匹配的 location 捕获路径并配合 break 重写，或通过 try_files + named location 实现可控分支，确保指令继承链不中断。
避免在 Nginx 基础架构定义中误用全局重写，关键在于理解重写（rewrite）不是“配置继承”行为，而是**请求路径的主动干预动作**——它一旦触发，就会改变 URI，并可能绕过原本依赖 location 层级结构形成的路由继承逻辑。所谓“实例路由无法被正常继承”，本质是重写后的新 URI 脱离了原设计的 location 匹配链路，导致后续指令（如 proxy_pass、root、add_header）不再按预期生效。
不把 rewrite 放在 http 或 server 顶层
rewrite 指令只应在 location 块内使用。http 或 server 块中直接写 rewrite 是非法语法（Nginx 启动会报错），但更隐蔽的问题是：有人试图在 server 块开头用 if + rewrite 模拟“全局重写”，这极易破坏 location 的匹配优先级。
- if 在 server 块中属于“非标准上下文”，其内部 rewrite 行为不受 location 路由控制，容易与后续 location 冲突
- 例如：
if ($request_uri ~ ^/old/(.*)$) { rewrite ^/old/(.*)$ /new/$1 last; }—— 此时 /new/xxx 可能跳过本应处理它的 location /new/，而落入更宽泛的正则 location 中 - 正确做法：用独立、精确的 location 捕获原始路径，再用 rewrite + last 转发到另一个明确隔离的 location
用 location 分区代替“全局意图”的重写逻辑
所谓“实例路由继承”，实际依赖的是 location 块的嵌套关系和匹配顺序。想让某类路径统一处理，不应靠 rewrite “拉平”，而应靠 location 结构“收口”。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 把入口路径（如 /v1/、/legacy/）用
^~或=精确匹配，确保只进一次 - 重写目标路径（如 /api/、/backend/）用单独的 location 定义，且内部不包含任何 rewrite
- 示例：
location ^~ /legacy/ { rewrite ^/legacy/(.*)$ /api/$1 break; }+location ^~ /api/ { proxy_pass http://svc; }—— break 避免重启匹配，break 后直接走 /api/ 块内 proxy_pass
警惕 rewrite last 对继承链路的“重置效应”
last 不是跳转，是用新 URI **重新走一遍 server → location 匹配全流程**。这意味着：父块中定义的 add_header、proxy_set_header、甚至 root，都不会自动带到新匹配的 location 中——它们属于原 location 上下文，而 last 已经退出该上下文。
- 如果重写后 URI 进入另一个 location，那个 location 必须显式声明所有需要的指令（如 add_header ... always、proxy_set_header）
- 尤其注意 error_page、try_files 触发的 internal 重定向，同样会丢失原 location 的头和代理设置
- 不要指望 server 块里配了 proxy_set_header X-Real-IP $remote_addr 就能在所有 rewrite 后的 location 中生效；每个最终承接请求的 location 都得自己写
用 try_files + named location 替代复杂 rewrite 链
当需要多层路径判断（比如先查静态文件、再 fallback 到 API），用 try_files 比嵌套 rewrite 更清晰、更可控，也天然规避继承断层问题。
-
try_files $uri @api;→ 匹配成功走当前 location，失败才进 @api，上下文保持连贯 - @api 是 internal location，仍处于同一 server 块作用域，server 级的 add_header、proxy_set_header 默认可用（除非该 @ 块自己定义了 add_header）
- 相比
rewrite ... last;触发全新 location 匹配，try_files 是“流程内分支”，不中断指令继承链
