Clash 사용 가이드

1단계: 구독을 가져오고 설정 활성화하기

먼저 설정 제공처에서 받은 구독 URL이나 로컬 YAML 파일을 준비하세요. 클라이언트는 설정을 읽고 코어를 실행해 트래픽을 전달하지만, 설치만으로 사용할 수 있는 프록시 노드가 생기는 것은 아닙니다. 구독 URL은 웹사이트 홈 주소와 다릅니다. 클라이언트가 인식할 수 있는 설정 내용을 반환해야 합니다. 제공처에서 여러 형식을 지원한다면 현재 Clash 클라이언트 또는 mihomo 코어와 호환된다고 명시된 형식을 선택하세요. 다른 프로그램용 원문을 이름만 바꿔 가져오면 안 됩니다.

클라이언트를 열고 ‘설정’ 또는 ‘구독’ 페이지에서 ‘추가’, ‘가져오기’ 또는 더하기 버튼을 찾으세요. URL 가져오기를 선택하고 구독 링크 입력란에 주소 전체를 붙여 넣습니다. 이름은 기기에서 구분할 때 사용하는 것이므로 출처를 알아보기 쉬운 짧은 이름을 지정하면 됩니다. 링크 앞뒤에 공백이나 줄바꿈이 들어갔는지, 메신저가 문장 부호를 덧붙였는지 확인한 뒤 다운로드 또는 저장을 누르세요. 가져오기 결과가 나올 때까지 기다리고, 구분하기 어려운 설정이 여러 개 생기지 않도록 연속해서 다시 제출하지 마세요.

다운로드가 완료되면 설정 목록에 항목이 추가됩니다. 해당 항목을 누르거나 옆의 ‘활성화’, ‘사용’ 버튼을 눌러 현재 설정으로 지정하세요. 가져온 직후 자동으로 활성화되는 클라이언트도 있지만 파일만 저장하는 경우도 있습니다. ‘다운로드 성공’ 메시지만 믿지 말고 현재 선택 표시를 확인하세요. 그런 다음 ‘프록시’ 페이지에서 설정에 정의된 정책 그룹이 보이는지 확인합니다. 파일 항목만 있고 예상한 정책 그룹이 없다면 설정 페이지로 돌아가 활성화된 항목과 오류 메시지를 확인하세요.

로컬 파일을 사용하려면 같은 페이지에서 ‘파일에서 가져오기’를 선택하고 저장한 .yaml 또는 .yml 파일을 찾아 여세요. 파일 가져오기는 보통 로컬 사본을 저장하는 방식이며 원격 업데이트를 설정하는 것은 아닙니다. 제공처에서 노드를 수정하면 파일을 다시 가져오거나 제공처의 구독 기능을 사용해야 합니다. 파일 안의 노드 항목 하나를 전체 설정으로 착각하지 마세요. 처음에는 제공처가 제공하는 호환 가능한 전체 설정을 사용하는 것이 좋습니다.

가져오기에 실패하면 먼저 응답 내용을 확인하세요

다운로드 시간 초과, 형식 오류, 로드 실패가 발생하면 먼저 오류 메시지를 그대로 확인하세요. 프록시를 켜지 않은 상태에서 기기가 인터넷에 연결되는지, 구독 URL이 만료되었는지, 제공처 페이지에서 URL을 다시 복사해야 하는지 확인합니다. 로그인 페이지나 오류 페이지, 지원하지 않는 형식이 반환되면 파싱에 실패할 수 있습니다. 클라이언트에 ‘프록시를 통해 업데이트’ 옵션이 있지만 아직 연결을 사용할 수 없다면, 현재 네트워크 환경에 맞춰 직접 업데이트를 사용하세요. 아직 실행되지 않은 프록시에 업데이트 요청이 의존하지 않도록 합니다.

구독 링크에는 계정 식별 정보가 포함될 수 있으므로 로그인 정보처럼 안전하게 보관하세요. 문제를 해결할 때 전체 URL이나 QR 코드, 설정 파일 전문을 공개 댓글에 올리지 마세요. 오류를 기록해야 한다면 오류 유형만 남기고 스크린샷의 민감한 정보는 가리세요. 구독 형식과 업데이트 문제는 자주 묻는 질문에서 더 자세히 확인할 수 있습니다. 우선 이 페이지의 연결 설정을 계속 진행하세요.

업데이트가 로컬 변경 사항을 덮어쓰지 않는지 확인하세요

처음 가져오기를 마친 뒤 ‘업데이트’를 한 번 실행해 제공처에서 다시 가져올 수 있는지 확인하세요. 다음 업데이트 때 내용이 교체될 수 있으므로 다운로드한 설정 본문을 대폭 수정하는 것은 피하세요. DNS, 규칙, 포트를 변경해야 한다면 먼저 클라이언트의 오버라이드 방식을 확인하세요. 자세한 내용은 mihomo 고급 설정 가이드에서 다룹니다. 지금은 설정이 활성화되었고 정책 그룹이 표시되는지만 확인한 다음 모드 선택으로 넘어가세요.

2단계: 프록시 모드와 정책 그룹 선택

설정이 로드되면 클라이언트 홈 화면이나 프록시 설정으로 돌아가 모드 선택 메뉴를 찾으세요. 일반적으로 ‘규칙’, ‘전역’, ‘직접 연결’이 표시되며 코어의 rule, global, direct에 해당합니다. 처음에는 규칙 모드를 선택해 설정에 정의된 규칙에 따라 요청을 처리하도록 하세요. 연결을 더 확실히 하겠다고 네트워크 스위치를 여러 개 동시에 켜지 마세요. 모드는 요청이 코어에 들어온 뒤 어떻게 처리할지를 결정할 뿐, 앱의 트래픽을 코어로 전달하지는 않습니다.

규칙 모드는 설정에 적힌 순서대로 규칙을 확인하고, 처음 일치하는 항목이 사용할 정책을 결정합니다. 예를 들어 특정 도메인은 프록시 정책 그룹으로 보내고 다른 요청은 DIRECT로 처리할 수 있습니다. 분기 방식은 현재 설정에 따라 다르며 모든 구독이 같은 규칙을 사용하는 것은 아닙니다. 따라서 규칙 모드를 선택한 뒤에도 ‘프록시’ 또는 ‘정책 그룹’ 페이지를 열어 규칙에 사용되는 주요 정책 그룹이 어디를 가리키는지 확인하세요.

수동 선택 그룹에서 제공처가 제공한 현재 사용 가능한 노드를 누르거나 설정에 미리 지정된 자동 선택 그룹을 고르세요. 그룹 이름은 설정에 따라 ‘프록시’, ‘노드 선택’ 등으로 다를 수 있으므로 특정 이름을 찾을 필요는 없습니다. 그룹 안에 다른 그룹이 표시되면 아래 단계의 선택도 확인하세요. 상위 그룹이 직접 연결을 가리키는 경우, 사용되지 않는 다른 그룹의 노드만 바꿔도 해당 요청의 실제 출구는 달라지지 않습니다.

클라이언트에 연결 테스트 기능이 있다면 노드를 추리는 데 활용할 수 있습니다. 테스트 성공은 해당 조건에서 연결할 수 있다는 뜻일 뿐, 모든 사이트와 프로토콜이 정상 작동한다는 의미는 아닙니다. 테스트 시간 초과는 테스트 주소의 영향일 수도 있습니다. 기본 접속이 가능한 노드를 하나 선택하고, 실제로 작동하는지는 4단계에서 요청을 확인하세요. 테스트 결과나 숫자만 보고 판단하지 마세요.

전역 모드는 비교용이며 트래픽 전달 설정을 대신하지 않습니다

규칙 모드에서 특정 사이트 접속에 실패하면 전역 모드로 잠시 전환하고, 전역 정책에서 실제로 선택된 노드를 확인한 뒤 다시 요청해 보세요. 전역 모드에서는 작동하지만 규칙 모드에서는 실패한다면 DNS를 바로 바꾸기보다 일치한 규칙과 정책 그룹을 확인해야 합니다. 테스트가 끝나면 규칙 모드로 돌아가 직접 접속이 적절한 요청까지 프록시 출구로 보내지 않도록 하세요.

전역 모드라고 해서 기기의 모든 트래픽이 프록시를 통과하는 것은 아닙니다. 시스템 프록시를 따르지 않는 앱은 여전히 코어를 우회할 수 있습니다. 더 넓은 범위의 트래픽을 전달해야 할 때 TUN을 고려하세요. 직접 연결 모드도 클라이언트 종료를 뜻하지 않습니다. 시스템 프록시나 VPN을 통한 트래픽 전달은 계속 켜져 있을 수 있습니다. 이 차이를 이해했다면 규칙 모드와 선택한 정책을 유지하고, 이제 앱 요청을 코어로 전달하는 설정을 진행하세요. 규칙과 그룹 유형은 정책 그룹 설정 안내에서 더 자세히 확인할 수 있습니다.

3단계: 시스템 프록시 또는 모바일 VPN 켜기

클라이언트에서 설정을 불러오는 데 오류가 없고, 홈 화면에 코어 실행 중 표시가 있거나 연결 버튼을 누를 수 있는지 확인하세요. 설정 활성화, 코어 실행, 트래픽 전달은 서로 다른 단계입니다. 설정이 있어도 코어가 실행되지 않으면 요청을 처리할 수 없고, 코어가 실행 중이어도 트래픽을 전달하지 않으면 브라우저는 기존 네트워크로 접속할 수 있습니다. 시스템 프록시, TUN, 다른 VPN을 동시에 켜지 말고 한 가지 전달 방식만 사용하면 결과를 확인하기 쉽습니다.

데스크톱: 먼저 시스템 프록시 사용

Windows, macOS 또는 Linux 클라이언트에서 ‘시스템 프록시’ 스위치를 찾아 켜세요. 일부 클라이언트는 먼저 시스템 권한을 요청합니다. 기기의 안내에 따라 승인한 뒤 스위치가 계속 켜져 있는지 확인하세요. 보통 브라우저에 노드 서버 주소를 따로 입력할 필요는 없습니다. 시스템 프록시는 로컬 코어의 수신 포트를 가리키며, 코어가 설정에 따라 원격 출구를 선택합니다.

시스템 설정을 확인하려면 시스템 프록시에서 사용하는 주소와 포트가 클라이언트 설정과 일치하는지 살펴보세요. 흔히 로컬 주소로 127.0.0.1을 사용하고, 이 사이트의 예시 혼합 포트는 mixed-port: 7890입니다. 실제 포트는 클라이언트마다 다를 수 있으므로 현재 적용된 설정을 기준으로 하세요. 브라우저 프록시 확장 프로그램을 사용 중이라면 먼저 브라우저가 시스템 프록시를 사용하도록 설정해 확장 프로그램이 이전 포트로 요청을 보내지 않게 하세요. 처음에는 LAN 연결 허용을 켤 필요가 없습니다.

포트가 사용 중이거나 코어 실행에 실패해도 시스템 프록시 스위치만 반복해서 켜고 끄지 마세요. 같은 포트를 사용할 수 있는 다른 프록시 클라이언트를 먼저 종료한 뒤 다시 실행해 보세요. 수신 포트를 변경한다면 시스템 프록시의 포트도 함께 변경해야 합니다. Linux 데스크톱 환경과 앱에 따라 시스템 프록시 지원 여부가 다를 수 있습니다. 브라우저는 작동하지만 터미널 프로그램은 작동하지 않는다고 해서 반드시 코어 오류인 것은 아닙니다. 이 안내에서는 시스템 프록시를 확실히 지원하는 브라우저로 먼저 확인합니다.

모바일: VPN 권한과 연결 상태 확인

Android 또는 iOS 클라이언트 홈 화면에서 ‘연결’ 또는 시작 버튼을 누르세요. 시스템에서 VPN 설정 추가나 VPN 연결 허용을 처음 요청하면 현재 사용하는 클라이언트에서 보낸 요청인지 확인한 뒤 안내에 따라 승인합니다. 기기 잠금 해제가 필요할 수도 있습니다. 클라이언트로 돌아와 연결 상태가 바뀌는지 기다리고 시스템의 VPN 상태도 확인하세요. 권한 승인은 트래픽 전달을 허용했다는 뜻일 뿐, 노드가 실제로 작동하는지는 요청을 보내 확인해야 합니다.

기기에 다른 일반 VPN 연결이 있다면 먼저 연결을 끊고 현재 클라이언트를 시작하세요. 시스템이 연결을 교체해 판단이 혼란스러워지는 일을 막을 수 있습니다. Android 클라이언트에서 앱별 프록시나 우회 목록을 설정했다면 테스트 브라우저가 트래픽 전달 대상에 포함되었는지도 확인하세요. 첫 테스트는 클라이언트의 기본 범위를 그대로 사용하는 것이 좋습니다. 기본 연결이 확인된 뒤 범위를 줄이고, 목록의 의미를 모르는 상태에서 앱을 여러 개 한꺼번에 제외하지 마세요.

위 단계를 마치면 클라이언트를 실행한 채 브라우저에서 새 탭을 여세요. 홈 화면의 ‘연결됨’ 표시만 확인해서는 안 됩니다. 여기까지는 트래픽 전달 경로를 만든 단계이며, 다음 단계에서 요청이 어떤 규칙과 출구를 거쳤는지 확인합니다.

4단계: 연결 기록으로 트래픽 분기 확인

현재 테스트할 수 있고 익숙한 사이트 두 곳을 준비하세요. 하나는 설정상 직접 접속이 예상되는 사이트, 다른 하나는 프록시를 거칠 것으로 예상되는 사이트입니다. 새 탭에서 접속한 뒤 클라이언트의 ‘연결’, ‘활성 연결’ 또는 로그 페이지로 돌아가세요. 대상 도메인이나 주소가 표시되는지, 기록에 일치한 규칙과 정책 체인, 최종 출구가 무엇인지 확인합니다. 클라이언트마다 표시 항목은 다르지만, 브라우저 요청과 코어 처리 기록을 연결해 확인하는 것이 목적입니다.

사이트가 열리고 해당 연결 기록도 찾을 수 있다면 예상한 정책이 적용되었는지 확인하세요. 기록에 DIRECT가 표시되면 코어가 해당 연결을 직접 처리한 것이지 클라이언트가 작동하지 않는다는 뜻은 아닙니다. 프록시 그룹을 가리키는 기록은 펼치거나 최종 노드를 확인하세요. 상위 그룹 이름만 보고 결론을 내리지 마세요. 프록시 규칙을 테스트할 때는 해당 규칙과 실제로 일치하는 도메인을 사용해야 합니다. 아무 웹페이지나 열린다고 해서 프록시 출구를 사용했다고 볼 수는 없습니다.

그런 다음 직접 연결이 예상되는 사이트에 접속해 규칙 모드에서 두 종류의 요청이 모두 적절히 처리되는지 확인하세요. 출구 IP 조회는 참고 자료일 뿐입니다. 조회 사이트 자체가 직접 연결 규칙에 해당할 수 있고, 브라우저 캐시나 기존 연결도 결과에 영향을 줍니다. 노드를 방금 바꿨다면 새 요청을 보내세요. 필요하면 해당 활성 연결만 끊고 다시 시도합니다. 확인을 위해 전체 방문 기록을 내보내거나 연결 목록을 공개적으로 업로드하지 마세요.

예상과 다르면 경로 순서대로 확인하세요

브라우저에서 요청을 보냈는데 클라이언트에는 관련 연결이 전혀 보이지 않는다면 먼저 트래픽 전달 설정을 확인하세요. 시스템 프록시가 켜져 있는지, 주소와 포트가 일치하는지, 브라우저 확장 프로그램이 설정을 덮어쓰는지, 모바일에서 브라우저가 제외되었는지 살펴봅니다. 일부 클라이언트는 활성 연결만 표시하므로 짧은 요청이 금방 사라질 수 있습니다. 로그를 함께 확인하세요. 요청이 코어에 들어오지 않는 상황에서는 노드를 바꾸거나 분기 규칙을 수정해도 대개 해결되지 않습니다.

연결은 보이지만 잘못된 정책이 선택되었다면 2단계로 돌아가 현재 모드, 상위 그룹 선택, 일치한 규칙을 확인하세요. 예상한 노드로 요청이 전달됐는데도 연결에 실패한다면 같은 설정의 다른 사용 가능한 노드를 시도하고 구체적인 오류를 비교합니다. 도메인 이름을 확인할 수 없다는 등의 징후가 있을 때만 DNS를 점검하세요. 모드, 노드, DNS, TUN을 한꺼번에 변경하지 마세요. 조건을 하나씩만 바꾸고 같은 대상에 다시 접속해야 변경 사항의 영향을 판단할 수 있습니다.

브라우저에서는 규칙에 따라 접속되는데 특정 앱만 실패한다면 해당 앱이 시스템 프록시를 따르는지, 별도의 프록시 설정을 사용하는지, 현재 트래픽 전달 범위에 포함되는지 확인하세요. 첫 연결에서 DNS와 Fake-IP의 모든 작동 원리를 파악할 필요는 없습니다. 관련된 문제가 명확할 때 Fake-IP 설정 안내를 살펴보세요. 다른 오류와 해결 방법은 자주 묻는 질문에서 확인할 수 있습니다.

사용을 마치고 기존 네트워크로 복원하기

확인을 마치고 사용을 중단하려면 데스크톱에서는 먼저 클라이언트의 시스템 프록시를 끈 뒤 클라이언트를 종료하세요. 모바일에서는 클라이언트 연결을 끊고 시스템 VPN 상태가 종료되었는지 확인합니다. 프로세스만 종료하고 로컬 포트를 가리키는 시스템 프록시를 남겨두면, 브라우저가 더 이상 수신하지 않는 서비스에 요청을 보낼 수 있습니다. 종료 후 웹페이지가 열리지 않으면 시스템 네트워크 설정에서 프록시 상태를 확인하고 이전 설정으로 복원하세요. 조직에서 관리하는 기기는 해당 관리 지침을 따라야 합니다.

다음에 실행할 때는 ‘현재 설정 → 규칙 모드와 정책 → 트래픽 전달 스위치 → 실제 요청’ 순서로 빠르게 확인하면 됩니다. 구독을 업데이트한 뒤에도 그룹 이름이나 분기 규칙이 바뀌었을 수 있으므로 간단히 다시 점검하세요. 설정 가져오기부터 연결 기록 확인까지 기본 흐름을 마쳤습니다. 이후 규칙 집합, 로컬 오버라이드, 외부 제어가 필요하면 고급 가이드에서 항목별로 설정하세요. 처음부터 모든 기능을 켤 필요는 없습니다.