mihomo
코어와 엔진 KernelClash Meta 프로젝트가 이름을 바꾼 뒤 이어지는 코어로, 현재 Clash Verge Rev, FlClash, Clash Plus 등 주요 클라이언트가 모두 기본 내장하고 있습니다. 프로토콜 핸드셰이크, 규칙 매칭, 트래픽 전달을 담당하는 전체 체계의 엔진이며 VLESS, Hysteria2 같은 신규 프로토콜은 이것만 인식합니다. 클라이언트를 고를 때 코어가 mihomo인지부터 확인하세요.
26개 핵심 용어를 5대 분류로 나눠 정리했습니다: 코어, 프로토콜, 규칙, 구독, DNS 각 영역마다 2~4문장으로 의미와 용법, 흔한 오해까지 짚습니다. 튜토리얼이나 문제 해결 가이드를 보다가 낯선 단어가 나오면 이 페이지에서 바로 찾아보세요.
클라이언트 밑단에서 무엇이 돌고 트래픽이 어떻게 처리되는지, 이 몇 가지 용어부터 확실히 잡으세요
Clash Meta 프로젝트가 이름을 바꾼 뒤 이어지는 코어로, 현재 Clash Verge Rev, FlClash, Clash Plus 등 주요 클라이언트가 모두 기본 내장하고 있습니다. 프로토콜 핸드셰이크, 규칙 매칭, 트래픽 전달을 담당하는 전체 체계의 엔진이며 VLESS, Hysteria2 같은 신규 프로토콜은 이것만 인식합니다. 클라이언트를 고를 때 코어가 mihomo인지부터 확인하세요.
초기의 소스 비공개 Clash 코어로, 한때 Clash for Windows의 기본 엔진이었습니다. 2023년 원 프로젝트와 함께 업데이트가 중단되어 신규 프로토콜과 규칙 유형을 지원하지 않습니다. 예전 설정에서 Premium 전용 기능이 언급되면 대부분 mihomo에서 동일한 이름 또는 강화된 형태로 찾을 수 있습니다.
시스템에 가상 네트워크 카드를 만들어 모든 네트워크 트래픽을 코어로 끌어와 처리하는 동작 모드입니다. 명령줄 도구나 게임 클라이언트처럼 시스템 프록시를 무시하는 프로그램은 TUN만이 잡아낼 수 있습니다. 처음 활성화할 때는 보통 관리자 권한이나 시스템 서비스 설치가 필요하니, 켜지지 않으면 이 부분부터 확인하세요.
운영체제의 HTTP/SOCKS 프록시 설정을 Clash 로컬 리스닝 포트(흔히 7890/7897)로 지정하는 모드입니다. 시스템 프록시를 따르는 브라우저 등의 소프트웨어는 자동으로 프록시를 타지만, 따르지 않는 프로그램은 완전히 우회하므로 TUN 모드나 수동 프록시 지정으로 보완해야 합니다.
코어가 공개하는 로컬 RESTful API로, 설정에서는 external-controller로 표기하며 기본적으로 9090 계열 포트를 사용합니다. 클라이언트 패널과 웹 대시보드는 이 인터페이스로 노드 목록을 읽고 정책 그룹을 전환하며 연결과 로그를 확인합니다. 패널이 텅 비어 있다면 이 인터페이스가 점유되거나 변경되지 않았는지 먼저 확인하세요.
구독 안에 줄줄이 나열된 프로토콜 이름들이 각각 무엇인지, 한 영역에서 다 읽고 가세요
설정 파일 proxies 항목의 한 줄로 표현되는 프록시 서버 레코드로, 서버 주소, 포트, 프로토콜 종류, 비밀번호 등의 필드를 포함하는 트래픽 출구의 최소 단위입니다. 노드 이름 앞의 지역 표기는 서비스 제공자가 붙인 명칭일 뿐이며, 실제 소재지는 직접 테스트해봐야 확실합니다.
오래된 암호화 프록시 프로토콜로, 구조가 단순하고 전송 오버헤드가 작아 서버, 포트, 암호화 방식, 비밀번호 네 가지만 있으면 설정이 끝납니다. Clash 계열 클라이언트가 모두 지원하며 구독 안에서 기본형 프로토콜로 자주 등장하고, 안정성 평가도 꾸준히 좋습니다.
V2Ray 생태계의 네이티브 프로토콜로, UUID를 인증 수단으로 사용하며 WebSocket, TLS와 함께 다단계 전송을 구성하는 경우가 많습니다. 필드가 Shadowsocks보다 훨씬 많아 대부분 구독으로 자동 전달되며 직접 입력하면 파라미터를 빠뜩리기 쉽습니다. 시스템 시간 오차에 민감하므로 연결이 안 되면 먼저 시간을 맞춰보세요.
프록시 트래픽을 표준 HTTPS 접속으로 위장하는 프로토콜로, 서버 측이 유효한 TLS 인증서를 보유해야 하며 핸드셰이크 특징이 일반 웹사이트와 거의 동일합니다. 설정 필드가 적고 진입이 빨라, 눈에 덜 띄는 전송이 필요한 상황에서 자주 선택됩니다.
QUIC 기반의 신형 프로토콜로, 손실률이 높고 지연이 긴 환경에서의 처리량을 강점으로 삼아 스트리밍 시 대역폭을 끌어올리는 데 유리합니다. mihomo 코어만 이 노드 유형을 인식하며, 구버전 Premium 코어를 쓰는 클라이언트는 바로 지원 안 함으로 표시됩니다.
클라이언트가 테스트 주소(흔히 Google generate_204)로 요청을 보내 밀리초 단위 소요 시간을 집계하는 기능입니다. 이 값은 핸드셰이크 왕복 시간을 반영할 뿐 대역폭 크기를 뜻하지 않으며, timeout이 표시돼도 노드가 반드시 죽었다는 뜻은 아닙니다. 테스트 주소가 노드 측에서 차단된 경우일 수 있으니 URL을 바꿔 다시 확인해보세요.
어떤 트래픽이 프록시를 타고 어떤 트래픽이 직결되는지, 전부 이 영역의 메커니즘이 결정합니다
Clash의 핵심 기능: 모든 연결이 rules 항목을 위에서 아래로 하나씩 대입해 매칭되면 즉시 멈추고 해당 동작을 실행합니다. 순서가 곧 우선순위이므로, 세밀한 규칙을 앞에 두고 광범위한 규칙을 뒤에 두어야 국내 직결·해외 프록시 같은 정밀한 제어가 가능합니다.
가장 흔히 쓰이는 도메인 접미사 매칭 규칙입니다: DOMAIN-SUFFIX,example.com,PROXY라고 쓰면 해당 도메인과 그 모든 서브도메인이 함께 매칭됩니다. 단일 도메인만 정확히 지정하려면 DOMAIN을, 키워드로 느슨하게 매칭하려면 DOMAIN-KEYWORD를 필요에 따라 조합해 쓰세요.
목적지 IP가 지리 데이터베이스상 어디에 속하는지로 매칭하는 규칙 유형으로, GEOIP,CN,DIRECT라는 대표적인 표기는 중국 본토 IP를 무조건 직결시킵니다. 데이터베이스는 코어와 별도로 배포되는 파일이라 너무 오래되면 오판을 유발하니, 클라이언트 업데이트와 함께 갱신해야 합니다.
여러 노드를 하나의 선택 가능한 그룹으로 묶는 메커니즘입니다: select는 수동 선택, url-test는 가장 빠른 것을 자동 선택, fallback은 순위대로 대체, load-balance는 트래픽을 분산합니다. 규칙의 출구는 보통 개별 노드가 아니라 정책 그룹을 가리켜, 노드를 바꿀 때는 그룹 내 선택만 조정하고 규칙은 손댈 필요가 없습니다.
수천 개에 달하는 규칙을 별도의 원격 파일로 분리해 메인 설정에서 이름으로 참조하는 메커니즘으로, interval에 따라 주기적으로 자동 업데이트할 수 있습니다. 대형 분기 방안은 대부분 이 방식으로 구성되어, 메인 설정을 수십 줄로 줄이고 규칙 유지보수는 메인 파일을 건드리지 않고도 가능합니다.
규칙 목록 맨 마지막에 있는 전체 매칭 규칙으로, 앞에서 매칭되지 않은 모든 트래픽이 여기로 떨어집니다. 이 기본 출구가 PROXY와 DIRECT 중 어느 쪽을 가리키는지가 알 수 없는 트래픽의 기본 경로를 결정하므로, 이상한 트래픽이 엉뚱한 경로로 나갈 때는 먼저 MATCH가 어디를 가리키는지 확인하세요.
노드는 어디서 오고 설정은 어떤 모양인지, 이 영역이 조달 경로를 관리합니다
서비스 제공자가 발급하는 URL로, 클라이언트가 이를 가져와 완전한 노드 목록과 설정을 자동 생성하고 주기적으로 갱신할 수 있습니다. 이는 대다수 사용자가 노드를 얻는 표준적인 방법이며, 구독 주소는 계정 정보와 같으니 공개된 장소에 올리지 마세요.
Clash 설정 파일이 사용하는 텍스트 형식으로, 들여쓰기로 계층을 표현하고 콜론 뒤 공백으로 키와 값을 구분하며 공백에 매우 민감합니다. 수동으로 설정을 고칠 때 들여쓰기가 한 칸만 틀리거나 공백이 하나 빠져도 파일 전체가 로드에 실패하니, 수정 후 YAML 검사를 한 번 거친 다음 불러오면 디버깅 시간을 크게 줄일 수 있습니다.
다른 클라이언트 형식의 노드 링크나 구독을 Clash가 읽을 수 있는 YAML로 변환하는 서비스와 도구로, 기존 분기 규칙 템플릿을 함께 씌워주기도 합니다. 변환 과정에서 노드 정보가 경유하므로, 자체 구축이나 커뮤니티에서 평가가 확인된 인스턴스를 우선 쓰고 출처가 불분명한 온라인 서비스에는 함부로 맡기지 마세요.
클라이언트 안에서 완전한 하나의 설정을 관리하는 단위로, 여러 개를 동시에 저장하고 한 번에 전환할 수 있습니다. 구독을 업데이트한다는 것은 본질적으로 현재 활성화된 프로필을 새로 고치는 것이며, 여러 서비스를 쓰는 사용자는 제공자별로 프로필을 따로 만들어두면 서로 간섭하지 않고 문제 발생 시 어느 설정이 문제인지도 쉽게 파악할 수 있습니다.
해석이 어디로 가는지, 누출되는지, 골치 아픈 문제의 절반은 이 영역에서 나옵니다
프록시가 켜져 있어도 도메인 해석 요청이 여전히 로컬 통신사 DNS로 직접 전송되는 현상으로, 이 때문에 접속 의도가 노출될 수 있습니다. 일반적인 해결책은 Clash 내장 DNS를 활성화하고 Fake-IP나 TUN 모드를 함께 쓰는 것이며, 온라인 DNS 누출 검사 페이지로 한 번 확인해보면 제대로 막혔는지 알 수 있습니다.
Clash DNS의 응답 방식 중 하나로, 먼저 198.18.0.0/16 예약 대역의 가상 IP를 돌려주어 연결을 즉시 성립시키고, 실제 해석은 규칙 매칭 이후로 미룹니다. 첫 패킷 속도가 빠르고 자연스럽게 DNS 오염을 회피할 수 있으나, 실제 IP에 의존하는 일부 프로그램은 fake-ip-filter로 예외 처리해야 합니다.
Clash DNS 항목의 두 상위 서버 그룹입니다: nameserver는 일상적인 해석을 담당하며 보통 국내 고속 DNS를 넣고, fallback은 결과가 오염된 것으로 의심될 때 대신 작동하며 보통 DoH/DoT 암호화 DNS를 넣어 해외 도메인 해석 정확도를 보장합니다. 각자의 역할이 있으니 암호화 DNS를 전부 nameserver에 몰아넣어 해석 속도를 떨어뜨리지 마세요.
Fake-IP와 대비되는 DNS 모드로, 먼저 실제 해석 결과를 받아온 뒤 그 IP로 연결을 맺습니다. 호환성은 좋지만 첫 패킷이 더 느리고 오염된 결과를 더 쉽게 받으며, 최근 설정에서는 잘 쓰이지 않습니다. 예전 설정을 마이그레이션할 때 해석 관련 이상 증상이 나타나면 모드를 Fake-IP로 바꾸는 것만으로 즉시 해결되는 경우가 많습니다.
노드와 프로토콜이 UDP 트래픽을 지원하는 능력으로, 음성 통화, 게임 접속, 영상 회의가 이에 크게 의존합니다. 노드가 UDP를 지원하지 않을 때의 대표적인 증상은 연결은 되지만 소리가 안 나거나 게임에서 손실률이 높은 것으로, 노드 설정에서 udp 필드가 true인지 확인하거나 UDP 지원이 표시된 노드로 바로 바꿔보세요.
용어는 입장권일 뿐, 실제로 손을 움직이려면 이 세 곳을 보세요