In this Article
기업 네트워크 안에서 GitHub를 사용하는 일은 보통 설정 문제이며, 설정을 공유하지 않는 다섯 가지 도구에 걸쳐 있습니다. 복제는 작동하지만 npm install은 실패할 수 있고, npm은 작동하지만 Docker는 이미지를 가져올 수 없을 수 있으며, 명령줄에서는 모두 작동하는데 IDE는 아무것에도 연결하지 못할 수 있습니다.
이 가이드에서는 각 도구가 프록시 설정을 읽는 위치, SSH가 HTTPS와 다르게 동작하는 이유, 실제로 마주하게 될 네 가지 오류 유형을 해석하는 방법, 그리고 피해야 할 두 가지 지름길을 다룹니다.
핵심 정보
- 각 도구에는 자체 프록시 설정이 있습니다. Git, npm, pip, Docker 및 셸은 모두 서로 다른 설정을 읽으므로, 하나를 고쳐도 나머지는 계속 작동하지 않을 수 있습니다.
- HTTPS가 작동하는 환경에서도 SSH는 보통 실패합니다. 대부분의 기업 프록시는 표준 포트에서 HTTP CONNECT만 전달하기 때문입니다.
- 인증서 오류는 거의 항상 TLS 검사 때문입니다. 해결책은 검증을 비활성화하는 것이 아니라 기업 CA를 신뢰하도록 설정하는 것입니다.
- clone을 작동시키기 위해 인증서 검증을 절대 비활성화하지 마십시오. 눈에 보이는 설정 문제를 보이지 않는 보안 문제로 바꾸게 됩니다.
- 프록시 URL에 포함된 자격 증명은 로그와 셸 기록에 유출됩니다. 대신 도구의 자격 증명 저장소를 사용하십시오.
각 도구는 프록시 설정을 어디에서 읽습니까?
각각 별도로 읽으며, 이것이 혼란 대부분의 근본 원인입니다. 이를 4단계 도구 체인 모델이라고 부릅니다.
| 도구 | 확인하는 위치 | 흔한 공백 |
|---|---|---|
| 1. Git | 자체 설정, 그다음 환경 변수 | HTTPS 원격 저장소는 작동하지만 SSH 원격 저장소는 작동하지 않음 |
| 2. 패키지 관리자 | 자체 설정 파일, 그다음 환경 변수 | 각각 별도로 설정해야 하며, 레지스트리는 GitHub와 다를 수 있음 |
| 3. Docker | 셸뿐 아니라 데몬 설정 | 셸 변수는 이미지를 가져오는 데몬에 전달되지 않음 |
| 4. IDE 및 편집기 | 자체 설정, 경우에 따라 시스템 저장소 | 터미널은 작동하지만 통합 기능은 작동하지 않음 |
따라서 작동하는 github 프록시 설정은 하나가 아니라 다섯 가지 설정을 뜻합니다. 실무적인 순서는 셸의 환경 변수를 설정하고, git을 설정한 다음, 각 패키지 관리자와 Docker 데몬을 설정하며, 처음부터 내부 호스트용 no-proxy 목록을 포함하는 것입니다. 마지막 단계를 건너뛰면 설정이 정상적으로 완료된 뒤에도 내부 서비스에 연결할 수 없게 됩니다.
HTTPS는 작동하는데 SSH는 왜 실패합니까?
서로 다른 포트의 서로 다른 프로토콜이고, 대부분의 기업 프록시는 제한된 포트 집합으로의 HTTP CONNECT만 전달하기 때문입니다.
HTTPS를 통한 Git은 프록시가 기본적으로 처리하는 일반적인 웹 요청입니다. SSH를 통한 Git은 포트 22를 사용하며, 이 포트는 보통 프록시를 통해 전혀 허용되지 않습니다. 따라서 HTTPS 원격 저장소에서는 리포지토리가 문제없이 복제되지만 SSH 원격 저장소에서는 시간 초과가 발생하고, 오류 메시지에는 이유가 거의 나타나지 않습니다.
선호도 순서에 따른 세 가지 실질적인 해결책은 다음과 같습니다. 원격 저장소를 토큰이 있는 HTTPS로 전환하거나, GitHub가 지원하는 경우 HTTPS 포트에서 SSH를 사용하거나, 네트워크 팀에 특정 호스트에 대한 SSH 허용을 요청하십시오. 첫 번째 방법은 어디에서나 작동하며 대부분의 팀이 선택하는 방법입니다.
오류를 어떻게 해석합니까?
| 오류 | 이 해결책을 사용할 경우 | 피해야 할 경우 |
|---|---|---|
| 인증서 검증 실패 | 기업 CA를 도구의 신뢰 저장소에 추가 | 실제 위험을 숨기는 검증 비활성화는 절대 하지 않음 |
| SSH 원격 저장소에서 연결 시간 초과 | HTTPS로 전환하거나 HTTPS 포트에서 SSH 사용 | 재시도, 포트가 느린 것이 아니라 차단된 상태임 |
| 프록시 인증 필요 | 도구의 저장소에서 자격 증명 구성 | 로그에 유출되는 URL에 자격 증명 입력 |
| 터미널에서는 작동하지만 Docker에서는 실패 | Docker 데몬 구성 후 재시작 | 데몬이 읽지 않는 셸 변수를 더 추가 |
| 설정 후 내부 호스트에 연결할 수 없음 | no-proxy 목록에 추가 | 프록시 설정을 완전히 제거 |
첫 번째 행은 단호하게 대응할 가치가 있습니다. TLS 검사는 중간 장비가 연결을 종료하고 다시 서명한다는 뜻이며, 올바른 대응은 조직의 CA를 의도적으로 신뢰하도록 설정하는 것입니다. 검증을 비활성화하면 오류는 사라지지만 향후 모든 가로채기를 감지할 수 없게 됩니다.
외부 프록시가 적합한 도구인 경우는 언제입니까?
이 문제에서는 드물며, 이를 분명히 해 둘 가치가 있습니다.
기업 프록시는 조직이 운영하는 인프라이며, 그 뒤에서 GitHub에 접속하는 문제의 해결책은 두 번째 프록시가 아니라 설정입니다. 고용주가 의도적으로 마련한 네트워크 제어를 우회하는 일은 기술적 문제에 앞서 정책의 문제입니다.
상용 프록시가 실제로 적용되는 경우는 GitHub와 관련되었을 뿐 다른 작업입니다. 공개 리포지토리 데이터를 대규모로 수집하거나, 다른 국가에서 공개 페이지가 어떻게 렌더링되는지 확인하거나, 여러 지역에서 자동화 검사를 실행하는 작업이 여기에 해당합니다. 특히 리포지토리 데이터를 수집할 때는 토큰을 사용하는 GitHub API가 우선적인 정답이며, 그 할당량도 충분히 넉넉하여 웹 스크래핑이 정당화되는 경우는 드뭅니다.
수집에 분산된 출구가 필요한 경우 DataImpulse 레지덴셜 프록시는 195개국을 GB당 $1에 제공합니다. 관련 글: 웹 스크래핑용 프록시, 403 Forbidden 설명.
자주 묻는 질문
git이 프록시를 사용하도록 어떻게 설정합니까?
git 자체 설정 또는 표준 환경 변수에서 프록시를 설정하고, 동시에 내부 호스트를 no-proxy 목록에 추가하십시오. Git은 npm, pip 및 Docker와 별도로 자체 설정을 읽으므로 각 도구를 개별적으로 설정해야 합니다.
프록시 뒤에서 SSH를 통한 git 복제는 왜 실패합니까?
SSH는 포트 22를 사용하고 대부분의 기업 프록시는 표준 웹 포트로의 HTTP CONNECT만 전달하기 때문입니다. HTTPS 원격 저장소는 일반적인 웹 요청이므로 작동합니다. 토큰이 있는 HTTPS로 원격 저장소를 전환하는 방법은 가장 많은 환경에서 작동하는 해결책입니다.
기업 프록시 뒤에서 인증서 오류가 발생하는 원인은 무엇입니까?
TLS 검사입니다. 중간 장비가 조직 자체 인증 기관의 인증서로 연결을 종료하고 다시 서명합니다. 해결책은 각 도구의 신뢰 저장소에 해당 CA를 추가하는 것입니다. 인증서 검증을 비활성화하면 오류는 없어지지만 실제 가로채기를 감지할 수 있는 능력도 사라집니다.
터미널은 작동하는데 Docker는 왜 실패합니까?
이미지를 가져오는 것은 셸이 아니라 Docker 데몬이며, 데몬은 환경 변수가 아니라 자체 설정을 읽기 때문입니다. 데몬의 프록시 설정을 구성하고 재시작하십시오.
직장에서 GitHub에 접속하기 위해 상용 프록시를 사용해야 합니까?
아니요. 기업 프록시는 조직이 의도적으로 운영하는 인프라이며, 해결책은 설정입니다. 상용 프록시는 여러 지역에서 공개 데이터를 수집하는 등의 다른 작업에 적용되며, 그런 경우에도 토큰을 사용하는 GitHub API가 보통 더 나은 방법입니다.
작업이 연결이 아니라 수집인 경우
다른 지역에서 공개 페이지가 어떻게 렌더링되는지 확인하거나 공개 데이터를 대규모로 수집하는 일은 기업 네트워크 설정과는 다른 문제입니다. DataImpulse 레지덴셜 프록시는 195개국을 GB당 $1에 제공합니다. 그 작업이 필요할 때 계정 만들기를 선택하십시오.
관련 글: 웹 스크래핑용 프록시 · 웹 스크래핑 시 403 Forbidden · 웹 프록시란 무엇인가.
최종 업데이트: 2026년 9월 17일.