GUIDE / LINUX CLIENT

Clash Verge Rev 사용법
구독 가져오기 및 연결 확인

구독 가져오기 → 프록시 모드 선택 → 연결 → 확인 순서로 처음 설정을 마치세요. 먼저 브라우저 요청이 정상적으로 연결되는지 확인한 다음 터미널 프록시와 TUN을 설정하세요.

시작 전: 클라이언트 설치 및 구독 준비

설치 후 정상적으로 실행되는 클라이언트와 서비스 제공자가 안내한 Clash 또는 mihomo 형식의 구독 URL을 준비하세요. 클라이언트는 설정을 읽고 코어를 실행해 요청을 처리합니다. 프로그램을 설치하는 것만으로 사용할 수 있는 노드가 생기지는 않습니다. 계정 페이지, 구매 내역 또는 제공자의 안내에서 구독 용도를 확인한 다음 URL을 가져오세요. 일반 웹페이지 주소, 계정 로그인 페이지, 개별 노드 공유 링크는 완전한 설정으로 가져올 수 없는 경우가 많습니다.

Linux 사용자는 아래 명령으로 프로세서 아키텍처를 확인할 수 있습니다. 출력이 x86_64이면 보통 amd64 또는 x64, aarch64이면 보통 arm64에 해당합니다. 설치 파일은 배포판에도 맞아야 합니다. Debian 및 Ubuntu 계열은 주로 DEB, Fedora 등은 주로 RPM 패키지를 사용합니다. 지원 아키텍처는 다운로드 페이지에 실제로 등록된 파일을 기준으로 확인하고 확장자만 보고 판단하지 마세요. GUI 클라이언트는 배포판의 패키지 관리 도구로 설치한 뒤 앱 메뉴에서 실행하세요.

uname -m

처음 설정할 때는 다른 프록시 클라이언트의 시스템 프록시와 투명 프록시 기능을 꺼 두세요. 여러 프로그램이 로컬 포트를 함께 사용하거나 데스크톱 프록시 설정을 반복해서 바꾸는 상황을 막을 수 있습니다. 현재 네트워크의 기본 게이트웨이와 DNS 설정은 그대로 두고 라우터 설정도 동시에 변경하지 마세요. 아래에서는 규칙 모드, 명확한 출구 하나, 시스템 프록시를 사용하는 간단한 확인 절차를 안내합니다. 현재 네트워크에서 일반 웹페이지도 열리지 않는다면 먼저 기본 연결을 복구한 뒤 구독을 가져오세요.

1단계: 구독을 가져와 설정 활성화

Clash Verge Rev를 열고 사이드바에서 ‘구독’ 또는 ‘설정’ 페이지로 이동하세요. 구독 URL 입력란에 제공자가 안내한 전체 주소를 붙여 넣고 ‘가져오기’를 누릅니다. 주소에 쿼리 매개변수가 포함되어 있다면 전부 유지하세요. 복사할 때 메시지에 함께 적힌 따옴표, 줄바꿈, 끝의 문장 부호는 제외합니다. 가져오기가 끝날 때까지 기다리고, 같은 설정이 여러 개 만들어지지 않도록 버튼을 연속해서 누르지 마세요.

가져오기가 완료되면 설정 이름과 업데이트 메뉴 등이 표시된 설정 카드가 나타납니다. 카드를 선택하거나 메뉴에서 활성화해 현재 설정으로 지정하세요. 선택 표시는 버전에 따라 테두리, 체크 표시 또는 현재 설정 안내로 다를 수 있습니다. 파일 다운로드가 완료된 것만으로는 충분하지 않습니다. 해당 설정이 실제로 사용 중인지 확인하세요. 다음으로 ‘프록시’ 페이지를 열어 정책 그룹과 선택 가능한 노드가 보이는지 확인하면 다음 단계로 넘어갈 수 있습니다.

제공자가 로컬 YAML 파일을 전달했다면 설정 페이지에서 파일 가져오기를 선택해 파일을 불러온 뒤 활성화하세요. 파일에는 클라이언트가 읽을 수 있는 설정 구조가 있어야 합니다. 일반 텍스트 파일의 이름을 config.yaml로 바꾼다고 노드가 자동으로 생성되지는 않습니다. 원격 구독은 보통 설정 카드에서 업데이트할 수 있지만 로컬 파일에는 업데이트 출처가 없을 수 있으므로 두 방식의 관리 방법을 구분하세요.

가져오기에 실패하면 먼저 오류 안내의 유형을 확인하세요. 다운로드 시간 초과는 클라이언트가 콘텐츠를 가져오지 못했다는 뜻입니다. 형식 또는 파싱 오류는 가져온 콘텐츠를 설정으로 읽을 수 없다는 뜻이며, 계정 만료 안내가 나오면 제공자 페이지에서 상태를 확인해야 합니다. 브라우저에서 구독 페이지에 접속되는지 확인할 수는 있지만 구독 URL을 공개 온라인 변환 사이트에 붙여 넣거나 응답 내용을 공개하지 마세요. 오류를 문의할 때는 오류 유형만 남기고 URL, 계정 정보, 노드 인증 정보는 가리세요.

이 단계의 완료 기준은 현재 설정이 선택되어 있고 ‘프록시’ 페이지에 설정에서 제공하는 정책 그룹과 노드가 표시되는 것입니다. 설정 카드는 있지만 목록이 비어 있다면 먼저 설정을 실제로 활성화했는지, 구독에 Provider 항목만 있는지 확인하세요. Provider 참조 관계는 설정 문제이므로 설정 파일 참고를 확인하세요. 목록이 비어 있는 상태에서 시스템 프록시를 반복해서 켜고 끄지 마세요.

2단계: 규칙 모드와 프록시 노드 선택

설정을 활성화한 뒤 홈 또는 ‘프록시’ 페이지에서 실행 모드를 찾아 ‘규칙’ 또는 Rule을 선택하세요. 규칙 모드는 현재 설정의 규칙에 따라 코어로 들어온 요청을 직접 연결, 프록시 또는 다른 동작으로 처리합니다. 요청마다 어떤 규칙이 적용됐는지 확인할 수 있어 처음 사용하기에 적합합니다. 처음부터 모든 요청을 하나의 출구로 보내는 것보다 문제를 파악하기 쉽습니다.

다음으로 프록시 출구를 담당하는 정책 그룹을 찾으세요. 그룹 이름은 구독 설정에 따라 다르며 ‘프록시 선택’, Proxy 등으로 표시될 수 있습니다. 반드시 정해진 이름의 버튼이 있는 것은 아닙니다. 그룹을 눌러 선택지를 펼치고 우선 구체적인 노드 하나를 선택하세요. 선택한 항목이 다른 정책 그룹이면 계속 펼쳐 최종적으로 특정 노드나 원하는 자동 선택 그룹에 연결되는지 확인합니다. DIRECT는 대상에 직접 연결한다는 뜻이므로 프록시 노드로 선택하지 마세요.

페이지에 지연 시간 테스트 버튼이 있다면 응답하지 않는 후보를 먼저 걸러내는 데 사용할 수 있습니다. 다만 테스트 결과가 웹사이트 접속을 보장하지는 않습니다. 테스트 주소와 노드 프로토콜, 대상 웹사이트가 다르면 실제 결과도 달라질 수 있습니다. 처음 문제를 확인할 때는 출구를 하나로 유지하고 다음 단계의 요청 테스트를 마치세요. 노드, 모드, DNS를 동시에 바꾸면 원인을 찾기 어려워집니다.

규칙·전역·직접 연결 모드의 차이

‘전역’ 또는 Global은 코어로 들어온 트래픽을 전역 정책 그룹으로 처리합니다. 특정 웹사이트의 접속 결과가 규칙 선택에 영향을 받는지 잠깐 확인할 때 사용할 수 있습니다. 모드를 바꾼 뒤에는 전역 정책 그룹에서 선택된 출구도 확인하세요. 규칙 모드에서 선택한 출구와 다를 수 있습니다. ‘직접 연결’ 또는 Direct는 코어로 들어온 요청을 바로 대상에 연결하며, 주로 임시 비교에 사용합니다. 전역 모드가 모든 앱을 자동으로 프록시에 연결하는 것은 아닙니다. 코어에 들어오지 않은 요청은 모드 스위치를 바꿔도 처리되지 않습니다.

따라서 모드와 트래픽 처리 방식은 서로 다른 설정입니다. 우선 규칙 모드를 유지하고 선택한 정책 그룹과 출구를 기록하세요. 다음 단계에서 시스템 프록시를 통해 브라우저 요청을 코어로 보냅니다. 정책 그룹, 규칙 적용 또는 DIRECT의 의미가 익숙하지 않다면 용어 안내를 확인하세요. 전체 규칙 문법은 설정 참고에서 볼 수 있으며, 처음 연결할 때 모든 규칙을 수정할 필요는 없습니다.

3단계: 시스템 프록시를 켜고 연결하기

클라이언트 홈 또는 설정 페이지로 돌아가 코어가 실행 중인지 확인한 다음 ‘혼합 포트’ 또는 Mixed Port를 찾으세요. 아래 명령에서는 7890을 예시로 사용하지만 실제 포트는 클라이언트에 표시된 값을 따라야 합니다. 혼합 포트는 HTTP와 SOCKS 프록시 연결을 모두 받을 수 있습니다. 브라우저나 터미널 요청이 이 포트로 전달되어야 코어가 앞서 선택한 모드에 따라 처리할 수 있습니다.

클라이언트에서 ‘시스템 프록시’를 켜세요. Linux 그래픽 환경에서는 보통 데스크톱 세션의 프록시 설정이 변경되며, 앱이 해당 설정을 따르는지는 앱의 구현에 따라 다릅니다. 시스템 설정에서 네트워크 프록시 페이지를 열어 주소가 127.0.0.1인지, 포트가 클라이언트와 일치하는지 확인하세요. 브라우저에서 별도의 프록시 확장 프로그램을 설정했다면 시스템 프록시를 사용하도록 바꾸거나 동일한 주소와 포트를 명시해 이전 클라이언트를 계속 참조하지 않도록 하세요.

이제 브라우저에서 새 탭을 열고 테스트할 웹사이트에 접속하세요. 브라우저가 오래된 연결을 계속 사용하는 것 같다면 해당 탭을 닫았다가 다시 열고, 필요하면 브라우저를 재시작하세요. 클라이언트의 시스템 프록시 스위치는 데스크톱 설정 변경을 요청했다는 뜻이지 모든 앱이 프록시를 사용한다는 뜻은 아닙니다. 다음 단계에서는 스위치 색상에 의존하지 않고 로컬 포트와 실제 요청을 함께 확인합니다.

터미널 명령에서 프록시 직접 지정

터미널 프로그램은 보통 데스크톱 시스템 프록시 설정을 자동으로 사용하지 않습니다. 처음 연결을 확인할 때는 curl --proxy로 주소를 직접 지정하면 됩니다. 셸 시작 파일을 바로 수정할 필요는 없습니다. 이 방법은 이번 명령에만 적용되므로 직접 연결 결과와 쉽게 비교할 수 있습니다. 클라이언트의 혼합 포트가 7890이 아니라면 아래 명령의 포트를 바꾸세요. curl이 설치되어 있지 않다면 배포판의 패키지 관리자로 설치한 뒤 실행합니다.

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 30 \
  -I https://example.com/

처음 연결할 때는 TUN을 켜지 마세요

TUN은 가상 네트워크 장치로 트래픽을 처리하므로 시스템 프록시를 따르지 않는 앱에 적합하지만 권한, 라우팅, DNS 설정이 추가로 필요합니다. 처음에는 TUN을 끈 상태로 브라우저와 프록시를 명시한 명령을 확인한 뒤 필요한 경우에만 사용하세요. Clash Verge Rev의 TUN에는 보통 관련 서비스와 권한이 필요합니다. 클라이언트가 제공하는 서비스 설치 또는 권한 부여 메뉴를 사용하고, 기능 하나를 켜려고 GUI 클라이언트 전체를 계속 root로 실행하지 마세요.

나중에 TUN을 켜야 한다면 먼저 다른 VPN이나 투명 프록시를 끄고 클라이언트 서비스가 정상인지 확인한 다음 TUN을 활성화하고 다시 테스트하세요. 컨테이너, 원격 데스크톱, 서버에서는 네트워크 경로가 다를 수 있습니다. 특히 원격 세션에서 기본 경로를 직접 변경하지 마세요. tun.stack, DNS 하이재킹, 라우팅 제외 설정은 설정 참고에서 확인할 수 있습니다. 이는 이번 간단한 연결 절차에 필수인 항목이 아닙니다.

4단계: 포트, 요청 및 규칙 적용 확인

세 단계로 확인하세요. 먼저 코어가 포트에서 연결을 기다리는지 확인하고, 다음으로 요청이 프록시를 통해 응답을 받는지 확인한 뒤, 마지막으로 브라우저가 예상한 경로를 사용하는지 확인합니다. 각 단계는 서로 대체할 수 없습니다. 포트가 열려 있다는 것은 로컬 진입점이 준비됐다는 뜻일 뿐입니다. 웹사이트가 열려도 직접 연결된 결과일 수 있습니다. 명령 출력과 클라이언트의 연결 기록을 대조해야 설정이 제대로 적용됐는지 판단할 수 있습니다.

먼저 로컬 포트 확인

Linux 터미널에서 아래 명령을 실행하세요. 실제 포트가 다르면 검색 조건을 바꾸면 됩니다. 정상이라면 LISTEN과 해당 주소 및 포트가 포함된 행이 표시됩니다. 결과가 없다면 클라이언트에서 코어가 실행 중인지, 다른 포트를 사용 중인지 확인한 뒤 시작 로그의 오류를 살펴보세요. 요청이 노드 선택 단계까지 도달하지 않은 상태이므로 먼저 노드를 바꾸지 마세요.

ss -lnt 'sport = :7890'

포트가 이미 사용 중이라는 메시지가 나오면 이전 클라이언트나 다른 mihomo 프로세스가 실행 중인지 확인하세요. 정체를 모르는 프로세스를 바로 종료하지 마세요. 확인된 이전 클라이언트를 닫거나 현재 클라이언트에서 사용 중이지 않은 포트로 바꿀 수 있습니다. 포트를 변경한 뒤에는 브라우저 설정과 테스트 명령도 함께 수정해 두 값이 일치하도록 하세요. 처음 로컬에서 사용할 때는 보통 LAN 연결 허용을 켤 필요가 없습니다.

프록시를 지정한 요청 다시 확인

앞 단계에서 안내한 curl 명령을 실행하고 HTTP 응답 헤더를 받는지 확인하세요. HTTP 프록시로 HTTPS 사이트에 접속하면 먼저 터널 연결 응답이 나타난 뒤 대상 사이트의 응답이 나올 수 있습니다. 터널 연결 성공만으로 대상 페이지가 응답했다고 판단할 수는 없습니다. 대상 사이트가 403 등의 상태를 반환하면 요청이 거부된 것이므로 포트 문제로 단정하지 마세요. 인증서 오류가 발생하면 시스템 시간, 인증서 환경, 구체적인 오류 원인을 확인하고 인증서 검증을 끄는 방법으로 문제를 숨기지 마세요.

여기서 example.com은 테스트 방법을 설명하기 위한 예시입니다. 응답이 온다고 해서 모든 사이트에 접속할 수 있거나 요청이 반드시 원격 노드를 거쳤다는 뜻은 아닙니다. 테스트 주소를 실제 접속하려는 사이트로 바꾸고 클라이언트의 ‘연결’ 또는 로그 페이지를 여세요. 해당 도메인을 찾아 적용된 규칙, 정책 그룹, 최종 출구를 확인합니다. DIRECT가 표시되면 해당 요청은 코어에서 직접 연결하도록 처리된 것입니다.

마지막으로 브라우저와 터미널 차이 확인

프록시를 명시한 curl은 대상 응답을 받는데 브라우저에서 실패한다면 브라우저가 시스템 프록시를 따르는지, 프록시 확장 프로그램이 설정을 덮어쓰는지, 이전 탭이 기존 연결을 계속 사용하는지 먼저 확인하세요. 반대로 브라우저에서는 접속되지만 일반 터미널 명령은 실패한다면 구독을 다시 가져오기보다 터미널 환경 변수를 먼저 확인하세요. 프로그램마다 트래픽을 프록시로 보내는 방식이 다르므로 테스트할 때는 같은 웹사이트를 사용해야 합니다.

포트는 정상인데 프록시를 명시한 요청이 계속 시간 초과된다면 같은 정책 그룹에서 노드를 바꿔 한 번 더 테스트하고 로그에서 연결 실패나 도메인 조회 오류가 있는지 확인하세요. 일부 사이트만 접속되지 않는다면 규칙과 DNS를 점검합니다. 포트 → 프록시 설정 → DNS → 규칙 → 노드 순서로 확인해 한 번에 여러 조건을 바꾸지 마세요. 자세한 문제 해결 절차는 문제 해결을 참고하세요.

종료, 업데이트 및 다음 실행

잠시 사용을 중지할 때는 클라이언트에서 시스템 프록시를 먼저 끄세요. TUN을 사용 중이라면 TUN도 끈 뒤 프로그램을 종료합니다. 프로세스를 바로 강제 종료하면 데스크톱 프록시 설정이 로컬 포트를 계속 가리킬 수 있습니다. 클라이언트는 종료됐는데 브라우저에서 갑자기 웹페이지가 열리지 않는 경우가 이에 해당합니다. 시스템 네트워크 프록시 페이지에서 원래 설정을 복원하고 네트워크를 확인하세요. 곧바로 클라이언트를 다시 설치할 필요는 없습니다.

다음에 실행할 때는 현재 설정과 정책 그룹 선택이 유지됐는지 확인한 뒤 필요한 트래픽 처리 방식을 켜세요. 설정 카드의 업데이트 메뉴에서 구독을 업데이트할 수 있습니다. 업데이트 후 노드 이름이 바뀌었다면 정책 그룹에서 선택한 항목을 다시 확인하세요. 구독 자동 업데이트와 클라이언트 소프트웨어 업그레이드는 별개의 작업입니다. 전자는 설정 출처를 갱신하고 후자는 앱을 교체하므로 서로를 완료 표시로 착각하지 마세요.

이제 기본적인 일상 사용 절차를 마쳤습니다. YAML 필드, Provider, 오버라이드와 병합을 알아보려면 설정 파일 참고를 읽어 보세요. 화면에 표시된 용어만 확인하려면 용어 안내를 참고하면 됩니다. 현재 정상 작동하는 설정을 비교 기준으로 남기고, 한 번에 옵션 하나만 바꾼 뒤 같은 대상 사이트에서 다시 테스트하면 문제를 더 쉽게 찾을 수 있습니다.