Как диагностировать отсутствие ответа от сервера при наличии IP и порта с доступом к серверу и клиенту
Что проверяют
Системность: умеете ли вы идти по уровням от сокета до приложения и различать симптомы. Доступ к обеим сторонам дан специально, ждут, что вы посмотрите трафик с двух концов. Следом спрашивают, чем «connection refused» отличается от таймаута.
Как отвечать
Сначала определите симптом с клиента: nc -vz IP PORT или curl -v.
- refused: пришёл RST. На порту никто не слушает или сработало правило REJECT;
- таймаут соединения: SYN уходит и пропадает. Обычно это DROP в файрволе, security group или маршрутизация;
- соединение есть, ответа нет: проблема выше TCP. Приложение зависло, кончился пул потоков, клиент говорит HTTP на TLS-порт или наоборот.
Дальше на сервере:
ss -ltnp: слушает ли процесс порт и на каком адресе. Частая причина: сервис привязан к127.0.0.1, а не к0.0.0.0. У слушающего сокетаRecv-Qпоказывает очередь непринятых соединений: если она растёт, приложение не успевает делатьaccept;nft list rulesetилиiptables -L -n -v: счётчики пакетов покажут, какое правило срабатывает;tcpdump -ni any port PORTодновременно на обеих сторонах: дошёл ли SYN до сервера, ушёл ли SYN-ACK, вернулся ли он клиенту. Сервер отвечает, а клиент ответа не видит? Ищите асимметричную маршрутизацию илиrp_filter;journalctl -u app.serviceиdmesg: падения, OOM, переполнение таблицы conntrack.
Если рукопожатие проходит, а большие ответы висят, проверьте MTU: ping -M do -s 1472. В Docker смотрите, опубликован ли порт и слушает ли приложение внутри контейнера на всех интерфейсах. В Kubernetes проверьте селектор Service, Endpoints и NetworkPolicy.
Где спотыкаются
Начинают с ping и делают вывод по нему. ICMP часто закрыт, и отсутствие пинга ничего не говорит о TCP-порте.
Смотрят только логи приложения. Если пакет режется файрволом, приложение о запросе не узнает и в логах будет пусто.
Не различают refused и таймаут, хотя это разные ветки поиска. Одна ведёт к процессу на сервере, другая к фильтрации по пути.