Nginx重定向不生效主因是配置未重载或规则位置错误：需执行nginx -s reload或宝塔点“重载配置”，确保return/rewrite写在server块顶层而非location内，并用curl -I验证状态码。
配置改了但旧重定向还在生效，大概率不是规则写错了，而是新配置根本没加载进去。关键要确认 Nginx 是否真正应用了你刚写的规则。
先看配置有没有被实际加载
别只信“保存”按钮——宝塔或手动改完配置后，必须执行重载操作，否则还是跑的老配置。
- 在宝塔里：改完「重定向」或「配置文件」后，点右上角「重载配置」（不是重启 Nginx）
- 命令行下：运行 nginx -s reload，成功时无输出；失败会报错
- 验证是否生效：执行 nginx -T | grep -A3 "your_rule"，确认你写的 return 或 rewrite 确实出现在输出里，且位置正确（比如在 server 块顶层，不在 location 内）
检查规则是否被错误放置
很多重定向不跳转，是因为规则被塞进了 location 块里，Nginx 默认当内部重写处理，不发 301 状态码。
- 伪静态文本框里写的 rewrite，默认不加 permanent，只会内部转发，地址栏不变
- 正确写法应是：return 301 https://new-url.com$request_uri; 或 rewrite ^/old(.*)$ https://new-url.com$1 permanent;
- 这两条必须写在 server { } 块内、所有 location 之外，否则可能被 location ~ \.php$ 等块拦截跳过
排除浏览器和 worker 进程干扰
即使配置重载成功，你也可能看到“旧行为”，原因常来自客户端或旧进程残留。
- 301 会被浏览器强缓存，换无痕窗口或用 curl -I -H "Cache-Control: no-cache" https://example.com/old 测试真实状态码
- reload 后旧 worker 还在处理已有连接，尤其长连接（WebSocket、上传中请求），可能继续走旧逻辑长达几十秒
- 若急需立即生效，可临时设 worker_shutdown_timeout 15s;（放在 events 块），加快旧进程退出
快速验证是否真生效
别靠肉眼看页面跳没跳，用状态码说话。
- 执行 curl -I https://yoursite.com/old-path，看返回是不是 HTTP/2 301 或 HTTP/1.1 301
- 如果返回 200 或 404，说明重定向根本没触发，重点查重载动作和规则位置
- 如果返回 301 但跳转地址不对，再核对 rewrite 中的正则捕获和目标 URL 拼接
