TUN 모드와 시스템 프록시의 차이: 트래픽 처리 메커니즘 완전 분석
많은 사람들이 이 둘을 그냥 "설정 화면의 스위치 두 개" 정도로 여기고 감으로 켜고 끕니다. 시스템 프록시는 앱이 설정을 읽어 프록시 포트에 스스로 연결하는 방식이고, TUN은 네트워크 계층에서 데이터 패킷을 가로채므로 앱이 원하든 말든 상관없습니다. 이 계층 차이가 적용 범위, DNS 동작, 그리고 문제 발생 시 확인해야 할 방향을 결정합니다.
두 메커니즘 먼저 구분하기: 각각 어느 계층에서 동작하는가
차이를 이해하려면 먼저 앱에서 요청이 나가 실제로 인터넷에 도달하기까지 몇 개의 계층을 거치는지 알아야 합니다. 시스템 프록시와 TUN 모드가 가로채는 계층은 서로 다르며, 이것이 모든 동작 차이의 근본 원인입니다.
시스템 프록시는 애플리케이션 계층에서 동작합니다. 운영체제가 "프록시 설정" 인터페이스를 제공하면 브라우저, 터미널 도구, 일부 데스크톱 앱이 이 설정을 읽어 자신의 네트워크 요청을 지정된 프록시 포트로 스스로 전달합니다. 이 전달 동작은 앱이 직접 구현하는 것이며, OS는 해당 설정 값을 저장하고 읽으려는 프로그램에게 알려주는 역할만 합니다.
TUN 모드는 네트워크 계층, 더 정확히는 IP 패킷 수준에서 동작합니다. Clash Meta(mihomo)에서 TUN을 켜면 시스템에 가상 네트워크 인터페이스가 생성되고, 라우팅 테이블을 수정해 기본 경로를 이 가상 네트워크 카드로 향하게 만듭니다. 이후 IP 프로토콜로 나가는 모든 데이터 패킷은 어떤 프로세스에서 왔든 상관없이 먼저 이 가상 네트워크 카드를 거쳐 커널이 Clash로 전달하며, 규칙에 따라 직접 연결할지 프록시 노드를 경유할지 결정됩니다.
한 줄로 정리하면: 시스템 프록시는 "설정을 만들어두고 앱이 알아서 읽는 방식"이고, TUN은 "경로 자체를 바꿔서 패킷이 다른 길로 갈 수 없게 만드는 방식"입니다.
시스템 프록시: 앱이 자발적으로 따르는 위임 방식
시스템 프록시가 실제로 구현되는 방식은 운영체제마다 조금씩 다르지만 핵심 원리는 동일합니다.
- Windows / macOS 그래픽 인터페이스——시스템이 전역 프록시 설정 항목을 제공하며, Clash 클라이언트에서 "시스템 프록시로 설정"을 켜면 이 설정이 시스템 환경설정에 기록되고, 대부분의 주요 브라우저와 최신 앱들이 기본적으로 이를 읽어들입니다.
- 명령줄 터미널——
http_proxy,https_proxy같은 환경 변수를 인식하며, 시스템 차원의 프록시 설정은 터미널에는 대부분 적용되지 않으므로 별도로 export 해야 합니다. - PAC 스크립트——일부 클라이언트는 PAC(Proxy Auto-Config) 파일을 사용해 도메인별로 프록시 경유 여부를 동적으로 판단하며, 브라우저가 이 스크립트를 불러와 규칙에 따라 경로를 결정합니다.
이 메커니즘은 "앱이 협조할 의사가 있다"는 전제 위에서 동작합니다. 어떤 프로그램이 연결 주소를 내부에 하드코딩해두었거나 시스템 프록시 설정을 전혀 확인하지 않는다면(일부 게임, 업데이트 서비스, 백그라운드 데몬 프로세스에서 흔함) 시스템 프록시는 그 프로그램에 아무 효과가 없고 트래픽은 그대로 직접 연결됩니다. 시스템 프록시를 켰는데 브라우저 트래픽 분배는 정상인데 특정 클라이언트 프로그램만 계속 프록시 노드에 연결되지 않는 이유도 바로 이것입니다. 그 프로그램이 "자발적으로 따르는" 부류에 속하지 않기 때문입니다.
시스템 프록시는 새로 실행되는 프로세스에는 즉시 적용되지만, 이미 실행 중이며 시작 시점에 네트워크 설정을 캐시해둔 프로그램은 새 프록시 설정을 인식하려면 재시작이 필요한 경우가 있습니다. "프록시는 켰는데 특정 소프트웨어만 우회하는" 문제를 진단할 때는 먼저 해당 프로그램을 재시작해보고, 그다음 규칙을 확인하세요.
TUN 모드: 네트워크 계층에 가상 네트워크 카드를 만들어 전체 트래픽을 가로챈다
TUN 모드는 앱의 협조가 필요 없으며, 데이터 패킷이 기기를 떠나기 전에 반드시 거쳐야 하는 경로 자체를 바꿉니다. 활성화 시 대략 다음과 같은 과정이 일어납니다.
- Clash Meta(mihomo) 코어가 가상 네트워크 인터페이스(흔히
utun,Meta같은 이름)를 생성하는데, 이 네트워크 카드는 시스템 관점에서 실제 네트워크 어댑터와 동일하게 취급됩니다. - 로컬 라우팅 테이블을 수정해 기본 경로(또는 지정된 네트워크 대역)를 이 가상 네트워크 카드로 향하게 하며, 기존 물리 네트워크 카드 경로보다 우선순위를 높게 설정합니다.
- 시스템 커널이 라우팅 테이블에 따라 패킷을 전달할 때, 기본 경로에 매칭되는 트래픽은 먼저 가상 네트워크 카드로 보내지고, Clash 프로세스가 이를 읽어 파싱한 뒤 규칙에 따라 처리합니다.
- 처리가 끝난 트래픽은 프록시 노드 또는 직접 연결 경로를 통해 나가고, 응답 패킷은 원래 경로를 거쳐 요청을 보낸 프로세스로 돌아오는데, 프로세스 자신은 이 전달 과정 전체를 전혀 인지하지 못합니다.
가로채기가 라우팅 계층에서 일어나기 때문에 IP 프로토콜로 나가는 모든 트래픽이 걸러집니다. 브라우저, 명령줄 도구, 시스템 백그라운드 서비스를 구분하지 않고, 이들이 프록시 설정을 지원하는지도 상관없습니다. 이것이 바로 TUN 모드의 가장 큰 가치입니다. "말을 안 듣는" 프로세스의 트래픽까지 처리할 수 있다는 점입니다.
그만큼 대가도 직접적입니다. 가상 네트워크 카드는 시스템 하위 네트워크 스택과 관련되어 있어 권한 요구 사항이 높고(Windows에서는 보통 관리자 권한 실행이나 드라이버 인증이 필요하고, macOS에서는 시스템 확장 기능이나 root 권한 서비스 모드의 보조가 필요합니다), 설정을 잘못하면 문제 발생 범위도 넓어집니다. 라우팅 테이블 충돌, 다른 VPN 소프트웨어와의 기본 경로 경쟁, 방화벽이 가상 네트워크 카드 트래픽을 차단하는 문제 등은 모두 TUN 모드에서만 나타나는 특유의 점검 항목이며, 시스템 프록시 모드에서는 거의 겪지 않는 문제입니다.
DNS 처리: 두 메커니즘의 차이가 가장 크게 드러나는 부분
DNS 해석이 프록시를 경유하는지, 로컬에서 처리되는지는 두 메커니즘의 동작 차이가 가장 뚜렷하게 나타나는 부분이며, 초보자가 가장 혼란스러워하는 지점이기도 합니다.
시스템 프록시 모드에서는 DNS 요청이 보통 Clash를 거치지 않습니다. Clash는 앱이 직접 시작한 TCP/HTTP 연결만 가로채며, 도메인 해석 단계는 많은 경우 기존의 로컬 DNS 서버를 통해 그대로 처리된 뒤 그 결과 주소를 가지고 프록시에 연결합니다. 즉 DNS 조회 자체가 현지 통신사에 노출될 수 있고, 로컬 DNS가 오염되어 있다면 해석된 주소 자체가 잘못되어 연결이 실패하거나 잘못된 서버에 연결될 수 있습니다.
TUN 모드에서는 Clash Meta(mihomo)가 DNS 요청 자체를 가로챌 수 있으며, 흔히 사용하는 방식이 fake-ip입니다. 코어가 도메인에 임시로 가짜 IP 대역을 할당하고, 앱은 이 가짜 IP로 연결을 시도하는데, Clash가 네트워크 계층에서 이 연결이 어떤 도메인에 해당하는지 식별한 뒤 규칙에 따라 프록시 경유 또는 직접 연결을 결정하고, 실제 해석은 프록시 서버 측에서 이루어집니다. 이렇게 되면 DNS 조회와 이후 연결 모두 Clash의 통제 범위 안에 있게 되어 도메인 오염이 판단 결과에 거의 영향을 주지 않습니다.
| 비교 항목 | 시스템 프록시 | TUN 모드 |
|---|---|---|
| 가로채는 계층 | 애플리케이션 계층, 앱의 협조 필요 | 네트워크 계층, 라우팅 테이블 기반 |
| 적용 범위 | 프록시 설정을 지원하는 앱 | 모든 IP 트래픽, 프로세스는 인지 못함 |
| DNS 처리 | 대부분 로컬 해석 경유 | fake-ip로 전체 가로채기 가능 |
| 권한 요구 사항 | 일반 사용자 권한으로 충분 | 관리자 권한 또는 시스템 서비스 필요 |
| 대표적인 문제 발생 지점 | 일부 앱이 시스템 설정을 읽지 않음 | 라우팅 충돌, 가상 네트워크 카드 이상 |
적용 범위 비교: 어떤 트래픽이 누락되는가
실제 사용 중 가장 많이 나오는 질문은 "프록시를 켰는데 왜 일부는 여전히 프록시를 안 타는가"입니다. 답은 대개 어떤 메커니즘을 쓰고 있는지에 따라 달라집니다.
시스템 프록시 모드에서 자주 누락되는 대표적인 경우:
- 명령줄 도구(
curl,git, 패키지 매니저)는 시스템 프록시를 인식하지 않고 환경 변수만 인식하므로, 따로 설정하지 않으면 직접 연결됩니다. - 일부 데스크톱 클라이언트(메신저, 다운로드 도구, 게임 업데이터)는 자체 네트워크 스택을 사용하며 시스템 프록시 설정을 확인하지 않습니다.
- 시스템 수준 백그라운드 서비스(자동 업데이트, 원격 측정 보고)는 보통 사용자 수준 프록시 설정의 영향을 받지 않습니다.
TUN 모드에서는 위 시나리오 대부분이 가로채집니다. 라우팅 계층은 프로세스 신원을 구분하지 않기 때문입니다. 다만 TUN 모드에도 나름의 "누락" 사례가 있습니다. 규칙에서 특정 네트워크 대역을 직접 연결로 설정해둔 경우(예: 로컬 네트워크 대역), 또는 가상 네트워크 카드의 라우팅 우선순위가 다른 네트워크 도구(일부 VPN 클라이언트, 가상머신 네트워크 카드 등)에 의해 선점된 경우 트래픽이 마찬가지로 Clash를 우회하게 됩니다. 이런 문제는 앱 설정이 아니라 라우팅 테이블과 네트워크 카드 우선순위를 확인하는 방향으로 진단해야 합니다.
어느 것을 써야 할까: 상황별 선택과 전환 기준
"어느 쪽이 더 좋다"의 문제가 아니라 "지금 필요와 어느 쪽이 맞는가"의 문제입니다. 실용적인 판단 기준 몇 가지를 정리해봤습니다.
- 브라우저를 주로 쓰고 자주 쓰는 도구가 몇 개뿐인 경우——시스템 프록시로 충분하고 설정도 간단하며 문제 발생 시 확인할 범위도 좁으니, 일단 이 모드부터 시작하는 것이 안전합니다.
- 명령줄 도구, 게임, 백그라운드 서비스 등 프록시 설정을 지원하지 않는 프로그램까지 커버해야 하는 경우——TUN 모드를 사용하세요. 이것이 바로 TUN 모드가 존재하는 핵심 이유입니다.
- 이미 다른 VPN을 쓰고 있거나 가상 네트워크 카드 충돌 이력이 있는 경우——TUN을 켜기 전에 먼저 라우팅 테이블을 점검해, 두 네트워크 가로채기 메커니즘이 경로를 두고 경쟁하면서 연결이 불안정해지는 상황을 피하세요.
- DNS 오염에 민감하거나 도메인 해석 정보 유출이 걱정되는 경우——TUN 모드와 fake-ip를 함께 쓰는 것이 더 확실합니다. 시스템 프록시는 DNS 조회 자체를 통제하지 못합니다.
두 모드는 상호 배타적이지 않으며 대부분의 클라이언트는 언제든 전환할 수 있습니다. 특정 상황에서 동작이 이상하다면 먼저 현재 어느 메커니즘을 쓰고 있는지 확인한 다음, 위의 차이표를 참고해 원인을 찾는 것이 무작정 재설치하거나 노드를 바꾸는 것보다 훨씬 효율적입니다.
연결 이상을 진단할 때 가장 먼저 할 일은 항상 지금 쓰고 있는 것이 시스템 프록시인지 TUN인지 확인하는 것입니다. 두 메커니즘은 문제 발생 양상이 완전히 다르기 때문에, 방향을 잘못 잡으면 이후에 무엇을 확인하든 시간만 낭비하게 됩니다.