# Cómo saber qué proceso está usando un puerto en Linux

**Categoría:** Linux · **Nivel:** Intermedio · **Lectura:** 18 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/linux/como-saber-que-proceso-usa-un-puerto-en-linux/

## Respuesta rápida

Para saber **qué proceso está usando un puerto** en Linux, el comando moderno es `ss`: `ss -tulpn` lista todos los puertos en escucha (*listening*) con el **proceso** que los tiene, su PID (identificador de proceso) y si son TCP o UDP. Es la forma más rápida y la recomendada hoy (sustituye al antiguo `netstat`). Hay dos alternativas útiles: `lsof -i :PUERTO` (por ejemplo `lsof -i :8080`) muestra qué proceso tiene abierto ese puerto concreto, y `fuser PUERTO/tcp` devuelve directamente el PID del proceso que lo usa. ¿Por qué necesitás esto? Por dos motivos habituales. El primero es el error **«address already in use»** (la dirección ya está en uso): intentás arrancar un servicio —un servidor web en el 80, una app en el 3000— y falla porque **otro proceso ya tiene ese puerto**. Un puerto solo puede estar «en escucha» por **un proceso a la vez**, así que hay que averiguar quién lo ocupa. El segundo es de **inventario y seguridad**: querés saber *qué* está escuchando en tu máquina y en qué puertos, para confirmar que no hay servicios de más expuestos. Una vez identificado el proceso por su **PID**, decidís: si es algo que no debería estar corriendo, lo detenés (con las [señales adecuadas](../procesos-y-senales-en-linux/index.md), mejor pidiéndole que termine ordenadamente antes de forzarlo); si es un servicio legítimo, lo reconfigurás o cambiás el puerto de *tu* aplicación. Importante distinguir esto de [qué es un puerto](../../redes/que-es-un-puerto-de-red-y-puertos-mas-usados/index.md): esa es la teoría (qué son los puertos y para qué sirven); esto es la tarea práctica de averiguar *quién* tiene uno ocupado. Todo sobre tu propio sistema o uno que administrás.

## El puerto ocupado

La situación más común que lleva a esta pregunta es un error al arrancar un servicio: **«address already in use»** o «bind: address already in use». Significa que tu aplicación intenta **quedarse a la escucha** en un puerto —esperar conexiones ahí—, pero **otro proceso ya lo tiene tomado**. La regla de fondo es simple: un puerto, para escuchar conexiones entrantes, solo puede estar en manos de **un proceso a la vez**. Dos servidores no pueden escuchar en el mismo puerto simultáneamente. Así que cuando ves ese error, la pregunta obligada es **¿quién tiene ese puerto?**, y ahí es donde entran los comandos.

> **Dos motivos para preguntar por un puerto**
>
> Averiguar qué proceso usa un puerto responde a dos necesidades distintas. La primera, **resolver un conflicto**: algo no arranca porque su puerto está ocupado, y necesitás saber por quién para decidir qué hacer —a veces es una instancia vieja de tu propia app que quedó colgada, a veces es otro servicio legítimo—. La segunda, de **inventario y seguridad**: querés ver *todo* lo que está escuchando en tu servidor, para confirmar que solo están los servicios que esperás y que no hay nada de más expuesto a la red. En ambos casos, la herramienta es la misma, pero el objetivo cambia: en el primero buscás *un* puerto concreto; en el segundo, listás *todos* los puertos en escucha.

## Los tres comandos

Las tres herramientas y cuándo usar cada una:

| Comando | Qué hace | Cuándo |
|---|---|---|
| `ss -tulpn` | Lista todos los puertos en escucha con proceso, PID y protocolo | Inventario, o ver quién tiene un puerto |
| `lsof -i :PUERTO` | Muestra el proceso que tiene abierto ese puerto concreto | Consultar un puerto específico |
| `fuser PUERTO/tcp` | Devuelve directamente el PID del proceso que lo usa | Cuando solo querés el PID rápido |

> **Atención**
>
> Durante años, el comando de referencia para esto fue `netstat`, y todavía lo verás en muchos tutoriales. Hoy, `netstat` está **obsoleto** en la mayoría de las distribuciones modernas (a veces ni viene instalado), y su sustituto oficial es `ss` (*socket statistics*), que es más rápido y da la misma información. Las opciones de `ss -tulpn` se leen así: `t` muestra TCP, `u` muestra UDP, `l` filtra los que están en escucha (*listening*), `p` muestra el proceso, y `n` muestra los números de puerto sin traducirlos a nombres. Para ver el proceso hace falta ejecutarlo con permisos de administración; sin ellos, `ss` lista los puertos pero puede no mostrar a qué proceso pertenecen los ajenos. Si buscás un puerto concreto en la lista, se combina con un filtro. Este es un caso más del arsenal de [comandos útiles de Linux](../comandos-utiles-de-linux/index.md) para administrar el sistema.

## Identificar y actuar

Una vez que tenés el **PID** (el identificador del proceso), decidís qué hacer según qué sea:

- **Identificá qué es.** El nombre del proceso que muestra `ss` o `lsof` te dice de qué se trata; si no lo reconocés, investigá antes de tocar nada.
- **Si es una instancia colgada de tu app.** Un proceso viejo que no cerró bien: detenerlo libera el puerto para volver a arrancar.
- **Si es un servicio legítimo.** Otra cosa que *debe* usar ese puerto: cambiá el puerto de *tu* aplicación en vez de matar el servicio.
- **Al detener, hacelo ordenadamente.** Pedirle al proceso que termine con una señal amable antes de forzarlo, para que cierre bien.

> **Atención**
>
> Cuando decidís detener el proceso que ocupa el puerto, **cómo** lo hacés importa. La forma correcta es enviarle primero una señal de **terminación ordenada** (la señal por defecto de `kill`), que le pide que cierre sus conexiones, guarde lo que tenga y termine limpiamente. Solo si **ignora** esa petición y se queda colgado, se recurre a la señal de **forzado** (la que no se puede ignorar), que lo mata de inmediato pero sin darle ocasión de cerrar bien —lo que puede dejar datos a medias—. Esta lógica de señales es la que se explica en [procesos y señales en Linux](../procesos-y-senales-en-linux/index.md). Y una advertencia clave: si el proceso que ocupa el puerto es un **servicio gestionado** por el sistema (por systemd, por ejemplo), lo correcto no es «matarlo» por su PID —el gestor podría volver a levantarlo—, sino **detenerlo por su servicio**. Todo esto, siempre sobre tu propio sistema o uno que administrás legítimamente.

## Errores frecuentes

- **Usar netstat en sistemas modernos.** Está obsoleto y a veces ni está instalado; usar `ss`.
- **No ejecutar con permisos de administración.** Sin ellos no se ve a qué proceso pertenecen algunos puertos.
- **Matar un servicio legítimo para liberar el puerto.** Mejor cambiar el puerto de tu propia app.
- **Forzar el proceso de entrada.** Pedirle primero que termine ordenadamente; forzar puede dejar datos a medias.
- **Matar por PID un servicio gestionado por systemd.** El gestor lo relanza; hay que detenerlo por su servicio.
- **Confundir "en escucha" con "conectado".** Un puerto en escucha espera conexiones; una conexión establecida es otra cosa.
- **Actuar sobre un sistema ajeno.** Solo sobre el propio o uno que se administra legítimamente.

## Preguntas frecuentes

**¿Cómo sé qué proceso está usando un puerto en Linux?**
Para saber qué proceso está usando un puerto en Linux existen tres comandos principales, siendo el más recomendado hoy en día el comando de estadísticas de sockets. Este comando, ejecutado con un conjunto de opciones habitual, lista todos los puertos que están en escucha en el sistema, mostrando para cada uno el proceso que lo tiene, su identificador de proceso y si corresponde al protocolo TCP o UDP, y constituye la forma más rápida y moderna de obtener esta información, ya que ha sustituido al antiguo comando de estadísticas de red que hoy está obsoleto. Las opciones que se suelen combinar indican, respectivamente, que se muestren los sockets de tipo TCP, los de tipo UDP, solo los que están en escucha, el proceso asociado y los números de puerto sin traducir a nombres. Para que muestre el proceso asociado a los puertos, conviene ejecutarlo con permisos de administración, ya que sin ellos puede listar los puertos pero no revelar a qué proceso pertenecen los que no son propios. El segundo comando es el que lista los archivos y sockets abiertos, que permite consultar un puerto concreto indicándoselo, y devuelve qué proceso tiene abierto ese puerto, siendo útil cuando se quiere investigar un puerto específico en lugar de listar todos. El tercer comando es el que identifica los procesos que usan un archivo o socket, que indicándole un puerto y su protocolo devuelve directamente el identificador del proceso que lo está usando, resultando práctico cuando solo se necesita ese identificador de forma rápida. Estos comandos responden a dos necesidades habituales. La primera es resolver el error que indica que la dirección ya está en uso, que aparece cuando se intenta arrancar un servicio en un puerto que otro proceso ya ocupa, ya que un puerto solo puede estar en escucha por un proceso a la vez. La segunda es de inventario y seguridad, para saber qué servicios están escuchando en la máquina y en qué puertos, comprobando que no haya servicios expuestos de más. Una vez identificado el proceso por su identificador, se puede decidir detenerlo si no debería estar corriendo, o reconfigurar la propia aplicación si el puerto lo ocupa un servicio legítimo. Todo ello debe hacerse siempre sobre el propio sistema o sobre uno que se administra legítimamente.

**¿Por qué aparece el error "address already in use"?**
El error que indica que la dirección ya está en uso, a menudo mostrado como un fallo al enlazar con el mensaje de que la dirección ya está en uso, aparece cuando un programa intenta ponerse a la escucha en un puerto que otro proceso ya tiene ocupado, y se debe a la regla fundamental de que un puerto solo puede estar en escucha por un único proceso a la vez. Cuando una aplicación de red, como un servidor web o el servidor de desarrollo de una aplicación, quiere recibir conexiones entrantes, necesita reservar un puerto y quedarse a la escucha en él, esperando que lleguen conexiones. Este acto de reservar el puerto y ponerse a escuchar es exclusivo, de manera que si otro proceso ya ha reservado ese mismo puerto y está escuchando en él, el segundo proceso no puede hacer lo mismo y el sistema le devuelve el error de que la dirección ya está en uso. Es análogo a intentar sentarse en una silla que ya está ocupada: solo cabe una persona a la vez. Las causas más habituales de este error son varias. Una muy frecuente es que exista una instancia anterior de la propia aplicación que no se cerró correctamente y que sigue ocupando el puerto, por ejemplo un servidor que se quedó colgado o que no se detuvo del todo antes de intentar arrancarlo de nuevo. Otra causa es que otro servicio distinto, legítimo, esté usando ese puerto, por ejemplo si se intenta arrancar un servidor web en un puerto que ya está ocupado por otro servidor web instalado en el sistema. También puede ocurrir que se intente usar un puerto reservado para un servicio del sistema. Ante este error, el procedimiento correcto es averiguar qué proceso está ocupando el puerto, utilizando los comandos apropiados para ello, e identificarlo. Una vez identificado, si se trata de una instancia colgada de la propia aplicación, basta con detenerla para liberar el puerto y poder arrancar de nuevo. Si se trata de un servicio legítimo que debe seguir funcionando, la solución adecuada no es detener ese servicio, sino cambiar el puerto en el que se quiere arrancar la propia aplicación, eligiendo uno libre. Comprender que este error refleja simplemente un conflicto por un puerto ocupado, y no un fallo grave, facilita mucho su resolución.

**¿Qué diferencia hay entre ss, lsof y netstat?**
Los comandos de estadísticas de sockets, de listado de archivos abiertos y de estadísticas de red son tres herramientas que permiten averiguar qué procesos usan qué puertos, pero se diferencian en su enfoque, su vigencia y su ámbito de uso. El comando de estadísticas de red fue durante muchos años la herramienta clásica y más conocida para ver las conexiones de red y los puertos en escucha, y aún aparece en numerosos tutoriales y documentación antigua. Sin embargo, en las distribuciones modernas de Linux se considera obsoleto, hasta el punto de que en muchas de ellas ya no viene instalado de forma predeterminada, y ha sido reemplazado oficialmente por el comando de estadísticas de sockets. Este último, el comando de estadísticas de sockets, es el sucesor moderno y recomendado, que ofrece la misma información que su predecesor pero de forma más rápida y eficiente, y es la herramienta que conviene usar hoy en día para listar los puertos en escucha junto con los procesos que los ocupan. Es especialmente adecuado para obtener un inventario completo de todo lo que está escuchando en el sistema. El comando de listado de archivos abiertos tiene un enfoque más amplio y general, ya que su función principal es listar todos los archivos que los procesos tienen abiertos, y dado que en los sistemas de tipo Unix los sockets de red se tratan también como una forma de archivo, este comando puede mostrar igualmente qué procesos tienen abiertos qué puertos de red. Su ventaja es su versatilidad y la comodidad para consultar un puerto concreto, ya que permite preguntar directamente qué proceso tiene abierto un puerto específico. En resumen, la recomendación práctica es la siguiente: el comando de estadísticas de sockets es la opción moderna y preferida, tanto para listar todos los puertos en escucha como para investigar uno concreto; el comando de listado de archivos abiertos es una excelente alternativa, muy cómoda para consultar puertos específicos y con un enfoque más general sobre los recursos abiertos; y el comando de estadísticas de red, aunque muchas personas lo siguen usando por costumbre, es preferible evitarlo en sistemas modernos por estar obsoleto, y en su lugar utilizar el comando de estadísticas de sockets, que cumple la misma función de forma actualizada.

**¿Cómo detengo el proceso que ocupa un puerto?**
Para detener el proceso que ocupa un puerto en Linux, primero hay que identificarlo obteniendo su identificador de proceso con los comandos adecuados, y luego detenerlo de la forma correcta según de qué tipo de proceso se trate, teniendo cuidado de hacerlo de manera ordenada y de no detener servicios que deban seguir funcionando. El primer paso es identificar el proceso, averiguando su identificador y, muy importante, comprendiendo qué es ese proceso, ya que el nombre que muestran los comandos de diagnóstico indica de qué programa se trata; si no se reconoce, conviene investigar antes de detenerlo, para no interrumpir algo importante. Una vez identificado, la forma de detenerlo depende de su naturaleza. Si se trata de una instancia colgada o abandonada de la propia aplicación, que quedó ocupando el puerto tras no cerrarse correctamente, se puede detener para liberar el puerto. Si se trata de un servicio legítimo que debe seguir en funcionamiento, la recomendación no es detenerlo, sino cambiar el puerto que se pretende usar para la propia aplicación. En cuanto a la manera de detener un proceso, es importante hacerlo de forma ordenada. Lo correcto es enviarle primero una señal de terminación ordenada, que es la señal predeterminada del comando de terminación de procesos, la cual le pide al proceso que cierre sus conexiones, guarde lo que necesite y termine de forma limpia. Solo si el proceso ignora esa petición y permanece colgado, se recurre a una señal de terminación forzada, que no puede ser ignorada y que detiene el proceso de inmediato, aunque con el riesgo de que no cierre correctamente y deje datos a medio escribir. Existe además una consideración crucial: si el proceso que ocupa el puerto es un servicio gestionado por el sistema de gestión de servicios, como el que administra los servicios en las distribuciones modernas, no se debe detener directamente por su identificador de proceso, porque el gestor de servicios probablemente lo volvería a levantar de inmediato; en su lugar, hay que detenerlo a través del propio gestor de servicios, usando el comando correspondiente para detener ese servicio concreto. Todo este procedimiento debe realizarse siempre sobre el propio sistema o sobre uno que se administra legítimamente y con autorización.

**¿En qué se diferencia esto de saber qué es un puerto?**
Saber qué proceso usa un puerto y saber qué es un puerto son dos cuestiones relacionadas pero distintas, ya que la primera es una tarea práctica de administración y diagnóstico, mientras que la segunda es un concepto teórico de fundamentos de redes, y ambas se complementan. Saber qué es un puerto corresponde a los fundamentos de las redes de comunicaciones, y consiste en entender el concepto: un puerto es un número que identifica un punto de comunicación concreto dentro de una máquina, de modo que un mismo equipo, con una sola dirección de red, puede ofrecer o usar múltiples servicios simultáneamente, cada uno asociado a un puerto distinto. Este concepto abarca cómo funcionan los puertos, la diferencia entre los puertos bien conocidos reservados para servicios estándar y los puertos de rango alto, la distinción entre los protocolos de transporte, y para qué sirven los puertos más habituales. Es conocimiento conceptual que explica el porqué y el cómo del sistema de puertos. En cambio, saber qué proceso usa un puerto es una tarea eminentemente práctica de administración de sistemas, que da por supuesto el concepto de puerto y se centra en resolver una necesidad concreta del día a día: averiguar qué programa específico está ocupando o escuchando en un puerto determinado de la máquina, normalmente para resolver un conflicto, como el error de que la dirección ya está en uso, o para hacer un inventario de los servicios que están escuchando. Esta tarea se realiza con comandos concretos que consultan el estado del sistema en tiempo real y devuelven el proceso responsable. La relación entre ambas es de complementariedad y de niveles: para poder realizar y entender bien la tarea práctica de averiguar qué proceso usa un puerto, conviene tener claro el concepto de qué es un puerto, ya que sin ese fundamento las herramientas y sus resultados resultan confusos. Por eso, quien no domine el concepto de puerto haría bien en repasarlo antes o en paralelo, mientras que quien ya lo tiene claro puede centrarse directamente en la tarea práctica. En definitiva, una es la teoría que explica el sistema de puertos y la otra es la habilidad práctica de investigar y gestionar qué ocurre con un puerto concreto en un sistema real.

**¿Necesito permisos de administrador para ver los puertos?**
Para ver los puertos que están en escucha en un sistema Linux no siempre se necesitan permisos de administrador, pero para ver a qué proceso pertenece cada puerto, especialmente los que no son propios del usuario que ejecuta el comando, sí suele ser necesario ejecutar los comandos con privilegios de administración. La razón de esta distinción tiene que ver con la seguridad y con la privacidad de la información del sistema. La información básica sobre qué puertos están en escucha suele ser accesible para los usuarios normales, de modo que un usuario sin privilegios especiales puede, en muchos casos, obtener una lista de los puertos que están abiertos y escuchando en el sistema. Sin embargo, la información sobre qué proceso concreto está detrás de cada puerto es más sensible, ya que revela detalles sobre los programas que otros usuarios o el propio sistema están ejecutando. Por ello, cuando un usuario normal ejecuta los comandos de diagnóstico de puertos, puede que vea los puertos en escucha pero que no se le muestre el proceso asociado a aquellos que pertenecen a otros usuarios o a servicios del sistema, apareciendo esa información en blanco o restringida. Para obtener la información completa, incluyendo el proceso e identificador de proceso asociado a cada puerto, con independencia de a quién pertenezca, es necesario ejecutar los comandos con permisos de administración, ya sea directamente como el usuario administrador o utilizando el mecanismo que permite elevar los privilegios para un comando concreto. Por tanto, la recomendación práctica es que, cuando se está diagnosticando un problema de puertos y se necesita saber exactamente qué proceso ocupa cada uno, se ejecuten los comandos correspondientes con privilegios de administración, para asegurarse de obtener la información completa. En el caso de estar investigando únicamente los puertos y procesos del propio usuario, es posible que no haga falta elevar privilegios, pero en las tareas habituales de administración del sistema, que suelen implicar servicios del sistema y procesos de distintos usuarios, contar con permisos de administración es lo habitual y lo necesario para obtener una visión completa. Como siempre, esto debe hacerse sobre el propio sistema o sobre uno que se administra de forma legítima.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [GNU/Linux](https://underc0de.org/foro/gnu-linux/). Administración de servicios y red.
2. **Underc0de, foro.** [Redes y servidores](https://underc0de.org/foro/redes-y-servidores/). Diagnóstico de puertos.

### Documentación oficial

1. **man7.org.** [ss(8)](https://man7.org/linux/man-pages/man8/ss.8.html). Estadísticas de sockets.
2. **man7.org.** [lsof(8)](https://man7.org/linux/man-pages/man8/lsof.8.html). Archivos y sockets abiertos.
3. **man7.org.** [fuser(1)](https://man7.org/linux/man-pages/man1/fuser.1.html). Procesos que usan archivos o sockets.
4. **The Linux Documentation Project.** [TLDP](https://tldp.org/). Administración de red en Linux.

## Guías relacionadas

- [Procesos y señales](../procesos-y-senales-en-linux/index.md)
- [Qué es un puerto de red](../../redes/que-es-un-puerto-de-red-y-puertos-mas-usados/index.md)
- [Comandos útiles de Linux](../comandos-utiles-de-linux/index.md)
- [Administración de servidores](../administracion-de-servidores-linux-desde-cero/index.md)
- [Índice de Linux](../index.md)