Encontre uma requisição com falha nos logs do Squid
Use access.log para os resultados das transações e cache.log para as falhas do Squid, diferenciando o status do túnel do status do destino.
No pacote Squid 6 do Debian, comece pelos logs habituais de transações e do daemon:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logUma configuração de logs personalizada ou um gerenciador de serviços pode enviá-los para outro lugar. Reproduza uma única requisição de escopo limitado a partir de uma origem conhecida e anote horário, método e destino para encontrar o registro correto.
| Evidência | O que extrair dela |
|---|---|
| Resultado nativo do access.log | O código de resultado do Squid e o status HTTP são partes separadas da transação. |
| Informações da hierarquia de acesso | Como o encaminhamento usou um proxy pai ou outra rota. |
| Sucesso do CONNECT | O túnel foi aberto; isso não é o status posterior do site dentro do TLS criptografado. |
| cache.log | Falhas de auxiliares, inicialização, resolução de nomes e configuração do próprio Squid. |
Se nenhuma requisição correspondente aparecer, confirme se este cliente chegou a esta instância e a este listener. Verifique ACLs de log, buffer, rotação e se a transação ainda está ativa; um túnel de longa duração talvez ainda não tenha um registro de acesso final. Um desvio do proxy ou um processo proxy antigo pode mandar o tráfego para outro lugar. Por isso, associe o processo que escuta à configuração que ele carregou antes de editar a política de acesso.
Compartilhe a transação relevante com os dados sensíveis ocultados e os erros próximos. URLs, consultas, endereços de origem e nomes de usuário podem ser privados; despejar logs inteiros ou habilitar o registro completo de cabeçalhos sem uma necessidade específica aumenta a exposição em vez de fornecer evidência útil.