排查 RewriteCond 逻辑错误的关键是验证 Apache 实际解析执行过程：需启用 LogLevel alert rewrite:trace3 查看条件求值结果，核对 %{REQUEST_FILENAME} 等变量真实值，确认条件组合顺序及正则转义，并通过隔离测试排除全局配置干扰。
排查 rewritecond 逻辑错误，关键不是“看规则写了什么”，而是“apache 实际怎么解析并执行它”。rewritecond 的行为高度依赖匹配时机、变量含义和上下文顺序，很多看似合理的条件在真实请求中会失效或反向触发。
确认 RewriteCond 是否真被触发
Apache 不会在日志里默认记录 RewriteCond 的匹配过程，必须主动开启调试。在虚拟主机或目录配置中加入：
- LogLevel alert rewrite:trace3（Apache 2.4+）—— trace3 能看到每个 RewriteCond 的求值结果（true/false）、所用变量值及匹配细节
- 重启 Apache 后触发一次请求，再查 error_log：
tail -n 50 /var/log/apache2/error.log | grep 'rewrite.*cond' - 如果日志里没出现任何 rewrite:cond 相关行，说明该 RewriteCond 所在的 RewriteRule 根本没进入匹配流程（可能被上一条 [L] 截断，或 URI 已被重写过）
重点核对变量的实际值，而非字面理解
%{REQUEST_FILENAME}、%{REQUEST_URI}、%{QUERY_STRING} 等变量在不同阶段取值不同，容易误判：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
-
%{REQUEST_FILENAME} 是映射后的绝对文件系统路径（如
/var/www/html/test/），不是 URL；若 test/ 是目录，它就存在，但test/.php一定不存在 —— 这正是尾部斜杠引发 500 循环的根源 -
%{REQUEST_URI} 始终以
/开头，且不包含查询参数；想匹配?id=123，必须用 %{QUERY_STRING} - 用
RewriteRule ^ - [E=DEBUG:%{REQUEST_URI},E=QS:%{QUERY_STRING}]+CustomLog ... "%{DEBUG}e %{QS}e"可把实际值记入访问日志，比猜更可靠
检查条件组合与执行顺序陷阱
RewriteCond 只对紧随其后的 RewriteRule 生效，且所有条件必须同时为 true 才触发规则。常见错误包括：
- 多个 RewriteCond 写在一起，但中间夹了其他指令（如 SetEnv），会导致后一个 RewriteCond 失效
- 用
RewriteCond %{ENV:xxx} ^1$判断环境变量时，该变量必须由前面的 RewriteRule [E] 或 SetEnvIf 在同一处理阶段设置好 - 条件中用了正则但未转义特殊字符：例如
%{HTTP_HOST} ^example\.com$中的点号必须加反斜杠，否则匹配任意字符 - 使用
-f或-d判断文件/目录存在性时，路径必须是服务器上真实可访问的物理路径，符号链接需配合-L单独判断
隔离测试：绕过全局配置干扰
主配置或 .htaccess 中其他重写规则可能提前终止流程或覆盖环境变量。快速验证方法：
- 临时清空 .htaccess，只保留待测的 RewriteCond + RewriteRule，观察是否生效
- 在虚拟主机配置中新建一个专用 Location 块：
<Location "/test-rewrite"> RewriteEngine on RewriteCond ... RewriteRule ... </Location>，用 curl 测试/test-rewrite/xxx - 用
curl -v http://localhost/test-rewrite -H "Host: example.com"控制请求头，排除 DNS 或 Host 匹配问题
