PAC 테스트 결과에서 브라우저의 실제 경로까지
PAC 함수가 반환하는 경로를 파일 전달, 브라우저의 채택, 프록시 도달 가능성, 요청의 최종 경로와 구분합니다.
PAC 테스터는 PROXY proxy.example:8080을 반환합니다. 유용한 결과입니다. 하지만 브라우저 구성을 검증되었다고 부르기 전에 답해야 할 질문이 더 있습니다.
| 질문 | 무엇을 살펴볼지 |
|---|---|
| 이 스크립트는 이 입력에 무엇을 반환하는가? | 평가기, 입력 URL, 헬퍼 함수의 결과 |
| 브라우저가 이 사본을 받았는가? | 설정된 PAC URL과 전달 또는 캐시의 증거 |
| 브라우저가 반환된 경로를 사용했는가? | 브라우저의 프록시 결정과 연결 진단 |
| 그 경로가 요청을 실어 나를 수 있었는가? | 선택된 엔드포인트의 연결과 프록시와의 교환 |
pacparser 같은 도구는 자체 지원 헬퍼로 PAC 로직을 평가합니다. 대상 브라우저의 구성 검색, 정책, 캐시, 연결 체계 전체를 실행하는 것은 아닙니다.
입력은 비교 가능하게 유지합니다. 다른 URL 스킴, 호스트 이름 표기, DNS 응답, 제공된 클라이언트 주소는 정당한 결과를 바꿀 수 있습니다. 다른 네트워크에서의 실행은 스크립트에 결함이 없어도 다른 분기를 탈 수 있습니다.
브라우저 정책이 다른 PAC URL이나 고정 프록시를 선택할 수도 있습니다. 디스크의 파일을 편집해도 브라우저가 다시 가져왔다는 증거는 되지 않습니다. Chrome에서는 PAC 새로 고침이 기억된 불량 프록시 지우기와 다릅니다. 결과와 함께 파일의 정확한 판본과 관련 소비자 설정을 기록하십시오.
로직 문제를 좁히려면 오프라인 평가를 사용합니다. 채택과 경로를 확인하려면 실제 클라이언트의 진단을 사용합니다. 스크립트 결과는 맞는데 프록시에 트랜잭션이 보이지 않는다면, 동작하는 규칙을 다시 쓰기 전에 그 간극을 조사하십시오.