Clash Verge Rev가 Windows 종료 또는 다시 시작을 막을 때 해결 방법

이 글은 한 가지 명확한 현상만 다룹니다. Clash Verge Rev를 실행한 채 Windows를 종료하거나 다시 시작하면 ‘이 앱 때문에 종료할 수 없습니다’ 화면에서 멈추고, 종료를 취소한 뒤에는 클라이언트가 흰 화면을 보이거나 정상적으로 종료되지 않을 수 있습니다. 반면 종료 전에 시스템 트레이에서 앱을 완전히 종료하면 정상적으로 진행됩니다.

공식 저장소의 issue #7725, #7755, #7794, #7841에는 Windows 10, Windows 11, 정식 v2.5.2 및 이후 AutoBuild에서 발생한 유사 보고가 여러 건 있습니다. 일부 보고는 TUN과 시스템 프록시를 끈 뒤에도 재현되므로 TUN만 껐다고 Service가 종료된 것은 아닙니다.

먼저 Clash Verge Service가 설치되어 있고 진단 정보의 Running Mode가 Service로 표시되며, 주 창을 닫아도 프로그램이 트레이에 남아 있고 프로그램을 실행한 상태에서만 종료가 막히는지 확인하세요. 문서 저장, Windows Update, 다른 VPN 또는 이름이 다른 백그라운드 프로그램이 종료를 막는 경우는 이 글의 범위가 아닙니다.

첫 번째 테스트에서는 Clash Verge Rev를 실행한 상태로 모든 작업을 저장한 뒤 다시 시작하세요. 차단 화면이 나타나면 ‘그래도 종료’를 누르지 말고 취소한 다음 발생 시간을 기록하세요.

두 번째 테스트에서는 창 오른쪽 위의 닫기 버튼만 누르지 말고 시스템 트레이에서 ‘종료’를 선택하세요. 트레이 아이콘이 사라질 때까지 기다리고 작업 관리자에서 Clash Verge Rev GUI가 종료되었는지 확인한 뒤 같은 방식으로 다시 시작하세요.

‘실행 중에는 차단되고 완전히 종료하면 정상’이라는 차이가 반복해서 재현될 때만 Service를 계속 확인하세요. 두 경우 모두 차단된다면 Windows 메시지와 작업 관리자를 통해 실제로 종료를 막는 프로세스를 먼저 찾으세요.

종료를 취소한 뒤 최신 애플리케이션 로그를 열어 종료 단계부터 확인하세요. 유사 보고에서는 설정 저장, TUN 종료, 코어 중지 이후 ‘서비스를 통해 코어 중지(IPC)’에서 멈춥니다.

그 뒤에 ‘서비스가 코어를 성공적으로 중지함’, 정리 완료 또는 Application exited가 없지만 트레이에서 수동 종료할 때는 이런 완료 기록이 정상적으로 나타난다면, 문제 범위를 시스템 종료 경로의 Service 중지 요청이나 완료 대기로 좁힐 수 있습니다.

issue #7794의 보고자는 프로세스 덤프를 근거로 Service는 유휴 상태로 돌아왔지만 클라이언트 측 IPC 완료 대기가 반환되지 않았다고 판단했습니다. 이는 유용한 진단 증거이지만 유지 관리자가 발표한 공식 근본 원인 결론은 아닙니다.

Service를 비활성화하거나 버전을 바꾸기 전에 현재 버전, 실행 모드, 구독 이름, 사용 중인 Profile, 시스템 프록시와 TUN 활성화 여부를 기록하세요. TUN과 시스템 프록시를 끄고 Windows가 로컬 프록시 포트에 의존하지 않아도 LAN이나 기본 네트워크에 접근할 수 있는지 확인한 뒤 트레이에서 완전히 종료하세요.

AppData 설정 디렉터리를 삭제하지 말고 구독, 노드 비밀번호, 컨트롤러 secret 또는 token이 포함된 전체 로그를 공개 업로드하지 마세요. 덤프를 제출해야 한다면 프로세스 메모리에 민감한 정보가 들어 있을 수 있음을 먼저 확인하세요.

현재 가장 위험도가 낮은 임시 대응은 종료 또는 다시 시작 전에 시스템 트레이에서 ‘종료’를 선택하고 GUI, Mihomo 코어 및 정리 절차가 완료될 때까지 기다린 뒤 Windows를 종료하는 것입니다. 주 창만 닫으면 대개 트레이로 숨겨질 뿐이므로 종료 완료로 판단할 수 없습니다.

이 단계는 설정을 바꾸거나 Service를 제거하거나 구독을 변경하지 않습니다. 다음 부팅 후 Clash Verge Rev를 정상적으로 실행하면 원래대로 돌아오므로 공식 수정이 나올 때까지 기본 임시 대응으로 적합합니다.

매번 수동 종료하는 것이 사용에 불편을 준다면 Service Mode를 일시적으로 해제할 수 있습니다. 먼저 TUN과 시스템 프록시를 끄고 일반 네트워크가 복구되었는지 확인한 뒤 현재 클라이언트 설정의 Service Mode 메뉴에서 Clash Verge Service를 비활성화하거나 제거하세요. 빌드마다 버튼 이름이 다를 수 있으므로 앱 내부 메뉴를 우선 사용하세요.

Windows 서비스 레지스트리, 가상 네트워크 어댑터 또는 설치 디렉터리의 서비스 파일을 직접 삭제하지 마세요. 제거 후 Windows를 다시 시작하고 클라이언트를 열어 Running Mode가 Sidecar 또는 Service가 아닌 다른 상태로 돌아왔는지 확인하세요.

먼저 시스템 프록시만 사용해 기본 연결을 확인하세요. Service 또는 관리자 권한이 없으면 TUN을 활성화하지 못할 수 있으며 이는 예상되는 영향입니다. TUN을 반복해서 눌러 우회하려 하지 마세요.

issue #7725와 #7794의 보고자는 v2.5.1을 자신의 기기에서 마지막으로 정상 작동한 버전으로 표시했지만, 이는 유지 관리자가 발표한 일반적인 롤백 보장이 아닙니다. 같은 로그 경계를 재현했고 완전 종료로 해결되며 Service 비활성화까지 확인했지만 Service Mode가 꼭 필요할 때만 공식 v2.5.1 Release를 이용한 통제된 비교를 고려하세요.

롤백 전에 현재 정식 버전 설치 파일을 보관하고 버전과 설정을 기록하세요. 프로젝트의 공식 Release에서 기기 아키텍처에 맞는 v2.5.1을 다운로드하세요. 사용자 설정을 삭제하지 말고 첫 실행에서는 TUN과 Service를 끈 상태로 구독과 시스템 프록시가 정상인지 확인한 뒤 Service를 설치하고 이 한 항목만 바꿔 종료 테스트를 수행하세요.

이전 버전에는 이후 수정 사항이 없으므로 장기간 사용하면 안 됩니다. v2.5.1에서도 종료가 막히면 버전을 원인으로 보는 테스트를 중단하고 현재 정식 버전 v2.5.2 또는 이후 공식적으로 수정이 확인된 정식 버전을 다시 설치하되 우선 Service는 제거된 상태로 유지하세요.

‘그래도 종료’를 반복해서 누르거나 전원 버튼을 길게 누르지 마세요. AppData 설정 디렉터리 전체를 삭제하거나 알 수 없는 Windows 서비스 또는 가상 네트워크 어댑터를 직접 제거하지 말고, 테스트를 위해 출처가 불분명한 AutoBuild를 다운로드하지도 마세요.

프로세스를 강제 종료하면 한 번의 차단은 해제할 수 있지만 설정 저장과 프록시 정리를 건너뛸 수 있습니다. 종료를 취소하고 모든 작업을 저장했으며 클라이언트가 자체적으로 종료되지 않는 것을 확인한 경우에만 작업 관리자에서 GUI를 종료하는 방법을 현재 데스크톱을 복구하기 위한 마지막 수단으로 사용하세요. 그 뒤에도 시스템 프록시를 확인해야 합니다.

한 가지 대응을 선택한 뒤 통제할 수 있는 시간에 두 번 연속 다시 시작하세요. 매번 작업을 먼저 저장하고 차단 화면이 나타났는지 기록하며, 다시 로그인한 뒤 시스템 프록시, 구독, Profile 및 규칙을 확인하세요.

종료가 더 이상 막히지 않는 것은 첫 번째 결과일 뿐입니다. 종료 전 로그에서 코어 중지가 완료되었는지, 다시 시작한 뒤 Windows에 프록시 설정이 남아 있지 않은지, 클라이언트를 다시 열었을 때 설정이 온전한지, 시스템 프록시로 새 HTTPS 요청을 완료할 수 있는지도 확인해야 합니다.

2026-09-01 기준 현재 증거로 다음은 확인할 수 있습니다. Clash Verge Rev의 Windows 종료 차단은 단일 사용자 제보가 아니며 Service Mode와 GUI를 실행 상태로 유지한 환경에서 여러 차례 보고되었고, 공식 협업자도 issue #7755에서 재현했습니다.

하지만 ‘Service IPC가 유일한 근본 원인으로 공식 확인되었다’고 단정할 수는 없습니다. issue #7725는 유지 관리자가 Service 리팩터링 후 다시 테스트해 달라고 요청하면서 닫힌 것이며 공식 수정 공지가 아닙니다. 이후 issue #7794에서는 리팩터링 후 AutoBuild에서도 재현된다고 보고했고 #7841에는 Windows 10의 v2.5.2에서 같은 현상이 기록되었습니다.

정식 버전 릴리스 노트에는 아직 이 문제가 수정되었다는 발표가 없습니다. 추가로 보고할 때는 민감 정보를 제거한 로그, 버전, Running Mode, 수동 종료 비교 결과 및 Service 설치 여부를 제공하고 전체 프로세스 덤프, 구독 또는 노드 인증 정보는 공개하지 마세요.