apache error_log 不监测但会在重写循环超限（默认10次）时记录“maximum number of internal redirects reached”等关键告警，配合调高loglevel、检查无终止规则及路径排除可高效定位与预防死循环。
Apache 的 error_log 本身不直接“监测”重写规则死循环，但它会在检测到重写循环时主动记录明确错误信息，这是诊断 mod_rewrite 死循环最直接、最关键的线索。
error_log 中识别重写死循环的关键日志条目
当 Apache 判断某请求在重写规则中超过默认迭代上限（通常为 10 次）时，会拒绝继续处理并写入错误日志。典型日志内容如下：
-
[rewrite:trace1] ... applying pattern '...' to uri '...' —— 这类 trace 日志需开启
RewriteLogLevel 3（旧版）或RewriteLog（已废弃），但不推荐用于生产环境 - [alert] [pid XXXX] mod_rewrite: maximum number of internal redirects reached —— 最权威的死循环证据，表示已触发安全保护机制
-
Request exceeded the limit of 10 internal redirects —— 常见于启用
LimitInternalRecursion后的提示，本质同上
如何让 error_log 更有效地暴露重写问题
仅靠默认日志级别往往不够。需针对性调整配置以增强可观测性：
- 临时提高重写日志级别（仅调试用）：
RewriteLogLevel 5（Apache 2.2）或使用LogLevel alert rewrite:trace3（Apache 2.4），配合RewriteLog "/path/to/rewrite.log"（2.2）或直接依赖ErrorLog（2.4） - 确保
ErrorLog级别不低于warn，避免关键 alert 被过滤；推荐设为LogLevel warn或更细粒度如LogLevel warn rewrite:warn - 检查是否启用了
LimitInternalRecursion（默认 10），可在虚拟主机或目录上下文中设为稍高值（如 20）辅助定位，但不能取消限制
结合日志快速定位问题规则的方法
看到死循环日志后，不要逐行检查所有规则。聚焦以下方向：
- 查找无终止条件的规则：例如
RewriteRule ^(.*)$ /index.php?path=$1 [L]在 DocumentRoot 下无排除逻辑，会导致 /index.php 自身又被重写 - 检查 RewriteCond 是否始终为真：比如基于
%{HTTP_HOST}的条件未覆盖当前访问域名，导致规则意外生效 - 确认 [L] 标志是否被误用：多个规则链中遗漏 [L]，或在 .htaccess 中因作用域限制导致后续规则仍执行
- 验证重写目标是否引入新匹配：如将
/old/重写为/new/，而/new/又被另一条规则捕获，形成闭环
预防胜于排查：设计健壮重写规则的习惯
从源头降低死循环风险比事后分析日志更高效：
- 对可能自我匹配的目标路径显式排除，例如：
RewriteCond %{REQUEST_URI} !^/index\.php$ - 优先使用
RewriteRule ^/api/(.*)$ /api/index.php?$1 [L]这类有明确前缀的规则，避免泛匹配 - 在开发阶段用
cURL -I或浏览器开发者工具观察响应头中的X-Redirect-By和跳转链路 - 将复杂重写逻辑拆分到独立的
<ifmodule mod_rewrite.c></ifmodule>块，并添加注释说明每段意图
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
