1. 클라이언트, 코어, 구독의 차이부터 확인
Clash for Windows(CFW) 원 프로젝트는 이미 유지보수가 중단되었습니다. 기존 설치 프로그램이 여전히 실행되고 저장된 노드로 연결될 수는 있지만, 그래픽 인터페이스와 종속 구성 요소, 프록시 코어까지 계속 수정·업데이트된다는 뜻은 아닙니다. 이전의 목적은 기존 프로그램의 이름만 바꾸는 것이 아니라, 구독 출처와 로컬 규칙, 시스템 트래픽 처리 방식을 계속 관리되는 클라이언트로 옮기는 데 있습니다.
Clash Meta는 Clash에서 파생된 코어 프로젝트이며, 이후 mihomo로 이름이 바뀌었습니다. 그래픽 클라이언트는 구독 관리, 트레이 메뉴, 시스템 프록시, 서비스 설치를 담당하고, mihomo 코어는 설정 해석, 연결, DNS, 규칙 매칭을 담당합니다. mihomo를 지원하는 클라이언트를 선택해도 CFW의 사용자 디렉터리 전체를 그대로 불러올 수 있는 것은 아닙니다.
- 구독: 일반적으로 인증 정보가 포함된 URL이며, 노드 목록이나 전체 YAML 설정을 반환합니다. 계정 권한과 트래픽, 이용 기간은 구독 제공업체가 계속 관리합니다.
- 코어 설정: 흔히 사용하는 키는
proxies,proxy-groups,rules,dns,tun입니다. - 클라이언트 데이터: 구독 색인, 인터페이스 설정, 업데이트 일정, 오버라이드 연결 정보 등이 포함되며 형식은 클라이언트마다 다릅니다.
- 시스템 트래픽 처리: 시스템 프록시, TUN 가상 네트워크 어댑터, 백그라운드 서비스는 별도의 상태입니다. YAML만 복사해서는 이전할 수 없습니다.
2. 플랫폼에 맞는 mihomo 클라이언트 선택
먼저 운영체제와 아키텍처를 확인한 다음 설정 편집 및 오버라이드 기능을 살펴보세요. 설치 파일 이름의 x64와 ARM64는 서로 다른 프로세서 아키텍처를 뜻합니다. macOS도 Apple 칩용과 Intel용을 구분해야 합니다. 클라이언트 릴리스 버전과 코어 버전은 별도의 번호 체계이므로 설치 후 ‘정보’ 또는 ‘코어’ 화면에서 각각 확인하세요. 인터페이스에 표시된 이름만으로 실행 중인 코어를 판단해서는 안 됩니다.
| 플랫폼 | 검토할 클라이언트 | 이전 전 확인 사항 |
|---|---|---|
| Windows | Clash Verge Rev、Clash Nyanpasu、FlClash | 구독 오버라이드 메뉴, 서비스 설치 권한, 시작 프로그램 설정, TUN 처리 방식. |
| macOS | Clash Verge Rev、FlClash、ClashX Meta | 칩 아키텍처, 시스템 프록시 권한, 선택한 배포판이 제공하는 강화된 트래픽 처리 기능. |
| Linux | Clash Verge Rev, FlClash 또는 독립 mihomo 코어 | 배포판 패키지 형식, 데스크톱 트레이 지원, 서비스 권한, 설정 디렉터리. |
| Android | FlClash 등 mihomo 기반 클라이언트 | VPN 권한, 백그라운드 실행 제한, 앱별 프록시, 구독 업데이트 방식. |
| iOS / iPadOS | 클라이언트가 지원한다고 명시된 구독 형식부터 확인 | Clash 설정을 지원한다고 해서 mihomo를 사용하는 것은 아닙니다. 규칙과 스크립트는 다시 적용해야 할 수 있습니다. |
데스크톱에서 먼저 확인할 세 가지 메뉴
- ‘구독’ 또는 ‘설정’ 화면에서 URL 가져오기와 현재 구독의 개별 업데이트를 지원하는지 확인하세요.
- ‘설정’에서 포트, 시스템 프록시, TUN, 코어 로그 메뉴를 찾고 현재 값을 기록하세요. 처음부터 모든 기능을 켤 필요는 없습니다.
- 설정 오버라이드, 설정 병합 또는 스크립트 메뉴를 찾아 구독 하나에 적용되는지 전체 설정에 적용되는지 확인하세요.
메뉴 이름은 클라이언트와 버전에 따라 달라질 수 있습니다. Clash Verge Rev를 예로 들면 ‘구독’에서 링크를 가져온 다음 ‘설정’에서 시스템 프록시, 가상 네트워크 어댑터, 서비스 관련 옵션을 찾을 수 있습니다. 메뉴 위치가 다르면 CFW 경로를 그대로 따라 하지 말고 현재 버전의 문서를 확인하세요. 각 플랫폼의 설치 파일은 클라이언트 다운로드 페이지에서 확인할 수 있습니다.
3. CFW 설정 백업 및 이전 목록 작성
Windows에서 CFW의 사용자 디렉터리는 보통 %USERPROFILE%\.config\clash에 있지만, 포터블 설치나 실행 인수, 사용자 지정 디렉터리에 따라 위치가 달라질 수 있습니다. 기존 클라이언트에서 ‘General’ → ‘Home Directory’를 열어 실제 경로를 확인하세요. 경로 입력란이나 디렉터리 열기 버튼이 제공된다면 화면에 표시된 위치를 기준으로 하면 됩니다.
기존 클라이언트를 종료한 뒤 설정 디렉터리 전체를 본인만 접근할 수 있는 위치에 복사해 백업하고, 다음 항목을 별도로 정리하세요. 현재 선택한 YAML만 저장하면 구독 주소와 설정 보강 로직을 놓치기 쉽습니다.
- 구독 출처: 원본 URL, 구독 이름, 업데이트 간격, 로컬 파일 여부를 기록하세요. 노드 이름만 적어 두지 마세요.
- 로컬 설정:
profiles에서 사용하는 YAML과 관련 리소스를 보관하고, 직접 작성한 파일과 구독 업데이트 시 갱신되는 파일을 구분해 표시하세요. - 추가 설정: CFW의 Parsers, 병합 규칙, 스크립트와 각 항목의 적용 조건을 내보내거나 복사하세요.
- 실행 설정: HTTP, SOCKS 또는 혼합 포트, LAN 접속 허용 여부, DNS, TUN, 우회 주소 설정을 기록하세요.
- 정책 선택: 자주 쓰는 프록시 그룹에서 현재 선택된 노드를 기록하세요. 선택 상태는 다른 클라이언트로 옮겨도 유지되지 않을 수 있습니다.
4. 구독부터 이전한 다음 프록시 그룹과 규칙 확인
첫 번째 단계에서는 기본 연결만 확인
- 기존 클라이언트의 시스템 프록시, TUN, 자동 시작을 끈 다음 프로그램을 종료하세요. 백그라운드 서비스를 설치했다면 서비스도 실행 중이 아닌지 확인해야 합니다.
- 새 클라이언트를 열고 원본 구독 URL로 구독을 추가하세요. 기존 클라이언트의 데이터 디렉터리 전체를 새 디렉터리에 덮어쓰지 마세요.
- 구독을 업데이트하고 설정을 선택한 뒤, 로그에 YAML 파싱 오류나 알 수 없는 프로토콜, 존재하지 않는 프록시 그룹 참조 등의 메시지가 있는지 확인하세요.
- 규칙 모드를 선택하고 노드를 하나 직접 지정하세요. 먼저 시스템 프록시로 브라우저 연결을 확인하고 TUN은 꺼 둡니다.
구독에는 노드만 포함될 수도 있고 전체 proxy-groups와 rules가 들어 있을 수도 있습니다. 노드형 구독은 클라이언트 템플릿이나 자체 기본 설정과 함께 사용해야 합니다. 가져온 뒤 노드만 있고 사용할 정책 그룹이 없다면 mihomo 호환성 문제로 단정하기 전에 구독 유형부터 확인하세요.
규칙을 옮길 때는 순서와 참조를 그대로 유지
rules는 위에서 아래로 순서대로 매칭되며, MATCH는 보통 마지막에 둡니다. 사용자 지정 도메인 규칙은 기본 처리 규칙보다 앞에 추가하세요. 규칙이 참조하는 프록시 그룹 이름은 공백과 대소문자까지 proxy-groups와 일치해야 합니다. 다음은 순서를 설명하기 위한 규칙 조각이며, 완성된 구독 설정이 아닙니다.
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- MATCH,출구 선택이 조각을 사용하려면 ‘출구 선택’이라는 프록시 그룹이 미리 정의되어 있어야 합니다. 예시 도메인은 문법 설명용이므로 실제로 직접 연결할 도메인으로 바꾸세요. 클라이언트의 ‘선행 규칙’ 기능을 사용한다면 보통 목록 항목만 입력하면 됩니다. rules: 아래에 다시 넣지 마세요. 입력 형식은 해당 메뉴의 안내를 따르세요.
rule-providers를 사용하는 경우 각 provider의 type, behavior, format, url, path와 업데이트 간격도 옮겨야 합니다. 상대 경로인 path는 새 코어의 작업 디렉터리에 따라 달라집니다. 기존 캐시 디렉터리를 옮기지 않았다면 규칙 파일을 다시 다운로드하도록 허용하세요. ‘규칙 파일이 없음’을 노드 장애로 오해해서는 안 됩니다.
5. Parsers와 오버라이드 스크립트를 새 클라이언트 형식으로 변경
CFW의 Parsers는 mihomo의 범용 설정 표준이 아닙니다. 양쪽에서 JavaScript를 작성할 수 있더라도 전달되는 설정 매개변수, 반환값, 실행 순서, 사용 가능한 인터페이스는 다를 수 있습니다. 기존 스크립트를 새 클라이언트에 그대로 붙여 넣으면 실행되지 않거나 구독 업데이트가 실패할 수 있고, 정상 실행되더라도 다른 설정을 덮어쓸 수 있습니다.
고정 설정은 선언형 오버라이드로 옮기는 것을 우선
포트, 모드, LAN 접속 설정처럼 고정된 값은 새 클라이언트의 설정 화면이나 설정 병합 기능을 우선 사용하세요. 아래는 이전할 때 확인해야 할 키의 예이며, 구독 설정 전체를 덮어쓰는 방식은 권장하지 않습니다.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: infomixed-port: 7890은 같은 포트에서 HTTP와 SOCKS 요청을 모두 받도록 설정하지만, 클라이언트가 최종 설정을 생성하는 단계에서 포트를 다시 지정할 수 있습니다. 변경한 뒤에는 오버라이드 파일만 확인하지 말고 실제 실행 설정을 열어 확인하세요. 목록 병합도 주의해야 합니다. 일부 메뉴는 rules 배열 전체를 교체하고, 다른 메뉴는 앞에 추가하거나 뒤에 덧붙일 수 있어 결과가 완전히 달라집니다.
스크립트가 필요하다면 변환 로직을 항목별로 다시 작성
- 먼저 특정 노드 삭제, 프록시 그룹 추가, DNS 변경처럼 기존 스크립트의 목적을 정리하세요. 오래된 로직을 모두 그대로 가져오지 않도록 합니다.
- 새 클라이언트 문서에 나온 스크립트 메뉴를 사용해 작성하고 함수 서명, 전체 설정을 반환하는 방법, 예외 표시 방식을 확인하세요.
- 한 번에 변경 사항 하나만 옮기세요. 실행 후 노드 수, 프록시 그룹 구성원, 규칙 순서를 확인한 다음 다음 항목을 적용합니다.
- 구독을 직접 한 번 업데이트하고 로컬 변경 사항이 그대로 남는지 확인하세요. 업데이트 후에도 적용되어야 오버라이드가 올바르게 연결된 것입니다.
기존 Clash의 코어 스크립트 설정과 클라이언트의 JavaScript 사전 처리를 혼동하지 마세요. script 같은 과거 설정 키를 발견하면 mihomo가 현재 지원하는지 확인하고, 명시적인 규칙이나 규칙 세트 또는 클라이언트 사전 처리 로직으로 바꾸는 것이 좋습니다.
6. 포트, DNS, TUN 모드를 나눠서 확인
브라우저 접속이 된다는 것은 해당 경로 하나가 작동한다는 뜻일 뿐입니다. 명령줄 도구, 게임, LAN 기기, UDP 트래픽은 다른 경로를 사용할 수 있습니다. 이전 후에는 단계별로 확인하고 한 번에 하나의 변수만 바꾸세요.
| 점검 항목 | 확인 방법 | 중점 확인 사항 |
|---|---|---|
| 로컬 포트 | 새 클라이언트의 혼합 포트가 7890인지 확인합니다. | 로그에 포트 충돌이 표시되는지, 터미널 프록시 환경 변수가 여전히 기존 포트를 가리키는지 확인합니다. |
| 명시적 프록시 | curl에서 127.0.0.1:7890을 지정해 요청을 보냅니다. | 연결 기록이 남는지, 매칭된 규칙과 출구가 예상대로인지 확인합니다. |
| 시스템 프록시 | 시스템 프록시를 켠 뒤 브라우저에서 실제로 사용하는 사이트에 접속합니다. | 앱이 시스템 프록시를 따르는지, 기존 PAC 설정의 영향을 받는지 확인합니다. |
| DNS 및 TUN | 기본 연결이 확인된 후 TUN을 켜고 도메인, LAN, UDP 앱을 각각 테스트합니다. | DNS 처리, 라우팅 충돌, 가상 네트워크 어댑터 권한, 로컬 서비스 접속을 확인합니다. |
Windows PowerShell에서는 다음 명령으로 포트와 명시적 HTTP 프록시를 확인할 수 있습니다. 구버전 PowerShell에서 curl 별칭으로 인해 발생하는 인수 차이를 피하려고 curl.exe를 지정했습니다. 테스트 주소는 확인하려는 실제 서비스 주소로 바꾸세요.
Get-NetTCPConnection -LocalPort 7890 -State Listen
curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com명시적 HTTP 프록시 요청만으로 UDP도 처리되고 있다고 볼 수는 없습니다. TUN을 켠 뒤에는 UDP가 필요한 앱을 따로 테스트하고 연결 기록을 확인하세요. DNS 설정에서 기존에 enhanced-mode: fake-ip를 사용했다면 fake-ip-filter와 로컬 도메인 해석 요구 사항도 확인해야 합니다. 사내 도메인은 내부 DNS가 필요한 경우가 많으므로 모두 공용 DNS로 보내면 안 됩니다.
필요하면 코어로 설정 검사
독립 mihomo 실행 파일을 확보했다면 설정 디렉터리에서 문법을 검사할 수 있습니다. 다음 예시는 Windows에서 현재 디렉터리에 코어와 설정 파일이 함께 있는 경우에 사용할 수 있습니다. 클라이언트 내부에서 생성된 설정은 내장 검사 기능을 우선 사용하세요.
.\mihomo.exe -t -d . -f .\config.yaml-t는 설정을 테스트하고, -d는 작업 디렉터리를, -f는 설정 파일을 지정합니다. 검사를 통과해도 노드 접속 가능 여부까지 확인되는 것은 아닙니다. 구독 권한, 원격 규칙 다운로드, 실제 DNS 동작도 검증할 수 없으므로 실행 로그와 함께 점검해야 합니다.
7. 업데이트를 테스트한 뒤 기존 클라이언트 정리
구독을 한 번 직접 업데이트하고, 시스템을 한 번 재시작하고, 평소처럼 네트워크를 전환해 보는 것을 권장합니다. 재시작 후에는 새 클라이언트만 자동 실행되는지 확인하세요. 유선 네트워크에서 Wi-Fi로 전환한 뒤 TUN 라우팅과 LAN 접속도 점검합니다. 이러한 테스트가 한 번의 지연 시간 측정보다 실제 사용 환경을 더 잘 반영합니다.
- 업데이트 확인: 구독을 새로 고친 뒤에도 사용자 지정 규칙, 프록시 그룹, DNS 오버라이드가 적용되는지 확인합니다.
- 서비스 확인: 브라우저, 터미널, 개발 도구, LAN 서비스를 각각 테스트합니다. 웹페이지 하나만 확인해서는 안 됩니다.
- 서비스 상태 확인: 기존 클라이언트의 백그라운드 서비스, 시작 작업, 시스템 프록시 설정이 더 이상 네트워크를 제어하지 않는지 확인합니다.
- 복구 준비: 보호된 원본 백업을 보관하고 새 클라이언트 버전, 코어 버전, 이전 날짜를 기록합니다.
새 설정이 안정적으로 작동하는 것을 확인한 뒤 기존 클라이언트의 서비스 관리 메뉴에서 백그라운드 서비스를 제거하고 프로그램을 정리하세요. 이전에 실패해 되돌려야 한다면 먼저 새 클라이언트의 TUN과 시스템 프록시를 끄고 코어를 종료한 다음 기존 환경을 복원하세요. 비교를 위해 두 프로그램을 동시에 실행하지 마세요.