nginx 301重定向彻底清理死链需四步闭环：精准匹配（location = /old 和 ^~ /old/ 覆盖所有变体）、无参净化（if + $args 清理 page=1 等无效参数）、强制跳转（独立80端口server块，目标写死https://new.com$request_uri）、持续验证（curl -i 检查响应头、gsc监控重定向状态）。
彻底清理历史缓存死链、防止搜索引擎抓取报错，关键不是“清缓存”，而是让旧 URL 永久失效的同时，主动引导爬虫转向新地址——Nginx 的 301 重定向本身是手段，但必须配以精准匹配、无参净化、强制跳转和持续验证四步闭环。
精准匹配所有旧路径，不漏一条死链
别只写一条泛匹配规则，否则 /old/xxx 会跳，但 /old、/old/、/old/?ref=test 就可能 404。用组合方式全覆盖：
- 用 location = /old 处理裸路径（如
/old） - 用 location ^~ /old/ 处理带斜杠的前缀（如
/old/article、/old/?id=1） - 避免
if ($uri ~ ^/old)—— 易触发隐式重写、匹配失控
清除无效参数，只保留 SEO 友好参数
搜索引擎常因 ?page=1、?utm_source=xxx 把同一内容抓成多个 URL。Nginx 可在跳转时剥离特定参数：
- 对含
page=1的请求做规范化：用 rewrite 提取干净路径再 301 - 示例：
rewrite ^(/[^?]*)(\?.*)?$ $1? redirect;清除全部参数（慎用） - 更稳妥做法：
if ($args ~ "page=1(&|$)") { return 301 $scheme://$host$uri?; }—— 仅清除 page=1，保留 category=tech 等有效参数
强制 HTTPS + 写死目标域名，杜绝跳转链断裂
跳转链出错（比如 HTTP → HTTPS → 域名拼错 → 404）是死链主因。必须切断中间环节：
- 所有 301 配置放在 独立 listen 80 的 server 块中，不混入 HTTPS 配置
- 目标地址写死协议+域名，如
https://example.com$requested_uri，不用$scheme://$host - 若旧站已停用，直接 return 301 到新站，不要 proxy_pass 或 try_files 回退到本地 404
上线后持续验证，用工具代替浏览器直觉
浏览器缓存会让错误跳转“看起来生效”，实际爬虫看到的是另一套结果：
- 每天用 curl -I http://old-site.com/old-path 检查响应头是否为
HTTP/1.1 301 Moved Permanently且Location正确 - 用 Google Search Console 的「URL 检查」工具提交旧 URL，观察是否显示“已重定向至…”而非“未找到”
- 在日志中加
log_format redirect '$remote_addr - $request "$status" "$http_referer"';，监控 301 请求是否持续下降
