Dilohost Docs

Solución de problemas

Qué hacer cuando algo no funciona. Está ordenado por lo que ves, con la petición que tienes que hacerle a tu agente para averiguar la causa.

Actualizado el 11 de octubre de 2026 Ver en Markdown

Casi todo se resuelve pidiéndole a tu agente que lo mire. Las herramientas de Dilohost no se limitan a decir que algo ha fallado: explican la causa y qué hacer después. Si después de esto sigue sin funcionar, escríbenos (ver Soporte).

Consejo

La petición más útil cuando algo va mal es esta:

La web de la tienda no funciona. Mira qué le pasa y dime qué hay que hacer.

El agente usará app.diagnose, que revisa el estado de la app, su última publicación y sus registros, y te explica el problema en lenguaje llano.

El agente no encuentra Dilohost o no consigue iniciar sesión

  • El agente no muestra las herramientas de Dilohost. Comprueba que lo has añadido con la dirección exacta https://mcp.dilohost.es/mcp (ver Conectar tu agente). En Claude Code, escribe /mcp: Dilohost tiene que aparecer como conectado. En claude.ai o Claude Desktop, el conector tiene que estar activado en la conversación.
  • Te pide iniciar sesión una y otra vez. Termina el inicio de sesión en la ventana del navegador que se abre y aprueba el acceso en la pantalla de consentimiento. Si tu cuenta tiene el correo sin verificar, primero te pedirá verificarlo.
  • Funcionaba y ha dejado de funcionar. El acceso caduca si pasan 30 días sin usarlo, o si lo revocaste en el panel o cambiaste la contraseña con «He olvidado mi contraseña». Vuelve a iniciar sesión desde el agente.
  • Usas un token de servicio y responde 401. El token ha caducado, se ha revocado o quien lo creó ya no es el propietario de la cuenta. Crea otro (ver Tokens de servicio).

La publicación falla o tarda mucho

¿Cómo va la publicación de la web del proyecto tienda?

El agente consulta deploy.status hasta que la versión quede «en línea» o «fallida». Si falla, la respuesta trae el motivo y las últimas líneas del registro del build.

  • El primer build tarda mucho. Es normal que el primero de una app tarde bastante más que los siguientes, porque descarga y prepara todo lo necesario. Tiene hasta 60 minutos; los siguientes, 25. Si la respuesta trae para_que_tarde_menos, aplica ese consejo en la próxima publicación.
  • Tu proyecto trae un Dockerfile pensado para otro hosting. Suele hacer el build mucho más lento. Pide publicar con dockerfile=false: Dilohost lo construye sin él, y en PHP/Laravel es mucho más rápido.
  • El build se cortó por tiempo. Casi siempre es porque compila algo desde el código fuente o instala paquetes del sistema. Antes de publicar, pide deploy.guide: explica cómo evitarlo.
  • «Demasiados ficheros» o «no cabe». Publicar con files admite hasta 400 ficheros y 8 MB. Para proyectos más grandes, sube el código con git, desde tu repositorio o en un zip (ver Formas de subir el código).
  • «Has llegado al límite de publicaciones de hoy». Cada plan tiene un número de publicaciones al día. Espera al día siguiente o cambia de plan (ver Planes y precios).

La app se publica pero no arranca

Si la versión nueva no arranca, Dilohost vuelve a poner la anterior, así que tu web no se queda caída. Además te explica qué falló. Pide app.diagnose para verlo. Las causas más habituales:

Lo que dice el diagnóstico Qué hacer
La app usa un puerto ocupado o no responde Haz que escuche en 0.0.0.0 y en el puerto de la variable PORT (8080)
No puede conectar con la base de datos o la contraseña no es correcta Pide conectar la base a la app (database.connection con inject_into) para que reciba sus datos de conexión como variables
Falta una variable de entorno Añádela (config.set). Si es una contraseña o una clave, como secreta
Intenta escribir donde no puede Escribe en /tmp, que es temporal, o pide un disco persistente (volume_path) para lo que tenga que durar
Se queda sin memoria Reduce lo que carga al arrancar o cambia a un plan con más memoria por app

Para ver qué escribe la app, pide sus registros («enséñame los últimos registros de la app web»). Para volver a una versión que funcionaba, pide deploy.rollback (ver Versiones).

Error al conectar con la base de datos

Las bases de datos solo aceptan conexiones cifradas y verificadas. Si conectas la base con database.connection e inject_into, la app recibe todo lo que necesita: la URL de conexión, las variables DB_* y las del certificado. Si aun así falla:

  • self-signed certificate in certificate chain o un error de certificado. Tu código no está usando las variables que recibe. Con PostgreSQL, usa DATABASE_URL tal cual (ya lleva sslmode=verify-full y la ruta del certificado) o las variables PGSSLMODE y PGSSLROOTCERT. Con MySQL, usa MYSQL_ATTR_SSL_CA.
  • La conexión se rechaza sin más. Comprueba que la app usa la conexión que se le inyectó y no una dirección escrita a mano en el código.
  • La base ha dejado de aceptar conexiones. Si ocupa bastante más de lo que permite tu plan, se le corta el acceso. Libera espacio o cambia de plan, y se vuelve a abrir. Ver Bases de datos.

El dominio no se verifica o no tiene HTTPS

¿En qué estado está el dominio mipanaderia.es?

domain.status dice en qué paso está y qué falta.

  • No se verifica. Para demostrar que el dominio es tuyo, el registro TXT se pone en el nombre _dilohost-verify de tu dominio, con el valor exacto que te dio el agente. No sirve ponerlo en la raíz ni hacer que ese nombre sea un CNAME. Los cambios de DNS pueden tardar en verse. Tienes 7 días; después hay que empezar otra vez.
  • Cambiaste los nameservers y sigue «pendiente». El cambio puede tardar horas en verse. Si a los 30 días no se ve, el dominio se retira y hay que conectarlo de nuevo.
  • No tiene HTTPS. El certificado solo se pide cuando el dominio y su www ya apuntan a Dilohost. Si tu DNS está en otro sitio, revisa los registros que te indicó el agente. Ver Traer tu dominio.

El correo no llega o no se puede enviar

¿Está listo el correo de mipanaderia.es?

email.status dice si ya se puede recibir y enviar. Si el DNS del dominio está fuera de Dilohost, también dice qué registros faltan.

  • No llega nada. El registro MX del dominio tiene que apuntar a mail.dilohost.es, y solo a él. Si el DNS está en Dilohost, se pone solo. Si está fuera, lo tienes que poner tú.
  • Recibes pero no puedes enviar. Para enviar, el dominio tiene que estar verificado. Hacen falta los tres registros DKIM y un SPF que incluya include:amazonses.com. Suele tardar unos minutos desde que se ven. Si el DNS está en Cloudflare, los DKIM van sin proxy (nube gris).
  • El programa de correo no conecta. Revisa los datos del servidor y que usas la dirección completa como usuario. Ver Configurar el móvil y Outlook.
  • No puedes enviar con otra dirección como remitente. Cada buzón solo puede enviar con su propia dirección o sus alias.

La migración del correo falla

email.migrate_status dice cómo va la copia y, si falló, por qué.

  • Contraseña rechazada en Gmail, iCloud, Yahoo, Zoho o Fastmail. Estos proveedores exigen una contraseña de aplicación, no la normal. Créala en la cuenta del proveedor y vuelve a lanzar la migración.
  • Microsoft 365 / Outlook.com. No se puede migrar desde aquí: esos buzones solo dejan entrar por IMAP con OAuth.
  • «El buzón se ha llenado». El correo antiguo ocupa más que el buzón de destino (5 GB). Lo que cupo ya está copiado. Libera espacio en el origen o reparte el correo antes de seguir.
  • Faltan los correos que llegaron durante el cambio. Después de cambiar el MX, pide email.migrate_again: solo copia lo que falta.

Todo el proceso está en Traer tu correo antiguo.

«Has llegado al límite»

Tu plan tiene un número máximo de proyectos, apps, bases de datos, almacenes de ficheros, dominios, buzones y publicaciones al día. El mensaje dice cuál se ha alcanzado. Puedes:

  • borrar lo que no uses;
  • o cambiar de plan (billing.change_plan, que te muestra antes lo que se cobra).

Los límites de cada plan están en Planes y precios; los técnicos, iguales para todos, en Límites.

Mis apps se han parado solas

¿Por qué se ha parado mi app? ¿Cuánto llevo gastado este mes?

billing.usage da lo gastado, el crédito que queda y el tope de gasto. Las apps con servidor, los procesos y las tareas se paran en dos casos (las webs estáticas y el correo siguen funcionando):

  • Plan Gratis sin crédito ni saldo. Has gastado el crédito de uso del mes y no queda saldo para pagar el exceso. Vuelven solas el día 1, o en cuanto recargues saldo (billing.add_funds).
  • Has llegado a tu tope de gasto. En los planes de pago, el exceso de uso se cobra hasta el tope que tú eliges. Súbelo o quítalo (billing.spend_cap) y vuelven al momento.

Te avisamos por correo al llegar al 80 % y al 100 % del crédito. Ver Pagos, IVA y tope de gasto.

La cuenta está suspendida

Si una herramienta responde «La cuenta está suspendida», el mensaje dice el motivo.

  • Impago. Stripe no ha podido cobrar la suscripción después de reintentarlo. Tus datos se conservan. Actualiza el método de pago en el portal de pagos (billing.portal): en cuanto se cobre, la cuenta se reactiva sola. Si sigue sin pagarse, a los 30 días te avisamos de que se borrarán los proyectos, y a los 45 se borran.
  • Revisión por seguridad. Se ha detectado un uso que incumple las condiciones, como phishing, minería o abuso de recursos. Mientras dure no se pueden hacer cambios. Escríbenos a hola@dilohost.es para revisarlo.

Relacionado