Clash 오리지널·Meta·mihomo 코어 차이와 설정 호환성 비교

클라이언트 다운로드 및 구독 가져오기

처음 사용하는 경우 Clash 클라이언트 다운로드 페이지에서 운영체제와 프로세서 아키텍처에 맞는 클라이언트를 선택하세요. 설치한 뒤 클라이언트의 ‘설정’ 또는 ‘Profiles’ 페이지에서 서비스 제공업체의 구독 URL을 가져오고, 방금 가져온 설정을 선택한 다음 프록시 그룹에서 노드를 고르면 됩니다. 구독 URL에는 보통 접속 정보가 포함되므로 공개 댓글이나 문의용 스크린샷에 전체 주소를 올리지 마세요.

어떤 코어를 써야 하는지 판단하려면 먼저 세 가지를 구분해야 합니다. 클라이언트는 창, 트레이, 구독 관리, 시스템 설정 기능을 제공하고, 코어는 설정을 파싱해 프록시 연결을 만들고 규칙을 적용합니다. 구독에는 노드와 함께 프록시 그룹, 규칙, DNS 설정이 포함될 수 있습니다. 클라이언트에서 구독을 정상적으로 가져왔다고 해서 코어가 구독에 포함된 모든 프로토콜을 지원하는 것은 아닙니다.

가져온 뒤 먼저 확인할 사항

1. 구독 다운로드가 완료됐는지, 설치 시 포함된 예제 설정이 아니라 현재 해당 설정이 활성화됐는지 확인하세요.
2. 시작 로그에서 설정 파싱 오류, 미지원 노드 유형, 포트 충돌이 없는지 확인하세요.
3. 데스크톱에서는 먼저 시스템 프록시를 사용해 브라우저 연결을 테스트하세요. Android에서는 보통 VPN 연결 권한을 허용해야 합니다.
4. 시스템 프록시를 따르지 않는 앱의 트래픽까지 처리해야 한다면 TUN을 별도로 설정하세요. 한꺼번에 여러 설정을 바꾸지 않는 편이 좋습니다.

Clash 오리지널·Meta·mihomo의 발전 과정

Clash 오리지널과 Premium 포크

Clash 오리지널은 보통 Dreamacro 프로젝트와 해당 코어를 가리킵니다. 이 프로젝트는 proxies, proxy-groups, rules와 같은 YAML 설정 구조를 널리 정착시켰습니다. 오리지널 생태계에는 Premium 코어도 있으므로 오픈소스 오리지널과 Premium의 기능을 한데 묶어 비교하면 안 됩니다. Premium은 TUN, 규칙 집합, 스크립트 등의 기능을 확장해 제공했으며, 구체적인 지원 범위는 사용한 빌드에 따라 다릅니다.

오리지널 프로젝트는 2023년 11월에 유지 관리가 종료됐습니다. 기존 클라이언트와 코어는 계속 실행될 수 있지만, 새로운 노드 프로토콜이나 운영체제 변경, 신규 설정 필드가 등장해도 같은 구버전을 다시 다운로드한다고 지원 기능이 추가되지는 않습니다. 기존 설정은 마이그레이션 참고용으로 활용하고, 새로 구축할 때는 계속 유지 관리되고 구독 요구사항에 맞는 코어를 우선 고려하세요.

Clash Meta에서 mihomo로

Clash Meta는 Clash 생태계를 바탕으로 발전한 포크로, 프록시 프로토콜, DNS, 규칙 매칭, 투명 프록시 등의 기능을 확장했습니다. 이후 프로젝트 이름이 mihomo로 변경됐습니다. 따라서 구독 업체가 사용하는 ‘Meta 형식’, 가이드에 나오는 ‘Clash.Meta’, 클라이언트에 표시되는 ‘mihomo 코어’는 대개 같은 프로젝트의 발전 과정에 속합니다.

이름이 이어진다고 해서 모든 시기의 버전이 완전히 같은 것은 아닙니다. 이전 Meta 빌드에는 나중에 추가된 프로토콜이나 설정 옵션이 없을 수 있고, 최신 mihomo에서는 필드 동작이 달라졌을 수도 있습니다. 마이그레이션 여부는 이름에 Meta가 포함됐는지가 아니라 실제 버전과 실행 결과를 기준으로 판단해야 합니다.

노드 프로토콜과 구독 형식 호환성

구독에 mihomo가 필요한지 확인하는 가장 쉬운 방법은 노드의 type을 살펴보는 것입니다. 설정 파일 전체를 공개하지 말고 필요한 필드만 로컬에서 확인하세요. Shadowsocks, VMess, Trojan 같은 일반적인 유형은 Clash 생태계에서 오래전부터 지원됐지만, 같은 프로토콜 안에서도 암호화 방식, 전송 방식, 확장 매개변수가 다를 수 있습니다.

구독 URL과 노드 공유 링크

전체 Clash YAML에는 보통 프록시 그룹과 규칙이 포함됩니다. 프록시 제공자 파일에는 일반적으로 노드 목록만 들어 있습니다. Base64로 인코딩된 노드 목록이나 단일 ss://, vmess:// 공유 링크는 또 다른 입력 형식입니다. 이런 형식을 클라이언트가 자동으로 인식하거나 변환할 수 있는지는 클라이언트 기능에 달려 있습니다. 모든 코어가 임의의 링크를 완전한 설정으로 바로 읽을 수 있다고 가정하면 안 됩니다.

서비스 제공업체 페이지에서 구독 형식을 선택할 때 ‘Clash Meta’ 또는 ‘mihomo’ 항목이 있고 구독에 VLESS, Reality, Hysteria 2 등의 유형이 포함돼 있다면 해당 형식을 우선 사용하세요. 구형 Clash 형식을 선택하면 변환 과정에서 호환되지 않는 노드가 제거될 수 있습니다. 가져온 뒤 노드 수가 크게 줄었다면 계정의 트래픽이 소진됐다고 단정하지 말고 먼저 출력 형식을 비교하세요.

규칙·DNS·TUN 필드 차이

규칙 순서와 정책 이름

DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP, MATCH는 일반적으로 사용되는 규칙 유형입니다. 규칙은 위에서 아래로 적용되며 먼저 일치한 규칙이 트래픽의 경로를 결정합니다. 마지막에 MATCH를 두면 기본 정책을 명확하게 지정할 수 있습니다. 마이그레이션할 때는 규칙이 참조하는 프록시 그룹이 존재하는지도 확인하세요. 그룹 이름의 공백과 대소문자도 일치해야 합니다.

mihomo는 GEOSITE, 논리 규칙처럼 더 다양한 매칭 기능을 제공하며, 플랫폼과 실행 권한, 기능 설정에 따라 프로세스 매칭도 사용할 수 있습니다. 이런 규칙이 포함된 구독을 구형 코어에서 사용하면 파싱 오류가 발생할 수 있습니다. 규칙 이름을 인식하더라도 필요한 지리 데이터나 원격 규칙 파일을 불러오지 못하면 최종 결과에 영향을 줍니다.

규칙 제공자와 이전 스크립트

rule-providers는 규칙 집합을 불러오고, RULE-SET은 해당 집합을 참조합니다. 호환성을 확인할 때는 최상위 필드가 있는지만 보지 말고 제공자의 behavior, 파일 형식, 경로도 살펴보세요. Premium의 구형 script 설정을 mihomo에서 그대로 쓸 수 있는 동등한 기능으로 간주하면 안 됩니다. 이런 설정을 마이그레이션하려면 지원되는 규칙과 정책 그룹을 이용해 다시 구성해야 합니다.

DNS 설정은 서버 주소 하나로 끝나지 않습니다.

DNS 설정에는 수신 주소, 상위 DNS 서버, enhanced-mode, fake-ip-filter 등이 포함됩니다. mihomo는 DNS 정책과 트래픽 스니핑 관련 기능도 제공합니다. 구형 설정의 필드를 받아들인다고 해서 기본 동작까지 이전 코어와 완전히 같다는 뜻은 아닙니다. 마이그레이션한 뒤 도메인 조회, 규칙 적용, 실제 연결을 각각 확인하세요.

예를 들어 fake-ip를 사용하면 앱에 198.18.0.0/16 범위의 가상 주소가 전달될 수 있습니다. 이는 서버의 실제 IP가 아닙니다. 이후 주소 매핑을 처리하려면 앱의 트래픽을 같은 코어로 전달해야 합니다. DNS 설정만 복사하고 트래픽을 넘기는 경로를 제대로 구성하지 않으면 ‘도메인은 조회되는데 웹페이지가 열리지 않는’ 문제가 생길 수 있습니다.

TUN과 시스템 프록시

시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에서 주로 사용됩니다. TUN은 가상 네트워크 인터페이스로 트래픽을 전달하며, 보통 관리자 권한이나 서비스 모드 또는 해당 운영체제의 기능이 필요합니다. Windows, macOS, Linux는 라우팅 설정 방식이 다르고, Android 클라이언트는 일반적으로 VpnService를 이용해 VPN 인터페이스를 구성합니다. 클라이언트에 TUN 스위치가 있다고 해서 모든 플랫폼에서 구현 방식까지 같은 것은 아닙니다.

tun.stack, auto-route, dns-hijack 등의 필드는 대상 버전과 플랫폼을 함께 고려해야 합니다. 처음 마이그레이션할 때는 TUN을 끄고 시스템 프록시로 노드 연결을 확인한 다음 라우팅과 DNS 가로채기를 하나씩 활성화하세요. 이렇게 하면 프로토콜 비호환, 권한 부족, 라우팅 충돌을 구분하기 쉽습니다.

코어 버전 확인 및 설정 테스트

GUI 클라이언트에서는 먼저 ‘정보’ 페이지의 코어 정보와 시작 로그의 버전 줄을 확인하세요. 메뉴 이름은 클라이언트마다 다를 수 있습니다. 문제를 보고할 때 클라이언트 자체 버전 번호를 코어 버전으로 적지 마세요. 명령줄로 설치했다면 다음 두 명령을 사용할 수 있습니다. 첫 번째는 버전을 표시하고 두 번째는 지정한 설정을 검사합니다. 두 명령 모두 실제 실행할 바이너리를 호출해야 합니다.

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

시스템의 검색 경로에 mihomo가 등록되지 않았다면 Linux나 macOS에서는 현재 디렉터리에서 ./mihomo를 실행할 수 있습니다. Windows PowerShell에서는 .\mihomo.exe를 사용하세요. 컴퓨터에 복사본이 여러 개 있다면 클라이언트의 실행 경로도 확인해야 합니다. 터미널에서는 새 코어를 테스트하면서 GUI 클라이언트는 계속 구형 코어를 사용하는 상황을 피할 수 있습니다.

최소 설정 및 포트 확인

아래 YAML은 설정 구조와 로컬 수신 상태를 확인하기 위한 예시입니다. 구독 노드는 포함하지 않으며 원격 프록시 연결을 제공하지도 않습니다. 혼합 포트는 7890으로 설정해 HTTP와 SOCKS5 요청을 모두 받습니다. allow-lan: false로 접속 범위를 이 컴퓨터로 제한합니다. 별도의 테스트 파일로 저장하고 현재 사용 중인 구독 설정을 덮어쓰지 마세요.

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

proxy-groups:
  - name: 테스트 출구
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,테스트 출구
  - MATCH,DIRECT

설정 검사가 통과한 뒤 코어를 실행하고 다음 명령으로 HTTP 프록시 수신 경로를 확인할 수 있습니다. 예시는 기본적으로 DIRECT를 선택하므로 성공해도 로컬 프록시 진입점과 직접 연결이 작동한다는 뜻일 뿐, 구독 노드가 작동한다는 의미는 아닙니다. 로그에 포트 사용 중 오류가 표시되면 다른 클라이언트를 종료하거나 테스트 포트와 요청 포트를 같은 값으로 변경하세요.

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

설정 검사를 통과해도 네트워크 연결이 성공한다고 보장할 수는 없습니다. 노드 비밀번호, 원격 인증서, 구독의 남은 트래픽, 통신사의 UDP 정책은 확인되지 않습니다. 실제 구독으로 각 노드를 테스트하고 연결 로그도 확인해야 합니다. 제어 인터페이스는 보통 127.0.0.1:9090에서 사용하며, 프록시 포트와는 다릅니다. 제어 인터페이스를 활성화할 때는 접근 키를 설정하고 공용 인터넷에 직접 노출되지 않게 하세요.

기존 설정 마이그레이션과 자주 발생하는 오류

마이그레이션 순서

1. 기존 설정을 보관하세요. 로컬 오버라이드, 규칙 파일, 프록시 그룹 선택을 별도로 백업하고 유일한 사본을 직접 수정하지 마세요.
2. 호환되는 구독을 다시 받으세요. 서비스 제공업체의 Meta 또는 mihomo 형식을 우선 사용하고, 새 설정과 기존 설정의 노드 수 및 프로토콜 유형을 비교하세요.
3. 기본 연결을 테스트하세요. 먼저 시스템 프록시를 사용하고 규칙 모드를 유지한 채 실제 노드 하나 이상으로 대상 사이트에 접속할 수 있는지 확인하세요.
4. 사용자 설정을 합치세요. 규칙 제공자, DNS, 스니핑 설정을 하나씩 추가하고 변경할 때마다 시작 로그를 확인하세요.
5. TUN과 자동 시작을 다시 설정하세요. 기본 연결이 안정된 뒤 가상 네트워크 카드와 백그라운드 서비스를 활성화하고, 기기를 재시작해 설정이 유지되는지 확인하세요.

오류 유형별 점검

코어 선택 결론 및 자주 묻는 질문

새로 설치할 때는 현재 구독을 지원하고 지속적으로 관리되는 클라이언트와 코어를 우선 선택하세요. VLESS, Reality, Hysteria 2 또는 최신 트래픽 분류 기능이 필요하다면 요구사항에 맞는 버전의 mihomo를 선택하는 것이 일반적입니다. 이전 환경을 당장 마이그레이션할 수 없다면 현재 필요한 기능과 시스템 제한을 확인한 뒤 교체 시기를 계획하세요. 이름이 바뀌었다는 이유만으로 같은 설정을 반복해서 가져올 필요는 없습니다.

코어를 선택할 때는 하드웨어 아키텍처도 고려해야 합니다. Apple Silicon용과 Intel Mac용 설치 파일은 다르며, Linux의 x86_64와 arm64 바이너리도 서로 바꿔 쓸 수 없습니다. GUI 클라이언트는 데스크톱 연동과 업데이트 관리 기능도 제공하지만, GUI가 없는 서버에서는 명령줄 코어를 사용할 수 있습니다. 플랫폼별 옵션을 더 비교하려면 선택 가이드를 확인하고, 설치 및 가져오기 방법은 빠른 시작 가이드를 참고하세요.