Cómo saber qué proceso ocupa un puerto en Linux con ss y lsof
Publicado el 2026-10-26 por frfrand
Descubrir puertos ocupados y servicios que escuchan en Ubuntu
Nginx intenta enviar solicitudes al puerto 8000 y no encuentra nada. ¿La API murió o hay otro proceso usando ese puerto? ss y lsof te permiten ver quién escucha y qué archivos o sockets mantiene abiertos.
Te muestro dónde está el problema, cómo comprobarlo sin adivinar y qué haría en una aplicación que de verdad tiene usuarios. No necesitás memorizar un manual entero para resolver un fallo concreto.
Qué significa ss y lsof en la práctica
ss consulta sockets del sistema y muestra direcciones de escucha, mientras lsof enumera descriptores de archivos asociados a procesos. Para ver el PID o ejecutable de otros usuarios suele hacer falta sudo. Un proceso escuchando en localhost no equivale a estar accesible desde Internet.
Una aclaración antes de tocar el servidor: si el proyecto ya está en producción, guardá el estado que encontraste y comprobá en qué usuario y máquina vas a ejecutar los comandos. Trabajar como root sin necesidad y cambiar varias cosas a la vez dificulta encontrar la causa de un error.
Comandos útiles para empezar
sudo ss -ltnp
sudo ss -ltnp '( sport = :8000 )'
sudo lsof -nP -iTCP:8000 -sTCP:LISTEN
curl -i http://127.0.0.1:8000/health
sudo systemctl status miappLas rutas, nombres de unidades y dominios son ejemplos. Adaptalos a tu servicio. Si un comando requiere permisos de administrador, revisá qué cambia y por qué. Las consultas de diagnóstico deberían venir antes de las modificaciones.
Paso a paso, con comprobaciones
- Compruebe si existe un socket TCP escuchando en el puerto esperado.
- Verifique si escucha en
127.0.0.1, en una IP concreta o en todas las interfaces. - Identifique PID y servicio; no mate procesos solo por reconocer su número.
- Haga una petición local y otra a través de Nginx para aislar el tramo.
- Si el puerto está ocupado, corrija la configuración del servicio y compruebe los registros.
Después de cada paso, verifique un resultado observable: un estado, un archivo, una respuesta HTTP o una entrada de registro. Si encuentra un mensaje inesperado, guárdelo para investigar en lugar de ocultarlo con reinicios repetidos.
Ejemplo real: una aplicación que hay que mantener
Tiene dos proyectos FastAPI en el mismo VPS. Ambos intentan escuchar en 8000, así que el segundo falla. Con ss encuentra el proceso y asigna puertos internos distintos con Nginx por dominio.
Al final, pruebe el camino completo: entrar por dominio, llamar a la API, escribir un dato de prueba y verificar que la información sigue ahí tras un reinicio controlado. Un servidor que «arranca» no siempre es una aplicación que funciona.
Errores que vale la pena evitar
No use kill -9 como solución inicial; puede interrumpir transacciones o tareas. Primero identifique el servicio supervisor y su configuración.
También es importante que las credenciales no terminen en el historial de la terminal, logs, archivos compartidos o capturas. Para usuarios y servicios, usa permisos mínimos y documenta quién puede revocar el acceso.
Cómo entra ArduMaker en este escenario
Un VPS de ArduMaker puede alojar varias aplicaciones detrás de Nginx. Documentar puerto interno, dominio y servicio systemd evita conflictos entre proyectos.
ArduMaker puede ayudarte a administrar los VPS, desplegar repositorios y trabajar con servicios, bases y dominios desde la misma plataforma. No reemplaza lo que acabamos de explicar sobre Linux: precisamente por eso conviene entender el diagnóstico y tener una forma de repetirlo.
Cuándo conviene automatizarlo
Si la tarea se repite, documenta primero el procedimiento manual y sus comprobaciones. Después considera un script o una tarea programada con errores visibles, logs y permisos limitados. No automatices un comando que todavía no sepas recuperar cuando sale mal.
Preguntas habituales
¿Puedo probarlo sin afectar clientes? En muchos casos sí: un VPS de staging o un servicio de prueba separado permite validar la configuración antes de cambiar producción.
¿Cómo sé si quedó bien? Mira logs y una operación funcional, no solamente que el comando terminó con código cero.
¿Cuándo necesito más recursos? Cuando las métricas indiquen saturación de CPU, RAM, disco o conexiones. Un fallo de configuración rara vez se arregla contratando más memoria.
Referencias
En una frase: primero entiende el error, después cambia una cosa concreta y comprueba su efecto. Esa disciplina te ahorra muchas horas de soporte.