설정 항목을 살펴보며 연결 경로를 이해하세요. 주제를 선택하면 용도와 활성화 방법, YAML 예제를 확인할 수 있습니다. 예제는 일부 구조만 보여 주므로 기존 설정에 병합해야 합니다. 프록시 그룹 이름과 규칙 대상은 일치해야 합니다.
위에서부터 규칙을 확인하고 정책에 따라 연결
규칙 모드에서는 rules를 위에서부터 확인하며, 조건에 맞는 항목을 찾으면 해당 정책을 적용하고 다음 규칙은 확인하지 않습니다. 도메인 접미사 규칙은 같은 서비스의 하위 도메인을 처리할 때, IP 규칙은 알려진 주소 대역을 지정할 때 유용합니다. MATCH는 나머지 연결을 처리합니다. 별도로 처리할 규칙을 먼저 배치한 뒤 지역 규칙과 최종 정책을 추가하세요. mihomo는 기존 Clash 규칙 문법을 이어받으면서 규칙 기능을 확장했습니다. 이전 설정을 옮길 때는 사용 중인 규칙 유형과 데이터 파일이 여전히 호환되는지 확인하세요. 아래 예제의 PROXY는 프록시 그룹 이름이므로 설정에 먼저 정의해야 합니다. 규칙만 복사해서 바로 실행할 수는 없습니다.
프록시 그룹을 사용하면 규칙 대상과 실제 연결 출구를 분리할 수 있어, 출구를 바꿀 때 규칙을 일일이 수정하지 않아도 됩니다. select는 수동 선택, url-test는 테스트 결과에 따른 출구 선택, fallback은 순서대로 사용 가능한 항목을 찾는 방식입니다. 먼저 수동 제어와 자동 전환 중 필요한 방식을 정한 뒤 그룹 유형과 후보 목록을 설정하세요. mihomo는 일반적인 구버전 프록시 그룹 구조와 호환되지만, 새 필드를 구버전 코어가 인식하지 못할 수 있습니다. 이전 설정을 옮길 때는 실제 사용 중인 코어 문서를 기준으로 확인하세요. 아래 예제는 파싱 가능한 최소 그룹을 만들기 위해 DIRECT를 사용합니다. 구독을 가져온 뒤 proxies 또는 use로 실제 연결 출구를 추가하면 규칙의 PROXY가 프록시 선택을 담당합니다.
config.yaml · proxy-groups
proxy-groups:
- name: PROXY
type: select
proxies:
- DIRECT
도메인 정보를 유지하고 DNS 경로 확인
fake-ip는 도메인에 가상 IP를 할당해 이후 연결에서도 코어가 도메인 정보를 유지하도록 합니다. 이를 통해 도메인 규칙을 적용할 수 있습니다. dns를 활성화한 뒤에는 앱의 DNS 요청이 실제로 코어를 거치는지도 확인해야 합니다. enhanced-mode만 변경해도 모든 시스템 DNS 요청이 자동으로 전달되는 것은 아닙니다. 구형 코어보다 mihomo는 DNS 정책 옵션이 다양하지만, 출처가 불분명한 설정을 통째로 가져오지는 마세요. 로컬 네트워크 서비스나 특정 앱에서 호환성 문제가 생기면 도메인별 fake-ip-filter를 설정하고 캐시도 확인하세요. 아래는 기본 구조만 보여 주며, 상위 DNS 서버는 사용 중인 네트워크에서 접속 가능한 곳을 선택해야 합니다.
TUN은 가상 네트워크 인터페이스로 트래픽을 처리하며, 시스템 프록시 설정을 따르지 않는 프로그램에 적합합니다. 데스크톱에서는 보통 관리자 권한이나 클라이언트 서비스 모드가 필요하고, 모바일에서는 시스템 VPN 인터페이스를 사용합니다. 활성화하기 전에 일반 프록시 연결부터 확인하고, 자동 라우팅과 DNS 가로채기를 단계적으로 켜세요. 그래야 연결 출구 문제를 라우팅 문제로 오인하지 않습니다. 구형 코어, 클라이언트, 운영체제에 따라 TUN 구현 방식은 다릅니다. 설정 파일에 tun이 있어도 현재 프로그램에서 반드시 사용할 수 있는 것은 아닙니다. 활성화 후 로컬 네트워크 접속에 문제가 생기면 클라이언트를 반복해서 재설치하기보다 라우팅, 네트워크 어댑터, 다른 VPN과의 충돌을 확인하세요.
전체 설정 구독, proxy-providers, rule-providers는 서로 다른 종류의 데이터입니다. 전체 구독은 프록시, 그룹, 규칙을 덮어쓸 수 있고, 프록시 모음은 연결 출구만 제공하며, 규칙 모음은 매칭 조건만 제공합니다. 이를 분리해 관리하면 로컬 정책은 유지하면서 필요한 데이터만 업데이트할 수 있습니다. mihomo는 여러 규칙 모음 형식을 지원하지만 구형 코어는 모든 형식과 필드를 인식하지 못할 수 있으므로, 이전하기 전에 behavior와 format을 확인하세요. 아래 예제는 로컬 classical 규칙 파일을 RULE-SET으로 참조합니다. 파일이 미리 존재하고 payload 목록을 포함해야 합니다. 원격 구독 주소에는 접근 권한 정보가 들어 있을 수 있으니 로그나 설정을 공유하기 전에 삭제하세요.
외부 컨트롤러 인터페이스는 패널에서 연결을 확인하고 정책을 바꾸거나 실행 상태를 조정할 때 사용합니다. 브라우저가 사용하는 프록시 포트와는 다릅니다. external-controller를 활성화한 뒤 패널에 해당 주소를 입력해야 하며, external-ui는 설정 디렉터리에 넣어 둔 패널 폴더를 가리킵니다. mihomo는 일반적인 컨트롤 인터페이스 사용 방식을 유지하지만, 새로운 기능을 지원하는 정도는 패널마다 다릅니다. 우선 루프백 주소에 바인딩해 로컬에서만 접근하게 하세요. 원격 관리가 꼭 필요하다면 인증과 네트워크 접근 범위도 설정해야 합니다. 일부 GUI 클라이언트는 컨트롤 주소와 인증 정보를 직접 관리하므로, 수동 설정과 실행 중 덮어쓰기가 충돌하지 않도록 클라이언트 설정을 우선 사용하세요.
config.yaml · controller
external-controller: 127.0.0.1:9090
external-ui: ./ui
log-level: info
운영체제에 맞는 클라이언트 선택
GUI 클라이언트는 구독 관리, 시스템 프록시 설정, 일상적인 조작을 담당하고 코어는 프로토콜, DNS 해석, 규칙 실행을 처리합니다. 기기에 적합한 클라이언트를 선택한 다음 CPU 아키텍처, 시스템 요구 사항, 설정 지원 범위를 확인하세요.
Clash Plus처럼 꾸준히 관리되는 GUI 클라이언트부터 살펴보세요. 설치 후 구독을 가져오고 시스템 프록시를 켠 다음 브라우저 연결을 확인하세요. 게임이나 스토어 앱까지 트래픽을 처리해야 한다면 TUN과 루프백 제한도 알아보세요.
Clash for Windows에서 옮길 때는 구독, 사용자 지정 규칙, 오버라이드를 먼저 백업하세요. 새 클라이언트는 설정 디렉터리와 서비스 모드가 다를 수 있으므로 기존 디렉터리 전체를 그대로 덮어쓰지 않는 것이 좋습니다. 시스템 프록시 포트도 새 클라이언트에 표시된 값을 기준으로 설정하세요.
먼저 Apple Silicon과 Intel 프로세서를 구분한 뒤 해당 설치 파일을 선택하세요. Clash Plus, Clash Verge Rev 등의 클라이언트에서 구독과 규칙을 관리할 수 있습니다. 설치 후 네트워크 권한은 시스템 안내에 따라 설정하세요.
시스템 프록시와 TUN은 권한을 부여하는 방식이 다릅니다. 브라우저는 인터넷에 연결되지만 터미널은 연결되지 않는다면 명령줄 프로그램이 프록시 환경 변수를 읽는지 먼저 확인하세요. 투명 프록시 처리가 필요한 경우에만 TUN을 활성화하고, 기존 VPN과 기본 경로를 동시에 변경하지 않도록 주의하세요.
Clash Plus, Clash Meta for Android 등의 클라이언트를 선택할 수 있습니다. 설정을 가져온 뒤 VPN 연결 생성을 허용하고 앱의 접속을 확인하세요. 설치 파일의 아키텍처는 기기에 맞아야 하므로, 잘 모르겠다면 먼저 기기 프로세서 정보를 확인하세요.
백그라운드에서 연결이 끊겼다고 해서 구독이 만료된 것은 아닐 수 있습니다. 먼저 시스템의 배터리 최적화, 백그라운드 실행, 자동 시작 권한을 확인한 뒤 무선 네트워크를 전환했을 때 연결이 복구되는지 살펴보세요. 한 번에 설정 하나씩 변경하면 시스템의 앱 종료와 연결 경로 변경 중 무엇이 원인인지 파악하기 쉽습니다.
데스크톱에서는 Clash Verge Rev 또는 FlClash를, 서버와 라우터에서는 mihomo 코어 패키지를 사용할 수 있습니다. 설치 전에 배포판의 패키지 형식과 CPU 아키텍처를 확인하고 설정 디렉터리와 실행 권한을 지정하세요.
명령줄에서 실행할 때는 먼저 포그라운드로 실행해 로그를 확인하고 설정이 정상적으로 로드되는지 확인한 뒤 서비스 관리자를 사용하세요. 일반 사용자에게 필요한 권한은 포트 수신, TUN 장치 생성, 라우팅 변경에 따라 다릅니다. 문제를 찾을 때는 설정 오류와 권한 오류를 구분해 처리하세요.
코어, 클라이언트, 설정 출처를 구분해 이해하세요. 프로젝트 소스 코드는 구현 방식을 보여 주고 릴리스 노트는 변경 사항을 기록합니다. 실제 조작 방법은 클라이언트 인터페이스에 따라 달라집니다.
Clash Meta와 mihomo의 관계
Clash Meta는 이 코어 프로젝트에서 초기에 사용한 이름이며, 현재 프로젝트는 mihomo라는 이름으로 개발을 이어가고 있습니다. 튜토리얼을 검색하면 이전 이름과 저장소 경로, 클라이언트별로 다른 스크린샷을 볼 수 있습니다. 설정이 호환되는지 판단할 때는 클라이언트 이름에 Meta가 들어 있는지가 아니라 실제 실행 중인 코어와 해당 문서를 확인하세요. GUI와 코어 업데이트 시점도 서로 다를 수 있습니다.
클라이언트와 구독 서비스는 다릅니다
mihomo는 프록시 프로토콜, DNS 해석, 분기 규칙을 실행하며 GUI 클라이언트는 그 위에 설정 관리, 시스템 연동, 사용자 인터페이스를 제공합니다. 구독은 사용자가 직접 선택한 서비스나 자체 구축한 설정에서 가져옵니다. 클라이언트를 설치해도 사용할 수 있는 연결 출구가 자동으로 생기지는 않으며, 소스 코드가 공개되어 있다고 구독 정보까지 공개되는 것도 아닙니다. 이 사이트는 다운로드 목록과 한국어 사용 안내를 제공하며, 각 프로젝트의 개발과 배포, 문의 대응은 해당 프로젝트의 관리자가 담당합니다.
소스 코드와 릴리스 노트에서 변경 사항 확인
코어 소스 코드는 MetaCubeX/mihomo 저장소에서 확인할 수 있으며, 라이선스는 저장소의 LICENSE 파일을 기준으로 합니다. 커밋 기록, 이슈 논의, 릴리스 노트를 살펴보면 특정 필드의 지원 여부나 동작 변경을 확인하는 데 도움이 됩니다. 아래 명령을 복사하면 읽기용 소스 코드를 내려받을 수 있습니다. 일반 사용자가 GUI 클라이언트를 설치하는 데 필요한 절차는 아니며, 구독 가져오기나 네트워크 설정을 대신하지도 않습니다.
업데이트 전에 설정을 기록하고 이후 연결 경로를 확인
클라이언트나 코어를 업데이트하기 전에 현재 설정과 로컬 오버라이드를 백업하고 변경 사항을 확인하세요. 업데이트 후에는 설정이 정상적으로 로드되는지 확인한 다음 DNS, 규칙 적용, 연결 출구를 각각 점검하세요. 문제가 발생하면 운영체제, 클라이언트 이름, 코어 정보, 최소 재현 절차를 기록하세요. 로그를 공유하기 전에는 구독 주소, 인증 정보, 개인 도메인을 삭제해야 합니다. 설정 전체를 캡처하는 것보다 재현 절차를 명확히 정리하는 편이 문제를 찾는 데 도움이 됩니다.
소스 코드 공개
MetaCubeX / mihomo
코어 구현, 설정 변경, 커뮤니티 논의를 확인하세요. 데스크톱과 모바일 클라이언트의 기능 지원은 각각 따로 확인해야 합니다.