Nginx 301重定向核心是保流量、护SEO，优先用return 301而非rewrite；按场景分server块配置，保留$request_uri传参，上线前须语法检测、curl验证、新站可用性检查。
明确跳转类型，选对指令
优先用 return 301，不用 rewrite（除非必须正则匹配路径）。
- return 301 是最轻量、最可靠的方式：不走 location 匹配、不触发 rewrite 循环、不依赖正则引擎，适合绝大多数迁移场景
- 比如全站换域名：
return 301 https://new-site.com$request_uri; - rewrite 只在需要路径变形时才用，例如
/article/123→/post/123，且必须加permanent标记，否则默认是 302
按迁移场景分 server 块配置
不要把所有跳转塞进一个 server 块里，否则容易冲突或漏判。
-
旧域名跳新域名：单独起一个监听 80 的 server 块，
server_name old.com www.old.com;，里面只写return 301 https://new.com$request_uri; -
HTTP 强制跳 HTTPS：在旧站的 80 端口 server 块中加
return 301 https://new.com$request_uri;，别在 443 块里再写跳转，否则可能循环 -
目录结构变化：如旧站
/blog/xxx全部移到新站/articles/xxx，可用 rewrite：rewrite ^/blog/(.*)$ https://new.com/articles/$1 permanent;
保留原始路径和参数，别丢 $request_uri
这是 SEO 友好的关键——搜索引擎和用户点击的带参数链接（如 ?ref=utm）必须完整传递过去。
- 正确写法：
return 301 https://new.com$request_uri;（含问号及之后全部） - 错误写法：
return 301 https://new.com/;或return 301 https://new.com$uri;（$uri 不含 query string） - 如果新站路径需过滤某些参数（如 utm_source），得用 map 或 rewrite + $args 控制，但一般迁移阶段建议先全量保留
验证与上线前必做三件事
配置完别急着 reload，先确认这三点：
- 运行
nginx -t检查语法，确保无报错（尤其注意分号不能漏） - 用 curl 测试真实响应：
curl -I http://old.com/some-page，看返回头是否为301 Moved Permanently且Location正确 - 检查新站是否已上线并能正常访问目标 URL，避免跳过去 404 —— 301 不解决内容缺失问题，只解决路径指向
