Clash for Windows 지원 종료 후 대안: mihomo 기반 클라이언트로 설정 옮기기

구독과 규칙부터 옮긴 뒤 시스템 프록시와 TUN을 복구하세요

Clash for Windows는 지원이 종료되었습니다. 마이그레이션의 핵심은 기존과 똑같은 화면의 설치 파일을 찾는 것이 아니라 구독 소스, 사용자 지정 규칙, 오버라이드 로직, 시스템 연결 설정을 각각 옮기는 데 있습니다. 새 클라이언트의 시스템 프록시로 먼저 기본 동작을 확인하고 규칙과 DNS가 정상인지 점검한 다음 TUN 모드를 켜세요. 두 클라이언트가 동시에 시스템 프록시를 변경하거나 라우팅을 제어하지 않도록 하세요.

Clash for Windows는 GUI 클라이언트이고 mihomo는 프록시 코어이므로 서로 다른 계층에 속합니다. mihomo는 Clash 설정 체계를 이어받으면서 프로토콜과 설정 기능을 확장했습니다. 다만 같은 코어를 사용하는 클라이언트라도 설정 병합 순서, 서비스 관리 방식, 스크립트 인터페이스는 다를 수 있습니다. 기존 YAML을 읽을 수 있다고 해서 클라이언트 설정까지 모두 옮겨진 것은 아닙니다.

Clash for Windows 대체 클라이언트 고르기

Windows 데스크톱 사용자는 Clash Verge Rev와 Clash Nyanpasu를 먼저 비교해 볼 수 있습니다. 둘 다 GUI 클라이언트지만 mihomo를 지원한다는 이유만으로 설정 폴더, 오버라이드 형식, 서비스 구성 요소를 서로 바꿔 쓸 수 있다고 가정해서는 안 됩니다. 다운로드 전에 프로젝트 이름, 최신 릴리스 노트, 운영체제 요구 사항, 실제로 선택된 코어를 확인하세요.

기존 설정의 복잡도에 맞춰 선택하세요

• 구독이 하나뿐인 경우: 가져오기, 업데이트, 프록시 그룹 선택, 로그 확인이 편리한지 살펴보세요. 당장 쓰지 않는 기능 때문에 이전 단계를 늘릴 필요는 없습니다.
• 규칙과 오버라이드를 사용하는 경우: 규칙을 앞쪽에 삽입할 수 있는지, 전역 설정과 구독별 설정이 어떻게 병합되는지, 최종 실행 설정을 확인할 수 있는지 살펴보세요.
• TUN을 사용하는 경우: 서비스 설치, 관리자 권한, 가상 네트워크 어댑터, VPN과의 공존 여부를 점검하세요. TUN 스위치를 켤 수 있다고 해서 모든 앱의 트래픽이 제대로 처리되는 것은 아닙니다.

다운로드 파일 이름이 비슷하다는 이유만으로 같은 프로젝트라고 판단하지 말고, 화면에 표시되는 버전만 확인해서도 안 됩니다. GUI 클라이언트 버전과 코어 버전은 별개의 정보이므로 호환성 문제를 확인할 때 함께 기록하세요. 설치 파일은 다운로드 센터에서 확인할 수 있으며, 이 글은 이전 대상으로 기존 클라이언트 설치 파일을 제공하지 않습니다.

마이그레이션 전 백업: 구독 원본과 실행 설정 구분하기

널리 사용된 Clash for Windows 0.20.39 버전의 화면을 예로 들면, 먼저 Profiles에서 설정 소스를 확인하고 Proxies에서 선택한 프록시 그룹을 기록하세요. 마지막으로 General에서 포트, System Proxy, Allow LAN, TUN 상태를 확인합니다. 버전에 따라 메뉴 위치가 다를 수 있으니 스크린샷만 보고 버튼을 찾지 마세요.

1. 구독 소스를 저장하세요. 구독 URL, 설정 이름, 업데이트 간격, 변환 서비스를 거치는지 기록하세요. URL의 토큰은 접속 자격 증명과 같으므로 로그 스크린샷에 노출하지 마세요.
2. 구독 YAML을 저장하세요. 다시 가져오거나 오프라인에서 대조할 때 필요합니다. URL만 저장하면 나중에 로컬에서 추가한 규칙은 보존되지 않습니다.
3. 최종 실행 설정을 저장하세요. 실제 적용된 필드를 확인하는 데 유용하지만, 클라이언트가 생성한 포트, 제어 인터페이스, 캐시 경로가 포함되어 있을 수 있으므로 새 클라이언트 설정에 그대로 덮어쓰지 마세요.
4. Parsers, Mixin, 스크립트도 따로 저장하세요. 특정 구독에만 적용되는 변경인지 모든 설정에 적용되는 변경인지 기록하세요. 완전해 보이는 YAML 파일 하나만 백업해서는 안 됩니다.
5. 외부 의존성을 기록하세요. rule-providers, proxy-providers, 로컬 규칙 파일, 사용자 지정 DNS, 컨트롤 패널 연결 매개변수를 포함합니다.

기존 설정 폴더 전체를 새 폴더에 덮어쓰지 마세요. 클라이언트의 데이터베이스, 캐시, 서비스 상태, 코어 캐시는 호환되지 않을 수 있습니다. 옮길 것은 정확히 확인된 설정 및 규칙 파일이지, 기존 프로그램의 전체 실행 환경이 아닙니다.

구독 가져오기: 먼저 원본 설정만 실행하기

1. 기존 클라이언트에서 System Proxy와 TUN을 끄고 프로그램을 종료한 다음, 기존 서비스가 네트워크를 계속 제어하지 않는지 확인하세요.
2. 새 클라이언트를 열고 구독 또는 설정 관리 화면에서 기존 구독 URL을 가져오세요. 로컬 YAML만 있다면 먼저 로컬 설정으로 가져오세요. 자동으로 업데이트 주소가 등록될 것이라고 가정하지 마세요.
3. 사용자 지정 오버라이드는 잠시 적용하지 말고 구독을 한 번 업데이트한 다음 해당 설정을 활성화해 노드와 프록시 그룹이 표시되는지 확인하세요.
4. 작동 모드를 Rule(규칙)로 설정하고 프록시 그룹에서 노드를 다시 선택하세요. 기존 클라이언트의 선택 상태는 보통 YAML과 함께 이전되지 않습니다.
5. 로컬 수신 포트를 확인한 다음 새 클라이언트의 시스템 프록시를 켜고 일반 웹페이지와 프록시를 사용해야 하는 웹사이트에 접속해 보세요.

기억에 의존하지 말고 현재 실행 중인 포트를 확인하세요

기존 환경은 7890 포트를 사용했을 수 있지만 새 클라이언트는 다른 포트를 사용할 수도 있습니다. 터미널, 브라우저 확장 프로그램, 개발 도구가 여전히 이전 주소를 가리키면 시스템 프록시가 정상이어도 해당 프로그램은 연결에 실패할 수 있습니다. 아래는 포트 오버라이드 예시이며 완성된 설정 파일이 아닙니다. 클라이언트 화면에서 포트를 관리한다면 화면에서 변경하는 것이 좋습니다.

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

mixed-port는 HTTP와 SOCKS가 함께 사용하는 수신 포트를 지정합니다. Windows PowerShell에서 아래 명령으로 해당 HTTP 프록시를 거쳐 연결을 테스트할 수 있습니다. 실제 포트가 7890이 아니라면 실행 설정에 표시된 값을 사용하세요.

curl.exe --proxy http://127.0.0.1:7890 --head https://example.com/

이 테스트는 지정한 프록시 주소가 요청 하나를 처리할 수 있는지만 확인합니다. TUN, 적용된 규칙, 모든 앱이 정상이라는 뜻은 아닙니다. 407 Proxy Authentication Required가 반환되면 로컬 프록시 인증 설정을 확인하세요. 127.0.0.1에 연결할 수 없다는 메시지가 표시되면 먼저 포트와 코어 실행 상태를 점검하세요.

규칙과 오버라이드 스크립트: 로직은 옮기고 인터페이스는 그대로 쓰지 않기

Clash for Windows의 Parsers, Mixin과 새 클라이언트의 설정 병합 및 스크립트 오버라이드는 서로 다른 인터페이스입니다. 특히 JavaScript 스크립트는 입력 객체, 진입 함수, 사용 가능한 API, 실행 단계가 달라질 수 있습니다. 기존 스크립트의 확장자만 바꿔 바로 활성화하지 마세요. 클라이언트 스크립트에서 브라우저나 Node.js의 모든 기능을 사용할 수 있다고 가정해서도 안 됩니다.

기존 변경 사항을 세 가지로 나누세요

• 필드 덮어쓰기: 예를 들어 log-level, allow-lan이 있습니다. 클라이언트가 해당 필드를 관리하는지 확인한 뒤 화면 설정이나 오버라이드를 선택하세요.
• 목록 변경: 규칙, DNS 서버, 프록시 그룹 구성원을 추가하는 경우입니다. 새 도구가 목록 전체를 교체하는지, 앞에 삽입하거나 뒤에 추가할 수 있는지 확인하세요.
• 프로그램을 통한 처리: 노드 이름으로 필터링하거나 일괄 이름 변경, 동적 프록시 그룹 생성 등을 하는 경우입니다. 대상 클라이언트의 최신 스크립트 인터페이스에 맞춰 다시 작성하고 출력 설정을 비교하세요.

규칙은 위에서 아래로 순서대로 매칭됩니다. 직접 연결해야 하는 회사 도메인을 MATCH 뒤에 추가하면 해당 규칙이 적용되지 않습니다. 아래는 기본 규칙 앞에 배치해야 하는 규칙 두 개의 예시이며, 단독으로 실행할 수 있는 완성 설정은 아닙니다.

rules:
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

corp.example은 내부 도메인 매칭을 보여 주기 위한 예시입니다. 실제 적용 시 관리 중인 도메인을 입력하세요. 위 두 줄로 구독의 rules 목록 전체를 대체하지 마세요. 대상 클라이언트에서 지원하는 규칙 우선 삽입 기능이나 스크립트 인터페이스로 병합하고 기존 규칙과 기본 처리 정책을 유지해야 합니다.

규칙 제공자와 로컬 경로를 함께 확인하세요

rule-providers의 type, behavior, format은 파일 내용과 일치해야 합니다. 기존 절대 경로는 새 설치 폴더에서 유효하지 않을 수 있고, 상대 경로도 새 클라이언트가 실제로 사용하는 코어 작업 디렉터리를 기준으로 확인해야 합니다. proxy group not found와 같은 메시지가 표시되면 규칙에서 참조하는 프록시 그룹이 존재하는지 확인하세요. 이름의 공백과 대소문자도 일치해야 합니다.

DNS, TUN, 외부 제어: 마지막에 복구할 설정 세 가지

DNS: 용도는 유지하고 모든 필드를 그대로 복사하지 마세요

기존 설정의 dns.enable, enhanced-mode, nameserver, fake-ip-filter를 비교하세요. Fake-IP를 사용하는 경우 198.18.0.0/16은 흔히 쓰이는 매핑 대역이지 원격 노드 주소가 아닙니다. 코어나 DNS 모드를 바꾸면 브라우저와 운영체제에 이전 결과가 캐시되어 있을 수 있습니다. 먼저 테스트 앱을 완전히 종료했다가 다시 열고, 필요하면 Windows에서 ipconfig /flushdns를 실행하세요.

파싱 오류 하나를 없애려고 모든 DNS 설정을 공용 서버로 바꾸지 마세요. 회사 내부 도메인은 사내 DNS에 의존할 수 있습니다. 마이그레이션할 때 내부 도메인 하나와 일반 공용 도메인 하나를 각각 테스트하고, 로그로 요청이 예상한 경로를 따르는지 확인하세요.

TUN: 권한을 먼저 처리하고 라우팅 상태 확인하기

시스템 프록시 테스트를 통과한 뒤 다른 VPN이나 가상 네트워크 어댑터 제어 프로그램을 끄고, 새 클라이언트의 안내에 따라 서비스 구성 요소를 설치하거나 관리자 권한을 부여하세요. 최종 설정에서 tun.enable, stack, auto-route, dns-hijack 값을 확인하세요. 프로토콜 스택과 시스템 환경에 따라 결과가 다르므로 특정 stack 값을 모든 기기에 통하는 해결책으로 간주해서는 안 됩니다.

TUN을 끈 상태와 켠 상태에서 각각 웹페이지, 내부 사이트, 로컬 네트워크 기기, UDP가 필요한 앱을 테스트하세요. 웹페이지가 열린다고 UDP 전달까지 정상인 것은 아닙니다. UDP 전달 여부는 노드 프로토콜, 노드 서비스, 규칙에도 달려 있습니다. 네트워크가 끊기면 먼저 TUN을 끄고 검증된 시스템 프록시 상태로 되돌린 다음 항목별로 확인하세요.

외부 제어: 기존 수신 주소를 함께 노출하지 마세요

외부 패널을 사용한다면 external-controller와 secret을 다시 확인하세요. 로컬 기기에서만 접속할 때는 127.0.0.1:9090과 같은 루프백 주소를 사용할 수 있습니다. 기존 패널을 바로 연결하려고 모든 네트워크 인터페이스에서 수신하도록 설정하지 마세요. 이전 패널에 저장된 포트와 비밀 키도 함께 업데이트해야 합니다. 일반적인 데스크톱 사용에서는 제어 인터페이스를 로컬 네트워크에 공개할 필요가 없습니다.

마이그레이션 후 연결이 안 될 때: 증상별 확인 방법

문제를 신고할 때 운영체제 버전, 클라이언트 버전, 코어 버전, 오류 발생 시각, 최소 재현 절차를 제공하세요. 설정과 로그를 공유하기 전에 구독 URL, 노드 비밀번호, 제어 키, 민감한 내부 도메인을 삭제하세요. 추가 문제 해결은 도움말 센터와 고급 설정을 참고하세요.

최종 점검과 롤백: 업데이트 한 번, 재시작 한 번

• 구독 업데이트가 성공하고 노드와 프록시 그룹이 모두 표시되며 사용자 지정 규칙이 덮어써지지 않았는지 확인하세요.
• 작동 모드가 예상한 값인지 확인하고 자주 사용하는 프록시 그룹을 다시 선택한 뒤, 연결 기록에서 올바른 규칙이 매칭되는지 점검하세요.
• 브라우저, 터미널, 내부 사이트를 각각 테스트하세요. TUN이 필요하다면 로컬 네트워크와 UDP 앱도 추가로 확인하세요.
• 클라이언트를 다시 시작한 뒤에도 포트와 오버라이드가 올바른지 확인하세요. 시스템 재시작 후에는 서비스와 시작 프로그램 설정이 예상대로 동작하는지 점검하세요.
• 기존 클라이언트의 시스템 프록시, TUN, 자동 시작을 모두 껐는지 확인하세요. 두 프로그램이 번갈아 시스템 설정을 변경하지 않도록 하세요.

롤백이 필요하면 먼저 새 클라이언트의 시스템 프록시와 TUN을 끄고, 새 클라이언트와 서비스를 종료한 다음 기존 환경을 복구하세요. 두 클라이언트의 네트워크 제어 설정을 동시에 켜서 비교하지 마세요. 최종 점검을 마친 뒤 기존 프로그램을 정리하고, 민감한 정보가 제거된 마이그레이션 기록을 보관하세요. 다음 기기로 옮길 때 활용할 수 있도록 구독 소스, 오버라이드 파일 위치, 최종 포트를 기록해 두세요.