mihomo 커널과 기존 Clash 비교: 지원 프로토콜·규칙 유형·설정 호환성

커널, 클라이언트, 과거 분기를 구분하기

결론부터 말하면, 최신 프로토콜이나 세밀한 규칙, 지속적으로 관리되는 커널이 필요하다면 mihomo를 우선 검토하세요. 기존 설정이 안정적으로 작동 중이라면 호환성을 먼저 확인한 뒤 실제 트래픽을 전환해야 합니다.두 커널의 차이는 주로 기능 범위와 유지보수 방향에 있습니다. 이름만 바꾼다고 모든 노드의 속도가 빨라지는 것은 아닙니다. 연결 품질은 여전히 서버 설정과 로컬 네트워크 환경에 좌우됩니다.

Clash는 연결 중계, 규칙 매칭, DNS 등을 처리하는 프록시 커널입니다. 데스크톱이나 모바일 클라이언트는 구독 관리, 트레이, 시스템 프록시, 권한 관리 기능을 제공합니다. Clash Meta는 Clash에서 파생된 프로젝트로, 이후 mihomo로 이름이 바뀌었습니다. 오래된 문서나 설정 템플릿, 클라이언트 설정에는 여전히 Meta라는 이름이 남아 있을 수 있습니다. 이는 대개 과거 명칭이 이어진 것이며, 별도의 커널을 하나 더 설치해야 한다는 뜻은 아닙니다.

‘기존 Clash’도 구체적으로 구분해야 합니다. 과거에는 오픈소스 커널과 비공개 소스인 Clash Premium이 있었고, 두 버전의 기능은 완전히 같지 않았습니다. 원 프로젝트는 2023년에 유지보수를 중단했습니다. 과거 Premium의 기능을 모두 오픈소스 버전의 기능으로 간주해서는 안 되며, 서드파티 클라이언트가 계속 업데이트된다고 해서 원래 커널의 유지보수가 재개된 것도 아닙니다.

프로토콜 지원: 새로운 유형이 자동으로 호환되는 것은 아닙니다

mihomo는 기존 프록시 기능에 여러 프로토콜과 전송 방식 지원을 추가했습니다. 사용자가 체감하는 가장 큰 차이는 구독에 VLESS, Hysteria2, TUIC 노드가 포함될 때 나타납니다. 구형 커널은 이를 해석하지 못할 수 있지만, 해당 구현을 지원하는 mihomo는 처리할 수 있습니다. 실제 사용 가능 여부는 버전, 설정 필드, 서버 구성에 따라 달라지므로 노드 표시 이름만 보고 판단해서는 안 됩니다.

주요 기능 비교: 기존 오픈소스 커널과 mihomo
기능	기존 오픈소스 Clash	mihomo를 선택할 때의 이점
Shadowsocks、VMess、Trojan	기본 유형을 지원하지만, 세부 알고리즘과 전송 옵션은 버전에 따라 제한됩니다.	기존 기능을 지원하며 일부 알고리즘, 전송 방식, 연결 옵션이 추가되었습니다.
VLESS 및 REALITY	mihomo에 해당하는 지원 기능이 없습니다.	VLESS를 사용할 수 있으며, 지원되는 설정에서는 REALITY도 사용할 수 있습니다. 두 항목은 같은 계층의 개념이 아닙니다.
Hysteria2、TUIC	비교적 최근에 추가된 노드 유형은 지원하지 않습니다.	해당 기능을 지원합니다. UDP에 의존하는 연결은 로컬 네트워크와 서버 모두의 지원이 필요합니다.
규칙 세트 및 TUN	Premium 기능 목록을 그대로 적용할 수 없습니다.	규칙 프로바이더와 TUN 등을 지원해 복잡한 트래픽 분기 및 트래픽 가로채기에 적합합니다.

노드를 옮길 때 확인할 세 가지 설정

프로토콜 인증 정보: 서버 주소, 포트, 비밀번호 또는 UUID가 서버 설정과 일치해야 합니다. TLS에서 자주 쓰이는 포트 443은 단순한 포트 번호일 뿐, 해당 노드가 반드시 HTTPS를 사용한다는 근거는 아닙니다.
전송 설정: WebSocket 경로, Host, gRPC 서비스 이름 등을 하나씩 맞춰야 합니다. YAML 파일을 읽을 수 있다고 해서 핸드셰이크 설정까지 올바른 것은 아닙니다.
TLS 및 REALITY: servername, 지문, 해당하는 경우 reality-opts를 확인하세요. 도메인이나 인증서 설정 오류를 skip-cert-verify: true로 덮어서는 안 됩니다.

구독 변환 과정에서 새 프로토콜 노드가 이미 제거됐다면 커널을 업그레이드해도 노드가 다시 나타나지 않습니다. 서비스에서 제공하는 구독 형식, 변환기 출력, 클라이언트에 최종 적용된 설정을 모두 확인하세요. 먼저 노드 유형이 실제로 유지됐는지 확인한 다음 핸드셰이크 실패를 진단하면 문제 해결 경로를 크게 줄일 수 있습니다.

규칙과 규칙 세트: 순서를 유지하고 파일 형식을 구분하기

기본 매칭 방식은 같습니다. 규칙 모드에서 rules는 위에서부터 차례로 적용되며, 먼저 일치한 규칙이 연결에 사용할 정책을 결정합니다. DOMAIN, DOMAIN-SUFFIX, IP-CIDR 같은 기본 규칙도 여전히 중요합니다. 일반적으로 마지막에는 일치하지 않은 트래픽을 처리하도록 MATCH를 둡니다. 기능이 추가되더라도 잘못된 규칙 순서가 자동으로 수정되지는 않습니다.

mihomo는 프로세스 이름, 대상 포트, 논리 조합 등을 기준으로 연결을 필터링하는 더 다양한 매칭 조건을 제공합니다. 다만 프로세스 식별은 운영체제, 권한, 트래픽 가로채기 방식에 따라 달라집니다. 설정에 PROCESS-NAME이 있다고 해서 모든 플랫폼에서 기대한 프로세스 정보를 가져올 수 있는 것은 아닙니다.

RULE-SET은 노드 구독이 아닙니다

proxy-providers는 노드를 제공합니다. 최종적으로 프록시 설정으로 해석될 수 있는 내용이어야 합니다.
rule-providers는 매칭 항목을 제공하며, 이를 RULE-SET에서 참조해 적용할 정책을 지정합니다.
behavior: domain, ipcidr, classical은 각각 항목 내용에 대한 요구사항이 다릅니다. 파일 확장자만 바꿔 서로 대체할 수는 없습니다.
mihomo의 mrs는 규칙 세트 형식입니다. 기존 Clash에서 바로 사용할 수 없으며 일반 YAML 텍스트처럼 편집해서도 안 됩니다.

Premium에서 가져온 설정에는 rule-providers와 RULE-SET이 이미 포함되어 있을 수 있습니다. 기존 오픈소스 커널에서 가져온 설정이라면 이 필드가 원래부터 사용 가능했다고 가정해서는 안 됩니다. 아래는 설정 구조를 검증하기 위한 완전한 예제로, 원격 구독은 포함하지 않으며 정책 그룹에는 직접 연결 옵션만 있습니다.

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

proxy-groups:
  - name: 출구 선택
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,출구 선택

이 설정은 로드, 포트, 규칙 구조만 검증하며 프록시 경로는 제공하지 않습니다. 실제 노드를 연결한 뒤 유효한 노드나 노드 프로바이더를 정책 그룹에 추가하세요. MATCH를 구체적인 규칙보다 앞에 두지 말고, 규칙이 이미 이름이 바뀌었거나 존재하지 않는 정책 그룹을 참조하지 않는지도 확인하세요.

DNS 차이: 확인해야 할 해석 경로와 시작 시 의존성

기존 Clash에도 DNS와 Fake-IP 기능이 있으므로 ‘mihomo로 바꿔야 Fake-IP를 쓸 수 있다’는 설명은 정확하지 않습니다. mihomo의 차이는 더 많은 DNS 제어 옵션과 트래픽 분기 기능의 조합에 있습니다. 예를 들어 nameserver-policy로 특정 도메인에 사용할 리졸버를 지정하거나, proxy-server-nameserver로 프록시 서버 도메인을 별도로 해석할 수 있습니다.

fake-ip 모드는 도메인에 매핑 주소를 반환한 뒤 커널이 해당 매핑을 기준으로 연결을 처리합니다. redir-host는 실제 DNS 응답을 반환하는 방식에 가깝습니다. 적절한 방식은 앱 호환성과 네트워크 트래픽 처리 방식에 따라 달라집니다. LAN 기기 검색, 특정 게임, 사내 네트워크에서 문제가 생기면 모든 도메인을 필터 목록에 추가하기보다 해당 도메인과 접속 경로를 확인하세요.

혼동하기 쉬운 DNS 필드 세 가지

필드	주요 기능	마이그레이션 시 확인할 점
`default-nameserver`	DNS 서버 자체의 도메인 해석 등 초기 연결에 필요한 주소 확인에 사용합니다.	사용 가능한 IP 형식의 초기 연결 주소를 유지해 리졸버가 아직 구축되지 않은 DNS 경로에 의존하지 않도록 합니다.
`proxy-server-nameserver`	프록시 노드 서버 도메인을 조회할 리졸버를 지정합니다.	노드에 연결하려면 먼저 도메인을 해석해야 합니다. 노드 도메인 해석이 다시 해당 노드를 거쳐야 하는 순환 구조가 생기지 않도록 주의하세요.
`respect-rules`	설정된 규칙에 따라 DNS 상위 서버 연결을 라우팅합니다.	활성화할 때는 노드 도메인 해석 설정과 규칙의 출구도 함께 확인하세요. 불리언 값 하나만 복사해서는 안 됩니다.

TUN과 클라이언트: 기능 설정 외에 권한도 필요합니다

시스템 프록시는 보통 시스템 프록시 설정을 따르는 앱에만 적용됩니다. TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 IP 트래픽을 가로챕니다. mihomo는 TUN을 지원하지만, 정상 작동 여부는 시스템 권한, 가상 네트워크 어댑터, 라우팅 규칙, 다른 VPN 소프트웨어에 따라 달라집니다. TUN을 켜도 서버 프로토콜이 바뀌지는 않으며, UDP 전달을 지원하지 않는 연결이 갑자기 UDP를 지원하게 되는 것도 아닙니다.

먼저 일반 프록시를 확인하세요: 시스템 프록시나 명시적 HTTP 프록시로 테스트해 노드 자체가 연결되는지 확인한 다음 TUN을 설정하세요. 두 종류의 문제를 동시에 진단하는 상황을 피할 수 있습니다.
그다음 권한을 확인하세요: 데스크톱 클라이언트는 서비스 구성 요소를 통해 필요한 권한을 얻을 수 있습니다. 커널을 직접 실행한다면 운영체제 요구사항에 맞게 네트워크 관리 권한을 부여해야 합니다.
마지막으로 라우팅과 DNS를 확인하세요:auto-route, auto-detect-interface, DNS 가로채기는 실제 네트워크 환경에 맞춰 사용해야 합니다. 특히 여러 네트워크 어댑터, 기업용 VPN, 가상 머신 네트워크를 함께 사용할 때 주의하세요.

혼합 프록시 수신 포트 7890을 TUN 어댑터 포트로 착각하지 말고, 컨트롤러 포트 9090을 브라우저 프록시 설정에 입력하지 마세요. 컨트롤러는 클라이언트가 커널을 관리하는 데 쓰이며 일반 웹 프록시 진입점이 아닙니다. 컨트롤러를 설정한다면 루프백 주소에서만 접근할 수 있게 제한하고 인증 정보를 설정하세요.

기존 설정 마이그레이션: 덮어쓰지 말고 여섯 단계로 검증하기

기본 YAML 구조의 상당 부분은 이어서 사용할 수 있지만, ‘기존 설정으로 실행 가능’과 ‘새 설정이 온전히 적용됨’은 별개의 확인 항목입니다. 알 수 없는 필드는 무시될 수 있고, 특정 규칙이나 노드는 로드 후속 단계에서 오류를 일으킬 수 있습니다. 원본 설정과 기존 클라이언트 환경을 보존하고 별도 복사본에서 단계적으로 검증하는 것이 좋습니다.

설정 출처 백업: 구독 원문, 클라이언트 덮어쓰기 규칙, 현재 적용 중인 설정을 각각 저장하세요. 클라이언트에 표시되는 구독 파일이 커널에 최종 전달되는 파일과 같지 않을 수 있습니다.
실행 환경 기록: 운영체제, 클라이언트 버전, mihomo -v 출력, 시스템 프록시와 TUN 사용 여부를 기록하세요. 전환하기 전에 다른 인스턴스를 종료해 포트 충돌을 방지하세요.
설정 테스트 실행: 설정 파일이 있는 디렉터리에서 아래 명령을 실행하세요. 규칙 프로바이더가 상대 경로를 사용하는 경우 작업 디렉터리가 실제 실행 환경과 일치하는지 확인하세요.

mihomo -v
mihomo -t -f ./config.yaml

오류 유형 확인: YAML 들여쓰기나 타입 오류는 문법부터 수정하고, 정책 그룹이 없다는 오류는 이름을 확인하세요. 노드 유형을 인식하지 못하면 커널 버전과 구독 출력을 확인하세요. 오류가 보인다고 구독을 계속 갱신해 현재 상태를 덮어쓰지 마세요.
실제 연결 테스트: 커널을 시작한 뒤 명시적 프록시 요청으로 프록시 진입점, 노드, TLS를 확인하고 로그에서 어떤 규칙이 적용됐는지 살펴보세요. 설정 테스트 통과만으로 실제 인터넷 연결이 검증되는 것은 아닙니다.
확장 기능을 하나씩 복원: 마지막에 원격 규칙 세트, DNS 정책, 프로세스 규칙, TUN을 추가하세요. 항목을 하나 추가할 때마다 다시 테스트하면 문제를 일으킨 변경 사항을 쉽게 찾을 수 있습니다.

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

이 명령은 혼합 포트가 7890이고 프록시 인증이 설정되지 않은 경우를 가정합니다. 포트가 다르면 그에 맞게 수정하세요. HTTP 응답을 받았다는 것은 해당 요청이 완료됐다는 뜻일 뿐, 모든 규칙이나 UDP 앱, TUN이 정상이라는 의미는 아닙니다. 직접 연결할 대상과 프록시를 거칠 대상을 각각 테스트하고 로그에 표시된 정책 이름도 확인하세요.

구독을 갱신한 뒤 설정이 원래대로 돌아가면 어떻게 해야 하나요?

구독 관리 대상 파일을 직접 편집했다면 다음 새로고침 때 서버의 내용으로 덮어써질 가능성이 큽니다. 현재 클라이언트가 지원하는 덮어쓰기, 병합 또는 스크립트 기능으로 로컬 변경 사항을 보존하고 병합 순서도 확인하세요. 클라이언트마다 병합 문법이 다르므로 특정 클라이언트의 덮어쓰기 조각을 mihomo 기본 필드처럼 사용해서는 안 됩니다.

클라이언트 선택 결론: 실제 필요에 맞춰 마이그레이션 범위 정하기

새 프로토콜이 필요하다면: 적절한 버전의 mihomo가 통합된 클라이언트를 우선 선택하고, 구독 출력에 노드 필드가 빠짐없이 포함되는지 확인하세요.
복잡한 트래픽 분기가 필요하다면: 규칙 프로바이더, 프로세스 식별, DNS 정책, 대상 플랫폼 지원 여부를 확인하세요. 화면에 ‘규칙 모드’ 버튼이 있는지만 비교해서는 안 됩니다.
기존 환경이 안정적으로 작동 중이라면: 복사본으로 먼저 검증한 뒤 일상적으로 사용하는 연결을 교체하세요. 마이그레이션의 목표는 필요한 기능과 유지보수성을 확보하는 것이지 이름을 바꾸는 것이 아닙니다.

클라이언트를 선택할 때는 클라이언트 비교에서 플랫폼과 커널 계열을 확인하세요. 프로토콜 필드를 자세히 확인하려면 프로토콜 가이드를 참고하세요. 최종 판단은 실제 실행 버전, 로드 로그, 연결 결과를 기준으로 해야 합니다. 노드가 정상적으로 해석되고, 규칙 적용 경로를 추적할 수 있으며, DNS 경로가 분명해야 재현 가능한 마이그레이션이 완료된 것입니다.