mod_log_config无法记录重定向后的最终物理路径，因其在请求早期阶段工作，而重定向（301/302）终止原流程、不解析目标文件路径；%f和%{...}e变量仅在内部映射（如alias）时有效，重定向场景下为空。
mod_log_config 本身无法直接记录重定向后的最终物理文件路径，因为它只在请求处理的早期阶段（如日志记录阶段）工作，而重定向（如 Redirect 或 RewriteRule [R]）会触发新的 HTTP 响应，原请求流程终止，不会走到最终资源的磁盘路径解析环节。
为什么 %{...}e 或 %{...}f 不适用于重定向目标
Apache 日志格式中：
-
%f记录的是当前请求映射到的**本地文件系统路径**（即 DocumentRoot 下的真实路径），但仅当请求未被重定向、且成功匹配到一个静态文件或 CGI 脚本时才有效； -
%{PATH_TRANSLATED}e或%{SCRIPT_FILENAME}e属于环境变量，同样依赖于请求是否实际抵达内容处理阶段——重定向响应（301/302）不执行后续路径解析，这些变量为空或不可靠； - 一旦使用
Redirect、RedirectPermanent或RewriteRule [R]，服务器返回的是 HTTP 头 + 空响应体，不读取目标 URL 对应的物理文件，因此没有“最终物理路径”可记录。
真正能记录目标资源路径的场景：内部映射（非重定向）
如果你实际想记录的是用户访问 /static/logo.png 后，Apache 内部映射到 /var/www/assets/logo.png 这个真实路径，那应该用 Alias（非 Redirect）配合 %f：
Alias /static /var/www/assets
<directory>
Require all granted
</directory>
此时日志中 %f 就会显示 /var/www/assets/logo.png —— 因为这是内部路径映射，不改变 URL，也不发重定向。
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
若必须追踪重定向链的落地结果，需分步处理
没有单一日志字段能自动记录“跳转后最终加载的文件”，但可通过组合方式逼近目标：
- 在重定向配置中显式记录原始请求和目标 URL：
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %{REDIRECT_URL}e" redirectlog
（注意：REDIRECT_URL是 Apache 内部变量，仅在内部子请求中存在，对普通外部重定向无效）； - 更可靠的做法：对目标站点单独配置访问日志。例如从
old.com/a.html301 跳转到new.com/b.html，则在new.com的虚拟主机里用%f记录b.html的真实路径； - 启用
mod_rewrite的RewriteLog（旧版）或使用RewriteLogLevel 3+ErrorLog调试重写过程（仅限开发环境，性能开销大）。
替代建议：用 CustomLog + 脚本后处理
如果业务上强依赖“谁访问了哪个重定向链接并最终落到哪”，推荐：
- 在重定向规则中添加唯一查询参数（如
?via=oldsite），再用%r或%q记录完整原始请求行； - 结合
%{HTTP_HOST}i和%U（请求 URI）判断跳转来源与目标模式； - 用外部脚本（如 Python + pandas）分析 access_log，根据状态码 301/302 和
Location:响应头反查目标域名的日志，做关联分析。
本质上，重定向是客户端行为，Apache 只负责发一次跳转指令；记录最终物理路径这件事，得落在目标服务器的日志里，而不是发起跳转的这台机器上。
