做Web开发这几年301和302这两个状态码算是遇到频率最高的重定向方式但我发现不少同学到现在都没把两者的区别完全搞明白。之前接到一个模拟项目网站要从HTTP整体迁到HTTPS前端同事图省事配了一堆302跳转结果线上访问是没问题搜索引擎却不认账旧页面权重迟迟不转移新关键词排名一直上不来。最后定位到根因就是临时和永久这两个词的语义用反了。这篇文章不写概念教科书直接从实际工作出发把两个状态码的职责边界、服务器配置方法、踩过的坑和排查套路全部揉在一起聊。适合正在搭站的后端开发、维护线上环境的运维还有天天被SEO指标追着跑的运营同学。我会先用生活化的类比把301和302的本质讲透再给可抄作业的配置示例最后整理一份常见问题速查表。看完这篇文章你应该能在五分钟内判断某个场景到底该用301还是302。1. 重定向状态码的本质301和302到底在告诉客户端什么1.1 状态码是服务器给客户端的一句明确旁白HTTP请求是一个问答过程浏览器问服务器我要访问这个地址服务器用状态码回答请求收到了处理结果是这样。状态码不是给用户看的文案而是给浏览器、爬虫、客户端程序看的结构化信息。3开头的状态码统一表示重定向意思是你要的东西我已经看到了但它现在不在这个地址我给你一个Location响应头里面写着新地址你自己再跑一趟。你可以把301和302想象成导航App里的两种提示。301是这个目的地已经永久搬家了以后都用新地址来找我302是这个目的地暂时不对外开放你先去临时地址凑合一下过段时间再回原地址试试。两种说法看似相似但客户端和搜索引擎处理它们的逻辑完全不同这也是很多事故的源头。1.2 301与302的官方语义差异先看定义301 Moved Permanently请求的资源已经被永久移动以后任何对原始URL的请求都应该直接使用新的URL。302 Found请求的资源暂时被移到了另一个URL以后对原始URL的请求仍然应该继续使用原始URL。这里有个历史彩蛋302最初的名字叫Found语义非常模糊后来HTTP/1.1规范也没改干净导致很多浏览器实现是不管301还是302只要我用GET请求跳转后一律变成GET。所以官方规范后来补充了303 See Other和307 Temporary Redirect来解决语义混乱的问题。咱们后文会提到但工程上现在依然大量用到301和302所以理解其根本差异仍然是基本功。从实际影响看主要差异体现在三方面对比维度301 永久重定向302 临时重定向浏览器缓存行为会默认缓存跳转结果一般不会主动缓存除非响应头显式允许搜索引擎处理将旧URL权重继承到新URL索引更新为新地址继续把旧URL视为可访问地址不转移权重典型触发结果用户再次输入旧地址时可能直接被跳转用户每次都会先访问旧地址再收到跳转指令适用阶段域名更换、结构改版、协议升级临时活动页、登录、A/B测试对普通用户来说301和302在浏览器里看到的差异不大甚至感知不到。但对爬虫和客户端程序来说差别巨大。如果配置错误轻则增加无谓的请求次数重则让网站整整数个月的SEO工作白干。2. 场景选型什么时候用301什么时候用3022.1 用301的典型场景凡是旧地址以后再也不打算用了的情况都该用301。我实际经手过的场景主要有四类第一域名更换。从一个已经运营多年的域名迁移到新域名必须把所有页面、图片、静态资源的地址都通过301指到新域名。这时候如果用了302老用户在搜索引擎里点击旧链接后虽然也能到达新页面但搜索引擎会一直觉得旧域名还有效就不会把流量和权重放下。第二HTTP协议升级到HTTPS。这是当前最普遍的场景。配置时在服务器层面把80端口的请求全部301跳转到443端口返回带新链接的Location头。我见过有人为了图省事直接把所有HTTP请求都用302转发短期内确实能跳到HTTPS页面但搜索引擎对旧链接的信任度会下降而且多次临时跳转会让抓取效率变差。第三URL规范化。比如一个网站的页面既可以通过http://old.example.com访问也可以通过https://old.example.com访问搜索引擎会认为是两个不同站点。通常选择其中一个版本作为主版本把另一个版本通过301指过去。常见的做法是把裸域名统一带www或者反过来总之要用301不能两个域名都声称自己是正版。第四旧内容永久下线但希望用户去新的替代页面。比如原本的/article/123改成了/posts/123旧编号以后不再复用直接301到新地址。搜索引擎会把旧页面的外链声望转给新页面这也是SEO迁移中最值钱的环节。我自己的经验是只要在需求里看到永久、以后不恢复、域名换了这些字眼第一反应就应该上301。犹豫不决时宁可保守一点也不要让一个永久变更用临时状态码撑半年。2.2 用302的典型场景302适合原地址仍然有效只是这次请求你要去别的地方处理的场景。最常见的有三类。登录跳转算一个。用户访问一个需要登录的页面系统会先把他带到登录页登录成功后带着回跳参数再回到原始地址。在这个暂时走开一下的过程中原始URL本身没有任何变化用户下次再来还是走同样的流程所以用302非常合适。临时活动页也算一个。比如节日大促原页面栏位内容不变只是临时把流量引到一个活动页活动结束后再回到原来的页面逻辑。这里如果有缓存可能会把用户永远留在活动页所以要非常注意响应头的缓存控制。实在拿不准时301一定不要用302配合Cache-Control: no-store是更稳的方案。A/B测试同样依赖302。当一个功能有两个版本在分流实验后台要按用户群体或参数决定跳到哪一版。这个跳转对每个用户来说可能都不一样绝不能让浏览器永久缓存某个跳转目标否则实验就废了。用302的好处就在于此每次请求都老老实实到服务器问一句我这次该去哪。顺带提一句302还可以用于均衡负载。一些老旧的系统用302把请求轮流指到不同机房的服务节点但现代架构基本都用DNS或网关层负载均衡了302这种方案只适合少数限制严格的场景。2.3 容易被忽略的303、307和308既然聊到选型就得把另外三个兄弟状态码拿出来说说。HTTP/1.1时代补充了303 See Other和307 Temporary Redirect后来又有了308 Permanent Redirect。303无论原请求是POST还是PUT跳转后都让客户端改用GET去访问新地址。常用于表单提交成功后跳转到结果页防止用户刷新页面导致重复提交。307语义和302几乎一样都是临时重定向但不对请求方法做任何强制转换。如果用POST发起请求服务器返回307浏览器会再用POST请求新地址。这点很重要因为很多旧实现的302会把POST变为GET导致请求体丢失。308语义和301一样是永久重定向但同样不会更改请求方法。处理非GET请求的永久迁移时用它比301更安全。工程上普通页面的GET跳转用301/302足够但涉及API接口和表单回跳时要多留个心眼。我见过不少团队把POST接口的301跳转当GET处理导致客户端拿到响应后丢失了请求体查了半天才发现是状态码语义在作怪。3. Web服务器上的301/302配置实操3.1 主流服务器配置示例真正动手配的时候第一件事就是确定自己用的是哪种Web服务器。下面给几份可以直接抄的例子。NginxNginx里设置重定向一般用return或rewrite。return更简洁高效适合明确的目标地址# 整个站点的HTTP强制跳转到HTTPS用301永久跳转 server { listen 80; server_name old.example.com; return 301 https://new.example.com$request_uri; } # 某个旧路径永久跳转到新路径用301 location /old/ { return 301 https://new.example.com/new/$request_uri; } # 临时活动页跳转用302 location /promo { return 302 https://new.example.com/event/spring-sale; }rewrite也能实现但一般在需要基于路径正则改写时才更值得用rewrite ^/old/(.*)$ /new/$1 permanent; # 301 rewrite ^/old/(.*)$ /new/$1 redirect; # 302ApacheApache的配置更接近人类语言可以用Redirect或RedirectMatch指令# 单个路径的301永久重定向 Redirect 301 /old https://new.example.com/new # 基于正则匹配的302临时重定向 RedirectMatch 302 ^/old/(.*)$ https://new.example.com/new/$1Apache配置文件改动后用apachectl graceful平滑生效Nginx用nginx -s reload不要用restart否则会有短暂中断。Node.js / Express后端代码里控制重定向状态码也很常见Express框架只需要一行const express require(express); const app express(); // 永久跳转 app.get(/old, (req, res) { res.redirect(301, /new); }); // 临时跳转默认就是302 app.get(/temporary, (req, res) { res.redirect(/temp); });Java Servlet / Spring BootGetMapping(/old) public void redirectOld(HttpServletResponse response) throws IOException { response.setStatus(301); response.setHeader(Location, https://new.example.com/new); response.flushBuffer(); } // 或者用Spring Boot更简洁的方式 GetMapping(/old2) public RedirectView redirectOld2() { RedirectView view new RedirectView(/new); view.setStatusCode(HttpStatus.MOVED_PERMANENTLY); return view; }配置本身的语法不难难的是弄清楚目标地址怎么拼。3.2 配置时最容易踩的路径坑我在代码审查里最常看到的错误有三个。第一个是丢掉查询参数。Nginx里如果写死return 301 https://new.example.com/new;那么用户访问/old?fromad时fromad就丢了。正确写法是保留$request_uri或用对应变量拼上return 301 https://new.example.com/new$request_uri;这里的$request_uri包含原来的URI和查询字符串能把/old?fromad原样带到https://new.example.com/new?fromad。第二个是域名带的路径重复。假设源站是https://new.example.com/blog如果配置里不小心写成return 301 https://new.example.com/blog$request_uri而$request_uri又包含/old结果就变成/blog/old了。正确做法是明确我要把旧路径映射到新页面的哪个根位置最好先写一个测试文件验证再上线。第三个是特殊字符和中文路径。重定向目标URL只支持ASCII字符如果旧路径里有中文或空格服务器端最好对Location头做URL编码否则部分浏览器会直接报地址无效。Nginx和Apache通常会自动处理一部分但后端代码里自己拼接时一定要用encodeURI、URLEncoder.encode这类工具。修改完配置后我习惯用两三步自检先看是否保留参数再看目标URL是否可达最后用命令行工具确认响应头。别小看这三步能挡掉一大半线上事故。3.3 如何验证重定向配置生效验证重定向不是用浏览器点一下看看能不能跳这么简单浏览器会默认跟随跳转你根本看不到中间过程。最直接的方式是用curl查看响应头限制不跟随跳转curl -I http://old.example.com/old输出里会看到HTTP/1.1 301 Moved Permanently Location: https://new.example.com/newHTTP/1.1 301就是要的重点。如果看到的是302 Found说明你配错了。如果想去掉缓存因素的干扰可以加-H Cache-Control: no-cache再看一遍。要查看完整跳转链用curl -L并设置最大跳转次数curl -L --max-redirs 5 http://old.example.com/old这个方法能快速发现跳转链太长和循环重定向问题。浏览器开发者工具里的Network面板也能看到每次请求的状态码记得勾选Disable cache再测试否则浏览器缓存的301结果会干扰判断。4. 重定向配置常见问题与排查方法4.1 问题重定向循环典型的报错是浏览器显示此网页造成了太多重定向或ERR_TOO_MANY_REDIRECTS。原因通常是A跳B、B再跳A形成死循环。常见场景是HTTP与HTTPS两个配置互相指旧域名指向新域名新域名又因为某个规则指回旧域名。排查思路很简单第一步先看服务器配置确认有没有两个return规则同时命中同一个URL。第二步用curl逐步查看curl -I -L --max-redirs 3 http://old.example.com/如果输出里反复出现HTTP/1.1 301且Location一直变不回http://基本就是循环。我踩过一次很隐蔽的坑Nginx里server块的listen 80和listen 443 ssl都写了return 301 https://new.example.com$request_uri看起来没错但其中一个证书配置失效导致HTTPS端口响应失败浏览器在两次跳转后反而报循环。后来把监听规则放全局变量里统一管理才解决。4.2 问题302跳转后权重丢失这个问题的表现是页面能访问但搜索引擎收录一直不更新旧关键词排名波动。原因几乎都是永久性迁移却用了302。搜索引擎对302的处理是旧地址仍然存活先抓取旧地址临时跳转不完全信任所以权重不会真正转移。我的建议是凡是判断为永久变更立刻改成301。如果业务方说暂时不确定以后恢复不恢复怎么办那就给出时间底线——超过两周到一个月还没恢复的就默认按永久迁移处理改成301。不要为了以后方便恢复而长期使用302这个舒适区会让SEO团队很痛苦。另外还有一层容易被忽略CDN或中间代理可能会缓存302响应。有些缓存系统对于带Set-Cookie或特定路径的302不会缓存但纯静态路径就说不准。如果发现改完配置用户还在走旧地址优先检查CDN节点节点缓存和浏览器缓存。4.3 问题浏览器或CDN缓存了旧的跳转结果301的一个副作用是浏览器会记住这个跳转下次访问旧地址直接跳到新地址。这本来是性能优化但在调试阶段非常烦人你把301改成302或改成另一个地址后浏览器还在用旧结果。清理办法分三档第一档是开发者工具Network面板里勾选Disable cache然后强制刷新第二档是用curl -H Cache-Control: no-cache验证服务器实际响应第三档是换一个无痕窗口或换浏览器测试。如果是CDN缓存需要在CDN控制台刷新对应路径的缓存或者在响应头里加Cache-Control: no-store来控制。尤其是临时活动页如果CDN把302结果缓存一小时活动结束后的时间窗口里用户还是会跳到活动页等于白加班。4.4 问题重定向后请求方法丢失这里要回到之前提过的307/308。一个典型场景是客户端向服务端提交一个POST请求服务端返回302并指向另一个地址浏览器按规范可能把这个POST请求变成GET请求导致新地址收到的请求没有请求体业务报错。最直接的解决办法是如果后端需要保持原请求方法就用307或308如果希望把POST转成GET例如表单提交成功后跳转结果页就用303或302并告知客户端必须用GET。这里没有一刀切的答案完全取决于业务是否需要保留请求方法。排查这类问题时建议在服务端打印请求方法、请求头和请求体对比跳转前后的差异。很多框架默认会把302包装成GET请求这是框架行为不是服务器底层错误。5. 我在实际项目中掌握的几条避坑经验5.1 优先用简洁规则替代复杂正则Nginx里return指令比rewrite更容易理解也更省性能。rewrite适合需要从URL中提取一段并重新拼接的场景但正则写复杂后非常难维护。我曾经维护过一个老站点一条rewrite规则写了半年没人敢碰后来直接改用两三条return规则把所有旧路径显式列出来反而便于排查。我的建议是能用精确路径就不写正则能写正则就别嵌套多层判断尽量让每一条跳转规则一眼就能看懂。5.2 重定向目标必须做可达性自检跳转是否成功不只取决于状态码还取决于Location指向的地址是否真的能返回200。如果配了301到新地址但新地址本身是404那用户只会看到一记重定向失效搜索引擎也把新页面当成死链。我在验收时会写一个简单脚本把所有要配置的旧URL和新URL成对测试确保旧URL返回3XX、新URL返回2XX并且在跳转链上不出现404。5.3 重定向链越短越好从旧URL到最终页面中间经历多次3XX跳转会拖慢页面加载速度也会让搜索引擎的抓取预算浪费在非内容页上。理想状态是旧URL只跳转一次直达最终URL。如果有历史原因造成中间层比如旧域名跳中间域名再跳新域名一定要尽快收敛成一次跳转。我曾经处理过一个项目跳转链是6跳最后用curl -L看到响应耗时翻了四倍优化成单跳后用户体感快了很多。5.4 留好日志和监控重定向不是配完就结束的事。建议在Nginx或应用层为3XX响应单独打日志记录来源URL、目标URL、跳转类型。这样当运营反馈某个入口流量异常下降时你可以快速拉出日志看是哪个环节把流量截断了。我习惯每季度做一次重定向审计把所有3XX响应按状态码、跳转目标、命中次数排序一次性清理掉那些已经没人访问但还在消耗爬虫预算的旧规则。最后再分享一个个人体会处理301和302最重要的不是记住代码怎么写而是建立一张这个变更到底是不是永久的判断表。每次收到跳转需求先问业务方三句话旧地址以后还需要正常访问吗这个跳转预计持续多久目标地址是同一个站内的内容还是另一个系统的页面答案如果是旧地址以后不用了且持续超过一个月基本都是301跑不掉如果只是暂时引导且需要频繁变化302是更合适的选择。这套判断逻辑一旦养成你写出的跳转规则会比很多人稳得多。 301与302重定向区别详解：原理、配置与SEO影响
做Web开发这几年301和302这两个状态码算是遇到频率最高的重定向方式但我发现不少同学到现在都没把两者的区别完全搞明白。之前接到一个模拟项目网站要从HTTP整体迁到HTTPS前端同事图省事配了一堆302跳转结果线上访问是没问题搜索引擎却不认账旧页面权重迟迟不转移新关键词排名一直上不来。最后定位到根因就是临时和永久这两个词的语义用反了。这篇文章不写概念教科书直接从实际工作出发把两个状态码的职责边界、服务器配置方法、踩过的坑和排查套路全部揉在一起聊。适合正在搭站的后端开发、维护线上环境的运维还有天天被SEO指标追着跑的运营同学。我会先用生活化的类比把301和302的本质讲透再给可抄作业的配置示例最后整理一份常见问题速查表。看完这篇文章你应该能在五分钟内判断某个场景到底该用301还是302。1. 重定向状态码的本质301和302到底在告诉客户端什么1.1 状态码是服务器给客户端的一句明确旁白HTTP请求是一个问答过程浏览器问服务器我要访问这个地址服务器用状态码回答请求收到了处理结果是这样。状态码不是给用户看的文案而是给浏览器、爬虫、客户端程序看的结构化信息。3开头的状态码统一表示重定向意思是你要的东西我已经看到了但它现在不在这个地址我给你一个Location响应头里面写着新地址你自己再跑一趟。你可以把301和302想象成导航App里的两种提示。301是这个目的地已经永久搬家了以后都用新地址来找我302是这个目的地暂时不对外开放你先去临时地址凑合一下过段时间再回原地址试试。两种说法看似相似但客户端和搜索引擎处理它们的逻辑完全不同这也是很多事故的源头。1.2 301与302的官方语义差异先看定义301 Moved Permanently请求的资源已经被永久移动以后任何对原始URL的请求都应该直接使用新的URL。302 Found请求的资源暂时被移到了另一个URL以后对原始URL的请求仍然应该继续使用原始URL。这里有个历史彩蛋302最初的名字叫Found语义非常模糊后来HTTP/1.1规范也没改干净导致很多浏览器实现是不管301还是302只要我用GET请求跳转后一律变成GET。所以官方规范后来补充了303 See Other和307 Temporary Redirect来解决语义混乱的问题。咱们后文会提到但工程上现在依然大量用到301和302所以理解其根本差异仍然是基本功。从实际影响看主要差异体现在三方面对比维度301 永久重定向302 临时重定向浏览器缓存行为会默认缓存跳转结果一般不会主动缓存除非响应头显式允许搜索引擎处理将旧URL权重继承到新URL索引更新为新地址继续把旧URL视为可访问地址不转移权重典型触发结果用户再次输入旧地址时可能直接被跳转用户每次都会先访问旧地址再收到跳转指令适用阶段域名更换、结构改版、协议升级临时活动页、登录、A/B测试对普通用户来说301和302在浏览器里看到的差异不大甚至感知不到。但对爬虫和客户端程序来说差别巨大。如果配置错误轻则增加无谓的请求次数重则让网站整整数个月的SEO工作白干。2. 场景选型什么时候用301什么时候用3022.1 用301的典型场景凡是旧地址以后再也不打算用了的情况都该用301。我实际经手过的场景主要有四类第一域名更换。从一个已经运营多年的域名迁移到新域名必须把所有页面、图片、静态资源的地址都通过301指到新域名。这时候如果用了302老用户在搜索引擎里点击旧链接后虽然也能到达新页面但搜索引擎会一直觉得旧域名还有效就不会把流量和权重放下。第二HTTP协议升级到HTTPS。这是当前最普遍的场景。配置时在服务器层面把80端口的请求全部301跳转到443端口返回带新链接的Location头。我见过有人为了图省事直接把所有HTTP请求都用302转发短期内确实能跳到HTTPS页面但搜索引擎对旧链接的信任度会下降而且多次临时跳转会让抓取效率变差。第三URL规范化。比如一个网站的页面既可以通过http://old.example.com访问也可以通过https://old.example.com访问搜索引擎会认为是两个不同站点。通常选择其中一个版本作为主版本把另一个版本通过301指过去。常见的做法是把裸域名统一带www或者反过来总之要用301不能两个域名都声称自己是正版。第四旧内容永久下线但希望用户去新的替代页面。比如原本的/article/123改成了/posts/123旧编号以后不再复用直接301到新地址。搜索引擎会把旧页面的外链声望转给新页面这也是SEO迁移中最值钱的环节。我自己的经验是只要在需求里看到永久、以后不恢复、域名换了这些字眼第一反应就应该上301。犹豫不决时宁可保守一点也不要让一个永久变更用临时状态码撑半年。2.2 用302的典型场景302适合原地址仍然有效只是这次请求你要去别的地方处理的场景。最常见的有三类。登录跳转算一个。用户访问一个需要登录的页面系统会先把他带到登录页登录成功后带着回跳参数再回到原始地址。在这个暂时走开一下的过程中原始URL本身没有任何变化用户下次再来还是走同样的流程所以用302非常合适。临时活动页也算一个。比如节日大促原页面栏位内容不变只是临时把流量引到一个活动页活动结束后再回到原来的页面逻辑。这里如果有缓存可能会把用户永远留在活动页所以要非常注意响应头的缓存控制。实在拿不准时301一定不要用302配合Cache-Control: no-store是更稳的方案。A/B测试同样依赖302。当一个功能有两个版本在分流实验后台要按用户群体或参数决定跳到哪一版。这个跳转对每个用户来说可能都不一样绝不能让浏览器永久缓存某个跳转目标否则实验就废了。用302的好处就在于此每次请求都老老实实到服务器问一句我这次该去哪。顺带提一句302还可以用于均衡负载。一些老旧的系统用302把请求轮流指到不同机房的服务节点但现代架构基本都用DNS或网关层负载均衡了302这种方案只适合少数限制严格的场景。2.3 容易被忽略的303、307和308既然聊到选型就得把另外三个兄弟状态码拿出来说说。HTTP/1.1时代补充了303 See Other和307 Temporary Redirect后来又有了308 Permanent Redirect。303无论原请求是POST还是PUT跳转后都让客户端改用GET去访问新地址。常用于表单提交成功后跳转到结果页防止用户刷新页面导致重复提交。307语义和302几乎一样都是临时重定向但不对请求方法做任何强制转换。如果用POST发起请求服务器返回307浏览器会再用POST请求新地址。这点很重要因为很多旧实现的302会把POST变为GET导致请求体丢失。308语义和301一样是永久重定向但同样不会更改请求方法。处理非GET请求的永久迁移时用它比301更安全。工程上普通页面的GET跳转用301/302足够但涉及API接口和表单回跳时要多留个心眼。我见过不少团队把POST接口的301跳转当GET处理导致客户端拿到响应后丢失了请求体查了半天才发现是状态码语义在作怪。3. Web服务器上的301/302配置实操3.1 主流服务器配置示例真正动手配的时候第一件事就是确定自己用的是哪种Web服务器。下面给几份可以直接抄的例子。NginxNginx里设置重定向一般用return或rewrite。return更简洁高效适合明确的目标地址# 整个站点的HTTP强制跳转到HTTPS用301永久跳转 server { listen 80; server_name old.example.com; return 301 https://new.example.com$request_uri; } # 某个旧路径永久跳转到新路径用301 location /old/ { return 301 https://new.example.com/new/$request_uri; } # 临时活动页跳转用302 location /promo { return 302 https://new.example.com/event/spring-sale; }rewrite也能实现但一般在需要基于路径正则改写时才更值得用rewrite ^/old/(.*)$ /new/$1 permanent; # 301 rewrite ^/old/(.*)$ /new/$1 redirect; # 302ApacheApache的配置更接近人类语言可以用Redirect或RedirectMatch指令# 单个路径的301永久重定向 Redirect 301 /old https://new.example.com/new # 基于正则匹配的302临时重定向 RedirectMatch 302 ^/old/(.*)$ https://new.example.com/new/$1Apache配置文件改动后用apachectl graceful平滑生效Nginx用nginx -s reload不要用restart否则会有短暂中断。Node.js / Express后端代码里控制重定向状态码也很常见Express框架只需要一行const express require(express); const app express(); // 永久跳转 app.get(/old, (req, res) { res.redirect(301, /new); }); // 临时跳转默认就是302 app.get(/temporary, (req, res) { res.redirect(/temp); });Java Servlet / Spring BootGetMapping(/old) public void redirectOld(HttpServletResponse response) throws IOException { response.setStatus(301); response.setHeader(Location, https://new.example.com/new); response.flushBuffer(); } // 或者用Spring Boot更简洁的方式 GetMapping(/old2) public RedirectView redirectOld2() { RedirectView view new RedirectView(/new); view.setStatusCode(HttpStatus.MOVED_PERMANENTLY); return view; }配置本身的语法不难难的是弄清楚目标地址怎么拼。3.2 配置时最容易踩的路径坑我在代码审查里最常看到的错误有三个。第一个是丢掉查询参数。Nginx里如果写死return 301 https://new.example.com/new;那么用户访问/old?fromad时fromad就丢了。正确写法是保留$request_uri或用对应变量拼上return 301 https://new.example.com/new$request_uri;这里的$request_uri包含原来的URI和查询字符串能把/old?fromad原样带到https://new.example.com/new?fromad。第二个是域名带的路径重复。假设源站是https://new.example.com/blog如果配置里不小心写成return 301 https://new.example.com/blog$request_uri而$request_uri又包含/old结果就变成/blog/old了。正确做法是明确我要把旧路径映射到新页面的哪个根位置最好先写一个测试文件验证再上线。第三个是特殊字符和中文路径。重定向目标URL只支持ASCII字符如果旧路径里有中文或空格服务器端最好对Location头做URL编码否则部分浏览器会直接报地址无效。Nginx和Apache通常会自动处理一部分但后端代码里自己拼接时一定要用encodeURI、URLEncoder.encode这类工具。修改完配置后我习惯用两三步自检先看是否保留参数再看目标URL是否可达最后用命令行工具确认响应头。别小看这三步能挡掉一大半线上事故。3.3 如何验证重定向配置生效验证重定向不是用浏览器点一下看看能不能跳这么简单浏览器会默认跟随跳转你根本看不到中间过程。最直接的方式是用curl查看响应头限制不跟随跳转curl -I http://old.example.com/old输出里会看到HTTP/1.1 301 Moved Permanently Location: https://new.example.com/newHTTP/1.1 301就是要的重点。如果看到的是302 Found说明你配错了。如果想去掉缓存因素的干扰可以加-H Cache-Control: no-cache再看一遍。要查看完整跳转链用curl -L并设置最大跳转次数curl -L --max-redirs 5 http://old.example.com/old这个方法能快速发现跳转链太长和循环重定向问题。浏览器开发者工具里的Network面板也能看到每次请求的状态码记得勾选Disable cache再测试否则浏览器缓存的301结果会干扰判断。4. 重定向配置常见问题与排查方法4.1 问题重定向循环典型的报错是浏览器显示此网页造成了太多重定向或ERR_TOO_MANY_REDIRECTS。原因通常是A跳B、B再跳A形成死循环。常见场景是HTTP与HTTPS两个配置互相指旧域名指向新域名新域名又因为某个规则指回旧域名。排查思路很简单第一步先看服务器配置确认有没有两个return规则同时命中同一个URL。第二步用curl逐步查看curl -I -L --max-redirs 3 http://old.example.com/如果输出里反复出现HTTP/1.1 301且Location一直变不回http://基本就是循环。我踩过一次很隐蔽的坑Nginx里server块的listen 80和listen 443 ssl都写了return 301 https://new.example.com$request_uri看起来没错但其中一个证书配置失效导致HTTPS端口响应失败浏览器在两次跳转后反而报循环。后来把监听规则放全局变量里统一管理才解决。4.2 问题302跳转后权重丢失这个问题的表现是页面能访问但搜索引擎收录一直不更新旧关键词排名波动。原因几乎都是永久性迁移却用了302。搜索引擎对302的处理是旧地址仍然存活先抓取旧地址临时跳转不完全信任所以权重不会真正转移。我的建议是凡是判断为永久变更立刻改成301。如果业务方说暂时不确定以后恢复不恢复怎么办那就给出时间底线——超过两周到一个月还没恢复的就默认按永久迁移处理改成301。不要为了以后方便恢复而长期使用302这个舒适区会让SEO团队很痛苦。另外还有一层容易被忽略CDN或中间代理可能会缓存302响应。有些缓存系统对于带Set-Cookie或特定路径的302不会缓存但纯静态路径就说不准。如果发现改完配置用户还在走旧地址优先检查CDN节点节点缓存和浏览器缓存。4.3 问题浏览器或CDN缓存了旧的跳转结果301的一个副作用是浏览器会记住这个跳转下次访问旧地址直接跳到新地址。这本来是性能优化但在调试阶段非常烦人你把301改成302或改成另一个地址后浏览器还在用旧结果。清理办法分三档第一档是开发者工具Network面板里勾选Disable cache然后强制刷新第二档是用curl -H Cache-Control: no-cache验证服务器实际响应第三档是换一个无痕窗口或换浏览器测试。如果是CDN缓存需要在CDN控制台刷新对应路径的缓存或者在响应头里加Cache-Control: no-store来控制。尤其是临时活动页如果CDN把302结果缓存一小时活动结束后的时间窗口里用户还是会跳到活动页等于白加班。4.4 问题重定向后请求方法丢失这里要回到之前提过的307/308。一个典型场景是客户端向服务端提交一个POST请求服务端返回302并指向另一个地址浏览器按规范可能把这个POST请求变成GET请求导致新地址收到的请求没有请求体业务报错。最直接的解决办法是如果后端需要保持原请求方法就用307或308如果希望把POST转成GET例如表单提交成功后跳转结果页就用303或302并告知客户端必须用GET。这里没有一刀切的答案完全取决于业务是否需要保留请求方法。排查这类问题时建议在服务端打印请求方法、请求头和请求体对比跳转前后的差异。很多框架默认会把302包装成GET请求这是框架行为不是服务器底层错误。5. 我在实际项目中掌握的几条避坑经验5.1 优先用简洁规则替代复杂正则Nginx里return指令比rewrite更容易理解也更省性能。rewrite适合需要从URL中提取一段并重新拼接的场景但正则写复杂后非常难维护。我曾经维护过一个老站点一条rewrite规则写了半年没人敢碰后来直接改用两三条return规则把所有旧路径显式列出来反而便于排查。我的建议是能用精确路径就不写正则能写正则就别嵌套多层判断尽量让每一条跳转规则一眼就能看懂。5.2 重定向目标必须做可达性自检跳转是否成功不只取决于状态码还取决于Location指向的地址是否真的能返回200。如果配了301到新地址但新地址本身是404那用户只会看到一记重定向失效搜索引擎也把新页面当成死链。我在验收时会写一个简单脚本把所有要配置的旧URL和新URL成对测试确保旧URL返回3XX、新URL返回2XX并且在跳转链上不出现404。5.3 重定向链越短越好从旧URL到最终页面中间经历多次3XX跳转会拖慢页面加载速度也会让搜索引擎的抓取预算浪费在非内容页上。理想状态是旧URL只跳转一次直达最终URL。如果有历史原因造成中间层比如旧域名跳中间域名再跳新域名一定要尽快收敛成一次跳转。我曾经处理过一个项目跳转链是6跳最后用curl -L看到响应耗时翻了四倍优化成单跳后用户体感快了很多。5.4 留好日志和监控重定向不是配完就结束的事。建议在Nginx或应用层为3XX响应单独打日志记录来源URL、目标URL、跳转类型。这样当运营反馈某个入口流量异常下降时你可以快速拉出日志看是哪个环节把流量截断了。我习惯每季度做一次重定向审计把所有3XX响应按状态码、跳转目标、命中次数排序一次性清理掉那些已经没人访问但还在消耗爬虫预算的旧规则。最后再分享一个个人体会处理301和302最重要的不是记住代码怎么写而是建立一张这个变更到底是不是永久的判断表。每次收到跳转需求先问业务方三句话旧地址以后还需要正常访问吗这个跳转预计持续多久目标地址是同一个站内的内容还是另一个系统的页面答案如果是旧地址以后不用了且持续超过一个月基本都是301跑不掉如果只是暂时引导且需要频繁变化302是更合适的选择。这套判断逻辑一旦养成你写出的跳转规则会比很多人稳得多。