Clash 처음 설치 설정 방법: 운영체제별 초기 설정과 자주 발생하는 오류

첫 설정에서 구분해야 할 네 가지 단계

Clash 클라이언트를 설치한 뒤 네트워크가 예상대로 작동하는지는 특정 스위치 하나가 아니라 설정, 정책, 트래픽 진입 경로, 시스템 권한이라는 네 단계에 의해 결정됩니다. 설정에는 노드, 정책 그룹, 규칙, DNS 매개변수가 포함됩니다. 정책은 현재 사용할 노드나 출구를 정하고, 트래픽 진입 경로는 어떤 앱의 연결을 Clash로 보낼지 결정합니다. 시스템 권한은 클라이언트가 프록시 설정을 변경하거나 가상 네트워크 인터페이스를 만들고 백그라운드에서 계속 실행될 수 있는지를 좌우합니다.

처음 사용할 때는 정해진 순서대로 진행하는 것이 좋습니다. 먼저 클라이언트가 운영체제와 호환되는지 확인하고, 실행 후 권한 요청을 처리합니다. 그다음 구독이나 로컬 설정을 가져와 프록시 모드와 정책 그룹을 선택한 뒤 마지막에 시스템 프록시 또는 TUN을 켭니다. 이렇게 하면 단계별 확인 지점이 분명해집니다. 가져온 뒤 정책 그룹이 없다면 설정을 확인하고, 정책 그룹은 있지만 브라우저가 프록시를 사용하지 않으면 시스템 프록시를 확인해야 합니다. 브라우저는 정상인데 게임이나 명령줄 도구만 작동하지 않는다면 해당 프로그램이 시스템 프록시를 우회하는지 살펴보고 TUN이 필요한지 판단합니다.

실행 전 운영체제 버전, 설치 파일, 기존 프록시 상태 확인

클라이언트를 다운로드할 때는 먼저 운영체제와 프로세서 아키텍처에 맞는 파일을 선택해야 합니다. Windows 기기는 주로 x64와 ARM64로 나뉘며, 최근 Intel 또는 AMD 프로세서가 탑재된 PC는 대체로 x64를 사용하고 Qualcomm 같은 ARM 프로세서 기반 기기는 ARM64가 필요할 수 있습니다. macOS는 Apple Silicon과 Intel 프로세서를 구분해야 합니다. 일부 클라이언트는 유니버설 설치 파일을 제공하지만 아키텍처별로 따로 배포하기도 합니다. Android 설치 파일은 arm64-v8a, armeabi-v7a, x86_64 등으로 나뉠 수 있습니다. 아키텍처를 잘못 선택하면 설치 프로그램이 실행되지 않거나 호환되지 않는다는 안내가 표시되고, 설치 후에도 코어가 작동하지 않을 수 있습니다.

처음 실행하기 전에는 기기에 다른 프록시, VPN, 네트워크 필터링 도구 또는 이전 시스템 프록시 주소가 남아 있는지도 확인해야 합니다. 데스크톱 운영체제에서는 일반적으로 하나의 프로그램만 동일한 시스템 프록시 설정을 안정적으로 관리할 수 있으며, 모바일 운영체제에서도 보통 한 번에 하나의 VPN 유형 연결만 유지할 수 있습니다. 기존 도구가 가상 네트워크 어댑터, VPN 연결 권한 또는 로컬 수신 포트를 계속 점유하면 Clash에서 포트 충돌, 네트워크 인터페이스 생성 실패, 스위치가 자동으로 꺼지는 현상이 발생할 수 있습니다.

기존 클라이언트를 종료한 뒤에는 창이 사라졌는지만 보지 말고 백그라운드 프로세스까지 종료됐는지 확인하고 시스템 프록시가 원래대로 복구됐는지 점검해야 합니다. 대표적인 잔여 상태는 시스템 프록시가 여전히 127.0.0.1의 이전 포트를 가리키지만 해당 프로그램은 이미 종료된 경우입니다. 이때 브라우저에는 프록시 서버 연결 실패가 바로 표시됩니다. 이전에 프록시 주소를 직접 입력했다면 해당 설정도 잠시 지운 뒤 새 Clash 클라이언트가 일괄 관리하도록 하세요.

처음 실행할 때 자주 표시되는 권한 요청

• Windows: 방화벽에서 네트워크 액세스 허용 여부를 물을 수 있으며, 서비스 모드를 설치하거나 TUN을 활성화할 때 관리자 권한이 필요할 수 있습니다.
• macOS: 시스템 네트워크 설정을 변경하거나 보조 서비스 또는 네트워크 확장 프로그램을 설치할 때 관리자 승인을 요청합니다.
• Android: 프록시가 트래픽을 처리하도록 설정하면 VPN 연결 권한 요청이 표시되며, 일부 기기에서는 백그라운드 실행이나 배터리 관리 설정도 안내합니다.
• iOS 및 iPadOS: 호환 클라이언트에서 처음 로컬 VPN 구성을 만들 때 VPN 구성 추가를 승인해야 합니다.

각 권한은 서로 다른 기능에 대응합니다. 방화벽 액세스를 허용했다고 해서 시스템 프록시가 활성화되는 것은 아니며, 관리자 권한을 부여했다고 모든 연결이 자동으로 TUN으로 들어가는 것도 아닙니다. 현재 수행하는 작업에 맞춰 요청을 처리하면 되며, 설정을 가져오기도 전에 모든 고급 옵션을 한꺼번에 켤 필요는 없습니다.

구독 또는 로컬 설정을 가져오고 내용 확인하기

Clash에서 사용할 설정은 일반적으로 구독 주소, 로컬 YAML 파일 또는 클라이언트가 지원하는 설정 프로바이더를 통해 제공됩니다. 구독 주소는 일반 웹페이지 링크가 아니며, 개인 설정을 가져오기 위한 식별 정보가 포함되는 경우가 많으므로 계정 인증 정보처럼 안전하게 보관해야 합니다. 전체 주소를 공개 스크린샷이나 커뮤니티 게시물, 공동 문서에 붙여 넣지 마세요. 문제를 확인해야 할 때는 도메인 뒤의 토큰, 매개변수, 경로를 가리고 오류 메시지와 클라이언트 상태만 공유하는 것이 좋습니다.

URL로 가져올 때는 먼저 전체 구독 주소를 복사한 다음 클라이언트의 설정 또는 구독 화면에서 ‘URL에서 가져오기’, ‘새 구독 추가’처럼 비슷한 의미의 메뉴를 선택합니다. 클라이언트마다 메뉴 이름은 다르지만 성공적으로 가져오면 일반적으로 설정 이름, 업데이트 시간, 업데이트 버튼이 나타납니다. 이어서 해당 설정을 현재 설정으로 지정해야 합니다. 일부 클라이언트는 가져온 설정을 자동으로 활성화하지 않으므로 기본 설정이 계속 선택되어 있으면 프록시 화면이 비어 있을 수 있습니다.

파일로 가져올 때는 YAML 텍스트 구조와 올바른 들여쓰기를 유지해야 합니다. YAML은 들여쓰기에 민감하므로 전각 콜론, 탭 문자 또는 잘못된 계층 구조가 있으면 파싱에 실패할 수 있습니다. 신뢰할 수 있는 출처에서 받은 설정이라면 형식을 자동으로 바꾸는 문서 편집기로 열어 다시 저장하지 말고 원본 파일을 바로 가져오는 것이 좋습니다. 클라이언트에서 파싱 오류가 표시되면 정확한 줄 번호와 필드명을 기록하세요. 가져오기 버튼만 반복해서 누른다고 구문 오류가 해결되지는 않습니다.

가져온 뒤 확인할 세 가지

1. 설정이 활성화됐는지: 설정 목록의 선택 표시가 예제 설정이나 이전 설정이 아니라 방금 가져온 항목에 있어야 합니다.
2. 정책 그룹이 표시되는지: 프록시 화면에 노드 선택, 자동 선택, 장애 조치, 직접 연결 같은 그룹이 표시되어야 합니다. 실제 이름은 설정 작성자가 정하므로 반드시 정해진 영문 이름으로 표시되지는 않습니다.
3. 규칙과 DNS를 불러왔는지: 클라이언트 로그에 규칙 프로바이더 다운로드 실패, DNS 수신 실패, 지원되지 않는 설정 필드 같은 오류가 계속 나타나면 안 됩니다.

Mihomo라고도 하는 Clash Meta는 초기 Clash 코어보다 더 다양한 설정 기능을 지원합니다. 여기에는 폭넓은 규칙 유형, 프록시 프로토콜, DNS 동작, TUN 매개변수 등이 포함됩니다. 설정에 현재 코어가 인식하지 못하는 필드가 있으면 클라이언트가 불러오기를 거부하거나 일부 내용을 무시할 수 있습니다. 따라서 ‘구독을 다운로드할 수 있는지’와 ‘코어가 설정을 파싱할 수 있는지’는 별도로 확인해야 합니다. 호환성 오류가 표시되면 먼저 클라이언트에서 사용하는 코어의 종류와 버전을 확인한 뒤 설정 형식이 이에 맞는지 판단하세요.

규칙, 전체, 직접 연결 모드 선택 방법

설정 가져오기를 마쳤다면 첫 테스트에는 규칙 모드를 사용하는 것이 좋습니다. 규칙 모드는 설정에 있는 규칙 목록을 위에서 아래로 대조하며, 처음 일치한 규칙이 트래픽의 경로를 결정합니다. 일반적인 처리 결과는 직접 연결, 프록시, 차단 또는 특정 정책 그룹으로 넘겨 추가 선택하는 방식입니다. 이를 통해 로컬 서비스, 내부 네트워크 주소, 직접 연결에 적합한 사이트는 기존 경로를 유지하고 프록시가 필요한 대상만 지정된 정책으로 보낼 수 있습니다.

전체 모드는 일반적으로 처리할 수 있는 연결 대부분을 전체 정책 그룹으로 보냅니다. 짧은 비교 테스트에 적합합니다. 예를 들어 규칙 모드에서 접속되지 않던 사이트가 전체 모드에서는 열린다면 노드 자체보다 규칙 일치, DNS 라우팅 또는 정책 그룹 선택에 문제가 있을 수 있습니다. 다만 전체 모드만으로 모든 문제를 배제할 수는 없습니다. 내부 네트워크 연결, 시스템 서비스, 클라이언트 자체 트래픽에는 여전히 우회 규칙이나 구현 방식이 영향을 줄 수 있습니다.

직접 연결 모드는 Clash로 들어온 연결을 대상에 직접 연결하며, 프록시 경로 때문에 문제가 발생하는지 확인할 때 주로 사용합니다. 직접 연결 모드가 클라이언트를 완전히 종료한 상태와 같지는 않습니다. 시스템 프록시나 TUN이 계속 켜져 있으면 연결은 여전히 코어를 거치고 최종 정책만 직접 연결을 선택합니다. 테스트가 끝나 더 이상 사용하지 않을 경우 트래픽 전달 스위치를 꺼서 ‘직접 연결 모드’와 ‘프록시 비활성화’를 혼동하지 않도록 하세요.

노드와 정책 그룹 선택 순서

먼저 가장 바깥쪽의 수동 선택 그룹을 열어 사용 가능한 노드 또는 자동 정책 그룹이 선택됐는지 확인합니다. 설정에 url-test, fallback 같은 자동 그룹이 있다면 상태 확인이 한 차례 끝날 때까지 기다린 뒤 각 노드의 상태를 살펴보세요. 지연 시간 수치는 특정 테스트 주소를 특정 시점에 측정한 결과일 뿐, 웹페이지 로딩이나 동영상 전송, 장시간 연결의 실제 품질을 그대로 나타내지는 않습니다. 첫 설정의 목표는 수치가 가장 낮은 항목만 고르는 것이 아니라 기본 접속이 가능하고 안정적인 정책을 찾는 것입니다.

시스템 프록시와 TUN 모드 활성화 순서

데스크톱에서 가장 이해하기 쉬운 트래픽 진입 방식은 시스템 프록시입니다. 활성화하면 클라이언트가 운영체제의 HTTP 또는 HTTPS 프록시 설정을 루프백 주소의 혼합 포트 같은 로컬 수신 주소로 지정합니다. 브라우저와 시스템 프록시를 따르는 앱은 요청을 Clash로 보냅니다. 스위치 상태가 명확하고 확인 범위가 좁다는 장점이 있어 Windows와 macOS에서 처음 작동 여부를 확인할 때 적합합니다.

시스템 프록시가 모든 프로그램에 적용되는 것은 아닙니다. 일부 명령줄 도구는 환경 변수를 별도로 설정해야 하고, 일부 게임이나 UDP 기반 프로그램은 시스템 HTTP 프록시를 사용하지 않습니다. 자체적으로 네트워크 스택을 관리하는 앱도 있습니다. ‘브라우저는 접속되는데 특정 앱만 작동하지 않는’ 경우에는 먼저 Clash의 연결 화면에서 해당 앱의 기록이 생성되는지 확인하세요. 기록이 전혀 없다면 대체로 트래픽이 아직 코어에 들어오지 않은 상태이므로 노드를 계속 바꿔도 결과는 달라지지 않습니다.

TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 받아 시스템 프록시를 따르지 않는 많은 프로그램과 다양한 UDP 환경을 처리할 수 있습니다. 그 대신 라우팅, DNS 하이재킹, 인터페이스 우선순위, 관리자 권한 같은 변수가 추가됩니다. 처음 설치할 때는 시스템 프록시로 기본 작동을 확인한 뒤 실제 앱의 필요에 따라 TUN을 켜는 것이 좋습니다. 처음부터 시스템 프록시, TUN, 사용자 지정 DNS, 여러 네트워크 필터링 프로그램을 동시에 켜면 문제가 생겼을 때 어느 단계가 원인인지 판단하기 어렵습니다.

모바일용 호환 클라이언트는 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 처리합니다. 작동 방식은 데스크톱의 시스템 프록시 스위치보다 가상 네트워크 인터페이스에 가깝습니다. Android 또는 iOS 상태 표시줄에 VPN 아이콘이 나타나는 것은 가상 인터페이스가 생성됐다는 의미일 뿐입니다. 현재 설정이 활성화됐는지, 정책 그룹이 선택됐는지, 코어에서 오류가 계속 발생하지 않는지도 확인해야 합니다. 모바일 운영체제에서 Wi-Fi와 모바일 데이터를 전환하면 연결이 잠시 재구성될 수 있으므로 네트워크가 안정된 뒤 테스트하세요.

Windows, macOS, Android, iOS 초기 설정 차이

Windows: 서비스 모드, 방화벽, 남아 있는 시스템 프록시 확인

Windows 클라이언트에서 시스템 프록시만 사용한다면 일반적으로 모든 작업을 관리자 권한으로 실행할 필요는 없습니다. TUN 활성화, 보조 서비스 설치, 하위 네트워크 인터페이스 변경 시에만 권한 상승이 필요할 수 있습니다. TUN 스위치가 계속 켜져 있지 않다면 서비스 구성 요소가 정상적으로 설치됐는지, 관련 가상 네트워크 어댑터가 보안 정책에 의해 차단됐는지, 다른 VPN이 실행 중인지 확인하세요. 모든 웹사이트에 접속할 수 없다면 먼저 Clash의 시스템 프록시를 끈 다음 Windows 프록시 설정에 수동 프록시가 남아 있지 않은지 살펴보세요.

macOS: 네트워크 확장 프로그램과 보조 서비스 권한 확인

macOS에서 네트워크 확장 프로그램, 시스템 프록시 보조 프로그램 또는 TUN 구성 요소를 설치하면 시스템 승인 창이 표시될 수 있습니다. 승인 후에도 기능이 작동하지 않으면 시스템 설정의 네트워크, 로그인 항목 또는 확장 프로그램 관련 화면에서 구성 요소의 상태를 확인하세요. Apple Silicon 기기에서는 해당 아키텍처용 또는 유니버설 버전을 사용해야 합니다. 클라이언트에 수신 포트가 정상이라고 표시되는데 브라우저 연결 기록이 없다면 현재 네트워크 서비스의 프록시 설정을 다른 도구가 덮어썼는지 확인하세요.

Android: VPN 충돌과 배터리 관리 확인

Android에서 처음 프록시를 시작할 때는 VPN 연결 요청에 동의해야 합니다. 동일한 사용자 환경에서는 보통 VPN 하나만 활성화할 수 있으므로 기존 회사용 VPN, 필터링 도구 또는 다른 프록시 클라이언트와 충돌할 수 있습니다. 일부 제조사 기기는 화면이 꺼지면 백그라운드 활동을 제한합니다. 앱을 열어 둔 동안에는 정상 작동하지만 화면을 잠근 뒤 일정 시간이 지나면 연결이 끊기는 식으로 나타납니다. 초기 설정 단계에서는 기본 배터리 정책을 유지한 채 짧게 테스트해 기본 연결을 확인한 후, 필요에 따라 백그라운드 실행과 절전 제한을 조정하세요.

iOS 및 iPadOS: VPN 구성과 주문형 연결 확인

Clash 설정과 호환되는 클라이언트는 VPN 구성 추가를 요청하며, 시스템에서 기기 암호나 생체 인증 또는 명시적인 승인을 요구할 수 있습니다. 연결 버튼이 즉시 꺼짐 상태로 돌아가면 클라이언트 로그를 확인하고 조직의 기기 관리 정책이 VPN을 제한하고 있지 않은지 살펴보세요. 주문형 연결, 모바일 데이터 권한, 저데이터 모드는 백그라운드 연결 동작에 영향을 줄 수 있습니다. 첫 테스트는 안정적인 Wi-Fi에서 마친 뒤 모바일 데이터로 전환해 확인하는 것이 좋습니다.

연결 기록으로 첫 작동 확인하기

초기 설정 확인을 ‘웹페이지가 열리는지’에만 의존해서는 안 됩니다. 대상 앱, 연결 기록, 적용된 규칙, 정책 출구를 함께 확인하는 편이 효과적입니다. 먼저 관련 없는 앱을 종료하고 안정적인 테스트 페이지를 연 다음 Clash 연결 목록에 새 기록이 추가되는지 확인하세요. 기록에는 일반적으로 대상 도메인 또는 IP, 연결 유형, 적용된 규칙, 사용한 정책 그룹, 최종 노드가 표시됩니다. 클라이언트마다 필드 표시는 조금씩 다르지만 판단 과정은 같습니다.

1. 규칙 모드에서 확실히 작동하는 정책을 선택하고 이전 연결 기록을 지우거나 기록을 일시 중지합니다.
2. 대상 웹페이지를 열고 백그라운드 업데이트 요청만이 아니라 해당 도메인이 연결 목록에 표시되는지 확인합니다.
3. 연결에 적용된 규칙과 최종 정책을 확인해 직접 연결, 프록시, 차단 중 어떤 방식으로 처리됐는지 판단합니다.
4. 정책을 전환한 뒤 연결을 새로 만듭니다. 브라우저 캐시나 기존 장시간 연결이 이전 경로를 계속 사용할 수 있으므로 필요하면 페이지를 닫고 다시 시도하세요.
5. 직접 연결될 것으로 예상되는 사이트와 프록시를 사용할 것으로 예상되는 대상을 각각 테스트해 두 경로가 모두 작동하는지 확인합니다.

DNS 문제는 도메인으로 접속할 수 없지만 알려진 IP에 직접 연결하면 동작이 달라지는 형태로 자주 나타납니다. 노드 문제는 연결이 프록시 정책에 들어간 뒤 시간 초과가 발생할 수 있으며, 규칙 문제는 대상이 예상과 다른 정책에 배정된 것으로 로그에 표시됩니다. 연결 목록에 대상 요청이 전혀 보이지 않는다면 DNS부터 변경하지 말고 트래픽 진입 경로를 다시 확인하세요. 이 순서대로 살펴보면 ‘접속 불가’ 문제를 트래픽 전달, 이름 해석, 규칙 일치, 출구 연결의 네 단계로 나눌 수 있습니다.

처음 설치할 때 자주 발생하는 오류와 해결 방법

첫 설정 완료 체크리스트

다음 항목을 모두 확인해야 이후 문제 해결이 쉬운 기본 환경이 갖춰집니다. 한 번에 변수 하나만 변경하고 정상적으로 시작되는 설정을 보관하면 규칙, DNS, TUN, 시스템 권한이 서로 간섭하는 상황을 크게 줄일 수 있습니다.

• 설치 파일이 운영체제 및 프로세서 아키텍처와 일치하며 클라이언트가 안정적으로 실행됩니다.
• 기존 프록시 또는 VPN이 종료됐고 시스템에 작동하지 않는 로컬 포트를 가리키는 프록시 설정이 없습니다.
• 구독 또는 로컬 설정을 성공적으로 가져왔고 현재 설정으로 명확히 지정했습니다.
• 프록시 화면에 정책 그룹이 표시되고 현재 사용하는 그룹에 선택된 항목이 명확히 있습니다.
• 첫 테스트에 규칙 모드를 사용했고 전체 모드와 직접 연결 모드의 용도를 구분할 수 있습니다.
• 데스크톱에서는 시스템 프록시를 먼저 확인했고 모바일에서는 VPN 구성 권한을 승인했습니다.
• 앱이 시스템 프록시를 따르지 않을 때만 TUN을 추가로 활성화하고 점검합니다.
• 연결 기록에서 테스트 요청, 적용된 규칙, 정책 그룹, 최종 출구를 확인할 수 있습니다.
• 구독 업데이트 방식을 확인했고 장기 사용자 지정 항목은 오버라이드 또는 병합 계층에서 처리합니다.
• 클라이언트를 종료하기 전에 트래픽 전달을 먼저 꺼 시스템 프록시나 가상 인터페이스가 남지 않도록 합니다.

첫 설정의 핵심은 모든 기능을 한꺼번에 켜는 것이 아니라 반복해서 확인할 수 있는 경로를 만드는 것입니다. 설정을 불러오고, 정책을 선택하고, 트래픽이 들어오고, 규칙이 일치하며, 출구가 연결되는지 차례로 확인해야 합니다. 이후 구독 업데이트 실패, 특정 앱 미작동, TUN 시작 오류가 발생해도 이 경로를 따라가면 문제가 생긴 단계를 구체적으로 찾을 수 있습니다.