浏览器提示重定向次数过多，常见链路是旧 URL 301 到新 URL，新 URL 又被 Store、后缀或 Web 规则改回旧地址。删除全部 url_rewrite 可能让大量既有链接失效，应先画出每一跳是谁返回的。

先固定复现条件和影响范围

用 curl 保存 Location 链、状态码、Host、协议和 Set-Cookie，分别绕过 CDN 请求源站。确认循环只发生在某个 Store View、登录状态或特定商品分类。

curl -skIL --max-redirs 12 https://shop.example.com/old-path.html
SELECT url_rewrite_id,entity_type,entity_id,request_path,target_path,redirect_type,store_id,is_autogenerated
FROM url_rewrite
WHERE request_path IN ('old-path.html','new-path.html')
   OR target_path IN ('old-path.html','new-path.html')
ORDER BY store_id,url_rewrite_id;
php bin/magento config:show web/url/use_store
php bin/magento config:show catalog/seo/product_url_suffix

根据证据分支定位

数据库两条 301 互相指向，属于重写链冲突；Magento 只返回一次，后续由 Nginx/CDN 改回，则检查尾斜杠、HTTP 到 HTTPS 和 www 规范化；不同 Store Code 互跳时，检查 Base URL、Cookie 与 Store Resolver。

修复时保留回滚路径

保留唯一规范 URL和最多一条从旧地址到规范地址的 301，通过后台实体保存或受控数据补丁修复。修改 Web 规则时一次只统一一个维度，并在 CDN 清除精确 URL；不要把所有 404 广泛重定向到首页。

上线验收

检查旧地址一次 301 后到达 200，新地址直接 200；HTTP、HTTPS、www、非 www、带 Store Code 和无 Store Code 都不能形成第二条反向跳转。同步验证 canonical、Sitemap 和内部链接。

生产环境操作前的检查

处理“Magento 2 URL Rewrite 出现循环重定向”前，先记录 Magento 版本、部署模式、问题 Store View、复现时间和最近一次发布。所有 SQL 默认先执行 SELECT；任何写操作、目录清理或配置切换都应确认影响范围、保留备份并准备回滚。多节点环境要核对各节点代码版本、app/etc/env.php 配置摘要与流量分布。

php bin/magento --version
php bin/magento deploy:mode:show
php bin/magento maintenance:status
php bin/magento indexer:status
php bin/magento cache:status

命令应由 Magento 文件所有者在项目根目录执行。不要在生产高峰同时运行全量索引、静态部署和数据修复；涉及客户、支付、税费或订单的改动，先在脱敏数据副本验证。

建立可比较的排查记录

每次实验只改变一个变量，记录操作前值、命令、开始与结束时间、结果和回滚方式。准备一个正常对象与一个异常对象对照；若旧对象恢复而新对象仍能复现，说明根因尚未消除。

检查层需要保存的证据通过标准
入口层 URL、状态码、请求 ID、节点 路由和协议一致
应用层 异常堆栈、模块、作用域 无新异常且可重复
数据层 主键、时间、关联行数 关系完整且无重复副作用
业务层 正常、失败、重试路径 最终结果一致

修复后的观察窗口

上线后至少观察一轮 Cron、队列和索引周期，并在两台节点、无痕浏览器和目标 Store View 重复验证。临时调试日志必须脱敏，确认错误率、响应时间和数据量稳定后及时关闭。