Magento 2 页面突然 404，第一步是判断 404 由 Web 服务器返回，还是请求已经进入 Magento 后由路由返回。两者页面样式、响应头和日志位置通常不同。

确认影响范围

  • 只有一个商品或分类 404：优先检查实体和 URL 重写。
  • 所有前台页面 404，但静态文件正常：检查入口文件与 rewrite 规则。
  • 只有某个 store view 404：检查 Base URL、store code 和网站绑定。
  • 后台正常、前台全站异常：检查部署、维护模式和前端路由。

检查实体状态

商品必须启用、分配到当前网站，并具有适合的可见性。分类需要启用且位于当前网站使用的根分类下。CMS 页面要启用，并分配到当前 store view。

检查 URL 重写

SELECT url_rewrite_id, entity_type, entity_id, request_path,
       target_path, redirect_type, store_id
FROM url_rewrite
WHERE request_path = 'example-path.html';

查询时使用不带域名和开头斜线的实际 request path，并匹配当前 store ID。如果没有记录，先检查实体 URL Key 和网站范围，不要手工插入一条未经验证的 target_path。

Web 服务器规则

Nginx 或 Apache 必须把不存在的物理路径交给 Magento 的入口处理。发布新配置后，可先做语法检查再 reload：

nginx -t
# 通过后再由有权限的运维流程 reload

不要直接复制其他项目的 Nginx 配置覆盖当前站点，尤其要保留媒体、静态文件、安全目录和 PHP 入口规则。

检查 Base URL 与 Store

bin/magento config:show web/unsecure/base_url
bin/magento config:show web/secure/base_url
bin/magento config:show web/url/use_store

代理层终止 HTTPS 时，还要确认转发协议头配置正确，否则可能产生错误跳转，看起来像 404。

缓存不是第一原因

路由或 URL 重写修复后，可精准清理配置和 Full Page Cache：

bin/magento cache:clean config full_page

单纯反复 flush 不会创建缺失的 URL 重写，也不能修复错误的 Web 服务器规则。

验证

  1. 直接访问目标 URL，记录状态码和最终跳转地址。
  2. 确认同一页面在各 store view 的表现。
  3. 检查旧 URL 是否按预期 301，新 URL 是否返回 200。
  4. 抽查首页、分类、商品、CMS、静态文件和媒体文件。
  5. 再次保存测试实体，确认 URL 重写能自动维护。