Apache的mod_log_config可通过%{REQUEST_FILENAME}e变量间接记录内部重写后的最终物理路径，前提是使用RewriteRule [L]完成无[R]标志的内部重写，且目标文件真实存在；外部重定向（如[R=301]）无法记录目标路径。
Apache 的 mod_log_config 本身不直接记录“重定向后的最终物理路径”，因为它工作在请求处理早期阶段，而重定向（尤其是内部重写）可能发生在后续阶段，且物理路径（%{REQUEST_FILENAME}）在重定向链中会动态变化。但你可以通过组合日志变量和重写逻辑，**间接记录重定向最终落地的文件系统路径**——前提是该路径确实被 Apache 最终用于服务请求（例如 RewriteRule 后匹配到真实文件）。
关键日志变量：用 %{REQUEST_FILENAME} 获取实际物理路径
%{REQUEST_FILENAME} 是 mod_log_config 提供的核心变量，它表示 Apache 当前尝试映射到的**完整本地文件系统路径**（如 /var/www/html/index.php）。这个值会在 mod_rewrite 处理完所有规则后、且请求尚未被拒绝或交由其他模块处理时稳定下来。
只要你的重定向是通过 RewriteRule + [L] 实现的内部重写（非外部跳转），并且最终匹配到一个真实存在的文件或目录，%{REQUEST_FILENAME} 就是你想要的“最终物理路径”。
示例日志格式配置：
LogFormat "%h %l %u %t \"%r\" >%s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%{REQUEST_FILENAME}e\"" combined_with_path
⚠️ 注意：%{REQUEST_FILENAME}e 中的 e 是必需的——它表示“环境变量扩展”，因为 REQUEST_FILENAME 是运行时计算的环境变量，不是标准字段。
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
确保重写完成后再记录：启用 RewriteEngine 并正确使用 [L]
如果重定向依赖 RewriteRule，必须保证规则执行完毕、路径已解析，日志才有效。常见错误是规则没加 [L] 导致继续匹配，或条件未覆盖所有情况，使 REQUEST_FILENAME 仍指向原始路径。
- 开启重写引擎：
RewriteEngine On - 每条关键重写规则末尾加上
[L]，例如：RewriteRule ^/blog/(.*)$ /wp/$1 [L] - 避免循环：用
RewriteCond排除已重写过的路径，防止无限匹配
区分外部跳转与内部重写
如果你用的是 Redirect 或 RewriteRule ... [R] 这类**外部重定向**（浏览器地址栏会变），Apache 实际只处理原始请求，REQUEST_FILENAME 记录的是跳转前的路径，不是目标地址的物理路径。这种场景无法用日志直接记录目标路径——因为目标可能在另一台服务器上。
✅ 正确做法：仅对 内部重写（无 [R] 标志，URL 不变）使用 %{REQUEST_FILENAME}。
❌ 错误示例（外部跳转，日志无意义）：RewriteRule ^/old\.html$ /new.html [R=301,L] → 日志里仍是 /old.html 对应的物理路径
验证是否生效：检查日志输出与文件存在性
配置好后重启 Apache，发起一个触发重写的请求（如访问 /t_article_123.html 被重写为 /article.php?id=123），然后查看日志行末尾：
- 若显示
/var/www/html/article.php，说明重写成功且路径解析正确 - 若显示空、
/var/www/html/t_article_123.html或不存在的路径，检查：
•RewriteBase是否设置（尤其在子目录部署时）
•AllowOverride是否允许 .htaccess 使用重写功能
• 目标文件article.php是否真实存在于对应位置
