먼저 확인할 점: 화면이 종료됐나요, mihomo 코어가 종료됐나요?

클라이언트를 더블 클릭해도 창이 보이지 않는다고 해서 반드시 프로그램이 충돌한 것은 아닙니다. 일부 클라이언트는 이전의 ‘시작 후 최소화’ 설정을 복원해 알림 영역에만 아이콘을 표시합니다. 먼저 작업 표시줄 오른쪽의 펼침 화살표를 클릭한 다음, ‘작업 관리자’ → ‘세부 정보’에서 클라이언트 프로세스가 실행 중인지 확인하세요. 숨겨진 창이 없는 것을 확인한 뒤 아래 항목을 점검합니다.

Clash 클라이언트는 화면 인터페이스, 설정 관리, 프록시 코어 등으로 구성됩니다. 인터페이스는 정상적으로 열리지만 mihomo 코어가 시작되지 않을 수도 있고, 코어는 백그라운드에서 실행 중인데 화면 렌더링만 실패할 수도 있습니다. 두 경우의 해결 방법은 다르므로 ‘열리지 않는다’는 이유만으로 원인을 단정하지 마세요.

화면에 나타나는 증상먼저 확인할 항목기록할 단서
창이 뜬 직후 사라짐응용 프로그램 충돌 기록, 남은 설정 파일오류 모듈, 예외 코드, 발생 시각
흰 화면이지만 프로세스는 계속 실행됨인터페이스 런타임, 렌더링 프로세스WebView2 사용 여부, 렌더링 오류 여부
시작 화면에서 멈추거나 코어 연결 실패가 표시됨서비스 상태, 제어 인터페이스, 코어 로그서비스 오류, 리스닝 주소, 설정 파싱 오류
창은 정상인데 웹페이지가 열리지 않음시스템 프록시, 노드, 규칙실제 프록시 포트, 연결 로그, 적용된 정책

1단계: 버전과 Windows 오류를 기록하고 재설치를 반복하지 마세요

클라이언트 이름, 전체 버전 번호, Windows 버전, 설치 파일의 아키텍처를 먼저 기록하세요. 클라이언트 버전과 mihomo 코어 버전은 서로 다른 정보이며 대체할 수 없습니다. 인터페이스가 열리면 ‘정보’ 또는 버전 정보 페이지에서 확인하세요. 열리지 않으면 설치 파일 이름과 실행 파일의 ‘속성’ → ‘자세히’ 탭을 살펴보세요. 파일 속성에 코어 버전이 없을 수도 있으므로, 확인되지 않는 항목은 확인할 수 없다고 기록하세요.

  1. Win + R을 누르고 winver를 실행해 Windows 버전과 OS 빌드 번호를 기록하세요.
  2. ‘설정’ → ‘시스템’ → ‘시스템 정보’에서 ‘시스템 종류’를 확인해 x64와 ARM64를 구분한 뒤, 클라이언트 배포 안내에 맞는 빌드를 선택하세요.
  3. Win + R을 누르고 perfmon /rel을 실행하세요. 안정성 모니터에서 방금 발생한 앱 오류를 찾아 기술 정보를 여세요.
  4. 해당 항목이 없다면 eventvwr.msc를 실행하고 ‘Windows 로그’ → ‘응용 프로그램’에서 실행 실패 시각을 기준으로 오류를 찾아보세요.

‘오류가 발생한 응용 프로그램 이름’, ‘오류 모듈 이름’, ‘예외 코드’, 발생 시각을 기록하세요. 기록에 시스템 DLL이 표시되더라도 충돌 과정에서 해당 모듈이 사용됐다는 뜻일 뿐, DLL이 손상됐다고 단정할 수는 없습니다. 출처가 불분명한 다운로드 사이트에서 DLL만 따로 받지 마세요. 런타임, 서비스, 설정을 한꺼번에 변경하면 어떤 조치가 효과가 있었는지 알기 어렵습니다.

2단계: 흰 화면이 나타나면 WebView2 의존 여부부터 확인하세요

모든 Clash 클라이언트가 WebView2를 사용하는 것은 아닙니다. Tauri 기반 Windows 클라이언트는 보통 WebView2로 화면을 표시합니다. 이전 버전의 Clash for Windows는 Electron을 사용하며 자체 Chromium을 포함하는 경우가 많습니다. Flutter 클라이언트에는 WebView2 해결 방법을 그대로 적용할 수 없습니다. 먼저 현재 클라이언트의 프로젝트 안내와 설치 메시지를 확인한 뒤 런타임을 점검하세요.

점검 및 복구 순서

  1. Windows 11에서 ‘설정’ → ‘앱’ → ‘설치된 앱’을 열고 Microsoft Edge WebView2 Runtime을 검색하세요. Windows 10에서는 ‘앱 및 기능’에서 찾거나, 일부 시스템의 경우 ‘제어판’ → ‘프로그램 및 기능’에서 확인할 수 있습니다.
  2. 클라이언트에서 WebView2가 필요하다고 명시했는데 설치되어 있지 않다면 Microsoft 공식 배포 페이지에서 Evergreen 런타임 설치 프로그램을 받으세요. 오프라인 환경에서는 시스템 아키텍처에 맞는 독립 설치 패키지를 사용하세요.
  3. 이미 설치되어 있다면 해당 런타임을 사용하는 앱을 먼저 종료한 뒤, Windows에서 제공하는 ‘수정’ 기능이나 설치 프로그램의 복구 기능을 이용하세요. 설치 방식에 따라 메뉴가 다르므로 이름이 같은 버튼을 억지로 찾을 필요는 없습니다.
  4. 설치 또는 복구가 끝나면 클라이언트를 다시 실행하세요. 설치 프로그램에서 Windows 재시작을 요청하면 먼저 재시작한 다음 다음 테스트를 진행하세요.

Microsoft Edge 브라우저가 설치되어 있어도 클라이언트에서 필요한 WebView2 런타임이 온전하다는 뜻은 아닙니다. 반대로 흰 화면이 나타났다고 해서 WebView2 손상으로 단정할 수도 없습니다. 렌더링 프로세스 오류, 손상된 UI 캐시, 보안 소프트웨어의 차단도 비슷한 증상을 일으킬 수 있습니다.

로그에서 그래픽 렌더링 문제가 확인되면 기기 제조업체가 제공하는 그래픽 드라이버를 업데이트하고, 클라이언트에 ‘하드웨어 가속’ 옵션이 있는지 확인하세요. 현재 버전의 문서에서 지원을 명확히 안내하는 경우에만 해당 옵션이나 실행 인수를 사용하세요. Electron용 인수를 Tauri나 Flutter 프로그램에 그대로 추가하지 마세요.

3단계: TUN을 끄고 서비스와 일반 프록시를 따로 확인하세요

서비스 모드는 보통 백그라운드 구성 요소가 필요한 권한으로 실행되도록 하는 기능이고, TUN 모드는 가상 네트워크 어댑터를 통해 트래픽을 처리하는 기능입니다. 둘은 같은 기능이 아닙니다. 클라이언트에 서비스를 설치해도 TUN을 켤 필요는 없습니다. 일반 시스템 프록시를 사용할 때도 대개 인터페이스 전체를 항상 관리자 권한으로 실행할 필요는 없습니다. 실행 문제가 발생하면 인터페이스, 코어, 서비스, TUN을 나눠서 확인하세요.

인터페이스가 계속 열리는 경우

  1. 먼저 TUN 모드를 끄고 일반 프록시 환경에서 테스트하세요. 설정 항목 이름은 클라이언트마다 다르므로 실제 인터페이스를 기준으로 확인하세요.
  2. 클라이언트를 완전히 종료한 다음 다시 열어 기본 화면에 진입하고 설정을 읽으며 코어 로그를 표시할 수 있는지 확인하세요.
  3. 일반 모드가 정상이라면 클라이언트의 서비스 관리 메뉴에서 서비스 상태를 확인하세요. 서비스를 설치하거나 복구할 때는 Windows 권한 확인 창에 표시된 프로그램의 출처를 확인하세요.
  4. 서비스 복구가 끝난 뒤 TUN을 따로 켜고 가상 네트워크 어댑터 생성, 라우팅 설정, 권한 오류가 발생하는지 확인하세요.

서비스 연결 단계에서 멈추는 경우

Win + R을 누르고 services.msc를 실행하세요. 서비스 이름은 클라이언트마다 다르므로 온라인 안내만 보고 이름을 추측하지 마세요. 해당 서비스의 속성을 열어 실행 파일 경로가 현재 설치 폴더를 가리키는지 확인하세요. 포터블 버전 폴더를 다른 위치로 옮기면 이전 경로를 참조하는 서비스가 남을 수 있습니다. 클라이언트를 제거한 뒤 서비스가 남아 충돌을 일으키기도 합니다.

현재 클라이언트에서 제공하는 서비스 복구 또는 재설치 기능을 우선 사용하세요. 출처를 알 수 없는 서비스 삭제 명령을 직접 실행하거나 이전 클라이언트의 서비스 프로그램을 새 클라이언트 폴더에 복사하지 마세요. TUN을 켰을 때만 오류가 난다면 함께 실행 중인 VPN, 가상 머신 네트워크 소프트웨어, 다른 TUN 클라이언트도 기록하세요. 하나씩 종료해 테스트하고 모든 네트워크 어댑터를 한꺼번에 초기화하지 마세요.

4단계: 포트 점유를 확인하고 7890만 바꾸지 마세요

로그에 address already in use 또는 bind 오류가 있다면 리스닝에 실패한 경우가 많습니다. 7890은 프록시 포트 설정에, 9090은 제어 인터페이스 예시에 자주 나오지만 모든 클라이언트가 같은 값을 사용하는 것은 아닙니다. 실제로 생성된 설정에서 mixed-port, port, socks-port, external-controller 값을 확인하세요.

예를 들어 설정에 mixed-port: 7890이 있고 제어 인터페이스 주소가 127.0.0.1:9090이라면 PowerShell에서 두 TCP 리스닝 포트를 확인할 수 있습니다.

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

출력의 OwningProcess는 프로세스 ID입니다. ‘작업 관리자’ → ‘세부 정보’의 PID와 대조한 다음 프로세스 경로를 확인하세요. 출력이 없으면 조회 시점에 해당 TCP 포트 두 개가 리스닝 중이 아니었다는 뜻입니다. 다른 포트나 UDP 리스닝 문제까지 배제되는 것은 아닙니다. 로그에 UDP 충돌이 표시되면 실제 포트에 대해 Get-NetUDPEndpoint를 사용해 확인하세요.

  • 이전 클라이언트가 점유 중: 이전 클라이언트를 트레이 메뉴에서 정상 종료하고 백그라운드 서비스도 중지됐는지 확인하세요.
  • 같은 클라이언트를 중복 실행: 해당 클라이언트의 잔여 프로세스임을 확인한 뒤 종료하고 한 번만 다시 실행하세요.
  • 다른 프로그램이 점유 중: 어떤 프로그램인지 확인한 뒤 한쪽의 포트를 변경하세요. 정체를 알 수 없는 시스템 프로세스를 종료하지 마세요.

프록시 포트를 변경했다면 Windows 시스템 프록시 주소도 함께 확인하세요. 제어 인터페이스를 변경했다면 인터페이스가 연결하는 주소와 코어 설정이 일치해야 합니다. 제어 인터페이스에 인증 키가 필요한 경우 주소가 맞더라도 인증 정보가 다르면 ‘코어 연결 실패’가 나타날 수 있습니다. 점검 중에는 제어 인터페이스가 로컬에서만 리스닝하도록 유지하세요. 연결을 위해 모든 네트워크 어댑터에 함부로 공개하지 마세요.

5단계: 설정 잔여 파일을 분리하고 복구 가능한 백업을 보관하세요

덮어쓰기 설치는 보통 프로그램 파일만 교체하며 사용자 데이터는 지우지 않습니다. 따라서 업데이트 후 실행 직후 종료되거나 이전 설정을 복원한 뒤 흰 화면이 나타나는 문제는 남은 설정이나 설정 구조 변경과 관련이 있을 수 있습니다. 처음부터 폴더 전체를 삭제하지 말고 백업을 만든 뒤 새 설정으로 테스트하세요.

데이터 폴더 찾기

인터페이스가 열리면 클라이언트에서 제공하는 설정 폴더, 데이터 폴더, 로그 폴더 메뉴를 먼저 사용하세요. 인터페이스가 열리지 않으면 파일 탐색기 주소 표시줄에 %APPDATA%와 %LOCALAPPDATA%를 각각 입력하고, 클라이언트 문서와 폴더 안의 로그를 확인해 해당 폴더를 찾으세요. 포터블 모드에서는 프로그램 옆에 데이터가 저장될 수도 있습니다. 폴더 이름은 클라이언트와 버전에 따라 다릅니다.

  1. 클라이언트를 완전히 종료하고 해당 클라이언트의 프로세스임을 확인한 백그라운드 서비스도 중지하세요. 백업 중 파일이 계속 기록되는 상황을 방지할 수 있습니다.
  2. 확인된 데이터 폴더를 로컬 백업 위치에 복사하고 구독, 오버라이드, 규칙, 인증서, 로그를 보관하세요.
  3. 백업을 정상적으로 읽을 수 있는지 확인한 뒤 원래 폴더의 이름을 바꾸세요. 예를 들어 폴더 이름 뒤에 .backup-20260821을 추가하고 바로 삭제하지 마세요.
  4. 클라이언트를 다시 실행해 기본 데이터 폴더를 만들게 하세요. 구독과 오버라이드는 복원하지 않은 상태로 창과 코어가 안정적으로 시작되는지 확인하세요.
  5. 정상 작동하면 구독 하나만 가져온 뒤 사용자 지정 규칙, 오버라이드, TUN 설정을 하나씩 복원하세요. 변경할 때마다 다시 테스트합니다.

‘새 데이터에서는 정상이고 특정 설정을 복원한 뒤 실패한다면’ 원인은 해당 설정으로 좁혀집니다. YAML 들여쓰기 오류, 존재하지 않는 정책 그룹 참조, 현재 코어에서 지원하지 않는 필드 때문에 코어가 설정을 불러오지 못할 수 있지만, 반드시 인터페이스가 충돌하는 것은 아닙니다. 로그를 바탕으로 파싱 실패와 프로세스 충돌을 구분한 뒤 YAML 설명서를 확인하세요. 모든 문제를 구독 오류로 단정하지 마세요.

6단계: 보안 차단을 확인하고 통제된 방식으로 재설치하세요

인터페이스를 실행한 뒤 코어 파일이 없다는 메시지가 나오거나, 재설치할 때마다 같은 파일이 사라진다면 ‘Windows 보안’ → ‘바이러스 및 위협 방지’ → ‘보호 기록’을 열어 차단 시각, 파일 경로, 탐지 이름을 확인하세요. 경로와 오류 시각이 일치해야 합니다. 보호 기록에 경고가 있다는 이유만으로 현재 문제의 원인이라고 단정할 수는 없습니다.

먼저 설치 파일의 출처와 게시자, 현재 프로젝트의 시스템 요구 사항을 확인하세요. 파일을 신뢰할 수 있고 경고의 의미를 이해한 경우에만 해당 프로젝트에 맞는 복구 방법을 고려하세요. 전체 보안 기능을 끄거나 다운로드 폴더 전체를 제외 대상으로 추가하는 것은 권장하지 않습니다. 회사나 기관의 기기에서 정책 제한이 발생하면 관리자에게 문의하세요.

  • 신뢰할 수 있는 배포 경로에서 시스템 아키텍처에 맞는 전체 설치 파일을 다시 받으세요. 실행 파일 하나만 따로 복사하지 마세요.
  • 이전 인스턴스가 종료됐는지 확인하고 클라이언트 안내에 따라 기존 서비스를 처리하세요. 앞 단계에서 만든 데이터 백업은 보관합니다.
  • 변경되지 않는 로컬 경로에 설치하고 기본 데이터로 먼저 실행한 다음 구독을 복원하세요.
  • 특정 업데이트 후에만 문제가 다시 발생한다면 업데이트 전후의 전체 버전 번호를 기록하고 프로젝트 안내에 따라 롤백을 검토하세요. 이전 버전으로 새 버전의 데이터 구조를 덮어쓰지 마세요.

이전 버전 Clash for Windows의 Electron 인터페이스 문제와 mihomo를 사용하는 새 클라이언트의 서비스 문제는 같은 원인으로 볼 수 없습니다. 클라이언트를 바꿀 때 이전 데이터 폴더 전체를 그대로 복사하지 마세요. 구독, 사용자 지정 규칙, 오버라이드를 각각 옮기고 클라이언트 선택은 클라이언트 비교를 참고하세요.

복구 확인 및 문제 제보

창이 표시되는 것은 첫 단계일 뿐입니다. 아래 순서대로 확인해야 문제가 해결된 것인지, 오류를 일시적으로 우회한 것인지 알 수 있습니다.

  1. 재시작 확인: 정상 종료한 뒤 다시 실행해 인터페이스와 코어가 모두 시작되는지 확인하세요. 작업 관리자에서 프로세스를 반복해서 종료하지 않아도 되어야 합니다.
  2. 일반 프록시 확인: 실제 프록시 포트를 사용해 시스템 프록시를 테스트하고 연결 로그와 적용된 규칙을 확인하세요. 노드 지연 시간 테스트에 성공해도 앱 요청이 프록시를 통과한다고 보장되지는 않습니다.
  3. TUN 확인: 필요한 경우에만 TUN을 켜고 서비스, 가상 네트워크 어댑터, 로그를 확인하세요. 필요하지 않다면 일반 프록시를 사용하면서 TUN을 꺼 두어도 됩니다.
  4. 종료 확인: 클라이언트를 정상 종료한 뒤 시스템 프록시가 예상대로 복원되는지 확인하세요. 다음에 PC를 켰을 때 브라우저가 더 이상 리스닝하지 않는 포트에 연결하는 일을 방지할 수 있습니다.

문제가 계속되면 Windows 버전과 아키텍처, 클라이언트 및 코어 버전, 문제가 발생한 시각, 재현 절차, 서비스와 TUN 사용 여부, 오류 전후의 일부 로그, 새 데이터 폴더로 테스트한 결과를 함께 제보하세요. 버전 정보는 유지 관리자가 코드 변경 사항을 확인하는 데 도움이 되고, 항목별 테스트 결과는 중복된 해결책을 줄이는 데 도움이 됩니다.

설정을 이어서 진행하려면 구독 가져오기 안내와 연결 확인 방법을 참고하세요. 시작 문제를 해결할 때는 항상 ‘한 번에 한 항목만 변경’하세요. 먼저 인터페이스를 복구하고, 다음으로 코어를 확인한 뒤 서비스, TUN, 사용자 지정 설정을 복원합니다.