입문 가이드 예상 읽기 시간 12분

Clash 클라이언트 첫 설치 및 초기 설정: Windows·macOS·Android 공통 절차와 문제 해결

Windows·macOS·Android에서 Clash 클라이언트를 처음 설치하는 방법을 안내합니다. 권한 설정, 구독 가져오기, 포트 및 시스템 프록시 설정과 실행 오류·인증서 경고 해결법을 확인하세요.

설치 전 확인: 클라이언트, 코어, 시스템 아키텍처

Clash 클라이언트는 보통 그래픽 인터페이스와 프록시 코어로 구성됩니다. 인터페이스에서 설정을 가져오고 노드를 선택해 시스템 프록시를 설정하며, 코어는 규칙을 해석하고 연결을 수립해 트래픽을 전달합니다. Clash Meta는 현재 mihomo라는 이름을 사용하며 코어 프로젝트에 해당합니다. 이름에 Clash가 들어간 클라이언트라도 같은 코어를 사용하거나 동일한 설정 항목을 지원하는 것은 아닙니다.

처음 설치하기 전에 기기 아키텍처, 클라이언트가 지원하는 운영체제 버전, 구독 설정이 현재 코어에 맞는지 확인하세요. 구형 Clash 코어와 mihomo는 서로 같은 것이 아닙니다. 예를 들어 구독에 Hysteria2 노드가 포함되어 있다면 해당 프로토콜을 지원하는 코어가 클라이언트에 내장되어 있어야 합니다.

플랫폼확인 경로설치 파일 선택
Windows 11설정 → 시스템 → 시스템 정보 → 시스템 종류x64 기기는 x64를 선택하세요. ARM 기기는 네이티브 ARM64 패키지와 호환성을 먼저 확인하세요.
macOSApple 메뉴 → 이 Mac에 관하여Apple 칩은 arm64, Intel 프로세서는 x64를 선택하세요.
Android설정 → 휴대전화 정보에서 확인하고 기기 프로세서 사양도 참고하세요.대부분의 최신 기기는 arm64-v8a를 선택합니다. 구형 기기는 지원 여부에 따라 armeabi-v7a를 선택하세요.

Android 기기의 프로세서가 64비트라고 해서 운영체제에서도 64비트 앱을 실행할 수 있는 것은 아닙니다. 설치 파일이 호환되지 않는다는 메시지가 표시되면 시스템에서 실제로 지원하는 ABI를 확인하세요. ADB 사용에 익숙하다면 adb shell getprop ro.product.cpu.abilist를 실행할 수 있습니다. 확실하지 않다면 클라이언트에서 제공하는 범용 패키지를 사용하고 최소 Android 버전을 확인하세요.

Windows: 설치, 실행 및 로컬 프록시 포트

먼저 일반 실행을 확인한 다음 연결 방식을 설정하세요

  1. 시스템 아키텍처에 맞는 설치 파일을 다운로드하세요. 설치 버전은 안내에 따라 설치하고, 포터블 버전은 고정된 폴더에 압축을 푸세요. 압축 파일 미리보기 창에서 바로 실행하지 마세요.
  2. 처음에는 일반 사용자 권한으로 실행하세요. 기본 창이 열리고 상태 페이지에 코어 실행 정보가 표시되는지, 로그에 시작 실패가 계속 기록되지 않는지 확인하세요.
  3. 설정을 가져와 활성화한 뒤 클라이언트에 표시된 HTTP, SOCKS 또는 혼합 포트를 확인하세요. 여기서는 7890을 예로 들며, 실제 포트는 현재 설정을 따릅니다.
  4. 첫 테스트에서는 ‘규칙’ 모드와 ‘시스템 프록시’를 사용하세요. 가상 네트워크 어댑터, 라우팅, 서비스 권한까지 변수가 늘어나지 않도록 TUN은 일단 켜지 않는 것이 좋습니다.

Windows 방화벽 경고와 관리자 권한 요청은 서로 다른 문제입니다. 로컬 루프백 주소로 프록시에 연결한다면 일반적으로 공용 네트워크에서 인바운드 연결을 허용할 필요가 없습니다. 다른 기기에서 이 컴퓨터에 연결해야 하는 경우에만 LAN 수신과 방화벽 규칙을 고려하고, 접근 인증을 설정해 접속 출처를 제한하세요.

시스템 프록시가 올바른 포트를 가리키는지 확인하세요

Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시 설정을 확인할 수 있습니다. 클라이언트에서 시스템 프록시를 켜면 주소는 보통 127.0.0.1이며, 포트는 HTTP 포트 또는 혼합 포트와 일치해야 합니다. SOCKS만 지원하는 포트를 HTTP 프록시 항목에 입력하지 마세요.

# PowerShell: 예시 포트가 수신 대기 중인지 확인
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Windows 기본 curl.exe를 사용해 로컬 HTTP 프록시를 명시적으로 경유
curl.exe -I --proxy http://127.0.0.1:7890 https://example.com

첫 번째 명령에 결과가 없다면 포트가 올바른지, 코어가 실행 중인지 먼저 확인하세요. 두 번째 명령은 프록시를 명시적으로 지정한 연결을 테스트하며, 모든 앱이 시스템 프록시 설정을 읽는다는 뜻은 아닙니다. curl 대신 curl.exe를 사용하면 일부 PowerShell 환경에서 별칭이 달라 생기는 혼동도 피할 수 있습니다.

macOS: 앱 설치 및 네트워크 권한

  1. 설치 디스크 이미지를 열고 앱을 ‘응용 프로그램’ 폴더로 드래그한 다음 해당 폴더에서 실행하세요. 업데이트나 보조 구성요소 설치에 실패할 수 있으므로 읽기 전용 디스크 이미지에서 계속 실행하지 마세요.
  2. 설치 파일의 아키텍처를 확인하세요. Apple 칩 기기에서는 arm64 빌드를 우선 사용하고, Intel 기기에서는 Apple 칩 전용 앱을 실행할 수 없습니다.
  3. 클라이언트가 보조 도구 설치를 요청하면 먼저 안내에 표시된 앱 이름과 용도를 확인하세요. 시스템 프록시 설정이나 TUN 인터페이스 생성에는 권한이 필요할 수 있지만, 구독을 가져오는 작업만으로는 일반적으로 이런 권한이 필요하지 않습니다.
  4. 시스템 프록시를 켠 뒤 macOS 13 이상에서는 ‘시스템 설정’ → ‘네트워크’ → ‘현재 네트워크 서비스’ → ‘세부사항’ → ‘프록시’에서 주소와 포트를 확인하세요.

시스템 버전에 따라 메뉴 이름은 조금씩 다를 수 있습니다. 연결되지 않은 서비스가 아니라 Wi-Fi나 이더넷처럼 현재 사용 중인 네트워크 서비스를 확인하세요. HTTP, HTTPS, SOCKS는 서로 다른 프록시 연결 방식입니다. 어떤 항목을 켤지는 클라이언트 구현에 따라 달라지므로 모든 항목을 임의로 선택할 필요는 없습니다.

터미널에서 시스템 프록시를 확인하려면 scutil --proxy를 실행하세요. HTTP, HTTPS 또는 SOCKS의 활성화 상태와 포트를 확인한 뒤 클라이언트 설정과 비교하세요. 터미널 도구가 macOS 시스템 프록시를 따르지 않을 수 있으므로 테스트 명령에는 --proxy를 명시하는 것이 좋습니다.

Android: VPN 권한 및 백그라운드 실행 설정

Android 클라이언트는 시스템의 VpnService를 사용해 로컬 VPN 인터페이스를 만들고 기기 트래픽을 프록시 코어로 전달하는 경우가 많습니다. 별도의 VPN 서비스를 구독해야 한다는 뜻은 아니며, 모든 연결이 반드시 원격 노드를 거친다는 뜻도 아닙니다. 최종 연결 경로는 규칙, 프록시 그룹, 앱별 설정에 따라 결정됩니다.

  1. APK를 설치할 때는 설치 파일을 여는 앱에만 설치 권한을 임시로 부여하세요. 일반적인 경로는 ‘설정’ → ‘앱’ → ‘특별한 앱 액세스’ → ‘알 수 없는 앱 설치’이며, 메뉴 이름은 기기마다 다를 수 있습니다.
  2. 클라이언트를 열고 설정을 가져온 다음 현재 설정으로 선택하세요. 노드와 프록시 그룹이 표시되는지 확인한 후 연결 또는 시작을 누르세요.
  3. 시스템의 VPN 연결 요청을 확인하고 방금 설치한 클라이언트에서 보낸 요청일 때만 허용하세요. 상태 표시줄에 VPN 아이콘이 나타나면 인터페이스가 만들어진 것이며, 원격 노드의 연결 가능 여부까지 보장하는 것은 아닙니다.
  4. 화면을 잠근 뒤 연결이 끊긴다면 ‘설정’ → ‘앱’ → ‘클라이언트 이름’ → ‘배터리’에서 백그라운드 제한을 확인하세요. 일부 제조사 기기에서는 자동 시작 또는 백그라운드 관리 메뉴에서 계속 실행하도록 허용해야 합니다.

같은 사용자 계정이나 업무 프로필에서는 보통 VPN 서비스를 여러 개 동시에 사용할 수 없습니다. 기업용 VPN, VPN 기반 방화벽 또는 다른 프록시 도구가 실행 중이면 새 클라이언트를 시작할 때 기존 연결이 끊길 수 있습니다. 테스트 전에 현재 VPN 연결이 어떤 앱에 속하는지 확인해 서비스 전환을 노드 오류로 오인하지 않도록 하세요.

처음 설치할 때는 ‘항상 켜져 있는 VPN’과 ‘VPN 연결 없이는 차단’을 바로 켜지 않는 것이 좋습니다. 구독, 노드, 인터넷 연결이 정상인지 확인한 뒤 필요에 따라 사용하세요. 차단 기능을 켠 상태에서 클라이언트를 중지했다면 기기가 인터넷에 연결되지 않는 것은 시스템의 정상 동작일 수 있습니다.

구독 가져오기: 업데이트 성공 후 설정 활성화하기

주소, 콘텐츠, 현재 설정을 차례로 확인하세요

  1. 클라이언트의 구독 또는 설정 화면에서 URL 가져오기를 선택하고 전체 주소를 붙여 넣으세요. 쿼리 매개변수를 임의로 삭제하거나 웹페이지에 표시된 제목을 구독 링크로 사용하지 마세요.
  2. 다운로드가 끝나면 업데이트 시각과 파싱 결과를 확인하세요. 다운로드에 성공했더라도 로그인 페이지, 오류 메시지 또는 다른 클라이언트 형식의 콘텐츠라면 유효한 설정으로 사용할 수 없습니다.
  3. 새 설정을 현재 사용 설정으로 지정하세요. 목록에 구독 항목이 표시된다고 해서 코어가 해당 설정으로 전환된 것은 아닐 수 있습니다.
  4. 프록시 그룹 화면으로 이동해 사용할 수 있는 노드나 자동 선택 그룹을 고르세요. 규칙이 수동 선택 그룹을 가리킨다면 그 그룹에서 실제로 선택한 항목이 요청의 출구를 결정합니다.

‘구독 업데이트 실패’가 발생하면 먼저 링크 만료 여부, 제공업체에 접속할 수 있는지, 서버가 유효한 콘텐츠를 반환하는지 확인하세요. 클라이언트에 ‘프록시를 통해 업데이트’ 옵션이 있더라도 초기 설정 단계에서 사용할 노드가 없다면 이 방법으로 업데이트하지 못할 수 있습니다. 제공업체 안내에 따라 사용 가능한 업데이트 방법을 선택하세요.

자동 업데이트는 우선 24시간마다 한 번으로 설정할 수 있습니다. 이는 시작할 때 참고할 만한 주기이지 모든 클라이언트의 기본값은 아닙니다. 그래픽 인터페이스에서 구독을 업데이트하면 보통 로컬 설정이 교체됩니다. 다운로드한 파일의 항목을 직접 수정하면 다음 업데이트 때 변경 사항이 사라질 수 있습니다. 계속 유지할 변경 사항은 클라이언트에서 지원하는 덮어쓰기 또는 병합 기능으로 적용하고 먼저 백업하세요.

전체 설정과 프록시 제공자 구분하기

전체 YAML 설정에는 proxies, proxy-groups, rules와 DNS 설정이 함께 들어갈 수 있습니다. 반면 proxy-providers는 설정 안에서 노드 공급원을 참조하는 용도입니다. 따라서 이 항목의 interval을 그래픽 클라이언트의 전체 구독 업데이트 주기와 동일하게 보면 안 됩니다. 노드 목록만 받은 경우 분기 규칙까지 포함되어 있다고 가정하지 마세요.

초기 설정: 포트, 규칙 모드, TUN의 차이

첫 테스트에서는 클라이언트 하나만 실행하는 것이 좋습니다. 두 클라이언트가 동시에 시스템 프록시를 설정하거나 두 코어가 같은 포트에서 수신 대기하면 원인을 파악하기 어려워집니다. 아래는 노드가 포함되지 않은 로컬 설정 항목 예시이므로 이것만으로는 인터넷에 연결할 수 없습니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
  • mixed-port: 같은 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받습니다. 예시는 7890입니다. 포트가 이미 사용 중이면 비어 있는 다른 포트로 바꾸고 이를 사용하는 프로그램에도 동일하게 반영하세요.
  • allow-lan: false: LAN 연결을 허용하지 않습니다. 단일 기기에서 처음 사용할 때는 끈 상태로 두어 불필요한 노출을 줄이세요.
  • mode: rule: 규칙에 따라 직접 연결, 프록시 사용 또는 차단을 결정합니다. 전역 모드는 일시적인 비교 테스트에 적합하며 규칙 적용 결과를 확인하는 대신 사용해서는 안 됩니다.
  • log-level: info: 우선 일반 로그 수준을 유지하세요. 문제를 찾을 때만 잠시 디버그 수준으로 바꾸고, 로그를 공유하기 전에는 구독 인증 정보, 노드 비밀번호, 개인 접속 기록을 삭제하세요.

시스템 프록시는 해당 설정을 따르는 앱에서만 작동하며 모든 UDP 트래픽, 게임, 자체 네트워크 스택을 사용하는 프로그램까지 자동으로 처리하지는 않습니다. 데스크톱 TUN은 가상 네트워크 어댑터와 라우팅을 사용해 더 많은 트래픽을 처리하며 보통 관리자 권한이나 보조 서비스가 필요합니다. Android의 VPN 처리와 데스크톱 시스템 프록시도 같은 스위치처럼 단순하게 이해해서는 안 됩니다.

첫 테스트가 성공한 뒤에도 대상 앱이 시스템 프록시를 사용하지 않을 때 TUN을 고려하세요. 켜기 전에 기존 설정 상태를 기록하고 다른 VPN과 동시에 실행하지 않도록 하세요. DNS 모드, 라우팅 제외 항목, TUN 네트워크 스택은 코어와 클라이언트 문서에 따라 설정해야 합니다. 인터넷에서 찾은 YAML 전체를 구독 설정에 그대로 덮어쓸 필요는 없습니다.

첫 연결 확인 및 자주 발생하는 오류

세 단계로 연결, 규칙, 노드 문제 구분하기

  1. 로컬 연결을 확인하세요. 코어가 실행 중이고 포트가 수신 대기 중인지 확인한 뒤 데스크톱에서는 프록시를 명시한 명령으로 테스트하세요. Android에서는 VPN이 시작되었는지, 대상 앱이 앱별 규칙에서 제외되지 않았는지 확인하세요.
  2. 연결 기록을 확인하세요. 새 웹 요청을 한 번 보내고 클라이언트의 연결 화면에서 도메인, 적용된 규칙, 출구 경로를 확인하세요. DIRECT가 표시되는 것은 규칙에 따른 결과일 수 있으며 시스템 프록시가 작동하지 않는다는 뜻은 아닙니다.
  3. 원격 응답을 확인하세요. 서로 다른 사이트 두 곳을 비교하고 같은 프록시 그룹의 다른 노드로 전환해 보세요. 지연 시간 테스트에 값이 표시되더라도 테스트 대상에 대한 결과일 뿐, 모든 사이트에 접속할 수 있음을 의미하지는 않습니다.
설치 후 아이콘을 두 번 눌러도 반응이 없을 때 확인할 사항

먼저 시스템 트레이나 메뉴 막대에 이미 실행 중인 인스턴스가 있는지 확인한 다음 아키텍처와 최소 운영체제 버전을 확인하세요. Windows에서는 작업 관리자에서 프로세스를 확인하고 필요하면 앱 로그나 이벤트 뷰어를 살펴보세요. 배포 안내에 특정 런타임이나 WebView2가 필요하다고 되어 있다면 공식 종속성 안내에 따라 설치하세요. 출처가 불분명한 사이트에서 DLL 파일만 따로 다운로드하지 마세요. 포터블 버전은 압축이 제대로 풀렸는지, 폴더에 쓰기 권한이 있는지도 확인하세요.

로그에 address already in use가 표시될 때

대개 수신 대기 중인 포트를 다른 프로그램이 사용 중이라는 뜻입니다. Windows에서는 netstat -ano | findstr :7890으로 프로세스 번호를 찾고, macOS에서는 lsof -nP -iTCP:7890 -sTCP:LISTEN으로 수신 대기 프로세스를 확인하세요. 중복 실행된 클라이언트를 먼저 종료하거나 포트를 변경하세요. 포트를 바꾸면 시스템 프록시와 수동 설정을 사용하는 앱에도 새 포트를 반영해야 합니다.

HTTPS 사이트에서 인증서 오류가 발생하면 인증서를 설치해야 하나요?

일반적인 HTTP CONNECT, SOCKS 또는 TUN 전달에는 클라이언트 루트 인증서를 설치할 필요가 없습니다. 먼저 기기의 날짜와 시간대, 사이트 도메인, 인증서 유효기간을 확인하고 로그인 포털이나 기업용 HTTPS 검사 네트워크를 사용 중인지 살펴보세요. 오류를 없애려고 출처가 불분명한 루트 인증서를 설치하거나 skip-cert-verify를 기본적으로 true로 설정하지 마세요.

노드의 TLS 핸드셰이크 로그에 오류가 나타나면 노드 서버 이름, SNI, 서버 인증서를 확인하고 서비스 제공업체에 설정 수정을 요청하세요. 이는 브라우저에서 대상 사이트에 접속할 때 발생하는 인증서 오류와는 다른 단계의 문제입니다.

클라이언트를 종료한 뒤 브라우저에서 인터넷이 되지 않을 때

먼저 시스템 프록시가 더 이상 수신 대기하지 않는 127.0.0.1:7890을 가리키는지 확인하세요. 클라이언트를 다시 열어 시스템 프록시를 끈 다음 정상적으로 종료하세요. 클라이언트를 실행할 수 없다면 시스템 프록시 설정에서 남아 있는 수동 프록시를 제거하세요. Android에서는 ‘VPN 연결 없이는 차단’이 켜져 있는지 확인하고 필요하면 원래 설정으로 되돌리세요.

클라이언트 다운로드