커널, 클라이언트, Clash Premium의 차이부터
커널을 비교하기 전에 세 가지 역할을 구분해야 합니다. 커널은 설정을 파싱하고 프록시 연결을 만들며 DNS와 규칙 매칭을 처리합니다. 데스크톱·모바일 클라이언트는 설정 관리, 트레이 메뉴, 구독 업데이트, 권한 요청을 담당합니다. 구독은 노드, 프록시 그룹, 규칙 데이터를 제공합니다. 클라이언트 이름에 Clash가 들어간다고 해서 기본 Clash 커널을 실행하거나 모든 mihomo 설정을 지원하는 것은 아닙니다.
기본 Clash 오픈소스 커널과 Clash Premium도 같은 기능을 제공하지 않습니다. Premium은 원 프로젝트에서 제공한 비공개 강화 커널로, 과거에는 TUN과 규칙셋 등의 추가 기능을 포함했습니다. mihomo는 Clash Meta에서 이어진 오픈소스 커널로, Clash 스타일의 YAML 설정 구조를 상당 부분 유지하면서 프로토콜, 라우팅, DNS 기능을 계속 확장하고 있습니다. 원 프로젝트는 이미 유지보수가 중단됐으므로 이전할 때는 구형 클라이언트 이름을 기능 목록처럼 간주하지 말고 실제 바이너리 버전을 확인해야 합니다.
| 대상 | 주요 역할 | 확인 위치 |
|---|---|---|
| 기본 Clash 오픈소스 커널 | 기존 프록시 프로토콜, 프록시 그룹, 규칙 기반 라우팅 | 커널 버전 및 설정 파싱 로그 |
| Clash Premium | 기본 기능과 과거 추가 기능 | Premium 빌드 날짜 및 해당 문서 |
| mihomo | 추가 프로토콜, 규칙셋 확장, TUN 및 DNS 설정 | 실제 실행 중인 mihomo 버전 |
| 그래픽 클라이언트 | 구독 가져오기, 커널 실행, 권한 및 설정 덮어쓰기 관리 | 클라이언트 설정, 시작 로그, 실행 설정 |
명령어로 실제 버전 확인하기
mihomo -v
mihomo -t -d ./mihomo-data -f ./config.yaml첫 번째 명령은 현재 바이너리의 버전 정보를 확인하고, 두 번째 명령은 작업 디렉터리와 설정 파일을 지정해 설정을 테스트합니다. 해당 파일은 미리 존재해야 합니다. 테스트를 통과했다는 것은 설정을 파싱할 수 있다는 뜻일 뿐, 노드가 작동한다는 의미는 아닙니다. 그래픽 클라이언트는 내장 커널을 사용할 수 있으므로 터미널의 mihomo와 클라이언트가 실행하는 파일이 다를 수 있습니다. 클라이언트 로그도 함께 확인하세요.
추가 프로토콜: VLESS, REALITY, Hysteria2
mihomo와 구형 커널의 가장 직접적인 차이는 구독에 포함된 노드 유형과 매개변수를 인식할 수 있는지 여부입니다. 기본 Clash에서 흔히 사용하는 프로토콜은 Shadowsocks, VMess, Trojan, SOCKS, HTTP입니다. mihomo는 VLESS, Hysteria2, TUIC 등을 추가로 지원하며 특정 프로토콜 조합에서 REALITY도 지원합니다. YAML의 type만 바꾼다고 기존 노드를 다른 프로토콜로 변환할 수는 없습니다. 서버에서 해당 프로토콜을 제공해야 합니다.
| 기능 | mihomo 설정 시 확인 사항 | 흔한 오해 |
|---|---|---|
| VLESS | UUID, 전송 방식, TLS, flow 확인 | VMess 노드의 유형만 VLESS로 변경 |
| REALITY | 서버에서 요구하는 SNI, 공개 키, short-id 확인 | REALITY를 독립적인 노드 유형으로 간주 |
| Hysteria2 | type: hysteria2를 사용하고 비밀번호와 TLS 매개변수를 확인하세요 | Hysteria 1세대의 설정 전체를 그대로 재사용 |
| TUIC | 서버 버전, 인증 항목, UDP 연결 상태 확인 | TCP 포트만 테스트하고 노드가 정상이라고 판단 |
프로토콜 지원 여부와 네트워크 조건을 따로 확인
Hysteria2와 TUIC는 QUIC 기반이므로 UDP 연결이 필요합니다. LAN, 방화벽 또는 통신사 회선에서 UDP를 제한하면 설정 테스트를 통과해도 핸드셰이크가 시간 초과될 수 있습니다. VLESS는 실제 전송 방식에 따라 사용 가능 여부를 확인해야 하며, 모든 VLESS 노드가 같은 네트워크 동작을 한다고 볼 수 없습니다. 프로토콜 이름만으로 지연 시간이 짧아지거나 처리량이 높아지는 것도 아닙니다.
- 지원하지 않는 노드 유형 오류: 클라이언트가 실제로 mihomo를 실행 중인지, 구독이 해당 커널용으로 제공되는지 먼저 확인하세요.
- 인증 실패 오류: UUID, 비밀번호, 서버 프로토콜 버전을 확인하고 DNS는 먼저 변경하지 마세요.
- TLS 핸드셰이크 오류: 시스템 시간, SNI, 인증서 요구사항을 확인하세요. 인증서 검증 건너뛰기는 일반적인 해결 방법으로 사용하지 마세요.
- QUIC 노드가 계속 시간 초과될 때: 다른 네트워크에서 비교 테스트한 뒤 UDP 아웃바운드와 서버 상태를 확인하세요.
rule-providers: 기존 구조를 활용하고 behavior와 format 확인
rule-providers는 mihomo만의 기능이 아닙니다. Clash Premium도 이 방식을 지원합니다. 이전할 때는 보통 '규칙셋을 선언한 뒤 RULE-SET으로 참조하는' 기본 구조를 그대로 사용할 수 있습니다. 규칙셋은 매칭 대상을 정의하고, rules의 참조 항목은 매칭 후 적용할 정책을 지정합니다. 둘을 한데 섞지 마세요.
로컬 domain 규칙셋 예시
아래 내용을 기존 설정에 병합해 사용하세요. 예시 도메인 규칙을 DIRECT로 보내며, 노드 이름에는 의존하지 않습니다. 작업 디렉터리 안에 rules/local-domains.yaml 파일이 있어야 합니다. 기존에 rule-providers나 rules가 있다면 내용을 병합하고, 같은 최상위 키를 중복해서 만들지 마세요.
rule-providers:
local-domains:
type: file
behavior: domain
format: yaml
path: ./rules/local-domains.yaml
rules:
- RULE-SET,local-domains,DIRECT
- MATCH,DIRECTrules/local-domains.yaml 파일 내용:
payload:
- '+.example.com'
- 'intranet.example.net'+.example.com은 해당 도메인과 하위 도메인을 매칭합니다. 이 예시는 기본 동작을 직접 연결로 설정해 참조 관계만 보여줍니다. 기존 구독을 그대로 대체할 수 있는 프록시 설정은 아닙니다. 실제로 이전할 때는 기존 프록시 그룹과 마지막 기본 규칙을 유지하세요.
세 가지 behavior는 서로 바꿔 쓸 수 없습니다
domain: 항목에는 도메인 또는 지원되는 도메인 매칭 표현식을 씁니다.DOMAIN-SUFFIX접두사는 붙이지 않습니다.ipcidr: 항목에는192.168.0.0/16과 같은 IP 대역을 씁니다. 완성된 규칙 문장이 아닙니다.classical: 항목에는DOMAIN-SUFFIX,example.com과 같은 규칙 표현식을 씁니다. 일반적으로 항목 끝에 정책 이름을 붙이지 않습니다.
DOMAIN-SUFFIX,example.com을 behavior: domain 파일에 넣으면 YAML 들여쓰기가 올바르더라도 내용 형식이 맞지 않습니다. 규칙셋을 점검할 때는 파일 확장자만 보지 말고 제공자 선언과 다운로드한 파일을 함께 확인하세요.
mihomo에서 확장된 규칙셋 형식
mihomo는 YAML, 일반 텍스트, MRS 등의 규칙셋 형식을 지원합니다. MRS는 규칙셋용 바이너리 형식으로 domain과 ipcidr에 사용할 수 있지만 classical에는 사용할 수 없습니다. 구형 Premium 설정을 근거로 MRS를 바로 읽을 수 있다고 판단해서는 안 됩니다. 이러한 형식을 도입하기 전에 사용 중인 mihomo 버전과 규칙 제공자의 안내를 확인하고, 새 설정 항목을 구형 커널에 그대로 복사하지 마세요.
규칙은 여전히 위에서 아래 순서로 매칭됩니다. 규칙셋 참조 앞에 MATCH를 두면 뒤의 규칙은 정상적으로 매칭되지 않습니다. 라우팅 오류를 점검할 때는 프록시 그룹에서 현재 선택한 노드만 보지 말고 연결 세부 정보에 표시된 매칭 규칙과 실제 적용된 정책을 먼저 확인하세요.
TUN 구현: 스택 선택, 라우트 처리, 시스템 권한
시스템 프록시와 TUN은 연결 경로가 다릅니다. 시스템 프록시는 시스템 설정을 따르는 앱이 프록시 포트로 연결을 보내도록 합니다. TUN은 가상 네트워크 인터페이스를 만들고 라우팅 규칙과 함께 IP 트래픽을 받습니다. TUN은 시스템 프록시를 따르지 않는 앱을 처리하는 데 더 적합하지만, 특정 연결을 가로챌 수 있는지는 라우트, 인터페이스 선택, 제외 항목, 운영체제 권한에 따라 달라집니다.
기본 오픈소스 Clash와 Premium은 TUN 기능 범위가 다르므로 '모든 Clash에 TUN이 있다'고 일반화할 수 없습니다. Premium의 과거 TUN 구현은 gVisor 스택과 관련이 있으며, mihomo는 system, gvisor, mixed 등의 스택을 선택할 수 있습니다. 구체적인 지원 범위는 플랫폼과 버전에 따라 다릅니다. 다른 커널의 TUN 설정을 그대로 적용하지 마세요.
| stack 값 | 처리 방식 | 선택 기준 |
|---|---|---|
system | 시스템 네트워크 스택 기반 구현 사용 | 클라이언트 기본값으로 시작해 작동 기준을 먼저 확보 |
gvisor | 사용자 공간 네트워크 스택으로 트래픽 처리 | 호환성 비교에 사용하며, 반드시 더 빠르다고 가정하지 않음 |
mixed | system의 TCP 처리와 gVisor의 UDP 처리를 함께 사용 | 현재 플랫폼의 지원 여부를 확인한 뒤 테스트 |
데스크톱 환경 설정 예시
mixed-port: 7890
allow-lan: false
mode: rule
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53여기서 7890은 예시용 혼합 프록시 포트이며 모든 클라이언트에서 고정으로 사용하는 값이 아닙니다. auto-route는 라우트를 자동 설정하고 auto-detect-interface는 아웃바운드 인터페이스 선택을 돕지만, 권한 요청을 대신하지는 않습니다. Windows에서는 보통 클라이언트 서비스나 권한 상승이 필요하고, Linux에서는 적절한 네트워크 관리 권한이 필요합니다. macOS에서는 클라이언트 구현에 따라 권한을 부여해야 합니다.
- 라우팅 충돌을 줄이려면 다른 VPN이나 프록시 클라이언트의 TUN을 끄세요.
- 먼저 시스템 프록시 모드가 작동하는지 확인한 다음 TUN을 별도로 켜세요. 두 가지 문제를 동시에 추가하지 않는 것이 좋습니다.
- 로그에서 가상 인터페이스 생성 실패, 라우트 추가 실패, 권한 부족 오류가 있는지 확인하세요.
- Wi-Fi와 유선 네트워크를 전환하거나 절전 모드에서 복귀한 뒤 아웃바운드 인터페이스와 라우트를 다시 확인하세요.
DNS와 Fake-IP: 기존 동작을 유지하면서 해석 경로 재확인
Fake-IP는 mihomo에서 새로 도입된 개념이 아닙니다. 주소를 매핑해 도메인과 연결을 연계하고, 커널이 도메인 기준으로 규칙을 매칭하도록 돕습니다. 이전할 때 확인할 핵심은 DNS 요청이 커널에 전달되는지, 어떤 도메인에 실제 주소를 반환해야 하는지, 프록시 서버 도메인을 어떤 경로로 해석하는지입니다.
DNS와 TUN을 따로 검증하기
dns:
enable: true
listen: 127.0.0.1:7874
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- '*.lan'
- 'localhost'
nameserver:
- 223.5.5.5
- 119.29.29.29DNS 동작을 보여 주는 예시입니다. DNS는 로컬 7874 포트에서 수신하고 Fake-IP는 198.18.0.1/16 대역을 사용하며, 업스트림에는 명시적인 IPv4 DNS 주소 두 개를 지정합니다. 업스트림은 실제 네트워크와 개인정보 보호 요구사항에 맞게 선택해야 하며, 이 주소가 모든 회선에 적합하다는 뜻은 아닙니다. fake-ip-filter는 Fake-IP 할당을 제외할 뿐, 강제로 직접 연결하는 규칙이 아니며 로컬 DNS 서버 설정을 대신하지도 않습니다.
dig가 설치된 환경에서는 커널 DNS에 직접 질의할 수 있습니다:
dig @127.0.0.1 -p 7874 example.com A필터 항목에 해당하지 않으면 응답에 보통 설정한 대역의 매핑 주소가 표시됩니다. 이는 예상된 동작이며 DNS 서버가 잘못된 공인 IP를 반환한 것이 아닙니다. 해당 도메인에 접속한 다음 커널의 연결 기록에서 도메인과 연결이 연동되고 예상한 규칙이 매칭되는지 확인하세요.
암호화 DNS와 노드 도메인 해석
- 브라우저 자체 DoH: 브라우저가 시스템 DNS 경로를 우회할 수 있습니다. 문제를 확인할 때는 먼저 DNS 진입 경로를 통일한 다음 동작을 비교하세요.
- TUN의 DNS 가로채기:
any:53은 기존 DNS 트래픽을 대상으로 합니다. 모든 DoH·DoT 요청을 자동으로 가로챈다는 뜻은 아닙니다. - 노드 도메인 해석: mihomo에서는
proxy-server-nameserver로 프록시 서버 도메인을 해석할 DNS 서버를 지정해 시작 시 해석 경로가 서로 의존하는 문제를 줄일 수 있습니다. - DNS 아웃바운드에 규칙 적용:
respect-rules등의 설정은 DNS 연결의 라우팅 방식을 변경합니다. 현재 버전 문서에 맞춰 관련 설정을 함께 구성해야 하며, 스위치 하나만 켜서는 충분하지 않습니다.
LAN 서비스에 접속할 수 없다면 로컬 도메인 접미사, 라우터 DNS, 네트워크 대역 규칙을 확인하세요. *.lan만 추가해서는 기업 내부에서 사용하는 모든 도메인을 처리할 수 없습니다. 향상 모드로 전환한 뒤에는 브라우저, 시스템, 앱의 캐시도 고려해야 합니다. 이전 캐시에 남은 매핑 주소가 잠시 유지될 수 있습니다.
Clash Premium에서 mihomo로 이전할 때 확인할 순서
이전의 핵심은 모든 규칙을 새로 작성하는 것이 아니라 구형 커널에 의존하는 부분을 찾는 것입니다. 기본 필드, 기존 노드, 규칙 구문 대부분은 출발점으로 활용할 수 있지만 Premium 스크립트 설정, 구형 실험 필드, 특정 TUN 매개변수는 그대로 유지하면 안 됩니다. mihomo를 Premium 스크립트 인터페이스의 직접적인 대체재로 간주하지 마세요.
- 설정과 실행 환경 저장: 현재 작동하는 YAML을 보관하고 수신 포트, 선택한 프록시 그룹, 시스템 프록시, TUN 상태를 기록하세요. 구독 주소는 안전한 곳에 보관하고 공개적으로 공유하지 마세요.
- 구독 출력 형식 확인: 서비스 제공자가 지원하는 mihomo 또는 Clash Meta 형식을 우선 사용하세요. 노드에 VLESS나 Hysteria2가 포함된 경우 프로토콜 매개변수가 모두 제공되는지 확인하세요.
- 설정 테스트:
mihomo -t를 실행한 뒤 지원하지 않는 프로토콜, 필드 유형, 규칙 파일 경로, 프록시 그룹 이름 오류를 먼저 해결하세요. - 시스템 프록시만 검증: TUN을 끄고 지정된 포트로 노드와 규칙을 테스트하세요. 실제 포트가
7890이라면 프록시를 지원하는 앱에서127.0.0.1:7890을 사용하면 됩니다. - 규칙셋 확인:
behavior,format, 로컬 파일 내용, 규칙 순서를 확인하고 참조하는 프록시 그룹이 실제로 존재하는지 검증하세요. - DNS와 TUN을 각각 활성화: 권한, 인터페이스, 라우트, DNS 해석 순서로 문제를 좁혀 가세요. 한 번에 하나의 항목만 변경하고 변경 전후를 비교할 수 있도록 로그를 보관하세요.
- 클라이언트 덮어쓰기 확인: 최종 실행 설정을 확인하세요. 클라이언트가 포트, DNS, TUN, 규칙 설정을 병합할 수 있으므로 구독 원본 파일을 편집해도 실제 실행 값이 바뀌지 않을 수 있습니다.
재현 가능한 조건에서 속도 비교하기
프로토콜이 추가됐다고 자동으로 속도가 빨라지는 것은 아닙니다. 두 커널을 비교할 때는 노드, 테스트 대상, 네트워크, 시간대를 동일하게 유지하고 단일 연결 다운로드 속도, 동시 연결 성능, CPU 사용량을 기록하세요. 지연 시간 테스트는 지정한 대상에 한 번 요청했을 때의 소요 시간만 보여 줍니다. 대용량 파일 처리량을 대신하거나 모든 웹사이트가 같은 경로를 사용한다는 사실을 증명하지는 못합니다.
새 프로토콜, 지속적으로 업데이트되는 규칙셋, 세밀한 DNS 설정이 필요하다면 mihomo를 우선 검토할 커널로 고려하세요. 기존 프로토콜과 단순한 시스템 프록시만 필요하다면 클라이언트의 유지보수 상태, 현재 OS 호환성, 설정 관리 편의성을 중심으로 선택하면 됩니다. 용어집에서 Fake-IP, 프록시 그룹, 규칙셋 개념을 확인한 뒤 설정 가이드에 따라 단계별로 검증하세요.