curl은 PAC 파일을 읽지 못합니다: 대신 프록시를 전달하세요

설정 파일에서는 PAC 파일 주소와 프록시 엔드포인트가 서로 바꿔 쓸 수 있는 것처럼 보이지만 그렇지 않습니다. 하나는 URL마다 평가해야 하는 정책 프로그램이고, 다른 하나는 연결을 받아 주는 호스트와 포트입니다. curl은 후자만 이해합니다. PAC 주소를 --proxy 에 넘기는 것은 범주 오류이며, 대개 웹 서버로 향하는 긴 CONNECT 타임아웃 끝에 혼란스러운 방식으로 실패합니다.

각각의 실제 정체

이 점을 curl 자주 묻는 질문 이 분명히 밝힙니다. curl은 JavaScript나 PAC 해석을 제공하지 않습니다. PAC를 이해하는 래퍼를 curl 주위에 두면 가능하지만 curl 자체는 안 되며, 어떤 플래그로도 브라우저가 되지 않습니다.

브라우저는 되고 curl은 안 되는 이유

브라우저는 시스템 프록시 설정과 통합되어 PAC 파일을 가져오고, 여는 URL에 대해 그 규칙을 실행합니다. 그 평가가 바로 PAC 파일이 제공하는 서비스이며, 터미널 안이 아니라 브라우저 안에서 일어납니다.

curl로 PAC 파일을 내려받으면 그 텍스트만 얻습니다. curl이 정책을 실행하게 되는 것은 아니고, 프록시를 찾으려고 손으로 읽는 것은 같은 평가의 수동 버전이며 잘못된 분기를 고를 가능성도 같습니다. 읽는다면 파일의 첫 프록시 이름이 아니라 자기 호스트에 맞는 return 문을 읽으세요. 대부분의 PAC 파일에는 여러 개가 들어 있고, 자신에게 해당하는 분기는 하나뿐입니다.

승인된 HTTP 프록시와 승인된 HTTPS 서비스를 쓰는 경우, 예시 요청은 다음과 같습니다.

curl --proxy http://proxy.corp.example:8080 https://service.example.net/status

첫 주소는 프록시 리스너이고 둘째는 원하는 서비스입니다. 이것은 예시 엔드포인트이며 누군가 수행한 시험이 아니므로, 조직의 스킴과 포트, 인증 흐름으로 바꿔 넣으세요.

이 대상에 맞는 프록시 고르기

관리자에게 조직이 어떤 프록시를 보유했는지가 아니라, 정책이 필요한 URL에 대해 어떤 프록시를 고르는지 물어보세요. PAC 규칙은 내부 서비스, 공개 사이트, 장애 전환 상황에서 다른 결과를 돌려줄 수 있고, 오늘 URL과 맞는 규칙도 편집 후에는 다른 URL과 맞을 수 있습니다.

작업 흐름에 알려진 요청이 하나보다 많다면 관리자가 지원하는 정적 설정이나 승인된 PAC 인식 통합을 쓰세요. 복사한 주소 하나를 하드코딩하는 방식은 정책이 바뀌고 그 주소를 왜 골랐는지 아무도 기억하지 못하는 날까지 유지됩니다.

다음으로 curl이 무엇을 물려받는지 보세요. 프록시 환경 변수와 NO_PROXY 은 전달한 프록시를 덮어쓰거나 제외할 수 있고, 대상과 맞는 제외는 요청을 조용히 직접 보냅니다. 모든 제외를 지우거나 모든 것을 한 주소로 몰아넣지 말고 의도한 정책을 유지하세요. 요청을 한 번 -v 을 붙여 실행하고 실제로 어느 주소에 연결했는지 확인하세요.

두 TLS 신원을 구분하세요

HTTPS 프록시에서는 TLS 연결이 두 개 관여합니다. 하나는 프록시로 가는 내 연결이고 다른 하나는 프록시에서 대상으로 가는 연결입니다. 각각 검증할 신원이 따로 있고, 둘 중 어느 것에든 검증을 끄는 것은 PAC 수정이 아니라 첫 문제에 두 번째 문제를 더하는 일입니다.

검증을 켜 둔 채로 받은 실패를 읽으세요. 프록시 인증 요구, 닿을 수 없는 프록시, 웹사이트의 거부는 서로 다른 세 결과이고 자격 증명과 관련된 것은 첫 번째뿐입니다. VPN은 이것들 중 무엇이든 성공하기 전에 프록시 호스트 자체의 이름 해석을 포함해 사설 프록시로 가는 허용된 경로를 제공해야 합니다.

엔드포인트, 스킴, 포트, 인증 방식, 제외, 프록시까지의 VPN 경로를 적어 두세요. 그 기록이 다음 요청을 재현 가능하게 만들며, 프록시를 아는 것과 그것을 짐작하는 것의 차이가 바로 거기에 있습니다.