Mihomo
Mihomo는 Clash Meta라는 이름으로도 불렸던 프록시 커널로, 프로토콜 연결, 규칙 매칭, DNS 처리와 트래픽 전달을 담당합니다. GUI 클라이언트는 커널과 별개로 설정 관리 및 조작 인터페이스를 제공하는 앱입니다. 호환성 문제를 해결할 때는 앱 이름만 보지 말고 클라이언트 버전과 실제 실행 중인 커널 버전을 모두 확인해야 합니다.
커널 및 클라이언트 안내 보기 →MIHOMO / GLOSSARY
Mihomo 용어집
설정, 프로토콜 및 네트워크 스택
클라이언트 설정과 YAML 필드를 함께 살펴보세요. 먼저 커널, 노드, 정책 그룹의 차이를 익힌 다음 요청이 규칙, DNS, 라우팅을 거치는 과정을 이해할 수 있습니다.
커널 및 설정 파일
이 용어들은 설정을 실행하는 주체와 구성 방식, 원격 콘텐츠를 클라이언트로 가져오는 방법을 설명합니다.
YAML
YAML은 Mihomo에서 사용하는 설정 형식으로, 들여쓰기로 계층을 표현하고 키-값 쌍과 목록으로 필드를 구성합니다. 들여쓰기에는 공백을 사용해야 하며 불리언, 숫자, 문자열도 각 필드의 요구 사항에 맞춰야 합니다. 편집 후 구문 오류가 발생하면 오류가 표시된 줄 주변의 들여쓰기, 콜론, 따옴표부터 확인하세요. 구문 분석에 성공해도 필드 조합이 유효하다는 뜻은 아닙니다.
설정 파일 관리 방법 보기 →구독 링크
구독 링크는 클라이언트가 노드 목록이나 전체 설정을 가져오는 주소이며, 응답 형식에 따라 가져오는 방법이 달라집니다. 링크에 노드만 포함된 경우도 있고 정책 그룹, 규칙, DNS 설정까지 들어 있는 경우도 있으므로 주소 모양만 보고 판단할 수 없습니다. 구독 업데이트는 원격 콘텐츠를 다시 가져오는 기능이지 노드 문제를 해결하는 만능 방법이 아닙니다. 링크에 접속 인증 정보가 포함될 수 있으므로 공개된 스크린샷이나 로그에 노출하지 마세요.
구독 가져오기 및 업데이트 보기 →프록시 프로바이더
프록시 프로바이더는 proxy-providers로 정의하며, 로컬 파일이나 원격 주소에서 노드 목록을 불러올 수 있습니다. 정책 그룹은 use로 프로바이더를 참조해 노드 소스와 트래픽 분배 구성을 따로 관리합니다. 프로바이더 업데이트가 성공한 뒤에도 정책 그룹에서 실제로 참조하는지 확인해야 합니다. 프로바이더만 정의해 두어도 기존 규칙의 출구가 자동으로 바뀌지는 않습니다.
프록시 프로토콜 및 노드 매개변수
프로토콜은 클라이언트와 서버가 연결하는 방식을 결정합니다. 프로토콜 이름만으로 회선 품질을 판단할 수 없으며, 필요한 인증 및 전송 매개변수를 대신하지도 않습니다.
노드
노드는 프록시 연결 대상을 설명하는 매개변수 모음으로, 보통 프로토콜 유형, 서버 주소, 포트, 인증 정보를 포함합니다. 일부 프로토콜에는 전송 및 TLS 설정도 필요합니다. 노드 이름은 UI와 설정에서 참조하는 식별자일 뿐 실제 출구 지역을 증명하지 않습니다. 노드 연결에 실패하면 표시 이름만 바꾸지 말고 로그를 통해 인증, 도메인 조회, 서버 연결 가능 여부를 확인하세요.
Shadowsocks
Shadowsocks는 지정한 암호화 방식과 비밀번호로 프록시 연결을 설정하며, Mihomo에서는 type: ss로 지정합니다. 클라이언트와 서버가 호환되는 암호화 방식을 사용해야 하며, 방식에 따라 플러그인 매개변수가 필요할 수도 있습니다. UDP를 전달할 수 있지만 실제 사용 가능 여부는 양쪽 지원, 노드 설정, 중간 네트워크에 따라 달라집니다. 프로토콜 이름만으로 판단하지 마세요.
VLESS
VLESS는 UUID로 인증하며, 프로토콜 자체로는 콘텐츠를 암호화하지 않습니다. 보통 TLS나 REALITY 같은 방식과 함께 사용합니다. 실제 연결에는 전송 방식, 서버 이름, 흐름 제어 설정 등이 필요할 수 있으며, 이 매개변수는 서버와 일치해야 합니다. 서버 주소와 UUID만으로는 노드 설정을 완전히 복원하기 어려우므로 가져올 때 제공업체가 안내한 나머지 필드도 유지하세요.
Trojan
Trojan은 보통 TLS 연결로 프록시 트래픽을 전송하고 비밀번호로 인증합니다. 비밀번호가 맞아도 연결이 반드시 성공하는 것은 아닙니다. 인증서 유효성, 서버 이름, 전송 방식도 핸드셰이크에 영향을 줍니다. 인증서 오류가 발생하면 먼저 시스템 시간과 노드 매개변수를 확인하세요. 인증서 검증을 끄면 신원 확인이 약해지므로 장기적인 해결 방법으로 사용해서는 안 됩니다.
Hysteria2
Hysteria2는 QUIC 기반 프록시 프로토콜로, 하위 연결에 UDP가 필요합니다. 설정의 대역폭 매개변수는 혼잡 제어 관련 용도이며 해당 속도를 보장하지 않습니다. 현재 네트워크에서 UDP를 제한하면 웹 트래픽이 TCP를 사용하더라도 프록시 연결을 설정하지 못해 실패할 수 있습니다. 이때는 네트워크 제한과 서버 상태를 확인하세요.
TUIC
TUIC는 TCP와 UDP 트래픽을 전달할 수 있는 QUIC 기반 프록시 프로토콜입니다. 인증 정보, 프로토콜 버전, 혼잡 제어 설정이 서버와 호환되어야 하며, 다른 QUIC 프로토콜의 설정을 그대로 적용할 수는 없습니다. 테스트할 때는 하위 계층 핸드셰이크 실패와 특정 트래픽 전달 실패를 구분하세요. 전자는 UDP 연결 가능성을 먼저 확인하고, 후자는 규칙과 전달 설정도 살펴봐야 합니다.
WireGuard
WireGuard는 UDP로 통신하고 공개 키와 개인 키로 상대를 식별하는 터널 프로토콜이며, Mihomo에서 아웃바운드로 설정할 수 있습니다. 주소, 공개 키, 엔드포인트, MTU 등의 매개변수는 연결과 데이터 전송에 영향을 주며 개인 키는 민감한 설정입니다. WireGuard를 아웃바운드로 추가해도 시스템의 모든 연결이 이 터널을 통과하는 것은 아닙니다. 실제 경로는 트래픽 가로채기와 분배 규칙에 따라 달라집니다.
규칙 및 라우팅
먼저 요청이 어떤 규칙과 일치했는지 확인하고, 그 규칙이 어느 정책 그룹을 가리키는지 살펴보세요. 마지막으로 그룹에서 실제로 선택된 노드를 확인해야 합니다.
규칙 기반 라우팅
규칙 기반 라우팅은 규칙 모드에서 설정 순서에 따라 요청의 처리 대상을 선택하는 방식입니다. 대상은 정책 그룹, 특정 프록시, DIRECT 같은 내장 처리 방식일 수 있으며, 먼저 일치하는 규칙이 경로를 결정하는 경우가 많습니다. 특정 사이트가 잘못된 경로로 연결되면 노드 목록에서 계속 바꾸기보다 실제로 일치한 규칙을 확인한 뒤 규칙 순서를 조정하세요.
정책 그룹
정책 그룹은 여러 노드나 다른 정책 그룹을 하나의 참조 가능한 대상으로 묶으며 proxy-groups로 정의합니다. 수동 선택, 자동 테스트, 장애 조치 등이 일반적인 유형이며 유형에 따라 출구 선택 방식이 달라집니다. 규칙이 정책 그룹과 일치해도 최종 노드는 그룹의 상태에 따라 달라집니다. 따라서 규칙 이름과 현재 선택된 노드 이름이 서로 다를 수 있습니다.
IP 지리 규칙
GEOIP는 지리 데이터베이스에 등록된 대상 IP의 지역을 기준으로 매칭하며, 웹페이지 언어나 웹사이트 운영 회사의 등록지를 기준으로 삼지 않습니다. 데이터베이스 업데이트가 늦을 수 있고 CDN이나 공유 인프라 때문에 예상과 다른 결과가 나올 수도 있습니다. 도메인 요청은 규칙에 들어가기 전에 DNS 조회가 필요할 수 있으며, no-resolve 설정은 매칭을 위한 조회 여부에 영향을 줍니다.
도메인 접미사 규칙
DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인을 매칭합니다. 예를 들어 example.com 규칙은 해당 도메인의 하위 도메인에도 적용될 수 있습니다. 임의의 문자열 포함 여부를 검사하는 규칙이 아니며 DOMAIN-KEYWORD와 의미가 다릅니다. 규칙이 적용되려면 커널이 해당 도메인 정보를 알아야 합니다. IP 주소로 직접 접속하거나 도메인 연관 정보가 없으면 반드시 규칙과 일치한다고 볼 수 없습니다.
기본 규칙
MATCH는 앞선 규칙과 일치하지 않은 요청을 처리하며 보통 규칙 목록의 마지막에 둡니다. 지정한 정책 그룹이나 처리 방식에 따라 나머지 연결의 경로가 결정되며, 자동으로 모든 트래픽을 프록시하는 것은 아닙니다. 너무 앞에 두면 뒤에 있는 규칙이 적용되지 않을 수 있으므로 새 규칙을 추가할 때 순서를 확인하세요.
DNS 및 네트워크 스택
DNS 조회, 트래픽 가로채기, 출구 선택은 각각 별개의 단계입니다. 한 단계의 필드를 수정해도 다른 단계의 설정까지 자동으로 대체되지는 않습니다.
TUN 모드
TUN 모드는 가상 네트워크 인터페이스로 IP 패킷을 받은 다음 커널에서 연결을 처리합니다. 시스템 프록시 설정을 따르지 않는 일부 앱의 트래픽도 처리할 수 있습니다. 실제 가로채기 범위는 시스템 라우팅, 프로세스 제외 설정, 권한, 클라이언트 구현에 따라 달라집니다. 활성화한 뒤 인터넷이 끊기면 단순히 프록시 범위를 넓히는 스위치로 여기지 말고 라우팅과 DNS가 루프를 만들었는지 확인하세요.
TUN 및 라우팅 설정 보기 →Fake-IP
Fake-IP는 매핑 주소를 사용해 도메인과 연결 요청을 연관 짓는 DNS 작동 방식입니다. 앱에 전달되는 주소가 웹사이트의 실제 서버 주소가 아닐 수 있습니다. 커널은 이 매핑으로 도메인 정보를 유지한 뒤 규칙을 적용해 연결을 설정합니다. 실제 주소에 의존하는 앱은 필터 설정에 추가해야 할 수 있습니다. 매핑 주소가 보인다고 DNS 조회 실패를 뜻하지는 않으므로 실제 연결 결과도 확인하세요.
Fake-IP 및 필터 설정 보기 →redir-host
redir-host는 Fake-IP 매핑 주소 대신 실제 조회된 IP 주소를 앱에 반환하므로 실제 주소가 필요한 환경에 적합합니다. 업스트림 DNS를 올바르게 설정해야 하며 커널이 연결과 도메인을 연관 지을 수 있어야 합니다. 모드를 바꾸면 캐시와 앱 동작이 달라질 수 있으므로 다른 조건을 동일하게 유지하고 기존 연결과 DNS 캐시도 정리한 뒤 비교하세요.
DNS 모드 선택 방법 보기 →업스트림 DNS
nameserver는 Mihomo의 일반적인 도메인 조회에 사용할 업스트림 리졸버 목록을 지정합니다. 지원되는 형식에 따라 일반 DNS 또는 암호화 DNS 주소를 입력할 수 있습니다. 설정에 있는 모든 조회가 이 목록만 사용하는 것은 아닙니다. 정책 조회, 부트스트랩 조회, 프록시 서버 도메인 조회에는 다른 필드가 사용될 수 있습니다. 리졸버를 더 추가한다고 반드시 빨라지는 것은 아니므로 각 주소에 연결할 수 있는지와 조회 경로가 예상대로인지 먼저 확인하세요.
DNS 하이재킹
TUN 설정에서 DNS 하이재킹은 조건에 맞는 DNS 요청을 커널 리졸버로 리디렉션해 일관되게 처리하는 것을 뜻합니다. 요청을 가로채는 동작을 설명하는 용어이지 업스트림 리졸버를 바꾸는 것과 같은 의미는 아닙니다. 일반 DNS 포트 매칭만으로 앱 내부의 모든 암호화 DNS를 가로챌 수는 없으므로 앱 설정, 라우팅, 실제 요청 형식을 함께 확인해야 합니다.
DNS 요청 가로채기 설정 보기 →DNS 유출
DNS 유출은 도메인 조회가 예상과 다른 리졸버나 네트워크 경로를 통해 전송되어 접속 의도가 노출될 수 있는 현상입니다. 브라우저의 보안 DNS, 시스템 리졸버, 기타 네트워크 서비스가 조회에 관여할 수 있으므로 웹 트래픽의 출구 IP만으로는 정확히 판단하기 어렵습니다. 테스트 전에 예상되는 DNS 경로를 정한 뒤 조회 로그와 출구를 함께 확인하세요. 리졸버가 특정 지역에 있다는 사실만으로 DNS 유출이 발생했다고 단정할 수 없습니다.
DNS 문제 해결 방법 보기 →클라이언트 및 플랫폼
UI에 표시되는 연결 상태, 시스템 프록시 상태, 테스트 결과는 각각 의미가 다르므로 따로 확인해야 합니다.
GUI 클라이언트
GUI 클라이언트는 설정 가져오기, 모드 전환, 노드 선택, 로그 확인 등의 인터페이스를 제공하고 커널 실행 또는 관리를 담당합니다. 클라이언트마다 설정을 병합하는 방식이 다를 수 있으며 같은 이름의 버튼도 결과 설정 필드가 완전히 같지 않을 수 있습니다. 안내를 참고할 때는 해당 앱과 플랫폼이 맞는지 먼저 확인하세요. 설정의 최종 적용 결과는 커널에 전달된 실제 실행 설정을 기준으로 판단해야 합니다.
플랫폼별 클라이언트 보기 →시스템 프록시
시스템 프록시는 운영체제에 프록시 주소와 포트를 등록하는 설정으로, 보통 해당 설정을 따르는 앱에서 사용합니다. 일부 명령줄 프로그램, 게임, 자체 네트워크 스택을 사용하는 앱은 시스템 프록시를 자동으로 사용하지 않습니다. 따라서 스위치를 켰다고 모든 트래픽이 가로채지는 것은 아닙니다. 브라우저는 되는데 특정 앱만 연결되지 않으면 구독을 바로 바꾸기보다 앱별 프록시 설정, 환경 변수, TUN을 확인하세요.
연결 및 확인 절차 보기 →지연 시간 테스트
클라이언트의 지연 시간 테스트는 보통 노드를 통해 지정된 주소에 접속해 걸린 시간을 측정하며 ICMP Ping과 같지 않을 수 있습니다. 테스트 대상, 연결 재사용, DNS, 현재 네트워크 상태에 따라 결과가 달라지므로 클라이언트 간 수치를 직접 비교하기 어렵습니다. 지연 시간이 낮아도 다운로드 대역폭이 높다는 뜻은 아닙니다. 테스트 시간 초과가 발생하면 로그를 확인해 대상에 연결할 수 없는지 프록시 연결이 실패했는지 구분하세요.
속도 테스트 및 연결 문제 보기 →VpnService
VpnService는 Android가 앱에 제공하는 VPN 서비스 인터페이스로, 클라이언트가 가상 네트워크 인터페이스를 만들고 트래픽을 받을 수 있게 합니다. 시스템 권한은 앱이 연결을 만들도록 허용받았다는 뜻이지 원격 프록시 노드를 제공하거나 노드가 작동한다는 뜻은 아닙니다. 앱별 설정, 다른 VPN 앱, 시스템 절전 정책도 실제 동작에 영향을 줄 수 있습니다. 백그라운드에서 연결이 끊기면 각각 확인해야 합니다.
모바일 시작 가이드 보기 →