TUN 모드의 원리

Linux에서 Clash Meta를 사용하면서 브라우저만 프록시되고 다른 프로그램은 우회되지 않는다면, 대부분 시스템 프록시의 한계 때문입니다. 일반적인 HTTP 또는 SOCKS 프록시는 해당 프록시를 인식하도록 설정된 애플리케이션만 사용할 수 있습니다. 터미널 도구, 패키지 관리자, 게임 런처, 메신저, 컨테이너 내부 프로세스처럼 별도의 프록시 설정을 갖지 않은 프로그램은 여전히 일반 네트워크 인터페이스로 연결될 수 있습니다.

TUN 모드는 운영체제 안에 가상 네트워크 인터페이스를 만들고, 애플리케이션의 IP 트래픽을 Clash Meta가 처리할 수 있는 경로로 전달합니다. 따라서 프로그램마다 프록시 주소를 반복해서 입력하지 않아도 시스템 전체의 연결을 규칙에 따라 분류할 수 있습니다. 국내 서비스는 DIRECT로 연결하고 해외 서비스는 프록시 그룹으로 보내는 식의 정책을 한 곳에서 관리할 수 있다는 점이 핵심입니다.

다만 TUN은 단순한 스위치가 아닙니다. 가상 인터페이스, 라우팅 테이블, DNS 응답 방식, 관리자 권한이 서로 맞아야 안정적으로 작동합니다. 설정을 대충 적용하면 인터넷이 끊기거나 DNS가 실제 네트워크로 빠져나가고, Clash를 종료한 뒤에도 잘못된 경로가 남을 수 있습니다. 이 글에서는 Ubuntu 계열을 중심으로 설명하지만, NetworkManager를 사용하는 대부분의 Linux 배포판에서도 원리는 같습니다.

핵심 요약

TUN 모드는 모든 앱의 트래픽을 Clash Meta의 규칙으로 가져오는 기능입니다. 먼저 설정을 백업하고, 권한과 DNS 상태를 확인한 뒤 단계적으로 활성화해야 합니다.

1사전 준비 사항 확인

설정 전에 사용하는 코어와 클라이언트가 TUN을 지원하는지 확인하세요. 최근에는 Clash Meta라는 이름보다 Mihomo라는 이름으로 배포되는 코어가 많습니다. 클라이언트 화면에 Clash Meta, Mihomo, Meta 코어 중 하나가 표시되는지 확인하고, 너무 오래된 실행 파일은 최신 설정 문법을 인식하지 못할 수 있으므로 업데이트하는 것이 좋습니다.

설정 백업과 기본 상태 확인

현재 사용하는 YAML 설정 파일을 별도 위치에 복사합니다. TUN 설정을 추가하기 전 원본을 보관하면 문제가 생겼을 때 빠르게 돌아갈 수 있습니다.
Clash가 사용하는 포트와 컨트롤러 주소를 확인합니다. 다른 프록시 프로그램이나 VPN이 같은 포트를 사용하면 실행은 되더라도 연결이 불안정해질 수 있습니다.
현재 네트워크가 정상인지 확인합니다. TUN을 켜기 전에 브라우저와 터미널에서 인터넷이 작동해야 원인 분리가 쉽습니다.
관리자 암호를 알고 있는지 확인합니다. 가상 네트워크 인터페이스를 만들고 라우팅을 변경하려면 일반 사용자 권한만으로는 부족한 경우가 많습니다.

Linux 환경 점검

대부분의 최신 배포판은 TUN 장치를 기본 지원하지만, 최소 설치 환경이나 가상 사설 서버에서는 모듈이 빠져 있을 수 있습니다. 다음 명령으로 장치 파일을 확인하세요.

ls -l /dev/net/tun
ip link show
ip route show

/dev/net/tun이 존재하고 네트워크 인터페이스와 기본 경로가 표시되면 기본 조건은 충족된 것입니다. 장치 파일이 없다면 무작정 설정 파일을 수정하기보다 커널 모듈과 호스팅 업체의 네트워크 제한을 먼저 확인해야 합니다.

가상 서버 사용자 주의

일부 컨테이너나 저가형 VPS는 TUN 장치와 네트워크 관리 권한을 제공하지 않습니다. 이 경우 설정이 올바르더라도 TUN 인터페이스가 생성되지 않을 수 있습니다.

2Clash Meta 설정 파일 작성

설정 파일에서는 tun과 dns가 가장 중요합니다. 세부 옵션의 이름은 코어 버전에 따라 조금씩 다를 수 있으므로, 사용 중인 Mihomo 버전의 문서를 기준으로 확인해야 합니다. 아래 예시는 기본적인 방향을 보여 주는 예시이며, 이미 사용 중인 프록시 그룹과 규칙은 자신의 환경에 맞게 유지해야 합니다.

mixed-port: 7890
mode: rule
allow-lan: false
log-level: info

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

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  listen: 0.0.0.0:1053
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query

주요 TUN 옵션 이해하기

enable: TUN 기능의 활성화 여부입니다. 값을 true로 바꾸면 코어가 가상 인터페이스 생성을 시도합니다.
stack: 트래픽 처리 방식입니다. mixed는 호환성과 성능 사이의 균형이 좋아 처음 설정할 때 무난합니다.
auto-route: 시스템 라우팅 테이블을 자동으로 조정합니다. 직접 라우팅을 관리하는 고급 사용자가 아니라면 켜는 편이 편리합니다.
auto-detect-interface: 실제 인터넷에 연결된 인터페이스를 자동으로 찾습니다. Wi-Fi와 유선 네트워크를 자주 바꾼다면 유용합니다.
dns-hijack: 애플리케이션이 임의의 DNS 서버로 보내는 요청을 Clash의 DNS 처리기로 넘깁니다. DNS 누수를 줄이는 데 도움이 됩니다.

설정 파일을 저장할 때는 YAML의 들여쓰기를 반드시 지켜야 합니다. 탭 문자는 피하고 공백을 사용하세요. tun: 아래 항목은 같은 깊이로 정렬해야 하며, 콜론 뒤에 값이 빠지지 않았는지도 확인해야 합니다. 설정 오류가 의심되면 클라이언트 로그에서 줄 번호를 확인하고 마지막으로 추가한 항목부터 잠시 제거하여 원인을 좁히는 방식이 가장 빠릅니다.

안정적인 시작 방법

처음부터 복잡한 DNS 규칙과 우회 옵션을 모두 넣지 말고, TUN과 기본 DNS만 활성화한 뒤 정상 연결을 확인하면서 기능을 하나씩 추가하세요.

3권한을 부여하고 실행하기

Linux에서 TUN 모드가 켜지지 않는 가장 흔한 이유는 권한 부족입니다. GUI 클라이언트를 사용하는 경우에는 설정 화면의 권한 요청 버튼을 먼저 눌러 보세요. 배포판에 따라 관리자 암호를 입력하거나 별도의 권한 도우미 서비스를 설치해야 할 수 있습니다. 코어를 직접 실행한다면 터미널에서 관리자 권한으로 시작할 수 있지만, 장시간 사용할 때는 무조건 root로 실행하기보다 필요한 기능만 허용하는 방식을 고려하는 것이 안전합니다.

Linux 클라이언트에서 설정

Clash 클라이언트를 실행하고 올바른 프로필을 선택합니다. 프로필을 바꾼 뒤 TUN 설정이 사라지는 클라이언트도 있으므로 먼저 프로필을 고정하는 것이 좋습니다.
설정 메뉴에서 TUN Mode 또는 System Tunnel 항목을 찾고 스위치를 켭니다.
권한 요청 창이 나타나면 관리자 인증을 진행합니다. 인증이 끝난 뒤 가상 인터페이스 생성 여부를 로그에서 확인합니다.
모드가 Rule인지 확인하고, 테스트가 끝날 때까지 여러 설정을 동시에 변경하지 않습니다.

권한 요청이 반복될 때

클라이언트를 완전히 종료한 뒤 다시 실행하고, 이전에 생성된 권한 도우미 또는 서비스가 정상적으로 설치되었는지 확인하세요. 배포판의 보안 정책이 실행 파일을 차단하는 경우도 있습니다.

터미널에서 코어 실행

실행 파일과 설정 파일의 경로를 알고 있다면 다음처럼 시작할 수 있습니다.

sudo ./mihomo -d ./config

로그에 TUN 인터페이스 생성, DNS 리스너 시작, 프로필 로드 성공과 같은 메시지가 표시되는지 확인하세요. 실행 직후 permission denied, tun device not found, route failed가 나타난다면 네트워크 권한이나 장치 지원 문제일 가능성이 높습니다.

4DNS와 라우팅 상태 점검

TUN이 켜졌는데도 특정 사이트만 열리지 않거나 접속 지역이 예상과 다르다면 DNS와 라우팅을 함께 살펴봐야 합니다. DNS가 운영체제의 기존 서버로 직접 전송되면 도메인 해석 결과와 실제 프록시 경로가 어긋날 수 있습니다. 반대로 모든 DNS를 무조건 원격으로 보내면 국내 서비스의 응답 속도가 느려질 수 있으므로, 자신의 규칙 정책에 맞는 구성을 선택해야 합니다.

DNS 확인 방법

먼저 현재 시스템이 어떤 DNS를 사용하고 있는지 확인합니다. 배포판에 따라 resolvectl 또는 NetworkManager 명령을 사용할 수 있습니다.

resolvectl status
resolvectl query example.com
cat /etc/resolv.conf

Clash 로그에 DNS 요청이 기록되고, 설정한 리스너 포트가 열려 있는지도 확인하세요. fake-ip 모드를 사용할 때 일부 금융 프로그램이나 로컬 장치 검색이 오작동하면 해당 도메인을 fake-ip-filter에 추가하거나 해당 트래픽을 직접 연결하는 방법을 고려할 수 있습니다.

라우팅 확인 방법

가상 인터페이스의 이름은 환경에 따라 Meta, utun, mihomo 등으로 다를 수 있습니다. 다음 명령에서 새 인터페이스와 기본 경로의 변화를 확인합니다.

ip link show
ip route show
ip rule show

라우팅이 자동으로 적용되면 시스템 트래픽이 TUN으로 이동하고, Clash가 실제 외부 인터페이스를 통해 프록시 서버에 연결합니다. 이때 프록시 서버로 가는 경로까지 다시 TUN으로 들어가면 무한 루프가 발생할 수 있으므로, Mihomo의 자동 인터페이스 감지와 자동 라우팅을 함께 사용하는 것이 일반적으로 안전합니다.

VPN과 동시에 사용하지 마세요

WireGuard, OpenVPN, 다른 TUN 기반 프록시를 동시에 켜면 라우팅 우선순위가 충돌할 수 있습니다. 원인을 찾는 동안에는 하나의 터널만 활성화하세요.

5연결 상태 테스트하기

설정이 끝났다고 바로 장시간 사용하지 말고, 단계별로 테스트하는 것이 좋습니다. 먼저 Clash 대시보드의 연결 목록에서 요청이 실제로 기록되는지 확인합니다. 브라우저 페이지 하나만 열기보다 DNS 조회, HTTPS 연결, 터미널 요청을 각각 시험해야 시스템 전체 프록시가 제대로 적용되었는지 알 수 있습니다.

Clash의 로그를 열고 테스트할 도메인 요청이 기록되는지 확인합니다. 규칙 모드라면 해당 요청이 원하는 프록시 그룹 또는 DIRECT로 분류되는지도 살펴봅니다.
터미널에서 curl을 실행해 브라우저와 별개인 애플리케이션도 TUN을 통과하는지 확인합니다.
공개 IP 확인 서비스에서 외부 IP와 지역이 선택한 노드에 맞는지 확인합니다. 단, IP 정보만으로 모든 DNS 누수를 판단할 수는 없습니다.
DNS 누수 점검 사이트나 여러 도메인 조회 결과를 이용해 실제 DNS 서버가 의도한 경로를 사용하는지 확인합니다.
필요하다면 특정 국내 사이트, 해외 사이트, 로컬 네트워크 장치를 각각 테스트해 규칙의 균형을 확인합니다.

curl -I https://example.com
curl -4 https://ifconfig.co
curl -6 https://ifconfig.co

IPv6를 사용하지 않도록 설정한 환경에서 curl -6이 실패하는 것은 반드시 오류가 아닙니다. 오히려 IPv6 경로가 의도치 않게 직접 연결되는 것을 막기 위해 IPv6 정책을 명확히 정하는 것이 중요합니다. 연결 지연이 심하면 먼저 노드 품질과 DNS 응답 시간을 확인하고, 그 다음 규칙과 MTU를 점검하세요.

정상 상태의 기준

TUN 인터페이스가 유지되고, Clash 로그에 요청이 기록되며, 규칙에 맞는 IP와 DNS 경로가 확인되면 기본 설정은 정상적으로 완료된 것입니다.

6문제 해결과 안전한 복구

TUN을 켠 뒤 인터넷이 끊기는 경우

가장 먼저 Clash 로그에서 설정 파싱 오류와 라우팅 오류를 확인합니다. 인터넷이 전혀 되지 않는다면 TUN을 끄고 기본 네트워크를 복구한 뒤, 백업한 설정으로 돌아가 최소 구성부터 다시 시작하세요. 자동 라우팅이 활성화된 상태에서 코어가 비정상 종료되면 라우팅 규칙이 남는 경우가 있으므로 클라이언트의 복구 기능을 사용하거나 네트워크 서비스를 재시작해야 할 수 있습니다.

일부 앱만 프록시되지 않는 경우

해당 앱이 자체적으로 QUIC, IPv6, 사용자 지정 DNS 또는 별도 네트워크 네임스페이스를 사용하는지 확인합니다. Flatpak이나 Docker 안에서 실행되는 애플리케이션은 호스트의 네트워크 경로와 분리될 수 있습니다. 이때 호스트의 TUN 설정만으로 컨테이너 내부 트래픽이 자동으로 해결되지 않을 수 있으며, 컨테이너 네트워크와 DNS 정책을 별도로 구성해야 합니다.

브라우저는 되지만 터미널만 안 되면 환경 변수보다 TUN과 DNS 로그를 먼저 확인합니다.
특정 게임만 안 되면 UDP 지원 여부, 게임 런처의 자체 프록시와 방화벽 정책을 확인합니다.
로컬 프린터나 NAS가 안 보이면 사설망 대역을 직접 연결 규칙으로 보내고 로컬 DNS 접근을 허용합니다.
웹소켓이 자주 끊기면 노드의 TCP 안정성과 MTU, 연결 유지 시간을 점검합니다.

TUN 모드 해제와 원상 복구

사용을 마친 뒤에는 클라이언트에서 TUN 스위치를 먼저 끄고, 가상 인터페이스가 사라졌는지 확인합니다. 그 다음 자동으로 추가된 라우팅과 DNS 상태가 정상으로 돌아왔는지 점검하세요. 코어가 실행 중인 상태에서 설정 파일을 삭제하거나 네트워크 서비스를 강제로 재시작하는 것은 피하는 편이 좋습니다. 문제가 반복되면 백업 설정을 적용하고 시스템을 재부팅한 뒤, 한 번에 하나의 옵션만 다시 켜는 방식으로 복구합니다.

ip link show
ip route show
resolvectl status

복구 후에도 인터넷이 되지 않으면 다른 VPN이나 프록시 환경 변수가 남아 있는지 확인합니다. 특히 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY가 터미널 세션에 남아 있으면 TUN을 끈 뒤에도 명령줄 프로그램이 계속 프록시를 사용하려고 할 수 있습니다.

정리: Linux 프록시를 안정적으로 관리하는 방법

Linux에서 Clash Meta TUN 모드를 설정할 때 핵심은 스위치를 켜는 것보다 트래픽이 어떤 인터페이스와 DNS 경로를 지나가는지 이해하는 것입니다. 일반적인 시스템 프록시는 앱별 설정이 필요하고, VPN은 모든 트래픽을 한 경로로 보내 세밀한 분기가 어렵습니다. 반면 Clash Meta는 TUN과 규칙 기반 라우팅을 결합해 애플리케이션별, 도메인별, 네트워크별 정책을 세밀하게 적용할 수 있습니다.

다른 프록시 도구는 Linux 배포판이나 데스크톱 환경에 따라 설치 과정이 달라지고, 시스템 프록시가 적용되지 않는 앱을 별도로 설정해야 하는 경우가 많습니다. Clash Meta는 YAML 설정과 Mihomo 코어를 통해 다양한 환경을 일관된 방식으로 관리할 수 있으며, 로그와 대시보드에서 실제 요청의 처리 결과를 확인할 수 있다는 장점이 있습니다.

시스템 전체 적용: TUN 가상 인터페이스를 통해 브라우저뿐 아니라 터미널과 일반 앱의 트래픽도 규칙에 따라 처리할 수 있습니다.
세밀한 분기: 국내 서비스는 직접 연결하고 필요한 도메인만 프록시로 보내 속도와 호환성을 함께 조정할 수 있습니다.
DNS 관리: DNS 하이재킹과 원격 DNS 설정으로 실제 연결 경로와 이름 해석 경로의 불일치를 줄일 수 있습니다.
문제 추적: 로그, 라우팅 테이블, IP 확인 명령을 함께 사용해 단순한 추측보다 빠르게 원인을 찾을 수 있습니다.
안전한 복구: 설정 백업과 단계별 적용을 지키면 네트워크가 끊겨도 이전 상태로 되돌리기 쉽습니다.

처음에는 TUN, 기본 DNS, 간단한 규칙만 사용해 정상 여부를 확인하고, 이후에 fake-ip 예외, IPv6 정책, 로컬 네트워크 규칙을 추가하는 순서가 가장 안정적입니다. 설정을 변경할 때마다 로그와 실제 연결 결과를 기록하면 자신의 Linux 환경에 맞는 최적의 구성을 빠르게 찾을 수 있습니다. 이제 필요한 클라이언트를 준비하고, 사용하는 배포판과 네트워크 조건에 맞춰 단계적으로 적용해 보세요.

Clash 무료 다운로드 — 원활한 인터넷 경험을 시작하세요 →

Linux에서 Clash Meta TUN 모드 켜는 법과 설정 순서