¿Por qué no puedo acceder a mi puerto?

Has configurado una web, una app o una base de datos, y desde tu portátil no puedes acceder. El navegador se queda cargando. curl agota el tiempo de espera. Miras el servidor y por dentro todo parece estar bien: el proceso está en marcha, los logs dicen "listening on port 8080", pero desde fuera es como si el servidor no existiera.

Este es uno de los problemas más habituales. Y resulta frustrante porque tres problemas completamente distintos se ven exactamente igual desde fuera. Hasta que no sabes cuál de ellos tienes, no puedes solucionarlo.

Este artículo repasa las tres capas, en el orden en que conviene revisarlas, y muestra cómo Server Manager detecta y corrige cada una.

Las tres capas, en orden

Entre tu navegador y el programa que se ejecuta en tu servidor hay tres lugares donde se puede bloquear el tráfico. Desde fuera, los tres se ven igual: "no puedo acceder". Por dentro, son problemas muy distintos con soluciones muy distintas.

Las tres capas:

1. Firewall del proveedor en la nube — se ejecuta fuera de tu servidor, en tu proveedor (Hetzner, Oracle, AWS, etc.). Descarta los paquetes antes de que lleguen siquiera al servidor.
2. Firewall del servidor — se ejecuta en tu servidor. Descarta los paquetes cuando llegan, antes de que cualquier servicio los vea.
3. Tu servicio — el programa en sí (Caddy, tu app, tu base de datos). O no se está ejecutando, o solo escucha localmente.

Piénsalo como un edificio con tres controles de seguridad. El paquete tiene que pasar los tres para llegar hasta ti. Si cualquiera de ellos lo bloquea, no podrán acceder a tu servicio; y desde fuera no puedes saber qué control lo ha detenido.

Capa 3 — ¿Tu servicio está escuchando de verdad?

Es la causa más barata de comprobar y la más común. Antes de preocuparte por los firewalls, comprueba que hay un programa en el servidor escuchando activamente en el puerto que esperas.

Esto suele fallar de dos maneras:

• No hay nada escuchando. El contenedor se ha caído. El servicio systemd no ha arrancado. La app se cerró al iniciar. Desde fuera se ve exactamente igual que un bloqueo de firewall: el paquete llega, pero no hay nadie en casa para responder.
• Solo escucha en localhost. Este caso es traicionero. Muchos programas usan por defecto "solo loopback" (127.0.0.1), lo que significa que el programa se está ejecutando felizmente y acepta conexiones, pero solo desde el propio servidor. Las conexiones externas no pueden llegar aunque todos los firewalls estén completamente abiertos. Sospechosos habituales: PostgreSQL recién instalado, MySQL/MariaDB, Redis, notebooks de Jupyter, servidores de desarrollo y cualquier cosa que diga "por seguridad, por defecto solo nos enlazamos a localhost."

Cómo ayuda Server Manager:

• La pestaña Detalles del servidor → Firewall puede responder "¿lo está bloqueando el firewall de mi servidor?", pero la capa 3 es algo que el chat maneja mejor: pregúntale a Faro: "¿Hay algo escuchando de verdad en el puerto 8080?" y ejecutará ss -tlnp y te lo dirá.
• Si haces clic en Diagnosticar inaccesibilidad en la pestaña Firewall, el diagnóstico comprueba las tres capas, incluida esta, y te dice cuál es la causa.

Capa 2 — El firewall del servidor (en el servidor)

La siguiente capa que debes revisar es el firewall que se ejecuta en el propio servidor. En Ubuntu/Debian suele ser ufw; en Fedora/Rocky es firewalld; por debajo de ambos está iptables puro. Da igual cuál sea la interfaz: su trabajo es el mismo, descartar los paquetes entrantes que no estén permitidos explícitamente.

Tres cosas que debes saber sobre esta capa:

• La mayoría de los servidores recién creados usan "permitir por defecto": todos los puertos son accesibles a través del firewall del servidor, porque el firewall no está instalado o no está aplicando ninguna regla. Server Manager lo muestra claramente: la pestaña Firewall muestra un aviso amarillo de "Permitir por defecto" cuando este es el caso.
• Un servidor "reforzado" usa "denegar por defecto": el tráfico entrante se bloquea por defecto; solo pasan los puertos permitidos explícitamente. SSH (puerto 22) siempre se mantiene abierto, además de lo que hayas confirmado durante la configuración.
• La mayoría de los proveedores de hosting no activan un firewall de servidor por ti. O recibes un servidor que permite por defecto (todos los puertos abiertos en esta capa), o lo configuras tú.

Cómo ayuda Server Manager:

• Detalles del servidor → pestaña Firewall te muestra el estado actual de un vistazo: backend (ufw / iptables / firewalld / none), activo o permitir por defecto, y la lista de puertos permitidos explícitamente con etiquetas en lenguaje claro.
• Abrir un puerto te permite dejar pasar un único puerto por el firewall del servidor con un clic (el campo Puerto y el selector de protocolo en la parte superior de la pestaña). El chat te guía por la forma segura y persistente de hacerlo.
• Reforzar el firewall de este servidor cambia de forma segura un servidor de permitir por defecto a denegar por defecto. Un modal lista todos los servicios que están escuchando en ese momento y te permite elegir cuáles deben seguir siendo públicos. SSH siempre se mantiene abierto (la protección se niega a dejarte fuera). Docker se detecta automáticamente y se usa un modo compatible con Docker para que los contenedores sigan funcionando.
• Diagnosticar inaccesibilidad comprueba esta capa (y las demás) e informa de cuál está bloqueando tu puerto.

Importante: activar un firewall de servidor junto con Docker es delicado. Ejecutar sin más ufw enable en un host con Docker puede romper la red de los contenedores: Docker gestiona sus propias reglas de firewall mediante una cadena separada (DOCKER-USER), y ufw no lo sabe. Si dejas que Server Manager se encargue del refuerzo, detecta Docker y usa automáticamente una ruta segura para Docker. Hacerlo a mano sin esa integración es una forma habitual de perder conectividad con tus contenedores.

Capa 1 — El firewall del proveedor en la nube (fuera del servidor)

La capa más complicada. Tu proveedor de hosting ejecuta un firewall delante de tu servidor: los paquetes se filtran antes de llegar siquiera a tu VM. Server Manager no puede ver directamente ese firewall porque no está en tu servidor; solo la consola web de tu proveedor puede cambiarlo.

Los nombres y comportamientos varían muchísimo:

Lo importante que debes interiorizar: el firewall del servidor y el firewall en la nube son dos firewalls distintos. Ambos pueden bloquear. Ambos pueden permitir el paso. Puedes abrir un puerto en el servidor y aun así seguir bloqueado en la nube (muy común). Puedes no tener nada bloqueando en el servidor y estar bloqueado en la nube (también común).

Cómo ayuda Server Manager:

• Server Manager no puede cambiar directamente las reglas del firewall en la nube (necesitaría claves de API para cada proveedor), pero Faro conoce los pasos exactos, clic a clic, para todos los proveedores principales y te guía. Después de abrir un puerto en el servidor, Faro pregunta "¿quieres que te guíe también para abrirlo en la nube?" y te da instrucciones exactas para la consola web de tu proveedor.
• Cuando ejecutas Diagnosticar inaccesibilidad en la pestaña Firewall, el diagnóstico identifica si el firewall en la nube es el que bloquea y genera automáticamente la guía correspondiente a tu proveedor.
• Cuando refuerzas el firewall de este servidor, Faro te recuerda que también ajustes el firewall en la nube para que coincida (si no, tendrás una configuración asimétrica: estricta en el servidor, laxa en la nube).

Cómo comprueba Server Manager las tres capas por ti

La vía del chat: abre Faro y di "¿por qué no puedo acceder al puerto 8080?" El agente prueba las tres capas en orden: servicio escuchando, firewall del servidor, firewall en la nube, y te dice cuál es la causa. Después se ofrece a solucionarlo.

La vía de la interfaz: Detalles del servidor → pestaña Firewall → Diagnosticar inaccesibilidad. Escribe el puerto y haz clic en el botón. Misma comprobación de tres capas, mismo diagnóstico, misma oferta de solución.

El resultado siempre señala una capa concreta como causa y propone una única solución en forma de pregunta de sí/no. Nada de listas genéricas de varias páginas.

Situaciones habituales

"He desplegado una base de datos y no puedo conectarme desde mi portátil"

Casi seguro que es la capa 3: la base de datos **solo escucha en 127.0.0.1**. PostgreSQL, MySQL, MariaDB y Redis usan localhost por defecto. Están funcionando bien; simplemente no puedes acceder a ellas desde fuera.

La solución depende de lo que quieras:

• Para app→base de datos en el mismo servidor (el caso normal), así es como debe estar. Conecta tu app a localhost:5432 (o el puerto que corresponda) y listo. No necesitas cambiar ningún firewall. En Server Manager: no tienes que hacer nada; Faro despliega las bases de datos así por defecto.
• Para administración remota "mi portátil → base de datos", abre un túnel: ssh -L 5432:localhost:5432 user@server desde tu portátil y luego conecta tu cliente de base de datos a localhost:5432 localmente. Es más seguro que exponer la base de datos a internet. En Server Manager: pídele a Faro el comando exacto del túnel; conoce el usuario y el host de tu servidor.
• Para "de verdad quiero que esta base de datos sea accesible públicamente", cambia la dirección de escucha en la configuración de la base de datos a 0.0.0.0, reinicia la base de datos y luego abre el puerto tanto en el firewall del servidor COMO en el firewall en la nube. Asegúrate por completo de haber configurado antes una contraseña fuerte; exponer una base de datos a internet sin autenticación sólida es una forma habitual de acabar comprometido. En Server Manager: pídele a Faro que haga los tres pasos (cambiar la escucha de la base de datos, abrir el puerto del firewall del servidor desde la pestaña Firewall y guiarte por la regla del proveedor en la nube). Si aún no has definido una, haz que Faro genere primero una contraseña fuerte.

"He abierto el puerto en ufw y sigo sin poder acceder"

Capa 1: no se lo has indicado al firewall del proveedor en la nube. ufw allow 8080/tcp en el servidor abre la capa 2; el paquete todavía tiene que pasar la capa 1 antes de llegar a tu servidor. Abre la regla correspondiente en la consola de tu proveedor en la nube.

En Server Manager: pide a Faro que te guíe por la regla en la nube de tu proveedor. Te dará pasos clic a clic para Hetzner / AWS / Oracle / etc. sin que tengas que buscar cómo está organizado el panel.

"Ayer funcionaba y hoy no"

Algunas causas habituales:

• Tu IP ha cambiado: si tu firewall en la nube está limitado a "solo mi IP" y tu conexión de casa recibió una IP nueva durante la noche (muy común con la mayoría de los ISP domésticos), la nueva IP ahora está bloqueada. Amplía temporalmente a 0.0.0.0/0, entra y luego vuelve a limitarlo.
• El servicio se ha caído: un problema de capa 3 disfrazado. Comprueba systemctl status <service> o docker ps.
• El servidor se ha reforzado hace poco: si alguien activó el firewall del servidor sin incluir el puerto que te importa, ese puerto ahora está bloqueado en la capa 2. Abre la pestaña Firewall para ver el conjunto de reglas actual.

En Server Manager: escribe el puerto afectado en la pestaña Firewall y haz clic en Diagnosticar inaccesibilidad. Faro prueba las tres capas y te dice cuál ha dejado de funcionar. Más rápido que adivinar.

"Puedo hacer curl desde el servidor, pero no desde fuera"

Esa es la línea divisoria del diagnóstico: te dice que el servicio está bien y que la capa 3 no es el problema. Ahora es la capa 2 (firewall del servidor) o la capa 1 (firewall en la nube). Usa Diagnosticar inaccesibilidad para acotarlo más.

En Server Manager: el botón Diagnosticar inaccesibilidad de la pestaña Firewall es la herramienta adecuada justo para este caso: salta la capa 3 (porque ya has demostrado que funciona) y te dice cuál de las dos capas de firewall está descartando el paquete.

Preguntas frecuentes

¿Necesito un firewall de servidor si mi proveedor en la nube ya tiene uno?

Sí y no, depende de tu modelo de amenazas. Un firewall en la nube cubre el caso común. Un firewall de servidor es útil cuando:

• Usas Docker: en algunas configuraciones, los contenedores pueden abrir sus propios agujeros y saltarse el firewall en la nube. Un firewall de servidor controla la salida de los contenedores.
• Olvidas quitar reglas temporales del firewall en la nube: el firewall del servidor es la red de seguridad.
• Quieres filtrar tráfico saliente: los firewalls en la nube suelen centrarse en el tráfico entrante; los firewalls de servidor pueden hacer ambas cosas.

Si nada de eso aplica, un único firewall en la nube bien configurado basta para la mayoría de configuraciones.

¿Server Manager funciona sin un firewall de servidor?

Sí. Server Manager no necesita ninguna configuración de firewall para funcionar. La pestaña Firewall es por tu seguridad, no para conectar con Server Manager en sí (Server Manager solo necesita SSH, puerto 22).

¿Por qué la pestaña Firewall me dice "Permitir por defecto" si nunca he configurado nada?

Porque ese es el estado real. La mayoría de los servidores recién creados no tienen un firewall de servidor configurado: todos los puertos son accesibles en esa capa. Que algo llegue realmente a tu servicio depende de la capa 1 (firewall en la nube) y de la capa 3 (si el servicio está escuchando). El aviso amarillo te indica que quizá quieras reforzarlo.

¿Debería cerrar alguna vez "Abrir puerto 22 / SSH"?

No. Server Manager se comunica con tu servidor solo por SSH. Cerrar el puerto 22 desconecta Server Manager y necesitarías recuperarlo desde la consola del proveedor (consulta Recuperar cuando SSH deja de funcionar). La pestaña Firewall se niega a mostrar un botón Cerrar en la fila de SSH por este motivo, y el modal de refuerzo bloquea la fila de SSH como "mantener siempre abierto."

Qué NO cubre este artículo

• Problemas de tráfico saliente (tu servidor no puede acceder a internet): es otra configuración distinta, normalmente NAT, DNS o la red saliente del proveedor. Pide a Faro que lo diagnostique.
• Errores de HTTPS / TLS: en esos casos la conectividad sí ha funcionado, pero el intercambio de cifrado ha fallado. Es otro tipo de problema; consulta la sección dominios-HTTPS-correo electrónico.
• Problemas de DNS ("mi dominio no resuelve al servidor"): se tratan en Apuntar un dominio aquí. El paquete aún ni siquiera ha llegado a la cuestión de los firewalls: todavía no sabe dónde está el servidor.
• Configuración específica de una app (qué variable de entorno debes definir para que tu app escuche en 0.0.0.0 en lugar de 127.0.0.1): varía según la app. Pregunta a Faro: conoce las más habituales.