개발자 환경에서 Clash 프록시를 먼저 분리해야 하는 이유

개발 업무에서 프록시 문제는 브라우저가 열리는지만으로 판단하기 어렵습니다. 브라우저는 운영체제의 시스템 프록시를 자동으로 상속하지만, Git, SSH, Homebrew, npm, pip는 각자 다른 설정 파일과 환경 변수를 읽습니다. 따라서 웹 페이지는 정상적으로 열리는데 git clone만 멈추거나, GitHub 저장소는 받아지지만 brew install에서 다운로드가 끊기는 상황이 생깁니다. Clash의 노드 자체가 고장 난 것이 아니라 도구별로 서로 다른 출구를 사용하고 있는 경우가 많습니다.

가장 먼저 확인할 것은 Clash 클라이언트에서 실제로 어떤 포트가 열려 있는지입니다. 일반적으로 mixed-port는 HTTP와 SOCKS5 요청을 한 포트에서 함께 처리하므로 셸 도구를 연결하기 편합니다. 예를 들어 로컬 mixed-port가 7890이라면 HTTP 클라이언트는 http://127.0.0.1:7890, SOCKS5 클라이언트는 socks5://127.0.0.1:7890을 사용합니다. 다만 모든 프로그램이 SOCKS5를 직접 지원하는 것은 아니므로, 처음에는 HTTP와 HTTPS 환경 변수를 함께 설정한 뒤 도구별 예외를 확인하는 편이 안정적입니다.

회사 네트워크에서 테스트한다면 조직의 보안 정책과 저장소 접근 규정을 먼저 확인해야 합니다. 이 글은 허가된 개발 환경에서 Clash를 사용한다는 전제로, 인증 우회나 접근 제한 회피가 아니라 연결 경로를 일관되게 관리하는 방법을 설명합니다. 설정을 바꿀 때는 한 번에 모든 도구를 수정하지 말고, Clash 연결 로그 → 환경 변수 → 도구별 설정 → 실제 명령 순서로 한 계층씩 검증하세요.

ℹ 시작 전 점검: Clash의 mixed-port 번호, 현재 선택한 정책 그룹, 시스템 프록시 활성화 여부를 기록하세요. 같은 주소를 사용하더라도 curl과 Git이 서로 다른 정책으로 표시되면 먼저 규칙과 환경 변수를 맞춰야 합니다.

셸 환경 변수와 터미널별 상속 확인

터미널 도구를 한 번에 연결하는 가장 간단한 방법은 셸 환경 변수에 프록시 주소를 지정하는 것입니다. macOS와 Linux에서는 사용하는 셸에 따라 ~/.zshrc, ~/.bashrc, 또는 회사에서 관리하는 셸 초기화 파일에 설정합니다. Windows에서는 PowerShell 프로필이나 사용자 환경 변수에 같은 목적의 값을 넣을 수 있습니다. 중요한 점은 GUI에서 실행한 IDE와 내장 터미널이 같은 환경을 상속한다고 단정하지 않는 것입니다. IDE를 이미 실행한 뒤 환경 변수를 바꾸면 기존 프로세스에는 변경 내용이 반영되지 않을 수 있습니다. 

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

위 예시에서 ALL_PROXY는 프로그램에 따라 우선순위가 높게 적용될 수 있으므로 무조건 넣는 것이 정답은 아닙니다. HTTP 프록시만 지원하는 오래된 도구가 있다면 ALL_PROXY 때문에 오히려 연결이 실패할 수 있습니다. 먼저 curl로 기본 경로를 확인하고, 문제가 생기면 환경 변수를 하나씩 제거하면서 어떤 값이 영향을 주는지 비교하세요. 로컬 loopback 주소와 사내 저장소 주소는 NO_PROXY에 넣어 불필요하게 외부 노드로 보내지 않는 편이 좋습니다.

설정 후에는 새 터미널을 열고 변수가 실제로 등록됐는지 확인합니다. 명령 결과에 프록시 비밀번호나 구독 URL이 노출될 수 있으므로 로그와 화면을 공유할 때는 토큰을 가리세요. 또한 원격 개발 컨테이너, SSH로 접속한 서버, CI 러너는 로컬 컴퓨터의 127.0.0.1을 그대로 바라보지 않습니다. 그 환경에서 127.0.0.1:7890을 사용하면 서버 자신에게 접속하게 되므로, 원격 환경에서는 별도의 허용된 프록시 주소나 프록시 없는 내부 경로를 설계해야 합니다.

대상 주요 설정 위치 확인할 항목
셸과 curl HTTP_PROXY, HTTPS_PROXY 새 터미널에서 변수 상속 여부
Git 전역 또는 저장소별 설정 HTTP와 SSH가 서로 다른 경로인지
Homebrew 셸 변수와 다운로드 환경 formula, bottle, GitHub 릴리스 경로
npm·pip 도구별 설정 파일 또는 변수 레지스트리와 패키지 CDN의 정책

Git HTTPS와 SSH를 각각 안정적으로 연결하기

Git 저장소 주소가 https://인지 git@ 형식의 SSH인지에 따라 프록시 적용 방법이 완전히 달라집니다. HTTPS 방식은 대체로 Git의 HTTP 프록시 설정이나 셸의 HTTPS_PROXY를 사용할 수 있습니다. 반면 SSH는 HTTP 프록시 변수를 자동으로 읽지 않으며, 별도의 ~/.ssh/config와 ProxyCommand가 필요할 수 있습니다. “환경 변수는 설정했는데 SSH push만 실패한다”는 증상은 이 차이에서 시작하는 경우가 많습니다.

HTTPS 저장소를 사용할 때는 전역 설정과 특정 저장소 설정을 구분하세요. 전역 프록시는 모든 Git 원격 주소에 적용되므로 사내 GitLab이나 내부 미러까지 외부 정책으로 보낼 수 있습니다. 외부 저장소에만 적용하려면 URL별 설정을 사용하고, 내부 도메인은 직접 연결하거나 조직에서 지정한 프록시를 사용해야 합니다. 설정을 바꾼 뒤에는 git config --show-origin --get-regexp 'http.*proxy'처럼 출처와 값을 함께 확인하면 예상하지 못한 전역 설정을 찾기 쉽습니다.

SSH는 먼저 대상 포트가 열려 있는지 확인합니다. GitHub와 같은 서비스는 일반 SSH 포트가 네트워크에서 차단될 수 있으며, 이때 서비스가 제공하는 대체 SSH 엔드포인트가 정책상 허용되는지 확인해야 합니다. 로컬 Clash가 SOCKS5 연결을 지원한다면 SSH 설정에 해당 프록시를 연결하는 방법을 사용할 수 있지만, 모든 OpenSSH 빌드가 같은 문법과 외부 helper를 제공하는 것은 아닙니다. 조직 장비에서는 임의의 바이너리를 내려받기보다 승인된 nc 또는 운영팀이 지정한 연결 방식을 따르세요.

인증 실패와 네트워크 실패도 구분해야 합니다. Permission denied (publickey)는 키, ssh-agent, 계정 권한 문제일 가능성이 높고, 연결이 한참 멈춘 뒤 timeout이 발생하면 라우팅·포트·프록시 문제일 가능성이 큽니다. ssh -vT 같은 상세 로그를 사용하면 어느 단계에서 멈추는지 확인할 수 있지만, 출력에 호스트명과 사용자 정보가 포함될 수 있으므로 외부에 그대로 올리지 마세요.

운영 팁: 팀에서 HTTPS와 SSH를 혼용한다면 저장소별 연결 방식을 문서화하세요. 같은 프로젝트에서 원격 URL만 바꿔 놓고 프록시가 적용됐다고 생각하면 clone은 성공해도 push 단계에서 다른 경로를 타는 일이 반복됩니다.

Homebrew·npm·pip 패키지 도구의 프록시 점검

Homebrew는 단순히 하나의 파일을 내려받는 프로그램이 아닙니다. formula 정보, bottle 바이너리, GitHub 릴리스 파일, 추가 저장소가 서로 다른 호스트를 사용할 수 있습니다. 그래서 Homebrew 페이지가 열리는 것만으로 설치 성공을 예측하기 어렵습니다. brew update, brew install, brew upgrade를 각각 실행하면서 Clash 연결 로그에서 실제 요청 호스트와 선택된 정책을 비교해야 합니다.

특히 bottle 다운로드가 특정 CDN으로 이동하는 경우, 메타데이터 호스트만 규칙에 넣으면 설치가 중간에 멈출 수 있습니다. 반대로 모든 CDN을 하나의 프록시 그룹으로 강제하면 사내 미러나 지역적으로 가까운 저장소까지 느린 노드로 돌아갈 수 있습니다. 가장 좋은 순서는 실패 시각의 로그를 저장하고, 반복해서 등장하는 호스트만 좁은 범위의 규칙으로 추가하는 것입니다. brew config 결과에는 운영체제와 경로 정보가 포함될 수 있으니 공유 전 민감한 내용을 확인하세요.

npm은 registry.npmjs.org에서 패키지 메타데이터를 받은 뒤 별도의 tarball 주소에서 실제 파일을 내려받을 수 있습니다. 따라서 npm registry만 프록시 처리하고 CDN을 직접 연결하면 설치가 99%에서 멈추거나 무결성 검증 전에 연결이 끊기는 현상이 나타납니다. npm 설정에 프록시를 직접 지정할 때는 기존 회사 레지스트리와 인증 토큰을 덮어쓰지 않도록 현재 값을 먼저 백업하세요. 프로젝트별 .npmrc와 사용자 홈의 전역 .npmrc가 동시에 존재할 수 있다는 점도 확인해야 합니다.

pip 역시 인덱스 URL과 실제 wheel·source archive를 받는 저장소가 다를 수 있습니다. 사내 PyPI 미러를 쓰는 프로젝트라면 공용 인덱스를 무심코 추가하지 말고, 팀의 의존성 정책을 우선 적용하세요. 인증 토큰이 포함된 URL을 셸 명령이나 CI 로그에 직접 적으면 유출 위험이 있으므로 환경 변수나 비밀 저장소를 사용합니다. 패키지 도구에서 TLS 인증서 오류가 발생하면 검증을 끄기보다 회사의 인증서 체인, 시스템 시간, 중간 프록시의 인증서 배포 상태를 먼저 점검해야 합니다.

Clash 규칙 설계와 재현 가능한 검증 순서

개발 도구를 모두 하나의 거대한 규칙으로 묶으면 처음에는 편해 보이지만, 문제가 생겼을 때 원인을 찾기 어렵습니다. 외부 Git 호스트, 패키지 레지스트리, 회사 내부 도메인, 일반 웹 트래픽을 최소한의 논리적 그룹으로 나누고, 내부 주소에는 명확한 DIRECT 또는 조직이 지정한 정책을 사용하세요. GitHub 전체를 무조건 프록시로 보내는 방식도 저장소 위치와 회사 정책에 따라 적합하지 않을 수 있습니다.

규칙 순서도 중요합니다. 구체적인 내부 도메인과 저장소 규칙을 일반적인 국가·지역·final 규칙보다 앞에 배치해야 합니다. DOMAIN-SUFFIX를 지나치게 넓게 쓰면 전혀 관계없는 서비스까지 같은 그룹에 들어가 개발 도구의 속도와 보안 범위를 동시에 악화시킬 수 있습니다. 새 규칙을 추가할 때는 이름, 목적, 예상 호스트, 적용 그룹을 주석이나 팀 문서에 남겨 몇 달 뒤에도 의도를 알 수 있게 하세요.

검증은 다음 순서가 효율적입니다. 먼저 Clash를 실행하고 선택한 정책 그룹이 정상인지 확인합니다. 다음으로 curl 같은 작은 요청으로 프록시 포트의 기본 동작을 검사합니다. 그 뒤 Git HTTPS clone, SSH 연결, Homebrew 메타데이터 조회, npm 또는 pip의 작은 테스트 설치를 각각 실행합니다. 한 단계가 실패하면 다음 단계로 넘어가지 말고, 연결 로그의 호스트·포트·정책·错误 여부를 기록하세요. 모든 도구를 동시에 실행하면 어떤 설정 변경이 효과가 있었는지 판단하기 어렵습니다.

장시간 SSH 세션이나 패키지 다운로드가 자주 끊긴다면 노드의 순간 지연만 보지 말고 연결 유지 시간, TCP 재전송, DNS 응답, TLS 협상 시간을 함께 살펴보세요. 짧은 웹 요청에 가장 빠른 노드가 장시간 Git fetch나 대용량 bottle 다운로드에는 적합하지 않을 수 있습니다. 여러 노드를 시험할 때는 같은 명령, 같은 저장소, 같은 시간대에 비교해야 하며, 성공한 설정은 파일로 백업하고 변경 날짜와 이유를 기록하는 것이 좋습니다.

ℹ 문제 재현의 기준: “인터넷이 된다”는 판정 대신 Git HTTPS → Git SSH → Homebrew → npm·pip 네 가지를 별도 테스트하세요. 각 테스트에서 로그의 정책 이름이 의도한 그룹과 일치해야 개발 환경 전체가 안정되었다고 판단할 수 있습니다.

일반 VPN이나 단순 시스템 프록시는 브라우저와 일부 데스크톱 앱에는 편리하지만, Git HTTPS와 SSH를 서로 다르게 처리하거나 패키지 CDN의 실제 호스트를 보여 주지 않아 원인 추적이 어려울 수 있습니다. 오래된 프록시 도구는 최신 TLS와 개발용 인증 흐름에서 호환성 문제가 생기기도 합니다. 반면 Clash V.CORE는 정책 그룹, 실시간 연결 로그, HTTP·SOCKS5 포트, 세밀한 도메인 규칙을 한 화면에서 관리할 수 있어 Git·SSH·Homebrew를 같은 기준으로 점검하기 좋습니다. 이 글의 절차를 실제 개발 환경에서 재현해 보고 싶다면 운영체제에 맞는 패키지를 다운로드하세요.