Valheim: проблема с проброшенным портом сервера

MAATRIX GAMES

Сервер Valheim запущен, в консоли мелькнуло Game server connected, а друзья пишут "не вижу тебя в списке" или подключение виснет на "Connecting..." и обрывается таймаутом. Знакомая история почти для каждого, кто хоть раз поднимал dedicated-сервер сам — и в девяти случаях из десяти дело именно в портах: либо они не открыты там, где вы думаете, либо открыты не полностью. Разберём диагностику по шагам, без гадания, и отдельно — чем отличается ситуация на VPS от домашнего сервера за роутером.

Три порта, а не один — и это часто забывают

Valheim слушает не единственный порт, а сразу три подряд, начиная с того, что указан в параметре -port при запуске:

Все три — UDP, не TCP. Это первая частая ошибка: кто-то по привычке из других игр открывает TCP или открывает оба протокола "на всякий случай", а реальный трафик Valheim идёт исключительно по UDP. Открытый TCP-порт с тем же номером никак не поможет — игра его просто не слушает.

Вторая ошибка — открыть только 2456 и решить, что этого достаточно, потому что "порт же основной". Для прямого подключения по IP этого иногда хватает, но сервер не появится в общем списке (браузере серверов) без открытого 2457 — именно по нему клиент опрашивает статус и список публичных серверов.

Шаг 1: убедитесь, что сервер вообще слушает порты

Прежде чем разбираться с файрволом или роутером, проверьте изнутри сервера, что процесс valheim_server реально открыл нужные порты:

ss -ulnp | grep valheim

Ожидаемый вывод — три строки с портами 2456, 2457, 2458 в состоянии UNCONN (нормальное состояние для UDP-сокета) и именем процесса valheim_server. Если строк меньше трёх или нет вообще ни одной — проблема не в сети, а в самом сервере: либо он ещё не дописал загрузку мира (проверьте journalctl -u valheim -f на строку Game server connected), либо -port в стартовых параметрах указывает не тот номер, который вы проверяете.

Частый нюанс: если запускали сервер вручную в терминале без прав root, ss -ulnp без sudo не покажет имя процесса (колонка будет пустой), но сам факт, что порт слушается — увидите. Для точной привязки к процессу используйте sudo ss -ulnp.

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

Шаг 2: проверьте файрвол на самом сервере

Даже если процесс слушает порт, файрвол ОС может резать входящий трафик до того, как он дойдёт до приложения. На Ubuntu/Debian с ufw:

sudo ufw status verbose

В выводе должна быть строка вида 2456:2458/udp ALLOW Anywhere. Если её нет — добавляем:

sudo ufw allow 2456:2458/udp
sudo ufw reload

Если правило есть, но проблема сохраняется, — стоит перепроверить, не задваиваются ли правила ufw и "голого" iptables, если когда-то трогали оба вручную (в этом случае реальную картину покажет только iptables -L -n целиком). Подробный разбор настройки firewall для игровых серверов, включая типичные грабли с диапазонами и проверкой через nmap, — в статье про настройку портов и файрвола.

Проверка снаружи — с другого компьютера, не с самого сервера:

nmap -sU -p 2456-2458 your.server.ip

Учтите: сканирование UDP через nmap работает медленнее и менее надёжно, чем TCP (UDP-протокол не обязан отвечать на "пустой" пакет), поэтому статус open|filtered для UDP-портов — это нормально и не всегда означает проблему. Куда надёжнее содержательная проверка — реальная попытка подключения клиентом или через Steam Server Browser (см. ниже).

VPS: порты обычно уже открыты, но не всегда

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

У многих VPS-провайдеров есть панель управления с собственными Security Groups или облачным файрволом на уровне сети — и если там правила не совпадают с ufw/iptables внутри системы, пакеты срежутся ещё до того, как дойдут до сервера, а ufw status изнутри будет невозмутимо показывать, что всё открыто. Проверить это можно только снаружи (nmap с другой машины) или в панели хостинга — ищите разделы вроде "Firewall", "Security Groups" или "Network Rules".

На серверах MAATRIX GAMES для тарифов Valheim порты 2456-2458/UDP открываются автоматически при деплое — этот шаг можно пропустить полностью, что снимает как минимум половину типичных проблем из этой статьи. Если сервер арендован не у нас, а порты всё равно "не видны" при том, что ufw и процесс в порядке — почти наверняка дело именно в сетевом файрволе провайдера, пишите в поддержку хостинга с прямым вопросом про правила на портах 2456-2458 UDP.

Ещё одна деталь именно для VPS: если сервер стоит за отдельным облачным firewall-продуктом (не путать с обычным файрволом ОС) с whitelist по IP — такой режим для публичного игрового сервера не подходит в принципе, поскольку список игроков заранее не известен. Такую настройку стоит явно отключать или переводить в режим "разрешить всем" именно для игровых портов.

Домашний сервер: NAT и проброс на роутере

Если сервер поднят на домашнем ПК, а не на VPS, добавляется ещё один обязательный уровень — проброс портов (port forwarding) на роутере, отдельно от файрвола самой машины. Логика: провайдер выдаёт вам один "внешний" IP на роутер, а компьютер с сервером сидит за NAT на локальном адресе вроде 192.168.1.x — без явного правила на роутере входящие пакеты извне просто не знают, к какой машине в локальной сети их доставить, и роутер их отбрасывает.

Общий порядок действий (конкретные пункты меню отличаются у разных производителей роутеров):

1. Зайдите в веб-интерфейс роутера (обычно 192.168.1.1 или 192.168.0.1, логин/пароль — на наклейке снизу устройства).
2. Найдите раздел "Port Forwarding" / "Виртуальные серверы" / "NAT" — называется по-разному в зависимости от прошивки.
3. Добавьте три правила (или одно с диапазоном, если интерфейс это позволяет): порты 2456-2458, протокол UDP, внутренний IP — локальный адрес компьютера с сервером.
4. Желательно закрепить локальный IP компьютера через DHCP-резервацию в том же роутере — иначе после перезагрузки роутер может выдать машине другой локальный адрес, и правило проброса перестанет работать без видимой причины.

Если проброс настроен правильно, а сервер всё равно не виден снаружи — велика вероятность CGNAT (Carrier-Grade NAT), когда сам провайдер выдаёт вам не настоящий публичный IP, а адрес за собственным NAT-слоем провайдера. В этом случае проброс портов на вашем роутере бессилен в принципе — пакеты извне даже не доходят до вашего роутера, они упираются в оборудование провайдера раньше. Признак CGNAT: внешний IP, который показывает ваш роутер, отличается от IP, который показывают сервисы вроде "какой у меня IP" в браузере на устройстве в этой же сети. В этой ситуации реального решения два: просить у провайдера отдельный публичный IP (не у всех есть такая опция и часто она платная), либо переносить сервер на VPS — там белый IP есть по умолчанию, без переговоров с провайдером.

Домашний сервер удобен для разовой игры вечером с друзьями, но для стабильной группы, которая играет регулярно, не зависящий от того, включён ли ваш ПК и не легла ли домашняя сеть, вариант с VPS в итоге экономит куда больше нервов — сравнение по шагам разворачивания есть в статье как поднять сервер Valheim.

Проверка через Steam Server Browser

Отдельный полезный инструмент диагностики — встроенный в Steam браузер серверов, доступен независимо от того, запущен ли клиент Valheim:

1. Откройте Steam → меню View → Servers (или Просмотр → Серверы).
2. Вкладка Favorites — добавьте сервер вручную кнопкой "Add a Server" по адресу IP:2456.
3. Если сервер появляется в списке с корректным пингом и именем — query-порт 2457 работает, и проблема была на стороне клиента или в файрволе конкретного игрока, а не сервера.
4. Если сервер не появляется даже после ручного добавления по IP — проблема на стороне сервера: либо не открыт 2457, либо сетевой файрвол хостера/роутера режет трафик раньше.

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

Проверка "изнутри игры" даёт неполную картину

Соблазн проверить всё через сам клиент Valheim — зайти в меню, попробовать подключиться по IP и решить, что раз получилось, значит всё в порядке. Проблема в том, что подключение по прямому IP использует только основной порт 2456 — если проблема именно в query-порте 2457 (сервер не появляется в публичном списке, но по IP подключиться можно), такая проверка её не покажет и создаст ложное ощущение, что всё работает.

Правильная последовательность диагностики — сначала ss -ulnp на самом сервере (слушает ли процесс все три порта), затем nmap -sU или Steam Server Browser снаружи (видны ли порты из интернета), и только потом — попытка реального подключения клиентом. Если менять что-то в файрволе или на роутере и сразу проверять только последним шагом, легко упустить, что часть портов так и осталась закрытой, просто симптом (сервер не виден в общем списке) не так заметен, как полный отказ подключения.

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