在 apache 中开启 rewritelog 需要修改配置文件并重启服务，分析时则通过查看日志文件中的详细重写过程来排查规则匹配问题。具体做法是在 httpd.conf 或虚拟主机配置中添加 rewritelog 指定日志路径，并用 rewriteloglevel 设置日志级别（0-9），级别越高记录越详细。这样做会在指定文件中生成包含请求 uri、匹配规则、替换结果及内部重定向步骤的文本记录，帮助开发者定位为什么某个 url 没有被正确重写。
如何配置 RewriteLog 以捕获详细的重写过程
要开启详细的重写日志，必须在 Apache 的配置文件中显式声明日志文件和日志级别。推荐使用 RewriteLogLevel 9 来获取最完整的信息，包括每个规则的尝试、匹配成功与否以及最终的重定向目标。配置完成后，必须重启 Apache 服务使更改生效，否则日志不会开始记录。
# httpd.conf 或 vhost 配置片段 RewriteEngine On RewriteLog "/var/log/apache2/rewrite.log" RewriteLogLevel 9
上述配置将日志写入 /var/log/apache2/rewrite.log。注意，RewriteLog 是 Apache 2.2 及更早版本的指令。在 Apache 2.4+ 中，该指令已被移除，转而使用标准的 ErrorLog 配合 LogLevel rewrite:trace3（最高为 trace8）来实现相同功能。如果使用的是 Apache 2.4+，应使用以下配置：
# Apache 2.4+ 配置 RewriteEngine On ErrorLog "/var/log/apache2/rewrite_debug.log" LogLevel debug
在 Apache 2.4+ 中，通过调整全局或虚拟主机的 LogLevel 为 debug，并在 ErrorLog 中查看带有 [rewrite:trace] 前缀的行，可以获取与旧版 RewriteLog 类似甚至更结构化的信息。日志级别 trace3 到 trace8 分别对应不同的详细程度，trace8 最为详尽。确保日志文件路径对 Apache 运行用户（如 www-data 或 apache）有写权限。
如何解读 RewriteLog 中的关键信息字段
分析 RewriteLog 时，重点关注每一行开头的上下文标识、输入 URI、匹配的规则表达式以及最终的输出 URI。日志通常按请求处理阶段分组，显示从初始请求到最终内部重定向的每一步变化。通过对比输入和输出，可以判断规则是否按预期工作，或者是否存在循环重定向。
通过Apache Tika Server REST API从1400多种文件格式中提取文本和元数据。处理PDF、DOCX、PPTX、电子邮件归档以及带有MIME类型检测的嵌入式文档提取。
# 示例 RewriteLog 片段 (Apache 2.2) [rid#7f8b1c00a0a0/initial] [perdir /var/www/html/] strip per-dir prefix: /var/www/html/example.php -> example.php [rid#7f8b1c00a0a0/initial] [perdir /var/www/html/] applying pattern '^example/(.*)$' to uri 'example.php' [rid#7f8b1c00a0a0/initial] [perdir /var/www/html/] pass through /var/www/html/example.php [rid#7f8b1c00a0a0/initial] [perdir /var/www/html/] strip per-dir prefix: /var/www/html/index.html -> index.html [rid#7f8b1c00a0a0/initial] [perdir /var/www/html/] applying pattern '^index\.html$' to uri 'index.html' [rid#7f8b1c00a0a0/initial] [perdir /var/www/html/] rewrite 'index.html' -> '/static/home.html' [rid#7f8b1c00a0a0/initial] [perdir /var/www/html] internal redirect with /static/home.html [INTERNAL REDIRECT]
在上面的示例中，第一行显示 Apache 正在处理来自 /var/www/html/ 目录的请求，并剥离了前缀。第二行尝试应用模式 ^example/(.*)$ 到 example.php，但未匹配。第三行表明该文件被“pass through”（透传），即不进行重写。随后，Apache 检查默认文档 index.html，发现其匹配模式 ^index\.html$，并将其重写为 /static/home.html。最后一行确认这是一个内部重定向，请求将继续处理新的 URI。理解这些字段有助于识别规则失效的原因，例如正则表达式不匹配、路径前缀处理错误或循环重定向。
当 RewriteLog 显示内部重定向循环时该如何排查
如果 RewriteLog 中出现大量重复的 internal redirect 条目，且最终导致 HTTP 500 错误，这通常意味着存在重写循环。排查方法是检查是否有规则将已重写的 URI 再次匹配并重写回自身或另一个未终止的路径。解决策略包括添加 L（Last）标志以停止后续规则处理，或使用 %{ENV:REDIRECT_STATUS} 环境变量来避免对已重定向的请求再次应用规则。
# 防止循环重定向的示例规则
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^old-page$ /new-page [R=301,L]
在上述代码中，RewriteCond 确保只有当 REDIRECT_STATUS 为空（即首次请求）时才应用重写规则。这有效防止了 /new-page 再次被规则匹配并触发新的重定向。在分析日志时，寻找连续的 internal redirect 行，其输入和输出 URI 相似或形成闭环，即可定位此类问题。此外，确保所有重写规则都使用了适当的标志，如 L 用于最后一条规则，R 用于外部重定向，以避免不必要的内部处理开销。
