TUN 모드와 시스템 프록시, 무엇이 다를까요?
많은 사용자가 Clash에서 시스템 프록시만 켠 상태로 만족합니다. 이 방식은 운영체제가 제공하는 HTTP/HTTPS 프록시 설정을 따르는 애플리케이션에는 잘 맞습니다. 대표적으로 크롬·엣지·사파리처럼 OS 설정을 존중하는 브라우저는 별도 확장 없이도 잘 따라옵니다.
그러나 Git, npm·yarn·pnpm, Docker 데몬, Steam·에픽게임즈·배틀넷 같은 프로그램은 내부적으로 자체 스택을 쓰거나, 프록시 환경 변수를 비워 둔 채 직접 소켓을 여는 경우가 흔합니다. 이때는 OS에 등록된 127.0.0.1:포트가 아무리 정확해도 트래픽이 Clash를 거치지 않습니다. 사용자 입장에서는 브라우저만 빠르고 나머지는 느리거나 아예 타임아웃 나는 이중 경험이 생깁니다.
TUN 모드는 가상 네트워크 어댑터(윈도우의 Wintun 등)를 만들고, 운영체제 라우팅 테이블 상에서 트래픽을 Clash 코어가 수신하도록 돌립니다. 즉 애플리케이션이 프록시를 모른다 해도, 패킷이 먼저 Clash 규칙 엔진을 통과하게 됩니다. 그래서 명령줄 도구와 게임 클라이언트까지 한 번에 같은 정책 그룹과 분류 규칙을 적용할 수 있습니다.
왜 Git과 npm은 시스템 프록시를 자주 무시할까요?
Git은 HTTP(S) 리모트뿐 아니라 SSH 리모트도 사용합니다. SSH 경로는 OS의 HTTP 프록시 설정과 무관하게 동작하므로, 회사 밖 저장소를 쓸 때는 HTTPS로 전환하거나 SSH 자체에 ProxyCommand를 붙이지 않으면 그대로 직접 연결을 시도합니다. npm 계열은 Node.js의 네트워크 스택을 타는데, 기본값은 프록시 환경 변수가 비어 있으면 직결입니다. 일부 팀은 .npmrc에 레지스트리 프록시를 박아 두지만, 그건 조직 표준이 있을 때나 가능한 이야기입니다.
TUN을 켜면 이런 세부 설정을 앱마다 반복하지 않아도 됩니다. 물론 SSH처럼 완전히 다른 경로를 타는 프로토콜은 여전히 규칙에서 허용되는지, 그리고 22번 포트가 정책 그룹에서 어디로 붙는지 확인해야 합니다. 분류 규칙에서 국내 IP는 DIRECT, 해외는 PROXY로 나눠 두었다면, GitHub API 호출도 동일한 논리로 따라갑니다.
Windows에서 TUN을 켜기 전에 확인할 것
Windows에선 대부분의 Clash Meta 기반 GUI가 관리자 권한으로 실행될 때만 가상 어댑터를 안정적으로 올립니다. Wintun 드라이버 설치에 실패하면 장치 관리자에 고아 어댑터가 남거나, 반대로 이전 VPN과 충돌하기도 합니다. 설치 직후에는 방화벽에서 Clash 관련 실행 파일이 차단되지 않았는지, 그리고 다른 가상화 소프트웨어가 같은 터널 스택을 잡고 있지 않은지 점검하세요.
구체적인 클릭 경로와 UI 배치는 Clash Verge Rev Windows 완전 가이드에서 함께 다룹니다. 본문은 동작 원리와 개발·게임 시나리오에 초점을 맞추었으니, 처음 설치하는 분은 위 가이드를 먼저 밟고 오시면 학습 시간이 크게 줄어듭니다.
권장 활성화 순서: 구독 → 규칙 → 마지막에 TUN
아무 노드도 없는 상태에서 TUN만 켜면 순간적으로 전체 트래픽이 막히거나 루프에 빠질 수 있습니다. 안전한 순서는 다음과 같습니다. 첫째, 구독을 가져와 프로필이 정상인지 확인합니다. 둘째, 시스템 프록시 모드에서 브라우저로 국내·해외 사이트가 의도대로 나뉘는지 검증합니다. 셋째, DNS 모드(fake-ip vs redir-host)를 프로필에 맞게 고른 뒤, 넷째로 TUN을 켭니다.
fake-ip는 응답 속도와 규칙 매칭에 유리하지만, 일부 앱이 DNS 캐시를 공격적으로 쓸 때 예기치 않은 동작을 보일 수 있습니다. 문제가 생기면 일시적으로 redir-host로 바꿔 원인을 좁혀 보세요. 어느 쪽이든 TUN과 맞물리므로, 변경 후에는 브라우저와 터미널을 모두 한번씩 재시작해 캐시를 비우는 습관이 좋습니다.
Git과 npm·yarn·pnpm 실무 팁
TUN이 켜져 있으면 대부분의 git clone, git fetch, npm install, pnpm i가 별도의 HTTP_PROXY 없이도 프록시 경로를 탑니다. 그래도 특정 레지스트리만 회사 내부망으로 보내고 싶다면, Clash 규칙에서 DOMAIN-SUFFIX로 분기하는 편이 환경 변수를 앱마다 주입하는 것보다 관리가 쉽습니다.
혹시 레거시 스크립트가 이미 HTTP_PROXY를 강제로 비우도록 짜여 있다면, TUN과 중복되어 이상한 경로로 나갈 수 있습니다. 이런 경우에는 해당 셸 세션의 프록시 변수를 정리하고 다시 시도해 보세요. 모노레포에서 여러 패키지 매니저를 섞어 쓸 때도 동일합니다. 한 가지 더, corepack이나 npx가 호출하는 하위 바이너리는 여전히 일반 TCP이므로 TUN 규칙만 일관되면 충분합니다.
게임 클라이언트와 런처는 어떻게 되나요?
Steam, 에픽게임즈, 배틀넷, 라이엇 클라이언트 등은 대부분 자체 프로토콜과 UDP를 적극적으로 사용합니다. 시스템 HTTP 프록시만으로는 UDP 패킷을 다루기 어렵고, 애초에 런처가 그 설정을 읽지 않는 경우가 많습니다. TUN은 IP 레이어에서 잡기 때문에 다운로드·패치·로그인 검증까지 한 흐름으로 묶을 수 있습니다.
다만 안티치트 커널 모듈이나 일부 온라인 게임은 가상 어댑터 존재 자체를 경계하거나, 지역 잠금 정책과 충돌할 수 있습니다. 공식 이용약관과 서비스 지역을 항상 확인하시고, 경쟁 온라인 게임에서는 지연과 패킷 손실만 측정해 보신 뒤 TUN을 유지할지 판단하는 것이 좋습니다. LAN 파티나 협업 툴이 같은 머신에서 돌아갈 때는 분할 터널링 규칙으로 게임 IP 대역만 직행하게 만드는 식의 튜닝도 고려할 수 있습니다.
Clash Meta(Mihomo) 코어와의 관계
최신 GUI들은 내부적으로 Clash Meta 계열 코어를 탑재합니다. TUN 스택 이름이나 메뉴 표기는 클라이언트마다 조금씩 다르지만, 개념은 동일합니다. CFW 등 구형 클라이언트에서 넘어오는 경우라면 Clash Meta 업그레이드 가이드에서 프로필 이전과 드라이버 재설치 순서를 함께 정리해 두었으니 참고하세요.
자주 막히는 지점과 점검 방법
첫째, DNS 루프입니다. 로컬 DNS와 Clash의 DNS가 서로를 가리키면 해석이 영원히 돕니다. 프로필의 dns 섹션과 운영체제의 어댑터 DNS를 한눈에 그려 보세요. 둘째, MTU나 경로 중복입니다. 다른 VPN과 동시에 TUN을 올리면 라우팅 우선순위 싸움이 납니다. 셋째, UAC 권한입니다. 관리자 모드가 아닐 때는 TUN이 올라갔다가 바로 내려가는 증상이 흔합니다.
문제가 생기면 TUN을 끄고 시스템 프록시만으로 원상복구한 뒤, 로그에서 DROP 또는 REJECT 이유를 확인하세요. 규칙이 너무 공격적이면 패치 서버가 차단되어 게임만 실패하는 일도 생깁니다. 이때는 해당 도메인을 임시로 DIRECT에 넣고, 이후 Rule Provider로 정리하는 방식이 안전합니다.
보안·회사 정책·합법 사용에 대한 메모
TUN은 강력한 만큼, 회사 노트북에서는 IT 정책 위반일 수 있습니다. 승인 없이 커널 드라이버를 설치하면 보안 스캐너에 걸리기도 합니다. 또한 지역 법령과 서비스 약관을 준수하는 것은 사용자 책임입니다. 튜토리얼은 기술적 이해를 돕기 위한 것이며, 특정 서비스를 우회하도록 조장하는 목적은 아님을 분명히 밝힙니다.
정리하며
TUN 모드를 이해하면 브라우저와 터미널, 게임 런처 사이의 간극을 줄일 수 있습니다. 시스템 프록시는 가볍고 빠르게 시작하기 좋고, TUN은 예외 없이 한 코어에서 라우팅하고 싶을 때 쓰는 최종 보스에 가깝습니다. 둘을 상황에 맞게 조합하고, DNS·드라이버·권한 세 가지를 습관처럼 점검하면 반복되는 연결 오류가 크게 줄어듭니다.
다른 도구에 비해 Clash 계열은 규칙 기반 라우팅과 문서가 풍부해, 한 번 원리를 익혀 두면 이후 확장이 수월합니다. 설치 파일이 여러 포크로 흩어져 있어 출처를 헷갈리기 쉬운데, ClashFast 다운로드 페이지에서 플랫폼별 빌드를 모아 두었으니 변조 위험을 줄이면서 시작할 수 있습니다. 환경이 갖춰졌다면 → Clash를 무료로 내려받아 TUN과 규칙을 직접 체험해 보세요.