mihomo 코어와 기존 Clash의 차이: Mac 클라이언트 기능 비교

코어, 그래픽 클라이언트, 구독을 구분하기

Mac에서 Clash 클라이언트를 선택할 때는 먼저 실제로 어떤 코어가 실행되는지 확인해야 합니다. 그래픽 클라이언트는 메뉴 막대 접근, 구독 관리, 시스템 프록시 전환, 권한 요청을 담당하고, 코어는 설정을 해석하고 프록시 연결을 맺으며 규칙을 적용하고 DNS를 처리합니다. 인터페이스 이름이 비슷해도 지원 프로토콜까지 같은 것은 아닙니다. 클라이언트가 업데이트되어도 코어가 함께 업데이트된다는 보장은 없습니다.

mihomo는 Clash Meta 프로젝트에서 발전한 프록시 코어입니다. 이전 가이드의 Meta 설정이나 구독 서비스의 Clash Meta 출력 옵션은 대개 이 기술 계열을 가리킵니다. 다만 실제로 사용할 수 있는 설정 항목은 설치된 mihomo 버전의 지원 범위를 확인해야 합니다. 기존 Clash 공개 저장소는 2023년에 유지보수가 중단되어, 과거 설치 파일에는 이후 추가된 프로토콜이 자동으로 반영되지 않습니다.

Mac 사용자가 확인할 세 가지

클라이언트 버전: 앱 메뉴의 ‘정보’ 창에서 확인합니다. 인터페이스와 관리 기능을 파악할 때 필요합니다.
코어 버전: 클라이언트의 코어 정보 화면이나 시작 로그에서 확인합니다. mihomo 이름과 전체 버전을 기록해 두세요. 메뉴 이름과 위치는 클라이언트마다 다릅니다.
구독 출력 형식: 구독 서비스가 일반 Clash 설정을 생성하는지, Clash Meta／mihomo용 설정을 생성하는지 확인합니다. 파일 확장자가 모두 YAML이라고 해서 설정 항목까지 완전히 같은 것은 아닙니다.

기능 비교: 실제 사용에 영향을 주는 차이

비교 항목	기존 Clash	mihomo 및 Mac 사용 시 영향
기본 프록시 프로토콜	Shadowsocks, VMess, Trojan 등 널리 쓰이던 유형을 지원합니다. 지원 범위는 버전에 따라 다릅니다.	기존에 쓰이던 여러 유형을 유지하면서 새로운 프로토콜과 전송 기능을 추가로 지원합니다.
VLESS와 Reality	기존 오픈소스 코어는 이 조합을 지원하지 않습니다.	해당 노드를 처리할 수 있지만 서버 인증, 전송 방식, TLS 매개변수가 모두 일치해야 합니다.
Hysteria2와 TUIC	기존 오픈소스 코어는 이 노드 유형을 지원하지 않습니다.	해당 프로토콜을 지원합니다. 다만 네트워크에서 UDP를 허용하는지도 연결에 영향을 줍니다.
규칙과 규칙 세트	도메인, IP 등의 기본 규칙을 지원합니다. Premium에는 별도의 규칙 세트 기능도 있습니다.	논리 규칙, 매칭 조건, 규칙 세트 형식을 확장합니다. 복잡한 설정은 항목별로 지원 여부를 확인해야 합니다.
TUN 트래픽 처리	기존 오픈소스 코어와 TUN 기능이 있는 Premium을 같은 것으로 보면 안 됩니다.	TUN 설정을 지원합니다. Mac에서는 클라이언트가 서비스 설치와 권한 처리를 지원해야 합니다.
DNS와 트래픽 식별	DNS와 fake-ip 등의 기본 기능을 제공합니다.	더 다양한 DNS 정책과 스니핑 설정을 지원하지만, 기본값을 켠다고 반드시 속도가 빨라지는 것은 아닙니다.

업그레이드 효과는 필요한 기능을 기준으로 판단하세요. 기존 구독에서 일반적인 노드만 사용하고 브라우저도 시스템 프록시로 문제없이 작동한다면, 코어를 바꿔도 속도 차이가 뚜렷하지 않을 수 있습니다. 구독에 VLESS나 Hysteria2가 포함되어 있거나 더 세밀한 분기 조건이 필요하다면, 코어 지원 여부에 따라 설정을 불러올 수 있는지와 연결이 가능한지가 달라집니다.

프로토콜 확장: 새 노드를 기존 코어에서 사용할 수 없는 이유

VLESS, Reality, 전송 계층은 서로 다른 설정입니다

VLESS는 프록시 프로토콜이고, Reality는 관련 TLS 보안 옵션이며, WebSocket과 gRPC 등은 전송 방식입니다. 구독 설정의 type: vless, reality-opts, network는 각각 다른 역할을 합니다. VLESS를 지원한다고 해서 모든 Reality 설정으로 연결되는 것은 아닙니다. 공개 키, short ID, 서버 이름, 흐름 제어 매개변수가 서버 설정과 일치해야 합니다.

기존 코어에서 지원하지 않는 프록시 유형이라는 오류가 나오면 노드 표시 이름을 바꾸거나, 정책 그룹을 전환하거나, 시스템 프록시를 켜도 해결되지 않습니다. 해당 유형을 지원하는 코어로 바꾸거나 구독 서비스에 서버에서 실제 지원하는 다른 노드를 요청해야 합니다. type: vless를 억지로 vmess로 바꾸는 것은 형식 변환이 아니라 프로토콜 불일치만 일으킵니다.

Hysteria2와 TUIC은 네트워크 환경도 영향을 줍니다

이 프로토콜은 QUIC 기반이며 UDP 통신이 필요합니다. mihomo가 설정을 해석할 수 있다는 것은 프로토콜 구현이 있다는 뜻일 뿐입니다. 현재 Wi-Fi, 회사 네트워크, 상위 방화벽에서 UDP를 제한하면 연결 시간이 초과될 수 있습니다. “다른 노드는 되는데 이 유형만 실패한다면” 먼저 다른 프로토콜로 비교 테스트한 뒤 포트, 인증 정보, 네트워크 제한을 확인하세요.

불러오자마자 오류가 발생함: 먼저 코어 버전, 노드 유형, 설정 항목을 확인하세요. DNS부터 바꿀 필요는 없습니다.
설정은 불러왔지만 핸드셰이크에 실패함: 서버 매개변수, Mac 시스템 시간, 노드 연결 가능 여부를 확인하세요.
연결은 됐지만 일부 서비스가 작동하지 않음: UDP, 규칙 적용 여부, DNS, 경로 MTU를 추가로 확인하세요. 바로 코어 성능 문제로 단정하지 마세요.

규칙 확장: 기존 규칙은 유지하고 새 규칙은 의미를 확인하세요

기본적인 DOMAIN, DOMAIN-SUFFIX, IP-CIDR, MATCH는 mihomo 설정에서도 중요한 규칙입니다. 규칙은 일반적으로 위에서 아래로 적용되므로, 앞선 규칙이 연결과 일치하면 뒤에 있는 같은 종류의 규칙은 해당 연결의 출구를 결정하지 않습니다. 설정을 옮길 때는 텍스트를 그대로 보존하는 것보다 규칙 순서를 유지하는 일이 더 중요할 때가 많습니다.

논리 규칙과 프로세스 매칭

mihomo에서는 논리 조합으로 더 복잡한 조건을 표현할 수 있으며, 프로세스 관련 매칭도 지원합니다. 도메인, 네트워크 유형, 프로세스 등의 조건을 조합할 때 유용하지만, 프로세스 식별은 운영체제와 트래픽 유입 경로, 실행 권한에 따라 달라집니다. Mac에서는 규칙에 PROCESS-NAME을 적었다고 모든 연결에서 프로세스 정보가 정확히 잡히는 것은 아닙니다. 연결 상세 화면에서 실제 식별 결과를 확인하세요.

정책 그룹 이름도 설정에서 참조되는 항목입니다. 규칙 끝에 적은 정책 이름이 설정에 실제로 있어야 합니다. 구독 업데이트로 그룹 이름이 바뀌었는데 로컬 규칙에는 이전 이름이 남아 있으면 설정 검증에 실패할 수 있습니다. 설정을 옮길 때는 규칙 섹션만 복사하지 말고 rules, proxy-groups, proxies를 함께 확인하세요.

규칙 세트는 mihomo만의 기능이 아닙니다

rule-providers를 사용하면 규칙을 별도 리소스로 분리한 뒤 RULE-SET으로 불러올 수 있습니다. Clash Premium에도 비슷한 기능이 있으며, mihomo는 형식과 규칙 표현 범위를 확장했습니다. 규칙 세트를 확인할 때는 동작 유형, 콘텐츠 형식, 다운로드 주소, 실제 파일 내용을 함께 살펴봐야 합니다.

설정 항목: TUN, DNS, 스니핑을 각각 옮기세요

TUN은 규칙 모드나 전역 프록시와 다릅니다

TUN은 가상 네트워크 인터페이스를 통해 라우팅 대상 트래픽을 받아들입니다. 규칙 모드는 트래픽을 받은 뒤 어떤 출구를 선택할지 결정합니다. TUN을 켜도 규칙에 따라 트래픽을 직접 연결할 수 있습니다. ‘전체 트래픽 처리’는 트래픽 유입 범위에 관한 표현이지, 모든 사이트가 같은 프록시 노드를 거친다는 뜻은 아닙니다.

macOS에서는 tun.enable, tun.auto-route, tun.dns-hijack 등의 항목을 클라이언트의 서비스 관리와 함께 설정해야 합니다. 일부 클라이언트는 실행 설정을 생성하는 과정에서 이러한 항목을 수정합니다. 설정을 옮길 때 먼저 일반 시스템 프록시가 작동하는지 확인하고 TUN은 따로 켜면 노드 문제와 권한·라우팅 문제를 구분하기 쉽습니다.

DNS: fake-ip를 유지한다면 제외 항목도 확인하세요

dns.enhanced-mode의 fake-ip는 도메인에 가상 주소를 할당하고 코어가 그 매핑을 관리하는 기능입니다. 일반적인 공용 DNS 주소가 아닙니다. 기존 Clash에도 같은 방식이 있었습니다. mihomo는 주로 정책과 처리 옵션을 확장했으므로 DNS 모듈 전체를 새 기능으로 보면 안 됩니다.

기존 설정에 fake-ip-filter가 있다면 옮길 때 필요한 로컬 도메인 제외 규칙을 유지하고, 현재 버전에서 필터 모드를 어떻게 해석하는지 확인하세요. LAN 기기 이름을 확인할 수 없거나, 시스템 로그인 포털 인증에 실패하거나, 일부 앱이 오작동한다면 DNS 로그를 함께 살펴보세요. 모든 도메인을 제외 목록에 넣는 것은 피해야 합니다.

스니핑: 도메인 식별을 보조하며 HTTPS 본문을 복호화하지 않습니다

sniffer는 관찰 가능한 프로토콜 핸드셰이크 정보를 바탕으로 대상 도메인을 식별하는 데 도움을 줍니다. 모든 연결의 도메인을 알아내는 기능도, 루트 인증서를 설치해 트래픽을 복호화하는 기능도 아닙니다. 암호화된 핸드셰이크 방식, 앱 동작, 프로토콜 차이에 따라 식별 결과가 달라집니다. 기존 설정을 옮길 때 ‘기능을 빠짐없이 켜겠다’며 모든 스니핑 옵션을 한꺼번에 활성화하지 마세요.

기존 설정을 그대로 쓸 수 있을까? 세 단계로 확인하세요

일반적인 노드, 기본 정책 그룹, 기존 규칙을 사용하는 Clash 설정은 대부분 이전 작업의 출발점으로 삼을 수 있습니다. 하지만 ‘YAML을 파싱할 수 있음’, ‘코어가 설정 항목을 받아들임’, ‘앱에서 실제로 네트워크를 정상 사용함’은 서로 다른 단계입니다. 클라이언트에 가져오기 성공이라고 표시된 것만 보고 검증을 끝내면 안 됩니다.

구조 단계: 들여쓰기, 중복 키, 목록 형식을 확인합니다. YAML 들여쓰기에는 공백을 사용하고, 특수 문자가 포함된 비밀번호와 이름은 올바르게 따옴표로 묶어야 합니다.
코어 단계: 노드 프로토콜, 규칙 유형, 항목 조합이 현재 버전과 호환되는지 확인합니다. 일부 알 수 없는 항목은 무시될 수 있으므로, 검증을 통과해도 모든 기능이 작동한다는 뜻은 아닙니다.
실행 단계: 실제 사용 중인 설정, 수신 포트, DNS 결과, 연결에 적용된 정책을 확인해 그래픽 클라이언트가 설정을 덮어쓰는 영향을 배제합니다.

로컬에서 설정 검증하기

실행 가능한 mihomo 파일과 로컬 설정을 준비했다면 터미널에서 해당 디렉터리로 이동해 아래 두 명령을 실행할 수 있습니다. 예시의 파일명 mihomo와 config.yaml은 실제 파일에 맞게 바꾸세요. 그래픽 클라이언트를 사용한다면 앱에서 제공하는 설정 검사 기능을 우선 사용하고, 앱 패키지 내부 파일은 수정하지 않아도 됩니다.

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

첫 번째 명령은 실제 실행 중인 코어 버전을 확인하고, 두 번째 명령은 해당 코어에서 설정을 불러올 수 있는지 검사합니다. 이 명령만으로 원격 노드, 규칙 세트 다운로드, 웹사이트 접속이 모두 정상인지 확인할 수는 없습니다. 원격 리소스에는 네트워크 연결과 로컬 캐시도 영향을 주므로, 실행 후 로그도 확인해야 합니다.

구독 업데이트와 로컬 수정 사항을 따로 보관하세요

구독을 다운로드하며 생성된 파일을 직접 수정하면 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다. 구독 원본을 보관하고 클라이언트가 지원하는 오버라이드나 병합 기능으로 로컬 규칙을 추가하는 편이 안전합니다. 클라이언트마다 병합 순서가 다르므로 최종 실행 설정을 확인해 규칙이 끝에 추가됐는지 앞부분에 삽입됐는지 살펴보세요.

Mac 이전 절차: 시스템 프록시부터 확인한 뒤 TUN 테스트

되돌릴 수 있도록 설정을 보관합니다. 현재 구독과 로컬 오버라이드를 내보내고, 시스템 프록시 포트, 정책 그룹 선택, 이전 코어 버전을 기록하세요. 이전 작업을 시작하기 전에 기존 클라이언트를 종료해 두 프로세스가 포트를 차지하거나 시스템 프록시를 동시에 변경하지 않도록 합니다.
칩과 설치 파일을 확인합니다. Apple 메뉴 → ‘이 Mac에 관하여’에서 ‘칩’ 또는 ‘프로세서’를 확인하세요. Apple 실리콘 Mac에는 보통 arm64 설치 파일을, Intel Mac에는 x64 설치 파일을 사용합니다. 아키텍처에 따라 프로그램 실행 방식은 달라지지만 YAML의 기본 문법은 달라지지 않습니다.
설정을 가져오고 로그를 확인합니다. 지원하지 않는 프록시 유형, 찾을 수 없는 정책 그룹, 규칙 세트 로드 오류부터 해결하세요. 이 단계에서는 TUN, 스니핑, 복잡한 DNS 오버라이드를 동시에 켜지 마세요.
시스템 프록시를 확인합니다. macOS Ventura 13 및 이후 버전에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’로 이동할 수 있습니다. 주소와 포트가 클라이언트에서 실제로 수신 대기 중인 값과 일치하는지 확인하세요.
규칙 적용을 확인합니다. 직접 연결되어야 하는 사이트와 프록시를 거쳐야 하는 사이트에 각각 접속한 뒤, 클라이언트의 연결 화면에서 일치한 규칙과 출구를 확인하세요. 웹페이지가 열린다는 사실만으로 트래픽 분기가 올바르다고 볼 수는 없습니다.
필요한 경우 TUN을 켭니다. 클라이언트가 요청하는 권한을 부여하거나 서비스를 설치한 뒤 터미널, 다른 앱, LAN 접속을 테스트하세요. 문제가 생기면 먼저 TUN을 끄고 시스템 프록시 사용 결과와 비교합니다.

포트를 명시해 테스트하고 터미널 동작을 코어 오류로 오해하지 마세요

아래 예시는 현재 설정에서 혼합 프록시 포트가 7890이라고 가정합니다. 클라이언트에 다른 포트가 표시되면 실제 포트로 바꾸세요. 이 명령은 HTTP 프록시를 명시적으로 지정하므로 터미널이 macOS 시스템 프록시 설정을 읽는지 여부와 관계없이 테스트할 수 있습니다:

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

HTTP 응답을 받았다면 이 요청이 명시된 프록시를 거쳐 목적지에 도달했다는 뜻입니다. 하지만 모든 앱의 트래픽이 처리되는지, 요청이 원격 노드를 사용했는지는 이것만으로 확인할 수 없습니다. 출구는 규칙에 따라 결정됩니다. 127.0.0.1:7890에 연결할 수 없다는 메시지가 나오면 구독을 바로 바꾸지 말고 로컬 수신 여부와 포트부터 확인하세요.

TUN을 테스트할 때는 프록시를 명시하는 옵션 없이 요청을 보내고, 터미널에 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY가 설정되어 있는지도 확인하세요. 그렇지 않으면 환경 변수에 지정된 프록시를 계속 거칠 수 있어 테스트 결과가 달라집니다.

mihomo 업그레이드가 필요한지 판단하는 방법

구독에서 새 프로토콜을 사용함: 코어가 VLESS, Reality, Hysteria2 또는 TUIC을 지원하는지, 해당 설정 항목이 현재 버전에 맞는지 먼저 확인하세요.
더 많은 앱의 트래픽을 처리해야 함: 코어 기능표만 보지 말고 macOS TUN 서비스 관리, 권한 안내, 문제 발생 후 복구 기능도 비교하세요.
복잡한 트래픽 분기가 필요함: 논리 규칙, 프로세스 식별, 규칙 세트 형식을 확인하고 주요 규칙은 실제 접속으로 테스트하세요.
현재 사용 환경이 안정적임: 먼저 백업하고 기존 검증 목록을 보존한 뒤 이전하세요. 코어 업데이트만으로 노드 품질, 네트워크 환경, 설정 오류를 해결할 수는 없습니다.

Mac 사용자의 안정적인 업그레이드 절차는 그래픽 클라이언트에서 실제 사용하는 코어를 확인하고, 구독 형식이 맞는지 확인한 뒤 설정을 검증하고 시스템 프록시, DNS, TUN을 차례로 테스트하는 것입니다. mihomo는 프로토콜과 트래픽 분기 기능을 확장하지만, 이를 실제 연결에 활용하려면 서버 설정, 클라이언트 연동, Mac의 네트워크 설정이 서로 일치해야 합니다.

설정 항목의 의미를 더 확인하려면 사이트의 프로토콜 가이드를 참고하세요. 포트 충돌이나 시스템 프록시가 복구되지 않는 문제는 도움말 센터의 해결 절차에 따라 확인할 수 있습니다.