MIHOMO 커널 · GPL-3.0 오픈 소스
운영체제에 맞는 클라이언트를 선택하고 규칙 기반 라우팅으로 연결을 관리하세요. 한국어 설정 가이드에서 DNS, TUN, 구독 관련 설정 항목을 확인할 수 있습니다.
“규칙에 따라 연결 경로를 선택합니다.” 도메인, 주소, 프로세스 조건을 순서대로 확인합니다.
“앱의 네트워크 연결을 처리합니다.” TUN은 시스템 프록시를 사용하지 않는 프로그램에도 연결 경로를 제공합니다.
“설정을 계층별로 관리합니다.” 노드 구독과 로컬 오버라이드는 각각 따로 업데이트합니다.
“DNS 조회부터 점검합니다.” DNS 응답과 연결 로그를 함께 확인하세요.
“운영체제에 맞춰 클라이언트를 선택합니다.” 먼저 아키텍처를 확인한 뒤 클라이언트의 지원 기능을 살펴보세요.
CONFIGURATION / 설정 기능
인터페이스는 조작을, 커널은 연결 처리를 담당합니다. 아래 예시는 mihomo 설정 항목 간의 관계를 보여 주며, 프록시 서버에 바로 연결할 수 있는 완전한 설정이 아닙니다. 실제 지원 여부는 클라이언트에서 사용하는 커널을 확인하세요.
규칙 모드에서는 rules 목록을 위에서 아래로 확인하며 조건이 일치하는 항목을 찾습니다. 도메인 접미사는 같은 서비스를 묶을 때, IP 대역은 LAN 주소를 처리할 때 적합하며, 프로세스 조건은 운영체제에서 제공하는 정보에 따라 동작합니다. 모든 트래픽을 하나의 경로로 보내는 대신 규칙 기반 라우팅을 사용하면 로컬 리소스에 직접 연결할 수 있습니다. 문제를 점검할 때는 연결 세부 정보에서 어떤 규칙이 적용됐는지 확인한 다음 해당 정책 그룹을 살펴보세요. 노드만 바꿔서는 잘못된 규칙 순서를 바로잡을 수 없습니다. 예시에서는 사설망 주소를 직접 연결하고 MATCH를 마지막에 둡니다. 프록시를 사용하려면 대상 값을 이미 정의한 정책 그룹 이름으로 바꾸세요.
mode: rulerules: - DOMAIN-SUFFIX,lan,DIRECT - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve # 프록시 경로를 사용하려면 이미 정의된 정책 그룹으로 바꾸세요 - MATCH,DIRECT시스템 프록시는 앱이 프록시 설정을 직접 읽어야 작동하지만, TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 받습니다. 사용하기 전에 클라이언트에 필요한 권한이 있는지 확인하고, 다른 VPN, 가상 머신 네트워크 인터페이스, 보안 프로그램이 라우팅을 변경하는지도 살펴보세요. auto-route는 라우팅을 자동으로 설정하고 dns-hijack은 지정된 DNS 요청을 받습니다. 두 기능은 서로 다른 문제를 해결하므로 대체할 수 없습니다. 시스템 프록시만 사용하는 것보다 TUN이 더 많은 트래픽을 처리하는 경우가 많지만, 점검해야 할 단계도 늘어납니다. 인터넷 연결이 끊기면 먼저 네트워크 가로채기를 끄고 기존 네트워크를 복구하세요. 그런 다음 로그를 확인하며 설정을 하나씩 활성화하고, 노드와 DNS, 네트워크 스택을 동시에 바꾸지 마세요.
tun: enable: true stack: mixed auto-route: true auto-detect-interface: true dns-hijack: - any:53완전한 YAML 구독에는 노드, 정책 그룹, 규칙이 함께 포함될 수 있지만, 노드 제공자는 주로 재사용 가능한 노드 목록을 관리합니다. proxy-providers로 노드 소스를 정책 그룹에 연결할 수 있습니다. 로컬 파일은 구조를 확인하기 쉽고, 원격 소스는 구독 주소를 안전하게 관리해야 합니다. 오버라이드는 클라이언트가 처리하므로 병합 순서와 배열 처리 방식이 다를 수 있습니다. 따라서 클라이언트 인터페이스의 오버라이드 파일을 모든 커널에서 지원하는 독립 설정 항목으로 간주해서는 안 됩니다. 다운로드한 설정을 매번 직접 수정하는 것보다 계층별로 관리하는 편이 로컬 설정을 유지하기 쉽습니다. 업데이트 후에는 실제 생성된 설정을 확인해 그룹 이름이 그대로 있는지, 규칙 대상이 유효한지 살펴보고 복구용 로컬 사본도 보관하세요.
proxy-providers: local-nodes: type: file path: ./providers/nodes.yamlproxy-groups: - name: Proxy type: select use: [local-nodes]DNS는 도메인에서 주소를 찾는 방식에 관여하고, 규칙은 연결 경로를 결정하며, 스니핑은 일부 프로토콜 트래픽에서 도메인 정보를 보완합니다. fake-ip는 예약된 주소 대역을 사용해 도메인과 주소를 매핑하며 원격 서버의 실제 주소를 나타내지는 않습니다. 일부 로컬 서비스는 필터 규칙을 통해 일반적인 DNS 조회를 사용하도록 설정해야 합니다. 공용 DNS 서버만 바꾸는 데 그치지 말고, 시스템 요청이 커널에 전달되는지, 상위 DNS 서버에 연결할 수 있는지, 앱이 자체 암호화 DNS를 사용하는지도 확인하세요. 스니핑으로 모든 암호화 콘텐츠를 복원할 수는 없으며, 잘못된 규칙 설정을 보완하는 용도로 사용해서도 안 됩니다. 설정을 변경한 뒤에는 새 연결로 다시 테스트하고, 필요한 경우 앱 캐시를 비워 이전 결과가 판단에 영향을 주지 않도록 하세요.
dns: enable: true listen: 127.0.0.1:1053 enhanced-mode: fake-ip fake-ip-range: 198.18.0.1/16 nameserver: [1.1.1.1, 9.9.9.9]sniffer: enable: false클라이언트는 설정 관리, 트레이 메뉴, 시스템 권한을 하나의 인터페이스에 통합하고, 커널은 프로토콜 처리와 규칙 실행을 담당합니다. 제품 이름이 비슷해도 같은 커널을 사용하거나 TUN, 프로세스 규칙, 오버라이드 기능을 똑같이 지원한다는 뜻은 아닙니다. 운영체제와 프로세서 아키텍처를 먼저 확인한 뒤 유지 관리 상태, 설정 형식, 권한 요구 사항을 비교하세요. 커널을 직접 실행하는 것보다 그래픽 클라이언트가 일상적인 전환에 편리합니다. 서버와 라우터에서는 보통 프로세스와 설정 경로를 직접 관리해야 합니다. 이전하기 전에 로컬 규칙과 정책 선택을 내보내고, 가져온 뒤에는 최종 설정을 확인하세요. 노드 목록이 표시된다는 이유만으로 모든 설정이 제대로 이전됐다고 판단해서는 안 됩니다.
mixed-port: 7890allow-lan: falsemode: rulelog-level: info# 시스템 프록시 설정은 클라이언트 또는 운영체제에서 관리합니다# 이 예시에는 원격 프록시 노드가 포함되어 있지 않습니다인터페이스에 표시되는 스위치, 디스크에 저장되는 설정, 커널이 최종적으로 불러오는 내용은 서로 다른 계층일 수 있습니다. 예를 들어 시스템 프록시는 운영체제 설정이고, mixed-port는 커널이 연결을 수신하는 포트입니다. 브라우저가 시스템 프록시를 사용할지는 브라우저 자체 동작에 따라 달라집니다. 문제를 점검할 때는 인터페이스의 연결 상태만 보지 말고 “앱 요청 → 로컬 포트 → 규칙 일치 → 정책 그룹 → 원격 경로” 순서로 확인하세요. 로그를 켠 다음 테스트 도메인에 해당하는 새 연결을 찾아 적용된 규칙과 정책을 기록하고, 그 결과에 따라 수정할 설정 항목을 결정하세요.
위 설정 예시는 구조를 설명하기 위한 것입니다. 복사하기 전에 원본 파일에 같은 항목이 중복되지 않는지 확인하고, 들여쓰기에는 공백을 사용하며 그룹 이름과 참조 이름을 일치시키세요. 구독을 업데이트하면 설정이 다시 생성될 수 있으므로, 계속 유지할 규칙은 클라이언트가 지원하는 오버라이드 방식에 넣어야 합니다. 처음 설치한다면 가이드에 따라 설정을 가져오고 동작을 확인하세요. 매개변수 의미, 병합 순서, 규칙 작성법은 설정 레퍼런스에서 확인할 수 있습니다. 역할을 나누면 한 번에 너무 많은 변수를 바꿔 문제를 파악하기 어려워지는 일을 줄일 수 있습니다.
CLIENTS / 플랫폼별 클라이언트
다운로드 페이지에서 운영체제별 클라이언트와 아키텍처 옵션, 시스템 요구 사항을 확인할 수 있습니다. 데스크톱과 모바일은 권한 모델이 다릅니다. 설정을 이전할 수는 있어도 시스템 트래픽 처리 방식은 다시 확인해야 합니다.
데스크톱에서 사용할 클라이언트를 찾는다면 Clash Plus부터 확인한 뒤 Clash Verge Rev, FlClash 등의 설정 관리 방식을 비교해 보세요. 설치 전에 시스템 아키텍처를 확인하세요. 설정을 가져온 뒤 시스템 프록시를 켜고 브라우저에서 새 연결을 만든 다음 적용된 규칙을 확인합니다. 게임이나 명령줄 도구까지 처리해야 한다면 TUN 서비스와 권한을 확인하세요. 시작 프로그램 등록은 앱 실행만 담당합니다. 시스템 프록시와 연결 모드가 복원되는지는 별도로 확인해야 합니다.
다운로드Apple Silicon용과 Intel용 설치 파일을 구분한 다음 Clash Plus, Clash Verge Rev, FlClash 중에서 선택하세요. macOS의 첫 실행 알림, 네트워크 서비스 권한, 프록시 설정은 각각 별개의 과정이므로 하나의 문제로 취급하지 마세요. 네트워크를 바꾸거나 덮개를 닫았다가 다시 연 뒤 연결에 문제가 생기면 현재 네트워크 서비스의 프록시 설정부터 확인하세요. 이전 클라이언트를 교체할 때는 구독과 오버라이드 파일을 보관하고 기존 프로세스가 종료됐는지 확인하세요.
다운로드Clash Plus, Clash Meta for Android, FlClash, Surfboard의 플랫폼 안내를 살펴보고 클라이언트를 선택할 수 있습니다. 제품마다 지원하는 설정 형식이 다를 수 있습니다. 처음 연결할 때는 Android의 VPN 권한을 확인하세요. 백그라운드에서 앱이 종료된 뒤 연결이 끊기면 배터리 최적화와 백그라운드 실행 제한을 살펴보세요. 같은 네트워크에서 먼저 앱 하나로 테스트한 뒤 앱별 라우팅을 사용할지 결정하면 백그라운드 제한을 규칙 문제로 오해하는 일을 줄일 수 있습니다.
다운로드다운로드 페이지에서 Clash Plus의 App Store 페이지와 공식 웹사이트 clashplus.io를 확인할 수 있습니다. 설치 후 클라이언트에서 설정을 가져오고 시스템 네트워크 권한을 확인한 다음 규칙 모드와 사용 가능한 연결 경로를 선택하세요. 데스크톱 설정의 프로세스 매칭, 파일 경로, 확장 항목은 그대로 적용되지 않을 수 있으므로 이전할 때 하나씩 확인해야 합니다. 구독을 가져오지 못하면 먼저 소스 형식과 링크가 유효한지 확인하세요. 개인 구독 주소를 공개 게시판에 붙여 넣지 마세요.
다운로드데스크톱 환경에서는 Clash Verge Rev와 FlClash를 비교하고 배포판에 맞는 패키지 형식을 선택하세요. 앱이 시스템 프록시를 사용할 수 있는지는 데스크톱 환경과 앱 실행 방식에 따라 달라집니다. 터미널 프로그램에서는 보통 프록시 환경 변수를 직접 설정해야 합니다. 서버나 라우터에서 사용하려면 커널 페이지로 이동해 mihomo 프로세스, 설정 디렉터리, 서비스 시작을 직접 관리하세요. TUN을 켜기 전에 라우팅과 권한을 확인하고, 원격으로 작업할 때는 복구 가능한 관리 경로를 확보하세요.
다운로드클라이언트, 설정, 원격 프록시 서비스는 각각 다른 역할을 합니다. 클라이언트는 인터페이스와 실행 환경을 제공하고, 설정은 노드와 규칙, DNS를 지정하며, 원격 서비스는 연결 경로의 접근 가능 여부를 결정합니다. 이 사이트의 플랫폼별 안내는 소프트웨어 선택을 돕기 위한 것이며, 사용 가능한 노드를 제공한다고 보장하지 않습니다. “Clash 무료 노드”를 찾는다면 출처와 이용 권한, 개인정보 보호 위험을 먼저 확인하세요. 개인 구독에는 접근 정보가 포함될 수 있으므로 스크린샷을 공유하기 전에 전체 링크와 노드 인증 정보를 가리세요. 이미 설정 파일이 있다면 먼저 가져온 뒤 로그에서 지원되지 않는 항목이 있는지 확인하세요.
처음 연결하는 것이 목적이라면 가이드에 따라 검증 과정을 단순하게 유지하세요. 설정을 선택하고 정책 그룹의 연결 경로를 지정한 다음 현재 운영체제에 맞는 프록시 진입 방식을 활성화하세요. 테스트 페이지에 접속해 새 연결을 확인하면 됩니다. 시스템 프록시나 라우팅을 변경하는 프로그램을 여러 개 동시에 실행하지 마세요. 유지 관리 상태와 기능 범위를 비교하려면 비교 리뷰를 확인하고, “연결됨”으로 표시되는데 인터넷이 되지 않으면 FAQ의 문제 해결 항목을 살펴보세요. 반복해서 재설치하는 것보다 원인을 찾기 쉽습니다.
SOURCE / 오픈 소스와 범위
확인 가능한 코드, 명확한 설정 구조, 반복 가능한 검증 절차가 신뢰의 기반입니다. 이 사이트는 한국어 자료와 설명을 제공하며, 서로 다른 클라이언트의 기능을 하나의 공통 사양으로 묶어 안내하지 않습니다.
Clash는 YAML로 노드, 정책 그룹, 규칙을 작성하는 설정 방식을 정착시켰습니다. mihomo는 이러한 규칙 기반 프록시 커널의 사용 방식을 이어받아 프로토콜, 규칙, 네트워크 가로채기 기능을 발전시켜 왔습니다. 오래된 가이드에 등장하는 Clash, Clash Meta, 최신 클라이언트 이름은 서로 다른 시기의 프로젝트를 가리킬 수 있습니다. 자료를 볼 때는 파일 확장자나 창 제목만으로 호환성을 판단하지 말고 현재 실행 중인 커널과 해당 문서를 기준으로 삼으세요. 설정 항목을 인식하지 못한다면 전체 오류 메시지와 항목 위치를 기록한 다음 커널 문서를 확인하세요.
mihomo의 코드와 GPL-3.0 라이선스는 공개 저장소에서 확인할 수 있습니다. 그래픽 클라이언트는 커널을 바탕으로 설정 가져오기, 시스템 프록시, 트레이 메뉴, 권한 서비스 등의 기능을 제공하지만 배포 방식과 라이선스, 플랫폼 지원은 프로젝트별로 확인해야 합니다. 특정 커널을 사용하는 클라이언트라고 해서 다른 클라이언트의 모든 기능까지 제공하는 것은 아닙니다. 이 사이트는 소프트웨어 다운로드와 설정 자료를 구분해 정리하여, 한 인터페이스의 설정 항목을 모든 플랫폼에 존재하는 커널 항목으로 오해하지 않도록 합니다.
클라이언트는 보통 구독을 읽은 다음 오버라이드를 적용하고 로컬 설정을 병합한 뒤, 생성된 설정을 커널에 전달합니다. 따라서 인터페이스에 표시되는 구독 내용이 실제 실행 중인 설정과 다를 수 있습니다. 문제를 찾을 때는 가져오기 성공 메시지보다 실제로 불러온 설정과 연결 로그가 더 유용합니다. 규칙 대상은 존재하는 노드나 정책 그룹을 가리켜야 하고, 제공자 이름은 참조하는 이름과 일치해야 하며, DNS 수신 주소는 시스템의 요청 경로에 맞아야 합니다. 스니핑, 프로세스 규칙, TUN을 사용할 수 있는지도 시스템 권한과 클라이언트 구현에 따라 달라집니다.
클라이언트 업데이트, 커널 업데이트, 구독 새로고침, 지리 데이터베이스 업데이트는 서로 다른 작업입니다. 소프트웨어 업데이트로 설정 항목이나 권한 동작이 달라질 수 있고, 구독 새로고침으로 노드와 정책 그룹이 바뀔 수 있으며, 규칙 세트 업데이트로 도메인 분류가 달라질 수 있습니다. 문제가 재현되도록 한 번에 한 종류의 내용만 변경하고 이전 설정을 보관하세요. 업데이트 후에는 시작 로그, 그룹 이름 참조, 자주 사용하는 서비스에 적용된 규칙을 확인하세요. 인터페이스가 열리는 것만으로 검증을 끝내지 마세요. 설치 파일 정보는 다운로드 페이지에서 확인할 수 있으며, 홈에서는 플랫폼 안내와 설정을 읽는 순서를 제공합니다.
문제가 발생하면 먼저 시스템 프록시나 TUN을 끄고 기본 네트워크가 복구되는지 확인하세요. 기본 네트워크에도 문제가 있다면 네트워크 자체를 먼저 점검해야 합니다. 기본 연결이 정상이라면 로컬 수신 포트, DNS 요청, 노드 연결 가능 여부, 적용된 규칙 순서로 확인하세요. 문제를 신고할 때는 운영체제, 클라이언트 이름, 사용 중인 커널, 개인정보를 가린 로그를 남기고 최근 변경한 설정 항목도 적어 주세요. 설정에 포함된 비밀번호, 구독 주소, 제어 인터페이스 인증 정보는 공개하지 마세요. 이렇게 기록하면 문제를 재현하기 쉽고 클라이언트 통합 문제와 커널 설정 문제도 구분할 수 있습니다.
아래 명령은 mihomo 저장소의 소스 코드를 가져옵니다. 클라이언트를 설치하거나 시스템 프록시를 활성화하지는 않습니다. 빌드 및 실행 요구 사항은 저장소 문서를 확인하세요.
git clone https://github.com/MetaCubeX/mihomo.gitNOTES / 설정 참고
설정을 가져온 뒤 실제로 겪는 문제를 바탕으로 DNS 조회 경로, 프록시 모드, 설정 항목의 관계를 나누어 설명합니다. 예시는 로컬 설정에 맞춰 사용하고, 수정 전에 원본 파일을 보관하세요.
DNS 누수의 원인과 확인 방법을 설명하고 앱 자체 DNS, 시스템 DNS, 커널 DNS의 요청 경로를 구분합니다. TUN, fake-ip, 시스템 대체 DNS 설정을 하나씩 바꿔 가며 다시 테스트하세요. 한 번의 검사 결과를 모든 앱에 적용되는 결론으로 간주하지 마세요.
문제 해결 단계 보기 →구독의 출처와 형식부터 살펴보고, 규칙 모드와 전역 모드의 차이, 정책 그룹 선택이 실제 연결 경로에 미치는 영향을 설명합니다. 시스템 프록시가 작동하지 않거나 재시작 후 연결이 복구되지 않으면 프록시 진입 방식, 권한, 로그 순서로 확인하세요.
초보자 FAQ 보기 →dns 설정을 항목별로 살펴보며 enhanced-mode, nameserver, fallback, fallback-filter의 관계를 설명합니다. DNS 조회 설정과 dns-hijack의 요청 수신 역할도 구분해 문제가 DNS 조회 단계에서 발생했는지 트래픽 가로채기 단계에서 발생했는지 판단할 수 있도록 안내합니다.
설정 가이드 보기 →