Clash TUN 모드 설정

TUN이 트래픽을 처리하는 방식

Clash TUN 모드는 가상 네트워크 인터페이스로 IP 패킷을 받은 뒤, 코어가 연결을 식별하고 규칙을 적용해 출구를 선택합니다. 시스템 프록시 설정을 읽지 않는 명령줄 도구, 게임, 자체적으로 네트워크 연결을 만드는 데스크톱 앱 등을 처리할 때 유용합니다. 사용 전에 클라이언트의 코어가 TUN을 지원하는지 확인하세요. 클라이언트 이름이 같아도 배포 패키지마다 코어와 권한 설정이 다를 수 있습니다.

이 문서의 설정은 Clash Meta에서 발전한 mihomo를 기준으로 합니다. 원본 Clash, 구형 Premium 코어 및 다른 포크에서는 사용할 수 있는 설정 키가 다를 수 있습니다. 먼저 클라이언트의 코어 정보나 시작 로그에서 실제 코어를 확인한 뒤 해당 문서에 따라 설정을 점검하세요. 화면에 ‘TUN’ 스위치가 있다고 해서 모든 설정 항목이 적용되는 것은 아닙니다.

1. 앱에서 연결 시작: 운영체제가 대상 주소에 맞는 라우팅 테이블을 조회합니다.
2. 라우팅을 가상 인터페이스로 전달: 처리 대상에 해당하는 패킷은 물리 네트워크 인터페이스로 바로 나가지 않고 TUN으로 들어갑니다.
3. 코어에서 트래픽 분류: 도메인, IP, 프로세스 등의 규칙에 따라 프록시, 직접 연결 또는 차단을 선택합니다.
4. 출구로 연결 전달: 프록시 연결도 실제 네트워크 인터페이스를 거쳐야 합니다. 코어가 자체 외부 연결을 다시 TUN으로 보내는 루프를 방지해야 합니다.

TUN과 시스템 프록시의 차이

시스템 프록시는 보통 HTTP 또는 SOCKS 프록시 주소를 지원하는 앱에 전달합니다. 로컬 127.0.0.1:7890을 예로 들면, 이 주소를 사용하도록 설정된 연결만 코어로 전달됩니다. 반면 TUN은 네트워크 인터페이스와 라우팅을 이용하므로 앱이 프록시 포트를 인식할 필요가 없습니다.

‘전체 트래픽’은 이해를 돕기 위한 표현이지, 모든 트래픽이 빠짐없이 처리된다는 보장은 아닙니다. 기존 연결, 처리 대상에서 빠진 IPv6 경로, 다른 VPN의 우선 라우팅, 플랫폼별 제한에 따라 실제 범위가 달라질 수 있습니다. 어떤 앱의 트래픽을 처리할지 먼저 정하고 연결 로그로 확인하세요. 스위치가 켜졌는지만으로 판단하지 마세요.

처음 문제를 확인할 때는 변수를 줄이기 위해 시스템 프록시를 끄고 TUN만 켜는 것이 좋습니다. 두 기능을 함께 사용할 수도 있지만, 동시에 켜면 브라우저 접속에 성공해도 TUN이 정상이라는 뜻은 아닙니다. 브라우저가 여전히 시스템 프록시 포트를 통해 연결했을 수 있습니다.

활성화 전에 확인할 세 가지

먼저 프록시 출구가 작동하는지 확인

시스템 프록시로 정상 접속을 한 번 테스트해 구독이 가져와졌는지, 정책 그룹에 사용할 수 있는 노드가 있는지, 규칙에서 존재하지 않는 정책 이름을 참조하지 않는지 확인하세요. 노드 연결 실패, 빈 구독, 인증 오류는 TUN을 켠다고 해결되지 않습니다. 문제를 확인할 때는 기존 설정을 백업하고 한 번에 한 종류의 항목만 변경하세요.

서비스 권한과 네트워크 환경 확인

• Windows: 클라이언트에서 제공하는 서비스 모드를 우선 사용하세요. 관리자 권한으로 서비스를 설치한 뒤 서비스가 코어를 실행하도록 설정하면 됩니다. 일반 앱을 모두 관리자 권한으로 실행할 필요는 없습니다.
• macOS: 클라이언트가 보조 프로그램을 통해 네트워크 관리 권한을 요청할 수 있습니다. 시스템 안내에 따라 권한을 허용하고, 보안 소프트웨어가 인터페이스 생성을 차단하지 않는지 확인하세요.
• Linux: TUN 장치 생성과 라우팅 변경에는 보통 root 권한 또는 적절한 네트워크 관리 권한이 필요합니다. 컨테이너에서는 /dev/net/tun에 접근할 수 있어야 합니다. 프로세스 권한만 높이는 것으로 충분하지 않을 수 있습니다.

다른 터널은 잠시 중지

먼저 다른 VPN, 게임 가속기 및 유사 프록시 클라이언트의 연결을 끊으세요. 회사 VPN이나 가상 머신 네트워크를 반드시 꺼야 하는 것은 아니지만, 처음 확인할 때는 환경을 최대한 단순하게 유지하는 것이 좋습니다. 함께 사용해야 한다면 두 클라이언트가 기본 경로를 계속 덮어쓰게 두지 말고, 라우팅 접두사와 우선순위를 확인해야 합니다.

mihomo TUN 설정 예시

아래 내용은 기존 설정에 추가할 부분이며, 노드까지 포함된 전체 구독 파일이 아닙니다. 기존 proxies, proxy-groups, rules는 그대로 유지하세요. 원본 파일에 tun 또는 dns가 이미 있다면 해당 부분을 수정하고, 같은 계층에 동일한 키를 중복해서 추가하지 마세요.

mixed-port: 7890
mode: rule
log-level: info

tun:
  enable: true
  stack: mixed
  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:
    - 1.1.1.1

stack: 패킷 처리 방식 선택

mihomo에서 흔히 사용하는 값은 system, gvisor, mixed입니다. system은 시스템 네트워크 스택 관련 구현을 사용하고, gvisor는 사용자 공간 네트워크 스택을 사용합니다. mixed는 보통 TCP를 system으로, UDP를 gVisor로 처리합니다. 지원 여부는 플랫폼과 코어 빌드에 따라 다릅니다.

처음 설정할 때는 클라이언트의 기본값을 그대로 사용해도 됩니다. 예시는 mixed를 사용합니다. 특정 연결 문제가 재현될 때만 스택을 바꾸고 코어를 재시작해 다시 테스트하세요. 스택은 성능 순위가 아니므로 특정 스택이 모든 기기에서 더 빠르다고 단정할 수 없습니다.

auto-route와 출구 인터페이스

auto-route: true를 설정하면 코어가 트래픽 처리에 필요한 라우팅을 자동으로 구성합니다. 관리자 권한을 대신해 주는 설정은 아닙니다. auto-detect-interface: true는 외부 연결에 사용할 인터페이스를 자동으로 찾아 프록시의 외부 연결이 자체 터널로 되돌아가는 일을 방지합니다. Wi-Fi, 유선 네트워크, VPN을 함께 사용하는 경우에도 감지 결과를 확인하세요.

절전 모드에서 깨어나거나 Wi-Fi를 바꾼 뒤에만 연결이 끊긴다면 코어를 재시작해 출구 인터페이스를 다시 감지하게 한 다음 라우팅을 점검하세요. 물리 네트워크 인터페이스 주소를 설정에 바로 고정하지 마세요. 네트워크를 바꾸면 고정된 인터페이스 이름이 더 이상 유효하지 않을 수 있습니다.

dns-hijack과 DNS 수신 포트

any:53은 TUN으로 들어오는 일반 UDP DNS 요청을 처리하며, tcp://any:53은 해당 TCP DNS 요청을 처리합니다. 두 설정은 조건에 맞는 요청을 코어의 DNS 모듈로 전달합니다. 시스템 DNS 서버 주소가 127.0.0.1:1053이어야 하는 것은 아닙니다.

반면 listen: 127.0.0.1:1053은 DNS 모듈이 별도로 제공하는 로컬 수신 주소입니다. mixed-port: 7890과 용도가 다르므로 7890을 DNS 포트로 사용하면 안 됩니다. 앱 자체의 DoH나 DoT는 일반적인 53번 포트 DNS가 아니므로 이 두 가로채기 규칙만으로 직접 차단할 수 없습니다.

Windows·macOS·Linux에서 TUN 켜기

Windows: 서비스를 시작한 다음 TUN 활성화

1. 클라이언트 설정에서 TUN을 지원하는 mihomo 코어를 사용 중인지 확인하고 구독 연결을 테스트합니다.
2. 서비스 모드 또는 서비스 관리 메뉴를 찾아 안내에 따라 서비스를 설치하고 시작합니다. 메뉴 이름은 클라이언트마다 다를 수 있으므로 현재 화면을 기준으로 진행하세요.
3. TUN을 켠 뒤 로그에 권한, 인터페이스 생성 또는 라우팅 추가 오류가 있는지 확인합니다.
4. 「설정」→「네트워크 및 인터넷」→「프록시」를 열고 브라우저가 시스템 프록시를 계속 사용하는지 확인할 수 있도록 수동 프록시를 잠시 끕니다.
5. PowerShell에서 네트워크 인터페이스와 IPv4 라우팅을 확인한 뒤 새 연결을 시도합니다.

Get-NetAdapter -IncludeHidden
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object DestinationPrefix, RouteMetric
curl.exe --noproxy "*" -I https://example.com/

--noproxy "*"를 지정하면 이번 curl 요청에서 명시적 프록시를 사용하지 않지만, TUN 라우팅을 우회하지는 않습니다. 예시 주소는 연결 확인용입니다. 접속에 성공한 뒤에도 클라이언트 연결 목록에서 해당 요청의 규칙과 출구를 확인하세요. 일부 터널 인터페이스는 네트워크 인터페이스 목록에 완전히 표시되지 않을 수 있으므로 라우팅과 로그도 함께 확인해야 합니다.

macOS: 권한을 허용하고 라우팅 확인

1. 클라이언트 설정에서 필요한 보조 프로그램을 설치하거나 활성화하고 시스템 권한 요청을 승인합니다.
2. 다른 VPN을 끈 뒤 TUN을 활성화합니다. 「시스템 설정」→「네트워크」에서 동시에 활성화된 네트워크 터널이 있는지 확인하세요.
3. 시스템 프록시의 영향을 제외하려면 현재 네트워크 서비스의 「세부사항」→「프록시」에서 HTTP, HTTPS, SOCKS 프록시 설정을 확인하세요.
4. 터미널에서 인터페이스와 라우팅을 확인한 뒤 클라이언트 연결 로그를 대조하며 테스트합니다.

ifconfig
netstat -rn -f inet
route -n get 1.1.1.1
curl --noproxy '*' -I https://example.com/

macOS의 가상 인터페이스 이름에는 utun이 자주 포함되지만, 다른 시스템 서비스도 이런 인터페이스를 만들 수 있습니다. utun이 하나 보인다고 해서 현재 클라이언트가 만든 인터페이스라는 뜻은 아닙니다. 활성화 전후의 변화를 비교하고 테스트 대상이 실제로 사용하는 경로도 확인해야 합니다.

Linux: 장치·권한·정책 라우팅 확인

GUI 클라이언트는 보통 권한 상승이나 서비스 설치 절차를 제공합니다. 코어를 직접 실행한다면 먼저 설정 문법을 확인하고, 미리 구성한 시스템 서비스를 통해 시작하세요. 빠르게 테스트하려고 일반 앱이나 사용자 디렉터리 전체에 지나치게 넓은 권한을 부여하지 마세요.

mihomo -t -f config.yaml
test -c /dev/net/tun && echo "TUN device available"
ip link show
ip rule show
ip route show table all
curl --noproxy '*' -I https://example.com/

mihomo -t는 주로 설정을 해석할 수 있는지 확인하며, 실행 중 라우팅 권한이 있는지는 검증하지 않습니다. Linux는 정책 라우팅 테이블을 사용할 수도 있으므로 기본 라우팅 테이블만 보면 트래픽 처리 규칙을 놓칠 수 있습니다. ip rule과 모든 라우팅 테이블을 함께 확인하세요.

트래픽 처리·DNS·UDP 확인

제대로 검증하려면 단계별로 확인해야 합니다. 웹페이지가 열린다는 사실은 특정 접속 경로가 작동한다는 것만 보여 줍니다. DNS, UDP, IPv6 및 모든 앱이 예상대로 작동한다고 증명하지는 않습니다. 다음 순서로 확인하는 것이 좋습니다.

1. 인터페이스 단계: 활성화 전후의 가상 인터페이스와 라우팅을 비교하고, 오류가 계속 발생하지 않는지 확인합니다. 모든 플랫폼에서 인터페이스 이름이나 기본 라우팅 항목이 완전히 같을 필요는 없습니다.
2. 연결 단계: 시스템 프록시를 끄고 --noproxy를 지정한 curl로 새 연결을 만든 다음, 클라이언트 연결 목록에서 해당 요청을 찾습니다.
3. 규칙 단계: 적용된 규칙과 정책 그룹을 확인합니다. DIRECT가 선택된 것은 트래픽 분류 결과이며, TUN이 자동으로 작동을 멈췄다는 뜻이 아닙니다.
4. DNS 단계: DNS 로그를 확인해 일반 53번 포트 요청, 앱의 암호화 DNS, 캐시된 요청을 구분합니다.
5. UDP 단계: 실제로 UDP를 사용하는 앱으로 테스트하고, 선택한 노드와 프로토콜이 UDP 전달을 지원하는지 확인합니다. TCP 테스트 성공만으로 UDP가 작동한다고 볼 수 없습니다.

Fake-IP를 사용하면 처리된 일부 도메인의 DNS 조회 결과가 198.18.0.0/16 범위의 매핑 주소로 반환될 수 있습니다. 이는 설정에 따른 정상 동작이며 웹사이트의 실제 공인 IP 주소가 아닙니다. 필터링된 도메인, 별도의 암호화 DNS를 사용하는 앱, 캐시된 요청은 다르게 동작할 수 있습니다.

TUN 활성화 후 인터넷이 끊길 때 점검 순서

로컬 네트워크 프린터, NAS 또는 라우터 관리 페이지에 접속할 수 없다면 먼저 대상 사설 IP에 어떤 규칙이 적용되는지 확인하세요. 프록시 출구로 전달되고 있다면 실제 네트워크 대역에 맞춰 직접 연결 규칙을 추가합니다. 이미 직접 연결 중인데도 실패한다면 로컬 네트워크 라우팅과 방화벽을 확인하세요. 모든 로컬 네트워크 문제를 Fake-IP 탓으로 돌리지는 마세요.

규칙을 조정하면 출구 선택 문제는 해결할 수 있지만, 패킷이 코어에 들어오지 않는다면 도메인 규칙을 추가해도 소용이 없습니다. 프록시 노드에 연결할 수 없는 경우에도 stack을 반복해서 바꾼다고 해결되지 않습니다. 다음 설정 변경 전에 ‘문제가 발생한 앱, 대상, 적용된 규칙, 오류 로그, 다른 VPN 사용 여부’ 다섯 가지를 기록하세요.

구독 업데이트와 종료 후 복구

일부 클라이언트는 TUN 스위치를 로컬 설정으로 저장하고, 다른 클라이언트는 화면의 옵션을 실행 설정에 병합합니다. 구독 파일을 편집한 뒤 원격 업데이트를 하면 수정 사항이 덮어써질 수 있습니다. 클라이언트가 지원하는 재정의·병합·영구 설정 기능을 사용하고, 업데이트 후에는 편집기에 저장된 내용만 보지 말고 실제 적용된 설정을 확인하세요.

사용을 마칠 때는 먼저 TUN을 끈 다음 클라이언트를 정상 종료해 코어가 자동으로 만든 라우팅을 정리하도록 하세요. 프로세스가 비정상 종료된 뒤에도 네트워크가 정상화되지 않으면 클라이언트를 다시 실행하고 TUN을 꺼서 정리한 뒤 시스템 프록시가 남아 있는지도 확인하세요. 출처를 모르는 상태에서 시스템 라우팅을 한꺼번에 삭제하지 마세요.

• 브라우저에만 프록시가 필요하다면 시스템 프록시가 설정과 문제 해결이 더 간단합니다.
• 프록시를 지원하지 않는 앱까지 처리해야 한다면 TUN을 켜고 라우팅과 연결 기록을 확인하세요.
• 여러 VPN을 함께 사용해야 한다면 각 VPN이 처리할 주소 범위를 먼저 정한 뒤 규칙과 라우팅을 설계하세요.
• 문제를 더 자세히 확인하려면 문제 해결을 참고하세요. 구독 가져오기와 모드 설정은 Clash 설정 가이드에서 확인할 수 있습니다.