Clash for Windows 지원 종료 후 대처법: 설정 이전 단계와 대체 클라이언트 선택

CFW 지원 종료 후 이전 범위

Clash for Windows(이하 CFW)는 설정, 노드, 시스템 프록시를 관리하는 데스크톱 클라이언트이며 Clash 코어 자체와는 다릅니다. CFW는 지원이 종료됐으며, 마지막 시기 버전으로는 0.20.39가 널리 알려져 있습니다. 기존 설치본이 실행되더라도 운영체제 호환성 수정이 계속 제공된다는 뜻은 아닙니다. 새 구독에서 사용하는 프로토콜과 필드를 구형 코어가 모두 인식한다는 보장도 없습니다.

설정을 한꺼번에 전부 다시 작성할 필요는 없습니다. 구독과 규칙을 먼저 옮기고 시스템 프록시를 복구한 다음 TUN, DNS, 자동 시작을 설정하면 문제가 어느 단계에서 발생했는지 파악하기 쉽습니다. 클라이언트를 바꾼다고 기존 구독 서비스를 다시 구매할 필요는 대개 없습니다. 새 클라이언트의 코어가 읽을 수 있는 설정을 서비스 제공자가 제공하는지 확인하면 됩니다.

설정을 세 가지로 구분하기

• 구독 설정: 노드, 그룹, 규칙, 일부 DNS 설정으로, 보통 원격 구독에서 생성됩니다.
• 로컬 수정 사항: 직접 추가한 규칙, 구독 전처리 설정, 스크립트와 오버라이드는 별도로 정리해야 합니다.
• 클라이언트 설정: 시스템 프록시, 서비스 설치, 시작 프로그램, 화면 설정은 YAML 파일을 복사하는 것만으로 모두 복원할 수 없습니다.

구독 주소, 사용자 지정 규칙, 로컬 설정 백업

현재 사용 중인 설정 기록하기

1. 기존 CFW의 Profiles 페이지에서 현재 선택된 설정을 확인하고 이름, 구독 출처, 마지막 업데이트 성공 여부를 기록하세요.
2. General 페이지에서 실제 프록시 포트와 현재 모드, System Proxy 및 TUN Mode의 활성화 여부를 확인하세요. 흔히 사용하는 HTTP 프록시 포트는 7890이지만, 실제 값은 기기에 표시된 내용을 기준으로 해야 합니다.
3. 실제 설정 폴더를 찾아 로컬 백업 폴더에 복사하세요. Windows에서 흔히 사용하는 경로는 %USERPROFILE%\.config\clash이지만, 포터블 버전이나 사용자 지정 경로는 다를 수 있으므로 기본 경로라고 단정하지 마세요.
4. 직접 수정한 YAML, 규칙 파일, 구독 전처리 설정과 스크립트는 별도로 저장하세요. 어떤 항목을 직접 수정했는지, 어떤 항목이 구독 업데이트로 생성되는지도 기록해 두세요.

설정 폴더에는 클라이언트 설정, 구독 캐시, 코어 런타임 파일이 함께 들어 있을 수 있습니다. 전체 백업은 확인 작업에 유용하지만, 새 클라이언트에 폴더 전체를 그대로 덮어쓰는 것은 권장하지 않습니다. 프로젝트마다 설정 인덱스, 데이터베이스, 파일 이름이 다르기 때문입니다.

구독 주소와 설정 스냅샷 모두 보관하기

구독 주소는 이후 업데이트에 사용하고, 현재 YAML은 노드와 규칙을 확인하는 데 사용합니다. 설정 스냅샷만 있고 원래 구독 주소가 없으면 가져온 직후에는 연결되더라도 서비스 제공자의 노드 변경 사항을 계속 받을 수 없습니다. 반대로 구독 주소만 저장하면 로컬 규칙과 트래픽 분기 설정을 놓칠 수 있습니다.

구독 URL의 토큰은 쿼리 매개변수나 경로에 포함되는 경우가 많습니다. 다른 사람에게 도움을 요청할 때는 오류 메시지와 필요한 필드만 공유하고 전체 링크는 올리지 마세요. 링크가 이미 공개됐다면 서비스 제공자 계정에서 구독 토큰을 재발급한 뒤 새 클라이언트에 반영하세요.

대체 클라이언트 선택: 플랫폼을 먼저, 코어는 다음에

대체 클라이언트를 고를 때는 프로젝트의 최근 릴리스, 운영체제 아키텍처, 코어 종류를 확인하세요. 설치 패키지 버전과 코어 버전은 서로 다릅니다. 특정 필드의 지원 여부는 클라이언트 화면에 표시된 버전 번호가 아니라 실제 실행 중인 코어 버전으로 판단해야 합니다.

위 이름은 후보를 찾기 위한 참고 정보이며 향후 지원을 보장하지 않습니다. 설치 전에 다운로드 페이지에서 현재 제공되는 플랫폼과 프로젝트 출처를 확인하세요. 관리 방식 비교는 클라이언트 비교를 참고할 수 있습니다. 이름이 비슷한 구형 CFW 재패키지 버전을 원래 프로젝트의 업데이트 버전으로 오인하지 마세요.

기존에 CFW의 Parsers나 스크립트로 구독을 처리했다면 새 클라이언트가 이에 해당하는 오버라이드 기능을 제공하는지도 확인해야 합니다. Clash YAML을 가져올 수 있다고 해서 CFW의 화면 설정이나 모든 전처리 문법까지 지원하는 것은 아닙니다.

구독과 규칙 이전: 최소한의 연결부터 복구

첫 단계에서는 구독만 가져오고 TUN은 켜지 않기

1. 기존 클라이언트에서 System Proxy와 TUN Mode를 끈 다음 종료하세요. 기존 클라이언트의 시작 프로그램 등록도 해제하세요.
2. 새 클라이언트를 설치한 뒤 구독 또는 설정 관리 페이지에서 기존 구독 URL을 가져오세요. 버전에 따라 메뉴 이름이 다를 수 있으니 화면에서 '가져오기' 또는 '구독' 항목을 찾으면 됩니다.
3. 업데이트가 끝날 때까지 기다린 뒤 노드 수와 그룹 구성이 예상과 크게 다르지 않은지 확인하고, 해당 설정을 현재 설정으로 지정하세요.
4. 규칙 모드로 전환하고 사용 가능한 것으로 확인된 노드를 하나 직접 선택한 뒤 시스템 프록시만 켜서 브라우저 연결을 테스트하세요.

가져오기에 실패하면 먼저 로그를 확인하세요. 401 또는 403 응답은 인증 정보나 서비스 제공자의 제한을 확인해야 하는 경우가 많습니다. YAML 대신 웹페이지가 반환된다면 복사한 주소가 구독 URL인지 확인하세요. 지원하지 않는 필드나 프로토콜이라는 메시지가 나오면 코어와 구독 형식을 확인하세요. 모든 규칙을 먼저 삭제하고 해결되기를 기대하지 마세요.

로컬 규칙은 안정적인 오버라이드 계층에 배치하기

규칙은 대개 위에서 아래로 검사하며 먼저 일치한 규칙이 우선 적용됩니다. 다음 세 줄은 순서만 보여주는 예시입니다. 지정한 도메인을 먼저 처리하고, 내부망 주소를 다음으로 처리한 뒤, 마지막에 기본 규칙을 적용합니다. DIRECT는 기본 제공 직접 연결 정책입니다. 정책 그룹 이름으로 바꾸려면 해당 그룹이 설정에 이미 있어야 합니다.

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

이 예시를 완전한 구독 설정으로 가져오거나 기존 rules 아래에 같은 이름의 최상위 필드를 다시 추가하지 마세요. 실제 이전 작업에서는 새 클라이언트의 규칙 병합 또는 오버라이드 기능을 사용해 사용자 규칙을 적절한 위치에 삽입하고 구독에 포함된 기본 정책은 유지해야 합니다.

기존 설정을 mihomo로 옮길 때 호환성 확인

Clash.Meta는 이후 mihomo라는 이름으로 이어졌습니다. 기본 Clash YAML 필드는 상당수 계속 사용할 수 있지만, 구형 클라이언트 전용 기능을 같은 이름의 설정으로 그대로 옮길 수 있다고 가정해서는 안 됩니다. 이전할 때는 proxies, proxy-groups, rules와 같은 핵심 구조를 우선 보존하고 확장 기능은 하나씩 확인하세요.

• 기존 스크립트와 전처리: CFW Parsers, JavaScript 처리 과정, 구형 코어의 스크립트 모드가 새 클라이언트에서도 그대로 실행된다고 가정하지 마세요. 먼저 해당 기능을 제공하는 주체를 확인한 뒤 새 클라이언트 방식에 맞게 수정하세요.
• 규칙 파일 경로: rule-providers의 상대 경로는 새 설정 디렉터리에 따라 달라질 수 있습니다. 로컬 규칙 파일을 복사한 뒤 경로와 읽기 권한을 확인하세요.
• 그룹 참조: 규칙에서 참조하는 그룹 이름은 정확히 일치해야 합니다. 공백과 대소문자도 확인하세요. 그룹 이름이 없으면 설정을 불러오지 못하거나 규칙이 예상대로 작동하지 않을 수 있습니다.
• 컨트롤러 권한: 원격 관리가 필요하지 않다면 external-controller를 루프백 주소에만 바인딩하세요. 모든 네트워크 인터페이스에서 수신하면서 접근 키가 없는 기존 설정을 그대로 가져오지 마세요.
• DNS 설정: 먼저 기존 동작을 기준으로 기록한 다음 fake-ip, 상위 DNS 서버, 도메인 정책을 조정하세요. 코어를 바꾸면서 DNS 방식까지 한꺼번에 변경하면 문제 원인을 찾기 어려워집니다.

독립형 mihomo 코어를 사용한다면 mihomo -t -f config.yaml 명령으로 지정한 설정 파일이 검증을 통과하는지 확인할 수 있습니다. 실행 시에는 실제 파일 경로를 사용하세요. 그래픽 클라이언트에서는 설정 검사 결과와 코어 로그를 먼저 확인하면 됩니다. 검사를 통과해도 설정을 불러올 수 있다는 뜻일 뿐, 구독 주소와 규칙 소스, 모든 노드의 네트워크 연결까지 정상이라는 의미는 아닙니다.

시스템 프록시, TUN, 포트 충돌 문제 해결

브라우저는 되지만 다른 프로그램은 연결되지 않는 경우

시스템 프록시는 시스템 프록시 설정을 따르는 앱에서 주로 작동하며 모든 프로그램이 이를 사용한다고 보장할 수는 없습니다. 먼저 대상 프로그램에 별도의 프록시 설정이 있는지 확인하세요. 시스템 프록시를 따르지 않는 트래픽까지 제어해야 한다면 새 클라이언트 안내에 따라 TUN을 활성화하고 서비스 설치나 관리자 권한을 설정하세요.

기존 CFW의 서비스 설치 상태는 새 클라이언트로 자동 이전되지 않습니다. 새 클라이언트에서 권한 부족 메시지가 나오면 해당 클라이언트의 서비스 설치 기능을 사용하세요. 기존 서비스 파일을 직접 복사하거나 두 프록시 클라이언트가 동시에 가상 네트워크 어댑터와 라우팅을 설정하게 두지 마세요.

포트 충돌 또는 종료 후 인터넷이 연결되지 않는 경우

새 클라이언트 로그에 address already in use가 표시되면 먼저 기존 프로세스가 백그라운드에서 실행 중인지 확인하세요. Windows에서는 터미널에서 다음 명령을 실행해 7890 포트를 수신 중인 프로세스 번호를 확인한 뒤 작업 관리자에서 프로그램 이름을 대조하면 됩니다.

netstat -ano | findstr :7890

프로세스의 용도를 확인하지 않은 상태에서 바로 종료하지 마세요. 새 클라이언트에서 사용 중이지 않은 포트를 선택할 수도 있지만, 브라우저 확장 프로그램, 터미널 환경 변수, 기타 수동 프록시 설정도 함께 변경해야 합니다. 특히 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY가 여전히 기존 포트를 가리키는지 확인하세요.

클라이언트를 종료한 뒤에도 브라우저가 로컬 프록시에 연결하려 한다면 Windows 11에서 '설정' → '네트워크 및 인터넷' → '프록시'를 열고 '프록시 서버 사용'을 확인하세요. 조직 정책이나 다른 소프트웨어가 해당 설정을 필요로 하지 않는다고 확인된 경우에만 끄세요. TUN을 비활성화한 뒤에도 연결 문제가 계속되면 다른 VPN, 가상 네트워크 어댑터, DNS 설정도 확인하세요.

이전 완료 확인 및 기존 클라이언트로 되돌리기

지연 시간 숫자가 표시되는 것만으로 이전이 완료됐다고 판단하지 마세요. 지연 시간 테스트는 특정 요청만 확인하므로 모든 트래픽이 규칙에 따라 올바른 경로로 나가는지는 알 수 없습니다. 아래 항목을 실제로 점검한 뒤 기존 클라이언트를 제거할지 결정하세요.

1. 구독 업데이트: 수동 업데이트가 성공하고 노드와 사용자 지정 규칙이 예상치 않게 사라지지 않았는지 확인합니다.
2. 규칙 적용: 직접 연결되어야 하는 대상과 프록시를 거쳐야 하는 대상을 각각 방문하고, 연결 기록에서 일치한 규칙과 실제 정책을 확인합니다.
3. 일상적으로 사용하는 앱: 브라우저와 터미널, 자주 사용하는 데스크톱 앱 하나를 테스트해 브라우저만 확인하는 일이 없도록 합니다.
4. 로컬 네트워크 접근: 라우터 관리 페이지, 프린터, NAS에 기존 방식대로 접근할 수 있는지 확인합니다.
5. 재부팅 및 복구: 컴퓨터를 재부팅하고 절전 모드에서 깨어난 뒤에도 시작 프로그램, 서비스 권한, 프록시 상태가 올바른지 확인합니다.

구독 업데이트나 노드 연결에 문제가 있다면 구독 업데이트 문제 해결과 지연 시간 테스트 안내를 확인하세요. 이전할 때는 구독, 규칙, 네트워크 제어를 따로 처리하고 각 단계를 마칠 때마다 확인해야 합니다. 기존 폴더 전체를 새 클라이언트에 덮어쓰지 마세요.