Clash 오픈소스 생태계 총정리: mihomo, Clash Verge, ClashX 및 각 파생 프로젝트의 관계

먼저 코어, 클라이언트, 설정을 구분하기

Clash 생태계에서 가장 헷갈리는 부분은 여러 프로젝트 이름에 Clash가 들어가지만 같은 계층에 속하지 않는다는 점입니다. 기존 Clash, Clash.Meta, mihomo는 주로 프록시 코어이고, Clash Verge Rev, Clash Nyanpasu, ClashX 등은 GUI 클라이언트입니다. 구독 링크, YAML 파일, 규칙셋은 코어가 읽는 데이터입니다. 프로젝트의 용도를 판단할 때는 인터페이스 화면을 비교하기보다 먼저 어느 계층에 속하는지 확인하는 편이 정확합니다.

코어가 실제 네트워크 처리를 담당합니다

코어는 로컬 프록시 포트를 열고 프록시 서버와 연결한 뒤 규칙에 따라 트래픽 경로를 결정합니다. YAML 설정 해석, 프록시 그룹 관리, 도메인 및 IP 규칙 매칭, DNS 정책 실행, REST API 제공, 지원 플랫폼에서의 TUN 트래픽 처리 등이 대표적인 작업입니다. 다음은 일반적인 코어 기본 설정 예시입니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

external-controller: 127.0.0.1:9090
secret: "change-this-controller-secret"

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

여기서 7890은 HTTP와 SOCKS5가 함께 사용하는 혼합 포트이고, 9090은 제어 인터페이스 포트, 1053은 예시 DNS 리스닝 포트입니다. GUI 클라이언트는 보통 제어 인터페이스를 통해 노드 목록을 읽고 프록시 그룹을 전환하며 연결 기록을 확인합니다. 화면에서 ‘노드 선택’을 누르면 최종적으로 코어 API 호출로 변환됩니다.

GUI 클라이언트는 수명 주기와 시스템 통합을 담당합니다

구독 설정을 다운로드하고 업데이트하며 전환합니다.
코어 프로세스를 시작·중지하고 상태를 모니터링합니다.
시스템 프록시를 설정하거나 TUN 가상 네트워크 어댑터를 생성합니다.
프록시 그룹, 규칙, 연결, 로그, 트래픽 통계 화면을 제공합니다.
시작 시 자동 실행, 트레이 동작, 코어 경로 등 클라이언트 자체 설정을 저장합니다.

따라서 같은 구독을 두 클라이언트에서 사용해도 결과가 다르다고 해서 반드시 구독 내용이 바뀐 것은 아닙니다. 코어 버전, 기본 DNS 값, TUN 구현, 클라이언트가 추가한 오버라이드 필드, 클라이언트가 표시하는 설정 항목의 범위 때문에 차이가 날 수 있습니다.

기존 Clash, Clash.Meta, mihomo의 계보

기존 Clash가 설정과 API 구조를 마련했습니다

Dreamacro가 관리한 기존 Clash는 Go로 작성되었으며, 이 생태계의 핵심 호환 기반을 마련했습니다. YAML 설정, 프록시 그룹, 순차 매칭 규칙 시스템, HTTP 및 SOCKS 리스닝 포트, 외부 제어 API가 여기에 포함됩니다. 많은 클라이언트가 처음에는 이 인터페이스를 중심으로 개발되었습니다. 기존 저장소는 2023년에 유지보수가 중단되고 아카이브되었으므로, 이후에도 기존 코어에 의존하면 상위 프로토콜 대응, 플랫폼 호환성, 네트워크 스택 수정 업데이트를 받을 수 없습니다.

역사적으로 Clash Premium은 추가 기능을 포함한 별도 배포 라인이었으며 규칙셋, 스크립트, 더 완성도 높은 TUN 기능을 제공했습니다. 현재 새 클라이언트를 선택할 때 계속 추적해야 하는 활성 오픈소스 주류는 아닙니다. 오래된 튜토리얼에 나오는 rule-providers, tun, script 필드는 실제 코어를 기준으로 판단해야 하며, ‘Clash 설정’이라는 말만으로 호환성을 추정해서는 안 됩니다.

Clash.Meta가 기존 기능을 확장했습니다

Clash.Meta는 MetaCubeX 커뮤니티가 유지보수하며, Clash 설정 및 제어 인터페이스와의 호환성을 바탕으로 프로토콜, DNS, 규칙, 리스너, TUN 기능을 확장했습니다. 과거 많은 설정 제공 업체가 해당 구독을 ‘Clash Meta’로 표시했습니다. 이러한 구독에는 기존 Clash가 인식하지 못하는 프록시 유형이나 필드가 포함될 수 있으므로, 이를 구버전 ClashX, 구버전 Clash for Windows 또는 기존 Clash 코어에 바로 가져오면 해석 오류가 발생하거나 일부 옵션이 조용히 무시될 수 있습니다.

mihomo는 Clash.Meta의 후속 명칭입니다

Clash.Meta는 이후 mihomo로 이름이 변경되었습니다. 이름이 바뀌었다고 해서 설정 체계 전체가 폐기된 것은 아닙니다. 일반적인 proxies, proxy-groups, rules, proxy-providers, rule-providers 구조는 계속 사용됩니다. 실제 마이그레이션에서는 클라이언트가 활성 상태의 mihomo 코어를 사용하는지, 코어 버전이 설정 요구 사항을 충족하는지, 클라이언트가 시작 전에 설정을 수정하는지를 확인해야 합니다.

mihomo 버전은 보통 v1.x.x 형식으로 배포됩니다. 문제를 확인할 때는 ‘Meta 코어’라고만 적지 말고 전체 버전 번호를 기록해야 합니다. 클라이언트의 ‘설정’ → ‘코어’ 또는 ‘설정’ → ‘버전’ 화면에서 확인할 수 있으며, 프로젝트마다 메뉴 이름은 조금씩 다릅니다. 로그 첫 부분에는 보통 버전, Go 런타임, 대상 아키텍처가 표시됩니다. 예를 들면 linux-amd64, windows-amd64, darwin-arm64와 같습니다.

데스크톱 클라이언트 파생 프로젝트의 역할

Clash Verge와 Clash Verge Rev

Clash Verge는 Tauri로 제작된 크로스 플랫폼 데스크톱 클라이언트로, UI 계층과 프록시 코어가 분리되어 있습니다. 원 프로젝트의 유지보수가 중단된 뒤 Clash Verge Rev가 커뮤니티 파생 프로젝트로 이어받아 mihomo 대응을 계속하고 있습니다. 이름은 비슷하지만 유지보수 상태와 코어 업데이트 출처는 다릅니다. 새로 설치할 때는 프로젝트 이름에 Rev가 명확히 포함되어 있는지 확인하고, ‘설정’ → ‘코어 설정’에서 실제로 로드된 mihomo 버전을 확인하세요.

Clash Verge Rev는 Windows, macOS, Linux에서 비슷한 사용 방식을 원하는 사용자에게 적합합니다. 일반적인 흐름은 ‘구독’ → ‘새로 만들기’에서 구독 주소를 추가하고, 업데이트 후 ‘프록시’ 화면에서 정책 그룹을 선택한 다음 ‘설정’에서 시스템 프록시 또는 TUN 모드를 활성화하는 것입니다. 시스템 프록시는 운영체제의 프록시 설정을 따르는 프로그램을 주로 처리합니다. TUN 모드는 가상 네트워크 어댑터를 통해 더 다양한 트래픽을 처리하지만, 일반적으로 관리자 권한과 올바른 라우팅 및 DNS 설정이 필요합니다.

Clash Nyanpasu

Clash Nyanpasu 역시 크로스 플랫폼 GUI 클라이언트이며, 설정 관리, 코어 관리, 데스크톱 상호작용에 중점을 둡니다. mihomo를 대체하는 제품이 아니라 코어를 다운로드하거나 호출하고, 실행 설정을 생성하며, 코어 상태를 표시하는 역할을 합니다. 사용할 때는 ‘클라이언트 버전’과 ‘코어 버전’을 따로 확인해야 합니다. UI 프로그램만 업데이트했다고 해서 프록시 코어까지 업데이트된 것은 아니기 때문입니다.

Nyanpasu는 여러 설정, 오버라이드, 프록시 그룹을 관리해야 하는 사용자에게 적합합니다. 구독 업데이트 후 동작이 달라졌다면 ‘설정’에서 현재 활성 항목, 오버라이드 내용, 코어 선택, 실행 로그를 순서대로 확인하세요. 명령줄 mihomo에서는 시작되지만 Nyanpasu에서 실패한다면 원본 구독 파일보다 클라이언트가 병합한 최종 설정을 우선 점검해야 합니다.

ClashX, ClashX Pro, ClashX.Meta

ClashX는 초기에 등장한 macOS 메뉴 막대 클라이언트로, 상태 표시줄 아이콘에 주요 조작이 모여 있습니다. 클래식 버전은 기존 Clash 코어를 중심으로 설계되어 ‘시스템 프록시로 설정’, ‘아웃바운드 모드’, 프록시 그룹 선택 등 구형 macOS 튜토리얼의 메뉴 구조를 이해하는 데 도움이 됩니다. 기존 코어가 이미 아카이브된 만큼, 최신 프로토콜이나 규칙셋 기능 또는 최신 macOS 네트워크 변화에 의존하는 설정에는 클래식 ClashX를 권장하기 어렵습니다.

ClashX Pro는 역사적인 강화 배포 라인으로, 이름에 Pro가 들어간다는 이유만으로 mihomo를 사용한다고 판단할 수 없습니다. ClashX.Meta는 Meta 코어 호환 요구를 겨냥해 등장한 파생 프로젝트입니다. 세 제품은 아이콘과 메뉴가 비슷할 수 있지만 코어 출처는 서로 다릅니다. 설정을 가져오기 전에 ‘도움말’ → ‘정보’를 열거나 시작 로그를 확인해 코어 이름과 버전을 확인하세요. 애플리케이션 파일명만 비교해서는 특정 프록시 유형 지원 여부를 판단할 수 없습니다.

Clash for Windows

Clash for Windows는 한때 널리 사용된 데스크톱 클라이언트였지만 오픈소스 프로젝트가 아니며 2023년에 유지보수가 중단되었습니다. 오래된 튜토리얼에는 여전히 ‘Profiles’, ‘Proxies’, ‘General’, ‘Connections’ 화면이 예시로 등장합니다. 이런 튜토리얼은 설정 개념을 이해하는 데 활용할 수 있지만, 화면 경로를 Verge Rev나 Nyanpasu에 그대로 적용해서는 안 됩니다.

Clash for Windows에서 마이그레이션할 때는 프로그램 디렉터리 전체를 복사하지 말고 구독 주소 또는 원본 YAML을 우선 옮기세요. 기존 디렉터리에는 클라이언트가 생성한 병합 설정, 규칙셋 캐시, 로컬 오버라이드가 남아 있을 수 있습니다. 새 클라이언트에서 구독을 다시 가져온 뒤 포트, LAN 접근, TUN, DNS 설정을 항목별로 재구성하는 편이 차이를 찾기 쉽습니다.

모바일, 라우터, 웹 패널의 위치

모바일 클라이언트는 별도 구현입니다

Android와 iOS 앱이 Clash 형식을 지원하더라도 데스크톱과 동일한 코어 바이너리를 직접 실행하는 것은 아닙니다. 모바일 운영체제는 백그라운드 프로세스, VPN 인터페이스, DNS, 배터리 관리에 별도 제한을 둡니다. Android 클라이언트는 일반적으로 시스템 VPN API로 TUN을 구성하고, iOS 클라이언트는 Network Extension에 의존합니다. 데스크톱의 ‘시스템 프록시’ 스위치와 완전히 동일한 방식으로 동작하지 않습니다.

Clash Meta for Android는 한때 흔히 사용되던 Meta 계열 모바일 클라이언트지만, 계속 사용할지 판단할 때는 저장소의 아카이브 상태와 최근 릴리스 기록을 확인해야 합니다. FlClash 같은 프로젝트도 mihomo 기능을 사용할 수 있지만, UI 설정, 설정 저장 방식, 시스템 통합은 각 클라이언트의 고유 구현입니다. 여러 기기에서 설정을 공유할 때는 구독의 공통 부분만 공유하고, 플랫폼별 TUN, DNS 리스닝 주소, LAN 매개변수는 각 기기에 로컬로 유지하는 것이 좋습니다.

OpenClash는 OpenWrt 플러그인 계층입니다

OpenClash는 OpenWrt 환경에서 실행되며 코어 배포, 설정 변환, 규칙 업데이트, 방화벽 및 DNS 통합을 담당합니다. 데스크톱 클라이언트도 아니고 별도의 프록시 프로토콜도 아닙니다. 라우터에서 트래픽을 가로채려면 nftables 또는 iptables, 정책 라우팅, DNS 하이재킹, LAN 주소 대역을 함께 다뤄야 하므로 데스크톱의 시스템 프록시 스위치보다 복잡합니다.

예를 들어 데스크톱에서 흔히 사용하는 mixed-port: 7890은 로컬 애플리케이션에 프록시 진입점만 제공합니다. 라우터의 투명 프록시는 LAN 기기에서 전달되는 포워딩 트래픽까지 처리해야 합니다. allow-lan: true를 켜는 것은 다른 기기가 프록시 리스닝 포트에 연결할 수 있다는 뜻일 뿐, 게이트웨이 포워딩, DNS 인계, 방화벽 허용이 자동으로 완료된다는 의미는 아닙니다.

Yacd와 MetaCubeXD는 Dashboard입니다

Yacd, MetaCubeXD 같은 프로젝트는 외부 제어 패널입니다. 코어의 REST API와 WebSocket에 연결해 프록시 그룹, 활성 연결, 규칙 매칭, 트래픽 데이터를 표시합니다. 패널 자체는 프록시 트래픽을 처리하지 않으며 mihomo를 대체하지도 않습니다. 코어 제어 주소가 127.0.0.1:9090이라면 로컬 컴퓨터만 직접 접근할 수 있습니다. LAN에서 관리해야 한다면 리스닝 주소를 신중하게 조정하고 충분히 강력한 secret과 방화벽 규칙을 설정하세요.

프로젝트 간 구독·설정·규칙셋의 흐름

구독 링크가 반환하는 내용은 보통 YAML 설정이며, 인코딩된 노드 목록일 수도 있습니다. 클라이언트는 내용을 다운로드하고 필요하면 변환 또는 오버라이드를 적용한 뒤 최종 설정을 코어에 전달합니다. ‘Clash 구독 지원’은 최소한 세 가지를 포함합니다. 파일 형식을 인식하고, 포함된 프록시 프로토콜을 인식하며, DNS와 규칙 필드를 올바르게 실행할 수 있어야 합니다.

전체 설정과 Provider 설정

전체 설정은 노드, 프록시 그룹, 규칙을 하나의 파일에 작성합니다. Provider 방식은 노드나 규칙을 원격 리소스로 분리하고 코어가 정기적으로 업데이트하도록 합니다. 다음 구조는 3600초마다 노드 Provider를 새로 고치고 지정된 URL에 접속해 상태를 확인합니다.

proxy-providers:
  airport:
    type: http
    url: "https://example.invalid/subscription.yaml"
    path: ./providers/airport.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: "https://www.gstatic.com/generate_204"

proxy-groups:
  - name: PROXY
    type: select
    use:
      - airport

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

interval: 3600은 구독 새로고침 주기를, health-check.interval: 600은 상태 확인 주기를 제어하며 두 설정은 서로 다릅니다. 테스트 URL의 응답 속도는 해당 대상에 요청하는 데 걸린 시간만 반영할 뿐 다운로드 대역폭과 같지 않습니다. 규칙은 순서대로 매칭되므로 MATCH는 마지막에 폴백으로 배치해야 합니다.

클라이언트 오버라이드가 최종 결과를 바꿉니다

포트 오버라이드: 클라이언트가 구독의 mixed-port를 로컬에서 지정한 포트로 변경할 수 있습니다.
DNS 오버라이드: TUN을 활성화하면 클라이언트가 dns-hijack, Fake IP 또는 nameserver 설정을 삽입할 수 있습니다.
규칙 오버라이드: 스크립트나 병합 설정이 기존 규칙 앞에 직접 연결, 차단, 프로세스 규칙을 추가할 수 있습니다.
프록시 그룹 오버라이드: 클라이언트가 로컬 선택을 유지해 구독 업데이트 후에도 기존 노드 이름을 가리킬 수 있습니다.

호환성 문제를 확인할 때 가장 중요한 자료는 클라이언트가 실제로 코어에 전달한 최종 YAML입니다. 클라이언트에 ‘설정’ → ‘실행 설정 보기’ 또는 ‘설정’ → ‘설정 디렉터리 열기’가 있다면 해당 파일을 내보내 구독 원문과 비교하세요. 로그에 기록된 설정 경로도 생성 파일을 찾는 데 도움이 됩니다.

TUN, 시스템 프록시, 코어의 차이

시스템 프록시는 프록시 설정을 능동적으로 읽는 프로그램만 처리합니다

시스템 프록시를 켜면 클라이언트는 보통 운영체제의 HTTP 및 HTTPS 프록시를 127.0.0.1:7890으로 지정합니다. 브라우저와 대부분의 데스크톱 앱은 이 설정을 읽지만, 게임, 일부 명령줄 프로그램, 가상 머신, 자체 네트워크 스택을 구현한 소프트웨어는 우회할 수 있습니다. 따라서 코어가 정상 실행되고 브라우저가 접속된다고 해서 모든 프로세스가 프록시를 사용한다고 볼 수는 없습니다.

TUN은 가상 네트워크 어댑터로 IP 트래픽을 처리합니다

mihomo의 TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅 및 DNS 설정과 함께 트래픽을 수신합니다. 예시 설정은 다음과 같은 구조로 작성됩니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack: mixed는 코어가 지원하는 혼합 네트워크 스택 전략을 사용한다는 뜻이고, auto-route는 라우팅 자동 등록을 요청하며, auto-detect-interface는 기본 출구 인터페이스를 식별하는 데 사용됩니다. 운영체제마다 관리자 권한, 네트워크 어댑터 드라이버, 방화벽 요구 사항이 다릅니다. Windows에서 TUN 전환 후 인터넷이 완전히 끊긴다면 먼저 클라이언트가 필요한 권한으로 실행되었는지 확인한 뒤, 다른 VPN, Hyper-V, WSL, 보안 소프트웨어가 만든 라우팅을 점검하세요.

클라이언트마다 TUN 사용 경험이 다른 이유는 mihomo 자체보다 시작 순서, 라우팅 정리, DNS 주입, 절전 모드 복귀 처리에 있는 경우가 많습니다. 두 클라이언트를 비교할 때는 같은 설정, 같은 코어 버전, 같은 네트워크 환경을 사용해야 합니다. 한 번의 테스트에서도 시작 시간, 첫 DNS 응답, 기본 라우팅 변화, 절전 복귀 후 연결 상태를 기록하고 화면에 표시되는 메모리 수치만 비교하지 않는 것이 좋습니다.

유지보수 상태를 판단하는 방법

프로젝트 이름이 이어진다고 유지보수 활동까지 이어지는 것은 아닙니다. 클라이언트를 선택할 때는 다운로드 페이지의 버전 문자열만 보지 말고 코드 저장소, 릴리스 페이지, 의존 코어를 함께 확인해야 합니다. 기존 Clash, Clash for Windows, 클래식 ClashX, 각종 커뮤니티 파생 프로젝트의 상태는 서로 다릅니다.

확인할 수 있는 네 가지 신호

최근 릴리스: 정식 버전 출시일, 변경 기록, 각 플랫폼 설치 패키지가 동시에 생성되는지 확인합니다.
코어 출처: 기존 Clash, mihomo, 또는 클라이언트에 포함된 다른 호환 코어 중 무엇을 사용하는지 확인합니다.
이슈 대응: 현재 Windows, macOS, Linux 버전과 관련된 문제가 분류되고 수정되는지 확인합니다.
업그레이드 경로: 클라이언트 업데이트가 코어 업데이트까지 포함하는지, 실패했을 때 수동으로 되돌릴 수 있는지 확인합니다.

버전 번호는 프로젝트 간에 직접 비교할 수 없습니다. Clash Verge Rev 2.x, Nyanpasu 2.x, mihomo v1.x.x는 서로 다른 소프트웨어이므로 숫자 크기에 계승 관계가 없습니다. 문제를 신고할 때는 클라이언트 전체 버전, mihomo 전체 버전, 운영체제 버전, CPU 아키텍처, 현재 모드, 주요 로그를 함께 적어야 합니다. 예를 들어 ‘Windows 11 24H2, x64, 클라이언트 2.x, mihomo v1.x.x, TUN mixed 스택’이 ‘최신 버전이 작동하지 않음’보다 원인을 찾기 쉽습니다.

애플리케이션 이름만으로 아키텍처를 추정하지 마세요

macOS 설치 패키지는 x64와 arm64를 함께 제공할 수 있으며, Apple 칩 기기에서는 arm64 빌드를 우선 선택해야 합니다. Windows 기기는 일반적으로 x64를 사용하고 일부 최신 기기는 arm64를 사용합니다. Linux에서는 AppImage, deb, rpm 및 시스템 라이브러리 요구 사항도 구분해야 합니다. 아키텍처가 맞지 않으면 앱이 변환 계층을 통해 실행되더라도 TUN 보조 프로그램이나 코어 바이너리가 실패할 수 있습니다.

사용 환경에 맞춰 프로젝트 선택하기

Windows·macOS·Linux에서 통일된 사용 방식

세 가지 데스크톱 운영체제에서 비슷한 설정 관리 방식을 원한다면 Clash Verge Rev 또는 Clash Nyanpasu를 우선 검토할 수 있습니다. 선택할 때는 현재 운영체제의 TUN 지원, 설정 오버라이드 기능, 코어 업데이트 방식, 로그 진입점을 중점적으로 비교하세요. 브라우저 프록시만 사용하는 환경이라면 복잡한 TUN 옵션보다 시스템 프록시의 안정성이 중요합니다.

macOS 메뉴 막대의 가벼운 조작

메뉴 막대 중심의 사용 방식을 선호한다면 현재 유지보수 중이며 mihomo 사용을 명확히 밝힌 macOS 클라이언트를 검토할 수 있습니다. 클래식 ClashX를 계속 사용한다면 코어 기능의 한계를 명확히 이해하고 mihomo 전용 필드가 포함된 설정은 가져오지 않는 것이 좋습니다. macOS 대규모 버전 업데이트 전에는 새 시스템의 네트워크 권한과 백그라운드 실행 방식에 클라이언트가 대응하는지 확인하세요.

라우터로 가정 내 기기 통합 관리

TV, 게임기, IoT 기기에 클라이언트를 따로 설치할 수 없다면 OpenWrt와 OpenClash 조합이 일반적인 선택입니다. 배포 전에 라우터의 CPU 아키텍처, 사용 가능한 메모리, 플래시 공간, 방화벽 체계를 확인해야 합니다. 규칙셋이 크거나 연결 수가 많거나 복잡한 DNS를 사용하면 단순한 로컬 포트 프록시보다 리소스 요구량이 크게 증가합니다.

코어와 원격 패널만 필요한 경우

서버나 최소 구성의 Linux 환경에서는 mihomo를 직접 실행하고 systemd로 프로세스를 관리한 뒤 MetaCubeXD 같은 Dashboard를 제어 포트에 연결할 수 있습니다. 이 방식에서는 설정 디렉터리, 파일 권한, 로그 순환, 업데이트를 직접 관리해야 합니다. 제어 인터페이스를 신뢰할 수 없는 네트워크에 직접 노출해서는 안 되며, 원격 접근은 방화벽, 리버스 프록시 인증, 보안 터널 등으로 제한할 수 있습니다.

기존 클라이언트 마이그레이션 순서

현재 설정 기록: 구독 주소, 현재 프록시 그룹 선택, 로컬 오버라이드, 리스닝 포트, LAN 설정을 저장합니다.
원본 설정 내보내기: 구독 YAML을 우선 저장하고 캐시, 로그, 클라이언트 데이터베이스를 이식 가능한 설정으로 취급하지 않습니다.
새 클라이언트 설치: 시스템 아키텍처를 확인한 뒤 ‘설정’ → ‘코어’에서 mihomo 버전을 확인합니다.
먼저 시스템 프록시 테스트: 기본 7890 또는 클라이언트에 표시된 실제 포트를 사용해 기본 규칙과 DNS가 정상인지 확인합니다.
그다음 TUN 활성화: 활성화 전후의 라우팅과 DNS 변화를 기록해 인터넷이 끊겼을 때 빠르게 되돌릴 수 있도록 합니다.
오버라이드 재구성: 규칙, DNS, LAN 설정을 하나씩 추가하고 변경할 때마다 다시 로드한 뒤 로그를 확인합니다.

기존 설정에 스크립트 모드, Premium 전용 필드, 오래된 프록시 유형이 포함되어 있다면 해당 기능을 mihomo에서 어떻게 대체하는지 먼저 확인해야 합니다. 기존 클라이언트의 병합 설정 전체를 한 번에 복사하지 마세요. 절대 경로, 이전 포트, 이전 네트워크 어댑터 이름, 플랫폼 전용 필드가 포함되어 있을 수 있습니다.

마이그레이션이 끝나면 세 가지를 점검할 수 있습니다. 브라우저에서 시스템 프록시로 접속하고, 명령줄에서 http://127.0.0.1:7890을 명시해 접속하며, TUN을 활성화한 뒤 시스템 프록시를 읽지 않는 프로그램을 테스트합니다. 세 결과를 비교하면 구독 문제, 시스템 프록시 문제, TUN 라우팅 문제를 구분할 수 있습니다.