The command 'ss -tuln' shows port 80 is listening on a server, but a remote client cannot connect via HTTP. What is the most likely cause?
Firewalls commonly block ports; even if the service listens, external access may be blocked.
Why this answer
The `ss -tuln` command shows that port 80 is in the LISTEN state, which means the HTTP service (e.g., Apache or Nginx) is bound to the port and ready to accept connections. Since the server is listening but the remote client cannot connect, the most likely cause is a firewall (such as iptables, nftables, or a cloud security group) that is blocking incoming TCP SYN packets destined for port 80, preventing the three-way handshake from completing.
Exam trap
The trap here is that candidates see 'listening' on port 80 and assume the service is fully accessible, forgetting that a firewall can silently drop incoming packets even when the service is up and listening.
How to eliminate wrong answers
Option A is wrong because if the HTTP service were not running, `ss -tuln` would not show port 80 in the LISTEN state; the command output explicitly confirms the service is running. Option B is wrong because a misconfigured default gateway on the client would prevent the client from reaching any remote network, not just port 80 on this specific server; the client can likely reach other services or the server itself via other ports. Option C is wrong because the `/etc/hosts` file is used for local hostname resolution and does not affect network connectivity at the transport layer; a misconfigured hosts file would cause a DNS-like resolution failure, not a TCP connection timeout or reset.