라우팅 방식 예상 읽기 시간 12분

Clash TUN 모드와 시스템 프록시 차이: 트래픽 진입점·적용 범위·선택 방법

작동 계층, 앱 호환성, DNS 처리와 권한 요구 사항을 비교해 기기 환경에 맞는 선택 기준을 안내합니다.

시스템 프록시와 TUN은 같은 진입점 문제를 해결합니다. 즉, 기기에서 발생한 연결을 Clash 또는 mihomo 코어로 전달하는 방식입니다. 두 방식 모두 특정 웹사이트가 프록시를 사용할지 직접 연결할지를 결정하지는 않습니다. 트래픽이 코어에 들어온 뒤에는 현재 실행 모드, 규칙 집합, 정책 그룹과 노드 상태에 따라 매칭됩니다. 따라서 “TUN 활성화”가 Global 전체 모드로 전환된다는 뜻은 아니며, “시스템 프록시 활성화”가 모든 앱을 라우팅한다는 뜻도 아닙니다.

트래픽 진입점: 시스템 프록시는 설정을 읽고, TUN은 네트워크 패킷을 받습니다

시스템 프록시의 작동 경로

시스템 프록시를 활성화하면 Clash 클라이언트는 일반적으로 운영체제의 HTTP, HTTPS 또는 SOCKS 프록시 주소를 로컬 루프백 주소로 설정하고 코어의 리스닝 포트를 지정합니다. 예를 들어 코어가 127.0.0.1:7890에서 실행 중이라면 시스템 프록시를 지원하는 브라우저나 데스크톱 앱이 해당 설정을 읽고 요청을 이 포트로 전달합니다. 시스템 프록시를 끄면 클라이언트가 이전 운영체제 설정을 복원합니다.

이 방식은 애플리케이션 계층에서 작동합니다. 앱이 시스템 프록시를 읽거나 운영체제가 제공하는 네트워크 인터페이스를 명시적으로 사용해야 트래픽이 Clash로 들어옵니다. 일반적인 브라우저, 오피스 프로그램과 일부 데스크톱 클라이언트는 대체로 바로 작동하지만, 자체 네트워크 스택을 구현했거나 프록시 설정을 무시하거나 특정 프로토콜만 지원하는 프로그램은 직접 연결을 계속할 수 있습니다. 명령줄 도구도 동작이 다릅니다. 환경 변수를 읽는 도구가 있는 반면, 별도로 HTTP_PROXY, HTTPS_PROXY 또는 SOCKS 주소를 지정해야 하는 도구도 있습니다.

TUN 모드의 작동 경로

TUN 모드는 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 통해 조건에 맞는 IP 트래픽을 해당 인터페이스로 보냅니다. mihomo 코어는 가상 인터페이스에서 네트워크 패킷을 읽어 대상 주소와 프로토콜을 식별한 다음, 규칙에 따라 직접 연결할지, 거부할지, 프록시 노드로 전달할지를 결정합니다. 진입점이 운영체제의 네트워크 계층에 더 가깝기 때문에 앱은 HTTP 또는 SOCKS 프록시를 이해하거나 시스템 프록시 설정을 직접 읽을 필요가 없습니다.

따라서 TUN은 게임 런처, 터미널 프로그램, 일부 스토어 앱, UDP를 사용하는 프로그램과 시스템 프록시를 무시하는 데스크톱 소프트웨어를 라우팅하는 데 더 적합합니다. 다만 TUN의 적용 범위는 라우팅 테이블, 제외 항목, 코어의 프로토콜 지원과 운영체제 제한에 영향을 받습니다. 로컬 네트워크 대역, 기본 네트워크 어댑터, 가상 머신 어댑터, 컨테이너 네트워크 또는 다른 VPN이 실제 경로를 바꿀 수 있으므로, 스위치가 켜져 있다는 사실만으로 라우팅이 완료됐다고 판단해서는 안 됩니다.

네 가지 핵심 차이: 적용 범위·프로토콜·DNS·권한

비교 항목 시스템 프록시 TUN 모드
작동 계층 앱이 운영체제의 프록시 설정을 읽은 후 로컬 프록시 포트에 연결 가상 네트워크 인터페이스가 시스템 라우팅을 거친 IP 트래픽을 수신
앱 적용 범위 주로 시스템 프록시를 따르는 프로그램에 적용 시스템 프록시를 무시하는 프로그램까지 더 폭넓게 적용 가능
프로토콜 범위 앱이 지원하는 HTTP·HTTPS·SOCKS 프록시 기능에 따라 결정 일반적으로 TCP를 통합 처리하며, UDP는 코어와 설정에 따라 처리
DNS 경로 앱, 프록시 프로토콜과 Clash DNS 설정에 따라 달라짐 DNS 하이재킹과 강화 모드를 함께 사용해 코어로 통합 전달 가능
시스템 권한 일반적으로 시스템 프록시 설정만 변경하면 됨 일반적으로 관리자 권한, 시스템 서비스 또는 네트워크 확장 기능이 필요
충돌 원인 브라우저 확장 프로그램, 수동 프록시, 남아 있는 프록시 주소 다른 VPN, 가상 네트워크 카드, 보안 소프트웨어, 라우팅 우선순위

앱 호환성은 단순히 “브라우저와 비브라우저”로 나뉘지 않습니다

브라우저는 대체로 시스템 프록시를 따르지만, 보안 DNS, QUIC, 브라우저 확장 프로그램과 기업 정책의 영향을 받을 수 있습니다. Chromium 기반 앱 중에는 시스템 네트워크 설정을 재사용하는 앱도 있고 자체 프록시 옵션을 제공하는 앱도 있습니다. 게임 플랫폼은 런처, 업데이트 프로그램, 로그인 구성 요소와 게임 프로세스로 구성될 수 있으며, 이 중 일부만 시스템 프록시를 읽습니다. 따라서 웹페이지가 열린다고 해서 다운로드, 로그인과 실시간 통신까지 같은 경로를 사용한다고 볼 수는 없습니다.

TUN 모드는 더 낮은 계층에서 이러한 연결을 받아 일반적으로 더 넓은 범위에 적용할 수 있습니다. UDP 트래픽이 정상적으로 전달되는지는 노드 프로토콜, 프록시 서버, 정책 규칙과 코어 설정에 따라 달라집니다. TUN을 켜는 것은 진입점을 제공할 뿐이며, 상위 노드가 지원하지 않는 기능을 자동으로 추가하지는 않습니다.

DNS 처리가 안정적인 도메인 규칙 매칭을 좌우합니다

시스템 프록시 환경에서는 DNS를 앱이 로컬에서 조회할 수도 있고, 프록시 프로토콜을 통해 코어가 처리하도록 전달할 수도 있습니다. 프로그램마다 동작이 일치하지 않습니다. 도메인이 Clash에 도달하기 전에 IP로 해석되면 코어가 얻는 정보가 도메인 요청을 직접 받은 경우와 달라질 수 있으며, 규칙 매칭 결과도 바뀔 수 있습니다. 브라우저의 자체 암호화 DNS 설정이 운영체제 DNS 경로를 우회하는 경우도 있습니다.

TUN은 mihomo의 DNS 모듈, dns-hijack, Fake-IP 또는 Redir-Host 모드와 함께 사용하는 경우가 많습니다. DNS 요청이 먼저 코어로 들어오면 코어가 도메인 매핑과 이후 연결을 연결해 도메인 규칙을 적용할 수 있습니다. Fake-IP는 로컬 매핑에 사용하는 가상 주소를 반환하며, 실제 대상의 해석과 프록시 선택은 코어가 계속 처리합니다. 로컬 네트워크 기기 검색, 게임 플랫폼과 특수한 DNS 결과에 의존하는 앱은 Fake-IP 제외 목록에 추가하거나 현재 환경에 더 적합한 DNS 강화 모드로 바꿔야 할 수 있습니다.

권한과 시스템 변경 범위가 다릅니다

시스템 프록시는 주로 운영체제에 저장된 프록시 주소를 수정하므로 필요한 권한이 비교적 적습니다. TUN은 가상 인터페이스를 만들고 라우팅을 조정해야 하므로 Windows 클라이언트는 관리자 권한이나 백그라운드 서비스로 실행되는 경우가 많고, macOS에서는 네트워크 확장 기능 승인이 필요할 수 있습니다. Android와 iOS는 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 라우팅합니다. 처음 활성화할 때 권한 확인이 나타나는 것은 네트워크 진입점을 만드는 정상적인 절차입니다.

권한 승인이 완료된 뒤에도 서비스가 실제로 시작됐는지 확인해야 합니다. 클라이언트 화면에 TUN이 켜졌다고 표시되어도 라우팅 기록, DNS 하이재킹과 기본 인터페이스 식별이 모두 성공했다는 뜻은 아닙니다. mihomo 로그에 나타나는 인터페이스 생성, 라우팅 설정과 리스닝 오류가 스위치 상태만 보는 것보다 더 유용한 판단 근거입니다.

선택 방법: 기기와 앱 적용 범위에 따라 판단하세요

일상적인 웹 사용과 업무: 먼저 시스템 프록시 사용

주요 용도가 브라우저 접속, 문서 동기화와 시스템 프록시를 따르는 데스크톱 앱이라면 시스템 프록시가 대체로 더 간단합니다. 라우팅 테이블에 미치는 영향이 작고 켜고 끄는 경로가 명확하며, 앱이 프록시를 능동적으로 사용하는지도 확인하기 쉽습니다. 문제가 발생하면 가상 네트워크 카드와 라우팅 충돌을 동시에 다루지 않고 로컬 포트, 운영체제 프록시 주소와 정책 그룹부터 점검할 수 있습니다.

게임·명령줄·독립 네트워크 스택: TUN 우선 점검

앱이 시스템 프록시를 명시적으로 무시하거나 UDP, 업데이트 프로그램, 하위 프로세스와 독립 로그인 구성 요소를 포함한다면 TUN을 주요 라우팅 진입점으로 사용할 수 있습니다. 대표적인 사례로는 프록시 변수를 읽지 않는 터미널 패키지 관리자, 플랫폼에서는 다운로드되지만 게임 연결은 직접 연결되는 경우, 시스템 프록시를 사용하지 못하는 스토어 앱과 한 프로그램의 구성 요소마다 네트워크 경로가 다른 경우가 있습니다.

모바일 기기: 시스템 VPN 인터페이스가 TUN 역할을 맡는 경우가 많습니다

모바일 운영체제의 Wi-Fi 수동 프록시는 일반적으로 현재 무선 네트워크에만 적용되며, 앱이 해당 설정을 따를지는 앱 구현에 따라 달라집니다. 셀룰러 네트워크에서는 이 Wi-Fi 프록시 설정을 사용하지 않습니다. 기기 전체에 적용하려면 Clash 또는 mihomo를 지원하는 클라이언트가 보통 시스템 VPN 인터페이스를 통해 터널을 만듭니다. 시스템 상태 표시줄에 VPN이 표시된 뒤에도 클라이언트 로그에서 연결이 실제로 규칙에 따라 처리되는지 확인해야 합니다.

개발 환경·가상 머신·컨테이너: 먼저 라우팅 경계를 확인하세요

가상 머신과 컨테이너는 일반적으로 독립된 네트워크 카드, 게이트웨이 또는 네트워크 네임스페이스를 사용합니다. 호스트에서 TUN을 켰을 때 게스트 시스템의 트래픽이 해당 인터페이스로 들어가는지는 브리지, NAT와 기본 라우팅 관계에 따라 달라집니다. 컨테이너에서 호스트의 루프백 주소에 접근할 때 127.0.0.1은 컨테이너 자신을 가리키며 호스트의 Clash 포트를 의미하지 않습니다. 이러한 환경에서는 먼저 호스트, 가상 네트워크 카드, 컨테이너 브리지와 외부 연결 네트워크 카드 사이의 경로를 그린 다음 TUN, LAN 수신 또는 앱 수준 프록시 중 적합한 방식을 선택해야 합니다.

시스템 프록시와 TUN을 동시에 켜야 할까요?

대부분의 경우 주요 진입점 하나만 선택하는 편이 문제를 찾기 쉽습니다. TUN이 대상 앱을 안정적으로 라우팅한다면 시스템 프록시는 필수가 아니며, 브라우저와 일반 데스크톱 앱만 사용한다면 적용 범위를 넓히기 위해 TUN을 계속 켜 둘 필요도 없습니다. 일부 클라이언트는 두 방식을 동시에 실행할 수 있고 코어가 로컬 연결과 라우팅 제외 항목을 처리하기도 하지만, 복잡한 환경에서는 트래픽 우회, 루프백 또는 실제 진입점을 판단하기 어려운 문제가 발생할 수 있습니다.

두 방식을 함께 켜야 한다면 시스템 프록시가 현재 코어 포트를 가리키는지, TUN에서 필요한 로컬 주소가 제외됐는지, 로그에서 같은 연결이 한 번만 수신되는지를 확인해야 합니다. 라우팅 방식을 바꿔 테스트할 때는 이전 진입점을 먼저 끈 뒤 새 진입점을 시작하는 것이 좋습니다. 남아 있는 시스템 프록시나 이전 라우팅이 결과에 영향을 주는 것을 막을 수 있습니다.

설정 순서: 먼저 구성을 검증한 뒤 적용 범위를 넓히세요

  1. 구독을 업데이트합니다. 구성이 정상적으로 로드되고 프록시 노드와 정책 그룹이 표시되는지 확인하세요. 구독 오류를 트래픽 라우팅 실패로 잘못 판단하는 일을 막을 수 있습니다.
  2. 규칙 모드를 선택합니다. 일반적인 사용에서는 먼저 Rule로 설정하고 기본 정책 그룹에 사용 가능한 노드가 있는지 확인하세요. Global과 Direct는 짧은 시간 동안 문제를 좁히는 데 사용할 수 있지만, TUN이 적용됐는지를 판단하는 유일한 기준으로 삼아서는 안 됩니다.
  3. 먼저 시스템 프록시를 테스트합니다. 시스템 프록시를 켠 뒤 해당 설정을 확실히 따르는 브라우저로 대상 사이트에 접속하고, Clash 연결 기록에 도메인·규칙·정책 그룹이 표시되는지 확인하세요.
  4. 라우팅되지 않는 앱을 식별합니다. 특정 프로그램에 연결 기록이 전혀 없다면 자체 프록시 설정을 제공하는지, 환경 변수가 필요한지, UDP와 독립 네트워크 스택을 사용하는지 확인하세요.
  5. 그다음 TUN을 활성화합니다. 시스템 권한 승인을 완료하고 가상 인터페이스, 자동 라우팅, 기본 네트워크 카드 식별과 DNS 설정을 확인하세요.
  6. 다른 네트워크 도구는 하나씩 다시 활성화합니다. 먼저 단일 네트워크 환경에서 검증한 다음 다른 VPN, 가상 머신이나 보안 소프트웨어를 실행해 라우팅 충돌 원인을 쉽게 찾을 수 있도록 하세요.

mihomo 구성에서 자주 사용하는 TUN 기본 구조는 다음과 같습니다. 클라이언트에 따라 그래픽 인터페이스가 이러한 필드를 생성할 수 있으며, 실제 지원 항목은 클라이언트에 통합된 코어 버전에 따라 달라집니다.

mixed-port: 7890
mode: rule

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

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

auto-route는 필요한 라우팅을 자동으로 기록하고, auto-detect-interface는 현재 기본 출구를 식별하며, dns-hijack는 조건에 맞는 DNS 요청을 코어로 보냅니다. stack의 사용 가능한 값과 구현은 코어 버전, 운영체제와 클라이언트 패키징 방식에 따라 달라질 수 있습니다. 현재 버전을 정확히 모르는 상태에서 설정 전체를 그대로 복사해 클라이언트가 생성한 항목을 덮어쓰지 마세요.

시스템 프록시에서는 주로 리스닝 포트를 확인해야 합니다. 구성에서 mixed-port를 사용하면 하나의 포트로 일반적인 HTTP와 SOCKS 프록시 연결을 받을 수 있습니다. 클라이언트가 시스템 설정에 기록하는 포트는 코어가 실제로 수신 대기 중인 포트와 일치해야 합니다. 구성 포트를 변경했는데 운영체제에 이전 포트가 남아 있으면 시스템 프록시를 따르는 앱은 갑자기 모두 연결되지 않을 수 있지만, TUN으로 라우팅되는 프로그램은 계속 작동할 수 있습니다.

문제 점검: 진입점·DNS·규칙·출구 네 단계로 확인

첫 번째 단계: 트래픽이 코어에 들어오는가

클라이언트의 연결 목록이나 실시간 로그를 열고 대상 앱을 실행하세요. 새 연결이 전혀 나타나지 않으면 시스템 프록시 주소, TUN 서비스 상태, 앱 자체 프록시, 라우팅 테이블과 방화벽을 먼저 확인하세요. 이때 노드를 먼저 바꾸지 마세요. 노드는 코어에 들어와 프록시 정책에 할당된 연결에만 영향을 줍니다.

두 번째 단계: 도메인이 올바르게 확인되는가

연결 기록에 IP만 표시되거나 도메인 규칙이 매칭되지 않거나, 앱이 도메인 확인 단계에서 시간 초과된다면 DNS 모듈 활성화 여부, TUN의 DNS 하이재킹 작동 여부, 브라우저의 독립 보안 DNS 사용 여부와 Fake-IP 제외 규칙이 지나치게 넓지 않은지를 확인하세요. 로컬 네트워크 도메인과 기기 검색 프로토콜에는 로컬 확인 경로를 유지해야 합니다.

세 번째 단계: 규칙과 정책 그룹을 올바르게 선택했는가

트래픽은 나타나지만 예상과 다른 방향으로 연결된다면 최종 매칭 규칙, 정책 그룹과 노드를 확인하세요. 규칙은 일반적으로 구성에 적힌 순서대로 매칭되므로, 앞에 있는 범위가 넓은 규칙이 뒤의 정밀한 규칙을 덮어쓸 수 있습니다. 구독을 업데이트하면 정책 그룹 선택이 다시 구성될 수 있으므로 현재 그룹에서 선택된 노드를 다시 확인해야 합니다.

네 번째 단계: 노드와 물리 네트워크에 연결할 수 있는가

규칙이 프록시에 매칭됐는데 연결 시간이 초과될 때 출구를 점검합니다. 노드 상태, 노드 프로토콜의 TCP 또는 UDP 지원 여부, 현재 네트워크의 대상 포트 제한과 기본 출구 네트워크 카드가 올바른지를 차례로 확인하세요. 유선 네트워크에서 Wi-Fi로 바꾸거나 Wi-Fi에서 모바일 핫스팟으로 전환한 뒤에는 TUN이 기본 인터페이스를 다시 식별해야 할 수 있습니다.

결론: 현재 기기에 필요한 최소 범위만 라우팅하세요

시스템 프록시는 앱이 운영체제 설정을 능동적으로 읽는 방식으로 구조가 간단하며 브라우저와 일반 데스크톱 소프트웨어에 적합합니다. TUN은 가상 인터페이스로 네트워크 패킷을 받아 더 넓은 범위에 적용할 수 있어 시스템 프록시를 무시하거나 UDP를 사용하거나 여러 네트워크 구성 요소를 포함한 앱에 적합합니다. 대신 권한, 라우팅, DNS와 가상 네트워크 카드 충돌을 추가로 점검해야 합니다.

선택할 때 특정 모드를 고정적으로 고집할 필요는 없습니다. 먼저 시스템 프록시로 구독, 노드와 규칙 경로를 검증한 다음 대상 앱이 코어에 들어오지 않는 경우 TUN을 활성화해 적용 범위를 넓히세요. 어떤 진입점을 사용하든 연결 로그로 트래픽이 코어에 들어왔는지 확인하고 DNS, 규칙, 정책 그룹과 실제 출구를 계속 점검해야 합니다. 이 네 가지 계층을 순서대로 확인하는 편이 스위치만 반복해서 바꾸는 것보다 구체적인 문제 지점을 찾기 쉽습니다.

Clash 다운로드