Отделите игрока, который не подключается к Palworld, от игрока, который входит и позднее теряет соединение. Первому нужны проверка адреса и входящего маршрута, второму — данные вокруг обрыва. Одинаковая настройка таймаута или MTU для обоих случаев может скрыть полезное различие.
Инструкция рассчитана на существующий выделенный сервер; примеры наблюдений используют Linux. Документация Pocketpair проверена 4 ноября 2026 года. Начальную схему публичного и внутреннего портов разбирает статья о слушающем и объявляемом порте. Здесь к ней добавлены попытка входа с отметкой времени, наблюдение пакетов и проверяемое исправление.
Запишите маршрут, которым действительно пользуется игрок#
Pocketpair указывает изменяемый UDP 8211 как стандартный игровой порт. Проверьте фактический сокет текущего процесса: параметр запуска может выбрать другой. Запишите адрес назначения клиента, преобразование на роутере или у провайдера, порт хоста и, при наличии контейнера, его внутренний порт.
Разделите три элемента управления:
| Параметр | Назначение | Что проверить |
|---|---|---|
-port | Слушающий игровой порт | Действующий запуск и сокет |
-publicport / PublicPort | Объявляемый адрес community-сервера | Реальное внешнее преобразование |
-publiclobby | Регистрация community-сервера | Режим списка и текущая запись |
Публичное объявление не меняет слушающий сокет. Например, внешний UDP 18211 может вести к UDP 8211 на хосте: фильтр только по 18211 внутри контейнера с портом 8211 способен пропустить нужный трафик.
Xbox и PS5 используют описанный разработчиком маршрут community-сервера. Сверьте CrossplayPlatforms, совместимые сборки клиента и сервера и запись, выбранную консолью. Успешный прямой вход Steam не подтверждает, что консоль обратилась к тому же объявленному адресу. REST и RCON для администрирования оставьте приватными: их открытие не связано с игровым UDP.
Выделите одно окно наблюдения#
Выберите одного пострадавшего игрока и одну попытку. Запишите время, часовой пояс, платформу, адрес назначения и точный отказ. Отметьте, был ли недавний перезапуск и продолжали ли играть уже подключённые люди.
Для непосредственно установленной службы systemd с именем palworld короткий исходный снимок дают команды:
date -u +'%Y-%m-%dT%H:%M:%SZ'
sudo systemctl show palworld -p MainPID -p NRestarts -p ExecStart
sudo ss -lunp 'sport = :8211'
sudo journalctl -u palworld --since '15 minutes ago' --utc --no-pager
Замените службу и порт своими. Сопоставьте именно игровой процесс, а не PID оболочки или другую установку. Храните вывод приватно, если параметры запуска содержат секреты.
Контейнеру нужны наблюдения в подходящем сетевом namespace и проверка опубликованного порта хоста. Отсутствие отдельного пользовательского слушателя на хосте само по себе не доказывает отсутствие перенаправления Docker. Сокет контейнера, в свою очередь, не подтверждает, что хост его опубликовал. Проследите обе границы до изменений.
Проследите настоящий внешний вход#
Попросите игрока из другой сети выполнить попытку: так поведение hairpin NAT не смешается с работой публичного маршрута. Pocketpair прямо описывает роутеры, которые не позволяют из той же LAN обратиться к собственному community-серверу по внешнему адресу.
При наличии права наблюдать трафик сервера запустите ограниченную проверку на нужном хосте или в нужном namespace:
sudo timeout 30 tcpdump -ni any -nn -c 80 'udp port 8211 and host 203.0.113.25'
Замените порт и учебный адрес 203.0.113.25 настоящим портом и публичным адресом пострадавшего клиента, видимым в этой точке. Туннель или преобразование может изменить этот адрес. Команда выводит метаданные, не запрашивая дамп полезной нагрузки и не создавая файл захвата. Адреса всё равно остаются приватными данными инцидента. Проверка заканчивается через тридцать секунд или восемьдесят пакетов; код timeout 124 означает окончание интервала, а не неисправность игры.
Согласуйте попытку с игроком и сопоставьте адреса и время. На хосте с bridge один пакет может попасть в any через несколько интерфейсов: повторные наблюдения ещё не означают повторные сообщения приложения. Число строк захвата не является процентом потерь. Запускайте проверку непосредственно перед согласованной попыткой. Если лимит достигнут до сбоя, окно не даёт нужного вывода: повторите с подходящим ограниченным интервалом.
| Наблюдение во время попытки | Следующая проверка |
|---|---|
| Нет подходящего пакета на ожидаемой границе | Назначение, публичный адрес, NAT, вышестоящие правила и правильность интерфейса/namespace |
| Пакет пришёл на хост, но не виден у контейнера | Публикация, политика перенаправления и настоящий порт контейнера |
| На игровой границе есть запросы и ответы, но вход не завершён | Обратное преобразование, приём клиентом и журналы версии/платформы/аутентификации |
| Игрок уже находился в мире до прекращения трафика | Время жизни процесса и прежний маршрут, включая изменения сети клиента |
Захват способен увидеть пакет до того, как его отбросит следующий обработчик firewall. Ответ на стороне сервера не доказывает получение и принятие клиентом. При возможности добавьте наблюдение у клиента; на консоли могут остаться только её ошибка и контролируемое сравнение сетей.
Выберите исправление по найденным данным#
При отсутствующем маршруте сопоставьте точное UDP-преобразование с firewall провайдера и политикой хоста. Домашнему соединению за CGNAT нужен достижимый вышестоящий маршрут: ещё одно правило только на домашнем роутере его не создаёт. Для нативного публичного VPS разрешите настроенный игровой UDP-порт в соответствующих правилах. Для контейнеров используйте документированную политику перенаправления, не предполагая, что правило UFW хоста управляет каждым опубликованным путём.
Если в тот же момент сервер перезапускается или перестаёт отвечать, сохраните сведения приложения и ресурсов. Увеличенный таймаут клиента не вернёт завершившийся процесс. При несовпадении версий или запрещённой платформе исправьте этот отказ до сетевых параметров.
Если отключается один игрок, а остальные остаются, сравните то же устройство и аккаунт через второе обычное соединение. Сборку сервера и мир сохраните прежними. Результат сужает поиск, но требует повторения: один спокойный пятиминутный тест не объясняет периодический сбой.
Проверяйте MTU как гипотезу конкретного маршрута#
Рассматривайте MTU, когда наблюдения указывают на проблему пути, особенно после появления VPN или туннеля. Запишите исходные параметры интерфейса и туннеля, сравните неисправный маршрут с рабочим. Подтверждённую проблему path MTU сначала разберите с провайдером или владельцем сети, затем выбирайте постоянное изменение интерфейса.
Linux ping проверяет ICMP echo, а не UDP-рукопожатие Palworld. tracepath может добавить данные о path MTU, но неполные ответы и другие пробы ограничивают вывод. Успешный ping не подтверждает игровой маршрут; отсутствие ответов не доказывает, что пакеты Palworld слишком велики.
Не копируйте универсальные значения MTU, глобальные UDP-таймауты, sysctl буферов или недокументированные ключи Engine.ini. Меняйте один обоснованный параметр во время обслуживания, сохраняйте прежнее значение и путь восстановления удалённого доступа. Исправление должно улучшить исходную попытку игрока, сохранив доступ работающим клиентам.
Проверьте тот же путь после изменения#
Попросите пострадавшего игрока войти в ожидаемый мир, повторить действие, при котором возникал обрыв, и подключиться заново. Если использовался список, проверьте его текущую запись. После контролируемого перезапуска ещё раз сверьте применённые настройки, адрес и мир.
Сохраните итоговую схему портов, наблюдения с временем и принятое изменение в записи сервера. Для собственных машин Nexardo помогает организовать администрирование инфраструктуры; приложите сетевые данные игры к настройкам соответствующего хоста.
Источники#
- Pocketpair: требования к игровой сети, слушающие и объявляемые параметры и поля конфигурации.
- Pocketpair: community-сервер и hairpin NAT и маршруты подключения платформ.
- Pocketpair: приватная граница REST.
- tcpdump: руководство разработчиков, Linux: проверка сокетов и фильтрация журнала.
- iputils: ICMP ping и ограничения tracepath.
