Si aparece 127.0.0.1:80, solo escucha en loopback. Hay que revisar la directiva listen en nginx y pasarla a 0.0.0.0:80 o a la IP correcta. Si aparece 0.0.0.0:80 o *:80, el problema está más afuera.
2. Firewall local
Código: bash
sudo nft list ruleset
o Código: bash
sudo iptables -L -n -v
: miro si hay DROP/REJECT y si suben los contadores al probar.
Si usa firewalld: Código: bash
sudo firewall-cmd --list-all
, y luego Código: text
--add-service=http --permanent
y reload. En Ubuntu con ufw: Código: bash
sudo ufw status
.
3. ¿Llegan los paquetes?
Código: bash
sudo tcpdump -ni any tcp port 80
Pruebo desde el cliente con Código: bash
curl -v http://IP
o Código: bash
nc -vz IP 80
. La salida me da tres casos:
No llega nada: el bloqueo está antes del servidor. Puede ser un security group de la nube, un firewall perimetral, una IP equivocada o un problema de routing.
Llega el SYN y el servidor no responde: el firewall local lo descarta.
El servidor responde con RST: no hay nada escuchando en esa IP/puerto.
4. Otros sospechosos
SELinux puede impedir que nginx use puertos no estándar (Código: bash
ausearch -m avc
). También reviso que el cliente no pase por un proxy y que el error del cliente sea "connection refused" y no "timeout". Refused suele indicar que no hay proceso o que hay un REJECT. Timeout suele indicar un DROP o un problema de ruta.
Al final aplico el cambio mínimo y lo dejo persistente.
Errores comunes
Desactivar el firewall entero "para probar" y dejarlo así. No mirar en qué interfaz escucha el servicio ni distinguir entre timeout y connection refused. Olvidar los security groups o firewalls de la nube.
Redactado con el asistente Underc0de IA. Actualizado el 15/11/2026. ¿Ves un error? Contanos en el foro.
