«Mi servidor no responde» abarca una decena de situaciones muy distintas. El método siguiente las separa en unos minutos y evita que espere una respuesta cuando la solución estaba a un clic.
1. ¿Cómo compruebo el estado de mi VPS en el área de cliente?
Abra Mis servicios y después su VPS. La ficha indica el estado de la máquina.
- Detenida: pulse Iniciar. Una parada puede venir de un
shutdownlanzado por error, de un núcleo bloqueado o de una acción anterior. - En instalación: nada que hacer, espere a que termine.
- Suspendida o caducada: revise sus facturas en el área de cliente. Un servicio impagado queda suspendido.
2. ¿Dónde veo las últimas acciones realizadas en mi VPS?
La pestaña Historial enumera las acciones realizadas en el VPS, su autor —Sistema, Usuario o Administrador— y su fecha. Una reinstalación, un cambio de contraseña o una parada olvidada aparecen ahí con todas las letras. Muchas veces la explicación está justo ahí.
3. ¿Qué muestran los gráficos de mi VPS?
La pestaña Gráficos muestra CPU, memoria, red y entradas/salidas de disco. Tres lecturas útiles:
- todo a cero desde una hora concreta: la máquina está parada o bloqueada;
- CPU al máximo de forma continua: un proceso se ha desbocado, o alguien que no es usted está usando la máquina;
- tráfico saliente inusual: plantéese seriamente un compromiso de seguridad.
4. ¿Cómo veo con la consola lo que ocurre en la máquina?
Es el paso decisivo. La consola muestra la pantalla de la máquina sin pasar por la red.
- Ve el indicador de inicio de sesión: el sistema funciona, el problema es de red o de SSH. Pase al paso 5.
- Ve errores durante el arranque: anote la última línea antes del bloqueo, es la que importa.
- La pantalla está negra y no responde: reinicie desde la ficha del servicio y observe el arranque en la consola.
5. ¿Cómo compruebo la red y SSH desde la consola?
Bastan unos pocos comandos: la dirección y la ruta por defecto, un ping a una IP pública y luego a un nombre de dominio, el estado del servicio SSH y un posible baneo de su dirección por fail2ban.
Inicie sesión en la consola como root:
ip -4 addr # ¿está realmente la dirección?
ip route # ¿existe la ruta por defecto?
ping -c3 9.9.9.9 # ¿funciona la capa IP?
ping -c3 debian.org # ¿resuelve el DNS?Si 9.9.9.9 responde pero un nombre de dominio no, corrija la resolución DNS. Si no responde nada, compare su configuración con lo que muestra la pestaña Red del área de cliente.
Después, SSH y el cortafuegos:
systemctl status ssh # o sshd
ss -tulpn | grep :22
ufw status # o firewall-cmd --list-all
fail2ban-client status sshd # ¿está baneada su propia IP?Una dirección baneada por fail2ban tras varios errores de contraseña es una causa muy frecuente de un servidor «inaccesible» que está perfectamente. Desbanéela con fail2ban-client set sshd unbanip SU_IP.
6. ¿Cómo sé si el disco de mi VPS está lleno?
Con df -h para el espacio y df -i para los inodos: un disco saturado impide que los servicios arranquen y que se escriban los registros.
df -h
df -i
journalctl --disk-usageUn disco lleno al 100 % —o sin inodos, algo que df -h no muestra— impide que los servicios arranquen y que se escriban los registros. Libere espacio y reinicie los servicios afectados.
7. ¿Cómo detecto un servicio en fallo en mi VPS?
Con systemctl list-units --failed y después el registro del servicio afectado: la causa casi siempre aparece escrita con claridad.
systemctl list-units --failed
journalctl -p err -b --no-pager | tail -50
systemctl status NOMBRE_DEL_SERVICIOUn servicio que falla tras una actualización casi siempre está explicado con claridad en su propio registro.
¿Qué debo incluir en mi ticket de soporte?
Si abre un ticket al Service Technique, estos elementos evitan varias idas y venidas:
- el identificador del servicio afectado;
- la hora exacta de inicio del problema, con el huso horario;
- qué cambió justo antes: una actualización, un cambio de cortafuegos, de red o de SSH;
- los resultados de los comandos anteriores, pegados como texto;
- el mensaje de error exacto, no un resumen;
- lo que muestra la consola.
Nunca envíe contraseñas, claves privadas ni tokens: el soporte no los necesita y los tickets se archivan.