증상: 브라우저는 되는데 npm·pip·cargo만 끊긴다

Clash(또는 Clash Verge, Mihomo 런처)가 정상이고, 웹은 빠른데 터미널에서만 npm install, pip install, cargo build가 타임아웃·극초 느린 현상이 나면, 먼저 의심할 것은 노드(서버) 품질만이 아닙니다. 많은 경우 CLI는 시스템에 설정한 「인터넷 프록시」를 자동으로 따라가지 않고, 로컬 Clash의 리슨 포트에 맞는 환경 변수가 비어 있거나 잘못된 값이어서, 레지스트리·PyPI·crates.io로의 핸드셰이크가 의도한 경로(로컬 프록시)를 타지 않는 경우가 많습니다.

또한 GUI 클라이언트가 시스템 프록시를 켜 주더라도, 그게 셸이나 IDE가 띄운 통합 터미널에 동일하게 전파된다고 가정하면 안 됩니다. macOS·Windows·Linux는 각기 다른 스택이 있고, 터미널 앱·VS Code·Cursor·Android Studio 등은 로그인 셸이 아닌 non-login 셸로 뜨는 일이 흔해, ~/.zshrc에 써 둔 변수가 IDE 쪽에선 안 읽힐 수도 있습니다. 반대로, 한쪽에만 export해 두고 다른 쪽을 보면 「설정이 없는 환경」처럼 보이기도 합니다.

네트워크 정책과 로컬 규정을 준수하는 전제에서, 본문은 기술적 연결 경로(포트·환경 변수·셸 프로필)에 한정해 설명합니다. Clash의 기본 개념은 Clash 사용 문서에서 함께 보시면 흐름이 잡힙니다. 포트가 맞는지·노드가 의심될 때는 로그로 포트와 노드 타임아웃을 구분하는 글도 병행하면 진단이 빨라집니다.

Clash 혼합(mixed) 포트를 먼저 확인하라

Clash·Mihomo 계열은 보통 HTTP 전용, SOCKS5 전용, 그리고 둘을 합친 mixed(혼합) 리슨 포트를 따로 둡니다. 터미널 툴이 기대하는 값은 「HTTP 프록시 URL」이 많으므로, mixed 포트는 HTTP Connect를 받는 쪽에 가깝다고 이해하는 편이 실무에 맞습니다. (클라이언트·코어 설정에 따라 라벨은 mixed-port 등으로 표기됩니다.)

여기서 흔한 실수는, 예전에 듣기로 7890이었다는 기억만으로 http://127.0.0.1:7890을 넣는 것입니다. 실제로는 다른 인스턴스가 그 포트를 쓰거나, 프로필이 바뀌며 mixed가 7891·9090 등으로 옮겨간 뒤에도 옛날 export가 남아 있으면, 요청이 엉뚱한 곳으로 가 접속 실패·타임아웃이 납니다. 반드시 현재 사용 중인 GUI/코어 설정 화면에서 mixed(HTTP) 리슨 주소를 읽고, 그 숫자를 환경 변수에 반영하세요. 로컬 루프백이면 127.0.0.1을, LAN 공유를 켠 경우 PC의 사설 IP를 써야 할 수도 있습니다. 다만 팀/회사망에선 보안·정책에 맞는지 먼저 확인해야 합니다.

HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY

많은 HTTP 클라이언트와 패키지 매니저는 다음 관례를 따릅니다. HTTP_PROXY / HTTPS_PROXY는 각각 http·https URL의 프록시를 지정하고, ALL_PROXY는 둘 다에 대해 fallback·통합으로 쓰이는 경우가 있습니다. NO_PROXY(또는 no_proxy)는 프록시를 타지 말아야 할 호스트를 쉼표로 구분해 넣습니다(예: 사내망, 로컬 레지스트리).

Clash에 붙일 때 흔한 조합은 HTTP 계열로 혼합 포트에 맞추는 것입니다. 예는 아래와 같습니다. PORT는 본인의 mixed 값으로 바꿉니다.

# Example: point CLI tools to local Clash mixed (HTTP) port — replace PORT with your mixed port
export HTTP_PROXY="http://127.0.0.1:PORT"
export HTTPS_PROXY="http://127.0.0.1:PORT"
export http_proxy="http://127.0.0.1:PORT"
export https_proxy="http://127.0.0.1:PORT"

일부 툴은 소켓을 직접 쓰기도 해서, mixed가 SOCKS만 열려 있다면 socks5://127.0.0.1:… 형식이 맞는 경우가 있습니다. 그때는 ALL_PROXY에 socks5://…를 두고, HTTP 전용 툴과 충돌이 나는지 에러 메시지로 확인하는 것이 좋습니다. https_proxy에 socks를 넣는 조합이 맞는지는 런타임마다 달라, 한 가지만 고집하기보다 curl -v로 실제로 어떤 프록시로 나가는지 보는 것이 확실합니다.

NO_PROXY에는 localhost,127.0.0.1,::1·사내 *.corp.example 등을 넣어 불필요한 루프·사내만 직통을 줄일 수 있습니다. 잘못 넓게 잡으면 정작 필요한 외부 요청이 직접으로 빠지기도 하니, 목록을 최소한으로 유지하는 태도가 안전합니다.

일반 셸과 IDE 통합 터미널은 다른 수조를 탄다

터미널.app·iTerm2·Windows Terminal에서 직접 연 것과, VS Code·Cursor·IntelliJ 안의 통합 터미널은 초기화 스크립트가 다를 수 있습니다. 예를 들어 zsh는 .zshrc는 인터랙티브에서만 읽힌다는 식의 차이, 혹은 IDE가 최소 환경으로만 셸을 띄워 PATH만 잡는 경우가 있습니다. 그 결과 같은 PC에서도 한쪽만 프록시가 보이는 현상이 납니다.

실용적인 대응은 세 가지입니다. 첫째, 둘 다에서 쓰는 export를 ~/.zshrc와(쓰는 경우) ~/.zprofile 등에 의도를 나눠 넣는다. 둘째, IDE 설정에 터미널용 환경 변수를 넣는다(지원하는 편집기라면 terminal.integrated.env.* 류). 셋째, 프로젝트마다 direnv·.envrc로 프로젝트 루트에서만 켰다 껐다 한다. 팀에서 공유하는 경우에는 로컬 전용 파일로 두는 편이 실수로 커밋되는 일을 줄입니다.

Windows에서는 시스템 환경 변수 UI로 넣은 값이, WSL2 안의 터미널에 자동 복제되지 않는 경우가 흔합니다. WSL은 별도 리눅스 환경이므로 ~/.bashrc / ~/.profile에 같은 URL을 다시 선언하거나, WSL용 스크립트로 동기화하는 패턴이 필요할 수 있습니다.

도구별로 자주 틀어지는 지점: npm, pip, Cargo

npm은 환경 변수를 따르며, npm v7 이후 설정 파일(npm config)에 proxy / https-proxy가 우선되는 일이 있어, 과거에 넣은 잘못된 프록시가 남아 있으면 env가 맞아도 느리거나 실패할 수 있습니다. npm config list로 확인하고, 집에서는 의도한 registry인지도 함께 보세요.

pip는 PIP_TRUSTED_HOST나 내부 인덱스, --proxy 인자, pip config의 값이 겹쳐 혼란을 부추깁니다. HTTP_PROXY만으로 해결될 때도 있지만, 사내 Artifactory 등으로 index-url을 쓰는 중이라면 그 호스트는 NO_PROXY에 맞게 두는지 확인해야 합니다. TLS 검증 오류는 프록시 문제와 별개인 경우가 많으니, 메시지를 그대로 검색해 원인을 나누는 편이 낫습니다.

Cargo(rustup)는 crates.io, 때로는 git 기반 소스·서브모듈까지 건드려 Git의 프록시 설정과 맞물리기도 합니다. HTTP(S)_PROXY에 더해, 필요 시 git config --global http.https://github.com.proxy 같은 호스트 단위 설정이 추가로 필요한 프로젝트가 있습니다. 국가·회선에 따라 미러를 쓰는 팀도 있어, CARGO_REGISTRIES_…·스파스 인덱스 옵션은 팀 표준을 따르는 것이 안전합니다.

검증: env와 curl로 한 단계씩

환경을 바꾼 뒤에는 다음 순서로 확인하세요. 먼저 같은 터미널 세션에서 env | grep -i proxy로 의도한 문자열이 찍히는지 봅니다. 이어 curl -vI https://registry.npmjs.org 같이 가벼운 HTTPS 헤드로 프록시를 타는지(로그에 CONNECT·프록시 관련 라인) 확인합니다. npm ping·pip index 등 도구 본연의 health 커맨드가 있으면 그다음에 쓰는 편이 좋습니다. IDE 터미널은 같은 검사를 그 창에서 다시 수행하세요. 여기서 다르면, 아직 프로필/IDE 설정이 갈리는 것입니다.

한때 쓰던 쉬운 우회(회사 프록시·구 포트)가 .profile 어딘가에 이름만 비슷한 변수로 남아, 새 Clash와 충돌하는 경우도 있습니다. grep -R proxy ~는 범위가 너무 넓을 수 있으니, 의심스러운 파일부터 열어 중복 export를 정리하세요. 프록시를 끄고 싶을 때는 unset HTTP_PROXY HTTPS_PROXY ALL_PROXY 등으로 한 세션에서 지우는 것이 재현·디버깅에 유리합니다.

보안·팀 정책

회사 장비·VPN·DLP가 있는 환경에서는 로컬 프록시로 외부 레지스트리에 나가는 행위 자체가 정책 위반이 될 수 있습니다. 또한 NO_PROXY를 잘못 쓰면 민감한 사내 호스트로의 트래픽이 의도치 않은 경로에 노출될 위험을 키울 수 있어, 스코프·목록은 최소로 유지하세요. 본문은 기술적 설명이며, 적용은 귀하의 권한과 규정 범위 내에서만 하시기 바랍니다.

정리

Clash는 켜져도 터미널의 패키지 도구는 혼합(mixed) 포트에 맞춘 HTTP(S)_PROXY / 필요 시 ALL_PROXY을 명시해 주지 않으면, 브라우저와 다른 길로 직접 붙다 끊기기 쉽습니다. GUI에 보이는 시스템 프록시와, 셸·IDE가 실제로 읽는 환경은 항상 같다고 가정하지 말고, env·curl로 같은 창에서 확인하는 습관이 가장 큰 비용을 줄입니다. 의존성 설치는 반복 작업이므로, 한번 올바른 rc·IDE 통합 설정에 고정해 두면 이후엔 꽤 가볍게 굴러갑니다.

클라이언트·코어·규칙이 안정적일수록, 이런 로컬-포트-환경 세트만 맞으면 터미널 작업 흐름이 한결 편해집니다. 최신 Clash·Verge·Mihomo를 쓰는 편이 파서·프로바이더 쪽 호환에도 이롭고, 공식 다운로드에서 설치하신 뒤 위 순서로 혼합 포트만 눈에 익혀 두면, 나중에 포트가 바뀌어도 수긍이 빨라집니다. 오픈 소스 코드·이슈는 필요 시 GitHub에서, 패키지(설치본)는 신뢰할 수 있는 배포 경로를 우선하세요 — 위 다운로드 링크가 그 역할을 합니다.

→ Clash를 내려받고 혼합 포트에 맞춰 터미널 프록시를 점검해 보세요