diff --git a/docs/cutover/certificados-letsencrypt-cloudflare.md b/docs/cutover/certificados-letsencrypt-cloudflare.md
index 8edeeda..0563006 100644
--- a/docs/cutover/certificados-letsencrypt-cloudflare.md
+++ b/docs/cutover/certificados-letsencrypt-cloudflare.md
@@ -64,15 +64,49 @@ El problema está **delante**, en el borde de Cloudflare, no en Hetzner.
 
 ## El arreglo
 
-**Cloudflare → Rules → Configuration Rules.** Una regla acotada a la ruta del reto:
+⚠️ **Corrección (Inma, 3-ago): en este plan de Cloudflare las Configuration Rules NO ofrecen
+"Always Use HTTPS" ni "Security Level".** Los ajustes disponibles son Automatic HTTPS Rewrites,
+Browser Integrity Check, Disable RUM, Disable Zaraz, Email Obfuscation, Fonts, Hotlink Protection,
+I'm Under Attack, Opportunistic Encryption, Polish, Request/Response Body Buffering, Rocket Loader y
+SSL. **La regla no se puede montar así.**
 
-- **Ámbito:** `*feadulta.com/.well-known/acme-challenge/*`
-- **Always Use HTTPS → Off** — para que el reto se complete por el puerto 80, donde Traefik lo atiende
-- **Security Level → Essentially Off** (o una regla WAF de tipo *Skip* para esa ruta)
+### Lo que sí se puede hacer
+
+1. **Custom rule del WAF con acción *Skip*** para `/.well-known/acme-challenge/` — quita el 403.
+2. **Apagar "Always Use HTTPS" a nivel de zona** durante el reintento, y volver a encenderlo
+   después.
 
 Es una excepción mínima y acotada: esa ruta no sirve contenido, solo tokens de un solo uso que el
 propio Traefik genera y valida.
 
+### ⚠️ Puede que aun así no salga, y conviene saber por qué antes de intentarlo
+
+Con el modo SSL de la zona en **`Full`, Cloudflare habla con el origen por HTTPS**. Si eso se aplica
+también a las peticiones que le entran por HTTP, entonces al apagar "Always Use HTTPS" la petición
+de Let's Encrypt llegará igualmente al **443** de Traefik, donde **el handler de ACME no existe** —y
+volverá a fallar, ahora con un 404 en vez de un 403.
+
+No se puede determinar desde aquí sin apagar el ajuste: mientras "Always Use HTTPS" esté encendido,
+Cloudflare redirige en su borde y **nunca llega a contactar con el origen por el puerto 80**, así que
+no hay forma de observar qué puerto usaría.
+
+**Cómo distinguir los dos casos en el siguiente intento**, mirando el error de Traefik:
+
+| lo que reporte Let's Encrypt | qué significa | qué hacer |
+|---|---|---|
+| sale el certificado | Cloudflare reenvía por el 80 y Traefik atiende | nada más |
+| `403` | el *Skip* del WAF no está cogiendo esa ruta | revisar el ámbito de la regla |
+| **`404`** | **Cloudflare va al 443 del origen**: HTTP-01 no puede funcionar con la zona en `Full` | **pasar a DNS-01, dejar de quemar validaciones** |
+
+### Sobre los visitantes durante la ventana
+
+Apagar "Always Use HTTPS" unos minutos es inocuo, pero **no exactamente por el motivo que parece**.
+Si Cloudflare reenviara por el 80, Traefik devuelve un 302 a HTTPS por su cuenta (medido) y el
+visitante acaba igual. Si Cloudflare va al 443, ese 302 no llega a dispararse y **un visitante que
+entre por `http://` se quedará en `http://`** — con el contenido correcto y cifrado hasta Cloudflare,
+pero sin subir a HTTPS. Para una ventana de minutos no tiene consecuencias, pero que nadie se
+extrañe si lo ve.
+
 ### Alternativa de fondo, para más adelante
 
 Pasar Traefik a validación **DNS-01** con el token de Cloudflare que ya tenemos