{"id":10336,"date":"2026-11-11T10:11:10","date_gmt":"2026-11-11T09:11:10","guid":{"rendered":"https:\/\/www.hostingtg.com\/blog\/?p=10336"},"modified":"2026-11-11T10:13:26","modified_gmt":"2026-11-11T09:13:26","slug":"como-saber-proceso-usa-puerto-linux","status":"publish","type":"post","link":"https:\/\/www.hostingtg.com\/blog\/como-saber-proceso-usa-puerto-linux\/","title":{"rendered":"C\u00f3mo saber qu\u00e9 proceso usa un puerto en Linux (ss, lsof y netstat)"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Hay pocas cosas m\u00e1s molestas cuando est\u00e1s <a href=\"https:\/\/www.hostingtg.com\/blog\/administrar-un-servidor-vps\/\">administrando un servidor Linux<\/a> que intentar arrancar un servicio y encontrarte con un error indicando que el puerto ya est\u00e1 ocupado. Lo primero que piensas es que probablemente existe otra instancia del mismo servicio funcionando, pero no siempre es as\u00ed.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En ocasiones descubres que el puerto est\u00e1 siendo utilizado por una aplicaci\u00f3n que ni siquiera recordabas haber instalado. Otras veces, el proceso pertenece a un servicio importante y detenerlo sin comprobar qu\u00e9 est\u00e1 haciendo puede provocar un problema bastante mayor.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s de a\u00f1os trabajando con servidores Linux en <strong><a href=\"https:\/\/www.hostingtg.com\/servidores-vps\/\">HostingTG<\/a><\/strong>, me he encontrado con esta situaci\u00f3n al configurar <a href=\"https:\/\/www.hostingtg.com\/blog\/como-instalar-apache-en-ubuntu-paso-a-paso\/\">Apache<\/a>, <a href=\"https:\/\/www.hostingtg.com\/blog\/instalar-nginx-en-ubuntu\/\">Nginx<\/a>, aplicaciones web y servicios que necesitan escuchar en puertos determinados.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por suerte, <strong>saber qu\u00e9 proceso utiliza un puerto en Linux es bastante sencillo<\/strong> si conocemos las herramientas adecuadas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Los tres comandos que m\u00e1s utilizo para estas comprobaciones son <code>ss<\/code>, <code>lsof<\/code> y <code>netstat<\/code>. Cada uno tiene sus ventajas, aunque personalmente suelo empezar por <code>ss<\/code> y recurrir a los dem\u00e1s cuando necesito informaci\u00f3n adicional.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En esta gu\u00eda voy a explicar c\u00f3mo identificar qu\u00e9 aplicaci\u00f3n est\u00e1 utilizando un puerto, obtener su PID, interpretar las conexiones y resolver posibles conflictos sin detener servicios innecesariamente.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">C\u00f3mo identificar r\u00e1pidamente qu\u00e9 proceso ocupa un puerto en Linux<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Si necesitas saber qu\u00e9 proceso est\u00e1 utilizando un puerto concreto, mi recomendaci\u00f3n es empezar directamente con <code>ss<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, para comprobar qu\u00e9 servicio est\u00e1 escuchando en el puerto 80:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -ltnp 'sport = :80'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Este comando muestra las conexiones TCP en estado de escucha que utilizan el puerto local 80 y, cuando se dispone de los permisos necesarios, el proceso asociado.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n puedes utilizar <code>lsof<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo lsof -nP -iTCP:80 -sTCP:LISTEN<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">O <code>netstat<\/code>, si est\u00e1 instalado:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo netstat -tulnp<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">En este \u00faltimo caso obtendr\u00e1s una lista de puertos y procesos que tendr\u00e1s que revisar para localizar el que te interesa.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Los tres m\u00e9todos pueden ayudarte a identificar qu\u00e9 servicio est\u00e1 ocupando un puerto, aunque no presentan la informaci\u00f3n exactamente de la misma manera.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comandos r\u00e1pidos para los puertos 80, 443 y 8080<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Estos son algunos de los comandos que conviene tener a mano:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th>Puerto<\/th><th>Comando<\/th><\/tr><tr><td>80 (HTTP)<\/td><td><code>sudo ss -ltnp 'sport = :80'<\/code><\/td><\/tr><tr><td>443 (HTTPS)<\/td><td><code>sudo ss -ltnp 'sport = :443'<\/code><\/td><\/tr><tr><td>8080 (aplicaciones web)<\/td><td><code>sudo ss -ltnp 'sport = :8080'<\/code><\/td><\/tr><tr><td>3306 (MySQL)<\/td><td><code>sudo ss -ltnp 'sport = :3306'<\/code><\/td><\/tr><tr><td>Todos los puertos TCP y UDP en escucha<\/td><td><code>sudo ss -tulnp<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Estos comandos permiten realizar una primera comprobaci\u00f3n sin modificar la configuraci\u00f3n del servidor ni detener ning\u00fan proceso.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Y este \u00faltimo detalle es importante.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando aparece un conflicto de puertos, considero que lo primero debe ser investigar qu\u00e9 est\u00e1 ocurriendo, no intentar liberar el puerto a cualquier precio.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En un servidor de producci\u00f3n puede haber aplicaciones atendiendo peticiones reales. Terminar un proceso \u00fanicamente porque aparece asociado al puerto que necesitamos puede provocar interrupciones evitables.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Usar ss para saber qu\u00e9 proceso est\u00e1 escuchando en un puerto<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><code>ss<\/code> es actualmente una de las herramientas m\u00e1s pr\u00e1cticas para consultar sockets y conexiones de red en Linux.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Forma parte del paquete <code>iproute2<\/code> y est\u00e1 disponible en numerosas distribuciones modernas, como Ubuntu, Debian, AlmaLinux o Rocky Linux.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Su nombre procede de <em>Socket Statistics<\/em> y permite obtener informaci\u00f3n sobre conexiones TCP, UDP y otros tipos de sockets.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Aunque durante a\u00f1os utilic\u00e9 <code>netstat<\/code> para este tipo de tareas, actualmente suelo recurrir a <code>ss<\/code> porque ofrece una sintaxis adecuada para filtrar puertos, estados y conexiones.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Consultar un puerto concreto con ss<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Imaginemos que intentamos iniciar Apache y aparece un mensaje indicando que la direcci\u00f3n ya est\u00e1 en uso.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Como Apache suele escuchar en el puerto 80 para conexiones HTTP, podemos comprobarlo mediante:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -ltnp 'sport = :80'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Una salida posible ser\u00eda:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process\nLISTEN 0      511    0.0.0.0:80         0.0.0.0:*         users:((\"nginx\",pid=1250,fd=6))<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Este ejemplo indica que existe un proceso llamado <code>nginx<\/code>, con PID <code>1250<\/code>, escuchando en el puerto TCP 80.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Es decir, si estamos intentando iniciar otro servidor web que necesita utilizar la misma direcci\u00f3n y el mismo puerto, ya tenemos una pista bastante clara sobre el origen del conflicto.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No obstante, conviene recordar que la incompatibilidad depende de la combinaci\u00f3n de direcci\u00f3n IP, puerto, protocolo y opciones de los sockets. No cualquier uso de un mismo n\u00famero de puerto implica necesariamente un conflicto.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si necesitamos consultar otro puerto, simplemente modificamos el n\u00famero.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, para el puerto 443:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -ltnp 'sport = :443'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Y para el 8080:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -ltnp 'sport = :8080'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Este \u00faltimo es bastante habitual en aplicaciones desarrolladas con Java, <a href=\"https:\/\/www.hostingtg.com\/blog\/aprende-nodejs-como-funciona\/\">Node.js<\/a> y otros entornos web.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Listar todos los puertos TCP y UDP en escucha<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando estoy revisando un servidor nuevo o investigando alg\u00fan comportamiento inesperado, prefiero obtener una visi\u00f3n general de los puertos que est\u00e1n escuchando.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para ello utilizo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -tulnp<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Las opciones significan lo siguiente:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th>Opci\u00f3n<\/th><th>Significado<\/th><\/tr><tr><td><code>-t<\/code><\/td><td>Mostrar sockets TCP<\/td><\/tr><tr><td><code>-u<\/code><\/td><td>Mostrar sockets UDP<\/td><\/tr><tr><td><code>-l<\/code><\/td><td>Mostrar sockets en escucha o receptores de datagramas UDP<\/td><\/tr><tr><td><code>-n<\/code><\/td><td>Mostrar direcciones y puertos num\u00e9ricamente<\/td><\/tr><tr><td><code>-p<\/code><\/td><td>Mostrar informaci\u00f3n del proceso asociado, cuando est\u00e9 disponible<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Una salida de ejemplo podr\u00eda mostrar servicios como <a href=\"https:\/\/www.hostingtg.com\/blog\/ssh-que-es\/\">SSH<\/a>, Nginx y <a href=\"https:\/\/www.hostingtg.com\/blog\/como-instalar-mysql-en-ubuntu\/\">MySQL<\/a> escuchando en diferentes direcciones.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En HostingTG trabajamos con servidores que alojan m\u00faltiples p\u00e1ginas web y aplicaciones. Cuando revisamos un sistema, no nos interesa \u00fanicamente comprobar que los servicios funcionan. Tambi\u00e9n es importante saber <strong>en qu\u00e9 interfaces de red est\u00e1n escuchando<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, si una base de datos MySQL que deber\u00eda aceptar \u00fanicamente conexiones locales aparece vinculada a:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>0.0.0.0:3306<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Conviene investigar su configuraci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Esa direcci\u00f3n indica que el servicio est\u00e1 escuchando en todas las interfaces IPv4 disponibles, aunque no significa autom\u00e1ticamente que pueda accederse a \u00e9l desde Internet.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n intervienen el firewall, las rutas de red y otros controles de acceso.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En cualquier caso, considero que saber qu\u00e9 servicios est\u00e1n escuchando y d\u00f3nde lo hacen es una comprobaci\u00f3n b\u00e1sica de <a href=\"https:\/\/www.hostingtg.com\/blog\/como-asegurar-un-vps-ubuntu\/\">administraci\u00f3n y seguridad<\/a>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">C\u00f3mo interpretar la salida de ss y obtener el PID<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Al principio, la informaci\u00f3n de <code>ss<\/code> puede parecer algo confusa. Sin embargo, las columnas principales son bastante f\u00e1ciles de interpretar.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Supongamos que ejecutamos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -ltnp 'sport = :8080'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Y obtenemos una l\u00ednea similar a esta:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>LISTEN 0 128 127.0.0.1:8080 0.0.0.0:* users:((\"node\",pid=2481,fd=18))<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Podemos identificar varios elementos:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>LISTEN:<\/strong> el socket TCP est\u00e1 esperando conexiones.<\/li>\n\n\n\n<li><strong>127.0.0.1:8080:<\/strong> el servicio escucha en la interfaz local y utiliza el puerto 8080.<\/li>\n\n\n\n<li><strong>node:<\/strong> nombre del proceso asociado.<\/li>\n\n\n\n<li><strong>pid=2481:<\/strong> identificador del proceso en el sistema.<\/li>\n\n\n\n<li><strong>fd=18:<\/strong> descriptor de archivo mediante el que el proceso mantiene abierto el socket.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">El PID es especialmente \u00fatil porque permite investigar el proceso utilizando otras herramientas de Linux.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps -fp 2481<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Con este comando podemos consultar informaci\u00f3n sobre el proceso identificado.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si necesitamos conocer la l\u00ednea de comandos completa, podemos utilizar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps -ww -p 2481 -o pid,ppid,user,args<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Aqu\u00ed veremos el identificador del proceso, su proceso padre, el usuario propietario y los argumentos de ejecuci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Este paso puede ayudarnos a distinguir entre una aplicaci\u00f3n leg\u00edtima, una instancia duplicada o un servicio que no esper\u00e1bamos encontrar funcionando.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Identificar el proceso que utiliza un puerto con lsof<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Aunque <code>ss<\/code> suele ser mi primera opci\u00f3n, hay situaciones en las que prefiero utilizar <code>lsof<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Su nombre procede de <em>List Open Files<\/em> y permite consultar los archivos abiertos por los procesos del sistema.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En Linux, los sockets de red tambi\u00e9n pueden aparecer entre los recursos abiertos por los procesos. Gracias a ello, <code>lsof<\/code> resulta especialmente \u00fatil para relacionar puertos con aplicaciones, PID y usuarios.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Personalmente lo encuentro muy pr\u00e1ctico cuando necesito investigar qu\u00e9 aplicaci\u00f3n est\u00e1 detr\u00e1s de una conexi\u00f3n y obtener la informaci\u00f3n organizada por proceso.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Buscar un proceso por su puerto TCP o UDP<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Para saber qu\u00e9 proceso est\u00e1 escuchando en el puerto TCP 443, podemos ejecutar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo lsof -nP -iTCP:443 -sTCP:LISTEN<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Las opciones utilizadas tienen estas funciones:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>-n<\/code>: evita resolver direcciones IP mediante DNS.<\/li>\n\n\n\n<li><code>-P<\/code>: evita convertir n\u00fameros de puerto en nombres de servicio.<\/li>\n\n\n\n<li><code>-iTCP:443<\/code>: selecciona sockets TCP relacionados con el puerto 443.<\/li>\n\n\n\n<li><code>-sTCP:LISTEN<\/code>: limita los resultados a sockets TCP en escucha.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">La combinaci\u00f3n de estas opciones permite obtener una salida bastante directa.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>COMMAND PID  USER FD TYPE DEVICE SIZE\/OFF NODE NAME\nnginx   1250 root 6u IPv4 123456 0t0     TCP *:443 (LISTEN)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">En este caso, podemos identificar que el proceso se llama <code>nginx<\/code>, tiene el PID <code>1250<\/code> y est\u00e1 ejecut\u00e1ndose bajo el usuario <code>root<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si lo que necesitamos es comprobar el puerto 8080, podemos utilizar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo lsof -nP -iTCP:8080 -sTCP:LISTEN<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n podemos consultar sockets UDP asociados a un puerto determinado:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo lsof -nP -iUDP:53<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Este \u00faltimo ejemplo permite investigar qu\u00e9 procesos tienen abiertos sockets UDP en el puerto 53, utilizado habitualmente por DNS.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Hay que tener en cuenta que UDP no utiliza el estado <code>LISTEN<\/code> de la misma manera que TCP, por lo que no debemos aplicar indiscriminadamente los mismos filtros de estado a ambos protocolos.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Consultar el PID, el usuario y el comando del proceso<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Una de las ventajas de <code>lsof<\/code> es que muestra directamente columnas que resultan \u00fatiles para investigar procesos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Las m\u00e1s importantes suelen ser:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th>Columna<\/th><th>Informaci\u00f3n<\/th><\/tr><tr><td>COMMAND<\/td><td>Nombre del proceso<\/td><\/tr><tr><td>PID<\/td><td>Identificador del proceso<\/td><\/tr><tr><td>USER<\/td><td>Usuario propietario<\/td><\/tr><tr><td>FD<\/td><td>Descriptor de archivo<\/td><\/tr><tr><td>TYPE<\/td><td>Tipo de socket o archivo<\/td><\/tr><tr><td>NAME<\/td><td>Direcci\u00f3n, puerto y estado cuando corresponda<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">En servidores de alojamiento compartido esta informaci\u00f3n tiene especial importancia.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En HostingTG trabajamos con entornos donde pueden ejecutarse numerosas aplicaciones y procesos bajo usuarios diferentes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si descubro que un puerto est\u00e1 ocupado, no me basta con saber que existe un proceso llamado <code>python<\/code>, <code>node<\/code> o <code>php<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n quiero identificar qui\u00e9n lo est\u00e1 ejecutando, a qu\u00e9 aplicaci\u00f3n pertenece y c\u00f3mo se ha iniciado.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, si encontramos un proceso Node.js escuchando en el puerto 8080, podemos utilizar su PID para investigar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps -ww -p 2481 -o pid,ppid,user,args<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">En ocasiones, los argumentos revelan directamente el archivo de la aplicaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En otras, necesitaremos revisar la configuraci\u00f3n de systemd, el directorio de trabajo del proceso o los <a href=\"https:\/\/www.hostingtg.com\/blog\/comando-tail\/\">registros del servicio<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Lo importante es no sacar conclusiones \u00fanicamente por el nombre del ejecutable.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Un proceso puede estar realizando una funci\u00f3n perfectamente leg\u00edtima aunque no lo reconozcamos a primera vista.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">De hecho, he visto situaciones en las que alguien intenta resolver r\u00e1pidamente un conflicto de puertos deteniendo el primer proceso que aparece en pantalla.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En producci\u00f3n, prefiero dedicar un poco m\u00e1s de tiempo a investigar antes que provocar una interrupci\u00f3n innecesaria.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Comprobar qu\u00e9 proceso usa un puerto con netstat<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Durante muchos a\u00f1os, <a href=\"https:\/\/www.hostingtg.com\/blog\/netstat\/\"><code>netstat<\/code><\/a> fue una de las herramientas habituales para consultar conexiones y <a href=\"https:\/\/www.hostingtg.com\/blog\/comprobar-puertos-abiertos\/\">puertos abiertos<\/a> en servidores Linux.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Todav\u00eda recuerdo utilizarlo de forma casi autom\u00e1tica cuando necesitaba investigar qu\u00e9 servicio estaba escuchando en una direcci\u00f3n determinada.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Actualmente pertenece al paquete <code>net-tools<\/code>, un conjunto de utilidades tradicionales que ha sido sustituido en muchas tareas modernas por herramientas como <code>ss<\/code> e <code>ip<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Esto no significa que <code>netstat<\/code> haya dejado de funcionar.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En sistemas heredados puede seguir siendo perfectamente \u00fatil, siempre que est\u00e9 instalado.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">C\u00f3mo utilizar netstat -tulnp<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Uno de los comandos m\u00e1s conocidos es:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo netstat -tulnp<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Este comando muestra sockets TCP y UDP en escucha, con direcciones num\u00e9ricas y la informaci\u00f3n del programa o PID cuando est\u00e1 disponible.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Una salida de ejemplo podr\u00eda ser:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Proto Recv-Q Send-Q Local Address Foreign Address State PID\/Program name\ntcp   0      0      0.0.0.0:80    0.0.0.0:*       LISTEN 1250\/nginx\ntcp   0      0      127.0.0.1:3306 0.0.0.0:*      LISTEN 1432\/mysqld<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Para localizar un puerto concreto podemos filtrar la salida:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo netstat -tulnp | grep ':8080'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Este m\u00e9todo es habitual y puede resultar suficiente para una comprobaci\u00f3n r\u00e1pida.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sin embargo, cuando tenemos disponible <code>ss<\/code>, prefiero utilizar sus filtros nativos para seleccionar un puerto espec\u00edfico. As\u00ed evitamos depender de una b\u00fasqueda textual sobre toda la salida.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n conviene recordar que, si un proceso pertenece a otro usuario, es posible que necesitemos ejecutar <code>netstat<\/code> mediante <code>sudo<\/code> para obtener determinada informaci\u00f3n sobre su PID.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Qu\u00e9 hacer si netstat no est\u00e1 instalado<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">En muchas instalaciones actuales de Linux, <code>netstat<\/code> no viene incluido por defecto.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si intentamos ejecutarlo, podemos encontrarnos con un mensaje similar a:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>netstat: command not found<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Esto no significa que exista un problema con las conexiones de red.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Simplemente indica que la utilidad no est\u00e1 disponible en el entorno desde el que la estamos ejecutando.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En sistemas <a href=\"https:\/\/www.hostingtg.com\/blog\/ubuntu-server-vs-debian-para-tu-vps\/\">Debian o Ubuntu<\/a>, normalmente podemos instalar el paquete correspondiente mediante:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo apt update\nsudo apt install net-tools<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">En distribuciones basadas en RHEL, si el paquete est\u00e1 disponible en los repositorios configurados, podemos utilizar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo dnf install net-tools<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ahora bien, si estamos configurando un servidor Linux moderno desde cero, personalmente no instalar\u00eda <code>net-tools<\/code> \u00fanicamente para consultar un puerto.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En la mayor\u00eda de los casos, <code>ss<\/code> permite obtener la informaci\u00f3n que necesitamos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Creo que uno de los errores habituales en administraci\u00f3n de sistemas es continuar utilizando determinadas herramientas exclusivamente porque llevamos muchos a\u00f1os trabajando con ellas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La experiencia es importante, pero tambi\u00e9n lo es actualizar nuestra manera de trabajar.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Diferencias entre ss, lsof y netstat: \u00bfcu\u00e1l utilizar?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Aunque las tres herramientas pueden ayudarnos a identificar procesos asociados a puertos, no est\u00e1n dise\u00f1adas exactamente para lo mismo.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th>Herramienta<\/th><th>Principal ventaja<\/th><th>Cu\u00e1ndo la utilizo<\/th><\/tr><tr><td><code>ss<\/code><\/td><td>Consulta eficiente de sockets y filtros de red<\/td><td>Primera comprobaci\u00f3n de puertos y conexiones<\/td><\/tr><tr><td><code>lsof<\/code><\/td><td>Relaciona sockets con procesos, usuarios y archivos abiertos<\/td><td>Investigaci\u00f3n detallada del proceso<\/td><\/tr><tr><td><code>netstat<\/code><\/td><td>Sintaxis tradicional conocida y compatibilidad con sistemas heredados<\/td><td>Administraci\u00f3n de servidores antiguos<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Si alguien me pregunta cu\u00e1l deber\u00eda aprender primero, mi respuesta es clara: <strong>empezar\u00eda por<\/strong> <code><strong>ss<\/strong><\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Es una herramienta adecuada para la administraci\u00f3n habitual de servidores Linux y permite consultar de forma r\u00e1pida tanto puertos en escucha como conexiones establecidas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando necesito conocer m\u00e1s detalles sobre qu\u00e9 aplicaci\u00f3n mantiene abierto un socket, recurro a <code>lsof<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Y si estoy trabajando sobre un sistema antiguo que ya dispone de <code>netstat<\/code>, no tengo ning\u00fan problema en utilizarlo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En la pr\u00e1ctica, las tres herramientas no son excluyentes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Podemos empezar con <code>ss<\/code>, identificar un PID y despu\u00e9s usar <code>lsof<\/code> o <code>ps<\/code> para investigar el proceso.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -ltnp 'sport = :443'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s, si encontramos el PID <code>1250<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps -ww -p 1250 -o pid,ppid,user,args<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Y si queremos comprobar qu\u00e9 sockets de red tiene abiertos ese proceso:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo lsof -nP -a -p 1250 -i<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Este \u00faltimo comando permite filtrar los resultados por el PID indicado y por recursos de red.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Combinar herramientas suele proporcionar una imagen m\u00e1s completa que depender de un \u00fanico comando.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Qu\u00e9 hacer cuando un puerto ya est\u00e1 ocupado en Linux<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Identificar qu\u00e9 proceso utiliza un puerto es relativamente sencillo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La parte que requiere algo m\u00e1s de criterio es decidir qu\u00e9 hacer despu\u00e9s.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando aparece un error indicando que un puerto est\u00e1 ocupado, la tentaci\u00f3n puede ser localizar el PID y terminar el proceso inmediatamente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Personalmente considero que es una mala forma de empezar, especialmente en servidores de producci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Antes debemos averiguar qu\u00e9 servicio est\u00e1 utilizando ese puerto, si est\u00e1 atendiendo conexiones y qu\u00e9 consecuencias tendr\u00eda detenerlo.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Ejemplo pr\u00e1ctico: resolver un conflicto en el puerto 8080<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Imaginemos que estamos instalando una aplicaci\u00f3n y necesitamos que escuche en el puerto 8080.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Intentamos iniciarla y aparece este error:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Error: listen EADDRINUSE: address already in use :::8080<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">El mensaje indica que la aplicaci\u00f3n no ha podido vincularse a la direcci\u00f3n y al puerto solicitados porque ya existe un uso incompatible.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Lo primero que har\u00eda ser\u00eda consultar el puerto:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -ltnp 'sport = :8080'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Supongamos que obtenemos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>LISTEN 0 128 0.0.0.0:8080 0.0.0.0:* users:((\"node\",pid=2481,fd=18))<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ahora sabemos que existe un proceso Node.js escuchando en ese puerto.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Pero todav\u00eda no sabemos si es una aplicaci\u00f3n antigua, una instancia duplicada o un servicio que necesita seguir funcionando.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por eso, el siguiente paso consiste en investigar el proceso.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps -ww -p 2481 -o pid,ppid,user,args<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">La salida puede revelar el nombre del script o los argumentos utilizados para iniciar la aplicaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si pertenece a un servicio conocido, revisaremos tambi\u00e9n su configuraci\u00f3n y estado.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comprobar el proceso con ps y el servicio con systemctl<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Una vez identificado el PID, <code>ps<\/code> permite consultar informaci\u00f3n sobre el proceso sin modificar su estado.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps -fp 2481<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Y para obtener m\u00e1s detalle:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps -ww -p 2481 -o pid,ppid,user,args<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si sospechamos que pertenece a un servicio gestionado por systemd, podemos utilizar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo systemctl status nombre-servicio<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Naturalmente, debemos sustituir <code>nombre-servicio<\/code> por la unidad real que queremos consultar.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando conocemos el PID pero no la unidad, tambi\u00e9n podemos intentar identificarla mediante:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>systemctl status 2481<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">En sistemas compatibles, systemd puede mostrar informaci\u00f3n sobre la unidad a la que pertenece el proceso.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si el servicio est\u00e1 gestionado por systemd, merece la pena revisar sus registros:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo journalctl -u nombre-servicio -n 50 --no-pager<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Esto permite consultar las \u00faltimas entradas del registro y detectar errores de arranque, reinicios o configuraciones incorrectas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Conviene comprobar tambi\u00e9n si existe alguna dependencia que pueda verse afectada.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En m\u00e1s de una ocasi\u00f3n me he encontrado con situaciones en las que aparentemente hab\u00eda dos servicios compitiendo por el mismo puerto, pero uno de ellos estaba funcionando correctamente y el otro ten\u00eda una configuraci\u00f3n incorrecta.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En esos casos, no siempre es necesario detener nada.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La soluci\u00f3n puede consistir en modificar el puerto de escucha de la nueva aplicaci\u00f3n o corregir su configuraci\u00f3n.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">C\u00f3mo liberar un puerto sin detener servicios importantes<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Antes de liberar un puerto, deber\u00edamos tener respuesta a tres preguntas:<\/p>\n\n\n\n<ol start=\"1\" class=\"wp-block-list\">\n<li>\u00bfQu\u00e9 proceso lo est\u00e1 utilizando?<\/li>\n\n\n\n<li>\u00bfQu\u00e9 aplicaci\u00f3n o servicio depende de ese proceso?<\/li>\n\n\n\n<li>\u00bfQu\u00e9 ocurrir\u00e1 si lo detenemos?<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">Si confirmamos que existe un servicio que debe detenerse y est\u00e1 gestionado por systemd, lo normal es utilizar su propio mecanismo de administraci\u00f3n:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo systemctl stop nombre-servicio<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s podemos comprobar si el puerto ha quedado disponible:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -ltnp 'sport = :8080'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si no aparecen sockets TCP en escucha en ese puerto, habremos confirmado que no existe ninguno visible mediante esa consulta.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No obstante, eso no garantiza que una nueva aplicaci\u00f3n pueda utilizar cualquier combinaci\u00f3n de direcci\u00f3n y protocolo sin problemas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si el proceso no est\u00e1 gestionado por systemd, tendremos que investigar c\u00f3mo se ha iniciado y cu\u00e1l es la forma adecuada de detenerlo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En determinadas circunstancias puede utilizarse una se\u00f1al de terminaci\u00f3n:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo kill -TERM 2481<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Pero \u00fanicamente cuando hemos identificado correctamente el proceso y confirmado que debe detenerse.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Lo que evitar\u00eda como primera medida es:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo kill -9 2481<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">La se\u00f1al <code>SIGKILL<\/code> provoca la terminaci\u00f3n forzada del proceso, sin permitirle ejecutar su procedimiento habitual de cierre.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En un servidor de producci\u00f3n, eso puede interrumpir conexiones o impedir que una aplicaci\u00f3n complete tareas pendientes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Adem\u00e1s, si un supervisor reinicia autom\u00e1ticamente el servicio, el puerto puede volver a ocuparse inmediatamente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por eso prefiero solucionar el origen del conflicto antes que limitarme a terminar procesos.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">C\u00f3mo saber si un puerto est\u00e1 abierto, en escucha o tiene conexiones activas<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Hay un concepto que conviene tener claro cuando investigamos puertos Linux: <strong>un socket en escucha no es lo mismo que una conexi\u00f3n establecida<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tampoco debemos confundir que un puerto aparezca abierto en una herramienta local con que resulte accesible desde otra m\u00e1quina.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Son situaciones relacionadas, pero diferentes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, podemos tener un servidor web escuchando correctamente en el puerto 443 y, aun as\u00ed, no conseguir conectarnos desde Internet porque el <a href=\"https:\/\/www.hostingtg.com\/blog\/ufw-vs-iptables-vs-nftables\/\">firewall<\/a> est\u00e1 bloqueando las conexiones entrantes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n puede ocurrir que un servicio escuche \u00fanicamente en la interfaz local, de forma que otras m\u00e1quinas no puedan acceder directamente a \u00e9l mediante las interfaces externas.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Diferencias entre LISTEN, ESTAB y TIME-WAIT<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando ejecutamos <code>ss<\/code> podemos encontrarnos con diferentes estados TCP.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Algunos de los m\u00e1s habituales son:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><th>Estado<\/th><th>Significado<\/th><\/tr><tr><td><code>LISTEN<\/code><\/td><td>Socket TCP esperando conexiones entrantes<\/td><\/tr><tr><td><code>ESTAB<\/code><\/td><td>Conexi\u00f3n TCP establecida<\/td><\/tr><tr><td><code>TIME-WAIT<\/code><\/td><td>Estado temporal tras el cierre de una conexi\u00f3n TCP<\/td><\/tr><tr><td><code>SYN-SENT<\/code><\/td><td>Se ha enviado una solicitud para establecer una conexi\u00f3n<\/td><\/tr><tr><td><code>CLOSE-WAIT<\/code><\/td><td>Se ha recibido una solicitud de cierre y se espera el cierre local<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Si estamos intentando arrancar Nginx y necesitamos comprobar qui\u00e9n escucha en el puerto 80, normalmente nos interesa el estado <code>LISTEN<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Podemos consultarlo mediante:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -ltnp 'sport = :80'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Pero si queremos investigar conexiones TCP establecidas y los procesos asociados, podemos ejecutar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -tnp state established<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Este comando muestra conexiones TCP establecidas y, cuando la informaci\u00f3n est\u00e1 disponible, los procesos relacionados.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En mi caso, es una consulta \u00fatil cuando estoy investigando un consumo inesperado de recursos o conexiones hacia determinadas direcciones IP.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ahora bien, conviene interpretar los resultados con cuidado.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Que un proceso tenga muchas conexiones establecidas no significa necesariamente que est\u00e9 realizando alguna actividad sospechosa.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Un servidor web con bastante tr\u00e1fico puede mantener numerosas conexiones completamente leg\u00edtimas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Del mismo modo, encontrar sockets en estado <code>TIME-WAIT<\/code> no implica por s\u00ed solo que exista un proceso escuchando en ese puerto.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Este estado forma parte del funcionamiento normal de TCP y puede persistir durante un tiempo despu\u00e9s del cierre de determinadas conexiones.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por eso, cuando investigamos conflictos de arranque, resulta importante distinguir entre los diferentes estados y no interpretar cualquier aparici\u00f3n de un n\u00famero de puerto como una prueba de que existe un servicio escuchando.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Qu\u00e9 significa que un servicio escuche en 0.0.0.0 o 127.0.0.1<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando consultamos los puertos de un servidor Linux, es habitual encontrar direcciones como:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>127.0.0.1:3306<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">O:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>0.0.0.0:3306<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Aunque ambos ejemplos utilizan el mismo puerto, su significado es diferente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>127.0.0.1<\/code> es una direcci\u00f3n de loopback IPv4.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando un servicio escucha exclusivamente en esa direcci\u00f3n, acepta conexiones dirigidas a ella desde el propio sistema, no directamente desde otras m\u00e1quinas mediante una interfaz externa.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En cambio, <code>0.0.0.0<\/code> representa la direcci\u00f3n comod\u00edn de IPv4 y permite que el socket escuche en las interfaces IPv4 locales disponibles.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Esto no significa autom\u00e1ticamente que el puerto sea accesible desde Internet.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para determinarlo tambi\u00e9n debemos revisar las reglas del firewall, la configuraci\u00f3n de red y los controles de acceso.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En HostingTG considero importante prestar atenci\u00f3n a estos detalles, especialmente cuando se trata de bases de datos o servicios internos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, si MySQL solamente necesita aceptar conexiones locales, encontrarlo escuchando en todas las interfaces puede indicar una configuraci\u00f3n que merece revisarse.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No todos los puertos en escucha representan un problema de seguridad.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Lo importante es saber qu\u00e9 servicio utiliza cada uno, por qu\u00e9 est\u00e1 abierto y desde d\u00f3nde deber\u00eda poder accederse a \u00e9l.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Problemas habituales al identificar procesos y puertos en Linux<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Aunque los comandos anteriores son relativamente sencillos, existen situaciones en las que los resultados pueden resultar confusos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A veces el puerto parece estar ocupado, pero no encontramos ning\u00fan proceso escuchando.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En otras ocasiones aparece el socket, pero no su PID.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n podemos encontrar conflictos relacionados con contenedores, procesos que se reinician autom\u00e1ticamente o servicios vinculados a diferentes interfaces.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Antes de concluir que una herramienta no funciona, conviene revisar algunos de estos escenarios.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">El proceso no aparece aunque el puerto est\u00e9 ocupado<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Imaginemos que una aplicaci\u00f3n indica que el puerto 8080 est\u00e1 ocupado, pero ejecutamos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -ltnp 'sport = :8080'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Y no obtenemos ning\u00fan resultado.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Eso no demuestra necesariamente que el puerto est\u00e9 completamente disponible.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En primer lugar, debemos comprobar si la aplicaci\u00f3n utiliza TCP o UDP.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para consultar sockets UDP asociados al puerto 8080 podemos ejecutar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -unap 'sport = :8080'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n conviene comprobar los sockets TCP sin limitarnos al estado de escucha:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -tanp 'sport = :8080'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Esta consulta puede mostrar otros estados de conexi\u00f3n relacionados con el puerto local.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si todav\u00eda no encontramos la causa, es importante comprobar que estamos ejecutando el diagn\u00f3stico en el mismo entorno de red que la aplicaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, los contenedores pueden utilizar espacios de nombres de red independientes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En consecuencia, un proceso dentro de un contenedor no siempre aparecer\u00e1 como esperamos al ejecutar una consulta desde el sistema anfitri\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n debemos considerar que algunas aplicaciones intentan utilizar direcciones espec\u00edficas, que pueden existir conflictos con sockets IPv4 e IPv6 o que el estado del puerto haya cambiado entre una comprobaci\u00f3n y otra.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En estos casos prefiero revisar el mensaje exacto de error y la configuraci\u00f3n de la aplicaci\u00f3n antes de atribuir el problema a un proceso concreto.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Permisos insuficientes para visualizar el PID<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Otro problema habitual consiste en ejecutar <code>ss<\/code>, <code>lsof<\/code> o <code>netstat<\/code> sin los permisos necesarios.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En determinadas situaciones podemos ver que un puerto est\u00e1 en escucha, pero no obtener informaci\u00f3n sobre el proceso asociado.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Esto ocurre porque el sistema limita el acceso a determinados datos de otros procesos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para una consulta administrativa, normalmente podemos repetir el comando utilizando <code>sudo<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -tulnp<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">O:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo lsof -nP -iTCP:443 -sTCP:LISTEN<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Sin embargo, incluso con privilegios elevados pueden existir restricciones adicionales relacionadas con contenedores, espacios de nombres, configuraciones de seguridad o el entorno de ejecuci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n es posible que un proceso termine entre el momento en que identificamos el socket y el momento en que consultamos su PID.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por eso es recomendable comprobar que el identificador sigue correspondiendo al proceso que queremos investigar antes de realizar cualquier acci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Un PID puede reutilizarse despu\u00e9s de que el proceso original haya terminado.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Conflictos de puertos con Apache, Nginx y Docker<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Los conflictos entre servidores web son uno de los escenarios m\u00e1s habituales.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, podemos tener Nginx escuchando en el puerto 80 e intentar iniciar Apache utilizando esa misma direcci\u00f3n y puerto.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para comprobarlo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -ltnp 'sport = :80'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si encontramos Nginx, el siguiente paso ser\u00e1 investigar si debe actuar como <a href=\"https:\/\/www.hostingtg.com\/blog\/nginx-servidor-web-alto-rendimiento\/\">proxy inverso<\/a>, si Apache deber\u00eda utilizar otro puerto o si realmente existe una configuraci\u00f3n duplicada.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No siempre tiene sentido detener uno de los servidores.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En algunas arquitecturas, precisamente queremos que Nginx escuche p\u00fablicamente en los puertos 80 y 443 mientras Apache u otra aplicaci\u00f3n utiliza un puerto interno diferente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><a href=\"https:\/\/www.hostingtg.com\/blog\/introduccion-docker\/\">Docker<\/a> a\u00f1ade otro elemento que debemos considerar.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Un contenedor puede publicar un puerto del anfitri\u00f3n y generar un conflicto si intentamos utilizarlo para otra aplicaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para consultar los contenedores en ejecuci\u00f3n y sus puertos publicados podemos utilizar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker ps<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Y, si queremos una salida m\u00e1s concreta:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker ps --format \"table {{.Names}}\\t{{.Ports}}\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, una asignaci\u00f3n como:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>0.0.0.0:8080-&gt;80\/tcp<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Indica que el puerto TCP 8080 del anfitri\u00f3n est\u00e1 publicado hacia el puerto 80 del contenedor.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Dependiendo de la configuraci\u00f3n de Docker, las reglas de red y el mecanismo de publicaci\u00f3n utilizado, esta asignaci\u00f3n no tiene por qu\u00e9 aparecer siempre como un proceso convencional escuchando en <code>ss<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por eso conviene combinar la consulta de sockets con la revisi\u00f3n de los puertos publicados por los contenedores.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Es un buen ejemplo de por qu\u00e9 no deber\u00edamos depender de un \u00fanico comando para investigar todos los conflictos de puertos.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Qu\u00e9 comando recomiendo para comprobar un puerto en Linux<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Si tuviera que quedarme con un \u00fanico comando para averiguar qu\u00e9 proceso utiliza un puerto en Linux, elegir\u00eda <code>ss<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En la mayor\u00eda de las distribuciones actuales permite consultar r\u00e1pidamente los sockets, identificar puertos en escucha y obtener informaci\u00f3n del proceso asociado.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -ltnp 'sport = :80'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Para una revisi\u00f3n general:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -tulnp<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Y cuando necesito investigar con mayor detalle el proceso, su usuario o los archivos abiertos, recurro a <code>lsof<\/code>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo lsof -nP -iTCP:443 -sTCP:LISTEN<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><code>netstat<\/code> sigue siendo v\u00e1lido en muchos sistemas, especialmente en servidores heredados, pero personalmente prefiero utilizar las herramientas actuales cuando est\u00e1n disponibles.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s de a\u00f1os administrando servidores Linux en HostingTG, he aprendido que lo importante no es memorizar decenas de comandos, sino saber qu\u00e9 informaci\u00f3n necesitamos y c\u00f3mo interpretarla.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Identificar un PID puede llevar apenas unos segundos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Determinar si ese proceso debe seguir funcionando, si est\u00e1 correctamente configurado o si representa un problema requiere algo m\u00e1s de criterio.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Y esa es precisamente la diferencia entre limitarse a liberar un puerto y resolver correctamente el problema que lo estaba causando.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Dudas de la comunidad<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">\u00bfC\u00f3mo saber qu\u00e9 proceso utiliza el puerto 80 en Linux?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">La forma m\u00e1s r\u00e1pida es ejecutar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -ltnp 'sport = :80'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si existe un proceso con un socket TCP en escucha en ese puerto y tenemos permisos suficientes, podremos consultar su nombre y PID.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n podemos utilizar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo lsof -nP -iTCP:80 -sTCP:LISTEN<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Estos comandos son \u00fatiles cuando investigamos conflictos con Apache, Nginx u otros servidores web.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">\u00bfC\u00f3mo obtener el PID de un puerto concreto?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Podemos consultar el puerto mediante <code>ss<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -ltnp 'sport = :8080'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">El resultado puede incluir un identificador como <code>pid=2481<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s podremos investigar ese proceso mediante:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps -fp 2481<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Otra alternativa es utilizar <code>lsof<\/code>, que muestra el PID en una columna espec\u00edfica:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo lsof -nP -iTCP:8080 -sTCP:LISTEN<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">\u00bfC\u00f3mo comprobar si el puerto 443 est\u00e1 ocupado?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Para comprobar si existe un socket TCP en escucha en el puerto 443, ejecutamos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -ltnp 'sport = :443'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si encontramos resultados, podremos revisar qu\u00e9 proceso est\u00e1 asociado al puerto.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si no aparece ning\u00fan resultado, solamente habremos comprobado que no existen sockets TCP en escucha visibles mediante ese filtro.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La disponibilidad real tambi\u00e9n puede depender de la direcci\u00f3n de escucha, del protocolo y de otras condiciones del sistema.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">\u00bfQu\u00e9 diferencia hay entre un puerto abierto y uno en escucha?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Un socket TCP en estado <code>LISTEN<\/code> est\u00e1 preparado para aceptar conexiones entrantes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sin embargo, decir que un puerto est\u00e1 abierto puede tener un significado diferente dependiendo de c\u00f3mo se est\u00e9 comprobando.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, una herramienta de exploraci\u00f3n remota puede considerar abierto un puerto cuando consigue establecer una conexi\u00f3n con \u00e9l.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Un servicio puede estar escuchando localmente y no ser accesible desde Internet debido a reglas de firewall o a la direcci\u00f3n en la que est\u00e1 vinculado.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por tanto, escuchar y ser accesible desde una m\u00e1quina remota no son necesariamente lo mismo.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">\u00bfC\u00f3mo liberar el puerto 8080 en Linux?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Lo primero es identificar el proceso:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ss -ltnp 'sport = :8080'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s debemos investigar su PID y comprobar a qu\u00e9 servicio pertenece.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si se trata de un servicio gestionado por systemd y hemos confirmado que debe detenerse, podemos utilizar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo systemctl stop nombre-servicio<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n podemos modificar la configuraci\u00f3n de la aplicaci\u00f3n para utilizar otro puerto cuando sea m\u00e1s adecuado.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No recomiendo utilizar <code>kill -9<\/code> como primera opci\u00f3n, especialmente en servidores de producci\u00f3n, porque puede interrumpir procesos que est\u00e9n realizando tareas importantes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Opini\u00f3n Personal<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s de tantos a\u00f1os administrando servidores Linux en <strong>HostingTG<\/strong>, tengo bastante claro que saber qu\u00e9 proceso est\u00e1 utilizando un puerto es una de esas habilidades b\u00e1sicas que cualquier administrador de sistemas deber\u00eda dominar.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Y no lo digo porque sea una tarea especialmente complicada, sino porque es sorprendente la cantidad de problemas que podemos evitar con una simple comprobaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Personalmente, <strong>mi herramienta favorita para identificar qu\u00e9 proceso ocupa un puerto en Linux es<\/strong> <code><strong>ss<\/strong><\/code>. Me parece r\u00e1pida, pr\u00e1ctica y m\u00e1s que suficiente para la mayor\u00eda de las situaciones que encuentro en el d\u00eda a d\u00eda. Eso s\u00ed, tampoco renuncio a <code>lsof<\/code> cuando necesito investigar con mayor detalle qu\u00e9 usuario est\u00e1 ejecutando un proceso o qu\u00e9 aplicaci\u00f3n hay detr\u00e1s de un puerto determinado.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En cuanto a <code>netstat<\/code>, le tengo cierto cari\u00f1o porque lo he utilizado durante muchos a\u00f1os. Sin embargo, creo que debemos acostumbrarnos a utilizar herramientas m\u00e1s actuales, especialmente cuando administramos servidores modernos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Pero, por encima de los comandos, hay algo que considero todav\u00eda m\u00e1s importante: <strong>no debemos confundir identificar un problema con solucionarlo<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">He visto demasiadas veces c\u00f3mo alguien descubre que un puerto est\u00e1 ocupado y lo primero que hace es intentar terminar el proceso que lo utiliza. En un servidor de pruebas puede que no tenga mayores consecuencias, pero cuando administramos p\u00e1ginas web y aplicaciones en producci\u00f3n, actuar de esa manera puede ocasionar interrupciones completamente innecesarias.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Mi recomendaci\u00f3n es sencilla: primero identifica el proceso, despu\u00e9s averigua a qu\u00e9 servicio pertenece y, finalmente, decide qu\u00e9 hacer. No siempre es necesario detener nada. A veces basta con corregir una configuraci\u00f3n o cambiar el puerto de escucha de una aplicaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Al final, administrar servidores Linux no consiste \u00fanicamente en conocer comandos, sino en saber cu\u00e1ndo utilizarlos y entender las consecuencias de nuestras decisiones.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>\u00bfY t\u00fa, qu\u00e9 comando utilizas habitualmente para saber qu\u00e9 proceso ocupa un puerto en Linux?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\u00bfEres de los que prefieren <code>ss<\/code>, sigues utilizando <code>netstat<\/code> o te resulta m\u00e1s c\u00f3modo trabajar con <code>lsof<\/code>? \u00bfAlguna vez te has encontrado con un conflicto de puertos especialmente complicado de resolver?<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Te animo a dejar tu experiencia en los comentarios.<\/strong> Me interesa conocer qu\u00e9 herramientas utilizas y c\u00f3mo resuelves estas situaciones en tus servidores. Seguro que entre todos podemos compartir alg\u00fan truco \u00fatil que nos ahorre m\u00e1s de un quebradero de cabeza.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Hay pocas cosas m\u00e1s molestas cuando est\u00e1s administrando un servidor Linux que intentar arrancar un servicio y encontrarte con un error indicando que el puerto ya est\u00e1 ocupado. Lo primero que piensas es que probablemente existe otra instancia del mismo servicio funcionando, pero no siempre es as\u00ed. En ocasiones descubres que el puerto est\u00e1 siendo [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":10337,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[952],"tags":[836,779,1544,902,1101],"class_list":["post-10336","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-guias","tag-comandos-linux","tag-linux","tag-lsof","tag-netstat","tag-puertos"],"_links":{"self":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/10336","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/comments?post=10336"}],"version-history":[{"count":2,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/10336\/revisions"}],"predecessor-version":[{"id":10339,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/10336\/revisions\/10339"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/media\/10337"}],"wp:attachment":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/media?parent=10336"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/categories?post=10336"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/tags?post=10336"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}