cannot open git-upload-pack만으로 원인을 단정할 수 없습니다. Eclipse의 Error Log에서 함께 나온 메시지를 확인한 뒤 저장소 주소, 인증, 인증서, 프록시 순서로 범위를 좁혀 보세요.
2026년 10월 16일 수정: 이 글의 예전 내용은 http.sslVerify=false 설정만 안내했습니다. 인증서 검증을 끄는 방법을 일반 해결책으로 제시한 부분을 바로잡았습니다.
1. 상세 오류부터 확인하기
Eclipse의 Error Log 보기에서 실패한 시각의 예외와 하위 원인을 확인합니다. 사용 중인 Eclipse·EGit·Java 버전, HTTPS인지 SSH인지도 함께 기록하세요. 오류 로그를 공유할 때 토큰·비밀번호·내부 주소는 가립니다.
- 401 또는 인증 실패: 계정과 인증 수단을 확인합니다.
- 403 또는 저장소 접근 거부: 계정의 접근 권한과 조직 정책을 확인합니다.
- 404 또는 저장소를 찾을 수 없음: 복제 URL과 접근 권한을 함께 확인합니다. 비공개 저장소는 권한 문제도 의심해야 합니다.
- 인증서·PKIX 관련 메시지: 서버 인증서와 Eclipse가 사용하는 Java 환경의 신뢰 설정을 확인합니다.
- 타임아웃·호스트 조회 실패: 네트워크와 프록시 설정을 확인합니다.
이 목록은 진단 순서이며 각 메시지의 원인이 하나로 정해진다는 뜻은 아닙니다.
2. URL과 인증 확인하기
저장소 서비스에서 복제 URL을 다시 확인합니다. GitHub HTTPS 인증에서 토큰을 요구하는 경우 일반 계정 비밀번호 대신 적절한 권한의 토큰을 사용합니다. 토큰을 URL에 직접 넣지 말고 인증 입력란이나 지원되는 자격 증명 저장소를 사용하세요.
명령줄 Git이 설치되어 있다면 같은 저장소 폴더에서 아래 읽기 전용 조회로 비교할 수 있습니다. 출력에는 사설 저장소 주소가 포함될 수 있습니다.
git remote -v
git ls-remote origin명령줄에서는 성공하고 Eclipse에서 실패해도 서버가 완전히 정상이라고 단정할 수는 없습니다. 두 도구가 사용하는 인증 저장소·프록시·인증서 환경을 비교하는 단서로 사용하세요.
3. 인증서 검증을 끄기보다 신뢰 경로 확인하기
Git의 http.sslVerify는 HTTPS 인증서 검증 여부이며 기본값은 true입니다. 인증서 오류라면 서버의 만료·호스트 이름·체인 설정을 확인하고, 사내 인증서를 사용하는 환경에서는 관리자가 제공한 신뢰 설정을 따르세요. EGit의 HTTP 구현과 Java 실행 환경도 확인 대상입니다.
이전 글을 따라 검증을 껐다면 해당 설정의 위치와 적용 범위를 확인해 해제한 설정을 되돌리세요. 인증 문제가 해결되는지 확인하지 않고 전역 설정을 반복 변경하지 마세요.
4. 프록시와 재확인
회사 네트워크에서만 실패한다면 Eclipse의 Preferences → General → Network Connections를 확인합니다. EGit은 HTTP 연결 구현에 따라 프록시 동작이 다를 수 있습니다. 설정을 하나씩 바꾸며 동일한 조회로 결과를 비교하세요.
이 글은 공식 문서에 근거한 진단 안내입니다. 특정 Eclipse 설치에서 같은 장애를 재현해 해결했다고 주장하는 글은 아닙니다.
댓글 없음:
댓글 쓰기