根本原因是浏览器将301重定向关系持久化缓存，需通过curl验证、禁用缓存测试或改用302临时跳转来清除；apache端可加cache-control等响应头控制，同时检查规则顺序与协议一致性。

这个问题很常见：你改了 apache 的 301 配置，比如把旧 url 指向新地址，但用户浏览器依然跳转到老目标，甚至清空历史记录、换隐身窗口也没用。根本原因不是配置没生效，而是浏览器已经把这条 301 跳转“记死”了——它缓存的是重定向关系本身，不是页面内容。

确认是否真被浏览器缓存了

别急着改服务器，先验证是不是本地缓存惹的祸：

• 用 curl -I http://your-old-url 直接查响应头，看 Location 是否指向你期望的新地址（绕过浏览器）
• 在 Chrome 开发者工具的 Network 标签页里，勾选 “Disable cache”，再刷新页面，观察是否还走 301
• 换一个完全没访问过该域名的设备或手机（未登录同一 Google 账户），直接输入旧 URL 测试

Apache 端主动控制缓存行为

301 默认会被浏览器长期缓存，但你可以通过响应头覆盖这个行为。在 Apache 的虚拟主机或目录配置中加入：

Header always set Cache-Control "no-cache, no-store, must-revalidate"
Header always set Pragma "no-cache"
Header always set Expires "0"

Apache Superset Dashboard and SQL Exploration Skill

Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。

下载

注意：需要启用 mod_headers 模块，并确保这些指令放在重定向规则之后（例如 rewrite 规则下方），否则可能不生效。

强制刷新客户端缓存的实用办法

对已缓存的用户，光改服务器不够，得让他们“重新学习”：

• 临时把 301 改成 302 Found（临时重定向），等用户访问一次后，再切回 301。302 不会持久缓存，能自然清掉旧记录
• 给旧 URL 加个无意义参数，比如 /old-page?ver=2，并配置 Apache 对带参数的请求返回 302 或直接 200，引导用户过渡
• 如果使用 CDN（如 Cloudflare），在 CDN 后台清除“重定向缓存”或关闭“自动重定向缓存”选项，避免中间层二次固化

检查 .htaccess 或主配置里的重定向逻辑

很多问题出在规则叠加或顺序错误：

• 确认没有多个 RewriteRule 同时匹配，导致实际执行的是第一条而非你刚加的那条
• 检查是否用了 R=301 但漏写了 L（last），让后续规则继续干扰
• 如果旧 URL 是 HTTPS，而重定向目标是 HTTP，现代浏览器（尤其 Chrome）会因安全策略直接拦截，表现为“空白页”或“ERR_TOO_MANY_REDIRECTS”，此时应统一协议