Clash TUN 모드와 시스템 프록시의 차이: 트래픽 처리 범위, DNS 경로 및 활용 사례

Clash 클라이언트의 “시스템 프록시”와 “TUN 모드”는 두 가지 규칙 모드가 아니며, 최종적으로 어떤 노드를 선택할지도 결정하지 않습니다. 두 기능이 다루는 것은 그보다 앞선 단계인 앱의 트래픽을 Clash 또는 mihomo 커널로 전달하는 방식입니다. 트래픽이 커널에 들어온 뒤에야 도메인 스니핑, DNS, 규칙 매칭, 정책 그룹 선택, 아웃바운드 연결이 차례로 진행됩니다.

시스템 프록시는 앱과 운영체제가 제공하는 프록시 인터페이스 사이에서 작동합니다. 브라우저와 시스템 프록시를 지원하는 데스크톱 앱은 프록시 주소를 읽고 요청을 Clash에 전달합니다. 반면 TUN 모드는 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 통해 IP 패킷을 커널로 보내므로, 프록시 설정이 없는 앱도 더 넓게 처리할 수 있습니다. 두 모드는 같은 구독과 규칙을 사용할 수 있지만 트래픽 처리 범위, DNS 경로, 권한 요구 사항과 장애 양상은 서로 다릅니다.

두 모드의 요청 경로

시스템 프록시: 앱이 로컬 프록시 포트에 직접 연결

시스템 프록시를 활성화하면 그래픽 클라이언트가 운영체제의 HTTP, HTTPS 또는 SOCKS 프록시 주소를 보통 127.0.0.1:7890과 같은 로컬 리스닝 포트로 지정합니다. 브라우저는 이 설정을 읽은 뒤 대상 웹사이트에 직접 연결하지 않고 먼저 로컬 Clash 포트에 연결합니다. 커널은 대상 호스트 이름 또는 주소를 확인한 다음 현재 규칙에 따라 DIRECT, REJECT 또는 특정 프록시 정책 그룹을 선택합니다.

이 경로는 앱의 협조가 필요합니다. 대부분의 주요 브라우저와 시스템 네트워크 설정을 읽는 데스크톱 프로그램은 정상적으로 프록시를 사용하지만, 다음과 같은 트래픽은 시스템 프록시를 우회할 수 있습니다:

앱이 자체 네트워크 스택을 구현하고 운영체제의 프록시 설정을 명시적으로 무시하는 경우.
게임, 음성 통화, 동기화 도구 등이 UDP를 직접 사용하며 SOCKS 또는 앱 내 프록시를 지원하지 않는 경우.
터미널 프로그램이 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 같은 환경 변수만 읽는 경우.
가상 머신, 컨테이너 또는 서브시스템이 독립적인 네트워크 환경을 사용해 호스트의 루프백 주소를 자체 프록시 주소로 사용할 수 없는 경우.
앱이 하드코딩된 주소, 사설 프로토콜 또는 독립적인 보안 DNS 채널을 사용하는 경우.

따라서 시스템 프록시가 활성화되었다고 해서 모든 프로세스가 처리되는 것은 아닙니다. 시스템 전체의 데이터 패킷을 강제로 우회시키는 기능이라기보다 앱이 읽는 연결 안내에 가깝습니다.

TUN: 시스템 라우팅이 가상 인터페이스로 패킷 전달

TUN 모드는 가상 3계층 네트워크 인터페이스를 생성합니다. 시스템은 라우팅 테이블에 따라 조건에 맞는 IPv4 또는 IPv6 패킷을 해당 인터페이스로 보내고, mihomo 같은 커널은 사용자 공간 네트워크 스택으로 연결을 복원한 뒤 규칙을 적용하고 아웃바운드 연결을 만듭니다. 앱은 보통 HTTP 또는 SOCKS 프록시를 별도로 지원하지 않아도 대상 주소에 직접 접속한다고 인식합니다.

일반적인 경로는 다음과 같이 정리할 수 있습니다: 앱 연결 시작 → 운영체제 라우팅 선택 → TUN 가상 인터페이스 → Clash 커널 → 규칙 및 정책 그룹 → 직접 연결 또는 프록시 아웃바운드. 진입점이 IP 계층에 있기 때문에 TUN은 UDP, 명령줄 프로그램, 일부 게임 런처와 시스템 프록시를 무시하는 앱을 더 폭넓게 처리합니다. 처리 범위가 넓다고 해서 모든 트래픽이 자동으로 프록시되는 것은 아니며, 최종 동작은 여전히 규칙에 따라 결정됩니다. LAN, 예약 주소와 특정 프로세스는 계속 직접 연결로 설정할 수 있습니다.

비교 항목	시스템 프록시	TUN 모드
트래픽 진입점	HTTP, HTTPS 또는 SOCKS 로컬 리스닝 포트	가상 네트워크 인터페이스 및 시스템 라우팅
앱의 협조	앱이 시스템 프록시를 읽거나 프록시를 직접 지정해야 함	대부분의 앱에서 별도 설정 불필요
UDP 처리 범위	앱과 프록시 프로토콜 지원 여부에 따라 달라짐	대개 가상 인터페이스가 일괄 처리
권한 요구 사항	일반적으로 낮음	인터페이스 생성, 라우팅 설정 또는 시스템 서비스 설치 필요
문제 해결 난이도	진입점이 명확하고 변수가 적음	라우팅, DNS, 네트워크 어댑터, 방화벽과 권한을 함께 확인해야 함

DNS 경로가 결과를 바꾸는 이유

“노드는 연결되지만 웹사이트가 열리지 않음”, “도메인 규칙이 적용되지 않음”, “Clash를 끄면 DNS 조회가 되지 않음” 같은 문제는 실제로 DNS 경로에서 발생하는 경우가 많습니다. DNS가 Clash를 거치는지 확인하려면 화면의 DNS 스위치만 볼 것이 아니라 앱이 조회 요청을 어디로 보내는지, 시스템이 어떤 리졸버를 사용하는지, 53번 포트가 가로채기되는지, 브라우저가 별도의 암호화 DNS를 활성화했는지도 확인해야 합니다.

시스템 프록시에서는 로컬 DNS 조회가 발생할 수 있음

앱이 HTTP CONNECT 또는 SOCKS를 통해 도메인을 전달하면 Clash가 대상 호스트 이름을 확인하고 도메인 규칙을 적용할 수 있습니다. 하지만 모든 연결이 도메인 정보를 유지하는 것은 아닙니다. 일부 프로그램은 먼저 시스템 DNS로 IP를 조회한 뒤 IP 주소를 프록시에 전달하고, 다른 프로그램은 브라우저 내장 DNS over HTTPS를 직접 사용합니다. 이 경우 시스템 리졸버, 브라우저 리졸버와 Clash DNS가 동시에 존재할 수 있습니다.

요청이 커널에 들어오기 전에 이미 IP로 해석되었다면 도메인 규칙의 매칭 능력이 떨어질 수 있습니다. 커널이 스니핑을 통해 일부 HTTP, TLS 또는 QUIC 호스트 정보를 복원할 수도 있지만, 스니핑은 모든 프로토콜에서 유효하지 않으며 잘못된 DNS 설정을 대신하는 방법으로 사용해서도 안 됩니다.

TUN에서는 일반적으로 DNS 가로채기를 함께 사용

TUN 설정은 일반 UDP 또는 TCP 53번 포트의 DNS 조회를 커널의 DNS 모듈로 전달하는 방식으로 구성되는 경우가 많습니다. mihomo의 구체적인 필드는 버전과 클라이언트 구현에 따라 달라질 수 있으므로, 실제 사용 시에는 현재 클라이언트가 생성한 설정을 기준으로 해야 합니다:

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

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

fake-ip은 앱에 예약 주소 범위의 매핑 주소를 반환하고, 커널은 이를 바탕으로 도메인과 연결의 대응 관계를 유지합니다. 패킷이 TUN으로 들어오면 커널은 원래 도메인을 사용해 규칙을 매칭하고 실제 대상에 연결합니다. 일부 LAN 장치, 연결성 검사, 게임 플랫폼 또는 실제 주소 반환값에 의존하는 서비스는 fake-ip에 적합하지 않으므로 필터 목록에 추가하거나 클라이언트 기능에 따라 다른 강화 모드로 전환해야 합니다.

DNS 가로채기는 주로 기존 53번 포트 조회를 대상으로 합니다. 앱이 DoH 또는 DoT 서비스에 직접 접속하면 해당 조회는 일반 HTTPS 또는 암호화된 연결로 보이므로, dns-hijack을 설정했다고 해서 자동으로 Clash DNS 요청으로 바뀌지는 않습니다. 알려진 DNS 서비스의 아웃바운드를 규칙으로 제어하거나 앱 내 보안 DNS를 끄고 조회 경로를 시스템과 커널에 통합할 수 있습니다.

권한, 라우팅 및 플랫폼별 차이

시스템 프록시는 보통 현재 사용자의 네트워크 프록시 설정만 변경하며, 끌 때 기존 값으로 복원하면 됩니다. TUN은 가상 인터페이스 생성, 라우팅 추가, DNS 조정 또는 시스템 서비스 호출이 필요하므로 더 높은 권한을 요구합니다. 클라이언트마다 관리자 권한으로 실행하거나, 권한이 부여된 보조 서비스 또는 네트워크 확장 기능을 설치해 이러한 작업을 수행할 수 있습니다.

Windows

Windows 클라이언트에서 TUN을 활성화하려면 일반적으로 관리자 권한이 필요하거나, 필요한 권한을 가진 서비스를 미리 설치하고 실행해야 합니다. 화면에는 TUN이 켜진 것으로 표시되지만 트래픽이 기존 네트워크로 계속 나간다면 가상 네트워크 어댑터가 생성되었는지, 기본 라우팅이 등록되었는지, 보안 소프트웨어나 방화벽이 커널 프로세스를 차단하지 않는지 확인하세요. 절전 모드, 네트워크 전환 또는 비정상 종료 후에는 시스템 DNS와 라우팅이 복원되었는지도 확인해야 합니다.

macOS

macOS 구현은 시스템 네트워크 확장, 가상 인터페이스 또는 권한이 필요한 보조 프로그램을 사용할 수 있습니다. 처음 활성화할 때는 보통 시스템 권한 승인이 표시됩니다. 회사 관리 기기의 정책에 따라 네트워크 확장 설치가 제한될 수도 있습니다. 브라우저만 작동하고 터미널이나 UDP 앱이 작동하지 않는다면 먼저 현재 실제로 활성화된 것이 시스템 프록시인지 TUN인지 확인하세요. 바로 노드를 바꿀 필요는 없습니다.

Linux

Linux에서 TUN 인터페이스를 생성하고 라우팅을 설정하려면 root 권한 또는 해당 기능 권한이 필요합니다. 예를 들어 서비스에 네트워크 관리 권한을 부여해야 할 수 있습니다. 명령줄 배포에서는 기본 출구 식별, 정책 라우팅, systemd 시작 순서와 DNS 관리자의 관계도 처리해야 합니다. NetworkManager, systemd-resolved와 컨테이너 네트워크가 동시에 라우팅 또는 DNS 설정을 변경할 수 있으므로 최종 상태를 어느 구성 요소가 담당하는지 명확히 해야 합니다.

컨테이너와 가상 머신은 흔한 경계 영역입니다. 호스트에서 TUN을 활성화해도 게스트 트래픽이 해당 인터페이스를 거치는지는 브리지, NAT, 포워딩 규칙과 라우팅 설계에 따라 달라집니다. 호스트 브라우저의 테스트 결과만으로 컨테이너 트래픽도 Clash에 들어갔다고 판단할 수는 없습니다.

활용 사례에 따른 선택

시스템 프록시를 우선 사용할 상황

주로 브라우저, 코드 편집기와 시스템 프록시를 지원하는 데스크톱 앱을 사용하는 경우.
네트워크 변경을 최소화해 언제든 쉽게 켜고 끄며 문제를 추적하고 싶은 경우.
현재 계정에 가상 인터페이스 설치 또는 라우팅 변경 권한이 없는 경우.
LAN, VPN, 가상 머신 또는 기업 네트워크 환경이 복잡해 추가 라우팅 충돌을 피해야 하는 경우.
소수의 앱만 프록시로 연결하고 앱에서 HTTP 또는 SOCKS 주소를 명확히 설정할 수 있는 경우.

개발 도구는 별도로 확인해야 합니다. Git, 패키지 관리자, Docker 클라이언트와 터미널 다운로드 도구가 그래픽 인터페이스의 시스템 프록시를 반드시 읽는 것은 아닙니다. 도구 문서에 따라 프록시 환경 변수를 설정하거나 로컬 SOCKS/HTTP 리스닝 주소를 도구에 직접 입력하세요. 시스템 프록시 모드는 처리 범위를 눈에 보이고 통제 가능한 앱 계층으로 유지할 때 적합합니다.

TUN을 우선 사용할 상황

앱이 시스템 프록시를 무시하거나 프록시 설정 메뉴를 제공하지 않는 경우.
UDP, 게임 연결, 명령줄 프로그램 또는 여러 프로토콜이 섞인 트래픽을 처리해야 하는 경우.
DNS 조회, 규칙 매칭과 앱 연결을 비교적 통일된 경로로 처리하고 싶은 경우.
프로세스, 대상 네트워크 대역 또는 복잡한 규칙에 따라 전체 네트워크 트래픽을 처리해야 하고 클라이언트 커널이 해당 기능을 지원하는 경우.
관리자 권한, 시스템 서비스, 라우팅 복구와 LAN 우회 규칙을 직접 관리할 수 있는 경우.

TUN은 “앱은 통제하기 어렵지만 시스템 네트워크는 통제할 수 있는” 환경에 더 적합합니다. 속도를 높이는 스위치는 아닙니다. 지연 시간과 처리량은 여전히 노드 회선, 혼잡, 전송 프로토콜, MTU, DNS 응답과 대상 서비스의 영향을 주로 받습니다. TUN을 켠 뒤 속도가 느려졌다면 문제를 가상 네트워크 어댑터 자체의 탓으로 돌리기 전에 라우팅 루프, 잘못된 IPv6 경로, MTU 불일치 또는 DNS 폴백 대기부터 확인하세요.

두 모드를 동시에 켤 수 있나요?

많은 클라이언트는 시스템 프록시와 TUN을 동시에 활성화할 수 있습니다. 이렇게 하면 프록시 설정을 명시적으로 읽는 앱과 그렇지 않은 트래픽을 함께 처리할 수 있지만 문제 해결 변수는 늘어납니다. 일부 연결은 먼저 로컬 프록시 포트로 들어간 뒤, 해당 포트의 아웃바운드가 다시 TUN 라우팅의 영향을 받을 수 있습니다. 완성도 높은 구현은 일반적으로 인터페이스 제외와 프로세스 우회 설정으로 루프를 방지하지만, 클라이언트 서비스 오류, 수동 라우팅 또는 외부 VPN이 이 조건을 깨뜨릴 수 있습니다.

일상적인 사용에서는 “더 넓은 처리 범위”를 위해 두 모드를 항상 동시에 켤 필요가 없습니다. 먼저 앱 유형에 맞는 진입점을 하나 선택하세요. 시스템 프록시만으로 충분하다면 단일 진입점을 유지하는 편이 관리하기 쉽습니다. 시스템 프록시를 읽지 않는 앱이 실제로 있을 때 TUN을 추가로 테스트하세요.

진입점, DNS, 규칙, 아웃바운드 순서로 문제 해결

프록시 모드를 바꾼 뒤 문제가 발생했다면 노드를 계속 바꾸기보다 데이터 경로를 단계별로 확인하세요. 다음 순서를 따르면 문제 범위를 좁힐 수 있습니다.

커널이 실행 중인지 확인합니다. 클라이언트 상태, 로컬 리스닝 포트와 최근 로그를 확인하세요. 커널이 시작되지 않았다면 시스템 프록시와 TUN 모두 정상적인 전달을 수행할 수 없습니다.
트래픽이 커널에 들어오는지 확인합니다. 테스트 사이트에 접속하거나 명확한 요청을 한 번 실행하고 연결 목록에 대상이 나타나는지 확인하세요. 기록이 없다면 앱이 시스템 프록시를 읽지 않았거나 TUN 라우팅이 적용되지 않았을 가능성이 큽니다.
DNS 요청 경로를 확인합니다. 시스템 조회 결과, 클라이언트 DNS 로그와 브라우저 보안 DNS 설정을 비교하세요. 웹페이지 하나의 테스트 결과만으로 결론 내리지 마세요.
규칙 매칭을 확인합니다. 대상 연결이 어떤 규칙에 매칭되고 어느 정책 그룹으로 들어갔는지 확인하세요. 규칙은 보통 위에서 아래로 평가되며, 먼저 매칭된 규칙이 동작을 결정합니다.
정책 그룹의 실제 선택을 확인합니다. 정책 그룹 이름에 프록시가 표시된다고 해서 내부 노드를 사용할 수 있다는 뜻은 아닙니다. 현재 선택된 노드, 지연 시간 테스트와 실패 로그를 확인하세요.
아웃바운드 인터페이스를 확인합니다. TUN이 켜져 있을 때는 특히 커널이 올바른 물리 네트워크 어댑터를 선택했는지 확인해 프록시 서버 연결이 다시 TUN으로 들어가는 것을 방지해야 합니다.

시스템 프록시 모드에서는 “프록시 사용 안 함”과 “로컬 프록시를 명시적으로 지정”한 결과를 각각 테스트할 수 있습니다. 아래 포트는 일반적인 예시일 뿐이므로 클라이언트에 현재 표시되는 리스닝 포트로 바꾸세요:

curl https://example.com
curl --proxy http://127.0.0.1:7890 https://example.com
curl --proxy socks5h://127.0.0.1:7890 https://example.com

socks5h에서는 호스트 이름 조회를 SOCKS 프록시 측에서 수행하므로 로컬 조회 결과와 비교하기 좋습니다. 프록시를 명시하면 작동하지만 일반 요청이 작동하지 않는다면 문제는 대개 시스템 프록시 적용이나 환경 변수에 있습니다. 두 요청 모두 커널에 들어오지만 규칙이 다르게 적용된다면 요청에 도메인이 포함되었는지, 이미 해석된 IP가 전달되었는지 확인하세요.

TUN 모드에서는 먼저 시스템에 해당 가상 인터페이스와 라우팅이 존재하는지 확인한 뒤 요청이 Clash 연결 기록에 나타나는지 살펴보세요. TCP는 작동하지만 UDP가 통하지 않는다면 커널, 노드 프로토콜, 규칙과 대상 서비스가 해당 UDP 경로를 지원하는지 점검하세요. LAN 프린터나 라우터 관리 페이지에 연결할 수 없다면 사설 네트워크 대역이 직접 연결로 유지되는지, 자동 라우팅이 로컬 네트워크를 덮어쓰지 않았는지 확인하세요.

선택 결론: 최소한으로 처리하고 필요한 범위만 확장

브라우저와 일반적인 데스크톱 앱만 처리한다면 시스템 프록시가 대체로 더 직접적인 출발점입니다. 권한 요구가 낮고 연결 진입점이 명확하며 앱이 프록시 설정을 읽었는지도 확인하기 쉽습니다. 명령줄 프로그램은 환경 변수나 도구 자체의 프록시 설정을 추가로 구성할 수 있습니다.

앱이 프록시 설정을 무시하거나 UDP가 필요하거나 DNS 경로를 더 통일해야 할 때, 또는 라우팅으로 더 많은 프로세스를 처리하고 싶을 때 TUN을 활성화하세요. 활성화 후에는 관리자 권한, 가상 인터페이스, 자동 라우팅, 물리적 출구 식별, DNS 가로채기, LAN 우회와 IPv6 동작을 함께 확인해야 합니다.

두 모드 모두 최종적으로 같은 Clash 또는 mihomo 규칙 체계로 연결을 전달합니다. 시스템 프록시는 “앱이 커널에 넘길 의사가 있는지”를 해결하고, TUN은 “시스템이 패킷을 커널로 보내는지”를 해결합니다. 문제가 진입점, DNS, 규칙 또는 아웃바운드 중 어디에 있는지 먼저 확인한 뒤 해당 설정을 조정하면 모든 연결 문제를 노드나 구독 탓으로 돌리는 일을 피할 수 있습니다.