Clash 첫 설치 설정 체크리스트: Windows·macOS·Android 필수 설정과 문제 해결

1. 설치 전: 클라이언트, 코어, 기기 아키텍처 확인

Clash 클라이언트는 보통 그래픽 인터페이스와 프록시 코어로 구성됩니다. 그래픽 인터페이스는 구독 관리, 모드 전환, 시스템 설정을 담당하고, 코어는 설정을 해석하고 규칙을 적용해 연결을 수립합니다. Clash Meta는 이후 mihomo라는 이름으로 발전했지만, 클라이언트마다 포함된 코어와 지원하는 설정 항목은 다를 수 있습니다. ‘Clash 지원’이라고 표시되어 있어도 구독 제공자가 기존 Clash 형식을 요구하는지, mihomo 기능을 사용하는 설정을 요구하는지 확인해야 합니다.

Windows: Windows 11의 「설정」→「시스템」→「정보」에서 ‘시스템 종류’를 확인하세요. 일반적인 Intel·AMD PC는 x64를 선택하고, ARM 기기는 클라이언트에서 제공하는 ARM64 빌드를 우선 선택합니다.
macOS: Apple 메뉴에서 「이 Mac에 관하여」를 여세요. Apple 칩 기기는 arm64, Intel 기기는 x64를 선택하는 것이 좋습니다. Universal 설치 파일은 프로젝트 안내를 확인하세요.
Android: 최신 스마트폰은 대개 arm64-v8a를 사용하지만 구형 기기나 에뮬레이터는 다를 수 있습니다. 확실하지 않다면 프로젝트에서 제공하는 범용 APK를 선택하고 최소 Android 버전을 확인하세요.

다운로드 전에는 프로젝트의 유지 관리 상태와 릴리스 노트도 확인하세요. 클라이언트를 설치할 수 있다고 해서 시스템 권한이나 최신 설정 항목까지 계속 지원한다는 뜻은 아닙니다. 처음 사용하는 경우 플랫폼에 맞춰 다운로드 센터에서 선택한 뒤 클라이언트와 코어 버전을 기록해 두면 문제 해결에 도움이 됩니다.

2. 첫 실행: 세 플랫폼의 권한 확인

처음 실행할 때 모든 기능을 바로 켤 필요는 없습니다. 먼저 설정을 가져온 다음 시스템 프록시나 Android VPN으로 최소한의 연결을 확인하세요. 데스크톱 TUN은 가상 네트워크 어댑터, 라우팅, DNS를 다루므로 기본 연결을 확인한 뒤 별도로 테스트하는 것이 좋습니다.

플랫폼	먼저 확인할 권한	혼동하기 쉬운 점
Windows	시스템 프록시 설정을 변경할 수 있는지 확인하고, 클라이언트 안내에 따라 서비스 설치 또는 TUN 권한을 부여합니다.	방화벽에서 ‘액세스 허용’을 눌러도 시스템 프록시가 켜지는 것은 아니며, 인터넷에서 들어오는 연결을 허용해야 한다는 뜻도 아닙니다.
macOS	처음 실행할 때 출처를 확인하고, 필요한 경우 네트워크 보조 구성 요소를 허용합니다.	앱 실행 확인, 보조 서비스 권한 부여, 인증서 신뢰 설정은 각각 별개의 작업입니다.
Android	클라이언트가 VPN 연결을 설정하도록 허용합니다.	VPN 아이콘은 기기 내 트래픽 연결이 설정되었다는 뜻일 뿐, 원격 노드가 작동한다는 보장은 아닙니다.

Windows: 시스템 프록시와 서비스 모드 구분하기

시스템 프록시는 보통 이 기기의 HTTP 프록시 주소를 사용자 설정에 기록하고, 해당 설정을 따르는 앱에서 사용합니다. 모든 게임, 터미널 또는 UDP 트래픽까지 처리하지는 않습니다. TUN은 가상 네트워크 어댑터를 사용해 라우팅 설정에 해당하는 트래픽을 처리합니다. 관리자 권한 실행이나 서비스 설치가 필요한지는 클라이언트 구현에 따라 다릅니다. 웹페이지가 열리지 않는다고 모든 프로그램을 계속 관리자 권한으로 실행하지 마세요.

macOS: 출처를 먼저 확인한 후 시스템 알림 처리하기

앱을 「응용 프로그램」 폴더로 옮긴 뒤 실행하는 것이 좋습니다. macOS 15에서는 출처 관련 알림을 「시스템 설정」→「개인정보 보호 및 보안」에서 확인할 수 있습니다. 설치 파일이 프로젝트의 공식 배포 경로에서 왔고 알림이 처음 실행할 때의 제한에 해당하는 경우에만 시스템 절차에 따라 진행하세요. 앱이 손상되었거나 악성 콘텐츠가 포함되었거나 서명이 비정상이라는 알림이 나타나면 실행을 중단하고 출처를 다시 확인하세요. 시스템 보안 기능을 무작정 끄지 마세요.

Android: VPN 권한과 백그라운드 실행을 따로 확인하기

처음 연결할 때 시스템 VPN 권한 요청 창이 표시됩니다. 허용해야 클라이언트가 VpnService를 사용해 트래픽을 처리할 수 있습니다. 일반적으로 동일한 사용자 또는 업무 프로필에서는 일반 VPN 서비스를 하나만 활성화할 수 있으며, 다른 VPN 기반 방화벽이나 필터링 도구와 충돌할 수 있습니다. 화면을 잠근 뒤 한동안 지나 연결이 끊긴다면 앱의 배터리 제한을 확인하세요. 순정에 가까운 Android 14에서는 「설정」→「앱」→ 해당 클라이언트 →「앱 배터리 사용량」에서 확인할 수 있습니다. 제조사별 시스템에서는 메뉴 이름이 다를 수 있습니다.

3. 구독 가져오기: 형식, 상태, 현재 설정 확인

구독 링크는 설정을 가져오는 경로이지 노드 자체나 소프트웨어 활성화 코드가 아닙니다. 링크에는 계정 토큰이 포함되는 경우가 많으므로 비밀번호처럼 관리하세요. 스크린샷, 로그, 문의 내용에 링크 전체가 노출되지 않도록 가려야 합니다. 출처를 알 수 없는 온라인 변환 사이트에 개인 구독 링크를 붙여 넣지 마세요.

구독 형식을 확인하세요. 서비스 제공자 페이지에서 현재 클라이언트 코어에 맞는 Clash 또는 mihomo 설정을 선택하세요. Base64 노드 목록, 개별 공유 링크, 완전한 YAML 설정은 서로 다른 입력 형식입니다.
원격 설정을 추가하세요. 클라이언트의 ‘설정’ 또는 ‘구독’ 페이지에서 원격 설정을 추가하고 링크를 붙여 넣은 다음 다운로드하세요. 메뉴 이름은 클라이언트마다 다르므로 현재 화면을 기준으로 진행하세요.
다운로드 결과를 확인하세요. 업데이트 시간, 파싱 상태, 정책 그룹 내용을 확인하세요. HTTP 401·403 오류가 발생하면 토큰, 계정 권한 또는 서비스 제한을 확인해야 합니다. 시간 초과가 발생하면 먼저 현재 네트워크에서 구독 주소에 접속할 수 있는지 확인하세요.
가져온 설정을 활성화하세요. 목록에 설정이 표시되어도 적용된 것은 아닙니다. 해당 설정을 선택하고 코어가 정상적으로 시작되었는지 확인한 다음 정책 그룹에서 사용할 수 있는 노드를 선택하세요.

YAML 파싱 오류가 발생하면 로그에 표시된 항목 이름과 줄 번호부터 확인하세요. 응답이 로그인 페이지나 서비스 오류 메시지일 수도 있고, 현재 코어가 지원하지 않는 매개변수를 포함할 수도 있습니다. 이때 노드를 계속 바꿔도 설정 문법 오류는 해결되지 않습니다. 오류가 난 줄을 임의로 삭제하기보다 올바른 형식의 설정을 다시 받으세요.

4. 첫 연결 확인: 규칙 모드와 프록시 설정 점검

처음 연결을 테스트할 때는 규칙 모드를 선택하고, 실제 규칙에서 참조하는 정책 그룹에서 노드를 지정하는 것이 좋습니다. 규칙 모드는 설정된 규칙에 따라 직접 연결하거나 프록시를 사용합니다. 전역 모드로 바꿔도 작동하지 않는 노드가 고쳐지지는 않으며, 직접 연결 모드라고 해서 클라이언트가 종료되는 것도 아닙니다. TUN이 켜져 있다면 트래픽은 계속 로컬 코어를 통과할 수 있으며, 외부 연결 방식만 직접 연결로 바뀝니다.

현재 설정이 활성화되어 있고 코어 시작 실패나 반복 재시작이 없는지 확인하세요.
데스크톱에서는 시스템 프록시를 켜고, Android에서는 연결을 누른 뒤 VPN 권한을 허용하세요. 데스크톱에서 처음 테스트할 때는 TUN을 함께 켜지 마세요.
대상 정책 그룹에서 지연 시간을 한 번 테스트한 다음 실제로 사용할 웹사이트에 접속하세요. 테스트에 성공해도 테스트 대상에 접속할 수 있다는 뜻일 뿐, 모든 웹사이트 이용을 보장하지는 않습니다.
연결 기록을 열어 새 요청이 표시되는지 확인하고 일치한 규칙, 정책 경로, 최종 노드를 점검하세요. 기존 연결은 이전 출구를 계속 사용할 수 있으므로 노드를 바꾼 뒤에는 연결을 새로 설정해야 합니다.

데스크톱에서는 로컬 프록시를 명시적으로 지정해 ‘코어가 트래픽을 전달하는지’와 ‘브라우저가 시스템 프록시를 사용하는지’를 구분할 수 있습니다. 아래 예시는 실제 수신 포트가 7890인 HTTP 또는 mixed 프록시를 기준으로 합니다. 예시 포트이므로 먼저 클라이언트 설정에서 실제 값을 확인하세요. 테스트 대상 웹사이트는 확인하려는 HTTPS 주소로 바꿔도 됩니다.

# Windows PowerShell
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 10 https://example.com

# macOS 터미널
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 10 https://example.com

HTTP 응답 헤더가 반환되면 지정한 프록시를 통해 요청이 응답을 받았다는 뜻입니다. 상태 코드는 대상 사이트에 맞춰 해석해야 합니다. 명령은 성공하지만 브라우저에서 실패한다면 브라우저 프록시 확장 프로그램, 브라우저 자체 설정, 시스템 프록시를 먼저 확인하세요. 연결 거부 메시지가 나오면 DNS를 바로 수정하기보다 수신 주소와 포트, 코어 상태를 확인하세요.

5. 포트 충돌: 프로세스를 확인한 뒤 설정 변경

로그에 address already in use가 표시되거나 bind에 실패하면 수신 주소나 포트가 이미 사용 중일 가능성이 큽니다. 기존 클라이언트가 완전히 종료되지 않았거나 같은 프로그램이 두 번 실행된 경우가 흔한 원인입니다. 아래 예시에서는 TCP 포트 7890을 사용합니다. 확인 명령은 클라이언트를 실행 중인 PC에서 실행하세요.

# Windows: 포트를 사용 중인 PID 확인
netstat -ano | findstr :7890
# 그런 다음 작업 관리자의 ‘세부 정보’ 탭에서 PID로 프로세스 찾기

# macOS: 해당 TCP 포트를 수신 중인 프로세스 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

기존 프록시 프로세스가 확인된 경우: 먼저 기존 프로그램의 메뉴에서 정상적으로 종료하세요. 정체를 알 수 없는 시스템 프로세스를 바로 강제 종료하지 마세요.
포트를 바꿔야 하는 경우: 예를 들어 7890을 7895로 변경했다면 시스템 프록시, 브라우저의 수동 프록시, 터미널 프록시 설정도 함께 업데이트하세요.
포트가 수신 대기 중이 아닌 경우: 코어 로그에서 설정이 정상적으로 로드되었는지 확인하세요. 대시보드 포트는 트래픽 프록시 포트와 다른 용도이므로 서로 대체할 수 없습니다.

이 기기에서만 사용할 경우 수신 주소는 루프백으로 유지하고 필요하지 않은 LAN 접근 기능은 끄세요. HTTP, SOCKS, mixed, 제어 인터페이스는 용도가 서로 다릅니다. 연결을 위해 모든 수신 주소를 외부에 개방하지 마세요.

6. 인증서, DNS, TUN: 증상에 따라 해결하기

인증서 경고가 표시되어도 인증서를 설치해야 하는 것은 아닙니다

일반적인 HTTPS 프록시 연결은 터널을 통해 전달되므로 클라이언트에서 제공하는 루트 인증서를 설치할 필요가 없습니다. 브라우저에서 인증서 날짜가 유효하지 않다고 표시되면 시스템 날짜와 시간대, 자동 시간 설정을 먼저 확인하세요. 도메인 이름이 일치하지 않거나 발급자를 신뢰할 수 없다는 경고가 나오면 잘못된 도메인이나 공용 네트워크의 로그인 페이지에 접속한 것은 아닌지, 다른 HTTPS 검사 프로그램의 영향을 받는지 확인하세요.

구독을 다운로드할 때 TLS 오류가 발생해도 구독 서버 인증서와 기기 시간을 확인해야 합니다. 인증서 검증을 건너뛰는 방법을 일반적인 해결책으로 사용하지 마세요. 채팅 메시지나 출처가 불분명한 웹페이지에서 받은 루트 인증서를 설치해서도 안 됩니다. 회사에서 관리하는 기기에 명확한 인증서 정책이 있다면 관리자에게 확인하세요.

도메인 연결 실패 시 어느 단계에서 이름을 확인하는지 먼저 구분하세요

시스템 DNS, 브라우저 보안 DNS, 프록시 코어 DNS, 원격 노드의 이름 확인이 동시에 작동할 수 있습니다. 웹사이트가 열리지 않으면 로그에서 도메인 이름 확인에 실패했는지, 확인은 되었지만 연결이 시간 초과되었는지 먼저 살펴보세요. Android의 ‘비공개 DNS’와 제조사별 네트워크 설정은 DNS 경로에 영향을 줄 수 있습니다. 기존 설정을 기록한 뒤 비교를 위해 일시적으로 조정하고, DNS 항목을 한꺼번에 바꾸지 마세요.

기본 연결 확인 후 TUN 활성화

시스템 프록시를 따르지 않는 프로그램의 트래픽까지 처리해야 할 때만 데스크톱 TUN을 테스트하세요. 활성화 전에는 기존 VPN, 가상 네트워크 어댑터, DNS 설정을 기록해 두세요. 활성화 후에는 코어 로그, 기본 경로, 연결 기록을 확인하세요. 시스템 프록시는 정상인데 TUN을 켜자마자 인터넷이 끊긴다면 클라이언트를 재설치하기보다 먼저 TUN을 끄고 권한, 라우팅 충돌, DNS 처리 문제를 살펴보세요.

7. 설치 후 최종 점검과 종료 확인

첫 설정을 마친 뒤 ‘연결됨’ 표시만 확인해서는 충분하지 않습니다. 아래 항목을 하나씩 점검하면 재부팅, 네트워크 변경, 구독 업데이트 후 같은 문제를 다시 확인하는 일을 줄일 수 있습니다.

설정 점검: 현재 설정 이름과 업데이트 시간이 명확하고 로그에 반복되는 파싱 오류가 없는지 확인하세요. 필요한 정책 그룹에 사용할 수 있는 노드가 있어야 합니다.
트래픽 점검: 새 웹 요청이 연결 기록에 표시되는지, 직접 연결되거나 프록시를 사용하는 이유를 설명할 수 있는지 확인하세요.
종료 점검: 클라이언트를 닫기 전에 시스템 프록시를 끄거나 정상 종료 절차를 사용하고 일반 네트워크가 계속 작동하는지 확인하세요. Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시 설정이 남아 있는지 확인할 수 있습니다.
재시작 점검: 클라이언트를 다시 시작한 뒤에도 설정이 선택되어 있는지 확인하세요. 자동 시작을 설정했다면 다른 네트워크 도구와 동시에 실행되지 않는지도 확인하세요.
모바일 네트워크 점검: Android에서 Wi-Fi와 모바일 데이터 간 전환 후 다시 테스트하고, 화면을 잠근 뒤에도 백그라운드 연결이 유지되는지 확인하세요.
문의에 필요한 정보: 운영체제, 클라이언트와 코어 버전, 구체적인 오류 메시지, 재현 단계를 기록하세요. 로그는 필요한 부분만 공유하고 구독 토큰, 비밀번호, 개인 주소는 가리세요.

문제가 생기면 정상 작동하는 최소한의 설정을 우선 유지하세요. 설정 하나, 노드 하나, 트래픽 처리 방식 하나씩 확인한 뒤 자동 업데이트, TUN, 사용자 지정 규칙을 추가하세요. 문제를 쉽게 찾을 수 있고 설정이 바뀌어도 검증된 상태로 빠르게 되돌릴 수 있습니다.