Clash 최초 설치 및 설정 체크리스트: 멀티플랫폼 초기화 단계와 흔한 실수

Clash를 처음 설정할 때 실제로 확인해야 할 항목은 많지 않습니다. 클라이언트가 시스템 아키텍처와 일치하는지, 구성이 정상적으로 로드되는지, 정책 그룹이 선택되어 있는지, 프록시 진입점이 활성화되어 있는지를 확인하면 됩니다. 문제는 대개 작업 순서에서 발생합니다. 예를 들어 구독을 업데이트하기 전에 시스템 프록시를 켜거나, 기본 연결을 확인하기도 전에 DNS·규칙·TUN을 한꺼번에 변경하면 어떤 항목이 문제를 일으켰는지 판단하기 어려워집니다.

Clash는 규칙 기반 프록시 코어와 클라이언트 생태계를 통칭하는 이름으로 널리 사용됩니다. 데스크톱과 모바일 클라이언트마다 메뉴 이름은 다를 수 있고, 기반 코어도 Clash Meta(현재는 보통 mihomo라고 부름)일 수 있지만 초기 설정의 기본 원리는 거의 같습니다. 아래 체크리스트는 특정 인터페이스에 의존하지 않으며 Windows, macOS, Android, iOS 및 Linux에서 흔히 사용하는 호환 클라이언트에 적용할 수 있습니다.

1. 설치 전 클라이언트, 시스템 및 구성 출처 확인

다운로드하기 전에 기기 플랫폼과 프로세서 아키텍처를 확인하세요. Windows는 x64가 일반적이지만 일부 최신 기기는 ARM64를 사용합니다. macOS는 Apple Silicon과 Intel을 구분해야 하며, Linux는 아키텍처뿐 아니라 패키지 형식과 데스크톱 환경 지원 여부도 확인해야 합니다. 아키텍처가 맞지 않으면 프로그램이 실행되지 않거나 호환성 계층을 통해 실행되더라도 서비스 설치, 트레이 표시 또는 성능 문제가 발생할 수 있습니다.

설치 전 체크리스트

운영체제 버전 확인: 클라이언트 릴리스 안내에서 필요한 최소 시스템 요구 사항을 확인하세요. 오래된 시스템에는 실행 구성 요소나 시스템 API가 없을 수 있습니다.
프로세서 아키텍처 확인: 기기 브랜드만 보고 판단하지 말고 시스템 정보 화면에서 x64, ARM64, Apple Silicon 또는 기타 아키텍처 표시를 직접 확인하세요.
구독 경로 보관: 서비스 제공업체가 안내한 구독 주소, 구성 파일 또는 가져오기 방법을 준비하세요. 구독 주소에는 대개 접근 인증 정보가 포함되므로 공개 채팅, 스크린샷 또는 로그에 공유해서는 안 됩니다.
기존 네트워크 설정 기록: 시스템에 수동 프록시, VPN, 네트워크 필터 또는 기업용 보안 프로그램이 설정되어 있다면 먼저 현재 상태를 기록해 두세요. 연결 문제가 발생했을 때 항목별로 복원하기 쉽습니다.
유사 도구 동시 실행 피하기: 여러 프로그램이 시스템 프록시, 가상 네트워크 어댑터, DNS 또는 로컬 포트를 동시에 사용하면 최초 확인 결과를 신뢰하기 어려워집니다.

기기에 다른 프록시 클라이언트를 설치한 적이 있다면 프로그램을 종료하는 것만으로 프록시 설정이 복원되지는 않을 수 있습니다. Windows와 macOS에는 수동 프록시 주소가 남아 있을 수 있고, 모바일 운영체제에도 VPN 구성이 계속 표시될 수 있습니다. Clash 클라이언트를 설치하기 전에 시스템 네트워크 설정을 확인하여, 이미 종료된 프로그램을 가리키는 프록시 포트가 남아 있지 않은지 점검하세요.

2. 플랫폼별 설치 및 필요한 권한 승인

클라이언트가 열렸다는 것은 그래픽 인터페이스가 시작되었다는 의미일 뿐, 시스템 트래픽이 프록시 코어로 전달되고 있다는 뜻은 아닙니다. 최초 실행 시에는 코어 상태, 구성 디렉터리 및 권한 안내를 먼저 확인한 뒤 시스템 서비스 설치나 가상 네트워크 어댑터 활성화 여부를 결정하세요. 관리자 권한이 모든 작업에 필요한 것은 아니지만 서비스 모드, TUN 드라이버 및 일부 시스템 수준 설정에는 추가 권한이 필요한 경우가 많습니다.

Windows: 코어 실행을 확인한 뒤 서비스 모드 설정

Windows에 설치한 후에는 먼저 클라이언트를 정상적으로 실행하고 코어가 성공적으로 작동하는지, 로컬 프록시 포트가 수신 대기 중인지 확인하세요. 클라이언트에 ‘서비스 모드’, ‘관리자 서비스’ 또는 유사한 기능이 있다면 일반 권한의 인터페이스가 TUN, 라우팅 또는 시스템 설정을 관리하도록 돕는 용도인 경우가 많습니다. 최초 시스템 프록시 테스트에서 서비스를 바로 설치할 필요는 없습니다. 기본 프록시 연결이 작동한 뒤 클라이언트 안내에 따라 설치하면 문제 원인을 더 쉽게 찾을 수 있습니다.

설치 프로그램이 시스템 보안 경고로 차단되면 다운로드 출처와 게시자 정보를 확인하고, 시스템 보호 기능을 끄는 방식으로 우회하지 마세요. 회사나 학교에서 관리하는 기기는 드라이버, 서비스 및 프록시 변경이 제한될 수 있으므로 해당 권한은 기기 관리자에게 요청해야 합니다.

macOS: 칩 아키텍처와 네트워크 확장 권한 확인

macOS에서는 칩에 맞는 빌드를 선택해야 합니다. 처음 실행할 때 시스템에서 앱 출처 확인을 요구할 수 있으며, TUN 또는 강화 모드를 활성화하면 관리자 암호, 네트워크 확장 또는 VPN 구성 승인이 필요할 수도 있습니다. 승인 후에도 기능이 바로 적용되지 않으면 클라이언트를 완전히 종료했다가 다시 열고, 시스템 설정의 VPN 및 필터 항목을 확인하세요.

최초 실행 단계에서 기존 클라이언트의 규칙, 스크립트 및 오버라이드 설정을 모두 한꺼번에 옮기지 마세요. 먼저 원본 구독을 가져와 연결 테스트를 완료하면 시스템 권한 문제인지, 기존 구성과 새 코어의 호환성 문제인지 구분할 수 있습니다.

Android 및 iOS: 시스템 VPN 권한 이해

모바일 클라이언트는 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 처리합니다. 처음 연결을 누르면 시스템에서 VPN 구성 승인을 요청하며, 사용자가 승인한 뒤에야 상태 표시줄의 VPN 아이콘과 클라이언트 연결 상태가 실제 의미를 갖습니다. Android의 배터리 최적화 기능은 백그라운드에서 클라이언트를 종료할 수 있습니다. 일정 시간 화면을 잠근 뒤 연결이 끊긴다면 사용 중인 클라이언트의 백그라운드 실행 정책을 조정하세요. 제조사별 시스템마다 메뉴 이름은 다르므로 최초 설치 시 모든 절전 옵션을 바꾸기보다 실제로 백그라운드 중단이 발생하는지 먼저 확인하는 것이 좋습니다.

iOS 클라이언트는 시스템이 제공하는 네트워크 확장 방식을 따라야 합니다. 구독은 가져와지지만 VPN을 연결할 수 없다면 시스템에 더 이상 유효하지 않은 VPN 구성이 남아 있는지, 또는 기기 관리 정책이 새 구성 추가를 제한하는지 확인하세요.

Linux: 실행 권한, 데스크톱 세션 및 프록시 적용 범위 확인

Linux 클라이언트는 배포판 패키지, 압축 파일 또는 AppImage 등의 형태로 제공될 수 있습니다. 설치 후에는 ‘프로그램이 실행되는 것’과 ‘데스크톱 환경이 프록시 설정을 적용하는 것’을 구분해야 합니다. 데스크톱 환경마다 시스템 프록시 지원 방식이 다르고, 명령줄 프로그램이 데스크톱 프록시를 읽지 않을 수도 있습니다. 최초 테스트에서는 클라이언트에 내장된 연결 화면이나 시스템 프록시를 명확히 지원하는 브라우저를 먼저 사용하세요. 터미널의 특정 명령 하나만으로 클라이언트 전체가 작동하지 않는다고 판단하지 마세요.

3. 구독을 가져오고 구성이 실제로 로드되었는지 확인

구독은 원격 구성에 접근하는 경로이며, 일반적으로 프록시 노드, 정책 그룹 및 규칙을 포함합니다. 주소를 클라이언트에 붙여넣은 뒤에는 다운로드 또는 업데이트를 실행하고, 다운로드한 결과를 현재 구성으로 지정해야 합니다. 구독 주소만 저장하고 구성을 활성화하지 않는 것은 새로 설치할 때 가장 흔히 빠뜨리는 단계 중 하나입니다.

구독 가져오기 후 확인할 네 가지 항목

업데이트 시간: 구독이 방금 성공적으로 업데이트되었는지 확인하세요. 빈 상태나 오래된 캐시에 머물러 있어서는 안 됩니다.
구성 상태: 해당 구독의 구성이 선택되어 있는지 확인하고, 코어 로그에 YAML 구문 오류, 필드 오류 또는 규칙 제공자 다운로드 실패가 없는지 점검하세요.
정책 그룹 내용: 프록시 또는 정책 화면에서 자주 사용하는 정책 그룹에 선택 가능한 노드가 포함되어 있는지 확인하세요. 그룹이 비어 있으면 안 됩니다.
업데이트 방식: 클라이언트가 예약 업데이트를 지원하는지 확인하고 실제 필요에 맞는 간격을 설정하세요. 자주 새로 고친다고 노드 품질이 좋아지는 것은 아니며, 오히려 서버 측 제한이 발생할 수 있습니다.

일부 서비스는 클라이언트 요청에 따라 서로 다른 형식의 구성을 생성합니다. 브라우저에서는 구독이 열리지만 클라이언트에서 지원하지 않는 형식이라고 표시된다면, 일반 노드 목록이나 다른 소프트웨어 형식 또는 로그인 페이지가 반환되고 Clash 호환 YAML이 아닐 수 있습니다. 이때는 서비스 제공업체의 사용 안내 페이지에서 해당하는 구독 유형을 다시 선택하세요. 확장자만 수동으로 YAML로 바꾸면 안 됩니다.

mixed-port: 7890
mode: rule
allow-lan: false
log-level: info

위 조각은 몇 가지 기본 필드를 이해하기 위한 예시일 뿐입니다. mixed-port는 로컬 혼합 프록시 포트이고, mode: rule은 규칙에 따라 처리한다는 뜻이며, allow-lan: false는 기본적으로 로컬 네트워크 기기에 공개하지 않는다는 의미입니다. 실제 구독에는 프록시, 정책 그룹, DNS 및 규칙 등 훨씬 많은 내용이 포함되므로 이 조각을 완전한 구성으로 그대로 실행해서는 안 됩니다.

4. 변수를 최소화해 최초 연결 확인

구성이 정상적으로 로드된 뒤에도 모든 고급 기능을 바로 켜지는 마세요. 최초 연결의 목표는 ‘애플리케이션 트래픽이 로컬 프록시 포트로 들어가 구성에 따라 사용 가능한 출구를 선택하는지’를 확인하는 것입니다. 가장 안정적인 방법은 규칙 모드를 사용하고 명확한 정책 노드를 선택한 뒤 시스템 프록시를 켜고, 안정적인 사이트 몇 곳에 접속하면서 로그를 확인하는 것입니다.

권장 확인 절차

실행 모드를 규칙 모드로 설정하세요. 규칙 매칭을 확인하면서도 글로벌 모드처럼 모든 요청을 하나의 정책으로 강제하지 않을 수 있습니다.
주요 정책 그룹에서 상태가 정상인 노드 하나를 직접 선택하세요. 지연 시간 테스트가 성공했다는 것은 특정 탐색 요청에 응답했다는 뜻일 뿐, 모든 대상에 접속할 수 있다는 의미는 아닙니다.
시스템 프록시를 켜고 TUN은 잠시 활성화하지 마세요. 브라우저는 대개 시스템 프록시를 읽으므로 첫 번째 테스트 도구로 적합합니다.
일반 웹사이트를 하나 연 다음 프록시 정책이 필요한 대상에 접속하고, 클라이언트 연결 목록에 도메인, 대상 주소, 매칭된 규칙 및 정책 이름이 표시되는지 확인하세요.
접속할 수 없다면 먼저 시스템 프록시를 끄고 네트워크를 복구한 뒤, 로그에서 시간 초과, 연결 거부, DNS 실패 또는 구성 오류를 확인하세요.

로그 수준은 보통 info면 충분합니다. 로그에 연결 기록이 나타난다면 애플리케이션 트래픽이 Clash로 들어온다는 뜻입니다. 브라우저에 오류가 표시되는데 연결 목록에 새 요청이 전혀 없다면 시스템 프록시가 켜져 있는지, 브라우저가 별도의 프록시 설정을 사용하는지, 로컬 포트가 구성과 일치하는지를 먼저 확인하세요. 연결 기록은 있지만 계속 시간 초과가 발생한다면 노드, 정책 선택, 원격 네트워크 및 규칙의 목적지를 점검하는 것이 좋습니다.

규칙 모드에서는 각 요청이 규칙 목록의 위에서 아래로 매칭되고, 일치하는 규칙을 찾으면 지정된 정책으로 전달됩니다. 구성 마지막에는 앞에서 매칭되지 않은 트래픽을 처리하는 기본 규칙이 있는 경우가 많습니다. 최초 테스트에서는 규칙 순서를 수정할 필요가 없습니다. 원본 구성이 작동한 뒤 실제 필요에 따라 도메인 또는 프로세스 규칙을 추가하세요.

5. 기본 프록시가 정상 작동한 뒤 TUN 및 DNS 활성화

시스템 프록시는 주로 운영체제의 프록시 설정을 따르는 애플리케이션에 영향을 줍니다. 일부 게임, 명령줄 도구, 백그라운드 서비스 및 특수 네트워크 스택을 사용하는 프로그램은 이를 우회할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스와 라우팅을 통해 더 넓은 범위의 트래픽을 처리하지만, 그만큼 시스템 권한, 드라이버, 라우팅 테이블 및 DNS 설정에 더 크게 의존합니다.

TUN을 활성화하기 전에 시스템 프록시에서 정상적으로 작동하는 상태를 기록하세요. 그런 다음 시스템 프록시를 끄거나 클라이언트 권장 방식으로 전환하여, 문제 해결 시 트래픽이 어느 경로로 들어오는지 확인할 수 있게 하세요. 일부 클라이언트는 시스템 프록시와 TUN을 동시에 사용할 수 있지만, 최초 설정에서는 하나의 주요 처리 방식만 유지하는 것이 좋습니다. TUN을 켠 뒤 브라우저를 다시 테스트하고, 이전에 프록시되지 않았던 애플리케이션도 테스트하면서 연결 목록에 해당 요청이 새로 표시되는지 확인하세요.

TUN 활성화에 실패했을 때 확인할 항목

클라이언트에 관리자, VPN 또는 네트워크 확장 권한이 부여되었는지 확인하세요.
다른 VPN, 가상 네트워크 어댑터 또는 네트워크 필터 소프트웨어가 라우팅을 동시에 변경하고 있지 않은지 확인하세요.
TUN 장치가 정상적으로 생성되었는지, 코어 로그에 라우팅 또는 인터페이스 오류가 기록되었는지 확인하세요.
네트워크를 전환한 뒤 기본 네트워크 어댑터가 바뀌었는지 확인하세요. 예를 들어 유선 네트워크에서 Wi-Fi로 전환된 경우입니다.
로컬 네트워크, 프린터 또는 개발 환경의 네트워크 대역에 직접 연결 규칙이 필요한지 확인하세요.

DNS는 ‘연결되었지만 도메인이 열리지 않는’ 문제에서 핵심적으로 확인할 항목입니다. 도메인 접속은 실패하지만 이미 알고 있는 서비스에 직접 접속했을 때 응답이 있다면 DNS 해석 경로를 점검해야 할 가능성이 큽니다. Clash 또는 mihomo 구성에서는 내장 DNS를 활성화하고 fake-ip이나 redir-host 같은 강화 모드를 사용할 수 있습니다. 모드마다 적용 범위와 호환성이 다르므로 원래 구성의 설계를 이해하지 못한 상태에서 임의로 바꾸지 마세요.

DNS를 점검할 때는 먼저 요청이 코어로 들어가는지 확인한 다음, 상위 DNS에 접근할 수 있는지, 규칙이 DNS 요청을 잘못된 출구로 보내고 있지 않은지, 시스템이나 브라우저에서 별도의 암호화 DNS를 활성화했는지를 살펴보세요. 브라우저에 내장된 보안 DNS는 시스템 해석 경로를 우회할 수 있으므로 같은 도메인도 브라우저와 다른 애플리케이션에서 결과가 다를 수 있습니다.

6. 최초 설정에서 흔히 하는 실수

실수 1: 노드 지연 시간이 짧을수록 모든 접속이 반드시 빠르다고 생각하기

지연 시간 테스트는 특정 탐색 대상이 테스트 시점에 보인 응답만 반영합니다. 실제 속도는 회선 대역폭, 혼잡도, 대상 사이트, 전송 프로토콜 및 로컬 네트워크의 영향을 함께 받습니다. 노드를 선택할 때는 연결 안정성과 실제 접속 결과도 함께 확인하고, 지연 시간 수치를 반복해서 새로 고칠 필요는 없습니다.

실수 2: 구독을 가져오면 정책 선택이 필요 없다고 생각하기

구독에 따라 주요 정책 그룹이 자동 선택으로 설정되어 있을 수도 있고, 사용할 수 없는 노드에 머물러 있을 수도 있습니다. 가져온 뒤에는 정책 그룹을 열어 현재 선택 항목을 확인하세요. 구성이 여러 단계의 정책 그룹으로 이루어져 있다면 상위 그룹이 최종적으로 어떤 노드 또는 자동 테스트 그룹을 가리키는지도 확인해야 합니다.

실수 3: 연결 버튼이 켜지면 트래픽이 이미 프록시된다고 생각하기

클라이언트에 실행 중이라고 표시되는 것은 대개 코어 또는 VPN 세션이 시작되었다는 뜻일 뿐입니다. 시스템 프록시가 아직 켜지지 않았거나 TUN 라우팅 생성에 실패했을 수도 있습니다. 하나의 스위치만 보지 말고 시스템 상태, 연결 목록 및 실제 접속 결과를 함께 확인하세요.

실수 4: 문제가 생기면 코어, DNS 및 규칙을 동시에 바꾸기

여러 변수를 한 번에 변경하면 문제 해결의 기준 상태가 사라집니다. 올바른 방법은 원본 구성을 다시 사용하고 사용자 지정 오버라이드와 TUN을 끈 뒤 시스템 프록시만 테스트하는 것입니다. 기본 경로가 확인되면 DNS 오버라이드, 규칙 세트, 스크립트 및 가상 네트워크 어댑터를 하나씩 다시 적용하세요.

실수 5: 로컬 네트워크 접근을 켜면 별도 제한이 필요 없다고 생각하기

allow-lan은 같은 로컬 네트워크의 다른 기기가 이 기기의 프록시에 접근하도록 설정하는 항목입니다. 프록시 공유가 실제로 필요할 때만 활성화하고, 수신 주소·방화벽 및 인증 설정을 함께 사용해 접근 범위를 제한하세요. 일반적인 단일 기기 사용에서는 꺼 두는 편이 간단하고 포트 노출도 줄일 수 있습니다.

실수 6: 구독 주소를 일반 공개 링크처럼 다루기

구독 주소는 보통 계정에 해당하는 구성을 바로 가져올 수 있으므로 로그인 인증 정보처럼 보관해야 합니다. 문제를 문의하기 위해 스크린샷을 공유할 때는 전체 구독 URL, 쿼리 매개변수 및 구성의 인증 필드를 가리세요. 주소가 이미 공개되었다면 로컬 기록만 삭제하지 말고 서비스 제공업체의 관리 화면에서 재설정하세요.

7. 설치 완료 후 마무리 체크리스트

최초 연결이 확인되면 아래 체크리스트로 마무리 점검을 진행하세요. 각 항목을 완료한 뒤 다음 항목으로 넘어가면 이후 문제가 발생했을 때 정상 상태로 쉽게 돌아갈 수 있습니다.

클라이언트 버전과 시스템 아키텍처가 일치하고 코어가 안정적으로 실행됩니다.
구독이 성공적으로 업데이트되었으며 현재 사용 구성으로 지정되어 있습니다.
주요 정책 그룹에서 사용 가능한 노드 또는 적절한 자동 정책이 선택되어 있습니다.
규칙 모드에서 브라우저 접속이 정상이며 연결 목록에 매칭된 규칙과 정책이 표시됩니다.
시스템 프록시를 끄거나 VPN 연결을 해제하면 시스템 네트워크가 원래 상태로 복구됩니다.
필요한 경우에만 TUN을 활성화하고 라우팅, DNS 및 로컬 네트워크 접근을 별도로 확인합니다.
자동 업데이트와 시작 시 실행은 사용 습관에 맞게 설정하고, 문제 해결 중에는 구성을 자주 바꾸지 않습니다.
구독 주소와 로그의 민감한 필드를 안전하게 보관하며 공개 스크린샷에 포함하지 않습니다.

신뢰할 수 있는 최초 설치 과정의 핵심은 모든 옵션을 켜는 것이 아니라 명확한 정상 기준을 세우는 데 있습니다. 원본 구성이 로드되고, 시스템 프록시가 작동하며, 정책 매칭이 로그에 표시되는 상태를 먼저 확보하세요. 이후 TUN, 사용자 지정 규칙 또는 DNS 오버라이드를 추가하더라도 문제가 발생했을 때 변화의 원인을 빠르게 판단할 수 있습니다.