2026-08-06 심화 예상 읽기 시간 12분

mihomo와 원본 Clash 커널 비교: 추가 프로토콜·룰셋·설정 항목

mihomo(Clash Meta)와 원본 커널의 차이를 비교합니다. VLESS·Hysteria2, rule-providers, sniffer 설정과 기존 설정 마이그레이션 방법을 확인하세요.

커널 범위: 원본, Premium, mihomo부터 구분하기

mihomo는 기존 Clash.Meta 프로젝트의 후속 명칭으로, Clash Meta 커널이라고도 불립니다. Clash의 YAML 설정 체계를 이어받으면서 프로토콜, DNS, 룰셋, 트래픽 가로채기 기능을 확장했습니다. mihomo가 포함된 클라이언트로 바꾸는 것은 단순히 인터페이스만 바꾸는 일이 아닙니다. 설정을 해석하고 연결을 수립하며 규칙을 실행하는 프로그램 자체가 달라집니다.

‘원본 Clash’는 Dreamacro/clash 오픈소스 커널과 원본 생태계의 Clash Premium, 두 가지 비교 대상으로 나눠 봐야 합니다. 두 버전의 기능은 완전히 같지 않습니다. 특히 TUN과 규칙 제공자를 ‘원본에는 없고 mihomo에만 있다’고 단정할 수 없습니다. 원본 프로젝트는 2023년에 유지보수가 중단됐지만 기존 튜토리얼과 구독 템플릿은 여전히 유통되고 있으므로, 마이그레이션할 때는 실제 커널 버전을 기준으로 확인해야 합니다.

클라이언트: 구독 가져오기, 트레이 아이콘, 시스템 프록시 설정, 설정 파일 생성을 담당합니다. 데스크톱 앱의 설정 관리 화면이 한 예입니다.
커널: 프로토콜 핸드셰이크, DNS 조회, 규칙 매칭, 아웃바운드 연결을 담당합니다. 클라이언트 버전은 커널 버전을 대신하지 않습니다.
구독: 전체 설정일 수도 있고 노드 목록만 포함할 수도 있습니다. 두 종류를 같은 provider 필드에 임의로 넣어서는 안 됩니다.

기능 비교: 프로토콜 확장이 설정 호환성을 뜻하지는 않습니다

비교 항목	원본 Clash 계열	mihomo
일반 프록시 프로토콜	Shadowsocks, VMess, Trojan 등을 지원하며 구체적인 기능은 버전에 따라 다릅니다.	일반 프로토콜을 지원하고 VLESS, Hysteria2, TUIC 등으로 확장했습니다.
VLESS와 REALITY	원본 커널에서는 해당 mihomo 설정을 그대로 사용할 수 없습니다.	관련 조합을 지원하지만 전송 방식, TLS, 서버 설정이 모두 일치해야 합니다.
rule-providers	Premium은 룰셋 기능을 제공하지만 모든 오픈소스 원본 빌드에 적용되는 것은 아닙니다.	규칙 제공자를 지원하며 형식과 동작 옵션도 더 다양합니다.
도메인 스니핑	mihomo와 완전히 동일한 sniffer 설정 체계는 없습니다.	지원되는 트래픽의 프로토콜 메타데이터에서 도메인 정보를 추출할 수 있습니다.
TUN 트래픽 가로채기	Premium에서 관련 기능을 제공하지만 플랫폼과 버전에 따라 차이가 있습니다.	TUN을 지원하지만 실제 트래픽 가로채기에는 권한, 라우팅, 시스템 환경이 영향을 줍니다.
기본 분기 규칙	DOMAIN, DOMAIN-SUFFIX, IP-CIDR 등을 지원합니다.	기본 문법을 유지하면서 규칙 유형과 조합 방식을 확장했습니다.

이 표는 기능의 범위를 설명하며 모든 버전에 적용되는 보장은 아닙니다. 서버의 신규 기능, 특정 전송 방식 조합, 룰셋 형식은 최신 mihomo를 요구할 수 있습니다. ‘지원하지 않는 프록시 유형’ 오류가 발생하면 설치 파일 이름에 Meta가 있는지만 확인하지 말고 클라이언트에서 실제로 실행 중인 커널을 확인하세요.

VLESS·Hysteria2 마이그레이션 확인 사항

VLESS 노드의 유형은 type: vless로 지정합니다. 서버에서 REALITY를 사용한다면 reality-opts, 공개 키, short ID, 서버 이름, 일치하는 클라이언트 지문도 올바르게 설정해야 합니다. flow 역시 서버 설정과 일치해야 합니다. 기존 VMess 노드의 유형만 VLESS로 바꿔서는 프로토콜이 변환되지 않습니다.

Hysteria2 노드의 유형은 type: hysteria2로 지정합니다. Hysteria 1세대와 설정 형식이 다릅니다. 인증 값, 포트, SNI, 난독화, 대역폭 매개변수는 서버 설정에 맞춰야 하며, 현재 네트워크에서 해당 UDP 통신도 허용되어야 합니다. TCP 웹페이지가 열린다고 해서 Hysteria2의 UDP 핸드셰이크까지 연결되는 것은 아닙니다.

전체 구독 설정을 반복해서 직접 수정하기보다 구독 제공 업체에 mihomo용 출력 형식을 요청하세요.
인증서 이름이나 신뢰 체인 오류를 전역 설정 skip-cert-verify: true로 덮어서는 안 됩니다.
노드에는 비밀번호, UUID, 인증 토큰이 포함될 수 있습니다. 로그를 공유하기 전에 민감 정보를 가리고 구독 URL의 토큰도 삭제하세요.

룰셋 마이그레이션: provider, behavior, 파일 내용 구분하기

proxy-providers는 노드를 제공하고, rule-providers는 매칭 조건을 제공합니다. 전자는 정책 그룹의 use로 참조하고, 후자는 RULE-SET 규칙으로 참조합니다. 노드 구독 주소를 규칙 제공자에 넣으면 주소에서 파일을 내려받을 수 있더라도 유효한 분기 규칙을 얻을 수 없습니다.

아래는 로컬 파일을 사용하는 예입니다. 설정 파일과 rules 디렉터리는 같은 설정 작업 디렉터리에 둡니다. 클라이언트가 별도의 커널 작업 디렉터리를 사용한다면 실제 작업 디렉터리를 기준으로 확인하세요. 이 예시는 규칙 파일을 불러오는 방법만 보여 주며 프록시 노드나 프록시 아웃바운드 기능은 포함하지 않습니다.

주 설정의 규칙 제공자

rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,DIRECT

rules/local-domains.yaml의 내용

payload:
  - '+.example.com'
  - 'example.org'

behavior: domain 항목에는 도메인 패턴을 넣어야 하며 DOMAIN-SUFFIX,example.com 같은 완성된 규칙을 직접 넣을 수 없습니다. behavior: classical을 사용하면 payload에 DOMAIN-SUFFIX,example.com처럼 지원되는 클래식 규칙 항목을 작성할 수 있습니다. 실행 정책은 바깥쪽의 RULE-SET에서 지정합니다.

domain: 도메인 매칭 항목에 사용하며, 도메인 목록만 담을 때 적합합니다.
ipcidr: 192.168.0.0/16 같은 IP 대역에 사용합니다. 도메인을 섞지 마세요.
classical: 지원되는 클래식 규칙 유형에 사용하며, 앞의 두 유형과 파일 형식이 다릅니다.

YAML, 일반 텍스트, MRS는 서로 다른 저장 형식입니다. MRS는 mihomo의 바이너리 룰셋 형식으로 domain과 ipcidr 동작을 지원하며, 원본 커널과 함께 쓰는 범용 교환 형식으로는 적합하지 않습니다. 마이그레이션할 때는 behavior, format, 원격 서버가 실제로 반환하는 내용을 함께 확인하세요. 파일 확장자를 .yaml로 바꿔도 내부 형식은 달라지지 않습니다.

규칙은 여전히 위에서부터 순서대로 매칭됩니다. MATCH를 앞에 두면 뒤의 규칙이 적용되지 않습니다. 범위가 넓은 DIRECT 규칙을 프록시 규칙보다 앞에 두어도 기존 분기 결과가 달라질 수 있습니다. 파일을 성공적으로 불러왔다는 것은 내용을 파싱할 수 있다는 뜻일 뿐, 규칙 순서가 의도대로 작동한다는 뜻은 아닙니다.

sniffer 스니핑: 도메인 단서를 보완할 뿐, 트래픽을 복호화하지 않습니다

일부 연결은 목적지 IP만 있는 상태로 커널에 전달됩니다. mihomo의 sniffer는 지원되는 HTTP, TLS, QUIC 트래픽에서 도메인 정보를 추출해 규칙 매칭을 보조할 수 있습니다. 관련 옵션에 따라 연결 대상이 바뀔 수도 있습니다. HTTPS 복호화 프록시가 아니므로 TLS로 암호화된 본문을 가져오지 않으며, 모든 연결에서 도메인을 추출할 수 있는 것도 아닙니다.

sniffer:
  enable: true
  override-destination: false
  sniff:
    HTTP:
      ports: [80, 8080]
    TLS:
      ports: [443]
    QUIC:
      ports: [443]

이 설정은 HTTP 검사를 80, 8080 포트로 제한하고 TLS와 QUIC 검사는 443 포트에서만 수행하며, 연결 대상 주소 덮어쓰기를 명시적으로 비활성화합니다. 먼저 스니핑과 규칙 매칭 결과를 확인하기 좋고, 연결 대상이 바뀌는 변수를 동시에 추가하지 않아도 됩니다. 검사 포트 범위를 넓힐지는 사용 목적에 따라 결정하세요. ‘더 완전하게’ 만들겠다며 모든 포트를 검사하는 것은 권장하지 않습니다.

특정 사이트에서 스니핑을 켠 뒤 문제가 생기면 먼저 sniffer.enable을 끄고 한 번에 한 가지씩 비교하세요. 이어 관련 도메인을 skip-domain에 추가해야 하는지 확인합니다. TLS에서 ECH 같은 기술을 사용하면 확인 가능한 도메인 정보가 줄어들 수 있습니다. 스니핑은 DNS 분기를 대신하지 않습니다. 클라이언트 DNS가 시스템 네트워크를 우회하는 경우에는 DNS 설정이나 트래픽 가로채기 경로에서 별도로 처리해야 합니다.

DNS와 TUN: 기본 설정은 유지하되 실행 조건은 다시 확인하기

기존 설정의 dns.enable, enhanced-mode: fake-ip, fake-ip-filter 같은 항목은 mihomo에서도 사용할 수 있습니다. Fake-IP는 예약된 주소와 도메인을 매핑한 뒤 후속 연결에서 해당 도메인 정보를 복원합니다. ‘모든 DNS가 프록시를 거친다’는 뜻이 아니며 브라우저에서 별도로 사용하는 암호화 DNS까지 자동으로 가로채지도 않습니다.

새 DNS 필드를 단독으로 복사하지 마세요

nameserver-policy는 특정 도메인에 지정된 리졸버를 사용하게 합니다. proxy-server-nameserver는 프록시 노드 서버 도메인을 조회하는 데 사용하고, respect-rules는 DNS 업스트림 연결에 라우팅 규칙을 적용할 수 있습니다. 이 설정을 활성화하면 프록시 노드 도메인의 별도 조회 경로를 확인해야 합니다. ‘노드 조회를 위해 프록시가 필요한데 프록시 연결을 위해 노드 조회가 필요한’ 순환 의존이 생기지 않도록 주의하세요.

마이그레이션 초기에는 이미 작동이 확인된 DNS 업스트림을 유지하고, 도메인 조회와 대상 규칙 매칭을 먼저 확인한 뒤 새 필드를 하나씩 적용하세요. 두 클라이언트의 DNS 설정을 통째로 합치지 마세요. 같은 키가 뒤의 설정으로 덮일 수 있고, 클라이언트가 실행 전에 자체 수신 주소나 정책을 주입할 수도 있습니다.

TUN 오류는 YAML 문법 문제만으로 발생하지 않습니다

권한: 가상 네트워크 어댑터 생성과 라우팅 변경에는 관리자 권한, 시스템 서비스 또는 해당 네트워크 권한이 필요할 수 있습니다.
라우팅: 자동 라우팅을 VPN, 가상 머신 네트워크, 다른 트래픽 가로채기 소프트웨어와 조율해 이중 가로채기를 방지해야 합니다.
DNS 가로채기: dns-hijack의 포트 53 규칙만으로 모든 DoH·DoT 요청이 가로채지는 것은 아닙니다.
시스템 프록시: 시스템 프록시 설정을 따르는 앱에 적용됩니다. TUN은 가상 네트워크 어댑터 수준에서 트래픽을 가로채므로 두 기능은 서로 다른 설정입니다.

문제를 진단할 때는 먼저 TUN을 끄고 지정된 로컬 프록시 포트로 노드를 테스트한 다음 TUN만 따로 활성화하세요. 이렇게 하면 ‘노드 연결 실패’와 ‘시스템 트래픽 가로채기 실패’를 구분할 수 있어 라우팅 문제를 노드 비밀번호 수정으로 해결하려고 반복하는 일을 막을 수 있습니다.

기존 설정 마이그레이션: 최소 설정, 규칙, 트래픽 가로채기 순서로 확인하기

마이그레이션을 시작하자마자 모든 고급 필드를 한꺼번에 복사하지 마세요. 기존 클라이언트의 수신 포트, 작동 모드, 정책 그룹 선택, 커널 버전을 기록한 다음 되돌릴 수 있는 복사본을 만드세요. 아래 절차는 커널을 직접 확인할 때뿐 아니라 클라이언트가 생성한 설정의 문제를 찾을 때도 사용할 수 있습니다.

실제 커널 확인. 독립 실행 환경에서는 mihomo -v를 실행하세요. 클라이언트 환경에서는 커널 정보나 시작 로그를 확인해 클라이언트 버전과 커널 버전을 구분합니다.
설정 문법 확인. 설정 디렉터리에서 mihomo -t -f ./config.yaml을 실행하세요. 파일 provider가 상대 경로를 사용한다면 커널의 작업 디렉터리도 확인합니다. 문법 검사를 통과해도 원격 노드 연결까지 성공했다는 뜻은 아닙니다.
로컬 수신 설정 고정. 예를 들어 mixed-port: 7890을 사용하고 allow-lan: false를 유지합니다. 7890은 이 예시의 포트일 뿐 모든 클라이언트의 기본값은 아닙니다.
노드 하나씩 검증. 작동이 확인된 노드 하나를 선택해 로컬 프록시로 목적지에 요청을 보낸 뒤 자동 정책 그룹을 활성화하세요. 상태 검사와 노드 전환이 문제를 가리지 않도록 먼저 하나씩 확인하는 것이 좋습니다.
규칙과 DNS 복원. 규칙 제공자를 하나씩 활성화하고 연결 기록에서 매칭된 규칙, 정책 그룹, 최종 노드를 확인하세요. 웹페이지가 열리는지만 확인해서는 부족합니다.
마지막으로 TUN과 스니핑 활성화. 매번 기능 하나만 변경하고, 실패 전후의 로그와 실제 적용 설정을 보관하세요.

mihomo -v
mihomo -t -f ./config.yaml
curl --proxy http://127.0.0.1:7890 --head https://example.com

위 curl 명령은 로컬에 curl이 설치되어 있다고 가정하고 7890 포트를 명시해 요청을 보냅니다. Windows PowerShell에서 curl이 다른 명령에 매핑되어 있다면 curl.exe를 사용하세요. HTTP 응답이 반환되면 해당 요청 경로가 작동한다는 뜻이지만 모든 도메인, UDP, TUN 트래픽까지 정상이라는 의미는 아닙니다.

먼저 확인할 기존 설정 방식

구형 키 이름: 예전 템플릿의 Proxy, Proxy Group, Rule은 현재 설정 구조에 맞게 proxies, proxy-groups, rules로 정리하세요. 과거 버전의 호환 처리에 의존하지 마세요.
정책 그룹 참조: rules에서 참조하는 그룹 이름이 실제로 존재해야 하며 대소문자와 공백도 일치해야 합니다. 기존 그룹을 삭제했다면 마지막 MATCH 규칙도 수정하세요.
프로토콜 전용 필드: 다른 커널의 JSON 필드를 mihomo YAML에 그대로 붙여 넣지 마세요. 같은 프로토콜이라도 설정 체계에 따라 필드의 계층 구조와 이름이 다를 수 있습니다.
제어 인터페이스: external-controller는 프록시 수신 포트와 용도가 다릅니다. 로컬 관리 전용이라면 루프백 주소에 바인딩하세요. 원격 접속이 필요하면 인증을 설정하고 네트워크 접근 범위를 제한해야 합니다.

문제 진단: 설정 로드, 연결, 트래픽 분기 결과를 구분해 확인하기

증상	우선 확인할 항목	검증 방법
지원하지 않는 프록시 유형	실행 중인 커널과 구독 출력 형식	커널 버전을 확인하고 노드의 type 필드를 점검합니다.
규칙 제공자 로드 실패	파일 경로, 반환된 내용, behavior, format	실제 파일을 열어 오류 페이지나 노드 구독이 아닌지 확인합니다.
설정 검사는 통과했지만 노드 연결 시간 초과	주소, 포트, 인증, TLS, UDP 연결 가능 여부	노드 하나를 고정해 테스트하고 자동 전환은 함께 켜지 않습니다.
수동 프록시는 정상인데 TUN은 작동하지 않음	권한, 라우팅, DNS 가로채기, 다른 VPN	충돌하는 트래픽 가로채기 기능을 끄고 도메인과 IP 연결을 각각 테스트합니다.
재시작하면 수정 사항이 사라짐	구독 업데이트와 클라이언트 설정 병합	사용자 설정을 클라이언트의 영구 오버라이드 기능에 넣습니다.

mihomo의 주요 장점은 프로토콜 지원 범위와 설정 기능의 확장이지, 기존 설정을 어떤 환경에서든 자동으로 동일하게 실행하는 데 있지 않습니다. 안정적인 마이그레이션은 ‘화면에 오류가 없다’는 것만으로 판단할 수 없습니다. 노드 연결, DNS 조회, 규칙 매칭, 시스템 트래픽 가로채기를 각각 확인한 뒤 평소의 구독 업데이트를 다시 활성화하세요. 클라이언트 선택은 클라이언트 비교를 참고하고, 최초 설치와 시스템 권한 설정은 전체 플랫폼 가이드에서 확인하세요.