mod_log_config无法记录重定向后的最终物理路径，因其仅记录原始请求上下文，不追踪3xx跳转链；%f、%{REQUEST_FILENAME}e等均反映原始路径，而%{Location}o仅能记录Apache自身生成的重定向目标URL。
mod_log_config 本身无法记录重定向后的“最终物理路径”，因为它只记录 Apache 处理当前请求时的上下文信息，不追踪重定向链或后端实际执行的文件路径。
为什么无法直接记录重定向后的物理路径
重定向（如 Redirect 或 RewriteRule [R]）本质是向客户端返回一个 3xx 响应头，让浏览器发起新请求。Apache 日志记录的是**原始请求**的处理过程，不是跳转后的新请求。因此：
-
%f记录的是原始请求映射到的本地文件路径（若存在），不是重定向目标的路径； -
%{REQUEST_FILENAME}e或%{SCRIPT_FILENAME}e同样反映原始请求的解析结果； - 重定向目标（比如
/newpath）可能由另一个虚拟主机、另一个服务，甚至外部域名响应，Apache 不会、也不能将其物理路径写入本机访问日志。
能记录的与重定向相关的有效路径信息
虽然不能获取“最终物理路径”，但可记录重定向行为本身及原始请求的定位信息：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
-
%r：原始请求行（如GET /oldpage HTTP/1.1），能看出被重定向的入口； -
%>s：响应状态码，301/302 等可明确标识发生了重定向； -
%{Location}o：如果 Apache 自己生成了重定向响应（如用Redirect指令），该变量会记录Location响应头的值（即重定向目标 URL）； -
%U：请求的 URL 路径（不含查询字符串），可用于比对是否命中重定向规则； - 结合
RewriteLog（已弃用）或RewriteLogLevel（Apache 2.2）可调试重写过程，但非标准访问日志，且不记录物理路径。
替代方案：间接推断重定向目标路径
若目标仍在同一 Apache 实例内，可通过配置提前关联逻辑：
- 在
RewriteRule中使用[E=REDIR_TARGET:/real/path.php]设置环境变量，再用%{REDIR_TARGET}e记录； - 对常见重定向规则，用
SetEnvIf匹配原始 URI 并设置环境变量，例如：SetEnvIf Request_URI "^/oldpage$" REDIR_TARGET="/var/www/html/newpage.php"，然后日志中用%{REDIR_TARGET}e； - 确保
LogFormat包含这些自定义变量，并启用CustomLog输出。
真正需要物理路径时的建议做法
如果业务必须审计最终执行文件，应避免依赖重定向日志，转而：
- 将逻辑统一收口到一个前端控制器（如
index.php），通过路由分发，此时%f总是控制器路径，再配合应用层日志记录具体处理模块； - 对静态资源重定向，使用
Alias或DocumentRoot调整，使路径映射更透明； - 禁用外部重定向，改用内部重写（
RewriteRule ... [L]不带R），这样请求不跳出，%f就是真实处理文件。
