mihomo 코어와 기존 Clash의 차이: 프로토콜·규칙 세트·DNS 변경 사항

클라이언트, 코어, 설정 형식부터 구분하기

mihomo는 네트워크 프록시 코어로, Clash Meta에서 발전했습니다. 설정을 파싱하고 아웃바운드 연결을 만들며 규칙을 매칭하고 DNS를 처리합니다. 클라이언트는 설정 가져오기, 시스템 프록시 전환, TUN 모드, 프록시 그룹 선택, 로그 확인 기능을 제공합니다. 클라이언트 이름에 Clash가 들어간다고 해서 실제로 기존 Clash 코어가 실행되는 것은 아니며, mihomo의 모든 필드를 읽을 수 있다는 뜻도 아닙니다.

‘기존 Clash’를 비교할 때는 오픈 소스 코어와 과거의 Clash Premium도 구분해야 합니다. 두 버전은 기능에 차이가 있었으며, 특히 TUN과 규칙 제공자 등의 기능이 달랐습니다. 따라서 모든 확장 기능을 ‘mihomo에서 처음 지원’한다고 단정하거나, 예전 클라이언트의 화면만 보고 코어의 기능을 판단해서는 안 됩니다.

클라이언트 버전: 화면 구성, 권한 관리, 설정 덮어쓰기 방식을 결정합니다.
코어 버전: 프로토콜 유형, 필드 파싱, 네트워크 기능의 지원 여부를 결정합니다.
구독 형식: 노드 목록만 가져올지, DNS·규칙·프록시 그룹을 포함한 전체 설정을 가져올지 결정합니다.

프로토콜 확장: 노드를 읽을 수 있어도 연결 설정이 올바른 것은 아닙니다

기존 오픈 소스 Clash와 비교하면 mihomo는 다양한 아웃바운드 프로토콜과 전송 기능을 지원합니다. VLESS, REALITY, Hysteria2, TUIC 지원이 대표적인 마이그레이션 이유입니다. 실제 사용 가능한 필드는 설치된 코어 버전에 따라 달라집니다. 구독 변환 서비스에서 구형 Clash 출력 형식을 선택하면 가져오기 전에 노드나 연결 매개변수가 누락될 수도 있습니다.

기능	mihomo 설정에서 확인할 항목	자주 발생하는 마이그레이션 문제
VLESS	`type: vless`, UUID, 전송 계층 및 TLS 매개변수	구독 변환 과정에서 유형이 걸러지거나 전송 매개변수가 누락됨
REALITY	TLS、`servername`、`reality-opts`	공개 키, 짧은 ID, 서버 설정이 서로 맞지 않음
Hysteria2	`type: hysteria2`, 인증, TLS 및 UDP 연결 가능 여부	네트워크에서 UDP가 차단되거나 1세대 프로토콜 필드를 잘못 사용함
TUIC	`type: tuic`, 인증 및 서버 프로토콜 버전	클라이언트와 서버가 요구하는 버전이 서로 다름

REALITY는 독립된 노드 유형이 아닙니다

VLESS 대신 노드 유형을 type: reality로 설정하면 안 됩니다. 일반적으로 VLESS 노드에서 TLS를 활성화하고 reality-opts를 설정합니다. 서버에서 Vision을 사용하는 경우 해당 flow도 확인해야 합니다. 프록시 화면에 노드가 표시되는 것은 설정을 읽었다는 뜻일 뿐, 인증과 핸드셰이크가 성공한다는 의미는 아닙니다.

노드 하나를 먼저 검증한 뒤 전체 그룹을 옮기기

구독 출력 형식이 구형 Clash만 지원하는 것이 아니라 mihomo 또는 Clash Meta도 지원하는지 확인하세요.
노드 유형, 서버 포트, 인증 필드, TLS 매개변수가 빠짐없이 설정되었는지 확인하세요.
정상 작동이 확인된 노드 하나로 대상 사이트에 접속한 다음, 로그에서 핸드셰이크 또는 인증 오류를 확인하세요.
Hysteria2나 TUIC를 사용하는 경우 UDP 네트워크 조건도 별도로 확인하세요. TCP 포트 연결 결과로 해당 프로토콜을 테스트할 수는 없습니다.

코어를 업데이트해도 기존 노드가 새 프로토콜로 자동 변환되거나 서버 설정이 바뀌지는 않습니다. 새 프로토콜의 적합성은 이름이 최신인지가 아니라 서버 지원 여부와 현재 네트워크 환경에 따라 달라집니다.

rule-providers: 규칙 소스와 규칙 적용 분리하기

rule-providers는 별도의 규칙 세트를 관리하고, 규칙 목록에서 RULE-SET으로 해당 세트를 참조합니다. 과거 Clash Premium에도 규칙 제공자 기능이 있었으며, mihomo는 이를 바탕으로 규칙 형식과 관련 기능을 확장했습니다. 따라서 일반 오픈 소스 Clash에서 마이그레이션하는 경우와 Premium에서 옮기는 경우 필요한 변경 사항은 서로 다릅니다.

아래 예시는 원격 다운로드 오류를 먼저 배제할 수 있도록 로컬 규칙 세트를 사용합니다. 두 파일은 예시입니다. 기본 설정 부분은 기존 설정에 병합해야 하며, 기존 노드·프록시 그룹·DNS 설정을 삭제하고 덮어쓰면 안 됩니다.

기본 설정 예시

rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,DIRECT

규칙 세트 파일: rules/local-direct.yaml

payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

이 예시는 규칙을 참조하는 방법만 보여 줍니다. 기본 설정이 전부 직접 연결이므로 그대로 사용할 수 있는 프록시 분기 설정은 아닙니다. path는 코어의 작업 디렉터리를 기준으로 해석됩니다. GUI 클라이언트는 별도의 설정 디렉터리를 사용할 수 있으므로 실행 설정이나 로그에서 실제 경로를 확인하세요.

behavior: domain은 도메인 규칙 세트에 사용하며, 완전한 DOMAIN-SUFFIX,... 규칙 행을 넣는 형식이 아닙니다.
behavior: ipcidr은 IP 대역 규칙 세트에 사용하며, 도메인 규칙을 섞어 넣을 수 없습니다.
behavior: classical에서는 위 예시와 같은 기존 규칙 항목을 사용할 수 있지만, 코어에서 지원하는 규칙 유형을 따라야 합니다.
format은 실제 파일 형식과 일치해야 합니다. mihomo의 mrs 형식은 domain 및 ipcidr 유형 규칙 세트에 사용합니다. 임의의 YAML 파일에 확장자만 바꿔 MRS 파일로 사용할 수는 없습니다.

규칙은 여전히 순서대로 매칭됩니다. RULE-SET보다 앞에 MATCH를 두면 뒤에 있는 규칙 세트는 매칭될 기회가 없습니다. 원격 제공자를 사용할 때는 다운로드 성공 여부, 파일 파싱 성공 여부, 요청의 규칙 매칭 여부를 각각 확인하세요. 이 세 가지는 서로 다른 문제입니다.

DNS 변경: 접속 대상 도메인과 노드 도메인 구분하기

mihomo의 DNS 설정은 nameserver-policy, proxy-server-nameserver, DNS 연결에 라우팅 규칙을 적용하는 옵션 등 더 세밀한 조회 경로 제어를 제공합니다. 마이그레이션에서 흔한 문제는 주소를 하나 빠뜨리는 것이 아니라, DNS 조회가 아직 해석되지 않은 노드 도메인에 의존해 순환 참조가 발생하는 것입니다.

먼저 상태를 확인할 수 있는 최소 설정 구성하기

아래 설정은 fake-ip와 노드 도메인 조회의 역할을 구분하는 예시입니다. 127.0.0.1:1053은 로컬 DNS 수신 주소이며 시스템 프록시 포트가 아닙니다. 이 주소를 설정한다고 모든 앱이 자동으로 DNS를 사용하는 것은 아닙니다. 예시의 공용 리졸버가 현재 네트워크에 적합한지는 직접 확인해야 합니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5

nameserver는 일반적인 도메인 조회를 처리하고, proxy-server-nameserver는 프록시 노드의 도메인 조회에만 사용됩니다. 위 예시는 각 필드의 역할을 설명하기 위해 두 항목을 같은 리졸버로 지정했으며, 모든 환경에서 이 주소를 그대로 사용하라는 뜻은 아닙니다. 암호화 DNS를 사용하는 경우 리졸버 자체 도메인의 부트스트랩 조회와 네트워크 연결 가능성도 확인하세요.

fake-ip-filter는 직접 연결 규칙이 아닙니다

fake-ip 모드에서는 앱에 가상 주소를 반환하고 코어가 주소와 도메인의 매핑을 관리합니다. 도메인을 fake-ip-filter에 추가하면 fake-ip 할당 대상에서 제외된다는 뜻이지, 해당 연결이 반드시 직접 연결된다는 뜻은 아닙니다. 실제 아웃바운드는 규칙, 프록시 그룹, 아웃바운드 모드에 따라 결정됩니다.

마이그레이션 초기에 업스트림 DNS를 바꾸고 TUN과 스니핑을 켜면서 모든 규칙까지 다시 작성하는 것은 피하세요. 먼저 DNS가 예상한 응답을 반환하는지 확인한 다음 연결에 올바른 규칙이 적용되는지 점검하는 편이 좋습니다. respect-rules를 활성화하려면 노드 도메인의 조회 경로를 먼저 구성하고 현재 버전의 문서를 확인하세요. 그래야 DNS 요청이 아직 준비되지 않은 프록시에 거꾸로 의존하는 상황을 피할 수 있습니다.

스니핑: 도메인 정보를 보완할 뿐 HTTPS를 복호화하지 않습니다

트래픽이 코어에 들어올 때 대상 IP만 남아 있으면 도메인 규칙의 매칭 정보가 부족할 수 있습니다. mihomo의 sniffer는 HTTP Host나 TLS 핸드셰이크의 서버 이름 등을 바탕으로 도메인을 식별할 수 있습니다. 이를 위해 HTTPS 본문을 복호화할 필요는 없으며, 모든 암호화 연결에서 도메인을 알아낼 수 있는 것도 아닙니다.

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080]
    TLS:
      ports: [443]

이 예시는 지정한 포트에서만 HTTP와 TLS 스니핑을 시도하며, 목적지 주소 덮어쓰기와 같은 추가 기능은 활성화하지 않습니다. 서비스가 다른 포트에서 실행된다면 실제 환경에 맞게 조정하세요. 기존 설정에 남아 있는 과거 스니핑 필드를 새 구조에 그대로 붙여 넣지 마세요. 필드 계층이 맞지 않으면 현재 코어의 설정 검사 결과를 기준으로 판단해야 합니다.

확인하기 좋은 상황: TUN으로 IP 연결은 들어오지만 도메인 기준으로 분기되어야 하는 경우
대신할 수 없는 설정: DNS 설정, 프록시 그룹 정의, 라우팅 제외 항목, 앱 자체 프록시 설정
주의할 제한: ECH 등의 기술로 서버 이름이 노출되지 않을 수 있으며, 도메인을 식별할 수 없는 트래픽도 있습니다.

스니핑을 켠 뒤 특정 사이트의 동작이 달라지면 먼저 해당 도메인의 스니핑 범위를 조정하거나 기능을 잠시 끄고 연결 로그를 비교하세요. DNS나 라우팅 문제를 가리기 위해 스니핑 포트 범위를 넓히지는 마세요.

TUN과 시스템 프록시: 코어 업데이트만으로 트래픽 진입 경로가 자동 전환되지는 않습니다

시스템 프록시는 앱이 운영체제의 프록시 설정을 따를 때만 작동합니다. TUN 모드는 가상 네트워크 인터페이스로 IP 트래픽을 전달하므로 클라이언트가 권한, 라우팅, DNS를 올바르게 처리해야 합니다. mihomo는 TUN을 지원하지만 플랫폼·클라이언트·버전에 따라 적용 방식이 다릅니다. tun: 설정만 복사했다고 모든 트래픽을 처리하게 된 것은 아닙니다.

예를 들어 로컬 혼합 포트를 7890으로 설정하면 시스템 프록시를 따르는 앱은 이 포트를 통해 코어에 연결할 수 있습니다. DNS 수신 포트 1053은 별도의 진입 경로입니다. 두 포트의 역할은 다르므로 시스템 HTTP 프록시 주소에 DNS 수신 포트를 입력하면 안 됩니다.

처음 마이그레이션할 때는 TUN을 끄고 시스템 프록시로 구독과 노드를 확인한 다음 TUN을 별도로 활성화할 수 있습니다. LAN, 프린터, 다른 VPN에 접속할 때 문제가 생기면 노드 프로토콜부터 의심하지 말고 라우팅 중복, DNS 가로채기, 제외 항목을 먼저 확인하세요.

기존 설정 마이그레이션: 구문·리소스·연결 순서로 점검하기

1단계: 최종 실행 설정 확인

먼저 구독 파일, 사용자 지정 오버라이드, 프록시 그룹 선택을 백업하세요. 클라이언트는 코어를 시작하기 전에 여러 설정을 병합할 수 있으므로 편집기에서 보는 파일이 최종 실행 설정과 다를 수 있습니다. 클라이언트에서 내보낸 실행 설정을 확인해 dns, rules, proxy-groups가 다른 내용으로 덮어쓰이지 않았는지 점검하세요.

mihomo -v
mihomo -t -f ./config.yaml

-t는 설정을 검사하는 옵션입니다. 검사를 통과하면 코어가 설정을 받아들였다는 뜻이지, 원격 규칙 다운로드나 노드 연결까지 성공했다는 뜻은 아닙니다. 클라이언트가 관리하는 코어를 사용할 때는 다른 버전의 바이너리가 실행되지 않도록 클라이언트에서 제공하는 검사 기능을 우선 사용하세요.

2단계: 외부 리소스와 이름 참조 확인

프록시 그룹에서 참조하는 노드나 제공자가 실제로 존재하고 이름이 완전히 일치하는지 확인하세요.
RULE-SET의 이름이 rule-providers의 키와 일치하는지 확인하세요.
규칙 파일 경로, 원격 리소스 요청, 파싱 오류를 확인해 네트워크 오류와 형식 불일치를 구분하세요.
구독을 업데이트한 뒤에도 사용자 지정 설정이 적용되는지 확인하세요. 다음 업데이트에서 덮어쓸 캐시 파일만 수정해서는 안 됩니다.

3단계: 고정된 요청으로 결과 확인

혼합 포트가 실제로 7890이고 코어가 실행 중이라면, 아래 명령으로 HTTP 프록시를 명시해 요청을 보낼 수 있습니다. 테스트 도구가 시스템 프록시를 따르는지에 따른 혼선을 피할 수 있습니다.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

여기서 10초와 20초는 각각 연결 대기 시간과 전체 요청 시간의 제한이며 속도 점수가 아닙니다. 테스트한 뒤 연결 화면에서 대상 도메인, 적용된 규칙, 실제 아웃바운드를 확인하세요. 오류가 발생하면 로그 화면에서 원인을 확인합니다. 핸드셰이크 실패는 노드 매개변수를, 규칙 불일치는 규칙 순서와 도메인 정보를, 연결 기록이 없으면 트래픽 진입 경로를 먼저 점검하세요.

마이그레이션 완료 여부는 설정 검사 통과, 필요한 리소스 로드 성공, 앱 트래픽의 코어 유입, 예상한 규칙 매칭, 정상적인 노드 연결로 판단할 수 있습니다. 이 다섯 항목을 차례로 확인하면 새 기능을 한꺼번에 켜는 것보다 문제를 찾기 쉽고, 복구할 수 있는 기존 설정도 보존할 수 있습니다.