nginx rewrite规则不生效主因是执行顺序混乱：server块内rewrite在location匹配前执行，location内rewrite在匹配后执行，且last会触发uri重匹配，break则终止匹配；location优先级为= > ^~ > 正则 > /，高优规则可能截断低优rewrite。
rewrite规则不生效，八成不是正则写错了，而是执行顺序没理清。Nginx的rewrite不是“写了就跑”，它严格按阶段和位置执行：server块里的先跑，location匹配完再跑里面的，改完URI还可能触发新一轮匹配。顺序一乱，规则就被跳过、覆盖，甚至无限循环。
看 rewrite 是写在 server 还是 location 里
这是最基础也最容易忽略的一点。server 块中的 rewrite 在 location 匹配前执行，会直接影响后续走哪个 location；location 块内的 rewrite 则只在该 location 被选中后才运行。比如：
- 你写了
rewrite ^/old/(.*)$ /new/$1 last;在 server 块里 → 请求 /old/123 会先被重写成 /new/123，然后重新匹配 location - 如果这条规则写在
location /old/ { ... }里面 → 只有 URI 确实以 /old/ 开头才会触发，且重写后仍留在这个 location 内（除非用 last） - 错误示范：
rewrite ^/(.*)$ /api/$1 break;放在 server 块开头 → 所有请求都被强行改路径，/api/ 之外的 location 全部失效
检查 location 匹配是否被更高优先级规则截断
Nginx 不按配置文件书写顺序选 location，而是按匹配优先级硬性排序：
-
= /exact：完全相等，最高优先 -
^~ /prefix：前缀最长即胜出，命中后立刻停止，不查正则 -
~ \.php$或~* \.jpg$：按配置中出现顺序逐条试，首个匹配即停（但前提是 = 和 ^~ 都没中） -
/：兜底，最低优先
典型陷阱：你在文件末尾写了 location ~ \.js$ { rewrite ... }，但前面有个 location ^~ /static/ ——那么 /static/app.js 根本不会进正则块，rewrite 自然不执行。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
验证 rewrite 后有没有触发新 location 匹配
关键看 flag：
-
last：改完 URI 后，立即用新 URI 重新走一遍 location 匹配流程（相当于内部跳转） -
break：改完 URI 就停，继续在当前 location 内执行后续指令（比如 proxy_pass） -
redirect/permanent：发 302 或 301 给浏览器，地址栏会变，不涉及内部匹配
如果你期望 rewrite 后交给另一个 location 处理，却用了 break，那新 URI 就卡在原 location 里了——proxy_pass 可能转发错路径，root 可能指向错目录，结果就是 404 或内容异常。
用 nginx -T 确认实际生效的配置顺序
别信磁盘上的 conf 文件，要看 Nginx 当前内存里加载的是什么：
- 执行
nginx -T | grep -A 5 "rewrite\|location"，观察 rewrite 指令真实所处的位置（server 还是某个 location 下） - 对照输出，确认你写的 rewrite 是否被 include 的其他配置覆盖，或被 if 块包裹导致未满足条件
- 特别注意：if 块里的 rewrite 是独立作用域，且 if 在 location 中使用本身就有诸多限制（比如不能嵌套、不支持 && ||），容易误判条件是否成立
