GitHub·npm가 터미널에서만 멈춘다면: Clash HTTP_PROXY와 Git 프록시(Windows / macOS / Linux)

왜 브라우저는 되는데 터미널은 실패하나

macOS·Windows의 “시스템 프록시”는 Safari·Edge·Chrome 같은 앱이 잘 따르지만, POSIX 셸에서 돌아가는 바이너리는 그 설정을 자동으로 물려받지 않는 경우가 많습니다. 특히 OpenSSL 기반 git과 Node npm은 자체 스택으로 나가며, 회사 방화벽 밖의 GitHub·registry.npmjs.org로 직접 붙다가 지역 회선 품질·피어링·SNI 검열에 걸려 TCP 타임아웃이나 TLS 핸드셰이크 지연으로 보이기도 합니다.

Clash 쪽에서는 이미 규칙과 노드가 준비되어 있어도, 캡처 지점이 TUN·시스템 프록시에만 있고 CLI가 그 경로를 타지 않으면 증상은 그대로입니다. 해결의 핵심은 “브라우저와 같은 출구”를 127.0.0.1의 로컬 HTTP(S) 프록시 포트로 명시하는 것입니다. Clash 계열 클라이언트는 보통 mixed-port 하나로 HTTP와 SOCKS를 함께 받거나, HTTP 전용 포트를 따로 노출합니다—GUI의 포트 표시를 먼저 확인하세요.

• HTTP CONNECT를 지원하는 포트에 http://127.0.0.1:포트 형태로 붙는 것이 가장 호환성이 좋습니다.
• 일부 도구는 ALL_PROXY에 socks5://만 인식합니다—npm·curl 조합에 맞춰 둘 다 설정하는 편이 안전합니다.
• 내부 GitLab·사설 레지스트리는 NO_PROXY로 빼 두면 루프백·사내망 트래픽이 불필요하게 터널에 실리지 않습니다.

1단계: Clash에서 로컬 프록시 포트 확인

Verge·CFW·명령형 Meta 등 클라이언트마다 화면 이름은 다르지만, 확인할 값은 같습니다: mixed-port 또는 port(HTTP)와 socks-port. 문서화된 기본값으로 7890을 쓰는 구성도 많지만, 사용자가 바꿨을 수 있으니 현재 프로필 YAML이나 GUI 상태 표시줄을 기준으로 하세요. Allow LAN을 켠 경우 다른 기기에서 접속할 수 있지만, 터미널 프록시는 보통 127.0.0.1로 충분합니다.

2단계: 셸 환경 변수로 CLI 출구 지정

대부분의 HTTP 클라이언트는 대문자·소문자 이름을 모두 읽습니다. 호환을 위해 둘 다 맞추는 습관이 좋습니다.

# Replace 7890 with your Clash mixed-port or HTTP port
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"
export ALL_PROXY="socks5://127.0.0.1:7890"
export all_proxy="$ALL_PROXY"

ALL_PROXY는 curl·일부 언어 런타임이 SOCKS 경로를 탈 때 유용합니다. mixed-port가 HTTP와 SOCKS를 같이 받는 구성이라면 위와 같이 동일 포트에 socks5://를 지정할 수 있습니다. 클라이언트가 SOCKS를 다른 포트로 열었다면 그 번호로 바꾸세요.

3단계: OS별로 설정을 “남기기”

macOS·Linux (bash/zsh)

위 export 블록을 ~/.zshrc 또는 ~/.bashrc 끝에 넣고 source ~/.zshrc로 다시 읽습니다. 여러 네트워크 프로필을 오갈 때는 별도 스크립트로 프록시 켜기/끄기 함수를 두면 실수가 줄어듭니다.

Windows (PowerShell)

현재 세션만 적용하려면 $env:HTTP_PROXY="http://127.0.0.1:7890" 형식을 사용합니다. 사용자 환경에 고정하려면 시스템 속성의 환경 변수 편집이나 setx HTTP_PROXY "http://127.0.0.1:7890"를 쓰되, 새 터미널을 열어야 반영된다는 점을 기억하세요. WSL·Git Bash는 각각 자체 리눅스/민GW 환경이므로 《WSL2와 Windows Clash》 글과 함께 보고, WSL 안에서는 Windows 호스트 IP(또는 mirrored 모드에서의 localhost 의미)를 프록시 주소로 맞춰야 할 수 있습니다.

4단계: Git 전용 http(s).proxy

Git은 환경 변수를 존중하지만, 장기적으로는 git config가 명확합니다. 전역 설정 예시는 다음과 같습니다.

git config --global http.proxy  http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
# Optional: only GitHub
git config --global http.https://github.com.proxy http://127.0.0.1:7890

사내 Git만 예외로 두려면 http.https://internal.git.proxy를 빈 값으로 덮어쓰거나 NO_PROXY에 호스트를 추가합니다. SSH URL([email protected]:)로 클론하는 경우에는 이 설정이 적용되지 않으므로, HTTPS 원격으로 바꾸거나 SSH 자체에 ProxyCommand를 쓰는 별도 경로가 필요합니다.

5단계: npm·yarn·pnpm

npm은 프록시 환경 변수를 따르는 경우가 많지만, 레지스트리가 느릴 때는 명시적 설정이 디버깅에 유리합니다.

npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890
# When done
npm config delete proxy
npm config delete https-proxy

Yarn 1.x는 yarn config set proxy, Yarn Berry·pnpm은 문서에 맞는 .yarnrc.yml·환경 변수를 사용합니다. 회사 미러(registry=)와 프록시를 동시에 쓸 때는 인증서·MITM 이슈가 없는지 확인하세요—Clash의 스니퍼·안티바이러스 HTTPS 검사가 겹치면 npm이 신뢰 체인에서 막히기도 합니다.

6단계: curl로 빠르게 검증

curl -I https://github.com
curl -I https://registry.npmjs.org

응답 헤더가 빠르게 돌아오면 프록시 경로가 살아 있는 것입니다. 여전히 멈춘다면 Clash 로그에서 해당 도메인이 올바른 정책 그룹으로 나가는지, DNS가 fake-ip와 충돌하지 않는지 《DNS·fake-ip 점검》을 참고해 한 번에 한 변수만 바꿉니다.

SOCKS만 쓸 때와 혼합 팁

일부 툴은 HTTP 프록시만 지원하고, 다른 툴은 SOCKS5를 요구합니다. Clash mixed-port가 둘 다 받는다면 위 예시처럼 HTTP와 SOCKS를 같은 포트에 매핑할 수 있습니다. 그렇지 않다면 YAML에서 포트를 분리해 HTTP_PROXY와 ALL_PROXY에 각각 다른 포트를 넣으세요. 인증이 있는 업스트림을 쓰는 특수 구성은 로컬 Clash가 이미 인증을 처리하므로, 로컬 프록시 URL에는 보통 계정을 넣지 않습니다.

자주 묻는 질문

Q. 시스템 프록시만 켰는데 왜 안 되나요? A. 터미널 프로세스가 시스템 설정을 상속하지 않거나, 샌드박스된 IDE 터미널이 별도 환경을 쓰는 경우가 많습니다. 환경 변수는 가장 직접적입니다.

Q. Git은 되는데 npm만 실패합니다. A. 레지스트리 URL·회사 미러·cafile 설정을 확인하세요. 프록시는 살아 있어도 TLS 검증 실패로 끊길 수 있습니다.

Q. Linux 서버에 SSH로만 붙습니다. A. 서버 측 셸에도 동일한 export가 필요합니다. 서버에서 Clash를 돌리지 않는다면, 로컬에서 SSH 터널로 HTTP 프록시를 띄우는 방식을 검토하세요(이 글 범위 밖이지만 동일한 환경 변수 개념이 적용됩니다).

마무리 체크리스트

• Clash 로컬 HTTP(S) 또는 mixed 포트 번호를 GUI/YAML로 확인했다.
• HTTP_PROXY·HTTPS_PROXY·필요 시 ALL_PROXY를 셸에 넣었다.
• NO_PROXY에 localhost와 사내 도메인을 넣었다.
• git config http(s).proxy로 GitHub HTTPS 클론이 안정화되었다.
• npm 레지스트리에 curl -I 또는 npm ping으로 재현 테스트를 했다.

관련 읽을거리

Windows에서 Clash 기본기를 다시 잡으려면 《Clash for Windows 설정》을, macOS 권한·클라이언트 선택은 《Clash Verge Rev macOS》를 참고하세요. 개발자 워크플로 전체를 규칙으로 묶고 싶다면 《Claude Code·MCP CLI 라우팅》과 각도가 다릅니다—본 글은 터미널 환경 변수·Git·npm에 초점을 둔 보조 가이드입니다.

다운로드

규칙이 투명하고 로그로 검증 가능한 클라이언트일수록 위 설정이 빛납니다. Clash를 무료로 내려받고 터미널까지 한 번에 정리해 보세요.