Клиенты не могут достучаться до сервиса. По захвату назовите причину и следующий шаг.
api.internal:8443 недоступен с клиента. Имя разрешается, но curl зависает. Поставьте диагноз по захвату ниже; назовите одну наиболее вероятную причину и следующую команду.
$ dig +short api.internal
10.20.4.11
$ curl -sv https://api.internal:8443
* Trying 10.20.4.11:8443...
(зависает, дальше вывода нет)
$ 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 64240В чём причина и что проверяете дальше?
SYN переотправляется, а SYN-ACK и RST не приходят — значит пакет молча отбрасывается: firewall или security group блокирует 8443, либо ничего не слушает и пакет теряется. Пришедший RST означал бы слушателя, который отказывает. Дальше: проверить правила firewall/security-group и ss -ltn на сервере.
- ✗Читать переотправленные SYN как RST (отказ), а не как молчаливый drop
- ✗Винить DNS, когда имя уже разрешилось в адрес
- ✗Не различать отсутствие ответа (drop) и RST (слушает, но отказывает)
- →Как выглядел бы захват, если бы сервер отправил RST вместо этого?
- →Почему отброшенный SYN даёт зависание, а RST — мгновенный отказ?
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.
