A proposta é de Jeremy Howard, da Answer.AI, em setembro de 2024. E ela resolve um problema concreto: quando um assistente de IA precisa entender o seu site, ele encontra HTML cheio de menu, rodapé, scripts e banner de cookie — e a janela de contexto dele não cabe tudo isso. O llms.txt entrega o essencial já limpo.

Vamos ser diretos sobre o estágio disso: é uma convenção emergente, não um padrão consolidado. Mais adiante mostramos os números reais de adoção, que são modestos. Mas o custo de implementar é quase zero, o Lighthouse do Chrome já verifica o arquivo, e empresas como Anthropic, Stripe e Zapier já publicaram o deles.

O que é o llms.txt

É um arquivo de texto simples, formatado em Markdown, publicado na raiz do domínio. Ele contém o nome do site, um resumo do que ele faz, e uma lista organizada das páginas mais importantes — cada uma com uma descrição de uma linha.

A ideia é a de uma lista de leitura recomendada. Em vez de o modelo de IA rastrear cinquenta páginas para descobrir o que o seu site é, ele lê um arquivo de três kilobytes e já sabe.

Markdown foi escolhido por um motivo específico: é o formato que os modelos de linguagem processam melhor. Sem tags de fechamento, sem atributos, sem CSS — só título, parágrafo e link. É a mesma sintaxe dos README do GitHub.

Por que esse arquivo existe

O problema que ele resolve é a janela de contexto.

Todo modelo de IA tem um limite de quanto texto consegue processar de uma vez. Uma página web moderna tem, além do conteúdo, o menu completo, o rodapé com trinta links, scripts de analytics, aviso de cookies, widgets de rede social e marcação de tema. O conteúdo útil pode ser 10% do arquivo.

Quando um agente de IA precisa responder algo sobre o seu site, ele gasta a janela de contexto — e tempo, e custo de processamento — atravessando esse ruído. Com frequência, desiste antes de chegar ao que importa.

O llms.txt corta o caminho. E há um efeito colateral relevante: quanto menos o modelo precisa adivinhar, menor a chance de ele inventar informação sobre o seu negócio.

llms.txt, robots.txt e sitemap.xml: qual a diferença

Os três são arquivos na raiz do site, e é fácil confundir a função de cada um.

A distinção essencial: o sitemap.xml diz “aqui está tudo”. O llms.txt diz “comece por aqui”. Um é exaustivo, o outro é editorial — e é justamente a seleção que o torna útil.

E o llms.txt não controla acesso. Se você quer impedir que um bot de IA rastreie seu site, isso é trabalho do robots.txt — com regras para GPTBot, ClaudeBot, Google-Extended e afins. O llms.txt pressupõe que o acesso é permitido e apenas organiza.

A especificação, na prática

O formato é deliberadamente simples. São cinco regras.

1. Um H1, com o nome do site

Exatamente um, e é o único elemento obrigatório da especificação.

# Homehost

2. Um blockquote imediatamente depois

Uma ou duas frases dizendo o que o site é.

> Hospedagem de sites, e-mail e domínios no Brasil, com servidores LiteSpeed e suporte em português.

Este é o elemento mais importante do arquivo, e o mais esquecido. Os modelos de IA extraem esse blockquote literalmente como resposta para “o que é essa empresa”. Escreva-o como se fosse a única frase que a IA vai ler sobre você — porque frequentemente é.

3. Parágrafos livres, se necessário

Depois do blockquote, você pode acrescentar contexto em prosa. Ressalvas, o que o site não faz, informação que evita mal-entendido.

4. Seções em H2 com listas de links

Agrupe as páginas por função. O formato de cada linha é fixo:

- [Título da página](https://url-absoluta): descrição de uma linha

5. Uma seção ## Optional no fim

Conteúdo de prioridade menor, que o modelo pode ignorar se a janela de contexto estiver apertada. É a única seção com significado especial na especificação.

Três regras técnicas que valem repetir:

URLs absolutas, sempre com https://. Caminho relativo não funciona.
Uma linha por link. Sem aninhamento, sem sublistas.
Abaixo de 5 KB. O limite prático é 10 KB, mas as boas práticas convergiram para arquivos curtos.

Exemplo completo, comentado

Este é um llms.txt real para uma empresa de hospedagem:

# Homehost

> Hospedagem de sites, e-mail profissional e registro de domínios no
> Brasil. Servidores LiteSpeed com armazenamento NVMe, SSL grátis e
> suporte técnico em português.

Fundada em 2008, atende de sites pessoais a lojas virtuais e
aplicações Python/Django. Servidores localizados no Brasil, o que
reduz a latência para visitantes brasileiros.
Não oferecemos serviços de criação de sites nem de marketing digital.

## Produtos

- [Hospedagem de sites](https://www.homehost.com.br/hospedagem-de-sites/): planos compartilhados a partir de R$ 7,90/mês, com cPanel e SSL grátis
- [Hospedagem WordPress](https://www.homehost.com.br/hospedagem-wordpress/): otimizada para WordPress, com instalação em dois cliques
- [Registro de domínios](https://www.homehost.com.br/registro-de-dominio/): .com.br e domínios internacionais
- [Hospedagem de e-mails](https://www.homehost.com.br/hospedagem-de-e-mails/): caixas no seu domínio, com antispam
- [Hospedagem cloud](https://www.homehost.com.br/hospedagem-cloud/): recursos dedicados e escaláveis

## Guias técnicos

- [Como instalar o WordPress](https://www.homehost.com.br/blog/wordpress/como-instalar-o-wordpress/): passo a passo pelo Softaculous
- [Como descobrir a versão do MySQL](https://www.homehost.com.br/blog/tutoriais/como-descobrir-a-versao-do-mysql/): cinco métodos, do SQL ao painel
- [Erros comuns de SEO](https://www.homehost.com.br/blog/seo/erros-comuns-de-seo/): os cinco que mais derrubam sites
- [O que é TTFB](https://www.homehost.com.br/blog/seo/ttfb/): a métrica de velocidade que depende do servidor

## Informações da empresa

- [Suporte e contato](https://www.homehost.com.br/suporte): telefones, chat e tutoriais
- [Registro de domínios](https://www.homehost.com.br/whois-registro): consulta WHOIS de domínios .br

## Optional

- [Blog completo](https://www.homehost.com.br/blog/): mais de 300 artigos técnicos
- [Termos de uso](https://www.homehost.com.br/termos/): condições contratuais

Repare em duas coisas.

A linha “Não oferecemos serviços de criação de sites” existe de propósito. Dizer o que você não faz previne que a IA recomende você para algo errado — e é o tipo de informação que nenhum sitemap transmite.

E as descrições incluem número quando há. “a partir de R$ 7,90/mês” é mais útil que “planos acessíveis”, porque é o que a IA pode citar.

Confirme cada URL antes de publicar. Um llms.txt com link quebrado é pior que nenhum arquivo.

O que colocar, e o que deixar de fora

Escolha de 10 a 20 páginas. Mais que isso e a curadoria perde o sentido — você volta a entregar um inventário.

O que quase sempre entra:

A home, com a descrição mais clara possível do negócio.
As páginas de produto ou serviço, com preço quando houver.
Os guias de referência — o conteúdo perene que responde perguntas.
A página de contato, para a IA saber como encaminhar.
Sobre a empresa, se houver informação de credibilidade — tempo de mercado, infraestrutura, certificações.

O que deixar de fora:

Páginas de login e área de cliente. A IA não vai entrar, e listá-las gasta espaço.
Carrinho, checkout, resultados de busca interna. Conteúdo dinâmico não serve.
Posts de blog datados — promoções, notícias, “novidades de 2024”. Envelhecem e você não vai atualizar o arquivo.
Páginas legais, a menos que na seção ## Optional.
Conteúdo fino. Se a página não responde nada por si, ela não ajuda a IA a entender você.

O llms-full.txt

Existe um arquivo companheiro, opcional: o llms-full.txt.

Enquanto o llms.txt lista links, o llms-full.txt contém o conteúdo inteiro — todo o texto relevante do site, concatenado num único arquivo Markdown. A vantagem é que o agente busca uma vez e tem tudo; a desvantagem é o tamanho, que pode chegar a centenas de kilobytes.

Para quem faz sentido: documentação técnica, base de conhecimento, sites onde o conteúdo é o produto. A Mintlify gera os dois automaticamente para as documentações que hospeda.

Para quem não faz: site institucional, blog grande, loja virtual. Nesses casos o llms.txt sozinho é o certo.

Como criar o llms.txt no WordPress

Não existe função nativa, e você não precisa de plugin. São três caminhos, do mais simples ao mais robusto.

Opção 1 — Upload direto pelo painel (recomendado)

É o método mais confiável, porque o arquivo passa a existir de verdade no servidor.

1. Escreva o conteúdo num editor de texto simples — Notepad, VS Code, TextEdit em modo texto puro. Não use Word, que insere caracteres invisíveis.

2. Salve como llms.txt, com codificação UTF-8.

3. Acesse o gerenciador de arquivos do seu painel — no cPanel é o Gerenciador de Arquivos, no DirectAdmin é o File Manager.

4. Entre na pasta public_html. É a raiz do site: os arquivos dali aparecem diretamente em seusite.com.br/.

5. Clique em Upload e envie o arquivo.

6. Abra https://seusite.com.br/llms.txt no navegador. Se o texto aparecer, está pronto.

Um detalhe que trava muita gente: se o WordPress estiver instalado numa subpasta, o public_html ainda é a raiz do domínio — o arquivo vai ali, não dentro da pasta do WordPress.

Opção 2 — Plugin

Alguns plugins de SEO já criam o arquivo, e existem plugins dedicados. A vantagem é gerar automaticamente a partir do conteúdo publicado. A desvantagem é que a curadoria automática tende a incluir tudo — o que contraria o propósito do arquivo.

Se usar plugin, revise o resultado. Um llms.txt com duzentos links não é um llms.txt.

Opção 3 — Via .htaccess, servindo de outro lugar

Para quem quer versionar o arquivo junto do tema, é possível servir com uma regra de rewrite. É a opção mais frágil e a menos recomendada.

Como criar em outras plataformas

Site estático (HTML, Jekyll, Hugo, Astro): coloque o arquivo na pasta pública — /public, /static ou a raiz, conforme o gerador.

Next.js / React: na pasta /public.

Shopify: não permite arquivos na raiz por padrão. É preciso usar um app ou servir por um proxy.

Wix e Squarespace: também não permitem. Verifique se a plataforma já oferece a função nativamente.

Como verificar se está funcionando

O básico

Abra https://seusite.com.br/llms.txt. O navegador deve mostrar texto puro. Se baixar como arquivo, o Content-Type está errado — deveria ser text/plain ou text/markdown.

Valide o Markdown. Um H1, blockquote logo depois, H2 nas seções, links no formato correto.

Teste cada URL. Link quebrado num arquivo que se propõe a orientar é o pior tipo de erro.

O Lighthouse já verifica

Este é o sinal mais relevante de que o padrão vai a algum lugar: o Lighthouse do Chrome, na categoria de navegação agêntica, audita a existência do llms.txt.

Se o arquivo não existe, a auditoria fica como Não aplicável — porque publicá-lo é opcional. Se existe mas retorna erro de servidor, o Lighthouse aponta.

Cabeçalhos HTTP para descoberta

Opcionalmente, você pode anunciar o arquivo nos cabeçalhos de resposta:

Link: </llms.txt>; rel="llms-txt"
X-Llms-Txt: /llms.txt

O primeiro segue o formato padrão de descoberta de recursos; o segundo é uma conveniência que algumas ferramentas verificam.

Medindo o efeito real

Nos logs do servidor. Filtre por user agents de bots de IA — GPTBot, ClaudeBot, PerplexityBot, Google-Extended — e veja se algum requisitou o /llms.txt. Na Homehost, os logs de acesso estão disponíveis pelo painel.

Nas citações. Pergunte ao ChatGPT, ao Claude e ao Perplexity sobre o seu negócio antes e depois de publicar. É medição imprecisa, mas é a única direta.

A parte honesta: quem realmente lê isso

Nenhum artigo sobre llms.txt deveria omitir esses números.

A OtterlyAI monitorou 90 dias de tráfego de bots de IA em sites com o arquivo publicado. De mais de 62.100 visitas de bots, apenas 84 foram ao /llms.txt — cerca de 0,13%. Os agentes descobriram o conteúdo pelas páginas normais, como sempre fizeram.

E a adoção é pequena: por volta de meados de 2025, cerca de 951 domínios tinham publicado o arquivo. É uma fração mínima da web.

Nenhum grande provedor de IA se comprometeu oficialmente a usar o llms.txt como sinal. A Profound encontrou evidência de bots da Microsoft e da OpenAI acessando o arquivo, mas nada como uma adoção declarada.

Então por que fazer?

Porque o custo é quase zero e o risco é nulo. Vinte minutos, um arquivo de texto, nenhuma alteração no site. Não há cenário em que publicar um llms.txt correto piore sua situação.

Porque o Lighthouse já verifica. Quando a ferramenta de auditoria do Google inclui algo, isso raramente é acidente.

Porque quem adotou não é aleatório. Anthropic publica o dela em anthropic.com/llms.txt. Stripe, Zapier, Cursor, Mintlify e FastHTML também. São empresas que constroem com IA e conhecem o terreno.

E porque o exercício vale por si. Escrever um llms.txt obriga você a responder, em três frases, o que o seu site faz e quais são as cinco páginas que importam. Muita gente descobre nesse processo que não sabia responder.

O enquadramento realista: é uma aposta barata numa convenção que pode se firmar. Não é um canal de tráfego hoje.

Cinco erros comuns

Esquecer o blockquote. É o erro de maior impacto, porque é exatamente o trecho que os modelos extraem como resposta sobre o seu negócio.

Listar cinquenta páginas. Vira sitemap. A seleção é o valor.

Usar caminho relativo. - [Home](/): página inicial não funciona. URL absoluta com https://, sempre.

Descrição genérica. “Página de produtos” não diz nada. “Planos de hospedagem compartilhada a partir de R$ 7,90/mês, com cPanel e SSL grátis” diz.

Publicar e esquecer. Se as URLs mudarem, o arquivo passa a apontar para 404. Revise a cada seis meses, ou sempre que reestruturar o site.

Perguntas frequentes

O que é o llms.txt?

Um arquivo em Markdown publicado na raiz do site que orienta modelos de IA sobre o conteúdo dele. Contém o nome do site, um resumo em blockquote e listas de links para as páginas mais importantes, cada uma com uma descrição curta. A proposta é de Jeremy Howard, da Answer.AI, de setembro de 2024.

O llms.txt é obrigatório?

Não. É uma convenção opcional e emergente, sem adoção oficial declarada por nenhum grande provedor de IA. O Lighthouse do Chrome já verifica sua existência, mas marca a auditoria como não aplicável quando o arquivo não existe — justamente porque publicá-lo é opcional.

Qual a diferença entre llms.txt e robots.txt?

O robots.txt controla acesso: permite ou bloqueia rastreadores em diretórios. O llms.txt não controla nada — ele seleciona e descreve o conteúdo de maior valor para que a IA priorize. Um é permissão, o outro é curadoria. Se você quer bloquear bots de IA, isso é trabalho do robots.txt.

E qual a diferença do sitemap.xml?

O sitemap lista todas as URLs do site, em XML, para buscadores. O llms.txt lista as mais importantes, em Markdown, para modelos de IA — com uma descrição de cada uma. O sitemap é um inventário; o llms.txt é editorial.

Onde exatamente o arquivo deve ficar?

Na raiz do domínio, acessível em https://seusite.com.br/llms.txt. Em hospedagem compartilhada, isso significa a pasta public_html. Se o WordPress estiver numa subpasta, o arquivo ainda vai no public_html, não na pasta do WordPress.

Preciso de plugin para criar no WordPress?

Não. É um arquivo de texto que você escreve e envia pelo gerenciador de arquivos do painel ou por FTP. Existem plugins que geram automaticamente, mas eles tendem a incluir páginas demais — o que contraria o propósito do arquivo. Se usar um, revise o resultado.

Quantas páginas devo listar?

De 10 a 20. A especificação não impõe limite, mas as boas práticas convergiram para arquivos abaixo de 5 KB. Listar cinquenta páginas transforma o arquivo num sitemap e elimina o valor da curadoria.

O que é o llms-full.txt?

Um arquivo companheiro opcional que contém o conteúdo inteiro do site concatenado em Markdown, em vez de apenas links. Serve para documentações técnicas e bases de conhecimento, onde o agente busca uma vez e tem tudo. Para site institucional ou blog, o llms.txt sozinho é suficiente.

O llms.txt melhora meu SEO no Google?

Não diretamente. Ele não é um fator de ranqueamento e o Google não o usa para posicionar páginas na busca tradicional. O objetivo é outro: como sua marca aparece e é descrita em respostas geradas por IA.

Os bots de IA realmente leem esse arquivo?

Pouco, por enquanto. Um estudo da OtterlyAI acompanhou 90 dias de tráfego de bots de IA e encontrou apenas 84 requisições ao /llms.txt em mais de 62.100 visitas — cerca de 0,13%. Há evidência de bots da Microsoft e da OpenAI acessando o arquivo, mas nenhuma adoção oficial declarada.

Então vale a pena criar?

Vale, por três motivos. O custo é praticamente zero e não há cenário em que publicar um arquivo correto piore sua situação. O Lighthouse do Chrome já verifica sua existência, o que sugere direção. E empresas como Anthropic, Stripe e Zapier já publicaram o deles. É uma aposta barata numa convenção que pode se firmar — não um canal de tráfego hoje.

Quem criou o padrão?

Jeremy Howard, cofundador da Answer.AI e da fast.ai, em setembro de 2024. A especificação completa está em llmstxt.org.

Com que frequência devo atualizar?

A cada seis meses, ou sempre que reestruturar o site. O risco de esquecer é o arquivo passar a apontar para URLs que retornam 404 — o que é pior que não ter arquivo nenhum.

Conclusão

O llms.txt é uma das intervenções de melhor relação custo-benefício disponíveis hoje — não porque o retorno seja garantido, mas porque o custo é quase nulo. Vinte minutos, um arquivo de texto, nenhuma alteração no site.

Três coisas decidem se ele funciona. O blockquote, que é o trecho que a IA vai extrair literalmente como resposta sobre o seu negócio — escreva-o como se fosse a única frase que ela vai ler. A seleção, porque listar tudo é o mesmo que não selecionar nada. E as descrições concretas, com número e especificidade, porque é isso que a IA consegue citar.

E o realismo: hoje os bots de IA acessam esse arquivo raramente. Isso pode mudar, e há sinais de que mudará — o Lighthouse já verifica, e as empresas que constroem com IA já publicaram o deles. Mas quem promete tráfego imediato está vendendo o que não tem.

A melhor razão para fazer talvez seja outra. Escrever um llms.txt obriga você a responder, em três frases, o que o seu site é — e a escolher as dez páginas que representam isso. Se essa parte for difícil, você acabou de descobrir algo mais valioso que o arquivo.

O post llms.txt: o que é, como criar e por que vale a pena apareceu primeiro em Homehost.

O modelo OSI (Open Systems Interconnection) divide a comunicação em rede em sete camadas, da transmissão física dos bits até a aplicação que o usuário enxerga. Ele foi publicado pela ISO em 1984 como padrão internacional, e sua função é conceitual: dar um vocabulário comum para descrever onde cada tecnologia atua e onde um problema acontece.

Na prática, quase nenhuma rede é implementada exatamente segundo o OSI — a internet roda sobre o modelo TCP/IP. Mas o OSI continua sendo a referência usada para ensinar, diagnosticar e conversar sobre redes, porque separa com clareza responsabilidades que o TCP/IP agrupa.

O que é o modelo OSI

O OSI — sigla de Open Systems Interconnection, ou Interconexão de Sistemas Abertos — é um modelo de referência que descreve como sistemas diferentes se comunicam em rede, dividindo o processo em sete camadas independentes.

A ideia central é a separação de responsabilidades. Cada camada faz uma coisa só, oferece um serviço à camada acima e usa o serviço da camada abaixo — sem precisar saber como as outras funcionam internamente. Uma aplicação que envia um e-mail não precisa saber se a conexão é por cabo, Wi-Fi ou fibra; isso é problema da camada 1.

Essa organização traz três vantagens práticas:

• Interoperabilidade. Fabricantes diferentes constroem equipamentos que conversam entre si, desde que respeitem a interface de cada camada
• Diagnóstico estruturado. Quando algo falha, é possível isolar em qual camada o problema está, em vez de investigar tudo ao mesmo tempo
• Vocabulário comum. “Firewall de camada 7” e “balanceador de camada 4” são expressões que só fazem sentido por causa desse modelo

A origem do modelo OSI

O modelo nasceu de um problema concreto dos anos 1970: cada fabricante tinha sua própria arquitetura de rede — a IBM tinha a SNA, a DEC tinha a DECnet — e equipamentos de marcas diferentes simplesmente não se comunicavam.

O trabalho começou em 1977, na ISO (International Organization for Standardization), com o objetivo de criar um padrão aberto e neutro. O resultado foi publicado em 1984 como a norma ISO/IEC 7498-1, definindo formalmente as sete camadas.

Há uma ironia histórica: o modelo OSI venceu como referência conceitual e perdeu como implementação. Enquanto o comitê da ISO trabalhava, o conjunto de protocolos TCP/IP — desenvolvido no âmbito da ARPANET, mais simples e já funcionando — se espalhou e se tornou o padrão de fato da internet. O OSI sobreviveu como a linguagem que todo mundo usa para descrever redes, inclusive as que rodam TCP/IP.

As 7 camadas do modelo OSI

Camada 1 — Física

A camada mais baixa lida com a transmissão dos bits pelo meio físico. Ela não sabe o que os bits significam: sua função é converter zeros e uns em sinais elétricos, pulsos de luz ou ondas de rádio, e transmiti-los.

Do que trata: tipo de cabo, conectores, tensões, frequências, taxa de transmissão, topologia física.

Exemplos: cabo de par trançado, fibra óptica, conectores RJ-45, Wi-Fi (a parte de rádio), Bluetooth, USB.

Problemas típicos: cabo rompido, conector mal encaixado, interferência eletromagnética, sinal fraco.

Camada 2 — Enlace de dados

Organiza os bits em quadros e cuida da comunicação entre dispositivos diretamente conectados — dentro da mesma rede local. É aqui que vive o endereço MAC, o identificador físico de cada placa de rede.

Do que trata: endereçamento físico, detecção de erros, controle de acesso ao meio.

Exemplos: Ethernet, Wi-Fi (802.11), PPP, switches, ARP.

Problemas típicos: conflito de endereço MAC, loop de switch, quadros corrompidos.

Um detalhe útil: a camada 2 é dividida em duas subcamadas — LLC (controle lógico do enlace) e MAC (controle de acesso ao meio).

Camada 3 — Rede

Responsável pelo endereçamento lógico e pelo roteamento — ou seja, por levar os dados de uma rede a outra, possivelmente atravessando dezenas de redes intermediárias. É a camada do endereço IP.

Do que trata: endereçamento lógico, escolha de rota, fragmentação de pacotes.

Exemplos: IP (IPv4 e IPv6), ICMP, roteadores, protocolos de roteamento como OSPF e BGP.

Problemas típicos: rota incorreta, IP duplicado, DNS resolvendo para o endereço errado.

A unidade de dados aqui se chama pacote, e o comando traceroute mostra exatamente o caminho que ele percorre entre roteadores.

Camada 4 — Transporte

Garante a entrega fim a fim entre os dois computadores que estão conversando. É onde ficam as portas — o número que identifica qual aplicação deve receber os dados.

Do que trata: segmentação, controle de fluxo, controle de erros, multiplexação por porta.

Exemplos: TCP, UDP.

A distinção entre os dois protocolos é o ponto central desta camada:

Camada 5 — Sessão

Estabelece, mantém e encerra o diálogo entre duas aplicações. Ela cuida de coisas como manter o usuário logado durante uma navegação, ou retomar uma transferência do ponto onde parou.

Do que trata: abertura e encerramento de sessões, pontos de sincronização, controle de diálogo.

Exemplos: NetBIOS, RPC, PPTP.

Na prática, é a camada mais difícil de identificar isoladamente — no TCP/IP suas funções acabaram distribuídas entre outras camadas.

Camada 6 — Apresentação

Traduz os dados para um formato que a aplicação entenda. É onde acontecem criptografia, compressão e conversão de codificação.

Do que trata: formato dos dados, criptografia, compressão, conversão de charset.

Exemplos: TLS/SSL, JPEG, PNG, MP3, ASCII, UTF-8.

É por causa desta camada que um arquivo enviado de um sistema chega legível em outro, mesmo que os dois usem representações internas diferentes.

Camada 7 — Aplicação

A camada mais próxima do usuário. Ela não é o programa em si — é a interface entre o programa e a rede, definindo os protocolos que a aplicação usa para se comunicar.

Do que trata: os protocolos que aplicações usam para trocar dados.

Exemplos: HTTP e HTTPS, SMTP, IMAP, POP3, FTP, DNS, SSH.

Problemas típicos: erro 404, falha de autenticação, erro 500 — tudo que acontece depois que a conexão de rede já funciona.

Tabela de referência das 7 camadas

Como os dados percorrem as camadas: o encapsulamento

Quando você envia uma mensagem, ela desce pelas sete camadas no seu computador e sobe pelas sete no computador de destino.

A cada camada que desce, os dados recebem um cabeçalho com as informações que aquela camada precisa — endereço, número de porta, controle de erro. Esse processo se chama encapsulamento, e funciona como envelopes dentro de envelopes.

Na descida: a camada 7 entrega os dados à 6, que acrescenta seu cabeçalho e entrega à 5, e assim por diante até a camada 1 transmitir os bits.

Na subida: o computador de destino faz o inverso — cada camada remove o cabeçalho correspondente e passa o conteúdo para a camada acima, até a aplicação receber os dados originais.

A elegância do modelo está aqui: cada camada do destino conversa logicamente com a mesma camada da origem, ignorando tudo que acontece abaixo.

Modelo OSI e TCP/IP: quais as diferenças

Esta é a comparação que mais gera dúvida, e a resposta curta é: o OSI é o modelo teórico, o TCP/IP é o que efetivamente roda na internet.

O TCP/IP surgiu antes, com um objetivo prático, e agrupa em quatro camadas o que o OSI separa em sete.

As diferenças de fundo:

Por que aprender os dois? Porque o vocabulário do dia a dia mistura os dois modelos. Ninguém diz “firewall de camada de internet” — diz “camada 3”, que é linguagem OSI, mesmo descrevendo uma rede TCP/IP. Nosso guia sobre TCP/IP detalha o funcionamento dos protocolos.

Como memorizar as sete camadas

Mnemônicos são a forma clássica de fixar a ordem. Em português, de baixo para cima:

Física, Enlace, Rede, Transporte, Sessão, Apresentação, Aplicação
→ “Fui Entender Redes, Tive Sérias Aulas Avançadas”

Em inglês, o mais conhecido, de cima para baixo:

All People Seem To Need Data Processing
(Application, Presentation, Session, Transport, Network, Data Link, Physical)

Onde cada tecnologia atua

Aqui o modelo deixa de ser teoria e vira ferramenta prática — é o que permite dizer com precisão o que cada equipamento faz.

Camada 1: hubs e repetidores. Apenas retransmitem sinal, sem entender nada do conteúdo.

Camada 2: switches. Encaminham quadros com base no endereço MAC, dentro da rede local.

Camada 3: roteadores. Decidem por qual caminho o pacote segue entre redes diferentes.

Camada 3 e 4: firewalls de rede. Bloqueiam por endereço IP e por porta — eles veem de onde vem e para onde vai, mas não o conteúdo.

Camada 7: WAF — firewall de aplicação. Lê o conteúdo da requisição HTTP e bloqueia padrões de ataque como injeção de SQL. É a diferença que explica por que um firewall comum não protege um site: o ataque chega pela porta legítima.

Balanceadores de carga existem em duas variedades: os de camada 4 distribuem por IP e porta; os de camada 7 decidem com base no conteúdo da requisição, como a URL ou o cabeçalho.

Por que o modelo OSI ainda importa

Faz sentido perguntar por que estudar um modelo que ninguém implementa. Três razões:

É a linguagem padrão do diagnóstico. Quando um site não carrega, a pergunta profissional é “em que camada está o problema?”. Se o ping responde, as camadas 1 a 3 funcionam. Se a porta 443 aceita conexão, a 4 funciona. Se o navegador retorna erro 500, o problema é na 7. Isso transforma um “o site caiu” em uma investigação estruturada.

Define o vocabulário do mercado. Firewall de camada 7, balanceador de camada 4, switch de camada 3 — são termos que aparecem em documentação, contratos e especificações técnicas todos os dias.

É base de certificações e do ensino. CCNA, CompTIA Network+ e praticamente todo curso de redes começam por aqui.

Perguntas frequentes sobre o modelo OSI

O que é o modelo OSI?

É um modelo de referência publicado pela ISO em 1984 que divide a comunicação em rede em sete camadas, da transmissão física dos bits até a aplicação usada pelo usuário. Cada camada tem uma responsabilidade específica, oferece um serviço à camada acima e usa o serviço da camada abaixo.

Quais são as 7 camadas do modelo OSI?

De baixo para cima: Física (1), Enlace de dados (2), Rede (3), Transporte (4), Sessão (5), Apresentação (6) e Aplicação (7). A camada 1 transmite os bits pelo meio físico e a camada 7 é a interface com as aplicações.

O que significa a sigla OSI?

OSI significa Open Systems Interconnection, ou Interconexão de Sistemas Abertos em português. O nome reflete o objetivo original: permitir que sistemas de fabricantes diferentes se comunicassem, numa época em que cada empresa tinha sua própria arquitetura de rede proprietária.

Qual a diferença entre o modelo OSI e o TCP/IP?

O OSI é um modelo teórico de referência com sete camadas, criado pela ISO. O TCP/IP é o conjunto de protocolos que efetivamente roda na internet, organizado em quatro camadas. O TCP/IP agrupa as camadas 5, 6 e 7 do OSI numa só (Aplicação) e as camadas 1 e 2 em outra (Acesso à rede).

Por que o modelo OSI é importante se ninguém o usa?

Porque ele é a linguagem padrão para descrever e diagnosticar redes. Termos como “firewall de camada 7” e “balanceador de camada 4” vêm dele, e o diagnóstico estruturado de problemas — verificar se a falha está na camada 3, 4 ou 7 — é a forma profissional de investigar uma rede.

Em qual camada do OSI trabalha o protocolo IP?

Na camada 3, chamada camada de Rede. É ela que cuida do endereçamento lógico e do roteamento, decidindo por qual caminho os pacotes viajam entre redes diferentes.

Em qual camada trabalham o TCP e o UDP?

Na camada 4, a de Transporte. Ela garante a entrega fim a fim entre os dois computadores e gerencia as portas. O TCP oferece entrega confiável, com confirmação e retransmissão; o UDP é mais rápido e não confirma o recebimento.

Em qual camada está o endereço MAC?

Na camada 2, de Enlace de dados. O endereço MAC identifica fisicamente cada placa de rede e é usado para a comunicação entre dispositivos diretamente conectados, dentro da mesma rede local. Já o endereço IP, da camada 3, permite a comunicação entre redes diferentes.

Em qual camada atua um firewall?

Depende do tipo. Um firewall de rede tradicional atua nas camadas 3 e 4, decidindo por endereço IP e porta. Um firewall de aplicação web (WAF) atua na camada 7, analisando o conteúdo da requisição HTTP. Por isso um firewall comum não protege contra ataques como injeção de SQL, que chegam pela porta legítima.

O que é encapsulamento no modelo OSI?

É o processo pelo qual os dados recebem um cabeçalho a cada camada que descem, como envelopes dentro de envelopes. Na origem, os dados descem da camada 7 até a 1, ganhando cabeçalhos; no destino, sobem da 1 até a 7, tendo cada cabeçalho removido pela camada correspondente.

Qual a unidade de dados de cada camada?

Bit na camada física, quadro na camada de enlace, pacote na camada de rede, e segmento na camada de transporte. Das camadas 5 à 7, a unidade é genericamente chamada de dados.

Como memorizar as camadas do modelo OSI?

Mnemônicos ajudam. Em inglês, o mais usado é “All People Seem To Need Data Processing”, de cima para baixo. Em português, uma opção de baixo para cima é “Fui Entender Redes, Tive Sérias Aulas Avançadas” — Física, Enlace, Rede, Transporte, Sessão, Apresentação, Aplicação.

Quando o modelo OSI foi criado?

O trabalho começou em 1977 na ISO e o modelo foi publicado em 1984, como a norma ISO/IEC 7498-1. Ele surgiu para resolver a incompatibilidade entre arquiteturas proprietárias de fabricantes como IBM e DEC, que impediam equipamentos de marcas diferentes de se comunicarem.

Em qual camada do OSI está o HTTP?

Na camada 7, de Aplicação. Junto com ele estão outros protocolos usados diretamente por aplicações: SMTP e IMAP para e-mail, FTP para transferência de arquivos, DNS para resolução de nomes e SSH para acesso remoto.

Veja também

Sobre os protocolos que implementam esse modelo na prática, veja TCP/IP. Sobre segurança em cada camada, veja o que é firewall e o que é WAF. E sobre as portas da camada de transporte, veja porta 80 e porta 443.

Conclusão

O modelo OSI é uma daquelas ideias que venceram justamente por não terem sido implementadas: nenhuma rede moderna segue suas sete camadas literalmente, e ainda assim todo profissional de tecnologia pensa em termos delas. A razão é que ele resolve um problema que continua atual — dar nome preciso a cada parte de um processo que, de fora, parece uma coisa só. Saber que o endereço MAC é camada 2 e o IP é camada 3, que um firewall comum para na 4 e um WAF vai até a 7, muda a forma de diagnosticar um problema: em vez de procurar em todo lugar, você procura em um andar específico do prédio.

O post Modelo OSI: as 7 camadas explicadas com exemplos apareceu primeiro em Homehost.

Se o ícone do WAMP fica laranja e nunca chega ao verde, o mais provável é que outro programa já esteja usando a porta 80 — e o Apache não consegue subir. Os culpados mais comuns no Windows são o IIS, o serviço World Wide Web Publishing, o VMware e o Windows Media Player Network Sharing.

Há dois caminhos: liberar a porta, encerrando quem a ocupa, ou mudar o WAMP para outra porta. O primeiro é melhor quando você não precisa do programa concorrente; o segundo resolve em trinta segundos e não mexe em nada do sistema.

Antes de escolher, vale descobrir quem está usando a porta — e isso leva um comando.

O que significa o ícone laranja do WAMP

O ícone do WAMP na bandeja do Windows tem três estados, e eles dizem exatamente onde está o problema:

Uma confirmação rápida: clique com o botão direito no ícone do WAMP, vá em Tools → Test Port 80. Ele diz diretamente se a porta está livre ou ocupada, e por quem.

Passo 1: descubra quem está usando a porta 80

Antes de encerrar qualquer coisa, identifique o responsável.

Abra o Prompt de Comando como administrador — tecle Windows, digite cmd, clique com o botão direito e escolha “Executar como administrador”.

A saída mostra linhas assim:

O último número é o PID — o identificador do processo. Anote.

Para descobrir de quem é: abra o Gerenciador de Tarefas (Ctrl+Shift+Esc), vá na aba Detalhes, e procure a coluna PID. Se ela não aparecer, clique com o botão direito no cabeçalho e ative.

Alternativa pelo próprio Prompt:

(Troque 1234 pelo PID que você anotou.)

Os culpados mais comuns

Passo 2: liberar a porta

A ação depende de quem está ocupando.

Se for o IIS ou o World Wide Web Publishing Service

É o caso do PID 4, e o mais comum em Windows Pro. O serviço vem ativo por padrão em algumas instalações, mesmo sem você usar o IIS.

Pelo Prompt de Comando como administrador:

Esse comando para o Windows Process Activation Service e, junto, o serviço de publicação web.

Para desativar de vez, e não voltar a cada reinicialização: tecle Windows, digite services.msc, localize World Wide Web Publishing Service, clique duas vezes, mude o Tipo de inicialização para Desativado e clique em Parar.

Se for o VMware

Nas configurações do VMware, em Edit → Preferences → Shared VMs, desative o compartilhamento — ele é quem usa a porta.

Se for outro Apache

Encerre o outro ambiente local antes de iniciar o WAMP. Rodar XAMPP e WAMP ao mesmo tempo não funciona: os dois querem a mesma porta.

Se for algo que você precisa manter

Não force. Mude a porta do WAMP, como descrito a seguir — é mais simples e não quebra nada.

Não encerre processos do sistema pelo Gerenciador de Tarefas

O processo com PID 4 é o System do Windows — finalizá-lo à força trava a máquina. Nesse caso, o caminho é parar o serviço pelo services.msc ou pelo comando net stop was, nunca matar o processo.

Passo 3: ou mude a porta do WAMP

Se a porta 80 precisa continuar com o outro programa, a solução é o WAMP escutar em outra — normalmente a 8080.

Pelo menu do WAMP: clique com o botão direito no ícone → Tools → Use a port other than 80 → digite 8080 → confirme. O WAMP faz a alteração e reinicia sozinho.

Manualmente, se preferir: clique com o botão esquerdo no ícone → Apache → httpd.conf. No arquivo, localize as duas linhas:

Troque as duas para 8080, salve e reinicie o WAMP.

A partir daí, o endereço muda: o site local passa a ser acessado em http://localhost:8080 em vez de http://localhost. Anote isso — é a confusão seguinte mais comum.

Usa XAMPP ou Laragon? Vale o mesmo

O conflito de porta não é específico do WAMP: qualquer ambiente local baseado em Apache enfrenta o mesmo problema, porque todos disputam a porta 80.

No XAMPP, o caminho é o botão Config na linha do Apache → httpd.conf, alterando as mesmas duas linhas. E há um segundo arquivo, o httpd-ssl.conf, se você também precisar mudar a porta 443.

No Laragon, a alteração fica em Menu → Apache → httpd.conf, ou pelas preferências.

O diagnóstico com netstat é idêntico nos três.

Se o Apache continua sem subir

Porta ocupada não é a única causa. Se a 80 está livre e o Apache ainda não inicia:

Veja o log de erro. No WAMP, clique com o botão esquerdo no ícone → Apache → Apache error log. A última linha diz o motivo.

Erro de sintaxe no httpd.conf. Se você editou o arquivo, uma linha mal formada impede a inicialização. O log aponta a linha exata.

Falta o Visual C++ Redistributable. O WAMP depende dessas bibliotecas, e sem elas o Apache falha silenciosamente. Instale a versão indicada na documentação do WAMP e reinicie.

Antivírus bloqueando. Adicione a pasta do WAMP às exclusões.

A porta 443 também em uso, se você ativou SSL.

Perguntas frequentes

Por que o ícone do WAMP fica laranja?

Porque um dos serviços não conseguiu iniciar — na maioria das vezes o Apache, por conflito de porta. O laranja indica que o WAMP subiu parcialmente. Para confirmar, clique com o botão direito no ícone e vá em Tools → Test Port 80.

Como descobrir qual programa está usando a porta 80?

Abra o Prompt de Comando como administrador e rode netstat -ano | findstr :80. O último número de cada linha é o PID do processo, que você identifica no Gerenciador de Tarefas, na aba Detalhes. O culpado mais comum é o PID 4, que corresponde ao serviço World Wide Web Publishing do Windows.

O que é o processo com PID 4 na porta 80?

É o System do Windows, e na prática significa o serviço World Wide Web Publishing ou o driver HTTP do sistema. Ele não aparece como um programa comum, e por isso confunde. A solução é parar o serviço pelo services.msc ou com o comando net stop was — nunca finalizar o processo pelo Gerenciador de Tarefas.

Como mudar a porta do WAMP?

Clique com o botão direito no ícone do WAMP e vá em Tools → Use a port other than 80, digitando 8080. Alternativamente, edite o httpd.conf pelo menu Apache, alterando as linhas Listen 80 e ServerName localhost:80. Depois disso, o site local passa a ser acessado em http://localhost:8080.

Desativar o IIS atrapalha o Windows?

Não. O IIS e o World Wide Web Publishing Service só são necessários se você hospeda sites com o servidor web da Microsoft. Para quem usa WAMP, XAMPP ou Laragon, eles são dispensáveis — desativá-los libera a porta sem afetar o funcionamento do sistema.

Posso rodar WAMP e XAMPP ao mesmo tempo?

Não com as configurações padrão, porque os dois usam a porta 80 e a 3306. É possível fazer os dois conviverem alterando as portas de um deles, mas é mais simples manter apenas um ambiente instalado e ativo por vez.

A porta 80 está livre e o Apache ainda não inicia. Por quê?

Verifique o log de erro do Apache, acessível pelo menu do WAMP. As causas mais comuns nesse caso são erro de sintaxe no httpd.conf após alguma edição, falta do Visual C++ Redistributable, antivírus bloqueando o executável, ou a porta 443 ocupada se você ativou SSL.

Preciso liberar a porta 80 no firewall?

Para uso local, geralmente não — o acesso a localhost não passa pelo firewall. A liberação só é necessária se você quiser que outros dispositivos da rede acessem o seu servidor local, e nesse caso a regra é criada no Firewall do Windows Defender.

Veja também

Sobre o funcionamento da porta 80, veja o que é a porta 80. Sobre o ambiente local e como publicar o projeto, veja o que é PHP. E se o problema for com o MySQL em vez do Apache, veja Error: MySQL shutdown unexpectedly.

Conclusão

O conflito de porta 80 tem sempre a mesma estrutura: alguém chegou primeiro. Descobrir quem leva um comando, e a partir daí a decisão é simples — se o outro programa é dispensável, pare o serviço; se não é, mude o WAMP para a 8080 e siga em frente. O único cuidado que vale destacar é com o PID 4: ele é o System do Windows, e a saída ali é parar o serviço, nunca o processo.

O post Como liberar a porta 80 para o WAMP no Windows apareceu primeiro em Homehost.

Nosso guia sobre a porta 3306 explica o funcionamento e como test

Antes de seguir qualquer tutorial, um aviso que vale mais que todos os passos: faça uma cópia da pasta xampp/mysql/data agora, antes de mexer em qualquer coisa. A maior parte das soluções que circulam pede para apagar ou renomear arquivos dessa pasta — e é onde estão os seus bancos.

O que a mensagem significa

O painel do XAMPP exibe algo assim:

A própria mensagem lista cinco possibilidades — porta bloqueada, dependências faltando, permissões, travamento, ou desligamento por outro meio. É uma mensagem genérica: o XAMPP percebeu que o processo morreu, mas não sabe por quê.

Quem sabe é o log. E é justamente ele que a maioria dos tutoriais pula.

Um detalhe que confunde: as versões atuais do XAMPP não incluem MySQL, e sim MariaDB — o fork criado pelos desenvolvedores originais. O painel continua chamando de “MySQL” por compatibilidade, mas o que roda ali é MariaDB. Na prática, o comportamento e as soluções são os mesmos. Nosso guia sobre o que é MySQL explica a diferença entre os dois.

Antes de qualquer correção: copie a pasta data

Este passo não é opcional, e é o motivo de tanta gente perder o trabalho de meses.

Vá até C:\xampp\mysql\ e copie a pasta data inteira para a área de trabalho, um pendrive, ou qualquer lugar fora do XAMPP. Dentro dela estão todos os seus bancos.

Boa parte das soluções que você vai encontrar — inclusive as deste artigo — envolve renomear, substituir ou apagar arquivos dessa pasta. Se algo der errado no processo e você não tiver a cópia, não há como voltar atrás.

A pasta “backup” do XAMPP não é o seu backup

Existe uma pasta xampp/mysql/backup, e vários tutoriais mandam copiá-la para data como solução. Funciona para fazer o MySQL iniciar — mas entenda o que ela é: uma cópia das tabelas de sistema do momento da instalação, não dos seus dados. Restaurá-la faz o serviço subir com os bancos vazios. Os seus bancos continuam na pasta antiga, e precisam ser recuperados de lá num segundo passo.

Passo 1: leia o log de erro

É o que separa uma correção de dez minutos de uma tarde inteira tentando soluções aleatórias.

Pelo painel do XAMPP: clique no botão Logs na linha do MySQL e escolha mysql_error.log.

Pelo Explorador de Arquivos: abra C:\xampp\mysql\data\mysql_error.log no Bloco de Notas.

Role até o fim do arquivo — as últimas linhas são da tentativa mais recente. O que você encontrar ali diz o que fazer.

Causa 1: arquivos InnoDB corrompidos

A mais comum, e a que quase sempre aparece depois de um travamento do Windows, uma queda de energia, ou de fechar o XAMPP sem parar o MySQL antes.

O InnoDB — o motor de armazenamento padrão — guarda o dicionário de dados num arquivo chamado ibdata1 e os logs de transação em ib_logfile0 e ib_logfile1. Se o processo é interrompido no meio de uma escrita, esses arquivos ficam inconsistentes e o serviço se recusa a subir.

O procedimento, na ordem:

1. Confirme que você copiou a pasta data para fora do XAMPP
2. Renomeie xampp/mysql/data para data_old
3. Crie uma pasta nova chamada data
4. Copie todo o conteúdo de xampp/mysql/backup para dentro da nova data
5. De data_old, copie as pastas dos seus bancos (cada banco é uma pasta com o nome dele) para a nova data — mas não copie as pastas mysql, performance_schema e phpmyadmin
6. De data_old, copie também o arquivo ibdata1 para a nova data
7. Inicie o MySQL pelo painel

Por que o passo 6 é o mais delicado

O ibdata1 guarda o dicionário das tabelas InnoDB — a lista do que existe e onde está. Os dados em si ficam nos arquivos .ibd dentro das pastas de cada banco. Os dois precisam ser da mesma origem: se você copiar o ibdata1 antigo e esquecer os .ibd, ou o contrário, o InnoDB encontra uma referência para algo que não existe e falha.

E se o ibdata1 for justamente o arquivo corrompido, copiá-lo reproduz o problema na pasta nova. Nesse caso, o serviço sobe sem ele — mas os bancos InnoDB ficam inacessíveis, e a recuperação exige um caminho diferente, descrito mais abaixo.

Se o serviço subir, confira imediatamente se os seus bancos aparecem no phpMyAdmin. Não basta o MySQL iniciar: é preciso que os dados estejam lá.

Causa 2: a porta 3306 está ocupada

O MySQL não consegue iniciar se outro programa já está escutando na porta dele. Os suspeitos habituais são um MySQL instalado separadamente (fora do XAMPP), o WAMP, o Laragon, ou uma instância antiga que não encerrou.

Como confirmar, no Prompt de Comando:

Se aparecer alguma linha, a porta está ocupada — e o último número é o PID do processo. Você identifica quem é no Gerenciador de Tarefas, na aba Detalhes.

Duas saídas:

Encerrar o outro programa. Se for um serviço do Windows, abra services.msc, procure por MySQL ou MariaDB, e pare o serviço. Se for outro ambiente local, feche-o.

Ou mudar a porta do XAMPP. No painel, clique em Config na linha do MySQL e abra o my.ini. Troque as duas ocorrências de port=3306 para port=3307, salve e reinicie.

Se mudar a porta, lembre que as aplicações precisam saber disso — no WordPress, o DB_HOST passa a ser localhost:3307. Nosso guia sobre a porta 3306 explica o funcionamento e como testar.

O mesmo conflito acontece com o Apache, que disputa a porta 80 — nosso guia sobre como liberar a porta 80 mostra como identificar quem a está ocupando.

Causa 3: falta o Visual C++ Redistributable

Causa frequente em instalação nova do XAMPP no Windows, e praticamente invisível: o log fica vazio, porque o processo nem chega a iniciar.

O MySQL do XAMPP depende das bibliotecas do Microsoft Visual C++ Redistributable. Sem elas, ele falha silenciosamente.

Como verificar: abra Painel de Controle → Programas e Recursos e procure por “Microsoft Visual C++ 2015-2022 Redistributable (x64)”. Se não estiver na lista, baixe do site oficial da Microsoft, instale, reinicie o computador e tente novamente.

Causa 4: permissões insuficientes

Se o log menciona Permission denied ou Can't create/write to file, o XAMPP não tem permissão para escrever na própria pasta.

Primeiro teste: feche o XAMPP, clique com o botão direito no atalho e escolha Executar como administrador.

Se resolver, vale tornar permanente: botão direito no xampp-control.exe → Propriedades → Compatibilidade → marcar Executar este programa como administrador.

Uma causa relacionada: o XAMPP instalado em C:\Program Files costuma dar esse problema, porque o Windows protege essa pasta. A instalação recomendada é direto em C:\xampp.

Causa 5: antivírus ou outro processo travando arquivos

Se o log traz Operating system error number 32 — “arquivo em uso por outro processo” —, algo está segurando os arquivos do banco.

Antivírus é o suspeito mais comum: alguns fazem varredura em tempo real dentro da pasta data e travam o ibdata1 no momento em que o MySQL tenta abri-lo. A solução é adicionar C:\xampp à lista de exclusões do antivírus.

Um processo mysqld.exe órfão também causa isso. Abra o Gerenciador de Tarefas, procure por mysqld.exe na aba Detalhes, e finalize o processo antes de tentar de novo.

Causa 6: disco cheio

Simples e frequentemente esquecida: o MySQL precisa de espaço para os logs de transação, e se o disco está cheio ele não inicia.

Verifique o espaço livre na unidade onde o XAMPP está instalado. Menos de 1 GB já é motivo de preocupação.

Como recuperar seus bancos quando nada funciona

Se o serviço subiu mas os bancos não aparecem, ou se o ibdata1 estava corrompido, a recuperação depende do motor de armazenamento das tabelas.

Tabelas MyISAM são autocontidas: cada uma tem três arquivos — .frm, .MYD e .MYI — dentro da pasta do banco. Copiá-los para a instalação nova costuma funcionar, mesmo sem o ibdata1 original.

Tabelas InnoDB não são. Os dados ficam em arquivos .ibd, mas a estrutura que diz como lê-los está no ibdata1. Sem o ibdata1 correspondente, os .ibd sozinhos não são recuperáveis pelos meios normais.

Um último recurso é iniciar o MySQL em modo de recuperação. No my.ini, na seção [mysqld], acrescente:

Salve e tente iniciar. Se não subir, aumente o número gradualmente até 6 — mas saiba que a partir do nível 4 o processo pode causar perda de dados. Assim que o serviço subir, exporte tudo imediatamente pelo phpMyAdmin, remova a linha do my.ini, e reinstale o XAMPP do zero para importar os dados de volta.

Ao exportar, atenção ao charset: nosso guia sobre acentuação quebrada no MySQL mostra como não perder os acentos no processo.

Como evitar que aconteça de novo

Quase todos os casos vêm do mesmo comportamento — e a prevenção é simples:

Pare o MySQL antes de desligar o computador. No painel do XAMPP, clique em Stop na linha do MySQL e espere o indicador apagar. Fechar o painel ou desligar a máquina com o serviço rodando é o que corrompe os arquivos.

Faça backup dos bancos regularmente. Exportar pelo phpMyAdmin leva segundos e é a única garantia real — nosso guia sobre backup pelo phpMyAdmin mostra o processo.

Exclua a pasta do XAMPP do antivírus, para evitar travamento de arquivos.

Não instale o XAMPP em C:\Program Files.

Perguntas frequentes

O que significa “Error: MySQL shutdown unexpectedly”?

Significa que o XAMPP tentou iniciar o serviço do MySQL e o processo terminou antes de ficar pronto. É uma mensagem genérica — a causa exata está no arquivo mysql_error.log, dentro de xampp/mysql/data. As causas mais comuns são arquivos corrompidos por desligamento abrupto, porta 3306 ocupada e falta do Visual C++ Redistributable.

Vou perder meus bancos de dados?

Não necessariamente, e o mais importante é agir com calma: copie a pasta xampp/mysql/data para outro lugar antes de tentar qualquer correção. Os seus bancos estão ali. A maioria das soluções envolve renomear ou substituir arquivos dessa pasta, e sem a cópia não há como voltar atrás.

Posso apagar a pasta data para resolver?

Não apague — renomeie. Renomear para data_old produz o mesmo efeito de “começar do zero”, mas preserva os seus bancos para recuperação depois. Apagar é definitivo.

A pasta backup do XAMPP restaura meus dados?

Não. A pasta xampp/mysql/backup contém apenas as tabelas de sistema do momento da instalação — ela faz o serviço iniciar, mas com os bancos vazios. Seus dados continuam na pasta data antiga e precisam ser copiados de lá separadamente.

Por que o erro aconteceu do nada?

Quase sempre porque o MySQL não foi encerrado corretamente na última vez: o computador travou, faltou energia, ou o XAMPP foi fechado com o serviço rodando. O InnoDB interrompido no meio de uma escrita deixa os arquivos inconsistentes, e na próxima inicialização o serviço se recusa a subir.

Como sei se a porta 3306 está ocupada?

No Prompt de Comando, rode netstat -ano | findstr :3306. Se aparecer alguma linha, há um processo usando a porta — o último número é o PID, que você identifica no Gerenciador de Tarefas. Os culpados mais comuns são um MySQL instalado separadamente, o WAMP ou o Laragon.

O que é o arquivo ibdata1?

É onde o InnoDB guarda o dicionário de dados — a estrutura que diz quais tabelas existem e como lê-las. Os dados em si ficam nos arquivos .ibd. Os dois precisam ser da mesma origem: copiar um sem o outro faz o InnoDB falhar, porque encontra referências para algo que não existe.

O XAMPP usa MySQL ou MariaDB?

As versões atuais incluem MariaDB, o fork criado pelos desenvolvedores originais do MySQL depois da compra pela Oracle. O painel continua exibindo “MySQL” por compatibilidade. Na prática, os comandos, o phpMyAdmin e as soluções para este erro são os mesmos.

Devo usar innodb_force_recovery?

Só como último recurso, e com cuidado. Comece no nível 1 e aumente gradualmente — a partir do nível 4, o processo pode causar perda de dados. Assim que o serviço subir, exporte tudo imediatamente, remova a linha do my.ini e reinstale o XAMPP para importar os dados de volta.

Veja também

Para entender o funcionamento do banco, veja o que é MySQL e o que é um banco de dados. Sobre o ambiente local e como publicar o projeto, veja o que é PHP. E se o erro for no site em produção e não no XAMPP, veja erro ao estabelecer uma conexão com o banco de dados.

Conclusão

A mensagem parece grave, mas raramente é: o serviço morreu, e o log diz por quê. O erro de quase todo mundo é seguir direto para o tutorial que manda apagar a pasta data — e é aí que os bancos se perdem, não no travamento original. Copie a pasta antes de qualquer coisa, leia as últimas linhas do mysql_error.log, e trate a causa que ele apontar. E, para não repetir: pare o MySQL pelo painel antes de desligar o computador. É esse gesto de dois segundos que evita a maior parte dos casos.

O post Error: MySQL shutdown unexpectedly — como resolver no XAMPP apareceu primeiro em Homehost.

Se os acentos do seu site viraram símbolos estranhos — João em vez de João, informação em vez de informação —, o problema é de codificação de caracteres, e quase sempre aparece depois de exportar e importar um banco de dados. A causa mais comum é o mysqldump ou o phpMyAdmin gravando o arquivo num charset diferente do que o banco de destino espera.

A boa notícia: os dados não foram perdidos. Os bytes originais continuam lá — o que se perdeu foi a instrução de como interpretá-los. E na maioria dos casos dá para recuperar.

O que realmente está acontecendo

Um banco de dados não guarda letras — guarda números. Cada caractere é convertido em um ou mais bytes, e a tabela que define essa conversão é o charset (conjunto de caracteres).

O ã em UTF-8, por exemplo, ocupa dois bytes: C3 A3. Se um programa lê esses dois bytes achando que são latin1 — onde cada byte é um caractere —, ele exibe Ã e £. Daí o João.

Nada foi corrompido. Os bytes C3 A3 continuam exatamente onde estavam. O que falhou foi a instrução de como interpretá-los.

E é por isso que o problema costuma aparecer numa migração: o banco de origem falava um charset, o arquivo foi exportado noutro, e o banco de destino leu num terceiro. Basta um elo discordar para os acentos quebrarem.

Os quatro pontos onde o charset é definido

Esta é a parte que a maioria dos tutoriais não explica, e é por ela que o problema volta mesmo depois de “corrigido”: o charset é declarado em quatro lugares diferentes, e todos precisam concordar.

Um site pode ter o banco em UTF-8 e ainda assim mostrar acentos quebrados, se a conexão estiver em latin1. E o contrário também: banco em latin1 exibindo tudo certo, porque a conexão também está em latin1 — até o dia em que alguém exporta.

A regra é simples: use utf8mb4 nos quatro.

Atenção: utf8 no MySQL não é UTF-8

Um detalhe que resolve metade dos casos difíceis, e quase ninguém sabe.

Por razões históricas, o charset chamado utf8 no MySQL nunca foi o UTF-8 completo. Ele armazena no máximo 3 bytes por caractere, o que cobre acentos e a maioria dos idiomas, mas não cobre emojis nem alguns caracteres de línguas asiáticas.

O UTF-8 de verdade, com até 4 bytes, chama-se utf8mb4. Ele é o padrão desde o MySQL 8, mas bancos criados em versões anteriores costumam ter ficado no utf8 antigo.

Como isso aparece: os acentos funcionam normalmente, mas um emoji digitado num post ou num comentário some, vira ???, ou trunca o texto a partir dali.

Sempre use utf8mb4, nunca utf8

Ao criar um banco novo, escolher tabelas ou definir a conexão, prefira sempre utf8mb4 com collation utf8mb4_unicode_ci. O utf8 antigo funciona para acentos, mas cria um problema latente que só aparece quando alguém usa um emoji — e aí a correção exige converter tudo de novo.

Como exportar sem quebrar os acentos

A causa mais frequente do problema. Duas formas de exportar, e o cuidado em cada uma:

Pelo phpMyAdmin: ao exportar, escolha o método Personalizado e confira o campo de conjunto de caracteres do arquivo. Ele deve estar em utf-8. No método Rápido, o phpMyAdmin usa o padrão do servidor — que nem sempre é o certo.

Pela linha de comando, o parâmetro é explícito:

E na importação, o mesmo cuidado:

Um detalhe que engana: abrir o arquivo .sql no Bloco de Notas e ver os acentos corretos não garante nada — o editor pode estar interpretando bem um arquivo que o MySQL vai interpretar mal. O que vale é o charset declarado na exportação.

Nosso guia sobre backup do banco pelo phpMyAdmin cobre o processo completo.

Como descobrir o charset atual do seu banco

Antes de corrigir, vale saber o que está configurado. No phpMyAdmin, abra a aba SQL e rode:

E para ver tabela por tabela, que é onde as inconsistências aparecem:

É comum encontrar um banco declarado em utf8mb4 com tabelas antigas ainda em latin1 — resquício de migrações passadas.

Corrigindo um banco que já está com acentos quebrados

Aqui a ordem importa, e o primeiro passo não é negociável.

1. Faça backup antes de qualquer coisa. Conversão de charset é irreversível, e uma conversão feita na direção errada destrói os dados de vez — transformando um problema de exibição num problema real de perda. O mesmo vale para o erro de inicialização do MySQL no XAMPP, em que a pressa de “resolver” apagando arquivos é o que costuma destruir os bancos.

2. Identifique o cenário. Há dois, e a solução é diferente:

Aquele segundo caso é importante e pouco dito: quando os acentos viram ?, a informação se perdeu de fato. O ponto de interrogação é o que o MySQL grava quando não consegue representar um caractere no charset de destino, e não há como saber qual letra estava ali.

3. Converta as tabelas, se for o primeiro cenário:

Repita para cada tabela. Um banco WordPress tem cerca de doze tabelas — o phpMyAdmin permite selecionar todas de uma vez e aplicar a operação em lote.

4. Ajuste a aplicação. No WordPress, o charset fica no wp-config.php:

Em PHP puro com PDO, o charset vai na string de conexão: mysql:host=localhost;dbname=banco;charset=utf8mb4.

5. Confira o HTML. Mesmo com tudo certo no banco, uma página sem <meta charset="utf-8"> exibe acentos quebrados. Nosso guia sobre caracteres especiais e acentos no HTML cobre esse lado.

O caso específico do WordPress

Alguns pontos que só aparecem no WordPress:

A migração é o momento de risco. Ao mover o site, o banco de origem pode estar em latin1 e o de destino em utf8mb4. A exportação sem charset explícito é o que quebra tudo.

O wp-config.php manda no comportamento. Se o DB_CHARSET não bater com o charset real das tabelas, o WordPress grava certo e lê errado — ou o contrário.

Sites antigos costumam estar em latin1. Instalações de antes de 2015 foram criadas assim, e continuam funcionando até o dia da migração.

Plugins de migração ajudam. Ferramentas como Duplicator e All-in-One WP Migration cuidam do charset automaticamente — é um argumento a favor de usá-las em vez do processo manual, sobretudo para quem não domina o assunto.

Perguntas frequentes

Por que os acentos do meu site viraram símbolos estranhos?

Porque o texto foi gravado num charset e está sendo lido em outro. O caso mais comum é conteúdo em UTF-8 sendo interpretado como latin1, o que transforma ção em ção. Os dados não foram perdidos: os bytes originais continuam no banco, e o que falhou foi a instrução de como interpretá-los.

Qual a diferença entre utf8 e utf8mb4 no MySQL?

O charset chamado utf8 no MySQL não é o UTF-8 completo — ele usa no máximo 3 bytes por caractere, o que cobre acentos mas não emojis nem alguns caracteres asiáticos. O utf8mb4 é o UTF-8 de verdade, com até 4 bytes. Use sempre utf8mb4.

Como exportar um banco MySQL sem quebrar a acentuação?

Pela linha de comando, use mysqldump --default-character-set=utf8mb4. No phpMyAdmin, escolha o método Personalizado e confirme que o conjunto de caracteres do arquivo está como utf-8 — o método Rápido usa o padrão do servidor, que nem sempre é o correto.

Meus acentos viraram pontos de interrogação. Dá para recuperar?

Não. O ponto de interrogação é o que o MySQL grava quando não consegue representar um caractere no charset de destino — a informação original foi substituída e não há como saber qual letra estava ali. A única saída é restaurar um backup anterior à conversão.

Como sei qual charset meu banco está usando?

No phpMyAdmin, a aba Operações do banco mostra o agrupamento (collation) atual. Para ver tabela por tabela, rode uma consulta em information_schema.TABLES filtrando pelo nome do seu banco — é comum encontrar bancos em utf8mb4 com tabelas antigas ainda em latin1.

Corrigi o banco mas os acentos continuam errados. Por quê?

O charset é definido em quatro lugares: banco e tabelas, conexão, aplicação e página HTML. Corrigir só um não basta — se a conexão continua em latin1, o problema persiste mesmo com as tabelas em utf8mb4. No WordPress, confira também o DB_CHARSET no wp-config.php.

Converter as tabelas para utf8mb4 é seguro?

A operação em si é padrão, mas é irreversível — e se os dados já estiverem em estado inconsistente, a conversão pode piorar. Faça backup do banco antes, sempre. Se a conversão der errado, o backup é a única forma de voltar atrás.

Por que isso acontece principalmente em migrações?

Porque a migração envolve três pontos onde o charset pode divergir: o banco de origem, o arquivo exportado e o banco de destino. Basta um deles discordar para os acentos quebrarem. Exportar e importar declarando utf8mb4 explicitamente evita o problema.

Veja também

Para entender o funcionamento do banco, veja o que é MySQL e os tipos de dados do MySQL. Sobre acentuação no lado do HTML, veja caracteres especiais e acentos. E se o site parou de conectar ao banco, veja erro ao estabelecer uma conexão com o banco de dados.

Conclusão

Acentuação quebrada assusta mais do que deveria: na maioria das vezes os dados estão intactos, e o que se perdeu foi só a instrução de como lê-los. O caminho é sempre o mesmo — descobrir em qual dos quatro pontos o charset diverge, alinhar todos em utf8mb4, e conferir se a aplicação e o HTML concordam. Duas coisas valem gravar: faça backup antes de qualquer conversão, porque ela é irreversível; e se os acentos viraram pontos de interrogação, não há conversão que resolva — ali a informação se foi, e só o backup traz de volta.

O post Acentuação quebrada no MySQL: como corrigir o UTF-8 apareceu primeiro em Homehost.

Essa mensagem significa que o WordPress não conseguiu se conectar ao banco de dados onde ficam os seus posts, páginas e configurações. Na maioria esmagadora dos casos, a causa é uma só: as credenciais no arquivo wp-config.php estão erradas — e isso quase sempre acontece depois de uma migração, de uma troca de senha ou de uma alteração no painel.

A boa notícia é que seus dados não sumiram. O banco continua lá, com tudo dentro. O que falhou foi a conexão entre o site e ele, e resolver isso normalmente leva alguns minutos.

O que a mensagem significa

O WordPress guarda os arquivos (imagens, temas, plugins) no servidor, mas todo o conteúdo — posts, páginas, comentários, usuários, configurações — fica num banco de dados MySQL separado.

A cada visita, o WordPress precisa se conectar a esse banco para montar a página. Quando essa conexão falha, ele não tem o que exibir — e mostra a mensagem em vez do site.

Para conectar, ele usa quatro informações guardadas no arquivo wp-config.php: o nome do banco, o usuário, a senha e o endereço do servidor. Se qualquer uma das quatro estiver errada, a conexão falha. Nosso guia sobre o que é um banco de dados explica melhor esse funcionamento.

Causa 1: credenciais erradas no wp-config.php

É a causa de longe mais comum, e o primeiro lugar a verificar.

Abra o arquivo. No painel de hospedagem, use o gerenciador de arquivos, entre na pasta do site (geralmente public_html) e edite o wp-config.php. Procure por estas quatro linhas:

Compare com o painel. No cPanel, abra Bancos de Dados MySQL. Ali você vê o nome exato do banco e os usuários associados a ele. Confira letra por letra — o prefixo da conta costuma ser igual, e a diferença está no que vem depois.

Os erros mais frequentes:

• Depois de uma migração, o nome do banco e do usuário mudam, porque o prefixo é o da nova conta. O wp-config.php continua apontando para os antigos.

• Alguém trocou a senha do usuário do banco pelo painel e esqueceu de atualizar o arquivo.
• O usuário existe, mas não está associado ao banco. No cPanel, criar o usuário e criar o banco são passos separados — falta o terceiro, que é vincular um ao outro com todos os privilégios.

Se precisar redefinir a senha: no cPanel, em Bancos de Dados MySQL, altere a senha do usuário e cole exatamente o mesmo valor no wp-config.php.

Faça uma cópia antes de editar

Antes de alterar o wp-config.php, baixe uma cópia dele para o seu computador. Um caractere apagado por engano nesse arquivo derruba o site inteiro — e sem a cópia, recuperar exige refazer a configuração do zero. Vale o mesmo cuidado com o banco: nosso tutorial mostra como fazer backup pelo phpMyAdmin.

Causa 2: DB_HOST incorreto

O valor localhost funciona na maioria das hospedagens compartilhadas, porque o banco fica no mesmo servidor do site. Mas nem sempre.

Algumas configurações usam 127.0.0.1, um caminho de socket, ou o endereço de um servidor de banco separado — às vezes com porta específica, como mysql.seudominio.com.br:3306.

Se as credenciais estão certas e o erro persiste, esse é o valor a confirmar com o suporte. É o campo que a documentação genérica quase sempre erra, porque assume localhost.

Causa 3: banco de dados corrompido

O sintoma é característico: além do erro no site, o painel administrativo mostra uma mensagem dizendo que uma ou mais tabelas do banco precisam ser reparadas.

O WordPress tem uma ferramenta embutida para isso. Acrescente esta linha ao wp-config.php, antes da linha que diz “That’s all, stop editing”:

Depois acesse seudominio.com.br/wp-admin/maint/repair.php e escolha Reparar banco de dados. Ao terminar, remova a linha — enquanto ela estiver lá, qualquer pessoa consegue acessar a ferramenta sem estar logada.

Alternativamente, o phpMyAdmin faz o mesmo: selecione o banco, marque todas as tabelas e escolha “Reparar tabela” no menu inferior.

Causa 4: limite de conexões atingido

Se o erro aparece de forma intermitente, e principalmente em horários de maior movimento, o problema não é configuração — é capacidade.

Cada visita simultânea abre uma conexão com o banco. Quando o número de conexões passa do limite do plano, as novas são recusadas — e o visitante recebe exatamente essa mensagem.

Como reconhecer: o site funciona, cai por alguns minutos, volta sozinho. Ninguém mexeu em nada.

O que fazer:

• Instale um plugin de cache. É o que mais resolve: com cache, a maioria das visitas nem chega a consultar o banco
• Verifique o consumo no painel, na área de uso de recursos — o CloudLinux mostra quando você está batendo no teto do plano
• Procure plugins pesados, que fazem muitas consultas por página
• Considere subir de plano, se o site cresceu

Causa 5: o servidor de banco está fora do ar

Menos comum, mas acontece: o serviço MySQL do servidor caiu ou está sobrecarregado.

Como identificar: se outros sites da mesma conta também estão fora, ou se o phpMyAdmin no painel não abre, o problema é do servidor. Nesse caso não há nada a fazer do seu lado além de acionar o suporte da hospedagem. Se o erro estiver acontecendo no seu ambiente local com XAMPP, e não num site em produção, o caminho é outro — veja Error: MySQL shutdown unexpectedly.

Causa 6: um plugin ou atualização quebrou algo

Mais raro, mas possível — especialmente se o erro apareceu logo depois de instalar ou atualizar alguma coisa.

Como o painel está inacessível, a desativação precisa ser feita por fora: renomeie a pasta wp-content/plugins pelo gerenciador de arquivos, e o WordPress desativa todos de uma vez. Nosso guia sobre como desativar plugins do WordPress mostra os dois caminhos, inclusive pelo phpMyAdmin.

Se o site voltar, reative um a um até identificar o culpado.

Se o seu site usa Cloudflare

Um detalhe que confunde bastante: atrás de uma CDN, esse erro pode aparecer como um erro 500 genérico em vez da mensagem do WordPress.

Isso acontece porque o Cloudflare repassa o erro da origem, e a página que o visitante vê é a dele, não a sua. A causa continua sendo o banco — mas você não consegue diagnosticar pelo painel do Cloudflare. Nosso guia sobre erro 500 no Cloudflare explica como identificar de onde o erro veio.

Quando é da hospedagem

Vale saber distinguir, porque muda quem resolve.

É seu quando o erro apareceu depois de uma alteração: migração, troca de senha, edição de arquivo, instalação de plugin. As credenciais são o primeiro lugar a olhar.

É da hospedagem quando nada mudou do seu lado, outros sites da mesma conta também falham, ou o problema é recorrente sem explicação. Um servidor de banco constantemente sobrecarregado, ou limites apertados demais para o tamanho do site, são problemas de infraestrutura — e nenhuma configuração no WordPress resolve isso.

Perguntas frequentes

Vou perder o conteúdo do meu site?

Não. O erro significa que o WordPress não conseguiu se conectar ao banco, não que os dados foram apagados. Seus posts, páginas, comentários e configurações continuam lá, e reaparecem assim que a conexão for restabelecida.

Qual a causa mais comum desse erro?

Credenciais incorretas no arquivo wp-config.php — nome do banco, usuário, senha ou host errados. Acontece principalmente depois de uma migração de servidor, quando os nomes mudam de prefixo, ou quando alguém altera a senha do usuário do banco pelo painel sem atualizar o arquivo.

Onde encontro as credenciais do meu banco de dados?

No wp-config.php, dentro da pasta do site, nas linhas DB_NAME, DB_USER, DB_PASSWORD e DB_HOST. Para comparar com os valores corretos, abra Bancos de Dados MySQL no painel de hospedagem, onde aparecem o nome do banco e os usuários vinculados a ele.

O DB_HOST é sempre “localhost”?

Não. É o valor mais comum em hospedagem compartilhada, mas algumas configurações usam 127.0.0.1, um socket ou o endereço de um servidor de banco separado, às vezes com porta. Se as outras credenciais estiverem corretas e o erro persistir, confirme esse valor com o suporte.

O painel avisa que as tabelas precisam de reparo. O que faço?

Isso indica banco corrompido. Acrescente define( 'WP_ALLOW_REPAIR', true ); ao wp-config.php, acesse seudominio.com.br/wp-admin/maint/repair.php, execute o reparo e depois remova a linha — deixá-la ativa permite que qualquer pessoa use a ferramenta sem estar logada.

O erro aparece e some sozinho. Por quê?

É o padrão típico de limite de conexões atingido: em horários de pico, o número de visitas simultâneas ultrapassa o que o plano permite, e as conexões extras são recusadas. Instalar um plugin de cache costuma resolver, porque reduz drasticamente as consultas ao banco.

Como acesso o site se nem o wp-admin abre?

Pelo painel de hospedagem. O gerenciador de arquivos permite editar o wp-config.php e renomear a pasta de plugins, e o phpMyAdmin dá acesso ao banco — tudo sem depender do WordPress estar funcionando.

Mudei de hospedagem e o erro apareceu. É normal?

É a situação mais comum de todas. Ao migrar, o nome do banco e do usuário costumam mudar, porque incluem o prefixo da conta no novo servidor. O wp-config.php vem com os valores antigos e precisa ser atualizado com os novos.

Veja também

Sobre outros erros que deixam o site fora do ar, veja HTTP erro 500 e erro 503. Se você não consegue acessar o painel, veja login no WordPress e como resetar a senha.

Conclusão

A mensagem assusta porque parece perda de dados, e não é — o banco está intacto, só ficou inacessível. Comece sempre pelo wp-config.php, comparando as quatro credenciais com o que aparece no painel de hospedagem, porque é ali que está a resposta na maioria dos casos. Se nada mudou do seu lado e o erro aparece e some sozinho, o problema é de capacidade, não de configuração — e aí a solução passa por cache ou por um plano com mais recursos.

O post Erro ao estabelecer uma conexão com o banco de dados: como resolver apareceu primeiro em Homehost.

ModSecurity é o firewall de aplicação web mais usado em servidores de hospedagem — um módulo do servidor que lê cada requisição HTTP antes de ela chegar ao seu site e bloqueia o que corresponde a padrões de ataque. Ele é open source, roda no Apache, Nginx e IIS, e está ativo na maioria das hospedagens compartilhadas sem que o cliente saiba.

E é justamente por estar ativo sem aviso que a maior parte das buscas por “ModSecurity” vem de quem foi bloqueado por ele: o formulário que parou de enviar, o post do WordPress que não salva, o erro 403 que aparece só numa ação específica. Este guia cobre as duas pontas — o que ele faz e o que fazer quando ele bloqueia algo legítimo.

O que é o ModSecurity

O ModSecurity é um módulo de firewall de aplicação web — um WAF — que se instala junto ao servidor web. Ele foi criado em 2002 para o Apache, é open source, e hoje funciona também no Nginx e no IIS.

A diferença para um firewall comum é a camada em que atua. Um firewall de rede decide com base em endereço IP e porta: ele vê de onde a requisição vem, mas não o que ela contém. O ModSecurity lê o conteúdo — URL, parâmetros, cabeçalhos, cookies, corpo do POST — e compara com padrões conhecidos de ataque.

Nosso guia sobre o que é WAF explica essa distinção em detalhe. O ModSecurity é a implementação mais comum desse conceito em hospedagem.

Onde ele roda importa. Como é um módulo do servidor, ele inspeciona a requisição antes do PHP carregar. Um plugin de segurança do WordPress faz um trabalho parecido, mas só depois que o WordPress já iniciou — o que significa que o ataque já consumiu recursos da sua conta antes de ser barrado.

Contra o que ele protege

As categorias que ele cobre são as mais frequentes contra sites:

• SQL injection — comandos de banco inseridos em campos de formulário ou parâmetros de URL
• Cross-site scripting (XSS) — JavaScript malicioso injetado em páginas
• Path traversal e inclusão de arquivos — tentativas de acessar arquivos fora do diretório do site, como o wp-config.php
• Exploração de vulnerabilidades conhecidas — bots varrendo a internet em busca de sites com plugins desatualizados
• Execução remota de comandos
• Força bruta em formulários de login

O benefício mais concreto é o que se chama de virtual patching: quando surge uma falha crítica num plugin popular, a regra que bloqueia a exploração costuma chegar antes de o desenvolvedor lançar a correção — e muito antes de o dono do site aplicá-la.

Como ele decide o que bloquear: as regras

O ModSecurity sozinho não bloqueia nada. Ele é um motor que aplica regras, e as regras vêm de conjuntos separados.

O mais usado é o OWASP Core Rule Set (CRS) — um conjunto aberto, mantido pela comunidade, que cobre as principais categorias de ataque. Praticamente toda hospedagem que usa ModSecurity usa o CRS como base, complementado por regras próprias do provedor ou de fornecedores comerciais.

Cada regra tem um ID numérico, e esse detalhe é mais útil do que parece: quando o ModSecurity bloqueia algo, o log registra o ID da regra que disparou. É esse número que permite liberar exatamente aquela regra, em vez de desativar a proteção inteira.

Nesse exemplo, a regra 942100 foi acionada porque algo no campo content pareceu injeção de SQL. Se isso aconteceu enquanto você salvava um post com um trecho de código, é falso positivo — e o suporte pode liberar essa regra específica para o seu site.

Os níveis de paranoia

Um conceito do CRS que explica muita coisa, e que quase nenhum artigo em português cobre.

O Core Rule Set trabalha com níveis de paranoia, de 1 a 4. Quanto maior o nível, mais regras são aplicadas e mais rigorosa fica a inspeção — e mais falsos positivos aparecem.

Em hospedagem compartilhada, o provedor define esse nível para o servidor inteiro — o que explica por que a mesma aplicação funciona numa hospedagem e é bloqueada em outra.

Quando ele bloqueia você

Aqui está o motivo pelo qual a maioria das pessoas procura por ModSecurity.

O sintoma característico: um erro 403 que acontece numa ação específica, não no site inteiro. O site abre normalmente, mas alguma coisa dá erro.

Os casos mais comuns:

O que fazer, em ordem:

1. Confirme que é o ModSecurity. Peça ao suporte para verificar o log no horário exato em que o erro aconteceu. A entrada trará o ID da regra.

2. Peça a liberação daquela regra específica, para o seu site. É procedimento de rotina em qualquer hospedagem, e leva minutos.

3. Se o problema for recorrente com um plugin, vale investigar o que ele está enviando — às vezes o padrão que dispara a regra é evitável.

Não desative o ModSecurity inteiro

É a solução que muita gente pede ao suporte, e é a pior de todas. Desligar o ModSecurity resolve o falso positivo e remove, junto, a proteção contra todos os ataques que ele estava bloqueando silenciosamente — e são muitos, todos os dias, sem que você perceba. Liberar uma regra específica leva o mesmo tempo e mantém o resto funcionando. Se o suporte oferecer desativar tudo como primeira solução, vale insistir na liberação pontual.

ModSecurity em hospedagem compartilhada e em VPS

A diferença prática é quem controla:

Em hospedagem compartilhada, o ModSecurity é configurado pelo provedor para o servidor inteiro. Você não escolhe as regras nem o nível de paranoia — mas também não precisa manter nada. Quando um falso positivo acontece, o caminho é o suporte.

Em VPS ou dedicado, você tem controle total: escolhe o conjunto de regras, ajusta o nível de paranoia, cria exceções e lê os logs diretamente. Em painéis como cPanel e CyberPanel, o ModSecurity aparece como uma seção do próprio painel, com ativação em um clique.

Vale notar que o ModSecurity é o motor por trás de várias soluções comerciais de segurança para servidores — o cPGuard e o Imunify360, por exemplo, usam regras baseadas nele, acrescentando antivírus, detecção de malware e interface de gestão.

O que ele não faz

Delimitar importa, porque WAF é frequentemente vendido como proteção completa:

• Não corrige a vulnerabilidade. Ele bloqueia a tentativa de exploração, mas a falha continua no código. Atualizar plugins e temas continua sendo a defesa principal
• Não protege contra senha fraca. Se o atacante acerta a senha, a requisição é legítima
• Não remove malware já instalado. Isso é trabalho de scanner e limpeza
• Não protege serviços fora do HTTP. SSH, FTP e banco de dados são responsabilidade do firewall de rede
• Não substitui backup

Perguntas frequentes

O que é ModSecurity?

É um módulo de firewall de aplicação web (WAF) que roda junto ao servidor, lendo cada requisição HTTP antes que ela chegue ao site. Ele compara o conteúdo da requisição com padrões conhecidos de ataque e bloqueia o que corresponder. É open source, criado em 2002, e funciona em Apache, Nginx e IIS.

Como saber se o ModSecurity está bloqueando meu site?

O sintoma típico é um erro 403 numa ação específica — salvar um post, enviar um formulário, fazer upload — enquanto o resto do site funciona normalmente. Para confirmar, peça ao suporte para verificar o log do ModSecurity no horário exato do erro; a entrada traz o ID da regra que disparou.

Por que o ModSecurity bloqueou uma ação legítima?

É um falso positivo: alguma regra interpretou conteúdo válido como tentativa de ataque. O caso mais comum é salvar um post com trechos de código ou HTML, que se parecem com injeção de SQL. Quanto mais rigoroso o nível de paranoia configurado no servidor, mais frequentes esses bloqueios.

Devo desativar o ModSecurity?

Não. Desativá-lo remove a proteção contra todos os ataques que ele bloqueia silenciosamente todos os dias. O correto é identificar o ID da regra que causou o falso positivo e pedir ao suporte a liberação daquela regra específica para o seu site.

O que é o OWASP Core Rule Set?

É o conjunto de regras aberto mais usado com o ModSecurity, mantido pela comunidade OWASP. Ele cobre as principais categorias de ataque a aplicações web e serve de base para praticamente toda hospedagem que usa ModSecurity, geralmente complementado por regras próprias do provedor.

Qual a diferença entre ModSecurity e um plugin de segurança do WordPress?

A camada em que rodam. O ModSecurity é um módulo do servidor e inspeciona a requisição antes do PHP carregar. Um plugin roda dentro do WordPress, depois que ele já iniciou — então a requisição maliciosa já consumiu recursos da sua conta antes de ser barrada. Os dois são complementares, não redundantes.

Minha hospedagem tem ModSecurity?

Provavelmente sim, se for uma hospedagem séria. A maioria mantém ModSecurity ou solução equivalente ativa em todos os servidores, sem configuração do cliente. Vale confirmar com o suporte — e é também a explicação para bloqueios aparentemente inexplicáveis em ações específicas do site.

O que são níveis de paranoia?

São os níveis de rigor do OWASP Core Rule Set, de 1 a 4. Quanto maior, mais regras são aplicadas e mais rigorosa fica a inspeção — com mais falsos positivos como consequência. O nível 1 é o padrão e o recomendado para a maioria dos sites; níveis 3 e 4 são para ambientes de alto risco e exigem ajuste contínuo.

Veja também

Para o conceito geral de firewall de aplicação, veja o que é WAF. Sobre o erro que o ModSecurity gera quando bloqueia algo, veja erro 403 Forbidden. E sobre o isolamento entre contas no servidor, veja CageFS.

Conclusão

O ModSecurity faz um trabalho que só aparece quando erra: bloqueia ataques todos os dias sem que ninguém perceba, e chama atenção no dia em que barra um post legítimo. Entender isso muda a reação — em vez de pedir para desligar tudo, o caminho é pegar o ID da regra no log e liberar aquela especificamente. Leva o mesmo tempo, resolve o mesmo problema, e mantém no lugar a proteção que estava funcionando o tempo inteiro.

O post ModSecurity: o que é, como funciona e por que ele bloqueia seu site apareceu primeiro em Homehost.

Bounce é o e-mail que volta. A diferença entre os dois tipos está na permanência: o hard bounce é uma recusa definitiva — o endereço não existe, o domínio não existe, ou você foi bloqueado —, e reenviar não adianta. O soft bounce é temporário — a caixa está cheia, o servidor caiu, a mensagem é grande demais —, e o próprio servidor tenta de novo por até três dias antes de desistir.

O jeito mais rápido de saber qual você recebeu é olhar o código na mensagem de devolução: começa com 5xx é hard, começa com 4xx é soft. Essa única informação já diz se você precisa corrigir alguma coisa ou apenas esperar.

O que é um bounce

Quando você envia um e-mail, o seu servidor entrega a mensagem ao servidor do destinatário. Se essa entrega falha, o seu servidor devolve a mensagem com uma explicação — é o que se chama de bounce, ou devolução.

Essa devolução vem numa mensagem automática, geralmente com remetente mailer-daemon ou postmaster, e contém três informações úteis:

• O endereço que falhou
• Um código numérico de três dígitos
• Uma explicação em texto, geralmente em inglês

A maioria das pessoas lê só o texto e ignora o código. Mas é o código que separa os dois tipos, e é ele que diz se vale a pena tentar de novo.

O que é hard bounce

Hard bounce é a devolução permanente. O servidor do destinatário recusou a mensagem de forma definitiva, e tentar de novo não muda nada — o seu servidor nem tenta. O código da devolução começa com 5.

As causas são sempre de natureza estrutural:

• O endereço não existe. Erro de digitação, conta encerrada, ou endereço inventado
• O domínio não existe. A parte depois do @ aponta para um domínio inválido ou expirado
• O servidor bloqueou você. Por reputação ruim, falha de autenticação ou o IP estar numa lista de bloqueio

O que fazer: corrigir o endereço, se for erro de digitação — ou parar de enviar para ele. Num envio em volume, o endereço deve sair da lista imediatamente, porque cada nova tentativa piora a sua reputação como remetente.

O que é soft bounce

Soft bounce é a devolução temporária. Alguma coisa impediu a entrega naquele momento, mas o problema pode se resolver — e o seu servidor sabe disso, então continua tentando por até 72 horas antes de desistir. O código começa com 4.

As causas típicas:

• Caixa de entrada cheia. O destinatário estourou a cota e precisa liberar espaço
• Servidor do destinatário fora do ar ou sobrecarregado
• Mensagem grande demais para o limite de anexo do destinatário
• Limite de envios atingido, do seu lado ou do dele
• Greylisting — um atraso proposital do antispam, que aceita a mensagem na segunda tentativa

O que fazer: normalmente, nada. A entrega acontece sozinha na próxima tentativa. Se continuar voltando depois de um dia, vale avisar o destinatário por outro canal — pode ser que a caixa dele esteja cheia e ele não tenha percebido.

Atenção a um detalhe: um soft bounce que se repete por dias vira hard bounce quando o prazo de tentativas se esgota. O servidor desiste e devolve definitivamente.

A diferença na prática

Resumindo a diferença lado a lado:

Vale saber que a fronteira nem sempre é rígida. Servidores diferentes classificam a mesma situação de formas diferentes — um pode tratar uma caixa cheia como 4xx e outro como 5xx. E um soft bounce que se repete por dias acaba virando hard bounce quando o prazo de tentativas se esgota.

Como ler a mensagem de devolução

Esta é a parte que resolve o problema, e que a maioria dos artigos sobre o tema não cobre.

A devolução chega como um e-mail normal, e o trecho útil geralmente está no meio, num bloco com aparência técnica. Procure por uma linha parecida com:

Nesse exemplo: 550 indica falha permanente, e o texto explica que o destinatário não existe naquele servidor. Ou seja, o endereço está errado ou foi excluído.

As mensagens mais comuns e o que cada uma significa:

E-mail comum: o que fazer com um bounce

Se você não faz campanhas de marketing e só recebeu uma devolução ao enviar uma mensagem, o caso é simples:

Se for hard bounce, o problema quase sempre está no endereço. Confira a digitação — trocas de letra e domínios parecidos (gmail.con, hotnail.com) são as causas mais comuns. Se o endereço estiver certo, provavelmente a conta foi encerrada, e você precisa de outro contato.

Se for soft bounce, não faça nada por algumas horas. O seu servidor vai tentar de novo sozinho. Se depois de um dia continuar voltando, avise a pessoa por outro canal — pode ser que a caixa dela esteja cheia e ela não saiba.

Se todos os seus e-mails estão voltando, o problema não é o destinatário: é o seu domínio ou o seu servidor. Veja a seção sobre autenticação abaixo.

Envio em volume: por que o bounce importa mais

Se você dispara mensagens para muitos contatos — newsletter, comunicados, cobranças —, o bounce deixa de ser um incômodo pontual e vira um problema de reputação.

Provedores como Gmail e Outlook monitoram a sua taxa de devolução. Uma taxa alta sinaliza que você está enviando para endereços que não existem, e isso é característico de listas compradas ou desatualizadas — comportamento de spammer. A consequência é que suas mensagens passam a ser filtradas ou bloqueadas, inclusive as que iriam para endereços válidos.

A regra prática: remova imediatamente todo endereço que gera hard bounce. Não tente de novo — cada nova tentativa piora a sua reputação. Endereços com soft bounce podem ficar, mas se um deles falhar repetidamente por semanas, trate como hard.

E vale um cuidado com a origem dos endereços: listas compradas produzem taxas altíssimas de hard bounce, porque contêm endereços antigos, inventados ou armadilhas de spam. É o caminho mais rápido para queimar a reputação de um domínio.

Hospedagem compartilhada não é plataforma de envio em massa

Vale ser direto sobre isso: contas de hospedagem compartilhada têm limite de envios por hora, e não foram feitas para disparar milhares de mensagens. Usar a hospedagem para isso costuma resultar em bloqueio da conta, e uma taxa alta de bounce pode colocar o IP do servidor numa blocklist — prejudicando todos os outros clientes daquele servidor. Para envio em volume, o caminho é uma plataforma dedicada de e-mail marketing, que cuida de reputação, descadastro e relatórios.

Quando o bounce é culpa do seu domínio

Um cenário específico e muito comum: as devoluções não são de endereços inválidos, mas de servidores recusando as suas mensagens.

O sinal é claro — as devoluções mencionam SPF, DKIM, DMARC, ou vêm com mensagens sobre autenticação e reputação. Nesse caso, o endereço do destinatário está correto; o problema é que o servidor dele não confia no seu domínio.

As causas, em ordem:

• SPF, DKIM ou DMARC ausentes ou mal configurados. Desde 2024, Gmail e Yahoo exigem autenticação de quem envia em volume, e rejeitam quem não tem. Nosso guia sobre SPF, DKIM e DMARC cobre a configuração
• IP do servidor em blocklist, geralmente por causa de outra conta do mesmo servidor
• Registro MX mal configurado no seu domínio. Veja registro MX
• Conteúdo sinalizado como spam pelos filtros do destinatário

Esse é o tipo de bounce que você resolve — e que resolve todos os outros de uma vez.

Perguntas frequentes

O que é hard bounce?

É a devolução de um e-mail por uma falha permanente: o endereço não existe, o domínio é inválido, ou o servidor do destinatário bloqueou você definitivamente. O código da devolução começa com 5. Reenviar não resolve — é preciso corrigir o endereço ou parar de enviar para ele.

O que é soft bounce?

É a devolução por uma falha temporária: caixa de entrada cheia, servidor do destinatário fora do ar, mensagem grande demais ou limite de envio atingido. O código começa com 4. O seu servidor tenta entregar de novo automaticamente, por até 72 horas, antes de desistir.

Qual a diferença entre hard bounce e soft bounce?

A permanência. O hard bounce é definitivo e o servidor desiste na hora; o soft bounce é temporário e ele continua tentando. Na prática, o hard bounce exige uma ação sua — corrigir ou remover o endereço — enquanto o soft bounce costuma se resolver sozinho.

Como saber se meu e-mail deu hard ou soft bounce?

Abra a mensagem de devolução e procure o código de três dígitos. Começando com 5 é hard bounce; começando com 4 é soft bounce. O texto ao lado do código explica o motivo, geralmente em inglês.

Meu e-mail voltou dizendo “user unknown”. O que faço?

É hard bounce: o endereço não existe naquele servidor. Confira a digitação primeiro, porque trocas de letra e domínios parecidos como gmail.con são a causa mais frequente. Se o endereço estiver correto, a conta provavelmente foi encerrada.

Todos os meus e-mails estão voltando. Por quê?

Se a devolução acontece com destinatários diferentes, o problema não é o endereço deles: é o seu domínio ou o seu servidor. As causas mais comuns são SPF, DKIM e DMARC ausentes ou mal configurados, e o IP do servidor estar numa lista de bloqueio.

Qual taxa de bounce é aceitável?

Para envios em volume, o consenso do mercado é manter abaixo de 2%, e taxas acima de 5% já sinalizam problema sério de qualidade da lista. Para e-mail comum do dia a dia, a métrica não se aplica — uma devolução ocasional é normal.

Devo remover endereços que deram bounce da minha lista?

Os de hard bounce, sim, e imediatamente. Continuar enviando para endereços inexistentes prejudica a sua reputação como remetente e afeta a entrega de todas as suas mensagens. Os de soft bounce podem ficar, mas se um deles falhar repetidamente por semanas, trate como hard.

Veja também

Para configurar a autenticação do seu domínio, veja SPF, DKIM e DMARC. Sobre para onde os e-mails do seu domínio são entregues, veja registro MX. E sobre e-mails que caem na caixa de lixo em vez de voltar, veja o que é spam.

Conclusão

A distinção entre os dois tipos de bounce cabe numa linha: 5xx é definitivo, 4xx é temporário. O que muda é o que você faz — no primeiro caso, corrigir ou remover o endereço; no segundo, esperar. E há um terceiro cenário que não é sobre o destinatário: quando as devoluções vêm de endereços diferentes e mencionam autenticação, o problema é o seu domínio, e resolver isso conserta todos os envios de uma vez. Em qualquer caso, a resposta está na mensagem de devolução — basta ler o código antes do texto.

O post Hard bounce e soft bounce: o que significam e o que fazer apareceu primeiro em Homehost.

CloudLinux é um sistema operacional Linux feito especificamente para servidores de hospedagem compartilhada. Ele resolve o problema central de dividir uma máquina entre centenas de clientes: garantir que o comportamento de um não afete os demais. Faz isso com dois mecanismos principais — o LVE, que limita quanto de CPU e memória cada conta pode consumir, e o CageFS, que impede uma conta de enxergar os arquivos das outras.

É uma camada que o cliente nunca vê e cujo efeito só aparece pela ausência. Um servidor sem CloudLinux funciona normalmente — até o dia em que um site vizinho recebe um pico de acessos, ou é invadido. É por isso que ele aparece na descrição de planos de provedores sérios e some silenciosamente dos planos mais baratos.

O problema que o CloudLinux resolve

Hospedagem compartilhada funciona porque um servidor potente atende dezenas ou centenas de sites ao mesmo tempo. É o que torna possível hospedar um site por poucos reais por mês — o custo da máquina é rateado entre todos.

O problema é que, num Linux comum, essa divisão não existe de verdade. Todos os sites disputam os mesmos recursos e enxergam o mesmo sistema de arquivos. Na prática, isso produz duas situações:

O vizinho barulhento. Um site do servidor recebe um pico de acessos, ou tem um plugin mal feito que consome memória sem parar, ou é alvo de um ataque. Como não há limite por conta, ele consome o que estiver disponível — e todos os outros ficam lentos. Você não fez nada de errado, e mesmo assim o seu site sofre.

O vizinho comprometido. Um site desatualizado no servidor é invadido. Sem isolamento de arquivos, o atacante passa a enxergar as outras contas: quantas são, quais os nomes, onde ficam os arquivos. O que era problema de um cliente vira risco para todos.

Servidores antigos tentavam contornar isso com configurações do PHP e limites do sistema. Funcionava parcialmente — e é justamente essa insuficiência que motivou a criação de um sistema operacional dedicado ao problema.

O que é o CloudLinux

O CloudLinux é uma distribuição Linux comercial construída sobre a base do RHEL — a mesma família do CentOS, AlmaLinux e Rocky. Ele é compatível com essas distribuições, o que significa que qualquer software que roda nelas roda nele também.

A diferença está no kernel modificado, que traz recursos que o Linux comum não tem: a capacidade de limitar recursos por usuário e de criar sistemas de arquivos virtualizados individuais.

Um dado que vale conhecer: quando o CentOS 8 foi descontinuado em 2021, foi a própria CloudLinux que criou e mantém o AlmaLinux, hoje uma das principais alternativas gratuitas para servidores. É a mesma empresa por trás dos dois — um comercial, outro aberto.

Os componentes principais

LVE: isolamento de recursos

O LVE (Lightweight Virtual Environment) cria um “envelope” de recursos para cada conta de hospedagem. Dentro dele, ficam definidos limites de:

• CPU — quanto de processamento a conta pode usar
• Memória RAM — quanto pode alocar
• Processos simultâneos — quantos podem rodar ao mesmo tempo
• Entry processes — quantas requisições podem ser processadas simultaneamente
• I/O — velocidade de leitura e escrita em disco

O efeito é que um site nunca consegue consumir mais do que o seu limite, por mais que precise. Se ele estourar a cota, quem sofre é ele — os vizinhos continuam funcionando normalmente.

E há um segundo efeito, menos óbvio: os limites são por plano. Um plano mais caro aloca mais CPU e memória, o que dá uma justificativa técnica concreta à diferença de preço — não é só espaço em disco.

CageFS: isolamento de arquivos

O CageFS cria um sistema de arquivos virtual para cada conta. De dentro dele, o usuário vê uma estrutura de servidor normal, mas contendo apenas os próprios arquivos e as ferramentas necessárias. Não enxerga as contas dos vizinhos, nem os arquivos de configuração do sistema.

É o que impede que um site invadido vire porta de entrada para os demais. Nosso guia sobre o que é CageFS detalha o mecanismo e como verificar se a sua hospedagem usa.

Seletor de versão do PHP

Consequência direta do isolamento: como cada conta tem um ambiente próprio, cada uma pode rodar uma versão diferente do PHP, com extensões próprias.

Num servidor sem CloudLinux, a versão do PHP é definida globalmente. Se o servidor está no PHP 8.1, todos os sites rodam 8.1 — e um cliente com um sistema antigo que só funciona no PHP 7.4 simplesmente não pode ser atendido, ou obriga o provedor a manter um servidor separado.

É por isso que o seletor de versão do PHP no cPanel é um bom indício de CloudLinux.

Kernel com patches próprios

O CloudLinux mantém o próprio kernel, com correções de segurança aplicadas de forma independente. Isso inclui o KernelCare, uma tecnologia que aplica patches de segurança sem reiniciar o servidor — o chamado live patching.

Na prática, isso significa que uma vulnerabilidade crítica do kernel pode ser corrigida sem que os sites hospedados saiam do ar, o que em hospedagem compartilhada é uma diferença relevante.

Os componentes se complementam

Vale ver os dois principais lado a lado, porque a confusão entre eles é comum:

O outro lado: os limites que você sente

Vale ser honesto sobre isso, porque é a face menos confortável do CloudLinux.

Os mesmos limites que protegem você dos vizinhos também se aplicam a você. Se o seu site cresce e passa a exigir mais CPU do que o plano permite, você bate no teto — e o sintoma é o site ficando lento ou retornando erros em horários de pico.

As mensagens típicas dessa situação:

• Erro 508 (Resource Limit Is Reached) — a conta atingiu o limite de recursos
• Erro 503 em horários de pico, quando o limite de entry processes é atingido
• Lentidão que aparece e some, acompanhando o movimento do site

Isso não é defeito, é o sistema funcionando. Sem os limites, o seu site consumiria o servidor inteiro e derrubaria os outros — o que é exatamente o que acontecia antes.

O que fazer quando isso acontece: verificar no painel qual limite está sendo atingido (o cPanel mostra em Uso de recursos), otimizar o site para consumir menos, ou subir de plano. Nosso guia sobre erro 503 trata dos sintomas, e o de como acelerar o WordPress cobre a otimização.

CloudLinux em VPS e dedicado: faz sentido?

Uma dúvida razoável: se num VPS os recursos já são seus, para que isolar?

Faz sentido em dois casos:

• Se você revende hospedagem. Aí você tem os mesmos clientes compartilhando o seu servidor, e o problema volta a existir — com você no papel de provedor
• Se hospeda vários sites de clientes no mesmo VPS, mesmo sem revender formalmente

Não faz muito sentido se o VPS é só para os seus próprios sites: você já tem os recursos garantidos pelo hipervisor, e o isolamento entre os seus próprios projetos raramente compensa a licença.

Como saber se a sua hospedagem usa

Nem toda hospedagem compartilhada tem — o CloudLinux é licenciado por servidor, e é uma das primeiras coisas cortadas por provedores que competem só por preço.

Como verificar:

• Procure na descrição dos planos. Quem tem, anuncia
• Veja se há seletor de versão do PHP no painel. É indício forte
• Procure “Uso de recursos” ou “Resource Usage” no cPanel — esse painel é do LVE
• Pergunte ao suporte. A resposta, e a clareza dela, dizem bastante

Por que planos muito baratos não têm

O CloudLinux é uma licença paga, cobrada por servidor, e some da conta quando o provedor precisa espremer o preço. O efeito é duplo e invisível: sem o LVE, o provedor pode colocar muito mais contas no mesmo servidor — o que barateia o plano e degrada o desempenho de todos; e sem o CageFS, um site invadido enxerga os vizinhos. Você não percebe nada disso no dia da contratação. Percebe meses depois, quando o site fica lento sem explicação ou quando alguém no servidor é comprometido.

Perguntas frequentes

O que é CloudLinux?

É uma distribuição Linux comercial feita especificamente para servidores de hospedagem compartilhada. Construída sobre a base do RHEL, ela traz um kernel modificado com recursos que o Linux comum não tem: isolamento de recursos por conta (LVE) e sistema de arquivos virtualizado por usuário (CageFS).

Qual a diferença entre LVE e CageFS?

São os dois componentes principais do CloudLinux, e resolvem problemas diferentes. O LVE isola recursos: limita CPU, memória e processos de cada conta, impedindo que um site sobrecarregado deixe os outros lentos. O CageFS isola arquivos: impede que uma conta veja ou alcance os dados de outra.

CloudLinux deixa meu site mais rápido?

Indiretamente, sim. Ele não acelera o seu site em si, mas garante que os recursos do seu plano estejam disponíveis quando você precisa, em vez de serem consumidos por outro cliente do mesmo servidor. O ganho é de estabilidade e previsibilidade, que na prática significa não ficar lento em horários de pico por culpa alheia.

Por que meu site dá erro 508 ou fica lento em horários de pico?

Provavelmente porque atingiu os limites de recursos do plano, definidos pelo LVE. É o sistema funcionando como deveria: sem esses limites, o seu site consumiria o servidor inteiro. Verifique em Uso de recursos no cPanel qual limite está sendo atingido, e considere otimizar o site ou subir de plano.

Toda hospedagem compartilhada usa CloudLinux?

Não. É uma licença paga, cobrada por servidor, e uma das primeiras coisas cortadas por provedores que competem apenas por preço. Sem ela, o provedor pode colocar mais contas no mesmo servidor, o que barateia o plano e degrada o desempenho de todos.

Como sei se minha hospedagem usa CloudLinux?

Procure na descrição dos planos, veja se existe seletor de versão do PHP no painel, e se há uma seção de Uso de recursos no cPanel — esse painel é do LVE. Se nenhuma dessas pistas aparecer, pergunte ao suporte.

Preciso de CloudLinux num VPS?

Depende do uso. Se o VPS é só para os seus próprios sites, não compensa: os recursos já são garantidos pela virtualização. Faz sentido se você revende hospedagem ou hospeda sites de vários clientes no mesmo servidor, porque aí o problema de isolamento entre contas volta a existir.

Qual a relação entre CloudLinux e AlmaLinux?

O AlmaLinux foi criado e é mantido pela CloudLinux, a mesma empresa. Ele surgiu em 2021 como alternativa gratuita ao CentOS, que havia sido descontinuado. Os dois são compatíveis com o RHEL, mas o CloudLinux é comercial e traz os recursos de isolamento voltados a hospedagem compartilhada.

Veja também

Sobre o isolamento de arquivos em detalhe, veja o que é CageFS. Sobre as camadas de proteção de um site, veja o que é WAF. E para escolher hospedagem, veja melhor hospedagem de sites.

Conclusão

O CloudLinux existe porque hospedagem compartilhada tem um defeito de nascença: dividir uma máquina entre centenas de clientes sem que nenhum atrapalhe os outros não é o comportamento padrão do Linux. O LVE resolve a metade do desempenho, garantindo que os recursos do seu plano sejam seus; o CageFS resolve a metade da segurança, impedindo que um vizinho comprometido alcance você. Nenhum dos dois aparece na sua tela — e é justamente por isso que somem dos planos mais baratos sem que ninguém reclame no dia da contratação. A conta chega depois.

O post CloudLinux: o que é e por que ele importa na sua hospedagem apareceu primeiro em Homehost.

CageFS é a tecnologia do CloudLinux que coloca cada conta de hospedagem dentro da própria “gaiola” — um sistema de arquivos virtualizado em que o usuário enxerga apenas os próprios arquivos e as ferramentas de que precisa, e mais nada. Num servidor compartilhado com centenas de contas, é o que impede que um cliente veja os arquivos de outro, descubra quem mais está no servidor, ou leia arquivos de configuração do sistema.

O ponto que quase ninguém explica: sem essa camada, um site invadido num servidor compartilhado pode virar porta de entrada para os vizinhos. O CageFS é o que transforma “o servidor foi comprometido” em “uma conta foi comprometida” — e essa diferença é enorme para quem está na conta ao lado.

O problema que o CageFS resolve

Para entender por que ele existe, vale entender como era antes.

Num servidor Linux comum, todos os usuários compartilham o mesmo sistema de arquivos. Cada um tem sua pasta pessoal, mas o restante do sistema é visível para todos: dá para listar /home e ver os nomes de todas as contas, ler arquivos de configuração do Apache, consultar /etc/passwd, e navegar por boa parte da estrutura do servidor.

Isso cria três problemas em hospedagem compartilhada:

Reconhecimento. Um atacante que compromete uma conta qualquer — muitas vezes um site desatualizado, de alguém que nem sabe que foi invadido — passa a enxergar todos os outros clientes do servidor. Ele sabe quantos são, quais os nomes, e onde ficam os arquivos.

Vazamento de informação. Arquivos de configuração podem conter caminhos, versões de software e outras pistas úteis para quem procura uma falha.

Escalada. Com visibilidade do sistema, fica mais fácil encontrar uma brecha que permita sair da própria conta.

Historicamente, hospedagens tentavam resolver isso com restrições no php.ini — desabilitando funções perigosas, usando open_basedir. Funciona parcialmente, e é justamente essa limitação que motivou o CageFS: essas restrições são contornáveis com alguma frequência, e não valem para scripts CGI, que rodam fora do PHP.

Como o CageFS funciona

Ele cria, para cada usuário, um sistema de arquivos virtual completo — uma “gaiola”. De dentro dela, tudo parece um servidor normal: existe /etc, /bin, /usr, /tmp. A diferença é que esse conteúdo é montado especialmente para aquele usuário.

Tecnicamente, o CageFS usa recursos do próprio kernel do Linux — bind mounts e isolamento de namespace — para montar essa visão. Os arquivos de sistema são compartilhados em modo somente leitura (para não desperdiçar espaço), enquanto a pasta pessoal e o /tmp são privados e graváveis.

É parecido com o chroot, mas vai bem além: o chroot apenas troca o diretório raiz, enquanto o CageFS controla também processos, /proc e quais binários existem dentro da gaiola.

O que muda na prática

Aqui está o que a maioria dos artigos sobre o tema não responde: e daí?

Aquele último ponto é um benefício menos óbvio: o CageFS é o que permite cada conta escolher sua própria versão de PHP. O seletor de versão do PHP no cPanel funciona porque cada usuário tem um ambiente isolado — sem isso, a versão seria a mesma para todos no servidor.

CageFS e LVE: são coisas diferentes

Confusão comum, porque os dois vêm do CloudLinux e ambos fazem “isolamento”. Mas isolam coisas distintas:

Os dois são componentes do CloudLinux, o sistema operacional feito especificamente para hospedagem compartilhada. Juntos, eles resolvem os dois problemas clássicos de dividir um servidor: segurança e desempenho.

Quando um site fica lento porque outro no mesmo servidor recebeu um pico de acessos — ou porque boa parte do tráfego da web é de bots —, é o LVE que contém o estrago.

Isolamento por site: a evolução recente

Uma novidade que vale conhecer, porque muda o cenário para quem tem vários sites na mesma conta.

O modelo tradicional isola contas umas das outras. Mas se você hospeda cinco sites dentro da mesma conta de hospedagem — algo comum em planos que permitem domínios ilimitados —, esses cinco compartilham o mesmo ambiente. Um deles comprometido pode alcançar os outros quatro.

O CloudLinux introduziu recentemente o isolamento por site, que estende a lógica da gaiola para cada site individualmente, e não apenas para cada conta. É especialmente relevante para agências e revendedores, que costumam concentrar vários clientes numa mesma conta.

Como saber se a sua hospedagem usa CageFS

Nem toda hospedagem compartilhada tem — o CloudLinux é licenciado, tem custo por servidor, e é uma das primeiras coisas que provedores muito baratos cortam.

Como verificar:

• Pergunte ao suporte. É a forma mais direta, e a resposta diz bastante sobre o provedor
• Procure na descrição dos planos. Quem tem, costuma anunciar — é diferencial
• Teste pelo terminal, se tiver acesso SSH: rode ls /home. Se aparecer uma lista de contas de outros clientes, não há CageFS. Se aparecer só a sua, há
• Verifique o seletor de PHP no painel. Se você consegue escolher a versão do PHP só para a sua conta, é forte indício de CloudLinux

É isso que separa hospedagem barata de hospedagem barata demais

Numa hospedagem compartilhada, você não escolhe seus vizinhos e não tem como saber se o site ao lado está atualizado. O que separa você deles é a camada de isolamento — e ela custa dinheiro ao provedor. Quando um plano é dramaticamente mais barato que o mercado, o corte costuma vir daqui: sem CloudLinux, sem CageFS, sem isolamento de recursos. Você não vê a diferença até o dia em que um vizinho é invadido.

O que o CageFS não faz

Delimitar importa, porque isolamento não é proteção completa:

• Não impede que o seu site seja invadido. Se você tem um plugin vulnerável, o atacante entra na sua conta. O CageFS impede que ele saia dela — o que protege os outros, não você
• Não substitui atualizações. Manter WordPress, plugins e temas em dia continua sendo a defesa principal
• Não é firewall. Ele não filtra tráfego; para isso existe o WAF — implementado na maioria dos servidores pelo ModSecurity — e o firewall de rede.
• Não substitui backup. Se a sua conta for comprometida, restaurar continua sendo o caminho

Pense nele como as paredes corta-fogo de um prédio: não impedem o incêndio, mas impedem que ele se espalhe.

Perguntas frequentes

O que é CageFS?

É uma tecnologia do CloudLinux que cria um sistema de arquivos virtualizado para cada usuário de um servidor compartilhado — uma “gaiola”. Dentro dela, o usuário vê apenas os próprios arquivos e as ferramentas necessárias para o site funcionar, sem enxergar as contas dos outros clientes nem os arquivos de configuração do servidor.

Qual a diferença entre CageFS e LVE?

Os dois são componentes do CloudLinux, mas isolam coisas diferentes. O CageFS isola arquivos e processos: impede que uma conta veja ou alcance os dados de outra. O LVE isola recursos: limita quanto de CPU, memória e I/O cada conta pode consumir, impedindo que um site sobrecarregado prejudique os demais.

O CageFS deixa meu site mais lento?

Não de forma perceptível. Ele funciona no nível do kernel, usando recursos nativos do Linux, e os arquivos de sistema são compartilhados em modo somente leitura — o que evita duplicação. Na prática, o isolamento tende a melhorar a estabilidade geral do servidor, o que beneficia o desempenho.

Preciso configurar alguma coisa?

Não. O CageFS é configurado pelo administrador do servidor e funciona de forma transparente para o cliente. Você não precisa fazer nada, e o site funciona normalmente — a diferença é o que você não vê: as contas dos vizinhos.

Como sei se minha hospedagem usa CageFS?

Pergunte ao suporte, que é a forma mais direta, ou verifique se os planos mencionam CloudLinux. Com acesso SSH, o comando ls /home mostra: se aparecerem contas de outros clientes, não há isolamento; se aparecer só a sua, há. A presença de um seletor de versão do PHP no painel também é bom indício.

O CageFS impede que meu site seja invadido?

Não. Se o seu site tem uma vulnerabilidade, o atacante consegue entrar na sua conta. O que o CageFS faz é impedir que ele saia dela e alcance outras contas do servidor. Ele protege os vizinhos de você, e você dos vizinhos — mas não substitui manter WordPress, plugins e temas atualizados.

Toda hospedagem compartilhada tem CageFS?

Não. O CloudLinux é uma licença paga, com custo por servidor, e provedores que competem apenas por preço costumam cortá-la. É uma das diferenças invisíveis entre planos aparentemente iguais — e uma das mais relevantes em termos de segurança.

O que é isolamento por site?

É uma evolução recente do CageFS. O modelo tradicional isola contas umas das outras, mas vários sites dentro da mesma conta compartilham o ambiente. O isolamento por site estende a gaiola para cada site individualmente, o que interessa especialmente a agências e revendedores que concentram vários clientes numa conta.

Veja também

Sobre a camada que filtra o tráfego antes de chegar ao site, veja o que é WAF e o que é firewall. Sobre a escolha de hospedagem, veja melhor hospedagem de sites.

Conclusão

O CageFS resolve um problema que só existe porque hospedagem compartilhada é, por definição, compartilhada: num servidor com centenas de contas, alguém sempre estará com o site desatualizado. A gaiola faz com que isso seja um problema daquela conta, e não do servidor — o atacante que entra por uma porta não encontra as outras, nem sabe que existem. É uma proteção que você nunca percebe funcionando, e que só se nota pela ausência: quando um provedor corta essa camada para baratear o plano, a diferença aparece no dia em que o vizinho é invadido.

O post CageFS: o que é e por que ele protege seu site na hospedagem compartilhada apareceu primeiro em Homehost.