1. 왜 지금 TUN인가: 시스템 프록시와 다른 레이어
많은 사람이 처음 Clash를 맥에 깔았을 때 시스템 프록시만으로 브라우저·사무실 앱의 출구 바꾸기에 성공합니다. 문제는 같은 맥이라도 프로그램마다 「HTTP 프록시나 PAC를 읽지 않은 채 바로 목적지에 SYN을 연다」는 방식으로 움직이는 경우가 섞여 있다는 점입니다. 대표적으로 터미널 패키지 매니저, 일부 온라인 게임 빌드, 회사별 보안 에이전트가 붙은 커스텀 바이너리가 그렇습니다. 이때는 브라우저만 테스트하면 “잘 된다”는 착시가 나옵니다.
TUN 모드는 코어가 운영체제에 보이게 만든 가상 어댑터를 통해 패킷 흐름을 규칙으로 끌어오는 접근이라, 라우팅 우선순위와 DNS 순서 같은 인프라 변수가 함께 따라붙습니다. 따라서 기능을 켰다면 “내가 무엇을 켠 것인지”를 레이어별로 인지해야 하고, 네트워크 확장(system extension) 승인이 빠져 있으면 버튼은 있어도 실제 패킷이 안 넘어갈 수 있습니다. 시스템 문자열만 다룰 때의 감각은 맥 전용 시스템 프록시·네트워크 확장 점검 글에서 이미 묶어두었고, 본문은 거기 다음 단계입니다.
2. 전제 조건과 설치 상태 점검
TUN 버튼을 눌러도 깨진 프로필이면 아무 어댑터도 세우지 못합니다. Clash Verge Rev에서 활성 프로필이 들어 왔고, Mihomo 로그상 문법 에러 없이 시작했는지 먼저 확인하세요. Mixed Port처럼 대표적인 리스너가 표시된다면 적어도 코어 레벨의 대기 상태는 형성되어 있습니다.
맥에서는 보안 패치 차이 때문에 메뉴 이름이 「개인 정보 보호 및 보안」「일반」「로그인 항목」 등으로 번갈아 보일 수 있습니다. 검색 창에 TUN을 설치하는 앱의 상표 문자열이나 패키지에 표시된 이름을 입력해 해당 확장 카드까지 바로 들어가는 습관이 좋습니다. 관리 기기에서는 MDM이 네트워크 필터 또는 시스템 확장 클래스를 건드려 사용자 허용이 무의미하게 막히는 예도 있어, 학교 노트북이라면 정책과 충돌 여부부터 묻습니다.
코어 업데이트와 클라이언트 빌드
Verge 패밀리는 프론트엔드가 자주 업데이트되지만, 기능 이름은 같은 말이라도 실제 호출되는 Mach 서비스가 조금씩 달라질 수 있습니다. 릴리스 노트에서 TUN 또는 Network Extension 관련 고지가 있었다면 새 빌드를 올린 뒤에도 한 번 허용 절차를 다시 거칠 준비를 하세요.
3. Clash Verge Rev에서 스위치 켜기
구체 레이블은 빌드·언어에 따라 다르지만 패턴은 유사합니다. 홈 패널이나 설정 카테고리에 TUN, Enhance Mode, 혹은 시스템 스택 고도화 식 이름의 토글이 있습니다. 우선 해당 스위치를 켭니다.
- 활성 프로필 이름이 선택된 상태에서 Verge 우측·하단의 네트워크 카테고리로 이동합니다.
- TUN에 해당하는 토글을 켠 직후 macOS 알림 또는 자물쇠 아이콘이 뜨는지 확인합니다.
- 패스워드를 요구하면 입력하고, 허용을 누른 뒤 앱 재시작을 권하면 따릅니다.
- 토글이 순간적으로 꺼졌다 켜지면 한 번 재시작을 해 보세요. 일부 Ventura 이후에서는 첫 허용 직후에만 이런 패턴이 납니다.
영문 인터페이스를 쓰는 경우 검색 기능이 있다면 tun이나 virtual 키워드로 패널을 좁히면 실수 클릭이 줄어듭니다.
4. 시스템 확장·로그인 항목에서 허용
Apple은 패킷을 가공하는 기능을 사용자 승인과 개발자 서명 상태에 묶어두었기 때문에 단순한 “설치 프로그램”과는 접근 순서가 다릅니다. 전형적인 순서는 다음입니다.
- 알림 센터 또는 Verge 안내 카드에서 시스템 설정 열기 같은 링크를 눌러 깊은 페이지로 들어간다.
- 개인정보 보호 및 보안(또는 이에 대응하는 메뉴)에서 해당 개발자·앱 패키지에 대한 허용을 수동 승인한다.
- 로그인 항목 또는 확장 카테고리에서 Clash 계열 헬퍼가 꺼져 있지 않은지 본다. 백그라운드에서 확장 로더가 시작되지 않으면 사용자가 버튼을 켠 것처럼 보여도 내부 비동기 작업만 실패하는 경우가 있습니다.
한 번이라도 허용을 스킵하면 이후 같은 다이얼로그가 다시 안 뜨는 채 기능만 회색 상태로 남는 일이 있습니다. 이때 앱 삭제까지 가기보다 해당 시스템 설정 화면을 직 열어 “차단 목록 성격으로 남은 항목”을 찾아 풀고 Verge 전체 종료 후 재실행하면 다시 순서대로 따라갑니다.
실패했을 때의 최소 증명
확장이 실패하면 시스템의 콘솔(Console) 필터 문자열을 앱 이름이나 패키지 ID로 줄여 보거나, Mihomo 디버그 로그에 패킷 캡처 오류 문자열이 남았는지 봅니다. 한 줄이라도 패킷 엔진 시작 실패가 찍히면 GUI의 녹색 토글은 신뢰하지 않습니다.
5. YAML의 tun 블록 맞추기
Verge는 메인 프로필에 클라이언트 전용 override를 더해 최종 Mihomo 실행 파일에게 넘길 수 있습니다. TUN 활성이라도 실제 활성 실행 스냅샷 어딘가에 다음과 같은 패턴의 섹션이 있어야 합니다.
tun:
enable: true
stack: mixed
auto-route: true
strict-route: false
dns-hijack:
- any:53stack·strict-route·추가 키는 코어 버전과 구독 제공자 패치에 따라 달라지므로, 위는 “참조용 형태일 뿐”입니다. 사용자가 패치 패널에 직접 손대지 않는다면 활성 블록이 구독 쪽 또는 Verge 패치에 이미 존재하는지부터 확인해야 합니다. GUI에서 재정의 기능이 있는 빌드를 쓸 때는 패치 탭 내용과 실제 머지된 YAML을 화면에 띄우는 메뉴가 있으므로, 활성 상태에서 교차 검증하면 실수 줄이기에 좋습니다.
tun.enable가false로 남았는데 버튼만 켠 경우: 클라이언트가 패치 순서 문제로 무시했다는 신호입니다. 패치나 프로필을 한 축만 조정합니다.- DNS 우회 옵션과 규칙 모드 불일치: fake-ip 같은 전략과 TUN 레이어의 DNS 처리가 같은 서비스에 동시 적용되어 앱별로 결과가 나뉘는 패턴입니다. 해당 주제 전체가 길므로 초기 검증에서는 문서 내 DNS 장과 같은 자료와 조합해야 합니다.
- IPv6가 강하게 켜진 망: 라우팅 테이블이 이중이라 기대 노드 안 탄 것처럼 보입니다. 테스트 시점에 IPv6를 잠깐 줄이거나, 프로필이 IPv6 흐름을 어떻게 다룰지 확인합니다.
패치 작성은 패치 우선 순위 안내 글의 순서 도식을 따라가며 merge 우선 순위부터 맞춥니다.
6. 시스템 프록시와 함께 둘 때의 주의
실무에서는 TUN만 쓰거나, 시스템 프록시만 쓰거나 한 축만 켜 디버깅하는 편이 낫습니다. 둘 다 켠 구성 자체가 “틀렸다”는 뜻은 아니지만, Safari는 시스템 프록시를 읽고 CLI는 TUN을 타는 식으로 경로가 갈리면 “한쪽만 이상” 같은 보고가 생깁니다.
동시에 켜 둔 상태에서 시스템 설정의 수동 프록시 줄이 오래된 포트를 가리키고 있으면, 브라우저는 실패한 로컬 포트로 붙고 TUN 앱은 정상 노드로 보이는 이중 체감이 납니다. 이때는 수동 프록시를 끄거나 최신 Mixed Port에 맞추는 것이 빠릅니다. 터미널 환경 변수만 따로 쓰는 팀은 터미널 프록시 환경 변수 글과 조합해 정리하는 편이 좋습니다.
| 상황 | 짧은 판단 |
|---|---|
| 브라우저만 출구가 이상 | 시스템 프록시 값·확장별 예외·HTTP/HTTPS 수동 라인을 먼저 본다. |
| 브라우저는 정상, 터미널만 직행 | TUN 미적용 혹은 CLI가 환경 변수를 우선하는지 확인한다. |
| 특정 앱만 항상 국내 ISP | 앱이 자체 인증서 고정·사설 DNS·UDP 직행을 쓰는지, Rule에 그 프로토콜이 있는지 확인한다. |
7. 라우팅과 출구로 효과 확인
버튼이 녹색이어도 실제 패킷이 코어까지 도달해야 합니다.
- 터미널:
netstat -rn으로 기본 경로 또는 인터페이스 우선 순위 변화가 있었는지 봅니다. 시스템/OS 버전에 따라 출력 디테일이 다르니 “이전 상태와의 델타”를 중요하게 봅니다. - 시스템 정보나 네트워크 화면에서 새 가상 인터페이스가 나타나는 경우가 있습니다만, 모든 빌드가 한글 UI에 이름을 크게 노출하지는 않습니다. 없다고 무조건 실패는 아니라 코어 로그가 더 신뢰됩니다.
- Mihomo 쪽 연결 로그: 해외 테스트용 도메인을 하나 열고 해당 호스트가 로그에 찍히는지 확인합니다. 찍히지 않으면 아직 OS에서 코어로 붙지 않은 것입니다.
- 브라우저 출구: 사적인 ASN·국가 정보를 보여 주는 검사 페이지를 사전에 신뢰 가능한지 확인한 뒤 사용하고, 시크릿 창에서 확장을 제거한 상태로 비교합니다.
Windows에서 TUN 이후 전체 단절을 다루는 글은 OS 스택이 달라 맥에 그대로 복붙하면 안 됩니다. 필요하면 Windows TUN 라우팅·방화벽 점검을 따로 열어 두고, 맥 장애는 본문 절차와 시스템 확장 쪽을 우선합니다.
8. 자주 묻는 질문
Gatekeeper만 통과했는데 TUN은 여전히 회색인 이유는?
앱 실행 허용과 네트워크 확장 허용은 별도 파이프라인입니다. 시스템 설정에서 확장 관련 카드까지 들어가 수동 허용이 필요한지 확인하세요.
패치가 구독을 덮어써서 tun이 꺼지나요?
merge 순위에 따라 그렇게 됩니다. Verge 패치 패널이나 패치 우선 순위 규칙과 실제 머지 결과를 같은 화면에서 비교하세요.
직장망이라 정책으로 막히면?
클라이언트 기능 문제가 아니라 조직 장비 통제 문제일 수 있습니다. 기술 검증이라도 개인 기기와 분리해서 진행해야 혼선이 줄어듭니다.
9. 정리하고 Clash로 이어가기
맥에서 Clash Verge Rev의 TUN 모드는 단일 스위치가 아니라 Mihomo 기동 상태·시스템 확장 승인·머지된 YAML 안의 tun이 동시에 맞아야 실제 패킷이 보입니다. 절차적으로는 활성 프로필을 검증하고 Verge 안에서 해당 토글을 켠 뒤 macOS 설정 쪽 허용을 완료하고, 마지막에 라우팅과 코어 로그로 외향 트래픽 존재를 증명하는 것이 깔끔합니다.
시중에는 한 화면에 모든 기능을 때려 넣느라 규칙 편집이 번거롭거나, 패킷 레이어별 점검 도구 없이 증상만 나열하는 가벼운 도구들도 존재합니다. 그에 비해 Clash·Mihomo 생태계는 프로바이더·Rule·DNS 같은 자산 위에 여러 플랫폼 클라이언트를 같은 발상으로 쌓을 수 있어, 회사 노트와 가정용 맥에서도 구성 패턴을 이어 가기 좋습니다. 패킷 레이어별 디버깅만 익히면 재설치에 덜 흔들리고 장기적으로도 유지 비용이 줄어듭니다. 아직 클라이언트를 받지 않았다면 Clash 클라이언트를 무료로 받고 운영체제에 맞는 빌드를 고른 뒤, 이 글 순서로 TUN을 켜 보시면 됩니다.