mihomo 커널 기능 분석: 기본 Clash와 규칙·프로토콜·실행 기능 비교

mihomo와 기본 Clash의 호환성

기본 Clash는 조합하기 쉬운 설정 구조를 만들었습니다. proxies에서 노드를 정의하고, proxy-groups에서 수동 선택·자동 테스트·장애 조치 전략을 구성한 다음, rules에서 연결을 순서대로 프록시 그룹에 전달합니다. mihomo도 이 기본 구조를 이어가므로 일반적인 Clash YAML 설정을 마이그레이션의 출발점으로 사용할 수 있습니다. DOMAIN-SUFFIX, DOMAIN, IP-CIDR, GEOIP, MATCH 같은 기본 규칙과 select, url-test, fallback 같은 일반적인 프록시 그룹은 두 설정 체계에서 의미가 대체로 비슷합니다.

이러한 호환성이 두 설정의 필드가 완전히 같다는 뜻은 아닙니다. mihomo에 새로 추가된 필드·프록시 유형·규칙 문법을 기본 Clash가 인식하지 못할 수 있습니다. 반대로 기존 설정에 남아 있는 필드가 변경되거나 폐기되었거나 특정 클라이언트의 사전 처리 계층에서만 작동할 수도 있습니다. 특히 구독 변환 서비스가 생성한 설정에는 커널 필드, 클라이언트 전용 필드, 템플릿 변수가 섞여 있을 수 있습니다. 마이그레이션할 때는 구독 주소의 이름만 보지 말고 커널에 최종 전달되는 YAML을 확인해야 합니다.

설정 호환성은 세 단계로 나눌 수 있습니다

1. 문법을 읽을 수 있음: YAML 들여쓰기, 목록과 필드 이름을 파싱할 수 있어 커널이 시작됩니다.
2. 객체를 인식함: 현재 커널 버전이 노드 프로토콜, 프록시 그룹 유형, 규칙 유형과 DNS 필드를 지원합니다.
3. 동작이 예상과 일치함: 규칙 매칭 순서, DNS 응답, 속도 측정 방식과 트래픽 가로채기 범위가 원래 설정의 목적과 일치합니다.

“설정 가져오기 성공”만 표시되는 것은 대개 앞의 두 단계 중 일부만 확인한 결과입니다. 실제 호환성을 점검하려면 프록시 그룹이 완전한지, 규칙 제공자가 정상적으로 업데이트되는지, DNS가 수신 대기 중인지, 로그에 알 수 없는 필드가 나타나는지, 대상 사이트가 최종적으로 어떤 정책에 매칭되는지까지 살펴봐야 합니다.

규칙 시스템의 차이: 순차 매칭에서 복합 조건까지

Clash와 mihomo의 규칙 처리는 모두 한 가지 핵심 원칙을 따릅니다. 규칙을 위에서 아래로 확인하고, 먼저 매칭된 규칙이 연결 방향을 결정합니다. 따라서 규칙이 많다고 라우팅이 반드시 정확해지는 것은 아니며, 순서와 조건 범위가 더 중요합니다. 범위가 넓은 도메인 접미사 규칙을 구체적인 규칙보다 앞에 두면 뒤의 규칙이 실행될 기회를 잃을 수 있습니다. MATCH를 앞에 배치하면 나머지 트래픽을 즉시 가져갑니다.

mihomo는 기본 규칙 모델에 더 풍부한 매칭 기준을 제공합니다. 도메인, 대상 IP, 소스 IP, 포트, 프로세스 같은 일반적인 조건 외에도 지원되는 버전에서는 논리 조합을 사용해 여러 조건을 AND·OR·NOT 관계로 구성할 수 있습니다. 이를 통해 “특정 프로세스가 특정 포트에 접속할 때 지정된 정책을 사용”하거나 “특정 도메인 집합이면서 프로토콜 유형이 조건에 맞을 때 프록시 사용” 같은 세밀한 요구를 표현할 수 있습니다. 구체적인 규칙 이름과 중첩 문법은 버전에 따라 달라질 수 있으므로 작성 전에 현재 버전의 문서와 시작 로그를 확인해야 합니다.

기본 규칙과 확장 규칙의 활용 범위

• 도메인 규칙: DOMAIN은 전체 도메인을 정확히 매칭하고, DOMAIN-SUFFIX는 특정 도메인과 하위 도메인을 매칭하므로 안정적인 웹사이트 분류에 적합합니다.
• IP 규칙: IP-CIDR과 IP-CIDR6은 대상 주소 대역을 기준으로 판단합니다. 이 규칙 때문에 추가 DNS 조회가 발생하는 것을 피하려면 지원 여부에 따라 해당 옵션을 함께 사용할 수 있습니다.
• 지리 데이터 규칙: GEOIP은 IP 데이터베이스에 따라 분류합니다. mihomo는 도메인 분류를 위해 GEOSITE 또는 규칙 집합과 함께 사용하는 경우도 많습니다. 결과의 품질은 데이터 파일의 출처와 업데이트 시점에 좌우됩니다.
• 프로세스 규칙: 프로세스 이름이나 경로에 따라 라우팅할 수 있어 데스크톱 시스템에 적합하지만, 권한·운영체제·트래픽 가로채기 방식에 따라 식별 결과가 달라집니다.
• 인바운드 및 네트워크 조건: 인바운드 출처, TCP 또는 UDP, 소스 주소와 포트 등의 정보를 기준으로 정책을 세분화할 수 있어 게이트웨이 또는 다중 인바운드 환경에 적합합니다.
• 규칙 제공자: rule-providers를 사용해 대규모 규칙 집합을 기본 설정에서 분리하고 지정한 주기로 업데이트한 뒤 RULE-SET으로 참조합니다.

규칙 제공자는 대규모 설정에서 매우 유용한 구조지만, 많을수록 좋은 것은 아닙니다. 여러 규칙 집합이 같은 도메인을 중복 처리할 수 있고, 업데이트에 실패하면 라우팅 결과가 예상과 달라질 수 있습니다. 반드시 직접 연결해야 하는 LAN과 시스템 서비스를 앞쪽에 배치하고, 업무별 규칙 집합은 우선순위에 따라 정렬하며, 마지막에는 명확한 기본 처리 정책을 남겨 두는 것이 좋습니다. 출처가 불분명하거나 오랫동안 업데이트되지 않았거나 비정상적으로 큰 규칙 집합은 먼저 콘텐츠 형식과 동작을 확인해야 합니다.

rule-providers:
  service-set:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/service-set.yaml
    url: https://example.com/rules/service-set.yaml
    interval: 86400

rules:
  - DOMAIN,router.local,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - RULE-SET,service-set,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

이 구조는 규칙을 구성하는 방식을 보여 주는 예일 뿐, 모든 환경에 그대로 복사해 사용할 수 있다는 뜻은 아닙니다. 원격 주소, 프록시 그룹 이름, 규칙 집합 형식과 저장 경로를 실제 설정에 맞춰야 합니다. 특히 behavior와 다운로드 파일의 콘텐츠 형식이 일치해야 하며, 그렇지 않으면 규칙 제공자 로드에 실패할 수 있습니다. 클라이언트에 업데이트 성공이 표시된 뒤에도 커널 로그에서 파싱이 완료되었는지 확인해야 합니다.

프로토콜 지원 차이: 노드를 가져올 수 있다고 연결되는 것은 아닙니다

기본 Clash는 여러 전통적인 프록시 프로토콜을 지원하며, 통합 프록시 그룹을 통해 노드를 전환합니다. mihomo는 여기에 더해 현대적인 프로토콜과 전송 조합을 확장했으며, 대표적으로 VLESS, Reality, Hysteria2, TUIC, WireGuard와 프로토콜별 TLS·WebSocket·gRPC 옵션 조합을 지원합니다. 실제 사용 가능 범위는 mihomo 버전, 빌드 대상과 클라이언트 통합 진행 상황에 따라 달라지므로, 구독에 특정 링크 형식이 포함되어 있다는 이유만으로 반드시 작동한다고 판단해서는 안 됩니다.

구독 가져오기는 일반적으로 두 단계로 진행됩니다. 먼저 클라이언트 또는 구독 서비스가 노드 링크를 YAML 객체로 변환하고, 이어서 커널이 객체를 읽어 연결을 수립합니다. 특정 노드가 프록시 그룹에 나타나지 않는다면 변환 단계에서 인식하지 못했을 가능성이 있습니다. 노드가 표시되지만 연결 오류가 발생한다면 커널 매개변수, 서버 설정, 네트워크 환경 또는 시스템 시간이 원인일 가능성이 큽니다. 두 단계를 나누어 확인하는 편이 구독을 계속 다시 가져오는 것보다 효과적입니다.

프로토콜 마이그레이션 시 확인할 매개변수

• 서버 주소, 포트, 사용자 식별자 또는 인증 정보가 모두 입력되었는지 확인합니다.
• TLS가 활성화되어 있는지, 서버 이름·ALPN·인증서 관련 매개변수가 서버 측 설정과 일치하는지 확인합니다.
• 전송 계층이 TCP, UDP, WebSocket, gRPC 또는 다른 방식인지, 경로와 서비스 이름이 일치하는지 확인합니다.
• Reality 환경의 공개 키, 짧은 식별자와 지문 매개변수가 정확한지 확인합니다.
• Hysteria2, TUIC 같은 UDP 기반 프로토콜이 현재 네트워크·라우터·방화벽의 제한을 받는지 확인합니다.
• 프록시 그룹이 해당 노드를 참조하는지, 노드 이름을 변경한 뒤 끊어진 참조가 생기지 않았는지 확인합니다.

속도 측정 결과만으로 실제 접속 환경을 완전히 판단할 수는 없습니다. url-test는 일반적으로 지정된 URL의 응답 시간을 측정하고 일정 간격으로 다시 테스트합니다. 연결 가능하면서 지연 시간이 낮은 노드를 선택하는 데 도움이 되지만, 동영상 처리량·장시간 연결 안정성·UDP 품질·대상 사이트 자체의 제한까지 반영하지는 못합니다. 모든 노드의 속도 측정은 정상인데 특정 앱을 사용할 수 없다면 규칙 매칭, DNS 결과, IPv6 경로와 해당 앱이 시스템 프록시를 우회하는지까지 확인해야 합니다.

기본 Clash에서 mihomo로 전환할 때의 주요 이점 중 하나는 같은 정책 체계에서 더 다양한 노드 유형을 처리할 수 있다는 점입니다. 하지만 프로토콜이 많아질수록 설정 필드도 복잡해집니다. 구독 사용자는 서비스 제공자가 mihomo에 맞는 설정 형식을 생성하도록 하는 것이 우선입니다. 직접 설정을 관리한다면 단일 노드와 간단한 프록시 그룹으로 연결을 먼저 검증한 뒤 자동 선택·로드 밸런싱·복잡한 규칙을 단계적으로 추가해야 합니다.

실행 기능의 차이: DNS·스니핑·TUN 모드

커널의 실행 기능은 트래픽이 프록시 시스템으로 들어오는 방식과 규칙 매칭 시 확인할 수 있는 정보를 결정합니다. 시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에만 영향을 줍니다. 반면 TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 가로채므로 시스템 프록시 설정을 읽지 않는 프로그램, 일부 게임 또는 트래픽을 통합 처리해야 하는 환경에 적합합니다. mihomo는 TUN·DNS·트래픽 식별에 다양한 설정 옵션을 제공하지만, 시스템 권한과 올바른 네트워크 매개변수에 더 크게 의존합니다.

TUN 모드의 핵심 사항

TUN을 활성화하면 클라이언트가 가상 네트워크 어댑터를 만들고 라우팅을 조정하거나 자동 리디렉션 기능을 활성화해야 하는 경우가 많습니다. 운영체제마다 구현 세부 사항이 다르며, 클라이언트에서 system, gVisor, mixed 같은 네트워크 스택 옵션을 제공할 수 있습니다. 실제 사용 가능한 항목은 현재 커널과 클라이언트에 따라 확인해야 합니다. 한 기기에서 안정적인 네트워크 스택이 모든 운영체제 버전, 가상 머신 또는 기업 보안 환경에서도 같은 결과를 보장하지는 않습니다.

TUN 모드에서 자주 발생하는 문제로는 라우팅이 올바르게 등록되지 않음, LAN 접근이 가로채짐, DNS 요청 경로 불일치, 절전 모드 해제 후 가상 인터페이스가 작동하지 않음, 다른 VPN 프로그램이 기본 라우팅을 동시에 변경함 등이 있습니다. 문제를 해결할 때는 먼저 다른 네트워크 가로채기 도구를 끄고 일반 시스템 프록시 모드가 작동하는지 확인한 다음 TUN을 활성화하고 로그를 살펴보세요. LAN 기기만 접속할 수 없다면 모든 규칙을 무작정 수정하기보다 사설 주소 대역이 직접 연결로 설정되어 있는지 확인해야 합니다.

DNS 모드와 도메인 규칙

도메인 규칙이 정확히 작동하는지는 DNS 처리 방식과 밀접하게 관련됩니다. mihomo에서 흔히 사용하는 향상된 DNS 모드로는 redir-host와 fake-ip가 있습니다. fake-ip는 도메인에 대해 예약 주소 대역의 매핑 주소를 반환하고, 커널이 연결 단계에서 도메인 정보를 복원합니다. 덕분에 IP로만 연결을 시작하는 앱도 도메인 규칙 매칭에 참여할 수 있습니다. 일부 LAN 서비스, 기기 검색, 게임 플랫폼 또는 실제 주소를 기준으로 판단하는 프로그램은 fake-IP 필터 목록에 추가해야 할 수 있습니다.

DNS 설정은 기본 리졸버, 프록시 노드 도메인 리졸버, 도메인별 정책으로 선택되는 리졸버와 보조 리졸버를 구분하기도 합니다. 여기서 가장 쉽게 발생하는 문제는 순환 의존성입니다. 프록시 노드의 서버 주소 자체가 도메인인데, 그 도메인을 조회하려면 아직 연결되지 않은 프록시를 거쳐야 하는 경우입니다. 노드 도메인에는 직접 접근 가능한 기본 조회 경로를 준비하고, “프록시 서버 주소 조회”와 “프록시 연결 후 대상 웹사이트 조회”를 명확히 구분하는 것이 바람직합니다.

트래픽 스니핑의 활용 범위

트래픽 스니핑은 HTTP Host, TLS Server Name 같은 핸드셰이크 정보에서 대상 도메인을 식별해 대상 IP만 있을 때 부족한 도메인 정보를 보완할 수 있습니다. 이는 TUN 환경의 규칙 매칭에 도움이 되지만, 스니핑은 HTTPS 콘텐츠를 복호화하는 기능이 아니며 모든 연결에서 도메인을 추출할 수 있는 것도 아닙니다. 암호화된 핸드셰이크 방식, QUIC, 앱 자체 프로토콜 또는 IP를 직접 사용하는 연결은 식별을 제한할 수 있습니다.

스니핑을 활성화한 뒤 특정 앱에서 연결 문제가 발생하면 먼저 식별된 도메인이 정확한지 확인한 후 관련 대상에 예외 또는 제외 정책을 설정해 보세요. 스니핑·DNS·규칙 문제를 한 범주로 묶어서는 안 됩니다. 로그에 도메인이 표시되지만 정책이 잘못되었다면 규칙 순서를 확인하고, IP만 표시된다면 DNS와 스니핑을 확인해야 합니다. 연결이 아예 커널에 들어오지 않는다면 시스템 프록시, TUN 라우팅 또는 앱 자체 설정을 점검해야 합니다.

Clash 설정을 mihomo로 마이그레이션할 때의 점검 순서

설정을 마이그레이션할 때 가장 안정적인 방법은 모든 확장 기능을 한 번에 활성화하는 것이 아니라, 검증 가능한 최소 설정을 먼저 만든 다음 기능을 단계별로 복원하는 것입니다. 이렇게 하면 문제가 YAML 파싱, 노드 연결, 프록시 그룹 참조, 규칙 로드, DNS 또는 시스템 트래픽 가로채기 중 어느 단계에서 발생했는지 확인할 수 있습니다.

1. 클라이언트가 실제로 사용하는 커널을 확인합니다. 클라이언트의 정보 페이지, 커널 관리 페이지 또는 시작 로그에서 커널 이름과 버전을 확인하세요. 화면 제목에 Clash가 포함되어 있다는 사실만으로 판단해서는 안 됩니다.
2. 기존 설정을 백업합니다. 원본 YAML, 구독 주소, 사용자 지정 규칙과 DNS 설정을 보관하세요. 클라이언트 데이터베이스와 별도로 내보낸 YAML은 내용이 다를 수 있으므로 중요한 변경 사항은 별도로 저장해야 합니다.
3. 먼저 YAML 파싱을 검증합니다. 가져온 후 로그에서 알 수 없는 필드, 중복 키, 들여쓰기 오류와 규칙 제공자 로드 실패를 확인하세요. YAML은 공백으로 계층을 표현하므로 Tab이나 잘못된 들여쓰기가 구조를 바꿀 수 있습니다.
4. 간단한 정책으로 노드를 테스트합니다. 먼저 소수의 노드만 포함한 수동 선택 그룹을 만들고 TCP 및 필요한 UDP 연결이 작동하는지 확인하세요. 이 단계에서는 복잡한 속도 측정과 로드 밸런싱을 아직 추가하지 않는 것이 좋습니다.
5. 프록시 그룹 참조를 확인합니다. 규칙 마지막에 지정한 그룹이 실제로 존재해야 하며, 프록시 그룹 내부에서 참조하는 노드나 다른 그룹의 이름도 완전히 일치해야 합니다. 이름에 포함된 공백과 문장 부호도 이름의 일부입니다.
6. 규칙 집합을 단계적으로 로드합니다. LAN 직접 연결, 핵심 업무 규칙, 지역 규칙, 최종 기본 처리 순서로 하나씩 추가하면서 매번 규칙 제공자의 업데이트 상태와 실제 매칭 결과를 확인하세요.
7. 마지막으로 DNS와 TUN을 조정합니다. 먼저 시스템 프록시 모드에서 기본 연결을 확인한 다음 향상된 DNS, 스니핑과 TUN을 활성화하세요. 트래픽 가로채기 계층을 하나 추가할 때마다 웹페이지, 명령줄 프로그램, LAN과 UDP 앱을 다시 테스트해야 합니다.

문제가 발생했을 때 원인 찾기

커널이 시작되지 않으면 먼저 설정 문법, 지원되는 필드와 수신 포트 충돌을 확인하세요. 모든 노드를 사용할 수 없다면 네트워크 연결, 프로토콜 매개변수, 시스템 시간과 노드 도메인 조회를 점검해야 합니다. 일부 웹사이트만 잘못된 방향으로 연결되면 연결 로그의 도메인·대상 IP·매칭 규칙을 확인하세요. 브라우저는 정상인데 앱을 사용할 수 없다면 해당 앱이 시스템 프록시를 읽는지 또는 TUN 가로채기가 필요한지 확인해야 합니다. TUN을 활성화한 뒤 전체 네트워크가 끊기면 먼저 시스템 프록시 모드로 되돌린 다음 가상 네트워크 어댑터, 기본 라우팅과 DNS 수신 상태를 점검하세요.

로그 수준도 필요에 따라 조정해야 합니다. 평소에는 일반 수준을 유지하고, 문제를 해결할 때만 잠시 더 상세한 로그를 활성화하세요. 로그에는 접속 도메인, 노드 주소와 로컬 경로 같은 정보가 포함될 수 있습니다. 원인을 확인한 뒤에는 일반 수준으로 되돌려 불필요한 출력과 장기적인 로그 저장 공간 사용을 줄이세요.

기본 Clash와 mihomo 중 선택하는 방법

현재 클라이언트를 선택하는 사용자에게 더 현실적인 질문은 명령줄 커널을 따로 설치할지보다 어떤 커널을 사용하는 클라이언트를 선택할지입니다. 설정에 전통적인 프로토콜과 기본 라우팅만 포함되어 있고 현재 환경에서 안정적으로 작동하며 새로운 기능이 필요하지 않다면, 이름이 바뀌었다는 이유만으로 서둘러 마이그레이션할 필요는 없습니다. 안정적인 설정, 명확한 규칙과 반복 가능한 백업이 새 필드를 하나씩 따라가는 것보다 중요합니다.

구독에 VLESS Reality, Hysteria2, TUIC 같은 노드가 포함되어 있거나 논리 규칙·규칙 제공자·세밀한 DNS 정책·트래픽 스니핑·TUN 가로채기가 필요하다면 mihomo가 일반적으로 더 완성도 높은 기반을 제공합니다. 선택할 때는 그래픽 클라이언트가 해당 버전을 신속하게 통합하는지, 커널 업데이트를 관리할 수 있는지, 로그를 명확히 표시하는지, 시스템 프록시와 TUN 스위치가 현재 플랫폼의 사용 방식에 맞는지도 확인해야 합니다.

차이를 요약하면 다음과 같습니다. 기본 Clash는 설정과 규칙 라우팅 모델을 마련했고, mihomo는 이 모델을 이어받아 프로토콜·규칙·실행 기능을 확장했습니다. 마이그레이션의 핵심은 모든 확장 기능을 켜는 것이 아니라 새 기능이 어떤 문제를 해결하는지 확인하고 로그와 단계별 테스트로 결과를 검증하는 데 있습니다. 대부분의 설정에서는 먼저 기본 노드, 프록시 그룹과 규칙 순서를 올바르게 구성한 뒤 DNS·스니핑·TUN을 처리하는 것이 흔한 연쇄 장애를 줄이는 방법입니다.