클라이언트, 코어, 구독을 구분하기
Clash for Windows는 보통 CFW라고 줄여 부르며, 이름에 Windows가 들어가지만 Linux와 macOS 버전도 제공된 적이 있습니다. 구독 관리, 프록시 그룹 선택, 데스크톱 설정을 담당하고, 실제 연결 처리는 클라이언트와 함께 실행되는 프록시 코어가 맡습니다. CFW의 지원이 종료된 뒤에도 기존 설치본은 실행될 수 있지만, 새 시스템이나 프로토콜에 맞춰 계속 업데이트되거나 보안 문제가 수정된다는 뜻은 아닙니다.
마이그레이션은 구독을 다시 결제하는 것도, 기존 폴더 전체를 새 폴더에 덮어쓰는 것도 아닙니다. 클라이언트 조작 설정, 코어가 읽는 YAML 설정, 서비스 제공업체의 구독 URL을 각각 다뤄야 합니다. 서로 연관은 있지만 서로를 대신할 수는 없습니다.
- 클라이언트 설정: 시작 프로그램, 시스템 프록시, 단축키, 화면 설정, 백그라운드 서비스는 보통 새 프로그램에서 다시 설정해야 합니다.
- 코어 설정: 노드, 프록시 그룹, 규칙, DNS, TUN 관련 항목을 새 코어가 지원하는지 확인해야 합니다.
- 구독 URL: 원격 설정을 다시 가져올 때 사용합니다. 내려받은 YAML 파일만 저장해 두면 자동 업데이트 기능까지 보존되는 것은 아닙니다.
운영체제에 맞는 대체 경로 선택하기
기존에 Clash YAML을 주로 사용했다면 해당 설정을 읽을 수 있는 클라이언트를 우선 고려하세요. 일반적으로 마이그레이션 부담이 적습니다. mihomo는 기존 Clash Meta 프로젝트에서 이어서 사용되는 이름으로, 더 다양한 프로토콜과 규칙 기능을 지원합니다. 다만 관련 설정을 클라이언트에서 사용할 수 있는지, 어떤 코어 버전이 포함되어 있는지는 실제 설치본을 확인해야 합니다. 선택하기 전에 클라이언트 비교를 살펴보고, 프로젝트의 최근 릴리스와 해당 운영체제용 설치 파일도 확인하세요.
| 기기 운영체제 | 검토할 대안 | 마이그레이션 전 확인 사항 |
|---|---|---|
| Linux 데스크톱 | Clash Verge Rev、FlClashs | CPU 아키텍처, DEB 또는 RPM 형식, 트레이 지원, 서비스 권한 |
| Windows | Clash Verge Rev、Clash Nyanpasu | 운영체제 버전 요구 사항, 코어 종류, 기존 시스템 프록시가 해제되었는지 |
| macOS | Clash Verge Rev、ClashX Meta | Apple Silicon 또는 Intel 아키텍처, 운영체제 버전, 네트워크 권한 |
| Android | FlClash 등 꾸준히 호환성 업데이트를 제공하는 클라이언트 | Clash 설정 지원 여부, VpnService 권한, 백그라운드 배터리 제한 |
| iOS | 필요한 프로토콜과 설정 가져오기를 지원하는 iOS 클라이언트 | 현지 앱 스토어에서 이용 가능한지, 구독 형식과 규칙 구문이 일치하는지 |
Linux에서는 설치 파일 형식부터 확인하세요
Ubuntu·Debian 계열 배포판은 보통 DEB, Fedora 등은 RPM을 선택합니다. 패키지 형식이 같아도 의존성까지 충족된다는 보장은 없습니다. 터미널에서 uname -m을 실행했을 때 x86_64는 일반적으로 x64, aarch64는 ARM64에 해당합니다. 파일을 내려받을 수 있다는 이유만으로 현재 기기에 적합하다고 판단하지 마세요.
모바일에서는 데스크톱의 트래픽 처리 방식을 그대로 적용하지 마세요
Android의 VpnService는 시스템이 제공하는 트래픽 처리 인터페이스로, Linux의 서비스 방식과 동일하지 않습니다. iOS 클라이언트는 다른 설정 형식을 사용할 수도 있습니다. 같은 노드 프로토콜을 지원하더라도 Clash의 프록시 그룹과 규칙을 모두 가져올 수 있다는 뜻은 아닙니다. 먼저 설정 하나를 가져와 확인한 다음 전체 설정을 옮길지 결정하세요.
구형 Clash for Android도 유지 관리 상태를 확인해야 하는 보관된 프로젝트에 해당합니다. 이름이 익숙하다는 이유만으로 장기적인 대체 클라이언트로 선택하는 것은 권장하지 않습니다. 위 표는 선택을 위한 참고 자료일 뿐, 향후 유지 관리를 보장하지 않습니다.
구독 정보와 직접 수정한 설정 백업하기
기존 클라이언트를 바로 삭제하지 말고, 문제가 생기면 되돌릴 수 있는 상태로 유지하세요. CFW의 Profiles 페이지에서 설정 항목마다 이름, 출처, 현재 선택 항목, 업데이트 주기를 확인해 기록합니다. 구독 링크는 기존 서비스 관리 페이지나 클라이언트의 복사 기능을 이용해 저장하세요. 로컬 파일만 있다면 ‘로컬 가져오기’라고 기록하고 자동 업데이트가 가능한 것으로 착각하지 마세요.
- 원본 설정 내보내기: 현재 사용 중인 YAML을 저장하고, 클라이언트에서 처리되지 않은 원본 구독 내용도 따로 보관하세요. 파일명에 백업 날짜를 넣어 두면 좋습니다.
- 가공 설정 따로 저장하기: CFW의 Parsers, Mixin과 직접 추가한 규칙을 확인하세요. 이런 클라이언트 설정은 구독 파일에 포함되지 않을 수 있습니다.
- 실행 옵션 기록하기: HTTP, SOCKS, 혼합 포트와 LAN 연결 허용 여부, 현재 모드, DNS 설정을 적어 두세요.
- 외부 파일도 보관하기: 로컬 규칙 세트, 인증서 파일, 설정에서 참조하는 다른 파일도 챙기세요. 기본 YAML만 복사하면 필요한 파일을 놓칠 수 있습니다.
- 프록시 그룹 선택 기록하기: 자주 쓰는 그룹과 노드 이름을 적어 두세요. 기존 캐시를 새 클라이언트에서 읽지 못할 수도 있으므로 텍스트로 목록을 남기는 편이 좋습니다.
Linux에서는 먼저 현재 사용자만 접근할 수 있는 백업 디렉터리를 만든 뒤 내보낸 파일을 넣으면 됩니다. 아래 명령은 디렉터리를 만들고 권한을 제한할 뿐, 기존 설정을 검색하거나 내보내지는 않습니다:
mkdir -p "$HOME/cfw-migration"
chmod 700 "$HOME/cfw-migration"
# 내보낸 설정과 마이그레이션 기록을 이 디렉터리에 넣은 다음 파일 권한을 더 제한하세요:
find "$HOME/cfw-migration" -type f -exec chmod 600 {} \;기존 디렉터리 전체를 덮어쓰지 말고 설정을 가져오세요
새 클라이언트를 처음 실행한 뒤에는 TUN과 시스템 프록시를 끈 상태로 설정 하나를 가져와 파싱 결과를 확인하세요. 구독 URL이 있다면 URL을 다시 가져오고, 로컬 YAML만 있다면 로컬 설정으로 가져오세요. 클라이언트에서 가져오기 유형을 선택할 수 있다면 ‘원격 설정’과 ‘로컬 파일’을 구분해야 합니다. 그래야 업데이트 버튼은 있지만 실제로 업데이트할 출처가 없는 상황을 피할 수 있습니다.
필드 호환성을 확인한 뒤 규칙을 조정하세요
일반적인 proxies, proxy-groups, rules 구조는 대체로 계속 사용할 수 있지만 파싱 로그를 확인해야 합니다. 기존 코어 전용 스크립트 기능, CFW 전용 가공 구문, 오래된 실험용 필드는 mihomo에서 그대로 작동한다고 단정할 수 없습니다. 오류가 발생하면 먼저 문제가 된 필드를 찾아보세요. 파일을 불러오려고 알 수 없는 항목을 모두 한꺼번에 삭제하지 마세요.
- 노드 프로토콜: VLESS, Hysteria2 등의 지원 여부는 대상 코어에 따라 달라집니다. 설정이 로드되어도 모든 노드의 연결이 성공했다는 뜻은 아닙니다.
- 규칙 제공자:
rule-providers의 다운로드 URL, 동작 유형, 형식이 서로 맞아야 합니다. 로그에서 다운로드 또는 파싱 오류가 있는지 확인하세요. - 로컬 경로: Windows 드라이브 경로는 Linux에서 그대로 사용할 수 없습니다. 상대 경로를 해석하는 위치는 새 클라이언트의 설정 디렉터리와 코어 동작을 기준으로 확인하세요.
- 규칙 순서: 규칙은 일반적으로 위에서 아래 순서로 적용됩니다. 최종
MATCH뒤에 사용자 규칙을 추가하면 기대한 대로 적용되지 않는 경우가 많습니다.
사용자 설정은 유지되는 오버라이드에 넣으세요
다운로드 후 생성된 구독 파일만 직접 수정하면 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다. 새 클라이언트가 지원하는 오버라이드, 병합, 스크립트 기능을 우선 사용하고 실제 병합 결과를 확인하세요. 어떤 기능은 규칙 배열 전체를 대체하고, 어떤 기능은 규칙을 앞에 추가할 수 있습니다. 기능 이름만 보고 동작을 판단하지 마세요. 먼저 확인하기 쉬운 규칙 하나를 추가하고 구독을 업데이트한 뒤에도 남아 있는지 확인하세요.
CFW의 Parsers나 Mixin은 기존 래퍼 구조를 그대로 복사하지 말고, 항목별로 대상 클라이언트가 지원하는 방식에 맞춰 다시 작성하세요. 각 필드의 기능은 코어 및 설정 참고 자료에서 확인할 수 있습니다.
시스템 프록시와 TUN은 따로 확인하세요
마이그레이션 중 흔히 발생하는 문제는 노드 손상이 아니라 두 클라이언트가 같은 포트를 사용하거나, 종료된 프로그램을 기존 시스템 프록시가 계속 가리키는 경우입니다. 전환하기 전에 CFW의 General 페이지에서 System Proxy를 끄세요. TUN을 사용했다면 먼저 끄고 기존 클라이언트를 정상 종료한 다음 새 클라이언트를 실행하세요.
첫 번째 단계에서는 로컬 프록시 포트만 확인하세요
아래 예시는 새 클라이언트에서 mixed-port: 7890을 지정하고 로컬 루프백 주소에서 수신 대기하도록 설정했다고 가정합니다. 7890은 이번 점검에 사용할 예시 포트이며 모든 클라이언트의 기본값은 아닙니다. 화면이나 실제 적용된 설정을 확인하고, 접근 권한이 있는 테스트 주소를 사용하세요:
# Linux에서 7890 포트의 수신 대기 상태 확인
ss -lntp 'sport = :7890'
# 데스크톱 시스템 프록시에 의존하지 않고 HTTP 프록시를 명시해 요청 보내기
curl --proxy http://127.0.0.1:7890 \
--connect-timeout 10 --max-time 20 \
--output /dev/null --write-out 'HTTP %{http_code}\n' \
https://clash86.com/연결이 거부되면 포트에서 수신 대기 중인 프로세스가 없거나, 포트가 잘못되었거나, 프로세스 시작에 실패했을 가능성이 큽니다. 시간 초과가 발생하면 코어 로그, 노드 연결, DNS를 추가로 확인하세요. HTTP 응답을 받았더라도 해당 요청이 응답을 받았다는 의미일 뿐입니다. 클라이언트 연결 기록에서 예상한 규칙과 프록시 그룹이 적용되었는지도 확인해야 합니다.
두 번째 단계에서 시스템 프록시를 켜세요
로컬 포트가 정상 작동하면 새 클라이언트에서 시스템 프록시를 설정하고 브라우저로 확인하세요. 시스템 프록시는 해당 설정을 따르는 앱에 주로 적용됩니다. 터미널 프로그램이 프록시를 사용하는지는 환경 변수와 프로그램 자체 옵션에도 달려 있습니다. GNOME 데스크톱에서는 gsettings get org.gnome.system.proxy mode를 실행해 데스크톱 프록시 모드를 확인할 수 있지만, 이 결과만으로 모든 앱이 프록시를 사용한다고 볼 수는 없습니다.
마지막으로 필요한 경우 TUN을 활성화하세요
TUN은 시스템 프록시를 따르지 않는 연결까지 더 폭넓게 처리하는 기능으로, 관련 권한이나 클라이언트 서비스가 필요합니다. 새 클라이언트의 서비스 권한을 먼저 확인한 뒤 TUN을 켜세요. 새 가상 인터페이스와 기존 가상 인터페이스가 동시에 기본 경로를 처리하게 두지 마세요. Linux에서는 ip rule과 ip route show table all로 상태를 확인할 수 있지만, 인터넷 게시물에 있는 라우팅 일괄 삭제 명령을 그대로 실행하지 마세요. 자세한 내용은 TUN 모드 가이드를 참고하세요.
점검 목록으로 마이그레이션 완료 여부 확인하기
지연 시간 테스트에 성공했다고 마이그레이션이 끝난 것은 아닙니다. 보통 테스트 대상에 연결할 수 있는지만 확인하며, 실제 서비스 이용, 규칙 적용, DNS 점검을 대신하지 않습니다. 같은 네트워크에서 아래 순서대로 확인하고, 문제를 찾기 쉽도록 한 번에 설정 하나씩만 바꾸세요.
| 점검 항목 | 확인 방법 | 완료 기준 |
|---|---|---|
| 구독 업데이트 | 수동으로 한 번 업데이트하고 시간과 로그 확인 | 노드가 유지되고 사용자 규칙이 덮어써지지 않음 |
| 규칙 분기 | 직접 연결해야 하는 주소와 프록시를 거쳐야 하는 주소에 각각 접속 | 연결 기록에 예상한 규칙과 프록시 체인이 표시됨 |
| DNS와 내부 네트워크 | 자주 사용하는 도메인, 라우터, 내부 네트워크 서비스에 접속 | 정상적으로 이름이 해석되고 LAN 연결이 잘못 가로채지지 않음 |
| 백그라운드 복구 | 창을 닫고, 절전 모드에서 복귀하고, 네트워크 전환 | 백그라운드 프로세스와 필요한 트래픽 처리 상태가 복구됨 |
| 종료 후 복구 | 프록시를 끄고 새 클라이언트를 정상 종료 | 시스템 프록시가 더 이상 작동하지 않는 로컬 프록시 포트를 가리키지 않음 |
fake-ip를 사용 중인데 내부 사이트의 이름 해석에 문제가 생기면 DNS 설정과 fake-ip-filter를 함께 확인하세요. 모든 DNS 문제를 단순히 “노드 문제”로 돌리지 마세요. IPv6도 따로 확인해야 합니다. IPv4 사이트에 접속된다고 해서 IPv6 연결도 예상한 경로를 통과한다고 볼 수는 없습니다.
휴대전화에서는 화면을 잠근 상태에서도 한 번 확인하세요. Android 기기에서 화면을 잠근 뒤 연결이 끊기면 배터리 최적화, 자동 시작, 백그라운드 제한을 먼저 점검하세요. 이 문제는 데스크톱에서 YAML을 정상적으로 가져왔는지와는 별개입니다.
롤백할 시간을 확보한 뒤 기존 설치를 정리하세요
첫 점검을 마친 뒤에는 CFW를 삭제하기 전에 재부팅, 네트워크 전환, 구독 업데이트를 각각 한 번 이상 확인하세요. 백업을 보관하면서 기존 클라이언트를 계속 시작할 필요는 없습니다. 자동 시작을 끄고 기존 백그라운드 서비스가 포트를 점유하지 않는지 확인하세요. 프로그램 파일을 삭제해도 시스템 서비스나 네트워크 설정이 자동으로 되돌아가지 않을 수 있으므로, 설치했던 방식에 맞춰 정리하세요.
- 새 클라이언트를 정상 종료해 일반 네트워크 연결이 복구되는지 확인하세요.
- 구독 출처, 로컬 오버라이드, 마이그레이션 기록을 보관하고 백업 파일을 실제로 읽을 수 있는지 확인하세요.
- 기존 프로그램의 자동 시작을 해제하고, 원래 사용하던 서비스 관리 또는 제거 방법에 따라 백그라운드 구성 요소를 정리하세요.
- 이전 환경으로 되돌려야 한다면 먼저 새 클라이언트의 시스템 프록시와 TUN을 끈 다음 기존 환경을 시작해 트래픽이 이중으로 처리되지 않게 하세요.
마이그레이션의 목표는 화면을 비슷하게 만드는 것이 아닙니다. 구독이 업데이트되고, 규칙의 동작을 확인할 수 있으며, 종료 후 네트워크가 복구되어야 합니다. ‘백업 → 가져오기 → 로컬 포트 → 시스템 프록시 → TUN → 재부팅 후 확인’ 순서로 진행하면 문제가 어느 단계에서 발생했는지 파악할 수 있어 구성 요소를 전부 다시 설치할 필요가 없습니다.