一排 301 让我紧张过

第一次在测速结果里看到状态码一列几乎全是 301，我以为站点出问题了，转头就去翻 Nginx 配置。后来才弄明白，301 是永久重定向，它不是错误，只是告诉请求方「你要的这个地址，请换个地方拿」。

所以要判断的从来不是「有没有 301」，而是「这个跳转是不是我有意配的、它跳得干不干净」。

有些 301 本来就不该动

http 跳 https、带 www 跳主域、老域名换新域名，这些都属于规范化跳转。只要落点是自己的站、协议和域名符合预期，测速里看到 301 反而是配置正确的表现。

用宝塔拨测的网站测速的时候，我习惯 http 和 https 各跑一次。http 返回 301、落点是 https 的同一路径，这条链路就是通的；如果 https 本身也返回 301，那就要看它到底跳去了哪里。

真正该处理的是这几种

一是跳转链太长，A 跳 B、B 又跳 C，每多一跳，用户和爬虫就多等一轮。二是落点不对，跳到别的域名、旧路径甚至错误页。三是循环跳转，两个地址互相指，最后只能超时。这几种在状态码那一列看都是 3xx，性质却完全不同。

判断方法很土但有效：看跳转后的最终地址是不是你预期的那个，路径有没有变，参数有没有丢。这比盯着状态码本身有用得多。

还有一种容易被忽略的情况：落点是对的，但返回的是 302 临时重定向。浏览器和爬虫每次访问都得重新问一遍，这种持续性跳转其实更应该用 301。

跳转的代价藏在耗时里

同域跳转只是多一次请求；跨域跳转等于重新走一遍 DNS 解析、TCP 连接和 TLS 握手。这时候五段耗时就很有说服力：要么首字节时间被拉长，要么多出一段解析和握手的时间。

所以看到 301 又觉得慢，别只看总时长。拆开看多出来的时间花在哪一段，就能分清是跳转本身的问题，还是落点那台机器慢。

用节点分布和复测定范围

如果只有个别地区返回 301，其他节点都正常，更像是 DNS 解析不一致或者 CDN 边缘配置没同步；如果所有节点一起 301，说明源站配置本来就是这样，属于全局行为。

我一般会连续复测两三次，再看按运营商和地区分组的结果。平均、最快、最慢摆在一起，能看出是稳定跳转还是偶尔抽风。稳定复现的才值得改配置，偶发一次的先放一放。

我的处理标准

自己配的规范化跳转，留着；跳转链超过一跳的，合并成一跳；落点不对或者成环的，立刻查配置。改完再复测一轮，看状态码有没有变成 200、那一段耗时有没有降下来，才算真正处理完。