Clash Verge 실행 오류 해결

창이 사라진 것인지 커널이 종료된 것인지 먼저 확인

Clash Verge가 실행 직후 종료된다면 먼저 로그를 보관한 뒤 오류가 발생한 계층을 확인하세요. 처음부터 설정 폴더를 삭제하지 마세요. 데스크톱 인터페이스, 백그라운드 서비스, mihomo 커널은 서로 다른 프로세스입니다. 인터페이스 종료는 WebView2나 앱 상태 파일 문제일 수 있습니다. 인터페이스는 정상인데 프록시를 사용할 수 없다면 커널 설정, 수신 포트, TUN 권한을 확인하는 편이 좋습니다. 노드 지연 시간 테스트에 실패했다고 해서 클라이언트 시작 오류라고 단정할 수도 없습니다.

이 글은 구버전 Clash Verge와 이후 버전인 Clash Verge Rev의 문제 해결 방법을 함께 다루지만, 두 프로그램의 폴더와 메뉴가 완전히 같다고 가정하지 않습니다. 사용 중인 프로젝트 이름, 전체 버전, 설치 패키지 아키텍처, 운영체제 버전을 기록하세요. Windows에서는 Win + R을 누르고 winver를 입력해 시스템 버전을 확인할 수 있습니다. 클라이언트를 바꾸기 전에는 백업해 구버전 상태 파일이 새 버전 폴더에 덮어쓰이지 않도록 하세요.

Windows 「작업 관리자」→「세부 정보」에서 앱 프로세스가 종료됐는지 먼저 확인한 다음 트레이를 살펴보세요. 창만 숨겨진 상태라면 트레이에서 복원해 보세요. 백그라운드 프로세스가 멈췄다면 정상적으로 종료하고, 필요한 경우 해당 클라이언트의 프로세스임을 확인한 뒤 종료하세요. 프록시나 서비스라는 이름이 들어간 프로세스를 한꺼번에 종료하지 마세요.

시작 로그와 오류 발생 시각 찾기

인터페이스가 열리는 경우: 앱에서 데이터 폴더 찾기

Clash Verge Rev의 「설정」 페이지에서 「앱 데이터 폴더」 또는 폴더 열기 항목을 찾아 로그 폴더를 확인하세요. 버전에 따라 메뉴 이름은 다를 수 있습니다. Windows 설치 버전의 데이터는 보통 사용자 %APPDATA% 아래에 있으며, 포터블 버전은 프로그램 폴더 근처에 데이터를 저장할 수 있습니다. 인터넷에서 찾은 경로 하나만 보고 현재 설치본에 로그가 없다고 판단하지 마세요.

앱이 열리지 않으면 아래 PowerShell 명령으로 이름에 Verge가 포함된 데이터 폴더 후보를 확인할 수 있습니다. 이 명령은 폴더 목록만 읽으며 파일을 삭제하거나 수정하지 않습니다. 폴더를 찾은 뒤 수정 시간을 기준으로 최신 로그 파일을 확인하세요. 앱 로그, 서비스 로그, 커널 로그가 있다면 각각 따로 보관하세요.

# Windows PowerShell: 사용자 데이터 폴더 후보 찾기
Get-ChildItem -LiteralPath $env:APPDATA -Directory -Force |
  Where-Object { $_.Name -match 'verge' } |
  Select-Object Name, FullName, LastWriteTime

인터페이스가 전혀 열리지 않는 경우: 시스템 기록 추가 확인

1. 현지 시각을 기록하고 한 번만 오류를 재현하세요. 연달아 실행하면 이전 로그가 덮어써질 수 있습니다.
2. Win + R을 누르고 eventvwr.msc를 입력한 뒤 「Windows 로그」→「응용 프로그램」에서 같은 분의 오류 기록을 확인하세요.
3. 오류가 발생한 애플리케이션, 오류 모듈, 예외 코드, 경로를 기록하세요. 이벤트 ID 1000, 1001이 단서가 될 수 있지만 모든 충돌에서 이 이벤트가 생성되는 것은 아닙니다.
4. perfmon /rel을 실행해 안정성 모니터를 열고 해당 날짜의 애플리케이션 오류 세부 정보를 확인할 수도 있습니다.

커널 로그의 fatal, error, panic은 확인을 시작할 단서이지, 그 자체가 완전한 결론은 아닙니다. 앞뒤 약 20줄을 함께 읽으세요. 마지막의 “프로세스 종료”는 결과일 뿐, 실제 원인은 앞서 발생한 설정 파싱 실패나 포트 바인딩 오류일 수 있습니다. GUI 프로그램이 터미널에 메시지를 출력하지 않았다고 해서 오류가 없었다고 볼 수도 없습니다.

설정 파일 손상: 먼저 검사한 뒤 격리

로그에 yaml: line 18, unmarshal, parse config 또는 존재하지 않는 정책 이름이 표시되면 설정 적용 과정을 먼저 확인하세요. YAML은 들여쓰기와 데이터 형식에 민감합니다. 탭으로 들여쓰기하거나 목록을 문자열로 작성하거나 삭제된 정책 그룹을 참조하면 커널이 시작되지 않을 수 있습니다. 인터페이스 상태 파일 파싱 실패와 프록시 설정 파싱 실패는 별개의 문제이므로 함께 다루지 마세요.

현재 설치본에 포함된 커널로 테스트

mihomo는 일반적인 프록시 수신을 시작하지 않고 설정을 검사하는 -t 옵션을 제공합니다. 아래 예시는 터미널이 mihomo.exe가 있는 폴더에 있고, 검사할 파일을 config-test.yaml로 복사했다고 가정합니다. 패키지에 포함된 커널 파일의 이름은 다를 수 있으므로 임의의 다른 커널로 바꿔 테스트하지 말고 현재 클라이언트에 포함된 파일을 사용하세요.

# Windows PowerShell: 복사한 설정 파일 검사
.\mihomo.exe -t -f .\config-test.yaml
$LASTEXITCODE

테스트가 실패하면 전체 출력과 종료 코드를 기록하세요. 규칙 세트, 지리 데이터 또는 상대 경로가 포함된 설정은 작업 폴더와 외부 리소스에도 영향을 받습니다. “리소스를 찾을 수 없음”과 “YAML 구문 오류”는 구분해서 해결해야 합니다. 테스트 통과는 해당 테스트 조건에서 설정 검사가 통과했다는 뜻일 뿐, 서비스 권한, TUN, 네트워크 연결이 모두 정상이라는 의미는 아닙니다.

1. 전체 백업: 앱을 종료하고 관련 프로세스가 멈췄는지 확인한 뒤 사용자 데이터 폴더를 별도 위치에 복사하세요. 구독, 오버라이드 스크립트, 규칙, 인터페이스 설정이 모두 들어 있을 수 있습니다.
2. 마지막 변경 되돌리기: 규칙이나 스크립트를 수정한 뒤 문제가 발생했다면 해당 변경부터 되돌리세요. 구독 업데이트, 커널 교체, 포트 변경을 한꺼번에 하지 마세요.
3. 실제로 적용되는 설정 확인: 클라이언트는 구독, 오버라이드, 스크립트를 병합한 뒤 커널에 전달할 수 있습니다. 원본 구독을 파싱할 수 있다고 해서 병합된 설정도 유효한 것은 아닙니다.
4. 앱 상태 파일 격리: 로그에서 특정 인터페이스 상태 파일을 원인으로 지목한 경우에만 백업 후 파일 이름을 바꿔 테스트하세요. 파일 이름을 추측해 여러 파일을 한꺼번에 삭제하지 마세요.

새 데이터 폴더로 확인해야 한다면 먼저 클라이언트와 관련 서비스를 중지하고 기존 폴더를 보관한 뒤, 해당 버전에서 지원하는 방법으로 독립된 환경을 만드세요. 새 환경에서 실행된다는 사실은 기존 환경의 설정이나 상태를 계속 확인할 필요가 있다는 뜻일 뿐, 구독을 전부 영구 삭제해야 한다는 뜻은 아닙니다. 복구할 때는 설정을 나눠서 가져오면 문제가 다시 발생했을 때 원인을 특정하기 쉽습니다.

포트 충돌: 수신 중인 프로세스 확인

address already in use 또는 bind 오류는 보통 수신 주소가 충돌했다는 뜻입니다. 흔히 사용하는 예시 포트는 7890, 7897, 컨트롤 인터페이스용 9090이지만 모든 버전에서 고정된 값은 아닙니다. 현재 적용된 설정의 mixed-port, port, socks-port, external-controller를 기준으로 확인하세요.

# Windows PowerShell: 실제 오류 포트에 맞게 목록 수정
$ports = 7890, 7897, 9090
Get-NetTCPConnection -State Listen -ErrorAction SilentlyContinue |
  Where-Object { $_.LocalPort -in $ports } |
  Select-Object LocalAddress, LocalPort, OwningProcess

# 예시: 1234를 앞 단계에서 확인한 실제 프로세스 ID로 바꾸기
Get-Process -Id 1234

위의 1234는 프로세스 ID 예시일 뿐이며, 이 값을 그대로 사용해 프로세스를 종료하면 안 됩니다. 프로세스 이름과 실행 파일 경로를 확인하고 다른 프록시 클라이언트에서 사용하는 프로세스인지 점검하세요. 이전 커널 프로세스가 남아 있다면 먼저 해당 클라이언트에서 종료하세요. 프로세스를 강제 종료해야 한다면 확인된 인스턴스만 대상으로 하세요.

• 클라이언트 두 개를 함께 실행하는 경우: 프록시 수신 포트와 컨트롤 포트를 서로 다르게 설정하세요. 프록시 포트만 바꾸면 컨트롤 인터페이스가 여전히 충돌할 수 있습니다.
• 프록시 포트를 변경한 경우: 시스템 프록시와 수동 프록시를 설정한 프로그램도 함께 확인하세요. 프로그램이 이전 포트에 계속 연결할 수 있습니다.
• 오류가 액세스 거부인 경우: 일반 프로세스가 포트를 사용 중이지 않더라도 포트 예약이나 보안 정책이 원인일 수 있습니다. 다른 종류의 오류와 같은 문제로 취급하지 마세요.

포트가 비어 있는데도 바인딩할 수 없다면 netsh interface ipv4 show excludedportrange protocol=tcp으로 IPv4 TCP 제외 범위를 확인할 수 있습니다. IPv6 환경에서는 관련 설정도 확인해야 합니다. 프록시를 실행하려고 시스템 예약 범위를 함부로 삭제하지 마세요. 우선 사용 가능한 것으로 확인된 다른 포트로 테스트하는 편이 좋습니다.

커널 권한과 TUN: 단계별로 복구

permission denied, access is denied, TUN 장치를 만들 수 없음, 서비스 연결 실패가 발생하면 먼저 실패 지점이 “커널 시작”인지 “가상 네트워크 어댑터 생성”인지 확인하세요. 시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 영향을 줍니다. TUN은 가상 네트워크 인터페이스로 트래픽을 처리하므로 서비스, 권한, 라우팅까지 점검해야 하며 확인 과정도 더 복잡합니다.

먼저 TUN을 끄고 기본 동작 확인

1. 인터페이스를 조작할 수 있다면 먼저 TUN을 끄고 규칙 모드를 유지한 상태에서 시스템 프록시로 같은 웹사이트에 접속해 보세요.
2. TUN을 끄면 사용할 수 있지만 켜면 실패하는 경우에는 노드를 바로 바꾸지 말고 서비스 상태, 가상 네트워크 어댑터, 라우팅 로그를 확인하세요.
3. 현재 버전의 설정 페이지에서 서비스 모드를 확인하세요. 서비스를 설치하거나 복구해야 한다면 해당 작업에만 권한을 부여하고 작업 후 로그를 확인하세요.
4. Win + R을 누르고 services.msc를 입력해 관련 서비스의 실행 상태와 실행 파일 경로를 확인하세요. 서비스가 이전 설치 폴더를 가리키고 있지 않은지 점검해야 합니다.

관리자 권한 실행은 권한 문제를 한 번 비교해 보는 용도로는 사용할 수 있지만, 문제를 가리는 상시 해결책으로 삼아서는 안 됩니다. 권한을 높여야 사용자 데이터 파일에 접근할 수 있다면 파일 소유자, 폴더 접근 권한, 설치 위치를 확인하세요. 드라이브 전체의 권한을 무분별하게 완화하면 위험이 커집니다.

Windows에서는 「Windows 보안」→「바이러스 및 위협 방지」→「보호 기록」에서 커널 파일이나 구성 요소가 차단됐는지 확인할 수 있습니다. 파일 출처와 기록 내용을 확인한 뒤 조치하고, 문제 해결을 위해 모든 보호 기능을 끄지 마세요. macOS에서는 「콘솔」과 「시스템 설정」→「개인정보 보호 및 보안」의 알림을 함께 확인하세요. Linux에서는 실행 방식에 따라 터미널 출력이나 서비스 로그를 살펴봐야 하며, Windows 서비스 복구 방법을 그대로 적용할 수 없습니다.

런타임과 설치 패키지: 오류 모듈에 맞춰 복구

Windows의 Tauri 기반 Clash Verge 계열 인터페이스는 일반적으로 WebView2에 의존합니다. 인터페이스 런타임이 없거나 손상되면 창이 열리지 않을 수 있지만, “창이 잠깐 떴다가 사라진다”는 증상만으로 WebView2를 원인이라고 단정할 수는 없습니다. 시스템 이벤트의 오류 모듈, 설치 프로그램 오류, 클라이언트 로그를 함께 확인하세요.

Windows의 「설정」→「시스템」→「시스템 정보」에서 시스템 종류를 확인할 수 있습니다. x64와 ARM64 패키지는 운영체제와 프로젝트 지원 여부에 맞춰 선택하세요. macOS에서는 Apple 칩 모델과 Intel 모델을 구분해야 합니다. 아키텍처가 맞지 않거나 구성 요소를 혼용했거나 이전 파일이 제대로 교체되지 않은 문제는 “구독 손상”보다 이런 로드 오류와 더 관련이 있습니다.

재설치가 필요하다면 먼저 사용자 데이터를 백업하고 현재 버전 정보를 보관한 뒤 클라이언트와 관련 프로세스를 종료하고 같은 프로젝트의 전체 설치 패키지를 사용하세요. 재설치해도 사용자 설정이 자동으로 삭제되지는 않으므로, 재설치 후에도 오류가 계속된다고 해서 설정 문제를 배제할 수는 없습니다. 기존 Clash Verge, Clash Verge Rev, 다른 클라이언트의 프로그램 파일을 같은 폴더에 섞어 두지 마세요.

복구 후 확인 및 문제 보고

창이 정상적으로 표시되는 것은 첫 단계일 뿐입니다. 아래 순서대로 복구하고 매번 변수 하나만 바꾸세요. 어느 단계에서든 오류가 다시 발생하면 해당 시점의 로그를 보관하고, 정상 작동했던 이전 상태로 되돌리세요.

1. 인터페이스 확인: 설정 페이지에 들어갈 수 있는지 확인한 뒤 앱을 종료하고 다시 실행해 한 번의 실행만 성공한 것이 아닌지 점검하세요.
2. 커널 확인: 로그에 파싱 또는 수신 관련 오류가 반복되지 않고 커널 프로세스가 계속 종료되는 일이 없는지 확인하세요.
3. 로컬 프록시 확인: 실제 수신 포트를 확인한 뒤 시스템 프록시를 따르는 앱으로 접속을 테스트하세요.
4. 설정 복구: 정상 작동이 확인된 설정 하나를 먼저 가져온 뒤 오버라이드, 사용자 지정 규칙, 구독 업데이트를 차례로 복구하세요.
5. 마지막으로 TUN 활성화: DNS, 라우팅, 접속이 정상인지 확인하세요. 시스템 프록시가 작동한다고 해서 TUN도 정상이라고 단정하지 마세요.

문제 해결 순서는 프로세스가 실제로 종료됐는지 확인하고, 발생 시각에 맞는 로그를 찾은 다음 설정, 포트, 권한, 런타임 중 해당 원인을 처리하는 방식으로 정리할 수 있습니다. 설정 항목을 확인하려면 프로토콜 가이드를 참고하세요. 복구 후 시스템 프록시나 구독에 문제가 있다면 자주 묻는 질문을 확인해 보세요. 클라이언트를 바꾸기 전에는 커널과 플랫폼 지원을 비교하세요. 모든 시작 오류를 클라이언트 이전으로 해결할 필요는 없습니다.