클라이언트 선택 예상 읽기 시간 12분

Clash for Windows 지원 종료 후 마이그레이션 방법: 대체 클라이언트와 설정 이전 가이드

데스크톱 클라이언트의 유지보수 상태, 플랫폼 지원 범위와 설정 호환성을 비교하고 구독 및 규칙 이전 절차를 정리합니다.

Clash for Windows 지원이 중단된 뒤에도 기존 버전을 계속 보관한다고 해서 현재 설정이 즉시 작동하지 않는 것은 아닙니다. 구독 URL, 프록시 노드, 프록시 그룹과 분할 라우팅 규칙은 대개 설정 파일에 저장되며, 클라이언트는 설정 관리, 코어 실행, 시스템 프록시, TUN 연결과 화면 조작을 담당합니다. 따라서 마이그레이션의 핵심은 외관이 완전히 같은 프로그램을 찾는 것이 아니라, 새 클라이언트가 필요한 코어를 실행하고 기존 설정 문법을 읽으며 운영체제 네트워크 설정을 정상적으로 인계할 수 있는지 확인하는 데 있습니다.

가장 안전한 방법은 먼저 기존 데이터를 백업한 다음, 현재도 유지보수가 이루어지는 데스크톱 클라이언트를 선택하고 구독 URL이나 원본 YAML을 다시 가져오는 것입니다. 마지막으로 규칙 모드, 프록시 그룹, DNS, 시스템 프록시와 TUN을 항목별로 점검하세요. 기존 클라이언트가 트래픽을 처리하는 상태에서 새 클라이언트를 바로 실행하면 두 프로그램이 시스템 프록시, 가상 네트워크 어댑터 또는 서비스 상태를 동시에 변경할 수 있어 문제 원인을 파악하기 어려워집니다.

먼저 이전 대상이 구독인지, 설정인지, 실행 환경인지 확인하기

Clash for Windows에서 보이는 ‘설정’은 서로 다른 출처에서 올 수 있습니다. 가장 흔한 것은 원격 구독입니다. 클라이언트가 구독 URL을 저장하고, 업데이트할 때 YAML을 내려받아 노드, 프록시 그룹과 규칙을 읽습니다. 두 번째는 직접 가져온 로컬 YAML로, 직접 작성한 분할 라우팅 파일 등이 여기에 해당합니다. 세 번째는 클라이언트 자체 설정으로, 시작 시 자동 실행, 시스템 프록시 포트, 화면 기본 설정, 설정 오버라이드, 스크립트 처리와 TUN 서비스가 포함됩니다. 이 세 가지 데이터는 이전 가능성이 서로 다릅니다.

데이터 유형 권장 이전 방법 주요 주의사항
원격 구독 새 클라이언트에서 구독 URL 다시 추가 구독이 여전히 유효한지 확인하고 업데이트된 프록시 그룹 점검
로컬 YAML 원본 파일을 복사한 뒤 로컬에서 가져오기 코어 문법, 외부 규칙 세트 경로와 인증서 경로 확인
수동 노드 전체 설정 내보내기 또는 다시 입력 화면에 표시된 노드 이름만 복사하지 않기
시스템 프록시 새 클라이언트에서 다시 활성화 기존 클라이언트를 종료한 뒤 먼저 시스템 네트워크 설정 복원
TUN 모드 새 클라이언트에서 서비스 다시 설치 또는 활성화 가상 네트워크 어댑터, 권한과 라우팅 상태는 그대로 복사할 수 없음
오버라이드 및 스크립트 새 클라이언트의 방식에 맞춰 다시 설정 클라이언트마다 처리 인터페이스가 달라 대개 호환되지 않음

원래 서비스 제공업체의 구독만 가져왔고 YAML을 직접 수정하지 않았다면 마이그레이션은 대개 간단합니다. 구독 URL과 자주 사용하는 프록시 그룹 선택만 기록한 뒤 새 클라이언트에서 다시 가져오면 됩니다. 사용자 지정 규칙, 프록시 제공자 또는 DNS 매개변수를 장기간 관리해 왔다면 원본 YAML, 외부 규칙 파일과 관련 경로를 함께 정리해야 합니다. 기존 클라이언트가 현재 생성한 실행 설정만 복사해서는 안 됩니다.

대체 클라이언트 선택 기준: 코어, 플랫폼과 설정 기능

데스크톱 대체 클라이언트는 유지보수 상태를 먼저 확인한 뒤 운영체제 지원 범위와 코어 기능을 살펴봐야 합니다. Clash Verge Rev는 Windows, macOS와 Linux를 지원하는 데스크톱 클라이언트이며 mihomo 코어를 사용합니다. 규칙 기반 분할 라우팅, 설정 관리, 시스템 프록시와 TUN이 필요한 사용자에게 적합합니다. mihomo는 Clash 설정 체계를 이어받으면서 규칙 세트, 프로토콜, DNS와 트래픽 인계 기능을 확장했기 때문에 일반적인 Clash YAML은 대부분 계속 사용할 수 있습니다.

현재도 유지보수가 이루어지는 다른 mihomo 그래픽 클라이언트도 후보가 될 수 있지만, 화면만 비교해서는 안 됩니다. 출시 빈도, 사용 중인 코어 버전, 설정 파일 저장 방식, 시스템 프록시 복원 방식, TUN 서비스 설치 방법, 연결·로그·규칙 매칭 결과를 확인할 수 있는지가 더 중요합니다. 유지보수 상황은 시간이 지나며 달라질 수 있으므로 프로젝트의 최신 릴리스 기록과 문서를 기준으로 판단하세요.

대체 클라이언트 선택 시 확인할 6가지

  1. 플랫폼 지원: 현재 사용하는 Windows, macOS 또는 Linux 버전을 공식적으로 지원하는지 확인하고 알맞은 프로세서 아키텍처를 선택하세요.
  2. 코어 유형: mihomo를 사용하는지, 클라이언트에서 코어 버전을 확인하거나 업데이트할 수 있는지 우선 확인하세요.
  3. 설정 호환성: 구독, 로컬 YAML, 프록시 제공자, 규칙 제공자와 사용자 지정 DNS를 지원하는지 확인하세요.
  4. 트래픽 인계 방식: 시스템 프록시와 TUN을 별도로 제어할 수 있는지, 프로그램 종료 시 시스템 설정을 복원하는지 확인하세요.
  5. 진단 기능: 연결 목록, 실시간 로그, 규칙 매칭과 DNS 로그가 있으면 마이그레이션 문제를 찾는 데 도움이 됩니다.
  6. 설정 유지 방식: 구독 업데이트, 오버라이드 또는 병합 방식을 확인해 업데이트할 때마다 로컬 수정 사항이 덮어써지지 않도록 하세요.

기존 Clash for Windows의 일부 설정은 당시 Clash Premium의 동작에 의존하거나 클라이언트 전용 parser 기능으로 구독을 변환했을 수 있습니다. mihomo는 일반적인 노드, 프록시 그룹과 규칙 문법의 호환성이 높지만, 클라이언트 전용 스크립트, JavaScript 파싱 로직과 화면 설정은 공통 YAML 표준에 포함되지 않으므로 대개 다시 구성해야 합니다. 선택하기 전에 클라이언트 비교를 확인한 뒤 플랫폼과 설정 복잡도에 따라 결정하세요.

마이그레이션 전 Clash for Windows 데이터 백업 방법

백업의 목적은 복구 가능한 정보를 보존하는 것이지, 기존 폴더 전체를 새 클라이언트 폴더에 그대로 덮어쓰는 것이 아닙니다. 시작하기 전에 Clash for Windows를 열고 현재 활성화된 설정 이름, 프록시 모드, 자주 사용하는 프록시 그룹 선택, 시스템 프록시 상태와 TUN 상태를 기록하세요. 설정 관리 화면에서 구독 URL을 확인할 수 있다면 별도로 저장하세요. 구독 주소에 액세스 토큰이 포함되어 있다면 백업을 통제된 위치에 보관하고 공개 스크린샷, 로그나 포럼에 붙여넣지 마세요.

그런 다음 Clash for Windows를 종료하고 트레이 프로세스까지 완전히 끝났는지 확인하세요. Windows의 기존 데이터는 대개 사용자 디렉터리 아래 설정 폴더에 있지만, 설치 방식과 버전에 따라 위치가 달라집니다. 고정 경로를 추측하기보다 클라이언트 설정이나 설정 관리 화면에서 데이터 폴더를 연 다음 전체 폴더를 복사해 읽기 전용 백업으로 보관하는 편이 안전합니다.

보관을 권장하는 항목

  • 구독 URL, 구독 이름과 마지막으로 성공한 업데이트 시각;
  • 직접 작성한 YAML 파일과 그 안에서 참조하는 로컬 규칙 파일;
  • 현재 실행 중인 설정. 마이그레이션 후 구간별 비교에 사용;
  • 자동 선택, 장애 조치 또는 지정 노드 등 프록시 그룹에서 자주 사용하는 선택;
  • 사용자 지정 포트, LAN 접근, DNS 리스닝과 컨트롤러 설정;
  • 오버라이드, 병합 또는 parser 스크립트의 원본 파일과 처리 로직 설명.

백업이 끝나면 기존 클라이언트에서 시스템 프록시와 TUN을 끈 뒤 정상적으로 종료하세요. 운영체제 프록시 설정을 열어 수동 프록시가 기존 로컬 포트를 계속 가리키고 있지 않은지 확인할 수 있습니다. 기존 TUN 서비스가 남아 있다면 먼저 기존 클라이언트의 서비스 관리 메뉴에서 중지하거나 제거한 다음 새 클라이언트의 해당 서비스를 설치하세요.

구독 및 YAML 설정 이전 절차

방법 1: 구독 URL 다시 가져오기

대부분의 사용자에게 구독을 다시 추가하는 방법이 가장 좋습니다. 새 클라이언트를 설치한 뒤 먼저 시스템 프록시와 TUN을 끄고 설정 또는 구독 화면으로 이동해 기존 구독 URL을 붙여넣으세요. 클라이언트가 설정을 다운로드하고 파싱할 때까지 기다립니다. 가져오기가 끝나면 노드 수, 프록시 그룹 이름과 규칙 수가 예상과 맞는지 확인한 뒤 자주 사용하는 프록시를 직접 선택하세요.

구독 가져오기에 성공했다는 것은 YAML을 읽을 수 있다는 뜻일 뿐, 트래픽이 정상적으로 흐른다는 의미는 아닙니다. MATCH 같은 최종 기본 규칙이 설정에 포함되어 있는지, 주요 프록시 그룹이 유효한 노드를 참조하는지도 확인해야 합니다. 일부 구독은 클라이언트 요청 헤더에 따라 서로 다른 형식으로 응답합니다. 새 클라이언트에서 빈 설정이나 형식 오류가 발생하면 먼저 구독 서비스 제공업체의 관리 페이지에서 Clash 또는 mihomo용 구독 주소를 다시 발급받으세요.

방법 2: 로컬 YAML 가져오기

로컬 설정은 새 클라이언트의 파일 가져오기 기능으로 추가해야 합니다. 가져오기 전에 텍스트 편집기로 proxies, proxy-providers, proxy-groups, rule-providers, rules와 dns 등 주요 구간을 확인할 수 있습니다. 프록시 그룹이 참조하는 노드나 제공자 이름은 실제로 존재해야 하며, 규칙에서 참조하는 프록시 그룹도 정의된 이름과 완전히 일치해야 합니다.

mode: rule
mixed-port: 7890

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

위 구조는 가장 기본적인 참조 관계를 보여줍니다. 규칙이 트래픽을 PROXY로 전달하고, PROXY 프록시 그룹은 반드시 미리 정의되어 있어야 합니다. 실제 마이그레이션에서는 예시 포트나 규칙을 기계적으로 복사하지 말고 기존 설정의 요구사항을 유지하면서 새 클라이언트의 사용 현황에 맞게 조정하세요. 설정이 상대 경로 파일을 참조한다면 새 클라이언트의 작업 디렉터리도 확인해야 합니다. 애플리케이션을 바꾸면 같은 상대 경로가 다른 위치를 가리킬 수 있습니다.

방법 3: 오버라이드 및 병합 로직 다시 구성하기

일부 Clash for Windows 사용자는 parser를 이용해 구독에 규칙을 추가하거나 프록시 그룹을 삭제하고 노드 이름을 변경했습니다. 이런 로직은 일반 YAML로 가져올 수 없는 경우가 많습니다. 마이그레이션할 때는 먼저 구독에서 생성된 기본 설정을 확보한 뒤 새 클라이언트가 지원하는 오버라이드, 병합 또는 스크립트 기능으로 같은 결과를 다시 구성하세요.

다시 구성할 때는 작업을 작게 나누는 것이 좋습니다. 먼저 프록시 그룹 하나를 추가하고 해당 규칙을 넣은 뒤 설정이 정상적으로 로드되는지 확인하세요. 스크립트를 한 번에 대량으로 옮기면 문법 오류, 이름 참조 오류와 규칙 순서 문제가 뒤섞입니다. 규칙은 위에서 아래로 평가되며 일치하는 순간 처리가 멈추므로, 새 규칙은 적절한 위치에 넣어야 합니다. 규칙 내용이 존재하는지만 확인해서는 충분하지 않습니다.

TUN, DNS와 시스템 프록시는 그대로 복사할 수 없음

시스템 프록시는 운영체제의 프록시 설정을 따르는 애플리케이션에만 영향을 줍니다. 일반적인 브라우저와 일부 데스크톱 프로그램은 로컬 HTTP 또는 SOCKS 포트를 사용합니다. 반면 TUN은 가상 네트워크 인터페이스와 라우팅을 통해 시스템 프록시를 읽지 않는 프로그램을 포함해 더 많은 트래픽을 인계합니다. 둘 다 실행 환경 설정이며 구독의 노드 데이터가 아니므로 클라이언트를 바꾼 뒤 반드시 다시 설정해야 합니다.

먼저 시스템 프록시로 기본 동작을 확인하는 것이 좋습니다. 사용 가능한 노드를 선택하고 규칙 모드와 시스템 프록시를 활성화한 뒤 웹 페이지 접속, 규칙 매칭과 DNS 해석이 정상인지 확인하세요. 기본 연결이 안정된 후 TUN을 켜고 새 클라이언트의 안내에 따라 서비스를 설치하거나 관리자 권한을 부여합니다. 이렇게 하면 문제가 설정 파일 때문인지, 가상 네트워크 어댑터·권한·라우팅 때문인지 구분하기 쉽습니다.

DNS 설정은 특히 신중해야 합니다. mihomo에서 흔히 사용하는 강화 모드에는 fake-ip와 redir-host가 있으며, 실제 사용 가능한 항목은 코어 버전과 설정에 따라 달라집니다. 마이그레이션 후 웹 페이지는 열리지만 일부 LAN 도메인, 게임 또는 기업용 프로그램에 문제가 생긴다면 즉시 노드를 바꾸기보다 DNS 리스닝 주소, 강화 모드, 제외 목록, 업스트림 서버와 규칙 모드를 확인하세요.

기존 설정에서 LAN 접근을 활성화했다면 allow-lan, 리스닝 주소와 운영체제 방화벽도 다시 확인해야 합니다. 루프백 주소에서 수신하면 로컬 컴퓨터만 사용할 수 있지만, 모든 인터페이스에서 수신하면 같은 네트워크의 다른 기기가 연결할 수 있습니다. 마이그레이션할 때는 실제 공유 필요에 맞춰 설정하고, 기존 설정이 있다는 이유만으로 그대로 복사하지 마세요.

마이그레이션 후 트래픽 경로 확인 방법

마이그레이션 검증은 설정 로드, 노드 연결, 규칙 매칭, 시스템 설정 복원 순서로 단계별 진행해야 합니다. 웹 페이지 하나만 테스트하면 브라우저 캐시, 연결 재사용과 애플리케이션 자체 DNS 때문에 문제를 놓치기 쉽습니다. 다음 순서로 확인하세요.

  1. 새 클라이언트를 실행하고 로그에 YAML 파싱, 프록시 그룹 참조 또는 포트 사용 오류가 없는지 확인합니다.
  2. 구독을 업데이트하고 업데이트 시각, 노드 수와 프록시 그룹 구성이 정상인지 확인합니다.
  3. 규칙 모드에서 명확한 프록시 그룹 출구를 선택하고 일반 웹 페이지 연결을 테스트합니다.
  4. 연결 또는 로그 화면을 열어 대상 도메인이 어떤 규칙에 매칭되었고 최종 정책이 무엇인지 확인합니다.
  5. 직접 연결되어야 하는 도메인과 프록시를 사용해야 하는 도메인을 각각 테스트해 DIRECT와 프록시 정책이 예상대로 적용되는지 확인합니다.
  6. TUN을 활성화한 뒤 시스템 프록시를 읽지 않는 애플리케이션을 테스트하고 해당 연결이 코어로 유입되는지 확인합니다.
  7. 클라이언트를 종료하고 시스템 프록시가 복원되었는지, 중지된 로컬 포트로 네트워크가 계속 연결되지 않는지 확인합니다.

규칙 매칭 결과가 기존 클라이언트와 다르다면 구독 이름만 비교하지 말고 양쪽에서 실제로 로드한 최종 설정을 먼저 비교하세요. 구독 업데이트, 클라이언트 오버라이드, 규칙 세트 다운로드 실패와 코어 기능 차이가 최종 내용을 바꿀 수 있습니다. mihomo의 연결 상세 정보에는 대개 규칙 유형, 정책 체인과 출구 노드가 표시되므로 단순히 접속 속도를 관찰하는 것보다 분할 라우팅이 올바른지 판단하는 데 적합합니다.

마이그레이션 후 자주 발생하는 문제와 처리 순서

구독은 가져와지지만 노드가 없음

먼저 구독 주소가 아직 유효한지, 응답 내용이 Clash 또는 mihomo 설정인지 확인하세요. 일부 주소는 서비스 관리 페이지에서 형식을 변환해야 합니다. 브라우저에서 열었을 때 로그인 페이지, 오류 문구 또는 다른 클라이언트 형식이 표시된다면 새 클라이언트가 노드 목록을 생성할 수 없습니다.

설정에서 프록시 그룹이 없다고 표시됨

rules에서 사용하는 정책 이름이 proxy-groups에 정의된 이름과 대소문자, 공백, 기호까지 완전히 일치하는지 확인하세요. 프록시 그룹이 use를 참조한다면 해당 proxy-providers가 정의되어 있고 다운로드에도 성공했는지 확인해야 합니다. 프록시 그룹을 수동으로 삭제했다면 이를 참조하는 규칙도 함께 수정해야 합니다.

시작할 때 포트가 사용 중이라고 표시됨

기존 클라이언트나 기존 코어 프로세스가 백그라운드에서 포트를 계속 사용하고 있을 수 있습니다. 먼저 두 클라이언트를 완전히 종료하고 작업 관리자나 시스템 모니터링 도구에서 관련 프로세스가 끝났는지 확인한 뒤 새 클라이언트를 다시 실행하세요. 새 클라이언트의 혼합 포트를 임시로 변경할 수도 있지만 시스템 프록시도 반드시 새 포트를 가리키도록 바꿔야 합니다.

TUN을 켠 뒤 인터넷에 연결되지 않음

먼저 TUN을 끄고 시스템 프록시 모드가 정상인지 확인하세요. 시스템 프록시가 작동한다면 TUN 서비스, 권한, 가상 네트워크 어댑터, 라우팅과 DNS를 중점적으로 점검합니다. 여러 클라이언트를 설치했던 경우 기존 서비스가 계속 실행 중이지 않은지도 확인해야 합니다. 서비스 충돌을 해결한 뒤 시스템을 재시작해 잔여 라우팅이 판단에 영향을 주지 않도록 하세요.

구독 업데이트 후 사용자 지정 규칙이 사라짐

대개 수정 사항을 구독 캐시에 직접 저장했기 때문에 발생합니다. 원격 업데이트가 설정을 다시 다운로드하면서 캐시 내용도 덮어쓰기 때문입니다. 새 클라이언트의 오버라이드 또는 병합 기능으로 로컬 규칙을 관리하거나, 독립적인 YAML을 만들고 프록시 제공자 방식으로 원격 노드를 업데이트해야 합니다. 구체적인 필드와 사용 방법은 기술 참고서에서 확인할 수 있습니다.

기존 클라이언트를 바로 삭제해야 할까?

백업을 완료했다면 설치 파일과 데이터 폴더를 잠시 보관해도 됩니다. 다만 기존 클라이언트가 시작 시 자동 실행되거나 새 클라이언트와 동시에 시스템 프록시 또는 TUN을 인계하도록 두어서는 안 됩니다. 며칠간 사용하면서 구독 업데이트, 규칙 분할 라우팅, 절전 모드 복귀와 종료 후 설정 복원이 모두 정상인지 확인한 뒤 기존 프로그램과 서비스를 정리하는 편이 안전합니다.

마이그레이션 결론: 설정 출처는 보존하고 실행 환경은 다시 구성하기

Clash for Windows 지원 종료 후 마이그레이션의 핵심은 두 가지로 정리할 수 있습니다. 재사용할 수 있는 것은 구독, 노드, 프록시 그룹과 공통 규칙이고, 다시 구성해야 하는 것은 클라이언트 설정, 오버라이드 로직, 시스템 프록시, TUN 서비스와 일부 DNS 동작입니다. 일반적인 구독 사용자라면 구독을 다시 가져온 뒤 프록시 그룹을 확인하는 것만으로도 충분한 경우가 많습니다. 사용자 지정 YAML을 관리해 왔다면 이름 참조, 규칙 순서, 외부 파일 경로와 코어 문법을 중점적으로 점검해야 합니다.

대체 클라이언트를 고를 때는 화면이 비슷한지보다 지속적인 유지보수, mihomo 코어 지원, 진단 기능과 시스템 인계의 안정성이 더 중요합니다. 마이그레이션이 끝난 뒤 원본 설정 백업을 보관하고 새 클라이언트의 핵심 설정을 기록해 두세요. 이후 기기나 클라이언트를 바꿀 때도 특정 프로그램이 만든 임시 캐시에 의존하지 않고 명확한 데이터 출처에서 복원할 수 있습니다.

Clash 다운로드