1. 先弄清楚Nginx重定向到底解决什么问题我记得刚接触Nginx那会儿对重定向的理解就停留在把用户从一个地址带到另一个地址这个层面。后来踩的坑多了才发现重定向这活儿在真实业务里承担的角色远比表面复杂。它至少要解决三类问题。第一类是URL规范化。同一个网站在PC端和移动端可能有不同域名用户可能用带www的域名访问也可能直接敲裸域名可能是http://进来也可能是https://进来。如果这些入口都各自为政搜索引擎就会认为你有多个重复页面权重被分散Site鉴权、登录态同步也都会出乱子。这时候重定向就是那个把所有入口拧成一股绳的开关。第二类是资源迁移。公司业务调整、系统重构旧的接口路径没了老的文章链接全部404。你要是直接返回404用户流失、搜索引擎收录全废。正确的做法是用301永久重定向把老地址指向新地址把旧页面的权重和用户心智一并转移过去。第三类是流量调度与安全控制。比如HTTP强制跳HTTPS、临时维护页面跳转、根据用户设备跳不同的站点甚至限制某个路径只允许特定来源访问——这些都依赖重定向能力来落地。所以Nginx里的重定向不是简单的从一个URL跳到另一个URL它是整个站点入口管理、迁移管理和流量治理的基础设施。一篇博文很难把所有场景穷尽我打算挑日常用得最频繁、坑也最多的几种配置展开包括rewrite、return、try_files、proxy_pass联动、alias场景下的路径改写、以及按设备/来源做条件跳转。搞明白这些常规业务基本就够用了。2. 搭建一个随手能复现的实验环境讲配置之前先聊聊环境。Nginx重定向的很多坑光看文档是理解不了的你必须搭一个环境自己去试。我建议用Docker跑一个独立的Nginx容器原因很简单干净、可丢弃、随便折腾不心疼。你本地搭建也行但Docker的方式对实验场景更友好——配置写坏了直接删容器重建不用和系统里的残留文件纠缠。我这里用一个固定的实验端口8080容器内Nginx监听80把宿主机的8080映射过去。同时准备两个域名用来测试跨域跳转主域名用www.oldsite.test目标域名用www.newsite.test。.test后缀不会被真实DNS解析非常适合本地实验。# 拉镜像并启动容器挂载配置目录 docker run -d --name nginx-redirect-test \ -p 8080:80 \ -v /opt/nginx-redirect-test/conf.d:/etc/nginx/conf.d:ro \ -v /opt/nginx-redirect-test/html:/usr/share/nginx/html:ro \ nginx:1.25-alpine然后本机hosts文件里加上两行让实验域名指向本机127.0.0.1 www.oldsite.test 127.0.0.1 www.newsite.test准备工作做好之后所有测试都可以用curl来验证。这里有个特别重要的细节看重定向必须用curl -I或者curl -v不能只用curl。为什么普通curl默认不会输出HTTP状态行和Location响应头你根本看不到重定向去了哪里、状态码是301还是302。而curl -I发送HEAD请求直接展示响应头curl -v则会把整个请求和响应过程完整打出来包括DNS解析、TLS握手、请求头、响应头。我平时排查重定向问题最常用的就是curl -v。从这篇开始后面所有示例我都会给出对应的curl验证命令方便你一边看一边抄着跑。3. 核心语法对比rewrite指令的重定向玩法Nginx中最传统的重定向手段是rewrite指令。它的完整语法是rewrite 正则表达式 替换内容 [标志位];rewrite干的事情是用正则去匹配$uri注意是不含参数的路径部分如果匹配到了就把URL重写成新的地址。后面跟的标志位决定重写完之后下一步干什么。3.1 最基础的URL结构改写先看一个最常见的需求把旧的/news/2023/xxx.html这种带日期的路径改成/articles/xxx这种语义化路径。server { listen 80; server_name www.oldsite.test; location /news/ { rewrite ^/news/(\d{4})/(.*)\.html$ /articles/$2 permanent; } }理解这条规则有个关键点替换内容里的$1、$2对应正则表达式里第1、第2个括号捕获的内容。(\d{4})捕获年份(.*)捕获文件名部分.html前面的点号在正则里是任意字符的意思所以必须写成\.。虽然我们这里捕获的年份没用到但保留分组能提高匹配精度避免把不合理的路径也吞进来。permanent标志位表示返回301。如果你想保留旧URL继续访问但内容换成新的用redirect标志位返回302。实际业务里临时性切换其实很少见大多数场景都用permanent。验证命令curl -v http://www.oldsite.test:8080/news/2024/nginx-redirect-guide.html正常情况下你会看到HTTP/1.1 301 Moved PermanentlyLocation头指向http://www.oldsite.test:8080/articles/nginx-redirect-guide。注意这里的301跳转后会重新请求同一个server里对应的新路径如果没有/articles/的匹配规则就会落到location /或404。所以写重定向规则的时候一定要想清楚跳过去之后由谁接盘。3.2 rewrite标志位last、break、redirect与permanent的区别rewrite有四个标志位很多人一开始搞不清楚区别导致配置行为完全不符合预期。我一个个说。redirect返回302临时重定向。浏览器地址栏会变成新URL以后再来还是先访问旧URL。permanent返回301永久重定向。浏览器会记住这个跳转下次直接访问新URL不再请求旧地址。last停止处理当前rewrite指令集但会重新发起一轮location匹配拿着改写后的URI去匹配新的location。这是内部跳转浏览器地址栏不变。break停止处理当前rewrite指令集不会再重新匹配location直接在当前location里继续执行后续处理比如proxy_pass或try_files。last和break都不是HTTP重定向而是Nginx内部的URI改写。它们的区别非常微妙我用一个实际例子说明。假设有这样的配置server { listen 80; server_name www.oldsite.test; location /old/ { rewrite ^/old/(.*)$ /new/$1 last; # 这一行不会执行 return 403; } location /new/ { return 200 new location reached\n; } }当请求/old/123时last会把URI改成/new/123然后重新走location匹配流程最后命中location /new/返回200。如果换成break请求会停留location /old/里后面的return 403仍然会执行最终返回403。这一点在实际配置中经常引发诡异现象明明写了rewrite跳转却不生效或者走到了完全不该走的逻辑。你排查时第一反应应该就是检查标志位到底是last还是break。3.3 rewrite和return混用时的执行顺序陷阱Nginx的一个隐蔽行为是如果同一层级里同时存在rewrite和returnrewrite会先执行return后执行。但这并不代表return一定会执行——因为rewrite一旦命中Nginx会按照标志位先去完成后续动作return是否有机会执行取决于标志位。server { listen 80; server_name www.oldsite.test; location /conflict/ { rewrite ^/conflict/(.*)$ /new/$1 last; return 301 http://www.newsite.test/blocked; } }上面的配置return 301看似会跳到newsite.test但由于rewrite ... last的存在请求最终会走location /new/的内部逻辑return根本轮不到。这种看起来互相矛盾的配置在实际维护中就是隐患。我的建议是同一个location里重定向需求要么全用rewrite、要么全用return尽量不要混用。混用会导致可读性急剧下降后人维护时往往要靠猜。4. 更推荐的方案用return指令做精准跳转rewrite擅长的是URL结构改写但如果你只是想把一个地址跳转到另一个地址尤其是跳往完整的外部URLreturn是更优解。原因有三点return语法简单直接不涉及正则捕获可读性强。return支持直接指定状态码和跳转目标不需要额外的重写后再匹配流程性能开销更小。return可以配合变量拼接目标URL灵活性反而更好。return有两种常用写法# 写法一直接跳转到固定URL return 301 http://www.newsite.test$request_uri; # 写法二不带URL只返回状态码配合error_page显示自定义页面 return 404;$request_uri这个变量在重定向场景里尤其顺手。它包含原始请求的完整URI和查询参数用它可以轻松实现旧域名整站搬迁到新域名路径保持不变的效果。4.1 整站域名迁移的完整配置域名迁移是重定向需求里最典型的一类配置不复杂但细节决定成败。下面这份配置我用了很久稳得很。server { listen 80; server_name www.oldsite.test; # 保留路径和查询参数跳转到新域名 return 301 http://www.newsite.test$request_uri; } server { listen 80; server_name www.newsite.test; location / { root /usr/share/nginx/html; index index.html; } }关键点就是$request_uri。它把用户访问的完整路径包括/a/b.html?x1这种带参数的原封不动地拼到新域名后面。这样用户从旧链接点击进来落地到新域名后看到的还是同一个页面体验完全不割裂。验证方法curl -v http://www.oldsite.test:8080/old/path?namenginx你会看到响应头HTTP/1.1 301 Moved Permanently Location: http://www.newsite.test:8080/old/path?namenginx这里的8080端口会出现是因为实验环境端口映射的关系。生产环境如果域名走标准80端口Location头就不会带端口号因为Nginx默认会用当前请求的端口来构造绝对URL。这个细节后面讨论绝对URL和相对URL时再展开。4.2 return配合error_page处理403/404的业务化跳转return还有一个高级用法配合error_page做访问被拒绝后跳转到登录页的逻辑。很多后台系统的权限控制会这么做未登录用户访问受限资源时先返回302或401然后把他引导到登录页。server { listen 80; server_name www.oldsite.test; location /admin/ { # 简单模拟未登录判断专业场景应该用auth模块或Lua脚本 if ($cookie_session ) { return 302 http://www.oldsite.test:8080/login; } proxy_pass http://backend_admin; } location /login { return 200 this is login page\n; } }这里用的是if加上判断cookie的方式做拦截。Nginx官方的if指令被戏称为邪恶的if因为它的指令执行模型和普通编程语言不一样在location里乱用if容易出问题。但如果你只是用它做判断后return这类简单动作是安全的。记住一个原则if里尽量不要放proxy_pass、rewrite这类复杂指令只放return。验证命令可以先用无cookie的请求试试curl -v http://www.oldsite.test:8080/admin/dashboard预期会返回302Location指向/login。这种用302做临时引导的方式很适合登录失效跳转、活动页面过期提示等场景。4.3 强制HTTP跳HTTPS虽然现在全站HTTPS已经很普遍了但时不时还能碰上HTTP和HTTPS并存导致双重登录失效的站点。最简单的解决方案就是在HTTP的server块里无脑301到HTTPS。server { listen 80; server_name www.oldsite.test; return 301 https://www.oldsite.test$request_uri; } server { listen 443 ssl; server_name www.oldsite.test; ssl_certificate /etc/nginx/certs/fullchain.pem; ssl_certificate_key /etc/nginx/certs/privkey.pem; }这个配置的精髓还是$request_uri保证HTTP请求跳HTTPS后路径参数不丢。如果你用的是云厂商的负载均衡LB做TLS卸载后端Nginx只监听80跳HTTPS的工作通常在LB那层就做掉了Nginx里一般不需要再加这一层避免出现HTTP/HTTPS循环跳转的诡异问题。这个我后面专门讲。5. 跨域跳转与绝对URL的边界问题重定向并不总是在同一个域名下进行。跨域跳转很常见微信扫码后的redirect_uri、第三方支付回跳、联盟推广落地页全都是跨域重定向。跨域跳转有几个坑我一个个说。5.1 不带协议和域名的Location头会怎样Nginx的return指令如果只写路径不写完整URL比如return 301 /new-page;Nginx会基于当前请求的Host和协议拼出一个绝对URL。如果Host头是www.oldsite.test:8080那Location就是http://www.oldsite.test:8080/new-page如果Host缺失Nginx会使用server_name配置。所以你在配置里写的/new-page最终响应给客户端的其实是一个完整的绝对URL。这对浏览器没影响因为浏览器消费的是Header里的Location值绝对相对都能处理。但对程序化访问比如一些老旧的支付SDK回调可能就有影响它们会严格校验Location必须以http://开头。所以如果你对接的外部系统对Location头有硬性要求最好在配置里直接写完整的协议域名不要依赖Nginx的自动拼接。5.2 302和301在跨域场景里怎么选跨域跳转时302和301的选择比很多人想象中更讲究。301永久性跳转浏览器和搜索引擎都会记住这个结果。下次再访问旧地址浏览器会直接跳到新地址不再请求旧地址。如果你的旧域名确实不用了用301。302临时性跳转每次访问旧地址都会先请求旧地址然后服务端再指示跳转到新地址。适合登录跳转、短链跳转、A/B测试这类临时行为。有个真实的教训我之前帮一个客户处理域名变更他图省事全用了301。结果后来域名解析管理权交接出了问题想改回旧域名发现浏览器里缓存的全是301跳转结果用户被死记到新域名怎么改都不生效非常被动。我的经验是不确定是否永久性的跳转先上302观察一段时间。等确认新域名稳定了再切换成301让搜索引擎把权重正式转移过去。5.3 Nginx是返回301还是302取决于什么其实Nginx本身不纠结它就是按return后面的状态码原样返回。纠结的是业务语义。我给你梳理了一张表日常基本够用场景推荐状态码原因域名永久迁移301通知搜索引擎权重转移HTTP强制跳HTTPS301属于永久性规则URL规范化加/去www301长期一致登录失效引导302临时行为下次还需再跳活动页过期302临时行为短链还原302短链跳转目标可能变化设备适配跳转302不同设备不同页面需实时判断6. 动态场景按设备、来源、Cookie条件跳转前面讲的都是静态规则——所有请求都跳同一个地方。但真实业务里大量重定向是条件性的手机用户跳H5站微信内置浏览器跳微信授权特定来源的请求跳特定落地页。这类场景的核心就是if加变量的组合。6.1 移动端与PC端自动分流最常见的场景检测到移动端User-Agent就把用户跳转到m.子域名。server { listen 80; server_name www.oldsite.test; # 移动端正则匹配 set $is_mobile 0; if ($http_user_agent ~* (Mobile|Android|iPhone|iPad|Windows Phone)) { set $is_mobile 1; } if ($is_mobile 1) { return 302 http://m.newsite.test$request_uri; } # 桌面端继续处理 location / { root /usr/share/nginx/html; index index.html; } }这里有两层if但我只用它干了设置变量和return这两件事都是安全用法。正则里的~*表示大小写不敏感匹配因为真实UA里可能是iPhone也可能是IPHONE。匹配规则写得越具体越好不要用那种什么设备都匹配的宽泛正则否则桌面浏览器也容易被误伤。6.2 防盗链与来源控制跳转用$http_referer做来源判断也很常见。有的站点会做仅允许站内和搜索引擎来源访问图片/视频其他来源一律跳转到一个提示页。server { listen 80; server_name www.oldsite.test; location /images/ { # 正常的来源域名列表 valid_referers none blocked server_names *.newsite.test www.oldsite.test; if ($invalid_referer) { return 302 http://www.oldsite.test:8080/anti-hotlink.html; } root /usr/share/nginx/html; } }valid_referers是Nginx自带的防盗链模块$invalid_referer变量会被自动设置成1。none允许空Referer直接输入URL访问或下载工具请求blocked允许掉Referer但格式非法的请求server_names允许本站域名。这个配置在图片站、视频站、附件下载场景里非常实用。不过现在很多站点防盗链策略已经改成不跳转直接返回403了。因为跳转本身会给盗链者留一个落地页曝光反而帮了倒忙。如果你不介意别人知道这个资源来自哪个站点跳转没问题如果想严格限制直接return 403;更干脆。6.3 Cookie定向跳转灰度发布与区域分流Cookie定向跳转最常见的应用场景是灰度发布。我们曾经做过一次活动页改版方案是用户cookie里带有exp1标记的走新版页面其他用户走旧版页面。用return实现server { listen 80; server_name www.oldsite.test; location /promo/ { # 判断是否灰度标记 if ($cookie_exp 1) { return 302 http://www.oldsite.test:8080/new-promo$request_uri; } # 非灰度用户继续走旧版 proxy_pass http://old_promo_backend; } }$cookie_exp就是Nginx自动解析Cookie里exp字段并赋值给变量的结果不需要额外配置模块。把这类功能做进Nginx层好处是不用动应用代码上线和回滚都只改配置就行。7. try_files另一种容易被忽略的重定向try_files严格来说不是重定向指令但它产生的外部效果常常和重定向相似而且在SPA应用、静态资源防404、伪静态支持这些场景中比rewrite更顺手。try_files的语法是try_files file1 file2 ... uri_or_code;它按顺序检查每个文件是否存在如果存在就用它处理请求如果都不存在就执行最后一个参数可以是一个内部跳转的URI也可以是404这种状态码。7.1 单页应用SPA的history路由回退SPA应用用history模式时用户直接访问/user/123这种深层路径服务器上并没有对应的物理文件传统做法是写一堆rewrite规则把请求重写到index.html。用try_files一行搞定server { listen 80; server_name www.oldsite.test; root /usr/share/nginx/html; location / { try_files $uri $uri/ /index.html; } }含义很清晰先看$uri对应的物理文件在不在在就直接返回再试目录形式$uri/都没有就把请求URI重写成/index.html由前端路由去处理。这里其实是内部重写浏览器地址栏不变状态码是200。但要注意这种回退到index.html的方式只适用于SPA如果你的站点是传统多页应用这样做会把404全部变成200SEO直接废掉。7.2 用try_files做伪静态跳转另一个常见用法是把带查询参数的老式动态URL重写成伪静态路径。比如动易CMS时代遗留的/show.php?id123想改成/detail/123.htmlserver { listen 80; server_name www.oldsite.test; location / { # 捕获数字id if ($args ~* ^id(\d)$) { set $detail_id $1; return 302 /detail/$detail_id.html; } try_files $uri $uri/ 404; } location ~ ^/detail/(\d)\.html$ { return 200 detail page for id$1\n; } }这个例子把if、set、return和try_files组合在一起模拟了一个老链接跳新地址的场景。$args变量保存查询参数内容正则捕获的ID存入$detail_id再拼成新的伪静态URL。虽然这种写法不推荐在生产环境直接照搬正则和if的组合可读性差但理解它的逻辑对排查别人的历史配置很有帮助。8. proxy_pass联动反向代理场景下的路径清洗Nginx最常见的身份是反向代理。你代理后端服务时常常需要处理路径问题前端请求的URL路径和后端服务的真实路径不一致这时候就需要路径改写或者让代理过程配合重定向一起工作。proxy_pass有两种写法行为差异极大很多人踩过坑。8.1 不带URI的proxy_pass原样转发server { listen 80; server_name www.oldsite.test; location /api/ { proxy_pass http://backend_upstream; } }注意proxy_pass后面只有IP/域名没有路径。这种写法下Nginx会把原始请求的完整URI原封不动地转发给后端包括/api/前缀。如果后端服务是按照/api/前缀来路由的这种配置没问题。8.2 带URI的proxy_pass路径被替换server { listen 80; server_name www.oldsite.test; location /api/ { proxy_pass http://backend_upstream/v2/; } }这里proxy_pass带了一个/v2/路径Nginx会把location /api/匹配到的那部分前缀替换成/v2/。比如原始请求是/api/users/list代理到后端就变成/v2/users/list。这是最常用的去掉前缀的做法路径改写在这儿就完成了。这里有一个历史悠久的坑proxy_pass带URI时如果location用的是正则或者路径里包含$变量那proxy_pass里的URL不能包含URI部分。Nginx会在启动时直接报错nginx: [emerg] proxy_pass cannot have URI part in location given by regular expression我见过不少同事在这个报错上卡了半小时最后才发现是正则location和proxy_pass带URI冲突所致。解决办法很简单正则location里的proxy_pass要么不带URI路径要么如果有动态路径需求在proxy_pass里用变量拼。8.3 后端返回重定向时的相对/绝对地址处理代理场景还有个隐蔽问题后端应用返回的响应里可能包含Location头但这个Location头的地址是相对路径或者写死了后端自己的域名。Nginx默认不修改后端返回的Location头直接透传。这会导致什么样的混乱我举个真实案例。后端Java应用本来跑在http://backend_upstream:8080应用里写死了支付回调地址http://backend_upstream:8080/pay/callback。前端通过Nginx代理访问Nginx对外域名是www.oldsite.test。用户发起支付后后端返回302跳转到http://backend_upstream:8080/pay/callback浏览器收到这个响应后会尝试直接访问backend_upstream:8080这个内网地址——结果自然是无法访问甚至可能把后端服务的真实内网IP暴露出去。这种坑的修复方式通常是后端应用代码不做绝对地址只返回相对路径由代理层拼完整地址。或者在Nginx中用proxy_redirect指令把Location头改写。location /api/ { proxy_pass http://backend_upstream; proxy_redirect http://backend_upstream:8080 http://www.oldsite.test; }proxy_redirect的作用就是改写上游返回的Location和Refresh头。第一个参数匹配上游返回的地址前缀第二个参数替换成对外可访问的地址。这是反向代理场景维护中比较隐蔽但又非常关键的配置项。9. 绝对URL中一个容易被忽略的细节端口问题回到前面实验环境里那个问题为什么Location头里会带8080端口这个其实取决于Nginx在构造绝对URL时的默认行为。return和rewrite构造URL时Nginx会把当前请求的Host头作为主机名端口用当前请求的端口。上面实验里我们访问的是http://www.oldsite.test:8080所以重定向目标自然带上8080。生产环境的特殊情况出现在SSL终结在ELB/LB层的架构里。假设外部用户访问https://www.newsite.testHTTPS流量在负载均衡器上被解密然后转成HTTP转发给后端Nginx的80端口。这时候Nginx看到的请求端口是80它会认为当前协议是HTTP构造出的Location头可能是http://www.newsite.test/...——把HTTPS变成了HTTP你就踩进了HTTPS跳HTTP的大坑。解决这类问题通常有两个方向方向一在Nginx侧手动指定协议和端口。server { listen 80; server_name www.oldsite.test; return 301 https://www.newsite.test$request_uri; }只要return目标里写死了协议Location头就是https://开头和当前请求协议无关。这就是为什么我建议所有HTTPS跳转配置都显式写协议不要依赖Nginx自动拼接。方向二设置absolute_redirect指令。Nginx从1.19.4版本开始提供了absolute_redirect可以控制是否生成绝对URLserver { listen 80; server_name www.oldsite.test; absolute_redirect off; location /old { return 301 /new; } }关闭后Location头会变成/new这样的相对路径。浏览器依然能正确跳转同时也避免了协议被降级的问题。这个指令在走LB的架构里特别好用但也有兼容性要求过老的客户端比如某些Android WebView历史版本对相对Location支持不佳。所以到底是开还是关要结合你的用户端情况判断。10. alias与root的重定向陷阱再讲一个非常容易踩的实际问题root和alias下访问目录时Nginx自动补斜杠导致的重定向行为差异。在Nginx里如果访问一个目录而你的location配置对应的物理路径末尾没有/Nginx会返回301把URL末尾补上斜杠。这个是浏览器目录访问的常规行为不用太担心。问题出在alias场景下补出的斜杠位置可能不对。# 正常root写法 location /download/ { root /data/www; }请求/download时Nginx会301跳转到/download/因为/data/www/download是目录Nginx自动加了斜杠。Location头是http://www.oldsite.test:8080/download/符合预期。再看aliaslocation /download/ { alias /var/files/store/; }有的老配置写alias时末尾没有斜杠请求/download时Nginx跳转后可能生成/download/store/这种错误路径。根源是alias在做目录斜杠补全时拼接了错误的物理路径表达式。这类问题很难通过日志定位因为请求本身成功了只是URL变了。我的建议是alias路径一律以斜杠结尾且location前缀也保持以斜杠开头、以斜杠结尾的写法保持对称。这个习惯能规避掉一大半alias相关的路径跳转问题。11. 必须知道的几个Nginx重定向运维注意点11.1 重写循环配置一时爽排错火葬场重定向配置最大的噩梦就是循环跳转。/a跳到/b/b又跳回/a用户浏览器疯狂刷新直到报错too many redirects。最常见的循环诱因是两个location互相匹配location /old { rewrite ^/old(.*)$ /new$1 permanent; } location /new { rewrite ^/new(.*)$ /old$1 permanent; }这种配置一眼就能看出问题。但更多循环是隐性的你配了HTTP跳HTTPSHTTPS的server里又强制把www前缀去掉结果某个URL在http://oldsite和https://newsite之间来回跳。排错方法只有一个笨办法用curl -v一路跟着看设置-L跟随重定向但逐条打印Location头或者用curl --max-redirs 5限制最大跳数快速定位循环节点。11.2 验证配置三步走修改重定向配置后标准的验证路径是检查配置文件语法nginx -t -c /path/to/nginx.conf先确认配置本身没有语法错误。热加载配置nginx -s reload平滑加载不中断现有连接。多场景curl验证分别测HTTP状态码、Location头、关键URL和参数确保没有意外重走。我在生产环境做任何重定向变更都会先备份原配置然后小范围切换比如只改一台机器用真实流量观察一两天再全量放。重定向这个事儿影响的是整个访问链路宁可慢不可错。11.3 错误配置导致SEO权重分流的经典案例很多站长意识不到同一URL在www和非www之间没有重定向收敛Google会认为这是两个站点。收录有www版本也收录无www版本外链也可能分散到两个版本上权重白白流失。解决方案很简单选一个主域名另一个301过去server { listen 80; server_name oldsite.test; return 301 http://www.oldsite.test$request_uri; } server { listen 80; server_name www.oldsite.test; # 正常业务配置 }这个收敛动作做完再去搜索引擎的站长平台提交站点地图让蜘蛛重新抓取一遍通常几周内权重会逐渐集中到主域名上。如果站点已经从HTTPS迁移过那同样要把http://版本的流量收敛到https://版本。12. 最后Nginx重定向排查的通用套路聊了这么多具体配置最后总结一下我平时排查重定向问题的工作流。遇到为什么跳转不对的报障我几乎从不直接改配置而是先做这几步第一步用curl -v完整打印一次请求响应拿到真实的HTTP状态码和Location头。很多人头疼的问题在第一步就能定位——比如目标地址写错、端口丢失、协议降级、循环跳转。第二步把外部域名和内部配置对应起来。用nginx -T大写T把当前加载的全部配置打印出来搜索报障域名相关的server块逐条核对server_name、location、rewrite、return规则。第三步打开Nginx的access log按域名和时间段过滤请求看实际请求命中了哪个server块、返回了什么状态码。日志里能看到Nginx实际落地的规则是哪个这比人肉推断可靠得多。第四步如果是代理链路的问题还要在proxy_pass后面的上游服务的access log里找线索确认请求有没有到达后端、后端返回了什么。这套流程跑下来大部分重定向疑难杂症都能定位。重定向配置不复杂复杂的是它处在用户入口和后端资源之间的关键链路上任何一个环节理解错了表现都很诡异。配置文件写得再漂亮不如把请求从进入到响应返回的完整链路吃透。希望这篇里那些踩坑案例和验证手段能让你下次碰到重定向问题时少走几步弯路。
