시작 가이드 예상 읽기 시간 13분

Clash 첫 설치 및 설정 완벽 가이드: 모든 플랫폼 공통 핵심과 흔한 실수

설치 파일 다운로드부터 구독 가져오기, 시스템 프록시 활성화까지 5개 플랫폼의 초기 설정 순서를 정리했습니다. 설치 차단, 구독 가져오기 실패, 프록시 미작동 등 초보자가 자주 겪는 문제와 해결 방법도 단계별로 안내합니다.

먼저 클라이언트, 코어, 설치 파일 확인하기

처음 설정에 실패하는 원인은 노드보다 첫 단계에서 잘못된 파일을 선택했기 때문인 경우가 많습니다. Clash는 프록시 규칙 체계와 코어를 통칭하는 이름이며, 데스크톱이나 휴대폰에서 실제로 사용하는 것은 그래픽 인터페이스가 있는 클라이언트입니다. 현재 널리 사용되는 코어는 Clash Meta, 즉 mihomo입니다. 클라이언트는 구독 관리, 정책 선택, 시스템 프록시, 로그 표시를 담당하고, 코어는 프로토콜 연결, 규칙 매칭, DNS, 트래픽 전달을 담당합니다.

다운로드하기 전에 운영체제, 프로세서 아키텍처, 설치 파일 형식 세 가지를 확인하세요. Windows 10 22H2와 Windows 11을 사용하는 일반적인 Intel·AMD PC는 보통 x64를 선택하고, Windows on ARM 장치는 arm64를 선택합니다. Apple Silicon Mac, 즉 M1·M2·M3·M4 시리즈는 arm64 또는 universal을 우선 선택하세요. 구형 Intel Mac은 x64를 선택하면 됩니다. Android 앱에서 여러 아키텍처를 제공한다면 최근 출시된 대부분의 스마트폰은 arm64-v8a입니다.

플랫폼 일반적인 설치 파일 설치 전 확인 사항
Windows .exe、.msi x64 또는 arm64, 데스크톱 앱 설치 허용 여부
macOS .dmg Apple Silicon 또는 Intel, 운영체제 버전 요구 사항
Android .apk arm64-v8a, 현재 출처의 앱 설치 허용 여부
iOS / iPadOS App Store 앱 스토어 지역, 운영체제 버전, 구독 형식 지원 여부
Linux .deb、.rpm、AppImage 배포판 패키지 관리자 방식, x86_64 또는 aarch64

시스템에서 설치를 차단할 때 해결 방법

구독을 가져오기 전에 링크 상태 확인하기

구독 링크는 일반적인 홈페이지 주소가 아닙니다. 보통 계정 식별 정보가 포함되어 YAML 설정이나 노드 목록을 반환합니다. 복사할 때 쿼리 매개변수를 빠뜨리지 말고, 메신저에서 생성된 미리보기용 리디렉션 주소를 구독 주소로 사용하지 마세요. 구독 링크는 접속 자격 증명과 같으므로 스크린샷, 포럼, 공개 코드 저장소에 게시해서는 안 됩니다.

데스크톱 클라이언트의 일반적인 경로는 「설정」 또는 「Profiles」→「URL에서 가져오기」→ 구독 주소 붙여넣기 →「가져오기」입니다. Android 클라이언트는 보통 「설정」→ 오른쪽 위 더하기 버튼 →「URL에서 가져오기」 순서로 진행합니다. iOS 호환 클라이언트는 대개 「설정」 또는 「구독」 화면에서 원격 리소스를 추가합니다. 메뉴 이름은 클라이언트 버전에 따라 달라질 수 있지만, 핵심은 개별 프록시 노드를 수동으로 만드는 것이 아니라 원격 설정을 생성하는 것입니다.

가져온 후 확인할 항목

  1. 설정 목록에 새 구독 이름이 나타나고 최근 업데이트 시간이 표시됩니다.
  2. 「프록시」 또는 「Proxies」 화면으로 전환하면 정책 그룹과 노드를 볼 수 있습니다.
  3. 설정 파일에 proxies, proxy-groups, rules 등의 필드가 있거나 구독 변환 서비스가 생성한 동일한 구조의 내용이 있어야 합니다.
  4. 선택한 설정이 활성화되어 있어야 하며, 단순히 로컬 목록에 다운로드된 상태여서는 안 됩니다.
mixed-port: 7890
mode: rule
allow-lan: false

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 자동 선택
      - DIRECT

위 YAML은 필드 계층만 보여주는 예시입니다. 실제 포트, 정책 그룹 이름, 노드는 설정에서 제공됩니다. “튜토리얼과 똑같이 설정한다”는 이유로 기존 설정을 덮어쓰지 마세요. 특히 구독으로 생성된 proxy-groups와 rules를 삭제하면 안 됩니다. YAML은 들여쓰기에 민감하므로 Tab, 공백 하나 부족, 중복 키 이름만으로도 로딩에 실패할 수 있습니다.

구독 가져오기 실패 시 오류별 대응

실행 모드와 첫 번째 사용 가능 노드 선택하기

구독을 성공적으로 가져왔다면 먼저 실행 모드를 「규칙」 또는 rule로 설정하세요. 규칙 모드는 도메인, IP, 프로세스 등의 조건을 위에서부터 매칭하고 요청을 해당 정책 그룹으로 전달합니다. 전역 모드는 대부분의 요청을 지정한 프록시로 통일하므로 임시 비교 테스트에 적합하며, 직접 연결 모드는 프록시를 우회합니다. 처음 설정할 때는 전역 모드를 권장하지 않습니다. 정책 그룹과 규칙 설정의 문제를 가릴 수 있기 때문입니다.

노드 테스트에서 지연 시간 숫자만 보지 마세요

「프록시」 화면에서 주 정책 그룹을 찾으세요. 일반적인 이름은 「노드 선택」, 「PROXY」, 「수동 선택」입니다. 먼저 지연 시간이 정상적으로 반환되는 노드를 선택한 뒤 웹페이지를 열어 확인하세요. 지연 시간 80ms가 반드시 빠른 다운로드를 의미하지는 않습니다. 지연 시간 테스트는 테스트 시점에 탐색 주소에 도달할 수 있다는 뜻일 뿐입니다. 3000ms, 5000ms 또는 Timeout이 연속으로 표시될 때 노드 상태나 네트워크 연결을 우선 점검하세요.

  1. 같은 지역의 노드 3개에서 각각 한 번씩 지연 시간 테스트를 실행하세요.
  2. 지연 시간 변동이 작고 두 번 연속 결과가 나온 노드를 우선 선택하세요.
  3. 프록시가 필요한 웹사이트를 열고 연결 기록에 새 요청이 나타나는지 확인하세요.
  4. 웹페이지가 열리지 않으면 두 번째 노드로 바꿔 다시 테스트하고, 곧바로 DNS를 변경하지 마세요.
  5. 모든 노드가 동시에 시간 초과되면 구독, 시스템 시간, 직접 연결 네트워크를 차례로 확인하세요.

시스템 시간의 오차로 TLS 인증서 검증이 실패할 수 있습니다. Windows는 「설정」→「시간 및 언어」→「날짜 및 시간」에서 자동 시간 설정을 켜세요. macOS 경로는 「시스템 설정」→「일반」→「날짜 및 시간」입니다. 휴대폰에서도 자동 날짜, 시간, 시간대를 활성화해야 합니다. 시간을 수정한 후에는 클라이언트를 완전히 종료했다가 다시 연결하세요.

시스템 프록시와 TUN을 무작정 함께 켜지 마세요

노드를 사용할 수 있다고 해서 앱 트래픽이 Clash로 들어온다는 뜻은 아닙니다. 클라이언트에는 시스템 프록시 또는 TUN 중 하나 이상의 트래픽 전달 방식이 필요합니다. 처음에는 경로가 짧고 문제를 확인하기 쉬운 시스템 프록시를 사용하세요. Windows와 macOS 데스크톱 클라이언트에는 보통 「시스템 프록시」 토글이 있습니다. 활성화하면 시스템 프록시를 지원하는 브라우저와 앱이 로컬 수신 포트로 연결됩니다.

시스템 프록시를 올바르게 확인하는 방법

일반적인 설정은 127.0.0.1:7890을 mixed-port로 사용하며 HTTP와 SOCKS 트래픽을 모두 받을 수 있습니다. 일부 오래된 설정은 7890과 7891을 각각 사용할 수 있습니다. 포트는 현재 설정과 클라이언트 화면에 표시된 값을 기준으로 확인하세요. 설정에는 7897이 적혀 있는데 시스템 프록시가 여전히 7890을 가리키면 클라이언트는 정상 실행되어도 웹페이지에 연결되지 않습니다.

TUN이 필요한 경우

TUN은 가상 네트워크 인터페이스를 만들어 시스템 프록시를 따르지 않는 앱, 일부 명령줄 도구, 게임 트래픽을 전달합니다. 데스크톱 클라이언트에서 TUN을 켤 때 서비스 모드를 설치하거나 관리자 권한을 부여해야 할 수 있습니다. 일반적인 데스크톱 클라이언트는 보통 「설정」→「시스템 설정」에서 서비스 모드를 설치한 뒤 TUN을 켭니다. Android와 iOS는 시스템 VPN 승인을 통해 가상 인터페이스를 만듭니다.

처음 문제를 확인할 때 시스템 프록시, TUN, 브라우저 확장 프로그램, 다른 VPN을 동시에 켜지 마세요. 먼저 다른 트래픽 전달 도구를 끄고 시스템 프록지만 활성화한 상태에서 웹페이지를 테스트하는 것이 좋습니다. 특정 앱이 여전히 직접 연결된다면 시스템 프록시를 끄고 TUN만 켜서 별도로 테스트하세요. 두 방식을 함께 사용한다고 반드시 충돌하는 것은 아니지만 라우팅, DNS, 제외 규칙을 판단하기가 더 어려워집니다.

5개 플랫폼의 최초 권한 확인

Windows: 서비스 모드와 남아 있는 프록시

일반적인 시스템 프록시는 보통 관리자 권한이 필요하지 않지만, TUN과 시작 시 자동 실행 기능은 서비스 모드에 의존할 수 있습니다. 서비스 설치에 실패하면 먼저 이전 버전의 클라이언트를 종료한 뒤 작업 관리자에 관련 코어 프로세스가 남아 있는지 확인하세요. 클라이언트가 비정상 종료되면 Windows에 수동 프록시 설정이 남아 Clash를 종료했는데도 브라우저가 완전히 오프라인이 될 수 있습니다. 이때 「설정」→「네트워크 및 인터넷」→「프록시」에서 작동하지 않는 수동 프록시를 끄고, 클라이언트를 다시 연 다음 시스템 프록시를 활성화하세요.

macOS: 네트워크 확장 프로그램과 로그인 항목

macOS에서 TUN 또는 네트워크 확장 프로그램을 처음 활성화하면 시스템 권한 승인 창이 나타납니다. 승인 후 기기 암호를 입력하거나 Touch ID를 사용해야 할 수 있습니다. 클릭해도 적용되지 않으면 「시스템 설정」→「개인정보 보호 및 보안」의 알림과 「시스템 설정」→「일반」→「로그인 항목 및 확장 프로그램」의 네트워크 확장 프로그램 상태를 확인하세요. 같은 종류의 클라이언트를 여러 개 반복 설치하지 마세요. 네트워크 확장 프로그램이 트래픽 전달 권한을 서로 차지하려 할 수 있습니다.

Android: VPN 승인과 배터리 제한

Android에서 시작을 누르면 TUN 인터페이스를 만드는 데 필요한 VPN 연결 요청이 표시됩니다. 일반적으로 한 번에 하나의 VPN 앱만 연결 상태가 될 수 있습니다. 화면을 잠근 뒤 몇 분 후 프록시가 자동으로 중지되면 「설정」→「앱」→ 현재 클라이언트 →「배터리」에서 백그라운드 실행 정책을 계속 실행 허용으로 변경하세요. 제조사별 운영체제에 따라 메뉴 이름은 조금 다를 수 있습니다. 상태 표시줄에 열쇠 또는 VPN 아이콘이 나타나면 인터페이스가 생성된 것이지만, 노드 사용 가능 여부는 연결 로그를 확인해야 합니다.

iOS 및 iPadOS: VPN 설정과 주문형 연결

호환 클라이언트를 처음 실행하면 시스템에서 VPN 설정 추가를 요청합니다. 승인 후 「설정」→「일반」→「VPN 및 기기 관리」→「VPN」에서 확인할 수 있습니다. 다른 VPN, 기업용 네트워크 도구, 필터가 실행 중이라면 먼저 연결을 끊고 테스트하세요. 주문형 연결은 네트워크 조건에 따라 자동으로 시작되므로, 처음 문제를 확인할 때는 자동 조건을 잠시 끄고 수동으로 연결한 뒤 클라이언트 로그를 살펴보는 것이 좋습니다.

Linux: 데스크톱 프록시와 환경 변수

Linux 데스크톱 환경은 시스템 프록시를 지원하는 방식이 서로 완전히 같지 않습니다. GNOME이나 KDE에서 시스템 프록시를 활성화해도 터미널 프로그램이 자동으로 상속하지 않을 수 있습니다. 프로그램에 따라 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY를 설정하고 포트는 클라이언트의 수신 포트와 맞추세요. 더 많은 프로그램의 트래픽을 전달하려면 TUN을 사용하기 전에 필요한 권한이 활성화되어 있는지 확인하고, 방화벽, 라우팅 테이블, NetworkManager 간 충돌도 점검하세요.

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

프록시를 켰는데도 작동하지 않을 때의 고정 점검 순서

이때 설정 열 개를 무작정 바꾸지 마세요. 트래픽이 거치는 계층을 따라 설정부터 출구까지 하나씩 확인합니다. 한 번에 변수 하나만 변경하고, 변경 후에는 같은 테스트 페이지를 새로 고치세요.

  1. 설정 활성화 확인: 설정 목록에서 현재 선택된 항목이 클라이언트 기본 예제가 아니라 방금 가져온 구독인지 확인하세요.
  2. 노드 연결 확인: 주 정책 그룹이 작동하지 않는 노드에 머물러 있거나 DIRECT를 잘못 선택한 상태가 아니어야 합니다.
  3. 실행 모드 확인: 규칙 모드를 선택하세요. 일시적으로 전역 모드로 전환해 한 번 테스트하면 노드 문제인지 규칙 문제인지 구분하는 데 도움이 됩니다.
  4. 수신 포트 확인: 코어 로그에 포트가 사용 중이라는 메시지가 있는지 확인하세요. 7890을 다른 프로그램이 사용 중이면 기존 프록시 프로그램을 종료한 뒤 클라이언트를 다시 시작합니다.
  5. 트래픽 진입점 확인: 시스템 프록시와 TUN 중 하나만 활성화하고 웹페이지를 새로 고친 다음 연결 기록을 확인하세요.
  6. 규칙 매칭 확인: 요청이 DIRECT에 매칭되면 해당 도메인이 직접 연결로 설정된 규칙인지 확인하세요. 프록시 그룹에 매칭되었다면 해당 그룹에서 실제로 선택된 노드를 확인합니다.
  7. 마지막으로 DNS 확인: 도메인 해석 실패, IP로는 접속되지만 도메인으로는 접속되지 않는 현상, 또는 로그에 DNS 오류가 명확히 표시되는 경우에만 DNS 설정을 점검하세요.

로그로 세 가지 문제 유형 구분하기

증상 문제 계층 다음 단계
웹페이지를 새로 고쳐도 연결 기록이 전혀 없음 트래픽이 클라이언트로 들어오지 않음 시스템 프록시, TUN, 브라우저 확장 프로그램, 포트 확인
기록은 있지만 DIRECT로 표시됨 규칙 또는 실행 모드 매칭된 규칙을 확인하고 프록시 정책 그룹을 사용해야 하는 요청인지 판단
기록은 있고 프록시 사용 후 Timeout 발생 노드 또는 원격 회선 같은 그룹의 다른 노드로 바꾼 뒤 직접 연결 네트워크와 시스템 시간 확인
connection refused 표시 로컬 포트 또는 원격 서비스 수신 포트를 확인하고 코어가 실행 중인지 확인
DNS lookup failed 표시 도메인 해석 DNS 설정, 네트워크 권한, 상위 DNS 연결 가능 여부 확인

브라우저의 보안 DNS가 해석 경로를 바꿀 수도 있습니다. 일반적인 웹사이트는 열리는데 특정 도메인만 해석에 실패한다면 브라우저의 보안 DNS를 잠시 끄고 비교 테스트를 해보세요. 원인을 확인한 뒤 시스템 DNS, 클라이언트 DNS, 브라우저에서 지정한 DoH 중 무엇을 사용할지 결정하고, 세 설정을 동시에 변경하지 마세요.

첫 설정 완료 후 점검 목록

아래 항목을 모두 확인해야 초기 설정이 안정적으로 완료된 것입니다. 이후 문제가 발생해도 같은 목록으로 구독 변경, 노드 만료, 다른 프로그램에 의한 시스템 설정 변경 여부를 빠르게 판단할 수 있습니다.

Clash 클라이언트 다운로드Windows · macOS · Android · iOS · Linux