개발 환경에서 Clash가 필요한 이유
개발자는 브라우저만 사용하는 일반 사용자보다 훨씬 다양한 네트워크 연결을 동시에 처리합니다. GitHub나 GitLab에서 저장소를 clone하고, npm 또는 pnpm으로 패키지를 내려받으며, Docker 이미지를 가져오고, 원격 서버에 SSH로 접속해야 합니다. 여기에 VS Code 확장, AI 코딩 도구, CI/CD 서비스까지 추가되면 하나의 컴퓨터에서 수십 개의 해외 도메인과 장시간 연결이 발생합니다.
이때 브라우저에서만 동작하는 일반적인 시스템 프록시는 충분하지 않을 수 있습니다. Git은 별도의 HTTP 또는 SSH 연결을 사용하고, Docker는 데몬 프로세스가 별도 환경에서 실행되며, 일부 개발 도구는 웹소켓이나 자체 인증 서버를 사용하기 때문입니다. 특정 요청만 실패하거나 다운로드가 중간에 멈추는 현상은 인터넷 속도 자체보다 프로그램별 프록시 경로가 일관되지 않기 때문에 발생하는 경우가 많습니다.
Clash는 도메인, 프로세스, IP, 포트와 같은 조건에 따라 트래픽을 직접 연결하거나 프록시 그룹으로 보낼 수 있습니다. 따라서 국내 패키지 미러와 사내 Git 서버는 DIRECT로 유지하고, GitHub, Docker Hub, npm 공식 저장소와 같은 글로벌 서비스는 안정적인 노드로 분리할 수 있습니다. 이 글에서는 2026년 기준의 Clash Verge Rev와 Mihomo 코어를 가정하여 터미널 중심의 개발 워크플로를 구성합니다.
가이드의 목표
브라우저에서 프록시가 작동하는 수준을 넘어 Git, SSH, npm, Docker, AI 코딩 도구까지 같은 원칙으로 진단하고 안정적으로 연결하는 방법을 익히는 것이 목표입니다.
1개발자용 Clash 기본 설정
먼저 노드 이름을 그대로 규칙에 입력하기보다 용도별 프록시 그룹을 만들어야 합니다. 노드를 직접 지정하면 나중에 서버를 교체할 때 여러 규칙을 다시 수정해야 하지만, 그룹을 사용하면 한 곳에서 선택한 노드만 바꾸면 됩니다. 예를 들어 해외 개발 서비스에는 Dev-Proxy, 일반 웹사이트에는 Proxy, 국내 서비스에는 DIRECT를 사용할 수 있습니다.
Clash Verge Rev에서 프로파일을 불러온 뒤에는 현재 모드가 Rule인지 확인하세요. Global 모드는 모든 트래픽을 하나의 경로로 보내므로 간단하지만, 국내 서비스와 사내망까지 불필요하게 우회할 수 있습니다. 반대로 Rule 모드는 개발 서비스별로 경로를 구분할 수 있어 속도와 안정성을 함께 관리하기 좋습니다.
- 노드 지연 시간을 측정하고 응답이 안정적인 지역 노드를 선택합니다.
- 해외 개발 서비스용 선택 그룹을 만들고 이름을
Dev-Proxy처럼 고정합니다. - Clash 모드를
Rule로 설정합니다. - TUN 모드를 사용할 경우 운영체제의 VPN 권한과 DNS 설정이 정상인지 확인합니다.
- 규칙을 수정한 뒤 프로파일을 저장하고 Clash 코어를 재시작합니다.
DNS는 개발 환경에서 특히 중요합니다. GitHub 주소는 정상적으로 열리는데 Git clone만 실패한다면 DNS 응답과 실제 연결 경로가 서로 다를 수 있습니다. Mihomo의 DNS 설정에서 원격 DNS를 사용하고, fake-ip 또는 redir-host 모드 중 현재 운영체제와 사용하는 프로그램에 더 안정적인 방식을 선택하세요. 설정을 바꾼 뒤에는 오래된 DNS 캐시를 비우고 다시 테스트해야 정확한 결과를 얻을 수 있습니다.
주의사항
TUN 모드는 시스템 전체 트래픽을 가로채므로 사내 VPN, 가상머신, Kubernetes 네트워크와 충돌할 수 있습니다. 문제가 생기면 TUN을 잠시 끄고 시스템 프록시 방식으로 원인을 분리해서 확인하세요.
2직접 따라 하는 Git·터미널 연결 설정
이제 실제 명령줄에서 동작을 확인해 보겠습니다. 터미널의 환경 변수와 Git의 내부 설정은 서로 별개이므로 한쪽만 설정하면 모든 명령이 프록시를 사용하는 것은 아닙니다. Clash의 혼합 포트가 7890이라고 가정하지만, 실제 포트는 Clash 설정 화면에서 확인해야 합니다.
터미널 환경 변수 설정
macOS와 Linux에서는 다음과 같이 현재 셸에 임시 프록시를 적용할 수 있습니다. 이 방식은 curl, 일부 패키지 매니저, HTTP 기반 CLI 도구를 빠르게 테스트할 때 유용합니다.
Windows PowerShell에서는 다음 명령을 사용합니다.
환경 변수는 새 터미널을 열면 사라질 수 있습니다. 매번 설정하는 것이 번거롭다면 macOS와 Linux의 셸 프로파일, Windows의 사용자 환경 변수에 등록할 수 있습니다. 다만 사내망이나 로컬 개발 서버까지 프록시를 통과시키지 않도록 NO_PROXY에 내부 도메인과 포트를 추가하세요.
Git HTTP 및 HTTPS 프록시
GitHub 저장소를 HTTPS로 사용하는 경우 Git에 직접 프록시를 등록하면 브라우저 설정과 무관하게 fetch, pull, clone이 같은 경로를 사용합니다.
설정이 적용되었는지는 다음 명령으로 확인합니다.
프록시를 해제해야 하는 네트워크에서는 전역 설정을 삭제할 수 있습니다.
확인 방법
git ls-remote는 저장소 전체를 내려받지 않고 원격 참조만 조회하므로 clone 전에 인증, DNS, 프록시 연결을 빠르게 점검하기 좋습니다.
Git SSH 연결과 ProxyCommand
Git 주소가 [email protected]:사용자/저장소.git 형식이라면 Git의 HTTP 프록시 설정은 적용되지 않습니다. SSH는 별도의 TCP 연결이므로 Clash의 SOCKS 포트를 SSH에 연결해야 합니다. OpenSSH에서는 ~/.ssh/config에 다음 항목을 추가할 수 있습니다.
일부 Windows 환경에서는 기본 nc가 없을 수 있습니다. 이때 사용하는 OpenSSH 버전과 함께 SOCKS5를 지원하는 네트워크 도구를 설치하거나, GitHub 저장소를 HTTPS 방식으로 전환하는 편이 더 간단할 수 있습니다. SSH 연결은 다음 명령으로 확인합니다.
처음 연결할 때 호스트 키 확인 메시지가 표시될 수 있습니다. 반드시 공식 호스트 정보와 지문을 확인한 뒤 승인하세요. 연결이 멈춘다면 ssh -vvv -T [email protected]으로 어느 단계에서 지연되는지 확인할 수 있습니다. 인증 키 오류와 프록시 연결 오류는 원인이 다르므로 로그를 구분해서 읽는 것이 중요합니다.
3npm·Docker·AI 도구별 규칙 최적화
Git이 해결되었다고 해서 모든 개발 도구가 자동으로 정상화되는 것은 아닙니다. 각 도구는 프록시를 읽는 위치와 인증 방식을 다르게 처리합니다. 따라서 도메인 규칙과 애플리케이션 설정을 함께 확인해야 합니다.
npm, pnpm, yarn 패키지 설치
npm은 자체적으로 프록시 설정을 저장할 수 있습니다. 다음 명령으로 공식 레지스트리를 지정하고 프록시를 등록하세요.
패키지 설치가 멈출 때는 무조건 타임아웃을 늘리기보다 레지스트리 응답, 인증서, DNS를 순서대로 확인하는 것이 좋습니다. 사내 레지스트리를 사용한다면 해당 도메인은 DIRECT로 보내고, 공용 npm 레지스트리만 Dev-Proxy 그룹에 할당하세요. pnpm과 yarn도 환경 변수나 자체 설정 파일을 사용할 수 있으므로 실제 명령이 참조하는 설정을 확인해야 합니다.
Docker 이미지와 데몬 프록시
Docker CLI에 환경 변수를 설정하는 것과 Docker daemon에 프록시를 설정하는 것은 다릅니다. docker pull이 실패한다면 이미지를 가져오는 데몬이 프록시를 모르는 경우가 많습니다. Docker Desktop을 사용한다면 Settings의 Resources 또는 Proxy 관련 메뉴에서 프록시를 설정하고 재시작하세요. Linux의 Docker Engine은 서비스 설정에 프록시를 추가해야 합니다.
Docker 컨테이너 내부의 프록시와 이미지 다운로드에 사용하는 데몬 프록시는 서로 다릅니다. 빌드 과정에서 외부 패키지를 받아야 한다면 Dockerfile의 ARG 또는 빌드 옵션을 별도로 구성해야 하며, 비밀 토큰이나 계정 비밀번호를 이미지 레이어에 남기지 않도록 주의하세요.
AI 코딩 도구와 개발 확장
AI 코딩 도구는 API 도메인, 로그인 도메인, 파일 업로드 도메인이 서로 다를 수 있습니다. 한 도메인만 프록시로 보내면 로그인은 되지만 코드 제안이 나타나지 않거나, 채팅은 되지만 파일 분석이 실패할 수 있습니다. Clash 로그에서 실제 요청 도메인을 확인한 뒤 관련 도메인을 하나의 전용 그룹으로 묶으세요.
위 목록은 서비스와 네트워크 환경에 따라 달라질 수 있는 예시입니다. 알 수 없는 도메인을 무작정 프록시로 보내기보다 Clash의 연결 로그를 보면서 실제로 필요한 도메인만 추가하세요. 조직의 보안 정책이나 서비스 이용 약관도 반드시 준수해야 합니다.
4문제 진단과 운영 체크리스트
프록시를 설정한 뒤에도 문제가 남는다면 다음 순서로 범위를 좁히세요. 먼저 Clash가 실행 중이고 해당 포트가 열려 있는지 확인합니다. 그다음 도메인 이름이 올바르게 해석되는지, TCP 연결이 성립하는지, 마지막으로 Git 또는 패키지 매니저 인증이 통과하는지 살펴봅니다.
- 연결 로그 확인: Clash의 Logs 화면에서 요청 도메인, 적용된 규칙, 사용 노드를 확인합니다.
- 직접 요청 테스트:
curl -I https://github.com으로 HTTP 응답과 인증서 오류를 구분합니다. - 경로 테스트: 특정 도메인이 예상과 다른 그룹으로 연결되는지 규칙 순서를 확인합니다.
- 인증 분리: SSH 키, GitHub 토큰, npm 토큰 오류를 프록시 오류로 오해하지 않습니다.
- 캐시 초기화: DNS 캐시, npm 캐시, Docker의 실패한 레이어를 정리한 뒤 재시도합니다.
- 노드 교체: 모든 설정이 맞는데 특정 서비스만 실패하면 노드의 IP 평판이나 해당 지역의 연결 품질을 의심합니다.
명령마다 출력 결과를 따로 저장하면 Clash 규칙 문제와 프로그램 인증 문제를 쉽게 비교할 수 있습니다.
보안 주의
공유 프록시에서 개인 키, 액세스 토큰, npm 토큰을 평문으로 전송하지 마세요. 토큰은 최소 권한으로 발급하고, 로그나 셸 히스토리에 인증 정보가 남지 않도록 환경 변수와 비밀 저장소를 사용하세요.
자주 묻는 질문
Git HTTPS 프록시와 터미널 프록시를 모두 설정해야 하나요?
반드시 둘 다 필요한 것은 아닙니다. Git 설정은 Git 프로세스에만 명시적으로 적용되고, 환경 변수는 이를 읽는 여러 CLI 도구에 영향을 줍니다. 팀 환경에서는 Git 설정을 명확히 관리하고, 일시적인 테스트에는 환경 변수를 사용하는 방식이 편리합니다. 두 설정의 포트가 서로 다른지 항상 확인하세요.
Git clone은 되는데 SSH clone만 실패하는 이유는 무엇인가요?
HTTPS와 SSH는 전혀 다른 프로토콜과 포트를 사용하기 때문입니다. Git의 HTTP 프록시는 SSH에 적용되지 않습니다. SOCKS5 포트를 사용하는 ProxyCommand를 SSH 설정에 추가하거나, 네트워크 환경상 SSH 프록시가 어려우면 HTTPS 저장소 주소를 사용하세요.
Docker Desktop에서는 되는데 터미널의 Docker가 실패합니다. 왜 그런가요?
Docker CLI와 Docker daemon의 실행 위치가 다르기 때문입니다. Desktop은 앱 설정을 따로 사용하고, Linux Engine은 systemd 서비스 설정을 참조합니다. 현재 사용 중인 Docker context와 daemon의 docker info 결과를 확인한 뒤 해당 환경에 프록시를 적용해야 합니다.
모든 개발 트래픽을 프록시로 보내면 더 안정적인가요?
그렇지 않습니다. 사내 Git 서버, 로컬 Kubernetes API, 국내 패키지 미러는 직접 연결이 더 빠르고 안전할 수 있습니다. 필요한 글로벌 서비스만 Dev-Proxy로 보내고, 내부 도메인과 로컬 주소는 NO_PROXY 및 Clash 규칙에서 제외하는 것이 권장됩니다.