Logs de Acesso ao Servidor — A História de Cada Solicitação Recebida pelo Seu Aplicativo

Cada solicitação HTTP que seu servidor trata deixa uma linha no log de acesso. Na maioria dos casos, esses arquivos ficam no disco crescendo silenciosamente até que um alerta de disco seja disparado ou algo quebre na produção. Depois disso, todos querem ler os arquivos de forma repentina.

Aqui está uma linha única de um servidor executando o Formato de Log Combinado:

203.0.113.42 - jsmith [09/May/2026:14:32:11 +0000] "GET /api/users/profile HTTP/1.1" 200 1843 "https://example.com/dashboard" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"

Oito campos. Cada um é uma peça de evidência sobre o que aconteceu. Vamos de esquerda para direita.

Os Campos, Um a Um

1. IP do Cliente — 203.0.113.42

O endereço IP que abriu a conexão TCP com seu servidor. Isso é não necessariamente o IP do usuário final. Se você estiver atrás de um balanceador de carga, CDN ou proxy reverso (por exemplo, Nginx em frente a um aplicativo Node), esse será o IP do proxy. O IP real do cliente está nos X-Forwarded-For ou X-Real-IP cabeçalhos — e você precisa configurar explicitamente o formato do log para capturá-los.

No Nginx, isso parece adicionar $http_x_forwarded_for à sua log_format directiva. No Apache, use %{X-Forwarded-For}i. Se você pular isso e depois receber uma reclamação de abuso ou precisar bloquear um ator malicioso, você vai se ver olhando para o IP do seu balanceador de carga em cada linha do log.

2. Ident — -

Sempre um traço. Esse campo era destinado a conter o resultado de uma consulta identd — um protocolo antigo (RFC 1413) que permitia que os servidores perguntassem ao sistema operacional do cliente quem era o processo fazendo a conexão. Ninguém mais executa identd. Esse campo existe porque o Formato de Log Comum foi padronizado quando o identd ainda era algo relevante. Pule-o.

3. Usuário Autenticado — jsmith

O nome de usuário, preenchido quando a autenticação HTTP Basic ou Digest estiver ativa. Para a maioria dos aplicativos modernos — autenticação por token, cookies de sessão, JWTs — isso será um traço. Se você proteger uma área de administração com htpasswd, os logins falhados aparecem como - próximo a um status 401; os logins bem-sucedidos mostram o nome de usuário.

4. Hora do Evento — [09/May/2026:14:32:11 +0000]

O momento em que o servidor finalizou o processamento da solicitação (não quando ela começou). O formato é day/Mon/year:HH:MM:SS timezone. A diferença horária é mais importante do que as pessoas percebem — se seu servidor de aplicação rodar em UTC, mas sua ferramenta de monitoramento ou alerta estiver em uma zona horária local, correlacionar um pico de logs com um incidente específico exige cálculos de conversão cada vez que isso acontecer. Execute tudo em UTC.

5. Linha da Solicitação — "GET /api/users/profile HTTP/1.1"

O campo mais denso em informações. Três partes: o método HTTP, o caminho com string de consulta e a versão do protocolo.

• Método — GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS. Métodos inesperados em um endpoint são dignos de nota.
• Caminho + string de consulta — diz exatamente o que foi solicitado. As strings de consulta podem conter termos de busca, IDs e, em APIs mal projetadas, tokens de autenticação. Registre conforme necessário.
• Protocolo — os clientes HTTP/1.0 em seus logs em 2026 são ou integrações antigas ou algo que imita um cliente antigo. Os clientes HTTP/2 e HTTP/3 são registrados como essas versões se seu servidor os suportar.

6. Código de Status — 200

O status HTTP que o servidor enviou de volta. Esse é o campo de julgamento.

• 2xx — sucesso. A solicitação foi tratada.
• 3xx — redirecionamento. O cliente precisa ir para outro lugar.
• 4xx — erro do cliente. Solicitação inválida, falta de autenticação, não encontrado. Pode ser uso legítimo ou exploração.
• 5xx — erro do servidor. Seu aplicativo travou, expirou ou retornou dados inválidos. Investigar sempre esses casos.

Ao triar um incidente, filtre por 5xx primeiro. Depois, examine a hora do primeiro 500 — é quando o falha começou. O que estava antes disso é o pré-incidente; o que está depois é o alcance do incidente.

7. Bytes Enviados — 1843

O tamanho do corpo da resposta em bytes, sem contar cabeçalhos. Um traço significa zero bytes (típico para 304 Not Modified respostas — o cliente já possui o conteúdo). Valores inesperadamente grandes em endpoints que deveriam retornar alguns centenas de bytes são um sinal de alerta. Um usuário autenticado acessando um endpoint “obter meu perfil” e recebendo 40MB é ou um bug ou alguém explorando uma exportação de dados.

8. Referer — "https://example.com/dashboard"

Onde o cliente veio antes de fazer essa solicitação — o URL no cabeçalho do navegador. Referer (O especificação HTTP cometeu um erro de ortografia em 1996 e estamos presos com isso.) O tráfego direto, marcadores e requisições de aplicativos nativos chegam com referer vazio. Esse campo existe apenas no Formato de Log Combinado; o Formato de Log Comum termina com bytes enviados.

Spam de referer — cabeçalhos falsos de referer em requisições em massa tentando aparecer em suas análises — era mais comum anteriormente, mas agora é quase um relicário. Ainda vale filtrar de seus dados agregados.

9. User Agent — "Mozilla/5.0 (Windows NT 10.0; Win64; x64)…"

O identificador do cliente. Os user agents são facilmente falsificados, portanto trate isso como uma pista, não como uma verdade. Os crawlers legítimos geralmente identificam-se honestamente: Googlebot/2.1 (+http://www.google.com/bot.html), Bingbot/2.0. Os scrapers que imitam navegadores enviam a string Mozilla/5.0 Chrome completa. O curl envia curl/8.x a menos que alguém o sobrescreva com -A.

Padrões a observar: strings idênticas de user agent atingindo os mesmos endpoints com velocidade de máquina, ou um user agent dizendo ser iOS Safari mas fazendo requisições em um padrão que nenhum navegador humano faria (sem imagens, sem CSS, crawls sequenciais de páginas de produtos).

Padrões que Aparecem em Cada Log

A varredura de vulnerabilidades

Um IP único ou um pequeno subrede atingindo dezenas de caminhos em sucessão rápida: /.env, /wp-login.php, /phpmyadmin, /admin/config.yml, /.git/config. Todos retornam 404. Isso é um scanner automatizado executando uma lista de verificações, não um ataque direcionado. Eles executam contra todos os IPs públicos constantemente.

A pergunta correta não é “por que estão me escaneando” — é “algum desses caminhos retornou 200”. Se /.env retornar 200 no seu servidor, isso é o problema real.

# Check if any sensitive paths actually returned 200
grep -E '"(GET|POST) /(wp-login\.php|\.env|\.git/config|phpmyadmin|admin)' access.log | awk '$9 == 200'

Estouro de credenciais

Requisições POST de alto volume ao seu ponto de entrada de login, quase todas retornando 401, provenientes de um conjunto distribuído de IPs. O sinal é o padrão: mesmo endpoint, tamanho de resposta consistente (a página de erro), muitos IPs diferentes que compartilham um ASN. Os tempos de resposta tendem a ser constantes também — tentativas automatizadas de login ocorrem em uma taxa estável para evitar limites de taxa.

# Count POST /login attempts with 401 status by source IP
awk '$6 == "\"POST" && $7 == "/api/login" && $9 == "401" {print $1}' access.log \
  | sort | uniq -c | sort -rn | head -20

O pico de 404 após uma implantação

Você faz uma nova versão. Os 404s aumentam. Os links antigos em e-mails, marcadores e sites externos estão apontando para URLs que não existem mais. Isso é normal — mas se os 404s estiverem em URLs que deveria existem na nova versão, isso é uma regressão de roteamento. Compare os caminhos com 404 com suas definições de rota.

Agrupamento de respostas lentas

O formato padrão de log não inclui o tempo de resposta. Você precisa adicioná-lo: no Apache, adicione %D (microssegundos) à sua LogFormat; no Nginx, adicione $request_time à sua log_format bloco. Uma vez que você tenha isso:

# Nginx: show requests slower than 3 seconds (request_time in last field)
awk '{if ($NF+0 > 3) print $0}' /var/log/nginx/access.log | head -20

Se os pedidos lentos se agruparem em uma janela de tempo específica, isso é contenda — um job cron, um processo em lote ou um backup martelando o banco de dados. Se um caminho específico for consistentemente lento independentemente do horário, isso é uma consulta lenta ou uma chamada bloqueante de I/O que precisa ser analisada.

Depurando um Incidente a Partir dos Logs

O log de acesso é uma linha do tempo. Quando um usuário relata “algo quebrou ao redor das 15h”, você:

• Filtre para a janela de 14:50–15:10
• Procure o primeiro 5xx — é quando começou
• Verifique o que mudou nos minutos anteriores: houve uma implantação? Um push de configuração? Uma renovação de certificado?
• Verifique quais caminhos atingiram 5xx — é tudo ou apenas um endpoint?
• Verifique os bytes enviados em respostas bem-sucedidas antes e depois — algo começou a retornar respostas truncadas?

Alguns sinais de falha importantes a saber:

• Pico de 502 — o upstream morreu (travamento do servidor de aplicação, pool de conexões esgotado, banco de dados parou). Os 502s começam em um horário preciso.
• Loop de redirecionamento — 301/302 de um mesmo IP para o mesmo caminho repetidamente. Normalmente uma configuração incorreta de redirecionamento HTTPS ou um ajuste de SSL do Cloudflare que está se enfrentando com a lógica de redirecionamento do seu aplicativo.
• 200 com zero bytes — status 200 mas bytes enviados é 0 ou -. Seu aplicativo aceitou a solicitação, engoliu uma exceção e retornou um corpo vazio. Caso clássico de erro não tratado.
• Pico de 413 — clientes enviando corpos de requisição acima do limite que você definir. Ou seu limite é muito baixo para o caso de uso ou alguém está explorando vulnerabilidades de upload.

Se você estiver lidando com logs em múltiplos formatos — Formato Comum do Apache, Formato Combinado do Apache, padrão do Nginx, formatos personalizados — o Formato de Log de Acesso pode analisar e anotar os campos para que você não precise mentalmente mapear posições de campos toda vez que muda entre servidores.

Gestão de Logs que Você Lamentará Não Ter Configurado

• Rotação de logs — logrotate configurada para rotacionar diariamente, compactar e manter 14 a 30 dias. Sem isso, access.log cresce até preencher o disco. Isso acontece em produção.
• Log centralizado — uma vez que você tenha mais de um servidor, seguir individualmente os arquivos de log não escala. Envie para Loki + Grafana, Elasticsearch ou um serviço gerenciado. O formato de log estruturado em JSON torna a consulta muito mais fácil do que interpretar CLF com awk.
• Controle de acesso aos logs brutos — os arquivos de log podem conter parâmetros de consulta com tokens, dados pessoais do usuário e caminhos internos. Não os deixe acessíveis ao mundo. Seja deliberado sobre os períodos de retenção de logs se estiver sob GDPR ou semelhantes.
• Não logue parâmetros sensíveis — se seu aplicativo aceita tokens de autenticação ou senhas como parâmetros de URL (não deveria, mas algumas APIs antigas fazem), filtre-os no nível de log antes que cheguem ao disco.

Você também pode gostar