Qué significa cada mensaje, qué comprobar y en qué orden, y el comando que lo corrige. El error va en inglés porque así lo emite el programa y así se busca; la explicación va en español.
El servidor rechaza la clave SSH
La conexión se corta sin llegar a pedir contraseña. El servidor ha recibido la clave y no la ha aceptado, o no ha llegado a considerar ninguna.
La conexión SSH se rechaza antes de negociar
El error llega de inmediato, sin esperar. Algo ha contestado al puerto y ha dicho que no: es distinto de un tiempo de espera agotado, que significa que no contestó nadie.
La clave de host del servidor no coincide con la guardada
SSH se niega a conectar y avisa de que la identificación del servidor ha cambiado. El cliente guarda la huella de cada servidor la primera vez y compara en cada conexión.
SSH agota los intentos antes de probar la clave correcta
La conexión se corta tras unos segundos aunque tengas la clave buena. El cliente ofrece todas las claves del agente una a una y el servidor corta al llegar a MaxAuthTries, que por…
Nginx no obtiene respuesta válida de la aplicación
Nginx responde y funciona. Lo que falla es lo que hay detrás: la aplicación a la que hace de proxy no contesta, contesta mal o no deja conectar.
Nginx corta las subidas de fichero por tamaño
Las subidas fallan a partir de cierto tamaño. El valor por defecto de client_max_body_size es 1 MB, así que aparece en cuanto alguien adjunta una imagen de móvil.
Nginx no arranca porque el puerto está ocupado
El servicio no llega a levantar. Otro proceso —o el propio Nginx que no terminó de pararse— ya tiene el puerto.
El servicio no arranca y systemd no dice por qué
systemctl start devuelve error y remite a systemctl status y journalctl. El mensaje en sí no contiene la causa: solo dice que el proceso terminó mal.
systemd no encuentra la unidad
El fichero está donde crees que está, pero systemd dice que no existe. Casi siempre es que no lo ha leído todavía, o que el nombre no es el que piensas.
systemd da el arranque por agotado
El servicio se queda en «activating» hasta que systemd lo mata. El proceso arranca pero nunca dice que está listo, o tarda más de lo permitido. En el journal la línea…
El disco no admite escrituras, aunque df diga que queda sitio
Los servicios empiezan a fallar de formas raras: bases de datos que no arrancan, logs que se cortan, sesiones que no se guardan. Todo lo que escribe deja de funcionar a la vez.
El sistema de ficheros ha pasado a solo lectura
No se puede escribir en ningún sitio y hasta los comandos más simples fallan. El kernel ha remontado el sistema en solo lectura para no empeorar un problema que ya ha detectado.
El fichero no se puede ejecutar
El fichero existe y se lee bien, pero no arranca. Hay cuatro motivos distintos y el mensaje es el mismo para todos.
La operación se deniega incluso siendo root
A diferencia de «Permission denied», este error aparece cuando los permisos del fichero son correctos e incluso cuando la orden se ejecuta como root. Hay otra capa por encima.
El cliente no encuentra el socket de MySQL o MariaDB
La conexión local falla mientras que por TCP a 127.0.0.1 puede funcionar. El error 2 significa que el fichero de socket no existe.
La base de datos rechaza conexiones nuevas
La aplicación empieza a dar errores de conexión bajo carga. El servidor ha llegado a max_connections y no acepta más.
PostgreSQL rechaza la contraseña
La contraseña es correcta y aun así se rechaza. En PostgreSQL el método de autenticación depende de desde dónde conectas, y eso lo decide pg_hba.conf.
El cliente de Docker no alcanza al demonio
Cualquier comando de Docker falla igual. El cliente y el demonio son dos cosas distintas y hablan por un socket Unix.
Docker se queda sin espacio al descargar una imagen
La descarga avanza y falla al escribir las capas. El espacio se agota en el directorio de datos de Docker, que no tiene por qué estar en la misma partición que el resto del…
La renovación del certificado falla en la validación
El certificado no se renueva y caducará sin más aviso que el correo de Let's Encrypt. La validación consiste en que la autoridad pida un fichero por HTTP y reciba exactamente lo…
Las causas de cada ficha van en el orden en que las comprobamos nosotros, que suele ser de lo más barato de descartar a lo más caro. No verás ningún porcentaje: no hemos medido con qué frecuencia ocurre cada causa, y publicar una cifra inventada sería más dañino que no dar ninguna.
Un diagnóstico sin comando de verificación obliga a probar cambios a ciegas sobre un servidor que ya está fallando. Por eso cada causa lleva dos comandos: uno que confirma si es esa, y otro que la corrige. El primero es el que importa.
A diferencia de los avisos de seguridad y del ciclo de vida, que se descargan de una API, esto lo escribimos y lo revisamos nosotros. Cada ficha afirma cómo se comporta un programa, y eso hay que comprobarlo ejecutándolo.
Algunos modifican la configuración o reinician servicios. Léelos antes de pegarlos,
y ten en cuenta que las rutas y los nombres de servicio cambian entre
distribuciones: ssh en Debian y Ubuntu es sshd en RHEL,
Rocky y AlmaLinux.
Si has llegado aquí con un servidor parado y esto no lo resuelve, cuéntanos qué tienes montado y qué has probado.
Soporte Linux y DevOps en español