Если выделенный сервер Sons of the Forest не появляется в списке или не пускает людей, причина почти всегда одна из пяти, и по симптому понятно, какая именно. В списке нет, но по адресу заходят: дело в query-порте 27016 или в LanOnly. Сервер в списке, но каждое подключение обрывается по таймауту: игровой порт 8766 или IpAddress, привязанный не к тому интерфейсу. Игрок заходит и навсегда зависает на экране загрузки: порт BlobSync 9700. Вчера работало, сегодня не пускает никого: игра обновилась, а сервер нет. Не пускает только одного человека: его пароль, версия клиента или сеть. Все три порта работают по UDP, и правило, открывающее вместо них TCP, - самый частый способ сделать всё правильно и всё равно получить отказ.
В этом руководстве каждая причина разобрана по порядку, вместе с проверками, которые их отличают. Установка, все ключи dedicatedserver.cfg и список владельцев описаны в руководстве по выделенному серверу Sons of the Forest; слоты сохранений и перенос миров - в статье настройки и сохранения Sons of the Forest. Здесь тема только одна: как провести игроков из меню в мир.
Сопоставьте симптом с причиной#
Для начала точно выясните, что именно видят игроки. Фраза "не работает" покрывает с десяток не связанных между собой неисправностей, и исправление одной ничего не даёт для остальных.
| Что видят игроки | Вероятная причина | Что проверить в первую очередь |
|---|---|---|
| Нет в списке, прямое подключение работает | Query-порт закрыт или задержка списка | UDP 27016 открыт |
| Нет в списке, прямое подключение не работает | Сервер недоступен вообще | Лог, IpAddress, все порты |
| В списке, подключение обрывается по таймауту | Игровой порт закрыт или неверная привязка | UDP 8766, IpAddress |
| Заходит, застревает на загрузке | Порт BlobSync закрыт | UDP 9700 |
| Отказ после патча | Версии клиента и сервера различаются | Запустите app_update |
| Сообщение о неверном пароле | Пароль введён или сохранён неправильно | Значение в JSON, регистр |
| Видно друзьям, но не хосту | Hairpin NAT дома | Подключайтесь по LAN-адресу |
Два быстрых теста сужают поиск лучше всего остального. Первый: может ли кто-нибудь за пределами вашей сети зайти по адресу? Если да, сервер работает, а проблема в списке, в одном клиенте или в вашей локальной сети. Второй: показывает ли лог сервера, что сетевая проверка при запуске пройдена? Если там написано, что порт закрыт, верьте логу, а не веб-странице роутера.
Три порта и что ломает каждый из них#
Sons of the Forest использует три UDP-порта, все они задаются в dedicatedserver.cfg:
{ "IpAddress": "0.0.0.0", "GamePort": 8766, "QueryPort": 27016, "BlobSyncPort": 9700}Каждый из них выходит из строя по-своему, и это удобно: закрытый порт обычно можно назвать по одному только симптому.
- `QueryPort` (`27016`) - через него мастер-сервер Steam и внутриигровой браузер видят сервер, читают его название и число игроков и измеряют пинг. Закройте его, и сервер продолжит работать и принимать прямые подключения, но в списке так и не появится. Если в списке сервер отображается без пинга или с устаревшим числом игроков, значит, query-трафик проходит с перебоями или не проходит совсем.
- `GamePort` (`8766`) - по нему идёт сама игровая сессия. Закройте его, и сервер может появиться в списке (query-порт отвечает), но нажатие на кнопку подключения закончится таймаутом.
- `BlobSyncPort` (`9700`) - по нему подключающемуся игроку передаётся состояние мира. Закройте его, и соединение установится, появится экран загрузки, но он никогда не закончится. Этот порт забывают чаще всего: у большинства игр в Steam есть только первые два, и чек-лист, скопированный для другой игры, третьего не содержит.
Все три должны быть UDP. На страницах проброса портов в домашних роутерах по умолчанию часто стоит TCP или "TCP/UDP", так что проверьте, что выбрали именно вы. Проброс 8766 по TCP для этой игры не даёт ровным счётом ничего. Если разница вам незнакома, статья TCP и UDP для игровых серверов объясняет, почему игры используют UDP и почему из-за этого сложнее тестировать.
Любой из трёх номеров можно изменить. Обычно это нужно, когда на одной машине стоит второй сервер, и тогда у двух серверов должны различаться все три порта: если у двух серверов общий порт BlobSync, именно тот, что запущен вторым, получит симптом "застрял на загрузке". Меняя порт в конфиге, меняйте и проброс, и правило брандмауэра, и всё, что вы сказали игрокам вводить, - всё сразу. Порт, изменённый в одном месте и забытый в остальных, стоит за значительной долей жалоб вида "сломалось после того, как я всё привёл в порядок". Общая картина про игровые, query- и передающие порты есть в статье порты игровых серверов, а на что на самом деле отвечает query-порт, описано в query-портах и A2S.
При запуске сервер сам проверяет доступность трёх портов и выводит результат в консоль. Неудачная проверка сообщит, какой порт он считает закрытым или что порт уже занят. "Уже занят" обычно значит, что предыдущая копия сервера так и не завершилась (упавший процесс продолжает держать порт) или что на этом номере сидит другая программа. Найдите и остановите старый процесс, прежде чем менять что-либо ещё.
IpAddress: что на самом деле делает настройка привязки#
IpAddress - это локальный адрес, на котором сервер принимает соединения. Это не тот адрес, который вводят игроки, и не ваш публичный IP.
0.0.0.0 означает все интерфейсы машины, и на домашнем ПК, на VPS или внутри контейнера нужно именно это. Ошибка, которая встречается снова и снова, - вписать сюда публичный адрес, потому что кажется, что сервер должен знать собственный адрес. На машине за роутером публичный адрес не принадлежит ни одному интерфейсу этой машины, он принадлежит роутеру, и сервер пытается слушать адрес, которого у него нет. В зависимости от сборки это либо приводит к ошибке при запуске, либо даёт сервер, который работает, но до которого никто не может достучаться.
Есть две законные причины указать что-то кроме 0.0.0.0:
- Машина с несколькими сетевыми интерфейсами, например сервер с публичной и частной сетью, где игру нужно держать на одной, а не на другой. Используйте адрес этого интерфейса в точности так, как его показывает операционная система.
- Машина с несколькими публичными адресами, где каждому игровому серверу должен принадлежать свой. Снова: адрес должен быть таким, который машина действительно имеет.
В Windows адреса машины показывает ipconfig, в Linux - ip -4 addr. Если значения из IpAddress в этом выводе нет, оно неверное. Родственная ловушка - домашний ПК, у которого LAN-адрес меняется после перезагрузки, потому что роутер выдаёт его по DHCP. Если вы привязались к 192.168.1.40, а машина теперь 192.168.1.52, сервер слушает впустую, а роутер пробрасывает порты на пустой адрес. Указывайте в конфиге 0.0.0.0 и задайте ПК резервирование DHCP в роутере, чтобы проброс всегда попадал на одну и ту же машину.
Кроме того, серверу нужен публичный адрес IPv4, чтобы зарегистрироваться в Steam. Подключение только с IPv6 или с IPv4 за провайдерским NAT (CGNAT) позволяет запустить сервер, но не позволяет внести его в список и принимать подключения. В логе будет сказано, что не удалось получить публичный адрес от Steam, либо сетевая проверка завершится неудачей сразу по всем портам. Почему игры Steam до сих пор рассчитывают на IPv4, объясняет статья IPv6 и игровые серверы.
LanOnly, hairpin NAT и тестирование из правильного места#
LanOnly, установленный в true, полностью оставляет сервер за пределами публичного интернета. Он не регистрируется в публичном списке Steam, и игроки из-за пределов вашей сети не могут подключиться. Для LAN-вечеринки это правильная настройка, для всего остального - неправильная, а поскольку сервер нормально запускается в обоих случаях, её стоит проверить раньше, чем лезть в меню роутера.
Вторая домашняя ловушка - проверка изнутри собственной сети. Большинство домашних роутеров не поддерживают hairpin NAT (его же называют NAT loopback): ПК в вашей локальной сети, подключающийся к вашему же публичному адресу, не получает маршрута обратно внутрь. В итоге друзья из другого конца города заходят без проблем, а тот, кто хостит, не может достучаться до сервера по публичному IP. Это не неисправность сервера. Хосту нужно заходить по LAN-адресу ПК с сервером, а всем остальным - по публичному.
Тот же эффект ломает и собственную самопроверку сервера. Он проверяет свой публичный адрес изнутри сети, и без поддержки hairpin эта проверка проваливается на сервере, который снаружи совершенно доступен. Это единственная веская причина поставить SkipNetworkAccessibilityTest в true: вы убедились вместе с игроком из-за пределов вашей сети, что подключение работает, а проверка по-прежнему говорит обратное. Если же включить её, чтобы заглушить непонятую проверку, вы просто спрячете сообщение об ошибке, а игроки продолжат не заходить.
Поэтому тестируйте снаружи. Подойдёт ПК друга, телефон в режиме модема на мобильном интернете с игрой на ноутбуке или сервер в другом месте, который умеет опрашивать Steam: любой из этих способов покажет правду. Машина самого сервера и всё, что находится в его локальной сети, - нет.
Хостинг дома: проброс, брандмауэры и CGNAT#
Если сервер работает на домашнем ПК, между игроками и игрой стоят три слоя, и на всех трёх должны быть открыты одни и те же три UDP-порта.
- Роутер. Пробросьте UDP
8766,27016и9700на LAN-адрес ПК с сервером. Некоторые роутеры требуют диапазон на правило; три правила по одному порту тоже подойдут. - Брандмауэр операционной системы. В Windows при первом прослушивании порта
SonsOfTheForestDS.exeбрандмауэр Защитника Windows спрашивает, разрешить ли программе доступ. Закройте это окно или отметьте только "частные сети", когда ваша сеть помечена как общедоступная, и входящий трафик будет отбрасываться молча. - Само подключение. Если ваш провайдер использует CGNAT, никакой проброс не заработает, потому что публичный адрес принадлежит не вашему роутеру.
В Windows явное входящее правило надёжнее, чем доверие к диалоговому окну. Из командной строки администратора:
$ netsh advfirewall firewall add rule name="Sons of the Forest server" dir=in action=allow protocol=UDP localport=8766,27016,9700На Linux-хосте, где сервер работает под Wine или Proton, с ufw в роли брандмауэра:
$ sudo ufw allow 8766/udp$ sudo ufw allow 27016/udp$ sudo ufw allow 9700/udpЕсли сервер работает в Docker, каждый порт нужно публиковать вместе с протоколом, например -p 9700:9700/udp. Docker по умолчанию публикует TCP, и контейнер, запущенный с -p 9700:9700, получает ту же проблему отсутствующего UDP, что и проброс в роутере, выставленный на TCP. Более широкая картина описана в статьях правила брандмауэра, которые важны и руководство по ufw.
Чтобы распознать CGNAT, сравните WAN-адрес на странице состояния роутера с адресом, который показывает сайт вроде "what is my IP". Если они различаются или WAN-адрес роутера лежит в 100.64.0.0/10, ваше подключение общее, и входящий проброс работать не может. Выход - попросить у провайдера публичный адрес IPv4 (кто-то выдаёт его по запросу, кто-то берёт деньги) или запустить сервер там, где он есть. Варианты разобраны в статье NAT и CGNAT для хостеров игровых серверов, а проброс портов или хостинг - честное сравнение борьбы с этим дома и аренды.
На арендованном сервере большая часть всего этого исчезает. На RE:NODE тарифы Sons of the Forest идут с тремя выделенными портами, которые уже открыты в интернет; ни роутера, ни брандмауэра Windows перед ними нет. Проверить нужно другое: совпадают ли три номера в dedicatedserver.cfg с выделенными портами на вкладке Network, ведь конфиг, скопированный с домашнего сервера, унесёт с собой и домашние номера портов.
Проверка снаружи: вносит ли Steam сервер в список вообще?#
Внутриигровой браузер обновляется медленно и сильно фильтрует, поэтому "нет в списке" в игре не всегда означает "не зарегистрирован". Публичный Web API Steam отвечает на этот вопрос напрямую. Подставьте публичный адрес IPv4 сервера в этот URL в любом браузере:
https://api.steampowered.com/ISteamApps/GetServersAtAddress/v1/?addr=203.0.113.25Он возвращает все игровые серверы Steam, зарегистрированные с этого адреса, вместе с портами, о которых знает Steam. Пустой список означает, что сервер не зарегистрировался в Steam: смотрите LanOnly, проблему с публичным IPv4 и лог сервера. Если же в ответе ваш сервер есть, Steam о нём знает, а игрок, который по-прежнему не видит его в игре, либо включил фильтр браузера, либо смотрит кэшированный список, либо query-порт закрыт между Steam и сервером, и браузер не может измерить пинг.
Собственный браузер серверов клиента Steam - второе мнение. В Steam откройте "Вид", затем "Игровые серверы", перейдите на вкладку "Избранное" и добавьте сервер по адресу и query-порту. Если он отвечает там с названием и пингом, query-трафик до него доходит. Это помогает отделить браузер игры от сети: если браузер Steam видит сервер, а игра нет, проблема на стороне игры, обычно это фильтр или разница версий.
Несовпадение версий после патча#
Клиент и сервер должны работать на одной сборке. Steam обновляет игру у игроков автоматически, обычно в день выхода патча. Выделенный сервер - это отдельное приложение (2465200), которое обновляется только тогда, когда кто-то запускает против него SteamCMD. Поэтому на следующий день после патча сервер остаётся на вчерашней сборке, а все, кто обновился, получают отказ, часто с сообщением, где о версиях ничего не сказано, или просто с оборвавшимся соединением.
Решение - обновить сервер и перезапустить его:
$ steamcmd +force_install_dir C:\sotf-server +login anonymous \ +app_update 2465200 validate +quitСделайте это до того, как кто-либо попытается зайти, и предварительно скопируйте сохранение: день патча - это ещё и самый вероятный день смены формата сохранений. Про validate и установки рассказывает статья SteamCMD: что это и как пользоваться, а что делать, если не удаётся само обновление, - ошибки SteamCMD и их исправление.
Бывает и обратное несовпадение. Игрок, который включил бета-ветку игры в свойствах Steam, сидит на другой сборке, чем сервер на публичной ветке. Если не может зайти ровно один человек, а остальные зашли, попросите его проверить вкладку "Беты" в свойствах игры в Steam и проверить целостность файлов. Обратная ситуация - сервер, застрявший на старой сборке, пока игроки ушли вперёд, - именно так выглядит сервер, чей скрипт запуска содержит старый аргумент -beta и тихо перестаёт принимать всех. Как это происходит, объясняет статья app id SteamCMD и бета-ветки.
Полезная привычка: когда объявлен патч, обновляйте и перезапускайте сервер в тот же день и сообщайте об этом группе. Шаги по порядку есть в чек-листе дня обновления игрового сервера, а как поручить это кому-то другому (а именно запланированной задаче) - в статье автоматизация обновлений игровых серверов.
Пароли, которые не срабатывают#
Password - это простая строка в JSON длиной до 40 символов. Пустое значение означает отсутствие пароля. С ним бывает три проблемы:
- Регистр и пробелы. Сравнение точное. Пробел в конце, попавший при вставке из сообщения в чате, становится частью пароля.
- Экранирование в JSON. Пароль с двойной кавычкой или обратной косой чертой нужно записать как
\"или\\, иначе файл перестаёт разбираться. Проще выбрать пароль без них. - Переопределение в командной строке. Любой ключ конфига можно задать в командной строке с префиксом
-dedicatedserver., и командная строка побеждает. Если панель или стартовый скрипт передаёт-dedicatedserver.Password, изменение файла ничего не даёт. Проверьте команду запуска, прежде чем решать, что сервер вас игнорирует.
Пароль применяется при каждом перезапуске, так что для смены достаточно остановить и запустить сервер, мир при этом не затрагивается. Если один игрок не может зайти с паролем, который подходит всем остальным, пусть наберёт его вручную, а не вставляет. Если не может никто, прочитайте в логе запуска строку с конфигурацией, прежде чем подозревать сеть.
Чтение лога сервера#
Вывод консоли - то место, где каждая из этих проблем заявляет о себе, и его стоит один раз прочитать сверху донизу на работающем сервере, чтобы знать, как выглядит норма. На время диагностики запускайте сервер с -verboseLogging: дополнительные подробности отличают знание от гадания. Установите LogFilesEnabled в true, если хотите, чтобы вывод ещё и записывался в файлы в папке пользовательских данных, а TimestampLogFilenames разложит каждый запуск по своему файлу.
На что смотреть, по порядку:
- Чтение конфигурации. Ошибка разбора означает некорректный JSON - лишнюю запятую в конце, "умную" кавычку, неэкранированный символ в пароле, - и сервер останавливается на этом месте. Исправьте файл и запустите заново.
- Открытие портов. Сообщение "in use" означает, что номер держит другой процесс. Остановите его или переведите этот сервер на свободные порты.
- Публичный адрес от Steam. Ошибка здесь означает, что публичного IPv4 нет: подключение только с IPv6, CGNAT или у Steam неудачный момент, и тогда стоит один раз попробовать перезапуск через несколько минут.
- Проверка сетевой доступности. Для каждого порта сообщается, доступен он или нет. Один закрытый порт прямо называет вашу проблему. Все три закрытые обычно означают, что проброс указывает не на ту машину, брандмауэр отбрасывает всё подряд или hairpin NAT ломает саму проверку.
- Подключение игроков. Пока идёт подключение, лог показывает, как оно приходит. Если подключение по игровому порту появилось, а за ним ничего не последовало, передача BlobSync не проходит.
На RE:NODE консоль показывает живой вывод сервера без фильтрации, так что сетевая проверка и каждое подключение видны по мере того, как происходят, а на вкладке Startup находятся все переопределения командной строки. Это первое место, куда стоит заглянуть, если значение из файла как будто игнорируется.
Лог раскрывает ещё одну вещь: повторные перезапуски. Сервер, который падает при загрузке, например из-за повреждённого сохранения, перезапускается, ненадолго выглядит "онлайн" и снова исчезает. Для игроков это неотличимо от сетевой проблемы. Если время работы в консоли постоянно сбрасывается, проблема в сервере, а не в портах; начать стоит со статьи почему ваш игровой сервер постоянно перезапускается.
FAQ#
Почему сервер виден друзьям, но не мне?
Вы находитесь в одной сети с сервером, а ваш роутер не заворачивает трафик к собственному публичному адресу обратно внутрь. Подключайтесь по LAN-адресу ПК с сервером. Все, кто вне вашей сети, используют публичный адрес как обычно.
Какие порты нужно пробросить для Sons of the Forest?
UDP 8766 для игры, UDP 27016 для запросов Steam и UDP 9700 для BlobSync, если вы не меняли их в dedicatedserver.cfg. Все три должны быть UDP. Из-за отсутствия третьего получается бесконечный экран загрузки.
Нужно ли вписывать мой публичный IP в IpAddress?
Нет. IpAddress - это локальный интерфейс для прослушивания, а 0.0.0.0 означает все сразу. Конкретный адрес указывайте только тогда, когда у машины их несколько и сервер нужно оставить на одном, и тогда берите адрес, который у самой машины есть.
Игроков выкинуло в меню сразу после обновления игры. Что случилось?
Их игра обновилась, а сервер нет. Остановите сервер, выполните app_update 2465200 через SteamCMD и запустите снова. Сначала сделайте резервную копию сохранения: в дни патчей форматы меняются.
Безопасно ли включать SkipNetworkAccessibilityTest?
Только после того, как кто-то вне вашей сети успешно зашёл. За NAT без поддержки loopback проверка срабатывает ложно, и тогда её пропуск допустим. Если не может зайти никто, пропуск ничего не меняет, кроме сообщения.
Можно ли запустить два сервера на одной машине?
Да, если у каждого свои три порта и своя папка пользовательских данных через -userdatapath. Два сервера с общим хотя бы одним портом (BlobSync забывают проще всего) нарушат подключение к тому, что запущен вторым.


