mihomo와 원본 Clash 커널 차이: 프로토콜 지원, 규칙 확장, 설정 호환성

요약: 기존 설정은 대체로 옮겨 쓸 수 있지만, 새 기능을 원본 커널에 그대로 적용할 수는 없습니다

구독에 흔히 쓰이는 Shadowsocks, VMess, Trojan 노드가 있고 규칙이 주로 DOMAIN-SUFFIX, IP-CIDR, MATCH를 사용한다면, mihomo로 옮길 때 YAML 전체를 다시 작성할 필요는 없는 경우가 많습니다. 노드 확장 매개변수, 규칙 세트 형식, DNS 설정, 클라이언트가 수동으로 수정한 값을 덮어쓰는지 여부는 항목별로 확인해야 합니다.

mihomo는 Clash Meta 프로젝트가 이후 사용한 이름으로, Clash의 설정 체계를 이어받아 프로토콜과 트래픽 처리 기능을 계속 확장하고 있습니다. mihomo는 커널이며, GUI가 있는 특정 Clash 클라이언트와 같은 뜻이 아닙니다. 클라이언트는 구독 관리, 시스템 프록시 전환, 설정 병합을 담당하고 커널은 연결을 만들고 규칙을 적용하며 DNS를 처리합니다. 인터페이스 프로그램만 바꿔도 실제 실행 중인 커널은 그대로일 수 있습니다.

원본 프로젝트는 유지 관리가 중단됐습니다. 새 프로토콜, 꾸준히 업데이트되는 규칙 기능, 최신 시스템 지원이 필요하다면 계속 관리되는 커널을 우선 검토하세요. 다만 커널을 업데이트한다고 모든 노드의 속도가 빨라지는 것은 아닙니다. 회선 품질, 서버 설정, 네트워크 패킷 손실, 실제로 적용되는 아웃바운드 정책이 연결 성능에 직접 영향을 줍니다.

프로토콜 지원: 노드 유형과 핸드셰이크 매개변수 확인

노드 또는 기능	원본 Clash 오픈소스 커널	mihomo로 이전할 때 확인할 항목
Shadowsocks、VMess、Trojan	일반적인 설정 지원	암호화 방식, 전송 계층, TLS 매개변수 확인
VLESS、Reality	해당 최신 조합은 지원하지 않음	서버에서 요구하는 flow, 지문, 공개 키, short-id 확인
Hysteria2、TUIC	지원하지 않음	UDP 연결 여부와 프로토콜별 인증 필드 확인
최신 암호화 및 전송 확장 기능	이전 버전의 제약이 있음	알고리즘, 전송 유형, 커널 버전을 기준으로 확인

VLESS 지원이 모든 VLESS 링크를 바로 사용할 수 있다는 뜻은 아닙니다

노드의 type은 첫 단계에 불과합니다. VLESS와 Reality를 함께 쓰면 servername, client-fingerprint, reality-opts의 공개 키와 짧은 식별자도 확인해야 할 수 있습니다. Vision을 사용한다면 flow도 점검하세요. 각 매개변수는 서버 설정과 일치해야 하며 다른 노드에서 복사해 그대로 재사용하면 안 됩니다.

“지원하지 않는 프록시 유형” 오류가 표시됨: 클라이언트 이름이나 구독 파일명만 보지 말고 실제 커널이 mihomo인지 먼저 확인하세요.
설정 검사는 통과했지만 TLS 핸드셰이크 실패: 시스템 시간, SNI, 인증서 도메인, Reality 매개변수를 확인하세요. 인증서 검증부터 끄지는 마세요.
Hysteria2 또는 TUIC 시간 초과: 현재 네트워크와 서버에서 UDP를 허용하는지 확인하세요. 브라우저에서 다른 TCP 노드로 웹페이지가 열린다고 UDP 연결까지 정상이라는 뜻은 아닙니다.

구독 변환에도 한계가 있습니다. 변환 도구는 필드 구조를 바꿀 수 있지만 Hysteria2 서버를 원본 Clash가 지원하는 VMess 서버로 자동 변환할 수는 없습니다. 클라이언트가 새 프로토콜을 인식하지 못한다면 호환되는 커널로 바꾸거나 서비스 제공업체가 명시적으로 지원하는 다른 노드를 사용하세요.

규칙 확장: 기본 문법은 유지하고 규칙 세트 형식은 확인하세요

Clash의 일반적인 규칙은 목록 위에서 아래 순서로 확인되며, 처음 일치한 규칙에 따라 아웃바운드 정책이 결정됩니다. 이전할 때는 기존 규칙 순서를 먼저 유지하고 한꺼번에 수십 개 규칙을 바꾸지 마세요. 특히 규칙에서 참조하는 정책 그룹이 실제로 있는지 확인하고, 앞선 규칙에 일치하지 않은 연결을 처리하도록 마지막에 MATCH를 두세요.

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Proxy

여기서 Proxy는 설정에 이미 정의된 정책 그룹 또는 아웃바운드 이름이어야 합니다. example.com은 문법을 보여 주기 위한 예시 도메인입니다. no-resolve는 이 IP 규칙이 도메인 조회를 새로 시작하지 않는다는 뜻이지, 커널의 DNS 전체를 끈다는 뜻은 아닙니다. 연결에 대상 IP가 이미 있다면 해당 IP로 규칙을 적용할 수 있습니다.

rule-providers와 RULE-SET은 서로 다른 개념입니다

rule-providers는 규칙을 어디서 가져오고 어떻게 해석할지 정의하며, RULE-SET은 기본 규칙 목록에서 해당 규칙 제공자를 참조합니다. mihomo는 규칙 제공자를 지원하며 더 다양한 규칙 조합과 매칭 기능도 제공합니다. Premium 사용자는 이 중 일부 기능을 이미 사용했을 수 있습니다.

rule-providers:
  private-net:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/private.yaml

rules:
  - RULE-SET,private-net,DIRECT
  - MATCH,Proxy

여기에 해당하는 ./rules/private.yaml 파일에는 다음과 같은 내용을 넣을 수 있습니다. 상대 경로는 일반적으로 커널의 작업 디렉터리를 기준으로 하며 GUI 프로그램이 있는 디렉터리와 다를 수 있습니다. 파일을 찾지 못하면 먼저 시작 로그에서 작업 경로를 확인하세요.

payload:
  - IP-CIDR,10.0.0.0/8,no-resolve
  - IP-CIDR,172.16.0.0/12,no-resolve
  - IP-CIDR,192.168.0.0/16,no-resolve

behavior: classical은 위의 IP-CIDR처럼 규칙 유형이 포함된 항목을 받습니다.
behavior: domain과 behavior: ipcidr은 각각 해당 형식의 콘텐츠를 사용합니다. classical 규칙 전체를 그대로 섞어 넣지 마세요.
mihomo의 MRS 바이너리 규칙 세트는 domain 또는 ipcidr 유형에 사용합니다. 임의의 classical YAML 파일은 확장자만 바꾼다고 MRS가 되지 않습니다.
논리 규칙, 프로세스 매칭 등의 확장 기능은 하나씩 검증하세요. 프로세스 식별은 운영체제, 권한, 트래픽 가로채기 방식의 영향도 받습니다.

이전 후 많은 웹사이트가 기본 정책으로 빠진다면 먼저 규칙 세트가 정상적으로 로드됐는지 확인한 뒤 규칙 순서를 살펴보세요. 규칙 세트 주소에서 파일을 내려받을 수 있다고 해서 콘텐츠 형식이 behavior 설정과 일치하는 것은 아닙니다.

DNS 차이: 기본 필드는 유지하고 조회와 아웃바운드를 따로 확인하세요

원본 Clash에도 DNS 모듈과 Fake-IP 등 기본 기능이 있습니다. mihomo는 이를 바탕으로 도메인별 조회 서버 선택, 노드 도메인 조회 등의 제어 기능을 확장했습니다. DNS가 올바른 주소를 반환하는 것과 연결에 맞는 정책이 적용되는 것은 별개의 문제입니다. 전자는 접속할 대상을 정하고 후자는 어떤 경로로 연결할지 정합니다.

기존 설정에서 우선 유지할 수 있는 필드

일반적인 dns.enable, listen, enhanced-mode, fake-ip-range, nameserver는 이전을 시작할 때 그대로 쓸 수 있습니다. 아래는 이해를 돕기 위한 DNS 설정 예시이며 전체 노드와 정책 그룹을 포함하지 않고 시스템 DNS도 자동으로 변경하지 않습니다.

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

1053은 이 예시에서 로컬 DNS가 수신 대기하는 포트입니다. 일반적인 시스템 DNS 설정에는 보통 서버 주소만 입력하며 이 포트까지 함께 입력할 수 없습니다. 시스템 DNS 요청을 가로채려면 별도의 전달 설정을 하거나 해당 환경에서 TUN의 DNS 하이재킹을 활성화해야 합니다. 198.18.0.1/16은 Fake-IP 매핑에 사용하는 주소이지 원격 웹사이트의 실제 공인 IP가 아닙니다.

새 기능을 한꺼번에 모두 켜지 마세요

nameserver-policy: 지정한 도메인 또는 도메인 그룹에 사용할 DNS 서버를 선택합니다. 사내 도메인과 공용 도메인을 나눠 처리할 때 유용합니다.
proxy-server-nameserver: 프록시 노드의 서버 도메인을 조회할 경로를 지정합니다. 프록시 노드 주소를 조회할 때 아직 연결되지 않은 프록시에 의존하는 상황을 피할 수 있습니다.
fake-ip-filter: 호환성 문제가 실제로 있는 도메인만 Fake-IP에서 제외하세요. LAN 서비스 하나 때문에 전체 트래픽 분리 설정을 해제하지 마세요.

검증할 때는 클라이언트 DNS 로그, 연결 상세 정보의 도메인, 최종 적용된 정책을 각각 확인하세요. 브라우저의 보안 DNS는 별도의 조회 경로를 사용할 수 있습니다. 커널 DNS만 바꿨다고 브라우저의 모든 조회가 커널을 거친다고 단정할 수는 없습니다.

TUN과 트래픽 스니핑: 트래픽 가로채기 범위와 규칙 모드는 다릅니다

시스템 프록시는 시스템 프록시 설정을 읽는 앱에서 주로 사용합니다. TUN은 가상 네트워크 인터페이스로 트래픽을 가로채므로 시스템 프록시를 사용하지 않는 프로그램에 적합합니다. TUN은 트래픽이 커널로 들어오는 방식이고 규칙 모드는 들어온 트래픽에 어떤 아웃바운드를 적용할지 결정하므로 서로 배타적인 옵션이 아닙니다.

원본 오픈소스 커널과 Premium의 TUN 기능을 혼동하지 마세요. mihomo로 옮긴 뒤에도 tun 설정만 복사한다고 모든 기능이 활성화되는 것은 아닙니다. 클라이언트에서 서비스 설치나 관리자 권한이 필요할 수 있고, GUI가 해당 필드를 생성한 뒤 덮어쓸 수도 있습니다.

구독, 노드, 규칙을 먼저 확인하려면 시스템 프록시를 사용하세요. 설정 검사가 끝나기 전에 TUN까지 함께 설정하지 마세요.
기본 경로 충돌을 피하려면 다른 VPN이나 가상 네트워크 어댑터 도구를 끄고 비교하세요.
TUN을 켠 뒤 로그에서 가상 인터페이스와 경로가 생성됐는지 확인하고 권한 오류가 없는지 살펴보세요.
LAN 프린터, NAS, 사내 네트워크 주소에 접속해 테스트하세요. 필요하면 명시적인 우회 규칙이나 경로 제외를 설정하세요.

mihomo의 트래픽 스니핑은 일부 HTTP, TLS, QUIC 트래픽에서 호스트 정보를 추출해 도메인 규칙 매칭을 도울 수 있습니다. 하지만 HTTPS 콘텐츠를 복호화하는 기능은 아니며 모든 연결을 식별한다고 보장할 수도 없습니다. 암호화된 ClientHello 같은 기능은 확인할 수 있는 정보를 제한할 수 있습니다. 스니핑 설정은 구체적인 트래픽 분리 요구에 맞춰 켜고 모든 DNS 문제를 해결하는 만능책처럼 사용하지 마세요.

기존 구독 이전: 설정이 제공된 위치에 따라 항목별로 처리하세요

설정 항목	일반적인 처리 방법	필수 확인 사항
mixed-port、mode、log-level	우선 기존 값 유지	포트 충돌, 클라이언트가 덮어쓴 값
proxies、proxy-groups	기본 구조 유지	프로토콜 필드, 그룹 내 노드 이름, 테스트 주소
rules	일반 규칙 유지	참조 이름, 순서, MATCH 위치
rule-providers	형식을 확인한 뒤 재사용	behavior, format, 파일 경로, 로드 결과
dns、tun	단계별로 활성화	시스템 권한, 경로, 조회 의존성, GUI 설정 병합
Premium script 스크립트 규칙	그대로 호환된다고 가정할 수 없음	mihomo가 지원하는 규칙 또는 규칙 세트로 다시 작성

실제 이전 순서

원본 설정 백업: 구독 원문과 클라이언트가 현재 생성한 실행 설정을 각각 저장하세요. 둘은 서로 다를 수 있으므로 문제를 확인할 때 구독 편집기만 보지 마세요.
커널 종류 확인: 클라이언트의 커널 정보 또는 시작 로그에서 이름과 버전을 확인하세요. 독립 실행 파일을 사용한다면 mihomo -v를 실행해 버전을 확인할 수 있습니다.
먼저 설정 검사: 설정 파일이 있는 디렉터리에서 mihomo -t -f ./config.yaml을 실행하세요. Windows 독립 실행 파일은 .\mihomo.exe -t -f .\config.yaml을 사용할 수 있습니다.
경로 하나만 먼저 확인: 작동하는 것으로 확인된 노드 하나를 선택하고 시스템 프록시를 켠 다음 규칙 모드로 테스트 페이지에 접속하세요.
확장 기능 단계별 복원: 규칙 세트, DNS 정책, TUN 순서로 활성화하세요. 한 번에 한 종류의 설정만 변경하고 로그를 확인하세요.
마지막으로 구독 업데이트: 사용자 지정 규칙이 사라지지 않았는지 확인한 다음 자동 업데이트와 시작 시 실행을 설정하세요.

설정 검사를 통과했다는 것은 커널이 설정 파일을 읽을 수 있다는 뜻일 뿐, 구독 노드가 온라인이거나 규칙 세트 다운로드와 시스템 프록시가 정상이라는 뜻은 아닙니다. GUI 클라이언트는 시작 전에 설정을 병합할 수도 있으므로 명령줄 검사에 사용하는 파일은 클라이언트가 실제 실행하는 파일과 최대한 일치해야 합니다.

이전 후 검증: 포트, 규칙, DNS를 나눠 확인하세요

실행 설정의 mixed-port가 7890이라고 가정하면 프록시를 명시해 먼저 테스트할 수 있습니다. 이렇게 하면 시스템 프록시 설정이 올바른지 여부를 변수에서 제외할 수 있습니다. 포트는 클라이언트에 실제로 표시된 값으로 바꾸세요.

curl -I --proxy http://127.0.0.1:7890 https://example.com

Windows PowerShell에서는 curl.exe를 사용하면 일부 환경에서 같은 이름의 명령 별칭이 매개변수 해석에 영향을 주는 일을 피할 수 있습니다. 이 테스트는 이번 HTTP 프록시 요청만 확인하며 UDP, TUN, 다른 앱이 정상 작동하는지는 검증하지 않습니다.

연결이 거부됐다는 메시지가 표시됨: 커널 실행 여부, 로컬 포트가 맞는지, 다른 프로세스가 해당 포트를 사용 중인지 먼저 확인하세요.
프록시에는 연결되지만 요청 시간이 초과됨: 선택한 노드, 노드 도메인 조회, 서버 연결 상태를 확인하세요.
페이지는 열리지만 출구가 예상과 다름: 연결 상세 정보에서 적용된 규칙, 정책 그룹의 현재 선택 항목, 전역 모드 사용 여부를 확인하세요.
특정 앱에서만 실패함: 해당 앱이 시스템 프록시를 사용하는지 확인하세요. 사용하지 않는다면 구독을 계속 바꾸기보다 TUN 사용을 검토하세요.

선택 기준은 간단합니다. VLESS Reality, Hysteria2, TUIC 또는 세밀한 규칙·DNS 제어가 필요하다면 해당 기능을 지원하는 mihomo 클라이언트를 사용하세요. 기존 기본 구독을 이전할 때는 안정적으로 작동하는 설정을 우선 재사용하세요. 커널 호환성, 설정 병합, 네트워크 연결을 나눠 확인하면 모든 설정을 한꺼번에 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다.

필드별 자세한 내용은 Clash 설정 매뉴얼에서 확인할 수 있습니다. 포트 충돌, 시스템 프록시 미작동, 권한 문제가 있다면 자주 묻는 질문을 참고해 하나씩 점검하세요.