GUI·커널·구독의 역할부터 구분하기
Clash GUI 클라이언트를 고를 때 테마나 트레이 아이콘부터 비교할 필요는 없습니다. 실제 사용에 영향을 주는 요소는 세 가지입니다. 클라이언트는 설정 가져오기, 노드 전환, 시스템 권한 요청을 담당하고, 커널은 프로토콜 연결과 DNS, 규칙 매칭을 처리합니다. 구독에는 노드 또는 전체 설정이 담깁니다. 다운로드 안내에 이 이름들이 함께 나오는 경우가 많지만 서로 대체할 수는 없습니다.
예를 들어 Clash Verge Rev는 클라이언트 이름이고, mihomo는 이 클라이언트에서 사용하는 커널입니다. 구독을 GUI에 저장할 수 있다고 해서 커널이 구독에 포함된 모든 프로토콜을 지원하는 것은 아닙니다. 반대로 커널이 특정 필드를 지원하더라도 GUI에 해당 옵션이 아직 없다면 오버라이드나 설정 파일로 지정해야 할 수 있습니다.
- 클라이언트 버전: GUI, 서비스 관리, 설정 편집 방식에 영향을 줍니다. 보통 ‘정보’ 메뉴에서 확인할 수 있습니다.
- 커널 버전: 사용할 수 있는 프로토콜과 설정 필드를 결정합니다. 커널 정보나 시작 로그에서 확인하고, 클라이언트 버전과 혼동하지 마세요.
- 구독 형식: 전체 Clash YAML, 노드 정보만 포함된 형식, 기타 형식은 서로 다릅니다. 가져오기 전에 서비스 제공업체가 표시한 형식을 확인하세요.
주요 클라이언트 비교
아래에서는 일반적인 사용 방식에 따라 비교합니다. 버튼이 많다고 기능이 더 뛰어난 것은 아니며, 플랫폼별 배포판을 같은 프로젝트로 취급해서도 안 됩니다. 설치 파일과 유지보수 상태는 바뀔 수 있으므로 다운로드할 때 대상 플랫폼의 릴리스 내역, 포함된 커널, 알려진 문제를 확인하세요. 특정 버전을 장기간 유효한 ‘최신 버전’으로 소개하지는 않습니다.
| 클라이언트 | 플랫폼 및 특징 | 우선 확인할 항목 | 이런 사용 방식에 적합 |
|---|---|---|---|
| Clash Verge Rev | Windows, macOS, Linux 데스크톱; mihomo 사용 | 서비스 모드, TUN 권한, 설정 오버라이드 적용 결과 | 데스크톱에서 구독을 관리하고 네트워크 설정을 하나씩 확인할 수 있는 사용자 |
| Clash Nyanpasu | 데스크톱 GUI 클라이언트; 이 사이트에서 Windows 패키지 다운로드 제공 | 현재 배포 패키지의 커널 종류와 버전, 설정 처리 방식 | 프록시 그룹 조작, 연결 정보 확인, 깔끔한 GUI 구성을 중시하는 사용자 |
| FlClashs | 이 사이트에서 데스크톱 및 Android 설치 경로 제공 | 프로젝트의 정확한 출처, 플랫폼별 패키지, 커널 버전, 백그라운드 실행 방식 | 데스크톱과 휴대폰에서 비슷한 방식으로 사용하고 싶고, 플랫폼별 기능 확인이 가능한 사용자 |
| ClashX Meta | macOS 메뉴 막대 중심 사용 방식 | 칩 아키텍처, OS 버전 요구 사항, 강화된 트래픽 가로채기 방식 | 메뉴 막대에서 전환하고 전체 창을 계속 열어 두지 않으려는 사용자 |
| Clash for Android | Android; 원 프로젝트 유지보수 중단 | 구형 커널의 프로토콜 한계, 시스템 호환성, 백그라운드 제한 | 기존 설정을 당분간 유지하는 용도. 장기적인 신규 배포의 기반으로 삼기에는 부적합 |
| Clash for Windows | 구형 데스크톱 클라이언트; 원 프로젝트 유지보수 중단 | 기존 설정 백업, 구독 이전, 남아 있는 시스템 프록시 설정 | 이전 대상 클라이언트로는 사용할 수 있지만 새 기기의 우선 선택지로는 부적합 |
이름이 비슷한 포크를 같은 프로젝트로 취급하지 마세요. 특히 FlClash, FlClashs 등은 다운로드 페이지에 연결된 저장소와 배포자를 확인해야 합니다. 화면 구성이 비슷하다고 같은 업데이트 경로를 사용해서는 안 됩니다. Android APK를 iOS에 바로 설치할 수도 없습니다. 다른 프록시 클라이언트를 선택한다면 구독 형식, 규칙 문법, 시스템 네트워크 확장 권한을 별도로 확인하세요. ‘프록시 지원’ 여부만으로 판단하기에는 부족합니다.
먼저 운영체제에 따라 후보를 좁히려면 클라이언트 비교를 확인하세요. Linux에서는 DEB와 RPM, CPU 아키텍처도 구분해야 합니다. Debian·Ubuntu용 설치 파일을 Fedora의 패키지 관리자에서 그대로 설치할 수 있는 것은 아닙니다.
커널 기능과 유지보수 상태
프로토콜 지원 여부는 GUI 이름이 아니라 커널로 확인
mihomo는 Clash의 규칙 설정 방식을 이어받으면서 프로토콜과 네트워크 기능을 확장했습니다. 하지만 ‘mihomo 기반’이라는 점만으로는 충분하지 않습니다. 실제로 사용할 수 있는 필드는 커널 버전에 따라 달라집니다. 노드를 가져올 수는 있지만 연결할 때 알 수 없는 필드, 핸드셰이크 실패, 전송 매개변수 미지원 오류가 발생한다면 GUI 테마나 테스트 버튼을 바꾸기보다 먼저 커널 로그를 확인하세요.
- 클라이언트의 ‘정보’, 커널 관리 화면 또는 시작 로그에서 클라이언트와 커널 버전을 각각 기록합니다.
- 실패한 노드의
type, 전송 방식, TLS 설정을 찾아 해당 커널 버전의 설정 문서와 대조합니다. - ‘설정을 불러오지 못함’과 ‘설정은 불러왔지만 연결 실패’를 구분하세요. 전자는 문법과 지원 범위를 먼저 확인하고, 후자는 서버, DNS, 네트워크를 점검합니다.
최근 릴리스 날짜만으로 유지보수 상태를 판단하지 않기
최근 릴리스 몇 건에서 커널 업데이트, OS 호환성, 권한 관련 수정 사항을 확인하고 사용 중인 플랫폼용 설치 파일이 계속 제공되는지도 살펴보세요. GUI에 커밋이 이어지고 있어도 Linux 서비스 설치 문제가 해결됐다는 뜻은 아닙니다. 릴리스 간격이 길다는 이유만으로 프로젝트가 중단됐다고 단정할 수도 없습니다.
- 이전 버전으로 되돌릴 수 있는가: 업데이트 전에 기존 설치 파일과 설정을 백업해 덮어쓰기만 가능한 상황을 피하세요.
- 관련 문제가 해결됐는가: 릴리스 노트에서 DNS, 절전 모드 복귀, TUN, 구독 업데이트 등 사용 환경과 관련된 문제를 확인하세요.
- 출처가 일치하는가: 클라이언트 업데이트 경로, 커널 출처, 수동 다운로드 페이지가 서로 대응하는지 확인하고 출처가 불분명한 실행 파일로 교체하지 마세요.
TUN과 시스템 프록시, 무엇을 선택할까
시스템 프록시는 해당 설정을 따르는 앱에 요청을 로컬 프록시 포트로 보내도록 안내합니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 더 많은 IP 트래픽을 가로채며, 시스템 프록시를 따르지 않는 프로그램에 주로 사용됩니다. TUN은 ‘속도 향상’ 옵션이 아닙니다. 라우팅, DNS, 권한 설정이 적절하지 않으면 오히려 문제 해결이 복잡해질 수 있습니다.
| 방식 | 적합한 상황 | 필요한 관리 작업 |
|---|---|---|
| 시스템 프록시 | 브라우저 및 시스템 프록시 설정을 따르는 데스크톱 앱 | 앱이 해당 설정을 따르는지 확인하고, 종료할 때 프록시 설정이 복구됐는지 점검 |
| 앱별 프록시 설정 | 터미널 도구 또는 별도 프록시 설정을 지원하는 소프트웨어 | 각 도구에 HTTP 또는 SOCKS 포트 지정 |
| TUN 트래픽 가로채기 | 시스템 프록시를 따르지 않는 앱 등 더 넓은 범위의 트래픽을 처리해야 하는 경우 | 관리자 권한, 라우팅, DNS, 다른 VPN과의 충돌 관리 |
Linux 데스크톱에서는 서비스 권한을 중점적으로 확인
TUN을 사용하려고 GUI 전체를 장기간 root 권한으로 실행하지 마세요. 클라이언트가 제공하는 서비스 설치 또는 권한 부여 절차를 우선 사용하고, 권한이 필요한 작업은 해당 서비스가 수행하도록 하세요. 배포판마다 인증 에이전트, 서비스 관리, 패키징 방식이 다르므로 TUN 버튼이 있다는 이유만으로 현재 시스템에서 실행할 준비가 됐다고 볼 수는 없습니다.
Linux에서는 ip link로 네트워크 인터페이스를, ip route로 기본 라우팅을 확인할 수 있습니다. 정책 라우팅을 사용하는 경우에는 ip rule과 관련 라우팅 테이블도 확인해야 합니다. 가상 인터페이스가 나타나는 것만으로 모든 대상 트래픽이 프록시를 통과한다고 단정할 수 없습니다. 요청을 보낸 뒤 클라이언트의 연결 화면에서 해당 연결, 매칭된 규칙, 아웃바운드를 확인하는 편이 확실합니다.
구독 관리, 업데이트 이후까지 확인하기
구독 가져오기는 시작에 불과합니다. 클라이언트 사용성을 가르는 요소는 업데이트 후 노드 선택이 유지되는지, 로컬 규칙이 덮어써지지 않는지, Profile을 전환할 때 포트와 DNS 설정도 바뀌는지입니다. 장기간 사용하기 전에 수동 업데이트와 설정 전환을 각각 한 번 이상 테스트하세요.
원격 설정과 로컬 수정 사항 분리하기
원격 전체 설정에는 보통 노드, 프록시 그룹, 규칙, 기타 옵션이 포함됩니다. 다운로드한 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 사라질 수 있습니다. 클라이언트에서 제공하는 오버라이드, 병합 또는 스크립트 기능을 우선 사용하고 커널에 최종 전달되는 설정을 확인하세요. 배열을 대체하거나 추가하거나 앞에 삽입하는 등 처리 방식은 클라이언트마다 다를 수 있으므로 오버라이드 파일을 검토 없이 여러 클라이언트에 그대로 적용하지 마세요.
- 규칙 순서: 규칙은 일반적으로 위에서 아래로 매칭됩니다. 사용자 지정 직접 연결 규칙을 최종
MATCH뒤에 두면 의도대로 적용되지 않습니다. - 프록시 그룹 참조: 로컬 규칙에서 참조하는 그룹 이름은 현재 설정에 실제로 있어야 합니다. 구독을 바꾸면 특히 참조가 끊기기 쉽습니다.
- 업데이트 주기: 개인 사용이라면 먼저 24시간으로 설정한 뒤 제공업체의 안내에 맞춰 조정하세요. ‘최신 상태’를 유지하려고 매분 요청할 필요는 없습니다.
- 개인정보 보호: 구독 링크에는 액세스 토큰이 포함되는 경우가 많습니다. 스크린샷, 공개 로그, 도움을 요청하는 게시물에서는 전체 링크를 가리세요.
Profile을 여러 개 저장해도 자동으로 병합되지는 않음
가정, 업무, 테스트용 Profile을 각각 저장해도 보통은 그중 하나를 선택해 사용하는 방식입니다. 세 설정의 규칙이 동시에 실행된다는 뜻은 아닙니다. 공통 규칙을 유지하려면 클라이언트가 전역 오버라이드를 지원하는지, 단일 설정 오버라이드와 어떤 순서로 적용되는지 확인하세요. 백업할 때는 구독 출처, 로컬 규칙, 스크립트도 함께 보관해야 합니다. 현재 노드 목록만 내보내서는 기존 동작을 복원하기 어려운 경우가 많습니다.
같은 절차로 사용성을 테스트하기
화면만 봐서는 일상적인 조작에 드는 수고를 알기 어렵습니다. 후보 클라이언트마다 같은 설정 가져오기, 같은 프록시 그룹 전환, 연결 하나 찾아보기, 구독 업데이트, 완전히 종료한 뒤 네트워크 복구 확인을 진행해 보세요. 기본 색상이 아니라 실제 작업 흐름을 비교할 수 있습니다.
- 수신 포트 확인: 아래 예시는 혼합 포트가
7890으로 설정됐다고 가정합니다. 모든 클라이언트의 기본값이라는 뜻은 아니므로 명령을 실행하기 전에 화면에 표시된 실제 값으로 바꾸세요. - 프록시를 지정해 테스트: 먼저 TUN을 끄고 명령에 프록시를 지정해 로컬 포트, 커널, 아웃바운드가 정상적으로 연결되는지 확인합니다.
- 규칙 확인: 연결 화면에서 테스트 요청에 매칭된 규칙과 프록시 그룹을 확인하세요. HTTP 응답이 성공했다고 해서 반드시 의도한 노드를 통과한 것은 아닙니다. 직접 연결 규칙이 적용됐을 수도 있습니다.
- 트래픽 가로채기 테스트: 명령에서 프록시 지정 옵션을 제거하고 시스템 프록시 또는 TUN이 처리하는 범위를 각각 확인합니다.
- 복구 여부 확인: 종료 후, 재시작 후, 절전 모드에서 깨어난 후 각각 점검하세요. 종료한 뒤 시스템 프록시가 중지된 로컬 포트를 가리키지 않는지도 확인합니다.
# 예시: 로컬 혼합 포트가 7890으로 설정된 경우
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 \
--max-time 20 --head https://example.com/
# SOCKS 테스트: 도메인 이름 해석을 프록시에서 처리
curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 \
--max-time 20 --head https://example.com/위 예시의 연결 시간 제한 10초와 전체 제한 20초는 테스트가 오래 멈추는 것을 방지하기 위한 값이지 속도 측정 결과가 아닙니다. 노드 목록에 표시되는 지연 시간은 보통 특정 테스트 주소에 요청을 보냈을 때 걸린 시간으로, 테스트 URL, 노드의 출구, 현재 회선에 따라 달라집니다. 다운로드 대역폭으로 간주할 수는 없습니다. 클라이언트 두 개를 비교할 때는 노드, 테스트 주소, 규칙, DNS 설정을 동일하게 맞추세요.
데스크톱과 모바일 환경별 선택 가이드
Linux, Windows, macOS
Linux에 새로 설치한다면 먼저 Clash Verge Rev가 배포판과 아키텍처에 맞는 패키지를 제공하는지 확인한 뒤 서비스 권한, 트레이, 시작 시 실행을 테스트하세요. 다른 GUI 구성을 선호한다면 FlClashs에서 실제 제공하는 플랫폼 패키지로 같은 작업 절차를 테스트할 수 있습니다. Windows 사용자는 Clash Nyanpasu도 후보로 살펴보세요. macOS 사용자는 전체 창 방식과 ClashX Meta 메뉴 막대 방식의 장단점을 비교하고 Apple Silicon 또는 Intel용 패키지가 기기에 맞는지 확인하세요.
규칙을 자주 조정한다면 최종 설정 확인, 로그 필터링, 오버라이드 관리를 우선 고려하세요. 노드만 전환한다면 이해하기 쉬운 프록시 그룹 화면, 안정적인 트레이 상태, 종료 후 네트워크 복구가 더 중요합니다. 기존 Clash for Windows 사용자는 이전할 때 기존 설정을 보관하되, 예전 서비스 경로와 캐시 디렉터리, 시스템 권한 설정을 그대로 가져오지는 마세요.
Android에서는 백그라운드 실행과 네트워크 전환이 중요
Android 클라이언트는 보통 VpnService를 통해 시스템 VPN 권한을 요청합니다. 이 권한은 앱이 로컬 VPN 인터페이스를 만들도록 허용한다는 뜻이지, 원격 VPN 서버에 연결됐다는 뜻은 아닙니다. 일반적으로 같은 사용자 또는 업무 프로필에서는 VPN 연결을 동시에 사용할 수 없습니다. 다른 VPN이나 일부 로컬 필터링 도구를 함께 켤 때는 충돌 여부를 확인해야 합니다.
- 시스템 ‘설정’ → ‘앱’ → 대상 클라이언트 → ‘배터리’에서 백그라운드 제한을 확인하세요. 메뉴 이름은 제조사마다 다를 수 있습니다.
- Wi-Fi와 모바일 데이터에서 각각 테스트한 뒤 화면을 잠그고 잠시 기다려 절전 정책이 클라이언트를 종료하지 않는지 확인하세요.
- 앱별 분할 설정에서는 ‘선택한 앱만 프록시’와 ‘선택한 앱 우회’ 중 어느 쪽인지 확인하세요. 두 설정은 의미가 반대입니다.
- 새 기기에서는 익숙한 GUI라는 이유만으로 유지보수가 중단된 Clash for Android를 우선 설치하지 않는 편이 좋습니다.