Не подключается по IP: диагностика

MAATRIX GAMES

Поднял сервер CS2, скопировал IP из панели, вбил connect в консоль — и тишина. Или того хуже: друзья пишут «не могу зайти», а у тебя локально всё летает. Это одна из самых частых проблем новичков, и в 90% случаев причина банальная — просто её не видно, пока не проверишь по порядку. Разберём диагностику снизу вверх: от «сервер вообще жив» до «провайдер режет порты».

Шаг 1: сервер реально запущен и слушает порт

Первым делом — не гадать, а посмотреть в лог. Если сервер запущен как systemd-сервис или в screen/tmux, подключись и глянь последние строки:

journalctl -u cs2server -n 50 --no-pager
# или, если запуск через screen
screen -r cs2

В логе должна быть строка вида:

Setting breakpad minidump AppID = 730
Network: IP xxx.xxx.xxx.xxx, mode MP, dedicated Yes, ports 27015 SV / 27005 CL

Если сервер завис на загрузке карты, вылетел с ошибкой (Host_Error, недостача памяти, битые файлы workshop) или процесс вообще не запущен — искать проблему в портах ещё рано, сначала почини сам процесс. Про разбор крашей и логов у нас есть отдельный разбор: логи и краш-репорты — как читать и искать причину.

Быстрая проверка, что процесс жив и слушает нужный порт, прямо на сервере:

ss -tulnp | grep 27015

Если строки нет вообще — сервер либо не поднялся, либо слушает другой порт (например, ты менял -port в параметрах запуска). Проверь строку запуска:

ps aux | grep cs2

и обрати внимание на флаг -port 27015 (или другой номер, если задавал вручную).

Шаг 2: порты открыты именно те, что нужны

CS2 (движок Source 2) слушает не один порт, а диапазон. Стандартная схема:

Если у тебя сервер в MAATRIX GAMES или другом хостинге с готовым панельным деплоем — порты обычно уже проброшены автоматически на уровне хостинга, и этот шаг можно пропустить. А вот если сервер стоит на своей VPS или домашнем железе за роутером — придётся пробрасывать руками.

На Linux с ufw:

sudo ufw allow 27015/tcp
sudo ufw allow 27015/udp
sudo ufw allow 27020/udp
sudo ufw status

На iptables напрямую:

sudo iptables -A INPUT -p udp --dport 27015 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 27015 -j ACCEPT

Если сервер физически дома за NAT-роутером — проброс портов (port forwarding) нужен ещё и на самом роутере, в его админке (обычно раздел «Переадресация портов» / Port Forwarding / Virtual Server). Без этого шага файрвол ОС можно открыть хоть настежь — снаружи всё равно не достучаться, потому что пакеты не доходят до машины вообще.

Подробнее про общую логику настройки портов и файрвола для игровых серверов — в отдельной статье: настройка портов и файрвола для игрового сервера.

Проверить снаружи, что порт реально открыт (с другого устройства, не с самого сервера), можно любым онлайн-чекером портов — вбиваешь IP и порт 27015, протокол UDP. Учти: UDP-чекеры менее надёжны, чем TCP, потому что UDP не даёт гарантированного ответа «закрыто» — иногда сервис просто пишет «нет ответа», хотя порт открыт, а сервис CS2 на нём молчит.

Шаг 3: правильный синтаксис connect в консоли

Частая ошибка новичков — не в портах, а в том, как вводится команда. Открой консоль клиента (` `` по умолчанию, если консоль включена в настройках — Options → Game → Enable Developer Console) и введи:

connect XXX.XXX.XXX.XXX:27015

Обрати внимание:

• IP и порт разделены двоеточием :, без пробелов.
• Если порт стандартный (27015), его можно не указывать — connect IP тоже сработает, CS2 сам подставит 27015. Но если сервер поднят на нестандартном порту (например, 27016, потому что 27015 занят вторым сервером на той же машине), порт указывать обязательно.
• Никаких http://, steam:// или кавычек — просто IP:порт.
• Если IP или пароль сервера скопирован с лишним пробелом в конце (частая история при копировании из панели или чата) — команда молча не сработает. Перепечатай вручную, если есть сомнения.

Если сервер защищён паролем:

password ВАШПАРОЛЬ
connect XXX.XXX.XXX.XXX:27015

или одной строкой:

connect XXX.XXX.XXX.XXX:27015; password ВАШПАРОЛЬ

Через +connect можно подключаться сразу при запуске игры (ярлык или параметры запуска в Steam):

-connect XXX.XXX.XXX.XXX:27015

Шаг 4: локальный LAN vs подключение через интернет — не путай два разных теста

Вот тут больше всего путаницы. Если ты тестируешь сервер с той же машины или того же домашнего роутера, где он крутится, и коннект по локальному/белому IP срабатывает — это НЕ доказывает, что сервер доступен из интернета. Локальная сеть и NAT-loopback (hairpin NAT) на многих роутерах ведут себя иначе, чем реальный внешний трафик.

Правильная схема проверки:

1. С той же сети, где стоит сервер: подключайся по локальному IP (192.168.x.x или что выдал DHCP) — так ты проверяешь, что процесс вообще жив.
2. Извне, с другого интернет-канала (мобильный интернет, друг из другого города, VPN на другую точку): подключайся по внешнему белому IP. Это и есть настоящая проверка «доступен ли сервер игрокам».

Если шаг 1 работает, а шаг 2 — нет, проблема почти гарантированно в проброшенных портах (см. шаг 2) или в блокировке провайдера (шаг 6), а не в самом сервере.

Отдельно: если сервер арендован в дата-центре (VPS/выделенный сервер у хостинга), а не стоит у тебя дома — у него обычно нет NAT вообще, машина сразу торчит белым IP в интернет, и тогда шаг 1 и шаг 2 по сути совпадают. Путаница локалка/интернет актуальна в первую очередь для тех, кто держит сервер на домашнем железе.

Шаг 5: sv_lan — тихий убийца внешних подключений

Один параметр способен свести на нет всю настройку портов. sv_lan определяет, в каком режиме сервер объявляет себя сети:

• sv_lan 0 — сервер в режиме интернет-сервера, доступен извне, может (если включено) публиковаться в списке серверов Steam.
• sv_lan 1 — сервер только для локальной сети, снаружи он для клиентов фактически невидим, даже если порты открыты.

Проверить текущее значение прямо в консоли сервера:

sv_lan

Если стоит 1, а тебе нужен доступ извне — выставляй 0:

sv_lan 0

Часто параметр прописан в стартовом конфиге (server.cfg или в параметрах запуска через +sv_lan 0/+sv_lan 1). Проверь файл запуска и server.cfg в папке game/csgo/cfg/ (структура CS2 частично унаследована от CS:GO — проверяй актуальный путь именно в своей сборке, он может отличаться в зависимости от того, как разворачивался сервер). Если значение задаётся и там, и там, побеждает то, что применяется последним при старте — обычно параметр командной строки перезаписывает cfg.

Также полезно проверить связанные флаги, которые иногда сбивают с толку:

hostname "Мой сервер CS2"
sv_visiblemaxplayers -1
sv_password ""

Пустой sv_password — сервер без пароля; если стоит непустой пароль, а ты забыл об этом, друзья будут получать отказ подключения, что легко перепутать с проблемой сети.

Шаг 6: провайдер режет порты — как проверить

Если сервер стоит на домашнем интернете (не в дата-центре), некоторые провайдеры блокируют или режут входящий трафик на нестандартные порты, особенно у тарифов без «белого IP» или с CGNAT (Carrier-Grade NAT). Симптомы:

• Порт открыт локально и на роутере, ss -tulnp показывает, что сервис слушает — но снаружи достучаться не выходит никаким способом.
• Онлайн-чекер портов извне показывает порт закрытым, хотя всё настроено правильно.
• Публичный IP, который ты видишь в браузере (например, через любой сервис «мой IP»), не совпадает с тем, что реально назначен твоему роутеру провайдером — верный признак CGNAT, при котором внешний проброс портов физически невозможен без дополнительных телодвижений (VPN с публичным IP, обращение к провайдеру за выделенным IP).

Проверить CGNAT просто: сравни IP, который показывает роутер в своей админке (WAN IP), с тем, что показывает внешний сервис определения IP с любого устройства в этой же сети. Если цифры не совпадают — у тебя NAT на стороне провайдера, и локальный проброс портов тут не поможет в принципе.

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

Если тема портов и файрвола пока не до конца понятна — почитай базовый разбор: настройка портов и файрвола для игрового сервера, там разложена логика TCP/UDP и типичные ошибки роутеров.

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