Прямое UDP-подключение к серверу Project Zomboid

Прямое UDP-подключение к серверу Project Zomboid

Источник описывает Host и выделенный сервер Build 42.19. Его значения портов, поведение Relay и UPnP и шаги брандмауэра — сведения автора, а не проведённый нами тест сети. Для конкретного сервера сначала сверяйте фактическую конфигурацию и документацию оборудования.

Когда может понадобиться перенаправление

По источнику локальная сеть по LAN IP, приглашение Steam, Use Steam Relay и арендованный сервер с уже доступными портами иногда работают без ручных правил роутера. Прямой вход друзей по публичному IP, домашний выделенный сервер или предупреждение о недоступном порте могут потребовать проверки прямого UDP-маршрута. Relay может помочь при блокировке входящего UDP, но автор отмечает возможные задержки и ограничения; предупреждение о порте само по себе не доказывает полную недоступность игры.

Порты из источника

Автор советует использовать изменённые значения из серверного INI, если они отличаются от примера. Для описанной B42.19 он не считает обязательными UDP 8766/8767 или диапазон по одному порту на игрока; рекомендации провайдера и конкретной сборки могут отличаться. Удалённый RCON не нужен для обычного игрового входа; источник советует закрыть его, если он не используется, и защитить сильным паролем, если используется.

Порядок настройки, описанный автором

1. Запустить Host или выделенный сервер и дождаться состояния готовности.
2. Сверить DefaultPort и UDPPort, в том числе в Zomboid/Server/<name>.ini при собственных значениях.
3. Обеспечить стабильный локальный адрес машины — например, резервированием DHCP на роутере или статическим адресом.
4. Для прямого входа сопоставить необходимые внешние UDP-порты с локальным IP сервера и соответствующими внутренними портами; интерфейсы роутеров различаются.
5. Проверить, что брандмауэр хоста разрешает соответствующий входящий UDP.
6. Проверить подключение с внешней сети по публичному IP и основному порту либо через Steam; если прямой маршрут не работает, автор предлагает попробовать Relay.

UPnP, локальный адрес и несколько NAT

Серверная опция UPnP, по автору, запрашивает автоматическое сопоставление на поддерживающем шлюзе. При неудаче сервер продолжает использовать настроенные порты; это не означает автоматическое переключение режима соединения. Для облачного сервера автор предлагает проверять правила провайдера, а не домашний UPnP.

Для поиска локального адреса автор упоминает IPv4 активного адаптера в ipconfig на Windows и системные настройки или ip addr / ifconfig на macOS и Linux. Адрес шлюза нужно проверять в своей сети: 192.168.1.1 и 192.168.0.1 — лишь частые примеры. Вход в административный интерфейс роутера использует его учётные данные; названия разделов могут быть Port Forwarding, Virtual Server, NAT или Gaming.

При двух домашних маршрутизаторах автор описывает режим моста либо последовательные правила от внешнего устройства к внутреннему и от внутреннего к серверу. При CGNAT или другом неподконтрольном входящем NAT правила домашнего роутера могут быть недостаточны; уточняйте топологию и возможности у провайдера. Несовпадение адресов само по себе не доказывает именно CGNAT. Автор упоминает публичный IP, туннель, другой хостинг или Relay как возможные варианты в зависимости от условий.

Открывайте только необходимые порты. Автор советует не использовать DMZ для обычного ПК и не открывать широкие диапазоны без потребности; при использовании RCON необходима отдельная защита.

Брандмауэр хоста

Роутер не компенсирует блокировку входящего трафика на серверной машине. Автор упоминает разрешение Project Zomboid / Java или входящих UDP-правил в Windows и приводит следующий пример ufw для Linux. Это иллюстрация источника; команды не выполнялись.

sudo ufw allow 16261/udp comment 'PZ DefaultPort'

sudo ufw allow 16262/udp comment 'PZ UDPPort'

sudo ufw reload

Проверка LAN и внешнего маршрута

1. Убедитесь, что серверный процесс готов и слушает настроенный порт.
2. Попробуйте подключение с другого устройства в LAN к локальному адресу и основному порту.
3. Проверьте вход с другой сети по публичному адресу и фактическому основному порту, отдельно с Relay и без него.
4. Сопоставьте попытку с серверным журналом.
5. При предупреждении о прямом порте автор предлагает проверить второй UDP-порт и повторить прямой тест.

Обычный веб-проверяльщик часто проверяет TCP или ожидает другой ответ, поэтому результат «закрыт» не доказывает состояние UDP игрового сервиса. Реальное подключение и журнал полезнее для проверки выбранного маршрута; в этой работе ни одна сеть не тестировалась.

Host, выделенный сервер и диагностика

Автор описывает In-game Host для небольших групп: хостовая машина должна работать, а при выходе хоста мир останавливается. Выделенный сервер доступен через Steam Tools или SteamCMD; его администратор отдельно отвечает за брандмауэр, копии и обновления. Для обоих источник приводит ту же пару ключей, но фактические значения следует проверять. Для управляемого Loafhosts на описанной провайдером сборке 42.21 адреса портов выдаёт панель, которая записывает их при запуске; UPnP там выключен, а RCON используется панелью. Это поведение конкретной услуги, а не правило для каждого хостинга.

Повторные ответы автора: ручной forwarding нужен не для каждой сессии; обычные игровые порты в его примере — UDP, а RCON — отдельный TCP. Стандартное открытие 8766/8767 он не рекомендует без требований конкретного стека. Описание Host / Join относится к указанной Build 42.19; TCP-проверка веб-сайтом не заменяет внешний игровой тест.

Связанные материалы

Порты и вместимость Build 42

Параметры администратора

Getting Server Info

Практика администратора