[Início](https://servghost.com/pt) / [Guias de Hospedagem com Privacidade](https://servghost.com/pt/guides) / Proteção DDoS em VPS: Onde o Host Para e a Camada 7 Começa Operações # Sobrevivendo a um Ataque DDoS no Seu VPS Todo plano de hospedagem diz "proteção contra DDoS incluída", e todos eles querem dizer a mesma coisa restrita: a rede absorve inundações medidas em gigabits. Os ataques que realmente derrubam sites pequenos são medidos em requisições por segundo, custam quase nada ao atacante, e chegam com aparência inteiramente legítima. Este guia traça a linha entre os dois, mostra como identificar em um minuto de qual lado você está, e cobre o que realmente se sustenta do lado da linha que é seu. [Ler o guia](#guide-body) [Perguntas frequentes](#guide-faq) ## Nesta página - [Guia](#guide-body) - [Perguntas frequentes](#guide-faq) - [Guias relacionados](#guide-related) - [Páginas recomendadas](#guide-cta) Sem KYC Somente Cripto Sem Logs DMCA ignorado Root Completo NVMe SSD 23 min de leitura Atualizado em Sep 2026 Nesta página [01Dois ataques diferentes que compartilham um nome](#dois-ataques-diferentes-que-compartilham-um-nome) [02O que a "proteção contra DDoS incluída" realmente compra](#o-que-a-proteção-contra-ddos-incluída-realmente-compra) [03Primeiro, decida se isto é mesmo um ataque](#primeiro-decida-se-isto-é-mesmo-um-ataque) [04Lendo o ataque a partir do próprio servidor](#lendo-o-ataque-a-partir-do-próprio-servidor) [05Os primeiros dez minutos](#os-primeiros-dez-minutos) [06Limites de taxa que seguram, e o erro que todo mundo comete](#limites-de-taxa-que-seguram-e-o-erro-que-todo-mundo-comete) [07Cache é a mitigação mais barata que você vai implantar](#cache-é-a-mitigação-mais-barata-que-você-vai-implantar) [08Os tetos que decidem se você vai cair](#os-tetos-que-decidem-se-você-vai-cair) [09Colocando algo na frente da origem](#colocando-algo-na-frente-da-origem) [10Uma origem oculta vale mais do que qualquer filtro](#uma-origem-oculta-vale-mais-do-que-qualquer-filtro) [11Escolhendo hardware e localização para que ataques continuem sendo chatos](#escolhendo-hardware-e-localização-para-que-ataques-continuem) [12Cinco coisas para não fazer](#cinco-coisas-para-não-fazer) [13A versão curta](#a-versão-curta) [FAQPerguntas frequentes](#guide-faq) [→Páginas recomendadas](#guide-cta) Há dois momentos em que as pessoas descobrem como a mitigação de DDoS realmente funciona. O primeiro é tranquilo, no momento da compra, ao ler uma lista de recursos que diz "proteção contra DDoS incluída" e presumir, sem pensar muito, que a frase cobre tudo. O segundo é às três da manhã, quando o site está fora do ar, os gráficos parecem errados de um jeito que não faz sentido, e aquela proteção incluída está — corretamente, e por design — sem fazer absolutamente nada. Os dois momentos envolvem o mesmo produto e a mesma verdade: um provedor de hospedagem filtra os ataques que chegam como volume bruto, porque é ele quem é dono do link por onde esses pacotes trafegam, e você não. Ele não consegue filtrar os ataques que chegam como requisições de aparência comum, porque do ponto de vista da rede elas são requisições de aparência comum. Essa linha — entre a inundação que o seu host absorve e a inundação que você precisa sobreviver sozinho — é o assunto inteiro. Tudo o que vem a seguir é sobre descobrir de que lado dela você está, e o que fazer em cada um. ## Dois ataques diferentes que compartilham um nome "DDoS" é uma única palavra cobrindo dois problemas que não têm quase nada em comum além do resultado. Eles são interrompidos em lugares diferentes, por pessoas diferentes, com ferramentas diferentes, e confundi-los é o motivo de tanto esforço de mitigação cair na camada errada. | | Volumétrico — camadas 3 e 4 | Aplicação — camada 7 | | --- | --- | --- | | O que chega | SYN floods, amplificação UDP via refletores DNS, NTP ou memcached abertos, ACK floods, pacotes de lixo genéricos | Requisições HTTP comuns: GET floods, POST floods, slow-loris, query strings que quebram o cache | | Medido em | Gigabits e milhões de pacotes por segundo | Requisições por segundo — muitas vezes apenas alguns milhares | | Largura de banda necessária para prejudicar | Enorme. É uma disputa de capacidade | Quase nenhuma. Um único notebook consegue, se o endpoint for caro o bastante | | Onde precisa ser barrado | **A montante, pelo seu provedor.** Quando os pacotes chegam à sua porta, o dano já está feito | **No seu servidor, por você**, ou em um proxy que você controla na frente dele | | Como aparece na máquina | Interface saturada, contadores de pacotes absurdos, CPU pode estar ociosa | Largura de banda modesta, mas todo worker ocupado, carga subindo, fila do banco de dados crescendo | | Quem resolve | A limpeza do seu host, automaticamente, geralmente em segundos | Sua configuração — limites de taxa, cache, tetos de conexão | Leia as duas últimas linhas de novo, porque é nelas que está o ponto prático. Se a interface está saturada, nada que você digitar no servidor vai ajudar: os pacotes já consumiram a porta, e a única parte capaz de descartá-los é quem é dono do roteador a montante. Se a interface está tranquila mas o site continua fora do ar, o oposto é verdade — o seu host não vê nada de errado porque, na camada dele, nada *está* errado, e o conserto é inteiramente seu. Inundações volumétricas são filtradas a montante, onde está a capacidade. O que sobrevive a esse filtro é tráfego de aparência comum — e barrá-lo é trabalho seu, não do seu host. ## O que a "proteção contra DDoS incluída" realmente compra A proteção em nível de rede é real, valiosa, e quase sempre mal interpretada. Quando um provedor anuncia filtragem L3/L4, quer dizer que a rede dele monitora o tráfego destinado ao seu endereço, e quando uma inundação é detectada, o tráfego é desviado por hardware de limpeza que descarta a parte maliciosa e encaminha o que parece legítimo. Isso acontece sem chamado de suporte, e geralmente sem que você perceba mais do que uma breve oscilação. Essa única frase está fazendo muito trabalho, então vale a pena destrinchar o que ela cobre e o que não cobre: - **Ela cobre os ataques que você não sobreviveria sozinho.** Uma inundação de amplificação de 200 Gbps contra um servidor com uma porta de 1 Gbps não é um problema de configuração. É aritmética. A limpeza a montante é a única resposta que existe. - **Ela é alheia ao estado da sua aplicação.** O filtro não sabe quais das suas URLs são caras, quais visitantes estão logados, ou que uma requisição ao seu endpoint de busca custa quatrocentas vezes uma requisição ao seu logo. - **Ela reage a um limiar, não ao seu sofrimento.** A detecção é disparada pelo volume de tráfego. Um ataque que nunca ultrapassa o limiar nunca a dispara, não importa o quão completamente ele tenha derrubado o seu site. - **Ela pode fazer um null-route breve em casos extremos.** Toda rede tem um teto. Se um ataque ameaça a infraestrutura compartilhada, o endereço pode ser descartado por um período — isso é padrão, universal, e vale a pena saber antes de acontecer, não durante. **A versão de uma linha:** o seu host protege a rede dele, e você se beneficia disso. Ele não protege a sua aplicação, e não tem como. A camada 7 não é um upsell que foi sonegado de você — é uma camada que o seu provedor não consegue enxergar sem terminar o seu TLS, o que para quem hospeda offshore é uma troca com custos sérios próprios. ## Primeiro, decida se isto é mesmo um ataque Uma fração impressionante dos incidentes suspeitos de DDoS é outra coisa vestindo essa fantasia, e os consertos não são intercambiáveis. Antes de limitar a taxa de qualquer coisa, gaste dois minutos descartando os impostores — um diagnóstico errado aqui custa uma hora e, ocasionalmente, os seus usuários de verdade. - **Você ficou popular.** Um link em um grande agregador produz um formato de tráfego que parece exatamente uma inundação de camada 7, exceto que os referrers são reais e as requisições são por páginas que um humano gostaria de ver. É um problema de capacidade com uma causa feliz; limitar a taxa disso é se autoprejudicar. - **Um crawler perdeu as boas maneiras.** Scrapers agressivos e bots de treinamento de IA conseguem facilmente superar um servidor pequeno. O user-agent geralmente confessa, e o conserto é robots.txt mais um limite direcionado, não um geral. - **Você quebrou alguma coisa.** Uma implantação que desativou o cache, um cron job fora de controle, um banco de dados que perdeu um índice — tudo isso se apresenta como "carga repentina, sem causa óbvia". Se o momento coincide com uma mudança que você fez, acredite na mudança. - **O seu próprio monitoramento é a inundação.** Raro, embaraçoso, e muito mais comum do que qualquer um admite. Um loop de health-check que tenta de novo sem backoff pode gerar uma taxa de requisições genuinamente impressionante. A pergunta que separa um caso do outro é simples: *o tráfego quer alguma coisa?* Carga real — mesmo carga real de aparência hostil — tem um formato. Ela atinge páginas que existem, segue links, carrega os assets, e vem de uma distribuição plausível de redes. Um ataque geralmente nem se dá ao trabalho. ## Lendo o ataque a partir do próprio servidor Você não precisa de um painel para classificar o que está acontecendo. Quatro comandos, executados em ordem, dizem em menos de um minuto em qual camada você está lutando — e saber isso determina tudo o que você faz a seguir. **O link está cheio?** Observe os contadores da interface. Se o throughput está preso perto do teto da porta, você está em um ataque volumétrico, e o seu trabalho é abrir um chamado, não mudar uma configuração: - vnstat -tr 10 — throughput médio ao longo de dez segundos, a leitura honesta mais rápida sobre saturação. - cat /proc/net/dev duas vezes, com um segundo de intervalo — deltas de pacotes e bytes por interface, sem precisar de ferramenta nenhuma. **É um SYN flood?** Conexões meio abertas se acumulam em SYN-RECV. Um punhado é normal; milhares não é: - ss -s — a linha de resumo, contagens de conexões por estado em uma olhada. - ss -tn state syn-recv | wc -l — o número específico que importa. **É camada 7?** Se a largura de banda não chama atenção mas tudo está lento, conte as requisições por cliente no seu access log. Um único endereço com dezenas de milhares de acessos é amador; cem mil endereços com três acessos cada é a coisa real: - tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30 - Troque $1 por $7 para classificar os caminhos requisitados em vez disso. Se um endpoint caro domina, você encontrou o alvo e metade do conserto. **O que está realmente esgotado?** A load average por si só diz pouco. Procure o teto específico que você atingiu: todos os children do PHP-FPM ocupados, conexões de banco de dados no limite, descritores de arquivo esgotados, ou workers presos em estado D esperando o disco. Esse teto — não o tráfego — é o que derrubou o site, e aumentá-lo costuma ser mais rápido do que filtrar qualquer coisa. **Tenha isto em mente enquanto observa:** se você roda um serviço focado em privacidade, um ataque é exatamente o momento em que você fica mais tentado a aumentar o logging e deixá-lo assim. Aumente se precisar, depois abaixe de novo e rotacione os arquivos agressivamente em seguida. Um incidente que deixa um mês de logs de visitantes em detalhe completo no disco trocou um problema por outro pior e mais duradouro. O nosso [OpSec para Servidores](https://servghost.com/pt/guides/server-opsec-staying-anonymous) cobre a disciplina a que isso pertence. ## Os primeiros dez minutos Sob pressão, as pessoas recorrem à maior alavanca disponível, e a maior alavanca geralmente é a errada. Esta é a ordem que limita o dano, começando, a grosso modo, pela opção mais rápida e mais segura: - **Classifique antes de agir.** Interface saturada significa volumétrico; interface tranquila com workers ocupados significa camada 7. Trinta segundos gastos aqui evitam que você conserte a camada errada durante uma hora. - **Se for volumétrico, abra um chamado imediatamente** e inclua o endereço de destino, o horário de início, e os seus contadores de interface. Depois pare de digitar no servidor — você não consegue consertar isso de dentro dele. - **Se for camada 7, faça cache primeiro.** Ativar cache agressivo de página inteira para visitantes anônimos é a forma mais rápida de converter uma indisponibilidade em um detalhe sem importância, e é a única medida que também ajuda contra tráfego real. - **Depois limite a taxa** — primeiro o endpoint visado, o resto depois. Comece conservador. Um limite que derruba os seus próprios usuários é uma continuação autoinfligida do ataque. - **Bloqueie só o que for inequívoco.** Uma dúzia de endereços com cem mil requisições cada, um user-agent obviamente falso, um país onde você não tem usuários. Resista ao impulso de escrever regras elaboradas debaixo de fogo; você não vai lembrar delas no mês que vem. - **Descarte carga deliberadamente se precisar.** Servir uma página estática de "em manutenção" para visitantes não autenticados mantém a máquina viva, mantém a sua API no ar, e compra tempo para pensar. Decidir o que sacrificar é melhor do que deixar que decidam por você. - **Anote o que você fez.** Toda regra temporária que você adicionou é uma mina terrestre para o seu eu futuro. As regras que ajudaram se tornam permanentes; o resto sai amanhã. ## Limites de taxa que seguram, e o erro que todo mundo comete A limitação de taxa é o instrumento principal para a camada 7, e o nginx faz isso bem, com duas diretivas que resolvem dois problemas genuinamente diferentes. limit_req limita a *taxa* de requisições — com que frequência um cliente pode pedir. limit_conn limita a *concorrência* — quantas conexões um cliente pode manter abertas ao mesmo tempo. Inundações precisam do primeiro; ataques slow-loris, que mantêm milhares de conexões quase ociosas para esgotar o seu pool de workers, precisam do segundo. Implante só um e você está coberto contra metade do problema. Três detalhes separam um limite que funciona de um que é decorativo: - **Use um burst, e use nodelay.** Navegadores reais vêm em rajadas — a visualização de uma única página dispara uma dezena de requisições de assets quase simultâneas. Um limite sem folga estrangula visitantes genuínos enquanto um atacante que se controla bem abaixo do limiar passa direto. - **Limite os endpoints caros separadamente.** A sua página de busca, o formulário de login, a redefinição de senha e qualquer endpoint que escreve no banco de dados merecem um orçamento muito mais apertado do que os seus assets estáticos. Atacantes encontram esses endpoints sem esforço, porque são os que doem. - **Devolva 429, não 503.** O código de status é um sinal para clientes bem-comportados e para os mecanismos de busca de que isto é limitação, não falha — e evita que uma tarde ruim vire um problema de ranqueamento. **O erro que anula tudo isso silenciosamente:** se qualquer coisa fica na frente do seu servidor — um CDN, um load balancer, o seu próprio proxy reverso — então toda requisição chega do endereço *dele*, não do visitante. Um limite de taxa por cliente passa então a contar a internet inteira como um único cliente, e ou não faz nada, ou bane toda a sua audiência de uma vez. Você precisa configurar a sua origem de IP real (no nginx, set_real_ip_from para as faixas do proxy, mais real_ip_header para o cabeçalho que ele envia) *antes* que os limites signifiquem alguma coisa. Restrinja isso às faixas do próprio proxy também: confiar em um cabeçalho fornecido pelo cliente vindo da internet aberta permite que um atacante forje uma identidade nova a cada requisição e passe direto por todo limite que você tem. ## Cache é a mitigação mais barata que você vai implantar Um limite de taxa rejeita trabalho. Um cache faz o trabalho deixar de existir. Para tudo o que um visitante anônimo vê, o cache de página inteira muda a economia do ataque inteiro: uma requisição que custaria uma ida e volta ao banco de dados, a renderização de um template e um worker de PHP vira uma leitura de arquivo medida em microssegundos. O mesmo servidor que travava com quatrocentas requisições dinâmicas por segundo vai servir dezenas de milhares de requisições em cache sem nem perceber. O que importa quando você ativa isso com urgência: - **Cache só para visitantes anônimos.** Faça bypass com base em um cookie de sessão. Servir a página de um usuário logado para outro é um incidente muito pior do que a indisponibilidade que você estava consertando. - **Sirva conteúdo obsoleto de propósito.** O proxy_cache_use_stale do nginx com updating error timeout faz com que, quando o seu backend está com dificuldade, os visitantes recebam uma página um pouco desatualizada em vez de um erro. Durante um ataque, isso é a diferença entre um site que parece bem e um que parece morto. - **Colapse misses duplicados.** O proxy_cache_lock garante que mil requisições simultâneas pela mesma página sem cache produzam uma única requisição ao backend, não mil. Sem isso, um ataque que quebra o cache passa direto por ele e chega ao seu banco de dados com força total. - **Neutralize query strings que quebram o cache.** O truque padrão é acrescentar um ? e um valor aleatório para que toda requisição seja uma chave única e sempre dê miss. Normalize a sua chave de cache para ignorar parâmetros de query que a sua aplicação não usa de verdade. Existe uma assimetria agradável aqui que vale a pena internalizar: toda hora que você gasta em cache também deixa o site mais rápido no seu melhor dia, mais barato de rodar, e melhor em sobreviver ao próprio sucesso. Quase nenhuma outra linha de defesa paga um dividendo quando nada está errado. ## Os tetos que decidem se você vai cair A maioria dos servidores não morre porque ficou sem CPU. Eles morrem porque bateram em um teto invisível que ninguém definiu de propósito — um padrão de uma década atrás que fazia sentido em hardware que ninguém mais usa. Sob ataque, é isto que costuma quebrar primeiro: - **Workers da aplicação.** O pm.max_children do PHP-FPM, a sua contagem de workers Python, o tamanho do seu cluster Node. Esse é o verdadeiro limite de concorrência do seu site. Quando todos estão ocupados, todo visitante adicional entra na fila, e o site fica fora do ar independente do quão ociosa a CPU pareça. Aumente só até onde a memória permitir — fazer swap é pior do que enfileirar. - **A fila de accept.** O net.core.somaxconn e o seu listen backlog decidem quantas conexões podem esperar para ser aceitas. Um backlog pequeno transforma uma rajada sobrevivível em conexões recusadas. - **SYN cookies.** O net.ipv4.tcp_syncookies permite que o kernel responda a um SYN flood sem alocar estado para conexões que nunca vão se completar. Kernels modernos ativam isso por padrão; verifique em vez de presumir, porque não custa nada e evita a inundação mais comum que existe. - **Descritores de arquivo.** Toda conexão é um descritor. O limite padrão de nofile costuma ser mais baixo do que o número de conexões que você está tentando servir, e o modo de falha — accepts falhando enquanto tudo parece saudável — é genuinamente confuso às três da manhã. - **Conexões de banco de dados.** Aumentar a contagem de workers sem aumentar o pool de conexões só move a fila para um lugar mais difícil de ver. Esses dois números precisam ser ajustados juntos. Ajuste isso em um dia tranquilo, não durante um incidente. A vantagem de conhecê-los é que, quando o site cai, você consegue nomear o teto que ele atingiu em vez de adivinhar — e um teto nomeado é um teto resolvido. ## Colocando algo na frente da origem Tudo o que foi dito até aqui acontece no servidor. O próximo passo é decidir se o servidor deve sequer ser a coisa que recebe o tráfego diretamente. Existem três opções honestas, e a resposta certa depende muito mais do que você hospeda do que do que você pode pagar. | Abordagem | O que ela dá a você | O que ela custa a você | | --- | --- | --- | | Origem diretamente exposta, endurecida | Simplicidade, nenhum terceiro, nenhuma terminação de TLS que você não controla | O seu endereço é público e permanente. A camada 7 é inteiramente com você | | CDN comercial ou serviço de limpeza | Capacidade de absorção enorme, uma página de desafio a um clique, cache global | Uma central de reclamações com opinião sobre o seu conteúdo, e uma empresa que consegue ver o seu tráfego. Para projetos offshore ou sensíveis a DMCA, isso pode ser o elo mais fraco de uma configuração cuidadosa em todo o resto | | O seu próprio nó frontal — um VPS pequeno rodando nginx, fazendo proxy para uma origem protegida por firewall | Controle total, nenhum terceiro no caminho da requisição, um endereço que você pode queimar e substituir, e um endereço real que permanece oculto | Seus próprios limites de capacidade, e mais uma máquina para administrar. Duas ou três frentes em redes diferentes tornam consideravelmente mais difícil derrubar | O nó frontal autogerenciado merece mais atenção do que costuma receber, particularmente para quem escolheu hospedagem offshore por motivos com os quais um grande CDN talvez não simpatize. O padrão não tem nada de glamouroso: nós de proxy baratos na frente, origem protegida por firewall para aceitar conexões apenas desses nós, DNS apontando para as frentes. Se uma frente é atacada, você a substitui por um endereço novo em minutos e a origem nem percebe. A versão completa dessa arquitetura — incluindo as seis formas pelas quais um endereço de origem vaza de qualquer jeito — é o tema do nosso guia sobre [ocultar o IP do servidor de origem](https://servghost.com/pt/guides/hiding-your-origin-server-ip). ## Uma origem oculta vale mais do que qualquer filtro Vale a pena dizer isso sem rodeios, porque inverte a prioridade habitual: a mitigação de DDoS mais barata disponível para você é um endereço que o atacante não tem. Filtrar é o que você faz quando isso já falhou. Isso importa mais do que parece, porque endereços de origem vazam constantemente e silenciosamente. Registros de DNS históricos de antes de você colocar um proxy na frente sobrevivem à mudança por anos. E-mails enviados diretamente pela aplicação carregam o endereço nos seus cabeçalhos. Um certificado TLS emitido para o endereço bruto é publicado permanentemente em logs de certificate transparency. Uma página de erro, um redirecionamento, ou um subdomínio obscuro que nunca passou pelo proxy — todos entregam o endereço. Se você colocou um CDN na frente de um servidor que costumava ficar exposto, presuma que o endereço antigo é conhecido até que você o tenha trocado. **O corolário é uma regra de firewall, e é a linha mais valiosa deste guia inteiro:** uma vez que algo passa a ficar na frente, a origem deve recusar conexões nas portas 80 e 443 de tudo, exceto dos endereços dessa frente. Sem isso, o proxy é apenas uma sugestão — qualquer um que descubra o endereço real simplesmente o contorna e ataca você diretamente, e tudo o que você configurou na frente se torna decorativo. ## Escolhendo hardware e localização para que ataques continuem sendo chatos Parte disso é decidida antes mesmo de um ataque acontecer, no momento em que você escolhe um plano. Três propriedades importam muito mais do que a ficha técnica sugere: - **Largura de banda ilimitada.** Em um plano medido, um ataque não é só uma indisponibilidade — é uma fatura. Tráfego que você nunca pediu e não conseguiu recusar ainda assim conta contra uma franquia. Transferência ilimitada converte um risco financeiro em um risco puramente técnico, o que é uma classe de problema muito melhor. - **Se a porta é só sua.** Em um host virtualizado compartilhado, um vizinho sob ataque pode degradar você, e o seu próprio teto de proteção é compartilhado. [Hardware dedicado](https://servghost.com/pt/dedicated) com porta própria elimina os dois efeitos. Para um projeto que espera atenção hostil, esse é o motivo mais claro para subir de um [VPS](https://servghost.com/pt/vps) — mais do que núcleos ou RAM. - **Onde a rede fica.** Uma rede europeia bem conectada, com capacidade de trânsito real, absorve uma inundação que uma rede mal peerada não absorve, e a jurisdição que você escolheu por motivos legais também tem características de rede. Vale a pena checar as duas coisas ao escolher entre as [localizações](https://servghost.com/pt/locations) disponíveis. Também existe um argumento de escala que silenciosamente favorece a simplicidade. Um site estático atrás de um cache em um servidor modesto é extraordinariamente difícil de derrubar; o mesmo conteúdo em um CMS pesado com um endpoint de busca sem cache pode ser quebrado por uma única pessoa determinada com um script. Reduzir o que é dinâmico é uma mitigação, e é de graça. Se o seu projeto realmente vive sob carga sustentada, as nossas notas sobre [hospedagem de alto tráfego](https://servghost.com/pt/use-cases/high-traffic-hosting) cobrem o lado do dimensionamento da mesma questão. ## Cinco coisas para não fazer Os modos de falha aqui são consistentes o bastante para listar, e cada um já custou um fim de semana de alguém: - **Não faça null-route de si mesmo.** Colocar o próprio endereço em blackhole encerra o ataque da forma mais literal possível — ninguém consegue chegar até você, incluindo os seus usuários. É um recurso de último caso para o seu provedor, não uma ação que você toma voluntariamente. - **Não trate o fail2ban como proteção contra DDoS.** É uma ótima ferramenta contra tentativas de força bruta vindas de poucos endereços. Contra uma inundação distribuída, ele reage em minutos a algo que chega em segundos, e uma regra que bane milhares de endereços pode custar mais em processamento de firewall do que o ataque custou a você. - **Não pague resgate.** A esmagadora maioria dos e-mails de extorsão ameaçando um ataque devastador vem de gente sem capacidade nenhuma, que envia milhares de mensagens idênticas. A pequena minoria que consegue cumprir a ameaça vai voltar, porque você provou que paga. - **Não revide.** Além de ser ilegal em praticamente todo lugar, as origens são terceiros comprometidos. Você estaria atacando vítimas, e fazendo isso a partir de um endereço que é inequivocamente seu. - **Não migre em pânico.** Trocar de host no meio de um ataque significa que o endereço novo fica público em minutos e você não tem nenhuma configuração funcionando. Estabilize primeiro, mude deliberadamente depois — e se for mudar, o nosso guia sobre [migrar sem downtime](https://servghost.com/pt/guides/migrate-website-to-offshore-hosting) existe exatamente para que a mudança não seja um segundo incidente. ## A versão curta Sem o raciocínio, o modelo prático cabe em oito linhas: - **Classifique primeiro.** Interface saturada significa volumétrico e pertence ao seu host. Interface tranquila com workers esgotados significa camada 7 e pertence a você. - **Para volumétrico, abra um chamado** com o endereço, o horário e os seus contadores — depois pare de mexer no servidor. - **Faça cache agressivo para visitantes anônimos,** sirva conteúdo obsoleto sob estresse, e colapse misses duplicados. Essa é a mudança de maior alavancagem que você pode fazer. - **Limite a taxa por requisição e por concorrência,** mais apertado nos endpoints que custam mais, e devolva 429. - **Corrija a sua configuração de IP real antes de tudo isso,** ou todo limite por cliente atrás de um proxy é inútil ou catastrófico. - **Conheça os seus tetos** — workers, backlog, descritores, conexões de banco de dados — e aumente-os deliberadamente em um dia tranquilo. - **Mantenha o endereço de origem secreto e protegido por firewall** só para os seus nós frontais. Isso vale mais do que todo filtro combinado. - **Compre largura de banda ilimitada** para que o tráfego que você não pediu nunca seja também uma fatura. Nada disso torna você imune, e quem vende imunidade está vendendo outra coisa. O que isso faz é tirar você da população que é derrubada por um adolescente entediado e colocar você na que exige recursos genuínos e intenção genuína para incomodar — o que, para a esmagadora maioria dos projetos, é indistinguível de estar seguro. O resto é o mesmo trabalho nada glamouroso que torna um servidor bom em tudo o mais: [com hardening desde o primeiro dia](https://servghost.com/pt/guides/first-hour-vps-hardening-checklist), [restaurável no pior deles](https://servghost.com/pt/guides/vps-backup-strategy), e rodando em algum lugar que trata o seu tráfego como o seu próprio negócio. Perguntas frequentes ## DDoS em um servidor pequeno — perguntas frequentes ### 01 "Proteção contra DDoS incluída" significa que estou seguro contra tudo? Não, e a lacuna é precisa, não vaga. A proteção incluída é filtragem em nível de rede: ela descarta inundações volumétricas — SYN floods, amplificação UDP, tempestades de pacotes brutos — a montante, antes que cheguem à sua porta. Essa é a categoria que você genuinamente não conseguiria lidar sozinho, então é a coisa certa a incluir. Ela não inspeciona a sua aplicação, então uma inundação HTTP de alguns milhares de requisições por segundo contra um endpoint caro passa por ela intocada e derruba o seu site enquanto todo gráfico de rede parece normal. A camada 7 é configuração que é sua: cache, limites de taxa e tetos de conexão. ### 02 Como eu distingo um ataque DDoS de um pico de tráfego? Pergunte se o tráfego quer alguma coisa. Visitantes reais, mesmo uma inundação repentina deles vinda de um link popular, requisitam páginas que existem, carregam os assets dessas páginas, chegam com referrers plausíveis e se espalham por muitas redes em um padrão natural. Um ataque geralmente martela um único caminho, ignora os assets, envia user-agents implausíveis ou ausentes, e mostra uma distribuição que parece sintética. Verifique o seu access log por requisições por endereço de cliente e por caminho: se um endpoint domina e mais nada está sendo carregado, é um ataque. Se as mesmas páginas que um humano gostaria de ver estão sendo servidas e os seus referrers são reais, você tem um problema de capacidade com uma causa feliz. ### 03 Qual é a única coisa mais eficaz que eu posso fazer enquanto estou sob ataque? Ative o cache de página inteira para visitantes anônimos, e configure-o para servir conteúdo obsoleto quando o backend estiver com dificuldade. Um limite de taxa rejeita trabalho; um cache faz o trabalho deixar de existir. Uma requisição que custava uma consulta ao banco de dados, a renderização de um template e um worker da aplicação vira uma leitura de arquivo, e o mesmo hardware que travava com algumas centenas de requisições dinâmicas por segundo vai servir dezenas de milhares de requisições em cache. É também a única medida da lista que ajuda igualmente contra tráfego real, então, ao contrário de um limite de taxa, ela não pode se voltar contra os seus próprios usuários. ### 04 Por que o meu limite de taxa do nginx parou de funcionar depois que coloquei um CDN na frente? Porque toda requisição agora chega do endereço do CDN, não do visitante, então um limite por cliente está contando a internet inteira como um único cliente. Dependendo do limiar, ou ele nunca dispara, ou bane todo o seu tráfego de uma vez. Configure a sua origem de IP real — no nginx, as faixas de proxy confiáveis mais o cabeçalho que o proxy envia — para que o limite volte a se basear no visitante de verdade. Restrinja essa confiança às faixas do próprio proxy: se você aceitar um cabeçalho fornecido pelo cliente vindo da internet aberta, um atacante pode forjar uma identidade nova a cada requisição e passar por todo limite que você tem. ### 05 O fail2ban é suficiente para parar um ataque DDoS? Não. O fail2ban lê logs em um intervalo e bane endereços infratores depois de um limiar, o que serve bem para tentativas de força bruta vindas de um pequeno número de origens. Um ataque distribuído chega em segundos, vindo de milhares de endereços que enviam apenas um punhado de requisições cada, então o limiar nunca é atingido, e o tempo de reação é lento demais de qualquer forma. Pior, um conjunto de regras que cresce para dezenas de milhares de entradas pode consumir mais recursos do que o próprio ataque. Mantenha-o para SSH e endpoints de login, e trate inundações com cache, limitação de taxa e um filtro a montante. ### 06 Eu devo usar um CDN, ou rodar o meu próprio proxy reverso na frente? Depende do que você hospeda, não do seu orçamento. Um CDN comercial traz uma capacidade de absorção que você não consegue igualar e uma página de desafio a um clique de distância, mas você herda a central de reclamações dele, e ele consegue ver o seu tráfego — o que, para projetos offshore ou sensíveis a DMCA, costuma ser o elo mais fraco de uma configuração cuidadosa em todo o resto. Os seus próprios nós frontais custam mais trabalho e têm limites reais de capacidade, mas não há terceiros no caminho da requisição, e uma frente que é atacada pode ser substituída por um endereço novo em minutos. De qualquer forma, a origem precisa estar protegida por firewall para aceitar tráfego web só da frente, ou o arranjo inteiro é decorativo. ### 07 Um ataque vai me custar dinheiro além de uptime? Em um plano medido, sim — tráfego que você nunca pediu e não conseguiu recusar ainda assim conta contra a sua franquia de transferência, e uma inundação sustentada pode gerar uma fatura de excedente maior do que um ano de hospedagem. Esse é o motivo prático pelo qual a largura de banda ilimitada importa mais do que parece em uma ficha técnica: ela converte um risco financeiro em um risco puramente técnico. Também vale saber com antecedência que, se um ataque ameaça a infraestrutura compartilhada, os provedores podem fazer um null-route temporário do endereço; isso é prática padrão em todo lugar, não uma falha do seu host em particular. ### 08 Migrar para um host offshore ou sem KYC torna ataques mais prováveis? A escolha da hospedagem em si é neutra; o que você roda é o que atrai atenção. Servidores de jogos, fóruns, streaming, marketplaces, e qualquer coisa com um concorrente ou uma rixa atraem ataques independentemente da jurisdição. O que muda no offshore é o seu recurso: é menos provável que você seja derrubado por ser inconveniente, o que corta dos dois lados — a proteção é técnica, não contratual. Escolha uma localização com capacidade de trânsito genuína, contrate largura de banda ilimitada, mantenha o endereço de origem oculto, e trate a camada 7 como responsabilidade sua desde o primeiro dia, não desde o primeiro incidente. Guias relacionados ## Continue lendo [### Como Escolher uma Jurisdição de Hospedagem Offshore em 2026 Compra Um framework de decisão prático para escolher uma jurisdição offshore: lei de retenção de dados, exposição a MLAT, postura sobre DMCA, velocidade dos tribunais e aplicação real — país a país. FAQ com 6 perguntas](https://servghost.com/pt/guides/choosing-an-offshore-jurisdiction) [### VPS vs Servidor Dedicado para Cargas de Trabalho com Privacidade Crítica Compra Quando um VPS é suficiente, quando a multilocação é um risco, e quando o bare metal é a única resposta honesta. Isolamento de hardware, risco de hypervisor e custo vs modelo de ameaça. FAQ com 6 perguntas](https://servghost.com/pt/guides/vps-vs-dedicated-for-privacy) [### VPN Auto-Hospedada em VPS Sem KYC: WireGuard vs OpenVPN Operações Por que uma VPN auto-hospedada supera os provedores comerciais e como WireGuard e OpenVPN realmente se comparam em privacidade, desempenho e risco operacional em 2026. FAQ com 6 perguntas](https://servghost.com/pt/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090 vs H100 SXM5 para Inferência de IA (e Onde o RTX 5090 se Encaixa) Compra Guia de decisão de compra: qual GPU NVIDIA para LLM auto-hospedado, imagem, vídeo, voz e cargas de trabalho de ajuste fino em 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs H100 duplo — VRAM, throughput, $/token, quando cada um vence. FAQ com 6 perguntas](https://servghost.com/pt/guides/rtx-4090-vs-h100-for-ai-inference) [### RDP Windows Offshore para Trading Forex com MT4 / MT5 / cTrader Operações Guia completo: por que um RDP Windows para trading forex, como escolher uma jurisdição offshore de baixa latência, configuração de MT4 / MT5 / cTrader / Expert Advisor, latência para servidores de corretora e o caminho de checkout sem KYC. FAQ com 6 perguntas](https://servghost.com/pt/guides/offshore-windows-rdp-for-forex-trading) [### Hospedagem DMCA-Ignorada Explicada: O Que Realmente Significa em 2026 Compra O que a hospedagem "DMCA ignorado" realmente oferece, quais jurisdições de fato a sustentam, os tipos de carga que a necessitam, e as armadilhas de direitos autorais que o termo não cobre. FAQ com 6 perguntas](https://servghost.com/pt/guides/dmca-ignored-hosting-explained) [### Registro Anônimo de Domínio com Cripto: Privacidade WHOIS em 2026 Privacidade Um guia prático para 2026 sobre como registrar domínios sem revelar sua identidade: regimes WHOIS por TLD, escolha de registrador, opções de pagamento em cripto e os erros operacionais que ainda assim vão te expor. FAQ com 6 perguntas](https://servghost.com/pt/guides/anonymous-domain-registration-with-crypto) [### Pagamentos Cripto para Hospedagem: Monero vs Bitcoin vs USDT Privacidade Como a escolha da moeda afeta o que seu host aprende sobre você. Privacidade, taxas, finalidade e exposição à análise de blockchain para XMR, BTC e USDT — com uma recomendação clara. FAQ com 6 perguntas](https://servghost.com/pt/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### Hospedagem offshore é realmente anônima? Uma resposta honesta Privacidade Hospedagem offshore sem KYC remove a identidade que um provedor comum coleta — mas "anônimo" depende do pagamento, dos logs do provedor e da sua própria segurança operacional. Veja o que é realmente rastreável. FAQ com 6 perguntas](https://servghost.com/pt/guides/is-offshore-hosting-truly-anonymous) [### A primeira hora de hardening do VPS: um checklist Operações Um checklist concreto e ordenado para proteger um VPS novo em menos de uma hora: chaves SSH, firewall, fail2ban, atualizações automáticas e a redução da superfície de ataque que barra a maioria dos ataques oportunistas. FAQ com 6 perguntas](https://servghost.com/pt/guides/first-hour-vps-hardening-checklist) [### O Que É Hospedagem Sem KYC? Definição, Legalidade e Como Funciona Privacidade A hospedagem sem KYC permite alugar um servidor sem nenhuma verificação de identidade — sem nome, sem e-mail, sem documento. Aqui está exatamente o que isso significa, como funciona tecnicamente, se é legal e como escolher um provedor de verdade. FAQ com 6 perguntas](https://servghost.com/pt/guides/what-is-no-kyc-hosting) [### Hospedagem Offshore É Legal? A Resposta Honesta para 2026 Compra Hospedagem offshore é legal — para você e para o provedor. Aqui está o que o termo realmente significa, onde a linha legal de fato se situa, os mitos que vale descartar, e como utilizá-la de forma responsável. FAQ com 6 perguntas](https://servghost.com/pt/guides/is-offshore-hosting-legal) [### Como Pagar por Hospedagem com Monero (XMR) — Passo a Passo Privacidade Um guia passo a passo para pagar por um VPS ou servidor dedicado com Monero (XMR): por que o XMR é a opção mais privada, como obtê-lo e como funciona o processo de pagamento — da fatura ao servidor em funcionamento em minutos. FAQ com 6 perguntas](https://servghost.com/pt/guides/how-to-pay-for-hosting-with-monero) [### Como Hospedar um Site de Forma Anônima — Guia Prático 2026 Privacidade Um guia prático e em camadas para hospedar um site sem nenhuma identidade vinculada: a conta, o pagamento, o domínio, a jurisdição, a sua conexão e o conteúdo — cada camada explicada. FAQ com 6 perguntas](https://servghost.com/pt/guides/how-to-host-a-website-anonymously) [### Como Configurar uma VPN WireGuard em um VPS — Guia Passo a Passo Operações Monte sua própria VPN privada em um VPS com WireGuard: por que uma VPN auto-hospedada supera as comerciais, o processo completo desde a instalação até o primeiro cliente conectado, e como reforçar a segurança. FAQ com 6 perguntas](https://servghost.com/pt/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### Como Hospedar um LLM em um Servidor GPU — Guia 2026 Operações Execute seu próprio modelo de linguagem em um servidor GPU alugado: por que hospedar seu próprio LLM supera uma API, qual GPU e modelo escolher, a configuração com Ollama ou vLLM, e quanto custa. FAQ com 6 perguntas](https://servghost.com/pt/guides/self-host-an-llm-on-a-gpu-server) [### Hospedagem Bulletproof vs Hospedagem Offshore — Qual é a Diferença? Compra Hospedagem bulletproof e hospedagem offshore são constantemente confundidas — e não são a mesma coisa. Veja a diferença real, por que isso importa e qual das duas você realmente precisa. FAQ com 6 perguntas](https://servghost.com/pt/guides/bulletproof-vs-offshore-hosting) [### Como Comprar um VPS com Bitcoin — Passo a Passo (2026) Compra Um guia completo para iniciantes sobre como comprar um VPS com Bitcoin: como obter BTC, escolher um plano, pagar a fatura e o que você recebe — um servidor funcionando sem cartão e sem nome associado. FAQ com 6 perguntas](https://servghost.com/pt/guides/how-to-buy-a-vps-with-bitcoin) [### Melhores Países para Hospedagem com DMCA Ignorado em 2026 Compra Onde hospedar quando você quer servidores além do alcance fácil das remoções ao estilo americano: as jurisdições que funcionam, o que DMCA ignorado realmente significa e como escolher. FAQ com 6 perguntas](https://servghost.com/pt/guides/best-countries-for-dmca-ignored-hosting) [### Como Hospedar um Serviço Oculto Tor (Site .onion) — Guia 2026 Operações Configure um serviço onion Tor em um VPS: o que é um serviço oculto, por que é a forma mais robusta de hospedagem anônima, o processo completo de configuração e como mantê-lo verdadeiramente anônimo. FAQ com 6 perguntas](https://servghost.com/pt/guides/how-to-host-a-tor-hidden-service) [### Configuração de Servidor de E-mail Offshore — Hospede Seu Próprio E-mail Privado em 2026 Operações Execute seu próprio servidor de e-mail privado em um VPS offshore: por que hospedar e-mail você mesmo, o que é necessário, a configuração prática com uma stack de e-mail completa e como garantir a entregabilidade. FAQ com 6 perguntas](https://servghost.com/pt/guides/offshore-mail-server-setup) [### Guia de Hospedagem de Nó de Criptomoeda — Execute um Nó Blockchain em um VPS Operações Como hospedar um nó blockchain em um servidor: por que executar seu próprio nó, dimensionamento do servidor para Bitcoin, Ethereum, Monero e outros, a configuração e como manter a privacidade. FAQ com 6 perguntas](https://servghost.com/pt/guides/crypto-node-hosting-guide) [### Hospedagem GPU para Stable Diffusion — Rode Seu Próprio Servidor de Imagens Operações Rode o Stable Diffusion no seu próprio servidor GPU: por que hospedar geração de imagens localmente, qual GPU escolher, como configurar com uma interface web e quanto custa em comparação a um serviço hospedado. FAQ com 6 perguntas](https://servghost.com/pt/guides/gpu-hosting-for-stable-diffusion) [### OpSec para Servidores — Como Manter o Anonimato ao Operar um Servidor Privacidade Segurança operacional para quem administra um servidor anônimo: os erros que expõem identidades, os hábitos que os previnem e como manter identidades verdadeiramente separadas. FAQ com 6 perguntas](https://servghost.com/pt/guides/server-opsec-staying-anonymous) [### Guia de Configuração de Seedbox — Monte Sua Própria Seedbox Privada em 2026 Operações Como montar sua própria seedbox em um servidor: o que é uma seedbox, como dimensioná-la, instalar um cliente torrent com interface web e mantê-la privada e segura. FAQ com 6 perguntas](https://servghost.com/pt/guides/seedbox-setup-guide) [### Como Contornar a Censura por DPI com Seu Próprio VPS (Guia 2026) Privacidade Sua VPN parou de funcionar? Como contornar a censura por DPI com seu próprio VPS: o que a inspeção profunda de pacotes realmente detecta, qual dos cinco protocolos de 2026 vence qual tipo de bloqueio, e um passo a passo completo de VLESS+REALITY. FAQ com 6 perguntas](https://servghost.com/pt/guides/bypass-dpi-censorship-with-your-own-vps) [### Criptografia de Disco Completo em um VPS: LUKS e o Que Ela Protege Operações Como criptografar um VPS com LUKS: volumes de dados, raiz completa com desbloqueio via SSH, as configurações que importam em um servidor pequeno, e o que a criptografia de disco realmente impede. FAQ com 8 perguntas](https://servghost.com/pt/guides/full-disk-encryption-on-a-vps) [### Ocultar o IP do Servidor de Origem: CDNs, Proxies Reversos e o Que Ainda Vaza Privacidade Colocar ou não um CDN na frente de um servidor offshore: o que ele esconde, a central de reclamações que você herda, as seis formas como o IP de origem vaza, e como auditar o seu. FAQ com 8 perguntas](https://servghost.com/pt/guides/hiding-your-origin-server-ip) [### Backup de VPS: Criptografado, Externo e Restaurável de Verdade Operações Sua hospedagem não guarda backup. O que realmente destrói servidores, por que backup via push morre junto com a origem, restic vs Borg, e como testar um restore. FAQ com 8 perguntas](https://servghost.com/pt/guides/vps-backup-strategy) [### Hospedar Servidor Matrix Próprio: Federação e Metadados Operações O que um servidor Matrix próprio realmente muda: Synapse ou Conduit, o server_name que você nunca poderá trocar, e a mídia que lota o disco rapidamente. FAQ com 8 perguntas](https://servghost.com/pt/guides/self-host-a-matrix-server) [### Como Migrar um Site para Hospedagem Offshore sem Downtime Operações A ordem que torna a migração de host tediosa: baixar o TTL do DNS dias antes, rodar os dois servidores em paralelo, congelar as escritas por minutos em vez de horas — e limpar o rastro de DNS passivo, Certificate Transparency e WHOIS que a mudança deixa para trás. FAQ com 8 perguntas](https://servghost.com/pt/guides/migrate-website-to-offshore-hosting) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server Operações Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. FAQ com 8 perguntas](https://servghost.com/pt/guides/self-host-a-crypto-payment-gateway) ## Coloque-o em um lugar que filtra as inundações Servidores KVM offshore em sete jurisdições com filtragem DDoS L3/L4, largura de banda ilimitada, root completo e armazenamento NVMe. Sem KYC, pagamento em cripto, implantado minutos após a confirmação da transação. [Ver Planos VPS](https://servghost.com/pt/vps) [Servidores Dedicados](https://servghost.com/pt/dedicated) [Hospedagem offshore](https://servghost.com/pt/offshore-hosting) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servghost.com/#organization", "name": "ServGhost", "url": "https://servghost.com", "description": "VPS e servidores dedicados offshore em 7 jurisdições privacy-friendly. Sem KYC, sem logs, apenas cripto. Privacidade por arquitetura.", "logo": { "@type": "ImageObject", "url": "https://servghost.com/ServGhost.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servghost.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servghost.com/canary", "https://servghost.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servghost.com/#website", "url": "https://servghost.com", "name": "ServGhost", "publisher": { "@id": "https://servghost.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "Proteção DDoS em VPS: Onde o Host Para e a Camada 7 Começa", "description": "O host filtra as inundações de pacotes; as de requisições são suas. Como funciona a limpeza L3/L4, por que a camada 7 passa direto por ela, e o cache, os limites de taxa e os tetos de conexão que mantêm no ar um pequeno servidor offshore sob ataque.", "image": "https://servghost.com/assets/img/guides/surviving-a-ddos-attack-on-your-vps.webp?v=1788769011", "author": { "@type": "Organization", "@id": "https://servghost.com/#editorial", "name": "ServGhost Editorial", "url": "https://servghost.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servghost.com/#organization" } }, "publisher": { "@id": "https://servghost.com/#organization" }, "datePublished": "2026-09-07T00:00:00+00:00", "dateModified": "2026-09-07T00:00:00+00:00", "mainEntityOfPage": "https://servghost.com/guides/surviving-a-ddos-attack-on-your-vps", "inLanguage": "pt", "keywords": "proteção DDoS para VPS, como parar um ataque DDoS no servidor, mitigação de DDoS na camada 7, limitação de taxa no nginx contra DDoS, hospedagem offshore com proteção DDoS, filtragem DDoS L3/L4, mitigação de SYN flood, esconder o IP do servidor de origem", "articleSection": "Operações", "wordCount": 4565 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "\"Proteção contra DDoS incluída\" significa que estou seguro contra tudo?", "acceptedAnswer": { "@type": "Answer", "text": "Não, e a lacuna é precisa, não vaga. A proteção incluída é filtragem em nível de rede: ela descarta inundações volumétricas — SYN floods, amplificação UDP, tempestades de pacotes brutos — a montante, antes que cheguem à sua porta. Essa é a categoria que você genuinamente não conseguiria lidar sozinho, então é a coisa certa a incluir. Ela não inspeciona a sua aplicação, então uma inundação HTTP de alguns milhares de requisições por segundo contra um endpoint caro passa por ela intocada e derruba o seu site enquanto todo gráfico de rede parece normal. A camada 7 é configuração que é sua: cache, limites de taxa e tetos de conexão." } }, { "@type": "Question", "name": "Como eu distingo um ataque DDoS de um pico de tráfego?", "acceptedAnswer": { "@type": "Answer", "text": "Pergunte se o tráfego quer alguma coisa. Visitantes reais, mesmo uma inundação repentina deles vinda de um link popular, requisitam páginas que existem, carregam os assets dessas páginas, chegam com referrers plausíveis e se espalham por muitas redes em um padrão natural. Um ataque geralmente martela um único caminho, ignora os assets, envia user-agents implausíveis ou ausentes, e mostra uma distribuição que parece sintética. Verifique o seu access log por requisições por endereço de cliente e por caminho: se um endpoint domina e mais nada está sendo carregado, é um ataque. Se as mesmas páginas que um humano gostaria de ver estão sendo servidas e os seus referrers são reais, você tem um problema de capacidade com uma causa feliz." } }, { "@type": "Question", "name": "Qual é a única coisa mais eficaz que eu posso fazer enquanto estou sob ataque?", "acceptedAnswer": { "@type": "Answer", "text": "Ative o cache de página inteira para visitantes anônimos, e configure-o para servir conteúdo obsoleto quando o backend estiver com dificuldade. Um limite de taxa rejeita trabalho; um cache faz o trabalho deixar de existir. Uma requisição que custava uma consulta ao banco de dados, a renderização de um template e um worker da aplicação vira uma leitura de arquivo, e o mesmo hardware que travava com algumas centenas de requisições dinâmicas por segundo vai servir dezenas de milhares de requisições em cache. É também a única medida da lista que ajuda igualmente contra tráfego real, então, ao contrário de um limite de taxa, ela não pode se voltar contra os seus próprios usuários." } }, { "@type": "Question", "name": "Por que o meu limite de taxa do nginx parou de funcionar depois que coloquei um CDN na frente?", "acceptedAnswer": { "@type": "Answer", "text": "Porque toda requisição agora chega do endereço do CDN, não do visitante, então um limite por cliente está contando a internet inteira como um único cliente. Dependendo do limiar, ou ele nunca dispara, ou bane todo o seu tráfego de uma vez. Configure a sua origem de IP real — no nginx, as faixas de proxy confiáveis mais o cabeçalho que o proxy envia — para que o limite volte a se basear no visitante de verdade. Restrinja essa confiança às faixas do próprio proxy: se você aceitar um cabeçalho fornecido pelo cliente vindo da internet aberta, um atacante pode forjar uma identidade nova a cada requisição e passar por todo limite que você tem." } }, { "@type": "Question", "name": "O fail2ban é suficiente para parar um ataque DDoS?", "acceptedAnswer": { "@type": "Answer", "text": "Não. O fail2ban lê logs em um intervalo e bane endereços infratores depois de um limiar, o que serve bem para tentativas de força bruta vindas de um pequeno número de origens. Um ataque distribuído chega em segundos, vindo de milhares de endereços que enviam apenas um punhado de requisições cada, então o limiar nunca é atingido, e o tempo de reação é lento demais de qualquer forma. Pior, um conjunto de regras que cresce para dezenas de milhares de entradas pode consumir mais recursos do que o próprio ataque. Mantenha-o para SSH e endpoints de login, e trate inundações com cache, limitação de taxa e um filtro a montante." } }, { "@type": "Question", "name": "Eu devo usar um CDN, ou rodar o meu próprio proxy reverso na frente?", "acceptedAnswer": { "@type": "Answer", "text": "Depende do que você hospeda, não do seu orçamento. Um CDN comercial traz uma capacidade de absorção que você não consegue igualar e uma página de desafio a um clique de distância, mas você herda a central de reclamações dele, e ele consegue ver o seu tráfego — o que, para projetos offshore ou sensíveis a DMCA, costuma ser o elo mais fraco de uma configuração cuidadosa em todo o resto. Os seus próprios nós frontais custam mais trabalho e têm limites reais de capacidade, mas não há terceiros no caminho da requisição, e uma frente que é atacada pode ser substituída por um endereço novo em minutos. De qualquer forma, a origem precisa estar protegida por firewall para aceitar tráfego web só da frente, ou o arranjo inteiro é decorativo." } }, { "@type": "Question", "name": "Um ataque vai me custar dinheiro além de uptime?", "acceptedAnswer": { "@type": "Answer", "text": "Em um plano medido, sim — tráfego que você nunca pediu e não conseguiu recusar ainda assim conta contra a sua franquia de transferência, e uma inundação sustentada pode gerar uma fatura de excedente maior do que um ano de hospedagem. Esse é o motivo prático pelo qual a largura de banda ilimitada importa mais do que parece em uma ficha técnica: ela converte um risco financeiro em um risco puramente técnico. Também vale saber com antecedência que, se um ataque ameaça a infraestrutura compartilhada, os provedores podem fazer um null-route temporário do endereço; isso é prática padrão em todo lugar, não uma falha do seu host em particular." } }, { "@type": "Question", "name": "Migrar para um host offshore ou sem KYC torna ataques mais prováveis?", "acceptedAnswer": { "@type": "Answer", "text": "A escolha da hospedagem em si é neutra; o que você roda é o que atrai atenção. Servidores de jogos, fóruns, streaming, marketplaces, e qualquer coisa com um concorrente ou uma rixa atraem ataques independentemente da jurisdição. O que muda no offshore é o seu recurso: é menos provável que você seja derrubado por ser inconveniente, o que corta dos dois lados — a proteção é técnica, não contratual. Escolha uma localização com capacidade de trânsito genuína, contrate largura de banda ilimitada, mantenha o endereço de origem oculto, e trate a camada 7 como responsabilidade sua desde o primeiro dia, não desde o primeiro incidente." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Início", "item": "https://servghost.com/pt/" }, { "@type": "ListItem", "position": 2, "name": "Guias de Hospedagem com Privacidade", "item": "https://servghost.com/pt/guides" }, { "@type": "ListItem", "position": 3, "name": "Proteção DDoS em VPS: Onde o Host Para e a Camada 7 Começa", "item": "https://servghost.com/pt/guides/surviving-a-ddos-attack-on-your-vps" } ] } ```