Clash for Windows 지원 종료 후 마이그레이션: 구독, 오버라이드 스크립트와 주요 설정 옮기기

옮길 항목 네 가지부터 구분하기

Clash for Windows(이하 CFW)는 유지 관리가 중단됐습니다. 마이그레이션할 때는 기존 프로그램 폴더 전체를 새 클라이언트에 복사하는 대신 구독 주소, 설정 가공 로직, 프록시 설정, Windows 연동을 각각 옮겨야 합니다. 이 글에서는 Clash Verge Rev로 옮기는 방법을 중심으로 설명합니다. mihomo 코어를 사용하는 다른 클라이언트에서도 점검 순서는 참고할 수 있지만 메뉴 이름, 스크립트 위치, 데이터 폴더는 그대로 적용할 수 없습니다.

클라이언트와 코어는 서로 다른 소프트웨어 계층입니다. 클라이언트 UI는 구독 다운로드, 시작 프로그램 등록, 시스템 프록시 설정을 담당하고, mihomo 코어는 최종 설정을 읽어 포트를 열고 트래픽을 분기합니다. 기존 클라이언트의 UI 설정 파일은 새 코어에서 읽을 수 있는 YAML 파일과 다릅니다.

기존 클라이언트의 항목	이전 방법	다시 확인할 사항
Profiles의 구독	원본 구독 주소 다시 가져오기	유효 기간, 응답 형식, 노드와 정책 그룹
Parsers와 사용자 지정 규칙	의도를 정리한 뒤 새 클라이언트의 오버라이드로 재작성	실행 순서, 규칙 순서, 정책 그룹 이름
System Proxy와 수신 포트	새 클라이언트에서 다시 설정	실제 수신 주소, HTTP 및 SOCKS 포트
Service Mode, TUN, 시작 프로그램	해당 기능 다시 설치하거나 활성화	서비스 권한, DNS, 라우팅, 시작 항목

대체 클라이언트 선택 기준

데스크톱 구독 관리와 오버라이드 작업 흐름을 유지하려면: Clash Verge Rev를 우선 살펴보세요. 현재 릴리스의 스크립트, 설정 병합, 서비스 모드 안내를 확인해야 합니다.
기기마다 일관된 사용 경험을 원한다면: FlClash 같은 클라이언트도 비교해 볼 수 있습니다. 다만 오버라이드 스크립트가 CFW Parsers와 호환된다고 가정해서는 안 됩니다.
일반적인 구독과 규칙 모드만 필요하다면: 구독 가져오기, 정책 그룹 선택, 시스템 프록시 설정부터 시작하세요. 마이그레이션을 위해 TUN을 바로 켤 필요는 없습니다.

클라이언트별 다운로드 링크는 클라이언트 비교에서 확인하세요. 설치 전 Windows 아키텍처와 릴리스 노트를 확인하고, 설치 후에는 '정보' 페이지에서 클라이언트 버전과 코어 버전을 기록해 두세요. 문제가 생겼을 때 이 두 정보가 단순히 '최신 버전'이라고 적는 것보다 유용합니다.

기존 설정 백업과 롤백 경로 확보

먼저 CFW가 정상 작동하는 상태에서 백업하세요. 일반적인 설치 방식에서 데이터는 사용자 폴더 아래의 .config/clash에 있지만, 포터블 모드나 사용자 지정 실행 매개변수를 사용하면 위치가 달라질 수 있습니다. 기존 클라이언트의 설정 폴더 열기 기능으로 실제 폴더를 찾고, 온라인에서 본 경로만 믿고 찾지 마세요.

원본 구독 주소를 저장하고 구독 이름, 마지막 업데이트 시각, 업데이트 간격을 기록하세요. 주소에 인증 정보가 포함되는 경우가 많으므로 신뢰할 수 있는 로컬 위치에만 보관해야 합니다.
로컬 YAML, Parsers 내용과 관련 스크립트를 백업하세요. 코드만 저장하지 말고 각 가공 로직의 목적도 기록해 두세요. 예: '개발 사이트를 지정된 정책 그룹에 추가'.
현재 모드, 선택한 정책 그룹, HTTP/SOCKS 포트, LAN 연결 허용 여부, TUN과 DNS의 사용자 지정 설정을 기록하세요.
시작 프로그램, 서비스 모드, 시스템 프록시 상태를 기록하세요. 먼저 스크린샷을 찍고 기존 클라이언트를 종료해 디스크에 저장되지 않은 설정을 읽지 않도록 하세요.
백업 파일은 별도 폴더에 복사하세요. 새 클라이언트가 기존 클라이언트의 데이터 폴더를 직접 사용하게 하지 말고, 첫 테스트가 끝나기 전에는 기존 프로그램을 제거하지 마세요.

새 클라이언트 테스트를 시작하기 전에 CFW의 시스템 프록시와 자동 시작을 끄고 코어 프로세스가 종료됐는지 확인하세요. 포트가 서로 달라도 두 클라이언트가 Windows 시스템 프록시 설정을 번갈아 변경할 수 있습니다. TUN 인스턴스 두 개를 동시에 실행하면 라우팅과 DNS 동작을 파악하기 어려워질 수도 있습니다.

원본 구독을 먼저 가져온 다음 생성된 설정 확인

Clash Verge Rev의 '구독' 페이지에서 가져오기 기능을 열고 원본 구독 주소를 붙여 넣은 뒤, 가져온 설정을 선택하세요. 릴리스에 따라 버튼 이름이 '가져오기' 또는 '새로 만들기'일 수 있으니 현재 버전을 기준으로 확인해야 합니다. 이 단계에서는 기존 스크립트를 추가하지 마세요. 먼저 구독을 새 클라이언트에서 다운로드할 수 있고 mihomo가 받아들이는지 확인하는 것이 목적입니다.

서로 다른 세 가지 주소를 혼동하지 마세요

구독 주소: 노드 또는 전체 설정을 반환하며, 보통 토큰이 포함되어 업데이트 원본으로 사용할 수 있습니다.
서비스 제공업체 계정 페이지: 로그인 페이지를 반환합니다. 이를 구독 입력란에 붙여 넣으면 HTML 파싱 오류가 발생하는 경우가 많습니다.
로컬에서 내보낸 YAML: 오프라인 문제 해결에 쓸 수 있지만, 일반적으로 원래 구독의 업데이트 연결까지 복원하지는 않습니다.

가져온 후 노드 수, 정책 그룹, 규칙이 있는지 확인하세요. 노드 수가 다르다고 해서 반드시 누락된 것은 아닙니다. 구독 매개변수, User-Agent 또는 서비스 제공업체의 템플릿에 따라 응답 내용이 달라질 수 있습니다. 먼저 원본 응답과 비교하고, 필요한 경우에만 요청 헤더를 조정하세요. 인증 정보가 들어 있는 주소를 출처 불명의 온라인 변환 서비스에 입력하지 마세요.

세 단계로 검증하기

다운로드 단계: 구독 업데이트가 성공하고 로그인 페이지, 만료 안내 또는 빈 응답이 반환되지 않습니다.
설정 단계: 코어가 정상적으로 시작되고 로그에 알 수 없는 필드, 존재하지 않는 정책 그룹 참조, YAML 타입 오류가 없습니다.
연결 단계: 사용할 노드를 하나 선택해 실제 요청을 테스트하세요. 지연 시간 테스트에 성공해도 테스트 대상에 연결할 수 있다는 뜻일 뿐, 브라우저 접속과 트래픽 분기까지 검증된 것은 아닙니다.

기존 구독이 CFW Parsers를 통해야 정상 작동한다면 '형식 변환'과 '규칙 추가'를 먼저 구분하세요. 일반적인 규칙 추가는 다음 단계에서 다시 구성할 수 있습니다. 반환 형식이 mihomo에 맞지 않는다면 기존 폴더를 복사해 해결하려 하지 말고 구독 제공업체에 호환 형식을 요청하세요.

Parsers 마이그레이션: 로직은 유지하고 호출 문법은 바꾸기

CFW Parsers는 구독 URL에 따라 항목을 찾아 YAML 수정이나 JavaScript를 실행할 수 있습니다. Clash Verge Rev의 설정 병합과 스크립트 설정은 자체 호출 규약과 적용 범위를 사용합니다. 기존 코드의 parsers, reg, yaml 같은 외부 구조를 일반 mihomo 필드처럼 최종 설정에 붙여 넣어서는 안 됩니다.

기존 로직을 규칙 추가·삭제, DNS 같은 최상위 필드 수정, 노드 또는 정책 그룹 재작성의 세 그룹으로 나누는 것이 좋습니다. 한 번에 한 그룹씩 옮기고 적용한 뒤 클라이언트가 제공하는 최종 설정 또는 실행 설정을 확인하세요. 필드에 관한 정확한 설명은 규칙 문법과 DNS 설정을 참고하세요.

예시: GitHub 도메인을 기존 정책 그룹에 추가하기

아래 예시는 function main(config) 진입점을 사용하는 Clash Verge Rev JavaScript 스크립트 설정용이며, CFW Parsers 전체를 대체하지는 않습니다. 구독에 '节点选择'라는 정책 그룹이 이미 있어야 합니다. 사용 전에 실제 그룹 이름을 확인하세요. 대소문자와 공백도 일치해야 합니다.

function main(config) {
  const groups = Array.isArray(config["proxy-groups"])
    ? config["proxy-groups"]
    : [];

  if (!groups.some(group => group.name === "节点选择")) {
    throw new Error("정책 그룹을 찾을 수 없습니다: 节点选择");
  }

  if (!Array.isArray(config.rules)) {
    throw new Error("현재 설정에 rules 목록이 없습니다");
  }

  const customRule = "DOMAIN-SUFFIX,github.com,节点选择";
  config.rules = [
    customRule,
    ...config.rules.filter(rule => rule !== customRule)
  ];

  return config;
}

이 스크립트는 규칙을 맨 앞에 추가하고 완전히 동일한 항목이 중복되지 않도록 합니다. github.com과 그 하위 도메인만 처리하므로 GitHub가 사용하는 다른 리소스 도메인까지 자동으로 포함되지는 않습니다. 마이그레이션할 때는 명확히 지정된 매칭 범위를 유지하고, 검증되지 않은 전체 사이트 규칙으로 예시를 확장하지 마세요.

규칙 순서와 병합 방식이 중요합니다

규칙은 보통 순서대로 매칭됩니다: 최종 대체 규칙인 MATCH 뒤에 사용자 지정 규칙을 두면 대개 실행되지 않습니다.
배열이 자동으로 추가된다고 보장할 수 없습니다: 설정 병합 방식에 따라 rules 배열 전체를 덮어쓸 수 있습니다. 수정 후 기존 구독 규칙이 남아 있는지 확인하세요.
구독별 오버라이드와 전역 오버라이드는 적용 범위가 다릅니다: 특정 구독에서만 사용하는 정책 그룹 규칙은 해당 구독에 연결하세요. 그래야 설정을 전환했을 때 존재하지 않는 그룹을 참조하는 일을 막을 수 있습니다.
업데이트할 때마다 설정이 다시 생성됩니다: 캐시나 생성 파일을 직접 수정하면 업데이트 후 사라질 수 있습니다. 변경 사항은 클라이언트가 지원하는 영구 오버라이드 기능에 넣으세요.

시스템 프록시와 포트를 다시 설정하고 코어가 하나만 수신하는지 확인

기존 UI를 보고 새 포트도 7890이라고 단정하지 마세요. 아래에서는 127.0.0.1:7890을 혼합 프록시 포트 예시로 사용하지만, 실제 설정은 새 클라이언트에 표시된 값을 따르세요. mihomo의 mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받을 수 있습니다. HTTP와 SOCKS를 별도로 수신하면 포트가 다를 수 있습니다.

수신 상태를 확인한 다음 시스템 프록시 켜기

PowerShell에서 아래 명령을 실행해 예시 포트를 수신하는 프로세스를 확인하세요. 새 클라이언트에서 포트가 사용 중이라는 메시지가 표시되면 프로세스 ID로 프로그램을 찾으세요. 어떤 프로세스인지 모르는 시스템 프로세스를 바로 종료하지 마세요.

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Name "*clash*", "*mihomo*" -ErrorAction SilentlyContinue |
  Select-Object Id, ProcessName, Path

수신 상태가 정상인지 확인한 뒤 새 클라이언트에서 '시스템 프록시'를 켜세요. Windows 11에서는 '설정' → '네트워크 및 인터넷' → '프록시'에서 수동 프록시 주소를 확인할 수 있습니다. Windows 10에서도 '설정' → '네트워크 및 인터넷' → '프록시' 경로를 사용합니다. 포트는 새 클라이언트의 HTTP 또는 혼합 포트와 일치해야 합니다.

이 PC에서만 사용한다면 일반적으로 LAN 연결 허용을 켤 필요가 없습니다. 연결 오류를 없애려고 수신 주소를 모든 네트워크 인터페이스로 바꾸거나 컨트롤 인터페이스를 LAN에 공개하지 마세요. 컨트롤 인터페이스의 주소와 키는 별도 설정이며 시스템 프록시 포트와는 다릅니다.

명시적 프록시 요청으로 문제 범위 좁히기

curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/
curl.exe --proxy socks5h://127.0.0.1:7890 --head --max-time 15 https://example.com/

예시에서는 시간 제한을 15초로 설정하고 프록시를 명시적으로 지정하므로 브라우저가 시스템 설정을 읽는지에 의존하지 않습니다. 두 번째 명령의 socks5h는 대상 도메인 이름의 해석을 프록시 측에 맡깁니다. HTTP 응답을 받으면 해당 테스트 경로가 연결된 것이지만, 연결 패널에서 적용된 규칙, 정책 그룹, 출구 노드도 확인해야 합니다.

브라우저에서는 연결되지만 터미널에서는 안 된다면 터미널 환경 변수와 앱 자체 설정을 확인하세요. HTTP_PROXY, HTTPS_PROXY, ALL_PROXY가 여전히 이전 포트를 가리킬 수 있습니다. WinHTTP 프록시도 Windows 사용자 계정의 시스템 프록시와 별도로 관리됩니다. 시스템 프록시를 한 번 켰다고 모든 앱의 설정이 바뀐 것은 아닙니다.

기본 연결을 확인한 다음 TUN과 DNS 설정하기

시스템 프록시 테스트가 통과한 뒤 TUN이 필요한지 판단하세요. TUN은 가상 네트워크 어댑터와 라우팅을 이용해 트래픽을 처리하므로 시스템 프록시를 따르지 않는 일부 앱도 지원할 수 있습니다. 그렇다고 모든 트래픽이 원격 프록시를 거친다는 뜻은 아닙니다. 실제 경로는 규칙, 라우팅 제외 항목, 직접 연결 정책에 따라 달라집니다.

먼저 기존 클라이언트의 TUN을 끄고 기존 코어와 서비스가 자동으로 재시작되지 않는지 확인하세요.
새 클라이언트의 현재 버전 안내에 따라 서비스 모드를 설치하거나 활성화하세요. 기존 CFW 서비스는 새 클라이언트의 서비스로 그대로 사용할 수 없습니다.
새 클라이언트에서 생성한 기본 TUN 설정을 유지하고, 기존 가상 네트워크 어댑터 매개변수, DNS 하이재킹 규칙, 사용자 지정 라우팅을 한꺼번에 가져오지 마세요.
TUN을 켠 뒤 일반 웹사이트, LAN 기기, 절전 모드에서 깨어난 뒤의 연결을 테스트하세요. 기업 VPN과 다른 가상 네트워크 어댑터도 각각 테스트해 동시에 켰을 때 충돌 원인을 찾기 어려워지지 않도록 하세요.

DNS 설정에서는 enhanced-mode, fake-ip-filter, 업스트림 리졸버, 클라이언트가 생성한 오버라이드를 따로 확인해야 합니다. 기존 설정이 fake-ip를 사용했다고 해서 이전 DNS 필드를 전부 그대로 복사해야 하는 것은 아닙니다. 필드 지원 여부는 현재 mihomo 버전을 기준으로 확인하세요. 규칙 기반 DNS 해석을 사용한다면 도메인 규칙과 DNS 요청 경로의 관계도 살펴봐야 합니다.

TUN을 켠 뒤 회사 내부 도메인만 실패한다면 기업 DNS와 트래픽 분기 요구 사항을 우선 확인하세요. LAN 주소만 실패한다면 라우팅과 직접 연결 규칙을 살펴보세요. 내부 네트워크 전체를 원격 노드로 보내는 것부터 시도하지 마세요. TUN을 끄고 시스템 프록시로 다시 테스트하면 구독 문제와 가상 네트워크 어댑터 문제를 구분하는 데 도움이 됩니다.

업데이트 검증, 문제 해결, 기존 클라이언트 정리

웹페이지가 열린다는 것만으로 마이그레이션이 완료됐다고 판단해서는 안 됩니다. 구독을 한 번 수동 업데이트하고 클라이언트를 한 번 재시작한 뒤, Windows 로그인 후 자동 시작도 확인하세요. 업데이트 후에도 사용자 지정 규칙이 유지되어야 오버라이드가 영구 설정에 제대로 반영된 것입니다.

증상	먼저 확인할 항목	다음 단계
가져온 뒤 노드가 표시되지 않음	구독 응답, 유효 기간, 형식	오버라이드를 잠시 끄고 원본 구독만 따로 확인
설정을 적용할 수 없음	스크립트 오류, 규칙 대상, 필드 타입	가장 최근에 추가한 수정 항목 비활성화
업데이트 후 규칙이 사라짐	생성 파일을 직접 수정했는지 여부	영구 스크립트 또는 설정 병합으로 옮기기
로컬 포트 연결이 거부됨	코어 상태, 실제 포트, 포트를 점유한 프로세스	먼저 수신 상태를 복구한 다음 네트워크 확인
재시작 후 프록시 주소가 이전 값으로 돌아감	기존 클라이언트의 자동 시작, 이전 서비스, 다른 프록시 프로그램	프록시 관리 기능은 하나만 사용
TUN을 켠 뒤 내부 네트워크에 연결할 수 없음	라우팅, DNS, 기업 VPN	시스템 프록시로 되돌리고 항목별로 다시 테스트

마이그레이션 완료 전 체크리스트

구독을 수동 업데이트할 수 있고 노드와 정책 그룹이 예상대로 표시됩니다.
사용자 지정 규칙이 올바르게 적용되며 규칙에서 참조하는 정책 그룹 이름이 실제로 존재합니다.
정상 종료 후 다시 시작해도 시스템 프록시 포트가 기존 프로그램에 의해 이전 값으로 바뀌지 않습니다.
프록시가 필요한 브라우저, 터미널, 기타 앱을 각각 테스트했습니다.
TUN을 사용하는 경우 LAN, DNS, 절전 모드 복귀, 다른 VPN을 각각 확인했습니다.
원본 구독 주소, 오버라이드 스크립트, 설정 기록을 별도 백업에 보관했습니다.

위 항목을 확인한 뒤 기존 클라이언트를 제거하고, 더 이상 필요하지 않은 서비스는 기존 클라이언트가 제공하는 관리 방법으로 삭제하세요. 임시로 되돌려야 한다면 새 클라이언트의 시스템 프록시와 TUN을 끄고 코어를 종료한 다음 기존 클라이언트를 시작하세요. 두 프로그램이 동시에 네트워크를 제어하게 하지 마세요. 마이그레이션 후 일상 설정은 연결 확인 가이드를 참고하고, 구독 관리 절차는 구독 가져오기 안내에서 확인하세요.