“Resolving Host in Proxy Script”에서 멈췄나요? PAC 파일을 보세요
브라우저는 어떤 프록시를 사용할지 결정하는 동안 DNS를 기다릴 수 있으며, 이는 페이지를 내려받는 연결을 열기 전에 일어납니다.
상태 메시지가 “Resolving host in proxy script”라고 표시되지만 프록시 서버를 바꿔도 거의 달라지지 않습니다. 이는 유용한 단서입니다. 브라우저가 아직 요청을 어디로 보낼지 결정 중일 수 있습니다.
PAC 파일은 DNS에 의존하는 검사를 수행할 수 있습니다. 그 검사가 접근할 수 없는 리졸버를 기다리거나 불필요한 질의를 반복하면, 선택된 프록시가 아무것도 받기 전에 페이지 로딩이 멈출 수 있습니다.
1. 멈추는 지점 찾기
영향받는 URL 하나에 대해 지연이 PAC 파일을 가져오는 단계, 평가하는 단계, 아니면 반환된 프록시에 연결하는 단계에서 생기는지 확인하세요. 프록시 액세스 로그가 비어 있는 것은 처음 두 단계와 일치하지만, 브라우저가 직접 경로를 사용했다는 증거는 아닙니다.
다음으로 어떤 규칙이 DNS를 필요로 하는지 살펴보세요. Microsoft의 PAC 성능 지침 은 불필요한 DNS 의존 작업을 피하라고 권합니다. 호스트 이름 동일성 검사는 그 호스트 이름을 확인하고 서브넷을 검사하는 것과 같은 정보를 필요로 하지 않습니다.
2. 불필요한 DNS 작업 제거
알려진 호스트 이름 예외 는 흔히 광범위한 주소 기반 검사보다 먼저 결정할 수 있습니다. 나머지 정책이 실제로 그 주소를 필요로 할 때만 이름을 확인하세요. 이후 여러 조건이 같은 값을 필요로 한다면 결과를 지역 변수에 보관하세요.
맨 위에 무조건적인 DIRECT 반환을 추가해 느린 스크립트를 “고치지” 마세요. 그러면 지연과 함께 라우팅 결정도 사라집니다.
기기별 DNS 해결책에는 근거가 필요합니다. 파일 공유를 켜거나 모든 노트북의 hosts 파일을 다시 쓰는 것은 느린 라우팅 스크립트에 대한 나쁜 첫 대응입니다. 영향받는 네트워크에서 리졸버와 호스트 이름의 동작을, 특히 네트워크 변경 후에 확인하고, PAC는 실제 결정 경로가 요구하는 곳에서만 바꾸세요.