rafa/feadulta
1
0
Fork 0
Code Issues 71 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

antiguo.feadulta.com sirve WordPress en vez de Joomla (via Cloudflare) — origen OK en directo #164

New Issue
Open
opened 2026-07-08 14:18:34 +00:00 by rafa · 5 comments
rafa commented 2026-07-08 14:18:34 +00:00
Owner
Copy Link
Copy Source

Sintoma

antiguo.feadulta.com deberia servir el Joomla post-cutover, pero navegando normal (confirmado en incognito + hard refresh, no es cache de navegador) aterriza en el WordPress (contenido de www.feadulta.com).

Verificado — el origen esta bien

SSH al servidor (134.0.10.170) y curl LOCAL forzando SNI correcto, saltandome DNS/Cloudflare:

curl -sk --resolve antiguo.feadulta.com:443:127.0.0.1 https://antiguo.feadulta.com/
-> 301 a /es/
-> /es/ -> 200, Joomla real (cookie de sesion PHP, meta keywords Joomla, sin marcas WP)

Apache/.htaccess de /web/antiguo/ tiene el rewrite Joomla estandar + una regla custom que solo actua si HTTP_HOST es exactamente feadulta.com (dominio pelado), no deberia afectar a antiguo..

DNS

antiguo.feadulta.com, www.feadulta.com y wp-nuevo.feadulta.com resuelven las 3 a las mismas IPs anycast de Cloudflare (172.67.129.42 / 104.21.1.107) — normal, todo proxied (naranja).

Lo que no pude verificar

Desde fuera (mi maquina, atravesando Cloudflare real) cualquier curl a estos dominios da 403 de bot-challenge de Cloudflare antes de llegar a nada util (headers tipo cf-cache-status no llegan a verse). No tenemos token de API de Cloudflare — solo Inma tiene acceso al dashboard.

Hipotesis

Como el origen sirve Joomla bien cuando se le pregunta directamente, pero por Cloudflare llega a WP, el problema probablemente esta en la capa de Cloudflare: un Redirect Rule / Page Rule / Origin Rule antiguo que reescribe el Host hacia el origen o redirige a nivel de edge antes de llegar a Apache, o el registro DNS de antiguo no es un A/CNAME proxied normal sino algo tipo Cloudflare Pages/Worker.

Pendiente para Inma (dashboard Cloudflare)

  • Rules > Redirect Rules — buscar reglas que afecten a antiguo.feadulta.com
  • Rules > Origin Rules — buscar reescritura de Host header para ese hostname
  • Page Rules (clasicas, si quedan) — lo mismo
  • Caching > Cache Rules / purga — por si hay una copia cacheada de WP bajo esa URL
  • DNS: registro de antiguo en concreto (¿A/CNAME proxied normal, o algo distinto?)

Relacionado (ya resuelto en esta sesion)

Horas antes hubo otro bug: wp-nuevo.feadulta.com quedo con directorio vacio tras el mv del cutover, causando bucles de redirección Apache (AH00124/AH01276). Rafa borro el subdominio en cPanel y se resolvio (esas peticiones caen ahora en el vhost principal WP, que gestiona el 404 con redireccion propia a antiguo.feadulta.com). Se corrigio tambien el menu WP (Cartas > Acceso a webs anteriores > Web V2 - Joomla), que apuntaba a www.feadulta.com en vez de antiguo.feadulta.com (post ID 1, wp_navigation).

## Sintoma `antiguo.feadulta.com` deberia servir el Joomla post-cutover, pero navegando normal (confirmado en incognito + hard refresh, no es cache de navegador) aterriza en el WordPress (contenido de www.feadulta.com). ## Verificado — el origen esta bien SSH al servidor (134.0.10.170) y curl LOCAL forzando SNI correcto, saltandome DNS/Cloudflare: ``` curl -sk --resolve antiguo.feadulta.com:443:127.0.0.1 https://antiguo.feadulta.com/ -> 301 a /es/ -> /es/ -> 200, Joomla real (cookie de sesion PHP, meta keywords Joomla, sin marcas WP) ``` Apache/.htaccess de `/web/antiguo/` tiene el rewrite Joomla estandar + una regla custom que solo actua si `HTTP_HOST` es exactamente `feadulta.com` (dominio pelado), no deberia afectar a `antiguo.`. ## DNS `antiguo.feadulta.com`, `www.feadulta.com` y `wp-nuevo.feadulta.com` resuelven las 3 a las mismas IPs anycast de Cloudflare (172.67.129.42 / 104.21.1.107) — normal, todo proxied (naranja). ## Lo que no pude verificar Desde fuera (mi maquina, atravesando Cloudflare real) cualquier curl a estos dominios da 403 de bot-challenge de Cloudflare antes de llegar a nada util (headers tipo cf-cache-status no llegan a verse). No tenemos token de API de Cloudflare — solo Inma tiene acceso al dashboard. ## Hipotesis Como el origen sirve Joomla bien cuando se le pregunta directamente, pero por Cloudflare llega a WP, el problema probablemente esta en la capa de Cloudflare: un Redirect Rule / Page Rule / Origin Rule antiguo que reescribe el Host hacia el origen o redirige a nivel de edge antes de llegar a Apache, o el registro DNS de `antiguo` no es un A/CNAME proxied normal sino algo tipo Cloudflare Pages/Worker. ## Pendiente para Inma (dashboard Cloudflare) - Rules > Redirect Rules — buscar reglas que afecten a `antiguo.feadulta.com` - Rules > Origin Rules — buscar reescritura de Host header para ese hostname - Page Rules (clasicas, si quedan) — lo mismo - Caching > Cache Rules / purga — por si hay una copia cacheada de WP bajo esa URL - DNS: registro de `antiguo` en concreto (¿A/CNAME proxied normal, o algo distinto?) ## Relacionado (ya resuelto en esta sesion) Horas antes hubo otro bug: `wp-nuevo.feadulta.com` quedo con directorio vacio tras el `mv` del cutover, causando bucles de redirección Apache (AH00124/AH01276). Rafa borro el subdominio en cPanel y se resolvio (esas peticiones caen ahora en el vhost principal WP, que gestiona el 404 con redireccion propia a antiguo.feadulta.com). Se corrigio tambien el menu WP (Cartas > Acceso a webs anteriores > Web V2 - Joomla), que apuntaba a www.feadulta.com en vez de antiguo.feadulta.com (post ID 1, wp_navigation).
rafa commented 2026-07-08 14:20:03 +00:00
Author
Owner
Copy Link
Copy Source

Actualizacion: descartado el origen tambien en la IP publica

Opus sugirio que mi primer test (loopback 127.0.0.1 desde dentro del SSH) podia no ser representativo, porque Cloudflare conecta a la IP publica (134.0.10.170), no a loopback -- si el vhost SSL por defecto en la interfaz publica fuera el de WordPress, el origen fallaria igual aunque loopback funcionase.

Repeti el test contra la IP publica directamente, sin pasar por Cloudflare:

curl -sk --resolve antiguo.feadulta.com:443:134.0.10.170 https://antiguo.feadulta.com/
-> 301 a /es/ -> 200, Joomla real

Resultado: correcto tambien en la IP publica. Esto descarta que sea un problema de vhost/Apache en el servidor. El problema esta aislado 100% en la capa de Cloudflare.

Pendiente para Inma (sin cambios en la lista, pero ahora con mas confianza)

  • DNS del registro antiguo: ¿A/CNAME proxied normal a la IP del server, o algo raro (CNAME a www, a Pages, a un Worker)?
  • Rules > Redirect Rules / Page Rules (legacy) / Bulk Redirects (a nivel de cuenta) -- reglas antiguas tipo "todo a www" que puedan estar capturando tambien antiguo.
  • Workers & Pages > Routes -- ruta que capture antiguo.feadulta.com/*
  • Rules > Origin Rules -- Host Header Override hacia www
  • Caching > Cache Rules + Purge Everything para antiguo. por si hay WP cacheado

Dato util para distinguir rapido cual es: si al entrar a antiguo.feadulta.com la barra de direcciones CAMBIA a www (redirect visible) es Redirect Rule/Bulk Redirect. Si la URL se queda en antiguo. pero el contenido es WP, es Origin Rule / Worker / cache (no hay redirect, hay reescritura o servido en el edge).

## Actualizacion: descartado el origen tambien en la IP publica Opus sugirio que mi primer test (loopback 127.0.0.1 desde dentro del SSH) podia no ser representativo, porque Cloudflare conecta a la IP publica (134.0.10.170), no a loopback -- si el vhost SSL por defecto en la interfaz publica fuera el de WordPress, el origen fallaria igual aunque loopback funcionase. Repeti el test contra la IP publica directamente, sin pasar por Cloudflare: ``` curl -sk --resolve antiguo.feadulta.com:443:134.0.10.170 https://antiguo.feadulta.com/ -> 301 a /es/ -> 200, Joomla real ``` **Resultado: correcto tambien en la IP publica.** Esto descarta que sea un problema de vhost/Apache en el servidor. El problema esta aislado 100% en la capa de Cloudflare. ## Pendiente para Inma (sin cambios en la lista, pero ahora con mas confianza) - DNS del registro `antiguo`: ¿A/CNAME proxied normal a la IP del server, o algo raro (CNAME a www, a Pages, a un Worker)? - Rules > Redirect Rules / Page Rules (legacy) / Bulk Redirects (a nivel de cuenta) -- reglas antiguas tipo "todo a www" que puedan estar capturando tambien `antiguo.` - Workers & Pages > Routes -- ruta que capture `antiguo.feadulta.com/*` - Rules > Origin Rules -- Host Header Override hacia www - Caching > Cache Rules + Purge Everything para `antiguo.` por si hay WP cacheado Dato util para distinguir rapido cual es: si al entrar a antiguo.feadulta.com la barra de direcciones CAMBIA a www (redirect visible) es Redirect Rule/Bulk Redirect. Si la URL se queda en `antiguo.` pero el contenido es WP, es Origin Rule / Worker / cache (no hay redirect, hay reescritura o servido en el edge).
inma commented 2026-07-08 17:23:49 +00:00
Collaborator
Copy Link
Copy Source

Investigado (Inma + Claude) — era caché stale de Cloudflare, ya resuelto

Sondeo desde fuera (máquina distinta a la tuya, atravesando Cloudflare real; esta vez sin bot-challenge):

  • antiguo.feadulta.com → 301 a antiguo.feadulta.com/es/ — la URL se queda en antiguo., no salta a www → descarta Redirect Rule / Bulk Redirect.
  • Contenido servido = Joomla real: cookie de sesión PHP befa4ebc…, 6 marcadores Joomla, 0 de WordPress, <title>Feadulta</title>.
  • cf-cache-status: DYNAMIC en 8/8 pasadas (root y /es/, PoP MAD) → va al origen cada vez, descarta Origin Rule / Worker (no hay reescritura activa).
  • Inma lo confirma en su navegador (incógnito + hard refresh): ve el Joomla viejo correctamente, con el banner "Hemos migrado a una web nueva…".

Conclusión: el síntoma era una copia de WordPress cacheada en el edge de Cloudflare bajo antiguo.feadulta.com (residuo del cutover). Ha caducado y ahora sirve fresco del origen = Joomla. No hay regla de redirección / origen / worker implicada.

Prevención (Inma la está aplicando ahora): Rules → Cache Rules → si Hostname = antiguo.feadulta.com → Bypass cache (el Joomla lleva sesión PHP, no debe cachearse en el edge; así no puede volver a colarse una copia WP).

Con eso, se puede cerrar. 🎯

## Investigado (Inma + Claude) — era caché stale de Cloudflare, ya resuelto Sondeo desde fuera (máquina distinta a la tuya, atravesando Cloudflare real; esta vez **sin** bot-challenge): - `antiguo.feadulta.com` → **301 a `antiguo.feadulta.com/es/`** — la URL **se queda en `antiguo.`**, no salta a www → **descarta Redirect Rule / Bulk Redirect**. - Contenido servido = **Joomla real**: cookie de sesión PHP `befa4ebc…`, 6 marcadores Joomla, **0** de WordPress, `<title>Feadulta</title>`. - **`cf-cache-status: DYNAMIC` en 8/8 pasadas** (root y `/es/`, PoP MAD) → va al origen cada vez, **descarta Origin Rule / Worker** (no hay reescritura activa). - Inma lo confirma en su navegador (incógnito + hard refresh): ve el **Joomla viejo correctamente**, con el banner "Hemos migrado a una web nueva…". **Conclusión:** el síntoma era una copia de **WordPress cacheada en el edge de Cloudflare** bajo `antiguo.feadulta.com` (residuo del cutover). Ha caducado y ahora sirve fresco del origen = Joomla. **No hay** regla de redirección / origen / worker implicada. **Prevención (Inma la está aplicando ahora):** Rules → Cache Rules → si Hostname = `antiguo.feadulta.com` → **Bypass cache** (el Joomla lleva sesión PHP, no debe cachearse en el edge; así no puede volver a colarse una copia WP). Con eso, se puede **cerrar**. 🎯
inma commented 2026-07-08 17:40:10 +00:00
Collaborator
Copy Link
Copy Source

Cierre — regla de bypass desplegada y verificado

Cambio aplicado (Inma, dashboard Cloudflare):

  • Caching → Cache Rules → regla nueva "Bypass cache antiguo (Joomla)":
    • Expresión: (http.host eq "antiguo.feadulta.com")
    • Acción: Bypass cache.
  • Al desplegar, Cloudflare avisó "This rule may not apply… DNS may not be proxying antiguo". Es falsa alarma: antiguo. va por un comodín *.feadulta.com proxied (el detector no ve un registro exacto "antiguo"). Elegido "Ignore and deploy rule anyway"; NO se creó ningún registro DNS nuevo.

Comprobaciones tras desplegar (desde fuera, atravesando Cloudflare):

  • antiguo.feadulta.com/es/ → Joomla real (0 marcadores WP, 6 Joomla), consistente en varias pasadas.
  • cf-cache-status: DYNAMIC tanto en el HTML como en un recurso estático (/modules/mod_tabs_gk5/styles/style3.css, text/css) → Cloudflare va al origen en cada petición; imposible servir una copia WP cacheada.
  • La etiqueta se queda en DYNAMIC (no BYPASS) porque el contenido ya es no-cacheable de por sí (cookie de sesión PHP de Joomla); el resultado práctico es el mismo. La regla de bypass queda como garantía extra.

Estado: resuelto (era caché stale del cutover, ya caducada + regla de bypass como prevención). Por mi parte se puede cerrar. 🎯

## Cierre — regla de bypass desplegada y verificado **Cambio aplicado (Inma, dashboard Cloudflare):** - **Caching → Cache Rules** → regla nueva **"Bypass cache antiguo (Joomla)"**: - Expresión: `(http.host eq "antiguo.feadulta.com")` - Acción: **Bypass cache**. - Al desplegar, Cloudflare avisó *"This rule may not apply… DNS may not be proxying antiguo"*. Es falsa alarma: `antiguo.` va por un **comodín `*.feadulta.com` proxied** (el detector no ve un registro exacto "antiguo"). Elegido **"Ignore and deploy rule anyway"**; **NO** se creó ningún registro DNS nuevo. **Comprobaciones tras desplegar (desde fuera, atravesando Cloudflare):** - `antiguo.feadulta.com/es/` → **Joomla real** (0 marcadores WP, 6 Joomla), consistente en varias pasadas. - `cf-cache-status: DYNAMIC` tanto en el HTML como en un **recurso estático** (`/modules/mod_tabs_gk5/styles/style3.css`, `text/css`) → Cloudflare va **al origen en cada petición**; imposible servir una copia WP cacheada. - La etiqueta se queda en `DYNAMIC` (no `BYPASS`) porque el contenido ya es no-cacheable de por sí (cookie de sesión PHP de Joomla); el resultado práctico es el mismo. La regla de bypass queda como garantía extra. **Estado:** resuelto (era caché stale del cutover, ya caducada + regla de bypass como prevención). Por mi parte se puede **cerrar**. 🎯
inma commented 2026-07-08 19:50:17 +00:00
Collaborator
Copy Link
Copy Source

⚠️ Resuelto de verdad — NO era Cloudflare ni caché: era la GRAFÍA del subdominio

Mi comentario anterior sobre "caché stale" queda descartado (perseguí un fantasma; solo miré mi propio edge). La causa real:

Hay dos grafías y sirven cosas distintas:

Subdominio Sirve title
antig**u**o.feadulta.com (O, el que configuraste) Joomla (web vieja) ✔ Feadulta
antig**u**a.feadulta.com (A) WordPress (web nueva) ✗ Fe adulta – feadulta.com

Verificado ahora mismo desde fuera (a través de Cloudflare, 5 pasadas) y directo al origen (--resolve a 134.0.10.170): antiguo (O) sirve Joomla correctamente. Ambos resuelven a las mismas IPs de Cloudflare (comodín proxied), pero el origen solo tiene vhost para antiguo (O); antigua (A) no está configurado → cae en el vhost por defecto de WordPress.

Por qué nos confundió

  • Tus tests por SSH/curl usaban antiguo (O) → Joomla, correcto.
  • Pero en el navegador se teclea antigua (A, "la web antigua", femenino) → WordPress.
  • Eran dos subdominios distintos: por eso "el origen está bien pero por navegador sale WP".

Arreglo sugerido (tu parcela)

Dar de alta antigua.feadulta.com (A) como alias del vhost Joomla en Apache, o redirect antigua → antiguo. Como "la web antigua" se escribe en femenino de forma natural, conviene que antigua (A) funcione (o incluso sea la principal).

La Cache Rule de bypass que añadió Inma es inofensiva y no pinta aquí; puede quedarse o quitarse.

## ⚠️ Resuelto de verdad — NO era Cloudflare ni caché: era la GRAFÍA del subdominio Mi comentario anterior sobre "caché stale" queda **descartado** (perseguí un fantasma; solo miré mi propio edge). La causa real: Hay **dos grafías** y sirven cosas distintas: | Subdominio | Sirve | title | |---|---|---| | `antig**u**o.feadulta.com` (**O**, el que configuraste) | **Joomla** (web vieja) ✔ | `Feadulta` | | `antig**u**a.feadulta.com` (**A**) | **WordPress** (web nueva) ✗ | `Fe adulta – feadulta.com` | Verificado ahora mismo desde fuera (a través de Cloudflare, 5 pasadas) **y** directo al origen (`--resolve` a 134.0.10.170): **`antiguo` (O) sirve Joomla correctamente**. Ambos resuelven a las mismas IPs de Cloudflare (comodín proxied), pero **el origen solo tiene vhost para `antiguo` (O)**; `antigua` (A) **no está configurado** → cae en el vhost por defecto de WordPress. ## Por qué nos confundió - Tus tests por SSH/curl usaban `antiguo` (O) → Joomla, correcto. - Pero en el **navegador** se teclea `antigua` (A, "la web antigua", femenino) → WordPress. - Eran **dos subdominios distintos**: por eso "el origen está bien pero por navegador sale WP". ## Arreglo sugerido (tu parcela) Dar de alta **`antigua.feadulta.com` (A)** como **alias del vhost Joomla** en Apache, o **redirect `antigua → antiguo`**. Como "la web antigua" se escribe en femenino de forma natural, conviene que `antigua` (A) funcione (o incluso sea la principal). La Cache Rule de bypass que añadió Inma es inofensiva y no pinta aquí; puede quedarse o quitarse.
rafa commented 2026-07-08 22:02:28 +00:00
Author
Owner
Copy Link
Copy Source

Nuevo: alta de antigua.feadulta.com (typo con 'a') como alias -> antiguo.feadulta.com

Rafa quiere dar de alta antigua.feadulta.com para que quien escriba mal el dominio (antigua en vez de antiguo) llegue igualmente al Joomla legacy. Pregunta: alias DNS directo al servidor, o redirigir a antiguo.

Recomendacion: NO dar de alta un registro A/subdominio cPanel independiente para antigua. Si solo se apunta el DNS a la IP del servidor sin vhost/subdominio configurado en cPanel para ese hostname exacto, Apache no sabe que servir (cae en el vhost por defecto o da error de certificado si Cloudflare no tiene el hostname dado de alta para TLS). Ademas anadir otro subdominio cPanel es mas superficie para repetir el lio de RewriteBase/bucles de redireccion que ya nos mordio con antiguo y wp-nuevo en el cutover (ver el resto de este issue y los AH00124 del 2026-07-08).

Mejor: resolverlo entero en el edge de Cloudflare, sin tocar Apache/cPanel:

  1. DNS -> anadir registro A (o CNAME) antigua -> misma IP que usa antiguo (134.0.10.170), proxy activado (nube naranja). Asi Cloudflare gestiona el TLS del hostname nuevo sin tocar el hosting.
  2. Rules > Redirect Rules (antes Page Rules) -> regla nueva: si Hostname = antigua.feadulta.com, redirigir 301 a https://antiguo.feadulta.com/$1 (o destino fijo si no hace falta preservar el path).

Todo pasa por Cloudflare antes de llegar al origen — coherente con que esto es tarea de Inma en el dashboard (igual que el resto de pendientes de este issue), no requiere acceso SSH ni cambios en el servidor.

Pendiente: Inma da de alta el registro DNS + la Redirect Rule quo cuando revise el resto de puntos de este issue.

## Nuevo: alta de `antigua.feadulta.com` (typo con 'a') como alias -> antiguo.feadulta.com Rafa quiere dar de alta `antigua.feadulta.com` para que quien escriba mal el dominio (antigua en vez de antiguo) llegue igualmente al Joomla legacy. Pregunta: alias DNS directo al servidor, o redirigir a `antiguo`. **Recomendacion: NO dar de alta un registro A/subdominio cPanel independiente para `antigua`.** Si solo se apunta el DNS a la IP del servidor sin vhost/subdominio configurado en cPanel para ese hostname exacto, Apache no sabe que servir (cae en el vhost por defecto o da error de certificado si Cloudflare no tiene el hostname dado de alta para TLS). Ademas anadir otro subdominio cPanel es mas superficie para repetir el lio de `RewriteBase`/bucles de redireccion que ya nos mordio con `antiguo` y `wp-nuevo` en el cutover (ver el resto de este issue y los AH00124 del 2026-07-08). **Mejor: resolverlo entero en el edge de Cloudflare, sin tocar Apache/cPanel:** 1. **DNS** -> anadir registro `A` (o `CNAME`) `antigua` -> misma IP que usa `antiguo` (134.0.10.170), proxy activado (nube naranja). Asi Cloudflare gestiona el TLS del hostname nuevo sin tocar el hosting. 2. **Rules > Redirect Rules** (antes Page Rules) -> regla nueva: si Hostname = `antigua.feadulta.com`, redirigir 301 a `https://antiguo.feadulta.com/$1` (o destino fijo si no hace falta preservar el path). Todo pasa por Cloudflare antes de llegar al origen — coherente con que esto es tarea de Inma en el dashboard (igual que el resto de pendientes de este issue), no requiere acceso SSH ni cambios en el servidor. Pendiente: Inma da de alta el registro DNS + la Redirect Rule quo cuando revise el resto de puntos de este issue.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
inma rafa
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: rafa/feadulta#164
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?