Лагает тикрейт на CS2-сервере

MAATRIX GAMES

Стреляешь в упор, а хитрег не засчитывается, или на реплее видно, что противник телепортируется на пару кадров — первое, на что грешат в CS2, это тикрейт. И часто не зря: сервер может быть настроен на 64 или 128 тиков, но реально отдавать 40-50 с просадками, а игрок этого даже не видит без выведенной статистики. Разберём, как посмотреть реальный тикрейт своего сервера, а не тот, что написан в рекламе тарифа, и что делать, если цифры не сходятся.

Что вообще такое тикрейт и почему он скачет

Тикрейт — это частота, с которой сервер пересчитывает игровую логику: позиции игроков, попадания, физику гранат. В CS2 стандартные значения — 64 тика в секунду, на части серверов (в том числе некоторых официальных режимах и почти всегда на кастомных выделенных серверах) — 128. Чем выше тикрейт, тем чаще сервер сверяет, где на самом деле находится пуля и где игрок в момент выстрела — это напрямую влияет на точность попаданий, особенно на скорострельном оружии и при резких движениях.

Важно понимать: тикрейт — это не FPS клиента и не пинг. Это отдельная, серверная метрика. У вас может быть отличный пинг 20 мс и при этом просевший до 30 реальных тиков сервер — и хитреги всё равно будут «прилипать» или не засчитываться, потому что сервер физически не успевает пересчитать мир так часто, как заявлено в конфиге.

Скачет тикрейт обычно не сам по себе, а потому что серверу не хватает вычислительных ресурсов вовремя досчитать каждый тик. Если тик должен укладываться в 15.625 мс (для 64 тиков) или в 7.8 мс (для 128), а логика карты, боты или сетевая обработка отнимают больше — сервер начинает «тормозить» и отдавать меньше тиков, чем настроено.

Смотрим net_graph: что показывает клиент

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

net_graph 1

В правом нижнем углу появится блок с несколькими строками. Нас интересуют:

• var — вариация между тиками, разброс интервалов обновления. Чем ближе к нулю, тем стабильнее сервер шлёт обновления.
• loss/choke — потери и «затыки» на линии, но это больше про сеть, чем про тикрейт как таковой.
• tick — интервал обновления сервера в миллисекундах, на который клиент реально ориентируется.

Если сервер настроен на 128 тиков, интервал должен держаться в районе 7-8 мс стабильно, без частых скачков в 20-30 мс. Разовые пики при резких событиях (взрыв гранаты, много игроков в одной точке) — это нормально. А вот если var постоянно высокий и держится так минуту-две — это уже симптом, что сервер не успевает считать тики равномерно.

Более детальную картину даёт net_graph 4 — добавляет графики потерь пакетов и джиттера прямо на экран, полезно, если хочется зафиксировать проблему скриншотом для support-тикета или для себя, прежде чем разбираться дальше.

Что реально показывает серверная консоль

Клиентский net_graph — это оценка со стороны игрока, и на неё влияет и его собственная сеть. Достовернее смотреть на статистику самого сервера. Если у вас есть доступ к серверной консоли (RCON или прямой доступ по SSH к процессу), там есть команда, которая показывает фактический тикрейт за последний период:

stats

Она выведет CPU-нагрузку, использование памяти и, что важно, реальную частоту тиков (в некоторых сборках движка Source 2 это отображается как "fps" сервера — не путать с клиентским FPS, здесь это синоним частоты тиков симуляции). Сравните это число с тем, что прописано в вашем конфиге автозапуска:

-tickrate 128

Если в параметрах запуска стоит 128, а stats стабильно показывает 90-100 — это не глюк отображения, это реальная просадка, и сервер физически не успевает считать так быстро, как заявлено. Проверить сам параметр запуска можно, заглянув в скрипт старта (cs2.sh или сервисный юнит systemd) — иногда его меняют один раз и забывают, а потом обновление образа или другой шаблон конфига откатывает значение обратно.

Главная причина: CPU сервера

CS2 (как и CS:GO до него) — движок Source 2, который очень сильно зависит от однопоточной производительности процессора. Симуляция тика — это в основном последовательные вычисления, а не то, что параллелится по ядрам. Поэтому сервер с 16 слабыми ядрами почти всегда проиграет серверу с 6 ядрами, но высокой частотой на ядро и хорошим IPC.

На практике это означает: если вы взяли тариф хостинга, в котором в характеристиках красиво написано «8 vCPU», а тикрейт всё равно скачет — дело не в количестве ядер. Смотрите на:

• Частоту процессора — современные высокочастотные десктопные/серверные чипы (актуальные на конец 2026 года линейки с высоким base clock и хорошим single-core performance) тянут 128 тиков ощутимо стабильнее, чем старые серверные Xeon с большим числом ядер, но низкой частотой на ядро.
• Тип виртуализации — на переподписанных (oversold) нодах, где физическое ядро делят между несколькими виртуалками, тикрейт скачет даже при формально мощном процессоре, потому что ваш процесс не гарантированно получает CPU-время именно тогда, когда нужно.
• Соседей по хосту — если хостинг использует общие ресурсы без изоляции, чужой сервер с высокой нагрузкой рядом может «съедать» ваши такты в моменты пиков.

Честно: стабильный высокий тикрейт — это в первую очередь вопрос железа под капотом, а не магической настройки конфига. Если процессор слабый или сильно перегружен соседями, никакие конвары это не вылечат — можно только сгладить симптомы.

Боты, плагины и сложная логика карты

Вторая по частоте причина — избыточная нагрузка со стороны игровой логики, а не голого движка. Боты (bot_quota) считаются сервером как полноценные сущности с ИИ — каждый добавляет вычислительную нагрузку на тик. На слабом железе разница между 0 и 10 ботами может быть заметна в стабильности тикрейта.

Плагины на базе CounterStrikeSharp или Metamod:Source, если их много или они написаны неоптимально (частые тяжёлые операции каждый тик, а не по таймеру), тоже забирают время у симуляции. Если тикрейт просел после установки нового плагина — это первое, что стоит заподозрить: отключите его временно и сравните показания stats.

Карты с большим количеством сложной геометрии, динамических объектов, скриптованных событий (двери, лифты, разрушаемые элементы) тоже требуют больше вычислений на тик, чем стандартные competitive-карты вроде de_dust2 или de_mirage. Если у вас кастомная карта из Steam Workshop с тяжёлой логикой — настройка кастомных карт отдельно затрагивает, на что смотреть при выборе, чтобы не перегружать сервер лишним.

Сетевые проблемы хостинга

Иногда «лагает тикрейт» — это на самом деле не про тикрейт, а про сеть между сервером и игроками, которую путают с просадками симуляции. Отличить одно от другого можно так: если stats на сервере стабильно показывает заявленный тикрейт, а игроки всё равно жалуются на рывки — смотрите в сторону сети (пинг, потери пакетов, маршрутизация до локации хостинга), а не в сторону CPU.

Проверить сетевую часть можно через net_graph 4 у нескольких игроков одновременно — если у всех разом скачет loss/choke при стабильном серверном тикрейте, дело в сети или маршруте до дата-центра, а не в вычислительной мощности. Подробнее про то, как вообще разделять эти два разных диагноза («тормозит симуляция» и «проблема с сетью»), разобрано в статье про мониторинг TPS и лагов на сервере — логика диагностики там применима и к CS2, хотя терминология в шутерах немного своя.

Проверяем и явно фиксируем настроенный тикрейт

Отдельная грабля, о которой стоит сказать прямо: не все хостинг-провайдеры по умолчанию дают тот тикрейт, который вы ожидаете. Часть тарифов и шаблонов образов ставит 64 тика "из коробки" даже там, где заявлена поддержка 128, просто потому что 64 экономнее по ресурсам и это дефолт установки через SteamCMD. Стоит явно проверить и, если нужно, прописать параметр в скрипте запуска:

./cs2.sh -dedicated -console -usercon +game_type 0 +game_mode 1 +map de_dust2 -tickrate 128

и продублировать в server.cfg, если ваша сборка сервера это поддерживает, через конвар, отвечающий за интервал симуляции — на разных сборках он может называться по-разному, поэтому стоит свериться с документацией конкретного билда сервера, который вы используете. После перезапуска обязательно перепроверьте через stats, что значение реально применилось, а не осталось прежним из закэшированного конфига.

Если вы только разворачиваете сервер с нуля и ещё не уверены в базовых шагах — в статье как поднять сервер Counter-Strike 2 параметр tickrate тоже упоминается на этапе первого запуска, стоит свериться с актуальным флагом для вашей версии сборки.

Таблица — ориентир, не измеренный бенчмарк: конкретные цифры интервала — это просто математика (1000 мс / тикрейт), а не результат тестов на каком-то конкретном железе.

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