Clash Verge 자주 묻는 질문

Clash Verge는 데스크톱 프록시 클라이언트 프로젝트 이름이며, Clash Verge Rev는 같은 사용 방식을 이어가는 커뮤니티 프로젝트입니다. 두 프로젝트는 별도의 배포 경로를 사용하므로 설치 파일과 유지 관리 상태를 각각 확인해야 합니다. Mihomo는 프로토콜 연결, 규칙 매칭, DNS 처리를 담당하는 코어이고, GUI 클라이언트는 구독 관리, 시스템 프록시, 설정 및 로그 표시를 담당합니다. 문제를 문의할 때는 클라이언트의 정보 또는 설정 화면에서 정확한 제품명을 확인하고 코어 정보도 함께 기록하세요. Clash라고만 적으면 제품을 구분하기 어렵습니다. 데스크톱 클라이언트는 모바일 앱과 다르므로 Android와 iOS에서는 각 플랫폼용 클라이언트를 선택하고 지원하는 구독 형식도 확인해야 합니다.

클라이언트는 설정을 읽고 트래픽을 전달하는 프로그램이며, 설치만으로 사용할 수 있는 프록시 서비스가 제공되지는 않습니다. 일반적으로 이용 권한이 있는 서비스에서 구독 URL을 받거나, 프록시 노드와 정책 그룹을 포함한 설정 파일을 직접 준비해야 합니다. 구독을 가져왔다는 것은 내용이 읽혔다는 뜻일 뿐, 계정이 유효하거나 모든 노드에 연결할 수 있다는 뜻은 아닙니다. 처음 사용할 때는 구독 상태를 확인하고 사용 가능한 정책 그룹을 선택한 뒤 시스템 프록시를 켜서 원하는 사이트에 접속해 보세요. 구독 URL에는 계정 식별 정보가 포함될 수 있으므로 민감 정보로 취급해야 합니다. 문제를 확인할 때 전체 URL이나 QR 코드, 가공하지 않은 설정 파일을 공개하지 마세요.

규칙 모드는 설정에 적힌 순서대로 규칙을 확인해 연결별로 직접 연결, 차단 또는 프록시 정책 그룹을 선택합니다. 전역 모드는 코어에 들어온 연결을 전역 정책 그룹으로 처리하고, 직접 연결 모드는 코어에 들어온 연결을 대상에 바로 연결합니다. 전역 모드라고 해서 기기의 모든 트래픽이 자동으로 코어를 거치는 것은 아닙니다. 트래픽이 코어에 들어오는지는 시스템 프록시, 앱별 프록시, TUN 같은 진입 경로에 따라 달라집니다. 평소에는 규칙 모드로 트래픽을 분기하고, 문제를 확인할 때는 전역 모드에서 사용 가능한 노드를 명시적으로 선택한 뒤 원래 모드로 되돌리는 방법이 좋습니다. 모드를 바꾼 뒤에는 연결을 새로 만드는 편이 안전합니다. 기존 장기 연결은 설정을 바꿔도 바로 경로가 변경되지 않을 수 있으며 DNS 요청도 DNS 설정을 따로 확인해야 합니다.

시스템 프록시는 운영체제에 로컬 프록시 주소를 등록하며, 이 설정을 따르는 브라우저와 앱에 적합합니다. 일부 게임, 명령줄 도구, 자체 네트워크 스택을 사용하는 앱은 시스템 프록시 설정을 읽지 않습니다. TUN은 가상 네트워크 인터페이스와 라우팅으로 설정 조건에 맞는 트래픽을 처리하므로 적용 범위가 넓지만, 권한과 라우팅, DNS 설정이 필요해 구성이 더 복잡합니다. 처음 설정할 때는 시스템 프록시로 구독과 노드가 정상인지 확인한 다음 앱의 필요에 따라 TUN을 켜세요. 두 방식을 함께 사용할 수도 있지만, 동시에 켜는 것을 문제 해결의 기본 단계로 삼지는 마세요. 다른 VPN이나 네트워크 트래픽을 가로채는 도구가 실행 중이라면 라우팅이 충돌하지 않도록 하나를 먼저 끄세요.

먼저 다운로드 실패와 파싱 실패를 구분하세요. 요청 시간 초과, 인증 실패, HTTP 403은 네트워크, 계정 또는 서버 측 제한과 관련된 경우가 많습니다. YAML 파싱 오류는 가져온 내용이 클라이언트에서 읽을 수 있는 설정 파일이 아니라는 뜻입니다. URL을 빠짐없이 복사했는지, 계정이 만료되지 않았는지, 서비스 제공자가 구독 주소를 변경하지 않았는지 확인하세요. 로그인 페이지나 오류 페이지가 반환된다면 반복해서 가져와도 해결되지 않습니다. HTTP 403도 반드시 계정 만료를 뜻하는 것은 아니므로 서비스 제공자의 안내와 함께 판단해야 합니다. 구독 URL에 프록시 연결이 필요한 경우에는 이미 사용 가능한 연결을 통해 업데이트할 수 있으며, 가능 여부는 클라이언트의 업데이트 설정에 따라 달라집니다. 출처가 불분명한 온라인 변환 서비스에 비공개 구독을 입력하지 마세요.

기기 브랜드만 보지 말고 운영체제에서 표시하는 CPU 아키텍처를 확인하세요. 일반적인 Intel 또는 AMD 기반 Windows PC는 대체로 x64 패키지를 사용합니다. ARM 기기는 클라이언트가 해당 버전을 제공하는지, 운영체제에서 호환 실행을 지원하는지 먼저 확인하세요. macOS에서는 이 Mac에 관하여 화면에서 Apple 칩인지 Intel인지 확인한 뒤 맞는 설치 파일을 선택하면 됩니다. Linux의 amd64와 arm64는 아키텍처이고 deb와 rpm은 배포판별 패키지 형식이므로 서로 대체할 수 없습니다. 실행할 수 없거나 의존성 오류가 발생하면 재설치하기 전에 아키텍처, 배포판 및 시스템 요구 사항을 확인하세요. 출처나 호환성이 불분명한 설치 파일을 실행하려고 시스템 보안 기능을 끄지 마세요.

로그를 확인해 서비스 시작, 가상 네트워크 어댑터 생성, 라우팅 설정 중 어디에서 실패했는지 살펴보세요. 스위치가 다시 꺼지는지만으로 원인을 판단하지 마세요. Windows에서는 클라이언트에 필요한 서비스 모드가 설치되어 실행 중인지 확인하세요. 서비스를 설치하거나 복구할 때는 보통 관리자 권한이 필요합니다. macOS는 시스템에서 요구하는 권한 승인 절차를 완료하고, Linux는 클라이언트 안내에 따라 서비스나 필요한 네트워크 권한을 설정해야 합니다. 권한을 승인한 뒤 코어를 다시 시작해 테스트하세요. 장치가 사용 중이거나 라우팅 충돌이 있다는 로그가 표시되면 다른 VPN, 기존 프록시 서비스 또는 중복 실행 중인 클라이언트를 먼저 종료하세요. 필요한 권한은 운영체제와 클라이언트 버전에 따라 달라집니다. 오류 하나를 해결하려고 모든 프로그램을 계속 최고 권한으로 실행하는 것은 권장하지 않습니다.

부팅 시 자동 실행은 로그인 후 클라이언트를 시작한다는 뜻이지, 네트워크 연결이 준비되고 구독이 업데이트되거나 TUN 서비스까지 시작된다는 뜻은 아닙니다. 먼저 클라이언트를 직접 실행해 현재 설정과 정책 그룹 선택, 프록시 진입 경로가 정상인지 확인한 뒤 자동 실행을 켜세요. 조용한 실행 옵션은 보통 창 표시 여부만 제어하며 연결 문제를 해결하지 않습니다. 재부팅한 뒤 작업 표시줄이나 메뉴 막대에서 실행 상태와 서비스 상태를 확인하고 로그 시간도 살펴보세요. 창만 닫힌 채 프로세스가 실행 중인지, 아니면 프로세스 자체가 시작되지 않았는지 구분해야 합니다. 네트워크에 연결되기 전에 구독 업데이트가 시작된다면 온라인 상태에서 수동으로 업데이트를 다시 시도하세요. 클라이언트를 종료할 때 시스템 프록시 설정이 복구되는지도 확인해, 실행되지 않는 포트를 가리키는 설정이 남지 않도록 하세요.

규칙은 일반적으로 위에서 아래로 확인하며, 일치하는 규칙이 나오면 해당 정책을 적용합니다. 기본 규칙인 MATCH 뒤에 작성한 규칙은 실행되지 않는 경우가 많습니다. 먼저 연결 기록에서 대상 도메인, 매칭된 규칙, 실제 적용된 정책을 확인한 뒤 도메인 규칙, IP 규칙, 규칙 세트 중 무엇이 적절한지 판단하세요. 규칙 끝에 지정한 정책 그룹 이름은 설정과 정확히 일치해야 하며, 수정 후에는 설정이 다시 로드되었는지도 확인해야 합니다. 브라우저 주소 표시줄만 봐서는 부족합니다. 페이지가 여러 리소스 도메인에 연결될 수 있고 기존 연결은 이전 정책을 계속 사용할 수도 있습니다. 계속 사용할 규칙은 클라이언트에서 지원하는 오버라이드나 병합 기능에 추가하고 삽입 위치도 확인하세요. 구독으로 생성된 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다.

구독을 업데이트하면 원격 설정을 다시 가져오므로 파일에 직접 입력한 변경 사항은 새 내용으로 덮어써질 수 있습니다. 노드나 정책 그룹의 이름이 바뀌면 이전에 저장한 항목을 찾지 못해 기본 선택으로 돌아갈 수도 있습니다. 먼저 유지해야 할 항목이 사용자 지정 규칙, DNS 필드, 정책 그룹 구조 중 무엇인지 구분한 뒤 현재 클라이언트에서 지원하는 오버라이드, 병합 또는 스크립트 기능을 사용하고 적용 순서도 확인하세요. 변경 전에는 복구할 수 있는 사본을 저장하고, 업데이트 후에는 편집기의 원본 파일이 아니라 실제 적용된 설정을 확인해야 합니다. 복구할 때는 항목별로 병합하세요. 오래된 노드 정보, 만료된 규칙 세트 주소, 더 이상 지원되지 않는 필드를 새 설정 전체에 덮어쓰지 마세요.

fake-ip는 DNS 응답과 연결을 매핑하는 방식이지, 모든 DNS 요청이 자동으로 처리된다는 뜻은 아닙니다. 시스템 DNS, 브라우저의 보안 DNS, 클라이언트의 DNS 수신 및 업스트림 해석 설정, TUN의 DNS 처리 범위를 각각 확인하세요. 테스트 전에 사용할 것으로 예상되는 DNS 서비스를 기록한 다음 로그와 실제 조회 경로를 비교하세요. 테스트 사이트에 표시된 DNS 서버의 위치만으로 누출 여부를 판단할 수는 없습니다. 브라우저 내장 암호화 DNS는 시스템 DNS를 우회할 수 있지만 연결 자체는 프록시를 통과할 수 있으므로 실제 라우팅을 확인해야 합니다. 한 번에 진입 경로 하나만 조정하고 앱의 DNS 캐시를 지운 뒤 다시 연결하세요. 여러 설정을 동시에 바꾸면 원인을 찾기 어렵습니다.

다른 기기에는 클라이언트를 실행 중인 컴퓨터의 현재 LAN IP 주소와 클라이언트가 실제로 수신 대기 중인 프록시 포트를 입력해야 합니다. 127.0.0.1은 각 기기 자신을 가리키므로 입력하면 안 됩니다. LAN 연결 허용이 켜져 있는지, 수신 주소가 외부 기기에서 접근 가능한지, 두 기기가 서로 통신할 수 있는 네트워크에 연결되어 있는지 확인하세요. 방화벽에서는 신뢰할 수 있는 네트워크에만 해당 포트를 허용해야 합니다. 게스트 Wi-Fi나 무선 기기 격리 기능은 기기 간 통신을 막을 수 있으며, 컴퓨터가 절전 모드에 들어가도 연결이 끊깁니다. 신뢰할 수 있는 LAN에서만 사용하고 프록시 포트를 인터넷에 노출하지 마세요. 더 이상 공유할 필요가 없다면 기능을 끄세요. 클라이언트 포트를 변경했다면 다른 기기의 설정도 함께 바꿔야 합니다.

먼저 클라이언트의 연결 기록에 대상 요청이 표시되는지 확인하세요. 기록이 전혀 없다면 코어가 실행 중인지, 운영체제에 등록된 주소와 포트가 클라이언트 설정과 일치하는지, 앱 자체 프록시 설정이나 브라우저 확장 프로그램, 우회 목록을 사용하는지 확인하세요. 명령줄 도구는 별도로 프록시 매개변수를 설정해야 할 수 있으므로, 그 도구의 연결 여부만으로 시스템 프록시가 작동하지 않는다고 판단할 수는 없습니다. 연결 기록이 있다면 매칭된 규칙과 정책을 확인하세요. 프록시 진입 경로 문제가 아니라 규칙에서 직접 연결을 선택했을 수도 있습니다. 설정을 바꾼 뒤에는 연결을 새로 만들어 다시 테스트하세요. 다른 프록시 프로그램이 시스템 설정을 반복해서 덮어쓰는지도 확인하고, 여러 클라이언트가 같은 포트를 사용하거나 동일한 프록시 설정을 동시에 제어하지 않도록 하세요.

먼저 프록시 진입 경로를 끄고 평소 직접 연결하는 사이트에 접속할 수 있는지 확인한 다음 구독이 유효한지, 시스템 시간이 정확한지 살펴보세요. 속도 테스트 시간 초과는 테스트 주소에 접근할 수 없다는 뜻일 수 있으므로 노드가 고장 났다고 단정할 수 없습니다. 실제 사이트 접속 결과와 코어 로그를 함께 확인하세요. 사용 가능한 것으로 확인된 노드를 하나 선택해 잠시 전역 모드로 테스트하고, 도메인 해석, 연결 수립, 프로토콜 핸드셰이크 중 어느 단계에서 오류가 나는지 살펴보세요. 일부 노드만 실패한다면 노드나 서비스 상태를 먼저 확인하고, 모든 노드가 실패한다면 로컬 포트, DNS, 네트워크 제한, 다른 VPN과의 충돌을 점검하세요. 매번 한 항목만 변경하고 원래 값을 기록해 두세요. 반복해서 재설치하기보다 재현 가능한 원인을 찾는 편이 좋습니다.

AppContainer로 격리된 일부 Windows 앱은 기본적으로 로컬 루프백 주소에 접근할 수 없습니다. 따라서 브라우저가 정상이라고 해서 해당 앱도 127.0.0.1의 프록시에 연결할 수 있는 것은 아닙니다. 먼저 대상 앱이 이 제한의 영향을 받는지 확인한 뒤 관리자 터미널에서 CheckNetIsolation LoopbackExempt -s를 실행해 기존 예외를 확인하세요. Get-AppxPackage로 대상 앱의 PackageFamilyName을 조회한 다음 CheckNetIsolation LoopbackExempt -a -n= 뒤에 패키지 패밀리 이름을 입력해 필요한 앱만 예외에 추가하세요. 작업을 마치면 앱을 다시 열어 테스트합니다. TUN으로 해당 트래픽을 처리하는 방법도 검토할 수 있지만 모든 연결 실패가 루프백 제한 때문인 것은 아닙니다. 회사 기기에서는 관리 정책을 먼저 확인하고 모든 앱을 일괄적으로 예외 처리하지 마세요.

인증서 경고를 무시하는 것은 일반적인 해결 방법이 아니며, 계속 접속하려고 출처가 불분명한 루트 인증서를 설치해서도 안 됩니다. 먼저 시스템 날짜와 시간대, 시간 동기화를 확인한 뒤 프록시를 끈 상태에서 같은 사이트에 접속해 결과를 비교하세요. 프록시를 켰을 때만 문제가 생긴다면 HTTPS 복호화 도구, 보안 프로그램의 암호화 트래픽 검사, 잘못된 DNS 응답, 웹 로그인이 필요한 네트워크 포털이 있는지 확인하세요. 일반적인 프록시 전달에는 대상 사이트의 인증서를 바꿀 필요가 없습니다. 여러 사이트에서 동일한 낯선 발급자가 표시되면 민감한 작업을 중단하고 인증서 체인을 확인하세요. 한 사이트에서만 오류가 발생하고 여러 네트워크에서 재현된다면 사이트 자체의 인증서 문제일 수 있습니다. 브라우저의 인증서 검증 수준을 낮추기보다 사이트가 수정될 때까지 기다리세요.