Apache RewriteRule死循环源于匹配与跳转逻辑闭环，导致内部重定向超限（默认10次）而报500或空响应；需通过错误日志识别线索、针对性加条件阻断循环，而非删规则。
apache 的 rewriterule 死循环不是“规则写多了”，而是匹配与跳转逻辑形成闭环，导致请求被反复重写、内部重定向超过上限（默认10次），最终返回 500 错误或空响应。关键在于识别触发条件、切断循环路径，而不是盲目删规则。
看日志确认是否真死循环
先查错误日志，定位典型线索：
-
Request exceeded the limit of 10 internal redirects—— 这是 Apache 明确报出的死循环信号，说明RewriteRule+[R]或隐式内部跳转已超限； -
mod_rewrite: maximum number of internal redirects reached—— 同上，确认是 rewrite 层级问题； - 日志中同一请求反复出现相似重写路径（如
/index.php?/a/b/c→/index.php?/a/b/c/→ 再加斜杠…）—— 典型末尾斜杠/查询参数自增类循环。
常见死循环模式与对应解法
多数死循环来自三类设计惯性，改法直接且低风险：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
-
无条件重写到自身：比如在根目录
.htaccess中写RewriteRule ^(.*)$ index.php [L]，而index.php又未排除匹配，导致每次访问都再进一遍规则。→ 解法：加前置条件，如RewriteCond %{REQUEST_FILENAME} !-f和RewriteCond %{REQUEST_FILENAME} !-d，确保只对不存在的文件/目录才重写； -
带查询字符串的重复追加：例如
RewriteRule ^(.*)$ /$1?foo=bar [QSA,L]，[QSA]会把原参数和新参数叠加，第二次匹配时又加一遍，参数越滚越大。→ 解法：去掉[QSA]，或用[QSD]（Apache 2.4+）清空原始参数； -
伪静态后缀强制补全：如
RewriteRule ^(.*)$ $1.php [L]，但没判断$1.php是否真实存在，结果把about.php重写成about.php.php，再重写成about.php.php.php……→ 解法：必须配合RewriteCond %{REQUEST_FILENAME}.php -f做存在性校验。
用 RewriteLog 辅助追踪（仅调试阶段）
Apache 2.4 已弃用 RewriteLog，改用 RewriteEngine On + RewriteLogLevel 需换为模块化日志配置：
- 在虚拟主机或主配置中启用详细 rewrite 日志：
LogLevel alert rewrite:trace3（数值 3~6 可调，3 足够看匹配/跳转，6 会记每步正则捕获）； - 重启 Apache 后，错误日志里会出现逐行 rewrite 流程，例如：
[rewrite:trace3] ... applying pattern '^/blog/(.*)' to uri '/blog/post'[rewrite:trace2] ... rewrite '/blog/post' -> '/index.php?slug=blog/post'； - 观察哪一步开始重复、参数如何变化，比猜快十倍。
预防性习惯：加安全出口
所有生产环境的重写规则，建议默认带上两道保险：
- 开头加
RewriteCond %{ENV:REDIRECT_STATUS} ^$：过滤已被重写过的请求，避免二次进入； - 结尾加
RewriteRule ^ - [E=NO_REWRITE:1]并配合后续规则中的RewriteCond %{ENV:NO_REWRITE} !=1，实现手动标记跳过； - WordPress 类 CMS 的标准规则本身已含防循环逻辑，不要擅自删掉
RewriteCond %{REQUEST_FILENAME} -f等判断行。
