Clash 커널 호환성 비교

클라이언트·커널·설정을 구분하기

Clash 클라이언트 이름만으로 실제 기능을 판단할 수는 없습니다. 클라이언트 화면은 구독 가져오기, 설정 관리, 시스템 프록시 설정을 담당하고, 커널은 노드 해석, 포트 수신, 규칙 매칭, 연결 수립을 담당합니다. 같은 클라이언트라도 배포 버전에 따라 포함된 커널 버전이 다를 수 있습니다. 구독을 사용할 수 있는지 판단하려면 바탕 화면 바로 가기의 이름이 아니라 현재 실행 중인 커널을 먼저 확인해야 합니다.

이 글에서 ‘원본’은 초기 Clash 오픈 소스 커널을 뜻하며, Premium은 당시 별도로 제공되던 비공개 강화 커널을 뜻합니다. 둘은 같은 것으로 볼 수 없습니다. 원본 오픈 소스 프로젝트와 Premium의 기존 공식 배포 채널은 2023년에 유지 관리가 중단되었습니다. 구형 프로그램이 실행되더라도 이후의 프로토콜 업데이트나 운영체제 지원까지 제공된다는 뜻은 아닙니다.

세 단계로 점검하기

1. 클라이언트 단계: 사용자 지정 규칙을 저장하고 구독을 업데이트할 수 있는지, TUN에 필요한 권한을 요청할 수 있는지 확인합니다.
2. 커널 단계: 노드의 type, 전송 옵션, DNS 필드를 인식하는지 확인합니다.
3. 실행 설정 단계: 화면에서 설정하고 구독을 변환·병합한 뒤 커널에 전달되는 최종 YAML이 예상한 내용인지 확인합니다.

예를 들어 편집기에서 mixed-port: 7890으로 저장했더라도 클라이언트의 포트 재정의 설정에 따라 다른 값으로 바뀔 수 있습니다. 문제를 점검할 때는 클라이언트 설정과 실행 설정을 모두 확인해야 합니다. 로컬에 내려받은 구독 원문만 살펴봐서는 안 됩니다.

원본·Premium·mihomo 비교

아래 표는 커널 계열별 기능 범위를 비교한 것이며, 임의의 과거 버전까지 보장하는 내용은 아닙니다. 특히 mihomo는 프로토콜·필드·규칙 형식이 버전에 따라 추가되므로 ‘mihomo 사용’이 ‘구형 바이너리에서 현재 설정을 모두 지원’한다는 뜻은 아닙니다.

Premium이라는 이름만으로 현재 mihomo보다 기능이 많다고 볼 수 없으며, 사용하려면 구독을 구매해야 한다는 뜻도 아닙니다. 커널 분기, 클라이언트 배포 방식, 프록시 서비스 구독은 서로 별개의 문제입니다. 구독에 포함된 서버에 연결할 수 있는지는 서버 측 설정, 인증 정보, 네트워크 경로, 인증서 설정에도 달려 있습니다.

프로토콜 지원은 세부 매개변수까지 확인하기

프로토콜 이름을 인식한다고 연결까지 성공하는 것은 아닙니다

노드에 type: vless, type: hysteria2 또는 type: tuic가 표시된다면 해당 유형을 명시적으로 지원하는 mihomo 버전을 선택해야 합니다. 노드 유형을 vmess나 trojan으로 바꿔 적어도 프로토콜이 변환되지는 않습니다. 서버 측에서 해당 프로토콜의 접속 지점을 제공해야 합니다.

두 커널 모두 type: ss를 인식하더라도 지원하는 암호화 방식은 다를 수 있습니다. ‘Shadowsocks 지원’이라는 설명만으로 Shadowsocks 2022 계열 방식과의 호환성을 판단할 수는 없습니다. 마찬가지로 VLESS의 REALITY 매개변수, 전송 방식, 지문 설정은 서버 설정과 일치해야 하며 사용 중인 커널 버전에서 지원되어야 합니다.

• 파싱 중 알 수 없는 유형 오류: 먼저 커널 분기, 버전, 구독 형식을 확인합니다.
• 필드 누락 또는 잘못된 매개변수 오류: 해당 버전의 설정 문서를 참고해 필드 이름, 계층 구조, 데이터 유형을 확인합니다.
• 설정은 불러왔지만 핸드셰이크 실패: 규칙 순서를 계속 바꾸기보다 서버 주소, 포트, 인증, SNI, 인증서 관련 매개변수를 확인합니다.
• 웹 페이지는 열리지만 UDP 앱은 실패: 노드, 서버, 로컬 트래픽 처리 경로가 모두 UDP를 지원하는지 확인합니다.

구독 형식에도 호환성 한계가 있습니다

‘Clash 구독’은 정확한 버전 표기가 아닙니다. 서비스 제공업체는 원본 커널용 간소화 설정을 제공할 수도 있고, mihomo 확장 기능이 포함된 설정을 제공할 수도 있습니다. 구독 변환기를 거쳐 가져온다면 변환기가 인식하지 못하는 노드나 필드를 삭제할 수도 있습니다. 노드 수가 줄어들었다면 원본 응답, 변환 결과, 클라이언트 실행 설정을 비교해 어느 단계에서 내용이 바뀌었는지 확인하세요.

설정 호환성: 기본 필드부터 확장 필드까지

마이그레이션할 때는 먼저 수신 포트, 기본 프록시 그룹, 자주 쓰는 규칙을 유지하고 확장 기능을 하나씩 추가할 수 있습니다. 아래는 mihomo가 설정을 불러올 수 있는지 확인하기 위한 최소 설정이며, 원격 프록시 노드는 포함되어 있지 않습니다. ‘출구 선택’에는 직접 연결만 있으므로 프록시 서버의 사용 가능 여부는 확인할 수 없습니다.

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

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

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

7890은 이 예시에서 HTTP와 SOCKS가 함께 사용하는 로컬 포트로 선택한 값이며, 모든 클라이언트의 기본 포트는 아닙니다. allow-lan: false는 LAN 접근을 제한합니다. 가져오기 전에 다른 프로그램이 해당 포트를 사용 중이라면 포트를 바꾸거나 충돌하는 프로세스를 종료하세요. 같은 수신 포트를 사용하는 커널 두 개를 동시에 실행하지 마세요.

규칙 순서와 프록시 그룹 참조도 중요합니다

일반적인 규칙은 위에서 아래 순서로 매칭됩니다. 앞선 규칙에 일치하면 이후 규칙은 해당 연결의 출구를 결정하지 않습니다. MATCH는 마지막 기본 규칙으로 배치해야 합니다. 규칙 끝에서 참조하는 프록시 그룹 이름은 실제로 존재해야 하며 철자도 정확히 일치해야 합니다. 커널을 바꿔도 잘못 입력한 프록시 그룹 이름이 자동으로 수정되지는 않습니다.

no-resolve는 IP 유형 규칙에서 흔히 사용되며, 해당 규칙을 매칭할 때 도메인 해석을 강제로 수행하지 않는다는 뜻입니다. 요청 전체에서 DNS를 전혀 사용하지 않는다는 뜻은 아닙니다. rule-providers를 추가할 때는 behavior, format, 규칙 파일 내용이 서로 맞는지도 확인해야 합니다. 도메인 목록만 들어 있는 파일을 완전한 규칙 문장이 포함된 classical 규칙 세트로 사용할 수는 없습니다.

Premium 스크립트를 그대로 가져오지 마세요

Premium의 스크립트 기능을 mihomo에서 일반적으로 호환되는 인터페이스로 간주해서는 안 됩니다. 기존 설정에 script가 있다면 먼저 사용 중인 커널이 같은 방식을 지원하는지 확인한 다음 규칙 세트, 논리 규칙, 프록시 그룹으로 바꿀지 검토하세요. YAML을 읽을 수 있다고 해서 알 수 없는 모든 필드가 동작하는 것은 아닙니다. 일부 필드는 무시될 수 있으므로 실제 연결 기록에서 규칙이 적용되는지 확인해야 합니다.

DNS와 TUN은 별도로 점검해야 합니다

Fake-IP, DNS 분류, TUN은 튜토리얼에 함께 등장하는 경우가 많지만 담당하는 단계는 서로 다릅니다. DNS 모듈은 도메인 해석과 매핑을 처리하고, TUN은 가상 네트워크 인터페이스와 라우팅으로 트래픽을 가로챕니다. TUN을 켠다고 해서 모든 DNS 요청이 예상대로 처리되는 것은 아닙니다. DNS 확인 페이지에 표시된 서비스 제공업체 이름만으로 커널 호환성을 판단할 수도 없습니다.

DNS 설정을 옮길 때 확인할 네 가지

1. 수신 주소: 예를 들어 127.0.0.1:1053은 로컬에서만 접근할 수 있습니다. 시스템이 다른 주소에 계속 질의한다면 커널 DNS가 요청에 관여하지 않을 수 있습니다.
2. 강화 모드: enhanced-mode가 fake-ip와 redir-host 중 어느 값을 사용하는지 확인합니다. 이전 인터페이스의 토글 상태만 그대로 유지해서는 안 됩니다.
3. DNS 분류: nameserver, fallback, nameserver-policy의 실제 동작을 확인합니다. fallback을 기본 DNS 서버가 시간 초과될 때만 사용하는 예비 주소로 단순하게 이해해서는 안 됩니다.
4. 추가 DNS 경로: 브라우저의 보안 DNS, 앱 내장 DoH, 라우터 전달 기능이 원래 예상한 DNS 경로를 우회할 수 있습니다.

TUN을 켜도 모든 트래픽이 프록시를 거치는 것은 아닙니다

mihomo의 tun.enable, auto-route, dns-hijack는 각각 가상 네트워크 인터페이스 활성화, 라우팅 설정, 지정된 DNS 트래픽 가로채기를 담당합니다. 최종 출구는 여전히 규칙에 따라 결정되며, DIRECT에 일치하는 연결은 직접 연결됩니다. 권한 부족, 라우팅 충돌, VPN 동시 실행으로 일부 트래픽이 처리되지 않을 수도 있습니다.

오래된 튜토리얼과 호환하려고 stack 값을 그대로 복사하지 마세요. 사용할 수 있는 스택과 동작은 커널 버전 및 운영체제에 따라 달라집니다. 먼저 현재 플랫폼에 맞는 클라이언트 기본 설정을 사용하고, 구체적인 문제가 있을 때만 조정하세요. 테스트할 때는 TUN을 끄고 시스템 프록시를 먼저 확인한 뒤, 노드가 정상 작동하면 TUN을 켜세요. 동시에 바뀌는 변수를 줄일 수 있습니다.

마이그레이션 전후 실행 상태 확인하기

언제든 되돌릴 수 있도록 설정 복사본을 만들어 마이그레이션하세요. 먼저 기존 커널 이름과 버전, 수신 포트, 구독 갱신 시각을 기록한 다음 설정을 복사해 테스트합니다. 명령줄 사용자는 실제 바이너리에 다음 검사를 실행할 수 있습니다. 데스크톱 클라이언트 사용자는 커널 로그를 확인하고 테스트 대상이 클라이언트에서 실제로 실행한 커널인지 확인해야 합니다.

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

첫 번째 명령은 버전을 확인하고, 두 번째 명령은 설정을 파싱하고 불러올 수 있는지 확인합니다. 검사를 통과했다는 것은 정적 설정이 해당 조건을 만족한다는 뜻일 뿐입니다. 원격 노드 핸드셰이크 성공, 올바른 DNS 경로, TUN 라우팅 적용까지 보장하지는 않습니다. 원격 규칙이나 노드 제공자를 참조하는 설정이라면 관련 리소스를 가져올 수 있는지도 확인해야 합니다.

문제가 생기면 ‘불러오기 실패 → 로컬 수신 → 노드 연결 → 규칙 매칭 → DNS/TUN’ 순서로 점검하세요. 한 번에 변수 하나만 바꾸세요. 더 자세한 일반 점검 방법은 문제 해결에서 확인할 수 있습니다. 설정을 처음 가져오는 경우 설정 가이드에 따라 기본 연결부터 완료하세요.

클라이언트 선택 기준

• 새로 설치하는 경우: 유지 관리가 계속되고 사용하는 mihomo 커널 버전을 명확히 표시한 클라이언트를 우선 선택한 뒤 운영체제와 프로세서 아키텍처를 확인합니다.
• 안정적으로 사용 중인 구형 환경: 먼저 작동하는 설정 복사본을 보존하고, 새 구독에 기존 커널이 지원하지 않는 프로토콜이 포함됐는지 확인하세요. 기존 설정을 모두 바로 덮어쓰지 마세요.
• TUN을 사용하는 경우: 커널 기능뿐 아니라 클라이언트가 권한을 요청하고 서비스를 관리하며 종료할 때 라우팅을 정리할 수 있는지도 확인해야 합니다.
• 복잡한 규칙을 사용하는 경우: 규칙 제공자, 논리 매칭, 설정 덮어쓰기 유지 방식을 중점적으로 확인하고 구독을 업데이트해도 로컬 수정 내용이 삭제되지 않는지 살펴봅니다.

선택은 확인 가능한 사실에 근거해야 합니다. 실제 실행 중인 커널 버전, 설정 검사 결과, 로그에 기록된 프로토콜 오류, 연결 기록의 규칙과 출구를 확인하세요. Meta와 mihomo라는 이름의 차이는 주된 장애물이 아닙니다. 마이그레이션에서 더 흔한 호환성 문제는 구형 바이너리, 확장 필드, 클라이언트 설정 덮어쓰기 사이의 불일치입니다.