apache rewriterule 匹配失败主因是默认拦截%2f/%5c请求，未进入rewrite引擎；需在服务器级配置allowencodedslashes on/nodecode启用编码斜杠处理，不可放.htaccess。
apache 的 rewriterule 匹配失败，尤其是涉及 %2f（编码斜杠）、%5c（编码反斜杠）等特殊字符时，通常不是正则写错了，而是 apache 在进入 rewrite 引擎前就已拦截请求——根本没走到匹配那一步。
关键原因：Apache 默认拒绝编码斜杠
Apache 内置安全机制会主动拦截 URL 路径中含 %2F 或 %5C 的请求，并直接返回 404，不交由 mod_rewrite 处理。这是为了防止路径穿越类攻击，与 RewriteRule 本身无关。
- 即使你的规则是
RewriteRule ^/api/(.*) /handler.php?path=$1 [L]，只要原始请求是/api/v1%2Fusers，Apache 就会在 rewrite 阶段前丢弃它 - 可通过访问日志确认：这类请求通常不会出现在 access_log 中，但 error_log 可能有类似
client denied by server configuration的提示（取决于版本和日志级别）
核心修复：启用 AllowEncodedSlashes
必须在 Apache 主配置（如 httpd.conf 或虚拟主机配置块内）添加该指令，且需在 RewriteEngine on 之前生效：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
-
AllowEncodedSlashes On：允许并自动解码 %2F → /，RewriteRule 模式将收到已解码路径（例如/api/v1/users） -
AllowEncodedSlashes NoDecode：允许但保留编码形式（%2F不变），RewriteRule 模式看到的是原始编码字符串，适合需要显式处理编码的场景 - 注意：该指令不能放在
.htaccess中，仅支持服务器级或虚拟主机级上下文
其他常见干扰项排查
若开启 AllowEncodedSlashes 后仍不匹配，继续检查以下环节：
-
URL 解码时机：RewriteRule 始终作用于已解码后的路径（除非用
NoDecode），所以正则里写v1%2Fusers是无效的；应写v1/users（On 模式）或用.*%2F.*（NoDecode 模式） -
NE 标志误用：若重写目标含特殊字符（如
?q=a%2Fb），需加[NE]防止 Apache 二次编码，否则可能变成a%252Fb -
QSA 与查询字符串冲突：原请求带参数又手动拼接 query，容易重复或丢失，建议统一用
[QSA]追加而非硬编码 -
日志辅助定位：临时启用重写日志（
RewriteLogLevel 3+RewriteLog "/path/to/rewrite.log"，2.4+ 改用LogLevel alert rewrite:trace3），观察每一步是否被跳过或匹配失败
验证是否生效的小技巧
部署后，用 curl 测试原始编码请求：
-
curl -v "http://your-site/api/v1%2Fusers"—— 应返回 200 或进入 rewrite 流程，不再 404 - 查看 rewrite 日志，确认是否出现
initial request和rewritten to记录 - 若仍失败，检查是否有其他模块（如 mod_security、自定义 LimitExcept）提前拦截了该请求方法或路径
