Moodle 5.2: el router no está configurado correctamente

Qué significa normalmente el error

Si Moodle 5.2 dice que el router no está configurado correctamente, el servidor web no está pasando rutas sin archivo real al controlador frontal r.php. El síntoma más claro es una URL enrutada que termina en .php y devuelve 404 Not Found cuando Moodle esperaba una respuesta del router.

En la discusión Moodle.org “Moodle 5.2: router is not correctly configured”, el caso tenía 38 respuestas y giraba alrededor de /lib/exampleshimroute2.php: devolvía 404 en vez del 302 esperado. El sitio puede ejecutar PHP, pero una ruta falsa con pinta de PHP queda atrapada antes de llegar al router de Moodle.

Por qué Moodle 5.x se preocupa por el routing

El router de Moodle es un controlador frontal. La documentación Configuring the Router explica que r.php se usa cuando una petición no corresponde a un archivo real.

Esto importa más desde Moodle 5.1 porque las peticiones públicas deben entrar por moodle/public, mientras el código interno y la configuración quedan fuera de la raíz web.

Empieza por la raíz web

Si tu código Moodle está aquí:

/var/www/moodle

el sitio público debe apuntar aquí:

/var/www/moodle/public

no aquí:

/var/www/moodle

Si la raíz está mal, depurar el router solo añade ruido.

Arreglo en Apache

La configuración base usa FallbackResource:

<Directory "/var/www/moodle/public">
    FallbackResource /r.php
</Directory>

Algunos hosts permiten esto en .htaccess dentro de public:

FallbackResource /r.php

El problema típico con Apache + PHP-FPM es que Apache manda cualquier ruta que parece .php a PHP-FPM aunque el archivo no exista. PHP-FPM devuelve 404 antes de que Apache pueda caer en r.php.

La solución práctica es aplicar el handler PHP solo a archivos reales:

<FilesMatch ".+\.ph(?:ar|p|tml)$">
    <If "-f %{REQUEST_FILENAME}">
        SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"
    </If>
</FilesMatch>

No pegues esto a ciegas. Busca tu SetHandler actual y conserva el socket o backend que ya usa tu servidor.

Arreglo en Nginx

En Nginx, el patrón esencial es:

location / {
    try_files $uri $uri/ /r.php$is_args$args;
}

Si Moodle vive en un subdirectorio:

location /moodle/ {
    try_files $uri $uri/ /moodle/r.php$is_args$args;
}

Esto debe estar en la configuración del servidor. Nginx no tiene .htaccess.

OpenLiteSpeed y cPanel

En hosting de panel suele funcionar mejor una regla de reescritura:

RewriteEngine On
 
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} -d
RewriteCond %{REQUEST_FILENAME}/index.php -f
RewriteRule ^(.*)$ $1/index.php [L]
 
RewriteRule ^$ ./index.php [L]
 
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ r.php [L,QSA]

Ponla en el .htaccess del directorio public, no en la carpeta padre antigua.

Cómo depurar el check exacto

1. Abre Administración del sitio > Informes > Estado del sistema.
2. Anota la prueba exacta que falla.
3. Pide esa URL directamente con el navegador o curl -I.
4. Mira si responde Apache, Nginx, PHP-FPM, Moodle, CDN o una capa de seguridad.
5. Revisa logs web y PHP-FPM en ese mismo momento.
6. Corrige la primera capa que devuelve la respuesta equivocada.
7. Recarga servidor web y PHP-FPM.
8. Purga cachés Moodle y repite el check.

La pregunta que importa es: ¿quién devolvió el 404?

Qué no debes hacer

No hagas público todo el directorio Moodle para silenciar el error. Eso rompe el motivo de seguridad de public.

No añadas reglas en la carpeta padre y en public a la vez. Configura la raíz real.

No uses $CFG->routerconfigured = true como sustituto. Puede ocultar un aviso, pero no hace que Apache, Nginx o IIS enruten bien.

FAQ

¿Es obligatorio el router en Moodle 5.2?

La documentación de Moodle dice que la configuración del router es obligatoria desde Moodle 5.1.

¿Dónde está el router?

El punto de entrada es r.php.

¿Por qué Moodle espera 302 y recibe 404?

Normalmente porque una ruta .php falsa llega a PHP-FPM antes de caer en r.php.