개발자 Clash 설정 가이드: Git·SSH·Homebrew 프록시 연결 한 번에 해결

브라우저는 되는데 Git·SSH·Homebrew는 실패하는 이유

브라우저에서 GitHub 페이지가 열린다고 해서 터미널의 Git, SSH, Homebrew도 같은 경로로 통신하는 것은 아닙니다. 브라우저는 운영체제의 시스템 프록시 설정을 자동으로 따르는 경우가 많지만, 터미널 프로그램은 셸 환경 변수나 자체 네트워크 라이브러리 설정을 따로 확인합니다. 따라서 Clash에서 시스템 프록시를 켰는데도 git clone은 멈추거나, 원격 서버 SSH 접속만 시간 초과가 나는 상황이 생길 수 있습니다.

세 도구가 사용하는 통신 방식도 서로 다릅니다. Git은 저장소 주소가 https://인지 git@ 형식인지에 따라 HTTP 프록시 또는 SSH 설정을 사용합니다. SSH는 일반적으로 시스템 HTTP 프록시 설정을 읽지 않으며, Homebrew는 저장소와 패키지 다운로드 과정에서 Git과 curl을 함께 호출할 수 있습니다. 한 단계는 성공하고 다음 단계에서 멈춘다면, “Clash가 연결되지 않았다”고 단정하기보다 어떤 프로그램이 어느 호스트에 접속했는지 나눠 확인해야 합니다.

이 가이드는 macOS 개발 환경에서 Clash의 혼합 포트나 SOCKS 포트를 사용해 각 경로를 연결하는 방법을 설명합니다. 메뉴 이름과 포트 번호는 Clash Verge, Clash Verge Rev, Mihomo 등 클라이언트의 설정에 따라 다를 수 있으므로 예시 값을 그대로 복사하기 전에 실제 화면에서 확인하세요. 회사나 학교 네트워크에서 프록시 사용이 제한되어 있다면 조직의 정책과 허용된 접속 방법을 우선 따릅니다.

먼저 선택하기: TUN 모드와 앱별 프록시

설정을 시작하기 전에 터미널 트래픽을 처리할 방식을 하나 정하면 문제를 좁히기 쉽습니다. TUN 모드는 가상 네트워크 인터페이스를 통해 시스템의 IP 트래픽을 처리하므로, 프록시 환경 변수를 지원하지 않는 프로그램까지 포함해 여러 앱을 함께 연결할 때 편리합니다. 반면 앱별 설정은 Git이나 Homebrew처럼 환경 변수를 지원하는 프로그램에만 프록시를 적용할 수 있어, 어떤 도구가 프록시를 쓰는지 관리하기 쉽습니다.

개발 도구만 연결하려면 우선 혼합 포트 또는 SOCKS 포트를 앱에 지정하고, Clash 로그에서 해당 연결이 실제로 나타나는지 확인하는 방식을 권합니다. 모든 트래픽을 TUN으로 보내려는 경우에는 앱별 프록시 변수를 동시에 추가하지 말고, 먼저 TUN만 켜서 동작을 검증하세요. 로컬 프록시 포트에 연결한 트래픽까지 TUN이 다시 가로채면 설정에 따라 중복 경로나 루프가 생길 수 있기 때문입니다.

반대로 TUN 권한을 사용할 수 없거나 회사 장비에서 가상 인터페이스 설치가 허용되지 않는다면, 앱별 설정이 현실적인 대안입니다. Clash의 시스템 프록시 기능만 켠 상태로는 터미널 앱이 이를 따르지 않을 수 있으므로, 셸 환경 변수나 Git 설정을 추가해야 합니다. 두 방식을 섞어 쓰고 싶다면 먼저 하나씩 검증한 뒤 필요한 앱에만 다른 경로를 적용하세요.

• TUN 모드: 여러 프로그램을 한 번에 연결하기 좋지만, 권한·라우팅·DNS 상태를 함께 확인해야 합니다.
• 환경 변수: 대상 프로그램을 명시할 수 있지만, 새 터미널과 IDE가 변수 값을 상속하는지 확인해야 합니다.
• Git 전용 설정: HTTPS 저장소에 적용하기 쉽고 범위를 좁힐 수 있지만, SSH 주소에는 같은 설정이 적용되지 않습니다.

Git HTTPS 저장소에 프록시 적용하고 확인하기

먼저 저장소 주소를 확인합니다. git remote -v 결과가 https://로 시작한다면 Git의 HTTP 전송 설정이나 환경 변수를 사용할 수 있습니다. Clash 혼합 포트가 실제로 HTTP 프록시 요청을 받도록 설정되어 있는지 확인한 뒤, 현재 셸에서 다음과 같이 지정해 테스트합니다.

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"
git ls-remote https://github.com/OWNER/REPOSITORY.git

git ls-remote는 저장소를 통째로 내려받지 않고 원격 참조를 조회하므로, 프록시 경로를 가볍게 점검하기 좋습니다. 명령이 성공하면 이어서 실제 git clone을 시도합니다. 실패할 때는 터미널에 표시된 오류만 보지 말고 Clash 연결 로그에서 GitHub 호스트가 나타났는지, 어떤 규칙과 정책 그룹에 매칭됐는지 확인하세요. 로그에 요청이 전혀 없으면 환경 변수가 셸에 전달되지 않았거나, 연결이 다른 네트워크 경로를 사용하고 있을 가능성이 있습니다.

환경 변수를 매번 입력하고 싶지 않다면 Git에 프록시를 지정할 수도 있습니다. 이는 Git의 HTTP(S) 전송에 대한 설정이며 SSH 방식의 저장소에는 적용되지 않습니다. 프록시 주소를 전역 설정에 저장하면 이후 다른 네트워크에서도 해당 설정이 남으므로, 공용 환경을 오가는 노트북에서는 임시 환경 변수나 별도 포함 설정을 우선 고려하세요.

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

더 이상 필요하지 않을 때는 설정 값을 지우고, 프록시 주소가 예상한 값으로 해석되는지 다시 확인합니다. Git의 디버그 출력이나 환경 변수에는 내부 프록시 주소, 인증 정보가 포함될 수 있으므로 로그를 공유하기 전에 민감한 값을 가리세요.

git config --global --unset http.proxy
git config --global --unset https.proxy
env | grep -i proxy

Git SSH와 원격 서버에 ProxyCommand 설정하기

주소가 [email protected]:OWNER/REPOSITORY.git처럼 SSH 형식이라면 HTTPS 프록시 설정만으로는 해결되지 않습니다. SSH 클라이언트는 자체 설정 파일인 ~/.ssh/config를 읽으며, Clash의 SOCKS 포트에 연결하려면 SSH의 ProxyCommand를 명시할 수 있습니다. 아래 예시는 macOS에 포함된 nc가 SOCKS5 프록시 옵션을 지원하는 환경을 전제로 합니다. 사용 중인 nc가 옵션을 인식하지 못하면 설치된 netcat 구현의 도움말을 확인하거나, TUN 모드로 경로를 처리하는 방법을 검토하세요.

Host github.com
    HostName github.com
    User git
    ProxyCommand nc -X 5 -x 127.0.0.1:7891 %h %p

파일에 설정을 추가한 뒤에는 ssh -T [email protected]으로 인증 경로를 확인합니다. GitHub는 인증 성공 시 셸을 제공하지 않는다고 안내할 수 있으므로, 셸이 열리지 않는다는 사실만으로 실패라고 판단하지 마세요. 중요한 것은 SSH 키 인증이 통과했는지와 Clash 로그에 해당 연결이 기록됐는지입니다. 처음부터 GitHub에서만 시험하고, 성공한 다음 원격 서버 설정을 추가하면 변수 수를 줄일 수 있습니다.

일반 서버도 같은 방식으로 설정할 수 있지만, 호스트별 항목을 구분해 두는 편이 안전합니다. 다음과 같이 별도의 별칭을 만들면 접속 명령은 간단해지고, GitHub용 규칙을 다른 SSH 서버에 잘못 적용하는 일을 줄일 수 있습니다.

Host dev-server
    HostName server.example.net
    User developer
    Port 22
    ProxyCommand nc -X 5 -x 127.0.0.1:7891 %h %p

이후 ssh dev-server로 연결합니다. 서버의 실제 포트가 22가 아니면 Port 값을 맞춰야 하고, 원격 서버가 프록시를 통한 접속을 허용하는지도 확인해야 합니다. 연결이 멈추면 Clash가 SOCKS 연결을 받는지, 호스트 이름과 포트가 정확한지, SSH 키 및 서버 측 접근 정책이 정상인지 순서대로 살펴보세요. 인증 실패와 네트워크 시간 초과는 원인이 다르므로, 둘을 구분하면 불필요한 노드 변경을 줄일 수 있습니다.

Homebrew 다운로드와 Git 작업을 함께 점검하기

Homebrew 명령 하나가 여러 통신을 유발할 수 있습니다. 저장소 메타데이터를 갱신하는 Git 요청과 패키지 파일을 받는 다운로드 요청은 서로 다른 호스트를 사용할 수 있어, 저장소 업데이트만 성공했다고 설치 경로까지 정상이라고 볼 수 없습니다. 또한 Homebrew가 실행되는 터미널이 어떤 환경 변수를 상속하는지도 중요합니다. 먼저 현재 셸에서 프록시 변수를 설정하고, 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
brew update

여기서 ALL_PROXY의 socks5h 표기는 SOCKS5 프록시를 사용하고 호스트 이름 해석도 프록시 쪽에서 처리하도록 요청하는 형식입니다. 프로그램마다 지원하는 프록시 변수와 대소문자 처리가 다를 수 있으므로, 변수를 선언했다는 사실만으로 Homebrew가 반드시 사용한다고 가정하지 마세요. brew update가 실패하면 오류에 표시된 호스트를 기록하고, 같은 시각의 Clash 로그에서 DNS 실패, 연결 거부, 시간 초과 중 어떤 상태인지 살펴봅니다.

설치 파일을 받는 단계에서만 실패한다면 저장소 자체보다 다운로드 호스트나 CDN 경로가 원인일 수 있습니다. 규칙을 무작정 넓혀 모든 관련 도메인을 프록시로 보내기보다, 실제 로그에 나타난 호스트와 기존 정책을 확인한 뒤 필요한 범위만 조정하세요. 규칙을 바꾼 후에는 프로필을 다시 적용하고, 이전 연결 세션이 남아 있지 않도록 새 터미널에서 동일한 명령을 반복합니다.

환경 변수를 셸 시작 파일에 영구 저장할 때는 사용 중인 셸이 zsh인지 bash인지 먼저 확인합니다. macOS 기본 셸 구성과 IDE 내장 터미널의 시작 방식이 다를 수 있어, 터미널 앱에서는 작동하지만 IDE에서만 실패하는 경우도 있습니다. 영구 설정 전에 현재 세션에서 시험하고, 적용한 뒤에는 새 창을 열어 env 출력과 Clash 로그를 다시 비교하세요. 공용 기기나 여러 네트워크를 오가는 환경이라면 프록시 변수를 필요할 때만 켜고 종료 시 해제하는 편이 관리하기 쉽습니다.

연결 실패를 좁히는 순서와 운영 팁

우선 실패 지점을 재현 가능한 한 가지 명령으로 고정합니다. HTTPS Git이라면 원격 참조 조회, SSH라면 인증 테스트, Homebrew라면 업데이트나 대상 패키지의 설치를 따로 실행하세요. 각 테스트 직후 Clash 연결 로그에서 도메인과 정책 그룹을 확인합니다. 한 도구의 서로 다른 요청이 모두 같은 경로를 써야 한다고 단정할 필요는 없지만, 어떤 요청이 DIRECT로 나가고 어떤 요청이 프록시로 가는지는 의도와 일치해야 합니다.

• 로그에 연결이 없음: 환경 변수가 새 셸에 전달됐는지, SSH가 올바른 설정 파일을 읽는지, TUN 또는 시스템 프록시가 의도한 상태인지 확인합니다.
• 연결 거부: Clash가 실행 중인지, 지정한 포트가 실제 HTTP 또는 SOCKS 포트인지 확인합니다. 포트가 비활성화됐거나 다른 프로세스가 사용 중일 수 있습니다.
• DNS 오류: 프록시 방식과 이름 해석 위치가 맞는지, Clash DNS 설정과 현재 네트워크의 DNS 응답이 충돌하지 않는지 살펴봅니다.
• 인증 오류: Git HTTPS 자격 증명, SSH 키, 서버 접근 권한을 네트워크 문제와 분리해 점검합니다. 프록시 노드를 바꿔도 키 권한 오류는 해결되지 않습니다.
• 특정 다운로드만 실패: 로그에 기록된 실제 다운로드 호스트를 확인하고, 저장소 도메인만으로 CDN 요청까지 설명할 수 있는지 검토합니다.

설정이 정상화되면 임시로 넣은 전역 Git 프록시나 셸 변수를 정리하고, 팀 프로젝트에는 개인 장비의 로컬 포트나 인증 값을 커밋하지 않습니다. 공유해야 할 것은 “HTTPS Git은 혼합 포트”, “SSH는 별도 ProxyCommand”, “Homebrew는 셸 환경 변수와 로그로 검증” 같은 원칙과 재현 절차입니다. 이렇게 기록해 두면 새 컴퓨터를 설정하거나 Clash 프로필을 바꿀 때도 전체 연결을 처음부터 추측하지 않아도 됩니다.

일부 GUI 클라이언트는 시스템 프록시만 설정해 터미널 도구까지 자동으로 연결될 것처럼 보이지만, Git SSH의 별도 설정이나 Homebrew 다운로드 경로까지 알아서 맞춰 주지는 않습니다. 반대로 환경 변수만 설정하는 방법은 앱마다 상속 여부를 확인해야 하고, TUN 모드는 권한과 라우팅 상태까지 관리해야 합니다. Clash V.CORE를 사용하면 개발 도구의 프록시 경로를 하나의 클라이언트에서 확인하고, 연결 로그와 정책을 함께 점검해 이런 차이를 분리하기 좋습니다. Git·SSH·Homebrew의 실패 원인을 직접 확인하며 설정을 정리하려면 다운로드로 이동해 사용 중인 환경에 맞는 Clash V.CORE를 살펴보세요.