Atopa unha petición fallida nos rexistros de Squid
Usa access.log para os resultados das transaccións e cache.log para os fallos de Squid, distinguindo o estado do túnel do estado do destino.
No paquete Squid 6 de Debian, comeza polos rexistros habituais de transaccións e do daemon:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logUnha configuración de rexistro personalizada ou un xestor de servizos pode envialos a outro lugar. Reproduce unha soa petición de alcance limitado desde unha orixe coñecida e anota a hora, o método e o destino para atopar a entrada correcta.
| Evidencia | Que se pode ler dela |
|---|---|
| Resultado no formato nativo de access.log | O código de resultado de Squid e o estado HTTP son partes separadas da transacción. |
| Información da xerarquía de acceso | Como o reenvío utilizou un proxy pai ou outra ruta. |
| CONNECT correcto | O túnel abriuse; non é o estado posterior do sitio web dentro do TLS cifrado. |
| cache.log | Fallos dos auxiliares, do inicio, do resolvedor e da configuración do propio Squid. |
Se non aparece ningunha petición coincidente, confirma que este cliente chegou a esta instancia e punto de escoita. Revisa as ACL de rexistro, o almacenamento en búfer, a rotación e se a transacción segue activa; un túnel de longa duración pode non ter aínda un rexistro de acceso final. Unha exclusión ou un proceso proxy antigo pode enviar o tráfico a outro lugar, así que relaciona o proceso que escoita coa configuración que cargou antes de editar a política de acceso.
Comparte a transacción relevante cos datos sensibles ocultos e os erros próximos. Os URL, as consultas, os enderezos de orixe e os nomes de usuario poden ser privados; volcar rexistros enteiros ou activar o rexistro completo de cabeceiras sen unha necesidade concreta aumenta a exposición no canto de achegar evidencia útil.