1. 왜 브라우저는 되는데 터미널만 프록시 밖으로 나갈까

macOS에서 Clash 계열 클라이언트가 시스템 프록시를 켜면, 많은 GUI 앱은 그 설정을 따릅니다. 그러나 터미널에서 실행되는 CLI는 기본적으로 http_proxy 같은 변수가 비어 있으면 OS 레벨 프록시를 “알아서” 물려받지 않는 경우가 많습니다. 특히 curl은 빌드 옵션에 따라 시스템 키체인·프록시 자동 탐지를 쓰기도 하지만, 사용자가 기대하는 동작과 어긋날 때가 있어 명시적 환경 변수가 가장 재현성이 높습니다.

git은 자체적으로 http.proxy 계열 설정을 가지며, 셸 변수만으로는 SSH 원격이나 일부 내부 명령 경로가 다르게 동작할 수 있습니다. npm은 레지스트리 접속에 Node의 HTTP 스택을 쓰므로 HTTPS_PROXY를 읽기도 하지만, 예전에 npm config로 고정해 둔 값이 남아 있으면 혼선이 생깁니다. 따라서 “한 번에 섞어 쓰기”보다 curl 검증 → git → npm 순으로 출구를 확인하는 편이 안전합니다.

2. Clash 측에서 먼저 확인할 것: mixed-port와 리슨 주소

대부분의 Mihomo 기반 클라이언트는 YAML 프로필에서 mixed-port: 7890처럼 HTTP와 SOCKS를 한 포트에서 받습니다. 이후 예시는 모두 7890을 쓰되, 본인 환경의 숫자로 바꿔 적용하세요. 로컬 터미널만 쓸 때는 127.0.0.1:7890으로 충분합니다. 같은 맥에서 가상 머신·컨테이너 호스트까지 열어둘 계획이라면 allow-lan과 방화벽을 함께 점검해야 하는데, 그때는 LAN 프록시 가이드의 보안 메모를 참고하세요.

GUI 사용자는 Clash Verge Rev 입문 가이드에서 구독 적용·시스템 프록시 토글을 익힌 뒤, 설정 화면이나 편집기에서 실제 mixed-port 값을 확인합니다. 포트가 다르면 아래 모든 URL의 포트만 일괄 치환하면 됩니다.

3. 터미널에 넣을 표준 export 블록

zsh·bash 공통으로, 현재 세션에만 적용하려면 터미널에 그대로 붙여 넣습니다. 대문자·소문자를 함께 두면 도구별 호환성이 좋아집니다.

export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export ALL_PROXY="socks5h://127.0.0.1:7890"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"
export NO_PROXY="localhost,127.0.0.1,::1"
export no_proxy="$NO_PROXY"

HTTPS_PROXYhttp:// 스킴을 쓰는 이유는, Clash mixed-port가 일반적으로 HTTP CONNECT로 TLS 터널을 받기 때문입니다. ALL_PROXYsocks5h://를 쓰면 DNS를 프록시 측에서 해석해 누수를 줄일 수 있습니다. 일부 도구는 ALL_PROXY만 보거나 반대로 무시하므로, 둘 다 넣어 두고 증상에 맞게 조정합니다.

4. curl로 1차 검증하기

같은 터미널 창에서 변수를 export한 직후, 아래처럼 시험합니다.

curl -I https://www.google.com
curl -I https://api.github.com

응답 헤더가 빠르게 돌아오고 Clash의 연결 로그에 해당 요청이 잡히면 환경 변수 경로는 정상입니다. 반대로 Connection refused면 Clash가 꺼져 있거나 포트가 다릅니다. 타임아웃이면 노드·규칙·DNS 쪽을 의심하고 일반 트러블슈팅 가이드와 연결 로그를 함께 보세요.

문제를 좁히려면 프록시를 명시한 제어 실험도 유용합니다. curl -x http://127.0.0.1:7890 -I https://example.com이 성공하는데 환경 변수만 켠 상태에서는 실패한다면, 해당 셸에 변수가 실제로 잡혀 있는지 env | grep -i proxy로 다시 확인합니다.

5. Git: 전역 http(s).proxy와 github 전용

환경 변수만으로도 git clone https://...가 동작하는 경우가 많지만, 팀에서 권장하는 방식이나 오래된 설정과 섞이지 않도록 Git 자체 설정을 맞추는 편이 깔끔합니다.

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

GitHub만 경유하게 하려면 URL 스킴을 좁힐 수 있습니다.

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

SSH 원격([email protected]:)은 이 설정과 무관합니다. SSH를 쓸 때는 ~/.ssh/configProxyCommand 등 별도 경로가 필요하므로, 본문 범위는 HTTPS 클론 위주로 두었습니다. 설정을 되돌리려면 git config --global --unset http.proxy처럼 해당 키를 제거하면 됩니다.

6. npm·npx: registry 트래픽을 mixed-port로

npm은 프록시 관련 키가 사용자 홈에 남기 쉬우므로, 먼저 현재 값을 확인합니다.

npm config get proxy
npm config get https-proxy

비어 있거나 예전 사무실 프록시가 찍혀 있으면 아래로 맞춥니다.

npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

레지스트리가 사내 미러일 때는 NO_PROXY에 호스트명을 추가해 직접 붙게 하는 편이 낫습니다. npx 일회성 패키지도 대개 부모 셸의 환경 변수를 물려받지만, CI 스크립트처럼 비로그인 셸에서 돌면 변수가 비어 있을 수 있으니 스크립트 상단에 export 블록을 반복하는 패턴을 고려하세요.

7. NO_PROXY로 내부 주소는 직행

사내 Git·npm 미러·로컬 레지스트리는 프록시를 타면 오히려 느리거나 인증이 깨집니다. 쉼표로 구분해 도메인·IP를 나열합니다.

export NO_PROXY="localhost,127.0.0.1,::1,.corp.example.com,10.0.0.0/8"
export no_proxy="$NO_PROXY"

도구마다 와일드카드 해석이 조금씩 다르므로, 막히는 호스트가 나오면 해당 FQDN을 하나씩 추가해 가며 조정하는 것이 현실적입니다.

8. 영구 적용: ~/.zshrc와 새 터미널

매번 수동으로 붙여 넣기 싫다면, macOS 기본 셸인 zsh의 ~/.zshrc 하단에 export 블록을 넣습니다. 편의를 위해 함수로 감싸 두면 켜고 끄기 쉽습니다.

proxy_on() {
  export HTTP_PROXY="http://127.0.0.1:7890"
  export HTTPS_PROXY="http://127.0.0.1:7890"
  export ALL_PROXY="socks5h://127.0.0.1:7890"
  export http_proxy="$HTTP_PROXY" https_proxy="$HTTPS_PROXY" all_proxy="$ALL_PROXY"
  export NO_PROXY="localhost,127.0.0.1,::1" no_proxy="$NO_PROXY"
}
proxy_off() { unset HTTP_PROXY HTTPS_PROXY ALL_PROXY http_proxy https_proxy all_proxy NO_PROXY no_proxy; }

편집 후 source ~/.zshrc로 반영합니다. Clash를 끈 채로 proxy_on만 켜 두면 모든 CLI가 거절되므로, 사용하지 않을 때는 proxy_off로 비우는 습관이 좋습니다.

9. 자주 보는 함정: 다른 앱의 터미널, SSL, 이전 설정

VS Code·Cursor·IDEA 통합 터미널은 부모 앱이 넘긴 최소 환경으로 시작하는 경우가 있어, 독립 Terminal.app과 변수 상태가 다를 수 있습니다. 증상이 재현되지 않으면 “어느 앱의 터미널인지”를 먼저 맞춥니다.

회사 중간 인증서를 쓰는 환경에서는 프록시만으로는 TLS 검증 오류가 남을 수 있습니다. 이 글 범위를 넘는 주제이므로, 내부 CA 안내를 따르되 Clash 쪽 노드·스니이핑 설정과 혼동하지 않도록 합니다. 또한 예전에 설정해 둔 git config·npm config가 남아 있으면 새 변수와 충돌하므로, 문제가 생기면 git config --global --listnpm config list로 흔적을 정리합니다.

10. 정리

macOS에서 macOS 터미널 프록시를 안정적으로 쓰려면, GUI 시스템 프록시에만 의존하지 말고 HTTPS_PROXY·ALL_PROXY를 셸에 명시하는 것이 핵심입니다. 같은 순서로 curl로 mixed-port를 검증하고, 이어서 git 프록시·npm 프록시를 맞추면 cloneinstall이 같은 출구로 묶입니다. 컨테이너·WSL처럼 루프백이 다른 네임스페이스는 Docker 가이드·WSL2 가이드의 호스트 주소 패턴을 따르세요.

규칙 편집·로그 확인·프로필 전환을 한 화면에서 다루기에 Clash 계열 클라이언트는 CLI 출구를 맞춘 뒤에도 원인 분리가 수월한 편입니다. 비슷한 범용 프록시 도구와 비교해도, 구독·분류·연결 기록이 같이 있으면 “터미널만 이상하다”는 상황을 빠르게 좁힐 수 있습니다. → Clash를 무료로 다운로드하고 터미널 환경 변수와 함께 mixed-port 출구를 한 번에 맞춰 보세요