클라이언트, 코어, 설정의 차이부터 확인
“구독을 가져왔지만 노드에 연결되지 않는다”와 “클라이언트에 TUN 스위치가 없다”는 서로 다른 계층의 문제입니다. GUI 클라이언트는 구독 관리, 트레이 메뉴, 시스템 프록시, 설정 병합을 담당하고, 코어는 최종 설정을 읽어 포트를 열고 DNS를 확인하며 규칙을 매칭해 프록시 연결을 수립합니다. 설정 파일은 이 동작을 정의합니다. Clash 오리지널, Clash Meta, mihomo의 차이를 확인하려면 창에 표시된 앱 이름만 보지 말고 실제 실행 중인 코어부터 확인하세요.
- 클라이언트 버전: 인터페이스, 서비스 설치 방식, 설정 덮어쓰기 방식을 결정합니다. GUI 프로그램을 업그레이드해도 코어까지 함께 업데이트되는 것은 아닙니다.
- 코어 버전: 지원 프로토콜과 설정 항목, 라우팅 기능을 결정합니다. 클라이언트 실행 로그나 코어 버전 명령의 출력으로 확인하세요.
- 구독 형식: 전체 Clash YAML일 수도 있고 노드 목록만 포함할 수도 있으며, 인코딩된 공유 링크 모음일 수도 있습니다. 세 형식은 서로 바꿔 쓸 수 없습니다.
오리지널, Meta, mihomo의 관계
Clash 오리지널: 오픈소스 코어와 Premium을 구분하세요
Clash 오리지널은 보통 Dreamacro/Clash를 가리킵니다. 과거에는 오픈소스 코어와 추가 기능을 제공하는 비공개 Premium 빌드가 함께 존재했습니다. 원 프로젝트는 더 이상 유지관리되지 않습니다. 오리지널이 TUN, 스크립트 또는 특정 규칙을 지원하는지 논할 때는 어떤 빌드를 말하는지 명확히 해야 합니다. Premium의 기능을 모두 오픈소스 버전의 기능으로 간주하거나 두 버전이 완전히 같은 설정을 사용한다고 가정해서는 안 됩니다.
예를 들어 오픈소스 오리지널 코어의 mixed-port와 Premium의 TUN 기능은 서로 다른 영역의 기능입니다. 전자는 로컬 HTTP/SOCKS 프록시 진입점을 제공하고, 후자는 가상 네트워크 인터페이스를 통해 트래픽을 처리합니다. 설정에 tun:이 있다고 해서 Clash라는 이름의 모든 바이너리가 이를 실행할 수 있는 것은 아닙니다.
Clash Meta: 오리지널에서 기능을 확장한 포크
Clash Meta는 Clash에서 발전한 포크로, 프로토콜·DNS·규칙·TUN 등의 기능을 확장했습니다. “Meta 설정”은 보통 이 포크가 지원하는 확장 항목을 사용한다는 뜻이지, 완전히 다른 파일 형식을 의미하지는 않습니다. YAML과 proxies, proxy-groups, rules 같은 익숙한 최상위 구조도 계속 사용합니다.
mihomo: Meta 프로젝트의 후속 이름
Clash Meta는 이후 mihomo로 이름이 바뀌었습니다. 두 프로젝트는 직접 이어져 있으며 서로 무관한 별개의 코어가 아닙니다. 일부 클라이언트는 코어 선택 메뉴에 여전히 “Meta”라고 표시하지만 실제 실행 파일은 mihomo일 수 있습니다. 반대로 오래된 Meta 바이너리는 이름이 비슷하더라도 나중에 추가된 설정 항목을 자동으로 지원하지 않습니다. 실제 호환 범위는 구체적인 버전에 따라 달라집니다.
# 수동 설치한 코어 버전 확인
mihomo -v
# 이전 Clash 바이너리 버전 확인
clash -v위 명령을 실행하려면 해당 실행 파일이 시스템 검색 경로에 있어야 합니다. Windows PowerShell에서 현재 디렉터리의 파일을 실행하려면 .\mihomo.exe -v를 사용할 수 있습니다. 클라이언트에 코어가 포함되어 있다면 전역 설치된 다른 프로그램의 버전을 조회하지 않도록 시작 로그에서 버전 정보를 확인하세요.
프로토콜 지원: 노드 유형과 전송 매개변수를 함께 확인
프로토콜 이름은 첫 번째 확인 항목일 뿐, 전부는 아닙니다. 같은 VMess 또는 Trojan 노드라도 WebSocket, gRPC, TLS 등의 전송 방식이나 암호화 설정을 사용할 수 있습니다. 노드 유형과 전송 방식, 주요 설정 항목이 모두 지원되어야 정상 연결을 기대할 수 있습니다.
| 기능 | Clash 오리지널 | mihomo | 마이그레이션 시 확인 사항 |
|---|---|---|---|
| Shadowsocks、VMess、Trojan | 관련 구현이 있지만 이전 버전의 제약이 있음 | 지원하며 세부 매개변수는 버전에 따라 달라짐 | 암호화 방식, 전송 방식, TLS 항목 확인 |
| VLESS 및 REALITY | 지원하지 않음 | 관련 설정 지원 | UUID, flow, 서버 이름 및 REALITY 매개변수 확인 |
| Hysteria2、TUIC | 지원하지 않음 | 해당 프로토콜 지원 | 버전, 인증 항목, UDP 네트워크 환경 확인 |
| TUN을 통한 트래픽 처리 | 오픈소스 버전과 Premium을 구분해야 함 | TUN 기능 제공 | 관리자 권한, 서비스, 시스템 라우팅도 확인 |
“Shadowsocks 지원”이 모든 암호화 방식을 지원한다는 뜻은 아닙니다
최신 암호화 방식은 더 새로운 코어가 필요할 수 있습니다. 문제를 진단할 때는 “SS 노드”라고만 기록하지 말고 type, cipher, network 등의 항목을 확인하세요. 로그에 “지원하지 않는 프록시 유형”이 표시된다면 코어 기능 문제일 가능성이 높습니다. 연결 시간이 초과된다면 서버, 네트워크 경로, UDP 연결 가능 여부, 인증 매개변수도 확인해야 합니다. 두 문제에 같은 해결 방법을 적용해서는 안 됩니다.
REALITY는 독립된 프록시 유형이 아닙니다
일반적인 설정에서는 type: vless로 노드 유형을 지정한 뒤 reality-opts 등의 항목으로 관련 매개변수를 설정합니다. 노드 유형을 reality로 바꾸거나 모르는 항목만 삭제한다고 프로토콜이 변환되지는 않습니다. 마찬가지로 type: hysteria2를 ss로 바꿔도 정상적인 Shadowsocks 노드가 되지 않습니다. 서버도 해당 프로토콜을 제공해야 합니다.
설정 호환성: 기본 구조는 비슷하지만 확장 항목에는 차이가 있음
오리지널 설정을 mihomo로 옮길 때는 일반적으로 기본 구조를 유지할 수 있습니다. 반대로 mihomo 설정을 오리지널로 되돌리면 알 수 없는 프로토콜이나 규칙, 설정 항목의 의미 차이로 문제가 생기기 쉽습니다. 호환성에는 방향이 있습니다. “둘 다 YAML이니 서로 바꿔 쓸 수 있다”는 뜻이 아닙니다. 파서에서 오류가 나지 않더라도 설정 항목이 실제로 적용되는지 확인해야 합니다.
최소 설정으로 포트와 규칙 진입점 확인
아래는 기본 구조를 점검하기 위한 mihomo 설정이며 원격 노드는 포함하지 않습니다. PROXY 그룹에는 DIRECT만 있으므로 모든 요청은 결국 직접 연결됩니다. 이 설정으로 로컬 수신 포트와 규칙 구조는 확인할 수 있지만 프록시 경로의 품질은 검증할 수 없습니다.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups:
- name: PROXY
type: select
proxies:
- DIRECT
rules:
- DOMAIN-SUFFIX,example.org,PROXY
- MATCH,DIRECTmixed-port: 7890: 하나의 로컬 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받습니다. 시스템 프록시가 자동으로 활성화된다는 뜻은 아닙니다.allow-lan: false: LAN에 프록시 진입점을 공개하지 않습니다. 마이그레이션할 때는 기존 접근 범위를 유지하고, 연결 문제를 해결하려고 수신 범위를 무작정 넓히지 마세요.mode: rule: 규칙 모드를 사용합니다. 전역 모드로 전환하면 특정 도메인 규칙이 적용되는지 확인해 분할 라우팅을 검증할 수 없습니다.MATCH,DIRECT: 마지막 단계의 기본 규칙으로 사용합니다. 프록시를 사용하는 경우에는 목적에 맞게 기본 출구를 변경하세요.
버전 간 오류가 발생하기 쉬운 설정 항목부터 확인
| 설정 영역 | 확인할 내용 | 흔히 나타나는 증상 |
|---|---|---|
proxies | 프로토콜 유형, TLS 매개변수, 전송 옵션 | 설정 로드 실패 또는 지정한 노드의 핸드셰이크 실패 |
proxy-groups | 노드 이름, 그룹 이름, provider 참조 | 프록시를 찾을 수 없음, 정책 그룹이 비어 있음 |
dns | 향상 모드, 리졸버 주소, 분할 라우팅 정책 | 노드에는 연결되지만 도메인 이름 확인에 문제가 생김 |
tun | 네트워크 스택, 라우팅, DNS 가로채기 설정 | 코어는 정상적으로 시작되지만 앱 트래픽이 유입되지 않음 |
script 등 과거 확장 기능 | 오리지널 Premium 전용 설정인지 확인 | 다른 코어에 그대로 적용할 수 없음 |
규칙, 규칙 세트, 구독을 각각 확인
기본 규칙은 순서와 대상 이름을 확인
DOMAIN, DOMAIN-SUFFIX, IP-CIDR, MATCH는 흔히 사용하는 규칙 유형입니다. 규칙은 일반적으로 순서대로 매칭되므로 앞쪽의 포괄적인 규칙이 뒤쪽의 세부 규칙을 가릴 수 있습니다. 마이그레이션 후 모든 트래픽이 같은 그룹으로 이동한다면 먼저 MATCH가 앞에 배치되어 있는지 확인하고, 규칙에서 참조하는 그룹 이름이 proxy-groups와 정확히 일치하는지도 살펴보세요.
mihomo의 논리 규칙, 프로세스 관련 규칙, 확장 매칭 기능을 모두 오리지널에서 지원한다고 볼 수는 없습니다. 프로세스 식별은 플랫폼과 권한, 트래픽 처리 방식의 영향도 받습니다. 설정 검사를 통과했다는 것은 현재 코어의 문법과 참조 조건을 충족했다는 뜻일 뿐, 모든 플랫폼에서 모든 앱의 프로세스를 식별할 수 있다는 보장은 아닙니다.
RULE-SET은 규칙 파일 형식도 확인해야 합니다
RULE-SET을 사용할 때는 rule-providers에 설정된 이름과 behavior, format, 파일 내용을 함께 확인하세요. domain, ipcidr, classical은 규칙 내용에 서로 다른 형식을 요구합니다. DOMAIN-SUFFIX,example.org 같은 완전한 규칙을 도메인 항목만 허용하는 데이터 소스에 임의로 넣어서는 안 됩니다.
mihomo의 MRS 규칙 세트는 특정 형식이며, 지원 여부는 코어 버전과 동작 유형의 지원 범위에도 좌우됩니다. 파일 확장자를 .mrs에서 .yaml로 바꿔도 파일 인코딩은 달라지지 않습니다. 이전 코어로 되돌릴 때는 확장자만 바꾸지 말고 대상 코어가 지원하는 규칙 소스를 준비하세요.
구독 가져오기에 성공해도 호환성이 검증된 것은 아닙니다
- 구독에서 전체 설정을 반환하는지, 아니면
proxy-providers에 사용할 노드 목록만 반환하는지 확인하세요. - 구독 서비스가 범용 Clash 설정을 제공하는지, Meta/mihomo 확장 설정을 명시적으로 제공하는지 확인하세요.
- 클라이언트가 덮어쓰기, 병합, 스크립트로 포트·DNS·규칙·정책 그룹을 변경하는지 살펴보세요.
- 다운로드한 원본 파일만 확인하지 말고 실제 코어가 실행하는 최종 설정을 기준으로 점검하세요.
설정과 로그에는 구독 주소, 노드 비밀번호, UUID, 제어 인터페이스 키가 포함될 수 있습니다. 문제를 제보할 때는 관련 설정 구조와 오류 메시지만 남기고 인증 정보는 먼저 삭제하세요. 전체 구독 링크를 스크린샷이나 공개 토론 공간에 올리지 마세요.
마이그레이션 순서: 설정을 먼저 검증하고 트래픽을 확인
기존 환경을 복구 지점으로 남겨 두고 한 번에 변수 하나만 변경하는 것이 좋습니다. 클라이언트와 구독을 동시에 바꾸고 TUN을 켜면서 DNS까지 다시 설정하지 마세요. 문제가 사라져도 원인을 파악할 수 없게 됩니다.
- 현재 상태 기록: 코어 버전, 클라이언트 버전, 현재 설정 사본, 수신 포트, 정책 그룹 선택을 저장하세요. 현재 네트워크에서 기존 설정이 실제로 어떻게 작동하는지도 확인합니다.
- 후보 설정 검사: 실행할 mihomo 바이너리로 설정을 테스트하세요. 첫 번째 파싱 오류가 나타나면 해당 오류를 먼저 수정한 다음 계속 확인합니다.
- 새 코어만 따로 실행: 기존 코어를 중지하거나 새 코어에 다른 포트를 사용하세요. 두 프로세스가
7890또는 제어 인터페이스 포트를 동시에 점유하지 않도록 합니다. - 명시적 프록시부터 테스트: TUN을 끄고 지정한 HTTP/SOCKS 포트를 통해 사용 가능한 노드 하나를 테스트하세요.
- 이후 규칙과 DNS 테스트: 직접 연결되어야 하는 대상과 프록시를 사용해야 하는 대상을 각각 방문한 뒤 연결 기록에서 적용된 규칙, 정책 그룹, 최종 노드를 확인하세요.
- 마지막으로 TUN 활성화: 클라이언트에 필요한 서비스를 설치하거나 권한을 부여한 뒤 가상 네트워크 인터페이스, 라우팅, DNS 처리 상태를 확인하세요.
# 후보 설정을 검사합니다. 상주 프록시 서비스는 시작하지 않습니다
mihomo -t -f ./candidate.yaml
# HTTP 프록시 진입점을 통해 요청합니다
curl -I --proxy http://127.0.0.1:7890 https://example.org/
# SOCKS 진입점을 통해 요청하고 대상 도메인 확인은 프록시 측에서 처리합니다
curl -I --proxy socks5h://127.0.0.1:7890 https://example.org/Windows에서는 curl.exe를 사용해 curl을 명시적으로 실행하면 구버전 PowerShell에서 같은 이름의 별칭이 간섭하는 일을 피할 수 있습니다. 테스트할 때는 대상 주소를 확인하려는 사이트로 바꾸고 연결 기록에서 출구를 확인하세요. 위의 최소 설정은 직접 연결만 하므로 원격 노드가 사용 가능하다는 것을 입증하지 않습니다.
-t 검사는 전체 인터넷 연결 테스트와 다릅니다. 외부 규칙, 노드 provider, 로컬 데이터베이스 파일, 상대 경로는 별도로 확인해야 합니다. 명령줄과 클라이언트는 작업 디렉터리가 다를 수 있으므로 수동 테스트에서 파일을 찾지 못하더라도 YAML 내용이 잘못된 것은 아닐 수 있습니다.
자주 묻는 질문과 코어 선택
기존 Clash YAML을 mihomo에서 그대로 사용할 수 있나요?
기본 노드·정책 그룹·규칙 구조는 대체로 유지할 수 있지만, 먼저 설정을 검사한 뒤 DNS, TUN, 외부 리소스를 확인해야 합니다. 원본 Premium의 스크립트 같은 전용 기능이 동일하게 구현된다고 가정할 수는 없습니다. 클라이언트가 실제 실행 설정을 변경하는지도 확인하세요.
클라이언트에 Meta라고 표시되면 mihomo로 직접 바꿔야 하나요?
이름만 보고 교체할 필요는 없습니다. 실제 코어 버전과 프로젝트 출처부터 확인하세요. 인터페이스에 이전 이름이 남아 있을 수 있습니다. 클라이언트가 제공하는 코어 업데이트 경로를 우선 사용하세요. 직접 교체하면 실행 파일 경로와 권한, 클라이언트 인터페이스 호환성도 고려해야 합니다.
코어를 바꾸면 속도가 빨라지나요?
코어는 프로토콜 지원, 연결 동작, 리소스 사용량에 영향을 줄 수 있지만 노드 대역폭이나 통신사 네트워크 품질을 직접 개선하지는 않습니다. 비교할 때는 노드, 대상 주소, 네트워크 연결 방식, 테스트 시간을 동일하게 유지하고 지연 시간·처리량·실패율을 함께 살펴보세요. 한 번의 속도 측정 차이를 일반적인 결과로 단정하지 마세요.
TUN을 지원하는 코어인데도 앱 트래픽을 처리하지 못하는 이유는 무엇인가요?
코어 지원은 필요조건일 뿐입니다. 서비스 권한, 자동 라우팅, 다른 VPN과의 라우팅 충돌, DNS 요청이 예상한 경로로 들어오는지 확인해야 합니다. 명시적 프록시는 작동하지만 TUN이 실패한다면 트래픽 처리 경로를 먼저 점검하세요. 노드를 바로 바꾸거나 노드 인증 매개변수를 수정하지 마세요.
최종 선택은 필요한 설정에서 거꾸로 결정하세요. 먼저 노드 프로토콜을 나열하고 규칙·DNS·트래픽 처리 요구사항을 정리한 뒤, 필요한 mihomo 버전과 권한 관리 기능을 제공하는 클라이언트를 선택합니다. 설정 항목의 의미는 기술 참고 자료에서 더 확인할 수 있습니다. 처음 배포할 때는 가이드에 따라 구독 가져오기와 명시적 프록시 테스트를 먼저 마친 다음 규칙과 TUN을 단계별로 추가하세요.