Ping проходит, а TCP timeout выглядит странно только на первый взгляд. ICMP-ответ от хоста не означает, что нужный TCP-порт открыт, что firewall пропускает соединение, что сервис слушает внешний адрес и что приложение вообще живое. ping проверяет одно, TCP-подключение проверяет другое.
Ниже короткая рабочая цепочка: сначала подтверждаем симптом, потом отделяем сетевой маршрут от фильтрации, проверяем порт с клиента, слушающий сокет на сервере и, если нужно, смотрим пакеты через tcpdump.
Почему ping может работать, а TCP нет
У ping и TCP разные протоколы и часто разные правила фильтрации. Сервер может отвечать на ICMP, но блокировать порт 443. Может быть и наоборот: ICMP закрыт, а сайт работает. Поэтому вывод «сервер пингуется» полезен, но это ещё не проверка сервиса.
pingпроверяет ICMP echo request / reply.- TCP-подключение начинается с SYN и ждёт SYN-ACK от сервера.
- Firewall может разрешать ICMP и запрещать конкретный TCP-порт.
- Сервис может слушать только
127.0.0.1, хотя сам сервер доступен по сети. - На пути может быть NAT, security group, провайдерская фильтрация или неправильный маршрут обратно.
Сначала зафиксируйте симптом
С клиентской машины проверьте ICMP и нужный TCP-порт. В примере ниже сервер пингуется, но подключение к HTTPS-порту зависает до таймаута.
ping -c 4 203.0.113.10 nc -vz -w 5 203.0.113.10 443
Если это HTTP или HTTPS, дополнительно проверьте через curl. Он покажет, зависает ли подключение на TCP, TLS или уже на HTTP-ответе.
curl -v --connect-timeout 5 https://example.com/
Разберите тип ошибки
Connection timed out— клиент отправляет SYN, но не получает понятного ответа. Часто это firewall, фильтрация по пути или обратный маршрут.Connection refused— хост ответил RST. Обычно порт закрыт или сервис не слушает.No route to host— проблема маршрутизации или локальный firewall явно сообщает о недоступности.SSL certificate problem— TCP уже установился, проблема не в доступности порта, а в TLS.HTTP 502/503— порт и веб-сервер доступны, дальше ломается backend.
Проверьте маршрут
Если TCP уходит в таймаут, посмотрите путь до сервера. Обычный traceroute использует UDP или ICMP в зависимости от системы, а это не всегда совпадает с поведением TCP-порта. Для спорных случаев используйте TCP-трассировку к нужному порту.
traceroute 203.0.113.10 traceroute -T -p 443 203.0.113.10
TCP-трассировка полезна, когда ICMP выглядит нормально, но конкретный порт не открывается. Если обычная трассировка проходит, а TCP-трассировка ломается ближе к серверу, почти всегда надо смотреть фильтрацию по порту.
Проверьте порт с другой точки
Одна клиентская машина не всегда показатель. Проверяйте с другого сервера, домашнего интернета, VPS в другом провайдере или хотя бы с самого сервера на внешний адрес. Так проще поймать фильтрацию по источнику.
nc -vz -w 5 example.com 443 nc -vz -w 5 203.0.113.10 443 curl -I --connect-timeout 5 https://example.com/
Если из одной сети порт открывается, а из другой нет, смотрите allowlist, fail2ban, security group, ACL у провайдера и гео-фильтры. Если не открывается ниоткуда, переходите на сервер.
На сервере проверьте, слушает ли сервис порт
На самом сервере сначала проверьте слушающие сокеты. Нужен не просто процесс, а правильный адрес и порт.
ss -ltnp | grep ':443'
Типовые варианты:
0.0.0.0:443— сервис слушает все IPv4-адреса.127.0.0.1:443— сервис доступен только локально.[::]:443— сервис слушает IPv6; с IPv4 поведение зависит от настроек системы.- Нет строки с портом — сервис не слушает, TCP timeout тут искать бессмысленно.
Проверьте и локальное подключение. Если локально не открывается, проблема в сервисе или его конфиге, а не в маршруте из интернета.
curl -I --connect-timeout 5 http://127.0.0.1:8080 nc -vz -w 5 127.0.0.1 8080
Проверьте firewall на сервере
Если сервис слушает внешний адрес, но снаружи таймаут, смотрите firewall. На современных Linux правила могут быть в nftables, даже если привычка тянет к iptables.
nft list ruleset iptables-save ufw status verbose firewall-cmd --list-all
Не нужно запускать всё подряд на каждом сервере. Смотрите тот инструмент, который реально используется в системе. На Ubuntu часто встречается UFW или голый nftables, на RHEL-подобных системах — firewalld.
Проверьте, доходят ли SYN-пакеты
Когда по конфигам всё выглядит нормально, включайте tcpdump. Он быстро показывает, приходит ли TCP-попытка на сервер и отвечает ли сервер обратно.
tcpdump -ni any host 198.51.100.25 and tcp port 443
Запустите команду на сервере и параллельно с клиента выполните:
nc -vz -w 5 203.0.113.10 443
Дальше смотрите картину:
- Видите SYN от клиента, но нет SYN-ACK от сервера — блокировка на сервере, сервис не слушает нужный адрес или локальная проблема с ответом.
- Видите SYN и SYN-ACK, но клиент всё равно получает timeout — возможно, ответ теряется на обратном пути.
- Видите SYN и сразу RST — порт закрыт или приложение отвергает соединение.
- Не видите SYN вообще — пакет не доходит до сервера. Ищите фильтрацию до сервера: провайдер, ACL, cloud firewall, NAT, маршрут.
Проверьте обратный маршрут
TCP требует не только входящего SYN, но и нормального ответа обратно. Иногда входящий пакет до сервера доходит, сервер отвечает, а клиент ответа не видит. Это бывает при асимметричной маршрутизации, неправильном gateway, policy routing или SNAT.
ip route get 198.51.100.25 ip rule show ip route show table all
Если на сервере несколько интерфейсов, несколько публичных адресов или VPN-туннель, обратный маршрут стоит проверить обязательно. Иначе можно долго чинить firewall, который вообще ни при чём.
Короткая таблица решений без таблицы
- Ping есть,
ncдаётrefused: хост жив, порт закрыт или сервис не слушает. - Ping есть,
ncдаётtimeout: пакет фильтруется или ответ не возвращается. ssне показывает порт: запускайте или чините сервис.ssпоказывает127.0.0.1: сервис не принимает внешние подключения напрямую.tcpdumpне видит SYN: проблема до сервера.tcpdumpвидит SYN, но нет SYN-ACK: проблема на сервере.tcpdumpвидит SYN-ACK, но клиент ждёт timeout: проверяйте обратный маршрут и фильтрацию ответа.
Полезные справки
Для редких параметров можно свериться с документацией по tcpdump, ip route и справкой curl по сетевым таймаутам: curl manpage.
Коротко
Если ping проходит, а TCP timeout, не делайте вывод, что сервер «почти работает». Проверяйте цепочку: TCP-порт с клиента, маршрут, слушающий сокет на сервере, firewall, входящие SYN через tcpdump и обратный маршрут. Обычно после этого становится понятно, где именно рвётся соединение.
[…] Ping проходит, а TCP timeout: как понять, где ломается соединен… […]
[…] Ping проходит, а TCP timeout: как понять, где ломается соединен… […]