1단계: 구독 가져오기 및 설정 활성화
시작하기 전에 클라이언트가 정상적으로 실행되는지, 구독 서비스가 아직 유효한지 확인하세요. Clash 클라이언트는 설정을 읽고 트래픽을 처리하는 프로그램이며, 클라이언트를 설치한다고 프록시 노드가 생기는 것은 아닙니다. 구독 URL은 보통 서비스 제공업체가 제공하며 계정 식별 정보가 포함될 수 있으므로 비공개 정보로 취급해야 합니다. 전체 URL을 공개 게시판에 올리거나 잘 모르는 온라인 변환 사이트에 입력하지 마세요.
Clash Verge Rev에서 구독 가져오기
Clash Verge Rev를 열고 사이드바에서 ‘구독’ 페이지로 이동합니다. 버전에 따라 ‘프로필’로 표시될 수 있습니다. 구독 URL 입력란에 Clash 또는 mihomo 호환으로 안내된 주소를 붙여 넣고 ‘가져오기’를 클릭하세요. 새 프로필 창이 뜨면 원격 프로필을 선택하고 알아보기 쉬운 짧은 이름을 입력합니다. 이름은 로컬에서 구분할 때만 사용되며 구독 내용에는 영향을 주지 않습니다. 확인을 클릭한 뒤 다운로드가 끝날 때까지 기다리고, 같은 주소를 연속으로 다시 가져오지 마세요.
가져오기에 성공하면 목록에 설정 카드나 항목이 표시됩니다. 해당 항목을 눌러 현재 사용 중인지 확인한 다음 ‘프록시’ 페이지에서 정책 그룹과 선택 가능한 노드가 보이는지 확인하세요. 가져온 직후 자동으로 활성화되는 클라이언트도 있지만 파일만 저장하는 클라이언트도 있습니다. 따라서 ‘목록에 구독이 있다’는 것과 ‘코어가 해당 구독을 사용 중이다’는 것을 각각 확인해야 합니다. 새 설정과 기존 설정의 내용이 다르다면 전환 후 프록시 페이지에도 차이가 보여야 합니다.
Android와 iOS 클라이언트에서는 보통 ‘구독’ 또는 ‘프로필’ 페이지의 더하기 버튼으로 시작합니다. URL 가져오기를 선택해 주소를 붙여 넣고 저장한 다음, 프로필 목록으로 돌아가 활성화하세요. 시스템 공유 메뉴에서 구독 URL을 클라이언트로 전달할 수도 있지만, 마지막에는 클라이언트로 돌아와 현재 설정을 확인해야 합니다. QR 코드로 가져올 때는 서비스 제공업체가 제공한 코드인지 먼저 확인하세요. 스캔 결과가 일반 웹페이지라면 사용할 수 있는 설정을 가져온 것이 아닙니다.
로컬 파일 및 첫 업데이트
YAML 파일을 받았다면 ‘파일 가져오기’ 또는 ‘로컬 프로필’ 메뉴에서 파일을 선택하세요. 파일 내용을 구독 URL 입력란에 붙여 넣으면 안 됩니다. 로컬 파일의 업데이트 여부는 파일 내용과 클라이언트 동작 방식에 따라 다르므로, 원격 구독처럼 새로고침할 수 있다고 가정하지 마세요. 설정 파일의 노드, 정책 그룹, 규칙은 각각 역할이 다릅니다. 처음에는 원본을 그대로 사용하고, 서로 어떤 관계인지 알아보려면 용어 설명을 참고하세요. 이 단계에서 파일을 직접 수정할 필요는 없습니다.
가져오기에 실패하면 먼저 주소가 완전한지 확인하세요. 특히 메신저에서 복사할 때 공백이나 줄바꿈이 들어가지 않았는지 살펴봅니다. 다음으로 클라이언트 메시지를 확인하세요. 다운로드 실패는 콘텐츠를 가져오는 단계가 끝나지 않았다는 뜻이고, 파싱 실패는 받은 콘텐츠를 현재 설정 형식으로 읽지 못했다는 뜻입니다. 로그인 페이지, 오류 페이지, 다른 클라이언트 전용 형식도 파싱 실패의 원인이 될 수 있습니다. 규칙을 계속 바꾸기보다 서비스 제공업체에 구독 유형을 확인하세요. 프록시 페이지에서 정책 그룹을 읽을 수 있을 때 다음 단계로 넘어갑니다.
2단계: 모드 및 출구 노드 선택
설정을 활성화한 다음 클라이언트의 홈, 프록시 또는 설정 페이지에서 ‘출구 모드’를 찾습니다. 보통 ‘규칙’, ‘전역’, ‘직접 연결’ 중에서 선택할 수 있으며, 첫 연결에는 규칙 모드를 선택하세요. 규칙 모드는 설정에 따라 각 연결이 사용할 정책 그룹이나 직접 연결 여부를 결정합니다. 이 모드는 트래픽이 코어에 들어온 뒤 처리되는 방식을 제어할 뿐, 브라우저나 다른 앱의 트래픽을 코어로 보내지는 않습니다. 트래픽을 코어로 전달하는 방법은 3단계에서 다룹니다.
| 모드 | 연결 처리 방식 | 첫 사용 시 권장 사항 |
|---|---|---|
| 규칙 | 현재 설정의 규칙에 따라 출구를 선택합니다 | 일상적인 기본 모드로 사용하고 연결 기록에서 규칙 적용 결과를 확인합니다 |
| 전역 | 코어에 들어온 앱 트래픽에 전역 정책을 적용합니다 | 짧은 비교 테스트에 사용하되, 사용할 출구를 지정해야 합니다 |
| 직접 연결 | 코어에 들어온 앱 트래픽을 대상에 직접 연결합니다 | 직접 연결 비교에 사용하며 프록시 적용 여부를 판단하는 기준으로 삼지 않습니다 |
이어서 ‘프록시’ 페이지에서 기본 출구 정책 그룹을 찾습니다. 이름은 구독 설정에 따라 ‘노드 선택’, ‘프록시’ 또는 다른 이름일 수 있으며, 반드시 PROXY라고 표시되지는 않습니다. 정책 그룹을 펼쳐 현재 사용할 수 있는 노드를 선택하고 선택 표시가 바뀌었는지 확인하세요. 그룹 안에 다른 정책 그룹이 나열되어 있다면 현재 선택을 따라가며 최종 출구가 특정 노드인지 직접 연결인지 확인합니다.
일부 설정은 동영상, 코드 호스팅, 메신저 앱에 별도의 정책 그룹을 지정합니다. 기본 그룹에서 노드를 선택해도 이 그룹들의 선택이 강제로 바뀌지는 않습니다. 처음 확인할 때는 테스트할 웹사이트에 해당하는 그룹만 확인하면 됩니다. 어떤 그룹인지 아직 모르더라도 먼저 연결한 뒤 ‘연결’ 기록에서 실제 경로를 찾을 수 있습니다. 노드 이름만 보고 특정 웹사이트가 해당 노드를 사용한다고 판단하지 마세요. 최종 출구는 규칙과 정책 그룹의 참조 관계로 결정됩니다.
Clash 노드 지연 시간 테스트
정책 그룹 옆의 테스트 버튼이나 클라이언트의 ‘지연 시간 테스트’ 메뉴를 눌러 결과가 나올 때까지 기다립니다. 테스트 결과는 클라이언트가 해당 출구로 테스트 주소에 접속한 상태를 보여주며, 의미는 클라이언트와 테스트 방식에 따라 다릅니다. 다운로드 속도를 나타내는 수치가 아니며 모든 웹사이트에 접속할 수 있다는 보장도 아닙니다. 시간이 초과되면 같은 그룹의 다른 노드를 선택해 다시 시도하세요. 한 번 낮게 나온 수치만으로 모든 앱에 가장 적합한 노드라고 단정하지 마세요.
테스트가 끝나면 선택된 항목을 다시 확인하세요. 일부 버튼은 연결 여부만 테스트하며 수동 선택 그룹의 현재 노드를 바꾸지 않습니다. 자동 선택 그룹은 자체 설정에 따라 노드를 전환합니다. 처음에는 대상 페이지가 계속 열리는지를 기준으로 사용할 노드를 하나 정하고, 점검 중에는 테스트를 반복해 흐름을 끊지 마세요. 선택 그룹, 자동 선택, 장애 조치의 차이는 정책 그룹 고급 안내에서 확인할 수 있습니다.
비교를 위해 Clash 전역 모드를 사용하려면 전환 후 전역 정책의 현재 출구도 확인해야 합니다. 전역 모드라고 해서 기기의 모든 트래픽이 자동으로 전달되는 것은 아니며, 작동하지 않는 노드를 복구해 주지도 않습니다. 테스트가 끝나면 규칙 모드로 되돌려 이후 확인 경로가 기존 설정의 예상과 달라지지 않도록 하세요. 세 가지 모드에 대한 자세한 내용은 출구 모드 안내를 참고하세요.
3단계: 연결 및 트래픽 전달 켜기
설정과 출구를 정했으니 이제 실제 앱이 클라이언트를 사용하도록 해야 합니다. 데스크톱에서는 확인하기 쉬운 시스템 프록시 경로를 먼저 사용하고, 모바일에서는 VPN 연결 방식으로 진행하세요. 기기에서 다른 프록시 도구나 VPN을 함께 실행 중이라면 먼저 다른 연결을 끊고 한 가지 조건만 남겨 테스트합니다. 한 번에 트래픽 전달 방식 하나만 바꾸면 문제가 생겼을 때 원인을 찾기 쉽습니다.
데스크톱 시스템 프록시 설정
Clash Verge Rev 설정 페이지에서 ‘시스템 프록시’를 찾아 켭니다. 그런 다음 운영체제의 네트워크 설정에서 프록시 페이지를 열어 상태가 바뀌었는지 확인하세요. 클라이언트는 보통 시스템 프록시가 로컬 수신 주소와 현재 포트를 가리키도록 설정합니다. 클라이언트에 표시된 값을 기준으로 사용하세요. 예시에서 흔히 보이는 7890 포트라고 해서 기기 설정을 무조건 그 값으로 바꾸면 안 됩니다. 사용자 지정 설정이나 다른 소프트웨어에서 다른 포트를 사용할 수 있습니다.
시스템 프록시 설정을 사용하는 브라우저는 보통 새 연결부터 해당 경로를 사용합니다. 별도 프록시 확장 프로그램이 설치되어 있거나 브라우저 자체 설정에 다른 프록시가 지정되어 있는지 확인하세요. Firefox 등은 별도의 네트워크 설정을 유지할 수 있으므로 시스템 프록시 사용을 선택하거나 클라이언트의 실제 수신 정보에 맞게 설정해야 합니다. 변경 후 새 창을 열어 접속하고 기존 연결을 재사용하지 마세요. 명령줄 도구와 일부 앱은 시스템 프록시를 읽지 않을 수 있으므로, 첫 연결의 성공 여부를 확인할 때 이들만 기준으로 삼지 마세요.
macOS에서 시스템 네트워크 설정을 변경하면 권한 확인 창이 나타날 수 있습니다. 서비스나 보조 구성요소를 설치해야 하는 클라이언트는 추가 권한을 요청할 수도 있습니다. 안내에 표시된 앱 이름을 확인한 뒤 승인하고, 클라이언트로 돌아와 스위치가 계속 켜져 있는지 확인하세요. Linux에서 데스크톱 네트워크 설정이 바뀌지 않으면 앱에서 프록시를 직접 지정해 테스트할 수 있습니다. 기존 값을 기록하지 않은 채 시스템 네트워크 옵션을 반복해서 바꾸지 마세요.
모바일 연결 및 VPN 권한
Android와 iOS에서는 클라이언트 홈으로 돌아가 연결 스위치를 누릅니다. 처음 연결할 때 시스템 VPN 설정 또는 연결 권한을 묻는 창이 나타나는 경우가 많습니다. 승인한 뒤 클라이언트에 연결됨으로 표시될 때까지 기다리고, 시스템에도 해당 VPN 상태가 나타나는지 확인하세요. 이 상태는 시스템에 클라이언트가 필요한 트래픽 전달 통로가 만들어졌다는 뜻이지, 원격 노드가 접속 테스트를 통과했다는 뜻은 아닙니다. 따라서 4단계도 완료해야 합니다.
스위치를 켠 직후 다시 꺼진다면 시스템이 권한을 거부했는지, 다른 VPN이 계속 연결되어 있는지 확인하세요. Android에서는 상시 연결 VPN, 앱별 트래픽 분할, 배터리 관리 설정도 살펴 다른 앱이 현재 연결을 제한하지 않도록 합니다. iOS에서는 시스템 설정에서 현재 VPN 구성이 사용 중인 클라이언트에 해당하는지 확인할 수 있습니다. 연결 안내가 완료되기 전에는 스위치를 빠르게 연속해서 누르지 마세요. 연결 상태를 파악하기 어려워질 수 있습니다.
TUN은 언제 사용해야 하나요?
브라우저는 규칙에 따라 접속되지만 시스템 프록시를 따르지 않는 특정 앱이 여전히 직접 연결될 때 TUN을 고려하세요. 설정에서 TUN 모드를 켜고 클라이언트 안내에 따라 서비스를 설치하거나 관리자 권한을 부여합니다. 처음에는 클라이언트 기본 stack을 유지하고 기능부터 확인하세요. DNS, 라우팅, 프로토콜 스택을 동시에 바꾸지 마세요. 가상 네트워크 어댑터 생성 여부, 라우팅 상태, 앱 제외 설정이 모두 결과에 영향을 줄 수 있으므로 스위치 색상만으로 트래픽 전달이 성공했다고 판단할 수 없습니다.
TUN을 켠 뒤 기기 전체에서 인터넷이 끊기면 먼저 TUN을 끄고 앞서 확인한 시스템 프록시 경로로 돌아가세요. 연결을 복구한 다음 로그를 살펴보고, 전체 설정을 바로 초기화하지 마세요. TUN, Fake-IP, DNS 조합은 이후에 최적화할 내용이며, 첫 연결에서 모두 설정할 필요는 없습니다. 관련 원리는 네트워크 트래픽 전달 및 DNS 용어부터 확인하세요.
4단계: 연결 적용 여부 확인
클라이언트의 ‘연결’ 페이지를 열어 둔 상태에서 브라우저에 새 창을 만들고 평소 자주 방문하는 안정적인 HTTPS 페이지에 접속합니다. 클라이언트 연결 기록에 해당 도메인이나 대상 주소가 나타나는지 확인한 다음, 적용된 규칙과 출구 경로를 살펴보세요. 일부 클라이언트에서는 기록을 펼쳐야 세부 항목이 표시됩니다. 짧은 연결은 금방 종료될 수 있으므로 기록 페이지를 먼저 열고 대상 페이지를 새로고침하세요.
페이지가 정상적으로 열리고 기록에 예상한 정책 그룹과 노드가 표시되면 요청이 코어로 전달되어 해당 경로로 처리된 것입니다. 이어서 직접 연결될 것으로 예상되는 페이지에 접속해 기록에 DIRECT가 표시되는지 확인하세요. 규칙 모드에서 일부 요청이 직접 연결되는 것은 정상이며 프록시가 작동하지 않는다는 뜻이 아닙니다. 우회 방식이 적용된 설정에서는 직접 연결 트래픽이 코어 기록에 나타나지 않을 수도 있으므로 실제 트래픽 전달 설정과 함께 판단해야 합니다.
신뢰할 수 있는 IP 주소 조회 페이지를 이용해 출구를 보조적으로 확인할 수도 있습니다. 다만 조회 페이지 자체가 어떤 규칙을 사용하는지 먼저 확인하세요. 해당 페이지에 표시되는 값은 그 요청에서 관찰한 출구일 뿐, 모든 앱과 도메인이 같은 경로를 사용한다는 뜻은 아닙니다. 브라우저 캐시, 기존 연결 재사용, 주소 계열 차이도 결과에 영향을 줄 수 있습니다. 페이지 접속 결과를 연결 기록과 맞춰 확인하고, 작업 표시줄 아이콘이나 VPN 표시만 보고 판단하지 마세요.
실패하면 같은 순서로 다시 점검
클라이언트에 테스트 요청이 전혀 나타나지 않으면 먼저 3단계로 돌아가 시스템 프록시, 브라우저의 별도 프록시 설정, 모바일 VPN 상태를 확인하세요. 기록은 있지만 예상과 달리 대상이 DIRECT로 연결되면 노드를 바꾸기 전에 규칙과 정책 그룹 선택을 점검합니다. 기록에 프록시 노드가 표시되는데도 연결 시간이 초과되면 같은 정책 그룹의 다른 노드와 비교해 보세요. 이 세 가지 경우는 각각 트래픽 전달, 분기 규칙, 출구 연결 문제에 해당합니다. 여러 설정을 동시에 바꾸기보다 나누어 확인하는 편이 원인을 찾기 쉽습니다.
로그에 파싱 관련 오류가 표시되면 원래 설정을 보존하세요. 먼저 직접 연결 상태에서 DNS 조회와 일반 웹페이지 접속이 정상인지 확인한 뒤, 특정 도메인에만 문제가 발생하는지 살펴봅니다. 인터넷에서 DNS 설정을 통째로 복사해 구독 설정을 덮어쓰거나 시스템 DNS, 클라이언트 DNS, 브라우저 보안 DNS를 한꺼번에 바꾸지 마세요. 문제를 신고할 때는 클라이언트 이름, 운영체제, 재현 절차, 오류 문구를 기록하세요. 로그를 공유하기 전 구독 URL, 계정 식별 정보 등 민감한 내용을 삭제해야 합니다.
연결 확인이 끝나면 현재 사용 중인 설정, 모드, 정책 그룹 선택을 기억해 두세요. 나중에 구독을 새로고침한 뒤 동작이 달라지면 현재 설정이 원래 사용하던 것인지, 정책 그룹 선택이 유지됐는지 먼저 확인합니다. 사용을 마칠 때는 클라이언트에서 시스템 프록시 또는 VPN 연결을 끈 다음 앱을 종료하세요. 앱을 바로 종료한 뒤 브라우저에서 인터넷이 끊기면 시스템 네트워크 설정에 로컬 주소를 가리키는 수동 프록시가 남아 있는지 확인합니다.