Clash TUN 모드 설정 방법: 가상 네트워크 인터페이스로 전체 트래픽 처리하기

TUN 모드가 필요한지 먼저 확인하기

먼저 시스템 프록시로 노드와 설정이 정상인지 확인한 뒤 TUN을 켜세요. 브라우저는 정상적으로 접속되지만 명령줄 도구, 게임 또는 시스템 프록시를 따르지 않는 앱이 계속 직접 연결된다면 가상 네트워크 인터페이스로 트래픽을 처리할 수 있습니다. TUN은 작동하지 않는 노드를 고쳐 주지 않으며, UDP 포워딩을 지원하지 않는 노드를 UDP 출구로 바꾸지도 않습니다.

TUN은 운영체제에서 제공하는 3계층 가상 네트워크 인터페이스입니다. 앱에서 보낸 IP 패킷이 이 인터페이스로 라우팅되면 커널이 패킷을 읽고 연결을 식별한 뒤 규칙에 따라 직접 연결하거나 프록시를 사용합니다. 일부 앱의 프록시 요청만 처리하는 시스템 프록시와는 동작하는 계층이 다릅니다.

시작 전 커널, 설정 및 권한 확인하기

TUN 설정을 명확히 제공하고 현재도 유지 관리되는 클라이언트를 우선 사용하세요. 아래 YAML 항목은 mihomo를 기준으로 합니다. 구버전 Clash, 다른 커널 포크 및 모바일 클라이언트는 지원하는 항목이 서로 다를 수 있습니다. 클라이언트의 ‘정보’ 또는 커널 정보 화면에서 실제 실행 중인 커널을 확인하세요. 앱 이름만으로 호환성을 판단하면 안 됩니다.

1. 사용 가능한 설정을 보관하세요.현재 설정을 내보내고 시스템 프록시 포트, 현재 모드, 선택된 정책을 기록해 두세요. 구독을 업데이트하면 구독 파일에 직접 입력한 수정 사항이 덮어써질 수 있으므로 클라이언트의 오버라이드 또는 병합 설정 기능을 우선 사용하세요.
2. 노드가 작동하는지 확인하세요.먼저 시스템 프록시를 켜고 프록시 접속이 필요한 웹페이지를 열어 보세요. 지연 시간 테스트에서 밀리초 값이 표시되는 것만으로는 대상 웹사이트나 UDP 서비스까지 정상이라고 볼 수 없습니다.
3. 다른 트래픽 처리 도구를 잠시 중지하세요.다른 VPN, 게임 가속기, 별도의 TUN 클라이언트 연결을 일시적으로 해제하세요. 회사 기기의 보안 소프트웨어나 VPN은 관리 정책에 따라 처리하고 임의로 제거하지 마세요.
4. 로컬 네트워크 접속 정보를 확인하세요.라우터, NAS, 프린터의 주소를 기록해 두세요. 예: 192.168.1.1. TUN을 켠 뒤에는 외부 네트워크뿐 아니라 이 주소들도 다시 확인해야 합니다.

시스템 프록시 포트와 DNS 수신 대기 포트는 용도가 다릅니다. 예를 들어 혼합 프록시 포트는 7890, DNS 수신 대기 주소는 127.0.0.1:1053으로 설정할 수 있습니다. 실제 값은 현재 적용된 설정을 기준으로 하세요. 프록시 포트를 시스템 DNS 주소에 입력하지 마세요.

OS별 가상 네트워크 인터페이스 설정

Windows: 서비스를 설치한 다음 TUN 켜기

mihomo 기반 데스크톱 클라이언트에서 먼저 ‘설정’으로 이동해 ‘서비스 모드’ 또는 ‘서비스 관리’를 찾아 설치하고 서비스가 실행 중인지 확인하세요. 서비스를 설치할 때 Windows 사용자 계정 컨트롤 창이 표시되는 경우가 많습니다. 그런 다음 홈 화면이나 프록시 설정으로 돌아가 ‘TUN 모드’ 또는 ‘가상 네트워크 인터페이스 모드’를 켜세요. 메뉴 이름은 현재 클라이언트 화면을 기준으로 확인하세요.

1. 먼저 ‘규칙 모드’를 유지하고, 작동이 확인된 정책을 선택하세요.
2. 서비스 모드를 켠 다음 TUN을 활성화하세요. 클라이언트에 ‘자동 라우팅’과 ‘출구 네트워크 인터페이스 자동 감지’ 옵션이 있다면 우선 기본 활성화 상태를 사용하세요.
3. 로그에 권한 거부, 네트워크 인터페이스 생성 실패 또는 라우트 추가 실패가 표시되는지 확인하세요. 스위치가 켜져 있어도 로그에 오류가 있다면 트래픽 처리가 정상적으로 시작된 것이 아닙니다.
4. 시스템 프록시를 끄고 앱 연결을 새로 만든 다음 브라우저, 터미널 및 로컬 네트워크 접속을 테스트하세요.

클라이언트에 서비스 모드가 없다면 관리자 권한으로 실행해야 할 수 있습니다. 먼저 해당 클라이언트의 권한 안내를 확인하세요. 일반 권한과 관리자 권한으로 클라이언트를 동시에 실행하지 마세요. 포트 점유와 라우팅 충돌이 발생하기 쉽습니다.

macOS: 보조 프로그램 또는 네트워크 권한 승인

클라이언트의 TUN 또는 네트워크 설정으로 이동해 안내에 따라 권한 있는 보조 프로그램을 설치하고 관리자 암호를 입력하거나, 시스템에서 요청하는 네트워크 관련 권한을 승인하세요. 클라이언트마다 구현 방식이 다를 수 있습니다. 시스템에서 해당 권한 요청이 표시될 때만 승인하면 되며, 출처를 알 수 없는 확장 프로그램을 직접 설치할 필요는 없습니다.

TUN을 켠 뒤 ifconfig로 네트워크 인터페이스를 확인하고 클라이언트 로그와 함께 생성 여부를 살펴보세요. macOS의 utun 인터페이스는 시스템 서비스나 다른 VPN이 만들 수도 있습니다. utun0, utun1이 보인다는 사실만으로 현재 Clash의 TUN이 정상 작동한다고 판단할 수는 없습니다.

Linux: TUN 장치와 네트워크 관리 권한 확인

먼저 시스템에 /dev/net/tun이 있는지 확인하세요. 커널에는 가상 네트워크 인터페이스 생성과 라우팅 변경에 필요한 권한이 있어야 합니다. 그래픽 클라이언트는 보통 보조 서비스를 통해 권한을 얻으며, 명령줄로 배포하는 경우 서비스 권한을 올바르게 설정해야 합니다. 일반 사용자에게 설정 파일 읽기·쓰기 권한만 부여해도 라우팅 작업의 권한 거부 문제는 해결되지 않습니다.

test -c /dev/net/tun && echo "TUN 장치가 있습니다"
ip link show
ip rule show
ip route show table all
ip route get 1.1.1.1

이 명령은 상태를 확인할 뿐 네트워크를 변경하지 않습니다. Docker, LXC 또는 제한된 VPS에서 실행한다면 호스트 환경에서 TUN 장치를 사용할 수 있고 필요한 네트워크 권한이 부여되어야 합니다. 컨테이너 안에서 root라고 해서 호스트의 네트워크를 자동으로 관리할 수 있는 것은 아닙니다. 원격 서버의 기본 라우트를 변경하기 전에는 콘솔 등 별도의 복구 경로를 준비하세요.

Android 및 iOS: 시스템 VPN 승인 기능 사용

Android에서 해당 기능을 지원하는 클라이언트는 보통 시스템 VPN 서비스를 통해 트래픽을 처리합니다. 처음 연결할 때 VPN 연결 요청이 표시되며, 대개 root 권한은 필요하지 않습니다. 앱별 프록시를 설정했다면 선택한 앱만 처리 범위에 들어갑니다. 시스템에서는 일반 VPN 서비스를 한 번에 하나만 활성화할 수 있는 경우가 많아 다른 VPN에 연결하면 현재 클라이언트의 연결이 끊길 수 있습니다.

iOS에서는 클라이언트가 제공하는 VPN 설정 및 연결 기능을 사용하고 시스템 안내에 따라 설정을 추가하세요. 데스크톱의 서비스 설치 절차는 iOS에 적용되지 않으며 데스크톱용 TUN YAML 전체를 그대로 사용해서도 안 됩니다. 모바일에서는 앱별 제외, 로컬 네트워크 접근, 백그라운드 실행 설정도 확인하세요.

mihomo TUN 및 DNS 가로채기 설정

먼저 항목을 병합한 뒤 설정을 다시 불러오세요. 아래는 사용 가능한 노드, 정책 그룹 및 규칙이 이미 있는 경우를 위한 설정 예시이며, 이것만으로 사용할 수 있는 완전한 구독 설정은 아닙니다. 같은 최상위 항목은 하나만 남기세요. 특히 dns:나 tun:을 중복으로 추가하지 마세요.

mixed-port: 7890
mode: rule

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
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

주요 옵션 3가지 이해하기

• auto-route: 커널이 트래픽 처리를 위한 라우트를 자동 설정합니다. 이 옵션을 끄면 보통 라우트를 직접 관리해야 하므로 처음 문제를 진단할 때 임의로 바꾸지 않는 것이 좋습니다.
• auto-detect-interface: 외부 연결에 사용하는 네트워크 인터페이스를 자동으로 감지해 프록시 연결이 다시 TUN으로 들어가는 루프를 방지합니다. 여러 네트워크 인터페이스, 다른 VPN 또는 특수 라우팅 환경에서는 실제 출구를 별도로 확인해야 합니다.
• dns-hijack: TUN으로 들어오는 지정된 DNS 트래픽을 내장 DNS가 처리하도록 전달합니다. 예시는 일반적인 UDP 53 및 TCP 53을 처리합니다. 앱에 내장된 DoH나 DoT를 자동으로 복호화하거나 모두 처리하지는 않습니다.

stack: system은 시스템 프로토콜 스택을 사용하도록 지정합니다. mihomo는 다른 프로토콜 스택도 지원하지만, 실제 지원 여부와 동작은 커널 버전 및 플랫폼에 따라 달라집니다. 우선 클라이언트에서 권장하는 기본값을 사용하세요. 호환성 문제가 생기면 라우팅, DNS, MTU를 한꺼번에 변경하지 말고 프로토콜 스택만 따로 바꿔 다시 확인하세요.

Fake-IP 주소와 실제 출구 주소 구분하기

Fake-IP 모드에서는 도메인에 내부 매핑용 주소를 할당합니다. 예를 들어 198.18.0.1/16 범위의 주소가 사용될 수 있습니다. 커널은 매핑 정보를 이용해 도메인을 복원하고 규칙을 적용합니다. 따라서 조회 결과가 이 대역에 있다고 해서 웹사이트 서버가 실제로 이 대역에 있거나 DNS 조회가 실패한 것은 아닙니다.

위 예시는 설정 구조를 설명하기 위해 IPv4 DNS 업스트림 두 개를 사용했습니다. 실제 네트워크에서는 연결 가능하고 분류 정책에 적합한 DNS를 선택하세요. dns.ipv6: false는 해당 DNS 모듈이 AAAA 레코드를 반환하지 않게 하는 설정이지, 운영체제의 IPv6를 끄거나 모든 IPv6 트래픽을 처리한다는 뜻은 아닙니다. 앱 자체의 암호화 DNS, 캐시, 하드코딩된 IP는 다른 경로를 사용할 수도 있습니다.

트래픽이 실제로 TUN을 통과하는지 확인하기

두 가지 트래픽 처리 경로를 구분하려면 시스템 프록시를 끈 뒤 테스트하세요. 터미널에 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY가 설정되어 있었다면 테스트 중에도 해당 변수를 우회해야 합니다. 그렇지 않으면 요청 성공은 명시적 프록시가 작동한다는 사실만 보여 줍니다.

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

Windows PowerShell에서는 실제 curl 프로그램을 실행하는 curl.exe를 사용할 수 있습니다. 여기서 --noproxy "*"는 curl의 명시적 프록시 설정을 우회하지만 운영체제의 TUN 라우팅은 우회하지 않습니다. 따라서 클라이언트의 연결 화면을 함께 확인하면 트래픽 처리 여부를 점검하는 데 유용합니다. 예시 웹사이트는 기본 HTTPS 확인용이므로 실제로 사용하는 대상도 테스트하세요.

1. 연결 화면을 확인하세요.방금 생성된 연결을 찾아 대상 도메인 또는 IP, 일치한 규칙, 최종 정책을 확인하세요.
2. 직접 연결 대상을 확인하세요.라우터나 NAS에 접속해 로컬 네트워크 연결이 정상이며 원격 노드를 잘못 거치지 않는지 확인하세요.
3. 프록시 대상 연결을 확인하세요.실제로 프록시가 필요한 앱에서 일치한 정책이 예상과 같은지 확인하세요.
4. UDP를 별도로 테스트하세요.실제 음성 통화, 게임 또는 다른 UDP 서비스로 확인하세요. HTTP 요청 성공이나 노드 지연 시간 정상 여부만으로 UDP를 테스트할 수는 없습니다.

모드를 바꾼 뒤에는 연결을 새로 만들어야 합니다. 브라우저의 장기 연결, 게임 세션 또는 다운로드 작업은 이전 연결을 계속 사용할 수 있습니다. 스위치만 바꾸고 요청을 다시 보내지 않으면 캐시된 결과를 현재 상태로 잘못 판단하기 쉽습니다.

TUN을 켠 뒤 인터넷에 연결되지 않을 때

먼저 문제가 발생한 계층 파악하기

권한, 라우팅, DNS, 정책 순서로 확인하기

먼저 로그를 확인하세요. permission denied나 이와 비슷한 작업 거부 메시지가 있으면 서비스 권한부터 해결하세요. 포트 점유 메시지가 나타나면 커널이 중복 실행 중인지 확인하세요. 이 단계에서 노드를 계속 바꿔도 대개 문제는 해결되지 않습니다.

그다음 출구와 라우팅을 확인하세요. TUN은 앱 트래픽을 커널로 전달하지만, 커널이 프록시 서버에 연결할 때는 물리 네트워크에 계속 접근할 수 있어야 합니다. 프록시 연결까지 다시 TUN으로 보내면 라우팅 루프가 생길 수 있습니다. 네트워크 인터페이스가 여러 개인 기기에서는 실제 기본 출구를 확인하고, 필요한 경우 현재 커널 문서에 따라 출구 인터페이스를 지정하세요. 시스템의 모든 라우트를 바로 삭제하지 마세요.

이어서 DNS를 확인하세요. nslookup example.com으로 조회 결과를 볼 수 있지만, 표시된 DNS 서버와 커널 로그도 함께 확인해야 합니다. Fake-IP가 내부 매핑 주소를 반환하는 것은 정상입니다. 시간 초과, 연결 거부, 업스트림 연결 불가는 추가 점검이 필요한 단서입니다. 브라우저에서 보안 DNS를 사용하는 경우 시스템 조회 결과와 브라우저 조회 결과도 따로 비교하세요.

마지막으로 일치한 규칙과 정책을 확인하세요. 규칙 모드에서 직접 연결 규칙의 범위가 너무 넓으면 대상이 프록시를 우회할 수 있습니다. 선택한 정책 그룹이 여전히 DIRECT를 가리킬 수도 있습니다. 작동이 확인된 정책으로 잠시 바꿔 비교하면 원인을 찾는 데 도움이 됩니다. 점검이 끝나면 원래의 트래픽 분류 설정으로 복원하고 새 연결에 실제로 어떤 규칙이 적용되는지 확인하세요.

증상이 일치할 때만 MTU 조정하기

연결은 성립하지만 큰 데이터를 전송할 때 멈추거나 특정 네트워크에서 문제가 반복되는 경우에만 MTU를 조정하세요. 현재 값을 기록한 뒤 mtu: 1400을 임시로 테스트하고, 필요하면 1280도 확인할 수 있습니다. 한 번에 하나씩만 변경하세요. 이 값들은 문제 진단을 위한 후보이며 모든 유선망, 모바일 네트워크 또는 터널 환경에 공통으로 적용되는 최적값은 아닙니다.

TUN을 끄고 네트워크 복구하기

먼저 클라이언트에서 TUN을 끈 뒤 클라이언트를 정상 종료해 커널이 자동 라우트를 정리하도록 하세요. 시스템 프록시도 함께 켜져 있었다면 시스템 프록시를 별도로 끄세요. TUN 스위치를 껐다고 시스템 프록시 설정까지 복구되는 것은 아닙니다.

• 다른 프록시 클라이언트나 VPN이 실행 중인지 확인하세요.
• 수동 입력한 시스템 DNS를 기존 설정으로 복원하세요. 원래 자동으로 가져오도록 설정했다면 자동 가져오기로 되돌리세요.
• 네트워크 문제가 계속되면 먼저 Wi-Fi 또는 유선 네트워크에 다시 연결한 뒤 기본 라우트를 확인하고, 필요한 경우 시스템을 재시작하세요.
• 원격 장치는 미리 준비한 콘솔을 통해 복구하는 것이 우선입니다. 라우트를 모두 지우거나 방화벽을 초기화하는 명령을 무작정 실행하지 마세요.

다시 켤 때는 ‘사용 가능한 노드, 규칙 모드, TUN 클라이언트 하나’만 사용하는 최소 구성으로 시작하세요. 사용자 지정 DNS, 앱별 제외, 다른 네트워크 도구를 하나씩 다시 설정하고 항목을 추가할 때마다 테스트하세요. 이렇게 하면 클라이언트를 반복해서 재설치하지 않고도 어떤 설정이 결과를 바꿨는지 파악할 수 있습니다.