먼저 구현 방식 확인: TUN에 시스템 확장이 항상 필요한 것은 아닙니다

macOS에서 Clash TUN을 켤 때 핵심은 코어에 가상 네트워크 인터페이스 생성 및 라우팅 조정 권한을 부여하는 것입니다. mihomo를 사용하는 클라이언트는 보통 특권 보조 서비스를 설치한 뒤 코어가 운영체제에서 제공하는 utun 인터페이스를 사용합니다. Apple Network Extension을 사용하는 앱은 VPN 구성을 추가하거나 네트워크 확장을 승인해야 할 수 있습니다. 두 방식은 서로 다르므로 혼동하지 말고, 모두 진행할 필요도 없습니다.

이 글은 macOS 13 이상에서의 시스템 설정 구성을 기준으로 보조 서비스 방식과 네트워크 확장 방식을 각각 설명합니다. 메뉴 이름은 클라이언트 버전에 따라 다를 수 있으므로 작업 전에 ‘정보’ 또는 ‘코어’ 화면에서 클라이언트 버전, mihomo 버전, macOS 버전을 확인하세요. Apple Silicon Mac에는 arm64 빌드를, Intel Mac에는 x86_64 빌드를 우선 선택하세요. 프로세서 아키텍처와 네트워크 권한은 별개입니다.

가상 네트워크 인터페이스는 IP 트래픽을 처리하며, 모든 연결을 자동으로 프록시하는 것은 아닙니다

TUN은 3계층 가상 네트워크 인터페이스입니다. 앱이 만든 IP 패킷은 시스템 라우팅을 거쳐 가상 인터페이스로 전달되고, 프록시 코어가 이를 읽어 규칙에 따라 프록시 노드를 선택하거나 직접 연결 또는 연결 거부를 수행합니다. 시스템 HTTP 프록시 설정을 따르지 않는 여러 프로그램의 트래픽도 처리할 수 있지만, 실제 범위는 라우팅, 제외 목록, IPv6 설정 및 다른 VPN의 영향을 받습니다.

따라서 ‘TUN 켜기’와 ‘모든 트래픽 프록시’는 별개의 설정입니다. 규칙 모드에서 TUN을 사용해도 DIRECT에 해당하는 연결은 직접 연결됩니다. 전역 모드로 전환해도 시스템에서 제외된 트래픽까지 모두 코어를 거친다고 단정할 수 없습니다. UDP 사용 가능 여부는 선택한 노드와 프로토콜, 서버 지원 여부에 따라 달라집니다.

시스템 프록시와 TUN: 앱 용도에 맞게 선택

항목 시스템 프록시 TUN 모드
트래픽 유입 경로 앱이 시스템 프록시를 읽고 로컬 프록시 포트에 연결 시스템 라우팅이 일치하는 IP 패킷을 가상 인터페이스로 전달
주요 사용 사례 브라우저 및 시스템 프록시를 따르는 데스크톱 앱 일부 명령줄 도구, 게임 및 프록시 설정을 읽지 않는 앱
UDP 처리 일반 HTTP 프록시는 UDP를 범용으로 전달할 수 없음 UDP를 받을 수 있지만, 출구에서도 UDP 전달을 지원해야 함
필요한 권한 시스템 프록시 설정 변경 시 권한이 필요할 수 있음 일반적으로 보조 서비스 또는 네트워크 확장 승인 필요
장애 영향 범위 주로 프록시를 사용하는 앱에 영향 라우팅 또는 DNS 오류 시 Mac 전체의 네트워크 연결에 영향 가능

Safari로 웹사이트에 접속하는 정도라면 우선 시스템 프록시를 사용하세요. 브라우저는 되지만 터미널 도구가 직접 연결한다면 먼저 해당 도구의 프록시 옵션을 확인한 뒤 TUN 사용 여부를 결정하세요. TUN은 더 많은 트래픽을 처리하지만 라우팅과 DNS 점검 항목도 늘어납니다. 지연 시간을 줄이는 스위치가 아닙니다.

시스템 프록시로 노드부터 확인하기

  1. 구독을 가져와 업데이트한 뒤, 클라이언트의 구문 검사에서 설정 오류가 없는지 확인하세요.
  2. 규칙 모드를 선택하고 프록시 그룹에서 사용할 노드를 지정하세요.
  3. 시스템 프록시를 켜고 브라우저에서 필요한 서비스에 접속한 다음 연결 로그를 확인하세요.
  4. 노드가 정상 작동하는 것을 확인한 뒤 시스템 프록시를 끄고 TUN만 별도로 테스트하세요. 두 트래픽 경로를 혼동하지 않는 데 도움이 됩니다.

일부 클라이언트에서는 시스템 프록시와 TUN을 동시에 사용할 수 있지만, 처음 문제를 진단할 때는 유입 경로를 하나만 유지하는 편이 좋습니다. 노드의 핸드셰이크 자체가 실패한다면 TUN으로 바꿔도 만료된 구독, 잘못된 노드 비밀번호 또는 연결할 수 없는 서버 문제는 해결되지 않습니다.

시작 전: 설정 백업 및 네트워크 상태 기록

클라이언트를 ‘응용 프로그램’ 폴더로 옮긴 뒤 그 위치에서 실행하세요. 디스크 이미지에서 바로 실행하거나 서비스를 설치한 후 앱을 이동하면 보조 서비스가 가리키는 프로그램 경로와 현재 설치 위치가 달라질 수 있습니다. 현재 설정, 오버라이드 파일, 프록시 그룹 선택을 백업하세요. 구독 링크에는 접근 정보가 포함되므로 공개 문의 게시판에 붙여 넣지 마세요.

  • 다른 터널 연결 해제: 다른 VPN, TUN 프록시 및 라우팅을 제어할 수 있는 네트워크 도구를 일시적으로 연결 해제하세요. 회사 기기라면 관리 정책을 먼저 확인하고, 회사에서 배포한 네트워크 구성을 삭제하지 마세요.
  • DNS 설정 기록: ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘DNS’를 열어 수동으로 입력한 서버 주소를 기록하세요.
  • 로컬 포트 확인: 클라이언트에서 실제 HTTP, SOCKS 또는 혼합 포트를 확인하세요. 아래의 7890은 예시이며 모든 클라이언트의 고정값이 아닙니다.
  • 오프라인 복구 경로 확보: 미리 클라이언트 설정을 열어 TUN 스위치와 보조 서비스 관리 메뉴를 확인하세요. 네트워크가 끊긴 뒤에 복구 방법을 찾지 않도록 준비하는 것이 좋습니다.

‘응용 프로그램’ → ‘유틸리티’ → ‘터미널’에서 아래 읽기 전용 명령을 실행하면 전환 전 상태를 기록할 수 있습니다. 출력에 네트워크 주소와 인터페이스 정보가 포함되므로 로그를 공유하기 전에 민감한 정보를 가리세요.

sw_vers
uname -m
scutil --proxy
scutil --dns
route -n get 1.1.1.1
ifconfig -l

uname -m은 Apple Silicon에서 네이티브로 실행한 터미널에서 보통 arm64를 반환합니다. 터미널이 Rosetta로 실행 중이면 x86_64로 표시될 수 있으므로 Apple 메뉴 → ‘이 Mac에 관하여’에서 기기 모델도 확인하세요. route -n get은 지정한 대상의 라우팅 경로를 보여 주므로, 기본 경로만 확인하는 것보다 TUN 적용 여부를 검증하기에 적합합니다.

방법 1: 보조 서비스 설치 후 mihomo TUN 켜기

설정 화면에 ‘서비스 모드’, ‘보조 서비스’ 또는 ‘특권 서비스’가 있다면 보통 이 방법을 사용합니다. 아래는 일반적인 진행 순서이며 모든 클라이언트의 메뉴 이름이 같다는 뜻은 아닙니다. 현재 앱에 표시되는 안내와 프로젝트 문서를 기준으로 진행하세요.

  1. 클라이언트의 ‘설정’으로 이동해 서비스 관리 항목을 찾고 ‘설치’ 또는 ‘보조 서비스 설치’를 클릭하세요. 직접 이 작업을 시작한 경우에만 시스템 인증 요청을 승인하세요.
  2. 관리자 계정으로 승인하세요. 시스템에서 암호 입력이나 Touch ID를 요구할 수 있습니다. 계정에 관리자 권한이 없다면 기기 관리자에게 문의하세요.
  3. 화면에 서비스가 실행 중이라고 표시될 때까지 기다린 뒤 클라이언트 안내에 따라 코어를 다시 시작하세요. 설치 버튼이 사라졌다는 이유만으로 서비스가 정상 실행된다고 판단하지 마세요.
  4. 네트워크 또는 TUN 설정으로 이동해 TUN 모드를 켜고, 첫 테스트에서는 클라이언트가 권장하는 프로토콜 스택과 라우팅 옵션을 유지하세요.
  5. 시작 로그에서 권한 부족, 인터페이스 생성 실패 또는 라우팅 추가 실패가 없는지 확인한 다음 실제 연결이 로그에 표시되는지 점검하세요.

특권 보조 서비스는 일반적으로 시스템 서비스 관리 기능으로 실행되며, 타사 커널 확장과는 다릅니다. 이때 ‘시스템 확장 허용’ 버튼이 보이지 않아도 승인 단계를 빠뜨린 것은 아닙니다. 권한 문제를 우회하려고 그래픽 클라이언트 전체를 장기간 sudo로 실행하지 마세요.

보조 서비스가 시작되지 않을 때 확인할 순서

  • ‘응용 프로그램’ 폴더에 있는 클라이언트와 동일한 앱을 실행 중인지 확인하세요. 다운로드 폴더나 디스크 이미지 안의 복사본을 실행하지 않았는지 살펴보세요.
  • 앱 업데이트 후 서비스가 맞지 않는 문제가 생겼다면 클라이언트에 포함된 서비스 제거 및 재설치 기능을 우선 사용하세요.
  • macOS 13 및 14에서는 ‘시스템 설정’ → ‘일반’ → ‘로그인 항목’에서 백그라운드 항목을 확인할 수 있습니다. macOS 15에서는 ‘로그인 항목 및 확장 프로그램’이 해당 메뉴입니다. 백그라운드 항목으로 등록된 앱만 관련 목록에 표시됩니다.
  • 처음 실패한 로그의 시간과 오류 내용을 기록하세요. 여러 클라이언트의 보조 서비스를 연달아 설치하며 문제를 해결하려 하지 마세요.

서비스 식별자, 설치 경로 및 관리 명령은 클라이언트마다 다릅니다. 다른 프로젝트의 launchctl 삭제 명령을 그대로 따라 하지 말고, /Library/LaunchDaemons/의 파일을 일괄 삭제하지 마세요.

방법 2: VPN 구성 및 네트워크 확장 승인

클라이언트가 Network Extension을 사용한다고 명시되어 있고 관련 요청이 실제로 표시될 때만 이 방법을 진행하세요. Apple의 Network Extension 프레임워크는 여러 방식으로 배포될 수 있습니다. VPN 구성 허용, 앱 확장 및 시스템 확장 승인은 각각 별개의 절차이므로 모든 안내를 ‘드라이버 승인’이라고 부르면 안 됩니다.

  1. 클라이언트에서 터널 기능을 켜세요. macOS가 앱의 VPN 구성 추가를 요청하면 앱 이름을 확인한 뒤 허용을 선택하세요.
  2. 시스템 확장이 차단되었다는 안내가 나오면 지시에 따라 ‘시스템 설정’을 여세요. macOS 13 및 14에서는 ‘개인정보 보호 및 보안’ 페이지 아래쪽에 승인 메뉴가 있는 경우가 많으며, 승인 대기 요청이 있을 때만 표시됩니다.
  3. macOS 15에서는 ‘시스템 설정’ → ‘일반’ → ‘로그인 항목 및 확장 프로그램’ → ‘네트워크 확장’을 확인하세요. 목록은 앱에서 사용하는 확장 유형과 설치 상태에 따라 달라집니다.
  4. 시스템이나 클라이언트가 요구하는 경우에만 재시동하세요. 그런 다음 앱에서 터널을 다시 연결하고 ‘시스템 설정’의 ‘VPN’ 또는 ‘네트워크’ 관련 화면에서 연결 상태를 확인하세요.

현재 클라이언트와 관계없는 VPN 구성까지 함께 삭제하지 마세요. 개인 VPN, 회사 VPN 및 콘텐츠 필터는 서로 다른 네트워크 구성 요소에 속할 수 있습니다. 삭제하기 전에 이름과 용도를 기록하고, 해당 앱에서 먼저 연결을 해제하거나 제거하세요.

mihomo 설정 점검: TUN, DNS, 규칙

많은 그래픽 클라이언트는 시작 전에 구독, 오버라이드 및 화면 설정을 병합합니다. 구독 캐시 파일을 직접 편집하면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 클라이언트의 TUN 설정이나 지속형 오버라이드 기능을 우선 사용하고, 최종 실행 설정을 확인하세요. 원본 Clash, 구버전 Premium 및 mihomo는 설정 지원 범위가 서로 다릅니다.

아래는 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: 코어가 TUN 경로를 자동으로 설정하도록 합니다. 설정 성공 여부는 로그와 실제 라우팅을 통해 확인해야 합니다.
  • auto-detect-interface: 아웃바운드 인터페이스를 자동으로 찾도록 합니다. Wi-Fi, 유선 네트워크 및 다른 VPN을 함께 사용하는 경우 잘못된 출구가 선택되지 않았는지 중점적으로 확인하세요.
  • dns-hijack: TUN으로 들어오는 조건에 맞는 일반 DNS 요청을 코어의 DNS로 전달합니다. 예시에서는 UDP와 TCP의 53번 포트를 처리하며, 임의의 암호화 DNS를 자동으로 복호화하지는 않습니다.
  • fake-ip-range: fake-ip 매핑에 사용할 주소 범위를 지정하며, 프록시 서버 주소가 아닙니다. 기존 네트워크 용도와 충돌하면 네트워크 환경에 맞게 조정하세요.

예시에 나온 DNS 상류 서버는 설정 구조를 설명하기 위한 평문 DNS 확인자이며, 모든 네트워크에서 권장되는 것은 아닙니다. 회사 내부 도메인은 회사 DNS로만 확인될 수 있습니다. 도메인별로 nameserver-policy 등의 설정을 계획하고, 모든 DNS 경로를 공용 DNS로 단순 교체하지 마세요.

놓치기 쉬운 두 가지 경계

IPv6는 별도로 확인하세요. 이 예시는 완전한 IPv6 트래픽 처리 구성이 아닙니다. 네트워크에서 IPv4와 IPv6를 모두 사용한다면 코어의 IPv6 설정, TUN 라우팅 및 실제 연결 로그를 확인하세요. IPv4 테스트만 통과했다고 모든 연결이 예상대로 전달된다고 볼 수 없습니다.

DNS가 정상이어도 규칙이 올바르다는 뜻은 아닙니다. 규칙은 순서대로 검사하며 보통 처음 일치하는 항목에서 정책이 결정됩니다. 회사 도메인을 직접 연결할지 특정 출구로 보낼지 규칙에 명시하세요. TUN은 규칙 순서를 바로잡거나 구독에서 누락된 규칙 세트를 자동으로 보완하지 않습니다.

적용 여부 확인: 인터페이스, 라우팅, 연결 로그를 함께 확인

TUN 스위치가 켜져 있어도 화면 상태가 바뀐 것일 뿐이며, utun이 보인다는 사실만으로 현재 클라이언트의 트래픽 처리가 성공했다고 볼 수 없습니다. macOS 자체 서비스와 다른 VPN도 utun 인터페이스를 만들 수 있고 번호도 달라지므로 utun0이나 utun3을 고정된 답으로 쓰지 마세요.

ifconfig -l
route -n get 1.1.1.1
scutil --dns
scutil --proxy
lsof -nP -iTCP:7890 -sTCP:LISTEN

활성화 전후의 인터페이스 목록을 비교하고 특정 대상의 라우팅이 클라이언트 설계에 맞는지 확인하세요. 일부 구현은 기본 경로 하나를 바꾸는 대신 더 구체적인 경로를 여러 개 사용합니다. lsof 명령은 예시의 로컬 포트를 프로세스가 수신 중인지 확인할 뿐, TUN이 적용됐다는 증거는 아닙니다.

프록시를 명시적으로 사용하지 않는 요청 테스트

curl --noproxy '*' --connect-timeout 10 --max-time 20 -I https://example.com

이 명령은 HTTP 또는 SOCKS 프록시를 명시적으로 사용하지 않아 TUN 테스트에 적합합니다. 연결 시간 제한은 10초, 전체 제한 시간은 20초로 설정해 실패 시 빠르게 종료됩니다. 그런 다음 클라이언트의 연결 화면에서 example.com을 찾아 적용된 규칙, 프록시 그룹 및 실제 노드를 확인하세요. HTTP 응답을 받았다는 사실만으로 프록시를 거쳤다고 단정할 수는 없습니다.

  • 먼저 직접 연결해야 하는 대상을 테스트해 로그에 예상한 직접 연결 정책이 표시되는지 확인하세요.
  • 그다음 프록시를 사용해야 하는 대상을 테스트해 마지막 규칙의 의도치 않은 기본 처리 대신 올바른 프록시 그룹이 선택되는지 확인하세요.
  • UDP가 필요하다면 실제로 사용할 UDP 앱으로 테스트하세요. TCP 요청 성공만으로 UDP 전달이 정상이라고 볼 수 없습니다.
  • Wi-Fi를 전환하거나 절전 모드에서 깨어난 뒤 다시 테스트해 네트워크 변경에 맞춰 인터페이스 자동 감지가 갱신되는지 확인하세요.

자주 발생하는 문제와 복구 순서

활성화 후 Mac 전체의 네트워크 연결이 끊김

먼저 TUN을 끄고 기본 네트워크가 복구되는지 확인한 다음 로그에서 가장 먼저 발생한 오류를 살펴보세요. 끈 뒤 복구된다면 DNS 요청, 라우팅 설정 및 아웃바운드 인터페이스를 우선 확인하세요. 복구되지 않는다면 시스템 프록시가 종료된 로컬 포트를 계속 가리키는지, 다른 VPN이 연결된 상태인지 확인하세요.

시스템 프록시는 되지만 TUN에서 권한 부족 오류가 표시됨

노드를 바꾸기보다 보조 서비스 상태부터 점검하세요. 서비스 설치 여부, 현재 앱 경로 변경 여부, 업데이트 후 서비스 갱신 필요 여부를 확인하세요. 오류가 인터페이스 생성이나 라우팅 추가 실패를 명시한다면 해당 로그를 보관하고 사용 중인 클라이언트의 서비스 관리 방식에 따라 복구하세요.

웹은 되지만 게임이나 음성 통화가 실패함

해당 연결이 실제로 TUN에 들어오는지, 노드가 UDP를 지원하는지, 규칙이 올바른 출구를 선택했는지 확인하세요. 특정 네트워크에서만 실패한다면 경로 MTU 또는 통신사 네트워크 제한을 점검할 수 있습니다. 더 작은 MTU 값을 무작정 따라 하지 말고 실패 상황을 기록한 뒤 항목별로 테스트하세요.

절전 모드에서 깨어난 뒤 도메인 이름을 확인할 수 없음

먼저 TUN을 다시 연결하고 실제 아웃바운드 인터페이스와 DNS 상태를 확인하세요. 시스템 DNS 캐시를 지워야 한다면 라우팅과 코어 DNS가 복구된 것을 확인한 뒤 아래 명령을 실행하세요. 잘못된 DNS 상류 서버나 규칙은 이 명령으로 해결되지 않습니다.

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

사용을 중단할 때 원래 상태로 되돌리는 방법

  1. 클라이언트에서 TUN을 끄고 연결이 해제될 때까지 기다린 뒤 앱을 종료하세요. 코어를 먼저 강제 종료하지 마세요.
  2. 시스템 프록시도 켰다면 클라이언트에서 함께 끄고 scutil --proxy로 남은 설정을 확인하세요.
  3. 이전에 기록한 수동 DNS 설정을 복원하세요. 원래 자동 DNS를 사용하던 네트워크에는 임시 공용 DNS를 추가로 남기지 마세요.
  4. 해당 클라이언트를 더 이상 사용하지 않는다면 앱에서 제공하는 메뉴를 통해 보조 서비스를 제거하세요. Network Extension 방식은 해당 앱의 제거 안내에 따라 관련 구성을 삭제하세요.
  5. 직접 연결이 되는지 다시 테스트하고 필요하면 현재 네트워크 서비스의 연결을 해제한 뒤 다시 연결하세요.

계속 점검해야 한다면 문제 해결 가이드를 확인하세요. 구독을 처음 가져오고 프록시 그룹을 선택하는 방법은 빠른 시작 가이드를 참고하세요. 문의할 때는 스위치 화면만 보내기보다 시스템 버전, 클라이언트 및 코어 버전, 활성화 방식, 민감한 정보를 가린 첫 오류 로그를 함께 첨부하는 것이 좋습니다.