Error «HTTP-code: 302» al agregar un sitio en MainWP: cómo diagnosticarlo

Uno de los errores más confusos que puede dar MainWP al intentar agregar un nuevo sitio administrado es este:

URL: tusitio.com (IP: xxx.xxx.xxx.xxx) - Received HTTP-code: 302 (Found)

Es un mensaje frustrante porque no dice por qué hubo una redirección, y en la mayoría de los casos, si probás la URL del child plugin manualmente con curl, todo responde perfecto (200 OK). Esa aparente contradicción es la que hace que el diagnóstico se pueda alargar bastante si no se sabe dónde mirar.

Por qué pasa esto

MainWP, al conectar un sitio, no solo llama al archivo mainwp-child.php — también valida que la URL base del sitio (la raíz del dominio) responda de forma directa, sin redirecciones. Si accede a mainwp-child.php directamente, sea vía GET o POST, ese archivo puede devolver 200 sin problema, aun cuando el resto del sitio esté bloqueado o redirigiendo, porque ese archivo se ejecuta fuera del ciclo normal de carga de plantillas de WordPress.

Ahí está la clave: hay dos causas típicas, con síntomas casi idénticos, que conviene distinguir desde el principio.

Causa 1: Un WAF o firewall está interceptando la conexión

Si el hosting (o un plugin de seguridad tipo Wordfence en modo Extended Protection, o un firewall de infraestructura tipo Imunify360/ModSecurity) detecta la conexión de MainWP como sospechosa —por ejemplo, por el User-Agent, por el tamaño del payload de autenticación, o por la IP del servidor del Dashboard—, puede responder con una redirección en lugar de un bloqueo directo (403). Esto es más común de lo que parece, porque el handshake real de conexión de MainWP (intercambio de claves, tamaño del body) es distinto a una petición simple, y algunos sistemas heurísticos lo tratan como actividad anómala.

Cómo detectarlo:

• Revisar el panel del firewall (Wordfence → Firewall, o el WAF del hosting) para ver si hay bloqueos recientes en el momento exacto del intento.
• Revisar el «Live Traffic» o log de acceso del firewall justo después de reintentar conectar el sitio.
• Si tenés acceso SSH al servidor de destino, comprobar si hay escáneres o firewalls a nivel de sistema (Imunify360, Maldet, ClamAV con cron) corriendo por fuera de WordPress.

Causa 2: El sitio no responde con la URL «limpia», sin redirección

Esta causa es más sutil y, en mi experiencia reciente, bastante más común de lo que se supone. MainWP necesita que la URL configurada en «Site URL» responda directamente, sin pasar por ningún redirect. Cualquier motivo que provoque una redirección en la raíz del dominio —y no solo en rutas específicas— rompe la validación de MainWP, aunque el child plugin funcione perfecto:

• Visibilidad del sitio en modo privado (Ajustes → Lectura → «Solo usuarios registrados pueden ver este sitio»), que fuerza un redirect a la página de login para cualquier visitante no autenticado.
• Plugins de restricción de acceso o membresía configurados para todo el sitio.
• Reglas de .htaccess o del hosting que fuerzan redirecciones de dominio.
• Plugins multi-idioma (como Polylang) que redirigen la raíz hacia una ruta con prefijo de idioma.

Cómo detectarlo: el test más simple y definitivo es:

bash

curl -IL "https://tusitio.com/"

Si la respuesta es un 301 o 302 con un header Location: apuntando a una página de login, de idioma, o cualquier otra ruta —en vez de un 200 OK directo—, ahí está el problema.

La solución práctica

Si podés sacar la restricción que causa el redirect (por ejemplo, cambiar la visibilidad del sitio a pública), esa es la solución más «limpia». Pero si el sitio necesita quedarse privado por motivos válidos, hay una alternativa práctica: usar como «Site URL» en MainWP la URL final a la que redirige el sitio, en vez del dominio raíz.

En mi caso, el dominio redirigía así:

https://tusitio.com/  →  302  →  https://tusitio.com/es/pagina-de-login/?redirect_to=/

Y configurando directamente esa segunda URL en MainWP, la validación deja de chocar contra el redirect, porque esa URL específica ya responde con 200 OK sin redirección adicional.

Resumen del diagnóstico

Ante un error 302 en MainWP:

1. Probá curl -IL contra la raíz del dominio, no solo contra mainwp-child.php. El archivo del plugin casi siempre va a responder bien aunque el sitio esté bloqueado.
2. Si la raíz da 200 limpio, sospechá de un WAF/firewall (revisá logs de Wordfence, del hosting, o de cualquier escáner a nivel de servidor).
3. Si la raíz da 301/302, revisá qué la está causando (visibilidad del sitio, plugins de restricción, multi-idioma, reglas de servidor) y, si no podés eliminar la redirección, usá esa URL de destino directamente como Site URL en MainWP.

Ninguna de las dos causas es necesariamente visible desde WordPress mismo si no se sabe exactamente dónde mirar — por eso vale la pena descartarlas en este orden antes de perder tiempo con hipótesis más exóticas (DNS, IPv6, versiones de plugin, sincronización de reloj) que, aunque también pueden causar el mismo síntoma, son bastante menos frecuentes.