网站改版、换域名、从 http 迁到 https，都会用到 301 重定向。规则写错时，你看到的是后台反复跳转、旧链接打不开、搜索结果里仍是旧地址。这篇文章教你按虚拟主机环境把 301 一次配对，并给出六类常见错误的排查命令。
301 表示永久搬迁，搜索引擎会把旧地址的权重转到新地址；302 表示临时变动。选错类型比写错规则更难补救，因为浏览器会长期缓存 301 的结果。
先判断：哪些场景要用 301
旧域名整站搬到新域名、http 全站切到 https、旧页面并入新的内容页，这三类用 301 是合适的；活动页、A/B 测试、维护停站要用 302 或 307。判断标准很简单：三个月后你仍希望这个地址指向新页面，就用 301；只要存在恢复的可能，就别用永久跳转。
配置前必须确认三件事
文件权限：多数虚拟主机面板（例如 Hostease 的共享主机方案）默认隐藏 .htaccess，需要在文件管理器里勾选“显示隐藏文件”确认它存在且可写。文件不存在就新建一个空文件再写规则，不要覆盖整个文件，否则面板生成的安全规则会被一起清掉。
站点地址：WordPress 的站点地址在“设置 → 常规”里，优先级高于 .htaccess。地址还是 http:// 时，写多少跳转规则，后台登录都会在 http 与 https 之间来回弹。先把两个地址都改成最终形态，再处理跳转。
解析与证书：DNS（域名解析系统）的 A 记录要指向当前主机，SSL（安全传输协议）证书要已经生效，否则跳到 https 只会得到一个告警页。用 dig +short www.example.com 和 curl -I https://www.example.com 各确认一次，两项都通过再动手。
方法一：Apache 与 LiteSpeed 的 .htaccess 写法
共享主机多数跑 Apache 或 LiteSpeed，两者都读 .htaccess。规则要按“统一协议与域名 → 单页 → 目录通配”的顺序写：
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]
Redirect 301 /old-page.html https://www.example.com/new-page.html
RedirectMatch 301 ^/old-category/(.*)$ /new-category/$1
[L] 不能省。它让请求在第一次匹配后立刻带 301 返回；省掉之后程序会继续匹配后面的规则，一个请求被改写两次，浏览器就看到两跳。RedirectMatch 里的 (.*) 与 $1 必须成对出现，否则 /old-category/a/b.html 会被压成 /new-category/，内页全部 404。
方法二：Nginx 与面板环境的等价配置
Nginx 不读 .htaccess，必须在站点配置里写 server 块，整站强制 HTTPS 的标准写法是给 80 端口单独开一段：
server {
listen 80;
server_name example.com www.example.com;
return 301 https://www.example.com$request_uri;
}
$request_uri 保留原始路径和查询参数，$uri 只保留解码后的路径。整站迁移必须用前者，否则带 ?utm_source= 的推广链接跳转后参数全丢，投放数据对不上。面板上的“强制 HTTPS”开关生成的就是这段配置，开了就别在 .htaccess 里重复写，两层同时生效等于每个请求跳两次，首屏白白多花几百毫秒。
方法三：WordPress 站点的处理顺序
WordPress 自带 redirect_canonical 规范化跳转，叠加自定义规则最容易出循环。顺序应是：先改两个站点地址，再改固定链接结构，最后才动插件或 .htaccess。
固定链接换结构后旧链接不会自动跳转，用 Redirection 插件按正则批量建规则，并打开 404 记录观察旧地址。插件规则与 .htaccess 同时存在时以先命中的那层为准，迁移完成后删掉重复的一条。
静态 HTML 站迁到 WordPress，可以用 RedirectMatch 301 ^/([^/]+)\.html$ /$1/ 按同名映射；slug 与新站不一致的部分必须逐条列出，硬套通配会让一批页面跳到错误内容，比 404 更难发现。
六类高频错误与对应改法
1. 循环重定向：浏览器报 ERR_TOO_MANY_REDIRECTS
规则自己指向自己是最常见的原因：RewriteRule ^(.*)$ https://www.example.com/$1 的目标又被另一条规则改回原地址。用 curl -I 看 Location 头，地址开始重复就是循环；修复时把协议、域名、路径合成一条规则判断。
2. 跳转链过长：一次访问跳三四次
http://example.com → http://www.example.com → https://example.com → https://www.example.com，四跳才到终点，通常是面板开关、插件规则、.htaccess 各写了一条。跨境访问单跳要 150 到 300 毫秒，四跳就把首屏拖慢近一秒。用 curl -sIL --max-redirs 10 -o /dev/null -w '%{num_redirects}' 确认只剩一跳。Apache 换成 Nginx 后规则失效也常表现为长链，可对照迁移时的配置差异。
3. 只配首页，内页全部 404
只写 Redirect 301 / https://new.example.com/，所有内页都会落到新站首页，被判定为软 404，原有排名一起消失。正确做法是用 RedirectMatch 按路径映射，或在新站建立同名 slug 后整段搬过去。
4. 临时跳转误用了 301
301 会被浏览器和中间缓存长期记住，活动结束后即使删掉规则，访客仍被送到已下线的页面。临时场景要用 302 或 307；已经误用的只能在原地址重新返回 200 内容，等缓存自然过期。
5. www 与协议交叉跳转
站点的规范地址只能有一个。证书只签了 example.com 却把 www.example.com 设为规范地址，会先出现证书告警再跳转；页面里仍写 http:// 的资源地址，浏览器会拦下混合内容。需要长期强制 HTTPS 时，跳转稳定后再追加 HSTS（强制安全传输策略），写法见HSTS 配置与预加载列表，但预加载提交后无法快速回退，务必先确认所有子域都支持 https。
6. 内容分发层与源站各跳一次
在 CDN（内容分发网络）上开了“始终使用 HTTPS”，源站又写了同一条规则，用户看到的就是两跳。更麻烦的是缓存：边缘节点会把源站返回的 301 缓存下来，源站规则改了以后，边缘仍在返回旧跳转。顺序是先清边缘缓存，再验证源站响应，最后才动边缘规则；搬站时先降低 TTL 再切解析，可参考解析切换期间的零停机做法。
三步定位：用 curl 看清跳转到底发生了什么
第一步看单次响应，不做跟随：curl -I -s -o /dev/null -w '%{http_code} %{redirect_url}' https://example.com/old-page.html。返回 200 说明规则没匹配上，先查 RewriteEngine 是否开启。
第二步跟随全链：curl -sIL --max-redirs 10 -o /dev/null -w '%{url_effective} %{num_redirects}'。跳转次数大于 1 就按第 2 条收敛，加 -v 能看到每次响应的 Location 头，循环重定向会在这里暴露成重复地址。
第三步看落点内容：200 但标题与旧页无关，等于把权重送给了错误页面；落点 404 说明映射写错。把三步写成脚本，迁移当天对旧站清单跑一遍即可。
上线前要过的五项检查
- 规范地址唯一：http 与不带 www 的组合都只跳一跳
- 内页抽查 20 条旧地址，落点 200 且标题匹配
- 证书与解析：
curl -I https://无告警，dig指向当前主机 - 缓存已清：边缘缓存与浏览器缓存清空后复验
- 监测就位：Search Console 提交地址变更，连续观察 404 报告两周
总结与行动建议
301 重定向的难点不在语法，而在“只留一条路径”。建议按这个顺序动手：确认证书与解析到位、把站点地址改成最终形态、写一条收敛规则、用 curl 全链验证、最后清缓存复验。
共享主机只能改 .htaccess；访问量接近共享环境的资源上限时，跳转再精简也解决不了并发瓶颈，这时可以考虑迁移到 VPS（虚拟专用服务器），选型可先看按流量规模与运维成本判断。改完后观察两周的抓取与 404 报告，旧地址收敛、新地址正常收录，迁移才算结束。文中的套餐与价格信息以官网实时标注为准（截至 2026 年 10 月）。