개발자를 위한 Clash 설정: Git·SSH·Homebrew 프록시 가이드

웹 브라우저는 정상적으로 열리는데 git clone은 멈추고, GitHub에 git push를 실행하면 타임아웃이 발생하며, brew update만 실패하는 상황이 있습니다. 이런 문제는 Clash 노드 자체보다 터미널 프로그램이 브라우저의 프록시 설정을 자동으로 사용하지 않기 때문인 경우가 많습니다. 브라우저는 Clash의 시스템 프록시를 따르지만 Git, SSH, Homebrew는 별도의 환경 변수와 연결 설정을 사용합니다.

이 글에서는 개발 환경에서 자주 사용하는 Git HTTPS, GitHub SSH, Homebrew를 Clash에 연결하는 방법을 단계별로 설명합니다. macOS, Linux, Windows의 터미널에서 공통으로 이해할 수 있도록 HTTP 프록시와 SOCKS5 프록시의 차이부터 다루고, 사내 Git 서버나 localhost 기반 개발 서비스는 계속 직접 연결하도록 예외를 구성하는 방법까지 살펴봅니다.

개발자 프로그램과 Clash의 연결 방식

Clash는 보통 로컬 포트 두 개 이상을 엽니다. HTTP 포트는 HTTP 및 HTTPS 요청을 프록시하는 데 사용되고, SOCKS5 포트는 더 다양한 TCP 연결을 전달합니다. 일반적인 기본값은 HTTP가 7890, SOCKS5가 7891이지만 Clash Verge, Clash Verge Rev, Mihomo 설정에 따라 달라질 수 있으므로 대시보드의 포트 값을 먼저 확인해야 합니다.

개발 도구에는 보통 http_proxy, https_proxy, all_proxy 환경 변수를 사용할 수 있습니다. HTTPS 요청도 프록시와의 연결 자체는 HTTP CONNECT 방식으로 처리할 수 있으므로 https_proxy에 HTTP 프록시 주소를 넣는 구성이 일반적입니다. SOCKS5를 사용할 때는 DNS 조회까지 프록시에서 처리하는 socks5h 형식을 지원하는지 확인하세요. 단순한 socks5는 DNS가 로컬에서 처리되어 연결 오류나 DNS 노출이 발생할 수 있습니다.

터미널에 프록시 환경 변수 설정하기

가장 빠른 방법은 현재 터미널 세션에 프록시 환경 변수를 설정하는 것입니다. macOS와 Linux에서 사용하는 셸이 Zsh 또는 Bash라면 다음 명령을 실행할 수 있습니다. 127.0.0.1은 로컬에서 실행 중인 Clash를 의미합니다.

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:7891

# 로컬 및 사내망 주소는 프록시를 사용하지 않음
export NO_PROXY=localhost,127.0.0.1,::1,.local,.lan,10.0.0.0/8,192.168.0.0/16

일부 프로그램은 변수 이름의 대소문자를 구분하거나 소문자만 읽습니다. 호환성을 높이려면 대문자와 소문자를 함께 선언할 수 있습니다. 매번 입력하지 않으려면 Zsh의 ~/.zshrc, Bash의 ~/.bashrc에 추가한 뒤 셸을 다시 로드합니다.

cat <<'EOF' >> ~/.zshrc
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:7891
export NO_PROXY=localhost,127.0.0.1,::1,.local,.lan,10.0.0.0/8,192.168.0.0/16
EOF

source ~/.zshrc

# 현재 셸에서 프록시 변수 제거
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY
unset http_proxy https_proxy all_proxy no_proxy

Windows PowerShell에서는 $env: 형식을 사용합니다. 다만 Windows용 Clash 클라이언트가 시스템 프록시를 활성화했다고 해서 모든 터미널 프로그램이 자동으로 이를 따르는 것은 아닙니다. 따라서 명령줄 작업을 시작하기 전에 해당 세션에 환경 변수를 명시하는 편이 문제를 재현하고 진단하기 쉽습니다.

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:ALL_PROXY = "socks5h://127.0.0.1:7891"
$env:NO_PROXY = "localhost,127.0.0.1,.local,.lan"

# 현재 세션에서 해제
Remove-Item Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY,Env:NO_PROXY

Git HTTPS clone과 push 설정

원격 저장소 주소가 https://github.com/... 형태라면 Git은 HTTP 기반으로 통신합니다. 환경 변수만 설정해도 동작하지만, Git에만 프록시를 적용하고 다른 터미널 프로그램에는 영향을 주고 싶지 않다면 전역 Git 설정을 사용하는 편이 좋습니다.

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

# 설정 확인
git config --global --get http.proxy
git config --global --get https.proxy

# Git 프록시 설정 제거
git config --global --unset http.proxy
git config --global --unset https.proxy

GitHub가 아닌 사내 Git 서버만 직접 연결하려면 전체 Git에 전역 프록시를 적용하지 말고 호스트별 설정을 사용하는 것이 안전합니다. 예를 들어 외부 GitHub 트래픽은 Clash를 통과시키고 사내 서버는 직접 연결할 수 있습니다.

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

# 사내 Git 서버는 직접 연결
git config --global http.https://git.intra.example.com.proxy ""
git config --global https.https://git.intra.example.com.proxy ""

설정 후에는 작은 저장소로 연결을 확인하세요. GIT_CURL_VERBOSE=1을 사용하면 Git이 프록시 주소로 연결하는지, TLS 협상이 어느 단계에서 실패하는지 확인할 수 있습니다. 인증 오류가 발생하면 프록시 문제가 아니라 토큰, 자격 증명 관리자 또는 저장소 권한 문제일 가능성이 높습니다.

GIT_CURL_VERBOSE=1 git ls-remote https://github.com/example/project.git

git clone https://github.com/example/project.git
git push origin main

GitHub SSH 접속을 Clash에 연결하기

[email protected]:owner/repository.git 형태의 주소는 HTTPS 프록시 설정을 사용하지 않습니다. SSH는 일반적으로 22번 포트에 직접 연결하므로, 브라우저와 Git HTTPS가 정상이어도 SSH만 타임아웃될 수 있습니다. 이때는 SSH가 연결을 생성할 때 Clash SOCKS5 포트를 사용하도록 ProxyCommand를 지정해야 합니다.

macOS와 Linux에서는 먼저 시스템에 SOCKS5를 지원하는 연결 도구가 있는지 확인합니다. OpenSSH에 포함된 nc가 SOCKS 옵션을 지원하면 다음과 같이 사용할 수 있습니다. 배포판이나 macOS 버전에 따라 옵션 이름이 다를 수 있으므로 실제 명령으로 테스트해야 합니다.

mkdir -p ~/.ssh
chmod 700 ~/.ssh

cat <<'EOF' >> ~/.ssh/config
Host github.com
    HostName github.com
    User git
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    ProxyCommand nc -x 127.0.0.1:7891 -X 5 %h %p
EOF

chmod 600 ~/.ssh/config

nc -x를 지원하지 않는 환경에서는 Ncat, connect-proxy 또는 다른 SOCKS5 지원 도구를 설치해 ProxyCommand에 지정할 수 있습니다. Windows에서는 Windows용 OpenSSH와 함께 설치된 도구의 문법이 다를 수 있으므로, 먼저 ssh -vT [email protected]로 실제 오류를 확인하는 것이 좋습니다. SSH 키 자체가 아직 없다면 프록시 설정과 키 생성은 별도의 단계라는 점도 기억하세요.

ssh -T [email protected]

# 상세 로그 확인
ssh -vT [email protected]

# 저장소 주소 확인 및 SSH clone
git remote -v
git clone [email protected]:example/project.git

Homebrew 업데이트와 패키지 설치

Homebrew는 저장소 메타데이터를 Git으로 가져오고, bottle과 소스 파일은 별도의 HTTPS 요청으로 다운로드합니다. 따라서 Git 프록시만 설정하면 brew update는 되지만 패키지 설치가 실패할 수 있고, 반대로 환경 변수만 설정하면 특정 Git 작업이 다른 설정을 사용할 수도 있습니다. Homebrew를 실행하는 셸에 HTTP와 HTTPS 프록시를 모두 지정하는 것이 기본적인 해결 방법입니다.

export HOMEBREW_NO_AUTO_UPDATE=1
export HOMEBREW_BOTTLE_DOMAIN=""
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:7891

brew update
brew install wget
brew upgrade

HOMEBREW_NO_AUTO_UPDATE=1은 명령을 실행할 때마다 자동 업데이트하지 않도록 하는 선택 사항입니다. 업데이트 자체를 영구적으로 끄는 설정은 아니며, CI 환경이나 반복적인 설치 작업에서 불필요한 대기 시간을 줄일 때 유용합니다. 특정 미러를 사용하는 HOMEBREW_BOTTLE_DOMAIN 설정이 기존에 있다면 프록시와 충돌할 수 있으므로, 문제를 진단하는 동안에는 값을 확인하거나 임시로 제거하세요.

Homebrew가 프록시를 통과하는지 확인하려면 verbose 출력과 환경 변수를 함께 확인합니다. 오류가 Could not resolve host라면 DNS 또는 SOCKS 형식 문제일 수 있고, Connection refused라면 Clash 포트 또는 Clash 프로세스가 실행 중인지 확인해야 합니다.

env | grep -i proxy
brew config
brew update --verbose
curl -I https://github.com

사내망과 로컬 서비스를 직접 연결하기

개발 환경에서 모든 트래픽을 프록시로 보내는 것은 편리하지만 항상 올바른 선택은 아닙니다. 사내 GitLab, 내부 패키지 저장소, 데이터베이스, Kubernetes API, 로컬 Docker 서비스는 프록시를 거치면 인증이 실패하거나 접근이 차단될 수 있습니다. 또한 localhost와 사설 IP를 프록시로 보내면 불필요한 지연이 생깁니다.

첫 번째 방어선은 셸의 NO_PROXY입니다. 도메인 접미사와 IP 대역을 환경에 맞게 추가하세요. 쉼표로 구분하며, 사용하는 도구에 따라 CIDR 처리를 지원하지 않을 수 있으므로 중요한 내부 호스트는 정확한 이름을 함께 적는 편이 안전합니다.

export NO_PROXY=localhost,127.0.0.1,::1
export NO_PROXY="$NO_PROXY,.local,.lan,.corp"
export NO_PROXY="$NO_PROXY,git.intra.example.com,registry.intra.example.com"
export NO_PROXY="$NO_PROXY,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"

두 번째는 Clash 규칙입니다. 사내 도메인과 로컬 네트워크를 DIRECT로 보내고 나머지 개발 관련 외부 서비스만 프록시 그룹으로 라우팅합니다. 규칙의 순서가 중요합니다. 더 구체적인 내부 도메인과 IP 규칙을 일반적인 프록시 규칙보다 앞에 배치해야 합니다.

rules:
  - DOMAIN-SUFFIX,intra.example.com,DIRECT
  - DOMAIN,registry.intra.example.com,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY
  - MATCH,DIRECT

사내망 주소가 공용 도메인과 같은 DNS 이름을 사용하거나, fake-ip 모드에서 내부 서비스가 정상적으로 동작하지 않는다면 해당 도메인을 fake-ip-filter에 추가하는 방법도 고려할 수 있습니다. 단, 무조건 모든 사내 도메인을 제외하기보다 실제로 문제가 발생하는 서비스부터 추가하고, DNS 누출과 연결 경로를 함께 점검하세요.

문제 발생 시 단계별 점검

Git이나 Homebrew가 실패할 때 설정을 한꺼번에 바꾸면 원인을 찾기 어렵습니다. 다음 순서로 범위를 좁히면 대부분의 문제를 빠르게 분리할 수 있습니다.

1. Clash가 실행 중인지 확인하고 대시보드에서 HTTP·SOCKS5 포트가 실제 설정과 일치하는지 확인합니다.
2. curl -I https://github.com으로 현재 셸의 HTTP 프록시 연결을 테스트합니다.
3. env | grep -i proxy로 잘못된 이전 프록시 변수나 대소문자 중복 설정을 확인합니다.
4. Git HTTPS는 git config --show-origin --get-regexp 'http.*proxy|https.*proxy'로 설정 출처를 확인합니다.
5. GitHub SSH는 ssh -vT [email protected]으로 ProxyCommand 실행 여부와 키 인증 단계를 확인합니다.
6. 사내 서비스가 실패하면 NO_PROXY와 Clash의 DIRECT 규칙이 모두 해당 호스트를 포함하는지 확인합니다.
7. 노드 변경 후에는 기존 터미널 세션을 다시 열거나 환경 변수를 다시 적용해 오래된 설정을 제거합니다.

특히 403이나 401은 대개 프록시 연결 실패가 아니라 인증 또는 권한 문제입니다. 반대로 connection refused는 로컬 포트에 서비스가 없다는 뜻이고, timeout은 노드 상태, 라우팅 규칙, 원격 포트 차단, SSH의 22번 포트 제한 등을 의심해야 합니다. 오류 메시지를 유형별로 나누면 불필요하게 Clash 설정 전체를 교체하는 일을 피할 수 있습니다.

정리하면 브라우저가 정상이라는 사실만으로 터미널의 Git·SSH·Homebrew도 자동으로 정상 동작하는 것은 아닙니다. Clash의 로컬 포트를 확인한 뒤 환경 변수, Git 호스트별 설정, SSH의 ProxyCommand, Homebrew 다운로드 경로를 각각 연결해야 합니다. 마지막으로 NO_PROXY와 Clash의 DIRECT 규칙을 구성하면 외부 개발 리소스는 안정적으로 다운로드하면서 사내 시스템과 로컬 개발 서비스는 기존 경로 그대로 사용할 수 있습니다.