Clash 빠른 시작:
구독 가져오기와 연결 확인
‘구성 가져오기 → 모드 선택 → 연결 켜기 → 요청 확인’ 순서로 진행하세요. 클라이언트를 설치하고 호환 구독을 준비했다면 약 10분이면 첫 설정을 마칠 수 있습니다.
시작하기 전에 서비스 제공자가 전달한 Clash 호환 구독 링크나 사용 가능한 YAML 구성 파일을 준비하세요. 클라이언트는 구성을 읽고 트래픽을 분기하며 프록시 연결을 설정합니다. 클라이언트만 설치한다고 구독이 생성되거나 노드가 자동으로 제공되지는 않습니다. 서버 주소만 있고 프로토콜, 포트, 인증 정보가 없다면 연결에 필요한 정보가 부족한 경우가 많습니다.
구독 링크에는 접속 정보가 포함될 수 있으므로 공개 댓글, 온라인 변환 페이지, 스크린샷에 올리지 마세요. 다른 사람에게 문제를 설명할 때는 링크 매개변수, 노드 비밀번호, 개인 정보를 먼저 가리세요. 아래 예시는 설정 방법만 설명하며 실제로 사용할 수 있는 프록시 서비스는 포함하지 않습니다.
구독을 가져와 현재 구성으로 설정
클라이언트를 열고 ‘구성’, ‘Profiles’ 또는 ‘구독’ 페이지로 이동합니다. ‘새로 만들기’, ‘추가’ 또는 ‘URL에서 가져오기’를 선택한 다음 전체 구독 링크를 입력란에 붙여 넣으세요. ‘일상용 구성’처럼 알아보기 쉬운 이름을 지정해도 됩니다. 이름은 목록 표시만 바꾸며 연결에는 영향을 주지 않습니다. 입력란 앞뒤에 공백이나 줄바꿈, 메신저에서 복사한 문장 부호가 들어가지 않았는지 확인한 뒤 가져오기 또는 다운로드를 누릅니다.
다운로드와 파싱이 끝날 때까지 기다립니다. 성공하면 목록에 구성 이름, 출처 또는 업데이트 시간이 표시되는 경우가 많습니다. 새 항목이 보인다고 해서 구성이 활성화된 것은 아닙니다. 해당 항목을 눌러 ‘활성화’, ‘이 구성 사용’ 또는 이에 해당하는 동작을 선택해 현재 구성으로 지정하세요. 일부 클라이언트는 선택 표시로 현재 항목을 나타내고, 다른 클라이언트는 개요 페이지에 사용 중인 이름을 표시합니다.
가져온 뒤에는 연결하기 전에 프록시 그룹부터 확인
‘프록시’ 페이지로 이동해 Proxy, 노드 선택, 자동 선택처럼 구성에 정의된 정책 그룹이 있는지 확인합니다. 그룹 이름은 구성 작성자가 정하므로 이 페이지의 예와 다를 수 있습니다. 그룹 하나를 펼쳤을 때 노드나 다른 하위 그룹이 보여야 합니다. 페이지가 비어 있거나 직접 연결 항목만 보이거나 이전 구성의 그룹이 계속 표시되면 시스템 프록시를 반복해서 켜고 끄지 말고 구성 페이지에서 현재 선택 항목을 확인하세요.
로컬 파일을 받았다면 ‘파일에서 가져오기’ 또는 ‘구성 가져오기’를 선택하고 파일 선택기에서 해당 .yaml 또는 .yml 파일을 골라 같은 방식으로 활성화하세요. 로컬 파일은 가져온다고 원격 구독으로 바뀌지 않습니다. 이후 노드가 변경되면 다시 가져오거나 구성에 선언된 원격 제공자 업데이트 기능을 사용해야 합니다.
다운로드 오류와 파싱 오류는 따로 해결
‘다운로드 시간 초과’, ‘구독을 가져올 수 없음’은 보통 구성을 받기 전에 발생합니다. 기기의 네트워크, 링크 유효 기간, 서비스 제공자 상태부터 확인하세요. 특정 네트워크에서 접속할 수 없는 구독 주소라면 서비스 제공자가 안내한 유효한 가져오기 방법을 사용합니다. 인증 정보가 포함된 링크를 모르는 변환 서비스에 넘기지 마세요. 브라우저에서 페이지가 표시되지 않는다는 이유만으로 구독이 만료됐다고 단정할 수도 없습니다. 구독 API는 특정 요청 방식이 필요할 수 있습니다.
‘파싱 실패’, ‘지원하지 않는 필드’는 클라이언트가 콘텐츠를 받았지만 현재 형식으로 읽지 못했다는 뜻입니다. 웹페이지 주소를 가져왔거나 로그인 페이지를 받았거나 구독 출력 형식이 코어와 호환되지 않는 경우가 흔합니다. 먼저 서비스 제공자에게 Clash 또는 mihomo 호환 형식인지 확인하세요. 들여쓰기나 필드 문제라면 YAML 가이드를 참고하면 됩니다. 첫 연결을 위해 파일 전체를 직접 다시 작성할 필요는 없습니다.
구성이 활성화되고 프록시 그룹을 펼칠 수 있는지 확인한 뒤 다음 단계로 넘어가세요. 원격 구독을 업데이트하면 직접 편집한 노드와 규칙이 덮어써질 수 있으므로 첫 설정에서는 원본을 유지하세요. 장기적으로 규칙을 직접 지정하려면 클라이언트의 오버라이드 또는 병합 기능을 익히면 됩니다. 구독 출처와 업데이트 문제는 구독 관련 자주 묻는 질문에서 확인하세요.
규칙 모드를 선택하고 프록시 출구 지정
‘프록시’ 또는 ‘개요’ 페이지에서 모드를 ‘규칙 / Rule’로 설정합니다. 규칙 모드는 현재 구성의 규칙 순서에 따라 요청을 처리합니다. 대상에 따라 직접 연결하거나 프록시 정책 그룹으로 보낼 수 있습니다. 처음에는 구독에 포함된 규칙을 그대로 사용하세요. 전체 연결 경로가 작동하는지 확인한 다음 필요한 트래픽 분기 규칙을 추가하면 됩니다.
모드와 노드는 서로 다른 설정입니다. 모드는 규칙에 따라 요청을 처리할지 정하고, 정책 그룹은 프록시 규칙에 일치한 요청에 어떤 출구를 사용할지 정합니다. 규칙 모드를 유지한 채 기본 프록시 그룹을 펼쳐 사용 가능한 노드를 선택하세요. 그룹에 ‘자동 선택’이나 ‘장애 조치’가 있다면 해당 하위 그룹을 골라도 됩니다. 일부 그룹은 기본값으로 DIRECT가 선택될 수 있으며, 이 경우 해당 그룹은 직접 연결을 사용합니다.
실제로 사용하는 그룹에서 선택했는지 확인
하나의 구성에 웹, 미디어, 메시지 등 여러 정책 그룹이 들어 있을 수 있으며, 한 그룹만 바꿔도 모든 요청에 적용되는 것은 아닙니다. 다른 그룹에서 참조하는 기본 프록시 그룹을 찾거나 구독 안내에 따라 기본 출구를 선택하세요. 그룹 간 참조 관계를 파악하기 어렵다면 임의로 하나씩 수정하지 마세요. 나중에 연결 기록에서 대상 요청이 실제로 거친 정책 경로를 확인한 뒤 해당 그룹을 조정할 수 있습니다.
클라이언트의 연결 테스트는 명백히 사용할 수 없는 항목을 걸러내는 데 도움이 됩니다. 다만 테스트 성공은 특정 테스트 요청에 응답이 왔다는 뜻일 뿐, 모든 대상 사이트에 접속할 수 있다는 보장은 아닙니다. 테스트를 통과한 출구를 하나 선택한 뒤 실제로 이용할 페이지에서 확인하세요. 테스트를 연달아 실행하거나 노드를 자주 바꾸면 원인을 찾기 어려워집니다. 한 번에 하나만 변경하고 결과를 비교할 수 있도록 기록하세요.
규칙·글로벌·직접 연결의 사용 범위
‘글로벌 / Global’ 모드에서는 코어에 들어온 트래픽이 모두 글로벌 정책에 따라 처리됩니다. 기기의 모든 앱 트래픽을 자동으로 가로채는 기능은 아니며 TUN을 켜는 것과도 다릅니다. 트래픽 분기 규칙이 문제인지 확인하려면 잠시 글로벌 모드로 전환하고 글로벌 정책에서 사용 가능한 노드를 선택하세요. 테스트가 끝나면 규칙 모드로 돌아가 원래 직접 연결할 요청까지 프록시를 경유하지 않도록 합니다.
‘직접 연결 / Direct’는 코어에 들어온 트래픽을 대상에 바로 연결한다는 뜻입니다. 클라이언트를 끄거나 운영체제의 프록시 설정을 해제하는 것은 아닙니다. 프록시 연결 자체를 완전히 중지하려면 모드를 직접 연결로 바꾸는 대신 4단계에 따라 시스템 프록시를 끄거나 모바일 연결을 해제하세요.
‘노드’, ‘정책 그룹’, ‘규칙’ 같은 용어가 익숙하지 않다면 용어 설명을 참고하세요. rules를 작성하거나 일치 순서를 바꾸고 원격 규칙 세트를 설정할 때는 YAML 가이드를 확인하면 됩니다. 이러한 작업은 첫 연결에 필요한 단계가 아닙니다.
시스템 프록시 또는 모바일 연결 켜기
클라이언트 개요 페이지로 돌아가 코어에 시작 오류가 없는지 확인한 다음 트래픽 연결을 켭니다. 데스크톱에서는 ‘시스템 프록시’, 모바일에서는 ‘연결’ 또는 시작 버튼을 사용합니다. 첫 연결에서는 한 가지 방식을 선택하세요. 다른 VPN이나 프록시 클라이언트, 브라우저 자체 프록시 설정을 동시에 켜면 여러 도구가 같은 시스템 설정을 덮어쓸 수 있습니다.
데스크톱: 시스템 프록시부터 켜기
Windows, macOS 또는 Linux 클라이언트에서 ‘시스템 프록시’를 찾아 켭니다. 일부 클라이언트는 보조 서비스 설치나 네트워크 설정 변경 권한을 요청할 수 있습니다. 운영체제의 권한 창에서 허용하세요. 현재 사용하는 클라이언트가 요청한 것인지 확인해야 합니다. 필요한 권한을 거부했다면 화면의 스위치가 켜져 있어도 시스템 설정에 반영되지 않았을 수 있으니 시스템 네트워크 프록시 페이지에서 확인하세요.
시스템 프록시는 보통 시스템 설정을 따르는 앱을 로컬 프록시 포트에 연결합니다. 대부분의 브라우저는 이 설정을 사용할 수 있지만 앱마다 구현이 다릅니다. 명령줄 도구, 게임, 자체 네트워크 스택을 사용하는 프로그램은 시스템 프록시를 따르지 않을 수 있습니다. 먼저 브라우저에서 확인하고 특정 프로그램이 프록시를 사용하지 않는다고 해서 곧바로 노드 문제로 판단하지 마세요. 터미널에서 별도로 확인하는 방법은 다음 단계에 안내합니다.
클라이언트에서 포트 충돌을 알리면 먼저 해당 포트를 사용 중일 수 있는 다른 프록시 도구를 종료한 뒤 현재 코어를 다시 시작하세요. 포트를 변경해야 한다면 설정에서 HTTP 또는 혼합 포트의 실제 값을 확인하고, 프록시 주소를 직접 입력한 앱에도 같은 값을 적용합니다. 예시 포트를 그대로 복사해 설정이 맞을 거라고 가정하지 말고 현재 클라이언트의 포트 값을 기준으로 하세요.
Android 및 iOS: 시스템 VPN 권한 확인
모바일에서 현재 구성을 선택한 뒤 연결 버튼을 누릅니다. 처음 실행할 때 시스템에서 VPN 연결 생성 또는 VPN 구성 추가를 허용할지 묻는 경우가 많습니다. 승인한 뒤 클라이언트로 돌아와 연결 상태를 확인하세요. 이 VPN 권한은 시스템 트래픽 연결 경로를 만드는 데 필요할 뿐, 구독이 자동으로 사용 가능해진다는 뜻은 아닙니다. 유효한 구성, 사용 가능한 출구, 권한 승인이 모두 필요합니다.
버튼을 켜자마자 다시 꺼지면 먼저 클라이언트 오류 메시지를 확인한 뒤 다른 VPN 앱이 연결을 사용 중인지 살펴보세요. Android에서 앱별 프록시를 사용한다면 테스트할 브라우저가 연결 대상에 포함되어 있는지 확인하고, 시스템이 백그라운드 실행을 제한하는지도 점검합니다. iOS에서는 선택한 구성이 실제로 시작되었는지 확인하세요. 오류 원인을 살펴보지 않고 앱을 반복해서 삭제하지 마세요.
필요할 때까지 TUN은 나중에 설정
브라우저는 정상적으로 작동하지만 대상 프로그램이 시스템 프록시를 사용하지 않는다면 TUN을 알아볼 수 있습니다. TUN은 가상 네트워크 인터페이스로 트래픽을 연결하며 서비스 권한, 라우팅, DNS 설정이 추가로 필요할 수 있습니다. 스위치를 켠다고 모든 프로그램의 트래픽이 처리되는 것은 아닙니다. 처음에는 시스템 프록시와 TUN을 함께 켤 필요가 없습니다. 먼저 확인 가능한 기본 연결을 만든 뒤 클라이언트 안내에 따라 기능을 하나씩 추가하세요.
회사 네트워크, 원격 데스크톱, 로컬 네트워크 기기는 특정 경로에 의존할 수 있으므로 TUN을 켜기 전에 기존 연결 정보를 보관하세요. DNS 또는 Fake-IP를 조정해야 한다면 DNS 설정 참고와 Fake-IP 안내를 각각 확인하세요. 연결을 켠 뒤에는 실제 요청을 확인해야 합니다. 스위치가 켜졌다는 이유만으로 설정을 끝내지 마세요.
브라우저·터미널 확인 및 연결 해제 후 복구
먼저 평소 직접 접속할 수 있는 페이지를 열어 기본 네트워크가 정상인지 확인한 뒤, 프록시가 필요한 대상 페이지를 엽니다. 브라우저 캐시만 확인하지 않도록 새 탭을 열거나 페이지를 새로고침하세요. 테스트하는 동안 같은 노드와 같은 모드를 유지해야 차이가 생겼을 때 어느 설정에서 비롯됐는지 판단할 수 있습니다.
연결 기록에서 트래픽 경로 확인
클라이언트의 ‘연결’ 또는 ‘Connections’ 페이지를 열고 브라우저에서 다시 접속한 뒤 대상 도메인을 찾습니다. 짧은 요청은 금방 끝날 수 있으므로 검색, 기록 또는 로그를 활용하세요. 클라이언트에 ‘실행 중’이라고 표시되는지만 보지 말고 대상, 일치한 규칙, 정책 경로를 확인해야 합니다. 해당 요청이 기록에 나타나야 요청이 코어에 들어갔음을 알 수 있습니다.
기록에 DIRECT가 표시되면 구성이 의도한 동작인지 먼저 확인하세요. 규칙 모드에서는 일부 사이트가 직접 연결될 수 있으므로 연결 실패가 아닙니다. 프록시를 사용해야 하는 대상이 직접 연결됐다면 일치한 규칙과 관련 정책 그룹을 점검하세요. 프록시 정책 경로가 표시되는데도 접속되지 않으면 노드 상태, 대상 서비스, 로그의 구체적인 오류를 확인하세요. DNS를 바로 바꿀 필요는 없습니다.
브라우저 요청을 전혀 찾을 수 없다면 시스템 프록시 설정이 적용됐는지, 브라우저가 별도 프록시 설정을 사용하는지, 확장 프로그램이 프록시 연결을 덮어쓰는지 먼저 확인하세요. 모바일에서는 테스트 앱이 연결 대상에 포함되어 있는지도 확인합니다. 요청이 클라이언트에 도달하지 않았을 수 있으므로 이 단계에서 노드를 바꿔도 보통 문제가 해결되지 않습니다.
터미널은 별도로 확인해야 합니다
명령줄 도구는 시스템 프록시 설정을 따르지 않을 수 있습니다. 클라이언트의 실제 혼합 포트가 7890이라면 아래 명령으로 한 번만 테스트할 수 있습니다. 포트가 다르면 설정 페이지에 표시된 값으로 명령의 포트를 바꾸세요. 이 명령은 해당 요청에만 HTTP 프록시를 지정하며 터미널 환경을 영구적으로 변경하지 않고 관리자 권한도 필요하지 않습니다.
curl --proxy http://127.0.0.1:7890 --head https://example.comexample.com은 명령 작성법을 설명하기 위한 예시 도메인이며 프록시 서비스가 아닙니다. 실제 대상 사이트를 확인하려면 방문하려는 HTTPS 주소로 바꾸고 클라이언트 연결 기록도 함께 확인하세요. 응답 헤더가 돌아왔다는 사실은 해당 주소가 이번 요청에 응답했다는 뜻입니다. 어떤 출구를 거쳤는지는 연결 기록의 정책 경로로 확인해야 합니다. 대상 사이트에 따라 응답 상태 코드는 다를 수 있습니다.
프록시를 명시한 명령은 성공하지만 터미널에서 명령을 바로 실행하면 실패한다면 구독 문제보다 터미널에 프록시 설정이 없는 경우가 많습니다. 사용 중인 도구의 문서에 따라 프록시 인수나 환경 변수를 설정하세요. 여러 셸의 시작 파일에 범용 명령을 그대로 추가하지 마세요. 도구, 포트 유형, 변수 적용 범위가 다르므로 필요한 사항을 먼저 확인해야 합니다.
순서대로 문제 범위 좁히기
브라우저에서 접속할 수 없다면 먼저 요청 기록이 있는지 확인하세요. 기록이 있으면 일치한 정책을 확인하고, 정책이 올바르면 사용 가능한 것으로 확인된 다른 노드를 선택합니다. 규칙 모드에서만 실패한다면 잠시 글로벌 모드로 바꿔 비교하고 글로벌 그룹에서 유효한 프록시가 선택됐는지 확인하세요. 글로벌 모드는 되지만 규칙 모드가 실패하면 규칙과 그룹 선택을 점검합니다. 두 모드 모두 실패하면 노드, 네트워크, 로그를 확인하세요.
모드, DNS, 포트, TUN을 한꺼번에 바꾸지 마세요. 한 번에 하나만 변경하고 같은 요청을 다시 실행해 결과를 기록해야 차이를 바탕으로 문제를 찾을 수 있습니다. 문제 유형별 자세한 안내는 자주 묻는 질문에서 확인하세요. 원인이 구성 필드로 좁혀졌다면 YAML 가이드에서 해당 항목을 살펴보세요.
마지막으로 연결 해제와 복구 확인
연결 확인이 끝나면 데스크톱에서는 먼저 시스템 프록시를 끈 뒤 클라이언트를 종료하고, 모바일에서는 연결을 해제합니다. 평소 직접 접속하는 페이지를 다시 열어 네트워크가 복구됐는지 확인하세요. 클라이언트를 종료한 뒤 브라우저가 인터넷에 연결되지 않으면 시스템에 로컬 프록시 주소가 남아 있는지 확인하고 수동 프록시 설정을 해제하세요. 다른 클라이언트로 바꾸기 전에도 이전 클라이언트의 트래픽 연결을 먼저 해제해야 합니다.
나중에 구독을 업데이트할 때는 올바른 구성을 사용 중인지 먼저 확인하고, 기존 정책 그룹과 선택 상태가 유지됐는지 살펴본 다음 같은 대상으로 다시 테스트하세요. 특정 클라이언트의 버튼 위치만 외우기보다 이 짧은 절차를 익혀 두면 기기를 옮기거나 문제를 찾을 때 도움이 됩니다.