apache无mod_log_debug官方模块，生产环境应使用rewriterule [d]标志配合loglevel rewrite:trace3调试重写规则，日志输出至errorlog；遇请求篡改疑点可临时启用mod_dumpio抓原始字节流。
Apache 中没有 mod_log_debug 这个官方模块，它不在 Apache 2.4+ 标准发行版中，也无法通过 LoadModule log_debug_module modules/mod_log_debug.so 正常启用——该路径下根本不存在对应 .so 文件，强制加载会报错：
Cannot load modules/mod_log_debug.so into server: Cannot open shared object file
所以，“利用 mod_log_debug 在线调试重写规则”这个前提不成立。生产环境真正可用、安全、原生支持的调试方式是以下组合：
✅ 用 RewriteRule [D] 标志 + LogLevel rewrite:trace3
-
[D]是 Apache 2.4.13+ 原生支持的调试标志，只对单条规则生效，不改变请求流程、不引入额外模块、无性能突增风险。 - 必须配合
LogLevel rewrite:trace3（或trace5）才能输出，日志写入ErrorLog（不是access.log！）。 - 示例配置：
RewriteEngine On RewriteCond %{QUERY_STRING} ^debug=1$ RewriteRule ^/api/(.*)$ /debug-proxy/$1 [D]只要请求带
?debug=1，就会在error.log中打印匹配变量、原始 URI、重写后 URI。
⚠️ 注意 LogLevel 的作用域和缓冲问题
-
LogLevel不是全局开关：放在<virtualhost></virtualhost>里只影响该站点；若子目录有<directory></directory>或.htaccess中的RewriteOptions覆盖，trace 日志可能被静默禁用。 - 日志默认带内核缓冲，
tail -f可能延迟数秒才刷出。调试时建议：stdbuf -oL tail -f /var/log/apache2/error.log
- 若使用
rotatelogs或systemd-journald，日志可能被截断或转发延迟——临时调试务必切回直写文件模式。
? 遇到“疑似死循环”？看 error.log 关键告警
Apache 不主动监测，但会在重写超过默认 10 次时明确记录：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
[alert] mod_rewrite: maximum number of internal redirects reached
这是最权威的死循环证据。配合 LogLevel warn rewrite:trace3，可快速定位：
- 是否遗漏
RewriteCond %{REQUEST_URI} !^/index\.php$等终止条件 - 是否
RewriteRule目标又触发自身（如/old/→/new/，而/new/又被另一条规则捕获） - 是否
[L]标志误用，导致规则链未真正终止
? 极端情况：怀疑原始请求被篡改？用 mod_dumpio
当 rewrite 日志显示“条件没匹配”，但你怀疑代理改头、BOM、换行符混用等问题时：
LoadModule dumpio_module modules/mod_dumpio.so DumpIOInput On LogLevel dumpio:trace7
⚠️ 它会把每个请求的 headers + body 原始字节全打到 error.log，几秒就能写满 GB 级日志。必须：
- 开启前确认磁盘空间充足
- 复现问题后立刻关闭（注释配置并
systemctl reload apache2） - 绝不长期开启，尤其在负载均衡后端节点
不复杂但容易忽略：所有调试日志都只进 ErrorLog，且受 LogLevel 作用域限制。翻 access.log 是白忙活。
