Clients cannot reach a service. From the capture, name the fault and the next step.
api.internal:8443 is unreachable from a client. The name resolves, but curl hangs. Diagnose from the capture below; give the single most likely fault and the next command.
$ dig +short api.internal
10.20.4.11
$ curl -sv https://api.internal:8443
* Trying 10.20.4.11:8443...
(hangs, no further output)
$ sudo tcpdump -ni eth0 host 10.20.4.11 and port 8443
10:14:02.101 IP 10.20.4.30.51120 > 10.20.4.11.8443: Flags [S], seq 1, win 64240
10:14:03.104 IP 10.20.4.30.51120 > 10.20.4.11.8443: Flags [S], seq 1, win 64240
10:14:05.108 IP 10.20.4.30.51120 > 10.20.4.11.8443: Flags [S], seq 1, win 64240What is the fault, and what do you check next?
The SYN is retransmitted with no SYN-ACK and no RST, so it is being silently dropped — a firewall or security group blocks 8443, or nothing is listening and a device swallows the packet. A returning RST would instead mean a listener that refuses. Next: check the firewall/security-group rules and run ss -ltn to confirm the server listens.
- ✗Reading retransmitted SYNs as a RST (refused) rather than a silent drop
- ✗Assuming DNS is at fault when the name already resolved to an address
- ✗Not distinguishing no-reply (dropped) from a RST (listening but refusing)
- →How would the capture look different if the server sent a RST instead?
- →Why does a dropped SYN cause a hang while a RST causes an instant failure?
The capture is the whole answer. The client sends a SYN, gets no SYN-ACK and no RST, and retransmits on the TCP backoff schedule (~1 s, 2 s, …). A packet that leaves and is never answered is being silently dropped — the two usual causes are a firewall / cloud security group blocking inbound 8443, or nothing is listening on 10.20.4.11:8443 and an in-path device drops the SYN instead of returning a reset.
The key contrast: if a service were listening but refusing (wrong bind, backlog full), you would see a SYN-ACK or a RST come back and curl would fail instantly, not hang. No reply at all is the fingerprint of a drop.
Next steps, cheapest first:
# On the server: is anything actually listening on 8443?
$ ss -ltn '( sport = :8443 )'
State Recv-Q Send-Q Local Address:Port
LISTEN 0 511 0.0.0.0:8443 # listening → suspect the firewall/SG
# From the client: does a plain TCP connect also hang (rules out TLS)?
$ nc -vz -w3 10.20.4.11 8443
nc: connect to 10.20.4.11 port 8443 (tcp) timed out: Operation now in progressIf ss shows a listener, the drop is in the path: open 8443 in the security group / host firewall. If ss shows nothing, the app is not bound — fix the service. A timed-out nc (not "refused") confirms a drop rather than a reset.
