Servidor CS2 en VPS: SteamCMD, tasa de ticks y protección contra DDoS

1. TL;DR

Un servidor CS2 en VPS es adecuado para partidas privadas, entrenamientos, comunidades de jugadores y pequeños torneos. Los parámetros clave son el rendimiento de uno o varios núcleos de CPU rápidos, baja latencia hacia los jugadores, una red estable y la disponibilidad de filtrado DDoS por parte del centro de datos.

La instalación paso a paso comienza con un servidor Ubuntu limpio. Tras instalar SteamCMD, el servidor descarga los archivos de CS2, se ejecuta bajo un usuario independiente y se gestiona mediante comandos systemd. La configuración se almacena separada de los archivos binarios, por lo que las actualizaciones pueden realizarse con un riesgo mínimo de perder los ajustes.

2. Contenido

El artículo está estructurado como un escenario práctico: primero se determina la configuración del VPS, después se aplica la protección básica de SSH, se instalan SteamCMD y CS2, y luego se añaden configuraciones, inicio automático, firewall, copias de seguridad y diagnóstico.

Los comandos están pensados para Ubuntu Server 24.04 LTS en 2026. Si se utiliza Debian u otro sistema Linux, los nombres de los paquetes y la ubicación de SteamCMD pueden diferir. Antes de ejecutar los comandos, sustituya los dominios, direcciones IP y contraseñas de ejemplo por sus propios valores.

3. Qué configuramos y por qué

Cuál será el resultado

Al final tendrá un CS2 Dedicated Server independiente, accesible para los jugadores en una dirección como 203.0.113.10:27015. Se iniciará automáticamente después de reiniciar, se reiniciará ante una finalización inesperada y recibirá actualizaciones mediante SteamCMD.

En el servidor se pueden utilizar los modos estándar Competitive, Casual, Deathmatch y Arms Race, así como configuraciones para entrenamientos. Para escenarios avanzados se aplican extensiones y plugins de servidor, por ejemplo SourceMod y MetaMod:Source. Deben instalarse únicamente desde fuentes verificadas: los plugins de terceros obtienen acceso al proceso de juego y pueden contener vulnerabilidades.

Self-hosted frente a servidor de juegos gestionado

El hosting de juegos en la nube ahorra tiempo: el panel crea la instancia, instala actualizaciones y, en ocasiones, ofrece protección DDoS lista para usar. Sus inconvenientes son el acceso limitado a Linux, slots adicionales de pago, dependencia de mods concretos y menor control sobre los registros y la red.

Un CS2 self-hosted en VPS ofrece acceso completo a systemd, firewall, sistema de archivos, monitorización y automatización. Esto resulta práctico si el servidor forma parte de una infraestructura propia o se requiere un modo no estándar. La responsabilidad de las actualizaciones, copias de seguridad, secretos y seguridad de red recae entonces en el propietario.

Qué no se debe confundir

Un Dedicated Server de juego no es un cliente Steam convencional. En el servidor no se ejecutan una interfaz gráfica, el cliente Steam ni un escritorio. Para conectarse, los jugadores utilizan el juego CS2 instalado en sus equipos, mientras que el servidor solo necesita el conjunto de archivos del servidor dedicado y acceso a la red.

Además, un servidor CS2 no necesita obligatoriamente HTTPS. El protocolo de juego utiliza UDP, mientras que TLS se aplica para el panel de administración, API, estadísticas web o un servicio healthcheck. No debe instalarse un panel web en el mismo puerto público donde funciona el servidor de juego.

4. Qué configuración de VPS se necesita para esta tarea

Requisitos mínimos

Para 5–10 jugadores en un mapa estándar, técnicamente pueden bastar 2 vCPU y 4 GB de RAM, pero esta configuración deja poco margen para actualizaciones, monitorización y procesos en segundo plano. Para un juego estable, es mejor comenzar con 4 vCPU, 8 GB de RAM y un disco NVMe rápido.

Más importante que la cantidad nominal de núcleos es la frecuencia y la previsibilidad de la CPU. El servidor de juego es sensible a las latencias de un único hilo, por lo que 4 núcleos rápidos sin un overselling intenso suelen ser mejores que 8 vCPU compartidas lentas. Consulte al proveedor si utiliza CPU dedicadas, cuál es su política de oversubscription y si existen límites de PPS.

Configuración práctica

Para un servidor de 10–12 jugadores, puede elegir un VPS adecuado con 4 vCPU, 8 GB de RAM, 80 GB NVMe, IPv4 público, virtualización KVM y un puerto de red de 1 Gbit/s. Es recomendable disponer de una consola del proveedor, snapshots, DNS inverso y la posibilidad de reemplazar o añadir IPv6.

El disco no solo es necesario para los archivos actuales de CS2. Las actualizaciones pueden ocupar espacio adicional temporalmente, y los registros, dumps, plugins y archivos comprimidos aumentan rápidamente el volumen. Deje al menos un 25–30% de espacio libre y no guarde la única copia de seguridad en el mismo disco.

Cuándo elegir dedicated

Un servidor dedicado se justifica si se necesitan varias instancias de juego, una gran cantidad constante de jugadores conectados, rendimiento predecible o si funcionan simultáneamente bases de datos, servicios web y sistemas de estadísticas. Los núcleos físicos reducen la influencia de los vecinos y permiten asignar CPU affinity con mayor precisión.

Para un servidor CS2 pequeño, un dedicated suele ser excesivo. Tiene sentido no por la propia palabra «juego», sino por los requisitos de cantidad de instancias, estabilidad de carga y capacidad de red. Si el problema es únicamente el DDoS, comprar más potencia no lo resuelve: se necesita un filtro upstream, no núcleos adicionales.

Elección de ubicación

Ubique el servidor cerca de la mayoría de los jugadores y compruebe la ruta desde sus proveedores de Internet. La distancia afecta al RTT, y los canales internacionales saturados pueden provocar pérdida de paquetes incluso con un buen ping hacia una región vecina.

Antes de contratar, realice pruebas hacia la IP de un servidor de prueba en varios centros de datos adecuados mediante ping, mtr y, si es posible, una prueba UDP. El resultado ideal es una latencia estable sin pérdidas, no el valor medio mínimo de una sola medición.

5. Preparación del servidor

Actualización del sistema y paquetes básicos

Conéctese al VPS con el usuario inicial que tiene sudo. Indique su propio nombre de host en los comandos. Primero actualizaremos el índice de paquetes e instalaremos utilidades para SSH, firewall, diagnóstico y copias de seguridad.

# Задаём понятное имя сервера
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

Después de la actualización, compruebe la versión del kernel y el espacio libre. Si se actualizó el kernel, reinicie el servidor durante una ventana de mantenimiento acordada.

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

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

Usuario independiente y clave SSH

No ejecute SteamCMD ni CS2 como root. Cree un usuario steam con un directorio personal y un usuario administrativo independiente, si aún no existe. Para la administración, use una clave SSH Ed25519 y desactive el acceso por contraseña únicamente después de verificar la nueva clave.

# Создаём системного пользователя для игровых файлов
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

En el equipo local, genere una clave si aún no la tiene y copie la parte pública al servidor.

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

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

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

Después de iniciar sesión correctamente, cree un drop-in para SSH. No cierre la sesión actual hasta comprobar la nueva.

# Разрешаем только ключевую аутентификацию
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 y fail2ban

Para el juego normalmente se necesita el puerto UDP 27015. El puerto TCP con el mismo número puede ser necesario para determinadas funciones o herramientas, pero ábralo solo cuando sea necesario. Permita SSH antes de activar la política 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

Si SSH funciona en un puerto no estándar, sustituya la regla 22/tcp. Cambiar el número de puerto por sí solo no constituye una protección importante, pero reduce la cantidad de escaneos automatizados no deseados. La protección real son las claves, la prohibición de root y la restricción de acceso por IP o VPN.

6. Instalación del software — paso a paso

Paso 1. Preparación de los directorios

SteamCMD está disponible como paquete de Ubuntu y como archivo de Valve. El paquete es más fácil de mantener y adecuado para una instalación estándar. Colocaremos los archivos del juego por separado para actualizarlos sin modificar los directorios del sistema.

# Создаём каталоги и назначаем владельца 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

Paso 2. Instalación de SteamCMD

En Ubuntu 24.04, el paquete SteamCMD puede encontrarse en el componente multiverse. La versión de SteamCMD no se fija como la versión de CS2: al iniciarse, la utilidad obtiene por sí sola los archivos actuales del cliente.

# Включаем репозиторий 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

Asegúrese de que el binario se ejecuta con el usuario steam.

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

Paso 3. Descarga de CS2 Dedicated Server

Para dedicated server se utiliza el App ID 730. Según la política actual de Valve, los archivos del servidor pueden descargarse mediante anonymous login. Si SteamCMD solicita autenticación, utilice una cuenta de Steam independiente sin objetos valiosos y no guarde la contraseña en el historial del shell.

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

El parámetro validate comprueba los archivos locales y puede aumentar considerablemente el tiempo de actualización. Para una actualización periódica normal basta con app_update 730. Después de la descarga, compruebe que exista el archivo ejecutable y el tamaño del directorio.

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

Paso 4. Script de inicio

Colocaremos los parámetros de inicio en un archivo independiente. Esto simplifica la actualización de la unidad de systemd y evita tener un comando largo en varios lugares. Para un servidor privado, establezca la contraseña mediante una variable de entorno o un archivo con permisos 600; no la publique en una configuración que se incluya en 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

Genere un secreto largo sin espacios y sustitúyalo en lugar del valor temporal.

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

Paso 5. Unidad de systemd

El servicio se inicia en el directorio de trabajo del juego. Los parámetros -dedicated, -console, -usercon y +game_type constituyen una base práctica para un servidor estándar. Los modos de juego concretos pueden cambiarse mediante archivos de configuración y comandos.

# Создаём 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

La ruta del binario puede cambiar en futuras actualizaciones de CS2. Si systemd indica que no se encuentra el archivo, realice una búsqueda:

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

Paso 6. Actualización mediante un script independiente

No ejecute SteamCMD simultáneamente con el servidor en funcionamiento: la actualización puede sustituir bibliotecas durante la partida. Utilice una maintenance window, detenga el servicio, actualice los archivos y vuelva a iniciarlo.

# Создаём безопасный скрипт обновления 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. Configuración

Configuración principal del juego

Cree el archivo server.cfg. CS2 lo lee desde el directorio game/csgo/cfg. Es preferible no guardar el secreto de RCON en el repositorio, pero para la carga normal de la configuración del juego debe estar disponible para el proceso. Es más seguro proporcionarlo mediante un archivo independiente con permisos 600 y restringir el acceso al servidor.

# Создаём каталог конфигурации
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

El nombre del mapa de_dust2 en systemd puede sustituirse por otro mapa. Para cambiar manualmente el mapa mediante la consola se utiliza el comando changelevel de_mirage. No añada sv_cheats 1 a un servidor público: esto cambia las reglas del juego y puede afectar a la confianza de los jugadores.

Modos y tickrate

CS2 utiliza una arquitectura subtick. En el sentido clásico, tickrate es el número de actualizaciones completas del estado del mundo por segundo. En un sistema subtick, el servidor también tiene en cuenta el momento exacto de las acciones entre los ticks de red, por lo que la comparación «64 frente a 128» ya no describe todo el proceso de procesamiento de la entrada.

El parámetro -tickrate 128 aparece a veces en guías y configuraciones antiguas. No garantiza que el servidor funcione como un servidor 128-tick anterior, y en la versión actual del juego parte del comportamiento está controlado por el propio motor. No sustituya la medición de la calidad de la red por este parámetro.

Compruebe el servidor mediante varios indicadores:

• estabilidad del RTT de los jugadores;
• ausencia de packet loss y de aumentos bruscos del jitter;
• carga de un solo hilo de CPU sin permanecer constantemente al 100%;
• ausencia de server hitches y retrasos de procesamiento;
• funcionamiento correcto del modo de juego seleccionado.

Para un servidor competitivo, no instale «parches de tickrate» dudosos. Pueden romper las actualizaciones, contradecir la arquitectura actual de CS2 o crear incompatibilidades con los clientes. Primero actualice el servidor a la versión actual y compare el resultado con una configuración limpia sin plugins.

GSLT y servidor público

Un servidor de juego público puede requerir un Game Server Login Token. El token vincula el servidor a una cuenta y se utiliza de acuerdo con las reglas de Steam. No lo publique en chats, Git, la unidad de systemd ni registros accesibles públicamente. Si el token se ve comprometido, revoque el existente y cree uno nuevo.

Guarde el token en /srv/cs2/cs2.env o en un archivo independiente con permisos 600. La variable exacta y el método de transmisión pueden depender de la versión actual del server launcher, por lo que debe comprobar la salida de inicio actual y la documentación de Valve antes de hacerlo público.

Comprobación del proceso y del puerto

# Проверяем службу и процесс 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

Comprobar UDP desde otro equipo es más complicado que comprobar TCP. Puede utilizar Steam Server Browser, una conexión desde el cliente de CS2 y la monitorización de red del proveedor. El comando nc -z para UDP no ofrece una confirmación fiable: la ausencia de una respuesta TCP no significa que el puerto UDP del juego esté cerrado.

Gestión mediante RCON

RCON permite ejecutar comandos de forma remota, pero añade una superficie de ataque. Utilice una contraseña larga, no abra un puerto RCON independiente sin necesidad y restrinja el acceso administrativo por IP. Si necesita una gestión remota permanente, es más seguro organizar el acceso mediante WireGuard o un bastion administrativo.

No transmita la contraseña de RCON en scripts públicos. Después de cambiar la contraseña, reinicie el servicio y compruebe que no se mantienen las conexiones antiguas. Revise periódicamente los registros de RCON, especialmente si el servidor está accesible desde Internet.

HTTPS para la monitorización

El protocolo del juego CS2 no necesita Caddy ni Certbot. HTTPS solo es útil para un servicio web independiente: por ejemplo, un healthcheck, una página de estadísticas o un panel interno. El servicio web debe escuchar en localhost, mientras que Caddy debe aceptar el tráfico externo en el puerto 443 y obtener automáticamente el certificado para el dominio.

# Устанавливаем 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

# Creamos un directorio con secretos de 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

# Inicializamos el repositorio una vez
sudo bash -c 'source /etc/restic/cs2.env && restic init'

# Creamos un script de copia de seguridad diaria
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

# Comprobamos la copia de seguridad manualmente
sudo /usr/local/sbin/backup-cs2
sudo bash -c 'source /etc/restic/cs2.env && restic snapshots'

# Ejecutamos la copia de seguridad todos los días a las 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

# Comprobamos la sintaxis de las tareas y el registro
sudo systemctl restart cron
sudo tail -n 30 /var/log/cs2-backup.log

Una copia de seguridad se considera funcional solo después de una restauración de prueba. Una vez al mes, cree un directorio temporal, restaure allí la configuración y compruebe que se puede leer, que los secretos están disponibles y que el servidor puede iniciarse después de una instalación limpia.

Actualizaciones y maintenance window

Las actualizaciones de CS2 pueden incluir cambios en el cliente y el servidor, así que no actualice la instancia de producción durante un partido. Primero realice la descarga en un VPS de prueba o después de una copia de seguridad; luego reinicie el servidor y compruebe el puerto, el mapa, los plugins y la conexión del cliente.

Para una sola instancia, es adecuada una maintenance window de 10–20 minutos. Para varios servidores, aplique una actualización secuencial: primero el de prueba, luego el menos importante y después el principal. Una actualización rolling completa es imposible sin una segunda instancia de juego a la que se pueda trasladar temporalmente a los jugadores.

Monitorización mínima

Supervise la disponibilidad del puerto UDP, el estado de systemd, el espacio libre, la RAM, el CPU steal time y el tráfico de red. Como umbrales de alerta se pueden considerar una ocupación de disco superior al 80%, un load average constante superior al número de núcleos disponibles, el aumento de packet loss y los reinicios repetidos del servicio.

# Comprobaciones útiles antes de comenzar la sesión de juego
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. Resolución de problemas y FAQ

El servidor no inicia: «No such file or directory»

Primero ejecute systemctl status cs2 y revise journalctl -u cs2 -n 100. Una causa frecuente es una ruta al binario modificada después de una actualización, la ausencia de bibliotecas de 32 bits o un propietario incorrecto del directorio. Compruebe el archivo con el comando find /srv/cs2/game -type f, instale lib32gcc-s1 y ejecute el binario manualmente como el usuario steam para ver el error original.

SteamCMD muestra un error de descarga o no se instala el App ID

Compruebe el DNS, HTTPS saliente y el espacio libre: curl -I https://steamcdn-a.akamaihd.net, df -h. Ejecute SteamCMD como el usuario steam e indique +force_install_dir antes de +login. Si el anonymous login ya no está permitido para un escenario concreto, utilice una cuenta de Steam independiente sin objetos valiosos y no transmita la contraseña mediante la línea de comandos.

Los jugadores no ven el servidor en la lista

Compruebe que el servicio está activo y escucha exactamente en la interfaz pública: sudo ss -lunp | grep 27015. Después, compruebe las reglas de UFW, el security group y el firewall de red en el panel del VPS. CS2 utiliza UDP, por lo que una comprobación TCP no confirma la disponibilidad del juego. Pruebe la conexión directa por IP y puerto desde el cliente, no solo la búsqueda por nombre.

Ping alto o rubber-banding con baja carga de CPU

Normalmente se trata de un problema de ruta, packet loss, jitter o saturación del canal, y no de falta de RAM. Compare mtr desde varias redes de jugadores, los gráficos de tráfico del VPS y las métricas de packet loss. Compruebe una ubicación cercana, desactive los plugins pesados y asegúrese de que la copia de seguridad o la actualización no saturen el canal saliente. Si las pérdidas comienzan fuera del centro de datos, el proveedor debe investigar el problema.

¿Ayudará el parámetro -tickrate 128?

No garantiza el modo clásico de 128 tick. El CS2 moderno utiliza procesamiento subtick, por lo que la calidad depende de la versión del motor, la carga del servidor, la latencia y la pérdida de paquetes. No añada el parámetro solo porque aparezca en guías antiguas. Primero mida la estabilidad del servidor con una configuración limpia y luego pruebe los cambios en una instancia independiente.

¿Qué configuración de VPS es mínimamente adecuada?

Para un servidor personal con pocos jugadores, lo mínimo razonable son 2 vCPU rápidos, 4 GB de RAM, 40 GB de NVMe y una IPv4 pública. Para un juego estable de 10–12 personas, es mejor elegir 4 vCPU, 8 GB de RAM y un puerto de 1 Gbit/s. No solo importan las cifras: confirme la disponibilidad de filtrado DDoS para UDP, CPU steal time, límites de PPS y la ubicación geográfica del centro de datos. Deje margen de disco y memoria para actualizaciones y plugins.

¿Qué elegir para esta tarea: VPS o dedicated?

Un VPS es adecuado para un servidor, un grupo pequeño de jugadores y un número moderado de plugins. Se debe elegir un dedicated para varias instancias, una comunidad grande, una carga alta constante o cuando se requieren núcleos físicos garantizados. Sin embargo, un dedicated no sustituye la protección DDoS: si el canal externo está saturado, tanto el VPS como el servidor físico quedan inaccesibles. Primero defina los requisitos de CPU y red y luego compare el coste del filtrado.

UFW está activado, pero el servidor sigue sin estar disponible

Compruebe el orden de diagnóstico: sudo ufw status numbered, sudo ss -lunp, el estado de systemd y el firewall/security group en el panel del proveedor. Asegúrese de que UDP esté abierto, no solo TCP, y de que el puerto en systemd coincida con el puerto de la regla UFW. Si se utiliza IPv6, la regla equivalente también debe estar permitida para IPv6 o IPv6 debe desactivarse correctamente, no dejarse parcialmente configurado.

¿Cómo protegerse de un DDoS por cuenta propia?

En el propio servidor se pueden limitar los puertos administrativos, desactivar servicios innecesarios, configurar rate limiting para el panel web y bloquear rápidamente fuentes evidentes de tráfico basura. Pero esto no detendrá un ataque que sature el canal hacia el VPS. Para un juego UDP se necesita filtrado a nivel de red del proveedor o un servicio especializado de scrubbing para juegos. Guarde de antemano los contactos del NOC y un plan de cambio de IP; no dependa solo de iptables.

Después de una actualización desaparecieron los plugins o las configuraciones

Compruebe si sobrescribió el directorio game/csgo con su propia copia durante la restauración. Compare propietarios y permisos: los archivos deben ser accesibles para el usuario steam. Asegúrese de que los plugins sean compatibles con la versión actual de CS2 y MetaMod:Source. Si el problema apareció inmediatamente después de la actualización, detenga el servidor, restaure las configuraciones desde la copia de seguridad e inicie temporalmente una versión limpia sin extensiones.

10. Conclusiones y próximos pasos

Hemos obtenido un CS2 Dedicated Server gestionable en Ubuntu 24.04 con instalación mediante SteamCMD, inicio automático con systemd, configuraciones básicas de juego, firewall y copias de seguridad. Para la calidad de juego son más importantes una CPU estable, una ubicación cercana y la ausencia de pérdida de paquetes que la indicación formal de «128 tick».

A continuación, conviene añadir monitorización externa, probar la restauración desde Restic y formalizar un procedimiento de actualizaciones. A medida que aumente la actividad, se pueden trasladar las estadísticas y el panel web a un servicio independiente, iniciar una segunda instancia de juego para la maintenance window y, ante una carga alta constante, migrar a un dedicated con núcleos garantizados y filtrado UDP DDoS especializado.