Clash Verge 인터페이스 기능 한눈에 보기: 프록시·프로필·로그 페이지 사용법

인터페이스의 트래픽 처리 순서부터 이해하기

하나의 연결은 여러 단계를 거칩니다. 프로필 페이지는 노드, 전략 그룹, 규칙, DNS 등의 실행 매개변수를 제공합니다. 프록시 페이지에서는 각 전략 그룹이 사용할 노드를 정합니다. 시스템 프록시 또는 TUN 모드는 기기의 트래픽을 코어로 전달하고, 규칙 시스템은 도메인, IP, 포트 또는 프로세스에 적용할 전략 그룹을 판단합니다. 연결 및 로그 페이지에서는 처리 결과를 보여줍니다.

1. 프로필 가져오기: 구독 주소 또는 로컬 YAML 파일로 프로필을 등록하고 처음 업데이트합니다.
2. 프로필 활성화: 프로필 목록에서 대상 프로필을 선택해 현재 실행 프로필로 지정합니다.
3. 노드 선택: 프록시 페이지에서 주요 전략 그룹을 확인하고 사용할 수 있는 노드를 선택합니다.
4. 트래픽 가로채기: 사용 범위에 맞춰 시스템 프록시를 켜거나, 더 폭넓은 트래픽 처리가 필요할 때 TUN 모드를 활성화합니다.
5. 결과 확인: 대상 사이트에 접속하면서 연결 목록, 규칙 매칭 및 로그 정보를 함께 확인합니다.

프로필 페이지: 구독을 가져오고 현재 프로필 확인하기

프로필 페이지는 전체 작업 흐름의 출발점이며 보통 Profiles라고 표시됩니다. 이곳에는 구독 프로필, 로컬 프로필, 그리고 병합이나 스크립트 처리 항목이 저장됩니다. 구독 주소 자체가 노드는 아닙니다. 프로필 내용을 가져오는 진입점이며, 업데이트가 완료되어야 클라이언트가 노드, 전략 그룹, 규칙 등의 데이터를 확보합니다.

구독을 가져올 때 확인할 상태

구독 입력 영역에 전체 주소를 붙여 넣은 뒤 가져오기를 실행합니다. 프로필 카드가 나타났다고 해서 내용이 반드시 정상적으로 사용 가능한 것은 아닙니다. 이름, 업데이트 시간, 업데이트 작업의 완료 여부도 확인해야 합니다. 프로필 제공자가 전용 User-Agent, 인증 매개변수 또는 특정 네트워크에서의 접속을 요구한다면 해당 제공자의 안내를 따르세요.

• 붙여 넣은 내용이 완전한 HTTP 또는 HTTPS 주소인지, 앞뒤에 불필요한 공백이 없는지 확인합니다.
• 업데이트 후 프록시 페이지에서 예상한 노드와 전략 그룹이 생성되었는지 확인합니다.
• 프로필이 여러 개 있을 때는 현재 선택 표시를 확인해 한 프로필을 편집하고 다른 프로필을 실행하는 실수를 피합니다.
• 구독 내용이 바뀌면 업데이트를 실행한 뒤 노드 이름, 전략 그룹과 기타 정보가 새로 반영되었는지 확인합니다.

로컬 YAML 프로필은 언제 적합한가

로컬 프로필은 규칙을 디버깅하거나, 노드를 직접 관리하거나, DNS 매개변수를 검증할 때 적합합니다. YAML은 들여쓰기와 데이터 구조에 민감하므로 목록 계층, 콜론 뒤의 공백, 필드의 소속이 모두 파싱에 영향을 줍니다. 프로필을 가져올 수 있다고 해서 모든 필드를 현재 mihomo 버전이 지원하는 것은 아닙니다. 파싱에 실패하면 먼저 로그에서 필드 이름과 줄 번호를 확인하세요.

proxies → proxy-groups → rules
          ↑
          전략 그룹이 노드를 참조함
rules는 최종적으로 연결을 전략 그룹, DIRECT 또는 REJECT에 전달함

규칙은 일반적으로 순서대로 매칭되며, 앞선 규칙이 일치하면 해당 전략을 적용합니다. 범위가 넓은 규칙을 너무 앞에 배치하면 뒤의 구체적인 도메인 규칙이 작동하지 않을 수 있습니다. 인터페이스의 프로필 편집 기능은 소규모 확인에 적합하고, 큰 폭으로 수정할 때는 먼저 원본 파일을 보관한 뒤 구간별로 검증해야 합니다.

프록시 페이지: 전략 그룹, 노드와 지연 시간 이해하기

프록시 페이지에는 프로필에 정의된 전략 그룹과 후보 항목이 표시됩니다. 상단에서는 규칙, 전역, 직접 연결 등의 실행 모드를 전환할 수 있고, 본문에는 전략 그룹이 카드나 목록으로 표시됩니다. 노드를 클릭하는 것은 보통 특정 전략 그룹의 현재 선택을 바꾸는 동작이며, 전체 프로필을 해당 노드로 전환하는 것은 아닙니다.

인터페이스에서 자주 보는 전략 그룹 유형의 차이

select 유형은 사용자가 노드 또는 하위 전략 그룹을 직접 선택합니다. url-test는 테스트 결과에 따라 조건에 맞는 후보를 자동으로 선택합니다. fallback은 사용 가능 여부와 순서를 중시하며 현재 후보가 실패하면 다음 후보로 전환합니다. load-balance는 설정된 전략에 따라 여러 후보에 연결을 분산합니다. 실제 동작은 테스트 주소, 간격, 허용 오차와 해시 전략의 영향도 받습니다.

하나의 전략 그룹이 다른 전략 그룹을 참조할 수도 있습니다. 따라서 인터페이스에 “진입 그룹이 자동 선택 그룹을 선택하고, 자동 선택 그룹이 다시 노드를 선택하는” 계층이 나타날 수 있습니다. 문제를 확인할 때는 규칙이 최종적으로 매칭된 그룹부터 시작해 각 단계의 현재 선택을 확인해야 하며, 특정 노드 카드의 색상만 봐서는 안 됩니다.

지연 시간 수치는 어떻게 이해해야 하나

지연 시간 테스트는 보통 프로필에 지정된 테스트 주소에 접속하며, 결과는 해당 탐색 경로의 응답 시간을 보여줍니다. 수치가 낮으면 후보 노드를 비교하는 데 도움이 되지만 다운로드 속도, 혼잡 시간대의 안정성, 모든 대상 사이트의 연결 품질을 직접 의미하지는 않습니다. 시간 초과는 노드 상태, 테스트 주소의 도달 가능성, DNS 조회 또는 로컬 네트워크 제한 때문에 발생할 수 있습니다.

• 규칙 모드: 규칙에 따라 연결을 프록시, 직접 연결 또는 거부로 처리하며 일상적인 사용에 적합합니다.
• 전역 모드: 대부분의 연결을 전역 전략 그룹으로 전달하며 노드의 기본 연결 상태를 잠시 확인할 때 적합합니다.
• 직접 연결 모드: 연결을 우선 직접 접속으로 처리하며 프록시 적용 전후의 차이를 비교할 때 사용할 수 있습니다.

규칙 모드에서 전역 모드로 전환한 뒤 접속이 되었다면 노드의 기본 연결은 정상일 가능성이 높고, 문제는 규칙 매칭, 전략 그룹 선택 또는 DNS 처리에 있을 수 있습니다. 전역 모드에서도 실패한다면 노드, 네트워크, 코어 상태와 트래픽 가로채기 방식을 계속 확인해야 합니다.

연결 페이지: 요청이 어떤 규칙을 거쳤는지 확인하기

연결 페이지에는 현재 코어를 통과하는 활성 연결이 기록됩니다. 일반적으로 대상 호스트, 대상 IP, 업로드 및 다운로드량, 연결 시간, 네트워크 유형, 매칭된 규칙과 최종 경로가 표시됩니다. 특정 애플리케이션의 트래픽이 Clash로 들어갔는지 판단하는 가장 직접적인 메뉴입니다.

대상 웹페이지를 연 뒤 도메인으로 연결을 필터링할 수 있습니다. 목록에 해당 도메인이 나타나고 특정 전략 그룹과 노드 경로가 표시되면 트래픽이 코어로 들어간 것입니다. 연결은 있지만 접속에 실패한다면 규칙, 대상 주소와 경로를 확인하세요. 목록에 기록이 전혀 없다면 브라우저 프록시 설정, 시스템 프록시 스위치, TUN 상태, 애플리케이션 자체의 시스템 프록시 우회 여부를 우선 확인해야 합니다.

연결 경로의 화살표는 무엇을 의미하나

일부 인터페이스는 전략 선택을 “미디어 전략 → 자동 선택 → 노드 A”와 같은 경로로 표시합니다. 규칙이 먼저 연결을 미디어 전략 그룹에 전달하고, 해당 그룹이 자동 선택 그룹을 참조한 뒤 최종적으로 노드 A가 아웃바운드 연결을 생성한다는 뜻입니다. 이 경로를 통해 선택이 어느 계층에서 이루어졌는지 파악할 수 있으며, 다른 전략 그룹을 수동으로 수정해도 현재 접속이 바뀌지 않는 이유를 설명할 수 있습니다.

연결 종료는 언제 유용한가

많은 애플리케이션은 기존 TCP, QUIC 또는 WebSocket 연결을 재사용합니다. 노드를 바꾼 뒤에도 이전 연결이 기존 경로를 유지하면 테스트 결과가 즉시 달라지지 않을 수 있습니다. 이때 연결 페이지에서 관련 연결을 종료한 후 페이지를 다시 로드하세요. 실시간 통신이나 다운로드 작업의 연결을 종료하면 현재 전송이 중단되므로 먼저 작업 상태를 확인해야 합니다.

로그 페이지: 프로필·DNS·연결 오류 구분하기

로그 페이지에는 코어 시작, 프로필 로드, DNS 조회, 규칙 매칭과 아웃바운드 연결 등의 이벤트가 표시됩니다. 첫 연결에 실패했을 때는 단순한 웹페이지 오류보다 로그가 더 유용합니다. 로그 수준은 일상적으로 읽기 쉬운 범위로 유지하고, 문제를 한 번 재현한 뒤 발생 시각을 기록하여 해당 시각 전후의 정보를 확인하는 것이 좋습니다.

자주 보이는 로그 메시지별 확인 방향

• 프로필 파싱 오류: YAML 들여쓰기, 필드 오탈자, 데이터 유형과 현재 코어의 필드 지원 여부를 확인합니다.
• DNS 조회 시간 초과: nameserver, 네트워크 도달 가능성, DNS 하이재킹 설정과 도메인 조회 모드를 확인합니다.
• 연결 거부: 대상 포트 또는 노드 서비스가 연결을 수락하지 않았거나 중간 네트워크 정책의 영향일 수 있습니다.
• 연결 시간 초과: 노드 주소 조회, 서버 도달 가능성, 전송 매개변수와 로컬 방화벽 정책을 확인합니다.
• 전략 또는 노드를 찾을 수 없음: 대개 프로필에서 참조한 이름의 불일치, 누락된 구독 내용 또는 병합 결과와 관련이 있습니다.

로그의 warning은 주의가 필요한 이상 상태나 호환성 안내를 의미하고, error는 대개 해당 작업의 실패를 나타냅니다. 다만 반드시 주변 문맥과 함께 판단해야 합니다. 예를 들어 보조 DNS 조회가 시간 초과되어도 다른 리졸버가 정상 응답할 수 있습니다. 한 줄만 잘라 보면 이후 결과를 놓치기 쉽습니다. 문제를 확인할 때는 오류 앞뒤의 여러 줄을 남기고 방금 실행한 접속과 관련된 내용인지 확인하세요.

로그에는 도메인, 노드 주소와 로컬 네트워크 정보가 포함될 수 있습니다. 스크린샷이나 텍스트를 공유하기 전에는 문제와 관련된 부분만 정리하고 구독 주소, 인증 매개변수와 개인 네트워크 식별 정보를 삭제하세요. 구독 링크에는 보통 접속 자격 증명이 포함되므로 그대로 공개해서는 안 됩니다.

설정 페이지: 시스템 프록시, TUN과 코어 상태

설정 페이지에서는 클라이언트 동작, 시작 시 실행, 시스템 프록시, TUN, 코어와 네트워크 매개변수를 관리합니다. 처음 사용하는 경우 시스템 프록시와 TUN 모드를 구분하는 것이 가장 중요합니다. 두 방식 모두 트래픽을 코어로 전달하지만 적용 범위와 시스템 권한 요구 사항이 다릅니다.

시스템 프록시는 브라우저와 일반 데스크톱 애플리케이션에 적합

시스템 프록시를 켜면 Clash Verge가 운영체제의 HTTP 및 HTTPS 프록시 주소를 로컬 리스닝 포트로 지정합니다. 시스템 프록시 설정을 따르는 브라우저와 애플리케이션은 요청을 코어로 보냅니다. 일부 애플리케이션은 별도의 프록시 설정을 사용하고, 일부 명령줄 프로그램은 환경 변수를 별도로 읽습니다. 따라서 시스템 프록시를 켠 뒤에도 연결 페이지에서 대상 프로그램의 트래픽이 실제로 들어오는지 확인해야 합니다.

TUN 모드는 더 넓은 범위의 트래픽 가로채기에 적합

TUN 모드는 가상 네트워크 인터페이스를 통해 IP 트래픽을 처리하므로 시스템 프록시를 읽지 않는 프로그램까지 더 폭넓게 지원하며, UDP 또는 투명 프록시가 필요한 환경에서도 자주 사용됩니다. 가상 네트워크 어댑터, 라우팅과 DNS 설정이 관련되어 활성화할 때 시스템 권한이 필요할 수 있습니다. 기기에서 다른 VPN, 가상 네트워크 어댑터 도구, 네트워크 필터링 소프트웨어 또는 기업 네트워크 구성 요소를 함께 사용한다면 라우팅 및 인터페이스 충돌에 주의하세요.

시스템 프록시와 TUN은 여러 기능을 동시에 켠다고 더 잘 작동하는 것이 아닙니다. 일상적인 브라우저 접속은 먼저 시스템 프록시로 최소한의 검증 경로를 구성하세요. 애플리케이션이 시스템 프록시를 우회하거나 게임 UDP, 투명 프록시가 필요한 경우에 TUN을 테스트하면 됩니다. 모드를 전환한 뒤에는 연결 목록과 DNS 동작을 다시 확인해야 합니다.

코어와 인터페이스 버전은 따로 확인하기

Clash Verge Rev는 관리 인터페이스이고 mihomo는 프록시 로직을 실행하는 코어입니다. 설정 페이지에서 코어 실행 상태나 관련 버전 정보를 확인할 수 있는 경우가 많습니다. 인터페이스가 정상적으로 열려도 코어 시작에 실패하면 프록시 포트, 규칙과 연결 페이지가 정상적으로 작동하지 않습니다. 모든 노드가 동시에 비정상이고 연결 목록이 비어 있으며 로그에 정상적인 시작 정보도 없다면 먼저 코어 상태를 확인하세요.

첫 연결 실패 시 인터페이스 점검 순서

점검의 목표는 노드, DNS, 규칙과 TUN을 동시에 수정하는 것이 아니라 문제 범위를 단계적으로 좁히는 것입니다. 한 번에 하나의 변수만 바꾸고 연결 페이지나 로그로 결과를 검증해야 어떤 조정이 실제로 효과가 있었는지 알 수 있습니다.

1. 프로필 페이지 확인: 구독 업데이트가 완료되었고 대상 프로필이 선택되어 있으며 업데이트 시간이 예상과 일치하는지 확인합니다.
2. 프록시 페이지 확인: 상태가 명확한 노드를 하나 선택하고 주요 전략 그룹의 지연 시간을 측정한 뒤 전략 경로가 최종적으로 해당 노드를 가리키는지 확인합니다.
3. 임시 검증 모드: 전역 모드로 기본 연결을 테스트합니다. 접속이 회복되면 규칙 모드로 돌아가 매칭된 규칙을 확인합니다.
4. 트래픽 가로채기 확인: 먼저 시스템 프록시를 켜고 테스트 페이지에 접속합니다. 연결 목록에 기록이 없으면 애플리케이션 프록시 설정을 확인하거나 TUN이 필요한지 검토합니다.
5. 연결 기록 확인: 대상 도메인, 매칭된 규칙, 전략 그룹과 최종 노드를 확인하고 노드를 바꾼 뒤 기존 연결을 종료하여 다시 테스트합니다.
6. 로그 확인: 테스트 시각을 기준으로 DNS, timeout, refused, parse 등의 정보를 찾고 문맥에 따라 어느 단계의 문제인지 판단합니다.
7. 최소 프로필로 복원: 추가 스크립트, 복잡한 오버라이드와 실험적인 DNS 설정을 잠시 중지하고 기본 프로필로 핵심 경로를 확인한 뒤 항목별로 다시 활성화합니다.

자주 발생하는 세 가지 현상 확인 방법

웹페이지는 열리지 않지만 연결 목록에 기록이 있음: 트래픽은 이미 코어에 들어간 상태이므로 매칭 규칙, 노드 경로, DNS 결과와 로그 오류를 확인합니다. DIRECT로 표시되면 규칙이 대상 도메인을 직접 연결로 보냈는지 확인하고, 프록시 노드로 표시되면 노드와 대상 사이트 사이의 연결을 살펴봅니다.

브라우저는 되지만 특정 애플리케이션은 안 됨: 브라우저는 시스템 프록시를 따르지만 해당 애플리케이션은 직접 연결, 별도 프록시 또는 특수 네트워크 스택을 사용할 수 있습니다. 먼저 연결 페이지에 해당 애플리케이션의 요청이 나타나는지 확인한 뒤 애플리케이션 프록시를 설정하거나 TUN 모드를 테스트하세요.

노드 테스트는 정상인데 실제 접속은 시간 초과: 지연 시간 테스트 주소와 실제 대상은 다르며 규칙, DNS, 전송 프로토콜과 기존 연결 재사용도 영향을 줄 수 있습니다. 관련 연결을 종료하고 대상 도메인의 전략 경로를 확인한 뒤 같은 시각의 로그를 읽는 것이 지연 시간 테스트를 반복하는 것보다 효과적입니다.

일상적으로 사용할 때 중점적으로 확인할 페이지

프로필이 안정된 뒤에는 모든 설정을 자주 조정할 필요가 없습니다. 구독 내용이 업데이트될 때는 프로필 페이지를 확인하고, 지역이나 회선을 바꿀 때는 프록시 페이지로 이동하세요. 접속 결과가 이상하면 연결과 로그를 우선 확인하고, 시스템 업그레이드, 코어 업데이트 또는 네트워크 환경 변화가 있을 때 TUN, 시스템 프록시와 서비스 상태를 다시 점검하면 됩니다.

규칙 모드에서는 노드 선택이 보통 소수의 주요 전략 그룹에 집중됩니다. 각 그룹이 일반 프록시, 스트리밍, 메신저 또는 기타 용도 중 무엇을 담당하는지 기록해 두면 올바른 메뉴를 빠르게 찾을 수 있습니다. 구독 제공자가 프로필을 관리하는 경우 전략 그룹 이름이 바뀔 수 있으므로 업데이트 후 계층과 현재 선택을 다시 확인해야 합니다.

인터페이스를 익히는 핵심은 모든 기능을 하나씩 눌러보는 것이 아니라 각 페이지가 어떤 질문에 답하는지 이해하는 데 있습니다. 프로필 페이지는 “무엇을 불러왔는가”, 프록시 페이지는 “현재 무엇을 선택했는가”, 연결 페이지는 “트래픽이 실제로 어디로 갔는가”, 로그 페이지는 “처리 중 무슨 일이 있었는가”, 설정 페이지는 “트래픽이 어떻게 코어로 들어가는가”에 답합니다. 이 다섯 가지 질문으로 최초 설치, 구독 가져오기와 연결 문제 해결의 대부분을 점검할 수 있습니다.