Clash 클라이언트 첫 설치: 시스템 아키텍처 선택, 권한 안내 및 초기 설정 체크리스트

설치 전: 클라이언트, 코어 및 설정 출처 확인

“Clash 설치 방법”을 검색하면 다운로드 목록에 데스크톱 클라이언트, Android 앱, 독립 코어가 함께 표시될 수 있습니다. 파일 크기만 보고 고르면 안 됩니다. 클라이언트는 인터페이스, 구독 업데이트 및 설정 관리를 제공하고, 코어는 프록시 연결, 규칙 매칭, DNS 처리 등을 담당합니다. 코어 실행 파일만 따로 내려받으면 일반적으로 트레이 메뉴가 있는 데스크톱 인터페이스는 사용할 수 없습니다.

Clash Meta는 이후 mihomo라는 이름으로 계속 개발되고 있지만, 클라이언트마다 탑재된 코어와 버전, 기능 스위치가 다릅니다. 설정에 tun, proxy-providers 또는 특정 프로토콜 필드가 있다고 해서 이름에 Clash가 들어간 모든 앱에서 불러올 수 있는 것은 아닙니다. 처음 설치할 때 클라이언트 버전과 코어 버전을 기록해 두어야 이후 호환성을 판단할 수 있습니다.

먼저 네트워크 기준 상태를 확인하세요: 기존 프록시나 VPN을 끄고 학교·호텔 네트워크의 웹 인증을 완료한 다음, 평소 직접 접속할 수 있는 웹사이트를 방문합니다.
기존 설정을 보존하세요: 기기에 유사한 앱이 설치되어 있었다면 먼저 설정, 오버라이드 및 규칙을 내보내고 기존 시스템 프록시 스위치와 포트를 기록합니다.
릴리스 노트를 확인하세요: 대상 운영체제 버전, 프로세서 아키텍처 및 필수 실행 구성 요소를 확인하고, 오래된 튜토리얼의 최소 시스템 요구 사항을 새 설치 패키지에 그대로 적용하지 마세요.
구독 정보를 보호하세요: 구독 URL에는 접근 인증 정보가 포함되는 경우가 많으므로 전체 주소를 공개 스크린샷이나 신뢰할 수 없는 온라인 변환 서비스에 올리지 마세요.

시스템 아키텍처 선택: x64, ARM64 및 설치 패키지 형식

아키텍처는 소프트웨어가 대상으로 하는 프로세서 명령어 집합을 뜻하며, 네트워크 속도나 운영체제 버전을 의미하지 않습니다. x64와 amd64는 일반적으로 같은 계열의 64비트 x86 아키텍처를 가리키고, arm64와 aarch64는 일반적으로 64비트 ARM을 가리킵니다. 설치 패키지를 다운로드할 수 있다고 해서 현재 기기에서 실행된다는 뜻은 아닙니다.

플랫폼	확인 경로 또는 명령어	선택 기준
Windows 11	「설정」→「시스템」→「시스템 정보」→「시스템 종류」	x64 프로세서는 x64를 선택하고, ARM 기기는 프로젝트에서 제공하는 ARM64 빌드를 우선 선택합니다.
macOS	Apple 메뉴 →「이 Mac에 관하여」에서 “칩” 또는 “프로세서” 확인	Apple Silicon은 ARM64, Intel 프로세서는 x64를 선택합니다. Universal 빌드는 릴리스 노트를 확인하세요.
Linux	`uname -m` 및 `cat /etc/os-release`	아키텍처와 배포판을 각각 확인합니다. Debian 계열은 일반적으로 deb, Fedora 계열은 일반적으로 rpm을 사용합니다.
Android	기기 사양. ADB가 설정되어 있다면 `adb shell getprop ro.product.cpu.abilist` 사용 가능	목록에 `arm64-v8a`가 있으면 ARM64를 고려하고, 32비트 ABI만 있으면 해당 빌드를 선택합니다.
iOS / iPadOS	「설정」→「일반」→「정보」→ 시스템 버전	앱에서 이용할 수 있는 배포 채널을 통해 최소 시스템 버전과 설정 형식을 확인하고, APK·EXE·DMG는 설치하지 않습니다.

Windows와 macOS: 먼저 아키텍처를 확인한 뒤 호환성 안내를 처리하세요

Windows 10의 경로는 일반적으로 「설정」→「시스템」→「정보」→「시스템 종류」입니다. “이 앱은 PC에서 실행할 수 없습니다”라는 메시지가 표시되면 먼저 운영체제 비트 수, 패키지 아키텍처 및 최소 시스템 버전을 확인하세요. Windows on ARM의 호환 실행 기능이 모든 프록시 서비스나 드라이버의 호환성을 보장하지는 않으므로, 메인 화면이 실행되는지만 확인해서는 안 됩니다.

Apple Silicon Mac에서 Intel 빌드를 사용하면 Rosetta가 필요할 수 있습니다. 프로젝트에서 기본 ARM64 패키지를 제공한다면 릴리스 노트에 따라 해당 패키지를 우선 선택하세요. DMG로 배포되는 클라이언트는 안내에 따라 앱을 “응용 프로그램” 폴더로 옮긴 뒤 실행해야 합니다. 마운트된 이미지 안에서 장기간 실행하면 업데이트나 권한 경로가 꼬일 수 있습니다.

Linux와 Android: 파일 형식과 아키텍처를 각각 확인하세요

Linux의 .deb와 .rpm은 패키지 관리 형식이며 CPU 아키텍처를 직접 나타내지 않습니다. 설치 전에 의존성과 배포판 지원 범위를 함께 확인하고, 설치를 진행하기 위해 의존성 검사를 강제로 무시하지 마세요. Android에서는 하드웨어는 64비트지만 시스템이 32비트 앱 환경만 제공하는 기기도 있을 수 있으므로 사용 가능한 ABI를 기준으로 판단해야 합니다. 프로젝트에서 범용 패키지를 제공한다면 안내를 참고해 대안으로 선택할 수 있지만, 범용 패키지는 대체로 용량이 더 큽니다.

권한 안내: 설치 권한, 서비스 권한 및 VPN 권한 구분하기

권한 팝업은 방금 실행한 작업과 일치해야 합니다. 설치 패키지를 열었을 때 설치 확인이 표시되는 것, TUN을 활성화할 때 서비스 권한을 요청하는 것, 모바일에서 처음 연결할 때 VPN 권한을 요청하는 것은 서로 다른 단계의 시스템 동작입니다. 관련 작업을 시작하지 않았는데 낯선 관리자 권한 요청이 나타나면 먼저 취소하고 요청을 발생시킨 프로그램과 파일 출처를 확인하세요.

Windows 설치 및 방화벽: 설치 프로그램이나 서비스 설치 과정에서 UAC가 표시될 수 있습니다. 방화벽에서 어떤 네트워크에 대한 접근을 허용할지 묻는다면 다른 기기가 이 기기의 프록시에 접근해야 하는지 먼저 확인하세요. 이 기기에서만 사용할 경우 알림을 없애기 위해 모든 공용 네트워크의 인바운드 접근을 허용해서는 안 됩니다.
macOS 보안 안내: 먼저 앱 출처, 서명 안내 및 버전 요구 사항을 확인한 뒤 「시스템 설정」→「개인정보 보호 및 보안」을 살펴보세요. 시스템 전체의 보안 검사를 끄는 것을 설치 절차로 삼지 마세요. “앱이 손상되었기 때문에 열 수 없습니다”와 같은 메시지가 나타나면 올바른 설치 패키지를 다시 받고 해당 버전의 안내를 확인하세요.
Android 설치 권한: APK를 설치할 때 브라우저나 파일 관리 앱에 “알 수 없는 앱 설치” 권한을 허용하라는 메시지가 표시될 수 있습니다. 이는 설치 출처 앱에 대한 권한이며 VPN 권한이 아닙니다. 설치가 끝난 뒤 더 이상 필요하지 않다면 해당 설치 권한을 철회할 수 있습니다.
모바일 연결 권한: Android의 VPN 연결 요청이나 iOS의 VPN 구성 추가 안내는 앱이 시스템 네트워크 확장을 통해 트래픽을 처리하도록 허용합니다. 사용하려는 클라이언트를 활성화하는 상황인지 확인한 경우에만 승인하세요.

알림 권한은 주로 상태 표시와 알림에 영향을 주며, 배터리 백그라운드 제한은 Android의 장시간 연결 안정성에 영향을 줄 수 있습니다. 이러한 설정을 “처음 설정을 가져올 수 있는지”와 혼동해서는 안 됩니다. 먼저 포그라운드에서 연결을 확인하고, 화면을 잠근 뒤 연결이 끊길 때만 해당 앱의 백그라운드 실행 정책을 점검하세요. 한 번에 너무 많은 시스템 설정을 바꾸지 않는 것이 좋습니다.

시스템 프록시, VPN 및 TUN: 첫 실행에서 무엇을 선택할까요

시스템 프록시는 프록시 서버 주소를 운영체제 설정에 기록하며, 해당 설정을 읽는 앱만 이를 사용합니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 IP 트래픽을 처리하므로 더 많은 권한과 DNS 설정이 필요할 수 있습니다. 모바일 기기에 표시되는 VPN은 시스템 승인 및 네트워크 처리 방식이며, 클라이언트가 특정 원격 VPN 프로토콜을 사용한다는 뜻은 아닙니다.

방식	첫 사용 시 권장 사항	이 정보만으로 판단할 수 없는 것
데스크톱 시스템 프록시	브라우저 접속을 먼저 확인하고 로컬 주소와 수신 포트를 점검하기에 적합합니다.	스위치가 켜져 있어도 모든 앱과 UDP 트래픽이 처리된다는 뜻은 아닙니다.
데스크톱 TUN	시스템 프록시를 따르지 않는 앱까지 처리해야 할 때 코어 문서에 따라 활성화하세요.	활성화에 성공해도 노드가 UDP를 지원한다는 뜻은 아니며, 모든 라우팅이 예상대로 동작한다고 보장할 수도 없습니다.
모바일 VPN 채널	유효한 설정을 가져온 뒤 앱의 연결 버튼으로 권한을 승인하고 시작합니다.	상태 표시줄의 VPN 아이콘은 채널 상태만 나타낼 뿐 원격 노드의 사용 가능 여부를 보장하지 않습니다.

규칙 모드와 트래픽 처리 범위를 따로 설정하세요

mode: rule은 코어가 규칙에 따라 연결의 출구를 선택하도록 하는 설정이며, 모든 앱을 코어로 보내지는 않습니다. 반대로 TUN을 활성화해도 모든 연결이 자동으로 같은 프록시 노드로 전송되는 것은 아닙니다. 처음에는 설정 제공자가 준비한 규칙 모드를 유지하고, 전역 모드·DNS 모드·TUN을 동시에 전환하지 마세요. 그래야 테스트가 성공한 뒤 어떤 변경이 영향을 주었는지 확인할 수 있습니다.

데스크톱에서는 먼저 시스템 프록시를 사용하고, 모바일에서는 클라이언트가 제공하는 VPN 연결 방식으로 시작할 수 있습니다. 관리 정책이 적용된 기기에서는 일반 사용자가 서비스 설치나 라우팅 변경을 할 수 없을 수 있으므로, 더 높은 권한으로 계속 재시도하지 말고 기기 관리자가 허용된 접속 방식을 확인해야 합니다.

초기 설정 체크리스트: 설정 가져오기, 포트 확인 및 정책 선택

버전 정보를 확인하세요. 클라이언트의 “정보” 또는 버전 정보 페이지에서 클라이언트와 코어 버전을 기록합니다. 배포 패키지 이름이 실제로 실행 중인 코어 버전과 항상 일치하는 것은 아닙니다.
설정을 가져오세요. 구독 URL은 원격 설정 가져오기 메뉴를 사용하고, 로컬 YAML은 파일 가져오기 메뉴를 사용합니다. 단일 노드 공유 링크는 클라이언트가 명시적으로 지원하는 경우에만 사용할 수 있으며, 완전한 YAML 설정으로 가져오면 안 됩니다.
활성화하고 로그를 확인하세요. 가져오기에 성공했다는 것은 내용이 저장되었다는 뜻일 뿐입니다. 해당 설정을 선택하고 코어가 정상적으로 로드되었는지 확인해야 합니다. 알 수 없는 필드나 YAML 구문 오류가 나타나면 먼저 형식과 호환성을 해결하고 TUN 활성화는 나중으로 미루세요.
정책 그룹을 확인하세요. 규칙에서 사용하는 정책 그룹이 실제로 존재하는지 확인하고, 수동 선택이 필요한 그룹에서는 사용 가능한 노드를 하나 선택합니다. 자동 속도 측정 그룹과 수동 선택 그룹은 동작 방식이 다릅니다.
트래픽 처리 방식 하나만 활성화하세요. 데스크톱에서는 먼저 시스템 프록시를 켜고, 모바일에서는 연결 버튼으로 권한을 승인합니다. 첫 테스트 동안 다른 네트워크 설정은 그대로 유지하세요.

설정 예시: 로컬 포트와 규칙 모드

# 일반 필드만 설명하는 예시이며, 그대로 연결할 수 있는 완전한 설정이 아닙니다
mixed-port: 7890
mode: rule
allow-lan: false

mixed-port: 7890은 로컬 HTTP와 SOCKS 프록시가 하나의 수신 포트를 공유하는 교육용 예시이며, 실제 포트는 클라이언트 실행 설정을 따릅니다. allow-lan: false는 LAN에 프록시 접근을 개방하지 않는다는 뜻으로, 이 기기에서만 사용하는 시작 설정에 적합합니다. 이 세 필드에는 노드, 정책 그룹 및 규칙이 포함되어 있지 않으므로 구독 내용을 대신할 수 없습니다.

실제 수신 주소가 127.0.0.1:7890이라면 시스템 프록시도 이 주소와 포트를 가리켜야 합니다. 포트가 이미 사용 중이면 로그에 address already in use가 표시될 수 있습니다. 이때는 기존 클라이언트가 백그라운드에서 계속 실행 중인지 먼저 확인하세요. 포트를 변경한 뒤에는 시스템 프록시나 수동으로 프록시를 설정한 앱도 함께 점검해야 하며, YAML 한 곳만 수정해서는 안 됩니다.

인터넷 연결 확인: 로컬 수신부터 실제 연결까지

속도 측정 버튼에 표시되는 지연 시간만으로 설치 완료를 판단하지 마세요. 속도 측정은 보통 특정 테스트 주소에 접속하므로 해당 주소와 측정 방식의 영향을 받습니다. 한 번의 테스트가 시간 초과되었다고 모든 웹페이지에 접속할 수 없는 것은 아니며, 한 번 성공했다고 대상 앱이 프록시를 사용한다는 뜻도 아닙니다.

코어 실행 여부를 확인하세요. 로그에서 설정 로드 및 수신 시작 기록을 찾습니다. 화면은 열리지만 코어에서 계속 오류가 발생한다면 시스템 프록시가 가리키는 로컬 포트에서 요청을 받을 프로세스가 없을 수 있습니다.
실제 요청을 확인하세요. 접속 가능하고 정상 작동이 확인된 HTTPS 웹사이트를 연 다음, 클라이언트의 “연결” 또는 로그 페이지에서 대상 도메인, 매칭된 규칙, 정책 그룹 및 최종 출구를 확인합니다.
직접 연결 트래픽과 비교하세요. 현재 규칙상 직접 연결되어야 하는 웹사이트에 접속하고 출구가 DIRECT 또는 해당 직접 연결 경로로 표시되는지 확인합니다. 프록시를 사용하는 요청만 테스트하지 마세요.
대상 앱을 테스트하세요. 브라우저가 정상 작동한 뒤 실제로 사용하려는 앱을 엽니다. 연결 기록이 없다면 구독을 바로 바꾸기보다 해당 앱이 시스템 프록시를 따르는지 먼저 확인하세요.
복구 상태를 확인하세요. 먼저 시스템 프록시를 끄거나 VPN 연결을 끊은 뒤 클라이언트를 종료하고, 원래 직접 연결되던 웹사이트가 계속 열리는지 확인합니다.

데스크톱 선택 사항: 명시적 프록시 테스트

curl이 설치되어 있고 로컬 HTTP 프록시가 실제로 127.0.0.1:7890에서 수신 중이라면 다음 명령어를 실행할 수 있습니다. Windows PowerShell에서는 일부 버전의 명령어 별칭 차이를 피하기 위해 curl.exe를 사용하세요. 테스트 URL은 공개 HTTPS 예시일 뿐이므로 현재 네트워크에서 정상 접속이 확인된 대상을 기준으로 삼아야 합니다.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --head https://example.com

--connect-timeout 10은 연결 단계의 대기 시간을 10초로 제한하고, --max-time 20은 전체 요청을 20초로 제한합니다. 둘 다 실제 지연 시간이 아니라 테스트 매개변수입니다. 이 명령은 로컬 프록시를 명시하므로 성공하더라도 해당 요청 경로가 작동한다는 것만 증명할 뿐 운영체제의 프록시 설정이 올바르다는 뜻은 아닙니다. 웹사이트가 HEAD 요청을 지원하지 않으면 메서드 관련 오류가 반환될 수 있으므로 로그와 함께 판단하세요.

첫 설치 중 자주 묻는 질문과 완료 기준

클라이언트는 열리는데 왜 웹페이지에 접속할 수 없나요?

먼저 시스템 프록시를 끄거나 VPN 연결을 끊고, 원래 직접 접속되던 웹사이트가 복구되는지 확인하세요. 복구된다면 코어 실행 여부, 로컬 포트 일치 여부, 설정 활성화 여부, 정책 그룹에서 사용 가능한 출구를 선택했는지 순서대로 확인합니다. 클라이언트를 종료한 뒤에도 인터넷이 끊긴다면 시스템 프록시가 남아 있는지 확인하세요. Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서, macOS에서는 현재 네트워크 연결의 「세부사항」→「프록시」에서 확인할 수 있습니다. 복구하기 전에 기존 설정을 기록하고, 조직 네트워크에 필요한 설정을 덮어쓰지 마세요.

설치 후 반드시 TUN을 켜거나 계속 관리자 권한으로 실행해야 하나요?

두 설정을 기본 전제로 삼을 필요는 없습니다. 로컬 프록시 포트와 시스템 프록시만 사용한다면 일반적으로 데스크톱 TUN은 필요하지 않습니다. 서비스 설치나 가상 네트워크 인터페이스 생성에는 클라이언트 구현에 따라 권한 상승이 필요할 수 있습니다. 클라이언트가 관리되는 백그라운드 서비스로 관련 작업을 처리한다면 해당 문서에 따라 설정하고, 앱 전체를 장기간 높은 권한으로 실행하는 것을 일반적인 해결책으로 사용하지 마세요.

가져온 뒤 노드가 없는데 다시 설치하면 해결되나요?

먼저 구독이 올바른 형식으로 응답하는지, 로그인 페이지나 오류 메시지를 YAML로 잘못 저장한 것은 아닌지 확인하세요. 프록시 컬렉션을 사용하는 설정은 컬렉션 내용을 추가로 다운로드해야 할 수도 있으므로, 기본 설정을 가져왔다고 컬렉션 업데이트까지 성공한 것은 아닙니다. 오류 유형을 보존한 뒤 설정 제공자에게 유효 기간과 클라이언트 호환 범위를 확인하세요. 재설치만으로는 구독 내용이나 인증 문제를 해결하기 어렵습니다.

설치 완료 전 이 기록을 보관하세요

시스템 버전, 기기 아키텍처, 클라이언트 버전 및 코어 버전을 기록했습니다.
설정을 로드할 수 있고 노드 또는 프록시 컬렉션이 준비되었으며 로컬 수신 오류가 없습니다.
프록시 요청 한 건과 규칙에 따른 직접 연결 요청 한 건에서 실제 출구를 모두 확인했습니다.
트래픽 처리 방식이 명확하고 불필요한 VPN이나 프록시 도구를 동시에 실행하지 않았습니다.
종료 후 네트워크 복구를 테스트했으며 원본 설정과 로컬 오버라이드를 각각 저장했습니다.

이 조건을 충족한 뒤에야 시작 시 실행, 백그라운드 실행, TUN 또는 LAN 공유를 항목별로 검토하세요. 한 번에 하나의 설정만 추가하고 연결 확인을 반복하면 문제가 생겨도 최근의 정상 상태로 쉽게 돌아갈 수 있습니다. 클라이언트별 시스템 지원과 유지 관리 상태를 비교하려면 클라이언트 선택 가이드를 확인하세요.