Debian 10中mod_rewrite不生效主因是权限与作用域配置缺失，非模块故障；需确认rewrite_module已加载、AllowOverride All启用、RewriteEngine On开启，并通过rewrite.log验证规则是否触发。
apache 的 mod_rewrite 不是“坏了能一键重装”的组件，它没有独立状态，所谓“重置”其实是清掉配置残留、权限错配和缓存干扰，让模块回归可预测的初始工作路径。在 debian 10（buster）这类默认安全收紧的系统上，90% 的“rewrite 不生效”问题，根源不在模块本身，而在加载后没被授权使用、或规则写在了被忽略的位置。
确认模块真实加载且无冲突
别只信 a2enmod 的返回提示——它只改了符号链接，不保证模块真在运行中：
- 执行 sudo apache2ctl -M | grep rewrite，必须看到 rewrite_module (shared)；若无输出，说明模块未加载成功
- 检查是否有重复加载：运行 grep -r "LoadModule rewrite_module" /etc/apache2/，如果多处出现（比如 mods-enabled 和 apache2.conf 里都写了），删掉冗余项，只保留 mods-enabled 下的启用链接
- 查看错误日志确认有无模块冲突：sudo tail -n 20 /var/log/apache2/error.log，留意类似 “Cannot load mod_rewrite into server” 或 “module rewrite_module is built-in and can’t be loaded” 的报错
清理配置层干扰：作用域与权限归零
Debian 10 默认禁用 .htaccess，且虚拟主机配置中常漏掉关键指令。这不是疏忽，是设计使然——你得显式告诉 Apache：“这里允许重写”：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 找到你的站点配置文件（通常在 /etc/apache2/sites-enabled/ 下），打开对应 VirtualHost 块，在 <Directory /var/www/your-site> 内确保包含三行：
AllowOverride All
Require all granted
- 如果用了 .htaccess，请确认它位于网站根目录，且文件名就是 .htaccess（开头带点，不是 .htaccess.txt）；内容第一行必须是 RewriteEngine On
- 临时注释掉所有 RewriteRule，只留最简测试规则：
RewriteEngine On
RewriteRule ^test$ /index.html [L]
然后访问 /test 看是否跳转，排除规则语法问题
绕过缓存与旧进程干扰
Apache 不会自动丢弃旧子进程里的配置上下文。改完配置后直接 restart 有时反而让问题更隐蔽：
- 先校验配置语法：sudo apache2ctl configtest，必须返回 Syntax OK
- 用优雅重载代替重启：sudo systemctl reload apache2（等价于发送 USR1 信号），确保新配置生效、旧连接不受影响
- 清除浏览器缓存或换隐身窗口测试；也可用 curl 验证原始响应：
curl -I http://localhost/test，看是否返回 200 或 301，排除 304 缓存响应干扰
验证重写是否真正进入处理链
很多问题卡在“规则没触发”，但你根本不知道 Apache 连匹配都没做。开启重写日志可定位断点：
- 在站点配置的 <Directory> 块内添加两行：
RewriteLogLevel 3
RewriteLog /var/log/apache2/rewrite.log - 创建日志文件并赋权：sudo touch /var/log/apache2/rewrite.log && sudo chown www-data:www-data /var/log/apache2/rewrite.log
- reload 后访问一次测试 URL，再执行 sudo tail -n 20 /var/log/apache2/rewrite.log；如果日志为空，说明 rewrite 引擎根本没启动或被跳过——大概率是 AllowOverride 仍为 None 或 RewriteEngine 没开
