Clash TUN 모드와 시스템 프록시의 작동 원리 비교

시스템 프록시의 작동 방식: 애플리케이션이 직접 설정을 읽는 구조

시스템 프록시(System Proxy)는 운영체제가 제공하는 표준 인터페이스로, Windows의 "네트워크 및 인터넷 - 프록시", macOS의 "시스템 설정 - 네트워크 - 프록시"가 여기에 해당합니다. Clash 클라이언트에서 시스템 프록시를 켜면 실제로는 시스템의 HTTP/HTTPS 프록시 주소를 로컬의 127.0.0.1:7890(포트는 실제 설정에 따라 다름)으로 지정하고, 이를 레지스트리 또는 시스템 설정 파일에 기록하는 동작이 일어납니다.

핵심은 이것이 하나의 "권장 설정"일 뿐이며, 실제로 적용되는지는 각 애플리케이션이 이 설정을 읽어들이느냐에 완전히 달려 있다는 점입니다. 브라우저와 대부분의 GUI 소프트웨어는 시스템 프록시 설정을 능동적으로 확인하고 따르므로 웹 브라우징에는 프록시가 즉시 적용됩니다. 하지만 상당수 프로그램은 시스템 프록시를 따르지 않는데, 대표적으로 다음과 같습니다.

• 시스템 네트워크 라이브러리를 사용하지 않고 자체적으로 네트워크 스택을 구현한 명령줄 도구, 예를 들어 Go로 정적 컴파일된 일부 CLI 프로그램.
• 게임 클라이언트, 특히 실시간 동기화에 UDP 프로토콜을 사용하는 게임은 많은 게임 엔진이 시스템 프록시 인터페이스를 거치지 않습니다.
• 백그라운드 업데이트 서비스, 드라이버, 시스템 수준 컴포넌트는 대부분 더 높은 권한이나 독립된 네트워크 컨텍스트에서 동작합니다.
• 일부 Electron 애플리케이션도 프록시 환경 변수를 명시적으로 읽지 않으면 시스템 프록시를 건너뛸 수 있습니다.

다시 말해 시스템 프록시는 "애플리케이션 계층의 신사협정"에 가깝습니다. Clash가 주소를 지정해줘도, 이를 실제로 따를지는 애플리케이션의 몫입니다. "클라이언트는 연결됐다고 표시되고 브라우저는 인터넷이 되는데, 특정 소프트웨어만 안 된다"는 사례의 본질은 대부분 그 소프트웨어가 시스템 프록시를 거치지 않아서입니다.

TUN 모드의 작동 방식: 가상 네트워크 인터페이스가 네트워크 계층을 처리

TUN 모드(Clash Meta / mihomo 코어에서는 Tun Mode라고도 부름)는 완전히 다른 방식으로 동작합니다. 활성화하면 클라이언트가 시스템에 가상 네트워크 인터페이스(가상 네트워크 어댑터)를 생성하고, 로컬 라우팅 테이블을 수정하여 네트워크 계층(IP 계층)에서 트래픽을 이 가상 인터페이스로 유도한 뒤, Clash 코어가 이를 수신·해석하여 규칙에 따라 전달합니다.

가로채기가 애플리케이션 계층이 아니라 라우팅 계층에서 일어나기 때문에, 트래픽이 프록시를 거치는지는 특정 프로그램이 프록시 프로토콜을 지원하는지와 무관해집니다. 어떤 프로세스든 IP 패킷을 생성해 시스템 네트워크 스택에 전달하면 가상 네트워크 인터페이스가 이를 가로챕니다. 이는 다음을 의미합니다.

• 시스템 프록시 설정을 인식하지 못하는 CLI 도구도 TUN 모드로 처리할 수 있습니다.
• 대부분의 게임 UDP 트래픽도 TUN 모드로 처리할 수 있습니다(다만 실제 효과는 게임이 사용하는 전송 방식, IPv6 사용 여부에 따라 달라질 수 있습니다).
• 시스템 백그라운드 서비스나 브라우저가 아닌 프로세스가 보내는 요청도 마찬가지로 가상 네트워크 인터페이스를 거칩니다.

시스템 프록시는 "입구에 안내문을 붙여두고 들어오는 사람이 자발적으로 검사에 협조하는" 방식이고, TUN 모드는 "입구를 반드시 지나야 하는 검사 통로로 바꿔서 드나드는 모든 사람을 스캔하는" 방식에 비유할 수 있습니다. 전자는 상대방의 협조에 의존하고, 후자는 그렇지 않습니다.

TUN 모드에서 자주 사용하는 설정 항목

mihomo 코어의 설정 파일에서 TUN 모드의 핵심 필드는 대략 다음과 같습니다(아래는 YAML 예시이며, 실제 필드명은 사용 중인 클라이언트의 설정 구조에 따라 다를 수 있습니다).

tun:
  enable: true
  stack: system     # 또는 gvisor / mixed, 가상 네트워크 인터페이스의 구현 방식을 결정
  dns-hijack:
    - any:53
  auto-route: true   # 시스템 라우팅 테이블을 자동으로 처리
  auto-detect-interface: true

auto-route는 라우팅 테이블을 자동으로 수정할지를 결정하고, dns-hijack은 DNS 조회도 함께 Clash 내부로 가로채 처리할지를 결정합니다. 이는 fake-ip 같은 DNS 처리 방식과 함께 사용되어, 일부 애플리케이션이 프록시를 건너뛰고 직접 DNS 요청을 보내는 상황을 막는 데 도움이 됩니다.

두 모드의 차이 비교

핵심 차이를 표로 정리하면 바로 비교하기 쉽습니다.

명령줄 도구와 게임, 어떤 모드를 선택해야 할까

위에서 설명한 원리 차이를 바탕으로 비교적 명확한 판단 기준을 세울 수 있습니다.

명령줄 도구를 사용하는 경우

평소 터미널에서 패키지 관리자, 버전 관리 도구, 스크립트용 요청 라이브러리를 사용한다면 먼저 HTTP_PROXY / HTTPS_PROXY 환경 변수를 읽을 수 있는지 확인하세요. 지원한다면 시스템 프록시를 켜고 환경 변수를 함께 설정하는 것만으로 대부분 충분하며, 굳이 TUN 모드를 추가로 켤 필요는 없습니다. 도구가 프록시 환경 변수를 명확히 지원하지 않으면서도 인터넷 연결이 필요한 경우에만 TUN 모드를 최후 수단으로 고려하면 됩니다.

# 현재 터미널 세션에서 임시로 프록시 환경 변수를 설정(예시 포트는 실제 설정에 맞게 변경)
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

게임을 플레이하는 경우

게임 클라이언트는 대부분 시스템 프록시 설정을 읽지 않으며, 특히 자체 네트워크 프로토콜을 사용하거나 UDP로 서버에 직접 연결하는 게임이 그렇습니다. 이런 경우 시스템 프록시는 거의 효과가 없으므로 네트워크 계층에서 강제로 처리하는 TUN 모드가 필요합니다. TUN 모드를 켠 뒤에는 클라이언트 규칙에서 해당 게임의 도메인이나 IP 대역에 별도의 정책 그룹을 설정해, 게임 트래픽이 다른 트래픽과 같은 노드를 사용해 지연이 흔들리는 상황을 피하는 것이 좋습니다.

일상적인 웹 서핑과 업무 환경

주로 브라우저로 웹을 보고, 영상을 시청하고, 시스템 프록시를 따르는 몇몇 데스크톱 앱만 사용한다면 시스템 프록시 모드만으로 충분하며, 굳이 TUN 모드를 추가로 켤 필요는 없습니다. TUN 모드는 적용 범위가 넓지만 더 높은 권한이 필요하고 라우팅 테이블 변경도 더 근본적이라, 문제가 생겼을 때 원인 파악이 더 까다롭습니다. "기능은 강력하지만 부담도 큰" 방식이므로 필요할 때만 켜는 것이 좋습니다.

모드를 전환할 때 자주 발생하는 문제

TUN 모드를 켠 뒤 인터넷이 전혀 안 되는 경우

대부분 권한 부족으로 가상 네트워크 인터페이스 생성에 실패했거나, 다른 네트워크 도구(일부 VPN 클라이언트 등)가 동시에 라우팅 테이블을 점유해 충돌이 발생한 경우입니다. 라우팅 테이블을 수정하는 다른 네트워크 도구를 먼저 종료하고, 관리자/root 권한으로 Clash 클라이언트를 다시 실행해 보세요.

TUN 모드를 켠 뒤 일부 사이트 접속이 이상한 경우

보통 DNS 가로채기와 분기 규칙 문제입니다. dns-hijack 설정과, 직접 연결해야 하는 도메인이 잘못된 규칙으로 프록시 노드로 라우팅되지는 않았는지 확인해 보세요.

시스템 프록시를 켰는데도 특정 소프트웨어가 계속 직접 연결되는 경우

이는 앞서 설명한 정상적인 현상으로, 해당 소프트웨어가 시스템 프록시 설정을 읽지 않는 것입니다. 해결하려면 그 소프트웨어에 별도로 프록시 환경 변수를 설정하거나, TUN 모드로 전환하면 됩니다.

두 모드를 동시에 켤 수 있는가

기술적으로는 동시에 켤 수 있지만 큰 의미는 없습니다. TUN 모드가 이미 네트워크 계층에서 대부분의 트래픽을 처리하므로, 시스템 프록시의 역할은 가려지거나 불필요한 판단 과정만 늘어납니다. 일반적으로는 상황에 맞게 둘 중 하나만 선택해서 변수를 줄이는 것을 권장합니다.