Firefox가 여전히 우회 서브넷의 인트라넷 호스트를 프록시로 보내는 이유

Firefox의 “프록시 사용 안 함” 목록에 192.168.0.0/16을 넣었습니다. http://192.168.1.20/을 열면 직접 연결되지만 http://wiki.office.example/는 여전히 프록시에 도달합니다. 두 URL은 같은 서버를 가리킬 수 있습니다.

중요한 차이는 Firefox가 비교하는 대상 문자열입니다. IP 범위 예외와 호스트 이름 예외는 서로 대체할 수 없습니다. 주소 범위 규칙이 적용되는지 판단하기 전에 수동 우회 목록이 모든 호스트 이름을 확인해 준다고 가정하지 마세요.

인트라넷에 전용 도메인이 있다면 이름이 확인될 수 있는 주소를 추측하는 대신 적절한 호스트 이름 또는 도메인 예외를 사용하세요. 관련 없는 공개 서비스는 그 예외 밖에 두세요. 하나의 도메인에는 내부 애플리케이션과 외부에서 호스팅되는 애플리케이션이 모두 있을 수 있습니다.

Mozilla의 원래 설명는 리터럴 IP 일치와 해당 IP로 확인되는 이름을 명확히 구분합니다. 그 문서는 역사적인 것이므로, 거기서 모든 구문 예제를 복사하기 전에 현재 클라이언트의 동작과 정책 인터페이스를 확인하세요.

정책에 DNS가 필요할 때

PAC 파일은 DNS를 인식하는 결정을 위한 별도의 명시적인 장소를 제공합니다. 또한 스크립트 배포, 실행, 확인의 실패 모드를 도입합니다. 긴 우회 목록을 짧아 보이게 하려는 것이 아니라 라우팅 요구 사항에 그 로직이 필요하기 때문에 사용하세요.

관리되는 설치에서는 Firefox의 실제 정책도 확인하세요. 잠긴 프록시 정책는 로컬 편집이 경로를 결정하지 못하는 이유를 설명할 수 있습니다.

문제를 해결할 때는 서버의 최종 IP만이 아니라 입력한 리터럴 URL을 기록하세요. 호스트 이름 URL과 리터럴 주소 URL을 비교하면 우회 결정에 사용할 수 있는 정보가 달라지며, 바로 그 때문에 두 요청이 서로 다른 경로를 탈 수 있습니다.