Squid 로그에서 실패한 요청 찾기
access.log로 트랜잭션 결과를, cache.log로 Squid 자체 오류를 확인하고 터널 상태와 목적지 상태를 구분합니다.
Debian의 Squid 6 패키지에서는 일반적인 트랜잭션 로그와 데몬 로그부터 확인하세요.
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.log사용자 지정 로깅이나 서비스 관리자가 로그를 다른 위치로 보낼 수 있습니다. 알려진 출발지에서 범위를 제한한 요청 하나를 재현하고 시간, 메서드, 목적지를 기록하여 올바른 로그 기록과 대조하세요.
| 증거 | 확인할 내용 |
|---|---|
| access.log 기본 형식의 결과 | Squid 결과 코드와 HTTP 상태는 트랜잭션의 서로 다른 부분입니다. |
| 접근 계층 정보 | 전달 과정에서 부모 프록시나 다른 경로를 어떻게 사용했는지. |
| CONNECT 성공 | 터널이 열렸다는 뜻이며, 암호화된 TLS 내부에서 나중에 나오는 웹사이트 상태가 아닙니다. |
| cache.log | Squid 자체의 헬퍼, 시작, 리졸버 및 설정 오류. |
일치하는 요청이 없으면 이 클라이언트가 이 인스턴스와 리스너에 도달했는지 확인하세요. 로깅 ACL, 버퍼링, 로테이션과 트랜잭션이 아직 진행 중인지 점검하세요. 오래 유지되는 터널은 최종 접근 기록이 아직 없을 수 있습니다. 우회나 이전 프록시 프로세스가 트래픽을 다른 곳으로 보낼 수 있으므로 접근 정책을 수정하기 전에 수신 프로세스와 그 프로세스가 읽어들인 설정을 대조하세요.
민감한 정보를 가린 관련 트랜잭션과 주변 오류를 공유하세요. URL, 쿼리, 출발지 주소와 사용자 이름에는 비공개 정보가 있을 수 있습니다. 구체적인 필요 없이 전체 로그를 내보내거나 전체 헤더 로깅을 켜면 유용한 증거보다 정보 노출이 늘어납니다.