Сервер не виден в списке серверов: как исправить

MAATRIX GAMES

Знакомая ситуация: сервер поднят, в консоли всё зелёное, "Done!" мелькнул, а друзья пишут "не вижу тебя в списке" или сам сервер висит серым квадратом в мультиплеере у клиента. Самое неприятное — сервер при этом может быть полностью рабочим: зайти по прямому IP получается, а вот в списке серверов (или даже просто в статусе — иконка, пинг, количество игроков) он не отображается. Разберём по шагам, где чаще всего собака зарыта, от самого простого до совсем неочевидного.

Сначала разделите две разные проблемы

Прежде чем лезть в конфиги, важно понять: у вас "не подключается" или "не виден в списке"? Это разные баги с разными причинами, и их легко перепутать.

• Не подключается вообще — клиент пишет "Connection timed out" или "Failed to connect" при попытке зайти. Тут дело почти всегда в порте или файрволе.
• Виден серым/офлайн, но подключиться можно — сервер добавлен в список (или это LAN-обнаружение), но статус не обновляется, пинг не показывается. Часто виноват enable-query.
• Не появляется в LAN-списке — это вообще отдельная история про broadcast в локальной сети, актуально только для домашних серверов без порт-форвардинга.

Дальше идём по чек-листу от причины, которая встречается чаще всего, к более редким.

Причина 1: порт не проброшен или закрыт файрволом

Это причина номер один, особенно если сервер стоит дома за роутером или на VPS с включённым файрволом по умолчанию. Java-издание слушает TCP 25565, Bedrock — UDP 19132 (это принципиально разные протоколы, спутать легко).

Сначала проверьте, что сам процесс сервера реально слушает порт на машине:

ss -tulnp | grep 25565

Если строки нет вообще — сервер не запущен на этом порту, либо упал ещё до биндинга (смотрите лог logs/latest.log), либо в server.properties стоит нестандартный server-port. Если строка есть, но адрес вида 127.0.0.1:25565 — сервер слушает только локальный интерфейс и снаружи недоступен в принципе. Нужно 0.0.0.0:25565; проверьте параметр server-ip в server.properties — если там что-то прописано вручную (например, старый внутренний IP), просто оставьте поле пустым, тогда сервер слушает все интерфейсы.

Дальше — открыт ли порт на уровне ОС. На Ubuntu/Debian с ufw:

sudo ufw allow 25565/tcp
sudo ufw status

На CentOS/AlmaLinux с firewalld:

sudo firewall-cmd --permanent --add-port=25565/tcp
sudo firewall-cmd --reload

Если сервер за домашним роутером — этого мало, нужен ещё проброс порта (port forwarding) в настройках роутера: внешний порт 25565 TCP → внутренний IP машины с сервером, порт 25565. У большинства провайдеров это раздел "Port Forwarding" или "Виртуальные серверы" в веб-морде роутера. Здесь же часто вылезает NAT-грабля: даже с правильным пробросом сервер может быть недоступен извне, если провайдер выдаёт вам "серый" IP через CGNAT — тогда проброс на своём роутере не поможет, порт физически не долетает до вашей квартиры. Проверяется просто: зайдите на whatismyip и сравните с IP на самом роутере в статусе WAN — если они разные, у вас CGNAT, и нужен либо VPN с белым IP, либо готовый арендованный сервер, где такой проблемы нет по определению.

Проверить доступность порта снаружи, не заставляя друга тестировать вслепую, можно любым онлайн-чекером портов (ищутся по запросу "port checker online") — вводите свой внешний IP и порт 25565/tcp. Если сервис пишет "closed" — проблема на уровне сети/роутера/провайдера, а не в самой игре.

Подробнее про настройку портов и файрвола с нуля — в статье про пробросы и firewall для игровых серверов.

Причина 2: неверный IP или порт в списке серверов игрока

Банально, но случается регулярно, особенно если сервер держит динамический IP (провайдер меняет его при переподключении роутера) или вы поменяли порт, а игроки добавляли сервер до этого.

Что проверить:

• Актуальный внешний IP сервера — командой curl ifconfig.me на самой машине, либо через тот же whatismyip.
• Порт в адресе указан именно тот, что в server.properties → server-port. Если порт нестандартный, в клиенте Minecraft нужно вводить его через двоеточие: 123.45.67.89:25566 — без порта клиент попробует достучаться по умолчанию на 25565 и не найдёт сервер.
• Для Bedrock-издания при добавлении сервера в список тоже нужно явно указывать порт (по умолчанию 19132), и там отдельная галка "Bedrock" при добавлении — если случайно добавили как Java-сервер, подключения не будет.
• Если используете DNS-имя (SRV-запись) вместо голого IP — убедитесь, что запись действительно указывает на актуальный IP и порт, а не на старый, оставшийся с прошлого хостинга.

Мелочь, которая тоже ловит людей: копипаст IP с лишним пробелом или точкой в конце при добавлении сервера — клиент Minecraft не всегда явно ругается, просто вечно "тайм-аут".

Причина 3: query отключён — сервер работает, но не показывает статус

Вот это самая неочевидная причина, и именно она чаще всего стоит за формулировкой "сервер работает, а в списке не виден". Дело в параметре enable-query в server.properties. Он отвечает не за возможность подключиться (это делает основной игровой протокол), а именно за то, отдаёт ли сервер статус-информацию по отдельному GameSpy-протоколу — количество игроков, версию, MOTD — сторонним инструментам мониторинга и части лаунчеров/сайтов со списками серверов.

enable-query=true
query.port=25565

По умолчанию в ванильном сервере (и во многих сборках Paper/Spigot) enable-query=false. Сам клиент Minecraft при обычном добавлении сервера в мультиплеер-список использует не query-протокол, а собственный ping-хэндшейк через основной игровой порт — поэтому для стандартного меню "Мультиплеер" в клиенте это обычно не критично. А вот если сервер должен светиться на внешних сайтах-мониторингах серверов (топ-листах, агрегаторах), большинство из них опрашивают именно через query — и без enable-query=true вы там просто не появитесь или будете показаны офлайн.

После изменения server.properties сервер нужно перезапустить (горячая перезагрузка конфига через /reload в игре не подхватывает этот параметр надёжно — лучше полный рестарт):

systemctl restart minecraft
# или, если через screen/tmux — просто stop в консоли и повторный запуск скрипта старта

Заодно проверьте, что порт из query.port (обычно совпадает с основным) тоже открыт на файрволе отдельно, если он отличается от server-port.

Причина 4: сервер ещё не до конца стартовал

При первом запуске, особенно с большим view-distance или предзаданным level-seed, генерация мира занимает время — от десятков секунд до нескольких минут в зависимости от мощности процессора хостинга и объёма спавн-чанков. Пока в логе не появилась строка вида:

[Server thread/INFO]: Done (12.483s)! For help, type "help"

— сервер физически не принимает игровые подключения, хотя порт уже может быть открыт. Некоторые клиенты в такой момент показывают именно "не виден в списке" вместо более честного "сервер запускается".

Тот же эффект бывает при большом модпаке на Forge/Fabric — там инициализация модов на старте иногда занимает 3-5 минут на слабом железе, и это нормально, не баг. Если пишете лог в файл, удобно последить в реальном времени:

tail -f logs/latest.log

Дождитесь Done, потом уже разбирайтесь с сетевыми проблемами — чтобы не чинить несуществующий баг.

Причина 5: хостинг или провайдер блокирует порт

Если всё вышеперечисленное проверено, порт слушается, файрвол ОС открыт, а снаружи всё равно "closed" — возможен блок на уровне провайдера (актуально для домашнего интернета, реже для VPS общего назначения, где иногда режут диапазоны портов по умолчанию из соображений антиспама/безопасности, особенно низкие порты вроде 25). Для 25565 это редкость, но встречается у некоторых бюджетных VPS-провайдеров или мобильного/спутникового интернета, где входящие соединения блокируются программно на уровне сети провайдера независимо от настроек вашей машины.

Проверить просто: попробуйте поднять любой другой сервис на этом же порту (например, python3 -m http.server 25565 временно) и проверить его доступность тем же онлайн-чекером портов. Если и он недоступен снаружи при полностью открытом локальном файрволе — проблема точно не в Minecraft и не в вашей настройке, а в сети провайдера или в готовых блокировках хостинга (в панели хостинга иногда есть отдельный список разрешённых портов — стоит свериться).

Здесь же стоит упомянуть облачные фаерволы (Security Groups в некоторых панелях VPS, отдельные от ufw/firewalld внутри системы) — правило может быть открыто внутри ОС, но закрыто на уровне гипервизора/панели провайдера, и тогда ss -tulnp покажет порт слушающим, а снаружи он всё равно будет недоступен. Проверяйте оба уровня.

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

Быстрый чек-лист по порядку проверки

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

1. ss -tulnp | grep <порт> — сервер вообще слушает нужный порт и не только на 127.0.0.1?
2. Открыт ли порт на файрволе ОС (ufw/firewalld) и — если сервер дома — сделан ли проброс на роутере?
3. Нет ли CGNAT у провайдера (внешний IP на whatismyip совпадает с IP на роутере)?
4. Верный ли IP:порт вводит игрок при подключении, тот ли протокол (Java/Bedrock)?
5. enable-query=true в server.properties, если нужен статус на внешних топ-листах серверов?
6. Дождались ли Done в логе после полного старта?
7. Нет ли блокировки на уровне хостинг-провайдера или облачного файрвола (Security Group)?

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