Clash 클라이언트(Clash Verge Rev, Clash Plus, Clash for Windows 등의 프런트엔드와 그 하위의 mihomo 코어를 포함)가 실행 단계에서 강제 종료되거나 "열자마자 사라지는" 현상은 대부분 소프트웨어 자체의 결함이 아니라 설정, 포트, 권한, 파일 무결성 중 한 부분에서 문제가 생긴 것입니다. 이 글은 실제 문제 해결 과정에서 마주치는 원인을 빈도가 높은 것부터 순서대로 정리하고, 시스템을 재설치하거나 클라이언트를 반복적으로 삭제·재설치하지 않고도 원인을 찾아 해결할 수 있는 구체적인 점검 방법을 제시합니다.
왜 실행 크래시는 원인을 한눈에 파악하기 어려운가
실행 시 크래시는 실행 중 발생하는 크래시와 다릅니다. 전자는 그래픽 인터페이스(GUI)가 렌더링을 마치기도 전에 프로세스가 종료되는 경우가 많아 사용자가 확인할 수 있는 정보가 극히 적습니다. 창이 순간적으로 나타났다가 사라지거나, 작업 표시줄 아이콘이 뜬 직후 사라지는 정도가 전부일 수 있습니다. 이런 문제의 핵심은, 클라이언트 자체는 대부분 하나의 GUI 계층에 불과하고, 실제로 프록시 규칙을 처리하고 연결을 수립하는 것은 코어 프로세스(mihomo 또는 구버전 Clash 코어)라는 점입니다. 크래시는 GUI 프로세스에서 발생할 수도 있고, GUI가 코어 프로세스를 실행시킨 직후 코어가 곧바로 종료되는 경우일 수도 있습니다. 두 경우의 점검 방향은 완전히 다르므로, 첫 단계는 언제나 "로그 확인"이어야 하며 추측으로 접근해서는 안 됩니다.
1단계: 로그부터 확인하고, 곧바로 재설치하지 않기
거의 모든 플랫폼의 Clash 클라이언트는 로컬에 실행 로그를 남깁니다. 재설치는 이런 단서들을 지워버려 문제 해결을 오히려 더 어렵게 만듭니다. 아래 표의 위치에서 먼저 로그 파일을 찾은 다음 다음 단계를 결정하는 것을 권장합니다.
| 플랫폼 | 로그/설정 디렉터리 | 설명 |
|---|---|---|
| Windows | %APPDATA%\io.github.clash-verge-rev.clash-verge-rev\logs | 날짜별로 파일이 나뉘며, 코어 실행 파라미터와 오류 출력이 기록됨 |
| macOS | ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/logs | "폴더로 이동" 기능으로 바로 이동 가능 |
| Linux(deb 설치) | ~/.config/clash-verge-rev/logs | journalctl로 서비스 로그를 확인할 수도 있음 |
| mihomo 명령줄 실행 | 터미널 표준 출력 / -d 디렉터리 아래 core.log | 명령줄로 포그라운드에서 실행하면 오류가 터미널에 바로 출력됨 |
가장 최근 로그 파일을 열어 panic, FATAL, error, bind: address already in use 같은 키워드를 중점적으로 찾아보세요. 이런 키워드는 대개 문제의 유형을 곧바로 알려줍니다.
흔한 원인 1: 설정 파일 문법 오류
실행 크래시 중 비중이 가장 높은 유형으로, 특히 설정 파일을 직접 편집하거나 구독 제공업체가 규격에 맞지 않는 형식으로 설정을 제공할 때 자주 발생합니다. Clash의 설정 파일은 YAML 형식이며 들여쓰기와 콜론 뒤 공백에 매우 민감합니다. 흔한 오류는 다음과 같습니다.
- 공백 대신 Tab으로 들여쓰기(YAML 규격상 Tab은 허용되지 않음)
- 규칙이나 프록시 그룹의 목록 항목이 들여쓰기 수준이 통일되지 않음
- 콜론을 포함한 문자열에 인용부호를 붙이지 않아 키-값 쌍으로 잘못 해석됨
- rule-providers가 설정 파일에 정의되지 않은 프록시 그룹 이름을 참조함
확인 방법은 간단합니다. 코어가 설정 파싱에 실패하면 로그에 구체적인 줄 번호와 필드 이름이 표시됩니다. 예를 들어 yaml: line 42: mapping values are not allowed in this context 같은 형태입니다. 줄 번호를 확인한 뒤 들여쓰기를 한 줄씩 대조하면 됩니다. 클라이언트가 로그조차 생성하지 못했다면, 설정 파일 자체를 읽지 못하는 상황(예: 파일 인코딩이 UTF-8이 아닌 경우)일 가능성이 높으므로, 텍스트 편집기에서 UTF-8(BOM 없음)으로 다시 저장한 뒤 재시도해 보세요.
권장
설정을 편집하기 전에는 한 줄만 수정하더라도 반드시 백업을 먼저 만들어 두세요. 그러면 문제가 생겼을 때 구독을 다시 받을 필요 없이 즉시 롤백할 수 있습니다.
흔한 원인 2: 포트 점유
Clash는 기본적으로 HTTP 프록시 포트(일반적으로 7890), SOCKS5 포트, 컨트롤 패널 포트(일반적으로 9090)를 사용합니다. 이 포트들이 다른 프로그램에 의해 이미 점유되어 있다면 — 이전에 완전히 종료되지 않은 Clash 프로세스 자신도 포함 — 코어는 포트 바인딩 시 곧바로 오류를 내고 종료되며, GUI는 "열자마자 사라지는" 것으로 보이게 됩니다.
점검 절차는 다음과 같습니다.
- 로그에서 bind: address already in use 또는 listen tcp :7890 관련 오류를 찾습니다.
- Windows에서는 netstat -ano | findstr 7890으로 해당 포트를 점유한 프로세스의 PID를 확인한 뒤 작업 관리자에서 해당 프로세스를 종료합니다.
- macOS/Linux에서는 lsof -i :7890으로 점유 상태를 확인합니다.
- 점유 중인 프로세스가 이전에 완전히 종료되지 않은 Clash 코어라면, 작업 관리자/활동 모니터에서 남아 있는 mihomo 또는 clash 프로세스를 수동으로 종료한 뒤 클라이언트를 다시 실행합니다.
- 포트 충돌을 확인했다면 설정 파일에서 mixed-port, socks-port, external-controller를 점유되지 않은 포트 번호로 변경하고 저장한 뒤 클라이언트를 재시작해 확인합니다.
netstat -ano | findstr 7890
lsof -i :9090흔한 원인 3: 코어 파일 손상 또는 버전 불일치
Clash Verge Rev, Clash Plus 등의 클라이언트는 GUI와 코어(mihomo)를 분리해 패키징하며, 코어는 독립된 실행 파일로 클라이언트와 함께 설치됩니다. 다운로드 중 파일이 잘리거나, 시스템 보안 소프트웨어가 코어 실행 파일을 오탐하여 삭제하거나, 호환되지 않는 코어 버전을 수동으로 교체했다면, GUI가 실행된 뒤 코어 프로세스를 찾지 못하거나 실행할 수 없어 곧바로 종료됩니다.
다음과 같은 방법으로 확인할 수 있습니다.
- 클라이언트 설치 디렉터리에 코어 실행 파일(일반적으로 verge-mihomo 또는 clash-meta라는 이름)이 있는지 확인합니다. 파일 크기가 눈에 띄게 작다면(수십 KB) 다운로드가 불완전했다는 뜻입니다.
- 시스템 보안 소프트웨어(특히 국내 백신 프로그램류)의 격리소/신뢰 목록 기록을 확인합니다. 코어 파일이 위험 프로그램으로 오탐되어 격리되는 경우가 흔합니다.
- 코어 아키텍처가 시스템과 일치하는지 확인합니다. 예를 들어 Apple 실리콘 Mac은 arm64 코어가 필요하며 Intel용 코어 파일을 그대로 사용할 수 없습니다.
해결 방법은 전체 설치 파일을 다시 받아 덮어쓰기 설치하거나, 다운로드 센터에서 해당 플랫폼의 코어 파일만 별도로 받아 설치 디렉터리에 교체하는 것입니다. 동시에 클라이언트 설치 디렉터리를 보안 소프트웨어의 신뢰 목록에 추가해 다음에 또 오삭제되는 것을 방지하세요.
흔한 원인 4: 시스템 권한 부족
이 유형의 문제는 TUN 모드(가상 네트워크 카드로 전체 트래픽을 처리하는 방식)를 활성화했을 때 가장 흔하게 발생합니다. TUN 모드는 가상 네트워크 인터페이스를 생성해야 하며, 이 작업은 모든 플랫폼에서 권한 상승이 필요합니다.
- Windows에서는 클라이언트를 관리자 권한으로 실행해야 합니다. 그렇지 않으면 TUN 장치 생성 시 곧바로 오류가 발생하며 종료됩니다.
- macOS에서는 시스템 설정의 "개인정보 보호 및 보안"에서 클라이언트가 네트워크 확장을 로드하도록 허용해야 합니다. 처음 활성화할 때 시스템 수준의 권한 요청 창이 나타나며, 실수로 거부했다면 시스템 설정에서 다시 수동으로 승인해야 합니다.
- Linux에서 일반 사용자 권한으로 mihomo를 실행하며 TUN을 켜려면 CAP_NET_ADMIN 권한이 필요합니다. 일반적으로 sudo로 실행하거나 코어 실행 파일에 capability를 설정하는 방식을 사용합니다.
TUN 모드를 켠 직후부터 크래시가 시작되었다면 권한 문제일 가능성이 매우 높습니다. 먼저 TUN 모드를 끄고 클라이언트가 정상적으로 실행되는지 확인한 다음, 위 방법에 따라 권한을 상승시키세요.
단계별 점검 순서 권장
크래시가 발생했을 때는 여러 변수를 동시에 바꾸지 말고 아래 순서대로 점검해야 어느 단계에서 문제가 생겼는지 정확히 확인할 수 있습니다.
먼저 로그를 확인해 설정 파싱 오류인지, 포트 바인딩 실패인지, 코어 프로세스가 곧바로 크래시하는 것인지 구분합니다.
설정 파일을 이미 검증된 최소 설정(기본 포트와 직접 연결 규칙 하나만 포함)으로 임시 교체해, 클라이언트 자체가 정상적으로 실행되는지 확인합니다.
정상 실행된다면 문제는 원래 설정 파일에 있는 것이므로 앞서 설명한 방법으로 문법이나 포트 충돌을 단계별로 점검합니다. 실행되지 않는다면 문제는 클라이언트 설치나 시스템 권한 쪽에 있습니다.
TUN 모드, 시스템 프록시 강제 적용 등 확장 기능을 하나씩 꺼가며 문제를 안정적으로 재현할 수 있는 최소 조건으로 범위를 좁힙니다.
코어 파일 문제로 확인되면 공식 설치 파일을 다시 받아 덮어쓰기 설치하고, 출처가 불명확한 코어 교체 파일은 사용하지 않습니다.
안전한 설정 롤백 방법
문제가 있는 설정 파일에서 계속 시행착오를 겪기보다, 이전 버전을 남겨두고 언제든 롤백할 수 있도록 준비하는 것이 더 안전합니다.
- 대부분의 클라이언트는 "구독 관리" 또는 "설정 파일" 페이지에서 업데이트 전 버전을 자동으로 백업해 두므로, 화면에서 바로 "이전 버전으로 복원"을 선택할 수 있습니다.
- 설정을 직접 편집하기 전에는 날짜를 붙인 사본을 먼저 만들어 두세요(예: config-2026-05-15.yaml). 새 버전이 정상 작동함을 확인한 뒤 이전 백업을 삭제합니다.
- 설정이 구독 링크에서 가져온 것이라면, 구독을 갱신하기 전에 수동으로 내보낸 로컬 사본을 하나 남겨두세요. 구독 서버가 비정상적인 내용을 반환해 덮어써진 뒤 복구할 수 없는 상황을 방지할 수 있습니다.
- 롤백 후 클라이언트를 재시작해 로그를 관찰하고, 크래시 현상이 사라졌는지 확인한 다음 변경 사항을 하나씩 다시 적용하며 어떤 변경이 문제를 일으켰는지 정확히 찾아냅니다.
주의
근본 원인을 확인하기 전에는 문제가 있는 설정 파일을 삭제하지 마세요. 먼저 보관해 두면 이후 대조 점검이 쉬워지고, 구독 제공업체에 문제를 알릴 때 샘플로 제공하기에도 편리합니다.
여전히 해결되지 않을 때 할 수 있는 것들
위 순서대로 점검했는데도 클라이언트가 여전히 실행되지 않는다면 다음과 같은 최후 수단을 고려할 수 있습니다.
- 설정 디렉터리를 완전히 비운 뒤 클라이언트를 완전히 삭제하고 재설치해, 설치 과정에서 남은 손상된 파일의 가능성을 배제합니다.
- 다른 클라이언트로 교체(예: GUI 클라이언트에서 순수 명령줄 mihomo 코어 실행으로 전환)해, 문제가 특정 GUI 프런트엔드에만 국한된 것인지 확인합니다.
- 권한이 낮은 계정이나 새로 만든 시스템 사용자로 테스트해, 시스템 수준 환경 변수나 로컬 정책으로 인한 간섭을 배제합니다.
- 전체 로그 파일을 보관해 두면, 커뮤니티나 피드백 채널에 문제를 설명할 때 정확한 정보를 제공할 수 있습니다.
실행 크래시는 당황스러워 보이지만, "먼저 로그 확인 → 범위 좁히기 → 마지막으로 롤백 검증"이라는 순서를 따르면 대부분 십여 분 안에 구체적인 원인 단계를 찾아낼 수 있습니다. 설정 백업을 남기고, 남아있는 프로세스와 포트 점유 상태를 정기적으로 확인하는 습관을 들이면 이런 문제가 발생하는 빈도를 근본적으로 줄일 수 있습니다.