1. 종료된 것이 창인지 프록시 커널인지 먼저 확인

창이 사라졌다고 해서 반드시 프로그램이 충돌한 것은 아닙니다.Clash 계열 클라이언트는 보통 버튼, 설정 목록, 환경설정을 담당하는 그래픽 인터페이스와 실제 연결을 받아 규칙을 적용하는 프록시 커널로 구성됩니다. mihomo는 일부 클라이언트에서 사용하는 프록시 커널이며 Clash Meta라고도 합니다. 두 구성 요소는 각각 문제를 일으킬 수 있으므로, 먼저 어느 쪽에 문제가 생겼는지 구분하세요.

  1. 시스템 트레이에 클라이언트 아이콘이 남아 있는지 확인하세요. Windows에서는 작업 표시줄의 숨겨진 아이콘 영역에 있을 수 있습니다. 아이콘이 보인다면 트레이에서 기본 창을 다시 열고, 시작 시 최소화 옵션이 켜져 있는지 확인하세요.
  2. Ctrl + Shift + Esc를 눌러 작업 관리자를 열고, ‘세부 정보’에서 클라이언트와 커널 프로세스를 확인하세요. 아이콘만 보고 판단하지 말고 프로세스 이름을 기록해 두세요.
  3. 창은 열리지만 커널이 실행되지 않았다고 표시되면 커널 로그를 먼저 확인하세요. 그래픽 인터페이스 프로세스도 바로 사라진다면 클라이언트 로그와 시스템 충돌 기록을 우선 살펴보세요.
  4. 다른 프록시 클라이언트를 종료한 뒤 문제가 발생한 클라이언트를 다시 실행하세요. 프로그램 두 개가 동시에 실행되면 로컬 포트나 가상 네트워크 어댑터를 놓고 충돌할 수 있습니다.

2. 로그 위치 찾기: 실행 전후에 기록된 첫 오류 확인

로그 위치는 클라이언트마다 다르며, ‘Clash’라는 통칭만으로 정해지지 않습니다.설치 폴더, 사용자 데이터 폴더, 커널 작업 폴더가 서로 다를 수 있습니다. 인터넷에서 찾은 폴더 경로를 그대로 복사해 자신의 로그가 반드시 그곳에 있다고 단정하지 마세요.

창이 몇 초라도 열려 있을 때

클라이언트 설정에서 ‘로그 폴더 열기’ 또는 ‘설정 폴더 열기’ 기능을 먼저 찾아보세요. 메뉴 이름과 위치는 클라이언트마다 다릅니다. 폴더가 열리면 로그 폴더 전체를 복사하고, 예를 들어 09:42:10처럼 실행 시각을 기록하세요. 그런 다음 한 번 더 실행해 해당 시각 이후에 추가된 로그를 확인하세요. 이전 오류만 반복해서 읽지 않는 것이 중요합니다.

창이 전혀 열리지 않을 때

로그에서는 먼저 시작을 중단시킨 첫 오류를 찾고, 그 앞뒤로 20줄씩 확인하세요. 마지막에 표시된 ‘연결 거부’는 커널이 이미 종료된 결과일 수 있습니다. 오류 모듈에 그래픽 런타임이 표시되어도 그래픽 드라이버가 원인이라고 단정할 수는 없으므로 클라이언트 로그와 함께 판단하세요.

로그 단서우선 확인할 항목다음 단계
address already in use수신 대기 포트가 사용 중사용 중인 프로세스를 확인하고, 바로 재설치하지 마세요
yaml、unmarshal설정 구조 또는 필드 형식실제로 불러온 설정 파일을 테스트하세요
no such file、not found커널 또는 필수 리소스를 찾을 수 없음오류에 표시된 경로와 설치 파일을 확인하세요
permission denied폴더, 실행 권한 또는 서비스 권한현재 계정과 폴더 권한을 확인하세요
access is denied권한, 포트 제외 또는 보안 차단전체 오류 내용을 확인하세요. 모두 포트 충돌로 볼 수는 없습니다

3. 포트 충돌: 7890 및 9090을 사용하는 프로세스 확인

포트 충돌은 보통 커널 실행에 영향을 주며, 인터페이스 전체가 강제 종료되는 원인은 아닐 수 있습니다.7890은 로컬 프록시 포트, 9090은 제어 인터페이스 포트로 자주 사용되지만 둘 다 변경할 수 있습니다. 로그와 현재 설정을 기준으로 확인하세요. 오류에 7897이 표시된다면 7897을 조회해야 합니다.

Windows PowerShell에서 아래 명령을 실행해 예시 포트의 TCP 수신 대기 프로세스를 확인하세요. 아무것도 출력되지 않아도 조회 시점에 해당 포트에서 수신 대기하는 프로세스가 없다는 뜻일 뿐, 방금 종료된 프로세스까지 배제할 수는 없습니다.

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

출력에 프로세스 ID가 4321로 표시되었다고 가정하고, 다음으로 프로세스 정보를 조회하세요. 4321은 예시이므로 실행할 때는 실제 조회된 ID로 바꿔야 합니다.

Get-Process -Id 4321 | Select-Object Id,ProcessName,Path
  1. 사용 중인 프로세스가 다른 프록시 프로그램이라면 트레이 메뉴에서 정상적으로 종료하세요. 정체를 모르는 시스템 프로세스를 바로 강제 종료하지 마세요.
  2. 사용 중인 프로세스가 같은 클라이언트의 잔류 커널이라면 클라이언트와 백그라운드 서비스를 먼저 종료하세요. 해당 프로세스를 사용하는 연결이 없는지 확인한 뒤 잔류 프로세스를 처리하세요.
  3. 프로그램 두 개를 함께 사용해야 한다면 한쪽의 프록시 포트를 사용 중이지 않은 7893으로, 제어 포트를 사용 중이지 않은 9093으로 바꿀 수 있습니다. 앱에 수동으로 입력한 프록시 주소도 함께 업데이트하세요. 설정만 바꾸고 기존 포트를 그대로 두면 안 됩니다.

수신 대기 프로세스가 없는데 Windows에서 포트 접근이 거부된다면 netsh interface ipv4 show excludedportrange protocol=tcp를 실행해 TCP 제외 포트 범위를 확인할 수 있습니다. 시스템 예약 범위를 임의로 삭제하지 말고, 먼저 해당 범위 밖에서 사용 가능한 포트를 선택하세요. UDP 바인딩 오류는 UDP 엔드포인트를 별도로 확인해야 하며, TCP 조회만으로 결론을 내려서는 안 됩니다.

4. 설정 복원: 먼저 YAML을 테스트하고 클라이언트의 병합 설정 확인

복원할 때는 임의로 필드를 삭제하지 말고 정상 작동하던 설정 전체를 되돌리세요.YAML은 들여쓰기로 구조를 나타내는 텍스트 형식입니다. 탭 문자가 섞이거나 숫자를 잘못된 형식으로 입력하거나 존재하지 않는 정책 그룹을 참조하면 설정을 불러오지 못할 수 있습니다. 구독을 정상적으로 내려받았다고 해서 그 내용이 현재 커널에 적합하다는 뜻은 아닙니다.

최근 변경 사항부터 확인 범위 좁히기

현재 커널로 설정 테스트

mihomo의 -t는 설정을 테스트한 뒤 종료하는 옵션이고, -f는 설정 파일, -d는 작업 디렉터리를 지정합니다. 아래 예시에서는 현재 클라이언트에 포함된 커널과 테스트할 설정 파일을 D:\ClashRecovery에 넣고, 파일 이름을 각각 mihomo.exe와 candidate.yaml로 지정했다고 가정합니다. 실제 경로가 다르면 알맞게 바꾸세요.

Set-Location 'D:\ClashRecovery'
.\mihomo.exe -t -d 'D:\ClashRecovery' -f 'D:\ClashRecovery\candidate.yaml'

작업 디렉터리에 지리 데이터나 규칙 리소스가 필요할 수도 있습니다. 리소스 누락 메시지가 표시되면 들여쓰기 오류로 단정하지 말고 현재 설정에 맞는 리소스를 먼저 준비하세요. 테스트를 통과했다는 것은 해당 커널이 설정을 불러올 수 있다는 뜻일 뿐, 노드 연결이나 원격 규칙 다운로드, 그래픽 인터페이스의 정상 작동까지 보장하지는 않습니다.

5. 커널 누락, 아키텍처 불일치 및 실행 환경 오류

로그에서 파일 누락이나 로드 실패를 명확히 가리킬 때만 프로그램 파일을 확인하세요.‘커널이 실행되지 않음’은 설정 오류 때문일 수도 있으므로 커널 파일이 사라졌다는 뜻은 아닙니다. 먼저 오류에 표시된 전체 경로를 확인하고, 파일이 존재하는지, 이동되지는 않았는지, 현재 사용자에게 읽기 및 실행 권한이 있는지 살펴보세요.

설치 파일과 기기 아키텍처 확인

Windows에서는 ‘설정’ → ‘시스템’ → ‘정보’에서 시스템 종류를 확인할 수 있고, Linux에서는 uname -m을 실행하면 됩니다. 기기와 클라이언트의 지원 여부에 맞춰 x64 또는 ARM64 설치 파일을 선택하세요. 다른 클라이언트의 커널 파일 이름을 바꿔 덮어쓰지 마세요. 실행 옵션, 제어 인터페이스, 관련 리소스가 다를 수 있습니다.

보안 기록 및 종속성 안내에 따라 확인

일반 모드에서는 실행되지만 TUN을 켰을 때만 실패한다면 가상 네트워크 어댑터, 서비스 설치 상태, 권한을 확인하세요. 비교를 위해 TUN을 잠시 끄고 테스트하세요. 모든 강제 종료 문제를 ‘관리자 권한으로 항상 실행’으로 해결하려고 하지 마세요.

6. 안전하게 재설치하기: 프로그램과 사용자 데이터를 따로 확인

재설치 전에 데이터를 보관하고, 재설치 직후 모든 데이터를 한꺼번에 복원하지 마세요.프로그램 파일만 덮어쓰면 문제를 일으킨 사용자 설정이 남을 수 있고, 데이터 폴더 전체를 삭제하면 로컬 규칙과 구독 기록을 잃을 수 있습니다. 백업 후 기존 데이터를 분리하고 하나씩 복원하는 편이 안전합니다.

  1. 현재 상태 기록:클라이언트 이름과 버전, 커널 버전, 운영체제 버전, 마지막으로 실행에 성공한 시각, 최근 업데이트나 설정 변경 내용을 기록하세요.
  2. 데이터 백업:프로그램과 관련 서비스가 완전히 종료된 뒤 설정, 구독 기록, 로컬 규칙, 오버라이드 스크립트, 로그를 복사하세요. 인증 정보가 포함된 백업은 보호된 로컬 폴더에 보관하세요.
  3. 기존 폴더 분리:실제 사용자 데이터 폴더를 확인한 다음 이름을 날짜가 포함된 백업 폴더로 바꾸세요. 예를 들어 기존 이름 뒤에 -backup-20261015를 추가할 수 있습니다. 폴더가 사용 중이라면 백그라운드 프로세스부터 해결하고 강제로 삭제하지 마세요.
  4. 재설치:클라이언트 문서에 따라 프로그램을 제거하세요. 서비스 모드를 사용한다면 프로젝트 안내에 따라 해당 서비스를 제거하세요. 기기 아키텍처에 맞는 안정 버전을 설치하고 다른 프로젝트의 프로그램 파일을 섞어 설치하지 마세요.
  5. 데이터 없이 먼저 실행:새 인스턴스가 새 데이터 폴더를 사용하는지 확인하고, 기존 구독, 스크립트, TUN 설정을 복원하지 않은 상태로 창을 여세요. 일부 클라이언트는 설정을 선택하지 않으면 커널을 실행하지 않습니다. 이는 인터페이스가 강제 종료되는 문제와는 다릅니다.
  6. 항목별로 복원:먼저 작동이 확인된 설정 하나를 가져와 실행하고 로그를 확인하세요. 이후 로컬 규칙, 오버라이드, 시스템 프록시, TUN을 차례로 복원하세요. 매번 한 항목씩만 변경하면 문제를 일으키는 조건을 찾기 쉽습니다.

데이터가 없는 상태에서도 강제 종료된다면 시스템 호환성, 런타임, 설치 파일 손상 또는 클라이언트 자체 결함을 중점적으로 확인하세요. 새 데이터에서는 정상 작동하지만 기존 데이터를 복원한 뒤 문제가 재현된다면 새 폴더는 유지하고 기존 항목을 나눠서 복원하세요. 백업 전체를 한 번에 덮어쓰지 마세요.

7. 복구 후 확인 및 문의에 필요한 정보

창이 열리는 것은 첫 단계일 뿐입니다. 설정과 연결도 정상적으로 복구됐는지 확인하세요.클라이언트를 2분간 실행해 커널이 반복해서 재시작하는지 살펴보세요. 선택된 설정, 프록시 모드, 정책 그룹도 확인하세요. 규칙 모드에서는 규칙에 따라 연결 방식이 선택되므로 특정 사이트에 직접 연결되더라도 프록시가 고장 났다고 볼 수는 없습니다.

문제 해결 순서는 간단하게 유지하면 됩니다. 먼저 종료된 대상을 확인하고 로그를 읽으세요. 포트 오류가 있으면 포트를 확인하고, 설정 오류가 있으면 설정을 복원하며, 파일 오류가 있을 때 설치 파일을 점검하세요. 매 단계에서 복구 가능한 백업을 보관하면 계속 재설치하는 것보다 실제 원인을 찾기 쉽습니다.