用 return 301 指令是最简洁、高效的方式，nginx 在连接处理早期就直接响应，不走 rewrite 流程，性能好且语义明确，适合生产环境的域名迁移；需在 server 块中设旧域名、用 https://new.com$request_uri 强制跳转并保留路径参数，支持多域名合并配置，配置后须 nginx -t 检查并 reload，再用 curl -i 验证 301 响应头和 location 正确性。
用 return 301 指令是最简洁、高效的方式，Nginx 在连接处理早期就直接响应，不走 rewrite 流程，性能好且语义明确，适合生产环境的域名迁移。
基础配置：单旧域名跳转到新域名
在 Nginx 配置中新建一个 server 块，监听 80 端口，绑定旧域名，并用 return 301 发起跳转：
-
server_name必须设为要跳转的旧域名（如old.com或www.old.com） - 推荐使用
https://new.com$request_uri，确保协议强制为 HTTPS（避免$scheme在 HTTP 请求下仍跳 HTTP） -
$request_uri会完整保留原始路径和查询参数，例如/about?ref=abc→https://new.com/about?ref=abc
示例：
server {listen 80;
server_name old.com www.old.com;
return 301 https://new.com$request_uri;
}
多旧域名统一跳转到一个新域名
多个需要废弃的域名可以合并写在一个 server 块里，节省配置和匹配开销：
- 把所有旧域名用空格分隔写在
server_name后面 - Nginx 会自动匹配任意一个命中即执行跳转，无需重复写多个
server块 - 适用于品牌整合、收购后域名归并等场景
示例：
server {listen 80;
server_name old1.com www.old1.com old2.net;
return 301 https://main.com$request_uri;
}
HTTPS 场景下的注意事项
如果旧站本身也支持 HTTPS，需单独配置 443 端口的 server 块：
- 必须配置有效的 SSL 证书（
ssl_certificate和ssl_certificate_key） - 同样使用
return 301 https://new.com$request_uri，不建议混用$scheme，防止跳回 HTTP - 若旧站无 HTTPS 能力，只需配 80 端口即可，用户访问
https://old.com会因证书错误或连接失败而自然失效，无需额外处理
验证与生效
配置完成后需实际验证效果，不能只看语法是否正确：
- 运行
nginx -t检查配置语法 - 执行
nginx -s reload重载配置（不中断服务） - 用
curl -I http://old.com/test查看响应头，确认返回HTTP/1.1 301 Moved Permanently及正确的Location头 - 浏览器访问测试路径，检查跳转是否保留参数、是否出现循环、是否跳到预期地址
