2026-10-18 고급 설정 예상 읽기 시간 12분

TUN 프로토콜 스택이 패킷을 처리하고, 코어가 연결 정보를 복원한 뒤 규칙을 적용합니다.

코어가 물리 네트워크 어댑터를 통해 직접 연결하거나 프록시 연결을 만들고, 응답 데이터를 앱으로 돌려보냅니다.

TUN 모드: IP 계층에서 앱 트래픽 수신

설정 전 확인: 코어, 권한, 설정 파일 출처

시스템 프록시는 보통 앱에 HTTP 또는 SOCKS 프록시 주소를 알려줍니다. 예를 들면 127.0.0.1:7890입니다. 브라우저는 이 설정을 따를 수 있지만 명령줄 도구, 게임, 자체 네트워크 스택을 사용하는 프로그램은 따르지 않을 수도 있습니다. TUN은 시스템 라우팅으로 트래픽을 유도하므로 시스템 프록시 설정을 읽지 않는 일부 프로그램의 트래픽도 수신할 수 있습니다.

연결은 어떤 과정을 거칠까요?

앱이 도메인 이름을 조회해 실제 IP 또는 커널이 할당한 Fake-IP를 받습니다.
앱이 TCP 또는 UDP 연결을 시작하면 시스템이 라우팅 테이블을 확인해 가상 인터페이스를 선택합니다.
최소 설정: 먼저 트래픽 처리 여부를 확인하고 프록시 정책 적용하기
커널은 물리 네트워크 어댑터를 통해 직접 또는 프록시 연결을 설정하고, 응답 데이터를 앱에 전달합니다.

예시 설정으로 기존 노드 구성을 덮어쓰지 마세요

시작 전 확인: 커널, 권한, 설정 출처

아래 설정은 해당 필드를 지원하는 mihomo 커널을 기준으로 합니다. Clash 원본, 구버전 Premium 커널, mihomo는 TUN 기능과 설정 필드가 완전히 같지 않습니다. 클라이언트 이름만으로 커널 종류를 판단할 수도 없습니다. 먼저 클라이언트의 커널 정보, 정보 화면 또는 시작 로그에서 커널 이름과 실제 버전을 확인한 뒤 해당 버전의 설정 필드 안내를 참고하세요.

Windows: 가상 인터페이스를 만들고 라우팅을 변경하려면 보통 관리자 권한이 필요합니다. 일부 클라이언트는 설치된 서비스를 통해 작업을 수행하므로 그래픽 인터페이스는 일반 권한으로 실행해도 사용할 수 있습니다.
macOS: 보통 클라이언트가 제공하는 권한 있는 보조 프로그램이나 별도의 승인이 필요합니다. 로컬 네트워크 접근을 허용했다고 해서 라우팅 변경 권한까지 얻은 것은 아닙니다.
Linux: 사용 가능한 /dev/net/tun 장치와 적절한 네트워크 관리 권한이 필요합니다. 컨테이너에서는 장치 매핑과 권한도 별도로 설정해야 합니다.
Android: 일반적으로 클라이언트가 시스템 VpnService를 통해 인터페이스를 생성합니다. 데스크톱의 관리자 권한이나 서비스 모드 설정 절차를 그대로 적용할 수 없습니다. 다른 VPN을 동시에 실행하면 충돌이 발생할 수 있습니다.

먼저 현재 작동하는 설정을 내보내고 구독 업데이트가 변경 내용을 덮어쓰는지 확인하세요. 클라이언트에서 설정 덮어쓰기, 설정 병합 또는 설정 확장을 지원한다면 해당 기능을 이용해 TUN 설정을 저장해야 합니다. 구독에서 생성된 임시 파일을 수정하면 다음 업데이트나 재시작 후 변경 내용이 사라질 수 있습니다. 관련 공통 필드는 설정 참고 자료에서 확인할 수 있습니다.

시스템 프로토콜 스택을 사용해 연결을 처리합니다.

다음은 데스크톱 환경에서 문제를 확인하기 위한 최소 설정 전체 예시입니다. 모든 연결을 직접 연결로 설정해 가상 인터페이스, 라우팅, DNS가 작동하는지 확인합니다. 사용할 수 있는 프록시 노드 설정은 포함되어 있지 않습니다. 7890은 이 예시의 혼합 프록시 포트이고 1053은 로컬 DNS 수신 포트로, 용도가 서로 다릅니다.

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

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

rules:
  - MATCH,DIRECT

예시의 DNS 업스트림은 문제 원인을 분리하기 쉽도록 일반 DNS를 사용하며 암호화 전송은 제공하지 않습니다. 네트워크 연결 가능 여부와 개인정보 보호 요구사항에 맞게 조정하세요. ipv6: false는 초기 문제 해결 범위를 좁히기 위한 설정입니다. 운영체제의 IPv6를 끄는 것은 아니며, 다른 프로그램이 시스템의 IPv6 경로로 연결하지 않는다는 보장도 없습니다.

이 옵션을 지원하는 mihomo 버전에서 시작점으로 사용하기 좋습니다.

auto-route와 auto-detect-interface	처리 방식	선택 기준
`system`	DNS 처리: dns-hijack과 Fake-IP의 관계	호환성 비교를 위한 선택지입니다. 구체적인 동작은 플랫폼 구현에 따라 달라집니다.
`gvisor`	사용자 공간 네트워크 스택을 사용합니다.	연결 호환성 문제가 있을 때 다른 방식과 교차 테스트할 수 있습니다.
`mixed`	TCP에는 system, UDP에는 gVisor를 사용합니다.	해당 옵션을 지원하는 mihomo 버전에서 시작점으로 사용하기 좋습니다.

일부 LAN 서비스나 앱은 DNS 응답을 직접 확인합니다. 이런 경우 실제 문제에 맞춰 fake-ip-filter를 설정하고 특정 도메인에 실제 주소를 반환할 수 있습니다. 모든 도메인을 제외하면 DNS 동작 전체가 달라지므로 주의하세요. Fake-IP와 실제 IP 조회 방식을 전환한 뒤에는 테스트 앱을 재시작하고 기존 DNS 캐시를 지워야 앱이 이전 매핑을 계속 사용하지 않습니다.

설정 절차: 의존 관계에 따라 단계별로 확인하기

auto-route: true를 설정하면 커널이 트래픽을 TUN으로 보내는 라우팅을 자동 구성합니다. 프록시 규칙을 켜는 설정은 아닙니다. auto-detect-interface: true는 아웃바운드 인터페이스를 자동으로 선택해 프록시 연결이 실제 네트워크 출구로 나가도록 하며, TUN으로 다시 유입되는 라우팅 루프를 방지합니다.

네트워크 어댑터가 여러 개이거나 다른 VPN, 기업 전용망, 가상 스위치가 함께 있으면 자동 감지가 원하는 출구를 선택하지 못할 수 있습니다. 먼저 라우팅과 인터페이스를 확인한 다음, 현재 커널에서 지원하는 interface-name 등의 필드로 출구를 지정하는 방법을 고려하세요. 다른 컴퓨터의 인터페이스 이름을 그대로 복사하지 마세요. Wi-Fi와 유선 네트워크를 전환하면 인터페이스 이름이 달라질 수 있습니다.

DNS 트래픽 처리: dns-hijack와 Fake-IP의 관계

dns-hijack는 TUN으로 들어와 대상 조건에 일치하는 DNS 트래픽을 커널 DNS 모듈로 전달합니다. 예시의 any:53은 UDP 53, tcp://any:53은 TCP 53에 해당합니다. 모든 이름 조회 방식을 가로챈다는 뜻도, 모든 트래픽을 로컬 1053 포트로 보낸다는 뜻도 아닙니다.

새 연결을 만듭니다: 테스트 앱을 완전히 종료한 뒤 다시 열고, 클라이언트 연결 목록에서 대상 도메인과 IP, 네트워크 유형, 적용된 규칙을 확인하세요.
서비스 규칙을 복원합니다: 최소 직접 연결 설정으로 검증한 다음 기존 프록시 그룹과 규칙을 적용하고, 직접 연결과 프록시 연결의 출구를 각각 확인하세요.
DoH: 보통 HTTPS 443 포트를 사용합니다. 브라우저의 ‘보안 DNS’는 기존 DNS 트래픽 처리를 우회할 수 있지만, 연결 자체는 여전히 TUN으로 들어올 수 있습니다.

Fake-IP 모드에서는 커널이 앱에 198.18.0.2와 같은 매핑 주소를 반환하고, 이후 연결에서 이 매핑을 이용해 도메인 이름을 복원할 수 있습니다. 도메인 규칙을 적용하는 데 도움이 되지만, 해당 주소가 웹 서버의 실제 IP라는 뜻은 아닙니다. 예시의 198.18.0.1/16은 매핑 주소 풀입니다. 일반 공인 IP 목적지처럼 연결 가능 여부를 테스트하지 마세요.

일부 로컬 네트워크 서비스나 앱은 DNS 조회 결과를 자체적으로 검증합니다. 이런 경우 실제 문제에 맞춰 fake-ip-filter를 설정해 특정 도메인에 실제 주소를 반환할 수 있습니다. 모든 도메인을 제외하면 DNS 동작 방식 전체가 달라지므로 피하세요. Fake-IP와 실제 IP 조회 방식을 전환한 뒤에는 테스트 앱을 재시작하고 기존 DNS 캐시를 지워 앱이 오래된 매핑을 사용하지 않도록 하세요.

# Windows: PowerShell에서 실행

먼저 기본 네트워크를 확인합니다: TUN을 끄고 현재 네트워크가 작동하는지 확인하세요. 프록시 설정이 있다면 먼저 시스템 프록시로 노드와 정책 그룹이 정상 작동하는지 테스트해 가상 네트워크 어댑터 문제와 노드 장애를 구분합니다.
권한을 확인합니다: 클라이언트가 안내하는 방법에 따라 서비스를 활성화하거나 시스템 권한을 승인하세요. Linux에서는 먼저 /dev/net/tun이 있는지 확인합니다. 인터페이스의 스위치 색상만 확인해서는 안 됩니다.
설정을 저장하고 다시 불러옵니다: 설정 검사를 통과한 뒤 커널을 시작하세요. 시작 로그에서 가상 인터페이스 생성 실패, 권한 부족 또는 필드 파싱 오류가 있는지 확인합니다.
시스템 프록시를 잠시 끕니다: 브라우저가 이전 프록시 설정을 사용해 연결하는 상황을 배제하세요. TUN과 시스템 프록시를 함께 사용할 수 있지만, 첫 테스트에서는 연결 경로를 분리하는 편이 좋습니다.
새 연결을 만듭니다: 테스트 앱을 완전히 종료한 뒤 다시 열고, 클라이언트의 연결 목록에서 대상 도메인, 대상 IP, 네트워크 유형, 적용된 규칙을 확인하세요.
서비스 규칙을 복원합니다: 최소 직접 연결 설정으로 확인을 마친 뒤 기존 프록시 그룹과 규칙을 적용하고, 직접 연결과 프록시 연결의 출구를 각각 점검하세요.

클라이언트가 시작될 때 시스템 프록시를 자동으로 다시 켠다면 스위치 상태를 다시 확인하세요. 앱에 저장된 SOCKS 설정과 터미널 환경 변수 HTTP_PROXY, ALL_PROXY도 테스트 경로를 바꿀 수 있습니다. 시스템 프록시를 껐다는 사실만으로 연결이 반드시 TUN을 거친다고 단정할 수 없습니다.

라우팅 및 DNS 조회 결과 확인

도메인은 접속할 수 없지만 알고 있는 IP로는 연결된다면 DNS 경로를 중점적으로 확인하세요. 반대로 DNS 조회는 되는데 연결이 시간 초과된다면 라우팅과 정책, 노드를 확인해야 합니다. IP 주소로 HTTPS 사이트에 직접 접속하면 인증서나 가상 호스트 설정 때문에 실패할 수 있습니다. 이 실패만으로 네트워크가 끊겼다고 판단하지 마세요.

브라우저는 되지만 게임이나 음성 채팅이 안 됩니다
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Resolve-DnsName example.com

# macOS: 터미널에서 실행
ifconfig
netstat -rn -f inet
route -n get 1.1.1.1

LAN 기기, 프린터 또는 기업 네트워크에 접속할 수 없습니다
ip link show
ip rule show
ip route show table all
ip route get 1.1.1.1

조회 테스트에서 Fake-IP가 반환되면 해당 조회가 DNS 경로에 진입했다는 점만 확인할 수 있으며, 앱 연결이 제대로 프록시 처리되었다는 뜻은 아닙니다. 연결 기록과 출구를 함께 확인하세요. 새 연결이 커널에 들어왔는지, 예상한 규칙과 정책이 적용되었는지 살펴본 다음 대상 서비스에 실제로 접속해 검증합니다.

TUN을 껐는데도 네트워크가 복구되지 않습니다

스위치를 켰는데 가상 인터페이스가 나타나지 않음

서비스 실행 여부, 권한 승인 여부, 시작 로그의 오류, 실제 실행 설정에 tun.enable: true가 포함되어 있는지 먼저 확인하세요. 그래픽 인터페이스의 스위치 상태가 설정에 의해 덮어써지거나 커널 시작 실패로 적용되지 않을 수 있습니다. 이 경우 DNS를 바꿔도 대개 해결되지 않습니다.

켜자마자 모든 앱의 네트워크 연결이 끊김

먼저 TUN을 꺼서 네트워크를 복구한 뒤 다른 VPN, 아웃바운드 인터페이스 선택, DNS 업스트림 연결 가능 여부를 확인하세요. 로그에 같은 대상의 연결이 반복해서 나타나면 라우팅 루프를 의심해야 합니다. stack, DNS, MTU, 규칙을 한꺼번에 바꾸지 말고 재현 가능한 설정을 보관한 뒤 한 번에 한 항목만 변경하세요.

연결 기록으로 트래픽이 들어왔는지 확인하고, 적용된 정책으로 분기 결과를 확인하세요. 스위치 상태만으로 검증을 대신하지 마세요.

코어를 업그레이드하거나 네트워크를 바꾸거나 VPN을 추가한 뒤에는 인터페이스와 DNS, 라우팅을 다시 확인하세요.

패킷 분할이나 경로 MTU 문제가 확인된 경우에만 MTU를 조정하세요. 특정 값을 모든 환경에 적용할 수 있는 최적값으로 보지 마세요.

TUN 설정은 인터페이스 존재 여부, 라우팅 적용 여부, DNS 정상 여부, 규칙 일치 여부, 출구 연결 가능 여부 순으로 확인하면 됩니다. 여러 스위치를 반복해서 바꾸기보다 단계별로 점검하는 편이 문제를 찾기 쉽습니다.

대상이 사설 IP인지, 다른 VPN 또는 라우팅 대역과 겹치는지 확인하세요. IP-CIDR,192.168.0.0/16,DIRECT,no-resolve는 정책 계층에서 직접 연결하는 규칙의 예시입니다. 다만 직접 연결도 TUN 수신 과정을 거칠 수 있습니다. 라우팅 계층에서 특정 대역을 제외하려면 현재 커널의 라우팅 제외 필드를 확인하세요. 이는 DIRECT 규칙을 추가하는 것과는 다른 작업입니다.

플랫폼별 클라이언트와 시스템 요구 사항을 확인한 뒤, 안내에 따라 구성을 가져오고 연결을 테스트하세요.

먼저 클라이언트를 정상적으로 종료해 커널이 가상 인터페이스와 라우팅을 정리하도록 하세요. 그런 다음 시스템 프록시가 더 이상 수신하지 않는 127.0.0.1:7890을 계속 가리키는지 확인합니다. 필요하면 네트워크에 다시 연결하거나 시스템을 재시작하세요. 기업 라우팅의 용도를 모르는 상태에서 라우팅 테이블 항목을 일괄 삭제하지 마세요.

사용 안내 보기

이전·다음 글 탐색

mode: rule을 유지해 로컬 트래픽과 프록시 트래픽을 규칙에 따라 나눠 처리하세요.
Clash 다운로드
커널 업그레이드, 네트워크 변경 또는 VPN 추가 후에는 인터페이스, DNS, 라우팅을 다시 확인하세요.
패킷 분할이나 경로 MTU 문제가 확인된 경우에만 MTU를 조정하세요. 특정 값을 일반적인 최적화 설정으로 간주하지 마세요.

TUN 설정은 인터페이스 확인, 라우팅 적용, DNS 조회, 규칙 적용, 출구 연결 순서로 점검하면 됩니다. 이 순서대로 한 단계씩 확인하면 여러 스위치를 반복해서 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다.