Clash Verge Rev
구독 가져오기 및
규칙 연결 사용법

PREPARATION

시작 전 확인: 클라이언트, 구독, 시스템 시간

작업을 시작하기 전에 클라이언트가 설치되어 정상적으로 실행되는지 확인합니다. Windows와 macOS 사용자는 Clash Verge Rev를 우선 사용할 수 있고, 모바일에서는 해당 플랫폼을 지원하는 호환 클라이언트를 선택해야 합니다. 아직 설치하지 않았다면 다운로드 페이지에서 운영체제에 맞는 클라이언트를 선택하세요. 이 사용법은 특정 버전에 의존하지 않지만, 화면에서 설정 관리, 프록시 정책, 실행 설정, 연결 기록 같은 기본 기능을 찾을 수 있어야 합니다.

이제 유효한 구독 주소 또는 클라이언트가 읽을 수 있는 Clash 설정 파일을 준비합니다. 구독 주소는 보통 https://로 시작하는 링크이며, 클라이언트가 노드, 프록시 그룹, 규칙, DNS 등의 설정을 가져오도록 합니다. 일반 웹페이지 주소가 아니므로 브라우저에서 먼저 열 필요가 없고, 구독 내용을 여러 노드로 나눠 수동 입력해서도 안 됩니다. 클라이언트의 구독 입력란으로 직접 가져오면 프록시 그룹과 규칙 사이의 참조 관계를 유지할 수 있습니다.

기기의 날짜, 시간, 시간대도 정확한지 확인합니다. 시스템 시간이 어긋나면 TLS 연결에 영향을 주어 구독 업데이트나 노드 연결에서 인증서 시간 관련 오류가 발생할 수 있습니다. 노트북을 절전 모드에서 막 복구했다면 네트워크가 다시 연결되었는지도 확인하세요. 이러한 점검을 마친 뒤 첫 단계로 이동하면 시스템 문제를 설정 문제로 잘못 판단하는 일을 줄일 수 있습니다.

STEP 01 / CONFIGURATION

구독 가져오기: 설정, 프록시 그룹, 규칙을 클라이언트에 불러오기

Clash Verge Rev를 연 뒤 왼쪽 탐색 메뉴에서 “구독” 또는 “설정” 페이지로 이동합니다. 버전에 따라 “Profiles”로 표시될 수도 있습니다. 구독 링크를 입력하는 텍스트 상자를 찾아 전체 주소를 붙여넣습니다. 붙여넣기 전후에 공백이나 한글 문장 부호를 추가하지 말고 “가져오기”, “추가” 또는 “업데이트”를 클릭합니다. 클라이언트가 구독 내용을 요청하고 설정을 파싱하면 정상적으로 새 설정 항목이 나타나며, 여기에는 설정 이름, 업데이트 시간, 업데이트 작업이 표시됩니다.

설정 항목이 나타났다고 바로 연결 단계로 넘어가지는 마세요. 먼저 해당 설정을 클릭해 현재 활성 항목으로 지정되었는지 확인합니다. 일부 클라이언트는 선택 후 강조 테두리, 체크 표시 또는 “현재” 상태를 보여주고, 다른 클라이언트는 설정 오른쪽 메뉴에서 “활성화”를 선택해야 합니다. 다운로드만 하고 활성화하지 않으면 프록시 페이지에 이전 설정의 프록시 그룹이 표시될 수 있으며, 이후 선택하는 노드도 방금 가져온 구독에 속하지 않게 됩니다.

그다음 “프록시” 페이지에서 파싱 결과를 확인합니다. 노드 선택, 자동 선택, 장애 조치 또는 용도별 그룹 등 여러 프록시 그룹이 보여야 합니다. 프록시 그룹 이름은 설정 제공자가 정하므로 예시와 다를 수 있습니다. 프록시 그룹 하나를 펼쳐 내부에 노드, 다른 프록시 그룹 또는 DIRECT 같은 정책이 있는지 확인합니다. 프록시 페이지가 비어 있거나 기본 항목만 표시되거나 설정 파싱 실패가 명확히 표시되면 시스템 프록시를 시작하지 말고 구독 페이지로 돌아가 다시 업데이트합니다.

구독 가져오기에 실패하면 먼저 주소가 완전한지 확인한 다음 현재 네트워크에서 구독 주소에 액세스할 수 있는지 확인합니다. 채팅 앱이나 문서에서 복사한 링크라면 줄바꿈이 섞이지 않았는지 살펴보세요. 이번 실패로 생성된 빈 설정 항목을 삭제하고 다시 붙여넣어 가져올 수도 있습니다. 오류 메시지에 YAML 형식, 필드 유형, 프록시 그룹 참조 문제가 나타난다면 클라이언트는 내용을 받아왔지만 설정 구조가 파싱을 통과하지 못한 것입니다. 이 경우 설정 출처를 수정해야 하며 기본 연결 스위치로 구조 오류를 해결할 수는 없습니다.

구독이 성공적으로 추가되면 “업데이트”를 한 번 수동 실행하고 업데이트 시간이 바뀌는지 확인하는 것이 좋습니다. 이 단계는 클라이언트가 현재 캐시뿐 아니라 이후 구독 업데이트도 가져올 수 있는지 확인합니다. 완료 후 새 설정을 선택된 상태로 유지하고 두 번째 단계에서 프록시 모드를 선택합니다. YAML 구문, 프록시 그룹 참조, 규칙 집합 구조에 대한 자세한 설명은 프로토콜 및 코어 기술 참고서에서 확인할 수 있습니다. 이 페이지에서는 첫 연결에 필요한 작업만 다룹니다.

STEP 02 / ROUTING

프록시 모드 선택: 규칙 모드를 먼저 사용하고 프록시 그룹의 출구를 지정하세요

설정을 활성화한 뒤 “프록시” 페이지 또는 클라이언트 홈 화면의 모드 선택 영역으로 이동합니다. 일반적인 모드는 규칙, 전역, 직결입니다. 처음 설정할 때는 “규칙” 모드, 즉 Rule을 선택하는 것이 좋습니다. 이 모드에서는 각 연결이 설정의 규칙을 위에서부터 순서대로 비교하고, 처음 일치한 규칙에 따라 해당 프록시 그룹으로 처리됩니다. 프록시가 필요한 요청은 프록시 정책으로, 직결에 적합한 요청은 DIRECT로, 명시적으로 거부할 요청은 REJECT로 처리될 수 있습니다.

“전역” 모드는 대부분의 트래픽을 지정한 하나의 프록시 그룹으로 전달하므로 특정 노드가 연결되는지 임시로 테스트할 때 유용하지만, 규칙 설정을 이해하기 위한 시작점으로는 적합하지 않습니다. “직결” 모드는 트래픽을 직접 연결하며 프록시를 일시 중지하거나 비교 점검할 때 사용합니다. 모드 선택은 전체 처리 방식만 정할 뿐 구체적인 노드까지 선택한 것은 아니므로, 규칙 모드로 전환한 뒤에도 프록시 그룹을 확인해야 합니다.

프록시 페이지에서 주요 노드 선택 그룹을 찾습니다. 설정에 따라 “노드 선택”, “Proxy”, “수동 선택” 등으로 표시될 수 있습니다. 해당 프록시 그룹을 클릭하고 목록에서 사용할 수 있는 노드를 선택합니다. 자동 선택 그룹이 제공된다면 자동 정책을 먼저 선택해 설정된 테스트 방식에 따라 클라이언트가 출구를 고르게 할 수도 있습니다. 노드를 선택하면 프록시 그룹에 현재 선택 항목의 이름이 표시되는 경우가 많습니다. 일부 프록시 그룹은 다른 프록시 그룹을 내부에서 참조하므로 자동 선택, 장애 조치, 지역별 그룹이 표시되는 것은 이상한 일이 아닙니다. 이는 출구를 계층적으로 관리하기 위한 설정 구조입니다.

이제 클라이언트의 연결 테스트 기능을 사용할 수 있지만, 테스트 결과만으로 전체 설정이 적용되었다고 판단하지는 마세요. 테스트는 보통 클라이언트가 특정 노드에 연결을 시도할 수 있는지만 확인합니다. 브라우저와 다른 앱이 클라이언트로 들어오는지는 다음 단계의 시스템 프록시 또는 TUN 설정에도 달려 있습니다. 모든 노드가 즉시 사용할 수 없음으로 표시되면 구독을 업데이트하고 네트워크를 바꾸거나 시스템 시간을 확인하세요. 특정 노드 하나만 문제가 있다면 같은 프록시 그룹에서 다른 노드로 바꿔 다시 테스트합니다.

선택을 마친 뒤 여러 모드를 계속 바꾸지 마세요. 규칙 모드와 명확한 프록시 그룹 출구를 유지해야 이후 검증을 반복해서 수행할 수 있습니다. 연결에 실패해도 문제가 구독 파싱, 노드 연결, 시스템 프록시, 규칙 매칭 중 어디에 있는지 정확히 판단할 수 있습니다. 세 가지 모드의 자세한 사용 사례는 Clash 규칙, 전역, 직결 모드의 차이에서 확인할 수 있습니다. 처음 설정할 때는 규칙 모드가 일반적인 시작점이라는 점만 기억하면 됩니다.

STEP 03 / CONNECTION

연결 시작: 시스템 프록시를 먼저 켜고 필요할 때 TUN을 활성화하세요

모드와 노드를 선택한 뒤 클라이언트 홈 화면 또는 “설정” 페이지로 돌아가 “시스템 프록시” 스위치를 켭니다. 시스템 프록시는 운영체제의 프록시 설정을 따르는 앱 요청을 Clash의 수신 포트로 보내고, 현재 설정에 따라 규칙을 매칭합니다. Windows와 macOS의 주요 브라우저 대부분은 시스템 프록시 설정을 읽으므로 첫 확인에 적합하며 적용 범위도 명확합니다.

스위치를 켠 뒤 클라이언트가 계속 실행 중인지 확인합니다. 데스크톱 클라이언트는 보통 트레이나 메뉴 막대에 아이콘을 남기며, 메인 창을 닫는 것이 프로그램 종료를 의미하지 않을 수 있습니다. 그러나 트레이 메뉴에서 종료를 선택하면 시스템 프록시가 사용하는 로컬 수신 서비스가 중단될 수 있습니다. 처음 테스트할 때는 클라이언트 창을 열어 두고 연결 기록과 오류 메시지를 바로 확인하는 것이 좋습니다. 시스템에서 방화벽 네트워크 액세스를 요청하면 현재 네트워크 환경에 맞게 필요한 로컬 통신을 허용합니다.

Android와 iOS의 연결은 시스템 VPN 인터페이스를 통해 처리됩니다. 홈 화면의 연결 버튼을 누르면 시스템에서 VPN 설정 또는 연결을 허용할지 묻습니다. 승인하면 상태 표시줄에 보통 시스템 VPN 표시가 나타납니다. 모바일에서는 데스크톱의 “시스템 프록시” 스위치를 따로 찾을 필요가 없지만, 클라이언트 홈 화면에 연결됨으로 표시되는지와 올바른 설정이 활성화되어 있는지는 확인해야 합니다.

일부 앱은 시스템 프록시를 따르지 않으며, 일부 명령줄 도구, 게임, 특수 네트워크 프로그램은 직접 연결을 만들 수 있습니다. 이런 경우 TUN 모드 활성화를 고려할 수 있습니다. TUN은 가상 네트워크 인터페이스를 통해 더 넓은 범위의 트래픽을 처리하지만 관리자 권한, 네트워크 확장 승인 또는 시스템 VPN 권한이 필요할 수 있습니다. 처음 설정할 때 시스템 프록시, TUN, DNS, 우회 목록을 동시에 변경하지 마세요. 먼저 시스템 프록시로 브라우저를 확인한 뒤 실제 앱 요구에 따라 TUN을 별도로 켜야 각 설정의 변화를 쉽게 판단할 수 있습니다.

시스템 프록시를 켠 직후 어떤 웹사이트에도 접속할 수 없다면 먼저 스위치를 꺼 기존 네트워크를 복구합니다. 그런 다음 클라이언트 코어가 시작되었는지, 현재 설정이 유효한지, 프록시 포트를 다른 프로그램이 사용 중인지 확인합니다. 연결이 끊긴 상태에서 여러 설정을 연속으로 바꾸면 어떤 변경으로 연결이 복구되거나 중단되었는지 알기 어려워집니다. “클라이언트 실행 상태—현재 설정—프록시 모드—프록시 그룹 노드—시스템 프록시” 순서로 하나씩 확인하세요.

연결 스위치가 안정되면 규칙 모드를 유지한 채 다음 단계에서 확인합니다. 버튼 색이 바뀌었는지만 보지 마세요. 스위치 상태는 설정 활성화 요청이 처리되었다는 뜻일 뿐, 브라우저 트래픽이 코어로 들어갔거나 예상한 규칙과 일치했다는 증거는 아닙니다. 실제 연결 기록이 전체 경로가 정상인지 판단하는 중요한 근거입니다.

STEP 04 / OBSERVATION

적용 여부 확인: 웹페이지, 연결 기록, 규칙 매칭을 함께 확인하세요

이제 브라우저를 열고 새 탭에서 평소 안정적으로 접속되는 웹사이트를 방문합니다. 웹페이지가 정상적으로 로드되면 프록시 그룹으로 처리될 것으로 예상되는 대상에도 접속해 보세요. 핵심은 웹페이지가 열리는지만 보는 것이 아니라 서로 다른 유형의 요청을 만들어 클라이언트에 직결 및 프록시 규칙 결과가 표시되도록 하는 것입니다. 테스트할 때는 브라우저의 다른 다운로드 작업이나 백그라운드 페이지를 가능한 한 닫아 연결 목록의 혼선을 줄이세요.

Clash Verge Rev로 돌아와 “연결” 또는 “로그” 페이지를 엽니다. 연결 목록에는 보통 요청 대상, 매칭된 규칙, 사용된 프록시 그룹, 최종 출구가 표시됩니다. 방금 브라우저에서 발생한 요청을 찾아 실제로 클라이언트에 들어왔는지 확인합니다. 목록에 새 기록이 전혀 없다면 브라우저가 시스템 프록시를 읽지 않았거나 다른 프록시 확장을 사용 중일 수 있습니다. 먼저 시스템 프록시가 계속 켜져 있는지 확인하고, 브라우저 네트워크를 가로채는 다른 설정을 잠시 끈 다음 테스트 페이지를 다시 로드합니다.

연결 기록이 보이면 규칙 매칭도 확인합니다. 직결로 예상한 요청은 DIRECT로 표시되거나 최종 선택이 직결인 프록시 그룹으로 들어가야 합니다. 프록시로 예상한 요청은 설정에서 지정한 프록시 그룹으로 들어가고, 앞 단계에서 선택한 노드나 하위 정책이 표시되어야 합니다. 모든 요청이 같은 출구로 들어간다면 먼저 현재 모드가 전역이 아닌지 확인합니다. 규칙 모드가 맞다면 설정에 해당 규칙이 포함되어 있는지, 더 포괄적인 항목이 앞에서 먼저 매칭되고 있지는 않은지 확인합니다.

시스템 프록시를 켠 상태에서 주요 프록시 그룹의 다른 사용 가능 노드로 바꾼 뒤 테스트 페이지를 새로 고쳐 비교할 수도 있습니다. 연결 목록의 새 요청에는 변경된 출구가 표시되어야 합니다. 완료 후 원래 노드로 돌아갑니다. 이 작업을 통해 프록시 그룹 선택이 이후 연결에 실제로 영향을 주는지, 페이지가 단순히 브라우저 캐시를 읽은 것인지 확인할 수 있습니다. 기존 연결은 이전 출구를 계속 사용할 수 있으므로 전환 후 새로 생성된 요청을 기준으로 판단하세요.

모바일에서 확인할 때는 앱을 완전히 종료한 뒤 다시 열어 테스트하는 것이 좋습니다. 그래야 앱이 전환 전에 만들어진 장기 연결을 재사용하지 않습니다. Android와 iOS의 시스템 VPN 표시가 계속 보이고 클라이언트 연결 페이지에도 새 기록이 생성되어야 합니다. 특정 앱에만 기록이 없고 브라우저 테스트는 정상이라면 앱 자체의 연결 방식이나 시스템 트래픽 분류 범위가 원인일 수 있으므로 클라이언트의 TUN, 우회 설정, 앱별 프록시 옵션을 추가로 검토합니다.

마지막으로 구독 페이지에서 현재 설정이 계속 활성화되어 있는지 확인하고 시스템 프록시 또는 모바일 연결 스위치의 위치를 기억해 둡니다. 이제 구독 가져오기, 모드 선택, 시스템 연결, 규칙 확인이 하나의 전체 흐름으로 완성되었습니다. 일상적으로는 구독을 주기적으로 업데이트하고 프록시 그룹에서 적절한 출구를 선택하며, 문제가 생길 때 연결 기록을 확인하면 됩니다. 설정 전체를 다시 가져올 필요는 없습니다.

BASIC TROUBLESHOOTING

첫 연결이 되지 않을 때는 경로 순서대로 점검하세요

문제를 해결할 때는 노드를 계속 바꾸기보다 설정 진입점에 가까운 곳부터 확인해야 합니다. 첫 번째는 구독입니다. 업데이트 오류가 없는지, 새 설정이 활성화되어 있는지, 프록시 페이지에 전체 프록시 그룹이 표시되는지 확인합니다. 두 번째는 모드와 출구입니다. 규칙 모드를 사용하고 주요 프록시 그룹에서 사용할 수 있는 노드를 선택했는지 확인합니다. 세 번째는 클라이언트 연결입니다. 데스크톱에서는 시스템 프록시를, 모바일에서는 시스템 VPN 상태를 확인하고 더 넓은 범위를 처리해야 할 때 TUN을 점검합니다. 네 번째로 규칙과 DNS 같은 심화 설정을 확인합니다.

구독은 업데이트되지만 모든 노드의 테스트가 실패한다면 현재 네트워크를 바꾸거나 클라이언트 코어를 재시작한 뒤 로그에서 처음 나타난 명확한 오류를 확인합니다. 노드 테스트는 정상이지만 브라우저 연결 기록이 없다면 시스템 프록시와 브라우저 자체 프록시 설정을 중점적으로 살펴봅니다. 연결 기록은 있지만 웹사이트 동작이 예상과 다르면 노드 이름만 보지 말고 매칭된 규칙과 프록시 그룹을 확인합니다. 일부 도메인에서만 DNS 조회가 비정상이라면 설정의 DNS 구간, 시스템 DNS 상태, 다른 네트워크 도구의 동시 실행 여부를 추가로 점검합니다.

한 번에 하나의 설정만 변경하고 변경 후 새 테스트 요청을 생성하세요. 여러 옵션을 동시에 켜는 것보다 조금 느리지만 원인과 결과를 명확하게 추적할 수 있습니다. 구체적인 오류 코드, 구독 업데이트 문제, TUN 권한 문제가 발생하면 자주 묻는 질문에서 유형별 해결 방법을 찾아보세요. 프로토콜 특성, 코어 관계, 설정 호환성을 비교하려면 기술 참고서를 계속 읽어보세요.