Выкидывает с ошибкой VAC

MAATRIX GAMES

Игроки жалуются, что их выкидывает с вашего CS2-сервера с упоминанием VAC, а вы точно никого не банили и читеров не покрываете. Это одна из самых частых причин, по которой люди в панике пишут в поддержку хостинга — а на деле в 90% случаев дело не в банах вообще, а в том, как сервер настроен относительно Valve Anti-Cheat. Разберём, что реально происходит, как проверить статус своего сервера и что чинить, а что не в вашей власти.

Что на самом деле означает "ошибка VAC"

Первое, что нужно понять: сообщение про VAC при коннекте к серверу почти никогда не значит "тебя забанили". Реальный VAC-бан — это отдельная, куда более редкая история, и она видна в профиле Steam игрока намного раньше, чем он вообще попробует зайти к вам. То, с чем сталкивается 9 из 10 админов кастомных серверов — это несовпадение режима secure/insecure между сервером и клиентом, либо проблема с валидацией сессии через GSLT-токен.

У CS2-сервера (как и у любого Source 2 dedicated server) есть два состояния:

• Secure — сервер зарегистрирован в Steam через валидный GSLT (Game Server Login Token), VAC активен, читы отслеживаются.
• Insecure — сервер либо не отправил токен, либо токен невалиден/просрочен, либо VAC отключён явно. Такой сервер помечается как unsecure в браузере серверов.

Игрок с активным VAC-статусом аккаунта может нормально играть и на secure, и на insecure серверах — но клиент Steam честно предупреждает при коннекте к unsecure. А вот сообщения о разрыве сессии чаще всего вылезают, когда сервер заявляет себя как secure, но фактическая авторизация в Steam у него не проходит — то есть токен есть, но не рабочий, IP сервера сменился без обновления, или временные проблемы на стороне Steam auth.

Проверяем реальный статус сервера: secure или insecure

Первым делом — не гадать, а посмотреть, что сервер сам о себе думает. Зайдите в консоль сервера (через RCON или напрямую, если есть доступ) и выполните:

status

В выводе будет строка вида:

hostname: My CS2 Server
version : 1.xx.x.x secure  [нет данных для лога сборки]

Ключевое слово — secure в конце строки версии. Если вместо него insecure — сервер не проходит VAC-валидацию, и именно это чаще всего читают игроки как "ошибку VAC" при попытке зайти. Второе, что стоит проверить — сам GSLT:

sv_visiblemaxplayers -1
gameinfo

Если в логах при старте сервера вы видите что-то вроде GC Not Ready или Failed to login game server, sv_setsteamaccount — это прямой сигнал, что токен не принят Steam. Причины обычно банальные:

• токен скопирован с лишним пробелом или обрезан;
• токен уже привязан к другому запущенному инстансу сервера (Steam не даёт двум процессам одновременно логиниться с одним GSLT);
• сменился внешний IP сервера, а токен создавался под другой адрес (актуально для некоторых хостингов с динамическим IP — уточняйте у провайдера, фиксированный ли у вас IP).

Настройка GSLT-токена: где взять и как прописать правильно

Токен выпускается в Steamworks: https://steamcommunity.com/dev/managegameservers, для приложения CS2 (App ID 730). Один токен — один одновременно работающий сервер. Пропишите его в конфиге запуска, обычно в server.cfg (лежит в game/csgo/cfg/server.cfg) или прямо в параметрах старта:

sv_setsteamaccount "ВАШ_ТОКЕН_ЗДЕСЬ"

Либо через аргумент командной строки при запуске cs2.sh:

./cs2.sh -dedicated -console -usercon +game_type 0 +game_mode 1 +map de_dust2 +sv_setsteamaccount ВАШ_ТОКЕН

После рестарта проверьте status ещё раз — статус должен смениться на secure. Если сервер стоит за NAT или на VPS с проброшенными портами, убедитесь, что сервер может достучаться наружу к серверам авторизации Steam — блокировка исходящего трафика фаерволом хостинга (не входящего, а именно исходящего) — частая причина, почему токен "не цепляется" даже будучи правильным. Про настройку портов и фаервола для игрового сервера подробнее — в статье про настройку портов и файрвола для игрового сервера.

sv_pure: смежная, но другая история

Отдельно стоит разделить VAC и sv_pure — это разные механизмы, которые часто путают именно потому, что оба влияют на "что игроку можно, а что нет" на сервере.

sv_pure контролирует, какие файлы клиента (модели, звуки, текстуры, скины) должны совпадать с эталонными файлами игры, а не отвечает за детект читов напрямую:

Для официальных матчей и серьёзных соревновательных серверов обычно ставят sv_pure 1 или 2. Для кастомных community-серверов (surf, deathmatch, retake) многие намеренно держат sv_pure 0, чтобы не мешать игрокам с их визуальными модами. Важно понимать: низкий sv_pure сам по себе не отключает VAC и не делает сервер insecure — это разные настройки, но путаница между ними и порождает половину форумных тредов "у меня VAC ошибка, а я ничего не менял". Если вы недавно трогали sv_pure и после этого начались жалобы — это, скорее всего, совпадение по времени, а не причина.

Secure vs unsecure: осознанный выбор, а не баг

Если вы держите тестовый сервер, песочницу для отладки плагинов или сборку с кастомными режимами (например surf/bhop — про их настройку есть отдельный разбор про настройку кастомных режимов surf, bhop, deathmatch), иногда осознанно держат сервер unsecure — это упрощает разработку и не требует валидного GSLT на каждый тестовый рестарт.

Но у этого есть цена, и её честно нужно проговорить: unsecure-сервер не защищён VAC от читеров. На публичном list-сервере это довольно быстро превращается в проблему — рано или поздно набегут читеры, которых на secure-сервере отсекло бы. Если сервер приватный, для друзей, по прямому IP — риск ниже, но не нулевой, особенно если IP светится в истории подключений или логах где-то публично.

Практический компромисс, которым пользуются многие админы community-серверов:

• Тестовые/дев-сервера — insecure, не в публичном списке, доступ по прямому IP только для доверенных.
• Продакшн-сервер, куда заходят рандомные игроки — обязательно secure, с рабочим GSLT.
• Для контроля дополнительно ставят серверные плагины анти-чит поверх VAC (например через SourceMod/Metamod, если сборка это поддерживает) — VAC не покрывает всё, особенно новые виды читов до обновления баз Valve.

Логи сервера: где искать первопричину

Если после проверки GSLT и статуса secure проблема осталась — идите в логи. Обычно они лежат в game/csgo/logs/ (если логирование включено log on в конфиге) либо смотрите вывод консоли напрямую при подключении проблемного игрока. Что искать:

log on
sv_logfile 1
sv_logsdir logs

После этого при следующем коннекте с ошибкой в логе будет видно: разрыв произошёл на этапе Steam-авторизации клиента, на этапе загрузки карты, либо это вообще не связано с VAC, а сервер просто крашнулся или превысил лимит по памяти. Если история с крашами и разборами логов у вас регулярная — отдельная статья про чтение логов и крэш-репортов поможет системно подойти к диагностике, а не гадать каждый раз заново.

Отдельно проверьте нагрузку: если сервер параллельно тянет тяжёлые кастомные карты из Steam Workshop (см. материал про кастомные карты из Steam Workshop), нехватка RAM или деградация тикрейта иногда маскируется под "разрывы соединения", которые игроки описывают как угодно, включая "выбросило с VAC-ошибкой", хотя формально это не она.

Что делать, если проблема на стороне аккаунта игрока

Бывает и обратная ситуация: с сервером всё в порядке (secure, GSLT валиден, статус подтверждён), а конкретного игрока всё равно кикает с упоминанием VAC. Тут важно честно сказать игроку: это не зона ответственности владельца сервера, чинить нужно на стороне Steam. Типичные причины:

• у игрока реальный VAC-бан на аккаунте (проверяется в его же профиле Steam — раздел статуса VAC виден публично или в Steam Support);
• Steam Guard не подтверждён достаточное время (Valve требует, чтобы Mobile Authenticator был активен определённый период перед тем как аккаунт считается доверенным для secure-серверов — конкретные сроки лучше сверять в актуальной справке Steam, они периодически меняются);
• проблемы на стороне самого Steam-клиента — устаревший клиент, повреждённые файлы игры (помогает проверка целостности через Steam или чистая переустановка);
• временный сбой авторизации Steam (глобальный, не связанный с конкретным сервером — проверяется по статусу steamstat.us или аналогичных мониторов).

В таких случаях направляйте игрока в Steam Support (help.steampowered.com) — как владелец сервера вы физически не можете снять VAC-ограничение с чужого аккаунта, и попытки "починить" это конфигами сервера ничего не дадут.

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