Clash 클라이언트 실행 즉시 종료될 때 해결 방법: 실행 환경부터 설정 복구까지 점검 절차

먼저 구분하기: 창 즉시 종료, 백그라운드 실행, 코어 종료

“Clash가 실행되지 않음”을 검색하기 전에 먼저 사라진 것이 창인지 전체 프로세스인지 확인해야 합니다. Clash 계열 클라이언트는 화면, 구독 가져오기, 설정 관리를 담당하고, Clash 또는 Clash Meta(mihomo) 코어는 프록시 연결, 규칙 매칭, DNS 처리를 담당합니다. 화면은 정상적으로 표시되지만 코어가 실행되지 않을 수 있고, 반대로 코어는 계속 실행 중인데 화면 창만 닫힐 수도 있습니다. 두 경우에 수집해야 할 로그와 복구 위치가 다릅니다.

한 번 실행한 뒤 약 10초간 관찰하고 시스템 트레이, 활성 상태 보기 또는 작업 관리자를 확인하세요. 프로그램을 연속으로 두 번 클릭하지 마세요. 이미 실행 중인 인스턴스, 백그라운드 서비스, 새 실행 요청이 섞이면 포트 점유와 종료 시점을 판단하기 어려워집니다.

관찰된 현상	우선 점검할 항목	보존할 증거
창은 사라졌지만 트레이 메뉴는 열림	트레이로 닫기 및 시작 시 최소화 설정	트레이 상태, 화면 프로세스의 지속 실행 여부
창과 화면 프로세스가 모두 종료됨	아키텍처, 화면 실행 종속성, 애플리케이션 데이터	시스템 충돌 기록, 화면 로그
화면은 열리지만 코어 실행 실패가 표시됨	설정 파싱, 리소스 경로, 수신 포트	코어 종료 직전의 첫 번째 구체적 오류
TUN을 켠 뒤에만 오류가 발생하거나 종료됨	서비스 권한, 가상 네트워크 어댑터, 라우팅 충돌	TUN 활성화 전후 로그 차이
화면과 코어는 정상인데 웹페이지에 접속할 수 없음	프록시 적용, DNS, 노드, 규칙	연결 기록. 이것만으로 즉시 종료를 판단할 수 없음

작업 전 백업: 설정, 로그, 버전 정보 보존

바로 제거하면 손상된 사용자 데이터가 남거나 아직 내보내지 않은 구독과 오버라이드가 삭제될 수 있습니다. “재설치해도 계속 즉시 종료됨”만으로 설치 패키지 문제라고 단정할 수 없습니다. 먼저 클라이언트 전체 이름과 버전, 코어 버전, 시스템 버전과 아키텍처를 기록하고, 문제가 클라이언트 업데이트 후인지 구독 업데이트 후인지 설정 변경 후인지 표시하세요. 클라이언트 버전과 코어 버전은 서로 다른 정보이므로 “최신 버전”이라고만 적으면 안 됩니다.

백업에 포함할 항목

원본 설정과 구독: 로컬 YAML, 구독 기록, 현재 정상 작동하는 이전 설정을 저장하세요. 구독 URL에는 보통 접근 자격 증명이 포함되므로 비밀번호처럼 안전하게 보관해야 합니다.
오버라이드와 병합 로직: 규칙 추가, 설정 병합 조각, 스크립트를 별도로 저장하세요. 구독 원문이 올바르다고 해서 최종 실행 설정까지 올바른 것은 아닙니다.
클라이언트 설정: 시스템 프록시, TUN, 서비스 모드, 로컬 수신 포트, 컨트롤 인터페이스 설정을 기록하고 필요하면 화면을 캡처하세요.
오류 로그: 시작 전후 약 1분간의 기록을 보존하세요. 코어 로그뿐 아니라 화면 프로세스의 오류도 확인해야 합니다.

화면을 열 수 있다면 먼저 클라이언트에서 제공하는 설정 폴더 열기, 로그 폴더 열기 또는 내보내기 기능을 사용하세요. 클라이언트마다 메뉴 이름은 통일되어 있지 않습니다. 완전히 실행되지 않는다면 해당 클라이언트 문서에서 데이터 디렉터리를 확인하세요. Windows의 %APPDATA%와 %LOCALAPPDATA%, macOS의 ~/Library/Application Support/는 가능한 상위 경로일 뿐입니다. 전체 폴더를 삭제하거나 설치 폴더를 사용자 데이터 폴더로 간주하지 마세요.

복사하기 전에 클라이언트를 정상적으로 종료하고 관련 프로세스가 더 이상 파일에 기록하지 않는지 확인하세요. 서비스 모드를 사용 중이라면 클라이언트가 지원하는 서비스 관리 메뉴를 통해 해당 서비스를 중지해야 합니다. 프로세스 이름을 대략적으로 일치시켜 작업을 일괄 종료하지 마세요. 로그를 공유할 때는 별도의 비식별화 사본을 만들고 구독 토큰, 노드 비밀번호, 컨트롤 인터페이스 키, 개인 도메인, 사용자 이름을 가리세요.

실행 환경 점검: 시스템 아키텍처, 종속성, 압축 해제 상태

파일명으로 추측하지 말고 기기 아키텍처에 맞는 패키지 선택

Windows 11에서는 「설정」→「시스템」→「시스템 정보」에서 “시스템 종류”를 확인할 수 있습니다. Intel 또는 AMD 기반의 일반적인 데스크톱은 보통 x64를 선택하고, ARM 기기는 프로젝트에서 ARM64 패키지를 제공하는지 확인해야 합니다. macOS에서는 Apple 메뉴의 「이 Mac에 관하여」에서 “칩” 또는 “프로세서”를 확인해 Apple Silicon과 Intel을 구분하세요. Linux에서는 uname -m으로 아키텍처를 확인할 수 있으며, 일반적으로 x86_64와 aarch64는 각각 x64와 ARM64에 해당합니다.

프로세서 아키텍처가 맞는 것만으로는 충분하지 않습니다. 시스템 최소 버전, Linux 실행 라이브러리 버전, 데스크톱 환경에도 요구 사항이 있을 수 있습니다. Exec format error가 표시되면 먼저 실행 파일의 아키텍처를 확인하세요. GLIBC_… not found가 명확히 표시되면 배포판과 프로그램 빌드 요구 사항을 확인하고 시스템 핵심 실행 라이브러리를 수동으로 교체하지 마세요. Android 설치 패키지는 기기가 지원하는 ABI에 맞춰 선택해야 하며, 구형 기기는 “64비트 프로세서”라는 이유만으로 모든 ARM64 앱을 실행할 수 있다고 볼 수 없습니다.

종속성은 해당 클라이언트 구현에 맞춰 확인해야 함

Windows WebView 화면: WebView2에 의존하는 클라이언트에서 런타임 누락 또는 초기화 실패가 표시되면 프로젝트 문서에 따라 해당 런타임을 복구하세요. Electron 클라이언트는 다른 종속성 구성을 사용하므로 WebView2 설치를 만능 해결책으로 볼 수 없습니다.
DLL 누락: 오류 메시지나 프로젝트 안내가 Visual C++ 런타임 등의 구성 요소를 명확히 지목할 때만 해당 아키텍처의 런타임을 복구하세요. 출처가 불분명한 개별 DLL을 다운로드해 시스템 폴더에 넣지 마세요.
포터블 패키지: 먼저 현재 사용자가 읽고 쓸 수 있는 로컬 폴더에 전체 압축을 해제한 뒤 압축 해제 폴더에서 실행하세요. 압축 파일 미리보기에서 바로 실행하면 코어, 리소스 또는 인접 파일을 찾지 못할 수 있습니다.
시스템 차단: Windows의 「Windows 보안」→「바이러스 및 위협 방지」→「보호 기록」 또는 macOS의 「시스템 설정」→「개인정보 보호 및 보안」에서 관련 알림을 확인하고 차단된 파일과 원인을 파악하세요. 시스템 보안 기능 전체를 끄지 마세요.

Windows에서는 Win + R을 누르고 eventvwr.msc를 입력한 뒤 「Windows 로그」→「응용 프로그램」에서 실행 시각 전후의 오류를 찾으세요. 오류가 발생한 애플리케이션, 오류 모듈, 예외 코드를 기록합니다. 모듈 정보는 화면 렌더링 오류와 코어 종료를 구분하는 데 도움이 되지만, 모듈 이름 하나만으로 근본 원인을 확정할 수는 없습니다.

권한 및 포트 점검: 먼저 TUN을 끄고 범위 좁히기

클라이언트가 TUN을 활성화하거나 서비스를 설치한 뒤부터 문제가 발생했다면 먼저 화면에서 TUN을 끄고 종료한 다음 한 번 실행해 보세요. TUN은 네트워크 계층에서 트래픽을 가로채므로 시스템 권한, 서비스 또는 가상 네트워크 어댑터가 필요한 경우가 많습니다. 시스템 프록시는 시스템 프록시 설정을 따르는 앱에 프록시 진입점을 제공하는 기능으로, 두 설정은 같은 스위치가 아닙니다. 일반적인 화면 실행과 로컬의 높은 포트 번호 수신에는 지속적인 관리자 권한이 보통 필요하지 않습니다.

TUN을 끈 뒤 실행된다면 클라이언트 서비스 상태, 시스템 VPN 권한, 다른 VPN 또는 가상 네트워크 어댑터 소프트웨어와의 충돌을 계속 확인하세요. Windows 서비스 모드는 현재 클라이언트 문서에 따라 서비스를 복구해야 합니다. Android의 VPN 권한 문제나 다른 앱이 VPN 슬롯을 점유한 문제는 앱 화면 충돌과 분리해서 처리하세요. 모든 가상 네트워크 어댑터를 바로 삭제하거나 전체 데이터 디렉터리에 모든 사용자의 쓰기 권한을 부여하지 마세요.

로컬 포트 7890을 예로 든 수신 충돌 점검

로그에 address already in use 또는 Windows의 Only one usage of each socket address가 표시되면 먼저 실제로 충돌한 주소와 포트를 찾으세요. 아래 명령은 설정에서 실제로 7890을 사용하는 경우에만 적용됩니다. 컨트롤 인터페이스나 DNS 포트를 가리키는 오류라면 로그에 나온 포트를 확인해야 합니다.

# Windows PowerShell: 7890을 수신 중인 프로세스 찾기
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS: TCP 수신 프로세스 찾기
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux: TCP 수신 목록 및 프로세스 정보 확인
ss -ltnp

출력된 프로세스 식별자로 점유 주체를 확인하세요. Linux 일반 사용자는 다른 사용자의 전체 프로세스 정보를 보지 못할 수 있습니다. 점유 주체가 다른 프록시 클라이언트라면 먼저 정상적으로 종료하세요. 현재 클라이언트에 남은 서비스라면 해당 관리 메뉴를 통해 처리해야 합니다. 포트를 변경해야 한다면 브라우저나 시스템 프록시 진입점도 함께 수정하세요. 그렇지 않으면 코어가 복구되어도 앱이 이전 포트에 계속 연결합니다.

설정 점검: 코어가 실제로 읽는 YAML 검증

화면은 열리지만 코어가 반복해서 종료된다면 로그에서 마지막의 “실행 실패”가 아니라 첫 번째 구체적 오류를 찾아야 합니다. 흔한 원인으로는 YAML 들여쓰기 오류, 존재하지 않는 프록시 그룹을 가리키는 규칙, 코어가 지원하지 않는 노드 유형, 존재하지 않는 리소스 파일이 있습니다. Clash와 mihomo는 지원하는 필드 범위가 다르므로, 특정 클라이언트가 구독을 가져올 수 있다고 해서 그 클라이언트가 호출하는 코어가 모든 필드를 실행할 수 있다는 뜻은 아닙니다.

병합 결과를 먼저 확인한 뒤 구독 원문 점검

현재 선택된 설정 파일을 확인하고 로그 또는 클라이언트 기능에서 실제 실행 설정을 찾으세요.
오버라이드, 스크립트, 규칙 추가 또는 프록시 컬렉션이 활성화되어 있는지 확인하고 최근 추가된 처리 단계를 일시적으로 끄세요.
YAML이 공백으로 들여쓰기되었는지 확인하고 프록시 그룹 이름, 규칙 대상, 프록시 참조가 완전히 일치하는지 점검하세요.
구독 다운로드 실패와 설정 파싱 실패를 구분하세요. 로그인 페이지나 오류 페이지의 URL은 YAML로 코어에 넘겨 파싱할 수 없습니다.

mihomo를 사용하고 독립 실행 파일을 실행할 수 있다면 먼저 설정을 테스트할 수 있습니다. 아래 명령은 현재 폴더에 mihomo 실행 파일과 diagnostic.yaml이 있다고 가정합니다. Windows에서는 파일명이 mihomo.exe라고 가정합니다. 실제 이름은 사용 중인 클라이언트에 포함된 파일을 기준으로 해야 하며, 테스트를 위해 클라이언트 코어를 임의로 교체하지 마세요.

# macOS / Linux
./mihomo -v
./mihomo -t -f ./diagnostic.yaml

# Windows PowerShell
.\mihomo.exe -v
.\mihomo.exe -t -f .\diagnostic.yaml

-v는 코어 버전을 기록하고 -t는 설정을 테스트할 때 사용합니다. 설정에서 상대 경로, 프록시 컬렉션 또는 규칙 컬렉션을 사용한다면 코어 도움말에 따라 -d로 해당 작업 디렉터리를 지정해야 합니다. 그렇지 않으면 리소스 위치가 달라 추가 오류가 발생할 수 있습니다. 테스트 통과는 해당 테스트 환경에서 설정 점검이 통과했다는 뜻일 뿐, 포트 바인딩, TUN 권한, 원격 노드 연결까지 보장하지는 않습니다.

최소 직접 연결 설정으로 구독 문제 격리

아래는 mihomo용 진단 예시이며 프록시 노드와 프록시 출구를 포함하지 않습니다. 백업을 완료하고 시스템 프록시와 TUN을 끈 뒤 7890이 사용 중이지 않은지 확인한 경우에만 별도 테스트 파일로 사용하세요. 구독 원본 파일에 덮어쓰지 마세요. 클라이언트가 자동으로 추가하는 오버라이드도 일시적으로 꺼야 합니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

최소 설정은 실행되지만 원래 설정이 실행되지 않는다면 프록시 노드, 프록시 그룹, 규칙, DNS, 오버라이드를 하나씩 복구하면서 처음 실패한 변경 사항을 찾으세요. 최소 설정에서도 같은 종속성, 권한 또는 포트 오류가 계속되면 실행 환경 단계로 돌아가 점검해야 합니다. 화면 프로세스 충돌을 해결하려고 Fake-IP 전환이나 DNS 서버 변경 같은 네트워크 매개변수를 사용하지 마세요.

설정 복구: 기존 데이터를 격리하고 바로 초기화하지 않기

실행 환경을 확인했고 로그가 로컬 설정 읽기 실패를 가리키거나 업데이트 후 기존 사용자 데이터에서만 문제가 발생한다면 데이터 디렉터리를 격리해 테스트할 수 있습니다. 목적은 문제가 기존 데이터와 함께 발생하는지 확인하는 것이지, 원래 설정을 영구적으로 버리는 것이 아닙니다.

백업 완료 후 종료: 클라이언트와 해당 서비스를 중지하고 남은 프로세스가 계속 기록하지 않는지 확인하세요.
올바른 디렉터리 확인: 현재 클라이언트 문서에 따라 데이터 디렉터리를 찾으세요. 독립 설정 디렉터리나 포터블 모드를 지원한다면 프로젝트가 제공하는 격리 방식을 우선 사용하세요.
원본 디렉터리 보존: 확인한 데이터 디렉터리의 이름을 변경하세요. 백업 이름은 client-data.backup-20260819처럼 지정할 수 있으며 삭제해서는 안 됩니다.
기본 설정으로 실행: 클라이언트가 새 사용자 데이터를 생성하도록 하고, 처음에는 TUN을 켜지 말고 구독을 가져오거나 모든 설정을 복원하지 마세요.
단계별 복구: 먼저 정상 작동이 확인된 설정을 가져와 코어 실행을 확인한 다음 필요한 규칙과 오버라이드를 복원하고, 마지막에 시스템 프록시 또는 TUN을 활성화하세요.

빈 데이터 디렉터리에서도 계속 즉시 종료된다면 기존 설정만이 유일한 원인은 아닐 가능성이 큽니다. 시스템 충돌 로그와 버전 호환 조건을 다시 확인하세요. 특정 항목을 복원한 뒤 다시 실패한다면 복원 전후의 차이를 보존하는 편이 전체 재설치보다 원인 파악에 유리합니다. 기존 디렉터리를 되돌릴 때는 먼저 프로그램을 종료하고 이번 테스트에서 생성된 새 디렉터리를 보존한 뒤 원래 이름으로 복구하세요. 두 데이터베이스나 캐시를 그대로 섞지 마세요.

복구 후 검증 및 문제 제보 체크리스트

창이 다시 나타난 것은 첫 단계일 뿐입니다. 먼저 화면과 코어가 안정적으로 실행되는지 관찰하고 로컬 수신 포트를 확인한 뒤 마지막에 프록시 트래픽을 테스트하세요. 아래에서는 127.0.0.1:7890에서 수신하는 HTTP 혼합 포트를 예로 듭니다. 접근 권한이 있고 현재 네트워크에서 연결 가능한 HTTPS 주소를 선택해 검증하세요. 예시 주소의 연결 가능 여부는 현지 네트워크 환경의 영향을 받을 수 있습니다.

# macOS / Linux
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

# Windows: curl.exe를 명시적으로 호출
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

여기서 10초 연결 시간 초과와 20초 전체 시간 초과는 진단 상한이며 지연 시간 성능을 의미하지 않습니다. 200 Connection established만 보였다고 대상 요청이 성공했다고 판단할 수 없습니다. 이후 TLS와 HTTP 결과도 확인해야 합니다. 앞의 최소 설정을 계속 사용한다면 트래픽은 직접 연결됩니다. 실제 프록시 출구를 검증하려면 유효한 노드와 해당 규칙을 복원하고 연결 기록에서 적용된 정책을 확인하세요.

문제 제보 시 재현 가능한 정보 보존

클라이언트 이름, 전체 버전 번호, 코어 -v 출력, 시스템 버전 및 아키텍처
설치 패키지 유형, 포터블 모드 또는 서비스 모드 사용 여부, TUN 활성화 여부
재현 순서. 예: “기본 실행 정상 → 설정 가져오기 정상 → 오버라이드 활성화 후 코어 종료”
문제 발생 시각, 첫 번째 구체적 오류, 종료 코드, 비식별화한 인접 로그
기본 데이터 디렉터리 테스트, 최소 설정 테스트, 포트 점검에서 각각 어떤 결과가 나왔는지

문제가 한 번의 클라이언트 업데이트 후에만 발생했다면 위 증거를 첨부해 해당 프로젝트에 제보하세요. 다른 클라이언트를 선택하기 전에 클라이언트 선택 가이드에서 플랫폼과 코어 지원 범위를 확인할 수 있습니다. 설정 문제는 설정 전체 가이드와 대조해 항목별로 점검하세요. 문제를 재현해 특정 단계까지 격리하는 것이 반복적인 재설치보다 검증 가능한 해결책을 만들기 쉽습니다.