Clash 원본 코어·Clash Meta·mihomo 기능 차이와 설정 호환성 비교

코어 계보: 원본 Clash, Premium, Meta 분기

Clash 클라이언트를 고를 때는 화면에 표시되는 이름과 코어 이름을 따로 확인해야 합니다. 클라이언트는 구독 관리, 시스템 프록시 전환, 설정 병합, 로그 표시를 담당하고, 코어는 프록시 연결을 만들고 규칙을 적용하며 DNS를 처리합니다. 같은 클라이언트라도 내장 코어가 업데이트될 수 있고, 코어를 직접 바꿀 수 있는 경우도 있습니다. 프로그램 이름만으로 특정 VLESS 노드나 TUN 설정의 사용 가능 여부를 판단할 수는 없습니다.

원본 Clash는 오픈소스 코어와 Clash Premium을 구분해야 합니다. Premium은 원 프로젝트의 별도 배포 계열로, TUN과 규칙 세트 등의 확장 기능을 제공한 적이 있습니다. 따라서 Premium 기능을 모두 원본 오픈소스 코어의 기능으로 보면 안 됩니다. 원 프로젝트는 2023년에 유지보수가 중단됐습니다. 기존 클라이언트와 바이너리는 계속 실행될 수 있지만, 새 설정의 기능을 판단하는 기준으로 삼기에는 적절하지 않습니다.

Clash Meta는 Clash에서 파생된 분기이며, 이후 mihomo로 이름이 바뀌었습니다. 따라서 Meta와 mihomo는 서로 호환되지 않는 별개 제품이라기보다 같은 기술 계열이 시기에 따라 사용한 이름입니다. 예전 튜토리얼의 ‘Meta 코어’나 구독의 ‘Clash Meta 형식’은 대체로 이 확장 계열을 가리킵니다. 실제 기능은 사용 중인 배포 버전에 따라 달라집니다.

기능 비교: 프로토콜·규칙·TUN·DNS

아래 표는 기능의 범위를 비교한 것으로, 모든 과거 버전의 기능을 빠짐없이 나열한 목록은 아닙니다. ‘지원’ 여부는 서버 설정, 클라이언트 패키징 방식, 운영체제 권한도 함께 충족해야 합니다. 특히 현재 mihomo의 기능을 초기 Meta 버전에도 있다고 간주해서는 안 됩니다.

기능	원본 오픈소스 Clash	Clash Premium	Meta / mihomo 계열
주요 프록시 프로토콜	SS, VMess, Trojan, SOCKS, HTTP 등을 지원합니다. 세부 설정은 버전에 따라 다릅니다.	원 프로젝트의 지원 범위를 기반으로 합니다.	VLESS, Hysteria2, TUIC 등을 추가 지원합니다. 버전과 설정 항목을 확인해야 합니다.
기본 트래픽 분기	도메인, IP 대역, GEOIP 등 일반적인 규칙을 지원합니다.	기본 규칙과 확장 기능을 지원합니다.	주요 규칙을 유지하면서 GEOSITE, 논리 규칙 등의 기능을 확장합니다.
규칙 세트	Premium의 RULE-SET 설정을 지원한다고 단정할 수 없습니다.	rule-providers와 RULE-SET을 지원합니다.	규칙 세트를 지원합니다. 설정 형식과 동작이 구성과 맞는지 확인해야 합니다.
TUN 모드	Premium과 동등한 내장 TUN 기능은 제공하지 않습니다.	TUN을 지원하지만 플랫폼과 버전에 따라 차이가 있습니다.	TUN을 지원합니다. 네트워크 스택, 라우팅, 권한을 별도로 확인해야 합니다.
DNS	내장 DNS와 Fake-IP 등 기본 기능을 지원합니다.	원 프로젝트의 DNS 기능에 확장 기능을 더해 사용할 수 있습니다.	DNS 조회 정책과 연결 조회 제어 기능을 확장합니다. 설정 항목은 버전에 따라 발전해 왔습니다.
유지보수 상태	과거 프로젝트이며 유지보수가 중단됐습니다.	과거 배포 계열이며 유지보수가 중단됐습니다.	mihomo 프로젝트의 최신 배포 기록을 기준으로 확인하세요.

프로토콜 지원 여부는 구독 파일을 열 수 있는지와 별개입니다.

YAML 파일을 읽을 수 있다는 것은 기본 형식이 유효하다는 뜻일 뿐입니다. 구독에 type: vless가 들어 있는데 VLESS를 지원하지 않는 구형 코어로 처리하면 노드 파싱이나 설정 전체 로드에 실패할 수 있습니다. Reality는 관련 프로토콜에서 사용하는 전송 보안 설정이지, VLESS나 Trojan과 나란히 놓이는 노드 유형이 아닙니다. 이전할 때는 type, network, TLS 설정과 해당 전송 옵션을 함께 확인하세요.

구독 서비스가 ‘Clash’를 표기한다고 해서 원본 Clash와 호환된다는 뜻은 아닙니다. 일부 서비스는 YAML 출력 전반을 가리키는 이름으로 이 표현을 사용하며, 실제 파일에는 mihomo 확장 필드가 포함될 수 있습니다. 서비스에서 Meta 또는 mihomo 출력 형식을 명시적으로 제공한다면 대상 코어에 맞는 형식을 선택하세요. 변환 도구는 지원되는 데이터 구조만 변환할 수 있으며, 구형 코어에 없는 프로토콜 구현을 추가해 주지는 않습니다.

설정 호환성: 유지할 구조와 확인할 항목

일반적으로 proxies, proxy-groups, rules 구조는 그대로 사용할 수 있습니다. 기본적인 DOMAIN-SUFFIX, IP-CIDR, MATCH 규칙도 이름이 바뀌었다는 이유만으로 모두 다시 작성할 필요는 없습니다. 이전할 때는 확장 필드가 지원되는지, 클라이언트가 최종적으로 어떤 설정을 생성하는지 확인하는 것이 중요합니다.

항목별 확인 목록

로컬 포트: port, socks-port, mixed-port를 확인하세요. 예를 들어 mixed-port: 7890을 사용한다면 시스템 프록시와 수동 설정이 필요한 앱 모두 실제로 수신 대기 중인 포트를 가리켜야 합니다. 기존 환경의 7897을 그대로 사용하면 안 됩니다.
제어 인터페이스: external-controller는 관리 API이며 앱이 사용하는 프록시 주소가 아닙니다. 127.0.0.1:9090을 사용한다면 브라우저 프록시 포트로 9090을 입력하지 마세요. 로컬에서만 관리한다면 루프백 주소를 유지하고 접근 키를 설정하세요.
규칙 참조: RULE-SET에서 참조하는 이름은 rule-providers의 키와 일치해야 합니다. GEOSITE에는 해당 데이터 파일도 필요합니다. 데이터 다운로드 실패와 규칙 구문 오류는 따로 확인해야 합니다.
규칙 대상: 각 규칙이 참조하는 정책 그룹이 실제로 존재해야 합니다. ‘자동 선택’을 ‘지연 시간 우선’으로 바꿨다면 규칙과 다른 그룹에 있는 참조도 함께 수정해야 합니다.
스크립트 설정: Premium의 script 트래픽 분기 기능을 그대로 가져오지 마세요. 클라이언트의 JavaScript 오버라이드는 설정을 생성할 때 실행되며, 코어가 연결을 처리하는 동안 실행되는 스크립트와는 다른 방식입니다.
클라이언트 전용 설정: 구형 클라이언트의 설정 병합, 설정 파일 확장, 시작 옵션은 mihomo 기본 YAML과 다릅니다. 이전할 것은 이러한 설정이 만들어 내는 실제 결과이지, 기존 파일 전체를 그대로 복사하는 것이 아닙니다.

독립 설정으로 포트와 규칙부터 확인

아래는 로컬 진단용 기본 설정이며, 실제로 사용할 수 있는 프록시 노드는 포함하지 않습니다. 코어가 시작되는지, 7890 포트에서 수신 대기하는지, 기본 규칙을 불러올 수 있는지 확인하는 용도입니다. MATCH,DIRECT는 규칙에 일치하지 않는 트래픽을 직접 연결하므로, 완성된 프록시 구성으로 사용해서는 안 됩니다.

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

proxies: []
proxy-groups: []

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

먼저 이 기본 설정을 테스트한 뒤 실제 노드, 정책 그룹, 규칙 세트를 나눠 추가하세요. 이렇게 하면 수천 개 규칙이 포함된 구독 파일에서 여러 변수를 한꺼번에 확인하는 대신 새로 추가한 항목에서 발생한 시작 오류를 찾을 수 있습니다.

TUN 이전: 권한·라우팅·DNS 가로채기를 각각 확인

시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 사용됩니다. TUN은 가상 네트워크 어댑터를 통해 트래픽을 처리합니다. 코어를 바꾼 뒤 TUN 스위치가 켜져 있다고 해서 가상 어댑터, 라우팅, DNS 가로채기가 모두 정상적으로 작동한다는 뜻은 아닙니다. Windows에서는 서비스 모드나 관리자 권한이 필요한 경우가 많고, Linux에서는 네트워크 관리 권한이 필요합니다. macOS도 별도 권한을 허용해야 합니다. 구체적인 설정 위치는 클라이언트 구현에 따라 다릅니다.

예전 튜토리얼의 TUN 기본값을 그대로 가져오지 마세요. stack, 자동 라우팅, 인터페이스 감지의 적합성은 플랫폼, 코어 버전, 다른 네트워크 소프트웨어의 영향을 받습니다. 아래 mihomo 설정은 자주 쓰이는 항목만 보여 줍니다. 처음 테스트할 때는 enable: false로 두고, 시스템 프록시 경로를 확인한 뒤 활성화하세요.

tun:
  enable: false
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

먼저 권한을 확인하세요: 로그에 가상 어댑터 생성이나 경로 추가 실패가 표시되면 노드를 바꾸기보다 서비스와 권한부터 확인하세요.
그다음 출구를 확인하세요: 다른 VPN, 가상 머신 또는 컨테이너 네트워크를 함께 사용하면 자동 인터페이스 감지가 잘못된 출구를 선택할 수 있습니다. 다른 트래픽 처리 도구를 잠시 끈 뒤 결과를 비교하세요.
마지막으로 DNS를 확인하세요: any:53은 일반적인 53번 포트의 DNS 트래픽을 대상으로 하며, 브라우저에 내장된 HTTPS DNS를 자동으로 복호화하지는 않습니다. HTTPS DNS는 일반 HTTPS 연결로 처리된 뒤 규칙에 따라 출구가 결정될 수 있습니다.

TUN을 사용해도 노드에 없는 UDP 기능이 추가되는 것은 아닙니다. 게임이나 음성 앱에서 여전히 문제가 발생한다면 TUN 스택만 반복해서 바꾸지 말고 노드 프로토콜, 서버의 UDP 지원 여부, 정책 그룹의 경로 선택, 로컬 방화벽을 각각 확인하세요.

DNS와 Fake-IP: 필드가 호환돼도 DNS 조회 경로는 다를 수 있습니다.

원본 Clash에도 Fake-IP 기능이 있으므로 Fake-IP 자체를 mihomo만의 기능으로 보면 안 됩니다. 먼저 가상 주소를 반환한 다음 코어가 매핑 정보를 이용해 도메인을 복원하고 연결을 처리하는 방식입니다. 이전 후 DNS 요청이 코어에 전달되지 않거나 앱이 이전 결과를 캐시하고 있다면 YAML의 enhanced-mode가 바뀌지 않았더라도 실제 동작은 달라질 수 있습니다.

DNS 필드는 역할에 따라 확인하세요

nameserver는 일반적인 상위 DNS 서버를 지정합니다. 암호화 DNS 서버 주소를 도메인으로 입력한다면, 그 서버 주소를 처음 조회할 때 사용할 DNS 경로도 고려해야 합니다.
nameserver-policy는 도메인 조건에 따라 DNS 서버를 선택합니다. 프록시 트래픽 분기 규칙이 아니므로 rules를 그대로 대체할 수 없습니다.
fake-ip-filter는 어떤 도메인에 Fake-IP를 반환하지 않을지 지정합니다. 호환성 문제가 있는 도메인만 정확히 예외로 추가하고, 넓은 범위의 와일드카드로 전체 구성을 실제 IP 조회 방식으로 되돌리지 마세요.
fallback과 fallback-filter는 별도의 DNS 서버 선택 방식이며 모든 설정에서 반드시 사용할 필요는 없습니다. 기존 설정에 이 필드가 있다고 해서 이전할 때 지역 필터 조건까지 모두 복사해야 하는 것은 아닙니다.

아래는 Fake-IP와 도메인별 DNS 정책을 구성하는 최소 예시입니다. example.com은 문서용 예시 도메인입니다. 바꿔 넣을 때는 별도의 DNS 조회가 실제로 필요한 서비스 도메인을 사용하세요. 1053은 로컬 DNS 수신 포트이며 시스템 기본 포트인 53이 아닙니다. 리스너만 실행해도 시스템 DNS 설정이 자동으로 바뀌지는 않습니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
  nameserver-policy:
    '+.example.com':
      - 1.1.1.1
  fake-ip-filter:
    - '*.lan'

테스트 환경에 따라 nslookup example.com 127.0.0.1 -port=1053과 같은 명령을 실행하세요. 운영체제마다 인수 순서와 구현이 다릅니다. dig를 지원하는 환경이라면 아래 조회 명령을 바로 사용할 수 있습니다. Fake-IP 응답은 설정한 가상 주소 대역에 있어야 하지만, 실제 주소가 반환된 것은 필터 항목 때문일 수도 있습니다. 주소 하나만으로 DNS 유출 여부를 판단하지 마세요.

dig @127.0.0.1 -p 1053 example.com A

코어 로그에 DNS 조회가 들어오는지 확인하고, 시스템 DNS·브라우저 보안 DNS·연결 출구도 함께 비교하세요. 온라인 검사 페이지에 표시된 DNS 서버의 위치는 참고 자료 중 하나일 뿐입니다. DNS 서버와 프록시 출구의 위치가 다르다는 사실만으로 요청이 의도한 경로를 벗어났다고 단정할 수 없습니다.

이전 순서: 오프라인 테스트, 단계별 복구, 롤백

이전할 때 클라이언트, 구독 형식, DNS 구성, 규칙 출처를 한꺼번에 바꿀 필요는 없습니다. 같은 노드와 테스트 대상을 유지한 채 최소한의 변경부터 적용하고 확장 기능을 차례로 복구해야 결과를 제대로 비교할 수 있습니다.

현재 실행 상태를 백업하세요. 구독 원본 파일, 클라이언트 오버라이드, 현재 유효 설정, 코어 버전 출력을 보관하세요. 7890과 같은 로컬 프록시 포트와 시스템 프록시, TUN, LAN 접속의 활성화 여부도 기록해 두세요. 노드 비밀번호와 구독 인증 정보가 포함된 파일은 신뢰할 수 있는 위치에만 보관하세요.
대상 바이너리를 확인하세요. 버전 명령을 실행해 실제 출력 결과를 기록하세요. 설치 패키지 이름만으로 판단하면 안 됩니다. 데스크톱 클라이언트에 포함된 코어는 별도로 다운로드한 버전과 다를 수 있습니다.
설정 테스트를 실행하세요. 먼저 구문과 참조 항목을 확인하세요. 테스트를 통과한 뒤 실행합니다. 정책 그룹이 없다는 오류가 나오면 DNS를 동시에 바꾸지 말고 그룹 이름 참조부터 수정하세요.
시스템 프록시 경로를 확인하세요. TUN을 끄고 정상 작동이 확인된 실제 노드 하나를 불러오세요. 명시적 프록시 요청으로 수신 포트, 핸드셰이크, 출구를 확인한 다음 시스템 프록시 스위치를 테스트하세요.
규칙과 DNS를 복구하세요. 규칙 세트를 하나씩 추가하고 로그에 표시되는 일치 규칙과 대상 그룹을 확인하세요. 이어서 DNS 조회 경로를 점검한 뒤 마지막으로 TUN을 활성화하세요.
롤백할 수 있는 상태를 유지하세요. 새 설정에 문제가 생기면 먼저 새 클라이언트의 TUN과 시스템 프록시를 끈 다음 기존 환경으로 복구하세요. 두 클라이언트가 같은 포트나 가상 네트워크 경로를 동시에 사용하게 두지 마세요.

명령줄 검증 예시

바이너리 이름이 mihomo이고 현재 디렉터리의 config.yaml을 설정 파일로 사용하는 경우입니다. Windows PowerShell에서는 로컬 실행 파일을 보통 .\mihomo.exe로 지정해야 합니다. 데스크톱 클라이언트를 사용한다면 구독 다운로드 파일만 테스트하지 말고 클라이언트가 실제로 불러온 설정을 대상으로 확인하세요.

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

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

-t 검사를 통과해도 원격 노드에 연결할 수 있다는 뜻은 아닙니다. 위 요청에는 장애 발생 시 무한 대기를 막기 위해 연결 제한 시간 10초와 전체 제한 시간 20초를 설정했습니다. 속도 측정 기준이 아닙니다. 앞에서 만든 직접 연결 진단 설정을 사용 중이라면 이 요청은 로컬 프록시 진입점만 확인하며 원격 노드를 통해 트래픽이 전달되는지는 검증하지 않습니다.

코어 선택 결론과 장애 진단 범위

VLESS, Hysteria2, TUIC 또는 최신 규칙 기능이 필요하다면 원본 코어에 새 필드를 반복해서 적용하기보다 해당 mihomo 버전의 지원 여부를 먼저 확인하세요. 기존 환경을 유지해야 한다면 설정을 원본 코어가 실제로 지원하는 범위로 제한해 구독 업데이트 후 노드를 파싱하지 못하는 상황을 피해야 합니다.

Clash Meta에서 mihomo로 이전할 때는 보통 버전 차이와 클라이언트의 설정 생성 방식을 중점적으로 확인합니다. 원본 Clash나 Premium에서 mihomo로 옮긴다면 스크립트, 규칙 세트, DNS, TUN의 구현 차이도 점검해야 합니다. 모든 필드를 일괄 교체하는 범용 규칙은 없습니다. 가장 확실한 방법은 버전을 확인하고, 실제 적용된 설정을 점검한 뒤 연결을 단계별로 테스트하는 것입니다.

클라이언트를 고를 때는 클라이언트 플랫폼 및 코어 비교를 확인하세요. 규칙 문법과 설정 구조를 알아보려면 프로토콜 안내서를 참고하세요. 출처를 알 수 없는 오버라이드를 여러 개 겹쳐 쓰기보다 각 필드의 용도를 설명할 수 있는 설정 하나를 유지하는 편이 관리하기 쉽습니다.