코어·클라이언트·구독 형식부터 구분하기
Clash 설정을 사용할 수 있는지 확인하려면 바탕 화면 아이콘이 아니라 실제로 실행 중인 코어부터 확인해야 합니다. 코어는 YAML을 파싱하고 프록시 연결을 설정하며 규칙을 실행하고 DNS를 처리합니다. 클라이언트는 설정 가져오기, 시스템 프록시 전환, 서비스 관리, 화면 표시를 담당합니다. 클라이언트 이름이 같아도 배포 버전이나 코어 전환 여부, 사용자 지정 코어 경로에 따라 실행되는 프로그램은 달라질 수 있습니다.
구독은 설정을 제공하는 경로입니다. 완성된 설정을 반환할 수도 있고, 노드 목록만 포함할 수도 있습니다. 구독 페이지에 ‘Clash’라고 적혀 있어도 모든 노드를 Clash 원본에서 인식할 수 있다는 뜻은 아닙니다. vless, hysteria2, reality-opts 같은 항목이 있다면 코어와 구체적인 버전을 추가로 확인하세요.
- 코어 확인: 시작 로그나 코어 정보 화면을 확인하거나 코어 실행 파일의 버전 명령을 실행합니다.
- 실제 적용 설정: 구독 원문만 보지 말고, 클라이언트가 병합·덮어쓰기한 뒤 코어에 전달하는 설정을 확인합니다.
- 오류 발생 단계: 설정 파싱 실패, 규칙 로드 실패, 노드 연결 실패를 구분하세요. 해결 방법이 서로 다릅니다.
명칭의 변천: Clash 원본, Premium, Meta, mihomo
Clash 원본과 Clash Premium은 지원 범위가 다릅니다
Clash 원본은 보통 Dreamacro의 오픈 소스 Clash 코어를 가리킵니다. Clash Premium은 원작자가 과거에 배포한 비공개 확장 코어로, TUN·규칙 세트·스크립트 등의 기능이 추가됐습니다. Premium 기능을 모든 Clash 클라이언트의 기본 기능으로 간주해서는 안 되며, 오픈 소스 원본 코어와 Premium의 설정 항목을 한데 묶어서도 안 됩니다.
2023년 원 프로젝트의 공개 유지 관리가 중단된 뒤에도 일부 구형 클라이언트에는 이 코어가 포함되어 있습니다. 기존 설정은 계속 작동할 수 있지만, 구독을 업데이트한다고 새 프로토콜 구현이 자동으로 추가되지는 않습니다. 구형 설치 파일이 실행되는지와 현재 구독을 처리할 수 있는지는 별도로 확인해야 합니다.
Clash Meta에서 mihomo로 이름 변경
Clash Meta는 Clash 생태계에서 갈라져 나온 확장 포크로, 이후 mihomo로 이름이 바뀌었습니다. 두 이름은 같은 프로젝트의 발전 과정에 속하므로, 서로 무관한 두 코어처럼 설정 전체를 다시 작성할 필요는 없습니다. 클라이언트 화면에 ‘Meta’가 표시되어도 실제로는 후속 mihomo 빌드를 가리킬 수 있습니다.
다만 프로젝트가 이어졌다고 해서 모든 버전이 완전히 호환되는 것은 아닙니다. 초기 Meta 빌드에는 후속 mihomo의 설정 항목이나 프로토콜 기능이 없을 수 있으며, 기존 기능이 변경되거나 제거되기도 합니다. 마이그레이션할 때는 전체 버전 정보를 기록하고 해당 버전의 설정 문서와 시작 시 검사 결과를 기준으로 판단하세요.
| 이름 | 구분 | 마이그레이션 시 확인 사항 |
|---|---|---|
| Clash 원본 | 오픈 소스 기본 코어 | 기본 프로토콜·규칙·DNS 지원. Premium 전용 설정은 적용하지 마세요. |
| Clash Premium | 과거의 비공개 확장 코어 | TUN·규칙 세트·스크립트 지원. 스크립트는 대체 방안을 별도로 검토해야 합니다. |
| Clash Meta | 확장 포크의 과거 명칭 | 빌드 버전을 반드시 확인하세요. 이름만으로 모든 최신 기능을 지원한다고 판단할 수 없습니다. |
| mihomo | Meta에서 이름이 바뀐 프로젝트 | 프로토콜 매개변수, 규칙 세트 형식, DNS·TUN의 버전 요구 사항 |
설정 항목 호환성: 그대로 쓸 수 있는 항목과 확인이 필요한 항목
기본 항목은 대체로 호환되지만, 호환성은 세 단계로 나눠 확인해야 합니다. 항목을 파싱할 수 있는지, 지정한 값을 지원하는지, 실행 결과가 같은지입니다. 예를 들어 dns 항목을 인식하더라도 그 안의 새 옵션까지 구형 코어가 처리한다는 보장은 없습니다. 일부 알 수 없는 항목은 무시될 수 있으므로 설정 검사에 통과했다고 기능이 작동한다고 단정할 수 없습니다.
| 항목 또는 기능 | Clash 원본 오픈 소스 코어 | Premium | Meta / mihomo |
|---|---|---|---|
mixed-port、mode、log-level | 대체로 사용 가능 | 대체로 사용 가능 | 대체로 그대로 사용 가능 |
proxies、proxy-groups | 기본 구조 지원 | 기본 구조 지원 | 기본 구조는 유지되지만 새 유형은 별도 확인 필요 |
DOMAIN-SUFFIX、GEOIP、MATCH | 지원 | 지원 | 지원. 데이터 파일도 사용할 수 있어야 함 |
proxy-providers | 지원. 페이로드 형식이 맞아야 함 | 지원 | 지원. 확장 옵션은 버전에 따라 다름 |
rule-providers、RULE-SET | Premium 기능을 전제로 사용하면 안 됨 | 지원 | 지원. 형식과 동작 유형 확인 필요 |
tun | Premium에 내장된 TUN 기능은 지원하지 않음 | 지원. 플랫폼과 권한에 따라 다름 | 지원. 네트워크 스택과 라우팅 옵션을 다시 확인해야 함 |
sniffer | 그대로 적용할 수 없음 | mihomo 전용 항목으로 적용할 수 없음 | 지원. 세부 옵션은 버전에 따라 다름 |
Premium script 모드 | 미지원 | 과거 기능 | Premium 스크립트를 그대로 사용할 수 없음 |
dns.enhanced-mode: fake-ip | 기본 기능 지원 | 지원 | 지원. 필터링 및 파싱 방식은 추가 확인 필요 |
정책 그룹 이름은 설정 간 참조 관계에 포함됩니다
규칙 끝에 지정한 정책 이름은 실제 노드, 정책 그룹 또는 내장 동작과 일치해야 합니다. 정책 그룹 ‘프록시 선택’을 ‘노드 선택’으로 바꾸면 이를 참조하는 모든 규칙과 규칙 세트 항목, 다른 정책 그룹의 구성원 이름도 함께 바꿔야 합니다. 이런 오류는 코어 세대와 무관하지만 마이그레이션 중 프로토콜 호환성 문제로 오해하기 쉽습니다.
Premium 스크립트의 분기 로직은 다시 작성해야 합니다
기존 설정에서 mode: script와 script:를 사용한다면 코어 파일만 교체하지 마세요. 먼저 스크립트가 실제로 판단하는 도메인·주소·정책을 정리한 다음, 대상 코어에서 지원하는 규칙이나 규칙 세트로 옮겨야 합니다. 동적 판단이 포함된 부분은 대응 기능이 있는지 항목별로 확인해야 하며, 모드를 rule로 바꾸는 것만으로 마이그레이션이 끝나지 않습니다.
프로토콜 호환성: 구독 이름보다 노드 유형이 중요합니다
Clash 원본과 Premium에서 흔히 쓰는 프로토콜은 Shadowsocks, VMess, Trojan, HTTP, SOCKS5입니다. 여기서 지원한다는 말은 프로토콜 유형을 뜻하며, 나중에 추가된 모든 암호화 방식·전송 조합·확장 항목까지 포함하지는 않습니다. mihomo는 지원 프로토콜 범위를 넓혔지만, 서버 매개변수와 하나씩 대조해야 합니다.
| 설정 내용 | Clash 원본 / Premium | mihomo에서 확인할 항목 |
|---|---|---|
ss、vmess、trojan | 기본 지원. 모든 확장 기능을 지원한다는 뜻은 아님 | 암호화 방식, 전송 방식, TLS 매개변수 |
vless | 미지원 | UUID, 전송 방식, flow 및 TLS 조합 |
reality-opts | 미지원 | 공개 키, short-id, 서버 이름 등 매개변수 |
hysteria2 | 미지원 | UDP 연결 가능 여부, 인증, TLS 매개변수 |
tuic | 미지원 | 서버 프로토콜 버전, 인증, 혼잡 제어 옵션 |
‘unsupported proxy type’ 같은 오류가 나타나면 DNS를 바꾸기보다 먼저 코어와 노드 유형을 확인하세요. 설정은 불러와지지만 연결되지 않는다면 서버 주소·포트·인증·TLS·하위 네트워크를 점검합니다. Hysteria2와 TUIC는 UDP를 사용합니다. 클라이언트를 전역 모드로 바꿔도 외부 네트워크에서 UDP를 차단하는 문제는 해결되지 않습니다.
규칙 세트·DNS·TUN: 마이그레이션 후 중점 확인 항목
규칙 세트의 behavior와 페이로드 형식은 서로 일치해야 합니다
rule-providers의 behavior 값으로는 domain, ipcidr, classical이 흔히 사용됩니다. 도메인 목록을 완전한 규칙 목록처럼 불러올 수 없으며, 파일 확장자만 바꾼다고 전체 규칙이 도메인 페이로드로 바뀌지도 않습니다. mihomo의 MRS 형식은 과거 Premium에 그대로 사용할 수 없습니다. 마이그레이션할 때 format, 실제 파일 내용, 대상 버전을 확인하세요.
규칙은 설정된 순서대로 매칭됩니다. 도메인 규칙과 IP 주소 규칙 중 무엇을 먼저 두는지에 따라 DNS 조회 동작과 최종 연결 경로가 달라질 수 있습니다. 마지막의 MATCH는 기본 처리 규칙이므로, 뒤이어 다른 규칙을 매칭해야 하는 위치에 두면 안 됩니다. 규칙 세트 다운로드가 성공해도 이를 참조하는 RULE-SET의 위치가 올바르다는 뜻은 아닙니다.
Fake-IP 예약 주소는 노드 주소가 아닙니다
198.18.0.0/16은 Fake-IP 설정에서 흔히 사용하는 주소 범위입니다. 앱이 이 주소를 받으면 보통 동일한 코어가 이후 연결을 처리해야 매핑을 통해 도메인을 복원할 수 있습니다. DNS에서 가짜 주소만 반환하고 해당 트래픽을 처리할 경로가 없으면 연결이 실패할 수 있습니다. 마이그레이션 후에는 가짜 주소를 비정상 서버로 단정하지 말고 DNS 설정, 시스템 프록시, TUN, 앱 자체 프록시 설정을 확인하세요.
TUN은 운영체제 권한과 라우팅 설정이 필요합니다
tun.enable: true는 TUN을 켜겠다는 설정일 뿐입니다. 실제 동작에는 서비스 권한, 가상 네트워크 어댑터, 라우팅, DNS 처리, 네트워크 스택 구현이 필요합니다. Windows에서는 클라이언트 서비스나 관리자 권한이 필요할 수 있고, Linux에서는 적절한 네트워크 관리 권한이 필요합니다. 클라이언트의 ‘서비스 모드’와 설정의 TUN 스위치는 서로 다른 계층의 설정입니다.
- 구형 클라이언트와 백그라운드 서비스를 먼저 종료해 두 프로그램이 동시에 라우팅을 제어하지 않도록 합니다.
- 시스템 프록시로 기본 연결을 먼저 확인한 뒤 TUN을 별도로 켜서 문제 범위를 좁힙니다.
- 기존 설정 사본을 보관하고 일반 도메인, 로컬 네트워크 기기, IPv6 접속을 각각 확인합니다.
- 로그에서 실제로 활성화된 네트워크 스택을 확인하세요. 화면의 스위치 상태만 보고 트래픽 제어가 성공했다고 판단하지 마세요.
기존 설정 마이그레이션: 기본 포트부터 확인한 뒤 확장 기능 복원
아래 설정은 로컬 수신 포트와 기본 규칙 파싱을 확인하기 위한 예시입니다. 원격 노드는 포함하지 않으며 기존 구독을 대체하지 않습니다. 혼합 포트는 7890으로 설정하고, LAN 접속을 차단하며 모든 연결을 직접 연결로 처리합니다. 포트 번호는 예시이므로 다른 프로그램에서 이미 사용 중이면 포트를 바꾸거나 해당 프로그램을 먼저 종료하세요.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
- MATCH,DIRECT- 현재 상태를 저장합니다. 구독 원문, 덮어쓰기 규칙, 현재 적용 중인 설정을 백업하세요. 클라이언트와 코어 버전도 기록하고, 가져오기 링크만 백업하지 않도록 주의합니다.
- 새 코어를 확인합니다. mihomo 실행 파일을 사용한다면
mihomo -v를 실행해 버전을 확인하세요. 실제 프로그램 경로와 파일 이름은 설치 위치에 따라 다릅니다. - 구문을 검사합니다.
mihomo -t -f config.yaml을 실행하세요. 상대 경로 리소스를 사용하는 설정이라면 작업 디렉터리와 데이터 디렉터리가 클라이언트의 실제 실행 환경과 일치하는지 확인합니다. - 노드와 정책 그룹을 복원합니다. 먼저 정상 작동이 확인된 노드 하나를 추가해 인증과 TLS를 검증한 다음, 자동 선택·장애 조치 같은 정책 그룹을 복원합니다.
- 규칙 세트와 DNS를 복원합니다. 리소스 로드, 정책 이름, 규칙 매칭을 확인한 뒤 Fake-IP나 특수 DNS 처리 방식을 추가합니다.
- 마지막으로 TUN을 켭니다. 권한·기본 경로·LAN 접속을 확인하고, 클라이언트를 종료한 뒤 네트워크가 예상대로 복구되는지 확인합니다.
기본 포트는 curl -x http://127.0.0.1:7890 -I https://clash-dl.com/로 확인할 수 있습니다. 이 명령은 HTTP 프록시가 요청을 처리하는지 확인할 뿐, SOCKS5·UDP·TUN 또는 모든 노드의 작동을 보장하지 않습니다. 명령이 실패하면 로그를 확인해 수신 포트가 열리지 않았는지, 대상 사이트에 접속할 수 없는지, 외부 연결 경로에 문제가 있는지 구분하세요.
클라이언트 선택과 자주 발생하는 호환성 문제
클라이언트를 고를 때는 운영체제와 프로세서 아키텍처부터 확인한 다음 코어의 출처와 유지 관리 상태를 살펴보세요. Clash Verge Rev, FlClash 등은 mihomo 계열 코어를 사용하지만, 실제 지원 범위는 설치한 클라이언트 버전과 코어 빌드에 따라 달라집니다. 구형 Clash for Windows나 Clash for Android 설치 파일은 이름에 Clash가 들어간다는 이유만으로 mihomo 확장 프로토콜을 지원한다고 볼 수 없습니다.
클라이언트의 코어 정보, 구독 덮어쓰기 기능, 서비스 관리 기능도 확인해야 합니다. 실행 파일을 교체해도 구형 화면에서는 새 설정 항목이 표시되지 않거나 저장 과정에서 직접 수정한 내용이 덮어써질 수 있습니다. 운영체제별 클라이언트 비교는 클라이언트 비교를, 기본 설정 항목 설명은 프로토콜 참조를 확인하세요.
Clash Meta 설정을 mihomo에서 그대로 사용할 수 있나요?
기본 설정은 대체로 이어서 사용할 수 있지만, 모든 기존 옵션이 그대로 작동하는 것은 아닙니다. 먼저 설정 검사를 실행한 다음 로그의 폐기 예정 알림, 리소스 로드, 실제 연결을 확인하세요. 구형 Meta 빌드와 후속 mihomo의 차이는 구체적인 버전을 기준으로 판단해야 합니다.
mihomo 설정을 Clash 원본용으로 낮출 수 있나요?
프로토콜과 설정 기능이 모두 Clash 원본의 지원 범위 안에 있을 때만 가능할 수 있습니다. VLESS, Hysteria2, 스니핑, 확장 규칙 등은 그대로 사용할 수 없습니다. 서버 프로토콜이 관련된 경우 YAML 항목을 삭제하는 것만으로는 다운그레이드할 수 없습니다.
설정 검사는 통과했는데 왜 접속되지 않나요?
설정 검사는 주로 구조와 인식 가능한 설정 항목을 확인하며, 원격 서버 접속 가능 여부까지 보장하지는 않습니다. 노드 인증, DNS 응답, 인증서, 시스템 프록시 적용 범위, UDP 연결 경로, 규칙이 최종 선택한 출구도 확인해야 합니다.
기존 구독을 다시 결제하거나 바꿔야 하나요?
코어 이름만으로 결정할 수는 없습니다. 먼저 구독이 실제로 반환하는 프로토콜과 설정 형식을 확인하세요. 현재 서비스에서 mihomo용 설정 주소를 제공한다면 안내에 따라 전환할 수 있고, 기본 프로토콜 설정만 사용한다면 그대로 옮길 수 있는 경우도 있습니다. 클라이언트 설정 형식 문제와 서버 이용 가능 여부를 혼동하지 마세요.
최종 판단은 ‘코어 버전, 설정 항목, 서버 프로토콜, 운영체제의 트래픽 제어 기능’ 네 가지가 모두 맞는지를 기준으로 해야 합니다. 기본 규칙은 우선 그대로 사용하고, Premium 스크립트는 별도로 처리하며, 새 프로토콜은 지원 범위를 확인해야 합니다. TUN과 DNS는 대상 기기에서 직접 검증하세요. 이 확인을 마친 뒤 기존 설정을 유지할지, 구독 형식을 조정할지, 클라이언트를 바꿀지 결정하면 됩니다.