화면 종료, 코어 실행 실패, 백그라운드 실행을 구분하세요
“Clash Verge가 열리지 않는다”는 증상은 세 가지 원인으로 나뉠 수 있습니다. 데스크톱 화면이 생성되지 않거나, mihomo 코어가 시작되지 않거나, 프로그램은 트레이에서 실행 중이지만 기본 창이 표시되지 않는 경우입니다. 포트 충돌은 보통 코어에 먼저 영향을 주며 데스크톱 프로세스 전체가 종료되는 원인은 아닐 수 있습니다. 먼저 프로세스 상태를 확인한 뒤 설정을 처리할지 실행 환경을 복구할지 결정하세요.
이 글에서는 Windows용 Clash Verge Rev를 중심으로 문제를 확인합니다. 이전 버전 Clash Verge와 Clash Verge Rev는 서로 다른 유지 관리 브랜치이므로 설정 폴더와 메뉴 이름이 다를 수 있습니다. 바탕 화면 바로 가기 이름만으로 버전을 판단하지 마세요. 창을 열 수 있다면 「설정」→「정보」에서 전체 버전 번호를 확인하고 Windows 버전, 시스템 아키텍처, 최근 변경 사항도 기록하세요. 아래 포트 번호는 예시이며 실제 값은 현재 PC의 설정을 기준으로 합니다.
| 증상 | 먼저 확인할 항목 | 다음 단계 |
|---|---|---|
| 기본 창은 보이지 않지만 트레이 아이콘은 있음 | 백그라운드 프로세스와 창 상태 | 여러 인스턴스를 연속 실행하지 말고 트레이에서 창 다시 열기 |
| 화면은 열리지만 코어 시작 실패 메시지가 표시됨 | 코어 로그, 설정 파싱, 수신 포트 | 첫 오류를 확인한 뒤 설정 또는 포트 문제 해결 |
| 프로세스가 나타난 직후 사라짐 | 앱 로그, Windows 애플리케이션 이벤트 | 런타임, 권한, 오류 모듈 확인 |
| 창이 비어 있거나 계속 로딩됨 | 화면 런타임, 프런트엔드와 백그라운드 간 통신 | WebView2와 앱 로그 확인 |
먼저 프록시를 거치지 않는 네트워크 연결 복구
클라이언트를 종료한 뒤 웹페이지도 열리지 않는다면 먼저 Windows 「설정」→「네트워크 및 인터넷」→「프록시」→「수동 프록시 설정」을 확인하세요. 해당 클라이언트가 설정한 프록시인지, 지정된 로컬 포트에서 더 이상 수신하지 않는지 확인한 뒤 「프록시 서버 사용」을 끄세요. 예를 들어 시스템 프록시가 127.0.0.1:7890을 가리키지만 해당 포트에서 수신 중인 프로그램이 없다면 시스템 프록시를 사용하는 앱의 연결이 실패할 수 있습니다.
로그 위치: 시작 시점의 첫 오류부터 확인
화면을 열 수 있다면 먼저 「설정」에서 설정 폴더와 로그 폴더를 여세요. 배포 버전에 따라 버튼 이름은 조금씩 다를 수 있습니다. 폴더 이름만 보고 위치를 추측하는 것보다 이 방법이 정확합니다. 전혀 시작되지 않는 경우에만 운영체제의 데이터 폴더에서 직접 찾으세요.
Windows에서 자주 사용하는 데이터 폴더
Clash Verge Rev에서 흔히 사용하는 사용자 설정 루트 폴더는 다음과 같습니다. Win + R을 누르고 경로를 붙여 넣은 뒤 Enter를 누르세요. 폴더가 없다면 %APPDATA%를 열고 폴더 수정 시간을 기준으로 실제 설치 브랜치를 찾아보세요.
%APPDATA%\io.github.clash-verge-rev.clash-verge-rev
이 폴더에는 일반적으로 logs, profiles 폴더와 여러 YAML 파일이 있습니다. 로그 하위 폴더와 파일 이름은 버전에 따라 달라지므로 방금 실행한 시간대를 기준으로 정렬해 확인하세요. 모든 버전에 같은 이름의 로그가 있다고 단정하지 마세요. 이전 버전 Clash Verge의 데이터 폴더는 io.github.clash-verge.clash-verge를 사용할 수 있지만 설치 방식에 따라 달라질 수 있습니다.
- 앱 로그: 화면 초기화, 파일 읽기·쓰기, 서비스 통신, 백그라운드 시작 오류를 확인합니다.
- 코어 로그: YAML 파싱, 규칙 제공자 로드, DNS 수신, 포트 바인딩 오류를 확인합니다.
- 시스템 이벤트: 앱 로그가 갱신되지 않았다면 Win + R을 누르고
eventvwr.msc를 입력하세요. 「Windows 로그」→「애플리케이션」에서 같은 시간대의 오류를 찾아 오류가 발생한 애플리케이션과 모듈 이름을 기록합니다.
macOS의 앱 데이터는 일반적으로 ~/Library/Application Support/에 있으며, Linux에서는 보통 ~/.config/부터 확인합니다. 정확한 폴더는 클라이언트의 메뉴, 앱 식별자, 배포 패키지 안내를 기준으로 확인하세요. Windows 경로를 다른 플랫폼에 그대로 적용하지 마세요.
오류 키워드로 원인을 분류하고 마지막 줄만 보지 마세요
문제를 한 번 재현한 뒤 해당 실행에서 처음 나타난 명확한 오류를 확인하세요. 이후에 표시되는 “코어에 연결할 수 없음”은 앞선 설정 파싱 실패나 포트 충돌의 결과일 수 있습니다. 오류 앞뒤 약 20줄을 함께 보관하면 한 줄만 캡처하는 것보다 원인을 찾기 쉽습니다.
address already in use또는bind: 수신 주소와 포트부터 확인하세요.yaml,unmarshal,parse: 설정 문법, 필드 형식, 병합 결과부터 확인하세요.permission denied또는Access is denied: 거부된 파일, 서비스, 장치 작업을 확인하세요.WebView2또는 시스템 이벤트에 런타임 오류가 표시됨: 화면 실행 환경을 확인하세요. 프록시 규칙부터 수정하지 마세요.
남은 설정과 손상된 파일: 백업 후 최소 구성으로 시작
클라이언트를 다시 설치해도 계속 종료된다면 사용자 데이터 폴더가 그대로 남아 있는 경우가 많습니다. 설치 프로그램은 앱 파일만 업데이트하고 구독 인덱스, 화면 상태, 덮어쓰기 설정은 초기화하지 않을 수 있습니다. 파일을 전부 삭제하기보다는 이전 데이터를 분리해 두고 시작 여부를 확인하세요.
전체 백업 후 설정 폴더 분리
- 트레이 메뉴에서 클라이언트를 종료하세요. 작업 관리자에서 관련 데스크톱 프로세스가 모두 끝났는지 확인합니다. 백그라운드 서비스가 있다면 해당 클라이언트에서 제공하는 방법으로 중지하세요. 출처가 불분명한 시스템 프로세스는 종료하지 마세요.
- 사용자 데이터 폴더 전체를 별도의 백업 위치에 복사하세요. 백업에는 구독 주소와 키가 포함될 수 있으므로 접근 권한을 제한하세요.
- 기존 데이터 폴더의 이름을 바꾸세요. 예를 들어 폴더 이름 끝에
.backup-20260915를 붙입니다. 복구할 수 있도록 원본 파일은 그대로 보존하세요. - 같은 클라이언트를 다시 시작하세요. 일반적으로 초기 데이터가 새로 생성됩니다. 구독을 가져오거나 TUN을 켜지 말고 창과 기본 코어가 정상적으로 시작되는지만 확인하세요.
새 데이터로 시작된다면 문제 범위는 이전 설정이나 상태로 좁혀집니다. 그래도 종료된다면 새로 생성된 로그를 보관하고 실행 환경을 확인하세요. 이전 폴더 전체를 바로 덮어쓰면 같은 문제가 다시 발생할 수 있습니다.
구독, 덮어쓰기 설정, TUN 순으로 복원
신뢰할 수 있는 구독 하나만 먼저 복원하고 코어가 시작되는지 확인하세요. 그런 다음 규칙, 설정 병합, 스크립트를 하나씩 복원하고 마지막에 TUN과 서비스 설정을 복원하세요. 각 항목을 복원할 때마다 다시 시작해 확인합니다. 구독 원본을 파싱할 수 있어도 덮어쓰기 후 최종 설정이 유효하다는 뜻은 아닙니다.
- YAML 들여쓰기에는 Tab 대신 공백을 사용하세요. 목록 항목 앞의 하이픈과 콜론 뒤 공백도 확인하세요.
- 포트 필드에 문자가 잘못 입력되지 않았는지, 배열이 문자열로 작성되지 않았는지, 정책 그룹이 존재하지 않는 노드나 그룹을 참조하지 않는지 확인하세요.
- 사용자 지정 규칙 마지막에 지정된 정책 그룹 이름이 현재 구독과 정확히 일치하는지 확인하세요.
- 이전 코어 설정을 옮길 때는 현재 mihomo가 지원하는 필드인지 확인하세요. 이전 버전에서 파싱에 성공했다고 현재 버전에서도 호환되는 것은 아닙니다.
명령줄에서 다시 확인하려면 최종 설정의 복사본을 사용해 코어 설정 테스트를 실행할 수 있습니다. 다음 명령을 실행하려면 현재 폴더에 해당 mihomo 실행 파일과 config.yaml이 있어야 합니다. 이 테스트는 설정만 확인하며 상시 프록시를 실행하지 않습니다.
.\mihomo.exe -t -f .\config.yaml
가능하면 클라이언트에서 실제 사용하는 것과 같은 버전의 코어로 테스트하세요. 규칙 제공자나 외부 파일이 포함된 설정은 작업 폴더와 리소스 경로에도 영향을 받으므로 명령줄 결과를 클라이언트 로그와 함께 확인해야 합니다. 구독 원본 테스트 결과를 병합된 최종 설정의 테스트 결과로 간주하지 마세요.
포트 충돌: 수신 프로세스를 확인한 뒤 충돌 항목 수정
흔한 충돌 원인은 HTTP/SOCKS 혼합 프록시 포트, 제어 인터페이스 포트, 로컬 DNS 사용 시 DNS 수신 포트입니다. 아래에서는 7890과 9090으로 확인 방법을 설명합니다. 모든 Clash Verge Rev 버전의 기본값은 아닙니다.
Windows에서 PID와 프로그램 이름 확인
PowerShell에서 다음 명령을 실행하세요. 첫 번째 명령은 해당 포트의 TCP 수신 상태와 PID를 표시하고, 두 번째 명령은 PID를 확인한 뒤 프로그램 정보를 표시합니다. 예시의 4321을 실제 조회 결과로 바꾸세요.
Get-NetTCPConnection -State Listen -LocalPort 7890,9090 -ErrorAction SilentlyContinue |
Select-Object LocalAddress,LocalPort,OwningProcess
Get-Process -Id 4321 | Select-Object Id,ProcessName,Path
포트 조회 결과가 비어 있다면 조회 시점에 일치하는 TCP 수신이 없다는 뜻입니다. DNS나 다른 UDP 충돌은 UDP도 확인해야 합니다. 예를 들어 실제 설정에서 1053을 사용하는 경우 다음과 같이 확인하세요.
Get-NetUDPEndpoint -LocalPort 1053 -ErrorAction SilentlyContinue |
Select-Object LocalAddress,LocalPort,OwningProcess
수신 프로세스가 다른 프록시 클라이언트라면 해당 클라이언트와 백그라운드 서비스를 정상적으로 종료하세요. 현재 클라이언트의 코어라면 중복 실행 중이거나 서비스 모드가 계속 실행 중일 수 있습니다. 프로세스 경로, 시작 시간, 로그를 확인하고 mihomo라는 이유만으로 강제 종료하지 마세요. 권한이 부족하면 조회 결과에 프로그램 경로가 표시되지 않을 수 있습니다.
프록시 포트를 바꾼 뒤 시스템 설정도 함께 변경
두 클라이언트를 동시에 실행해야 한다면 한쪽의 혼합 포트를 사용 중이 아닌 7897로 변경할 수 있습니다(7890에서 변경). 현재 버전의 설정 메뉴나 지속적으로 적용되는 오버라이드 기능을 이용해 변경하세요. 다음 실행 때 다시 생성되는 파일만 수정하지 않도록 주의합니다.
포트를 변경한 뒤 해당 클라이언트의 시스템 프록시를 한 번 껐다가 다시 켜세요. 브라우저, 명령줄 환경 변수, 다른 앱에 수동으로 설정된 프록시 주소도 확인해야 합니다. 제어 인터페이스 포트는 HTTP 프록시 포트로 사용할 수 없습니다. 앱 프록시를 9090으로 지정해도 해당 포트에서 수신 중이라는 사실만으로 트래픽을 프록시할 수 있는 것은 아닙니다.
런타임, 권한, TUN 서비스를 단계별로 확인
코어보다 화면이 먼저 종료됨: WebView2와 시스템 이벤트 확인
Windows용 Clash Verge Rev는 화면 표시를 위해 WebView2를 사용합니다. 창이 빈 화면으로 표시되거나 창이 생성되는 즉시 종료되고 이벤트 또는 로그에서 WebView2가 원인으로 지목된다면 Windows 「설정」→「앱」→「설치된 앱」에서 Microsoft Edge WebView2 Runtime을 확인하세요. Microsoft 공식 설치 프로그램과 현재 클라이언트의 배포 안내에 따라 복구하거나 설치한 뒤 앱을 다시 시작하세요.
VCRUNTIME140.dll, MSVCP140.dll 등의 파일이 없다는 오류가 명확히 표시되는 경우에만 Microsoft Visual C++ 2015–2022 Redistributable을 추가로 확인하고, 오류가 발생한 프로그램의 아키텍처에 맞는 설치 패키지를 선택하세요. DLL 다운로드 사이트에서 파일만 받아 복사하지 마세요. 모든 강제 종료가 같은 런타임 문제 때문인 것도 아닙니다.
일반 모드는 정상인데 TUN을 켜면 실패함: 서비스 계층 확인
TUN 모드는 가상 네트워크 어댑터와 라우팅, 높은 권한을 사용합니다. 시스템 프록시와는 별개의 설정입니다. TUN을 끄면 화면과 코어가 정상 작동한다면 구독을 계속 정리하기보다 클라이언트 서비스, 가상 네트워크 어댑터 초기화, 다른 VPN과의 라우팅 충돌을 확인하세요.
- TUN을 끄고 일반 프록시 모드에서 연결이 되는지 확인하세요.
- 클라이언트 「설정」에서 서비스 모드 상태를 확인하고 현재 버전에서 제공하는 설치 또는 복구 메뉴를 사용하세요.
- 필요한 기업 네트워크 소프트웨어 설정은 유지하면서 다른 VPN이나 가상 네트워크 어댑터 관리 도구를 잠시 종료하세요.
- TUN을 다시 켜고 이번 실패와 관련된 첫 서비스 또는 코어 오류를 확인하세요.
복구 후 점검과 재발 기록
창이 열리는 것은 첫 단계일 뿐입니다. 복구 후에는 코어, 수신 포트, 설정 복원, 종료 후 네트워크 상태를 확인해야 합니다. 한 번에 하나씩만 복원해야 구독, 덮어쓰기, 포트, 서비스 중 무엇이 원인이었는지 파악할 수 있습니다.
- 완전히 종료한 뒤 다시 시작: 정상적으로 종료한 후 다시 열어 창과 트레이 상태가 일치하는지, 로그에 시작 오류가 반복되지 않는지 확인하세요.
- 설정 로드: 초기 빈 설정에 머무르지 않고 현재 구독, 정책 그룹, 규칙이 로드되었는지 확인하세요.
- 수신과 요청: 실제 프록시 포트를 확인한 뒤 클라이언트 연결 기록의 대상, 규칙, 정책 그룹이 예상과 일치하는지 살펴보세요.
- TUN 별도 점검: TUN이 필요할 때만 켜고 관련 앱의 네트워크 연결과 DNS 동작을 확인하세요. 시스템 프록시가 작동한다고 해서 TUN 검증까지 끝난 것은 아닙니다.
- 종료 후 복원: 종료한 뒤 시스템 프록시가 꺼진 로컬 포트를 계속 가리키지 않는지 확인하세요.
문제가 다시 발생한다면 클라이언트 전체 버전, 코어 버전, 시스템 버전, 설치 방식, 재현 단계, 민감 정보를 가린 로그를 정리하세요. “새 데이터 폴더에서도 재현되는지”, “TUN을 끄면 재현되는지”, “포트 수신 프로세스가 무엇인지”를 명시하면 단순히 “열자마자 종료된다”고 설명하는 것보다 진단에 도움이 됩니다. 설치와 설정 과정은 사용 가이드를, 용어 차이는 용어집을 참고하세요.