macOS TUN 모드 설정 방법: 터미널·전체 트래픽 프록시 연결

시스템 프록시와 TUN: 트래픽을 가로채는 위치의 차이

Mac에서 시스템 프록시를 켜면 브라우저는 정상적으로 연결되는데 터미널 명령은 시간 초과되는 경우가 있습니다. 보통은 하나의 설정이 작동하지 않는 문제가 아니라 두 프로그램이 서로 다른 네트워크 경로를 사용하기 때문입니다. 시스템 프록시는 HTTP, HTTPS 또는 SOCKS 프록시 주소를 제공하며, 앱이 해당 설정을 읽어 사용해야 합니다. 반면 TUN은 가상 네트워크 인터페이스와 라우팅을 이용해 지정된 범위의 IP 트래픽을 프록시 코어로 전달합니다.

비교 항목	시스템 프록시	TUN 모드
적용 조건	앱이 시스템 프록시를 사용하거나 프록시를 별도로 설정해야 함	가상 네트워크 인터페이스와 연결된 경로로 트래픽 전달
주요 용도	브라우저 및 시스템 설정을 따르는 앱	터미널 도구, 일부 게임 및 기타 직접 연결 프로그램
필요한 권한	네트워크 프록시 설정을 변경할 권한이 필요할 수 있음	인터페이스와 라우트를 만들려면 보통 권한이 있는 보조 서비스가 필요함
UDP 트래픽	일반 HTTP 시스템 프록시만으로는 모든 UDP 트래픽을 처리할 수 없음	코어, 아웃바운드 프로토콜, 노드 모두 지원해야 함
아웃바운드 선택	코어의 실행 모드와 규칙에 따라 결정	마찬가지로 코어의 실행 모드와 규칙에 따라 결정

‘전체 트래픽’이 반드시 예외 없이 모두 적용된다는 뜻은 아닙니다. LAN 제외 설정, 인터페이스를 명시적으로 지정한 프로그램, 다른 VPN의 라우트, 시스템 자체 트래픽 등에 따라 실제 적용 범위가 달라질 수 있습니다. 메뉴 막대의 스위치만 보고 판단하지 말고 대상 앱의 연결을 직접 확인하세요.

시작 전 확인: 코어, 노드, 현재 네트워크

클라이언트에서 실제로 실행 중인 코어 확인

Clash는 설정과 클라이언트 생태계에서 널리 쓰이는 이름일 뿐, 모든 앱이 같은 코어를 사용한다는 뜻은 아닙니다. Clash Meta는 이후 mihomo라는 이름으로 개발을 이어가고 있습니다. 특정 TUN 설정 항목의 지원 여부는 현재 실행 중인 코어 버전과 해당 문서를 기준으로 확인하세요. 먼저 클라이언트의 ‘정보’, 코어 관리 화면 또는 시작 로그에서 클라이언트 버전, 코어 이름, 버전 번호를 확인합니다. 그래픽 인터페이스 버전과 코어 버전은 별개의 정보이므로 서로 대체할 수 없습니다.

먼저 기본 연결 상태 확인

구독을 업데이트하고 사용 가능한 노드를 선택합니다. 시스템 프록시만 켠 상태에서 브라우저로 테스트할 사이트에 접속되는지 확인하세요.
현재 모드가 ‘규칙’인지 확인하고 대상 도메인에 어떤 정책 그룹이 적용되는지 살펴봅니다. 노드 지연 시간 테스트에 성공해도 HTTPS와 UDP까지 사용할 수 있다는 뜻은 아닙니다.
다른 개인용 VPN, 네트워크 가속기, 프록시 클라이언트는 일시적으로 연결을 끊으세요. 회사나 기관에서 관리하는 VPN은 임의로 제거하지 말고 먼저 네트워크 정책을 확인하세요.
현재 시스템 프록시 상태와 로컬 수신 포트를 기록하고, 문제가 생겼을 때 복구할 수 있도록 기존 설정을 백업해 두세요.

포트 번호는 클라이언트 설정에서 확인해야 합니다. 예를 들어 로컬 혼합 포트가 실제로 7890인 경우에만 127.0.0.1:7890을 프록시 주소로 사용할 수 있습니다. 모든 클라이언트에서 고정으로 사용하는 값은 아닙니다. TUN은 시스템 프록시 포트를 다른 번호로 바꾸는 기능도 아닙니다.

권한 승인 및 활성화: 서비스 설치 후 트래픽 처리

클라이언트마다 메뉴 이름이 다릅니다. Clash Verge Rev의 일반적인 화면을 예로 들면, 먼저 ‘설정’ → ‘Clash 설정’을 열어 ‘서비스 모드’의 설치 및 실행 상태를 확인한 다음 ‘TUN 모드’를 켭니다. 현재 버전에서 메뉴 위치가 바뀌었다면 화면의 ‘서비스 모드’와 ‘TUN 모드’ 항목을 찾아 설정하세요. 다른 클라이언트의 메뉴 경로를 그대로 적용하지 마세요.

권한이 필요한 보조 서비스를 설치합니다.서비스 모드 옆의 설치 버튼을 클릭합니다. macOS에서 권한을 요청하면 요청을 보낸 앱이 방금 실행한 클라이언트인지 확인한 뒤 시스템 안내에 따라 관리자 인증을 완료하세요. 터미널에서 그래픽 앱 전체를 관리자 권한으로 실행하지 마세요.
서비스가 실행 중인지 확인합니다.설치가 끝나면 화면에 서비스 준비 완료 상태가 표시되어야 합니다. 설치되지 않았거나 연결할 수 없다는 메시지가 계속 표시되면 TUN을 반복해서 켜고 끄지 말고 먼저 서비스 문제를 해결하세요.
TUN 모드를 켭니다.코어가 설정을 다시 불러올 때까지 기다린 뒤, 가상 인터페이스 생성이나 라우트 추가 실패와 같은 메시지가 로그에 있는지 확인하세요. 성공 메시지는 버전에 따라 다를 수 있습니다.
첫 테스트는 규칙 모드로 진행합니다.먼저 기존 규칙이 제대로 작동하는지 확인하세요. 노드 변경, 전역 모드 전환, DNS 수정까지 한꺼번에 하면 결과에 영향을 준 설정을 파악하기 어렵습니다.
TUN만 따로 확인합니다.서비스가 안정적으로 실행되면 시스템 프록시를 잠시 끄고 테스트할 수 있습니다. 이렇게 하면 브라우저가 읽는 HTTP 프록시를 통해 연결이 코어에 들어가는 상황과 TUN을 구분하기 쉽습니다.

Apple Silicon Mac에서는 Apple Silicon에 맞는 클라이언트를, Intel Mac에서는 해당 아키텍처용 클라이언트를 선택하세요. 아키텍처는 앱과 보조 프로그램의 정상 실행 여부에 주로 영향을 줍니다. 두 아키텍처 모두 TUN, 라우팅, 규칙 기반 분기의 기본 원리는 같습니다.

설정 항목: 라우팅, 프로토콜 스택, DNS 처리

그래픽 클라이언트에 TUN 스위치가 있다면 우선 인터페이스에서 관리하세요. 일부 클라이언트는 화면의 설정을 실행 구성에 합치므로 구독 원본 파일을 직접 수정하면 업데이트 과정에서 덮어써질 수 있습니다. 사용자 설정이 필요하다면 클라이언트의 오버라이드 또는 설정 병합 기능을 이용하고, 최종 실행 구성에 적용됐는지 확인하세요.

아래는 mihomo의 일부 설정 예시로, TUN 관련 항목만 보여 줍니다. 단독으로 실행할 수 있는 완전한 구독 설정은 아닙니다. 사용 가능한 프록시, 규칙, 활성화된 내장 DNS 설정이 이미 있다고 가정합니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

enable: TUN 기능을 활성화합니다. 그래픽 인터페이스에서 스위치를 끄면 클라이언트가 이 값을 다시 생성할 수 있습니다.
stack: mixed: 혼합 프로토콜 스택을 선택합니다. 사용할 수 있는 다른 값과 동작은 현재 코어의 지원 여부를 확인하세요. 네트워크가 느리다고 임의로 값을 반복해서 바꾸지 마세요.
auto-route: 코어가 관련 라우트를 자동으로 설정합니다. 사용자 지정 라우트, 다른 VPN, 관리 정책에 따라 최종 경로가 달라질 수 있습니다.
auto-detect-interface: 아웃바운드 인터페이스를 자동으로 감지합니다. Wi-Fi에서 이더넷으로 전환한 뒤 연결에 문제가 생기면 코어를 재시작하고 인터페이스 감지 결과를 확인하세요.
dns-hijack: 조건에 맞는 기존 DNS 요청을 내장 DNS로 전달합니다. 예시의 any:53은 ‘모든 암호화 DNS를 가로챈다’는 뜻이 아닙니다.

도메인 규칙에 DNS가 필요한 이유

많은 트래픽 분기 규칙은 도메인을 기준으로 하지만, TUN이 처음 받는 정보는 IP 패킷입니다. 코어는 DNS 매핑, 연결 메타데이터 또는 설정된 스니핑 기능을 통해 도메인을 식별해야 합니다. fake-ip 모드에서는 내장 DNS가 매핑 주소를 반환하고, 이후 코어가 실제 대상과 연결합니다. 다른 DNS 모드를 사용하면 도메인을 연결하는 방식이 달라질 수 있습니다.

브라우저의 보안 DNS는 보통 HTTPS를 사용하며 443 포트로 통신합니다. 따라서 53 포트를 가로챈다고 해서 암호화된 DNS가 자동으로 코어에서 읽을 수 있는 일반 DNS로 바뀌지는 않습니다. 규칙이 예상대로 적용되지 않으면 브라우저의 DNS 설정, 코어의 DNS 로그, 실제 적용된 규칙을 함께 확인하세요. 설정 하나만 바꾸고 도메인 식별이 완전히 해결됐다고 단정하지 마세요.

TUN 확인: 인터페이스, 터미널 연결, 규칙을 교차 점검

1단계: 네트워크 상태 확인 — 인터페이스 이름만으로 단정하지 않기

‘터미널’을 열고 다음 읽기 전용 명령을 실행하세요. 첫 번째는 시스템 프록시 설정, 두 번째는 네트워크 인터페이스 목록, 세 번째는 지정한 주소까지의 라우트를 확인합니다.

scutil --proxy
ifconfig
route -n get 1.1.1.1

macOS에서 흔히 볼 수 있는 가상 인터페이스 이름은 숫자가 붙은 utun입니다. 하지만 시스템 서비스나 다른 VPN도 이런 인터페이스를 만들 수 있습니다. 따라서 utun3이 보인다고 해서 현재 클라이언트가 만든 인터페이스라고 단정할 수 없습니다. 활성화 전후의 변화, 클라이언트 로그, 라우트 결과를 함께 확인하세요. 특정 대상 하나의 라우트 조회 결과가 모든 주소에 해당하는 것도 아닙니다.

2단계: 터미널에서 앱 수준 프록시를 사용하지 않도록 설정

macOS에 기본 포함된 curl로 테스트하고 --noproxy '*' 옵션을 사용해 curl의 앱 수준 프록시를 우회하세요. 이 옵션은 TUN을 우회하지 않으므로 두 가지 트래픽 처리 경로를 구분하는 데 유용합니다.

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

예시에서는 연결 시간 초과를 10초, 전체 시간 초과를 20초로 설정했습니다. HTTP 응답을 받았다는 사실만으로 해당 연결이 프록시 노드를 사용했다고 판단할 수는 없습니다. 일부 네트워크에서는 이 사이트에 원래 직접 연결할 수 있습니다. 명령을 실행하면서 클라이언트의 연결 목록도 열어 example.com 연결을 찾아 적용된 규칙, 정책 그룹, 최종 아웃바운드를 확인하세요.

3단계: TUN을 끈 상태와 비교

노드, 규칙, 테스트 URL을 그대로 둔 채 TUN을 켰을 때의 연결 로그를 기록합니다.
TUN을 끄고 시스템 프록시도 끈 상태에서 같은 명령을 다시 실행합니다.
클라이언트에서 해당 연결이 계속 보이는지, 적용된 규칙이 같은지, 요청 결과가 어떻게 달라졌는지 비교합니다.
필요한 스위치 상태로 복구합니다. 결과가 달라지지 않는다면 대상이 원래 직접 연결되는지, 다른 VPN이 계속 실행 중인지, 테스트 프로그램이 기존 연결을 재사용하는지 확인하세요.

게임을 테스트할 때는 게임이 실제로 생성하는 UDP 세션도 확인해야 합니다. 웹페이지 접속이나 TCP 테스트가 성공해도 노드가 게임에 필요한 UDP를 지원한다고 볼 수는 없습니다. 게임 로그인, 리소스 다운로드, 대전에서 서로 다른 도메인과 포트를 사용할 수 있으므로 런처만 테스트하지 말고 각각 확인하세요.

자주 발생하는 문제: 권한, 라우팅, DNS, 아웃바운드 순으로 점검

TUN 스위치가 바로 꺼지거나 인터페이스 생성에 실패함

먼저 보조 서비스가 실행 중인지, 코어가 정상적으로 시작됐는지 확인합니다. 그런 다음 실행 설정에 YAML 들여쓰기 오류가 있는지, 현재 코어에서 지원하지 않는 항목이 있는지 살펴보세요. 설치 파일을 업데이트한 뒤에는 클라이언트와 이전 보조 서비스의 버전이 맞지 않을 수 있습니다. 알 수 없는 시스템 파일을 수동으로 삭제하지 말고 클라이언트의 서비스 관리 기능을 사용해 복구하세요.

TUN을 켠 뒤 모든 웹사이트에 연결할 수 없음

먼저 TUN을 끄고 기본 네트워크가 복구되는지 확인하세요. 이어서 노드 연결 상태, DNS 업스트림 접근성, 로그에 표시된 아웃바운드 인터페이스를 확인합니다. VPN을 함께 사용 중이라면 허용된 경우 하나를 일시 중지하고 다시 테스트하세요. 라우트가 서로 덮어쓰면 트래픽이 잘못된 터널로 들어가거나 DNS 요청이 업스트림에 도달하지 못할 수 있습니다.

IP 주소로는 연결되지만 도메인 이름이 해석되지 않음

내장 DNS가 활성화되어 있는지, 업스트림 리졸버에 연결할 수 있는지, DNS 요청이 올바르게 처리되는지 확인하세요. ‘HTTPS 사이트의 IP 주소로 접속’하는 방법으로 도메인 테스트를 대체하지 마세요. 인증서와 가상 호스트는 대개 도메인 이름을 사용합니다. macOS의 scutil --dns로 리졸버 상태를 확인할 수 있지만, 최종적으로는 해당 앱의 DNS 처리 경로도 함께 살펴봐야 합니다.

터미널 트래픽은 TUN을 거치지만 특정 앱은 계속 직접 연결됨

먼저 ‘코어에 들어온 뒤 DIRECT 규칙이 적용된 경우’와 ‘애초에 코어에 들어오지 않은 경우’를 구분하세요. 전자라면 규칙 순서, 정책 그룹 선택, LAN 제외 설정을 확인합니다. 후자라면 앱이 특정 인터페이스에 바인딩됐는지, 다른 네트워크 확장 프로그램이 트래픽을 처리하는지, TUN을 켜기 전에 연결이 이미 만들어졌는지 확인하세요. 새 연결을 검증하려면 창만 새로 고치는 것보다 대상 앱을 완전히 종료했다가 다시 실행하는 편이 좋습니다.

잠자기에서 깨어나거나 Wi-Fi를 전환한 뒤 연결이 끊김

먼저 재시도 중인 앱 연결을 끊고 코어를 재시작해 인터페이스 감지와 라우트를 다시 설정하세요. 문제가 반복된다면 네트워크 전환 전후의 연결 유형, 코어 버전, 관련 로그를 기록한 뒤 문제를 신고하세요. 로그를 공유하기 전에 구독 URL, 노드 인증 정보, 기타 개인 네트워크 정보를 삭제하세요.

종료 및 복구: 다시 따라 할 수 있는 순서 유지

TUN이 더 이상 필요하지 않으면 먼저 클라이언트에서 TUN을 끄고 일반 네트워크가 복구됐는지 확인한 다음 앱을 종료하세요. 시스템 프록시를 켰다면 필요에 따라 함께 끕니다. 시스템 프록시가 이미 종료된 로컬 프로세스를 계속 가리키면 해당 설정을 따르는 앱은 인터넷에 연결되지 않을 수 있습니다.

Wi-Fi 프록시 확인 경로: ‘시스템 설정’ → ‘네트워크’ → ‘Wi-Fi’ → ‘세부사항’ → ‘프록시’. 유선 연결은 해당 네트워크 서비스를 선택하세요.
VPN 확인 경로: ‘시스템 설정’ → ‘VPN’. 클라이언트가 만든 TUN 인터페이스가 여기에 독립된 VPN 항목으로 표시되지 않을 수 있으므로, 항목이 없다고 가상 인터페이스가 없는 것은 아닙니다.
비정상 종료 후 네트워크가 복구되지 않으면 먼저 기존 클라이언트를 다시 실행한 다음 TUN과 시스템 프록시를 정상적으로 끄세요. 필요한 경우 Mac을 재시동하세요. 라우팅 테이블 전체를 바로 지우지 마세요.