mihomo와 오리지널 Clash 코어 차이: 프로토콜, 규칙 세트, 설정 호환성

먼저 결론부터: 기본 설정은 비슷하지만 확장 기능은 역방향으로 적용할 수 없습니다

설정에 일반적인 노드, select 정책 그룹, 도메인 분기 규칙만 있다면 mihomo로 옮길 때 대개 약간의 수정만 필요합니다. 하지만 YAML을 읽을 수 있다고 해서 모든 필드가 기존과 똑같이 작동하는 것은 아닙니다. 새 프로토콜, 규칙 데이터 파일, DNS 하이재킹 또는 TUN 트래픽 처리와 관련된 항목은 평소 사용하는 설정을 바로 덮어쓰지 말고 각각 검증해야 합니다.

여기서 말하는 ‘오리지널 Clash’는 먼저 두 가지를 구분해야 합니다. 오리지널 오픈소스 코어와 별도로 배포된 Clash Premium 코어는 기능 범위가 다릅니다. 특히 규칙 제공자와 TUN 기능은 예전 클라이언트에서 지원된다는 이유만으로 오리지널 오픈소스 코어도 지원한다고 판단할 수 없습니다. mihomo는 Clash Meta의 뒤를 이어 개발되는 프로젝트이지, 구형 코어의 표시 이름만 바꾼 것이 아닙니다.

구형 설정을 mihomo로 옮기는 경우: 기본 문법은 상당 부분 겹치지만 제거되거나 이름이 바뀐 항목, 클라이언트가 덮어쓰는 항목은 확인해야 합니다.
mihomo 설정을 구형 코어로 옮기는 경우: VLESS, Hysteria2, GEOSITE 등의 확장 기능을 사용할 수 있다고 가정해서는 안 됩니다.
그래픽 클라이언트를 바꾸는 경우: 서비스 권한, 설정 디렉터리, 오버라이드 규칙, 시스템 프록시 설정 경로도 달라지므로 코어만 비교해서는 안 됩니다.

프로토콜 지원: 노드 유형과 전송 매개변수를 함께 확인하세요

오리지널 오픈소스 Clash에서 흔히 사용하는 아웃바운드 유형은 Shadowsocks, VMess, Trojan, SOCKS5, HTTP입니다. mihomo는 여기에 VLESS, Hysteria2, TUIC 같은 프로토콜과 전송 방식을 추가하고, 관련 REALITY 설정도 지원합니다. 사용할 수 있는 매개변수는 실제 설치된 mihomo 빌드에 따라 다릅니다. 최신 문서의 필드를 아주 오래된 Clash Meta 바이너리에 그대로 적용해서는 안 됩니다.

확인 항목	오리지널 Clash 오픈소스 코어	mihomo
VMess, Trojan 등 일반적인 노드	해당 기능을 지원하며, 매개변수는 구형 코어 기준	지원하지만 전송 방식과 TLS 매개변수 확인 필요
VLESS、Hysteria2、TUIC	해당 노드 유형을 직접 사용할 수 없음	각 프로토콜을 지원하며 설정 필드는 서로 다름
rule-providers	일반적인 내장 기능으로 볼 수 없음. 구형 Premium 지원 여부는 별도로 확인해야 함	외부 규칙 제공자 지원
GEOSITE 규칙	mihomo에서 사용하는 이 문법은 지원하지 않음	지원하며 해당 도메인 분류 데이터 필요
TUN 트래픽 처리	구형 Premium의 TUN 기능과 혼동하지 말 것	지원하지만 시스템, 권한, 라우팅에 따라 작동 결과가 달라짐

프로토콜 이름이 같아도 노드를 그대로 복사할 수 있는 것은 아닙니다

예를 들어 WebSocket을 사용하는 노드는 type뿐 아니라 network, 경로, 요청 헤더, TLS 서버 이름도 확인해야 합니다. REALITY 노드에는 공개 키와 짧은 ID 등의 별도 매개변수가 있습니다. 서버 주소와 포트만 복사해서는 대개 연결할 수 없습니다. 구독 변환 도구가 이런 필드를 인식하지 못하면 정보를 그대로 버릴 수 있으며, 결과적으로 ‘노드는 표시되지만 연결은 실패하는’ 상황이 생깁니다.

먼저 구독이 다른 클라이언트의 JSON 설정이 아니라 mihomo에서 읽을 수 있는 설정 형식을 제공하는지 확인하세요.
노드 항목의 type을 확인한 뒤 해당 유형에 필요한 전체 매개변수도 점검하세요.
UDP가 필요한 서비스는 노드와 정책, 네트워크에서 UDP를 허용하는지도 확인해야 합니다. 웹 페이지가 열린다고 해서 UDP까지 사용할 수 있다는 뜻은 아닙니다.

프로토콜이 많다고 해서 자동으로 지연 시간이 줄어드는 것은 아닙니다. 서버 회선, 혼잡도, 패킷 손실, 클라이언트와 서버 사이의 네트워크 상태가 모두 결과에 영향을 줍니다. 필요한 기능에 따라 코어를 선택하고, 노드는 같은 네트워크와 대상, 테스트 방법으로 비교하세요.

규칙 세트의 차이: rule-providers와 GEOSITE는 다릅니다

rule-providers는 외부 규칙의 출처를 선언하고, RULE-SET은 규칙 목록에서 해당 출처를 참조합니다. 반면 GEOSITE는 도메인 분류 데이터베이스의 범주를 기준으로 일치 여부를 판정합니다. 둘 다 기본 설정에 포함되는 규칙 수를 줄여 주지만 데이터 출처, 파일 형식, 업데이트 방식은 서로 다릅니다.

먼저 로컬 규칙 파일로 참조가 제대로 되는지 확인하세요

아래는 mihomo 설정의 일부 예시입니다. 기존 설정에 합쳐 사용해야 하며, 노드 설정 전체로 바로 사용할 수는 없습니다. 설정 디렉터리의 rules/local-direct.yaml에서 일반 규칙을 읽고, 일치하는 연결을 DIRECT로 보냅니다.

rule-providers:
  local-direct:
    type: file
    behavior: classical
    path: ./rules/local-direct.yaml

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

해당 rules/local-direct.yaml 파일의 내용은 다음과 같습니다. 여기서는 도메인 접미사 일치 예시로 example.com을 사용합니다. 실제로는 직접 연결해야 하는 업무 도메인으로 바꾸세요.

payload:
  - DOMAIN-SUFFIX,example.com

behavior: classical 형식의 항목에는 DOMAIN-SUFFIX 같은 규칙 유형이 포함됩니다. behavior: domain으로 바꾸면 해당 도메인 규칙 형식에 맞춰야 하므로 선언만 바꾸고 파일 내용은 그대로 둘 수 없습니다. 바이너리 규칙 형식도 각각 지원 범위가 다르므로 파일 확장자만 바꿔 다른 파서에 넘겨서는 안 됩니다.

GEOSITE는 데이터베이스와 범주를 함께 확인해야 합니다

예를 들어 GEOSITE,cn,DIRECT를 사용하려면 도메인 분류 데이터에 cn 범주가 있어야 합니다. 이는 GEOIP,CN,DIRECT와 다릅니다. 전자는 도메인 분류를, 후자는 IP 지리 데이터를 기준으로 일치 여부를 판정합니다. 해외 CDN을 사용하는 웹사이트에서는 두 규칙이 서로 다른 결과를 낼 수 있습니다. 이는 일치 기준의 차이이며, 반드시 코어 오류를 뜻하지는 않습니다.

원격 규칙이나 지리 데이터를 처음 불러올 때는 인터넷 연결이 필요할 수 있습니다. 아직 프록시가 연결되지 않았는데 해당 리소스를 프록시를 통해 내려받아야 한다면 시작 단계에서 의존성 문제가 생깁니다. 처음 옮길 때는 최소한의 규칙만 유지하고 필요한 로컬 데이터를 준비한 다음 원격 업데이트를 하나씩 다시 설정하세요.

TUN의 차이: 코어 지원은 트래픽 처리의 첫 단계일 뿐입니다

시스템 프록시는 일반적으로 애플리케이션이 프록시 설정을 사용해야 합니다. 반면 TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 전달받습니다. mihomo가 TUN을 지원하더라도 스위치를 켜면 모든 애플리케이션의 트래픽이 반드시 프록시로 들어가는 것은 아닙니다. 시스템 권한, 가상 네트워크 인터페이스 생성, 라우트 설정, 다른 VPN과의 충돌 등이 트래픽 처리를 막을 수 있습니다.

구형 Clash Premium에도 TUN 기능이 있지만, 그렇다고 해당 TUN 설정 전체를 mihomo의 표준 문법으로 간주해서는 안 됩니다. 마이그레이션할 때 stack, auto-route, auto-detect-interface, dns-hijack 등의 필드를 확인하고 현재 시스템의 지원 여부에 맞춰 조정하세요.

세 단계로 TUN이 정상 작동하는지 확인하세요

인터페이스 단계: 시작 로그에서 가상 인터페이스가 정상적으로 생성됐는지 확인하세요. 권한 부족이나 장치 사용 중 오류가 없어야 합니다.
라우팅 단계: 대상 트래픽이 가상 인터페이스로 들어가는지 확인하세요. 여러 네트워크 인터페이스, 다른 VPN, 수동 정적 라우트가 출구 경로를 바꿀 수 있습니다.
연결 단계: 대상 애플리케이션에서 새 연결을 시작한 뒤 연결 패널에서 대상 주소, 일치한 규칙, 최종 정책을 확인하세요.

예를 들어 dns-hijack에서 흔히 사용하는 any:53은 DNS 트래픽 처리 설정이지 ‘암호화된 DNS를 모두 가로채는’ 스위치가 아닙니다. 애플리케이션이 직접 보내는 HTTPS DNS 요청은 HTTPS 연결을 사용하므로 일반적인 53번 포트 질의처럼 처리할 수 없습니다. IPv6 트래픽도 별도로 확인해야 합니다. IPv4 질의 결과만으로 모든 트래픽이 정상적으로 처리된다고 판단하지 마세요.

Linux에서는 root 권한이나 적절한 네트워크 관리 권한이 필요할 수 있습니다. Windows와 macOS의 그래픽 클라이언트는 백그라운드 서비스를 통해 권한 작업을 수행하기도 합니다. 서비스 설치 방법은 클라이언트마다 다르므로 해당 클라이언트 안내를 따르세요. 문제를 확인하려고 가상 네트워크 인터페이스와 라우팅 도구를 여러 개 겹쳐 사용하지 마세요.

DNS와 설정 호환성: 먼저 기존 해석 경로를 유지한 뒤 확장 모드로 전환하세요

mihomo는 Clash 설정에서 흔히 사용하는 dns, nameserver, fallback 등의 개념을 이어받았으며 더 세분화된 DNS 정책도 지원합니다. 하지만 필드 조합에 따라 실제 질의가 전달되는 곳이 달라집니다. 모든 DNS 주소를 같은 서비스로 바꾼다고 호환성이 좋아지는 것은 아닙니다. 오히려 노드 도메인과 서비스 도메인의 해석 경로가 서로 다르다는 점을 놓칠 수 있습니다.

fake-ip와 redir-host를 코어와 함께 바꾸지 마세요

fake-ip는 도메인에 연결할 가상 주소를 할당하며, 흔히 사용하는 주소 대역은 198.18.0.0/16입니다. 이 주소는 도메인과 이후 연결을 연결하는 용도이지 원격 서버의 실제 주소가 아닙니다. redir-host는 일반적으로 실제 DNS 조회 결과를 반환합니다. 두 모드는 로컬 네트워크 기기, 실제 IP에 의존하는 애플리케이션, 기존 DNS 캐시에 영향을 줄 수 있습니다.

구형 환경에서 redir-host를 사용했다면 첫 마이그레이션에서는 이 모드를 유지하세요. 노드와 규칙이 정상적으로 작동하는지 확인한 다음 fake-ip를 따로 테스트하세요. 특정 애플리케이션에서 문제가 생기면 현상에 맞춰 제외 항목을 설정하세요. 애플리케이션 하나에 문제가 생겼다고 TUN을 끄고 DNS와 노드를 동시에 바꾸지는 마세요.

노드 도메인이 해석되지 않음: 노드 연결 전에 사용하는 DNS 해석 경로를 확인하고, 필요한 경우 proxy-server-nameserver 등 관련 설정을 점검하세요.
도메인 규칙이 작동하지 않는 것처럼 보임: 연결에 도메인 정보가 유지되는지, DNS가 예상한 경로를 거치는지 확인하세요.
수정 후에도 예전 설정처럼 작동함: 클라이언트가 병합, 오버라이드 또는 구독 업데이트를 통해 DNS 섹션을 다시 작성하는지 확인하세요.

fallback을 ‘기본 DNS가 완전히 실패한 뒤에만 보조 DNS를 시작하는 기능’으로 단순하게 이해해서는 안 됩니다. 필터 조건과 함께 결과를 선택하는 방식에 영향을 줍니다. 마이그레이션 문제를 해결할 때는 먼저 현재 설정과 로그를 확인한 다음 이 부분을 바꿀지 판단하세요.

마이그레이션 단계: 문법 확인부터 실제 연결 테스트까지

기존 코어와 설정, 클라이언트 오버라이드 내용을 보관하고 별도의 테스트 디렉터리를 만드세요. 아래에서는 독립 실행 파일을 사용합니다. mihomo-test는 이번 테스트용 디렉터리 이름일 뿐입니다. 명령에 지정하는 파일과 작업 디렉터리는 현재 터미널 위치를 기준으로 합니다.

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

-t는 설정 테스트, -d는 작업 디렉터리 지정, -f는 설정 파일 지정을 의미합니다. 문법 검사를 통과했다는 것은 설정 검사 단계에서 치명적인 오류가 없었다는 뜻일 뿐, 서버에 연결할 수 있거나 시스템 프록시가 설정됐거나 TUN 라우트가 작동한다는 의미는 아닙니다.

첫 단계에서는 로컬 프록시 포트만 확인하세요

테스트 설정에는 다음과 같은 기본 항목을 사용할 수 있습니다. 여기서 7890은 명시적으로 지정한 혼합 프록시 포트이며, 모든 클라이언트가 이 포트를 사용하는 것은 아닙니다. 유효한 노드와 정책 그룹이 포함된 설정에 이 항목을 합친 뒤 테스트를 시작하세요.

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

기존 클라이언트도 7890을 사용한다면 구형 코어를 먼저 종료하거나 테스트 설정에 사용 중이지 않은 포트를 지정하세요. 기존 클라이언트 창만 닫아서는 안 됩니다. 백그라운드 서비스가 계속 실행 중일 수 있습니다. 이 단계에서는 TUN을 켜지 말고 로컬 네트워크 공유도 설정하지 마세요.

설정 파싱: 알 수 없는 노드 유형, 잘못된 규칙, 누락된 정책 그룹, 규칙 파일 경로 오류를 해결하세요.
코어 시작: 포트가 정상적으로 열렸는지, ‘주소가 이미 사용 중’과 같은 시작 오류가 없는지 확인하세요.
프록시를 지정해 테스트: 터미널에서 아래 명령을 실행하고 요청 성공 여부와 연결 패널의 기록을 확인하세요.
분기 규칙 복원: 규칙 제공자와 지리 규칙을 단계별로 추가하고 실제로 일치하는 결과를 확인하세요.
마지막으로 시스템 트래픽 처리: 먼저 시스템 프록시를 테스트한 다음 TUN을 별도로 켜세요. 변수를 여러 개 동시에 추가하지 마세요.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

이 명령은 로컬 프록시 경로를 통한 요청을 확인합니다. 대상 도메인이 DIRECT와 일치하면 직접 연결로도 성공할 수 있으므로 연결 패널에서 정책 경로를 확인해야 합니다. 테스트에 성공해도 모든 애플리케이션이 원격 노드를 거치거나 회선의 최대 속도에 도달했다는 뜻은 아닙니다.

자주 발생하는 마이그레이션 문제와 선택 기준

증상	우선 확인할 항목	다음 조치
unknown proxy type	실행 중인 코어, 노드 유형 표기	클라이언트가 여전히 구형 바이너리를 실행하는지 확인
규칙 제공자를 찾을 수 없음	RULE-SET 참조 이름, 파일 경로, 다운로드 로그	먼저 작은 로컬 규칙 파일로 파싱 여부 확인
설정 테스트는 성공했지만 인터넷에 연결되지 않음	리스닝 포트, 노드 연결 가능 여부, 정책 선택	시스템 설정을 배제할 수 있도록 프록시를 명시해 요청
TUN을 켠 뒤 일부 애플리케이션에서 문제가 발생함	라우팅, DNS, IPv6, 다른 VPN	시스템 프록시 기준 상태로 돌아간 뒤 트래픽 처리를 항목별로 다시 설정
구독 업데이트 후 설정이 사라짐	설정 출처, 클라이언트 병합 및 오버라이드 순서	클라이언트가 지원하는 영구 오버라이드 위치에 사용자 설정 저장

VLESS, Hysteria2, TUIC, GEOSITE 또는 더 완성도 높은 최신 분기 설정이 필요하다면 mihomo가 더 적합한 비교 대상입니다. 기본적인 프록시 기능만 필요하다면 코어 기능표만으로 결정하지 말고 그래픽 클라이언트의 유지 관리 상태, 플랫폼 통합, 설정 관리 방식을 함께 비교하세요.

Clash 리뷰 허브는 클라이언트 선택과 설정 정보를 제공하며 클라이언트 개발사는 아닙니다. 실제 마이그레이션에서는 설치된 코어의 문서, 시작 로그, 연결 기록을 기준으로 판단하세요. ‘설정 불러오기’, ‘요청 성공’, ‘규칙 일치’, ‘시스템 트래픽 처리’를 네 가지 별도 점검 항목으로 나누면 모든 설정을 한꺼번에 바꾸는 것보다 문제를 더 명확하게 찾을 수 있습니다.

기본 개념은 용어 빠른 검색에서 확인할 수 있습니다. 규칙과 프록시 모드 점검 방법은 사용 설명서의 규칙 안내를 참고하세요.