Gradle이 프록시 설정을 가져오는 위치

IDE에서 시작한 Gradle 빌드는 터미널에서 시작한 같은 프로젝트와 다른 구성을 사용할 수 있습니다. 오래된 프록시 프로세스를 탓하기 전에 각 시작에서 Gradle 사용자 홈, JVM, 프록시 속성을 비교하세요.

Gradle은 JVM 프록시 속성을 문서화합니다

HTTP 및 HTTPS 경로의 속성 파일에는 다음이 들어갈 수 있습니다.

systemProp.http.proxyHost=203.0.113.10
systemProp.http.proxyPort=8080
systemProp.https.proxyHost=203.0.113.10
systemProp.https.proxyPort=8080
systemProp.http.nonProxyHosts=localhost|*.example.internal

할당된 엔드포인트를 사용하세요. 허용된 공개 저장소 경로에는 HTTP 프록시 목록이 후보 호스트와 포트 쌍을 제공합니다. HTTPS 우회 속성도 http.nonProxyHosts입니다. https.nonProxyHosts를 만들어내는 것은 문서화된 해결책이 아닙니다. 호스트 속성에는 완전한 프록시 URL이 아니라 주소가 들어갑니다.

셸에서 HTTP_PROXY를 내보내는 것만으로 이 JVM 클라이언트가 이를 프록시 정책으로 사용한다는 증거가 되지 않습니다. 애플리케이션이 지원하는 속성을 확인하세요.

데몬은 빌드 정보를 받습니다

현재 Gradle 문서에 따르면 클라이언트는 환경 변수를 포함한 빌드 정보를 데몬에 보냅니다. 따라서 “데몬은 새 환경 변수를 절대 받지 않는다”는 일반적인 설명은 정확하지 않습니다.

신뢰 저장소 속성을 포함한 일부 JVM 시작 속성은 실행 중인 JVM에서 변경할 수 없습니다. 일반적인 빌드 환경 값이 전달되더라도 변경된 Java home이나 신뢰 저장소 시작 구성이 영향을 줄 수 있습니다.

두 실행을 비교하세요

IDE가 선택한 Gradle 배포판과 Java 런타임을 확인하세요. 터미널과 같은 GRADLE_USER_HOME와 사용자 속성을 사용하는지 확인하세요. 한 사용자의 구성에 있는 프록시 항목만으로 다른 컨텍스트가 무엇을 로드했는지는 알 수 없습니다.

변경된 시작 요구 사항에 다른 데몬이 필요하면 해당 Gradle 버전의 문서화된 데몬 제어를 사용하세요. 잘못된 속성이나 누락된 구성 파일을 찾는 대신 데몬을 중지하지 마세요.

마지막으로 실패한 요청을 확인하세요. Wrapper 다운로드, 빌드 종속성 해결, 분기된 애플리케이션 또는 테스트 프로세스의 요청은 자동으로 하나의 네트워크 컨텍스트가 아닙니다. Gradle 속성이 제어할 것이라고 기대하기 전에 요청을 수행하는 프로세스를 확인하세요.