Clash 실행 직후 강제 종료될 때: 시작 오류 원인 6가지와 해결 방법

창이 닫힌 것인지 커널이 종료된 것인지 먼저 확인

Clash를 실행하자마자 종료되더라도 서둘러 재설치할 필요는 없습니다. 데스크톱 클라이언트는 보통 그래픽 인터페이스, 프록시 커널, 백그라운드 서비스로 구성됩니다. 창이 사라진 것은 트레이로 최소화된 결과일 수 있고, 창은 열리지만 연결되지 않는다면 커널이 시작되지 않았을 수 있습니다. 두 경우에 확인해야 할 로그는 서로 다릅니다.

먼저 Windows 알림 영역이나 macOS 메뉴 막대에 아이콘이 남아 있는지 확인하세요. 아이콘을 눌러 기본 창이 정상적으로 열리면 시작 오류가 아닙니다.
Windows에서는 ‘작업 관리자’ → ‘세부 정보’에서 클라이언트와 커널 프로세스를 확인하세요. macOS에서는 ‘활성 상태 보기’에서 앱 이름을 검색하면 됩니다. 창이 보이는지만으로 프로세스 상태를 판단하지 마세요.
실행을 누른 정확한 시각을 기록하고, 해당 시각 전후 1분의 앱 로그와 시스템 충돌 기록을 보관하세요. 마지막에 표시되는 ‘프로세스 종료’는 원인이 아니라 결과인 경우가 많으므로 첫 번째 오류부터 확인합니다.

아래에서 원인 6가지를 차례로 확인합니다. 표의 오류 문구는 문제를 찾기 위한 단서이며, 모든 클라이언트에 똑같이 표시되는 것은 아닙니다.

확인 단서	우선 점검 항목
`yaml: line …`	설정 문법 및 클라이언트 오버라이드 내용
`address already in use`	프록시 포트, 컨트롤 포트 또는 DNS 수신 포트 충돌
`no such file` / `exec format error`	커널 경로 및 CPU 아키텍처
`permission denied`	데이터 폴더, 실행 권한 및 TUN 서비스
DLL 또는 동적 라이브러리 누락	해당 클라이언트에 필요한 시스템 구성 요소
업데이트 후 인터페이스 복구 실패	창 상태, 프런트엔드 캐시 또는 설정 데이터베이스

1. 설정 파일 문법 오류

구독을 갱신하거나 오버라이드 파일을 편집하거나 설정을 바꾼 뒤 문제가 생겼다면 설정부터 확인하세요. YAML은 들여쓰기에 공백을 사용해야 하며 같은 수준의 항목은 맞춰 정렬해야 합니다. 콜론 뒤에 공백이 없거나 목록에 하이픈이 빠져도 파싱에 실패할 수 있습니다. mihomo용 설정을 오래된 Clash 커널에 적용한 경우도 흔한 원인입니다. YAML 문법이 올바르더라도 지원 필드와 규칙이 호환되지 않을 수 있습니다.

실제로 불러온 파일 찾기

클라이언트가 구독, 오버라이드, 인터페이스 설정을 합쳐 실행 설정을 만들 수도 있습니다. 따라서 구독 원본 파일이 정상적으로 파싱되더라도 최종 설정으로 실행되지 않을 수 있습니다. 로그에서 설정 파일 경로를 확인하세요. 인터페이스를 열 수 있다면 설정이나 프로필 관리 메뉴에서 데이터 폴더, 실행 설정 또는 로그 위치를 찾아보세요. 클라이언트마다 메뉴 이름은 다릅니다. 설치 폴더에서 우연히 찾은 config.yaml 파일을 바로 덮어쓰지 마세요.

Windows에서 mihomo를 사용하는 경우를 예로 들겠습니다. 실제 커널 파일이 있는 폴더에서 PowerShell을 여세요. 설정 파일이 C:\ClashData\config.yaml에 있고 데이터 파일도 같은 폴더에 있다고 가정하면 다음 명령을 실행할 수 있습니다.

.\mihomo.exe -t -d "C:\ClashData" -f "C:\ClashData\config.yaml"

-t는 설정을 검사한 뒤 종료하고, -f는 설정 파일을 지정하며, -d는 작업 폴더를 지정합니다. 경로는 실제 위치에 맞게 바꾸고 클라이언트에 포함된 커널을 사용하세요. 이 명령을 모든 GUI 클라이언트의 실행 옵션으로 사용해서는 안 됩니다. 지리 데이터베이스나 규칙 제공자 파일이 없어도 검사에 실패할 수 있으므로 오류 내용에 따라 추가로 확인해야 합니다.

로그에서 20번째 줄을 가리킨다면 19번째 줄도 확인하세요. 앞줄에서 따옴표를 닫지 않은 탓에 다음 줄에서 오류가 표시될 수도 있습니다.
‘정책을 찾을 수 없음’ 오류가 나오면 규칙의 대상과 정책 그룹 이름을 공백과 대소문자까지 그대로 대조하세요.
지원하지 않는 규칙 유형이라는 오류가 나오면 클라이언트 이름만 보지 말고 실제로 실행 중인 커널을 확인하세요.

복구하려면 최근에 추가한 오버라이드를 먼저 비활성화하거나 마지막으로 정상 작동한 설정으로 되돌리세요. 필드의 용도를 모르겠다면 설정 필드 문서를 참고하세요. DNS나 규칙 설정을 한꺼번에 삭제하지 마세요.

2. 포트 충돌로 인한 커널 종료

프록시 클라이언트를 두 개 실행했거나, 이전 커널이 종료되지 않았거나, 백그라운드 서비스와 수동으로 실행한 커널이 중복 실행되면 포트 충돌이 발생할 수 있습니다. 7890은 혼합 프록시 포트로, 9090은 컨트롤 인터페이스 포트로 자주 사용되지만 모든 클라이언트가 이 포트를 고정으로 쓰는 것은 아닙니다. 로그에 실제로 표시된 주소와 포트를 기준으로 확인하세요.

포트를 점유한 프로세스를 확인하고 모르는 프로세스는 강제 종료하지 마세요

Windows에서는 터미널에서 다음 명령을 실행하세요. 마지막 열에 프로세스 PID가 표시됩니다.

netstat -ano | findstr :7890
netstat -ano | findstr :9090

로컬 주소의 포트 중 상태가 LISTENING인 항목을 확인한 다음 ‘작업 관리자’ → ‘세부 정보’에서 PID로 프로그램을 찾으세요. macOS에서는 다음 명령을 사용할 수 있습니다.

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

Linux에서는 ss -lntp로 TCP 수신 포트를 확인할 수 있습니다. 다른 사용자의 프로세스 정보를 보려면 적절한 권한이 필요할 수 있습니다. 오류가 DNS의 UDP 수신 포트와 관련된 경우에는 TCP만 확인하지 말고 UDP도 점검하세요.

점유 프로세스가 이전 클라이언트임을 확인했다면 해당 클라이언트의 종료 메뉴를 사용해 정상적으로 종료하고 백그라운드 서비스가 계속 실행 중인지 확인하세요.
설정 두 개를 동시에 실행해야 한다면 프록시와 컨트롤 인터페이스에 서로 다른 포트를 지정하세요. 예를 들어 한쪽의 혼합 포트를 7893으로 바꿀 수 있습니다.
포트를 변경한 뒤에는 시스템 프록시와 브라우저의 수동 프록시 설정도 함께 변경하세요. 커널은 새 포트를 수신하는데 앱은 이전 포트로 연결하면 ‘실행되지만 인터넷에 연결되지 않는’ 문제가 발생합니다.

로그에 수신 프로세스가 없는데 소켓 접근이 거부되었다고 표시된다면 Windows의 예약 포트 범위와 보안 정책도 확인하세요. 모든 바인딩 실패를 프로그램의 포트 점유 탓으로 돌려서는 안 됩니다.

3. 커널 파일 누락 또는 아키텍처 불일치

그래픽 인터페이스가 열린 뒤 커널 시작 실패 메시지가 나타난다면 압축 파일이 완전히 풀리지 않았거나, 주 프로그램만 복사했거나, 앱 업데이트 후에도 이전 경로를 참조하거나, 보안 소프트웨어가 커널을 격리했을 가능성이 있습니다. 일부 클라이언트는 커널을 별도로 다운로드하므로 다운로드가 중단되면 인터페이스는 정상인데 커널은 없는 상태가 될 수도 있습니다.

no such file or directory: 로그에 표시된 전체 경로와 파일 존재 여부부터 확인하세요. Linux에서는 필요한 동적 로더가 없는 경우에도 이 오류가 발생할 수 있습니다.
exec format error: 먼저 아키텍처와 파일 형식을 확인하세요. 예를 들어 x86_64 Linux에서 ARM64용 Linux 커널을 실행하려는 경우입니다.
‘지정된 파일을 찾을 수 없습니다’라는 오류가 나와도 누락된 파일이 주 프로그램이 아니라 커널이나 종속 파일일 수 있습니다.

원 프로젝트의 공식 배포 경로에서 운영체제와 아키텍처에 맞는 전체 설치 파일을 다시 받은 다음 클라이언트에서 제공하는 복구 또는 재설치 절차를 따르세요. macOS에서는 ‘Apple 메뉴’ → ‘이 Mac에 관하여’에서 칩 종류를 확인할 수 있습니다. Windows에서는 ‘설정’ → ‘시스템’ → ‘정보’에서 시스템 종류를 확인하세요. Linux에서는 uname -m으로 x86_64와 aarch64를 구분할 수 있습니다.

시스템에 격리 기록이 있다면 파일의 출처와 격리 사유를 먼저 확인한 뒤 시스템 안내에 따라 처리하세요. 보안 기능 전체를 끄거나 출처 불명의 파일 공유 사이트에서 같은 이름의 실행 파일을 받아 교체하지 마세요. 클라이언트와 커널은 서로 호환되는 인터페이스를 사용하므로 임의로 섞으면 시작 오류의 원인을 찾기 더 어려워질 수 있습니다.

4. 권한 부족 및 TUN 서비스 오류

일반적인 시스템 프록시 사용에는 클라이언트를 계속 관리자 권한으로 실행할 필요가 없습니다. 하지만 TUN 장치 생성, 라우팅 변경, 백그라운드 서비스 설치에는 추가 권한이 필요할 수 있습니다. TUN을 끄면 정상 실행된다면 구독을 계속 수정하기보다 서비스 상태, 가상 네트워크 어댑터, 권한을 먼저 확인하세요.

운영체제별로 필요한 권한만 점검

Windows: 중복 실행된 인스턴스를 모두 종료한 뒤 클라이언트의 서비스 관리 메뉴에서 서비스 설치 여부와 실행 가능 여부를 확인하세요. 서비스 설치나 복구에 실제로 관리자 권한이 필요한 경우에만 관리자 승인을 확인합니다. 앱 데이터 폴더가 읽기 전용으로 설정되어 있지는 않은지도 살펴보세요.
macOS: 앱을 ‘응용 프로그램’ 폴더로 옮긴 뒤 실행하세요. 보조 도구 권한이나 시스템 보안 경고가 나타나면 개발자와 출처를 확인한 후 시스템 화면의 안내에 따라 필요한 작업을 허용하세요. 보안 속성을 일괄 제거하는 명령으로 오류를 감추지 마세요.
Linux: 터미널에서 실행해 표준 오류를 확인하세요. 신뢰할 수 있는 출처에서 받은 커널에 실행 권한이 없다면 해당 파일에만 실행 권한을 부여할 수 있습니다. TUN은 /dev/net/tun이 존재하는지, 서비스에 필요한 권한이 있는지 별도로 확인하세요.
Android: VPN 모드를 처음 활성화할 때 시스템 연결 요청을 승인해야 합니다. 일반적으로 한 사용자나 프로필 공간에서는 VPN 하나만 활성화할 수 있으므로 다른 VPN 앱을 종료한 뒤 다시 연결해 보세요.

‘설정 파일을 쓸 수 없음’과 ‘네트워크 장치를 만들 수 없음’은 구분해야 합니다. 전자는 설정, 데이터베이스, 로그 폴더 쓰기 실패가 로그에 남는 경우가 많고, 후자는 TUN 초기화 단계에서 발생합니다. 전체 인터페이스를 계속 관리자 권한으로 실행해도 잘못된 폴더 권한은 해결되지 않습니다.

5. 시스템 구성 요소 또는 실행 환경 누락

앱 로그가 생성되기도 전에 실행 프로그램에서 DLL, WebView 또는 공유 라이브러리가 없다는 메시지가 뜬다면 먼저 인터페이스 실행 환경을 확인하세요. Clash 클라이언트마다 Electron, Tauri, Flutter 등 서로 다른 기술을 사용할 수 있어 필요한 구성 요소도 다릅니다. 다른 클라이언트의 안내를 따라 런타임을 모두 설치할 필요는 없습니다.

Windows: 안내에 표시된 구성 요소의 전체 이름을 기록하세요. WebView2가 없다고 명시된 경우 Microsoft 공식 경로에서 해당 런타임을 설치합니다. Microsoft Visual C++ 런타임이 누락되었다면 프로젝트 요구 사항에 맞는 아키텍처를 선택하세요. DLL 파일만 따로 받아 시스템 폴더에 넣지 마세요.
macOS: ‘콘솔’ → ‘충돌 보고서’에서 해당 프로세스를 찾아 macOS 버전 미지원 또는 아키텍처 로드 실패 여부를 확인하세요. 지원하는 최소 시스템 버전은 해당 클라이언트의 최신 릴리스 노트를 기준으로 확인합니다.
Linux: 터미널에서 실행해 누락된 공유 라이브러리를 확인하세요. 신뢰할 수 있는 프로그램이라면 ldd로 동적 종속성을 확인할 수 있습니다. 배포판에 맞는 패키지를 우선 사용하고 시스템 패키지 관리자로 종속성을 설치하세요. 시스템 핵심 라이브러리를 수동으로 교체하지 마세요.

Windows에서는 Win + R을 누르고 perfmon /rel을 입력해 안정성 모니터를 열면 같은 시각의 앱 오류 기록을 확인할 수 있습니다. 오류 모듈 이름과 예외 코드는 보관해 두세요. 시스템 DLL 이름이 표시되었다고 해서 해당 DLL이 손상되었다고 단정할 수는 없습니다.

6. 캐시 또는 앱 상태 손상

업데이트 중단, 갑작스러운 전원 차단, 버전 간 마이그레이션으로 창 상태, 인터페이스 캐시 또는 로컬 데이터베이스가 손상될 수 있습니다. 창이 빈 화면으로 표시되거나 실행 직후 종료되거나 이전 페이지를 복원할 때마다 충돌하는 것이 흔한 증상입니다. 캐시 삭제는 후순위로 시도해야 하며 첫 번째 조치로 삼지 마세요.

데스크톱: 전체 폴더를 지우지 말고 백업 후 재생성

인터페이스, 커널, 백그라운드 서비스를 종료하고 데이터에 계속 쓰는 프로세스가 없는지 확인하세요.
프로젝트 문서나 로그에서 실제 데이터 폴더를 찾은 뒤 폴더 전체를 복사해 백업하세요. 이름이 비슷한 클라이언트라도 데이터 경로를 공유한다고 단정할 수 없습니다.
먼저 클라이언트에서 제공하는 캐시 삭제 또는 인터페이스 초기화 기능을 사용하세요. 인터페이스를 열 수 없다면 문서에서 캐시나 창 상태 파일로 명시한 항목만 이름을 바꿔 보관하세요.
앱 데이터 폴더 전체를 새로 만들어야 한다면 구독과 사용자 지정 규칙이 백업되었는지 확인하세요. 그런 다음 기존 폴더의 이름을 바꿔 백업으로 남기면 앱이 새 데이터를 만들 수 있습니다.
초기 상태에서 실행되는 것을 확인한 뒤 구독과 오버라이드를 하나씩 복원하세요. 이전 폴더 전체를 곧바로 다시 복사하지 마세요.

Windows 앱 데이터는 %APPDATA% 또는 %LOCALAPPDATA% 아래에 있을 수 있고, macOS에서는 ~/Library/Application Support/, Linux에서는 ~/.config/ 아래에 있는 경우가 많습니다. 하지만 이 경로들은 상위 폴더일 뿐, 그대로 삭제할 대상이 아닙니다.

Android: 캐시 삭제와 데이터 삭제를 구분

Android에서 ‘설정’ → ‘앱’ → 해당 클라이언트 → ‘저장공간 및 캐시’로 이동해 먼저 ‘캐시 삭제’를 시도하세요. 제조사에 따라 메뉴 이름은 조금 다를 수 있습니다. ‘저장공간 삭제’ 또는 ‘데이터 삭제’를 선택하면 앱이 초기화되어 구독, 설정, 인증 상태가 함께 사라질 수 있으므로 반드시 백업한 뒤 진행하세요. 설치 파일의 아키텍처가 맞지 않거나 시스템 버전이 요구 사항을 충족하지 않으면 캐시를 지워도 해결되지 않습니다.

복구 후 순서대로 확인

창이 열리는 것은 첫 단계일 뿐입니다. ‘인터페이스 안정성 → 커널 수신 포트 → 프록시 연결 → TUN’ 순서로 복구하고, 각 단계가 정상인지 확인한 뒤 다음 단계로 진행하세요. 여러 설정을 한꺼번에 바꾸지 않는 것이 중요합니다.

클라이언트를 두 번 연속으로 실행하고 종료해 새 충돌 기록이 남지 않는지 확인하세요.
정상 작동이 확인된 설정을 사용하고 TUN은 잠시 끈 상태로 둡니다. 로그에 로드 실패나 포트 바인딩 오류가 남아 있는지 확인하세요.
시스템 프록시를 활성화하고 프록시 포트가 현재 커널의 수신 포트와 일치하는지 확인한 다음 앱의 인터넷 연결을 테스트하세요.
마지막으로 TUN, 오버라이드 규칙, 자동 업데이트를 다시 활성화하세요. 어느 단계에서 문제가 재현되는지 확인하고 해당 모듈을 점검하면 됩니다.

계속 강제 종료된다면 문제를 제보할 때 운영체제 버전, CPU 아키텍처, 클라이언트 버전, 커널 버전, 설치 파일 종류, 처음 발생한 시각, 민감 정보를 가린 로그를 함께 첨부하세요. 업데이트 후인지, 설정을 가져온 뒤인지, TUN을 켠 뒤인지도 설명하면 좋습니다. ‘실행되지 않음’이라는 한마디보다 이런 정보가 있어야 유지 관리자가 문제를 재현하기 쉽습니다. 재설치가 필요하다면 다운로드 페이지에서 운영체제와 아키텍처를 확인하세요. 설정 복구는 입문 가이드를 참고할 수 있습니다.