Guía de puertos HTTP: tráfico web en el puerto 80

HTTP es el protocolo de solicitud y respuesta utilizado por navegadores, API, webhooks, comprobaciones de estado y muchos servicios internos. En el puerto 80, el cliente se conecta a través de TCP, envía una solicitud HTTP y recibe encabezados y un cuerpo de respuesta sin un protocolo de enlace TLS primero.

Debido a que el tráfico no está cifrado, cualquiera que pueda observar la ruta de la red puede ver URL, cookies, encabezados, datos de formularios y contenido de respuesta, a menos que la aplicación agregue su propia protección. Para sitios web públicos y aplicaciones autenticadas, el puerto 80 normalmente debería redirigir a HTTPS en lugar de servir contenido privado directamente.

El puerto 80 es HTTP simple. El puerto 443 es HTTPS, lo que significa que HTTP se transporta dentro de una sesión cifrada con TLS. La experiencia del usuario puede parecer similar en un navegador, pero el modelo de seguridad es diferente: HTTPS valida el certificado del servidor y cifra el tráfico en tránsito.

La mayoría de los sitios de producción utilizan ambos puertos juntos. El puerto 80 acepta enlaces antiguos, cuestionamientos de certificados y solicitudes de navegador por primera vez, luego envía una redirección 301 o 308 a la URL HTTPS en 443. Después de eso, HSTS puede decirle a los navegadores que prefieran HTTPS automáticamente.

Mantenga abierto el puerto 80 cuando necesite redireccionamientos HTTP a HTTPS, desafíos Let's Encrypt HTTP-01, comprobaciones de estado del balanceador de carga, comprobaciones de origen CDN, puntos finales de estado internos simples o compatibilidad con sistemas más antiguos que no pueden iniciarse directamente en HTTPS.

Cierre o restrinja el puerto 80 cuando el servicio sea privado, cuando todos los clientes estén controlados y puedan usar HTTPS directamente, o cuando HTTP simple cree una exposición innecesaria. Si lo mantiene abierto, mantenga el comportamiento limitado y predecible: redireccionamiento, desafío o verificación de estado en lugar de acceso completo a la aplicación.

Antes de abrir TCP 80, confirme que el servidor web, el proxy inverso, el controlador de ingreso, el origen CDN o el equilibrador de carga deseado esté escuchando en la interfaz correcta. Decida si el puerto 80 debe servir contenido, redirigir al 443, responder comprobaciones de estado o responder solo a rutas de validación de certificados.

Un verificador de puertos confirma la accesibilidad de la red, pero no le dice si su cadena de redireccionamiento, encabezados de caché, enrutamiento de host virtual o automatización de certificados son correctos. Pruebe tanto la ruta TCP como el comportamiento HTTP con un navegador, curl y registros del servidor.

En Windows Server, ejecute IIS, Nginx, Apache, Caddy u otro servidor web, vincule el sitio a TCP 80 y permita el tráfico HTTP entrante en el Firewall de Windows Defender. Los servidores en la nube también necesitan reglas de grupo de seguridad o firewall en la nube que coincidan.

En Linux, configure Nginx, Apache, Caddy, una publicación de puerto de contenedor o un controlador de ingreso para escuchar en 80, luego permita TCP 80 en ufw, firewalld, nftables, iptables o el firewall del proveedor. Los contenedores y los servicios de Kubernetes deben publicar o enrutar el puerto en el host, el equilibrador de carga o la capa de entrada.

En macOS, el puerto 80 se utiliza con mayor frecuencia para desarrollo local o servicios de laboratorio. Los puertos privilegiados pueden requerir permisos elevados, y las reglas del firewall o enrutador local aún determinan si otras máquinas pueden acceder al servicio.

Comience con una verificación del puerto externo con el nombre de host público o la dirección IP y el puerto 80. Si el resultado está abierto, los clientes remotos pueden establecer una conexión TCP. Luego ejecute curl -I http://example.com para inspeccionar códigos de estado, redirecciones, encabezados del servidor y comportamiento de la caché.

En el servidor, verifique los oyentes con ss -tlnp, netstat, lsof o PowerShell. Para proxies inversos e implementaciones en la nube, compare las reglas de firewall del host, los grupos de seguridad de la nube, los escuchas del balanceador de carga, las asignaciones de puertos de contenedores y los registros de aplicaciones porque cualquier capa puede bloquear o enrutar incorrectamente HTTP.

Si el puerto 80 se muestra cerrado, el servidor web puede estar detenido, escuchando solo en el host local, usando un puerto diferente o bloqueado por el firewall del host. Si se agota el tiempo de espera, los paquetes pueden ser descartados por un firewall en la nube, una regla NAT del enrutador, un filtro de ISP, una configuración de CDN o una política de seguridad ascendente.

Si el puerto 80 está abierto pero la página es incorrecta, inspeccione el orden de los hosts virtuales, el enrutamiento del encabezado del host, los bloques de servidores predeterminados, las corrientes ascendentes del proxy, las asignaciones de contenedores y los registros DNS. Si los redireccionamientos se repiten, compare los hosts virtuales HTTP y HTTPS y asegúrese de que el proxy pase el esquema original correctamente.

Utilice el puerto 80 intencionalmente. Redirija el tráfico de aplicaciones a HTTPS, evite credenciales y datos confidenciales en HTTP simple y mantenga solo los puntos finales que deben permanecer accesibles. Para sitios públicos, empareje la redirección con certificados válidos en 443 y HSTS después de confirmar que HTTPS es estable.

Registre solicitudes en el puerto 80, observe rutas inesperadas y elimine puntos finales heredados que ya no necesitan HTTP simple. Si el puerto 80 es solo para ACME o comprobaciones de estado, restrinja las respuestas a esas rutas para que sea más fácil razonar y monitorear el servicio.