Игровой сервер не отвечает на пинг — общая диагностика

MAATRIX GAMES

В Discord пишут "сервер не пингуется", "не могу зайти", "в браузере серверов его нет" — а вы даже не знаете, с чего начать: то ли процесс упал, то ли порт закрыт, то ли вообще дело не в вашем сервере, а у игрока дома роутер барахлит. Этот чек-лист не привязан к конкретной игре — работает одинаково что для Minecraft, что для Rust, CS2, ARK или любой другой из полусотни игр в каталоге. Идём по уровням от простого к сложному, чтобы не тратить час на танцы с конфигом там, где хватило бы одной команды.

Что вообще значит "не отвечает на пинг"

Первое, что стоит прояснить — что именно не работает, потому что под "пингом" игроки обычно понимают три разные вещи, и лечатся они по-разному.

• Обычный ICMP-пинг (ping your.server.ip из командной строки) — проверяет только доступность хоста на сетевом уровне. Игровой сервер тут вообще ни при чём: даже полностью упавший игровой процесс не помешает хосту отвечать на ping, если сама машина жива.
• Игровой "пинг" — это то, что видит клиент игры или сайт-монитор серверов (server browser, Steam query, список серверов в лаунчере). Тут проверяется не ICMP, а ответ конкретного игрового протокола на конкретном порту — и именно это чаще всего имеют в виду игроки, когда говорят "сервер не пингуется".
• Просто не подключается — сервер может отвечать на запрос статуса (виден в браузере серверов, показывает онлайн), но при попытке зайти клиент виснет на подключении или кикает с таймаутом. Это уже другая точка отказа — часто на уровне самого игрового процесса, а не сети.

Дальше по тексту под "не отвечает" будем иметь в виду второй и третий случай — сервер не виден или не пускает игроков, — потому что именно с этим чаще всего сталкиваются админы. Если у вас буквально не идёт голый ICMP-пинг и при этом SSH тоже недоступен — это отдельная, более простая ситуация: скорее всего лёг сам хост, и стоит сразу заглянуть в статью про чек-лист диагностики при падении сервера, где разобран именно этот сценарий.

Шаг 1: жив ли процесс игрового сервера

Прежде чем разбираться с сетью, убедитесь, что вообще есть что искать в сети — процесс может быть банально не запущен.

systemctl status minecraft-server.service
# или для любого другого юнита, которым запущена ваша игра

active (running) — процесс жив, дело не в падении, идём дальше к сети. failed / inactive (dead) — сервис упал или не стартовал, и сеть тут ни при чём: сначала поднимаем сервис и смотрим лог, почему не стартует.

Если сервер запущен вручную, без systemd (через screen, tmux или nohup):

ps aux | grep java        # Minecraft
ps aux | grep srcds       # CS2 и другие Source-игры
ps aux | grep -i rust     # Rust
screen -ls
tmux ls

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

Шаг 2: слушает ли процесс нужный порт

Живой процесс не значит, что он слушает именно тот порт и протокол, который ожидает клиент — опечатка в конфиге, порт занят другим процессом или сервер вообще запустился на порту по умолчанию, а не на том, что вы прописали.

ss -tulnp

Ищите в выводе строку с вашим портом. -t — TCP, -u — UDP, -l — только слушающие сокеты, -n — порт числом, -p — имя процесса (нужен root, иначе колонка процесса пустая). Важно: убедитесь, что порт слушает именно ожидаемый процесс (java, srcds_linux, RustDedicated и т.п.), а не что-то постороннее, случайно занявшее нужный номер.

Свериться, какой порт и протокол вообще нужен конкретной игре, проще всего по её собственной документации или конфигу сборки — точные номера иногда меняются между версиями, поэтому в конфиге надёжнее, чем по памяти. Общий ориентир по типовым портам основных игр каталога:

Если порт в ss -tulnp вообще не листается — значит, сервер слушает что-то другое (проверьте конфиг: server-port в Minecraft, +port/+queryport для Source-игр, стартовые параметры для Rust) или не поднялся на сетевом интерфейсе вовсе. Если порт слушается, но именно на 127.0.0.1, а не на 0.0.0.0 или внешнем IP — снаружи он всё равно будет недоступен, хотя локально всё выглядит нормально. Это отдельная и довольно частая причина "сервер вроде запущен, а пинга нет".

Шаг 3: не режет ли трафик файрвол

Порт слушается локально, но снаружи тишина — следующий подозреваемый файрвол, причём сразу на двух возможных уровнях: внутри ОС и на уровне хостинга.

Проверка файрвола ОС:

sudo ufw status verbose
# либо
sudo iptables -L -n -v

Смотрите, есть ли явное правило ALLOW для нужного порта и протокола (TCP или UDP — перепутать их вручную легко, и это самая частая ошибка новичков). Если правила нет вовсе, а default policy на входящий трафик deny — вот и причина, добавляем правило:

sudo ufw allow 28015/udp

Подробный разбор настройки правил по каждой игре, разница TCP/UDP и типичные ошибки конфигурации разобраны в отдельной статье про настройку портов и файрвола — если после открытия порта в ufw/iptables снаружи всё равно ничего не видно, там же описано, как проверить через nmap с другой машины, что реально видно из интернета, а не что вы думаете, что открыли.

Второй уровень — файрвол самого хостинг-провайдера (Security Group, панель управления). Он существует отдельно от файрвола ОС и может резать трафик, даже если внутри системы всё разрешено. Если вы арендуете сервер у MAATRIX GAMES или другого провайдера, где игровые порты открываются автоматически при создании сервера — сначала проверьте панель управления: не были ли правила случайно изменены вручную, не истёк ли какой-то временный доступ.

Шаг 4: проблема у вас или у игрока

Если процесс жив, порт слушается, файрвол ничего не режет — а конкретный игрок всё равно жалуется на "не пингуется" — велика вероятность, что дело не на вашей стороне вообще. Проверьте это трассировкой маршрута.

С вашего сервера (или любой другой машины, не с той, что жалуется):

mtr your.server.ip
# или классический traceroute, если mtr не установлен
traceroute your.server.ip

Попросите игрока со своей стороны сделать то же самое (на Windows — tracert your.server.ip из cmd, на macOS/Linux — traceroute). Если у вас трассировка доходит чисто, а у игрока обрывается на каком-то узле задолго до вашего сервера — проблема на стороне его провайдера или домашней сети, и никакие изменения на сервере это не починят. Типичные причины на стороне игрока:

• VPN или прокси, который сам режет UDP-трафик или роутит его криво;
• домашний роутер с включённым строгим NAT, из-за которого исходящие пакеты на нестандартный порт теряются;
• антивирус или сторонний файрвол на самом компьютере игрока, блокирующий конкретный порт;
• временные проблемы у местного интернет-провайдера — не так редко, как кажется, особенно для мобильного интернета.

Если же трассировка обрывается близко к вашему серверу или прямо на входе — тогда дело всё-таки на стороне хостинга: возможно, сработала DDoS-защита провайдера (многие хостинги временно null-routят IP при аномальном трафике, что выглядит ровно как "сервер не пингуется" для всех подряд), или проблема на магистральном канале дата-центра. Разница принципиальная: в первом случае чинить нечего — сервер работает нормально, проблема у одного игрока; во втором — нужно обращаться в поддержку хостинга.

Шаг 5: если проблема массовая, а не у одного игрока

Отдельно стоит проверка, если жалуются сразу несколько игроков из разных сетей — тогда индивидуальные причины (роутер, VPN конкретного человека) можно сразу отбросить, и вероятность проблемы на вашей стороне или на стороне хостинга резко растёт.

Быстрая проверка снаружи, не полагаясь на слова игроков: онлайн-сервисы вида "check port" или сторонний VPS в другом регионе — попробуйте подключиться к игровому порту с машины, физически не связанной с вашей сетью:

nc -zvu your.server.ip 28015   # проверка UDP-порта
nc -zv your.server.ip 25565    # проверка TCP-порта

Если снаружи порт закрыт или недоступен, а внутри сервера всё выглядит нормально (процесс жив, порт слушается, файрвол ОС не режет) — почти наверняка дело в сетевом уровне хостинга: Security Group, панель провайдера или тот самый null-route после автоматического срабатывания DDoS-защиты. Для отдельных игр стоит также проверить нюансы конкретного протокола — например, для CS2 частая причина "не подключается по IP при видимом онлайне" разобрана отдельно в статье про диагностику подключения CS2 по IP, там есть специфичные для Source-движка причины, не относящиеся к общему чек-листу.

Если ни один из локальных шагов не находит причину, а внешняя проверка порта подтверждает, что снаружи он недоступен — переходим к последнему шагу.

Шаг 6: когда и что писать в поддержку хостинга

Если после всех шагов процесс жив, порт слушается, файрвол ОС чист, а снаружи сервер всё равно недоступен — дело почти наверняка на уровне сети хостинга, и дальше без доступа к их инфраструктуре не разобраться. Чтобы не тратить пару итераций переписки на "уточните детали", соберите сразу:

• IP сервера и точный порт/протокол, который не отвечает;
• время, когда проблема началась (по возможности — с точностью до минут);
• вывод traceroute/mtr с вашей стороны — видно, докуда доходит трафик;
• подтверждение, что порт слушается локально (ss -tulnp) и файрвол ОС его не блокирует — так поддержка сразу понимает, что проблема не в вашей конфигурации, и не тратит время на проверку очевидного;
• если проблема массовая — упоминание, что жалуются игроки из разных сетей/регионов, это сразу указывает на сетевой уровень хостинга, а не на локальную настройку.

Такой запрос обрабатывается заметно быстрее, чем "сервер не пингуется, помогите", потому что снимает с поддержки половину диагностики, которую вы уже сделали сами. Если история падений/недоступности повторяется без явной причины — вопрос стоит держать в переписке с указанием предыдущих обращений, это ускоряет эскалацию на уровень сетевых инженеров, если дело не решается на первой линии.

Частые вопросы