网站改版之后，有时会遇到一种看起来很像服务器配置错误的问题：
服务器上的主页已经更换，旧的跳转逻辑也已经取消，但访问网站根地址时，浏览器仍然自动跳转到过去使用的旧页面。由于旧页面已经被删除或停止使用，最终看到的往往是一个 404 Not Found。
这种现象很容易让人误以为 Apache、Nginx、VirtualHost 或 Rewrite 规则仍然存在问题。
实际上，问题也可能完全发生在浏览器端。
问题场景
假设网站过去采用如下结构：
https://example.com/
↓
https://example.com/portal/desktop.html
根目录中的主页负责判断访问设备，然后将桌面浏览器跳转到：
/portal/desktop.html
移动设备则可能跳转到另外一个页面。
后来网站进行了调整，新的主页直接部署到了根地址：
https://example.com/
因此旧的：
/portal/desktop.html
已经不再需要，甚至已经被删除。
服务器配置也已经更新。
但某些此前访问过网站的浏览器再次打开：
https://example.com/
时，仍然立即进入：
https://example.com/portal/desktop.html
随后返回 404。
此时需要先判断一个关键问题：
跳转到底发生在服务器端，还是浏览器端？
最简单的判断方法：使用隐身窗口
可以先使用浏览器的 Incognito / Private Window 打开网站根地址：
https://example.com/
如果隐身窗口能够正常显示新主页，而普通窗口仍然跳转到旧地址，那么服务器通常已经没有问题。
问题基本可以锁定在：
浏览器缓存。
隐身窗口不会直接使用普通浏览器 Profile 中已经保存的大部分站点缓存，因此相当于进行了一次相对干净的访问测试。
这个方法非常适合快速区分：
服务器问题
和：
浏览器本地问题
使用 Chrome DevTools 强制刷新缓存
在 Chrome 中，可以使用开发者工具强制重新请求网站资源。
操作步骤：
- 打开目标网站。
- 按
F12打开 Developer Tools。 - 进入 Network。
- 勾选 Disable cache。
- 保持 Developer Tools 打开。
- 重新访问网站或刷新页面。
此时 Chrome 会绕过正常的页面缓存，重新向服务器请求当前版本。
如果新的主页随后能够正常加载，并且旧跳转消失，就说明之前确实使用了旧缓存内容。
很多情况下，只需要这样重新访问一次。
浏览器获取到新版本之后，即使之后关闭 Developer Tools，并恢复正常缓存机制，网站也会继续正常访问。
为什么旧跳转会被缓存？
旧主页如果包含 JavaScript 跳转，例如：
window.location.href = "/portal/desktop.html";
或者：
location.replace("/portal/desktop.html");
浏览器如果仍然使用过去缓存的 HTML 或 JavaScript，就可能继续执行已经不存在于服务器当前版本中的跳转逻辑。
因此会出现一个容易产生误判的现象：
服务器实际提供的是：
新主页
而浏览器实际执行的却可能还是：
旧主页缓存
→ 旧 JavaScript
→ 跳转旧地址
→ 404
从用户看到的结果来看，像是服务器仍在重定向。
实际上，请求甚至可能还没有按照预期重新获取最新主页。
更彻底的处理方法
如果勾选 Disable cache 之后仍然异常，可以继续清除该网站本地保存的数据。
Chrome 中可以进入：
Developer Tools
→ Application
→ Storage
然后选择：
Clear site data
这会清理当前站点相关的缓存和部分本地存储数据。
如果网站曾经使用过 Service Worker，还应该检查：
Application
→ Service Workers
必要时执行：
Unregister
Service Worker 具有较强的资源缓存能力。如果网站历史上部署过 PWA 或离线缓存机制，即使服务器文件已经更新，Service Worker 也可能继续向浏览器提供旧资源。
如果隐身窗口也会跳转怎么办？
如果普通窗口和隐身窗口都会跳转到旧地址，就不应该继续把注意力放在浏览器缓存上。
这时才需要回到服务器检查。
常见检查位置包括：
网站根目录中的首页文件
Apache：
VirtualHost
.htaccess
Redirect
RedirectMatch
RewriteRule
Nginx：
server
location
rewrite
return 301
return 302
以及主页代码中的：
window.location
location.href
location.replace()
或者 HTML：
<meta http-equiv="refresh">
还需要检查 CDN、反向代理或其他中间层是否存在缓存或重定向。
因此，一个比较高效的排查顺序是：
普通浏览器异常
↓
隐身窗口测试
↓
隐身正常
↓
浏览器缓存问题
或者：
普通浏览器异常
↓
隐身窗口仍异常
↓
继续检查服务器 / 代理 / CDN
不要一开始就修改服务器配置
这种问题最值得注意的一点，是不要因为看到旧地址和 404，就立即修改 Apache 或 Nginx。
如果服务器本来已经配置正确，此时再次修改：
RewriteRule
Redirect
VirtualHost
location
反而可能制造新的问题。
比较合理的方法是先确定：
旧跳转究竟是谁产生的。
例如先检查：
curl -I https://example.com/
或者使用浏览器 Network 面板观察首个请求。
如果服务器返回：
200 OK
而不是：
301
302
307
308
却仍然在浏览器中发生页面跳转，就应该重点检查页面脚本和客户端缓存。
一个非常实用的经验
网页修改完成后，如果出现：
服务器文件明明已经更新
但浏览器表现仍然像旧版本
可以优先尝试：
F12
→ Network
→ Disable cache
→ Reload
如果这样立即恢复正常，就不需要继续修改服务器。
这类问题尤其容易发生在：
- 网站首页重构
- JavaScript 跳转逻辑删除
- CSS / JS 文件替换
- 页面目录调整
- 旧入口下线
- 反向代理路径改变
- 前端路由调整
等场景中。
总结
网站已经更新，但浏览器仍然跳转旧地址，并不一定意味着服务器还保存着旧规则。
可能的真实过程只是：
浏览器保存旧页面
↓
旧页面继续执行旧跳转
↓
跳转到已经不存在的路径
↓
404
排查时可以先通过隐身窗口确认服务器当前状态，再使用 Chrome DevTools 的：
Network → Disable cache
强制重新获取页面。
如果重新加载一次之后问题永久消失，就可以确认：
服务器配置本身没有问题，异常只是浏览器仍然使用了历史缓存。
相比直接修改 Web Server 配置，这种先区分客户端和服务器端的排查方式风险更低，也更加高效。