企业官网建设流程全解析

最近排查一个线上问题，发现有人在Nginx里把临时跳转和永久跳转混着写，结果某搜索引擎的收录页面全都变成了中间跳转页，权重和流量掉了一大截。这种事在站点里其实特别常见，说小不小，说大也大。很多人对301和302的理解停留在“反正都能跳转”的层面，但这两个状态码从协议语义、浏览器行为到搜索引擎处理逻辑，差异都非常大。用错了，轻则多一次无效请求，重则影响整站收录和排名。

这篇文章就把301和302彻底拆开讲透，从协议底层逻辑、实际配置写法、SEO差异到排错手段，一条条捋清楚。不管是刚入门的后端开发、前端调接口的同学，还是负责站点运维、SEO优化的朋友，看完应该都能对这两个状态码有个完整的判断框架。

1. 301和302到底差在哪：从定义到使用场景

先看看协议层面怎么定义这两个状态码。301 Moved Permanently，含义是请求的资源已经被永久移动到新地址，以后所有对该资源的请求都应该使用新的URL，旧地址直接失效；302 Found，含义是请求的资源临时被调走了，当前先用新地址响应，但旧地址后续还是有效的。

这段话翻译成人话就是：301等于宣布“搬家了，再也不回老地址”，302等于“临时在隔壁办工，过段时间还回来”。这个语义差异直接决定了后续所有行为。

1.1 浏览器是怎么区别对待它们的

浏览器收到301响应时，会记住这个重定向关系。下次用户在地址栏输入旧地址，浏览器可能会直接跳过请求，自己跳到新地址去；收302响应时则不会做这种长期记忆，每次访问旧地址都会再次向服务器确认一次。

这句话在排障中非常关键。我在实际项目中踩过一个坑：把一个临时活动的入口用了301重定向，活动结束后把跳转撤掉，结果老用户访问旧链接还是被浏览器强行跳到早已下线的活动页。原因就是浏览器缓存了301，清掉缓存或者换个无痕窗口才好。这是301最典型的“副作用”，也是为什么临时跳转必须用302。

另一个直观差异是请求方式。HTTP规范里，301和302都允许客户端在重定向时把POST改为GET，这就引发了不少业务事故。比如用户在A页面提交了表单，后端返回302指向B页面，部分浏览器会直接用GET请求B页面，导致提交的幂等性无法保证。所以在处理支付回调、登录授权这类场景时，很多后端接口会明确改用307或308，确保POST方法在重定向过程中不被改变。关于307和308后面详细说。

1.2 搜索引擎对二者的处理逻辑完全不同

搜索引擎爬虫处理301时，会更新索引库里的URL，把旧链接的权重、收录信息全部迁移到新链接上，之后爬虫会优先抓取新地址，旧地址逐渐从索引中移除。这个过程在业内叫“权重转移”。做过域名迁移或者站点改版的朋友应该深有体会：换完域名后如果只做302，排名和收录基本会掉光；如果做对了301，通常两到三周搜索引擎就能把大部分权重迁移过去。

302就不一样了。爬虫看到302，会认为这是临时的变化，不会轻易更新索引中的主URL，旧地址继续保留并参与排名计算。问题在于，很多站点出于运营目的，把需要永久变更的页面也配成了302，导致搜索引擎反复抓取旧地址，每次都会多付出一次重定向请求，白白消耗抓取配额，还可能出现“搜索引擎收录的是中间页”这种怪象。

所以在决定用哪个状态码之前，先问自己一个问题：旧地址是不是永远不再启用了？如果是，用301；如果只是暂时跳开，一定要用302。这个判断是所有选择的基础。

1.3 从一次案例看选择错误的影响范围

之前帮某内容平台做站点体检，发现它的分页列表页全部用了302跳转到最新列表。结果就是搜索引擎收录的全部是带参数的URL，因为302不会更新主索引，页面权重迟迟无法汇聚。更麻烦的是，用户点击搜索结果后进入链接，又被302跳一次，白白增加一次往返延迟。整站的平均响应时间从200毫秒被拉高到接近500毫秒，流量损耗肉眼可见。

后来把这些302全部改成301，收录结构和排名在下一轮抓取周期就开始改善。这种案例在实践中非常多，状态码配置不当的影响往往被低估，它不只是协议层面的“小问题”，而是直接关联到用户体验、站点性能、搜索流量的全局性配置。

2. 重定向的底层机制：响应头、方法变化与3xx家族

只记住301和302两个编码还不够，真正要搞懂重定向，必须看懂服务器返回的响应头，以及3xx这个大家族里每个成员的角色。很多人在排查问题时卡住，就是因为对机制本身的认知有盲区。

2.1 Location响应头是重定向的核心

服务器返回301或302时，必须在响应头里带上Location字段，告诉客户端“要跳到哪里去”。代码层面长这样：

HTTP/1.1 301 Moved Permanently Location: https://example.com/new-path Content-Length: 0

客户端读取到状态码和Location之后，才会发起二次请求。反过来，如果服务器只设置了状态码，没有Location头，浏览器就会停在原地，用户看到的效果是页面一直白屏或者报错。这个细节在自研网关、Mock服务、后端框架的定制响应里特别容易漏。

Location里的地址可以是完整的绝对URL，也可以是相对路径。绝对URL兼容性最好，各个代理、CDN环境下都不会出问题；相对路径虽然浏览器也支持，但如果经过中间层改写，可能产生意外的拼接结果。我个人的习惯是后端代码里永远返回绝对URL，减少歧义。

2.2 Refresh头是怎么实现“延迟跳转”的

除了状态码加Location，还有一种常见的HTTP重定向方式是Refresh响应头，长这样：

HTTP/1.1 200 OK Refresh: 5; url=https://example.com/landing

它的含义是“5秒后跳转到新地址”。很多老网站会在跳转页上显示“倒计时5秒自动跳转”，用的就是这个机制。Refresh和301/302最大的区别在于：Refresh本身返回200状态码，客户端先加载当前页面内容，再根据Refresh头做跳转。所以搜索引擎看到的是两个URL都返回200，对SEO来说这不是一次真正意义上的重定向，权重迁移效果很差。

日常实践中，Refresh适合用在“告知型跳转”场景，比如支付完成后的结果页提示、下载前的免责声明页。不要用它替代301/302做正规的重定向，尤其不要用在需要传递权重的场景里。

2.3 3xx家族全貌：301/302/303/304/307/308

3xx这个大类其实远不止301和302，理解整个家族有助于在特殊场景里选对编码。

304不是传统意义上的“跳转”，但它是缓存体系里的重定向行为。服务器收到条件请求后，如果资源没有变化，就返回304，告诉浏览器“你本地缓存还能用”。很多排查问题的人会把304和302搞混，其实二者逻辑完全两回事。

关于303和307的出现有个历史背景：早期协议对301/302的定义没有明确“POST转GET”的边界，各浏览器实现不一，为了拯救语义混乱，后来补充了303和307。303明确要求“无论如何都转成GET”，适合表单提交后的返回；307明确要求“保持原方法”，适合API接口的临时流转。到了今天，如果你在做API网关或者前后端分离的项目，建议优先用307/308来收紧行为，避免不同设备上的表现不一致。

2.4 链式重定向是怎么发生的

重定向还有一种常见形态：A返回302跳到B，B又返回302跳到C，最终用户请求了三四个URL才到达目标页面。这种链式重定向在日志里非常普遍，原因是站点调整过程中各层配置疏于同步。

链式重定向的最大代价是性能损耗。浏览器每跳一次就要重新建立一个连接（如果跨域），移动端网络下每次往返可能增加几百毫秒延迟；搜索引擎爬虫对链式跳转尤其敏感，超过一定跳数甚至直接放弃抓取。另外，链条中的任何一个环节出错，整个跳转就断掉。

排查链式重定向的办法是逐跳查看响应。后面会讲到用curl观察完整跳转序列，这是最直接的手段。

3. 服务器端与前端环境下的重定向配置实操

理论部分铺垫好了，接下来聊实操。不同环境下配置301/302的写法和注意点差别很大，我按常见的几种环境分开说。

3.1 Nginx配置301与302的两种常用方式

Nginx里配置重定向主要有rewrite和return两种方式。rewrite属于URL改写，return则直接返回指定状态码加Location，二者在语义上有细微差别。

# 使用rewrite，permanent表示301，redirect表示302 rewrite ^/old/(.*)$ /new/$1 permanent; rewrite ^/old/(.*)$ /new/$1 redirect; # 推荐使用return，语义更直接 return 301 /new/$1; return 302 /new/$1;

rewrite和return的选择有个讲究：rewrite会把正则匹配到的片段捕获后重新拼接，适合复杂的路径改写；return适合简单直接的跳转，性能更高，因为它不再执行后续的rewrite阶段。实际经验是，能用return就用return，可读性和性能都更好。

还有一个容易被忽略的点：Nginx里return后面跟的状态码如果是301/302，Location默认会继承当前请求的Host和端口，生成相对完整的绝对URL。但如果网站本身在CDN或反向代理后面，外层域名和内层回源地址不一致，Nginx生成的Location可能变成内网地址，直接暴露给用户。解决方法是显式拼接完整URL，比如：

return 301 $scheme://www.example.com$request_uri;

3.2 Apache环境配置重定向

Apache的配置风格和Nginx不同，它用的是mod_alias模块里的Redirect指令。

Redirect 301 /old http://www.example.com/new Redirect 302 /old http://www.example.com/temp

Apache的Redirect支持路径匹配，配置起来比较直观，但它的匹配规则是基于目录前缀的，如果要做正则匹配，需要用RedirectMatch或者RewriteRule，这类配置部署时一定要确认模块已经加载。

很多人在Apache里配301后忘记考虑HTTPS跳转，结果就是HTTP和HTTPS两套逻辑各自为政，用户从百度点过来是http页面，域名不统一对SEO很不友好。建议在VirtualHost配置里直接把80端口的请求统一301到443端口，把HTTPS跳转和业务跳转分开处理。

3.3 后端代码里怎么返回301/302

无论前端还是后端应用，重定向的最终本质都是“设置响应状态码+Location头”。以Node.js为例：

// Express框架写法 res.redirect(301, '/new-path'); res.redirect(302, '/temp-path'); // 原生Node.js写法 res.statusCode = 301; res.setHeader('Location', '/new-path'); res.end();

Java的Spring框架里是：

return ResponseEntity.status(HttpStatus.MOVED_PERMANENTLY) .location(URI.create("/new-path")) .build();

Go标准库是：

http.Redirect(w, r, "/new-path", http.StatusMovedPermanently)

这些框架提供的接口本质都一样，只是封装层数不同。需要注意的自定义场景是：如果你在框架里做了全局的响应拦截器，有些拦截器会把Location头吞掉或者改写，导致重定向失效。排查这类问题时，不要只盯着路由代码，把过滤器、中间件全部过一遍。

3.4 前端能做的重定向方式与限制

前端场景常见的重定向有meta refresh和JavaScript跳转。

<!-- meta refresh 写法 --> <meta http-equiv="refresh" content="0; url=/new-path">

// JavaScript 跳转写法 window.location.replace('/new-path');

这两种方式在HTTP协议层面返回200，浏览器根据页面内容再发起跳转。它们的使用限制很明显：爬虫看到200状态码会认为自己访问的就是有效页面，不会进行权重转移，而且每次爬取都要重新加载一遍页面再跳转。所以前端方式只适合交互型跳转，比如登录后跳回原页面、多步表单的条件路由。凡是涉及站点结构变更、URL永久调整的，都应该走服务器端的301或302。

有个细节：想通过前端方式模拟“重定向后不留历史记录”的需求很常见。window.location.replace要优于location.href，因为replace会替换当前历史记录，用户点返回不会回到中间跳转页，体验上更接近服务器端重定向的效果。

4. 重定向的排查手段与问题纠错

理论知识再扎实，到了线上排查还是得靠工具说话。这一节我把平时用顺手的排障手段、常见问题和应对思路整理出来。

4.1 用curl快速查看重定向全链路

curl是排查重定向问题的首选工具，参数-I可以只看响应头。

curl -I -L --max-redirs 5 https://example.com/old-path

-I发出HEAD请求查看响应头；-L表示跟随重定向；--max-redirs限制最大跳转次数。输出里会出现多段响应头，每一段都可以看到状态码和Location，整条重定向链一目了然。如果不加-L，curl只返回第一跳的状态码和Location，不继续跟下去。

在排查具体问题时，我通常会分两步走：第一次不加-L，单独看第一跳返回的是301还是302、Location指向哪里；第二次加-L，把整条链串起来看有没有循环或多余跳数。看到301，还要特别留意响应的Cache-Control头，如果是301且被CDN缓存了，旧地址的跳转关系会持续很长时间，对业务调整很不友好。

4.2 Chrome DevTools里的重定向观察技巧

Chrome开发者工具里Network面板默认会把重定向过程简化显示。想看到完整链路，可以打开面板后勾选“Preserve log”，然后重新加载页面，列表里会出现多条同名请求，每条对应一跳，可以展开查看各自的响应头和状态码。

这里的额外价值在于能看到请求的实际耗时分布。一条重定向如果跨域，往往意味着多一次DNS解析、TLS握手和连接建立。从Network面板就能直观看到这些开销，帮助你判断是否可以把跳转链压缩掉一层。

4.3 配置了301却出现死循环怎么办

死循环是重定向最常见的故障。现象是浏览器报ERR_TOO_MANY_REDIRECTS，或者curl跟随跳转时超过最大次数强制终止。

排查这种问题有个固定套路：

1. 用curl -I不带-L看第一跳返回什么状态码、Location指向哪里。
2. 对比Location和原始URL，检查是否指向了同一个地址或者互相指来指去。
3. 检查Web服务器配置里是否存在多条重定向规则，规则的生效顺序可能和预期不符。
4. 查看域名解析层有没有额外跳转，比如CDN回源规则里配置了强制HTTP跳HTTPS，源站又配了强制HTTPS跳HTTP，两方逻辑冲突。
5. 留意环境变量，比如X-Forwarded-Proto或X-Forwarded-Port在代理层没有正确传递，后端判断协议时拿到的总是http，导致不断的跳转。

第五点在实际项目中很常见。应用层判断“当前是不是HTTPS”，走的是代理传过来的X-Forwarded-Proto头，如果代理没配这个头，应用永远认为自己处在HTTP环境，于是拼命301到HTTPS，而代理层看到的已经是HTTPS请求又不动，最终就陷入循环。解决思路是在代理层透传或者改写这类头，让源站拿到正确的协议信息。

4.4 301和302的缓存策略与排查

很多人不知道301和302的缓存行为也可以控制。协议层面上，301默认可以被浏览器和CDN缓存，302默认不会。但你可以通过响应头显式控制：

Cache-Control: no-cache, no-store, must-revalidate

在返回302响应时加上这段头，可以避免某些代理服务器对302做激进缓存。在返回301时如果希望尽快生效而非等缓存过期，同样可以通过设置no-store来阻止中间层缓存。

实际排障时遇到“改了重定向地址但线上还是跳旧地址”，大概率就是缓存问题。排查顺序是先看浏览器是否命中本地缓存，再看CDN层面是否有缓存，最后查服务器配置是否确实更新了。用curl查看响应头里的Cache-Control和Age字段，能快速判断缓存来自哪一层。

5. 我踩过的那些重定向坑与防范心得

最后分享几个真实案例，都是我在不同项目里踩过的坑。没有亲身经历过的话，看文档很难意识到这些细节有多重要。

第一个坑是登录态跳转被缓存。某系统登录成功后跳转到用户中心，后端返回的302被一层代理服务器强缓存了，导致用户A登录成功后，用户B打开同一URL直接被跳转到A的首页数据。排查到最后发现是代理层对302做了缓存，而且没有Key区分用户。从那以后，我要求所有涉及用户态的302响应必须带Cache-Control: no-store，从协议层杜绝这类事故。

第二个坑是HTTP与HTTPS之间的跳转链设计不当。有个站点在DNS解析层做了HTTP到HTTPS的301，CDN回源时又把HTTPS落到一个HTTP的源站，源站自身又配了301到HTTPS。用户访问一次页面，实际经过了三次跳转：DNS层一次、CDN层一次、源站一次。响应时间从80毫秒涨到了600多毫秒。后来重新梳理，把跳转职责收敛到CDN边缘层和源站层各自只做一次决定，整条链路才清爽。

第三个坑是302导致的搜索引擎索引混乱。某商城为了做促销，把详情页全部302到活动页，持续了一个多月。活动结束后搜索流量骤降，因为搜索引擎在这段时间里建立的大量索引都是活动页URL，活动页下线后这些URL全部404。如果当时用的是301，索引会稳定迁移到活动页，即使活动结束后也有机会通过301把权重转移到下一个承接页面。促销逻辑和SEO逻辑经常打架，但技术侧至少要把选择权透明化，让业务明白风险。

第四个坑是移动端和桌面端分别跳转时状态码用反。有些站点桌面版是完整内容，移动版是简化页面，通过检测User-Agent做302跳转，这是合理场景。但有人为了“省事”，直接给移动端配置成301，后果是用户手机浏览器永久记住了移动版URL，之后即使用户想切换桌面版网页，浏览器还是会直接跳到移动版。移动适配跳转必须用302，这已经是行业共识，但仍然有站点在犯。

说到这，我个人的习惯可以总结成几句话：

凡是确认永久变更的，比如换域名、改路径、统一协议，一律301，同时确认不经过浏览器缓存的历史残留；凡是临时性流转的，比如活动页、登录跳转、移动适配、A/B测试，一律302，并显式关闭缓存；涉及POST接口的重定向，优先307和308；所有重定向配置上线前，用curl走一遍完整跳转链，记录状态码与耗时。

这几点做到位，重定向相关的坑基本都能避开。状态码选错不会立刻让网站挂掉，但会在流量、收录、性能上持续放血，越早纠正越省事。