왜 브라우저는 되는데 git·npm·curl은 안 될까

많은 사용자가 겪는 패턴입니다. 운영체제 설정이나 Clash 클라이언트에서 시스템 프록시만 켜 두면 크롬·사파리·엣지 같은 브라우저는 잘 열리는데, 터미널에서 git clone , npm install , curl https://… 는 여전히 시간 초과·연결 거절·느린 속도에 시달립니다. 그 이유는 “프록시가 없어서”가 아니라 해당 프로그램이 운영체제가 알려 주는 HTTP 프록시 테이블을 기본적으로 읽지 않기 때문입니다.

curl 은 환경 변수 HTTP_PROXY / HTTPS_PROXY 가 있을 때만 프록시를 타는 경우가 많고, git 는 자체 설정 http.proxy 가 있어야 하며, npm 은 .npmrc 의 proxy 항목이나 별도 레지스트리 정책에 의존합니다. 즉 GUI 앱 한두 개는 시스템 프록시를 따르지만, CLI 생태계는 각자 설정이 분산되어 있어 “한 번에 전부” 맞추기가 어렵습니다. 도구마다 설정 파일을 만지는 방식은 팀 단위로도 유지보수 비용이 크고, 새 터미널 세션·CI 스크립트마다 빠지기 쉽습니다.

Clash TUN 모드는 이 문제를 “앱마다 환경 변수”가 아니라 운영체제 네트워크 스택 앞단에서 한 번에 가로채는 방식으로 풉니다. 가상 네트워크 인터페이스(TUN)를 통해 나가는 TCP·UDP 연결을 Clash 코어가 받아 rules: 목록과 프록시 그룹에 맡기므로, 별도로 git config 를 건드리지 않아도 저장소 fetch가 같은 규칙을 따르게 됩니다. 이 글에서는 그 원리를 한국어 검색 의도에 맞게 풀고, 대표 클라이언트 기준으로 켜는 순서·검증 명령·자주 묻는 질문까지 이어 갑니다.

시스템 프록시와 TUN 모드, 무엇이 다른가

시스템 프록시는 운영체제가 “이 포트로 HTTP(S) 트래픽을 보내라”고 알려 주는 힌트에 가깝습니다. 이를 존중하는 앱은 자동으로 로컬의 Clash 혼합 포트나 시스템이 지정한 HTTP 프록시로 붙습니다. 하지만 앞에서 말했듯 터미널 유틸리티는 이 힌트를 무시하는 경우가 기본에 가깝습니다. 게임·일부 데스크톱 앱도 마찬가지입니다.

TUN 모드는 한 단계 아래, IP 레이어에 가까운 위치에서 패킷을 받아 사용자 공간의 Clash(Mihomo 등)로 넘깁니다. 가상 NIC이기 때문에 운용 관점에서는 “새 이더넷 카드가 생겼다”고 느끼면 됩니다. 라우팅 테이블과 방화벽 규칙이 이 인터페이스를 경유하도록 바뀌면, 애플리케이션이 프록시를 의식하지 않아도 나가는 SYN 패킷이 Clash 안에서 목적지·정책에 따라 DIRECT 또는 원격 노드로 재작성됩니다.

정리하면, 시스템 프록시는 협조적인 앱만 데려오고, TUN은 협조 여부와 관계없이 대부분의 TCP·UDP를 한 규칙 세트로 묶는다고 보면 됩니다. 그래서 개발자 문서에서 “CLI까지 프록시하려면 TUN”이라고 반복해서 말하는 것입니다.

규칙 품질은 별개입니다. TUN을 켰다고 해서 분할 라우팅이 자동으로 완벽해지지는 않습니다. GEOIP , RULE-SET , DNS fake-ip 설정이 어긋나면 여전히 잘못된 경로로 나갈 수 있으니, TUN은 “전달 파이프”이고 “길 안내”는 규칙 YAML이 담당한다고 기억하세요.

Clash에서 TUN이 동작하는 직관적인 그림

코어 내부 구현까지 파고들 필요는 없습니다. 실무에서 중요한 것은 다음 세 가지입니다. 첫째, 애플리케이션이 connect() 로 목적지에 붙으려 할 때 그 흐름이 TUN 장치를 경유하는지. 둘째, Clash가 그 연결을 어느 프록시 그룹 이름에 붙였는지(연결 로그·UI). 셋째, DNS 요청이 어디에서 해석되고 있는지(해외 DNS로 가면 GeoIP가 엇나갈 수 있습니다).

Mihomo 계열은 Rule Provider, 지연 테스트, 최신 전송 프로토콜을 한 코어에서 다룹니다. TUN을 켠 상태에서 규칙 모드로 두면, 브라우저와 CLI가 같은 매칭 순서를 공유합니다. “중국 본토 도메인은 DIRECT, 나머지 해외는 Proxy” 같은 구성을 쓰고 있다면, npm 이 레지스트리에 붙을 때도 동일한 한 줄 규칙에 걸립니다. 반대로 전역 프록시에 가까운 MATCH 정책이면 CLI까지 모두 해외 노드를 타므로, 의도한 정책인지를 반드시 확인해야 합니다.

플랫폼별로 TUN 켜기 (요약)

Windows

Clash Verge Rev 등 최신 그래픽 클라이언트는 설정 화면에 “TUN 모드” 토글이 있습니다. 처음 켤 때는 관리자 권한(UAC) 이 필요합니다. 팝업에서 “예”를 눌러 가상 어댑터 드라이버 설치를 허용하세요. 방화벽에서 Clash 실행 파일이 차단되지 않았는지도 함께 확인합니다. 회사 보안 에이전트가 네트워크 필터를 심으면 TUN과 충돌하는 경우가 있으니, 그럴 때는 IT 정책을 우선하시기 바랍니다.

macOS

macOS는 네트워크 확장(Network Extension) 권한을 요구합니다. 시스템 설정에서 필터·프록시 관련 확장을 허용하고, 클라이언트가 안내하는 대로 비밀번호를 입력합니다. 허용을 건너뛰면 메뉴 막에서 “프록시 켜짐”으로 보여도 실제로는 터미널 트래픽이 빠져 나갈 수 있습니다. Apple Silicon과 Intel 모두 동일하게 권한 플로우가 있습니다.

Linux

배포판에 따라 tun 모듈, ip route 권한, 또는 nftables / iptables 연동을 수동으로 맞춰야 할 수 있습니다. 데스크톱용 GUI 클라이언트를 쓰면 루트 없이 PolicyKit으로 처리되는 경우도 있습니다. 스크립트로 코어만 띄우는 사용자는 공식 문서의 TUN 예시와 자기 배포판 방화벽 규칙을 함께 읽어야 합니다.

TUN은 강력합니다. 잘못된 규칙이면 모든 앱이 동시에 느려지거나 끊깁니다. 처음에는 백업 프로필을 두고, 문제가 생기면 TUN만 끄고 시스템 프록시로 되돌릴 수 있게 해 두세요.

검증: curl , git , npm

설정이 들어갔는지 확인할 때는 “브라우저”보다 짧은 명령이 빠릅니다. 아래는 예시이며, 실제 엔드포인트는 본인 환경에 맞게 바꾸면 됩니다.

curl

# 공인 IP 확인 (출력 서버가 프록시 Exit와 일치하는지 보면 됨)
curl -s https://api.ipify.org

# 연결 타임아웃까지 시간이 길다면 DNS 또는 노드 지연 의심
curl -sI --max-time 15 https://www.google.com

TUN이 꺼진 상태에서는 위 명령이 로컬 회선 그대로 나가고, 켠 뒤에는 Clash 연결 목록에 해당 세션이 잡혀야 합니다. 클라이언트 UI에서 어떤 규칙에 매칭됐는지를 보는 습관을 들이면 이후 트러블슈팅이 빨라집니다.

git

원격 저장소가 GitHub 등 해외라면, TUN + 규칙만으로 git fetch 가 통과해야 정상입니다. 여전히 안 되면 SSH 포트(22) 를 막는 회사망인지, 또는 [email protected]:... SSH 경로가 별도 정책을 타는지 확인하세요. HTTPS URL로 바꿔 테스트해 보면 원인을 좁히기 쉽습니다.

npm

npm 은 레지스트리 호스트가 해외이면 큰 패키지를 받을 때 프록시 경로가 중요합니다. TUN이 켜진 뒤에도 느리다면 .npmrc 에 남아 있는 예전 proxy 줄이 이중으로 걸리는지, 또는 registry 가 차단된 도메인을 가리키는지 살펴보세요. IPv6만 시도하다가 막히는 경우도 있어, 코어의 IPv6 관련 옵션과 운영체제 설정을 함께 점검하는 편이 좋습니다.

DNS·규칙과 TUN을 같이 쓸 때의 주의점

TUN은 패킷을 가로채도, 도메인 해석이 엉키면 여전히 “엉뚱한 IP로 직접 연결”이 발생합니다. fake-ip 를 쓰는 구성에서는 fake-ip-filter 에 LAN·국내 필수 도메인을 넣어야 하는 등 세심한 조정이 필요합니다. 반대로 해석은 로컬인데 라우팅만 프록시로 보내고 싶다면, 규칙 순서에서 DOMAIN 규칙과 GEOIP 규칙의 상대적 위치를 재점검하세요.

개발자에게 실용적인 조언은 하나입니다. 문제가 생기면 연결 로그 + 규칙 매칭 결과를 먼저 보고, 그다음 DNS를 의심하세요. “TUN이 고장”이라기보다 “규칙이 DIRECT로 떨어져 ISP 경로를 탔다”인 경우가 훨씬 많습니다.

자주 묻는 질문 (본문 요약)

Q. 시스템 프록시만으로는 절대 CLI를 못 잡나요? 이론상 전 종단에 환경 변수와 팀 표준 스크립트를 강제하면 가능하지만, 현실적으로 유지가 어렵습니다. TUN이 운영 비용 대비 효과가 큽니다.

Q. 다른 VPN과 동시에? 둘 다 커널 라우팅을 만지면 충돌합니다. 한 번에 하나의 “전체 트래픽” 솔루션을 켜는 것을 권합니다.

Q. 보안·컴플라이언스는? TUN은 모든 앱 트래픽이 정책을 통과합니다. 회사 노트북에서는 내부 정책을 확인하고, 개인 데이터 처리 법규를 준수하세요.

정리: 왜 Clash 생태계인가

일부 오래된 클라이언트는 저장소가 비공개로 전환되었거나 업데이트가 멈춰 최신 코어·프로토콜·Rule Provider 워크플로 를 따라가기 어렵습니다. 반면 활발히 관리되는 Clash·Mihomo 기반 앱은 TUN, 지연 테스트, 연결별 규칙 표시를 한 UI에서 묶어 줍니다. 단순 VPN 토글 하나로 “전부 터널”만 하던 방식은 빠르게 설정할 수 있어도, 국내 서비스까지 해외로 돌아가 느려지는 부작용이 큽니다. 규칙 + TUN 조합이면 브라우저와 git · npm · curl 이 같은 정책을 공유하므로, 팀 개발 환경을 맞출 때 설명할 변수가 줄어듭니다.

또한 동일한 구독이라도 클라이언트마다 디버깅 경험이 크게 달라집니다. 연결 화면에서 어느 규칙에 걸렸는지 바로 보이고, TUN 토글이 정돈되어 있다면 “왜 터미널만 안 되지?” 같은 문제를 한 시간 헤매지 않아도 됩니다. 공식 배포 페이지에서 OS에 맞는 최신 빌드를 받아 TUN을 켠 뒤, 이 글의 검증 순서만 따라가 보시기 바랍니다.

Clash 클라이언트 무료 다운로드 →