Moodle 5.1.3+ 升级时如何排查 ERR_TOO_MANY_REDIRECTS？

2026-11-04数据阿明

结论

仅凭现有信息还无法确定重定向循环的根因。目前已确认 $CFG->dirroot 指向新版 Moodle 包的根目录，这可以排除该路径明显错误的情况，但无法证明 Web 服务器实际使用了预期的 public 目录，也无法确认站点 URL、配置文件和升级代码彼此匹配。先查清每次跳转的 HTTP 状态码和 Location，再核对配置和实际文件路径。不要继续注释 admin/index.php 中的跳转代码。

先记录完整跳转链

在浏览器开发者工具中打开 Network 面板，启用保留日志，然后重新访问站点。记录从第一个请求开始的 URL、状态码和 Location 响应头。也可以在终端查看响应头：

curl -sS -D - -o /dev/null 'https://你的站点地址/'

要跟踪后续跳转，可以加上 -L，并限制跳转次数，避免命令持续跟随：

curl -sS -L --max-redirs 10 -D - -o /dev/null 'https://你的站点地址/'

逐一比较每次跳转的主机名、协议、路径和查询参数，尤其留意是否反复出现 index.php?lang=en、admin/index.php、install.php 或 admin/install.php。原描述提到的末尾路径写作 ./admin/install/php。请以浏览器 Network 面板捕获的实际 URL 为准，确认是否确实是这个路径。

核对 Moodle 配置与 Web 根目录

检查新版安装包根目录中的 config.php，确认 $CFG->wwwroot 与用户实际访问的规范站点地址一致，包括正确的 https 协议和主机名。还要确认 HTTP/HTTPS 或是否带 www 的差异没有引发反复的规范化跳转。请勿公开粘贴配置中的数据库密码或其他凭据。

Moodle 5.1 的新目录结构要求 Web 服务器将文档根目录设为安装包中的 public 子目录。在 cPanel 或 Apache 配置中核对实际生效的 DocumentRoot，并确认 public_html 和 www 符号链接都指向同一新版安装包下的 public 目录。可以检查链接目标：

readlink -f ~/public_html
readlink -f ~/www

再确认链接目标中确实有新版的公开入口文件。$CFG->dirroot 指向包根目录，而 Web 服务器的 DocumentRoot 指向 public；两者是不同的设置。只验证前者，无法确认后者正确。

同时确认新版安装包根目录中的 config.php 沿用本站配置，且对应的数据目录仍是原站使用的目录。若新版代码意外使用了另一份配置或空的数据目录，升级入口可能会表现异常。

对照重定向来源

根据跳转链判断跳转由哪一层发出：

若响应来自 Apache 或 cPanel 规则，检查虚拟主机、.htaccess、域名跳转和 HTTPS 强制规则，确认它们没有与 Moodle 的规范 URL 设置互相重定向。
若响应来自 PHP 页面，检查 wwwroot、Moodle 配置加载路径，以及请求是否进入预期版本的 public 入口和新版代码目录。
若跳转目标在安装页和管理页之间来回变化，先确认访问的 URL、实际执行的代码版本和升级状态一致，再根据相关响应及日志判断原因。单靠清缓存无法确认问题是否由缓存引起。

可以查看 Apache 的访问日志和错误日志，按同一时间段筛选这些请求，确认请求实际进入的虚拟主机、返回状态码和命中的路径。如果有多层代理或 CDN，也应核对它们传给 Apache 的协议和主机信息。目前的信息不足以判断是否存在这类代理。

清理缓存后的注意事项

问题描述中提到已清理 cache、localcache 和 sessions。清理会话目录可能使用户退出登录，但这本身不能证明重定向问题已经排除。完成路径和配置核对后，如需再次清缓存，应先停止修改 admin/index.php，并记录原始文件状态。不要通过注释核心跳转逻辑绕过升级流程。

建议按这个顺序处理：先获取完整的 Location 跳转链，再核对 $CFG->wwwroot，然后验证生效的 DocumentRoot 和两个符号链接，最后结合 Web 服务器日志检查请求实际命中的代码路径。拿到首个循环请求及其响应头后，才能进一步判断需要修改哪项配置。