어떤 증상을 말하는가

macOS에서 Clash 클라이언트를 실행하고 노드를 선택한 뒤 「시스템 프록시(System Proxy)」까지 켜 두었는데도, Safari나 Chrome으로 열어본 IP 확인 페이지에서는 노드의 위치가 나오는데, 터미널에서 curl로 같은 사이트를 찍어 보면 여전히 집 회선(또는 기대와 다른 출구)으로 보이는 경우가 있습니다. 이어서 git clone이나 git pull이 느리거나 실패하고, brew update가 GitHub·병합 소스에 닿지 못하는 패턴도 자주 나옵니다.

이런 현상은 「구독이 잘못됐다」거나 「규칙만 틀렸다」고 단정하기 전에, CLI 프로그램이 애초에 Clash가 리슨하는 로컬 프록시 포트까지 트래픽을 보내고 있는지를 먼저 가려야 합니다. macOS에서는 브라우저가 시스템 프록시 설정을 읽는 방식과, 터미널 세션이 http_proxy 같은 환경 변수를 읽는 방식이 완전히 분리되어 있어, 한쪽만 맞춰 두면 나머지 한쪽이 빠져나가는 형태가 흔합니다. 이 글에서는 그때마다 어떤 순서로 포트를 확인하고, 어떤 변수를 내보내면 되는지 Clash macOS 터미널 프록시 관련 검색으로 이 페이지를 찾은 분도 바로 따라 할 수 있게 정리했습니다.

시스템 프록시와 셸 환경 변수는 왜 따로인가

Clash가 제공하는 「시스템 프록시」는 macOS의 네트워크 설정에 「HTTP/HTTPS 트래픽은 이 주소의 프록시로 보내라」라고 등록해 주는 동작에 가깝습니다. 그러나 대부분의 GUI 앱과 Chromium 기반 브라우저는 이 설정을 잘 따르지만, 터미널에서 돌아가는 도구는 기본적으로 그 설정을 자동으로 물려받지 않습니다. 대신 http_proxy·https_proxy·all_proxy 같은 표준 환경 변수를 읽는 프로그램이 많고, git·curl·많은 언어 런타임의 패키지 매니저가 이 경로를 탑니다.

따라서 시스템 프록시는 켜져 있어도 터미널·Homebrew가 직접 연결처럼 보이는 것은 오류라기보다, 설계상 기대되는 동작에 가깝습니다. 해결은 「Clash가 실제로 열어 둔 로컬 포트(예: HTTP 7890, SOCKS 7891)와 동일한 값을 환경 변수에 넣는 것」으로 정리할 수 있습니다. 반대로 말하면, 브라우저만 쓸 거라면 시스템 프록시만으로도 충분한 경우가 많고, 개발·CLI까지 한 번에 맞추려면 셸 설정을 추가하거나, 아래에서 설명하는 TUN 모드처럼 커널 쪽에서 트래픽을 가로채는 방식을 검토해야 합니다.

ℹ️
참고: 모든 TCP·UDP를 Clash 규칙으로 모으려면 TUN이 유효하지만, 권한·다른 VPN과의 충돌을 고려해야 합니다. 우선은 본문의 순서대로 시스템 프록시와 셸 변수만 점검하는 편이 부담이 적습니다. TUN 개요는 TUN 모드 가이드를 함께 참고하세요.

1단계: Clash에서 로컬 포트 번호 확인

환경 변수에 넣을 주소는 항상 127.0.0.1 또는 localhost에 붙는 클라이언트가 표시하는 포트와 일치해야 합니다. 일반적으로 Clash 계열은 HTTP 프록시와 SOCKS를 각각 다른 포트로 열거나, mixed 포트 하나에 묶어 두기도 합니다. 설정 화면에서 「포트」「HTTP Port」「Mixed Port」「SOCKS Port」 등의 항목을 확인하고, 아래 예시에서 사용할 숫자를 메모해 두세요.

가장 흔한 조합은 HTTP(또는 mixed)가 7890, SOCKS가 7891인 경우입니다. 다만 사용자가 바꿔 두었을 수 있으므로 반드시 본인 화면의 값을 따릅니다. 이후 단계에서 http_proxy에는 보통 http://127.0.0.1:HTTP포트 형식을 쓰고, SOCKS5를 쓰려면 all_proxy에 socks5://127.0.0.1:SOCKS포트를 지정하는 식으로 맞춥니다. HTTP와 SOCKS 중 무엇을 쓸지는 도구마다 다르므로, 우선 HTTP 프록시 포트로 통일해 curl부터 검증하는 편이 재현성이 좋습니다. Clash 클라이언트 설치·구독 반영 절차는 설치·기본 설정 문서와 맞춰 두면 이후 포트 확인이 수월합니다.

2단계: 현재 셸에 http_proxy·https_proxy 내보내기

터미널을 연 상태에서, 아래에서 7890을 실제 HTTP(또는 mixed) 포트로 바꿔 실행합니다. zsh 기준 예시입니다.

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"

여러 도구는 대문자·소문자 변수를 모두 보므로 위처럼 둘 다 맞춰 두면 호환성이 좋아집니다. SOCKS만 쓰는 환경이라면 예를 들어 다음과 같이 설정할 수 있습니다(포트는 본인 SOCKS 포트로).

export all_proxy="socks5://127.0.0.1:7891"
export ALL_PROXY="$all_proxy"

일부 스택은 https_proxy에 socks5://를 허용하지 않거나, 반대로 SOCKS만 안정적으로 읽는 경우가 있어, 우선 HTTP 프록시 포트로 통일한 뒤 필요 최소한으로 SOCKS를 추가하는 방식을 권장합니다. 이 설정은 현재 터미널 세션에만 적용되며, 새 창을 열면 초기화됩니다. 영구 적용은 뒤의 ~/.zshrc 절에서 다룹니다.

3단계: curl로 실측 검증

프록시가 실제로 타는지 확인하려면, 외부에서 출구 IP를 알려 주는 HTTPS 엔드포인트에 curl을 걸어 봅니다. 프록시가 없으면 집 회선 IP가 나오고, Clash 노드를 타면 해당 노드 지역의 IP가 나와야 합니다.

curl -sS https://api.ipify.org
echo
curl -sS https://ifconfig.me/ip

여기서도 여전히 집 IP가 나온다면, (1) 환경 변수가 비어 있거나 (2) curl이 프록시를 무시하는 옵션이 붙어 있거나 (3) Clash 포트가 다르거나 (4) 클라이언트가 꺼져 있는지를 순서대로 의심합니다. echo $http_proxy로 값이 출력되는지 먼저 확인하세요. 또한 curl -v https://example.com로 연결이 127.0.0.1 쪽으로 프록시되는지 로그를 보면 원인 분리가 빨라집니다.

이 단계가 통과하면 터미널 기반의 많은 도구도 같은 세션에서는 동일한 출구를 쓰게 됩니다. 여기서 말하는 검증 흐름이 바로 http_proxy·https_proxy 키워드로 검색해 들어온 사용자에게 필요한 「실측」 단계입니다.

4단계: git 전용 프록시(선택)

환경 변수만으로도 git은 HTTPS를 Clash로 보내는 경우가 많지만, HTTP/HTTPS 프록시와 SOCKS를 다르게 쓰고 싶거나 레포지토리별로 고정하고 싶다면 git config를 사용할 수 있습니다.

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

SSH로 [email protected]:... 형식만 쓴다면 환경 변수의 HTTP 프록시와는 별개로 SSH 자체가 직접 연결될 수 있습니다. 그 경우는 SSH 설정(~/.ssh/config)에서 ProxyCommand로 nc·socat 등을 붙이거나, HTTPS 원격으로 전환하는 등의 선택지가 필요합니다. 이 글의 범위는 HTTPS 원격 + HTTP 프록시에 맞춰 두었습니다.

5단계: Homebrew(brew)와 프록시

Homebrew 프록시는 위에서 내보낸 http_proxy·https_proxy를 상속하는 경우가 많습니다. 즉, 같은 터미널 세션에서 변수를 설정한 뒤 brew update를 실행하면 GitHub·병합 소스 접근이 Clash 쪽으로 나가는지 관찰할 수 있습니다.

환경 변수 외에 Homebrew 자체가 쓰는 보조 변수로 HOMEBREW_PIP_INDEX_URL 등이 필요한 경우가 있으나, 일반적인 업데이트·설치 실패는 먼저 프록시 미설정이나 DNS가 원인인 경우가 많습니다. brew가 여전히 직결처럼 보이면, brew update -v로 어느 URL에 붙는지 로그를 확인하고, 동시에 Clash 쪽 연결 로그에서 해당 요청이 잡히는지 비교해 보세요.

⚠️
주의: 회사·학교 보안 정책으로 시스템에 맞춤 신뢰 저장소나 SSL 검사가 걸려 있으면, 프록시를 타도 brew가 인증서 오류로 멈출 수 있습니다. 그때는 IT 정책을 벗어나지 않는 범위에서 대응해야 합니다.

6단계: proxy on/off 함수로 편하게 쓰기

매번 export를 치기 번거롭다면, zsh에 짧은 함수를 두고 토글하는 방식이 자주 쓰입니다. 아래는 예시이며, 포트는 본인 환경에 맞게 바꿉니다.

proxy_on() {
  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"
  echo "proxy on"
}
proxy_off() {
  unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY all_proxy ALL_PROXY
  echo "proxy off"
}

작업이 끝나면 proxy_off로 빠져 나와 로컬망·사내망에 불필요한 트래픽이 프록시를 타지 않게 하는 습관이 좋습니다. 특히 사내 Git·패키지 미러는 NO_PROXY로 빼 두는 것이 안전합니다.

7단계: ~/.zshrc에 영구 반영할 때

매 세션 자동 적용을 원하면 위 export 또는 proxy_on 정의를 ~/.zshrc 끝에 넣고 source ~/.zshrc합니다. 다만 항상 Clash가 켜져 있지 않은 PC에서는 터미널을 열 때마다 실패하는 스크립트가 붙는 것을 피하기 위해, 자동 실행 대신 함수만 정의해 두고 필요할 때 proxy_on을 호출하는 방식을 권장합니다.

또한 VS Code·Cursor 터미널·iTerm2·Terminal.app마다 로그인 셸이 다르게 뜰 수 있어, bash를 쓰는 경우에는 ~/.bash_profile 또는 ~/.bashrc에 동일한 내용을 맞춰야 합니다. GUI 앱에서 실행되는 스크립트는 환경 변수를 물려받지 못하는 경우가 있어, 그 경우 해당 앱에서만 별도 설정이 필요합니다.

8단계: NO_PROXY로 예외 도메인·IP 빼기

프록시를 켠 상태에서도 사내망·로컬호스트·특정 레지스트리는 직접 연결해야 할 때가 있습니다. NO_PROXY(또는 no_proxy)에 쉼표로 구분해 도메인 접미사나 IP를 넣습니다.

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

이렇게 해 두면 해당 호스트에 대한 요청은 Clash를 거치지 않고 직접 가므로, 지연·인증서 문제를 줄일 수 있습니다. 목록이 길어지면 관리가 어려워지므로, 필요한 최소한만 유지하는 것이 좋습니다.

9단계: 그래도 CLI가 빠져나간다면 TUN·규칙 점검

환경 변수를 모두 맞춰도 특정 바이너리만 프록시를 무시한다면, 그 프로그램이 자체 프록시 설정을 갖고 있거나, Clash 규칙 모드에서 해당 트래픽이 DIRECT로 빠지는지를 봐야 합니다. 클라이언트의 연결 로그를 잠시 켜 두고, 해당 도메인이 어떤 규칙에 매칭되는지 확인하면 원인 분리가 빨라집니다.

브라우저와 무관하게 시스템 전체를 한 경로로 모으고 싶다면 TUN 모드를 검토합니다. 권한과 다른 VPN·보안 소프트웨어와의 상호작용을 신경 써야 하므로, 가이드의 주의 사항을 읽은 뒤 켜는 것이 안전합니다. 규칙 기반 분할이 필요하면 규칙 분류 설정 글과 조합해 보세요.

한눈에 보는 점검 순서

  1. Clash에서 HTTP(또는 mixed)·SOCKS 포트 번호를 확인한다.
  2. 터미널에 http_proxy·https_proxy(및 대문자)를 127.0.0.1:포트로 내보낸다.
  3. curl로 출구 IP가 노드와 일치하는지 확인한다.
  4. 필요하면 git config로 HTTP 프록시를 고정한다.
  5. 같은 세션에서 brew update 등을 시험하고, NO_PROXY로 예외를 정리한다.
  6. 여전히 특정 앱만 직행이면 규칙 로그와 TUN 필요 여부를 본다.
✅
팁: 증상을 기록할 때 「어떤 터미널 앱」「프록시 변수 on/off 시 curl 결과 차이」를 짧게 메모해 두면, 이후 규칙을 손볼 때 큰 도움이 됩니다.

맺음말

Clash macOS 터미널 프록시 문제는, 구독 품질 이전에 「CLI가 로컬 프록시 포트를 실제로 쓰고 있는가」를 확인하는 것이 첫 단추입니다. 브라우저는 시스템 프록시를 따르지만, 터미널은 http_proxy·https_proxy 등을 명시해야 하는 경우가 많고, Homebrew 프록시도 같은 원리로 상속됩니다. 위 순서대로 좁혀 가면 대부분 재현 가능한 원인에 도달할 수 있습니다.

Clash 계열 클라이언트는 GUI에서 시스템 프록시와 코어 로그를 한 화면에서 다룰 수 있어, 포트·규칙·프록시 토글을 반복 실험하기에도 편합니다. 다른 도구에 비해 설정이 한곳에 모이는 편이라 일상적인 끊김을 줄이는 데 유리합니다. 최신 빌드와 설치 패키지는 Clash 공식 다운로드 페이지에서 받을 수 있습니다. → Clash를 무료로 내려받아 macOS 환경에서 터미널·Homebrew까지 한 번에 점검해 보세요.