在Web服务运维中，重定向是最常用也最容易配错的功能之一。Nginx作为主流反向代理与Web服务器，提供了多种实现重定向的方式，而301与302这两个HTTP状态码决定了客户端如何看待这次跳转。如果只停留在“能跳过去就行”的层面，很可能在搜索引擎收录、浏览器缓存以及接口兼容性上埋下隐患。本文从语义定义、配置写法、缓存与SEO影响、实践选型四个角度，把两者的差异讲透。
一、HTTP语义层面的根本差异
301状态码在HTTP规范中被定义为“Moved Permanently”，意思是请求的资源已经被分配了新的永久URI，未来任何对该资源的引用都应当使用新地址。服务器在返回301时，实际上是在告诉客户端：旧地址已经作废，你可以把本地记录的链接、书签都改成新地址。对于爬虫来说，它会将旧页面的权重逐步迁移到新页面，旧URL最终会从索引中移除。
302状态码定义为“Found”或历史称呼“Moved Temporarily”，表示资源暂时可以从另一个URI访问，但客户端应当继续沿用原URI进行后续请求。它并不要求浏览器或爬虫更新收藏，也不承诺新地址会一直有效。在早期的HTTP/1.0中302可能导致部分浏览器把POST请求改成GET请求，后来RFC规范引入303和307来细分行为，但302依旧是最被广泛兼容的临时跳转码。
从协议角度讲，两者最核心的区别在于“永久性”与“临时性”的语义承诺。这个承诺直接影响中间节点（如CDN、代理）和终端（如浏览器）的缓存决策。如果一个本应临时的维护页面用了301，用户浏览器会永久记住错误地址；反之，本应永久迁移的站点用了302，SEO权重永远无法合并，旧站收录也清不掉。
二、Nginx中的具体配置与代码对照
在Nginx里实现301和302最常用的有两种手段：return指令和rewrite指令。使用return时，状态码由你显式写出，语义最清晰。下面给出两个最简配置，分别完成永久与临时跳转。
server {
listen 80;
server_name old.ippipp.com;
# 301永久重定向到新域名
location / {
return 301 https://new.ipipp.com$request_uri;
}
}
server {
listen 80;
server_name temp.ippipp.com;
# 302临时重定向，用于临时维护或AB测试
location / {
return 302 https://maintenance.ipipp.com/notice.html;
}
}
如果使用rewrite指令，则必须注意结尾标记。rewrite后面跟permanent等价于301，不加标记默认是302。很多事故就源于运维抄了旧配置却忘了加permanent，导致本该永久的迁移变成了临时跳转。
server {
server_name www.ippipp.com;
# 以下两行效果相同，都是301
rewrite ^/product/(.*)$ https://shop.ipipp.com/goods/$1 permanent;
# rewrite ^/product/(.*)$ https://shop.ipipp.com/goods/$1 redirect; # 这是302
# 若什么都不加，Nginx默认按302处理
# rewrite ^/old/(.*)$ /new/$1;
}
除了状态码本身，还要关注请求方法。在Nginx的return和rewrite实现中，301和302默认都可能改变方法（如POST变GET），若需要严格保持原方法应使用307或308。不过绝大多数网页跳转场景都是GET，因此301与302在方法处理上的差异常被忽略，但在接口网关层必须留意。
三、缓存行为与SEO权重传递对比
浏览器对301的响应通常会做长期缓存，甚至把重定向结果直接写进磁盘缓存。这意味着一旦用户访问过一次301跳转，之后连原服务器都不再请求，直接跳到新地址。这个特性提升了性能，但也让“改错难挽回”：你若把301配错，用户可能几周内都跳到错误页，只能清缓存解决。
302则通常不会被浏览器持久缓存，每次都会去原地址确认是否还跳转。这对临时活动页、灰度发布非常合适，因为你可以随时下线302规则让流量回到原服务。下表总结了关键差异：
| 对比维度 | 301永久重定向 | 302临时重定向 |
|---|---|---|
| 浏览器缓存 | 长期缓存跳转关系 | 基本不缓存或短时缓存 |
| SEO权重 | 旧页权重传递给新页 | 权重留在原页不转移 |
| 适用场景 | 域名更换、路径永久迁移 | 临时维护、活动页、AB测试 |
| 错误代价 | 改错后用户难即时恢复 | 规则移除即恢复原状 |
在搜索引擎优化领域，301是权重合并的唯一正规手段。比如你把全站从http迁到https，必须用301把http流量导到https，否则搜索引擎会认为这是两个站，排名数据割裂。而电商大促的临时落地页用302，活动结束删规则，原商品页排名丝毫不损。
四、生产环境选型与避坑实践
选型的核心原则只有一条：问自己“这个跳转一年后是否还成立”。如果答案是肯定的，比如公司改名换域名、系统升级废弃旧API，就用301；如果是否定的，比如凌晨发版暂停服务、给内部员工看测试版，就用302。切忌用302做长期迁移，也别用301做临时屏蔽。
一个常见坑是链式重定向。有人在Nginx里把old.com 301到www.old.com，又把www.old.com 301到new.com，造成两次跳转，拖慢首屏且部分爬虫只跟一次。应当直接在第一个server块里301到最终地址。另一个坑是在try_files或error_page里误触发302，导致本应返回404的资源被临时跳走，掩盖了真实故障。
最后建议把所有重定向规则集中到独立的conf片段并用版本库管理，每次改动前用curl -I验证响应头。例如执行curl -I http://old.ipipp.com应看到“HTTP/1.1 301 Moved Permanently”及正确的Location头。把301和302用对地方，才能让流量、收录和用户体验都平稳可控。
Nginx301_redirect302_redirect修改时间：2026-08-16 20:30:16