Guia de Logs do Nginx/Apache - Localização e Análise de access/error Log

2025-12-16 Tempo de leitura: Cerca de 12 min Dificuldade: Intermediário

O que você vai aprender

• Onde ficam os arquivos de log do Nginx/Apache no Ubuntu
• Como isolar as causas de "500/502/503/504", "403", "404" a partir dos logs
• Uma abordagem sistemática para investigação de logs (ordem, filtragem, reprodução, verificação)
• Entender que o crescimento dos logs pode causar problemas de disco

1. Verifique qual servidor está rodando (Nginx? Apache?)

Conclusão: Confirme qual servidor está ativo com systemctl antes de abrir qualquer arquivo de log.

Pule se você já sabe.

1-1. Verificar pelo status do serviço

$ sudo systemctl status nginx
$ sudo systemctl status apache2

• nginx está ativo -> Verifique os logs do Nginx
• apache2 está ativo -> Verifique os logs do Apache
• Ambos ativos -> Provavelmente configuração de proxy reverso (verifique os logs do front-end primeiro)

1-2. Verificar pela porta (complementar)

$ sudo ss -lntp | grep ':80 '
$ sudo ss -lntp | grep ':443 '

2. Localização dos logs (caminhos típicos no Ubuntu)

Conclusão: Logs do Nginx: /var/log/nginx/; Apache: /var/log/apache2/ por padrão no Ubuntu.

Geralmente ficam aqui no Ubuntu:

2-1. Nginx

• error log: /var/log/nginx/error.log
• access log: /var/log/nginx/access.log

$ ls -la /var/log/nginx

2-2. Apache (apache2)

• error log: /var/log/apache2/error.log
• access log: /var/log/apache2/access.log

$ ls -la /var/log/apache2

3. Primeiro verifique o "error log" (caminho mais rápido)

Conclusão: Sempre leia o error.log primeiro — a causa raiz aparece lá, não no access.log.

O access log mostra "o que aconteceu", mas a causa raiz (stack trace/erro de configuração/upstream morto) aparece no error.log.

3-1. Ver as últimas 200 linhas (primeiro passo)

# Nginx
$ sudo tail -n 200 /var/log/nginx/error.log

# Apache
$ sudo tail -n 200 /var/log/apache2/error.log

3-2. Acompanhamento em tempo real enquanto reproduz (mais eficaz)

# Nginx
$ sudo tail -f /var/log/nginx/error.log

# Apache
$ sudo tail -f /var/log/apache2/error.log

4. Encontre a requisição com falha no access log

Conclusão: grep " 500 " access.log isola as falhas para cruzar com o error.log.

4-1. Encontrar apenas erros 500

$ sudo grep " 500 " /var/log/nginx/access.log | tail -n 50

4-2. Encontrar apenas erros 404

$ sudo grep " 404 " /var/log/nginx/access.log | tail -n 50

4-3. Encontrar apenas um caminho específico (ex.: /api/)

$ sudo grep " /api/" /var/log/nginx/access.log | tail -n 50

5. Guia de isolamento por código de status

Conclusão: O código mapeia para a camada: 500=app, 502/503=upstream, 403=permissões, 404=roteamento.

5-1. 500 (Internal Server Error)

• Erro interno da aplicação (PHP/Node/Ruby, etc.)
• Erro de configuração (configurações FastCGI, etc.)
• Possível problema de permissão/caminho (Permission denied)

Próximo: error.log (prioridade), logs da aplicação, journalctl -u

5-2. 502 / 503 / 504 (Bad Gateway / Service Unavailable / Gateway Timeout)

• Nginx/Apache não consegue conectar ao upstream / resposta lenta / inativo

Próximo passo:

$ nc -vz 127.0.0.1 3000
$ curl -I http://127.0.0.1:3000

5-3. 403 (Forbidden)

• Autenticação básica, restrição de IP, WAF, permissão de diretório, permissão de arquivo

Próximo: error.log mostrará "permission denied" ou "client denied"

5-4. 404 (Not Found)

• Roteamento / arquivo não existe
• Configuração de rewrite para SPA ausente

6. Encontrando localizações de log não padrão

Conclusão: nginx -T | grep error_log ou apache2ctl -S encontra caminhos de log não padrão.

6-1. Nginx: Exibir toda a configuração

$ sudo nginx -T 2>&1 | grep -E "access_log|error_log" | head -n 50

6-2. Apache: Verificar configuração

$ sudo apache2ctl -S

7. Dicas de filtragem para investigação mais rápida

Conclusão: Reproduza o erro com tail -f error.log aberto — esse é o caminho mais rápido.

7-1. Quer ver apenas o que está acontecendo agora

Melhor: "reproduzir -> tail -f"

7-2. Filtrar por palavra-chave (ex.: upstream)

$ sudo grep -i "upstream" /var/log/nginx/error.log | tail -n 50

8. Mensagens comuns no error.log

Conclusão: "refused" é upstream inativo; "timed out" é lento; "denied" é acesso a arquivo.

8-1. connect() failed (111: Connection refused) while connecting to upstream

Significado: Upstream não está escutando / inativo

$ nc -vz 127.0.0.1 <upstream-port>
$ sudo systemctl status <app-service>

8-2. upstream timed out (110: Connection timed out)

Significado: Upstream está lento/congestionado (carga, banco de dados, I/O, etc.)

8-3. permission denied

Significado: Problema de permissão de arquivo/diretório, possivelmente SELinux/AppArmor

8-4. client intended to send too large body

Significado: Limite de tamanho de upload (nginx client_max_body_size, etc.)

9. O que evitar

Conclusão: Nunca reinicie antes de ler o error.log — o uso de disco pelos logs também precisa de monitoramento.

Não faça: Reiniciar repetidamente sem verificar os logs

Reiniciar sem verificar os logs apenas esconde a causa e perde tempo. Verifique error.log / journalctl primeiro.

Não faça: Verificar apenas o access.log e parar por aí

A causa raiz geralmente está no error.log. O access log serve para "qual requisição falhou".

Não faça: Ignorar o crescimento dos logs

Mais tráfego = mais logs. Pode levar a disco cheio (No space left). Monitore o disco e configure a rotação de logs (logrotate).

# Status do servico
sudo systemctl status nginx

# Erro (verifique primeiro)
sudo tail -n 200 /var/log/nginx/error.log

# Acompanhamento em tempo real enquanto reproduz (mais eficaz)
sudo tail -f /var/log/nginx/error.log

# Encontrar requisicoes com falha
sudo grep " 500 " /var/log/nginx/access.log | tail -n 50
sudo grep " 502 " /var/log/nginx/access.log | tail -n 50
sudo grep " 403 " /var/log/nginx/access.log | tail -n 50
sudo grep " 404 " /var/log/nginx/access.log | tail -n 50