Starting with “the firewall must be broken” can make a failed web connection harder to diagnose. Name resolution, the destination address, the network path, the port, and the server process all have to line up. Narrow down the failure one boundary at a time.
Identify the destination and port first
DNS resolves to destination 203.0.113.10, and the client connects on TCP port 443. 0.0.0.0:443 shows a server listening on all local IPv4 interfaces; it is not a destination address for the client. The arrows show what to check, not a guarantee that the connection or application response succeeds.
Check which IP address the URL's host resolves to and which port the client actually contacts. The default HTTPS port may differ from an application's port, and a load balancer and its backend can use different ports.
Check whether the server is listening
Confirm that the server process is running and bound to the expected address and port. A service bound only to loopback can work on the server itself but remain unreachable from outside. Inspect logs and binding state before restarting the process so you do not lose clues about a configuration error.
python3 -m http.server 8000 --bind 127.0.0.1
# In another terminal
ss -ltn
curl --max-time 3 -I http://127.0.0.1:8000/
curl --max-time 3 -I http://127.0.0.1:8001/In this example, port 8000 should return a local HTTP response, while port 8001 should fail because no process is listening there. The same IP can therefore give different results on different ports. On Linux, 127.0.0.1:8000 under Local Address in ss means the service is bound only to loopback. If port 8000 also fails, check the process and port configuration. If local access works but remote access fails, move the diagnosis to firewall, security-group, and load-balancer boundaries.
Check allow rules at each boundary
The server's operating-system firewall, a cloud security group or NSG, network ACLs, and load-balancer rules are separate boundaries. Allow only the required source, protocol, and port; do not open every IP and port just to make a test pass. When there is no response, use logs and connection tests to see how far the request got.
Key takeaways
A failed connection may involve more than one IP or port. Check name resolution, the destination address, server listening state, and network-boundary rules in order. Keep access rules narrow and use observations to choose the next hypothesis.
