mihomo 코어 · 규칙 분할 라우팅 레퍼런스

Clash Verge 공식 사이트 다운로드와 설정

이 사이트는 mihomo 코어 설명, 구독 가져오기 단계, 규칙 분할 라우팅 작성법을 정리했으며, 5개 플랫폼 클라이언트와 코어 파일 다운로드 링크는 다운로드 페이지에 모아 두었습니다. 처음 사용한다면 설치, 구독 가져오기, 모드 선택, 연결 확인의 네 단계만 거치면 됩니다.

영구 무료 오픈소스 코드 한국어 문서 GPL-3.0 라이선스

설정 드로어

클라이언트 분할 라우팅을 결정하는 다섯 가지 설정 항목

mode, dns, tun, proxy-providers, external-controller는 설정 파일에서 가장 자주 수정되는 다섯 개 섹션입니다. 왼쪽에서 각 섹션이 어떤 문제를 해결하는지 확인하고, 오른쪽에서 해당 config.yaml 조각을 볼 수 있습니다.

mode는 코어가 연결을 받은 뒤 어떻게 처리할지 결정합니다. rule은 규칙 목록을 위에서 아래로 대조해 일치하는 규칙의 전략을 따르고, global은 모든 트래픽을 하나의 출구로 보내며, direct는 프록시를 잠시 끈 것과 같습니다. 평소에는 rule을 유지하고, '규칙이 잘못된 것인지 노드가 안 되는 것인지' 판단할 때만 global로 바꿔 비교하세요. 클라이언트 화면의 모드 스위치가 바꾸는 값이 바로 이 줄이며, rule로 되돌린 뒤에는 전략 그룹에 사용 가능한 노드가 최소 하나 있는지 확인해야 합니다. 그렇지 않으면 PROXY로 매칭된 연결이 그대로 실패합니다.

mode: rule        # rule / global / direct
log-level: info
ipv6: false
규칙 모드글로벌 모드다이렉트 모드분할 순서

dns 섹션은 도메인을 누가 해석하고 어느 경로로 보낼지 결정합니다. enhanced-mode를 fake-ip로 설정하면 코어가 먼저 가상 주소를 애플리케이션에 반환하고 실제 해석은 프록시 경로에서 이루어지므로 평문 쿼리가 로컬 네트워크에 나타나지 않습니다. redir-host로 설정하면 먼저 해석한 뒤 연결하며 호환성은 더 좋지만 중간 장비에 노출되기 쉽습니다. nameserver에는 암호화된 해석 주소(DoH 또는 DoT)를 넣고, fallback은 오염된 응답을 걸러내는 용도로 사용합니다. 이 섹션을 수정한 뒤에는 코어를 재시작하는 것이 좋습니다. 설정만 다시 불러오면 해석 캐시가 재생성되지 않을 때가 있습니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://223.5.5.5/dns-query
  fallback:
    - tls://1.1.1.1:853
fake-ipDoH도메인 해석DNS 유출

tun은 코어가 가상 네트워크 어댑터를 만들어 시스템 수준의 트래픽을 통째로 넘겨받으며, 애플리케이션이 시스템 프록시 설정을 따르는지에 의존하지 않습니다. 터미널 명령, 컨테이너, 게임 클라이언트처럼 프록시 설정을 읽지 않는 프로그램은 tun을 켠 뒤에야 규칙을 따릅니다. 켜기 전에 권한을 확인하세요. Windows에서는 관리자 권한으로 실행해야 하고, macOS에서는 처음 켤 때 네트워크 구성 요소 설치 권한을 요청합니다. stack은 gvisor가 호환성이 가장 좋고, system은 시스템 프로토콜 스택을 빌려 처리량이 더 높지만 일부 시스템에서는 방화벽과 충돌합니다. 전역 트래픽을 넘겨받을 필요가 없다면 꺼 두면 됩니다.

tun:
  enable: true
  stack: gvisor      # gvisor / system / mixed
  auto-route: true
  dns-hijack:
    - any:53
가상 네트워크 어댑터시스템 프록시gvisor전역 트래픽 처리

proxy-providers는 구독 링크를 proxies에서 분리해 코어가 일정한 간격으로 가져오도록 합니다. 여러 전략 그룹이 같은 노드 집합을 공유할 수 있어 구독 주소가 바뀌어도 이곳만 수정하면 됩니다. health-check는 사용 가능 여부를 확인할 주소와 간격을 정하며, 확인에 실패한 노드는 전략 그룹에서 일시적으로 제외됩니다. path는 캐시 파일 위치를 지정하므로 가져오기에 실패해도 코어는 직전 캐시를 계속 사용하고, 네트워크가 한 번 흔들렸다고 노드가 비워지지 않습니다. interval 단위는 초이며, 너무 짧게 설정하면 구독 서비스에서 속도 제한을 받을 수 있으므로 보통 3600부터 시작합니다.

proxy-providers:
  sub-a:
    type: http
    url: "https://example.com/api/v1/client/subscribe?token=xxxx"
    interval: 3600
    path: ./providers/sub-a.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
구독 업데이트상태 확인노드 필터링로컬 캐시

external-controller는 코어가 노출하는 제어 인터페이스로, 클라이언트 화면과 서드파티 패널, 스크립트가 이를 통해 현재 전략을 읽고 노드를 전환하며 연결 목록을 확인합니다. GUI 클라이언트는 코어를 시작할 때 이 줄을 자동으로 기록하고 무작위 키를 생성하므로, 코어를 직접 배포할 때만 직접 지정하면 됩니다. 기본값은 127.0.0.1:9090을 수신하며 로컬에서만 접근할 수 있습니다. LAN이나 서버에 올릴 때는 반드시 secret을 함께 설정해야 하며, 그렇지 않으면 같은 대역의 누구나 분할 규칙과 노드 선택을 바꿀 수 있습니다.

external-controller: 127.0.0.1:9090
secret: "your-password"
제어 인터페이스패널로컬 수신

오픈소스 생태계

코어, 클라이언트, 규칙 세트의 유지보수 경계

같은 설정 파일을 서로 다른 클라이언트가 사용할 수 있는 이유는 실제로 파일을 해석하는 주체가 코어이기 때문입니다. 세 계층이 각각 무엇을 담당하는지 정리해 두면 클라이언트나 코어를 바꿀 때 규칙을 다시 작성할 필요가 없습니다.

클라이언트와 코어는 두 계층

mihomo는 설정 해석, 연결 수립, 규칙 실행을 담당하고, Clash Verge Rev나 FlClash 같은 클라이언트는 화면, 구독 관리, 코어 프로세스의 시작과 종료를 담당합니다. 같은 코어를 여러 클라이언트에서 사용할 수 있고 설정 파일 형식도 동일하므로, 클라이언트를 바꿀 때는 profile을 내보낸 뒤 가져오면 되고 규칙과 전략 그룹을 다시 작성할 필요가 없습니다.

분기 관계와 설정 호환성

원본 Clash 코어는 유지보수가 중단되었고, 커뮤니티가 그 설정 형식을 이어서 개발해 Meta와 mihomo 계열로 발전시켰습니다. VLESS, Hysteria2, TUIC 등의 프로토콜 지원과 rule-providers, proxy-providers 같은 설정 기능이 추가되었습니다. 현재 업데이트되는 클라이언트는 대부분 mihomo를 코어로 사용하며, 설정 파일에 어떤 필드를 쓸 수 있는지는 mihomo 문서를 기준으로 합니다.

규칙 세트는 별도 유지보수 라인

분할 규칙은 도메인, IP, 프로세스 등의 유형별 목록 파일로 나뉘어 각기 다른 프로젝트에서 유지보수하며, 코어는 rule-providers를 통해 필요할 때 가져옵니다. 따라서 규칙을 갱신해도 설정 파일을 수정할 필요가 없고 클라이언트는 참조만 유지하면 됩니다. 규칙 세트를 고를 때는 항목 총 개수보다 업데이트 주기와 분류 세분화 수준을 보는 것이 더 의미 있습니다.

업데이트 체계는 세 계층

클라이언트 업데이트는 화면, 코어, 구독과 규칙 세트의 세 계층으로 나뉩니다. 대부분의 클라이언트는 코어를 교체 가능한 구성 요소로 취급해 설정에서 버전을 지정하거나 바이너리를 직접 교체할 수 있고, 구독과 규칙 세트는 각각 설정된 간격에 따라 정기적으로 가져옵니다. 연결에 문제가 생기면 먼저 세 계층의 설정과 시각이 서로 맞는지 확인한 뒤 구체적인 오류 메시지를 살펴보세요.

자주 묻는 질문 모음

시작하기 전 가장 자주 마주치는 네 가지 문제

여기에는 가장 자주 묻는 네 가지를 실었습니다. 전체 분류별 문답은 자주 묻는 질문 페이지에, 용어 설명은 용어 사전에 정리되어 있습니다.

구독 업데이트 실패 시 먼저 확인할 것

먼저 구독 링크가 브라우저에서 열리고 내용이 반환되는지 확인한 다음, 클라이언트로 돌아와 업데이트 로그와 타임스탬프를 확인하세요. 대부분의 실패는 링크 만료, 로컬 DNS의 도메인 차단, 구독 서비스의 일시적 속도 제한 때문이며, 링크를 다시 가져오면 캐시와 이전 설정의 간섭을 대개 걸러낼 수 있습니다.

구독 및 노드 점검 목록 →

클라이언트는 연결됨으로 표시되는데 웹 페이지가 열리지 않을 때

세 가지를 순서대로 확인하세요. dns 섹션이 활성화되어 암호화 해석을 가리키는지, 모드가 direct로 바뀌지 않았는지, 연결 로그에서 대상 도메인이 어느 규칙에 매칭되었는지입니다. 세 가지 모두 정상이라면 다른 노드로 바꿔 출구 자체의 문제인지 확인하세요.

연결 이상 점검 단계 →

rule 모드와 global 모드의 차이

rule은 규칙 목록을 하나씩 대조해 도메인마다 다른 출구로 보내고, global은 모든 트래픽을 같은 출구로 보냅니다. 모드는 코어의 처리 방식만 바꿀 뿐 노드 자체에는 영향을 주지 않으므로, 문제를 확인할 때는 global로 바꿔 비교하는 것이 가장 빠릅니다.

용어 사전: 모드와 분할 라우팅 →

사용자 지정 규칙은 설정 파일 어느 섹션에 작성하나요

rules 섹션에 작성하며, 문법은 '유형, 매칭 내용, 전략 이름' 세 부분입니다. 규칙이 많아지면 별도 규칙 세트 파일로 분리해 rule-providers로 불러올 수 있어, 규칙을 갱신할 때 기본 설정을 건드리지 않아도 됩니다.

프로토콜 가이드: 규칙 작성법 →

자주 묻는 질문 전체 보기 →

기술 노트

최근 점검과 선택 기록

문제 유형별로 정리한 긴 글: 플랫폼 시작하기, 클라이언트 비교, 유지보수 종료 후 마이그레이션, 인증서 점검까지 각 글마다 그대로 따라 할 수 있는 단계를 제시합니다.

iOS 시작하기: App Store에서 클라이언트 받고 설정 가져오기까지

iOS에서 App Store 검색과 지역 차이, 구독 링크 가져오기, 필요할 때만 켜는 설정 흐름을 정리하고, 첫 연결 후 규칙 분할 라우팅이 적용되었는지 확인하는 방법을 설명합니다.

전문 읽기 →

클라이언트 유지보수 종료 이후: 설정 내보내기, 코어 교체, 대안

클라이언트 유지보수가 끝났다고 설정이 무효가 되는 것은 아닙니다. 먼저 profile과 규칙을 내보낸 뒤 플랫폼에 맞는 최신 클라이언트를 고르거나 mihomo 코어로 바로 바꾸면 되며, 이전 전후 점검 목록도 함께 제공합니다.

전문 읽기 →

주요 Clash 클라이언트 비교: 플랫폼과 사용 습관에 맞는 선택

코어 버전, 플랫폼 지원 범위, 설정 방식, 업데이트 주기 네 가지 기준으로 주요 클라이언트를 비교하고 Windows, macOS, 모바일과 데스크톱에 맞는 선택 기준을 제시해, 설치한 뒤에야 맞지 않는다는 걸 알게 되는 일을 줄여 줍니다.

전문 읽기 →

모든 글 보기 →

Clash 다운로드