Nginx中访问example.com/shift，选反向代理还是301重定向？

先明确两种方案的核心差异：

• 反向代理：浏览器地址栏始终显示https://example.com/shift，由你的Nginx服务器后台请求CloudFront上的内容，再返回给用户
• 301重定向：浏览器直接跳转到https://newDomain.com/shift，地址栏URL会同步变更

选择反向代理的场景 #

• 要维持品牌统一性：用户全程看到的都是主域名example.com，不会感知到newDomain.com的存在，强化品牌认知
• 需保留主站流量权重：反向代理不会让搜索引擎将/shift路径的权重分流到新域名，所有流量和SEO权重都集中在主站
• 需要额外处理请求/响应：比如要修改页面内容、添加自定义HTTP头、做IP访问限制等，Nginx反向代理层可以直接实现这些需求

反向代理注意事项 #

• 确保Nginx能正常访问CloudFront站点，配置时需正确设置proxy_pass，并开启proxy_ssl_server_name on以适配CloudFront的SSL配置
• 反向代理会增加主站服务器的带宽和处理压力，所有/shift请求都需经过Nginx中转

选择301重定向的场景 #

• 想降低主站负载：301重定向仅返回跳转响应，用户后续直接访问CloudFront，主站无需承担中转流量的压力
• 计划逐步迁移服务：如果/shift对应的服务未来会完全转到newDomain.com，301重定向可以引导用户习惯新域名，方便后续主站下线该路径
• 追求配置简洁：301的Nginx配置比反向代理更简单，出错概率低，后续维护成本更小

301重定向注意事项 #

• 301是永久重定向，搜索引擎会将https://example.com/shift的权重转移到新域名路径，若未来需改回主站，权重恢复需要一定时间
• 需确保newDomain.com/shift的内容与主站预期展示的完全一致，用户会直接访问新域名内容

配置示例 #

反向代理配置

location /shift {
    proxy_pass https://newDomain.com/shift;
    proxy_set_header Host newDomain.com;
    proxy_ssl_server_name on;
    # 可选：传递用户真实IP到CloudFront
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

301重定向配置

location /shift {
    return 301 https://newDomain.com/shift$request_uri;
}

内容的提问来源于stack exchange，提问作者Adriel M