Squid 요청을 상위 프록시로 보내기

Squid에 상위 프록시를 선언했다고 모든 전달 요청이 반드시 그것을 쓰는 것은 아닙니다. 직접 경로가 정책에 어긋난다면 그 요구를 명시적으로 설정하고 상위 프록시를 쓸 수 없을 때의 동작을 시험하세요.

이 Squid 6.13 예제는 상위 프록시 하나를 지정하고 클라이언트 출발지 하나에 대해 원본으로의 직접 전달을 금지합니다:

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream
acl routed_client src 198.51.100.27/32
never_direct allow routed_client

두 주소는 모두 자리표시자입니다. 공개 HTTP 상위 프록시를 허용하는 통제된 상위 경로 시험에서는 HTTP 프록시 목록에서 주소를 고르세요. 원하는 클라이언트만 허용하는 별도의 http_access 정책은 유지해야 합니다. 라우팅 규칙은 클라이언트에게 프록시 사용 권한을 주지 않습니다.

기존 라우팅 규칙 확인

no-query는 이 피어에 대한 ICP 질의를 끕니다. 0은 피어의 질의 포트이며 HTTP 리스너가 아닙니다. 클라이언트 쪽 리스너와 그 접근 규칙은 별개로 남습니다.

이 부분을 추가하기 전에 기존 always_direct 설정과 다른 피어 선택을 검토하세요. always_direct에서 일치를 거부하는 것만으로 상위 프록시 사용이 필수가 되지는 않습니다. 명시적인 never-direct 규칙이 선택한 클라이언트에 그 요구를 나타냅니다.

이는 전달이 필요한 트랜잭션을 제어합니다. 쓸 수 있는 로컬 캐시 항목은 상위 프록시에 접속하지 않고 응답할 수 있으므로 새 상위 연결이 없다고 자동으로 라우팅 위반은 아닙니다.

경로와 실패 동작 확인

통제된 목적지를 사용하고 목적지 관측과 함께 접근 로그의 계층 정보를 살펴보세요. 최종 HTTP 상태만으로는 Squid가 상위 프록시와 직접 경로 중 무엇을 썼는지 알 수 없습니다.

유지보수 시험에서 상위 프록시를 사용할 수 없게 하고 같은 미캐시 요청을 반복하세요. 정책이 직접 전달을 금지한다면 다른 경로로 원본에 도달하는 대신 트랜잭션이 실패해야 합니다. 직접 제어하는 서비스에서만 수행하고 이후 원래 의도한 설정을 복원하세요.