Clash Verge 초보자 FAQ 10가지: 구독 가져오기, 프록시 모드, 연결 오류 해결

처음 설정할 때는 문제를 세 단계로 나눠 확인하세요. 구독이 정상적으로 불러와졌는지, 커널이 노드를 통해 연결할 수 있는지, 앱의 트래픽이 커널로 전달되는지 살펴보면 됩니다. 구독을 가져왔다고 시스템 프록시가 켜진 것은 아니며, 노드 지연 시간에 숫자가 표시된다고 모든 사이트에 접속할 수 있는 것도 아닙니다. 아래에서는 실제 설정 순서에 따라 자주 묻는 질문 10가지를 답합니다. 문제를 점검할 때는 한 번에 설정 하나만 바꾸고, 변경 전후의 로그를 보관하세요.

1. Clash Verge를 설치한 뒤에도 구독이 필요한 이유는 무엇인가요?

클라이언트는 설정 관리, 시스템 프록시 및 커널 실행을 담당합니다. 구독은 보통 노드, 정책 그룹, 트래픽 분기 규칙을 제공합니다. 클라이언트만 설치한다고 연결 가능한 원격 프록시 서버가 자동으로 생기지는 않습니다. 구독 주소는 이용 권한이 있는 서비스에서 받아야 합니다. 클라이언트는 서비스 계정을 대신하지 않으며, 요금제의 데이터 한도나 이용 기간을 결정하지도 않습니다.

Clash Verge Rev: 구독을 관리하고 커널을 제어하는 데스크톱 GUI 클라이언트입니다.
mihomo: 프로토콜 연결, DNS 처리, 규칙 매칭을 담당하는 커널로, Clash Meta라고도 불립니다.
구독 설정: 노드와 라우팅 동작을 정의하는 데이터입니다. 설치 파일이나 웹 로그인 주소가 아닙니다.

시작하기 전에 구독 링크를 준비하고 서비스 이용 기간이 만료되지 않았는지 확인하세요. ss:// 또는 vmess:// 형식의 단일 노드 링크만 있다면 이를 완전한 Clash 설정으로 가져올 수 있다고 단정하지 마세요. 먼저 제공 업체에 Clash 또는 mihomo 전용 구독 메뉴가 있는지 확인하세요.

2. 구독 링크를 가져오려면 어떻게 해야 하며, 적용 여부는 어떻게 확인하나요?

왼쪽 메뉴에서 「구독」 페이지로 이동해 구독 링크 입력란에 주소를 붙여넣고 「가져오기」를 클릭하세요. 설정 카드가 표시될 때까지 기다린 뒤 해당 설정을 현재 설정으로 선택합니다. 버전에 따라 메뉴가 「새로 만들기」 안에 있을 수 있습니다. 이 경우 원격 구독 유형을 선택하고 URL을 입력하세요. 가져온 뒤에는 「프록시」 페이지에서 구독 카드만 보이는 것이 아니라 정책 그룹과 그 안의 노드도 표시되어야 합니다.

원본 링크를 복사한 다음 앞뒤 공백과 메신저가 덧붙인 문장 부호를 제거하세요.
가져오기가 끝나면 해당 설정을 선택하고 파싱 오류나 커널 재로드 실패가 있는지 확인하세요.
「프록시」로 이동해 외부 트래픽을 처리하는 정책 그룹을 펼친 다음 사용 가능한 노드를 선택하세요.
먼저 「규칙」 모드를 사용하고, 「시스템 프록시」를 켠 뒤 웹페이지에 접속해 확인하세요.

구독 URL의 토큰으로 계정 설정을 불러올 수 있는 경우가 많으므로 비밀번호처럼 안전하게 관리하세요. 스크린샷을 찍을 때는 전체 주소를 가리고, 로그를 공유하기 전에는 요청 URL도 확인하세요. 설정 관련 질문을 할 때는 서버 인증 정보와 구독 토큰을 삭제한 부분만 공유하세요.

3. 가져올 때 YAML 오류, 403 또는 시간 초과가 발생하면 어떻게 하나요?

먼저 ‘다운로드 실패’와 ‘내용을 파싱할 수 없음’을 구분하세요. 403은 접근 거부, 토큰 만료 또는 서버 정책 제한이 원인인 경우가 많습니다. 404는 보통 경로가 존재하지 않는다는 뜻이고, 시간 초과가 발생하면 현재 네트워크에서 구독 서버에 연결할 수 있는지 확인해야 합니다. 이는 YAML 들여쓰기 오류와는 다른 문제입니다.

표시되는 현상	우선 확인할 항목	해결 방법
HTML 페이지 또는 로그인 페이지가 표시됨	관리 페이지 URL을 복사한 것은 아닌지	서비스 페이지로 돌아가 Clash 전용 구독을 받으세요
YAML 파싱 실패	오류 페이지가 반환됐는지, 들여쓰기가 손상됐는지	오류가 발생한 줄을 확인하고 원본 설정을 다시 받으세요
unsupported proxy type	노드 프로토콜과 커널 지원 여부	mihomo 지원 범위와 커널 버전을 확인하세요
요청 시간 초과	구독 도메인 확인 및 네트워크 연결 상태	다른 네트워크에서 다시 확인하고 구독 업데이트의 프록시 설정을 점검하세요

구독 서버에 접속하려면 프록시가 필요한데 사용할 수 있는 설정이 하나도 없다면 처음 가져오는 단계에서 막힐 수 있습니다. 권한이 있고 사용할 수 있는 다른 네트워크로 설정을 받거나 제공 업체에 접속 가능한 주소를 문의하세요. 토큰이 포함된 링크를 출처가 불분명한 온라인 변환 사이트에 입력하지 마세요.

4. 규칙, 전역, 직접 연결 모드는 각각 언제 선택해야 하나요?

일상적으로 사용할 때는 「규칙」 모드를 선택하세요. 커널은 설정에 있는 규칙을 위에서 아래로 확인하고, 일치하는 규칙에 따라 연결을 해당 정책으로 전달합니다. 정책은 노드 그룹, DIRECT 또는 REJECT일 수 있습니다. 규칙 모드가 ‘해외 트래픽은 모두 프록시, 국내 트래픽은 모두 직접 연결’하는 고정 방식은 아닙니다. 실제 동작은 현재 설정에 따라 달라집니다.

규칙: 도메인, 대상 IP, 프로세스 등의 규칙에 따라 트래픽을 분기합니다. 분기 설정이 있는 경우 일상적인 사용에 적합합니다.
전역: 커널로 전달된 연결을 모두 전역 정책으로 보내며, 실제 출구 노드는 전역 그룹에서 선택해야 합니다.
직접 연결: 커널로 전달된 연결이 원격 노드를 거치지 않고 대상에 직접 접속합니다.

‘전역’이라고 해서 컴퓨터의 모든 프로그램을 강제로 가로채는 것은 아닙니다. 커널에 들어온 연결의 라우팅 방식만 바꿉니다. 어떤 프로그램이 시스템 프록시를 전혀 따르지 않는다면 전역 모드로 바꿔도 트래픽을 가로채는 문제는 해결되지 않습니다. 규칙과 결과를 비교할 때만 잠시 전역 모드를 사용하고, 확인 후에는 규칙 모드로 돌아가세요.

5. 시스템 프록시를 켰는데도 일부 앱이 직접 연결되는 이유는 무엇인가요?

시스템 프록시는 앱이 참고하는 프록시 설정이지, 네트워크 계층에서 트래픽을 강제로 전달하는 기능이 아닙니다. 브라우저는 대체로 시스템 설정을 따르지만 일부 다운로드 도구, 터미널 프로그램, 게임 또는 자체 네트워크 스택을 사용하는 앱은 별도 설정을 사용할 수 있습니다. 먼저 클라이언트의 「연결」 페이지에서 새 요청을 보낸 뒤 해당 도메인이나 프로세스 기록이 나타나는지 확인하세요.

명시적 프록시 요청으로 문제 위치 구분하기

실제 혼합 포트가 7897이라고 가정하고, Windows 터미널에서 다음 요청을 실행할 수 있습니다. 여기서는 프록시를 명시적으로 지정해 앱이 시스템 프록시를 읽는지에 따른 변수를 제외합니다. macOS나 Linux에서는 curl.exe를 curl로 바꾸면 됩니다.

curl.exe --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com

HTTP 응답이 돌아오면 해당 요청의 연결 과정이 완료된 것입니다. 다만 연결 기록에서 어떤 정책이 적용됐는지 확인하세요. 연결이 거부됐다는 오류가 나오면 먼저 로컬 포트가 대기 중인지 확인하세요. 명시적 프록시는 작동하는데 특정 앱만 작동하지 않는다면 해당 앱의 프록시 옵션을 확인하고, 필요한 경우 TUN을 고려하세요. TUN을 켜기 전에 명시적 프록시 테스트가 성공하는지 확인해야 노드 문제와 트래픽 가로채기 문제를 구분할 수 있습니다.

6. 노드 연결이 시간 초과되거나 지연 시간은 정상인데 웹페이지가 열리지 않는다면 어떻게 하나요?

노드 지연 시간 테스트는 보통 커널이 노드를 통해 지정된 테스트 URL에 요청을 보내는 방식이며, 결과는 해당 요청만 보여줍니다. 테스트 주소에 연결할 수 있어도 대상 웹사이트, UDP 트래픽 또는 모든 DNS 조회가 정상이라는 뜻은 아닙니다. 반대로 테스트 주소에 연결할 수 없다고 해서 노드가 완전히 작동하지 않는다고 단정할 수도 없습니다.

「프록시」에서 실제 규칙이 참조하는 그룹에 노드가 선택되어 있는지 확인하세요. 관련 없는 다른 그룹에서만 노드를 바꾸지 않았는지 살펴보세요.
「연결」을 열어 실패한 요청을 찾고, 적용된 규칙과 정책 경로 및 대상 주소를 확인하세요.
다른 노드로 바꾼 뒤 다른 설정은 그대로 둔 채 같은 URL로 다시 테스트하세요.
「로그」에서 같은 시각의 오류를 확인해 인증 실패, DNS 오류, 연결 시간 초과를 구분하세요.

모든 노드가 동시에 실패한다면 계정 만료, 데이터 사용량, 로컬 네트워크 및 시스템 시간을 먼저 확인하세요. 특정 사이트만 실패한다면 해당 사이트의 규칙과 DNS 조회 결과를 살펴보세요. 지연 시간이 80ms에서 120ms로 늘었다고 설정이 손상됐다고 단정하지 마세요. 연결 수립, 처리량, 단일 지연 시간은 서로 다른 지표입니다.

7. 포트가 사용 중이라는 오류가 나타나면 충돌하는 프로그램을 어떻게 찾나요?

로그의 address already in use는 보통 해당 주소와 포트가 이미 사용 중이라는 뜻입니다. 백그라운드에서 이전 프록시 클라이언트가 실행 중이거나 다른 인스턴스가 같은 포트를 사용하는 경우가 흔합니다. 먼저 중복으로 실행 중인 클라이언트를 종료하세요. 그래도 충돌이 계속되면 포트를 사용 중인 프로세스를 확인하고, 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요.

Windows에서는 다음 두 명령을 실행할 수 있습니다. 첫 번째 명령은 로컬 7897 TCP 대기 항목을 찾아 PID를 표시합니다. 두 번째 명령은 확인한 실제 PID에 해당하는 프로그램 이름을 조회합니다. 예시의 1234는 조회 결과로 바꿔야 합니다.

netstat -ano -p tcp | findstr LISTENING | findstr ":7897 "
tasklist /FI "PID eq 1234"

다른 방법으로는 「설정」→「Clash 설정」에서 포트 옵션을 찾아 혼합 포트를 사용하지 않는 값으로 바꾸는 방법이 있습니다. 예를 들어 7898을 사용할 수 있습니다. 버전에 따라 메뉴 위치가 다르면 mixed-port에 해당하는 실제 설정 항목을 확인하세요. 변경 후 커널을 다시 불러오고 시스템 프록시를 껐다 켠 다음, 브라우저 확장 프로그램이나 터미널 등 이전 포트를 직접 입력한 앱도 함께 업데이트하세요.

8. TUN 모드는 언제 필요하며, 활성화에 실패하는 이유는 무엇인가요?

TUN은 가상 네트워크 인터페이스와 관련 라우팅을 통해 트래픽을 가로채며, 앱별 프록시 설정이 어렵거나 불가능한 경우에 적합합니다. 시스템 프록시와는 동작 계층이 다르지만 라우팅, 프로세스 제외 설정, 커널 구성 및 시스템 권한의 영향을 받습니다. 모든 트래픽이 원격 노드를 통과한다고 보장하지는 않습니다.

Windows: 먼저 「설정」→「서비스 모드」에서 설치 및 실행 상태를 확인한 뒤 TUN을 켜세요. 서비스 설치에는 보통 관리자 권한이 필요합니다.
macOS 및 Linux: 현재 클라이언트 버전에서 요구하는 네트워크 관련 권한을 부여했는지 확인하고, 권한 부족 로그가 있는지 살펴보세요.
다른 VPN이 실행 중인 경우: 기본 경로와 DNS 설정이 서로 덮어쓰지 않도록 다른 VPN이나 가상 네트워크 인터페이스 관리 도구를 먼저 일시 중지하세요.

시작에 실패하면 가장 먼저 나타난 구체적인 오류를 기록한 뒤 권한, 인터페이스 생성, 라우팅 설치 중 어디에서 문제가 발생했는지 확인하세요. 원격 데스크톱으로 작업 중이라면 알 수 없는 TUN 설정을 연달아 바꾸지 마세요. 현재 세션 연결이 끊길 수 있습니다. TUN으로 트래픽을 가로챌 수 있더라도 노드가 UDP를 지원한다는 뜻은 아닙니다. 앱에서 필요한 프로토콜을 노드와 서버가 모두 지원해야 합니다.

9. 구독을 업데이트한 뒤 사용자 지정 규칙이 사라지는 이유는 무엇인가요?

원격 구독을 업데이트하면 설정을 다시 가져옵니다. 내려받은 내용을 직접 편집하는 방식은 변경 사항을 지속적으로 보존하기에 적합하지 않습니다. 다음 업데이트 때 로컬 수정 내용이 원격 설정으로 대체될 수 있습니다. 규칙을 계속 유지하려면 클라이언트가 지원하는 오버라이드 또는 확장 설정 기능을 사용하고, 해당 기능이 현재 구독에 연결되어 있는지 확인하세요.

규칙의 위치와 정책 이름을 확인하세요

예를 들어 예시 도메인에 직접 연결하려면 다음 규칙을 추가할 수 있습니다. 해당 요청을 먼저 처리하는 포괄적인 규칙보다 위에 배치해야 하며, 특히 마지막 기본 규칙인 MATCH 뒤에 두면 안 됩니다.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT

위 예시는 규칙 필드의 구조만 보여 주며, 완전한 구독 설정이 아닙니다. 이 내용으로 전체 설정을 덮어쓰지 마세요. 오버라이드 방식에 따라 설정 병합, 앞부분 삽입 또는 스크립트 수정이 사용될 수 있으므로 rules 배열을 붙여넣기만 하면 자동으로 추가된다고 가정하지 마세요. 대상을 사용자 지정 정책 그룹으로 지정한다면 해당 이름이 최종 설정과 정확히 일치해야 합니다. 저장 후 실행 중인 설정과 연결 기록을 확인하고, 구독을 수동으로 한 번 업데이트해 변경 사항이 유지되는지 확인하세요. 필드의 의미는 설정 참조에서 더 살펴볼 수 있습니다.

10. 클라이언트를 종료한 뒤 인터넷 연결이 끊기면 어떻게 복구하고 문제 정보를 정리하나요?

앱을 종료한 뒤에도 시스템 프록시가 127.0.0.1의 프록시 포트를 가리키고 있으면 브라우저는 해당 주소에 연결된 프로그램이 없는 상태에서 요청을 보냅니다. 먼저 클라이언트를 다시 열어 「시스템 프록시」와 TUN을 끈 다음 정상적으로 종료하세요. 프로그램을 시작할 수 없다면 시스템 네트워크 설정을 직접 복구할 수 있습니다.

Windows 11: 「설정」→「네트워크 및 인터넷」→「프록시」로 이동해 「프록시 서버 사용」과 「설정 스크립트 사용」을 확인하고, 해당 클라이언트가 설정한 항목만 해제하세요.
macOS: 「시스템 설정」→「네트워크」→ 현재 네트워크 서비스 →「세부사항」→「프록시」로 이동해 웹 프록시, 보안 웹 프록시 및 SOCKS 프록시를 확인하세요.
터미널: 이전에 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY를 직접 설정했다면 현재 터미널과 시작 파일에서도 해당 설정을 지워야 합니다.

회사 기기는 조직에서 프록시 설정을 일괄 배포할 수 있으므로 모든 설정을 바로 지우지 마세요. 먼저 기존 값을 기록하고 관리자에게 확인하세요. 직접 연결로 복구한 뒤에는 커널 실행, 포트 대기 상태 확인, 명시적 프록시 요청, 시스템 프록시 활성화 순으로 설정을 다시 진행하고 마지막에 TUN을 테스트하세요.