TUN 모드와 시스템 프록시의 본질적인 차이
Clash 클라이언트에서 흔히 볼 수 있는 「시스템 프록시」와 「TUN 모드」는 강약이 다른 두 스위치가 아니라, 트래픽을 받아들이는 서로 다른 경로입니다. 시스템 프록시는 운영체제에 HTTP 및 HTTPS 프록시 주소를 기록하며, 일반적으로 127.0.0.1:7890에서 연결을 수신합니다. 브라우저나 메신저처럼 시스템 프록시 설정을 능동적으로 읽는 프로그램은 연결을 Clash에 전달하지만, 시스템 프록시를 무시하는 프로그램은 계속 직접 인터넷에 연결합니다.
TUN 모드는 가상 네트워크 어댑터를 만들고 시스템 라우팅 테이블에 관련 경로를 추가합니다. 라우팅 조건에 맞는 IP 패킷은 먼저 가상 어댑터로 들어간 뒤 mihomo 코어가 목적지를 식별하고 규칙을 적용해 프록시, 직접 연결 또는 차단 여부를 결정합니다. 따라서 TUN이 처리하는 것은 네트워크 계층의 트래픽이며, 각 앱이 HTTP 또는 SOCKS 프록시를 이해해야 하는 것은 아닙니다.
| 비교 항목 | 시스템 프록시 | TUN 모드 |
|---|---|---|
| 연결 지점 | 애플리케이션 계층의 프록시 설정 | 가상 네트워크 어댑터 및 시스템 라우팅 |
| 일반적인 포트 | 혼합 포트 7890 | 가상 네트워크 어댑터가 IP 패킷을 직접 받아 앱에서 포트를 입력할 필요가 없음 |
| 적용 대상 | 브라우저 및 시스템 프록시를 따르는 앱 | 런처, 명령줄 도구, 게임 및 기타 직접 연결 프로그램 |
| UDP 지원 | 앱과 프록시 프로토콜에 따라 다름 | UDP를 처리할 수 있지만 노드와 프로토콜도 지원해야 함 |
| 필요한 권한 | 대개 일반 사용자 권한 | 서비스 설치, 네트워크 확장 기능 또는 VPN 권한 허용 필요 |
TUN을 켜볼 만한 상황
- 브라우저는 연결되지만 게임 런처, 스토어 클라이언트 또는 데스크톱 앱은 계속 직접 연결되는 경우
git, 패키지 관리자 및 기타 명령줄 프로그램이 시스템 프록시를 읽지 않는 경우- 앱이 UDP나 QUIC를 사용해 HTTP 프록시 설정만으로는 처리할 수 없는 경우
- 각 프로그램마다
HTTP_PROXY,HTTPS_PROXY또는 SOCKS5 주소를 입력하고 싶지 않은 경우 - 하나의 Clash 규칙 세트로 이 기기의 더 많은 연결을 통합 처리해야 하는 경우
웹 브라우징만 한다면 시스템 프록시가 보통 더 간단하고, 문제가 생겨도 원인을 찾기 쉽습니다. TUN은 라우팅과 DNS 처리 경로를 변경하므로 실제로 트래픽을 통합해야 할 때 적합합니다. 설치 후 반드시 켜야 하는 기능으로 생각할 필요는 없습니다.
시작 전 권한과 서비스 준비하기
아래 단계는 mihomo 코어를 사용하는 Clash Verge Rev 2.x 설정 구조를 기준으로 합니다. 클라이언트마다 메뉴 위치는 조금 다를 수 있지만 준비 과정은 대체로 같습니다. 코어가 가상 네트워크 어댑터를 만들고 라우팅을 작성할 충분한 권한을 가져야 하며, 앱을 종료하거나 다시 시작할 때 해당 설정도 올바르게 정리해야 합니다.
Windows: 서비스 모드 설치
- 처음 설치할 때 라우팅 충돌을 피하려면 실행 중인 다른 VPN, 네트워크 가속기 또는 가상 네트워크 어댑터 도구를 종료합니다.
- 클라이언트를 열고 「설정」→「시스템 설정」→「서비스 모드」로 이동합니다.
- 「설치」를 선택한 뒤 Windows 사용자 계정 컨트롤 창에서 관리자 권한을 확인합니다.
- 설치가 끝나면 서비스 상태가 실행 중인지 확인한 다음 「프록시」 페이지에서 「TUN 모드」를 켭니다.
- 처음 켠 뒤 가상 네트워크 어댑터와 라우팅이 초기화될 때까지 약 3~10초 기다립니다.
서비스 모드에서는 관리자 권한을 가진 백그라운드 서비스가 가상 네트워크 어댑터와 라우팅을 처리하고, 그래픽 인터페이스는 일반 사용자 권한으로 실행할 수 있습니다. 설치 버튼을 눌러도 상태가 바뀌지 않으면 클라이언트를 완전히 종료한 뒤 「관리자 권한으로 실행」으로 한 번 시작해 다시 설치합니다. 회사 PC에서 서비스 설치가 제한되어 있다면 장치 관리자에게 권한을 요청해야 합니다.
macOS: 보조 프로그램 또는 네트워크 확장 허용
- 클라이언트의 「설정」→「시스템 서비스」 또는 「서비스 모드」로 이동해 보조 프로그램 설치를 선택합니다.
- 시스템 암호 또는 Touch ID 안내가 표시되면 작업을 확인합니다.
- 시스템이 네트워크 구성 요소를 차단하면 「시스템 설정」→「개인정보 보호 및 보안」을 열고 페이지 아래쪽에서 해당 구성 요소를 허용합니다.
- 클라이언트로 돌아가 TUN을 켭니다. 시스템에서 VPN 구성 추가를 다시 허용할지 묻는다면 허용을 선택합니다.
macOS 업데이트 후에는 기존 보조 프로그램을 다시 승인해야 할 수 있습니다. 암호 입력이 반복되거나 TUN 스위치가 자동으로 꺼지면 먼저 클라이언트의 서비스 모드를 제거하고 시스템을 재시동한 뒤 현재 버전의 클라이언트에서 다시 설치합니다. 두 개의 Clash 그래픽 클라이언트 시스템 서비스를 동시에 유지하지 마세요.
Android: VPN 연결 권한 확인
Android의 Clash Meta 계열 클라이언트는 일반적으로 시스템 VPNService를 통해 로컬 가상 네트워크 어댑터를 만듭니다. 「설정」→「네트워크」→「TUN」을 열면 시스템에 VPN 연결 확인 창이 표시됩니다. 확인하면 상태 표시줄에 열쇠 또는 VPN 아이콘이 나타납니다. Android에서는 한 번에 하나의 VPN 서비스만 유지할 수 있으므로, 이미 실행 중인 회사 VPN, WireGuard 또는 다른 프록시 앱의 연결이 끊깁니다.
Clash TUN 권장 설정 방법
대부분의 데스크톱 환경에서는 stack: mixed, auto-route: true, auto-detect-interface: true를 기본값으로 설정하고 Clash DNS가 53번 포트 질의를 처리하도록 하는 것이 좋습니다. 다음은 mihomo 1.19 계열에서 인식할 수 있는 기본 설정 예시입니다.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
strict-route: true
dns-hijack:
- any:53
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
default-nameserver:
- 223.5.5.5
nameserver:
- https://dns.alidns.com/dns-query그래픽 클라이언트는 보통 이 필드 일부를 생성하거나 덮어씁니다. 클라이언트에 「TUN 스택」, 「자동 라우팅」, 「DNS 하이재킹」 스위치가 있다면 인터페이스에서 먼저 수정하세요. 구독에서 생성된 읽기 전용 설정을 동시에 편집하지 않는 것이 좋습니다. 구독을 업데이트하면 설정 본문이 덮어써질 수 있지만, 클라이언트에 저장한 전역 오버라이드는 계속 적용되는 경우가 많습니다.
스택 선택: mixed를 기본값으로 사용
| 스택 | 특징 | 권장 용도 |
|---|---|---|
| mixed | 시스템 및 사용자 공간 처리 경로를 함께 사용해 호환성과 성능의 균형을 맞춤 | Windows와 macOS에서 일반적으로 우선 선택 |
| system | 시스템 네트워크 스택 의존도가 높고 리소스 사용량이 대체로 낮음 | mixed가 특정 프로그램과 충돌할 때 테스트 |
| gVisor | 사용자 공간 네트워크 스택을 사용하며 격리 및 호환 경로가 다름 | 특정 UDP 또는 시스템 스택 이상이 있을 때 점검용으로 선택 |
특정 스택 이름이 더 고급스러워 보인다는 이유로 자주 바꾸지 마세요. 먼저 mixed로 실행하면서 웹 페이지, DNS, 다운로드 및 처리 대상 앱을 각각 테스트합니다. 특정 연결 유형만 실패할 때 system과 gVisor를 차례로 테스트하고, 변경할 때마다 TUN을 완전히 끊었다가 다시 켭니다.
자동 라우팅과 출구 인터페이스 자동 감지
auto-route: true는 코어가 트래픽을 처리하는 데 필요한 라우팅을 자동으로 작성하게 합니다. auto-detect-interface: true는 현재 실제 출구 네트워크 어댑터를 식별합니다. 노트북이 유선 네트워크에서 Wi-Fi로 전환되거나 집 네트워크에서 휴대폰 핫스팟으로 바뀔 때 자동 감지를 사용하면 프록시 연결이 다시 TUN으로 들어가는 문제를 줄일 수 있습니다.
strict-route: true는 라우팅 제약을 강화하며, Windows에서 일부 DNS 요청이 처리 경로를 우회하는 것을 줄이는 데도 도움이 됩니다. 다만 엄격한 라우팅은 로컬 네트워크 검색, 가상 머신 브리징 또는 사내 네트워크에 영향을 줄 수 있습니다. 켠 뒤 프린터, NAS 또는 회사 네트워크에 접근할 수 없다면 TUN 전체를 끄기보다 strict-route만 잠시 끄고 비교하세요.
DNS 하이재킹에 any:53을 자주 사용하는 이유
dns-hijack: any:53는 처리 대상 트래픽의 기존 UDP/TCP 53번 포트 질의를 mihomo DNS 모듈로 전달한다는 뜻입니다. 이를 통해 도메인 해석 결과와 규칙 판단을 일치시키고, 앱이 시스템 DNS 설정을 우회하는 상황도 줄일 수 있습니다. 앱에 내장된 DoH까지 자동으로 가로채지는 않습니다. DoH는 본질적으로 특정 서버로 전송되는 HTTPS 트래픽이므로 도메인 또는 IP 규칙으로 별도 처리해야 합니다.
198.18.0.1/16은 fake-ip에서 자주 사용하는 주소 대역입니다. 앱이 도메인을 조회하면 먼저 이 범위의 매핑 주소를 받고, 코어가 매핑을 통해 원래 도메인을 복원해 규칙을 적용합니다. 로컬 네트워크 장치, 프린터 도메인 또는 실제 IP에 의존하는 일부 앱에 문제가 생기면 해당 도메인을 fake-ip 필터 목록에 추가하세요. 일반 공인 주소 대역으로 함부로 바꾸면 안 됩니다.
인터페이스에서 켠 뒤 실제 처리 여부를 확인하는 전체 단계
- 「프로필」 페이지에서 사용 가능한 설정을 업데이트하고 선택한 뒤, 정상적으로 연결할 수 있는 노드가 하나 이상 있는지 확인합니다.
- 실행 모드를 「규칙」으로 설정해 테스트 중 모든 트래픽이 전역 정책의 영향을 받지 않도록 합니다.
- 「설정」→「Clash 설정」→「TUN」으로 이동해 스택을 mixed로 설정합니다.
- 「자동 라우팅」, 「출구 네트워크 어댑터 자동 감지」 및 「DNS 하이재킹」을 켭니다.
- 서비스 모드가 설치되어 실행 중인지 확인한 다음 TUN 기본 스위치를 켭니다.
- 먼저 시스템 프록시를 따르는 브라우저를 테스트한 뒤, 기존에 시스템 프록시로 처리되지 않던 앱을 테스트합니다.
- 클라이언트 연결 로그를 열고 대상 도메인이 표시되는지, 최종적으로 어떤 규칙과 정책 그룹이 적용되었는지 확인합니다.
효과를 확인하려면 「시스템 프록시」를 잠시 끄고 TUN만 유지해 보세요. 브라우저와 대상 앱이 여전히 Clash 규칙에 따라 연결된다면 가상 네트워크 어댑터 경로가 작동하는 것입니다. 테스트 후 시스템 프록시를 다시 켤지는 클라이언트 구현에 따라 다릅니다. mihomo는 보통 두 진입 경로를 동시에 처리할 수 있지만, 원인 분석 단계에서는 한 번에 하나만 유지하는 편이 더 명확합니다.
Windows에서 가상 네트워크 어댑터와 라우팅 확인
PowerShell에서 다음 명령을 실행하면 현재 네트워크 어댑터와 IPv4 라우팅을 확인할 수 있습니다. 클라이언트마다 생성하는 어댑터 이름에는 Mihomo, Clash 또는 Meta가 포함될 수 있습니다.
Get-NetAdapter | Sort-Object Status, Name
Get-NetRoute -AddressFamily IPv4 |
Sort-Object RouteMetric |
Select-Object -First 20가상 네트워크 어댑터는 Up 상태여야 하며, 라우팅 테이블에는 TUN이 관리하는 항목이 나타납니다. 기본 경로가 가상 네트워크 어댑터로 바뀌었는지만 보고 성공 여부를 판단하지 마세요. 운영체제와 코어 버전에 따라 분할 라우팅, 정책 라우팅 또는 더 구체적인 라우팅 항목을 사용할 수 있습니다.
웹 결과만 보지 말고 로그로 규칙 확인하기
「로그」 페이지에서 수준을 info로 설정합니다. 테스트할 앱을 실행하면 대상 주소, 네트워크 유형 및 적용된 정책이 표시되어야 합니다. 예를 들면 TCP, UDP, MATCH, DIRECT 또는 특정 프록시 그룹이 있습니다. 해당 연결이 전혀 없다면 트래픽이 코어로 들어오지 않은 것입니다. 로그는 있지만 DIRECT로 표시된다면 규칙 순서를 확인하세요. 프록시를 선택했는데도 시간 초과가 발생하면 노드, UDP 지원 또는 원격 서비스를 추가로 점검합니다.
TUN을 켠 뒤 인터넷에 연결되지 않을 때의 점검 순서
문제를 확인할 때 스택, DNS, 노드와 규칙을 동시에 바꾸지 마세요. 「서비스 권한 → 가상 네트워크 어댑터 → DNS → 규칙 → 노드」 순서로 단계별 확인하면 고장 지점을 더 빨리 찾을 수 있습니다.
| 증상 | 우선 확인할 항목 | 해결 방법 |
|---|---|---|
| TUN 스위치가 즉시 꺼짐 | 서비스 모드 또는 관리자 권한 | 시스템 서비스를 다시 설치하고 클라이언트를 재시작한 뒤 다시 켜기 |
| IP로는 연결되지만 도메인이 열리지 않음 | DNS 모듈과 53번 포트 하이재킹 | dns.enable, dns-hijack 및 업스트림 DNS 사용 가능 여부 확인 |
| 웹은 되지만 게임이나 음성이 실패함 | UDP, QUIC 및 노드 지원 여부 | UDP 로그를 확인하고 다른 노드 또는 스택 테스트 |
| 로컬 네트워크 장치에 접근할 수 없음 | strict-route 및 사설 네트워크 대역 규칙 | 엄격한 라우팅을 끄고 로컬 네트워크 대역에 DIRECT 추가 |
| 절전 모드 해제 후 인터넷이 끊김 | 출구 네트워크 어댑터 변경 및 남은 라우팅 | TUN을 껐다가 다시 켜고 필요하면 시스템 서비스를 재시작 |
| 특정 앱 하나만 실패함 | 앱 내장 DNS, IPv6 또는 인증서 정책 | 해당 앱의 연결 로그를 확인하고 IPv4와 UDP를 별도로 테스트 |
1단계: 기본 설정과 노드 자체가 정상인지 확인
TUN을 끄고 시스템 프록시를 켠 다음 브라우저로 현재 노드를 테스트합니다. 이때도 연결되지 않는다면 문제는 가상 네트워크 어댑터에 있지 않으므로 설정, 정책 그룹 또는 노드 상태부터 확인해야 합니다. TUN은 트래픽이 코어로 들어오는 방식을 바꿀 뿐, 작동하지 않는 노드를 고쳐주지는 않습니다.
2단계: DNS 문제와 라우팅 문제 구분
도메인은 실패하지만 알고 있는 IP에는 접속된다면 DNS부터 확인하는 것이 좋습니다. 클라이언트 로그에 DNS 질의가 없으면 dns.enable과 53번 포트 하이재킹을 확인하세요. 질의는 있지만 업스트림 시간 초과가 발생한다면 접근 가능한 업스트림 DNS로 바꾸고, 프록시 서버 도메인 해석에 사용하는 부트스트랩 DNS가 직접 연결되는지도 확인합니다.
도메인은 해석되지만 TCP 연결이 로그에 전혀 나타나지 않는다면 라우팅이 작성되지 않았거나 가상 네트워크 어댑터가 시작되지 않았거나, 다른 VPN이 트래픽을 먼저 처리하고 있을 가능성이 큽니다. 이때는 다른 VPN과 네트워크 필터링 도구를 먼저 종료한 뒤 TUN을 껐다가 다시 켜세요.
3단계: 로컬 네트워크와 가상 머신 네트워크 처리
일반적인 사설 주소에는 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16이 있습니다. 가정용 라우터, NAS와 프린터는 보통 DIRECT로 처리해야 합니다. 규칙은 기본 MATCH보다 앞에 배치해야 합니다. 예시는 다음과 같습니다.
rules:
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH, 노드 선택가상 머신과 컨테이너 네트워크도 이러한 주소 대역을 사용할 수 있으므로 모든 사설 주소를 기계적으로 TUN에서 제외해서는 안 됩니다. 가상 머신 내부 트래픽을 프록시해야 한다면 먼저 실제로 호스트의 어느 네트워크 어댑터를 통과하는지 확인한 뒤 DIRECT 규칙, 라우팅 제외 또는 가상 머신 내부의 별도 프록시 설정 중에서 선택하세요.
성능, IPv6 및 장기 사용 팁
TUN은 가상 네트워크 어댑터와 사용자 공간 처리 계층을 추가하지만, 일상적인 웹 브라우징과 다운로드 속도는 대개 노드 지연 시간, 회선 혼잡, 프로토콜 및 원격 서버의 영향을 더 크게 받습니다. 성능을 평가할 때는 같은 노드와 같은 대상 파일을 사용해 TUN을 끈 상태와 켠 상태를 각각 테스트하고, 각 조건에서 최소 3회 실행하세요. 한 번의 속도 측정만 비교하면 캐시와 순간적인 회선 변동의 영향을 받기 쉽습니다.
CPU 사용량이 높다면 먼저 로그 수준을 debug에서 info로 되돌리고 지속적인 연결 테스트를 중지한 뒤 특정 프로세스를 관찰하세요. UDP 세션이 많거나 P2P 소프트웨어를 사용하거나 DNS 질의가 빈번하면 연결 수가 크게 늘어날 수 있습니다. 데스크톱 클라이언트의 연결 페이지에서 비정상적으로 활발한 프로그램을 찾을 수 있습니다.
네트워크 조건을 확인하지 않은 상태에서 IPv6를 무조건 켜지 않기
로컬 네트워크, 프록시 노드와 규칙 세트가 IPv6를 제대로 지원한다면 관련 처리를 켤 수 있습니다. 통신사가 불안정한 IPv6만 제공하면 앱이 AAAA 주소에 우선 연결을 시도한 뒤 시간 초과를 기다리는 문제가 생길 수 있습니다. 점검할 때는 Clash 설정에서 IPv6를 잠시 끄고 동일한 대상의 연결 시간을 비교해 보세요. 특정 사이트 하나를 고치기 위해 운영체제 전체에서 IPv6를 영구적으로 비활성화하지는 마세요.
되돌릴 수 있는 설정 하나를 보관하기
- 현재 정상 작동하는 스택 유형, DNS 모드와 strict-route 상태를 기록합니다.
- 클라이언트 또는 mihomo 코어를 업데이트한 뒤 서비스 모드가 계속 실행 중인지 먼저 확인합니다.
- 구독을 업데이트한 뒤 정책 그룹 이름을 확인해 로컬 규칙이 더 이상 존재하지 않는 그룹을 가리키지 않도록 합니다.
- YAML을 수정하기 전에 클라이언트의 설정 검사 기능을 사용하고, 들여쓰기는 공백으로 통일합니다.
- 인터넷이 끊기면 먼저 TUN을 끄세요. 네트워크가 즉시 복구되면 이 글의 순서대로 항목을 하나씩 점검합니다.
TUN의 핵심은 가능한 모든 스위치를 켜는 것이 아니라 권한, 라우팅, DNS와 규칙이 완전한 경로를 이루게 하는 것입니다. 먼저 가상 네트워크 어댑터가 정상적으로 생성되었는지 확인하고, 로그로 트래픽이 코어에 들어왔는지 판단한 다음 적용된 규칙과 출구를 점검하세요. 이 순서대로 처리하면 브라우저는 되지만 데스크톱 프로그램은 연결되지 않는 문제, 켠 뒤 도메인이 작동하지 않는 문제, 로컬 네트워크 장치가 사라지는 문제를 명확한 점검 단계로 나눌 수 있습니다.