wpad 이름은 예상한 머신으로 확인됩니다. 고무적인 일이지만 시작에 불과합니다. 브라우저는 여전히 그 머신에서 파일을 요청하고 PAC 스크립트를 받아야 합니다.

유용한 단서는 웹 서버의 액세스 로그에서 찾을 수 있습니다. 클라이언트가 /wpad.dat을 요청했고 HTTP 404를 받았습니다. 직접 연 PAC URL은 다른 호스트 이름을 사용할 수 있습니다. 두 이름이 같은 서버에 도달하더라도 서로 다른 가상 호스트를 선택할 수 있습니다.

클라이언트가 보낸 요청을 추적하세요

검색이 선택한 정확한 URL, HTTP Host 값, 경로, 응답을 확인하세요. 일반 브라우저 탭에서 편리한 PAC URL을 여는 것은 자동 검색이 그 URL을 요청했다는 증거가 아닙니다.

짧은 이름과 정규화된 이름을 모두 기대한다면 의도한 웹 호스트가 그 이름들을 명시적으로 처리하도록 구성하세요. /wpad.dat이 기본 문서 루트나 무관한 애플리케이션이 아니라 올바른 파일에 매핑되는지 확인하세요.

오류 페이지가 아니라 스크립트를 제공하세요

응답 상태뿐 아니라 본문도 확인하세요. 로그인 페이지, 브랜드 오류 문서, 리디렉션은 직접 볼 때는 그럴듯해 보일 수 있지만 리졸버가 기대하는 PAC 스크립트가 아닙니다. Chromium은 엄격한 PAC 다운로드 요구 사항을 문서화하며 HTTP 200 응답도 포함합니다.

전달이 성공한 뒤에 후에야 FindProxyForURL()을 디버깅하는 것이 의미가 있습니다. 호스트 이름 규칙을 바꾼다고 브라우저가 파일을 받지 못하게 한 404가 고쳐지지는 않습니다.

PAC 웹 서버와 그 스크립트에 명시된 포워드 프록시도 구분하세요. 같은 머신을 공유할 수 있지만 한 서비스의 액세스 로그 항목은 다른 서비스가 사용자의 목적지 요청을 처리했다는 증거가 아닙니다.

관련 글