Squid가 호스트 이름을 확인하지 못할 때
클라이언트에서 조회에 성공했다고 Squid도 같은 이름을 확인할 수 있다고 가정하지 말고 프록시 서버의 리졸버를 점검하세요.
조회 실패가 발생하는 위치에서 DNS를 살펴보세요. 노트북에서 이름을 확인할 수 있다고 해서 Squid나 그다음 연결을 수행하는 상위 프록시도 확인할 수 있다는 뜻은 아닙니다.
실패하는 인스턴스의 캐시 로그와 서버 리졸버 설정을 확인하세요. 호스트 수준의 보조 점검은 다음과 같습니다.
getent ahosts target.example실제 대상을 사용하세요. getent는 호스트의 이름 조회 체계를 사용하며, Squid의 내부 리졸버나 캐시는 다를 수 있습니다. 서로 일치한다고 가정하기 전에 명시적으로 지정한 dns_nameservers 및 hosts_file 입력을 살펴보세요.
Squid 6.13에서 명시적으로 지정하는 네임서버 목록에는 IP 주소가 들어갑니다.
dns_nameservers 192.0.2.53이 문서용 주소를 Squid 서버에서 접근할 수 있는 승인된 리졸버로 바꾸세요. 사설 이름에는 조직의 리졸버가 필요할 수 있습니다. 무관한 공개 리졸버의 DNS 뷰에서는 해당 이름이 보이지 않을 수 있습니다.
노트북 hosts 파일의 별칭은 호스트 이름을 사용하는 프록시 요청과 함께 전달되지 않습니다. 조회를 수행하는 컴퓨터에서 설치된 Squid 버전의 hosts_file 설정을 확인하고, 해당하는 경우 상위 프록시의 리졸버도 고려하세요. TLS 신원 확인에 사용하는 호스트 이름은 서비스와 일치시켜야 합니다.
통제된 설정 변경을 하나 수행한 뒤 설정 구문을 검사하고 의도한 인스턴스를 다시 로드한 다음, 같은 요청을 반복하고 관련 증거를 살펴보세요. 캐시된 긍정 및 부정 응답은 반복 시험에 영향을 줄 수 있습니다. 조회 성공 뒤의 연결 시간 초과는 이후 단계의 경로나 권한 문제입니다. 이를 해결하려고 DNS를 계속 바꾸지 마세요. 서버 변경을 평가하는 동안 클라이언트 DNS, 상위 프록시 라우팅, 프록시 프로토콜을 일정하게 유지하세요.