nginx 301重定向的核心目标是完整、稳定、无损seo权重地将旧域名所有请求跳转至新域名对应路径；需确保新旧域名均解析到位且新站https可用，推荐用return指令配合$request_uri实现全量跳转，避免rewrite+if陷阱，并通过nginx -t和curl测试验证。
域名解析变更时，Nginx 301 重定向的核心目标是：让旧域名的所有访问请求，**完整、稳定、无损 SEO 权重地跳转到新域名对应路径**。这不是简单加一条规则，而是要覆盖所有可能入口，避免漏跳、循环、参数丢失或协议/端口异常。
确保新旧域名都可被 Nginx 正确识别
在配置重定向前，必须确认两件事：
- 旧域名（如 old.com）已解析到当前服务器 IP，且 Nginx 中有对应的
server_name old.com www.old.com - 新域名（如 new.com）也已解析到位，并已有独立、可用的 HTTPS 站点配置（含有效证书）
如果只配了重定向但新域名没部署好，用户会跳到一个无法打开的页面——这比不跳更伤用户体验和搜索排名。
用 return 指令做全量 301 跳转（推荐）
这是最简洁、高效、不易出错的方式，适用于绝大多数域名迁移场景：
- 在旧域名的
server块中（监听 80 和/或 443），使用return 301直接跳转 - 务必带上
$request_uri，保证路径和查询参数原样传递 - 示例配置：
listen 80;
server_name old.com www.old.com;
return 301 https://new.com$request_uri;
}
若旧站还支持 HTTPS，也需为 443 端口单独配一个 server 块（即使证书已过期，只要能响应 301 即可）：
server {listen 443 ssl;
server_name old.com www.old.com;
ssl_certificate /dev/null; # 可临时用占位证书或忽略验证
ssl_certificate_key /dev/null;
return 301 https://new.com$request_uri;
}
避免 rewrite + if 的组合陷阱
很多老教程用 if ($host = old.com) { rewrite ... permanent; }，这种写法存在明显风险：
-
if在 location 外使用属于“危险上下文”，Nginx 官方明确不推荐 - 容易因多层嵌套或变量作用域问题导致跳转失败或循环（比如跳到
https://new.com/https://new.com/...） - rewrite 的
permanent标志虽等效于 301，但底层仍走重写引擎，性能与语义清晰度不如return
除非你要做路径级精细映射（如 /blog/xxx → /articles/xxx），否则无需 rewrite；域名级整体迁移，return 是唯一推荐方案。
检查并上线前必做三件事
-
语法检测：运行
nginx -t，确认无报错 -
真实测试：用
curl -I http://old.com/some/path?k=v查看返回是否为301，Location头是否准确（应为https://new.com/some/path?k=v） - 关闭旧站服务（可选但建议）：重定向生效后，可停掉旧域名的 PHP、数据库等后端服务，只留 Nginx 响应 301，降低资源占用和安全面
