Clash 실행 직후 종료될 때 해결 방법: 로그 확인, 설정 복원, 권한 점검

창이 닫힌 것인지, UI가 충돌한 것인지, 커널이 종료된 것인지 먼저 구분하세요

“Clash를 켜자마자 종료된다”는 증상은 창이 트레이로 숨겨진 경우, UI 프로세스가 충돌한 경우, UI는 남아 있지만 커널 시작에 실패한 경우로 나뉩니다. 설정 오류나 포트 충돌은 보통 커널에 먼저 영향을 주며 클라이언트 전체가 종료되는 것은 아닙니다. 먼저 문제가 발생한 계층을 확인한 뒤 설정을 점검할지 실행 환경을 복구할지 결정하세요.

1. 백그라운드 프로세스를 확인하세요. Windows에서는 Ctrl + Shift + Esc를 눌러 작업 관리자를 엽니다. macOS에서는 ‘활성 상태 보기’를 열고, Linux에서는 ps -ef를 실행하세요. 창이 사라졌어도 클라이언트와 커널이 실행 중이라면 트레이, 메뉴 막대, 여러 모니터의 창 위치를 먼저 확인하세요.
2. 문제가 재현되는 조건을 기록하세요. 첫 설치부터 실패했는지, 업데이트 후 실패했는지, 구독을 가져온 뒤 실패했는지, TUN을 켠 뒤 실패했는지 구분하세요. 운영체제 버전, CPU 아키텍처, 클라이언트 버전, 커널 버전을 기록하고 ‘최신 버전’이라고만 적지 마세요.
3. 클라이언트를 완전히 종료하세요. 트레이 메뉴에서 종료한 뒤 관련 프로세스가 끝났는지 확인하고 다시 실행하세요. 이전 인스턴스가 백그라운드에서 포트를 계속 사용하고 있을 수 있습니다. 반복해서 아이콘을 클릭하면 원인 파악만 더 어려워집니다.

로그 확인: 실행 시각과 첫 오류를 보존하세요

클라이언트 로그, 커널 로그, 시스템 충돌 보고서는 각각 다른 문제를 보여 줍니다. 클라이언트 로그에서는 UI 초기화, 커널 경로, 서비스 연결을 확인하고, 커널 로그에서는 YAML, 리스닝 포트, 규칙 로딩을 확인합니다. 시스템 보고서는 런타임 라이브러리, 동적 라이브러리, 비정상적인 프로세스 종료를 파악하는 데 유용합니다.

운영체제별 실행 실패 기록 확인

• Windows: Win + R을 누르고 eventvwr.msc를 입력한 다음 ‘Windows 로그’ → ‘응용 프로그램’으로 이동하세요. 문제가 발생한 시각의 ‘Application Error’ 등의 기록을 확인하고, 오류가 난 응용 프로그램과 모듈, 예외 코드를 보존하세요. 클라이언트 데이터는 %APPDATA% 또는 %LOCALAPPDATA% 아래에 있을 수 있으며, 포터블 버전은 프로그램 폴더에 기록하기도 합니다. 해당 클라이언트 문서와 시작 로그를 기준으로 확인하세요.
• macOS: ‘콘솔’을 열어 충돌 보고서를 확인하세요. ~/Library/Logs/DiagnosticReports/도 확인할 수 있습니다. 프로세스 이름, 예외 유형, 종료 원인을 기록하세요. 같은 시각에 생성된 다른 앱의 보고서를 프록시 클라이언트 로그로 착각하지 않도록 주의하세요.
• Linux: 설치된 실행 파일을 터미널에서 직접 실행해 표준 오류를 확인하세요. systemd를 사용하는 경우 journalctl --user -b --since "10 minutes ago"를 실행할 수 있습니다. 충돌 수집 기능이 활성화되어 있다면 coredumpctl list로 해당 프로세스를 찾으세요. 배포판에 따라 같은 수집 기능이 기본으로 활성화되어 있지 않을 수 있습니다.

오류 키워드에 따라 다음 점검 항목을 정하세요

로그 끝부분의 ‘커널이 중지되었습니다’는 대개 결과일 뿐입니다. 이번 실행에서 가장 먼저 발생한 구체적인 오류를 앞쪽에서 찾아 전후 약 30줄을 보존하세요. 공유하기 전에 구독 URL, 인증 정보, 컨트롤 인터페이스 키, 개인 폴더 이름을 가리세요. 프록시 노드 주소도 민감한 정보일 수 있습니다.

설정 복원: 실제로 로드되는 YAML을 검증하세요

구독을 업데이트한 직후 문제가 생겼다면 설정 변경을 먼저 의심하세요. 구독 원본 파일이 커널에서 실제로 읽는 최종 파일과 다를 수 있습니다. 클라이언트가 오버라이드, 스크립트, 규칙 조각, TUN 설정을 함께 적용할 수 있기 때문입니다. 다운로드한 구독만 검증해서는 병합 단계에서 생긴 오류를 찾을 수 없습니다.

1. 클라이언트를 완전히 종료하고 현재 구독, 오버라이드 파일, 클라이언트 설정을 백업하세요. 데이터 폴더를 바로 삭제하지 마세요.
2. 마지막으로 정상 실행됐던 설정을 복원하고 새로 추가한 오버라이드나 스크립트는 잠시 비활성화하세요. UI에 접근할 수 없다면 백업 후 클라이언트 문서에 따라 해당 설정 파일을 복원하세요. 내부 데이터베이스 구조를 임의로 추측하지 마세요.
3. 클라이언트에 실제 포함된 커널로 최종 설정을 테스트하세요. 구버전 Clash와 mihomo는 지원하는 프로토콜과 필드가 다르므로 다른 커널에서 통과한 결과로 대신할 수 없습니다.
4. 실행이 복구되면 구독 업데이트, 규칙 세트, 사용자 지정 DNS, TUN을 하나씩 활성화해 어떤 변경에서 문제가 재발하는지 확인하세요.

mihomo를 예로 들면 터미널에서 커널이 있는 폴더로 이동하고, 확인할 설정의 복사본을 해당 폴더에 config.yaml로 저장한 뒤 해당 명령을 실행하세요. 설정에서 상대 경로를 참조한다면 -d로 올바른 데이터 폴더를 지정하고 관련 파일 위치도 일치시켜야 합니다.

# Windows PowerShell
.\mihomo.exe -t -f .\config.yaml

# macOS / Linux
./mihomo -t -f ./config.yaml

-t는 설정을 테스트하는 옵션이며 원격 규칙 세트, 노드 연결 상태, 실행 중 권한까지 모두 검증하지는 않습니다. 로그에 특정 줄 번호가 표시되면 바로 앞 줄도 확인하세요. 콜론 누락, Tab 들여쓰기, 잘못된 목록 계층 때문에 파서가 다음 줄에서 오류를 보고할 수 있습니다.

최소 설정은 문제를 분리해 확인할 때만 사용하세요

아래 설정은 커널이 기본적으로 시작되는지 확인하기 위한 것으로 프록시 노드는 포함하지 않으며 모든 트래픽을 직접 연결합니다. 별도의 테스트 파일로 저장하고 검사가 끝나면 원래 설정으로 되돌리세요. 실제로 사용할 수 있는 프록시 구독으로 오해하지 마세요.

mixed-port: 17890
allow-lan: false
mode: rule
log-level: info

rules:
  - MATCH,DIRECT

최소 설정으로는 시작되지만 원래 설정에서 실패한다면 노드 프로토콜, 정책 그룹 참조, 규칙 세트 경로, 오버라이드 결과를 먼저 확인하세요. 최소 설정에서도 시작되지 않으면 포트, 커널 파일, 시스템 환경을 계속 점검하세요. 예시에 나온 17890 포트도 사용 중이 아닌지 확인해야 합니다.

포트 충돌: 리스닝 프로세스로 점유 원인을 확인하세요

일반적인 설정에서는 7890을 혼합 프록시 포트로, 9090을 컨트롤 인터페이스 포트로 사용하는 경우가 있지만 모든 클라이언트가 이 값을 쓰는 것은 아닙니다. 로그와 최종 설정을 기준으로 확인하세요. HTTP, SOCKS, DNS 리스닝 포트도 각각 충돌할 수 있습니다.

Windows에서 리스닝 PID 확인

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

Get-Process -Id 4321

두 번째 명령의 4321은 예시 PID이므로 첫 번째 명령이 반환한 값으로 바꾸세요. 이전 클라이언트가 확인되면 먼저 트레이 메뉴에서 종료하세요. 다른 서비스라면 용도를 확인한 뒤 조치하고, 정체를 모르는 시스템 프로세스는 바로 종료하지 마세요. 전체 정보를 읽을 권한이 없을 때만 필요에 따라 관리자 터미널을 사용하세요.

macOS 및 Linux에서 포트 확인

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

# Linux
ss -lntp

이 명령은 TCP 리스닝을 대상으로 합니다. DNS의 UDP 리스닝과 관련된 오류라면 lsof -nP -iUDP:1053 또는 Linux의 ss -lnup도 사용하고, 1053은 실제 포트로 바꾸세요. 포트를 변경한 뒤에는 시스템 프록시, 브라우저 확장 프로그램, 명령줄 프록시 환경 변수도 함께 업데이트해야 합니다. 그렇지 않으면 ‘클라이언트는 시작되지만 앱에서 인터넷에 연결할 수 없는’ 문제가 생길 수 있습니다.

커널 파일과 TUN 권한: 실패한 대상에 맞춰 복구하세요

업데이트 중단, 보안 프로그램의 파일 격리, 설치 폴더 쓰기 권한 부족 등으로 클라이언트가 커널을 찾지 못할 수 있습니다. 먼저 로그에서 실제 커널 경로를 확인하고 파일이 있는지 점검하세요. 임의로 다운로드한 바이너리의 이름만 바꿔 대체하지 마세요. 클라이언트가 특정 실행 인자, 컨트롤 인터페이스 동작, 관련 리소스에 의존할 수 있습니다.

• Windows: ‘Windows 보안’ → ‘바이러스 및 위협 방지’ → ‘보호 기록’에서 관련 기록이 있는지 확인하세요. 출처와 경고 내용을 확인한 뒤 조치하고, 전체 보호 기능을 끄지는 마세요. 설치 버전은 원래 설치 프로그램으로 복구하는 것이 좋습니다. 포터블 버전은 현재 사용자에게 쓰기 권한이 있는 새 폴더에 압축을 풀어 테스트할 수 있습니다.
• macOS: 설치 패키지가 Apple Silicon 또는 Intel 아키텍처에 맞는지 확인하세요. 시스템에서 앱이 차단됐다는 안내가 명확히 표시되면 출처를 확인한 뒤 ‘시스템 설정’ → ‘개인정보 보호 및 보안’에서 관련 옵션을 확인하세요. 다운로드 폴더 전체의 보안 속성을 일괄 제거하지 마세요.
• Linux: uname -m으로 시스템 아키텍처를 확인하고 file ./mihomo로 커널 파일 유형을 확인하세요. 파일이 있는데도 실행할 수 없다고 나오면 권한 부족으로 단정하지 말고 동적 로더, 마운트 옵션, 아키텍처도 점검해야 합니다.

Linux에서는 대상 파일을 신뢰할 수 있고 실행 권한만 실제로 빠진 경우에 한해 해당 파일에 chmod u+x ./mihomo를 실행하세요. 사용자 폴더 전체에 재귀적으로 광범위한 권한을 부여하지 말고, 데이터 폴더 권한 오류를 피하려고 그래픽 UI를 계속 root로 실행하지 마세요.

TUN을 켠 뒤 실패할 때 원인 분리하기

먼저 TUN을 끄고 커널과 로컬 프록시 포트만 시작하세요. 일반 프록시 모드는 작동하지만 TUN을 켠 뒤 장치 생성, 라우팅, 권한 오류가 발생한다면 가상 네트워크 인터페이스나 권한이 필요한 서비스 쪽으로 범위를 좁힐 수 있습니다. Windows 클라이언트는 보통 관리자 권한이나 서비스 모드로 관련 작업을 처리하고, macOS에서는 보조 프로그램 설치가 필요할 수 있습니다. Linux에서는 /dev/net/tun과 네트워크 관리 권한이 관련되는 경우가 많습니다. 설치 방법은 클라이언트 버전에 따라 다르므로 해당 버전에서 제공하는 서비스 설치 절차를 이용하세요.

기본 라우팅을 여러 도구가 동시에 변경하지 않도록 다른 VPN이나 TUN 클라이언트도 잠시 중지하고 테스트하세요. 복구 후에는 일반 프록시부터 확인한 다음 TUN을 활성화하세요. DNS, 라우팅, 구독을 한꺼번에 변경하면 어떤 조치가 효과가 있었는지 파악하기 어렵습니다.

UI 실행 환경: WebView2, Electron, 시스템 구성 요소

커널은 단독으로 시작되는데 창이 흰 화면으로 남거나 바로 사라진다면 그때 UI 실행 환경을 점검하세요. 클라이언트마다 사용하는 기술이 다릅니다. 일부 Windows 클라이언트는 WebView2에 의존하지만 다른 클라이언트는 Electron이나 Flutter를 사용합니다. 이름에 ‘Clash’가 있다는 이유만으로 WebView2를 무조건 다시 설치하면 실제 문제와 관계가 없을 수 있습니다.

1. 클라이언트 의존성을 확인하세요. 해당 버전의 설치 안내와 시스템 요구 사항을 확인하세요. WebView2에 의존한다고 명시된 Windows 클라이언트라면 ‘설정’ → ‘앱’ → ‘설치된 앱’에서 Microsoft Edge WebView2 Runtime을 검색하세요. 시스템 버전에 따라 목록 위치가 다를 수 있습니다.
2. 공식 절차에 따라 복구하세요. Microsoft가 공식 배포하는 WebView2 Runtime 설치 프로그램으로 복구하거나 다시 설치한 뒤 클라이언트를 재시작하세요. 출처를 알 수 없는 사이트에서 DLL을 따로 내려받아 프로그램 폴더에 넣지 마세요.
3. 오류 모듈을 확인하세요. Electron 또는 Flutter 클라이언트는 해당 로그를 바탕으로 런타임, 그래픽 드라이버, 앱 리소스를 점검해야 합니다. 클라이언트 문서에서 명확히 지원하는 경우에만 하드웨어 가속 비활성화를 시도하고, 다른 클라이언트의 실행 인자를 그대로 적용하지 마세요.

Linux의 WebKitGTK, 그래픽 세션, 동적 라이브러리 의존성은 설치 패키지 유형에 따라 달라집니다. 먼저 터미널에서 누락된 라이브러리 이름을 확인한 뒤 배포판의 패키지 관리자로 처리하세요. 다른 배포판의 라이브러리 파일을 섞어 설치하지 마세요. macOS에서는 클라이언트를 다시 설치하기 전에 현재 설치 패키지의 시스템 요구 사항을 충족하는지 확인하세요.

데이터 폴더 분리: 복구할 수 있도록 기존 상태를 보존하세요

설정 검증, 포트 점검, 실행 환경 복구로 해결되지 않을 때 새 사용자 데이터로 테스트하세요. 앱을 삭제하고 다시 설치해도 사용자 폴더가 지워지지 않을 수 있으므로 ‘재설치해도 계속 종료된다’는 이유만으로 설치 패키지 문제라고 단정할 수 없습니다.

1. 관련 프로세스를 모두 종료하세요. 백그라운드 서비스가 계속 파일을 쓰고 있다면 백업 중 파일이 바뀌지 않도록 클라이언트가 지원하는 방법으로 먼저 중지하세요.
2. 실제 데이터 폴더를 확인하세요. 로그, 문서 또는 클라이언트의 폴더 열기 기능을 이용해 데이터 위치를 찾으세요. 설치 폴더, 시스템 캐시, 사용자 설정을 혼동하지 마세요.
3. 복사한 뒤 이름을 바꾸세요. 먼저 폴더 전체를 백업하고 원래 폴더 이름을 client-data-backup-20260929처럼 날짜가 포함된 이름으로 변경하세요. 바로 영구 삭제하거나 폴더 전체를 공개 업로드하지 마세요.
4. 초기 상태로 실행하세요. 구독을 가져오지 않고 TUN도 켜지 않은 상태에서 UI와 커널이 모두 정상인지 확인한 뒤 구독, 사용자 지정 규칙, 오버라이드, 환경 설정을 하나씩 복원하세요.

초기 상태에서는 정상인데 특정 항목을 복원한 뒤 다시 실패한다면 해당 항목만 포함한 최소 재현용 복사본을 보존하세요. 손상된 상태 파일까지 되살아날 수 있으므로 폴더 전체를 덮어쓰지 마세요. 초기 상태에서도 실패하지만 같은 커널을 단독으로 실행하면 정상이라면 프록시 규칙을 계속 수정하기보다 UI 계층의 충돌 정보를 우선 제출하세요.

복구 확인 및 문제 제보 기록

창이 열린다고 복구가 끝난 것은 아닙니다. 복구 후 커널이 계속 실행되는지, 포트가 올바르게 열리는지, 구독을 불러올 수 있는지, 필요한 기능을 켜도 종료되지 않는지 확인하세요. 시스템 프록시와 TUN은 각각 따로 테스트하고 기존 시스템 프록시 설정이 의도한 상태로 복구됐는지도 점검하세요.

• 실행 확인: 정상적으로 두 번 연속 시작하고 종료해 보세요. 종료 후 같은 포트를 점유하는 프로세스가 남아 있지 않은지 확인하세요.
• 설정 확인: 구독을 수동으로 한 번 업데이트하고 최종 설정 검사와 규칙 세트 로딩 결과를 확인하세요. 실패하더라도 유일하게 사용할 수 있는 설정 복사본을 자동으로 덮어쓰지 말고 기존 설정을 보존하세요.
• 모드 확인: 먼저 로컬 프록시를 확인한 다음 시스템 프록시를 테스트하고, 마지막으로 필요할 때 TUN을 켜서 로그를 항목별로 확인하세요.
• 제보 자료: 운영체제 버전, 아키텍처, 클라이언트와 커널 버전, 재현 단계, 첫 오류, 민감 정보를 가린 로그를 제공하세요. 최소 설정과 새 데이터 폴더에서 실행되는지도 함께 적어 주세요.

문제를 제보할 때 ‘업데이트 후 실행 2초 만에 종료됨, 최소 설정에서는 정상, 특정 오버라이드를 복원하면 재현됨’처럼 구체적으로 적으면 오류 창 사진만 첨부하는 것보다 원인을 찾기 쉽습니다. 점검이 끝나면 임시로 높인 로그 수준을 평소 설정으로 되돌리고, 정상 설정 백업은 안전하게 보관하며 민감 정보가 포함된 임시 진단 파일은 삭제하세요.