Windows 터미널 git·curl이 Clash를 안 탈 때: HTTP_PROXY

왜 브라우저는 되는데 터미널만 Clash를 안 탈까요?

Windows에서 Clash를 켜 두고 Edge·Chrome은 잘 열리는데, PowerShell이나 CMD, Git Bash에서 git clone·curl만 끊기거나 매우 느린 경험은 흔합니다. 이유는 단순합니다. 브라우저는 「시스템 프록시」나 확장·프로필에 따라 Clash의 로컬 수신 포트로 나가도록 맞춰져 있지만, 대부분의 CLI 도구는 환경 변수나 자체 설정이 없으면 직접 연결을 시도하기 때문입니다. TUN 모드를 쓰더라도 애플리케이션 종류와 드라이버 스택에 따라 터미널 프로세스가 예상과 다른 경로로 나가거나, 회사 보안 에이전트와 겹치면 증상이 섞입니다. 같은 PC에서 「호스트만의 Clash 프록시」를 명시적으로 잡아 주려면 mixed-port가 열어 둔 HTTP(S) 프록시 URI를 기준으로 http_proxy·https_proxy와 Git 프록시를 한 줄씩 맞추는 방식이 가장 재현성이 높습니다.

이 글은 순수 Windows 터미널에 초점을 맞춥니다. WSL2 리눅스 쪽에서 Windows 호스트 IP를 써야 하는 패턴은 WSL2·apt·git 가이드와 짝을 이루며, 컨테이너만 따로 다루고 싶다면 Docker·HTTP_PROXY 글을 참고하면 됩니다. 포트 번호가 꼬였는지 확인하는 흐름은 7890·mixed-port·netstat 가이드와도 맞닿아 있습니다.

1단계: Clash에서 mixed-port 번호 확인하기

Clash Meta(Mihomo) 계열 설정에서는 mixed-port: 7890처럼 HTTP와 SOCKS를 같은 포트에서 받는 구성이 일반적입니다. GUI(Clash Verge Rev 등)에서는 트레이 메뉴나 설정 화면에 「포트」「Mixed Port」로 표시됩니다. 여기서 적힌 숫자가 곧 터미널이 붙어야 할 로컬 프록시 포트입니다. 예전 스타일로 port(HTTP 전용)와 socks-port를 나눠 쓰는 프로필이라면, curl·git의 HTTPS 트래픽은 보통 HTTP CONNECT를 타므로 HTTP 쪽 번호(또는 mixed)를 기준으로 잡는 편이 안전합니다.

로컬에서만 쓴다면 프록시 주소는 http://127.0.0.1:포트 형태로 충분합니다. 방화벽이나 다른 앱이 같은 포트를 잡고 있으면 Clash가 기동 실패를 내거나, 시스템 프록시와 숫자가 달라져 브라우저와 터미널이 서로 다른 출구를 쓰는 착시가 납니다. 그럴 때는 위에서 인용한 netstat 글 순서로 먼저 정리하세요.

2단계: HTTP_PROXY·HTTPS_PROXY에 넣을 값

대부분의 도구는 소문자 http_proxy·https_proxy와 대문자 HTTP_PROXY·HTTPS_PROXY를 함께 지원합니다. Windows 개발자들은 둘 다 같은 URI로 맞춰 두면 스크립트 이식성이 좋습니다. Clash mixed-port가 7890이면 예시는 다음과 같습니다.

http://127.0.0.1:7890

https_proxy에도 위와 같이 http:// 스킴을 쓰는 것이 정상입니다. 클라이언트는 HTTPS 웹 요청을 HTTP 프록시에 터널링(CONNECT)으로 넘깁니다. SOCKS만 열어 둔 환경이라면 ALL_PROXY=socks5://127.0.0.1:...를 쓰는 경우도 있으나, Clash mixed-port는 보통 위 HTTP 형태로 통일하는 편이 단순합니다.

사내 Git·npm registry처럼 프록시를 타면 안 되는 주소가 있으면 NO_PROXY·no_proxy에 localhost,127.0.0.1,::1,.local과 사내망 대역을 넣어 분리하세요. 그렇지 않으면 내부 리포지토리만 느리거나 인증서 오류가 날 수 있습니다.

3단계: PowerShell에서 설정·검증

현재 세션에만 적용하려면 예를 들어 다음과 같습니다.

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:http_proxy=$env:HTTP_PROXY
$env:https_proxy=$env:HTTPS_PROXY

이후 curl.exe -I https://www.google.com처럼 짧은 요청으로 확인합니다. PowerShell 7과 Windows에 번들된 curl 동작이 다를 수 있으니, 실패 시 where.exe curl로 어떤 실행 파일이 잡히는지도 함께 보는 것이 좋습니다.

사용자 계정에 영구 반영하려면 시스템 속성의 「환경 변수」에서 사용자 또는 시스템 변수로 추가하거나, setx HTTP_PROXY "http://127.0.0.1:7890" 형태를 쓸 수 있습니다. setx는 현재 콘솔에는 바로 반영되지 않고 새로 연 터미널부터 적용된다는 점, 값 길이 제한이 있다는 점을 기억하세요. 팀마다 로그온 스크립트로 프로필에 주입하기도 합니다.

4단계: CMD와 Git Bash

CMD에서는 세션 한정으로 다음과 같이 설정할 수 있습니다.

set HTTP_PROXY=http://127.0.0.1:7890
set HTTPS_PROXY=http://127.0.0.1:7890

Git Bash는 MinGW 환경이라 구문은 리눅스와 비슷합니다.

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export http_proxy=$HTTP_PROXY
export https_proxy=$HTTPS_PROXY

Windows용 Git 설치 시 동봉된 Git Bash는 부모 Windows 세션의 환경 변수를 이어받기도 하므로, 한 번 GUI에서 사용자 변수를 잡아 두면 여기서도 보이는 경우가 많습니다. 반대로 Bash에만 export해 두고 VS Code 통합 터미널이 PowerShell이면 값이 비어 있는 것처럼 느껴질 수 있으니, 실제로 명령을 치는 셸 종류를 먼저 확인하는 습관이 필요합니다.

5단계: Git 전용 http.proxy·https.proxy

환경 변수만으로도 대부분의 HTTPS git clone은 동작하지만, 리포지토리마다 다르게 쓰고 싶다면 Git 자체 설정이 분명합니다.

git config --global http.proxy  http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

특정 호스트만 프록시를 태우려면 http.https://github.com.proxy 같은 URL 스코프 설정을 쓰기도 합니다. [email protected]:... 형태의 SSH 원격은 HTTP 프록시 변수를 그대로 따르지 않으므로, SSH를 꼭 써야 한다면 ProxyCommand나 HTTPS 원격으로 바꾸는 선택지를 검토해야 합니다. 자격 증명 관리자·Credential Manager가 끼어 있으면 프록시와 별개로 인증 단계에서 막히기도 하니, GIT_CURL_VERBOSE=1 등으로 한 단계씩 좁혀 가면 됩니다.

TUN을 켰는데도 왜 환경 변수가 필요할까?

TUN은 시스템 트래픽을 가로채는 모델이라 이론상 대부분의 프로그램이 같은 터널을 탈 수 있지만, 실제로는 드라이버 권한·스플릿 라우팅·보안 소프트웨어에 따라 CLI만 예외가 되는 경우가 있습니다. 또한 개발자는 「지금 이 터미널만 잠깐 프록시」를 켜고 끄고 싶을 때가 많아서, 명시적 HTTP_PROXY가 디버깅과 문서화에 유리합니다. 전역 TUN 동작과의 개념 비교는 TUN 모드 상세 글을 함께 읽으면 흐름이 잡힙니다.

자주 있는 증상과 점검 순서

Connection refused

Clash가 꺼져 있거나, mixed-port가 7890이 아닌데 환경 변수만 옛날 번호로 남아 있는 경우가 많습니다. 클라이언트 대시보드에서 실제 수신 포트를 다시 확인하세요.

프록시 변수는 맞는데 여전히 직결이라고 느껴질 때

일부 도구는 자체 설정 파일에 직접 주소를 박아 두었거나, 서비스 계정으로 돌아가 사용자 환경 변수를 볼 수 없습니다. 해당 도구 문서에서 「proxy」 키워드로 별도 옵션을 찾아보세요.

TLS handshake 실패

회사 SSL 검사 제품이 HTTPS를 가로채면 인증서 체인이 달라질 수 있습니다. 브라우저에서도 같은 오류가 나는지 먼저 비교해 보세요.

정리

Clash Windows 환경에서 터미널만 막힌다면, 브라우저용 시스템 프록시와 달리 CLI가 직접 나가고 있을 가능성을 먼저 의심하면 됩니다. HTTP_PROXY·HTTPS_PROXY에 Clash mixed-port에 맞는 http://127.0.0.1:포트를 넣고, 필요하면 Git 프록시까지 같은 URI로 맞추면 git clone과 curl이 같은 출구로 붙습니다. WSL2나 Docker는 각각 별도 글이 있고, 설치·업데이트 패키지는 Clash 공식 다운로드 페이지에서 플랫폼별로 확인할 수 있습니다. 다른 GUI 대비 규칙·로그·확장성의 균형이 좋은 편이라, 한번 맞춰 두면 터미널 작업 흐름이 한결 편해집니다. 준비가 되었다면 → Clash를 무료로 내려받아 Windows 터미널과 함께 써 보세요.