Windows에서 Git·GitHub CLI(gh)를 Clash로: HTTPS 클론·fetch와 Git Credential Manager 실무 맞춤 (2026)

1. 검색 의도: 무엇이 동시에 맞아야 하나

사용자 입장에서 문제는 단순합니다. 「Clash를 경유해 GitHub만 안정적으로 쓰고 싶다」인데, 실제로는 TCP 출구·TLS SNI·DNS·OS 자격 증명 UI가 각각 다른 전제를 갖고 있어서, 증상만 보면 모두 비슷한 fatal: unable to access 한 줄로 뭉개집니다. 특히 HTTPS 클론은 git 프로세스가 프록시를 쓰는지 여부와 별개로, GCM가 브라우저·디바이스 플로우로 토큰을 갱신할 때 또 다른 HTTP 스택을 타는 경우가 있습니다. 한 세션에서는 프록시를 타고, 자격 증명 헬퍼는 직행해 타임아웃·403·쿠키 불일치가 나면 「토큰이 망가졌나」보다 「경로가 갈렸나」를 먼저 의심하는 편이 빠릅니다.

이 글의 범위는 Windows 호스트의 네이티브 셸(PowerShell·CMD·Git Bash)이며, WSL 내부 리눅스 셸은 루프백·DNS가 달라 WSL2·호스트 IP 글을 먼저 맞춘 뒤 같은 변수를 적용하는 편이 안전합니다. npm·pnpm 프록시 글과도 짝을 이룹니다. IDE 안쪽 터미널은 부모 프로세스가 환경 변수를 물려주지 않는 경우가 있어, 「전역으로 넣었는데만 안 된다」면 해당 터미널에서 echo $env:HTTP_PROXY부터 다시 확인해야 합니다.

2. Clash 쪽 전제: mixed-port와 TUN·시스템 프록시

mixed-port(예: 7890)가 리슨 중이어야 http://127.0.0.1:7890 형태의 HTTP 프록시로 CONNECT가 붙습니다. 시스템 프록시만 켜 두고 터미널 변수는 비어 있으면, GUI 앱과 CLI가 갈라지는 첫 번째 원인이 됩니다. 반대로 TUN을 켠 구성에서는 이론상 전역으로 잡히지만, 관리자 권한·UWP·DNS 모드 조합에 따라 git만 예외로 보이는 일이 있어, 장기적으로는 「CLI 표준」인 HTTP_PROXY를 세션에 명시해 두는 편이 재현성이 높습니다. Verge 등에서 시스템 프록시와 TUN을 같이 다루는 흐름은 Windows 11·Verge Rev 글과 교차해 보시면 전체 그림이 맞습니다.

3. Git이 읽는 HTTP_PROXY·HTTPS_PROXY·ALL_PROXY

대부분의 Git 빌드는 libcurl을 쓰며, 대소문자 변종까지 포함해 표준 프록시 변수를 참고합니다. 관행적으로 HTTPS_PROXY에도 http://127.0.0.1:포트를 넣습니다. Clash mixed-port는 HTTP 프록시로 붙여 TLS를 CONNECT로 올립니다. git config --global http.proxy·https.proxy를 쓰면 사용자 전역에 남아 팀원마다 포트가 다를 때 관리가 번거로우므로, 프로젝트 공유 저장소에는 비우고 셸 스크립트로만 넣거나 반대로 팀 표준으로 고정하는 식의 정책을 택하게 됩니다.

git -c http.proxy=...처럼 일회성으로 끼워 넣어 실험할 수도 있습니다. 프록시가 비어 있으면 github.com으로 직접 나가다 회사 방화벽·지역 라우팅에서 막히고, 프록시만 있고 Clash 규칙이 DIRECT로 떨어지면 또 다른 의미의 실패가 납니다. 그래서 변수는 애플리케이션 레벨, 규칙은 mihomo 레벨에서 한 번 더 확인하는 이중선이 실무에서 잘 버팁니다.

4. PowerShell·CMD·Git Bash에서 세션 변수 넣기

PowerShell 현재 세션 예시는 아래와 같습니다. 포트는 본인 Clash 설정에 맞춥니다. CMD에서는 set HTTP_PROXY=... 형태, Git Bash·MSYS는 export가 익숙합니다. 변수를 바꾼 뒤에는 같은 창에서 git ls-remote로 빠르게 검증하세요.

# PowerShell: current session (adjust port)
$env:HTTP_PROXY   = "http://127.0.0.1:7890"
$env:HTTPS_PROXY  = "http://127.0.0.1:7890"
$env:ALL_PROXY    = "http://127.0.0.1:7890"
git ls-remote https://github.com/git/git.git HEAD

setx로 사용자 환경에 박아 두는 방법도 있으나, 다른 도구까지 함께 프록시를 타게 되고 되돌리기가 귀찮아집니다. 가능하면 「개발 셸을 띄울 때만 실행하는 프로필 스크립트」로 한정하세요. 공용 PC라면 보안 경고는 npm 글과 같습니다. 영구 저장 전에 팀 보안 정책을 확인하는 것이 좋습니다.

5. GitHub CLI gh: 인증·API와 같은 프록시 쓰기

gh는 GitHub의 REST·GraphQL·Git 작업에 모두 붙습니다. 일반적으로 위와 같은 HTTP_PROXY·HTTPS_PROXY를 존중합니다. gh auth login 과정에서 브라우저 플로우가 뜨면, 브라우저는 시스템 프록시를, 터미널 쪽 후속 요청은 환경 변수를 따를 수 있어 경로가 어긋나지 않게 Clash에서 github.com·api.github.com이 일관되게 나가는지 먼저 맞춥니다.

조직 SSO·엔터프라이즈 호스트를 쓰면 GH_HOST·엔터프라이즈 베이스 URL이 추가되므로, Clash 규칙에 그 호스트를 별도로 넣어야 할 때가 있습니다. 인증이 끝난 뒤 gh api user가 실패하면 토큰 만료보다 먼저 프록시·DNS·HTTP 코드를 보는 습관이 비용을 줄입니다. 고급 사용에서 SOCKS만 쓰는 경우도 있으나, 본문은 mixed HTTP 프록시와 맞물리는 가장 흔한 패턴에 맞췄습니다.

6. mihomo 규칙 예시: github.com 축을 한 그룹에

분기 규칙은 파일 위쪽일수록 우선합니다. 아래는 개념 스니펫이며 정책 그룹 이름은 본인 YAML에 맞게 바꿉니다. MCP 글에서 안내한 github.com·api.github.com·codeload.github.com·raw.githubusercontent.com·객체 스토리지 계열을 같은 그룹에 두면, git clone이 메타·아카이브·LFS를 섞어 부를 때 출구가 갈라지는 문제를 줄일 수 있습니다.

# Example rules — replace PROXY with your policy group name
rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY
  - DOMAIN-SUFFIX,github.dev,PROXY

GEOIP,cn,DIRECT 같은 광역 규칙이 앞에 있으면 의도와 다르게 직행할 수 있으니, GitHub 축은 상단에 고정하는 편이 안전한 경우가 많습니다. 세부 튜닝은 라우팅 가이드와 구독 안정화를 함께 보시면, 로그에서 어떤 FQDN이 어떤 정책으로 떨어졌는지 역추적하기 쉽습니다. 구독 자체가 자주 깨지면 Windows 구독·TLS 글부터 점검하세요.

7. Git Credential Manager: 혼용 실패와 캐시·지우기

GCM는 Windows에서 흔히 manager·manager-core 계열로 붙습니다. 한때는 프록시 없이 저장된 자격 증명으로만 시도하다 실패하고, 새로 로그인하면 성공했다가 다음 날 또 막히는 패턴이 나올 수 있습니다. 원인은 토큰 자체보다 「직행으로 받은 쿠키/리다이렉트」와 「프록시 경유 토큰」이 섞인 경우가 많습니다. 이때 저장소 단위로 비우거나 호스트 단위로 지우는 절차가 필요합니다.

예를 들어 HTTPS GitHub 호스트에 대해 관리자에 등록된 항목을 제거한 뒤, 프록시를 고정한 같은 셸에서 다시 git fetch를 시도합니다. GCM 버전에 따라 명령이 조금 다를 수 있으니 공식 문서의 erase 예제를 함께 보시되, 핵심은 「혼용 전 자격 증명을 비우고, 한 가지 네트워크 경로로 다시 흐르게 한다」입니다. PAT를 쓰는 팀이라면 SSO 승인·만료일·조직 IP 허용 목록도 같은 우선순위로 봐야 합니다.

# Example: open GCM UI to remove saved GitHub credentials, or use:
git credential-manager erase
# then paste host/path when prompted, e.g. protocol=https host=github.com

8. NO_PROXY: 사내 Git·레지스트리만 빼기

사내 GitLab·Gitea·IP 직접 지정 원격은 Clash를 탈 이유가 없을 때가 많습니다. NO_PROXY에 해당 호스트·접미 일치·루프백을 넣어 두면, git가 불필요한 홉을 덜 돕니다. 반대로 GitHub만 쓰는 경우라면 NO_PROXY를 잘못 넓게 잡아 *.github.com까지 빼 버리면 증상이 반대로 악화됩니다. 목록은 팀 인프라 담당과 맞춘 뒤 문서화하세요.

$env:NO_PROXY = "localhost,127.0.0.1,::1,.corp.example,.gitlab.internal"

9. 실측 점검 순서

첫째, Clash에서 mixed-port 리슨과 테스트 노드 지연을 확인합니다. 둘째, 동일 셸에서 curl -I https://api.github.com와 git ls-remote를 같은 변수로 실행합니다. 셋째, Clash 로그에서 GitHub 관련 FQDN이 기대한 정책 그룹에 찍히는지 봅니다. 넷째, 인증 오류가 지속되면 GCM 저장소를 비운 뒤 동일 경로로 다시 로그인합니다. 다섯째, DNS 모드·fake-ip·IPv6는 DNS 누수·브라우저 DoH 글과 교차합니다. SSH 원격([email protected]:)은 프록시 체인이 다르므로, HTTPS와 섞어 쓰는 팀이라면 문서에 「HTTPS는 Clash HTTP 프록시, SSH는 별도 설정」처럼 역할을 나누어 두면 온보딩 분쟁이 줄어듭니다.