Apache mod_rewrite日志分析需启用LogLevel alert rewrite:trace3，日志合并至error_log，trace级别1-8可追踪匹配全过程，生产环境勿超trace2，且仅支持服务器级配置。
Apache mod_rewrite 日志分析不是看普通访问日志，而是启用专门的重写追踪日志，通过 trace 级别记录规则匹配过程，从而看清请求到底被哪条规则改写了、为什么没生效、是否进入死循环。
开启 mod_rewrite 调试日志
Apache 2.4 不再支持 RewriteLog，必须用 LogLevel 指令单独打开重写日志：
- 在主配置文件（如 /etc/apache2/apache2.conf 或虚拟主机配置）中添加一行：
LogLevel alert rewrite:trace3 - trace 级别从 1 到 8，trace3 已能显示规则匹配、条件判断、替换结果；生产环境建议不超过 trace2，避免性能拖慢
- 该设置只能放在服务器级或虚拟主机级配置里，不能写在 .htaccess 中
- 修改后必须重启 Apache：sudo systemctl restart apache2（Debian/Ubuntu）或 sudo systemctl restart httpd（RHEL/CentOS）
定位日志输出位置
重写日志会合并到 Apache 的 error_log 文件中，不是独立文件：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 典型路径：/var/log/apache2/error.log（Debian/Ubuntu）或 /var/log/httpd/error_log（RHEL/CentOS）
- 搜索关键词：[rewrite:trace，例如 [rewrite:trace3]，每条记录带时间戳和客户端 IP
- 一条请求可能触发多行 trace 日志，从 trace1（初始化）到 trace4（执行替换）逐层展开，注意看 “applying pattern”、“passing through”、“forcing redirect” 等关键动词
读懂常见 trace 日志线索
日志不是报错清单，而是执行流水账。重点识别这几类信息：
- 规则未匹配：出现 “not-matching” 或 “skip” —— 检查正则是否写错、大小写是否敏感（[NC] 缺失）、URI 是否含前导斜杠（.htaccess 中要省略）
- 条件不满足：看到 “RewriteCond: input … does not match pattern …” —— 确认 %{HTTP_REFERER}、%{REQUEST_FILENAME} 等变量值是否符合预期，比如 -f 判断文件存在，但实际路径拼错了
- 内部循环：连续出现多次相同规则的 trace 记录，末尾提示 “restarting with …” —— 很可能是 RewriteRule 又生成了能被自身匹配的新 URI，缺少 [L] 终止或条件漏判
- 跳转失效：看到 “redirect to …” 却浏览器没变地址 —— 检查是否误用了 [P]（代理）或 [PT]（传递），而本意是 [R=301] 强制跳转
配合访问日志交叉验证
单看 rewrite 日志容易断章取义，需结合 access.log 锁定真实请求：
- 用 tail -f /var/log/apache2/access.log 和 tail -f /var/log/apache2/error.log 同时观察
- 找到某次 404 或 500 响应对应的时间点，在 error.log 里找同一秒附近的 rewrite:trace 记录
- 注意客户端 IP 是否真实 —— 若前端有 Nginx 或 CDN，确保已配置 RemoteIPHeader X-Forwarded-For，否则日志里的 [client] 是代理 IP，不是用户真实 IP
