.png)
클라이언트가 Proxypac을 통해 프록시 서버를 통과하도록 하는 표준 기업 환경. OSX 구성에서는 다음 형식을 따릅니다.
http://www.proxy.server.name:8080/proxy_pac_path_to_package.pac
홈브류 설치를 위해 CLI를 통해 연결을 시도하고 (지금까지) 다음 옵션을 사용했습니다.
export http_proxy=http://www.proxy.server.name:8080/proxy_pac_path_to_package.pac
export http_proxy=http://www.proxy.server.name:8080
export http_proxy=http://myusername:[email protected]:8080/proxy_pac_path_to_package.pac
export http_proxy=http://myusername:[email protected]:8080
mypasswd 특수 문자는 16진수 코드에 매핑되고 사용자 이름은 "간단한" 형식이나 전체 AD 경로 또는 이메일 등을 사용합니다.
위의 어느 것도 작동하지 않았습니다. 분명하지 않은 일을 통해 자신의 경험을 통해 내가 무엇을 놓칠 수 있는지에 대한 아이디어가 있습니까?
답변1
귀하의 특정 기업 환경에 대한 액세스 권한이 없기 때문에 확실한 진단을 내릴 수는 없지만 가장 먼저 시도해 볼 것은 동일한 값으로 내보내는 것입니다(URL이 https_proxy없을 수도 있습니다 . 이다 ). 귀하가 선택한 다양한 값은 시도해 볼 만한 올바른 값이었습니다(비록 사용자 이름/비밀번호에 대한 매우 이상한 인코딩을 보았으므로 이에 대해서는 쓰지 않겠습니다). Safari가 프록시를 통해 작동하는지 확인하고 Safari를 통해 프록시에 로그인해야 하는 경우 그렇게 합니다. Safari가 프록시를 통해 작동하지 않는 경우 기본적으로 Homebrew가 작동할 가능성은 없습니다.all_proxyhttps_proxyhttps:http_proxy
두 번째 시도로(이것은 부두교이고 단지 카고 컬팅일 수도 있지만) 스키마 대신 스키마로 설정해 보고 그렇지 않으면 URL의 나머지 부분을 동일하게 남겨 둘 수 http:있습니다 socks5:. 특정 프록시가 Windows 클라이언트에 더 적합하고 여전히 오래된 코드를 가지고 있고 Windows 버전의 TCP 스택 간의 상호 운용성 기록이 좋지 않기 때문에 SOCKS가 더 안정적이기 때문에 이 작업을 보았습니다.
답변2
믿을 수 없는!!! 내 입장에서는 엄청난 DUH: 두 개의 iTerm 창을 동시에 열었습니다. 한 창에서는 CLI에서 http_proxy 내보내기를 수행하고 다른 창에서는 연결을 테스트하고 있었습니다(물론 인식하지 못한 채 다른 쉘 세션을 실행 중이었습니다). 내가 변경한 변수의 내보낸 변수 중)... 이것이 얼마나 어리석은 일인지 믿을 수 없습니다. 소음으로 인해 죄송합니다... 그리고 제가 바보가 아니라고 생각해준 @Trey에게 감사드립니다 :-)