Clash Verge 실행 즉시 종료될 때: 시작 오류 점검 순서와 해결 방법

먼저 구분하기: 창 충돌, 백그라운드 잔류, 커널 시작 실패

Clash Verge의 인터페이스 프로세스, 프록시 커널, 시스템 서비스는 서로 다른 구성 요소입니다. 창이 사라져도 클라이언트 전체가 종료된 것은 아닐 수 있고, 창이 정상적으로 표시되면서 커널 시작에 실패했다고 해서 곧바로 WebView2 문제라고 단정할 수도 없습니다. 먼저 운영체제 버전, 클라이언트 전체 버전, 설치 파일의 아키텍처, 그리고 업데이트 후·구독 가져오기 후·최초 설치 중 언제 문제가 발생했는지 기록하세요.

구버전 Clash Verge와 이후 유지 관리되는 Clash Verge Rev는 같은 배포판으로 취급하면 안 됩니다. 데이터 디렉터리, 서비스 이름, 설정 메뉴 이름이 다를 수 있습니다. 인터페이스에 진입할 수 있다면 설정 페이지의 버전 정보에서 버전을 확인하세요. 진입할 수 없다면 설치 파일 이름이나 실행 파일 속성으로 확인하고, 바탕 화면 바로 가기 이름만으로 판단하지 마세요.

1. 작업 표시줄 알림 영역을 확인하세요. Windows에서는 숨겨진 아이콘을 열고, macOS에서는 메뉴 막대를 확인합니다.
2. 클라이언트를 종료한 다음 작업 관리자 또는 활성 상태 보기를 확인하세요. 해당 클라이언트의 잔여 프로세스임을 확인한 경우에만 종료합니다.
3. 한 번 실행한 뒤 정확한 발생 시각을 기록하세요. 연달아 더블 클릭하면 단일 실행 잠금과 여러 실행 기록이 점검을 방해할 수 있습니다.

1단계: Windows에서 WebView2와 응용 프로그램 오류 확인

Windows용 Clash Verge 인터페이스는 WebView2에 의존합니다. Microsoft Edge 브라우저가 정상적으로 열리더라도 WebView2 Runtime이 정상이라고 보장할 수는 없습니다. 기본 창이 흰 화면으로 표시되거나 WebView2 생성 실패 메시지가 나타나거나 충돌 기록에 WebView2 구성 요소가 포함되어 있다면 구독 설정을 반복해서 수정하기보다 실행 환경을 먼저 점검하세요.

런타임 복구 순서

1. 클라이언트를 종료합니다. Windows 11에서 「설정」→「앱」→「설치된 앱」을 열고 Microsoft Edge WebView2 Runtime을 검색하세요. 시스템에 따라 앱 목록 표시 방식이 다를 수 있으므로 검색되지 않는다는 이유만으로 런타임이 없다고 단정하지 마세요.
2. 항목에 「수정」 또는 복구 옵션이 있으면 안내에 따라 실행하세요. 옵션이 없다면 Microsoft에서 제공하는 공식 Evergreen WebView2 Runtime 설치 프로그램으로 복구하거나 다시 설치합니다. 오프라인 환경에서는 아키텍처에 맞는 독립 실행형 설치 프로그램을 사용할 수 있습니다.
3. 설치가 끝나면 클라이언트를 다시 실행하세요. 설치 프로그램이 시스템 재시작을 요구하면 작업 내용을 저장한 뒤 재시작합니다.
4. 계속 종료된다면 Win + R을 누르고 eventvwr.msc를 입력한 다음 「Windows 로그」→「응용 프로그램」에서 방금 기록한 시각의 오류를 찾으세요.

원본이 Application Error이고 이벤트 ID가 1000인 기록은 단서가 될 수 있지만 모든 오류에 해당 기록이 남는 것은 아닙니다. “오류가 발생한 응용 프로그램 이름”, “오류가 발생한 모듈 이름”, “예외 코드”를 기록하세요. ntdll.dll만 표시됐다고 시스템 파일 손상을 단정할 수는 없습니다. 예외가 최종적으로 발생한 위치일 수 있습니다.

흰 화면과 실제 강제 종료는 따로 점검

창이 흰 화면으로 표시되지만 프로세스가 계속 실행 중이라면 인터페이스 로그를 보존한 뒤 런타임과 사용자 데이터를 확인하세요. 프로세스도 남지 않는다면 시스템 응용 프로그램 오류도 함께 확인해야 합니다. 온라인에서 공유되는 GPU 비활성화 옵션을 모든 버전에 그대로 적용하지 마세요. 빌드마다 지원하는 옵션이 다를 수 있으며, 확인되지 않은 실행 옵션은 적용되지 않을 수도 있습니다.

WebView2 점검은 Windows에만 해당합니다. macOS는 시스템 WebKit을 사용하고, Linux 빌드는 대개 WebKitGTK 등의 시스템 구성 요소에 의존하므로 Windows 런타임을 설치해도 해결되지 않습니다.

2단계: 포트 충돌 확인하기 — 프록시 포트와 컨트롤 포트 구분

로그에 address already in use 또는 Only one usage of each socket address가 표시되면 먼저 수신 대기 포트를 확인하세요. 포트 충돌은 대체로 커널 시작 실패를 일으키며 인터페이스 충돌과는 별개일 수 있습니다. 인터페이스까지 종료된다면 인터페이스 로그도 확인하고 두 현상을 같은 문제로 취급하지 마세요.

설정의 mixed-port는 혼합 프록시 포트이고 external-controller는 컨트롤 인터페이스입니다. 아래에서는 7897과 9090을 예시로 조회합니다. 이 값이 모든 버전의 기본 포트는 아니므로 로그나 현재 설정의 실제 포트로 바꿔 사용하세요.

Windows: 포트를 점유한 프로세스 찾기

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

Get-Process -Id 4321

PowerShell에서 첫 번째 명령을 실행한 다음 두 번째 명령의 4321을 실제 OwningProcess 값으로 바꾸세요. 출력이 없다는 것은 조회 시점에 해당 TCP 포트가 수신 대기 중이 아니라는 뜻일 뿐, 다른 커널 포트까지 정상이라는 의미는 아닙니다. 예시 PID를 그대로 사용해 프로세스를 종료하지 마세요.

macOS 및 Linux: 포트 수신 프로세스 확인

# macOS
lsof -nP -iTCP:7897 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7897'
ss -ltnp 'sport = :9090'

• 다른 프록시 클라이언트가 포트를 점유하고 있다면 해당 클라이언트의 트레이나 메뉴 막대에서 정상적으로 종료한 뒤 다시 시도하세요.
• 이전 실행에서 남은 커널 프로세스라면 소속 경로를 먼저 확인해 다른 사용자나 프로그램의 서비스를 잘못 종료하지 않도록 하세요.
• 포트를 바꿔야 한다면 클라이언트에서 지원하는 포트 설정을 사용하세요. 재정의 설정이 있다면 최종 적용값도 확인해야 합니다. 구독 원본만 수정하지 마세요.

프록시 포트를 변경했다면 브라우저 확장 프로그램, 터미널의 프록시 환경 변수, 기타 수동 설정도 함께 업데이트하세요. 컨트롤 포트를 바꾼 경우 클라이언트와 커널의 연결 주소가 일치해야 합니다. 로컬 오류를 우회하려고 컨트롤 인터페이스를 0.0.0.0에 직접 노출하지 마세요.

3단계: 사용자 데이터 백업 후 손상된 설정 분리

구독을 가져오거나 YAML을 수정하거나 프로그램을 업그레이드한 직후 문제가 시작됐다면 설정과 로컬 상태를 우선 확인하세요. 프로그램을 제거해도 사용자 데이터가 남는 경우가 많으므로 재설치만으로는 시작 시 읽는 내용이 바뀌지 않을 수 있습니다. 먼저 백업한 다음 새 데이터 디렉터리에서 실행되도록 하세요.

디렉터리 위치부터 확인하고 프로그램 이름만으로 경로를 추측하지 않기

인터페이스를 열 수 있다면 설정에서 설정 디렉터리 또는 로그 디렉터리를 여는 메뉴를 먼저 사용하세요. 배포판에 따라 「설정 디렉터리」, 「설정 폴더 열기」, 「앱 디렉터리」 등으로 표시될 수 있습니다. 진입할 수 없다면 아래 시스템 경로의 앱 전용 하위 디렉터리를 확인하고 수정 시각, 로그, 앱 식별 정보를 함께 살펴 소속을 확인하세요.

• Windows: 파일 탐색기 주소 표시줄에 %APPDATA%와 %LOCALAPPDATA%를 각각 입력하세요. 설정과 WebView 캐시는 서로 다른 위치에 저장될 수 있습니다.
• macOS: Finder에서 「이동」→「폴더로 이동」을 선택하고 ~/Library/Application Support/ 아래의 해당 앱 디렉터리를 확인하세요.
• Linux: ${XDG_CONFIG_HOME:-$HOME/.config} 및 ${XDG_DATA_HOME:-$HOME/.local/share} 아래에서 앱 디렉터리를 확인하세요. XDG 환경 변수를 직접 설정했다면 실제 경로를 기준으로 합니다.

디렉터리 이름을 바꿔 새 환경에서 실행

1. 클라이언트와 해당 클라이언트의 프로세스임을 확인한 백그라운드 작업을 종료하고, 필요한 경우 관련 서비스를 먼저 중지하세요.
2. 앱 설정 디렉터리 전체를 별도의 백업 위치에 복사하세요. 백업에는 구독 주소, 노드 인증 정보, 컨트롤 인터페이스 키가 들어 있을 수 있으므로 접근을 제한해야 합니다.
3. 기존 설정 디렉터리 이름에 .backup-20261017처럼 알아보기 쉬운 접미사를 붙이세요. AppData, Library 또는 .config 전체를 삭제하지 마세요.
4. 이전 설정을 가져오지 않고 클라이언트를 실행합니다. TUN은 끈 상태로 두고 기본 창이 안정적으로 열리는지 확인하세요.
5. 새 환경에서 정상 작동한다면 먼저 사용 가능한 구독 하나를 가져온 다음 규칙 재정의, 스크립트, 기타 설정을 하나씩 복원하세요.

로그에 yaml: line, unmarshal 또는 존재하지 않는 정책 이름 오류가 표시되면 해당 줄, 필드 형식, 참조 관계를 확인하세요. YAML 들여쓰기에는 공백을 사용하고 같은 수준의 필드를 정렬해야 합니다. 정책 그룹이 참조하는 노드나 그룹 이름이 실제로 존재하는지도 확인하세요. 클라이언트 인터페이스가 열리더라도 현재 커널이 이전 설정의 모든 필드를 지원한다는 뜻은 아닙니다.

4단계: 서비스 모드 잔여 항목과 TUN 권한 확인

서비스 모드는 백그라운드 구성 요소가 필요한 권한으로 실행되도록 하고, TUN은 가상 네트워크 어댑터를 통해 트래픽을 처리합니다. 두 기능은 서로 연관되어 있지만 같은 설정은 아닙니다. 시스템 프록시는 작동하지만 TUN을 켰을 때만 실패한다면 WebView2를 다시 설치하기보다 서비스 상태, 권한, 가상 네트워크 어댑터를 먼저 확인하세요.

일반 프록시부터 복구한 다음 서비스 점검

1. 설정에 진입할 수 있다면 TUN을 먼저 끄고 클라이언트에서 제공하는 서비스 모드 관리 메뉴를 사용해 서비스를 중지하거나 복구하세요. 구체적인 버튼 이름은 현재 버전에 표시되는 내용을 따릅니다.
2. Windows에서 Win + R을 누르고 services.msc를 입력하세요. 의심되는 서비스의 「속성」에서 실행 파일 경로를 확인해 이전 설치 위치를 가리키는지 확인합니다.
3. 업그레이드 후에도 이전 서비스가 남아 있다면 기존 클라이언트나 해당 설치 프로그램의 제거·복구 절차를 먼저 사용한 다음 현재 클라이언트에서 서비스를 설치하세요.
4. 다시 시작한 뒤 TUN을 끈 상태에서 인터페이스와 커널을 먼저 확인하고, 그다음 TUN을 별도로 테스트하세요.

표시 이름이 비슷하다는 이유만으로 sc delete를 실행하거나 가상 네트워크 어댑터를 일괄 삭제하지 마세요. 이전 서비스 경로가 유효하지 않은 문제, 서비스 시작 실패, 라우팅 충돌은 각각 따로 처리해야 합니다. 관리자 권한은 일부 권한 문제만 해결할 뿐 손상된 설정이나 포트 충돌은 해결하지 못합니다.

macOS의 백그라운드 보조 구성 요소와 Linux의 systemd 서비스도 프로그램 경로를 확인해야 합니다. 서비스 파일이 계속 사용하는 다른 클라이언트에 속한다면 함께 정리하지 마세요. 회사 장비는 네트워크 정책의 제한을 받을 수 있으므로 기기 관리 요구 사항을 먼저 확인하세요.

5단계: 보안 소프트웨어 차단 기록 확인 — 보호 기능을 통째로 끄지 않기

“어제까지 정상이었는데 오늘 갑자기 실행되지 않는다”면 프로그램 업데이트, 커널 파일 격리, 보안 정책 변경이 원인일 수 있습니다. Windows에서 「Windows 보안」→「바이러스 및 위협 방지」→「보호 기록」을 열고 강제 종료 시각에 클라이언트, 커널 또는 보조 서비스 파일이 차단됐는지 확인하세요.

• 처리된 파일의 전체 경로, 탐지 이름, 시각을 기록하세요. 바탕 화면 아이콘이 남아 있다는 사실만으로 프로그램 파일이 온전하다고 판단할 수는 없습니다.
• 설치 파일이 해당 프로젝트의 공식 배포 경로에서 제공됐는지 확인하고 릴리스 안내와 시스템의 서명 정보를 살펴보세요. 출처가 불분명한 실행 파일은 복원하지 마세요.
• 오탐임을 확인한 뒤 조직의 정책에 따라 이의 제기하거나 필요한 파일만 최소 범위로 예외 처리하세요. 다운로드 폴더나 사용자 디렉터리 전체를 검사 제외 항목에 추가하지 마세요.
• 제어된 폴더 액세스가 파일 쓰기를 차단하면 앱이 상태를 저장하지 못할 수 있습니다. 신뢰성을 확인한 특정 프로그램에만 권한을 허용하세요.

macOS에서 “개발자를 확인할 수 없음” 또는 “앱이 손상됨” 메시지가 표시되면 아키텍처에 맞는 공식 설치 파일을 다시 받고 시스템 보안 안내를 확인하세요. 격리 속성을 일괄 제거하는 명령을 바로 실행하지 마세요. Linux에서는 파일 실행 권한, 시스템 로그, 설치 패키지 종속성 오류도 함께 확인해야 합니다.

운영체제별 초기화 및 재설치: 증거를 보존하고 단계별로 복원

앞선 점검으로 원인을 찾지 못한 경우에만 초기화 및 재설치를 진행하세요. 먼저 충돌 로그, 버전 정보, 사용자 데이터 백업을 보관하고 시스템 프록시를 끄세요. 제거 후에도 브라우저가 더 이상 존재하지 않는 로컬 포트에 연결하려는 상황을 막을 수 있습니다. 현재 운영체제가 지원하는 유지 관리 버전을 설치하고, 무작정 더 오래된 설치 파일을 찾지 마세요.

Windows

1. 클라이언트를 정상 종료하고 확인된 서비스를 중지한 다음 「설정」→「앱」→「설치된 앱」에서 해당 프로그램을 제거하세요.
2. 해당 앱의 잔여 설정 디렉터리임을 확인한 뒤 이름을 바꿔 보관하세요. 여러 앱이 공유하는 WebView2 Runtime은 삭제하지 마세요.
3. 시스템 아키텍처에 맞춰 다시 설치하세요. 파일이 사용 중이거나 서비스가 계속 실행 중이라는 메시지가 표시되면 잔여 프로세스를 먼저 정리하고, 필요하다면 시스템을 재시작하세요.
4. 처음 실행할 때 이전 설정을 복원하지 마세요. 인터페이스가 정상인지 확인한 뒤 구독, 시스템 프록시, 서비스 모드, TUN 순서로 테스트합니다.

macOS

1. 메뉴 막대에서 클라이언트를 종료하세요. 클라이언트가 지원하는 절차에 따라 보조 서비스를 제거한 다음 「응용 프로그램」에서 이전 앱을 삭제합니다.
2. 해당 Application Support 데이터 디렉터리를 백업하고 이름을 바꾸세요. Library 전체를 비우지 마세요.
3. Apple 메뉴의 「이 Mac에 관하여」에서 Apple 칩과 Intel 프로세서 중 어떤 제품인지 확인한 뒤 맞는 설치 파일을 선택하세요.
4. 계속 충돌한다면 「콘솔」에서 충돌 보고서를 확인하고 ~/Library/Logs/DiagnosticReports/에서 해당 시각의 보고서를 찾으세요.

Linux

1. 설치 방식이 DEB, RPM 또는 다른 배포 형식인지 확인하세요. 데스크톱 바로 가기가 서로 다른 배포 경로로 중복 생성되지 않도록 기존 패키지 관리 방식으로 먼저 제거합니다.
2. 터미널에서 실제 실행 파일을 실행해 표준 오류 출력을 저장하세요. 누락된 라이브러리, 디스플레이 세션, 권한 오류를 확인하고 배포판의 안내에 따라 종속 패키지를 설치합니다.
3. 해당 XDG 데이터 디렉터리를 백업하고 이름을 바꾼 뒤 재설치하세요. WebKitGTK 종속성 이름은 배포판과 빌드마다 다르므로 다른 시스템의 오래된 종속성 목록을 그대로 사용하지 마세요.
4. 일반 데스크톱 창이 안정적으로 열리는 것을 확인한 뒤 서비스와 TUN을 설정하세요. 창을 열기 위해 그래픽 클라이언트 전체를 root 권한으로 계속 실행하지 마세요.

복구 후 확인: 설정은 한 번에 하나씩 복원

복구 완료 여부는 창이 표시되는지만으로 판단할 수 없습니다. 커널이 계속 실행되고 로그에 같은 오류가 반복되지 않으며, 종료 후 시스템 네트워크가 정상적으로 돌아오는지도 확인하세요. 아래 순서대로 점검하고 특정 단계에서 문제가 다시 발생하면 처음부터 재설치하지 말고 해당 단계로 돌아가 확인하세요.

1. 초기 상태로 실행: 이전 데이터를 가져오지 않고 실행과 종료를 두 번 반복해 창, 트레이, 백그라운드 프로세스가 일관되게 작동하는지 확인합니다.
2. 설정 하나만 적용: 사용 가능한 구독 하나를 가져온 뒤 설정이 선택됐는지, 커널이 정상적으로 로드됐는지 확인합니다.
3. 시스템 프록시: 실제 수신 대기 포트를 확인하고 시스템 프록시를 켠 뒤 평소 사용하는 웹사이트에 접속해 요청이 연결 기록에 표시되는지 확인합니다.
4. 사용자 지정 규칙: 재정의, 스크립트, 규칙 모음을 하나씩 복원합니다. 문제가 재현되면 새로 추가한 항목과 오류가 난 줄을 기록하세요.
5. TUN 및 서비스: 마지막에 활성화하고 다른 VPN, 가상 네트워크 어댑터, 기업용 네트워크 프로그램과 충돌하는지 확인합니다.

문제 보고를 제출할 때는 운영체제 버전과 아키텍처, 클라이언트 및 커널 버전, 설치 방식, 발생 시각, 재현 단계, 초기 설정에서도 재현되는지, 관련 로그를 첨부하세요. 구독 링크, 노드 주소, 비밀번호, 컨트롤 키, 개인 경로에 포함된 민감 정보는 삭제해야 합니다. “초기 설정에서는 실행되지만 특정 재정의를 복원하면 실패한다”처럼 구체적으로 설명하면 “실행하자마자 종료된다”는 내용만 전달하는 것보다 원인을 찾기 쉽습니다.