核心是让301跳转逻辑与后端状态解耦，固化在统一入口层（如前置Nginx或SLB），主备配置完全同步、目标写死、$request_uri完整保留，并通过多路径验证确保切换前后响应一致。
在主备高可用架构切换时保持 Nginx 的 301 重定向策略，核心不是“改配置”，而是让跳转逻辑与后端服务状态解耦——即无论当前是主节点还是备节点在提供服务，用户访问旧域名或旧路径时，都必须稳定、一致地收到 301 响应，且 Location 正确指向新地址。
这要求跳转规则不依赖于后端健康检查、upstream 变量或运行时判断，而应固化在流量入口层（通常是前置 Nginx 或负载均衡器），并确保主备节点配置完全同步。
以下是关键实践要点：
跳转逻辑必须部署在统一入口层，而非应用服务器上
主备切换通常发生在应用层或数据库层，但 301 跳转属于“URL 映射策略”，应由最外层的反向代理承担：
- 若使用 LVS + Nginx 主备，跳转配置写在两台 Nginx 的 server 块中，且内容完全一致
- 若用云厂商 SLB（如阿里云 CLB、腾讯云 CLB），可将 301 规则配置在 SLB 的 HTTP 重定向策略中（支持固定返回 301 + Location）
- 避免把 return 301 放在 upstream 后的应用 Nginx 中——一旦主节点宕机、流量切到备节点，若备节点未同步该配置，就会漏掉跳转，导致用户看到 404 或错误内容
主备节点的 Nginx 配置需强制统一且自动同步
- 所有跳转规则（如 old.com → new.com）应抽离为独立文件（如
/etc/nginx/conf.d/redirects.conf） - 使用 Ansible / SaltStack / rsync 等工具，在主节点更新后自动推送到备节点，并触发
nginx -t && nginx -s reload - 不推荐手工复制；一次遗漏就可能造成备机上线后跳转失效
避免在跳转中引用动态变量或后端状态
以下写法危险，主备切换时易出错：
- ❌
return 301 https://$host$request_uri;（$host 来自请求头，可能被篡改，且主备共用时无法控制目标） - ❌
if ($upstream_status != 200) { return 301 ... }（if + return 在 location 外不可靠，且违背“永久跳转”语义） - ✅ 正确做法：
return 301 https://new.com$request_uri;—— 目标写死，协议固定，路径完整保留
主备切换期间仍需保障 HTTPS 跳转可用
若旧域名曾支持 HTTPS，则主备 Nginx 的 443 server 块都必须：
- 配置相同的 SSL 证书（建议用 ACME 自动续签，并同步证书文件）
- 包含独立的
listen 443 ssl;块和return 301 https://new.com$request_uri; - 不要复用新站的 443 server 块——旧域名证书和新站证书通常不同，混在一起会导致 SSL 握手失败
验证方式要覆盖主备双路径
上线前及每次切换演练后，必须分别验证：
- 直接访问主节点 IP + 旧域名（如
curl -I http://<master-ip>/old-page） - 直接访问备节点 IP + 旧域名（确认配置已同步）
- 通过 VIP 或 SLB 地址访问（模拟真实用户路径）
- 每次均检查响应头：
HTTP/1.1 301 Moved Permanently和Location: https://new.com/...是否准确，参数是否完整
不复杂但容易忽略。
