Encuentra una solicitud fallida en los registros de Squid
Usa access.log para los resultados de las transacciones y cache.log para los fallos de Squid, distinguiendo el estado del túnel del estado del destino.
En el paquete Squid 6 de Debian, empieza por los registros habituales de transacciones y del demonio:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logUna configuración de registro personalizada o un gestor de servicios puede enviarlos a otro lugar. Reproduce una sola solicitud de alcance limitado desde un origen conocido y anota su hora, método y destino para localizar la entrada correcta.
| Evidencia | Qué se puede extraer |
|---|---|
| Resultado nativo de access.log | El código de resultado de Squid y el estado HTTP son partes separadas de la transacción. |
| Información de jerarquía de acceso | Cómo se utilizó un proxy padre u otra ruta al reenviar. |
| Éxito de CONNECT | El túnel se abrió; no es el estado posterior del sitio web dentro del TLS cifrado. |
| cache.log | Fallos de auxiliares, inicio, resolución y configuración del propio Squid. |
Si no aparece una solicitud coincidente, confirma que este cliente llegó a esta instancia y a este punto de escucha. Revisa las ACL de registro, el almacenamiento en búfer, la rotación y si la transacción sigue activa; un túnel de larga duración puede no tener aún un registro de acceso final. Una exclusión del proxy o un proceso proxy anterior puede enviar el tráfico a otro lugar, así que relaciona el proceso que escucha con su configuración cargada antes de editar la política de acceso.
Comparte la transacción relevante con los datos sensibles ocultos y los errores cercanos. Las URL, consultas, direcciones de origen y nombres de usuario pueden ser privados; volcar registros completos o activar el registro de todas las cabeceras sin una necesidad concreta aumenta la exposición en vez de aportar evidencia útil.