Auditoria de servidor web (Apache/Nginx, PHP-FPM, MySQL): desempenho e segurança

Seu site está lento, apresenta erros 502/504 ou tem falhas de segurança? Seu servidor chega a 100% de CPU com apenas 50 visitantes simultâneos? Eu faço uma auditoria técnica completa do seu servidor (Ubuntu/Debian, OVH/Scaleway, Contabo...) para reduzir o TTFB, estabilizar a carga e reforçar a segurança.

A auditoria cobre toda a stack técnica: protocolos de rede (TLS/HTTP2), configuração do servidor web (Nginx/Apache), otimização do PHP-FPM, análise das consultas lentas do MySQL, segurança do sistema e implementação de ferramentas de monitoramento. Entrega: relatório claro e priorizado, com a possibilidade de eu mesmo aplicar as correções.

Por que fazer uma auditoria de servidor web?

Os sintomas que devem acender o alerta

Sua infraestrutura de servidor está dando sinais de fraqueza se você enfrenta um ou mais destes problemas:

Desempenho degradado:

• Tempo de resposta do servidor (TTFB) acima de 600ms, quando o objetivo é < 200ms
• O site fica lento ou inacessível assim que o tráfego aumenta (50-100 visitantes simultâneos)
• As páginas levam 5-10 segundos para carregar, quando só o HTML deveria ser entregue em < 1 segundo
• Os Core Web Vitals estão no vermelho (LCP > 4s, TTFB > 800ms)

Erros recorrentes:

• Erros 502 Bad Gateway ou 504 Gateway Timeout várias vezes por dia
• Erros 500 Internal Server Error sem causa aparente nos logs da aplicação
• Conexões PHP-FPM saturadas (“max children reached”)
• MySQL recusando novas conexões (“Too many connections”)

Problemas de estabilidade:

• O servidor precisa ser reiniciado com frequência (várias vezes por semana)
• Consumo de CPU ou RAM em 90-100% o tempo todo, sem pico de tráfego que justifique
• Os processos do PHP-FPM ou do MySQL são encerrados aleatoriamente (OOM Killer)
• Os logs mostram dezenas de consultas lentas (> 2 segundos) todos os dias

Vulnerabilidades de segurança:

• Certificado SSL/TLS expirado ou configuração fraca (ciphers obsoletos, sem HSTS)
• Nenhum firewall configurado ou regras permissivas demais
• Nenhuma proteção contra ataques de força bruta (sem fail2ban)
• Versões de PHP, MySQL ou do sistema operacional desatualizadas e sem patches
• Acesso SSH como root com senha (em vez de chaves SSH)

Impacto desses problemas no negócio

Um servidor mal configurado tem consequências diretas e mensuráveis para a sua empresa:

Perda de receita: um site que leva 5 segundos para carregar perde 20% dos visitantes (estudo do Google). Para um e-commerce que fatura € 50.000/mês, isso representa € 10.000 por mês deixados na mesa.

Penalidades de SEO: o Google penaliza sites lentos em seu algoritmo. Uma página que passa de 2 para 5 segundos de carregamento pode perder 30-50% do tráfego orgânico em poucos meses.

Custos de infraestrutura inflados: um servidor mal otimizado muitas vezes acaba exigindo um upgrade de hardware caro (de 4 para 8 CPUs, o dobro de RAM), quando uma simples otimização de software resolveria o problema por um custo 10 vezes menor.

Risco de invasão: 43% dos ciberataques têm como alvo pequenas e médias empresas (relatório Verizon 2024). Um servidor sem hardening é uma porta de entrada para phishing, roubo de dados de clientes ou ransomware.

O que eu analiso em detalhe

Minha auditoria de servidor cobre 7 camadas técnicas essenciais, com medições de antes/depois para quantificar as melhorias.

1. Rede e protocolo

O que eu verifico:

• Configuração TLS/HTTPS: versão do protocolo (no mínimo TLS 1.2, de preferência 1.3), suítes de criptografia seguras, cadeia de certificados completa
• Cabeçalhos de segurança: HSTS, CSP, X-Frame-Options, X-Content-Type-Options
• HTTP/2 ou HTTP/3 ativado para multiplexação e compressão de cabeçalhos
• Compressão Gzip/Brotli configurada para HTML/CSS/JS/JSON
• DNS: tempo de resolução, configuração de DNSSEC, se aplicável

O que isso revela: ciphers obsoletos (RC4, 3DES) deixam seu site vulnerável a ataques BEAST ou POODLE. A ausência de HTTP/2 custa 20-30% de velocidade em páginas com muitos recursos. Um tempo de resolução de DNS alto (> 100ms) torna todas as requisições sistematicamente mais lentas.

Impacto mensurável: migrar para TLS 1.3 + HTTP/2 + Brotli = redução de 25-40% no tempo total de carregamento e nota A+ no SSL Labs.

2. Configuração do Nginx / Apache

O que eu verifico:

• Cache de arquivos estáticos: diretivas expires, cache-control, etag para imagens/CSS/JS
• Cabeçalhos de compressão: gzip_types, brotli_types
• Logs: formato personalizado com $request_time e $upstream_response_time para depuração
• Rate limiting: proteção contra scrapers e bots agressivos
• WAF básico: ModSecurity ou limit_req do Nginx para bloquear padrões de ataque comuns
• Arquivos de configuração: worker_processes, worker_connections, keepalive_timeout, client_max_body_size

O que isso revela: worker_connections em 768 em vez de 4096 limita artificialmente o número de conexões simultâneas. Sem cache de arquivos estáticos, o navegador precisa baixar de novo os assets a cada visita. Um client_max_body_size de 2M bloqueia o upload de arquivos de mídia.

Impacto mensurável: configuração ideal = 50-60% de economia de banda graças ao cache do navegador + capacidade de processar 4x mais conexões simultâneas.

3. PHP-FPM: o gargalo invisível

O que eu verifico:

• Estratégia de gerenciamento de processos: pm = dynamic x static x ondemand
• Dimensionamento: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers
• Limites: pm.max_requests (reciclagem dos workers), request_timeout, request_terminate_timeout
• Opcache: opcache.memory_consumption, opcache.interned_strings_buffer, opcache.max_accelerated_files, taxa de acerto (hit rate)
• Limites do PHP: memory_limit, max_execution_time, post_max_size, upload_max_filesize
• Slow log: ativação e análise das requisições PHP lentas (> 1s)

O que isso revela: este é O principal ponto de bloqueio em 80% dos servidores. Exemplo típico: pm.max_children = 5 em um servidor com 4 CPUs → a partir de 6 requisições simultâneas, as seguintes entram na fila, gerando timeouts.

Um opcache mal configurado (pequeno demais, sem preloading no PHP 8.x) obriga o PHP a recompilar os scripts a cada requisição, multiplicando a carga de CPU por 5-10x.

Impacto mensurável: passar de pm.max_children = 5 para pm.max_children = 40 (dimensionado conforme a RAM disponível) + opcache otimizado = redução de 70% no TTFB + fim dos erros “502 Bad Gateway”.

Exemplo concreto: site WordPress com WooCommerce, 4GB de RAM, pm.max_children = 5 (padrão).

• Antes: erros 502 a partir de 8 visitantes simultâneos, TTFB de 3-6 segundos
• Depois: pm.max_children = 30, pm = dynamic, opcache ativado → TTFB de 0,4 s, nenhum erro 502 até 100 visitantes simultâneos

4. Banco de dados MySQL / MariaDB

O que eu verifico:

• Configuração de conexões: max_connections, wait_timeout, interactive_timeout
• Buffers e cache: innodb_buffer_pool_size, query_cache_size (se MySQL < 8.0), tmp_table_size
• Slow query log: ativação e análise das consultas > 1 segundo
• Índices ausentes: EXPLAIN nas consultas mais frequentes para identificar full table scans
• Bloqueios: detecção de deadlocks e transações longas
• Otimização de tabelas: fragmentação, tabelas não utilizadas, ANALYZE TABLE

O que isso revela: um innodb_buffer_pool_size de 128MB (padrão) em um servidor com 16GB de RAM = o MySQL não consegue manter em cache os dados mais acessados e recorre ao disco o tempo todo.

Consultas sem índice obrigam o MySQL a varrer 500.000 linhas em vez de 10, multiplicando o tempo de execução por 5000x (de 0,001 s para 5 s).

Impacto mensurável: innodb_buffer_pool_size ajustado para 70% da RAM + 3-5 índices estratégicos = redução de 80% nas slow queries + tempo de resposta das páginas dividido por 3.

5. Desempenho da aplicação e TTFB

O que eu meço:

• TTFB (Time To First Byte) a partir de diferentes pontos geográficos: objetivo < 200ms para a Europa
• LCP (Largest Contentful Paint): objetivo < 2,5 s
• Tempo de geração do HTML puro (sem assets): deve ser < 400ms para uma página dinâmica
• Número de consultas SQL por página: mais de 50 consultas = problema N+1 a investigar
• Tamanho e peso dos assets: imagens não otimizadas, JS/CSS não minificados
• Estratégia de cache da aplicação: Redis/Memcached, cache de HTML estático (Varnish, fastcgi_cache do nginx)

O que isso revela: um TTFB de 2-4 segundos indica que o servidor leva esse tempo só para começar a enviar os dados. Mesmo com conexão de fibra, o usuário fica esperando. O problema costuma ser uma combinação de PHP lento + consultas MySQL não otimizadas + falta de cache.

Impacto mensurável: otimização combinada (PHP-FPM + MySQL + cache Redis) = TTFB caindo de 2,8 s para 0,3 s e LCP de 6 s para 2,1 s → os Core Web Vitals passam para “Bom”.

6. Segurança do sistema e hardening

O que eu verifico:

• Firewall: UFW ou iptables configurado, mínimo de portas abertas (22, 80, 443), bloqueio de varreduras de portas
• Fail2ban: proteção de SSH, HTTP e MySQL contra ataques de força bruta
• Acesso SSH: login como root desativado, autenticação somente por chaves SSH, porta não padrão
• Usuários e permissões: nenhum serviço rodando como root, usuários separados para web e banco de dados
• Atualizações: versões de PHP, MySQL e sistema operacional em dia, com os patches de segurança
• Backups: frequência, retenção, teste de restauração, armazenamento fora do servidor
• Rotação de logs: logrotate configurado, compressão, exclusão automática de logs antigos
• Detecção de intrusões: detecção de arquivos modificados, monitoramento da integridade do sistema

O que isso revela: 80% dos servidores auditados não têm fail2ban ou o têm mal configurado, o que permite milhares de tentativas de login SSH por dia. A falta de backups testados = risco de perda total de dados em caso de falha de disco ou ransomware.

Impacto mensurável: hardening completo = redução de 95% nas tentativas de invasão (logs do fail2ban) + garantia de restauração em < 2h em caso de incidente grave.

7. Observabilidade e monitoramento

O que eu implemento:

• Análise de logs: erros do PHP, erros do Nginx, slow queries do MySQL, erros do sistema
• Métricas do servidor: CPU, RAM, disco, rede, swap
• Alertas básicos: e-mail/SMS se a CPU ficar > 90% por 5 min, disco > 85%, serviço fora do ar
• Ferramentas: Netdata (leve, gratuito) ou New Relic (se houver orçamento)
• Dashboard simples: uma olhada rápida para ver a saúde do servidor

Impacto: detecção proativa: você recebe o alerta 10 minutos antes de o servidor cair, em vez de descobrir o problema pelas reclamações dos clientes. Redução do MTTR (Mean Time To Repair) de 2 horas para 15 minutos.

Minha metodologia completa

Fase 1: acesso e análise preliminar (30 min)

Acesso:

• Conexão SSH (chave pública fornecida) ou acesso ao painel OVH/Plesk/ISPConfig
• Acesso de leitura aos logs (/var/log/nginx, /var/log/php-fpm, /var/log/mysql)
• Credenciais MySQL somente leitura para analisar as slow queries

Coleta inicial:

• Inventário: versões do PHP, MySQL, sistema e servidor web
• Estatísticas: uptime, load average, uso atual de CPU/RAM/disco
• Leitura rápida dos logs: identificação dos erros recorrentes

Fase 2: testes de desempenho e de carga (1h)

Medições de referência (baseline):

• TTFB a partir de 3 localizações diferentes (Europa, EUA, Ásia) com curl/webpagetest
• Teste de carga: simulação de 10, 50 e 100 usuários simultâneos com Apache Bench ou k6
• Profiling do PHP: ativação do Xdebug ou do Blackfire para identificar as funções lentas
• Análise do MySQL: top 20 das consultas lentas via pt-query-digest (Percona Toolkit)

Identificação dos gargalos: o teste de carga mostra exatamente onde a coisa quebra: é o PHP-FPM que satura? O MySQL que trava (lock)? A RAM que começa a usar swap?

Fase 3: análise de segurança (45 min)

Varredura de vulnerabilidades:

• Teste de SSL: ssllabs.com, testssl.sh para identificar fraquezas no TLS
• Varredura de portas abertas: nmap para detectar serviços expostos desnecessariamente
• Verificação de CVEs: versões desatualizadas de PHP/MySQL com vulnerabilidades conhecidas
• Auditoria de arquivos: arquivos com permissão 777, possíveis scripts de backdoor

Revisão da configuração:

• Análise do /etc/ssh/sshd_config, das regras de firewall e das jails do fail2ban
• Verificação da existência e da validade dos backups

Fase 4: análise das configurações (1h)

Mergulho profundo nas configurações:

• Nginx/Apache: leitura linha por linha dos arquivos de configuração + benchmarks
• PHP-FPM: cálculo da memória total consumida (pm.max_children * memory_limit) x RAM disponível
• MySQL: análise do my.cnf, recomendações do MySQLTuner
• Sistema: configuração de limites (ulimit), swap, parâmetros do kernel

Fase 5: redação do relatório (1-2h)

Estrutura do relatório:

1. Resumo executivo (2 páginas)

• Os 3 problemas críticos identificados
• Impacto estimado no negócio (ex.: perda de 15% do tráfego orgânico, 25% de visitantes que desistem)
• Orçamento das correções: € 0-500 (configuração), € 500-1.500 (otimizações complexas), > € 1.500 (migração/upgrade de hardware)

2. Diagnósticos detalhados (5-10 páginas)

• Cada problema documentado com capturas de tela, trechos de logs e métricas
• Explicação técnica acessível (sem jargão desnecessário)
• Gravidade: Crítico / Importante / Oportunidade

3. Plano de ação priorizado (2-3 páginas) Tabela: Ação | Impacto estimado | Complexidade | Tempo | Custo

Exemplo:

• Aumentar pm.max_children de 5 para 30 | Redução de 70% nos erros 502 | Baixa | 10 min | Incluído
• Adicionar 3 índices MySQL na tabela orders | Consultas 50x mais rápidas | Média | 1h | Incluído
• Migrar para um servidor com 8GB de RAM | Aguenta 3x mais carga | Alta | 4h | € 150 de migração

4. Recomendações de longo prazo

• Plano de monitoramento contínuo
• Frequência de atualização recomendada
• Roadmap de melhorias para 6-12 meses

Caso real de cliente: e-commerce com WooCommerce

Contexto inicial

Cliente: loja virtual especializada em produtos artesanais, 500-800 visitantes/dia, 5000 produtos, ticket médio de € 85.

Infraestrutura:

• VPS OVH Comfort (4 vCPU, 4GB de RAM)
• Ubuntu 20.04, Nginx 1.18, PHP 7.4, MySQL 5.7
• WordPress 6.1 + WooCommerce 7.5 + 15 plugins ativos

Sintomas relatados

• Picos de lentidão todos os dias entre 14h e 16h (pausa para o almoço = tráfego máximo)
• Erros 502 Bad Gateway 2-3 vezes por dia, exigindo reiniciar o PHP-FPM
• Páginas de produto levando 6-8 segundos para carregar
• Google Search Console indicando “Ruim” em 70% das páginas (LCP > 4s)
• Taxa de rejeição subiu de 45% para 62% em 3 meses
• Perda estimada: € 200-300/dia em vendas perdidas

Diagnósticos da auditoria (2h30)

1. PHP-FPM: configuração catastrófica

pm = dynamic
pm.max_children = 5 ATTENTION: (CRITIQUE)
pm.start_servers = 2
memory_limit = 128M

Cálculo: 5 processos filhos × 128MB = no máximo 640MB para o PHP, com 4GB de RAM disponíveis → a partir de 6 requisições simultâneas, fila de espera → timeout 502

2. MySQL: consultas lentas e índices ausentes

• 847 consultas > 2 segundos nas últimas 24h
• Consulta em wp_postmeta sem índice: 3,8 s para filtrar por meta_key
• innodb_buffer_pool_size = 128M (padrão), com um banco de dados de 2,1GB

3. Opcache do PHP: desativado

• O PHP recompila todos os arquivos do WordPress/WooCommerce a cada requisição
• Carga de CPU desnecessária multiplicada por 8-10x

4. Sem cache de aplicação

• Nenhum plugin de cache de HTML (WP Super Cache, W3 Total Cache)
• Cada página recalculada a cada visita, mesmo para visitantes não logados

5. Segurança fraca

• Fail2ban não instalado: 3200 tentativas de login SSH/dia
• PHP 7.4: 12 CVEs críticas sem patch (PHP 8.1 disponível)

Correções aplicadas (3h)

PHP-FPM (15 min)

pm.max_children = 30 (4GB RAM / 130MB par enfant)
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500

Opcache (5 min)

opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 10000
opcache.validate_timestamps = 0 (prod)
opcache.enable_cli = 1

MySQL (45 min)

-- Ajout index manquant
ALTER TABLE wp_postmeta ADD INDEX meta_key_value (meta_key, meta_value(20));
-- Configuration
innodb_buffer_pool_size = 2G (50% de la RAM)
max_connections = 200
query_cache_size = 0 (inutile MySQL 5.7+)

Cache de aplicação (30 min)

• Instalação do WP Rocket (licença do cliente)
• Configuração: cache de HTML, minificação de CSS/JS, lazy loading de imagens
• Geração do cache para as 500 páginas principais

Segurança (1h)

• Atualização do PHP 7.4 → 8.1
• Instalação do fail2ban com jails para SSH + HTTP
• Hardening do SSH: root desativado, somente chaves
• Backups automáticos diários para o S3

Resultados medidos (7 dias depois)

Desempenho:

• TTFB: ~~3,2 s~~ → 0,4 s (-87%)
• LCP: ~~6,1 s~~ → 2,0 s (-67%)
• Página de produto: ~~7,2 s~~ → 1,8 s (-75%)
• Core Web Vitals: ~~12% Bom~~ → 89% Bom

Estabilidade:

• Erros 502: ~~2-3/dia~~ → 0 em 7 dias
• Load average: ~~4,5~~ → 0,8 (em 4 CPUs)
• RAM utilizada: ~~92%~~ → 65%

Negócio:

• Taxa de rejeição: ~~62%~~ → 48% (-14 pontos)
• Tempo no site: +22%
• Conversões: +18% (calculado em 7 dias, comparado à semana anterior)
• Estimativa: +€ 280/dia de faturamento, ou seja, +€ 8.400/mês

Segurança:

• Tentativas de SSH bloqueadas: 3200/dia → 0 (IPs banidos automaticamente)
• Vulnerabilidades CVE: ~~12 críticas~~ → 0

Custo total: auditoria (€ 490) + execução (€ 350) + licença do WP Rocket (€ 59/ano) = € 899 sem impostos (HT) ROI: investimento recuperado em 3 dias de faturamento adicional

Auditoria de servidor x outros tipos de auditoria

É importante distinguir bem os diferentes tipos de auditoria web, porque eles não cobrem os mesmos aspectos:

Meu conselho: para um site que está se arrastando, comece sempre pela auditoria de servidor. Não adianta otimizar suas imagens se o seu TTFB está em 4 segundos por causa de um PHP-FPM mal configurado.

Checklist: você precisa de uma auditoria de servidor?

Responda com sinceridade às perguntas a seguir. Se você marcar 3 ou mais itens, uma auditoria de servidor é altamente recomendada.

• [ ] Meu site leva mais de 3 segundos para carregar em uma boa conexão
• [ ] Tenho erros 502, 504 ou 500 pelo menos uma vez por semana
• [ ] Meu servidor precisa ser reiniciado manualmente pelo menos uma vez por mês
• [ ] Não sei o valor de pm.max_children do meu PHP-FPM
• [ ] Meu site fica muito mais lento quando tenho mais de 50 visitantes simultâneos
• [ ] Nunca otimizei meu banco de dados MySQL
• [ ] Meu certificado SSL tem nota < A no SSL Labs
• [ ] Não atualizo o sistema ou o PHP há mais de 6 meses
• [ ] Não tenho um sistema de backup automático testado
• [ ] Meu provedor de hospedagem já entrou em contato comigo por “uso excessivo de recursos”
• [ ] O Google Search Console indica “Ruim” nos meus Core Web Vitals
• [ ] Minha taxa de rejeição aumentou mais de 10% nos últimos meses sem motivo aparente

Pontuação:

• 0-2 itens marcados: seu servidor parece estar OK, mas ainda é recomendável uma verificação preventiva a cada 12-18 meses
• 3-5 itens marcados: auditoria recomendada nos próximos 1-2 meses; você provavelmente tem quick wins fáceis
• 6+ itens marcados: auditoria urgente; você provavelmente está perdendo clientes e faturamento todos os dias

Entregas e etapas

O que você recebe

1. Relatório de auditoria completo (PDF de 15-25 páginas)

• Resumo executivo com os 3 problemas mais críticos
• Diagnósticos detalhados com capturas de tela e trechos de logs
• Plano de ação priorizado por impacto/complexidade
• Recomendações de longo prazo

2. Arquivos de configuração otimizados

• Configurações do Nginx/Apache comentadas e prontas para implantar
• Pool do PHP-FPM dimensionado para o seu servidor
• Arquivo my.cnf do MySQL otimizado
• Scripts básicos de monitoramento e alertas

3. Documentação de procedimentos

• Checklist de implantação das correções
• Guia de rollback em caso de problema
• Procedimento de restauração de backup

4. Acompanhamento pós-atendimento (opcional)

• Acesso ao painel de monitoramento por 30 dias
• Suporte por e-mail por 7 dias para dúvidas
• Sessão de treinamento de 30 min (configuração, leitura das métricas)

Etapas típicas

D0: primeiro contato

• Briefing por telefone ou videochamada de 15 min para entender seus problemas
• Envio de um questionário técnico prévio
• Orçamento em até 24h

D+1 a D+2: acessos e preparação

• Criação dos acessos SSH/painel
• Instalação de ferramentas de monitoramento não intrusivas, se você concordar
• Coleta dos logs e das métricas de referência

D+3: auditoria (2-4 horas)

• Análise aprofundada de todas as camadas (rede, servidor, PHP, MySQL, segurança)
• Testes de carga para identificar os limites
• Documentação das descobertas em tempo real

D+4 a D+5: redação e apresentação

• Redação do relatório completo
• Videochamada de 30-45 min para apresentar as descobertas e recomendações
• Respostas às suas dúvidas técnicas

D+6 (opcional): aplicação das correções

• Backup completo do sistema antes do atendimento
• Aplicação das otimizações por ordem de prioridade
• Testes de não regressão após cada alteração
• Medições pós-atendimento: verificação de que os objetivos foram atingidos

D+7: validação e encerramento

• Relatório de validação com métricas de antes/depois
• Transferência de conhecimento e treinamento rápido
• Documentação final + suporte por 7 dias

Resultados típicos após auditoria + otimização

Com base em mais de 40 auditorias de servidor realizadas desde 2020, estas são as melhorias médias observadas:

Desempenho

• TTFB reduzido em 30 a 70%: de 1,5-3 s para 0,3-0,8 s, em média
• LCP melhorado em 40-60%: a maioria dos sites passa de “Ruim” para “Bom” (< 2,5 s)
• Capacidade de carga multiplicada por 3-5x: um servidor que caía com 30 visitantes simultâneos agora aguenta 100-150
• Fim dos erros 5xx: 90% dos sites deixam de ter qualquer erro 502/504 após a otimização

Segurança

• Redução de mais de 95% nas tentativas de invasão graças ao fail2ban
• Superfície de ataque reduzida: fechamento das portas desnecessárias, atualizações de segurança aplicadas
• Nota SSL passando de B/C para A+ com o hardening do TLS
• Conformidade reforçada: RGPD (GDPR) (criptografia, backups), PCI DSS (no caso de e-commerce)

Custos

• 30-50% de economia em infraestrutura: muitas vezes evita um upgrade de servidor caro
• Redução de 70-80% no tempo de manutenção: menos “apagar incêndio”, monitoramento proativo
• ROI médio: 3-6 meses para um e-commerce (pelo aumento das conversões)

SEO e conversão

• Aumento de 15-30% no tráfego orgânico graças aos Core Web Vitals (fator de ranqueamento do Google)
• Queda de 10-20 pontos na taxa de rejeição: os visitantes deixam de sair por causa da lentidão
• Aumento de 10-25% na taxa de conversão: um site rápido converte mais

Ambientes atendidos

Sistemas operacionais

• Ubuntu 18.04, 20.04, 22.04, 24.04 LTS
• Debian 10, 11, 12
• Outras distribuições Linux sob consulta (CentOS, Rocky Linux, Alpine)

Provedores de hospedagem e infraestruturas

• OVH / OVHcloud (VPS, Dedicated, Public Cloud)
• Scaleway (Instances, Elastic Metal)
• Contabo (VPS, Dedicated)
• Hetzner (Cloud, Dedicated)
• DigitalOcean, Linode, Vultr
• Servidores dedicados on-premise

Painéis de administração

• Plesk Obsidian
• ISPConfig 3.x
• cPanel/WHM (menos experiência, mas é possível)
• Configuração manual (sem painel): preferível para o máximo desempenho

Servidores web

• Nginx 1.18+ (recomendado pelo desempenho)
• Apache 2.4+ com MPM Event ou Worker
• OpenLiteSpeed (sob consulta)
• Configurações híbridas (Nginx como proxy reverso + Apache no backend)

PHP

• PHP 7.4, 8.0, 8.1, 8.2, 8.3 (todas as versões FPM)
• Suporte a várias versões do PHP simultaneamente
• Extensões: opcache, APCu, Redis, Memcached, imagick etc.

Bancos de dados

• MySQL 5.7, 8.0+
• MariaDB 10.3, 10.5, 10.6, 10.11+
• PostgreSQL (sob consulta, menos experiência do que com MySQL)

Aplicações web comuns

• WordPress / WooCommerce (80% da minha experiência)
• Magento 2.x
• PrestaShop 1.7, 8.x
• Drupal 9, 10
• Laravel, Symfony, CodeIgniter (frameworks PHP)
• Aplicações PHP personalizadas

Preços e prazos

Pacotes de auditoria

Auditoria Essencial – € 390 sem impostos (HT)

• Servidor simples: 1 site, stack padrão (Nginx/Apache + PHP + MySQL)
• 2-3h de análise
• Relatório de 10-15 páginas com plano de ação priorizado
• Arquivos de configuração otimizados incluídos
• Ideal para: site institucional, blog, pequeno e-commerce (< 1000 visitantes/dia)

Auditoria Avançada – € 690 sem impostos

• Servidor complexo: vários sites, configurações personalizadas, tráfego elevado
• 4-6h de análise aprofundada
• Relatório de 20-30 páginas + testes de carga + profiling da aplicação
• Recomendações de arquitetura (Redis, CDN, balanceamento de carga)
• Apresentação das descobertas por videochamada de 1h
• Ideal para: e-commerce de médio/grande porte, SaaS, aplicações de negócio

Auditoria + Execução – sob orçamento (normalmente € 900-1.500 sem impostos)

• Auditoria Avançada + eu mesmo aplico as correções
• Backup completo antes do atendimento
• Testes de não regressão
• Medições de antes/depois com relatório de validação
• Suporte por 7 dias após o atendimento
• Ideal para: quem não tem competências de sistemas na equipe

Auditoria de Emergência (< 24h) – preço × 1,5

• Atendimento em até 24h (dias úteis)
• Relatório expresso em até 48h
• Ideal para: crise em andamento, site fora do ar, invasão recente

Opções complementares

• Sessão de treinamento (1h): +€ 150 sem impostos
  • Leitura das métricas, uso do monitoramento, manutenção preventiva
• Suporte de manutenção mensal: a partir de € 200 sem impostos/mês
  • Atualizações mensais de segurança
  • Monitoramento 24/7 com alertas
  • Intervenções corretivas incluídas (até 2h/mês)
• Auditoria de acompanhamento (6 meses depois): -50% sobre o preço inicial
  • Verificação de que as otimizações se mantêm ao longo do tempo
  • Ajustes caso o tráfego tenha mudado

Prazos padrão

• Orçamento: em até 24h após o briefing inicial
• Acessos e preparação: D+1 a D+2
• Auditoria: D+3 (2-4h de trabalho concentrado)
• Entrega do relatório: D+4 a D+5
• Execução (se contratada): D+6
• Validação final: D+7

Prazo total: 7 dias úteis em média, 3-4 dias em caso de urgência.

O que está incluído em todos os preços

Análise completa das 7 camadas (rede, servidor, PHP, MySQL, segurança, desempenho, monitoramento) Relatório em PDF detalhado, com capturas de tela e recomendações acionáveis Arquivos de configuração otimizados prontos para implantar Apresentação das descobertas por videochamada de 30 min (pacote Avançado e superiores) 1 rodada de perguntas e respostas por e-mail após a entrega

Formas de pagamento

• Transferência bancária (IBAN informado na fatura)
• Cartão de crédito via Stripe (link de pagamento seguro)
• PayPal (empresas francesas)

Condições: 50% na contratação (após a aprovação do orçamento), 50% na entrega do relatório.

Perguntas frequentes

O que exatamente a auditoria de servidor web cobre?

A auditoria analisa 7 camadas técnicas: protocolo de rede (TLS/HTTP2), configuração do servidor web (Nginx/Apache), otimização do PHP-FPM (pm.*, opcache), banco de dados MySQL (consultas lentas, índices ausentes), segurança do sistema (fail2ban, firewall, atualizações), desempenho da aplicação (TTFB, Core Web Vitals) e monitoramento (logs, métricas, alertas). Você recebe um relatório detalhado com um plano de ação priorizado.

Você pode corrigir os problemas encontrados ou só identificá-los?

As duas coisas. Os pacotes “Auditoria Essencial” e “Avançada” identificam os problemas e fornecem os arquivos de configuração otimizados para a sua equipe técnica implantar. O pacote “Auditoria + Execução” inclui a aplicação das correções por mim, com backup prévio, testes de não regressão e medições de antes/depois. É a opção recomendada se você não tem um sysadmin na equipe.

Quais são os prazos e o custo de uma auditoria?

Auditoria básica a partir de € 390 sem impostos para um servidor simples, realizada em 7 dias úteis (emergência em 24h possível, mediante acréscimo). O pacote “Auditoria + Execução” é sob orçamento (normalmente € 900-1.500 sem impostos), conforme a complexidade. Um briefing inicial gratuito de 15 min permite preparar um orçamento preciso em até 24h.

Preciso tirar meu site do ar durante a auditoria?

Não, a auditoria não é intrusiva. A análise é feita via SSH, principalmente em modo leitura (logs, configurações, métricas). Os testes de carga são combinados com você e podem ser agendados para horários de menor movimento, se preferir. Somente a aplicação das correções (pacote opcional) pode exigir 2-5 minutos de indisponibilidade para reiniciar serviços (PHP-FPM, MySQL), o que é agendado com antecedência.

Meu servidor está hospedado na OVH/Scaleway/outro provedor. Isso é um problema?

De forma alguma. Trabalho regularmente com OVH, Scaleway, Hetzner, Contabo, DigitalOcean e outros provedores de hospedagem padrão. A auditoria é feita independentemente do provedor, desde que eu tenha acesso SSH ou ao painel (Plesk, ISPConfig). Se o seu provedor for muito específico (ex.: hospedagem gerenciada na AWS com restrições), um briefing prévio permitirá confirmar a viabilidade.

O que acontece se você encontrar falhas de segurança críticas?

Eu aviso você imediatamente (mesmo antes do fim da auditoria completa) se detectar uma vulnerabilidade crítica que possa ser explorada ativamente (backdoor, versão do PHP com CVE crítica sendo explorada na prática, servidor totalmente aberto). Em seguida, o relatório inclui um plano de ação priorizado, com as correções urgentes no topo da lista. Com o pacote “Auditoria + Execução”, posso aplicar os patches de segurança com prioridade assim que forem identificados.

A auditoria cobre a otimização do código da minha aplicação?

A auditoria de servidor se concentra na infraestrutura e na configuração do sistema (servidor, PHP, MySQL). Posso identificar que uma página faz 150 consultas SQL ou que algumas funções PHP estão lentas (via profiling), mas a otimização detalhada do código da aplicação (refatoração, reescrita de consultas complexas) é tema de uma auditoria de aplicação dedicada. Ainda assim, 80% dos problemas de desempenho vêm da configuração do servidor, então a auditoria resolve a maioria dos casos.

Você oferece garantia de resultados?

Garanto que o relatório trará recomendações acionáveis e mensuráveis. No pacote “Auditoria + Execução”, eu me comprometo com metas numéricas definidas em conjunto com antecedência (ex.: TTFB < 400ms, 0 erro 502 durante 7 dias, Core Web Vitals “Bom” em mais de 80% das páginas). Se as metas não forem atingidas após o atendimento, retomo a otimização sem custo adicional até você ficar satisfeito.

Posso ver um exemplo de relatório de auditoria?

Sim, posso enviar por e-mail, mediante solicitação, um relatório anonimizado (dados do cliente ocultos), o que vai dar a você uma ideia precisa do nível de detalhe e do formato. Entre em contato pelo [seu e-mail] com “Exemplo de relatório de auditoria” no assunto.

Você oferece acompanhamento ou manutenção depois da auditoria?

Sim, há várias opções:

• Suporte pós-auditoria incluído: 7 dias de perguntas e respostas por e-mail após a entrega
• Auditoria de acompanhamento após 6 meses: -50% sobre o preço inicial para verificar se tudo se mantém ao longo do tempo
• Manutenção mensal: a partir de € 200/mês, incluindo atualizações de segurança, monitoramento 24/7 e intervenções corretivas (até 2h/mês)

Meu site usa WordPress/Shopify/outro CMS. Isso muda alguma coisa?

A auditoria de servidor é independente do CMS, porque se concentra na camada de sistema (Linux, Nginx, PHP, MySQL). Mesmo assim, minha ampla experiência com WordPress/WooCommerce (80% das minhas auditorias) me permite ir além: posso auditar os plugins problemáticos, otimizar o banco de dados do WP (wp_options, transients), configurar cache de objetos (Redis) etc. Para lojas hospedadas na Shopify, a auditoria de servidor não se aplica (a infraestrutura é gerenciada pela Shopify), mas posso auditar apps Shopify personalizados, se estiverem hospedados no seu servidor.

De quais acessos você precisa ao meu servidor?

Mínimo necessário:

• Acesso SSH (conta de usuário com sudo, ou root se você aceitar) via chave pública fornecida por mim
• Acesso de leitura aos logs (/var/log/nginx, /var/log/php-fpm, /var/log/mysql)
• Credenciais MySQL somente leitura para analisar as slow queries

Opcional (mas recomendado):

• Acesso ao painel (Plesk, ISPConfig), se houver
• Credenciais do CMS (admin do WordPress) para testar em condições reais
• Acesso ao Google Search Console / Analytics para cruzar com as métricas de negócio

Segurança: todos os acessos fornecidos são removidos imediatamente após a auditoria (em no máximo 48h). Um NDA pode ser assinado mediante solicitação.

Se você procura soluções complementares, confira também:

• Auditoria de segurança de sites: foco na aplicação (vulnerabilidades XSS/CSRF/SQLi, plugins desatualizados, conformidade com a RGPD (GDPR))
• Recuperação de site hackeado: atendimento de emergência após uma invasão (remoção de backdoors, restauração)
• Otimização dos Core Web Vitals: melhoria de LCP/FID/CLS no front-end
• Otimização de velocidade do site: otimização global (front + back)
• Correção e otimização de sites: visão geral dos meus serviços de correção
• Desempenho e velocidade: recursos e guias sobre otimização web
• Segurança e conformidade: central de recursos sobre segurança (RGPD (GDPR), SSL, backups)

Pronto para turbinar o desempenho e a segurança do seu servidor? Peça sua auditoria gratuita