Resolución de problemas — Documentación

La mayoría de los problemas de configuración se reducen al DNS, al firewall en la nube o al bloqueo del puerto 25 de salida. Aquí tienes cómo reconocer y solucionar cada uno.

El panel no abre en mi dominio

http://server-IP/ funciona pero el dominio no: el DNS aún no resuelve. Comprueba panel.yourdomain.com en dnschecker.org (tipo A). Si está en blanco, tus registros DNS o nameservers no están configurados; consulta Apunta tu dominio.
El dominio no tiene nameservers en absoluto: la delegación en el registrador no está publicada, o configuraste los registros en un host DNS que no es autoritativo. Verifica los NS en dnschecker.org (tipo NS); si está vacío o incorrecto, corrige los nameservers en tu registrador, o pásate a Cloudflare.
Los nameservers apuntan a algún sitio, pero aun así no resuelve ("REFUSED"): el host DNS en realidad no está sirviendo la zona. Activa la gestión de DNS allí, o mueve el dominio a Cloudflare (siempre sirve la zona una vez añadida).

HTTPS no está activo (falta el candado)

HTTPS se activa automáticamente en unos ~5 minutos una vez que panel.yourdomain.com apunta al servidor. Si no lo ha hecho:

Confirma que el registro A resuelve a la IP correcta (dnschecker.org).
Asegúrate de que los puertos 80 y 443 están abiertos en tu firewall en la nube.
Si usas Cloudflare, configura el registro panel como DNS only (nube gris), no proxied.
Para forzarlo ahora: conéctate por SSH como root y ejecuta sudo nimbopanel-enable-https.

Los clientes no pueden enviar correo / el correo saliente rebota o expira

Abre System → Outgoing mail antes de asumir nada. La ficha mide si este servidor puede alcanzar internet por el puerto 25 y lo dice con claridad. Si informa de que el puerto está bloqueado, configura un relay desde el formulario de esa misma ficha; consulta Entregabilidad y envío de correo. Un relay que funciona muestra status=sent en el registro de correo.

Si la ficha dice que el puerto 25 está abierto, el bloqueo no es tu problema y la causa está en otra parte: revisa el mensaje de rebote del destinatario y comprueba SPF/DKIM/DMARC más abajo.

El correo se envía, pero cae en spam

El mensaje no está completamente autenticado. Comprueba que los tres estén publicados y pasando para el dominio remitente:

SPF incluye tu relay (por ejemplo, include:spf.brevo.com).
DKIM: el dominio está verificado en tu relay y sus registros DKIM están en tu DNS.
DMARC: existe un registro v=DMARC1; p=none; … (Nimbopanel agrega uno por dominio).

El correo entrante nunca llega

Confirma que el registro MX del dominio apunta a mail.yourdomain.com y que mail.yourdomain.com resuelve a tu servidor.
Asegúrate de que el puerto 25 entrante está abierto en tu firewall en la nube (el 25 entrante casi nunca está bloqueado; solo el de salida lo está).

Una página de herramienta (webmail, phpMyAdmin) muestra un error o no carga

phpMyAdmin devuelve 401 sin una sesión del panel: eso es lo esperado; ábrelo desde dentro del panel (inicio de sesión único).
Ninguna de las dos fichas aparece en el panel de un cliente: son solo para Debian/Ubuntu. En AlmaLinux, Rocky y RHEL el panel oculta ambas en lugar de enviar a un cliente a una página inexistente. Es así por diseño, no un fallo.
El webmail / un sitio devuelve 502: puede que un servicio de PHP se haya reiniciado. Comprueba los servicios con systemctl status. Si persiste tras un momento, vuelve a ejecutar el actualizador (sudo nimbopanel update) para reaplicar la configuración gestionada.

Problemas del sitio de un cliente

Una regla en .htaccess no hace nada. El sitio está en modo traducido. O bien pulsa Translate now en Domains → Apache / .htaccess, o activa el soporte completo de .htaccess. La tabla de esa página enumera exactamente qué directivas se están omitiendo. Consulta .htaccess — los dos modos.
Cada página devuelve 500 inmediatamente después de cambiar al soporte completo de .htaccess. A Apache le falta un módulo que el archivo necesita; mod_rewrite es el habitual, y está desactivado por defecto en Debian y Ubuntu. Vuelve a ejecutar el instalador (sudo nimbopanel update), que habilita los módulos requeridos; mientras tanto, vuelve a cambiar la cuenta.
Cada página devuelve 502 en una cuenta en modo .htaccess completo, mientras otros sitios funcionan bien. Apache no se está ejecutando: systemctl status apache2 (Debian/Ubuntu) o httpd (familia RHEL).
El sitio da 404 o muestra un directorio vacío tras un cambio de document root. La carpeta se publica exactamente como se escribió y se crea si no existe, así que un error tipográfico produce una carpeta vacía en lugar de un error. Lee el valor en la fila del dominio y corrígelo. Consulta Publicar desde una carpeta distinta a public_html.
El archivo .env o de configuración de un sitio es descargable. El document root está por encima de él. Mueve el document root a la carpeta public de la aplicación; curl -sI https://domain/.env debería responder 403.

Todos los sitios se cayeron a la vez

Si todos los sitios se detuvieron en el mismo momento, normalmente php-fpm no se está ejecutando. Comprueba con systemctl status php*-fpm. Si se niega a arrancar con Address already in use mientras ningún proceso php-fpm está vivo, un proceso que murió abruptamente ha dejado atrás un archivo de socket obsoleto; las versiones actuales de Nimbopanel los limpian por sí mismas antes de arrancar.

Dónde mirar

Los registros del panel y de los servicios viven en el journal de systemd: journalctl -u nimbopanel -n 50.
Resultados de entrega de correo: journalctl -t postfix/smtp --since -10min (busca status=sent / status=bounced).
El registro de instalación está en /var/log/nimbopanel-install.log.

¿Aún atascado? Anota el síntoma exacto y la línea de registro relevante: eso suele bastar para localizarlo rápido.