Сайт проверки портов пишет «закрыт», хотя сервер запущен. Прежде чем менять firewall, выясните, проверял ли инструмент UDP. Подключение по TCP к порту 8211 ничего не говорит о UDP-сокете с таким же номером. Даже настоящий UDP-запрос может остаться без ответа от работающей игры, если содержимое пакета не соответствует её протоколу.
Ниже — диагностика на Linux. UDP 8211 используется как пример, а не общий порт всех игр: подставьте фактическое значение своей установки. Нужны запущенный сервер, его игровые и query-порты, административный доступ и клиент за пределами серверной сети. Если iproute2 или tcpdump отсутствуют, установите их пакетным менеджером дистрибутива. Nmap на внешней тестовой машине нужен только для дополнительной проверки.
Запишите адрес и вопрос, на который отвечает проверка#
Зафиксируйте адрес назначения, IPv4 или IPv6, номер порта, протокол и назначение. Игровой порт, query-порт браузера и RCON могут использовать разные протоколы и правила доступа. Оставляйте администрирование закрытым от публики: открытый RCON не исправит маршрут игрового UDP.
Разделите вопросы: есть ли сокет у процесса, доходят ли внешние запросы, отвечает ли приложение и входит ли игрок на сервер? Для каждого требуется своё подтверждение. Если используется доменное имя, добавляется DNS: сначала выясните, какой адрес действительно получает клиент, иначе будете сравнивать запросы к разным узлам.
В историческом обсуждении на форуме Unity автор подтвердил, что друг подключился, хотя TCP-проверка продолжала показывать закрытый порт. Это пример неподходящего инструмента, а не основание игнорировать реальные отказы подключения.
Проверьте сокет там, где работает игра#
Для обычного процесса Linux посмотрите соответствующие UDP-сокеты:
sudo ss -uanp 'sport = :8211'
Документация iproute2 описывает параметры UDP, числовых адресов, всех сокетов и процессов. Сверьте процесс и локальный адрес с нужным экземпляром сервера. Привязка IPv4 к 127.0.0.1 не принимает прямое подключение извне. 0.0.0.0 означает привязку ко всем IPv4-интерфейсам, а не адрес, который нужно сообщать игрокам. Состояние UDP UNCONN нормально для несоединённого датаграммного сокета и само по себе не означает ошибку запуска.
Если в сетевом пространстве приложения нужного сокета нет, проверьте готовность игры, другой порт и ошибку привязки в журнале. Правило на роутере не создаст сокет вместо ещё не запустившегося сервера.
В контейнере проверяйте сокет внутри сетевого пространства приложения, а публикацию порта — отдельно. Одного ss на хосте недостаточно, когда перенаправление реализовано NAT без отдельного процесса-прокси. Документация Docker различает TCP и UDP: публикация номера для TCP не публикует UDP с тем же номером. Виртуальная машина тоже добавляет собственную сетевую границу и firewall.
Отправьте настоящий запрос из другой сети#
Попросите игрока с другого интернет-подключения использовать совместимый клиент либо запустите query-инструмент для реального протокола сервера. Запишите время попытки и результат. Ответ на query подтверждает работу этого адреса и порта; возможность входа в игру подтверждается самим входом.
Дополнительно на внешней Linux-машине под вашим управлением можно проверить один UDP-порт собственного сервера:
sudo nmap -sU -Pn -p 8211 --reason 203.0.113.10
Вместо 203.0.113.10 укажите настоящий IPv4: в примере зарезервированный адрес для документации. Параметр -Pn пропускает предварительное определение доступности узла, поэтому блокировка ping не отменит проверку этого порта.
По описанию UDP в Nmap, open|filtered означает отсутствие решающего ответа, а не доказанную неисправность. Полученный ICMP port-unreachable позволяет отметить closed для этой попытки; отдельно выясните, какое устройство отправило сообщение. Даже open не доказывает успешную игровую сессию. Проверяйте конкретный порт: тысячи запросов с ожиданием таймаута не заменят вход игрока.
Посмотрите направление пакетов во время входа#
На Linux-хосте запустите короткое наблюдение, пока внешний игрок пытается подключиться:
sudo timeout 20s tcpdump -i any -nn -c 40 'udp port 8211'
Параметры из документации tcpdump отключают разрешение имён и ограничивают наблюдение. Команда завершится после 40 пакетов или 20 секунд. Если раньше сработал лимит времени, код завершения timeout ожидаем. Вывод содержимого пакетов не запрашивается. Но адреса в строках остаются: перед передачей другим людям удалите ненужные данные.
Интерпретируйте результат с учётом места захвата:
| Наблюдение во время известной попытки | Следующая проверка |
|---|---|
| Входящих пакетов нет | Адрес назначения, внешний firewall, проброс, вышестоящий NAT; также пространство и фильтр захвата. |
| Запросы приходят, ответов нет | Фильтры хоста, привязка сокета, готовность игры и корректность игрового запроса. |
| Запросы и ответы уходят с хоста | Обратный маршрут, внешние фильтры, сеть клиента и совместимость игры. |
| Игрок вошёл в нужный мир | Повторный вход после окончательного изменения правил и проверка сообщаемого адреса. |
Пакет на интерфейсе хоста ещё не доказывает доставку сокету приложения. Для контейнеров и трансляции номеров дополнительно проверьте нужное сетевое пространство и преобразованный порт. На any один пакет может встретиться на нескольких интерфейсах: повторяющиеся строки сами по себе не означают повторную отправку игры.
Исправьте ту границу, на которую указывают данные#
Измените неверное UDP-сопоставление, адрес привязки или конкретное правило firewall, затем повторите тот же внешний вход. Не отключайте все фильтры и не открывайте широкий диапазон портов: так легко потерять диагностические ориентиры и выставить наружу посторонний сервис.
Если до домашнего сервера ничего не доходит, сравните WAN и внешний IPv4 по инструкции о CGNAT. Для обращения за помощью сохраните адрес и протокол, время попытки, результат проверки сокета и направление пакетов. Это позволяет выбрать следующую проверку гораздо точнее, чем единственная надпись «порт закрыт».
