Windows용 Clash Verge Rev 설치 가이드: 시스템 프록시, TUN 서비스 및 오류 해결

설치 전 확인: Windows 아키텍처와 클라이언트 역할

Clash Verge Rev는 구독 관리, 설정 전환, 시스템 프록시 및 서비스 제어를 담당하는 GUI 클라이언트입니다. 실제로 규칙을 처리하고 외부 연결을 만드는 것은 mihomo 코어입니다. 클라이언트를 설치했다고 바로 사용할 수 있는 노드가 생기는 것은 아닙니다. 처음 사용할 때는 유효한 구독 링크 또는 노드, 프록시 그룹, 규칙이 포함된 로컬 YAML 설정 파일이 필요합니다.

Windows에서 「설정」→「시스템」→「정보」를 열고 「시스템 종류」를 확인하세요. x64 PC에는 x64 설치 파일을, ARM64 기기에는 해당 ARM64 설치 파일을 선택하세요.
클라이언트 다운로드 페이지에서 Clash Verge Rev의 Windows 다운로드 항목과 시스템 요구 사항을 확인하세요. 구형 Windows 지원 여부는 선택한 릴리스의 안내를 기준으로 판단하세요.
현재 사용 중인 다른 프록시 도구의 상태를 확인하세요. 처음 테스트할 때는 다른 VPN, 프록시 클라이언트, 네트워크 가속 프로그램을 종료해 여러 프로그램이 동시에 시스템 프록시나 기본 경로를 변경하지 않도록 합니다.
기존 구독과 오버라이드 설정을 백업하세요. 구독 URL에는 보통 접근 인증 정보가 포함되므로 공개 채팅방에 공유하거나 공개 스크린샷에 노출하지 마세요.

설치 마법사의 안내에 따라 설치 폴더를 선택하세요. 클라이언트 GUI는 일반 사용자 권한으로 실행할 수 있는 경우가 많습니다. 시스템 서비스를 설치하거나 가상 네트워크 어댑터를 만들고 경로를 변경할 때만 관리자 권한이 필요합니다. 회사나 기관에서 관리하는 기기라면 네트워크 서비스 설치가 허용되는지 먼저 확인하고, 보안 정책을 해제해 제한을 우회하지 마세요.

구독 가져오기: 설정이 활성화됐는지 확인하기

원격 구독과 로컬 파일 가져오기 순서

「구독」 페이지를 열고 구독 링크 입력란에 전체 URL을 붙여 넣은 다음 가져오기를 실행하세요. 사용 중인 버전에서 가져오기 메뉴가 「새로 만들기」에 있다면 원격 설정을 선택한 뒤 URL을 입력하세요.
다운로드와 파싱이 끝날 때까지 기다린 다음 YAML 구문 오류, 인증 실패 또는 요청 시간 초과 메시지가 없는지 확인하세요.
가져온 설정을 선택해 현재 활성 설정으로 지정하세요. 목록에 표시되는 것만으로 코어가 해당 설정으로 전환된 것은 아닙니다.
「프록시」 페이지를 열어 설정에서 제공하는 프록시 그룹과 노드가 표시되는지 확인하고, 실제 트래픽을 처리하는 선택 그룹에서 사용할 수 있는 노드를 선택하세요.
로컬 파일을 사용하는 경우 설정 가져오기 메뉴에서 YAML 파일을 선택하세요. 노드 목록만 있고 프록시 그룹과 규칙이 없는 파일은 완전한 실행 설정으로 바로 사용할 수 없을 수 있습니다.

구독을 가져온 뒤에는 먼저 규칙 모드를 사용하세요. 해당 설정 키는 mode: rule입니다. 규칙 모드는 rules의 순서에 따라 연결을 판별한 뒤 지정된 프록시 그룹이나 아웃바운드로 전달합니다. 전역 모드는 GLOBAL에서 선택한 아웃바운드로 처리하므로 규칙과 프록시 그룹 확인을 대신할 수 없습니다.

구독 가져오기에 실패하면 확인할 항목

HTTP 401 또는 403: 구독 만료 여부, 접근 토큰 재설정 여부, 서버의 클라이언트 유형 제한을 먼저 확인하세요. 인증 오류를 해결하려고 DNS를 반복해서 바꾸지 마세요.
HTML 응답 또는 YAML 파싱 실패: 링크가 로그인 페이지나 오류 페이지를 가리키거나 다른 클라이언트용 형식만 제공할 수 있습니다. Clash/mihomo와 호환되는 설정을 받으세요.
요청 시간 초과: 현재 네트워크에서 구독 서비스에 접속할 수 있는지 먼저 확인하세요. 이전 프록시가 시스템 설정을 계속 사용 중이라면 기존 클라이언트를 종료한 뒤 다시 테스트하세요.
노드는 보이지만 웹사이트에 접속할 수 없음: 실제로 적용된 프록시 그룹을 확인하세요. 속도 테스트 성공은 테스트 대상에 연결됐다는 뜻일 뿐, 모든 웹사이트와 프로토콜, 출구가 정상이라는 의미는 아닙니다.

시스템 프록시: 브라우저의 HTTP 연결부터 확인

클라이언트에서 「시스템 프록시」를 켜고 TUN은 끈 상태로 두어 문제 범위를 좁히세요. 시스템 프록시는 Windows 프록시 설정을 변경하며, 일반적으로 해당 설정을 따르는 브라우저와 앱에 적용됩니다. 모든 기기 트래픽을 처리하는 기능은 아니므로 일부 게임, 명령줄 도구, 자체 네트워크 스택을 사용하는 프로그램은 이 설정을 무시할 수 있습니다.

Windows에서 「설정」→「네트워크 및 인터넷」→「프록시」를 열고 수동 프록시 주소와 포트를 확인하세요. 주소는 보통 127.0.0.1이며, 포트는 클라이언트에서 현재 적용 중인 설정을 따라야 합니다. 아래의 7890은 예시일 뿐, 모든 설치 환경에서 사용하는 포트는 아닙니다.

확인 항목	예시 또는 예상값	주의 사항
혼합 포트	`mixed-port: 7890`	하나의 포트에서 HTTP 및 SOCKS 프록시 연결을 받을 수 있습니다.
Windows 프록시 서버	`127.0.0.1:7890`	실제 수신 포트와 동일하게 설정하세요.
현재 실행 모드	`mode: rule`	연결 기록에서 적용된 규칙을 확인하세요.
LAN 액세스	`allow-lan: false`	이 PC에서만 사용할 경우 LAN 공유를 켤 필요가 없습니다.

명시적 프록시 요청으로 앱 문제와 코어 문제 구분하기

PowerShell에서 다음 명령을 실행하세요. HTTP 프록시를 명시적으로 지정하므로 앱이 Windows 프록시 설정을 읽는지에 영향을 받지 않습니다. 포트를 클라이언트에 표시된 실제 값으로 바꾸세요. 테스트 도메인은 HTTPS 요청을 한 번 보내기 위한 예시이며, 모든 네트워크에서 접속할 수 있다는 뜻은 아닙니다.

Test-NetConnection 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

TcpTestSucceeded: True는 로컬 포트와 TCP 연결을 설정할 수 있다는 뜻일 뿐입니다. HTTPS 요청에서 응답 헤더를 받아야 해당 요청의 프록시 협상과 이후 연결이 완료된 것입니다. 명시적 프록시 요청은 성공하지만 특정 앱에서 실패한다면 클라이언트를 바로 다시 설치하기보다 해당 앱의 프록시 설정부터 확인하세요.

클라이언트의 연결 기록도 함께 열어 요청 도메인, 적용 규칙, 프록시 그룹, 최종 노드를 확인하세요. 요청이 DIRECT에 매칭되면 규칙이 예상대로인지 먼저 점검하세요. 프록시 그룹에서 사용할 수 없는 노드를 선택한 경우 시스템 프록시 주소를 바꿔도 해결되지 않습니다.

TUN 및 서비스 모드: 기본 연결이 확인된 뒤 활성화

TUN 모드는 가상 네트워크 인터페이스와 경로를 사용해 더 많은 앱 트래픽을 처리하므로 시스템 프록시를 따르지 않는 프로그램에 적합합니다. 서비스 모드는 권한이 필요한 코어 작업을 백그라운드 서비스로 실행합니다. 서비스가 설치됐다고 TUN이 켜진 것은 아니며, TUN 스위치를 켰다고 경로와 DNS가 올바르게 설정된 것도 아닙니다.

먼저 앞 절의 시스템 프록시 테스트를 완료해 구독, 노드, 코어가 모두 작동하는지 확인하세요.
「설정」으로 이동해 「서비스 모드」 항목을 찾고 화면에 표시된 설치 또는 관리 메뉴를 통해 서비스를 설치하세요. Windows 사용자 계정 컨트롤 메시지가 나타나면 프로그램 출처를 확인한 뒤 허용하세요.
서비스 상태가 정상인지 확인한 다음 「TUN 모드」를 켜세요. 화면에서 코어 재시작을 요청하면 재시작이 완료될 때까지 기다린 뒤 테스트하세요.
TUN만 따로 확인하려면 시스템 프록시를 잠시 끄세요. 이전에 시스템 프록시 설정을 읽지 않던 앱에서 요청을 보내고 클라이언트 연결 기록을 확인하세요.
일반 웹페이지, 도메인 조회, 사내 네트워크 접속을 점검하세요. TUN으로 인터넷에 접속할 수 있더라도 회사 내부망, 프린터 또는 다른 VPN의 경로까지 충돌 없이 작동한다는 뜻은 아닙니다.

TUN 설정 항목 이해하기

아래는 적용된 설정을 확인하기 위한 mihomo 설정 일부이며, 완전한 구독 설정이 아닙니다. 클라이언트가 해당 항목을 자동으로 생성하거나 덮어쓸 수 있습니다. 먼저 최종 설정을 확인한 뒤 클라이언트에서 지원하는 오버라이드 또는 병합 메뉴를 사용해 수정하세요. 원격 구독 내용을 직접 변경하면 다음 업데이트 때 덮어써질 수 있습니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

auto-route는 관련 경로를 자동으로 설정합니다. 경로가 제대로 추가되지 않으면 앱 트래픽이 TUN을 우회할 수 있습니다.
auto-detect-interface는 아웃바운드 인터페이스를 자동으로 식별합니다. 네트워크 어댑터가 여러 개이거나 가상 머신, 다른 VPN을 함께 사용하는 경우 로그에서 실제 출구를 확인해야 합니다.
dns-hijack의 any:53은 해당하는 기존 DNS 요청을 가로채는 설정이며, 모든 암호화 DNS를 처리하는 것은 아닙니다. 브라우저가 직접 보내는 DoH는 별도의 HTTPS 연결입니다.
fake-ip는 해당 요청에 매핑된 주소를 반환한 뒤 코어가 도메인과 연결하도록 합니다. 업스트림 DNS 서버는 전체 DNS 설정에서 올바르게 지정해야 합니다. 이 몇 줄만 복사했다고 DNS 설정이 완료된 것은 아닙니다.

자주 발생하는 오류: 포트, 권한, 경로별로 확인

포트 충돌: address already in use

로그에 bind, address already in use 또는 이와 비슷한 수신 실패 메시지가 나타나면 먼저 해당 포트를 사용하는 프로세스를 확인하세요. 아래 명령은 PowerShell용입니다. 포트가 7890이 아니라면 명령에서도 같은 값으로 바꾸세요.

Get-NetTCPConnection -State Listen -LocalPort 7890 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 4321

두 번째 명령의 4321은 예시 PID이므로 첫 번째 명령에서 반환된 OwningProcess 값으로 바꾸세요. 해당 프로세스가 이전 프록시 클라이언트라면 먼저 정상적으로 종료하세요. 포트를 비울 수 없다면 현재 클라이언트의 혼합 포트를 7897 같은 다른 사용 가능한 포트로 변경한 뒤 코어를 재시작하고 Windows 프록시 포트도 함께 확인하세요. 프로세스 소유자를 확인하지 않은 채 시스템 프로세스를 강제 종료하지 마세요.

서비스 설치 실패: 액세스 거부 또는 서비스 미실행

먼저 「서비스 설치 실패」와 「서비스는 설치됐지만 시작 실패」를 구분하세요. 전자는 권한이나 기기 정책이 원인인 경우가 많고, 후자는 설치 경로 오류, 구성 요소 격리, 이전 서비스 잔여 항목이 원인일 수 있습니다. 전체 오류 메시지를 기록한 뒤 아래 순서대로 확인하세요.

클라이언트의 서비스 설치 메뉴를 통해 관리자 권한 요청을 다시 실행하고 사용자 계정 컨트롤 메시지를 취소하지 않았는지 확인하세요.
Win + R을 누르고 services.msc를 입력하세요. 클라이언트가 안내하는 서비스 이름을 기준으로 상태와 실행 파일 경로를 확인하세요. 서비스 이름을 추측해 바로 삭제하지 마세요.
Windows 보안의 보호 기록과 「이벤트 뷰어」→「Windows 로그」→「시스템」에서 같은 시간대의 기록을 확인하세요.
업데이트 후 경로가 유효하지 않다면 클라이언트에서 제공하는 서비스 제거 및 재설치 메뉴를 먼저 사용한 뒤 클라이언트를 재시작하세요.

방화벽이나 보안 기능을 장기간 끄는 방식은 해결책으로 권장하지 않습니다. 조직 정책으로 설치가 제한된 경우 관리자가 서비스를 설치해야 할 수 있습니다. 이때는 이미 작동을 확인한 시스템 프록시 설정을 우선 유지하세요.

TUN을 켠 뒤 인터넷 또는 내부망 연결이 끊김

먼저 TUN을 끄고 일반 네트워크 연결이 복구되는지 확인하세요. 복구되면 시스템 프록시를 다시 테스트하세요. 시스템 프록시가 정상이라면 노드와 기본 아웃바운드가 주된 원인일 가능성은 낮으므로 가상 인터페이스, 경로, DNS를 확인하세요. 기본 경로를 여러 프로그램이 동시에 제어하지 않도록 다른 VPN을 종료한 뒤 다시 시도하세요.

Get-NetAdapter | Select-Object Name, InterfaceDescription, Status
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Select-Object -First 20 DestinationPrefix, InterfaceAlias, NextHop, RouteMetric

이 명령은 네트워크를 변경하지 않고 상태만 확인합니다. 활성화 전후의 인터페이스와 경로 차이를 기록하세요. 내부망 리소스만 접속할 수 없다면 내부망 대역, 접근 규칙, 경로 제외 설정을 확인하세요. 규칙에 DIRECT를 추가하는 것만으로는 대상 주소가 이미 잘못된 경로로 전달되는 문제를 해결하지 못할 수 있습니다. 원래 상태로 되돌리려면 먼저 TUN을 끄고 시스템 경로를 일괄 삭제하지 마세요.

클라이언트를 종료한 뒤에도 인터넷에 연결되지 않음

먼저 Windows의 「설정」→「네트워크 및 인터넷」→「프록시」를 확인하세요. 수동 프록시가 더 이상 수신하지 않는 127.0.0.1 포트를 가리키고 있다면 해당 수동 프록시 설정을 끈 뒤 다시 테스트하세요. 클라이언트를 정상적으로 종료하기 전에 시스템 프록시를 끄면 프록시 설정이 남는 문제를 줄일 수 있습니다.

여전히 문제가 있으면 백그라운드 서비스가 실행 중인지, TUN 경로가 해제됐는지 확인하세요. 창을 닫아 트레이로 최소화하는 것과 프로그램을 완전히 종료하는 것은 다릅니다. 창이 사라졌다는 이유만으로 코어가 종료됐다고 판단하지 마세요.

설치 후 확인: 재현 가능한 테스트 절차 마련

설정이 끝났다고 모든 스위치를 켤 필요는 없습니다. 주로 브라우저를 사용한다면 시스템 프록시만 유지해도 됩니다. 다른 앱의 트래픽까지 처리해야 할 때 검증을 마친 TUN 설정을 사용하세요. 규칙 모드, 시스템 프록시, TUN은 각각 다른 계층을 제어하므로 한 스위치의 상태만 보고 나머지 두 설정도 정상이라고 판단할 수 없습니다.

설정: 현재 구독이 활성화되어 있고 프록시 페이지에 사용할 수 있는 그룹이 있으며, 업데이트 후에도 정상적으로 불러와집니다.
포트: 클라이언트의 실제 수신 포트와 Windows 프록시 설정이 일치하고, 명시적 프록시 요청에서 응답을 받을 수 있습니다.
규칙: 직접 연결과 프록시 연결의 기록을 각각 한 번 이상 확인해 아웃바운드 선택이 설정과 일치하는지 확인합니다.
TUN: 시스템 프록시를 끈 상태에서도 대상 앱이 TUN을 통해 연결 기록을 남기고, 내부망 리소스에도 정상적으로 접속할 수 있습니다.
재부팅: Windows를 재시작한 뒤 서비스, 설정, 프록시 상태를 다시 확인하세요. 「시작 시 실행」이 「네트워크 트래픽 처리 완료」를 의미하지는 않습니다.
복구: 시스템 프록시와 TUN을 끄고 일반 네트워크를 복구할 수 있으며, 복구에 사용할 수 있도록 변경 전 오버라이드 설정을 보관합니다.

문제 해결을 요청할 때는 Windows 시스템 종류, 클라이언트 버전, 코어 버전, 실행 모드, 수신 포트, 같은 시간대의 오류 로그를 제공하세요. 구독 토큰, 노드 인증 정보, 개인 접속 기록은 삭제해야 합니다. 「Clash가 연결되지 않는다」고만 설명하기보다 명시적 프록시 테스트 성공 여부와 TUN 실패 여부를 알려주면 원인을 더 쉽게 찾을 수 있습니다. 설정 항목의 의미를 확인하려면 전체 문서를 참고하세요.