Clash TUN 모드 설정 방법: Windows 가상 네트워크 어댑터와 서비스 모드

시스템 프록시와 TUN: 트래픽 진입 경로는 달라도 분기 규칙은 그대로 적용

브라우저는 접속되는데 터미널이나 게임 런처는 연결되지 않는다면, 해당 프로그램이 Windows 시스템 프록시 설정을 사용하지 않는 경우가 많습니다. 시스템 프록시는 127.0.0.1:7890 같은 프록시 주소를 제공하고, 사용할지는 각 앱이 결정합니다. PC의 모든 네트워크 연결을 자동으로 Clash에 전달하지는 않습니다.

TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 통해 조건에 맞는 IP 트래픽을 커널로 전달합니다. 앱에서 HTTP 또는 SOCKS 프록시를 지원하지 않아도 연결을 처리할 수 있습니다. 이 문서는 Windows 10·Windows 11과 mihomo 커널을 사용하는 Clash 클라이언트를 기준으로 합니다. 구형 Clash 커널은 설정 키, 드라이버, 화면 구성이 다를 수 있으므로 모든 설정을 그대로 적용할 수는 없습니다.

시작 전 준비: 구독, 커널, 네트워크 상태 확인

처음 구독을 가져오고, 노드를 바꾸고, DNS를 수정하고, TUN을 켜는 작업을 한 번에 하지 마세요. 먼저 정상 작동하는 기준 상태를 만들어 두면 문제가 생겼을 때 원인을 계층별로 찾기 쉽습니다.

1. 클라이언트와 커널 정보를 기록합니다. ‘설정’ → ‘정보’ 또는 클라이언트의 커널 정보 화면에서 버전을 확인하세요. 클라이언트 이름만으로 판단하지 말고 실제로 mihomo가 실행 중인지 확인해야 합니다.
2. 구독이 정상인지 확인합니다. 설정을 업데이트하고 연결 가능한 노드를 선택하세요. 잠시 시스템 프록시를 켠 뒤 프록시가 필요한 사이트와 직접 연결할 사이트에 각각 접속해 봅니다.
3. 로컬 포트를 기록합니다. 예를 들어 혼합 포트가 7890일 수 있습니다. 이는 HTTP/SOCKS 연결 포트이며 가상 네트워크 어댑터 포트나 DNS 수신 포트가 아닙니다.
4. 다른 네트워크 구성 요소를 확인합니다. 회사 VPN, 게임 가속기, 다른 프록시 클라이언트와 Hyper-V·WSL·Docker가 만든 가상 인터페이스를 포함해 확인하세요.
5. 복구 방법을 준비합니다. TUN 설정 위치를 기억해 두세요. 원격 데스크톱에서 라우팅을 바꾸기 전에는 현장 조작이나 다른 관리 경로를 확보해 연결이 끊겨도 복구할 수 있게 하세요.

첫 테스트에서는 다른 프록시와 가속기를 종료하고 필요한 네트워크 연결만 남기는 것이 좋습니다. 회사 관리 기기라면 먼저 네트워크 정책을 확인하세요. 설정을 켜기 위해 보안 소프트웨어, 방화벽 또는 조직의 접근 제어를 끄지 마세요.

서비스 모드를 설치한 다음 TUN 가상 네트워크 어댑터 켜기

1단계: 커널에 필요한 권한 부여

Windows에서 TUN 인터페이스를 만들고 라우팅을 조정하려면 적절한 권한이 필요합니다. 일반적으로 클라이언트의 백그라운드 서비스를 설치해 권한 상승이 필요한 작업을 처리합니다. 서비스 모드는 실행 권한과 백그라운드 관리를 위한 것이며, 노드 품질을 높이거나 TUN을 자동으로 켜 주지는 않습니다.

1. 클라이언트의 ‘설정’에서 ‘서비스 모드’, ‘Service Mode’ 또는 ‘Clash 서비스’를 찾으세요. 일부 클라이언트에서는 ‘설정’ → ‘Clash 설정’에 있습니다. 메뉴 위치와 이름은 사용 중인 버전을 기준으로 확인하세요.
2. ‘설치’ 또는 ‘서비스 설치’를 클릭하고 Windows 사용자 계정 컨트롤 안내를 승인합니다. 설치 중에는 클라이언트가 있는 폴더를 이동하지 마세요.
3. 화면에 ‘설치됨’ 또는 ‘실행 중’이 표시될 때까지 기다립니다. 커널이나 클라이언트를 다시 시작하라는 안내가 나오면 설정을 저장한 뒤 다시 시작하세요.
4. 설치에 실패하면 먼저 설치 로그와 보안 소프트웨어 기록을 확인하세요. 권한 문제인지 구분하기 위해 잠시 관리자 권한으로 실행해 볼 수 있지만, 출처를 알 수 없는 드라이버 패키지를 반복해서 설치해서는 안 됩니다.

서비스 상태를 확인해야 한다면 PowerShell에서 아래 읽기 전용 명령을 실행할 수 있습니다. 클라이언트마다 서비스 이름이 다르므로 검색 결과는 참고용입니다. 클라이언트 로그와 서비스 실행 파일 경로도 함께 대조하세요.

Get-Service | Where-Object {
  $_.Name -match 'clash|mihomo|verge' -or
  $_.DisplayName -match 'clash|mihomo|verge'
} | Format-Table Status, Name, DisplayName -AutoSize

2단계: TUN을 켜고 Rule 모드 유지

1. 클라이언트 설정이나 홈 화면의 스위치 영역에서 ‘TUN 모드’를 찾으세요. 하위 메뉴에 있다면 해당 화면으로 이동해 가상 네트워크 어댑터를 켭니다.
2. 처음에는 클라이언트가 권장하는 프로토콜 스택을 그대로 사용하고 자동 라우팅을 켜세요. MTU, 인터페이스 이름, 인터페이스 바인딩은 동시에 변경하지 마세요.
3. Rule 모드를 유지하고 앞에서 확인한 노드나 프록시 그룹을 사용하세요.
4. 로그에 인터페이스 생성 및 라우팅 설정 성공 메시지가 있는지 확인하세요. 화면의 스위치가 켜졌다고 해서 실제 트래픽이 처리되고 있다는 뜻은 아닙니다.

Win + R을 누르고 ncpa.cpl을 입력하면 ‘네트워크 연결’에서 새로 추가된 인터페이스를 확인할 수 있습니다. 인터페이스 이름은 클라이언트나 설정에 따라 달라 TUN이라는 이름이 아닐 수도 있습니다. 공유 속성을 변경하거나 기본 게이트웨이를 직접 입력하지 마세요.

DNS 리디렉션과 fake-ip: 도메인 이름 조회도 확인해야 하는 이유

TUN으로 연결이 들어온다고 해서 DNS가 반드시 예상대로 처리되는 것은 아닙니다. 앱이 라우터로 DNS 요청을 보내거나 브라우저의 보안 DNS를 통해 HTTPS로 조회할 수도 있습니다. 커널이 대상 IP와 도메인을 연결하지 못하면 도메인 기반 분기 규칙이 제대로 적용되지 않을 수 있습니다.

mihomo의 dns-hijack은 TUN을 통과하는 지정 DNS 트래픽을 내장 DNS 모듈로 전달할 수 있습니다. 일반적으로 UDP 53과 TCP 53을 가로채도록 설정합니다. 이는 모든 DNS 조회 방식을 가로채는 범용 설정이 아닙니다. DoH는 보통 HTTPS 443 포트를, DoT는 보통 853 포트를 사용하므로 일반 DNS의 53 포트와는 다릅니다.

mihomo 설정 키 예시

아래는 설정 키를 이해하기 위한 예시이며 완성된 구독 설정이 아닙니다. 노드, 프록시 그룹, 분기 규칙은 포함하지 않습니다. 기존 설정에 tun: 또는 dns:가 있다면 해당 블록에 합쳐야 하며, 같은 단계에 동일한 키를 중복해서 붙여 넣으면 안 됩니다.

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

• auto-route: 커널이 트래픽 처리를 위해 필요한 라우팅을 설정하도록 합니다. 끄면 라우팅을 직접 설계해야 하므로 처음 문제를 확인할 때는 권장하지 않습니다.
• auto-detect-interface: 트래픽이 나가는 인터페이스를 자동으로 찾습니다. 네트워크 어댑터가 여러 개이거나 회사 VPN을 사용하는 환경에서는 실제 인터페이스에 맞춰 조정해야 할 수 있으며, 모든 환경에서 정확히 감지된다고 보장할 수 없습니다.
• stack: system: 시스템 프로토콜 스택을 사용합니다. 클라이언트가 다른 스택을 권장한다면 먼저 기본값을 따르세요. 스택 변경은 주로 호환성 문제를 확인할 때 사용하며, 속도를 일률적으로 비교하는 기준은 아닙니다.
• listen: 127.0.0.1:1053: 내장 DNS가 로컬에서 요청을 받는 주소입니다. 일반 Windows DNS 주소 입력란에는 포트를 지정할 수 없으므로 ‘시스템 DNS 주소와 포트’처럼 그대로 사용할 수 없습니다.
• fake-ip: 도메인에 매핑 주소를 할당해 연결을 도메인과 연관 짓도록 합니다. 예시의 198.18.0.0/16 주소는 매핑에 사용되는 범위이며 원격 사이트의 실제 주소가 아닙니다.

예시 DNS 서버는 일반 DNS를 사용하므로 현재 네트워크에서 접속 가능한지에 따라 작동 여부가 달라지며 암호화된 조회를 제공하지 않습니다. 실제 환경에서는 이미 검증한 DNS 구성을 유지하세요. 노드 서버 도메인 조회, 회사 내부 도메인, 분기용 DNS에는 별도 설정이 필요할 수 있으며, 서버 주소 두 줄만 바꿔서는 모든 문제가 해결되지 않습니다.

설정 적용 후 캐시 비우기

구독을 업데이트할 때마다 덮어쓰이는 파일을 직접 수정하지 말고 클라이언트의 오버라이드, 확장 설정 또는 TUN/DNS 설정 메뉴를 우선 사용하세요. 적용한 뒤 커널을 다시 시작하고 명령 프롬프트에서 Windows DNS 캐시를 비웁니다.

ipconfig /flushdns

그런 다음 테스트할 앱을 완전히 종료했다가 다시 실행하세요. 브라우저 자체 DNS 캐시가 남아 있을 수 있습니다. 결과가 여전히 다르면 비교 테스트를 위해 브라우저의 ‘보안 DNS’를 잠시 끄고 결과를 기록한 뒤 필요한 설정을 복구하세요. TUN을 켜기 위해 암호화된 DNS를 항상 꺼 둬야 하는 것은 아닙니다.

트래픽 처리 확인: 터미널, 게임, 연결 로그 함께 살펴보기

터미널 테스트: 명시적 프록시는 우회하되 TUN은 유지

Windows PowerShell에서는 일부 환경에서 curl이 다른 명령으로 해석될 수 있으므로 curl.exe를 명시해 실행하는 것이 좋습니다. 먼저 클라이언트의 시스템 프록시를 끈 다음 아래 명령을 실행하세요.

curl.exe --noproxy "*" --connect-timeout 10 -I https://example.com/

--noproxy "*"는 이번 curl 요청에서 명시적 프록시를 사용하지 않도록 합니다. 일반적인 프록시 환경 변수도 적용되지 않지만, 시스템 라우팅이나 TUN을 우회하지는 않습니다. 따라서 시스템 프록시를 지원하지 않거나 사용하지 않는 프로그램의 요청이 TUN을 통해 커널에 들어오는지 확인하는 데 적합합니다. HTTP 응답이 왔다는 사실만으로 최종적으로 어떤 노드를 사용했는지 판단할 수는 없습니다.

• 클라이언트의 ‘연결’ 페이지를 열고 대상 도메인, 대상 IP 또는 프로세스 정보로 이번 요청을 찾아보세요.
• 적용된 규칙과 프록시 그룹 경로를 확인하세요. DIRECT로 표시되면 현재 정책에서 직접 연결하도록 설정된 것이므로 TUN이 작동하지 않는다고 단정할 수 없습니다.
• TUN을 끈 뒤 같은 명령을 다시 실행해 결과를 비교하세요. 원래 직접 연결할 수 있는 사이트라면 두 번 모두 성공하는 것이 정상입니다.
• 프록시 경로를 확인하려면 프록시가 필요한 것으로 확인된 접근 가능한 대상에 요청하고, 해당 규칙에서 프록시 정책이 선택됐는지도 확인하세요.

인터페이스와 라우팅을 확인할 때는 아래 읽기 전용 명령을 실행할 수 있습니다. 출력 결과로 변경 사항을 확인하되, 다른 PC의 인터페이스 번호를 그대로 따라 라우팅을 수동 추가하지 마세요.

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status -AutoSize
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object InterfaceIndex, DestinationPrefix |
  Format-Table InterfaceIndex, DestinationPrefix, NextHop, RouteMetric -AutoSize

게임 테스트: TCP 로그인과 UDP 대전을 구분하세요

게임 런처, 로그인, 다운로드, 실제 대전은 서로 다른 도메인과 프로토콜을 사용할 수 있습니다. 로그인은 되지만 방에 들어가지 못한다면 브라우저 속도만 볼 것이 아니라 대전 UDP 연결을 확인해야 합니다. TUN은 UDP 연결을 커널로 전달할 수 있지만, 선택한 노드와 전송 프로토콜, 서버, 설정도 해당 UDP 전달을 지원해야 합니다.

1. 게임과 런처를 완전히 종료한 뒤 TUN을 켜고 다시 실행해 새 연결이 현재 라우팅을 사용하도록 하세요.
2. ‘연결’ 페이지에서 게임의 TCP·UDP 기록, 대상 주소, 적용 규칙을 확인하세요.
3. 게임 트래픽이 로컬 네트워크 규칙, 대상 IP 규칙 또는 프로세스 규칙에 따라 DIRECT로 분기되는지 확인하세요.
4. UDP를 명시적으로 지원하는 노드로 바꿔 비교 테스트하세요. 노드 지연 시간 테스트에 성공해도 게임 UDP 연결이 작동한다는 뜻은 아닙니다.

TUN은 게임 전용 가속 회선이 아닙니다. 해외 구간 경로, 노드 혼잡, 게임 서버 위치, 부정행위 방지 프로그램과의 호환성 등이 결과에 영향을 줍니다. TUN을 켜면 지연 시간이 줄어든다고 보장할 수 없습니다. 관리 대상 게임이나 업무 환경에서는 해당 서비스의 이용 규칙도 준수하세요.

자주 발생하는 문제: 권한, 라우팅, DNS, 정책 순으로 점검

WSL, Docker, 다른 VPN은 일반 데스크톱 앱과 다르게 처리됩니다

WSL 2, 컨테이너, 가상 머신은 별도의 가상 스위치, NAT 또는 미러 네트워크를 사용할 수 있습니다. 호스트 앱의 트래픽이 TUN으로 들어가도 게스트 환경이 같은 경로를 사용한다는 뜻은 아닙니다. 각 환경에서 DNS, 기본 라우팅, 연결 기록을 따로 확인하세요. Windows 브라우저가 정상이라고 해서 모든 트래픽이 처리된다고 판단하면 안 됩니다.

회사 VPN을 켠 뒤 인터넷이 끊긴다면 먼저 두 프로그램이 동시에 라우팅이나 DNS를 변경하는지 확인하세요. 다른 네트워크를 ‘강제로 덮어쓰기’ 위해 엄격 라우팅을 함부로 켜지 마세요. 로컬 네트워크와 다른 인터페이스의 접속이 달라질 수 있습니다. 네트워크 어댑터가 여러 개라면 유지해야 할 내부망 경로를 확인한 뒤 인터페이스 바인딩과 우회 규칙을 결정하세요.

인터넷이 끊겼을 때 복구하는 순서

1. TUN을 끄고 인터페이스와 라우팅이 복구될 때까지 기다린 다음 일반 직접 연결을 테스트하세요.
2. 클라이언트를 종료할 예정이라면 시스템 프록시도 끄세요. 클라이언트가 종료된 뒤에도 Windows가 더 이상 요청을 받지 않는 127.0.0.1:7890을 가리키지 않도록 해야 합니다.
3. 방금 변경한 DNS 또는 오버라이드 설정을 복구한 뒤 클라이언트 커널을 다시 시작하세요.
4. 문제가 계속되면 로그와 인터페이스 정보를 저장한 뒤 Windows를 다시 시작하세요. 모든 네트워크 어댑터를 제거하거나 네트워크 스택 전체를 초기화하는 조치는 첫 번째로 시도하지 마세요.

설정 완료 후 확인 목록

정상적인 TUN 설정은 ‘인터페이스 생성, 앱 트래픽의 커널 전달, 규칙의 올바른 적용, 일상적인 네트워크 사용 가능’ 네 가지를 모두 충족해야 합니다. 스위치 상태만 확인해서는 안 됩니다. 아래 항목을 점검한 뒤 클라이언트의 Windows 시작 시 자동 실행을 고려하세요.

• 권한: 백그라운드 서비스가 정상 실행 중이고, 커널 로그에 인터페이스 생성 실패나 권한 오류가 반복되지 않습니다.
• 트래픽 처리: 시스템 프록시를 꺼도 테스트한 터미널 요청이 클라이언트의 연결 페이지에 표시됩니다.
• 정책: 프록시 대상에는 예상한 프록시 그룹이 적용되고, 직접 연결 대상과 로컬 네트워크 리소스는 의도한 경로를 유지합니다.
• DNS: 자주 사용하는 도메인이 정상적으로 조회되고, 내부 도메인이 공용 DNS 서버로 잘못 전달되지 않습니다.
• 프로토콜: 필요한 UDP 앱은 개별적으로 확인하고, TCP 다운로드 속도로 게임 연결을 판단하지 않습니다.
• 복구: TUN을 끄고 클라이언트를 종료한 뒤 시스템 프록시와 네트워크 접속 상태가 예상대로 돌아옵니다.

나중에 특정 앱에서만 문제가 생기면 전체 설정을 바로 바꾸지 말고 해당 앱의 연결 기록과 규칙부터 확인하세요. 기본 포트, 구독, 트래픽 분기 설정은 Clash 사용 가이드에서 확인할 수 있습니다. 설정 키를 확인하려면 프로토콜 레퍼런스를 참고하세요.