Clash Verge Rev 화면 안내: 프록시·프로필·로그 페이지 사용법

먼저 구분하기: 인터페이스, 설정, mihomo 코어

Clash Verge Rev는 구독을 가져오고 설정을 관리하며 연결 상태를 보여 주는 데스크톱 클라이언트입니다. mihomo는 프록시 연결, DNS, 규칙 매칭을 실제로 처리하는 코어입니다. 인터페이스에 노드가 보여도 앱 트래픽이 코어로 들어간다는 뜻은 아닙니다. 시스템 프록시를 켰더라도 모든 연결이 원격 노드를 거치는 것은 아닙니다. 이 두 가지를 이해하면 사이드바의 각 페이지를 더 쉽게 파악할 수 있습니다.

이 글은 Clash Verge Rev 2.x의 일반적인 한국어 인터페이스를 기준으로 설명합니다. 세부 버전, 창 너비, 운영체제에 따라 버튼 위치나 일부 명칭이 다를 수 있으므로 현재 설치된 버전에 표시되는 내용을 기준으로 확인하세요. 아래에서는 ‘프록시 → 프로필 → 연결 → 규칙 → 로그 → 설정’ 순서로 각 페이지의 역할을 설명합니다. 실제 사이드바 순서는 다를 수 있습니다.

페이지	주요 작업	확인할 수 있는 내용
프록시	정책 선택, 지연 시간 테스트, 모드 전환	현재 정책 그룹은 어떤 노드를 사용하나요?
프로필	구독 프로필 가져오기, 업데이트, 활성화	노드와 규칙은 어디에서 가져오나요?
연결	실시간 요청, 정책 체인, 트래픽 확인	이 요청은 실제로 어떤 경로를 거쳤나요?
규칙	현재 로드된 분기 규칙 확인	어떤 조건에서 이 정책이 적용되나요?
로그	코어 실행 정보와 오류 확인	요청은 어느 단계에서 실패했나요?
설정	시스템 프록시, TUN, 수신 포트 관리	앱 트래픽은 어떻게 코어로 들어오나요?

프록시 페이지: 정책 그룹과 노드를 선택하고 지연 시간 확인하기

노드와 정책 그룹은 서로 다른 개념입니다

‘프록시’를 열면 모든 요청이 공유하는 노드 목록이 아니라 여러 정책 그룹이 먼저 표시되는 경우가 많습니다. 정책 그룹은 규칙에서 참조하는 출구 선택기입니다. 노드를 포함할 수도 있고 다른 정책 그룹을 포함할 수도 있습니다. 구독 제공자가 ‘노드 선택’, ‘자동 선택’, ‘스트리밍’ 등으로 이름을 붙일 수 있지만, 이는 설정에 따라 달라지며 클라이언트의 고정 메뉴가 아닙니다.

먼저 사용할 정책 그룹을 찾고 후보 목록을 펼칩니다.
그룹 유형이 select이면 노드나 하위 정책 그룹을 클릭한 뒤 선택 상태가 바뀌었는지 확인합니다.
그룹 내 지연 시간 테스트를 실행하고 후보 결과가 나올 때까지 기다립니다. 테스트를 연속해서 반복 실행하지 마세요.
새 웹 요청을 보낸 다음 ‘연결’ 페이지에서 정책 체인을 확인하세요. 노드 카드만 보고 판단하지 마세요.

url-test는 탐지 결과에 따라 후보 출구를 자동으로 선택하고, fallback은 설정된 순서대로 사용할 수 있는 출구를 찾으며, load-balance는 설정된 정책에 따라 연결을 분산합니다. 동작 방식은 설정에 따라 달라지므로 모든 그룹이 특정 노드 하나를 계속 선택하는 수동 목록이라고 볼 수 없습니다.

규칙·전역·직접 연결 모드

규칙 모드(Rule): 현재 규칙 집합에 따라 출구를 결정합니다. 일상적으로 직접 연결과 프록시 연결을 구분해야 한다면 먼저 이 모드를 사용하세요.
전역 모드(Global): 코어로 들어온 연결은 일반적으로 GLOBAL 정책을 사용합니다. 문제를 확인할 때는 해당 정책에서 실제로 선택된 출구도 확인해야 합니다.
직접 연결 모드(Direct): 코어로 들어온 연결을 직접 연결합니다. 보통 비교 테스트에 사용합니다.

일부 버전에서는 모드 선택이 프록시 페이지 상단에 있고, 다른 버전에서는 전역 빠른 설정 영역에 표시될 수 있습니다. 위치와 관계없이 모드 자체가 앱 트래픽을 코어로 보내지는 않습니다. 앱이 시스템 프록시를 우회하고 TUN에도 연결되지 않았다면 전역 모드로 바꿔도 프록시를 거친다고 판단할 수 없습니다.

프로필 페이지: 구독 가져오기, 업데이트, 활성화

‘프로필’에서는 코어가 사용할 설정 소스를 관리합니다. 원격 구독은 일반적으로 노드, 정책 그룹, 규칙 및 관련 매개변수를 제공하고, 로컬 프로필은 컴퓨터에 저장된 파일을 사용합니다. 가져오기에 성공했다는 것은 클라이언트가 저장할 설정 내용을 받았다는 뜻일 뿐입니다. 해당 프로필을 활성화했는지, 코어가 정상적으로 불러왔는지도 확인해야 합니다.

처음 가져올 때의 순서

‘프로필’로 이동해 구독 링크 입력란에 서비스 제공자가 준 전체 URL을 붙여 넣고 가져오기를 실행합니다. 링크에 접속 정보가 포함될 수 있으므로 공개 게시판에 올리지 마세요.
프로필 카드가 나타날 때까지 기다린 뒤 이름과 업데이트 시간을 확인합니다. 가져오기 오류가 발생하면 먼저 오류 메시지를 확인하세요. 구독 주소를 노드 주소로 착각해 직접 입력하면 안 됩니다.
해당 카드를 현재 프로필로 선택하고 활성화 상태로 표시되는지 확인합니다. 선택 표시 방식은 버전에 따라 다를 수 있습니다.
‘프록시’로 돌아가 정책 그룹과 노드가 표시되는지 확인합니다. 이전 내용이 그대로라면 프로필 페이지에서 다른 카드가 활성화되어 있지 않은지 확인하세요.

구독 업데이트와 프로필 전환은 다릅니다

업데이트는 같은 소스에서 설정을 다시 가져오는 작업이고, 활성화는 특정 설정을 현재 실행에 적용하는 작업입니다. 구독 카드가 두 개 있어도 한쪽을 업데이트했다고 해서 그 프로필이 자동으로 활성화되는 것은 아닙니다. 노드 수, 요금제 트래픽 정보, 만료일은 구독 서비스가 관련 데이터를 제공하는지에 따라 달라집니다. 클라이언트가 이런 정보를 임의로 만들지는 않습니다.

규칙을 수정할 때는 원격 원본 파일, 로컬 프로필, 클라이언트의 병합·스크립트 처리 중 무엇을 변경하는지 먼저 구분하세요. 원격 설정을 복사해 직접 수정하면 다음 업데이트 때 덮어써질 수 있습니다. 병합 기능을 사용한다면 최종 실행 설정에 원하는 내용이 반영됐는지 확인하세요. YAML의 들여쓰기와 필드 유형, 정책 그룹 이름이 정확해야 합니다. 편집기에서 저장됐다는 이유만으로 코어가 설정을 받아들였다고 판단하지 마세요.

연결 페이지: 요청이 실제로 사용한 출구 확인하기

‘연결’은 코어에 들어온 연결 기록을 보여 줍니다. 트래픽 분기 결과를 확인하기에 가장 직접적인 페이지입니다. 대상 호스트, 대상 주소, 네트워크 유형, 업로드·다운로드량, 매칭된 규칙, 정책 체인 등의 항목을 확인할 수 있습니다. 프로세스 이름의 표시 여부는 시스템 권한, 트래픽 처리 방식, 코어 설정에 따라 달라집니다. 프로세스 이름이 보이지 않는다고 해서 연결에 문제가 있다고 단정할 수는 없습니다.

새 요청 한 번으로 확인하기

‘연결’ 페이지를 열어 둔 상태에서 브라우저로 대상 웹페이지를 새로 엽니다. 다른 앱의 백그라운드 요청은 되도록 줄이세요.
도메인으로 기록을 필터링합니다. IP 주소만 보인다면 요청 시간과 대상 주소를 함께 확인해 구분하세요.
해당 연결의 상세 정보를 열고 매칭 규칙, 정책 그룹, 최종 노드를 기록합니다. 정책 체인에 여러 단계의 그룹이 포함될 수 있으므로 첫 번째 그룹 이름만 보면 안 됩니다.
DIRECT로 표시되면 규칙 페이지에서 원인을 확인하세요. 예상한 노드를 거쳤다면 웹페이지 응답이나 외부 IP 확인으로 결과를 검증합니다.

노드를 바꾼 뒤에도 기존 TCP 장기 연결이나 HTTP/2 세션은 이전 출구를 계속 사용할 수 있습니다. 테스트할 때는 새 요청을 보내고, 필요한 경우 해당 연결을 닫은 뒤 다시 접속하세요. 연결 페이지에서 연결을 종료하면 해당 세션이 끊깁니다. 다운로드, 화상 회의, 원격 터미널이 중단될 수 있으니 작업 범위를 먼저 확인하세요.

연결 페이지에 대상 기록이 잠시 보이지 않는다면 노드가 작동하지 않는다고 바로 판단하지 말고 트래픽이 코어에 들어오는지 먼저 확인하세요. 브라우저가 별도의 프록시 설정을 사용하거나 앱이 시스템 프록시를 무시할 수 있습니다. 반대로 캐시된 웹페이지가 표시되어도 예상한 새 요청이 발생하지 않았을 수 있습니다.

규칙 페이지: 매칭 조건과 순서, 최종 정책 확인하기

‘규칙’에는 현재 실행 설정에 로드된 규칙이 표시됩니다. 대표적인 유형으로 정확한 도메인을 지정하는 DOMAIN, 도메인 접미사를 지정하는 DOMAIN-SUFFIX, IP 대역을 지정하는 IP-CIDR, 규칙 집합을 참조하는 RULE-SET, 마지막에 기본 처리로 쓰이는 MATCH가 있습니다. 일반 규칙은 보통 순서대로 매칭되며 앞에서 일치한 규칙이 최종 결과에 영향을 줍니다.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,노드 선택

이 예시는 example.com과 그 하위 도메인으로 향하는 요청을 직접 연결하고 나머지는 ‘노드 선택’에 넘깁니다. 규칙 순서를 설명하기 위한 예시일 뿐 전체 설정을 대체할 수 없습니다. 두 번째 줄에서 참조하는 정책 그룹이 실제로 존재해야 하며 이름도 정확히 일치해야 합니다.

규칙 페이지와 연결 페이지를 함께 확인하세요

규칙 페이지에서 정의 확인: 조건이 무엇인지, 어느 순서에 있는지, 어떤 정책을 참조하는지 확인합니다.
연결 페이지에서 결과 확인: 특정 요청이 어떤 규칙과 일치했고 마지막에 어떤 노드를 거쳤는지 확인합니다.
프로필 페이지에서 설정 소스 수정: 장기적으로 조정하려면 실제 적용 중인 프로필이나 병합 규칙 설정을 찾습니다.

인터페이스에 대상 IP만 표시되고 사용할 수 있는 도메인 정보가 없다면 도메인 규칙이 예상대로 매칭되지 않을 수 있습니다. DNS 처리 방식, 앱이 직접 도메인을 해석하는지, 도메인 스니핑이 활성화되어 있는지를 함께 살펴보세요. 규칙 페이지에 규칙이 표시된다고 해서 모든 요청에 그 규칙을 매칭할 정보가 갖춰져 있다는 뜻은 아닙니다.

로그 페이지: 시간순으로 오류 단계 찾기

‘로그’는 실행 이벤트와 오류가 발생한 맥락을 확인하는 곳이지, 지연 시간 순위를 보는 페이지가 아닙니다. 일반적으로 info, warning, error, debug 등의 수준이 있습니다. 평소에는 필요한 정보만 남기세요. 문제를 확인할 때만 잠시 상세 수준을 높이고 재현한 뒤 원래대로 돌리면 로그가 지나치게 많아지는 것을 막고 접속 정보 노출도 줄일 수 있습니다.

오류를 재현한 뒤 주변 기록까지 확인하세요

현재 시간, 활성 프로필, 선택한 노드, 시스템 프록시와 TUN 중 어떤 방식을 사용하는지 기록합니다.
‘로그’를 열고 대상 웹페이지를 새로 고치는 등 실패한 작업을 한 번만 재현합니다.
같은 시간대의 기록을 찾아 앞뒤 몇 줄과 함께 읽으세요. 마지막 timeout만 잘라서 확인하지 마세요.
오류를 설정 로드, 로컬 수신, DNS, 원격 연결, 프로토콜 핸드셰이크 중 하나로 분류한 뒤 해당 부분만 조정합니다.

로그 단서	먼저 확인할 항목	이 단서만으로 단정할 수 없는 내용
`address already in use`	로컬 수신 포트를 다른 프로그램이 사용 중인지 확인	이 내용만으로 구독이 만료됐다고 단정할 수 없음
`lookup` 및 이름 해석 오류	오류가 발생한 도메인, DNS 업스트림, 연결 가능 여부	특정 단어 하나만으로 모든 노드가 작동하지 않는다고 단정할 수 없음
`i/o timeout`	시간 초과가 DNS 조회, 연결 시도, 데이터 수신 중 어느 단계에서 발생했는지	비밀번호 오류라고 단정할 수 없음
`connection refused`	대상 주소와 포트, 서비스의 수신 상태	규칙을 바꾸면 해결된다고 단정할 수 없음

같은 유형의 오류에도 원인은 여러 가지일 수 있습니다. 예를 들어 원격 연결 시도 시간 초과는 노드 회선에 연결할 수 없어서 발생할 수도 있고, 로컬 네트워크에서 차단되어 생길 수도 있습니다. DNS, 포트, 모드를 연달아 바꾸기보다 다른 노드나 다른 로컬 네트워크를 하나씩 비교해 보는 편이 원인을 찾기 쉽습니다. 로그를 제출할 때는 오류 유형과 시간 순서를 남기고 구독 주소, 인증 정보, 불필요한 접속 도메인은 삭제하세요.

설정 페이지: 시스템 프록시, TUN, 포트의 역할 구분하기

‘설정’에서 가장 혼동하기 쉬운 부분은 시스템 프록시와 TUN입니다. 시스템 프록시는 운영체제 설정에 프록시 주소를 지정하며 해당 설정을 따르는 앱에 적용됩니다. TUN은 가상 네트워크 인터페이스를 만들고 라우팅 및 DNS 설정을 통해 트래픽을 처리하며, 적용 범위는 실제 설정에 따라 달라집니다. 둘의 차이는 ‘일반 노드’와 ‘고속 노드’의 차이가 아니며 원격 서버 회선 품질을 자동으로 높여 주지도 않습니다.

시스템 프록시 확인 경로

‘설정’에서 ‘시스템 프록시’ 스위치를 찾습니다. 수신 포트는 보통 같은 페이지의 포트 또는 Clash 설정 영역에서 확인할 수 있습니다. 일부 버전에서는 관련 항목이 ‘설정’ → ‘Clash 설정’에 있습니다. 버전에 따라 메뉴 이름이 다르면 현재 페이지에 표시되는 항목을 기준으로 확인하세요. 다른 클라이언트의 메뉴 이름을 따라 찾지 마세요.

예를 들어 컴퓨터의 혼합 포트가 실제로 7897로 설정되어 있다면 프록시를 수동 설정하는 앱에는 127.0.0.1:7897을 입력해야 합니다. 현재 포트가 다르면 현재 값을 사용하세요. 7890이나 7897을 모든 설치 환경에 적용되는 고정값으로 간주해서는 안 됩니다. 혼합 포트는 HTTP와 SOCKS 프록시 연결을 모두 받을 수 있지만 앱에서는 지원하는 프로토콜을 선택해야 합니다.

TUN과 서비스 권한

TUN을 활성화할 때 클라이언트에서 서비스를 설치하거나 시작하고 관리자 권한을 부여하라는 메시지가 표시될 수 있습니다. 먼저 안내에 따라 서비스를 설정한 다음 스위치 상태와 로그를 확인하세요. 가상 네트워크 어댑터, 라우팅, DNS 설정에 실패했다면 버튼이 켜져 있다는 사실만으로 트래픽이 정상적으로 처리된다고 볼 수 없습니다. 회사 VPN, 다른 프록시 앱, 보안 소프트웨어도 라우팅에 영향을 줄 수 있으니 문제를 확인하기 전에 기존 네트워크 설정을 기록해 두세요.

가져오기부터 연결 확인까지 한 번에 진행하기

프로필 페이지: 구독을 가져오고 해당 프로필을 활성화한 다음 로드 오류가 없는지 확인합니다.
프록시 페이지: 규칙 모드를 선택하고 수동 정책 그룹에서 노드를 하나 선택한 뒤 지연 시간을 테스트합니다.
설정 페이지: 시스템 프록시를 켜고 로컬 수신 포트를 확인합니다. 다른 네트워크 설정은 그대로 둡니다.
연결 페이지: 대상 웹페이지에 접속한 뒤 새 연결에 적용된 규칙과 최종 출구를 확인합니다.
규칙 페이지: 출구가 예상과 다르면 해당 규칙과 그 앞에 있는 매칭 항목을 확인합니다.
로그 페이지: 연결이 실패하면 시간순으로 오류를 찾고 해당 단계만 점검합니다.

페이지 간 역할을 기억해 두면 됩니다. 프로필은 사용할 노드와 규칙을 결정하고, 프록시는 정책 선택 방식을 정하며, 설정은 트래픽이 코어로 들어오는 경로를 정합니다. 연결은 실제 결과를 보여 주고 규칙은 분기 조건을 설명하며 로그는 실패 원인을 파악하는 데 도움을 줍니다. ‘노드는 있는데 인터넷이 안 됨’, ‘노드를 바꿨는데 출구가 그대로임’, ‘특정 사이트가 계속 직접 연결됨’ 같은 문제도 이 흐름에 따라 단계별로 확인할 수 있습니다.

처음 설치하거나 플랫폼을 선택하려면 입문 가이드를 확인하세요. DNS, 포트, 시스템 프록시 문제를 살펴보려면 자주 묻는 질문을 참고할 수 있습니다. 정책 그룹, 코어, 규칙 집합 같은 용어가 낯설다면 설정을 바꾸기 전에 용어집부터 확인하세요.