Como usar um CDN para acelerar os assets do site do seu servidor de MU Online

Resposta rápida

Um servidor de MU Online vive e morre pela primeira impressão do site: se a página demora para carregar ou o download do cliente trava, o jogador desiste antes mesmo de instalar o jogo. Um CDN (Content Delivery Network) resolve isso distribuindo cópias dos seus arquivos estáticos — imagens, CSS, JavaScript, fontes e até o instalador do cliente — em servidores espalhados geograficamente, próximos do jogador. O resultado é carregamento mais rápido, menos carga no seu servidor de origem e resiliência contra picos de acesso em lançamentos e eventos. Este tutorial mostra como escolher um CDN, configurar DNS, separar assets estáticos do aplicativo dinâmico e medir o ganho real de performance.

Por que um CDN importa para um servidor de MU

O site de um servidor privado tem um padrão de tráfego irregular: praticamente vazio na maior parte do tempo e um pico brutal no dia do lançamento (open beta, wipe, temporada nova). Sem CDN, todo esse pico bate direto no servidor de origem — o mesmo que talvez rode o painel, o fórum e até o banco de dados do jogo. Um CDN absorve esse pico servindo os arquivos estáticos a partir de um cache de borda (edge), sem nunca chegar à sua origem. Isso é especialmente crítico para o instalador do cliente, que pode ter 2 a 6 GB e ser baixado por centenas de pessoas na mesma hora.

Anatomia dos assets de um site de MU

Nem tudo no site precisa (ou deve) passar pelo CDN da mesma forma. Vale separar por tipo:

Tipo de asset	Exemplo	Estratégia de cache
Estático puro	logo.png, style.css, app.js	Cache longo (dias/semanas) + cache busting
Cliente para download	mu-client-setup.exe	Bucket de objeto + CDN, cache muito longo
Imagens dinâmicas	avatar de personagem, ranking	Cache curto (minutos) ou sem cache
HTML de páginas	ranking, notícias, perfil	Sem cache ou cache curtíssimo (segundos)
API/JSON	status do servidor, online count	Sem cache, ou cache de 5-10s no máximo

Misturar tudo no mesmo balde de cache é o erro mais comum: cachear a página de ranking por um dia deixa o placar visivelmente errado, e isso mina a confiança dos jogadores no site.

Escolhendo o provedor de CDN

Para a maioria dos servidores de MU, três opções cobrem praticamente todos os cenários:

Provedor	Ponto forte	Quando usar
Cloudflare	Grátis, fácil, proxy + DNS + WAF básico	Padrão para 90% dos servidores
Bunny CDN	Barato, ótimo para arquivos grandes (cliente)	Download do cliente com muito volume
Cloudflare R2 / AWS S3 + CloudFront	Storage de objeto nativo + CDN integrado	Cliente grande + backups + múltiplos arquivos

Cloudflare costuma ser o ponto de partida por ser gratuito e cobrir DNS, proxy e cache num único painel. Bunny CDN entra quando o volume de download do cliente já é alto e o custo por GB da Cloudflare (em planos avançados) começa a pesar.

Passo 1 — Separar o domínio do site do domínio de downloads (opcional, mas recomendado)

Uma prática comum é usar um subdomínio dedicado para arquivos estáticos, por exemplo cdn.seuservidor.com ou dl.seuservidor.com, apontando para um bucket de objeto. Isso evita que o tráfego de download do cliente compita com as requisições do site principal e facilita configurar regras de cache diferentes por subdomínio.

site principal:  seuservidor.com          -> hospedagem do site (PHP/Node)
CDN de assets:   cdn.seuservidor.com       -> bucket + CDN (imagens, CSS, JS)
downloads:       dl.seuservidor.com        -> bucket + CDN (cliente, patches)

Passo 2 — Apontar o DNS e ativar o proxy

No painel da Cloudflare, adicione o domínio, aponte os registros A/CNAME para o seu servidor de origem e ative o modo proxy (nuvem laranja) nos registros que devem passar pelo CDN. Registros usados apenas para e-mail ou serviços internos devem ficar em modo DNS-only (nuvem cinza), sem proxy.

Tipo   Nome              Conteúdo              Proxy
A      seuservidor.com   203.0.113.10          Ativado (laranja)
CNAME  www               seuservidor.com       Ativado (laranja)
CNAME  cdn               bucket.exemplo.com    Ativado (laranja)
A      mail              203.0.113.11          Desativado (cinza)

Passo 3 — Configurar regras de cache por tipo de conteúdo

Na seção de Page Rules ou Cache Rules do CDN, crie regras específicas em vez de confiar apenas no cache padrão:

Regra 1: cdn.seuservidor.com/*
  Cache Level: Cache Everything
  Edge Cache TTL: 30 dias

Regra 2: seuservidor.com/ranking*
  Cache Level: Bypass

Regra 3: seuservidor.com/api/*
  Cache Level: Bypass

Essas três regras já cobrem o essencial: tudo que é estático cacheia agressivamente, tudo que é dinâmico (ranking, API) nunca é cacheado pelo CDN.

Passo 4 — Hospedar o cliente para download em bucket de objeto

Subir o instalador do cliente direto na mesma VPS que roda o site é um erro comum: além de consumir disco e banda da origem, um pico de downloads pode derrubar o serviço web. Migre o arquivo para um bucket (Cloudflare R2, Backblaze B2, S3) e sirva-o pelo CDN:

# exemplo com AWS CLI compatível (R2/B2 usam a mesma interface S3)
aws s3 cp mu-client-setup.exe s3://meu-bucket-mu/downloads/ \
  --endpoint-url https://<account-id>.r2.cloudflarestorage.com \
  --acl public-read

Depois, aponte um link do site para https://dl.seuservidor.com/downloads/mu-client-setup.exe, e o CDN cuida da distribuição sem tocar no seu servidor de origem.

Passo 5 — Cache busting para CSS e JS

Para evitar que o jogador veja uma versão antiga do site depois de um deploy, versione os arquivos estáticos por query string ou hash no nome:

<link rel="stylesheet" href="/assets/style.css?v=20260731">
<script src="/assets/app.js?v=20260731"></script>

Sempre que fizer deploy de mudanças visuais, incremente a versão. Isso é mais confiável do que confiar em purge manual do cache, que costuma ser esquecido.

Passo 6 — Comprimir e otimizar antes de subir ao CDN

CDN acelera a entrega, mas não substitui otimização de origem. Antes de subir imagens e scripts:

Comprima imagens (WebP/AVIF quando possível) — reduz até 70% do tamanho sem perda visível.
Minifique CSS e JS (remova espaços, comentários, código morto).
Ative Brotli ou Gzip no CDN para HTML/CSS/JS (a maioria já faz isso automaticamente).

Passo 7 — Medir o ganho real

Use ferramentas de teste de performance antes e depois de ativar o CDN, comparando o mesmo conjunto de páginas:

Métrica	Sem CDN (exemplo)	Com CDN (exemplo)
Tempo de carregamento (home)	2.8s	0.6s
Tempo até primeiro byte (TTFB)	480ms	40ms
Banda consumida na origem (pico)	100%	5-15%
Falhas em pico de lançamento	Frequentes	Raras

Os números variam por servidor, mas a direção é sempre a mesma: menos carga na origem e resposta mais rápida para o jogador, principalmente em picos.

Passo 8 — Configurar SSL/TLS corretamente

Ative o modo Full (Strict) de SSL no CDN, garantindo que a conexão entre o CDN e o seu servidor de origem também é criptografada, não só entre o CDN e o jogador. Isso evita mixed content warnings e mantém o certificado válido de ponta a ponta.

Erros comuns e soluções

Sintoma	Causa provável	Solução
Ranking desatualizado no site	Página de ranking sendo cacheada pelo CDN	Criar regra de Bypass para rotas dinâmicas
Site "quebrado" após deploy visual	CSS/JS antigo servido do cache do navegador	Cache busting com versão no nome do arquivo
Download do cliente lento ou falhando em picos	Cliente hospedado na mesma VPS do site	Migrar para bucket de objeto atrás do CDN
Erro de certificado (mixed content)	SSL configurado como Flexible em vez de Full Strict	Trocar modo SSL para Full (Strict) no CDN
IP do servidor exposto em ataques	Proxy do CDN desativado no registro DNS	Ativar modo proxy (nuvem laranja) no registro

Checklist de configuração de CDN

Domínio adicionado ao CDN com proxy ativado nos registros web.
Assets estáticos separados por subdomínio ou pasta dedicada.
Regras de cache diferenciadas para estático, dinâmico e API.
Cliente para download migrado para bucket de objeto.
Cache busting implementado no CSS/JS do site.
SSL configurado em modo Full (Strict).
Teste de performance feito antes e depois, com números registrados.

Com o CDN no ar, o site aguenta picos de lançamento sem derrubar o servidor de origem — e esse mesmo servidor de origem, liberado dessa carga, fica disponível para o que realmente importa: rodar bem o servidor de MU Online e o painel administrativo.

Perguntas frequentes

Preciso de CDN se meu servidor de MU tem poucos jogadores?

Mesmo com poucos jogadores simultâneos, o site sofre picos em lançamentos e eventos, quando centenas de pessoas baixam o cliente ao mesmo tempo. Um CDN gratuito (Cloudflare, por exemplo) já resolve esse gargalo sem custo, então vale configurar desde o início.

O CDN serve também o download do cliente do jogo (vários GB)?

Sim, e é justamente onde ele mais ajuda. Arquivos grandes como o instalador do cliente devem ficar em um bucket de objeto (R2, S3, Backblaze B2) atrás do CDN, e não no mesmo servidor que roda o site e o banco de dados.

Cloudflare grátis é suficiente ou preciso de um plano pago?

Para a maioria dos servidores privados de MU, o plano gratuito da Cloudflare atende bem: cache de assets estáticos, proxy DNS e proteção básica contra DDoS. Planos pagos fazem sentido quando o tráfego cresce muito ou você precisa de regras de firewall mais avançadas (WAF customizado).

Como invalido o cache do CDN depois de atualizar uma imagem ou o CSS?

A forma mais confiável é usar cache busting via versionamento no nome do arquivo ou query string (ex.: style.css?v=42), em vez de depender de purge manual. Isso evita esquecer de limpar o cache e o jogador ver uma versão antiga do site.

CDN esconde o IP real do meu servidor?

Sim, quando configurado como proxy (não apenas DNS), o CDN mascara o IP de origem para requisições HTTP/HTTPS, dificultando ataques diretos. Mas o IP do GameServer/ConnectServer (portas de jogo) continua exposto, pois o CDN não protege tráfego de jogo, apenas o tráfego web.

Bruno

Editor de eventos, mapas e itens

Bruno é especialista em eventos, mapas, bosses e economia de itens do MU Online. Documenta cada detalhe com base em jogo real.