mod_log_config 无法记录重定向后最终物理路径，因其在请求早期的 logging 阶段执行，而文件路径解析发生在后续 translate 和 map_to_storage 阶段；%f 变量可获取内部重写后的最终文件系统路径。
apache 的 mod_log_config 默认记录的是客户端请求的原始 url（%r）和响应状态（%>s），但**不直接提供重定向后最终访问的物理文件路径**——因为该模块设计上不参与内容处理阶段，无法获取经由 mod_rewrite、alias、redirect 或内部重写后实际映射到的磁盘路径。
为什么不能直接用 mod_log_config 记录最终物理路径
Apache 日志模块在请求处理的早期（如 logging 阶段）执行，而资源路径解析（如 DocumentRoot + URI → 文件系统路径）发生在后续的 translate 和 map_to_storage 阶段。重定向（301/302）本身是响应头控制，不改变当前请求的内部路径；内部重写（如 RewriteRule ... [L]）虽会更新 URI，但其最终对应的 filename 变量仅在核心处理后期才确定，且未暴露给 LogFormat 的标准变量。
可行的替代方案
若需记录重定向或重写后的最终物理文件路径，可采用以下方法：
-
使用
%{THE_REQUEST}e+ 自定义日志分析：记录原始请求行（如GET /old.php HTTP/1.1），再结合访问日志中的%U（规范化 URI）与服务器配置逻辑，离线推断目标路径。适用于简单别名或固定规则场景。 -
启用
mod_info或调试日志（LogLevel debug）：在httpd.conf中临时设置LogLevel core:debug rewrite:trace3，查看错误日志中每一步重写和路径映射详情。适合诊断，不适合长期生产记录。 -
用
mod_setenvif+%{ENV:...}e手动标记：在重写规则中显式设置环境变量，例如：RewriteRule ^/app/(.*)$ /var/www/app/$1 [E=FINAL_PATH:/var/www/app/$1]
然后在LogFormat中使用%{FINAL_PATH}e。注意：此方式需人工维护路径构造逻辑，不自动反映真实DocumentRoot解析结果。 -
改用
mod_dumpio或外部工具拦截：开启DumpIOInput On可捕获原始请求；更可靠的方式是用 Lua（mod_lua）在log钩子中调用req.filename获取最终路径，但需编译支持且增加复杂度。
最实用的简化做法
对大多数运维需求，建议组合使用两个标准日志字段：
-
%U：记录请求的规范化 URI（已受重写影响，如/new.php） -
%f：记录 Apache 内部解析出的最终文件系统路径（即filename），它会在内部重写完成后生效。例如：
配置RewriteRule ^/api$ /var/www/api/index.php [L]后，访问/api的日志中%f将显示/var/www/api/index.php。
只需确保重写规则使用 [L] 标志终止匹配，并避免多层跳转干扰路径解析。%f 是最接近“重定向后最终物理路径”的原生变量，无需额外模块。
