두 가지 트래픽 인계 방식의 본질적 차이
Clash 클라이언트(및 mihomo 코어)는 시스템 프록시와 TUN 모드라는 전혀 다른 두 가지 트래픽 인계 방식을 제공합니다. 두 방식은 흔히 "효과가 비슷한 두 개의 스위치"로 여겨지지만, 운영체제 레벨에서의 동작 원리는 완전히 다르며, 이 차이가 어떤 트래픽이 프록시를 거치고 어떤 트래픽이 빠져나가는지를 직접적으로 결정합니다.
시스템 프록시는 운영체제 또는 브라우저의 프록시 설정 항목을 수정하여, 프록시 프로토콜을 지원하는 애플리케이션에게 "HTTP/HTTPS 요청을 이 주소와 포트로 보내라"고 알리는 방식입니다. 이는 애플리케이션 계층의 약속으로, 각 프로그램이 스스로 이 설정을 읽고 따르는 것에 의존합니다. Windows의 "네트워크 및 인터넷 설정", macOS의 "네트워크 환경설정", Linux 데스크톱 환경의 프록시 옵션은 본질적으로 조회 가능한 설정 값을 기록하는 것이며, 프로그램은 이를 읽은 뒤 사용 여부를 스스로 결정합니다.
TUN 모드는 완전히 다릅니다. 운영체제 커널 레벨에 가상 네트워크 인터페이스(virtual network interface)를 생성하여 시스템이 네트워크 카드가 하나 더 생긴 것처럼 인식하게 만듭니다. 이후 Clash는 라우팅 테이블 규칙이나 방화벽 규칙을 통해 기기에서 나가는 거의 모든 아웃바운드 트래픽을 이 가상 네트워크 카드로 유도하고, mihomo 코어가 사용자 영역에서 이 원시 IP 패킷을 해석하여 구체적인 연결 요청으로 복원한 후 규칙에 따라 전달합니다. 이 방식은 네트워크 계층에서 작동하며 애플리케이션의 "협조" 여부에 의존하지 않는, 더 하위 계층의 트래픽 하이재킹 메커니즘입니다.
시스템 프록시에서 트래픽이 누락되는 이유
시스템 프록시의 핵심적인 한계는 "자발적 준수" 메커니즘이지 강제 인계가 아니라는 점입니다. 이로 인해 실제로 자주 마주치는 여러 트래픽 누락 상황이 발생합니다.
시스템 프록시 설정을 읽지 않는 프로그램
많은 명령줄 도구, 백그라운드 서비스, 일부 데스크톱 프로그램은 시스템 프록시 설정을 능동적으로 조회하지 않고 직접 TCP 연결을 생성합니다. 흔한 예로 curl, git, ssh, 프록시를 명시적으로 설정하지 않은 일부 패키지 관리자(pip, npm 등), Electron 앱이 아닌 다수의 네이티브 클라이언트가 있습니다. 이런 프로그램이 보내는 요청은 Clash를 그대로 우회해 기기의 기본 네트워크 경로를 따라갑니다.
UDP 트래픽은 대체로 시스템 프록시의 제약을 받지 않음
시스템 프록시 설정은 본질적으로 TCP 기반의 HTTP/HTTPS 요청을 위해 설계된 것으로, 운영체제 레벨에는 통일된 "UDP 시스템 프록시" 개념이 존재하지 않습니다. 즉 UDP에 의존하는 애플리케이션—다수의 온라인 게임 실시간 동기화 트래픽, QUIC(HTTP/3) 기반 웹 요청, 일부 영상통화 소프트웨어, DNS 조회 자체 등—은 시스템 프록시 모드에서 대부분 Clash를 전혀 거치지 않습니다. 프록시 노드 자체가 UDP 전달을 지원하더라도(Shadowsocks, Trojan의 일부 구현 등) 시스템 프록시 모드에서는 이 기능을 활용할 수 없습니다.
게임 클라이언트의 특수성
게임은 네트워크 지연에 매우 민감하며, 대다수 게임 엔진은 하위 소켓 인터페이스를 직접 호출해 연결을 생성하고, 시스템 프록시를 조회하지도 애플리케이션 계층 프록시 프로토콜을 지원하지도 않는 경우가 많습니다. 게임 트래픽을 프록시로 보내려면 거의 반드시 네트워크 계층의 인계 방식에 의존해야 하며, 이런 상황에서는 시스템 프록시가 기본적으로 무효합니다.
시스템 프록시 모드에서 "일부 사이트는 접속되고 일부는 안 되는" 현상은 많은 경우 노드나 규칙 문제가 아니라, 해당 프로그램 자체가 시스템 프록시 설정을 따르지 않거나 시스템 프록시가 관리할 수 없는 UDP 채널을 사용하기 때문입니다. 문제 진단 전에 해당 프로그램의 네트워크 구현 방식을 먼저 확인하면 노드를 반복해서 바꾸는 시간을 상당히 줄일 수 있습니다.
TUN 모드가 전역 인계를 구현하는 방법
TUN 모드의 인계 범위는 훨씬 넓으며, 원리적으로 시스템 프록시가 놓치는 대부분의 상황을 포괄합니다. 이는 애플리케이션 계층이 아닌 네트워크 계층에서 작동하기 때문입니다.
- 프로그램의 협조에 의존하지 않음. 가상 네트워크 카드와 라우팅 테이블의 조합을 통해, 공용망으로 향하는 모든 데이터 패킷이 기본적으로 이 가상 인터페이스를 거치게 됩니다. 연결을 시작한 프로그램이 프록시의 존재를 "알든 모르든" 상관없으며, 이는 명령줄 도구와 프록시 설정을 지원하지 않는 프로그램에 특히 중요합니다.
- UDP를 네이티브로 지원. mihomo 코어는 TUN 트래픽을 처리할 때 UDP 데이터 패킷을 해석하여 규칙에 따라 전달하며, 선택한 프록시 노드가 해당 프로토콜의 UDP over 전송을 지원한다면 게임, 음성통화, QUIC 요청 모두 정상적으로 프록시를 거칠 수 있어 더 이상 시스템 프록시 모드의 사각지대가 아니게 됩니다.
- 기기의 모든 네트워크 인터페이스에 적용. 가상머신, 컨테이너, 일부 개발 환경에서 발생하는 트래픽도 최종적으로 시스템 기본 라우팅을 거치기만 하면 TUN 네트워크 카드에 의해 가로채지며, 애플리케이션별로 프록시를 설정하는 것보다 훨씬 포괄적입니다.
다만 TUN 모드가 "설정 없이 만능인 스위치"는 아니라는 점을 짚어야 합니다. 운영체제 레벨의 권한에 의존하는데, Windows에서는 가상 네트워크 카드를 생성하고 라우팅 테이블을 수정하기 위해 관리자 권한으로 실행해야 하며, macOS와 Linux에서는 보통 커널 확장을 설치하거나 특정 네트워크 확장 프레임워크를 사용하여 해당 권한을 부여해야 합니다. 일부 클라이언트(Clash Verge Rev, FlClash 등)는 설정 화면에서 "서비스 모드" 또는 "TUN 모드" 스위치를 제공하며, 활성화 전 권한 승인 안내가 표시되는 것이 일반적인 절차이며 오류가 아닙니다.
두 모드의 실제 차이 비교
| 비교 항목 | 시스템 프록시 | TUN 모드 |
|---|---|---|
| 동작 계층 | 애플리케이션 계층(프로그램이 설정을 능동 조회해야 함) | 네트워크 계층(가상 네트워크 카드 + 라우팅 테이블) |
| 명령줄 도구 커버리지 | 도구가 프록시 환경변수를 읽는지에 따라 다름 | 기본적으로 전부 커버 |
| UDP / 게임 트래픽 | 대체로 지원 안 됨 | 지원(노드 프로토콜 능력에 따라 다름) |
| 필요 권한 | 일반 사용자 권한으로 충분 | 관리자/root 권한 또는 시스템 네트워크 확장 승인 필요 |
| 활성화 비용 | 낮음, 스위치만 켜면 됨 | 비교적 높음, 최초 권한 설정 필요 |
| 로컬 네트워크 도구와의 호환성 | 기본적으로 충돌 없음 | 일부 가상머신 네트워크, VPN 클라이언트와 라우팅 충돌 가능 |
선택 방법:상황 중심 판단 기준
절대적으로 우월한 쪽은 없으며, 선택은 실제 사용 상황에 기반해야 합니다. 다음은 몇 가지 대표적인 판단 경로입니다.
단순한 웹 브라우징, 오피스 소프트웨어의 외부 서비스 접근
시스템 프록시로 충분합니다. 브라우저와 대부분의 오피스 클라이언트는 시스템 프록시 설정을 따르므로, TUN 모드가 가져오는 추가 권한 설정과 잠재적 라우팅 충돌 위험을 감수할 필요가 없습니다. 이는 대다수 클라이언트가 기본으로 제공하는 초기 모드이기도 합니다.
터미널에서 git, curl, 패키지 관리자 등을 사용해야 하는 경우
TUN 모드를 우선 고려하거나, 이런 도구들에 개별적으로 프록시 환경변수를 설정하는 방법(예: HTTP_PROXY/HTTPS_PROXY 환경변수를 Clash의 혼합 포트로 지정)이 있습니다. 후자는 더 가볍지만 도구마다 일일이 설정해야 하므로 TUN 모드로 한 번에 해결하는 것보다 번거롭습니다.
해외 서버에 접속해야 하는 온라인 게임을 즐기는 경우
기본적으로 TUN 모드에 의존할 수밖에 없습니다. 게임 트래픽은 UDP가 주류이며 시스템 프록시 설정을 읽지 않으므로, 시스템 프록시 모드에서는 게임 연결에 거의 아무런 영향도 주지 못합니다. 이는 커뮤니티에서 "프록시를 켰는데도 게임이 여전히 연결되지 않는" 흔한 원인 중 하나입니다.
회사 컴퓨터 또는 시스템 권한 변경에 신중해야 하는 환경
시스템 프록시 사용을 권장합니다. TUN 모드는 상당히 높은 시스템 권한이 필요하고 라우팅 테이블을 수정하므로, 관리되는 업무용 기기에서 활성화하기 전에 소속 기관의 기기 사용 규정에 부합하는지 확인해야 합니다.
주요 클라이언트(Clash Verge Rev, FlClash, Clash Plus 등)는 모두 설정 화면에서 시스템 프록시와 TUN 모드를 직접 전환할 수 있도록 지원하며, 설정 파일 필드를 수동으로 수정할 필요가 없습니다. TUN 모드를 처음 켤 때는 안내에 따라 한 번의 권한 승인만 완료하면 되고, 이후의 전환은 단순한 스위치 조작에 불과합니다.
동시 사용에 관한 몇 가지 설명
일부 사용자는 시스템 프록시와 TUN 모드를 동시에 켜기도 하는데, 이론적으로 충돌하지는 않지만 실제 의미는 제한적입니다. TUN 모드가 활성화되면 거의 모든 트래픽이 이미 라우팅 테이블에 의해 가상 네트워크 카드로 유도되므로 시스템 프록시 설정은 대체로 더 이상 트리거되지 않으며, 동시에 켜는 것은 심리적인 "이중 안전장치"에 가깝고 실질적으로 추가 커버리지를 가져오지 않습니다.
또한 TUN 모드는 일부 VPN 클라이언트, 가상머신 데스크톱 소프트웨어의 네트워크 어댑터와 라우팅 테이블 점유 경쟁이 발생할 수 있습니다. TUN 모드를 켠 뒤 가상머신 네트워크에 이상이 생기거나 다른 VPN 연결이 끊긴다면 대개 라우팅 우선순위 충돌이며, 설정에서 TUN의 라우팅 메트릭(metric)을 조정하거나 충돌하는 쪽을 일시적으로 끄고 원인을 파악하면 됩니다. Clash 자체의 오류로 의심할 필요는 없습니다.
어떤 모드를 선택하든 정책 그룹, 프록시 노드, 분기 규칙의 설정 로직은 공통적입니다. TUN 모드는 단지 "트래픽이 어떻게 Clash로 전달되는가"를 바꾸는 것일 뿐, 이후 규칙 판단·노드 선택·전달 처리 흐름은 시스템 프록시 모드와 완전히 동일합니다. 이 점을 이해하면 두 모드 간의 전환은 인계 방식의 선택에 불과하며, 새로운 규칙 체계를 다시 배울 필요가 없습니다.