UI 종료, 커널 종료, 창 숨김부터 구분하기
Clash 클라이언트는 보통 그래픽 인터페이스, 프록시 커널, 선택적 백그라운드 서비스로 구성됩니다. 창이 사라져도 커널이 충돌한 것은 아닐 수 있으며, 모든 노드가 시간 초과된다고 해서 클라이언트가 종료된 것도 아닙니다. 먼저 어느 구성 요소가 종료됐는지 확인한 뒤 설정을 점검하면, 같은 원인을 남긴 채 반복해서 재설치하는 일을 피할 수 있습니다.
| 확인된 증상 | 우선 점검할 항목 | 판단 기준 |
|---|---|---|
| 창은 사라졌지만 트레이 아이콘은 남아 있음 | 창을 닫을 때 트레이로 최소화하는 설정 | 트레이 메뉴에서 창을 다시 표시해 숨겨진 것인지 확인 |
| UI는 정상 작동하지만 커널이 연결되지 않았다고 표시됨 | 설정 파싱, 커널 프로세스, 컨트롤 포트 | UI 데이터를 먼저 지우지 말고 커널 로그 확인 |
| 창과 프로세스가 함께 종료됨 | 시스템 충돌 기록, 실행 환경, 앱 데이터 | 종료 시각과 오류 모듈 기록 |
| TUN을 켠 뒤에만 종료됨 | 서비스 권한, 가상 네트워크 어댑터, 다른 VPN | TUN을 끈 상태에서는 안정적으로 실행되는지 확인 |
Windows에서는 Ctrl + Shift + Esc를 눌러 작업 관리자를 연 다음, ‘세부 정보’에서 클라이언트와 커널 프로세스를 확인합니다. macOS에서는 ‘활성 상태 보기’를 열고 클라이언트 이름과 mihomo를 검색합니다. Android에서는 ‘설정’ → ‘앱’ → 해당 클라이언트로 이동해 앱이 종료된 것인지 VPN 연결만 끊긴 것인지 구분합니다. 메뉴 이름은 기기 제조사와 OS 버전에 따라 다를 수 있습니다.
설정을 백업한 뒤 최초 오류 확인
구독 설정과 로컬 변경 사항 보존
먼저 클라이언트와 백그라운드 서비스를 완전히 종료한 다음 설정 폴더를 백업하세요. 구독 URL, 로컬 YAML 파일, 오버라이드 조각, 규칙 세트, 정책 그룹 선택 기록을 보존하는 것이 중요합니다. 설정 폴더 경로는 클라이언트마다 다르므로 특정 제품의 경로를 모든 Clash 클라이언트에 적용하면 안 됩니다. UI에 접속할 수 있다면 클라이언트의 ‘설정 폴더 열기’ 또는 ‘로그 폴더 열기’ 기능을 이용하세요.
UI를 열 수 없다면 설치 안내와 시스템의 앱 데이터 폴더를 확인하세요. Windows에서는 보통 %APPDATA% 또는 %LOCALAPPDATA% 아래의 앱별 폴더에 있습니다. macOS에서는 대개 ~/Library/Application Support/ 아래에 저장됩니다. 이 상위 폴더를 통째로 삭제하지 마세요. Android 앱의 비공개 데이터는 일반 파일 관리자로 열 수 없는 경우가 많으므로, 저장 공간을 비우기 전에 구독 설정과 로컬 설정을 외부에 백업했는지 확인하세요.
로그는 마지막 줄만 보지 말고 시간대별로 확인
- Windows: Win + R을 누르고
eventvwr.msc를 입력한 뒤 ‘Windows 로그’ → ‘응용 프로그램’으로 이동합니다. 종료 시각 전후의 Application Error, .NET Runtime 또는 Windows Error Reporting 기록을 찾아 오류가 발생한 앱, 모듈, 예외 코드를 저장하세요. - macOS: ‘콘솔’을 열어 충돌 보고서를 확인하거나
~/Library/Logs/DiagnosticReports/를 살펴보세요. 예외 유형, 종료 사유, 충돌 스레드 정보를 보존하세요. - Android: ADB 사용에 익숙하다면 USB 디버깅을 활성화한 뒤 아래 명령으로 실행 과정을 기록할 수 있습니다. 버퍼를 먼저 비우면 이전 로그가 삭제되므로, 기존 기록을 보존할 필요가 없을 때만 실행하세요.
adb logcat -c
adb logcat -v time > clash-startup.txt
# 휴대폰에서 클라이언트를 실행해 종료를 재현한 뒤 Ctrl+C를 눌러 기록을 중지Android 로그에서는 FATAL EXCEPTION, AndroidRuntime, Fatal signal과 앱 패키지 이름을 중점적으로 검색하세요. 데스크톱에서는 permission denied, address already in use, panic, 설정 파싱 오류를 확인합니다. 마지막에 표시된 ‘연결 실패’는 커널 종료에 따른 후속 메시지일 수 있습니다. 실제 원인은 그보다 앞선 로그에 있는 경우가 많습니다.
최소 설정으로 YAML과 커널 호환성 확인
구독을 업데이트하거나 오버라이드를 수정하거나 커널을 업그레이드한 직후 문제가 생겼다면, 가장 최근 변경부터 롤백하세요. 구독 원본 파일, 클라이언트 오버라이드, 실제 실행 설정은 서로 다른 파일일 수 있습니다. 구독 편집기의 내용만 보지 말고 커널이 실제로 불러온 설정을 확인하세요.
먼저 문법과 설정 불러오기 테스트
아래 명령은 mihomo용이며, 예시에서는 커널과 설정 파일이 같은 테스트 폴더에 있다고 가정합니다. 실제로 존재하는 커널 파일을 사용하세요. 다른 Clash 계열은 -h 도움말을 먼저 확인해야 하며, 모든 계열에서 명령 옵션이 같다고 가정하면 안 됩니다.
# Windows PowerShell
.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml
# macOS / Linux
./mihomo -v
./mihomo -t -f ./config.yaml-t는 설정을 불러올 수 있는지 검사하는 옵션입니다. 노드 연결 여부를 확인하거나 실제 실행을 대신하지는 않습니다. YAML 줄 번호 오류가 표시되면 들여쓰기에 탭이 섞였는지, 콜론 뒤에 공백이 빠졌는지, 정책 그룹에서 참조하는 이름이 실제로 존재하는지 확인하세요. 파서는 오류가 발생한 위치보다 다음 줄에서 멈출 수도 있으므로 오류 줄의 앞뒤도 함께 살펴보세요.
구독, 규칙 세트, TUN을 분리해 확인
백업한 뒤 별도의 테스트 폴더에 아래 최소 설정을 만드세요. 커널이 실행되는지 확인하기 위한 설정으로, 모든 트래픽을 직접 연결하며 프록시 노드는 포함하지 않습니다. 테스트 중에는 원래 클라이언트를 종료해 커널 두 개가 동시에 실행되지 않도록 하세요.
mixed-port: 17890
allow-lan: false
mode: rule
log-level: info
tun:
enable: false
dns:
enable: false
rules:
- MATCH,DIRECT.\mihomo.exe -f .\minimal.yaml 또는 ./mihomo -f ./minimal.yaml로 포그라운드에서 실행해 계속 동작하는지 확인한 다음 Ctrl + C를 눌러 종료하세요. 일반적으로 쓰이는 7890 포트와 구분하려고 17890을 사용했지만, 이 포트가 비어 있다고 보장되는 것은 아닙니다. 테스트 중에는 시스템 프록시나 TUN을 켜지 마세요.
- 최소 설정에서도 종료됨: 커널 아키텍처, 파일 권한, 실행 디렉터리, 시스템 충돌 기록부터 확인하세요.
- 최소 설정은 정상 작동함: 노드, 정책 그룹, 규칙 세트, DNS를 하나씩 복원하고 마지막에 TUN을 켜세요.
- 특정 조각을 복원한 뒤에만 문제가 발생함: 해당 조각과 정확한 오류 정보를 보존하고 필요한 커널 기능과 설정 형식을 확인하세요.
Clash, Clash Meta, mihomo는 설정 지원 범위가 완전히 같지 않습니다. 특정 필드를 무시하거나 설정 불러오기를 거부하면 동작이 달라질 수 있습니다. YAML 문법이 올바르다는 이유만으로 현재 커널과 호환된다고 볼 수는 없습니다. proxy-providers와 rule-providers는 파일 경로, 원격 응답 내용, 읽기·쓰기 권한도 확인하세요.
프록시 포트, 컨트롤 포트, 남은 프로세스 확인
address already in use는 해당 리스닝 주소가 이미 사용 중이라는 뜻입니다. 프록시 리스닝 포트와 컨트롤 인터페이스 포트의 용도는 다릅니다. 예를 들어 mixed-port: 7890은 HTTP/SOCKS 프록시용이고, external-controller: 127.0.0.1:9090은 관리 인터페이스용입니다. 이는 흔히 쓰이는 설정값일 뿐이므로 실제 실행 설정을 기준으로 확인하세요.
Windows에서 포트 사용 프로세스 확인
netstat -ano | findstr ":7890"
netstat -ano | findstr ":9090"
# 예시: PID 1234에 해당하는 프로세스 이름 확인
tasklist /FI "PID eq 1234"로컬 주소와 LISTENING 상태를 확인한 뒤 PID로 프로세스를 찾으세요. 원격 주소에 같은 포트가 표시된 것을 로컬 포트 점유로 오해하지 않도록 주의해야 합니다. 이전 실행에서 남은 커널이라면 클라이언트나 관련 서비스에서 정상적으로 종료하세요. 다른 프로그램이 사용 중이라면 어느 서비스의 리스닝을 유지할지 판단하고, 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요.
macOS에서 리스닝 포트 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN프록시 포트를 7890에서 17890으로 바꿨다면 브라우저 확장 프로그램, 명령줄 환경 변수, 시스템 프록시도 함께 변경해야 합니다. 클라이언트 관리 인터페이스 포트를 바꾸기 전에는 UI가 해당 변경을 자동으로 반영하는지 확인하세요. 컨트롤 포트가 일치하지 않으면 커널이 실행 중이어도 ‘커널이 연결되지 않음’으로 표시될 수 있습니다.
Windows, macOS, Android별 실행 환경 점검
Windows: 오류 모듈을 확인한 뒤 런타임 라이브러리 점검
로그가 UI 런타임 문제를 가리킨다면 해당 클라이언트의 릴리스 안내에 따라 필요한 의존성을 설치하세요. 예를 들어 WebView2를 사용하는 클라이언트에는 정상 작동하는 WebView2 Runtime이 필요할 수 있지만, 모든 Clash 클라이언트가 이를 사용하는 것은 아닙니다. DLL 누락이 확인됐거나 릴리스 안내에 명시된 경우에만 해당 Visual C++ 런타임을 설치하세요. 출처가 불분명한 사이트에서 DLL을 따로 내려받아 시스템 폴더에 넣지 마세요.
Windows 보안의 ‘바이러스 및 위협 방지’ → ‘보호 기록’을 확인해 커널이 격리됐는지 살펴보세요. 먼저 설치 파일의 출처와 경고 내용을 확인하고, 보안 기능을 계속 꺼 두는 방식으로 해결하지 마세요. UI 초기화나 설정 파싱에는 보통 관리자 권한이 필요하지 않습니다. 서비스 설치나 TUN 활성화처럼 권한이 필요한 단계에서만 관리자 권한으로 실행하세요.
macOS: Intel, Apple Silicon, 권한 안내 구분
‘이 Mac에 관하여’에서 프로세서를 확인하세요. Apple 칩이면 arm64 패키지를, Intel 프로세서면 x64 패키지를 선택하는 것이 좋습니다. macOS의 ‘열 수 없음’ 보안 경고와 실행 후 충돌은 서로 다른 문제입니다. 신뢰할 수 있는 앱이라면 ‘시스템 설정’ → ‘개인정보 보호 및 보안’에 표시된 안내에 따라 처리하세요. 모든 앱의 보안 속성을 일괄 제거하지 마세요.
보고서에 dyld, 동적 라이브러리 누락, 아키텍처 불일치가 표시되면 다른 기기에서 커널을 복사하기보다 해당 macOS와 호환되는 전체 앱 패키지를 다시 설치하세요. TUN 관련 문제가 발생하면 먼저 다른 VPN을 끈 다음 클라이언트 문서에 따라 보조 서비스 권한을 확인하세요.
Android: 실행 직후 종료와 백그라운드 연결 끊김 구분
adb shell getprop ro.product.cpu.abilist 명령으로 기기에서 지원하는 ABI를 확인할 수 있습니다. arm64, armv7, 범용 설치 패키지는 기기 사양과 클라이언트 지원 여부에 맞춰 선택하세요. APK의 ABI, 앱의 최소 Android 버전, 기기의 실제 OS 버전이 모두 호환되어야 합니다.
먼저 ‘설정’ → ‘앱’ → 클라이언트 → ‘저장공간 및 캐시’에서 캐시를 삭제해 보세요. 저장공간을 지우면 로컬 설정이 삭제되므로 반드시 백업한 뒤 진행해야 합니다. 화면을 잠근 뒤 몇 분 후 VPN 연결이 끊긴다면 배터리 최적화와 백그라운드 실행 권한을 확인하세요. 아이콘을 누르자마자 충돌 안내가 뜨는 문제와는 원인이 다릅니다. Android에서는 일반적으로 같은 사용자 계정에서 활성 VPN 서비스를 하나만 사용할 수 있으므로 테스트 전에 다른 VPN 앱의 연결을 끊으세요.
커널 재설치와 버전 롤백 순서
최소 설정에서도 실행되지 않거나 커널 파일이 없거나, 업그레이드 후 같은 종료 문제가 반복 재현될 때만 재설치나 버전 롤백을 진행하세요. 커널을 임의로 바꾸면 클라이언트와 컨트롤 인터페이스의 호환성이 깨질 수 있습니다. 임의의 mihomo 실행 파일 이름을 바꿔 설치 폴더에 넣어서는 안 됩니다.
- 현재 상태 보존: 로그와 설정을 백업하고 현재 클라이언트 및 커널 버전을 기록하세요. 유일하게 정상 작동하는 설치 파일은 덮어쓰지 마세요.
- 관련 프로세스 종료: 트레이 프로그램을 종료하고 클라이언트 문서에 따라 보조 서비스를 중지한 뒤 리스닝 포트가 해제됐는지 확인하세요.
- 관련 구성 요소 복구: 클라이언트에 내장된 커널 복구 기능을 우선 사용하세요. UI를 실행할 수 없다면 같은 버전의 전체 설치 패키지를 다시 설치하세요.
- 기존 데이터 분리: 백업한 뒤 앱 자체 데이터 폴더의 이름을 바꿔 보존하면 클라이언트가 새 폴더를 생성합니다. 시스템 앱 데이터 상위 폴더 전체를 삭제하지 마세요.
- 초기 상태에서 먼저 확인: 이전 오버라이드를 가져오지 말고 자동 시작과 TUN을 끈 상태에서 UI와 커널이 모두 계속 실행되는지 확인하세요.
- 항목별로 복원: 먼저 정상 작동이 확인된 설정 파일 하나를 불러온 다음 DNS, 규칙 세트, TUN을 복원하세요. 한 번에 하나씩만 변경하고 결과를 기록하세요.
새 데이터 폴더에서도 새 버전의 문제가 계속 재현되고 같은 기기에서 이전 버전은 정상 작동한다면, 버전 회귀를 의심할 근거가 충분합니다. 롤백할 때는 신뢰할 수 있는 출처의 설치 파일 중 시스템 아키텍처에 맞는 버전을 사용하세요. 새 버전의 데이터 형식을 이전 버전에서 읽을 수 있는지도 확인해야 하며, 필요하면 버전별로 데이터 폴더를 분리해 테스트하세요.
복구 후 확인 및 문제 신고 체크리스트
복구 여부는 창이 열린다는 것만으로 판단하지 마세요. UI가 계속 열려 있는지, 커널 초기화가 완료됐는지, 프록시 포트가 리스닝을 시작했는지, 설정을 불러왔는지, 규칙 모드가 작동하는지 순서대로 확인한 뒤 마지막에 TUN을 켜세요. 다음 단계로 넘어가기 전에 로그에 반복적인 시작이나 종료가 없는지 살펴보세요.
- 정상적으로 종료한 뒤 한 번 더 실행해 올바른 설정이 계속 불러와지는지 확인하세요.
- 시스템을 재부팅한 뒤 서비스 권한과 프록시 설정을 확인해 수동으로 실행할 때만 정상 작동하는 문제를 점검하세요.
- 클라이언트 버전, 커널 버전, OS 버전과 아키텍처를 제공하고 최근 업그레이드나 설정 변경 내용을 구체적으로 적으세요.
- 개인정보를 가린 로그, 충돌 시각, 재현에 필요한 최소 단계를 첨부하고 최소 설정에서도 종료되는지 알려 주세요.
문제 해결 순서를 지키세요. 먼저 종료된 구성 요소를 확인하고 로그를 살펴본 뒤, 설정을 롤백하고 포트를 확인하세요. 실행 환경을 검증한 다음 마지막으로 관련 구성 요소를 재설치하면 기존 규칙을 보존하면서 ‘Clash 실행 직후 종료’ 문제를 재현하고 원인을 찾기 쉬운 상태로 좁힐 수 있습니다.