Пинг есть, а сайта нет: диагностика недоступного веб-сервера

Почему пинг проходит, а сайт недоступен: диагностика и решение проблемы с недоступным веб-сервером

Сценарий: вы можете успешно пинговать удалённый хост (ping dix.lan работает), но при этом браузер или curl не могут получить доступ к веб-сайту на этом же хосте. Что происходит — и как это исправить?

В этой статье мы разберём реальный пример подобной ситуации, покажем пошаговую диагностику и объясним, почему так происходит даже при полностью работающем веб-сервере.

? Симптомы проблемы

Выполняем с клиентской машины (хоста):

☯

Terminal:

⌕

≡

✕

$ ping dix.lan
PING dix.lan (192.168.122.76) 56(84) bytes of data.
64 bytes from debian (192.168.122.76): icmp_seq=1 ttl=64 time=0.344 ms
...

→ Пинг работает. Значит, хост в сети, маршрутизация есть, сетевой стек отвечает.

Теперь пробуем HTTP:

☯

Terminal:

⌕

≡

✕

$ curl http://dix.lan
# ... ничего не происходит, команда зависает

Или:

☯

Terminal:

⌕

≡

✕

$ telnet dix.lan 80
Trying 192.168.122.76...
# ... тоже зависает

А вот если зайти по SSH на сам сервер и выполнить тот же запрос локально:

☯

Terminal:

⌕

≡

✕

root@debian:~# curl http://dix.lan
<!DOCTYPE html><html>...<h1>Welcome to nginx!</h1>...</html>

→ Всё работает отлично!

Получается:

✅ Сервер жив

✅ Nginx запущен

✅ Локально всё отвечает

❌ Но извне — нет доступа к порту 80

? Шаг 1: Убедиться, что веб-сервер слушает на всех интерфейсах

Проверяем, на каких адресах слушает Nginx:

☯

Terminal:

⌕

≡

✕

root@debian:~# ss -tuln | grep ':80'
tcp   LISTEN 0 511 0.0.0.0:80 0.0.0.0:*
tcp   LISTEN 0 511 [::]:80    [::]:*

→ Отлично! Сервер слушает на всех IPv4 и IPv6 интерфейсах, а не только на 127.0.0.1.

Вывод: проблема не в конфигурации Nginx.

? Шаг 2: Проверить, открыт ли порт 80 извне

С клиентской машины проверяем соединение на уровне TCP:

☯

Terminal:

⌕

≡

✕

$ nc -vz dix.lan 80
Ncat: Version 7.93 ( https://nmap.org/ncat )
# ... и ничего больше — команда зависает

Если бы порт был открыт, мы увидели бы:

☯

Terminal:

⌕

≡

✕

Ncat: Connected to 192.168.122.76:80.

Если бы порт был закрыт (например, сервис не слушает), было бы:

☯

Terminal:

⌕

≡

✕

Ncat: Connection refused.

Но зависание означает: пакет никогда не доходит до сервера или ответ не возвращается. Это классический признак фаервола, который молча отбрасывает входящие SYN-пакеты.

? Шаг 3: Анализ правил фаервола на сервере

На сервере выполняем:

☯

Terminal:

⌕

≡

✕

sudo iptables -L -n
# или (в новых Debian):
sudo nft list ruleset

Ключевые наблюдения:

Политика цепочки INPUT — DROP (всё, что не разрешено явно, блокируется).
ICMP (ping) разрешён в цепочке ufw-before-input.
В цепочке ufw-user-input разрешены только порты: - 22 (SSH) - 8443 - 4000

☯

Terminal:

⌕

≡

✕

...
        chain ufw-user-input {
                tcp dport 22 counter packets 1 bytes 60 accept
                tcp dport 8443 counter packets 0 bytes 0 accept
                tcp dport 4000 counter packets 0 bytes 0 accept
        }
...

⚠️ Порт 80 отсутствует!

Это и есть причина: UFW (Uncomplicated Firewall) блокирует весь входящий трафик, кроме явно разрешённых портов. Ping работает, потому что ICMP разрешён отдельно. А HTTP — нет.

✅ Решение: разрешить порт 80 в UFW

Выполняем на сервере:

☯

Terminal:

⌕

≡

✕

sudo ufw allow 80/tcp

Проверяем статус:

☯

Terminal:

⌕

≡

✕

sudo ufw status verbose

Вывод должен включать:

☯

Terminal:

⌕

≡

✕

80/tcp                     ALLOW IN    Anywhere

Теперь с клиентской машины:

☯

Terminal:

⌕

≡

✕

$ curl http://dix.lan
<!DOCTYPE html><html>...<h1>Welcome to nginx!</h1>...</html>

→ Работает!

?️ Общая методика диагностики подобных проблем

Если у вас пинг есть, а сайт нет, следуйте этому чек-листу:

Шаг	Действие	Цель
1	`ping <адрес>`	Убедиться, что хост в сети
2	`curl` / `telnet` / `nc` к порту (например, 80)	Проверить доступность TCP-порта
3	На сервере: `ss -tuln \| grep :80`	Убедиться, что сервис слушает на `0.0.0.0`, а не `127.0.0.1`
4	На сервере: `sudo ufw status` или `iptables -L -n`	Проверить, разрешён ли порт во входящих правилах
5	При необходимости: `sudo ufw allow 80/tcp`	Открыть порт
6	Повторить проверку с клиента	Убедиться, что проблема решена

? Почему именно так происходит?

ICMP и TCP — разные протоколы. Фаервол может разрешать один и блокировать другой.
UFW по умолчанию блокирует всё входящее, если не настроен иначе.
Зависание (а не "Connection refused") — главный индикатор фаервола, а не остановленного сервиса.

? Заключение

Проблема «пинг есть, сайт нет» — очень распространена в средах с активным фаерволом (особенно UFW, firewalld, iptables). Она не связана с веб-сервером, а вызвана сетевой политикой безопасности.

Главное — помнить:

Доступность хоста ≠ доступность сервиса.

Следуя простому алгоритму диагностики, вы быстро найдёте и устраните подобную проблему в любой Linux-системе.

ℹ️ Совет: всегда после установки веб-сервера (nginx, Apache и т.п.) проверяйте, открыт ли нужный порт в фаерволе. Это сэкономит часы отладки!

Создано 15.01.2026 15:15:39
Roman Sakhno

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

itDid

Пинг есть, а сайта нет: диагностика недоступного веб-сервера

? Симптомы проблемы

Terminal:

✕

Terminal:

✕

Terminal:

✕

Terminal:

✕

? Шаг 1: Убедиться, что веб-сервер слушает на всех интерфейсах

Terminal:

✕

? Шаг 2: Проверить, открыт ли порт 80 извне

Terminal:

✕

Terminal:

✕

Terminal:

✕

? Шаг 3: Анализ правил фаервола на сервере

Terminal:

✕

Terminal:

✕

✅ Решение: разрешить порт 80 в UFW

Terminal:

✕

Terminal:

✕

Terminal:

✕

Terminal:

✕

?️ Общая методика диагностики подобных проблем

? Почему именно так происходит?

? Заключение

Комментарии (0):