Сервер CS2 на VPS: SteamCMD, тікрейт і захист від DDoS

1. TL;DR

CS2-сервер на VPS підходить для закритих матчів, тренувань, ігрових спільнот і невеликих турнірів. Ключові параметри — продуктивність одного або кількох швидких CPU-ядер, низька затримка до гравців, стабільна мережа та наявність DDoS-фільтрації на боці дата-центру.

Покрокове встановлення починається з чистого Ubuntu-сервера. Після встановлення SteamCMD сервер завантажує файли CS2, запускається від окремого користувача й керується командами systemd. Конфігурація зберігається окремо від бінарних файлів, тому оновлення можна виконувати з мінімальним ризиком втрати налаштувань.

2. Зміст

Стаття побудована як практичний сценарій: спочатку визначається конфігурація VPS, потім виконується базовий захист SSH, встановлюються SteamCMD і CS2, після чого додаються конфіги, автозапуск, firewall, резервне копіювання та діагностика.

Команди розраховані на Ubuntu Server 24.04 LTS у 2026 році. Якщо використовується Debian або інша Linux-система, назви пакетів і розташування SteamCMD можуть відрізнятися. Перед виконанням команд замініть домени, IP-адреси та паролі-заглушки на власні значення.

3. Що ми налаштовуємо й навіщо

Яким буде результат

Зрештою вийде окремий CS2 Dedicated Server, доступний гравцям за адресою на кшталт 203.0.113.10:27015. Він запускатиметься автоматично після перезавантаження, перезапускатиметься в разі аварійного завершення й отримуватиме оновлення через SteamCMD.

На сервері можна використовувати стандартні режими Competitive, Casual, Deathmatch і Arms Race, а також конфігурації для тренувань. Для розширених сценаріїв застосовуються серверні розширення та плагіни, наприклад SourceMod і MetaMod:Source. Їх слід встановлювати лише з перевірених джерел: сторонні плагіни отримують доступ до ігрового процесу й можуть містити вразливості.

Self-hosted проти керованого ігрового сервера

Хмарний ігровий хостинг заощаджує час: панель сама створює інстанс, встановлює оновлення й іноді пропонує готовий DDoS-захист. Недоліки — обмежений доступ до Linux, платні додаткові слоти, прив’язка до конкретних модів і менший контроль над логами та мережею.

Self-hosted CS2 на VPS дає повний доступ до systemd, firewall, файлової системи, моніторингу та автоматизації. Це зручно, якщо сервер є частиною власної інфраструктури або потрібен нестандартний режим. Відповідальність за оновлення, резервні копії, секрети та мережеву безпеку при цьому лежить на власнику.

Чого не слід плутати

Ігровий Dedicated Server не є звичайним клієнтом Steam. На сервері не запускають графічний інтерфейс, Steam-клієнт або робочий стіл. Для підключення гравці використовують встановлену у себе гру CS2, а серверу потрібен лише набір dedicated server-файлів і мережевий доступ.

Також сервер CS2 не зобов’язаний мати HTTPS. Ігровий протокол використовує UDP, а TLS застосовують для панелі керування, API, вебстатистики або healthcheck-сервісу. Не варто розміщувати вебпанель на тому самому публічному порту, на якому працює ігровий сервер.

4. Яка VPS-конфігурація потрібна для цього завдання

Мінімальні вимоги

Для 5–10 гравців на стандартній карті технічно може вистачити 2 vCPU і 4 ГБ RAM, але така конфігурація залишає мало запасу для оновлень, моніторингу й фонових процесів. Для стабільної гри краще починати з 4 vCPU, 8 ГБ RAM і швидкого NVMe-диска.

Важливіша за номінальну кількість ядер — частота та передбачуваність CPU. Ігровий сервер чутливий до затримок одного потоку, тому 4 швидкі ядра без сильного overselling часто кращі, ніж 8 повільних shared-vCPU. Уточніть у провайдера, чи використовуються dedicated CPU, яка політика oversubscription і чи є обмеження на PPS.

Практична конфігурація

Для одного сервера на 10–12 гравців можна взяти відповідний VPS з 4 vCPU, 8 ГБ RAM, 80 ГБ NVMe, публічним IPv4, віртуалізацією KVM і мережевим портом 1 Гбіт/с. Бажано мати консоль провайдера, снапшоти, зворотний DNS і можливість замінити або додати IPv6.

Диск потрібен не лише для поточних файлів CS2. Оновлення можуть тимчасово займати додаткове місце, а логи, дампи, плагіни й архіви швидко збільшують обсяг. Залишайте щонайменше 25–30% вільного простору й не зберігайте єдину копію бекапу на тому самому диску.

Коли обирати dedicated

Dedicated-сервер виправданий, якщо потрібні кілька ігрових інстансів, великий постійний онлайн, передбачувана продуктивність або одночасно працюють бази даних, вебсервіси та системи статистики. Фізичні ядра зменшують вплив сусідів і дають змогу точніше закріпити CPU affinity.

Для одного невеликого CS2-сервера dedicated зазвичай надлишковий. Він має сенс не через саме слово «ігровий», а через вимоги до кількості інстансів, стабільності навантаження та пропускної здатності. Якщо проблема лише в DDoS, купівля потужнішого сервера її не вирішує: потрібен upstream-фільтр, а не додаткові ядра.

Вибір локації

Розміщуйте сервер ближче до більшості гравців і перевіряйте маршрут від їхніх інтернет-провайдерів. Відстань впливає на RTT, а перевантажені міжнародні канали можуть спричиняти втрати пакетів навіть за хорошого ping до сусіднього регіону.

Перед замовленням виконайте тести до IP тестового сервера в кількох відповідних дата-центрах за допомогою ping, mtr і, за можливості, UDP-тесту. Ідеальний результат — стабільна затримка без втрат, а не мінімальне середнє значення одного вимірювання.

5. Підготовка сервера

Оновлення системи та базові пакети

Підключіться до VPS під початковим користувачем, який має sudo. Укажіть у командах власне ім’я хоста. Спочатку оновимо індекс пакетів і встановимо утиліти для SSH, firewall, діагностики та резервного копіювання.

# Задаём понятное имя сервера
sudo hostnamectl set-hostname cs2-01

# Обновляем пакеты и устанавливаем базовые инструменты
sudo apt update && sudo apt full-upgrade -y
sudo apt install -y ca-certificates curl wget gnupg unzip tar \
  lib32gcc-s1 lib32stdc++6 tmux ufw fail2ban htop iotop \
  net-tools dnsutils mtr-tiny jq restic

Після оновлення перевірте версію ядра та вільне місце. Якщо оновилося ядро, перезавантажте сервер у погоджене вікно обслуговування.

# Проверяем ОС, ядро, память и диск
cat /etc/os-release
uname -r
free -h
df -h /

# Перезагрузка нужна, если обновилось ядро или системные библиотеки
sudo reboot

Окремий користувач і SSH-ключ

Не запускайте SteamCMD і CS2 від root. Створіть користувача steam з домашнім каталогом та окремого адміністративного користувача, якщо його ще немає. Для адміністрування використовуйте SSH-ключ Ed25519, а вхід за паролем вимикайте лише після перевірки нового ключа.

# Создаём системного пользователя для игровых файлов
sudo adduser --disabled-password --gecos "" steam

# При необходимости создаём администратора
sudo adduser deploy
sudo usermod -aG sudo deploy

# Создаём каталог SSH для deploy
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh

На локальному комп’ютері згенеруйте ключ, якщо його ще немає, і скопіюйте публічну частину на сервер.

# Выполняется на вашем локальном компьютере
ssh-keygen -t ed25519 -C "cs2-admin"

# Замените адрес на IP сервера
ssh-copy-id [email protected]

# Проверьте новый вход в отдельном окне
ssh [email protected]

Після успішного входу створіть drop-in для SSH. Не вимикайте поточну сесію, доки не перевірите нову.

# Разрешаем только ключевую аутентификацию
sudo tee /etc/ssh/sshd_config.d/10-hardening.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
EOF

# Проверяем синтаксис и перечитываем конфигурацию
sudo sshd -t && sudo systemctl reload ssh

Firewall і fail2ban

Для гри зазвичай потрібен UDP-порт 27015. TCP-порт із тим самим номером іноді потрібен для окремих функцій або інструментів, але відкривайте його лише за потреби. Дозвольте SSH до ввімкнення політики deny.

# Разрешаем SSH и игровой порт
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 27015/udp
sudo ufw allow 27015/tcp

# Включаем firewall и проверяем правила
sudo ufw --force enable
sudo ufw status verbose

# Включаем защиту SSH от перебора паролей
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Якщо SSH працює на нестандартному порту, замініть правило 22/tcp. Зміна номера порту сама по собі не є серйозним захистом, але зменшує кількість автоматичного сміттєвого сканування. Реальний захист — ключі, заборона root і обмеження доступу за IP або VPN.

6. Встановлення ПЗ — покроково

Крок 1. Підготовка каталогів

SteamCMD доступний як пакет Ubuntu і як архів від Valve. Пакет простіше обслуговувати, і він підходить для стандартного встановлення. Ігрові файли розмістимо окремо, щоб оновлювати їх без зміни системних каталогів.

# Создаём каталоги и назначаем владельца steam
sudo install -d -m 755 -o steam -g steam /opt/steamcmd
sudo install -d -m 755 -o steam -g steam /srv/cs2
sudo install -d -m 755 -o steam -g steam /var/log/cs2

# Разрешаем steam читать и обновлять собственные файлы
sudo chown -R steam:steam /opt/steamcmd /srv/cs2 /var/log/cs2

Крок 2. Встановлення SteamCMD

В Ubuntu 24.04 пакет SteamCMD може знаходитися в компоненті multiverse. Версія SteamCMD не фіксується як версія CS2: під час запуску утиліта сама отримує актуальні файли клієнта.

# Включаем репозиторий multiverse с 32-битными библиотеками
sudo add-apt-repository multiverse
sudo dpkg --add-architecture i386
sudo apt update

# Устанавливаем SteamCMD и необходимые runtime-библиотеки
sudo apt install -y steamcmd lib32gcc-s1 lib32stdc++6

# Копируем запускатель в отдельный каталог
sudo cp -a /usr/games/steamcmd /opt/steamcmd/steamcmd.sh
sudo chown -R steam:steam /opt/steamcmd

Переконайтеся, що бінарний файл запускається від користувача steam.

# Проверяем запуск SteamCMD без root
sudo -u steam /opt/steamcmd/steamcmd.sh +quit

Крок 3. Завантаження CS2 Dedicated Server

Для dedicated server використовується App ID 730. Залежно від поточної політики Valve файли сервера можуть завантажуватися через anonymous login. Якщо SteamCMD вимагатиме авторизацію, використовуйте окремий Steam-акаунт без цінних предметів і не зберігайте пароль в shell history.

# Загружаем или обновляем сервер CS2 в /srv/cs2
sudo -u steam /opt/steamcmd/steamcmd.sh \
  +force_install_dir /srv/cs2 \
  +login anonymous \
  +app_update 730 validate \
  +quit

Параметр validate перевіряє локальні файли й може значно збільшити час оновлення. Для звичайного регулярного оновлення достатньо app_update 730. Після завантаження перевірте наявність виконуваного файлу та розмір каталогу.

# Проверяем основные каталоги и размер установки
sudo -u steam find /srv/cs2/game/bin -maxdepth 2 -type f | head
du -sh /srv/cs2
ls -la /srv/cs2/game/csgo/cfg

Крок 4. Скрипт запуску

Параметри запуску винесемо в окремий файл. Це спрощує оновлення systemd unit і усуває довгу команду з кількох місць. Для приватного сервера задайте пароль через змінну середовища або файл із правами 600; не публікуйте його в конфігурації, яка потрапляє до Git.

# Создаём файл переменных с ограниченным доступом
sudo install -o steam -g steam -m 600 /dev/null /srv/cs2/cs2.env

# Записываем базовые параметры сервера
sudo tee /srv/cs2/cs2.env > /dev/null <<'EOF'
CS2_PORT=27015
CS2_HOSTNAME=Private CS2 Server
CS2_RCON_PASSWORD=CHANGE_THIS_TO_A_LONG_RANDOM_SECRET
CS2_TOKEN=
EOF
sudo chown steam:steam /srv/cs2/cs2.env
sudo chmod 600 /srv/cs2/cs2.env

Згенеруйте довгий секрет без пробілів і підставте його замість тимчасового значення.

# Генерируем случайный пароль для RCON
openssl rand -base64 32

Крок 5. systemd unit

Сервіс запускається в робочому каталозі гри. Параметри -dedicated, -console, -usercon і +game_type є практичною основою для стандартного сервера. Конкретні ігрові режими можна змінювати через конфігураційні файли та команди.

# Создаём systemd-сервис CS2
sudo tee /etc/systemd/system/cs2.service > /dev/null <<'EOF'
[Unit]
Description=Counter-Strike 2 Dedicated Server
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=steam
Group=steam
WorkingDirectory=/srv/cs2
EnvironmentFile=/srv/cs2/cs2.env
ExecStart=/bin/bash -lc 'exec /srv/cs2/game/bin/linuxsteamrt64/cs2 -dedicated -console -usercon -port ${CS2_PORT} +hostname "${CS2_HOSTNAME}" +map de_dust2 +game_type 0 +game_mode 1'
Restart=on-failure
RestartSec=10
LimitNOFILE=1048576
Nice=-5
UMask=0027

[Install]
WantedBy=multi-user.target
EOF

# Перечитываем unit-файлы и включаем автозапуск
sudo systemctl daemon-reload
sudo systemctl enable --now cs2

# Проверяем статус и последние сообщения
sudo systemctl status cs2 --no-pager
sudo journalctl -u cs2 -n 80 --no-pager

Шлях до бінарного файлу може змінитися в майбутніх оновленнях CS2. Якщо systemd повідомляє, що файл не знайдено, виконайте пошук:

# Находим актуальный бинарный файл сервера
sudo -u steam find /srv/cs2/game -type f -name 'cs2' -o -name 'cs2_linux64'

Крок 6. Оновлення через окремий скрипт

Не запускайте SteamCMD одночасно з працюючим сервером: оновлення може замінити бібліотеки під час ігрового процесу. Використовуйте maintenance window, зупиніть службу, оновіть файли та запустіть її знову.

# Создаём безопасный скрипт обновления CS2
sudo tee /usr/local/sbin/update-cs2 > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

systemctl stop cs2
runuser -u steam -- /opt/steamcmd/steamcmd.sh \
  +force_install_dir /srv/cs2 \
  +login anonymous \
  +app_update 730 \
  +quit
systemctl start cs2
systemctl --no-pager --full status cs2
EOF

# Ограничиваем запуск скрипта администраторами
sudo chmod 750 /usr/local/sbin/update-cs2
sudo chown root:root /usr/local/sbin/update-cs2

# Выполняем обновление вручную
sudo /usr/local/sbin/update-cs2

7. Конфігурація

Основний ігровий конфіг

Створіть файл server.cfg. CS2 читає його з каталогу game/csgo/cfg. Секрет RCON краще не зберігати в репозиторії, але для штатного завантаження ігрового конфіга він має бути доступним процесу. Безпечніше передавати його через окремий файл із правами 600 і обмежити доступ до сервера.

# Создаём каталог конфигурации
sudo install -d -o steam -g steam -m 750 /srv/cs2/game/csgo/cfg

# Создаём базовый конфиг сервера
sudo -u steam tee /srv/cs2/game/csgo/cfg/server.cfg > /dev/null <<'EOF'
hostname "Private CS2 Server"
sv_cheats 0
sv_lan 0
sv_hibernate_when_empty 0
sv_hibernate_postgame_delay 0
sv_hibernate_ms 0

mp_autoteambalance 1
mp_limitteams 1
mp_freezetime 12
mp_roundtime 1.92
mp_roundtime_defuse 1.92
mp_maxrounds 24
mp_c4timer 40
mp_buytime 20
mp_buy_anywhere 0
mp_startmoney 800
mp_restartgame 0

sv_logfile 1
sv_log_onefile 0
sv_logbans 1
sv_logecho 1
EOF

# Ограничиваем запись конфигурации пользователем steam
sudo chown steam:steam /srv/cs2/game/csgo/cfg/server.cfg
sudo chmod 640 /srv/cs2/game/csgo/cfg/server.cfg

Назву карти de_dust2 у systemd можна замінити на іншу карту. Для ручної зміни карти через консоль використовується команда changelevel de_mirage. Не додавайте на публічний сервер sv_cheats 1: це змінює правила гри й може вплинути на довіру гравців.

Режими й тикрейт

У CS2 використовується архітектура subtick. У класичному розумінні tickrate — це кількість повних оновлень стану світу за секунду. У subtick-системі сервер додатково враховує точний час дій між мережевими тіками, тому порівняння «64 проти 128» уже не описує весь процес обробки введення.

Параметр -tickrate 128 іноді зустрічається в старих посібниках і конфігураціях. Він не гарантує, що сервер працюватиме як колишній 128-tick сервер, а в актуальній версії гри частина поведінки контролюється самим рушієм. Не підміняйте цим параметром вимірювання якості мережі.

Перевіряйте сервер за кількома показниками:

• стабільність RTT у гравців;
• відсутність packet loss і різких стрибків jitter;
• завантаження одного потоку CPU без постійного упору в 100%;
• відсутність server hitches і затримок обробки;
• коректна робота вибраного ігрового режиму.

Для змагального сервера не встановлюйте сумнівні «tickrate-патчі». Вони можуть ламати оновлення, суперечити поточній архітектурі CS2 або створювати несумісність із клієнтами. Спочатку оновіть сервер до поточної версії та порівняйте результат на чистій конфігурації без плагінів.

GSLT і публічний сервер

Для публічного ігрового сервера може знадобитися Game Server Login Token. Токен пов’язує сервер з обліковим записом і використовується відповідно до правил Steam. Не публікуйте його в чатах, Git, systemd unit і загальнодоступних логах. Якщо токен скомпрометовано, відкличте його та створіть новий.

Зберігайте токен у /srv/cs2/cs2.env або в окремому файлі з правами 600. Точна змінна та спосіб передавання можуть залежати від поточної версії server launcher, тому перевіряйте актуальний вивід запуску та документацію Valve перед публічним розміщенням.

Перевірка процесу та порту

# Проверяем службу и процесс CS2
systemctl is-active cs2
pgrep -a cs2

# Проверяем, слушается ли UDP-порт
sudo ss -lunp | grep 27015

# Проверяем загрузку CPU и памяти
ps -eo pid,user,pcpu,pmem,cmd --sort=-pcpu | head -n 10
free -h

Перевірка UDP з іншого комп’ютера складніша, ніж перевірка TCP. Можна використовувати Steam Server Browser, підключення з клієнта CS2 і мережевий моніторинг провайдера. Команда nc -z для UDP не дає надійного підтвердження: відсутність відповіді TCP не означає, що ігровий UDP-порт закритий.

Керування через RCON

RCON дає змогу виконувати команди віддалено, але це додаткова поверхня атаки. Використовуйте довгий пароль, не відкривайте окремий RCON-порт без потреби та обмежуйте адміністративний доступ за IP. Якщо потрібне постійне віддалене керування, безпечніше організувати доступ через WireGuard або адміністративний bastion.

Не передавайте RCON-пароль у публічних скриптах. Після зміни пароля перезапустіть службу та перевірте, що старі підключення не зберігаються. Регулярно переглядайте логи RCON, особливо якщо сервер доступний з інтернету.

HTTPS для моніторингу

Ігровому протоколу CS2 не потрібен Caddy або Certbot. HTTPS корисний лише для окремого вебсервісу: наприклад, healthcheck, сторінки статистики або внутрішньої панелі. Вебсервіс має слухати localhost, а Caddy — приймати зовнішній трафік на 443 і автоматично отримувати сертифікат для домену.

# Устанавливаем Caddy из официального Debian-репозитория пакетов
sudo apt install -y caddy

# Создаём простой healthcheck-файл
sudo install -d -o www-data -g www-data -m 755 /var/www/cs2
echo 'CS2 host is reachable' | sudo tee /var/www/cs2/index.html

# Задаём домен и корневой каталог сайта
sudo tee /etc/caddy/Caddyfile > /dev/null <<'EOF'
cs2-status.example.com {
    root  /var/www/cs2
    file_server
    header {
        Cache-Control "no-store"
    }
}
EOF

# Проверяем Caddy и перезапускаем его
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl enable --now caddy
sudo systemctl reload caddy

# Открываем только HTTPS для веб-статуса
sudo ufw allow 443/tcp

8. Резервні копії та обслуговування

Що зберігати

Чисті бінарні файли CS2 зазвичай можна завантажити повторно, тому першими до резервної копії потрапляють конфіги, systemd unit, змінні середовища, плагіни, карти, журнали аудиту та дані статистики. Якщо використовується база даних, її потрібно експортувати логічно, а не копіювати робочі файли InnoDB або PostgreSQL без узгодженого snapshot.

• /srv/cs2/game/csgo/cfg — серверні налаштування;
• /srv/cs2/cs2.env — секрети, у зашифрованому сховищі;
• /etc/systemd/system/cs2.service — автозапуск;
• каталоги SourceMod, MetaMod, карт і користувацьких ресурсів;
• дампи баз даних, якщо вони використовуються;
• список пакетів і власні скрипти оновлення.

Restic і зовнішнє сховище

Для простого сценарію використовуйте S3-сумісне зовнішнє сховище. Змінні доступу зберігайте у файлі root-only, а пароль репозиторію — окремо. Зовнішнє сховище має знаходитися не на тому самому VPS і бажано в іншому дата-центрі.

# Создаём каталог с секретами restic
sudo install -d -m 700 /etc/restic
sudo tee /etc/restic/cs2.env > /dev/null <<'EOF'
export RESTIC_REPOSITORY='s3:https://s3.example.com/cs2-backups'
export AWS_ACCESS_KEY_ID='REPLACE_ME'
export AWS_SECRET_ACCESS_KEY='REPLACE_ME'
export RESTIC_PASSWORD='REPLACE_WITH_A_LONG_REPOSITORY_PASSWORD'
EOF
sudo chmod 600 /etc/restic/cs2.env

# Инициализируем репозиторий один раз
sudo bash -c 'source /etc/restic/cs2.env && restic init'

Створіть скрипт, який зупиняє сервер лише за потреби. Для конфігів і плагінів достатньо короткого вікна. Якщо на сервері є динамічні користувацькі дані, узгодьте момент копіювання або використовуйте snapshot, який надає сховище.

# Создаём скрипт ежедневного бэкапа
sudo tee /usr/local/sbin/backup-cs2 > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

source /etc/restic/cs2.env

restic backup \
  /srv/cs2/game/csgo/cfg \
  /srv/cs2/cs2.env \
  /etc/systemd/system/cs2.service \
  /usr/local/sbin/update-cs2 \
  --tag cs2-config

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune
EOF

sudo chmod 700 /usr/local/sbin/backup-cs2
sudo chown root:root /usr/local/sbin/backup-cs2

# Проверяем резервное копирование вручную
sudo /usr/local/sbin/backup-cs2
sudo bash -c 'source /etc/restic/cs2.env && restic snapshots'

Планувальник cron

Запускайте бэкап уночі або в період мінімального онлайна. Стандартний cron не повідомляє власника про помилки автоматично, тому додайте лог у journald або налаштуйте сповіщення через зовнішній monitoring-сервіс.

# Запускаем бэкап каждый день в 04:20
sudo tee /etc/cron.d/cs2-backup > /dev/null <<'EOF'
20 4    root /usr/local/sbin/backup-cs2 >> /var/log/cs2-backup.log 2>&1
EOF
sudo chmod 644 /etc/cron.d/cs2-backup

# Проверяем синтаксис заданий и журнал
sudo systemctl restart cron
sudo tail -n 30 /var/log/cs2-backup.log

Резервна копія вважається робочою лише після тестового відновлення. Раз на місяць створюйте тимчасовий каталог, відновлюйте туди конфіг і перевіряйте, що він читається, секрети доступні, а сервер може запуститися після чистої установки.

Оновлення та maintenance window

Оновлення CS2 можуть включати зміни клієнта й сервера, тому не оновлюйте продуктивний інстанс безпосередньо під час матчу. Спочатку виконайте завантаження на тестовому VPS або після бэкапа, потім перезапустіть сервер, перевірте порт, карту, плагіни та підключення клієнта.

Для одного інстансу підходить maintenance window тривалістю 10–20 хвилин. Для кількох серверів застосовуйте послідовне оновлення: спочатку тестовий, потім менш важливий, а далі основний. Повний rolling update неможливий без другого ігрового інстансу, на який можна тимчасово перевести гравців.

Мінімальний моніторинг

Контролюйте доступність UDP-порту, стан systemd, вільне місце, RAM, CPU steal time і мережевий трафік. Аварійними порогами можна вважати заповнення диска понад 80%, постійний load average вище за кількість доступних ядер, зростання packet loss і повторювані перезапуски служби.

# Полезные проверки перед началом игрового вечера
systemctl is-active --quiet cs2 && echo "CS2: OK" || echo "CS2: DOWN"
df -h /
free -h
sudo ss -s
sudo journalctl -u cs2 --since "1 hour ago" --no-pager | tail -n 80

9. Troubleshooting і FAQ

Сервер не запускається: «No such file or directory»

Спочатку виконайте systemctl status cs2 і перегляньте journalctl -u cs2 -n 100. Частою причиною є змінений шлях до бінарного файлу після оновлення, відсутність 32-бітних бібліотек або неправильний власник каталогу. Перевірте файл командою find /srv/cs2/game -type f, встановіть lib32gcc-s1 і запустіть бінарний файл вручну від користувача steam, щоб побачити початкову помилку.

SteamCMD видає помилку завантаження або App ID не встановлюється

Перевірте DNS, вихідний HTTPS і вільне місце: curl -I https://steamcdn-a.akamaihd.net, df -h. Запускайте SteamCMD від користувача steam і вказуйте +force_install_dir до +login. Якщо anonymous login більше не дозволений для конкретного сценарію, використовуйте окремий Steam-акаунт без цінних предметів і не передавайте пароль через командний рядок.

Гравці не бачать сервер у списку

Перевірте, що служба активна й прослуховує саме публічний інтерфейс: sudo ss -lunp | grep 27015. Потім перевірте правила UFW, security group і мережевий firewall у панелі VPS. CS2 використовує UDP, тому TCP-перевірка не підтверджує доступність гри. Спробуйте пряме підключення за IP і портом із клієнта, а не лише пошук за назвою.

Високий ping або rubber-banding за низького завантаження CPU

Зазвичай це проблема маршруту, packet loss, jitter або перевантаження каналу, а не нестача RAM. Порівняйте mtr із кількох мереж гравців, графіки трафіку VPS і метрики packet loss. Перевірте сусідню локацію, вимкніть важкі плагіни та переконайтеся, що бэкап або оновлення не насичують вихідний канал. Якщо втрати починаються за межами дата-центру, проблему має дослідити провайдер.

Чи допоможе параметр -tickrate 128?

Він не гарантує класичний режим 128-tick. Сучасний CS2 використовує subtick-обробку, тому якість залежить від версії рушія, навантаження сервера, затримки та втрат пакетів. Не додавайте параметр лише тому, що він є у старих гайдах. Спочатку виміряйте стабільність сервера на чистій конфігурації, потім тестуйте зміни на окремому інстансі.

Яка конфігурація VPS мінімально підійде?

Для особистого сервера на кілька гравців мінімально доцільними є 2 швидкі vCPU, 4 ГБ RAM, 40 ГБ NVMe і публічний IPv4. Для стабільної гри 10–12 людей краще взяти 4 vCPU, 8 ГБ RAM і порт 1 Гбіт/с. Важливі не лише цифри: уточніть наявність DDoS-фільтрації UDP, CPU steal time, обмежень PPS і географію дата-центру. Залишайте запас диска й пам’яті для оновлень і плагінів.

Що вибрати — VPS чи dedicated для цього завдання?

VPS підходить для одного сервера, невеликої групи гравців і помірної кількості плагінів. Dedicated варто обирати для кількох інстансів, великої спільноти, постійного високого навантаження або коли потрібні гарантовані фізичні ядра. Однак dedicated не замінює DDoS-захист: за заповненого зовнішнього каналу однаково недоступними будуть і VPS, і фізичний сервер. Спочатку визначте вимоги до CPU та мережі, потім порівняйте вартість фільтрації.

UFW увімкнено, але сервер усе одно недоступний

Перевірте порядок діагностики: sudo ufw status numbered, sudo ss -lunp, статус systemd і firewall/security group у панелі провайдера. Переконайтеся, що відкрито UDP, а не лише TCP, і що порт у systemd збігається з портом у правилі UFW. Якщо використовується IPv6, аналогічне правило має бути дозволене і для IPv6, або IPv6 слід коректно вимкнути, а не залишати частково налаштованим.

Як захиститися від DDoS самостійно?

На самому сервері можна обмежити адміністративні порти, вимкнути непотрібні сервіси, налаштувати rate limiting для веб-панелі та швидко блокувати очевидні джерела сміттєвого трафіку. Але це не зупинить атаку, яка заповнює канал до VPS. Для UDP-гри потрібна фільтрація на рівні мережі провайдера або спеціалізований ігровий scrubbing-сервіс. Заздалегідь збережіть контакти NOC і план зміни IP, не покладайтеся лише на iptables.

Після оновлення зникли плагіни або налаштування

Перевірте, чи не перезаписали ви каталог game/csgo власною копією під час відновлення. Порівняйте власників і права: файли мають бути доступні користувачеві steam. Переконайтеся, що плагіни сумісні з поточною версією CS2 і MetaMod:Source. Якщо проблема з’явилася одразу після оновлення, зупиніть сервер, відновіть конфіги з бэкапа і тимчасово запустіть чисту версію без розширень.

10. Висновки та наступні кроки

Ми отримали керований CS2 Dedicated Server на Ubuntu 24.04 із встановленням через SteamCMD, автозапуском systemd, базовими ігровими конфігураціями, firewall і резервним копіюванням. Для якості гри важливіші стабільний CPU, близька локація та відсутність втрат пакетів, ніж формальна вказівка «128 tick».

Далі варто додати зовнішній моніторинг, протестувати відновлення з Restic і оформити регламент оновлень. Із розширенням онлайна можна винести статистику та веб-панель в окремий сервіс, запустити другий ігровий інстанс для maintenance window, а за постійного високого навантаження перейти на dedicated із гарантованими ядрами та спеціалізованою UDP DDoS-фільтрацією.