Clash 클라이언트 실행 즉시 종료될 때: 시작 오류 로그 확인 및 해결 방법

창이 닫힌 것인지 코어가 종료된 것인지 먼저 구분하세요

Clash 클라이언트를 실행하자마자 창이 사라져도 프로그램 전체가 충돌한 것은 아닐 수 있습니다. 데스크톱 클라이언트는 보통 그래픽 인터페이스, 프록시 코어, 별도로 실행될 수 있는 서비스 구성 요소로 이루어져 있습니다. 창이 닫힌 뒤에도 트레이 아이콘과 코어 프로세스가 남아 있을 수 있고, 반대로 mihomo 코어만 시작에 실패하고 인터페이스는 계속 표시될 수도 있습니다. 먼저 어느 구성 요소가 종료됐는지 확인한 다음 해결 방법을 선택하세요.

시작 전에 네 가지 정보를 기록하세요

• 클라이언트 이름과 전체 버전 번호를 확인합니다. 인터페이스가 열리면 ‘정보’ 페이지에서 확인하고, 열리지 않으면 설치 파일 이름이나 프로그램 파일 속성을 살펴보세요.
• 운영체제 버전과 아키텍처를 기록합니다. 예: Windows 11 x64, macOS arm64. ‘PC’라고만 적지 마세요.
• 오류가 발생한 시각을 분 단위까지 기록하고, 직전에 클라이언트를 업데이트했는지, 구독을 가져왔는지, TUN을 켰는지 함께 적어 두세요.
• 종료 전에 표시된 전체 메시지와 시스템에 클라이언트, mihomo 또는 관련 서비스 프로세스가 남아 있는지 기록합니다.

시작 로그와 시스템 충돌 기록 확인

Clash 클라이언트마다 앱 데이터 디렉터리가 다르므로 특정 클라이언트의 로그 경로를 공통 경로로 간주하면 안 됩니다. 인터페이스를 열 수 있다면 먼저 ‘로그’ 페이지를 확인하거나 ‘설정’에서 로그 디렉터리 또는 앱 디렉터리를 여는 메뉴를 찾으세요. 메뉴 이름은 클라이언트 버전에 따라 다를 수 있습니다. 오류 발생 시각 전후 약 1분간의 내용을 저장하고, ‘시작 실패’가 적힌 마지막 한 줄만 캡처하지 마세요.

Windows: 이벤트 뷰어와 앱 데이터

1. Win + R을 누르고 eventvwr.msc를 입력합니다.
2. ‘Windows 로그’ → ‘응용 프로그램’으로 이동해 오류 발생 시각 전후의 기록을 찾습니다. 앱 충돌의 일반적인 이벤트 원본은 Application Error이고 이벤트 ID는 1000이지만, 종료될 때마다 이 기록이 남는 것은 아닙니다.
3. 오류가 발생한 애플리케이션 이름, 오류 모듈, 예외 코드, 프로그램 경로를 기록하세요. 프로그램 경로를 확인하면 새로 설치한 버전으로 실행했는지, 이전 바로 가기로 실행했는지 파악하는 데 도움이 됩니다.
4. 파일 탐색기 주소창에 %APPDATA%와 %LOCALAPPDATA%를 각각 입력한 뒤 클라이언트 이름이나 프로젝트 식별자로 해당 디렉터리를 찾습니다. 로그는 앱 하위 디렉터리의 logs에 있거나 인터페이스에서 지정한 경로에 저장될 수 있습니다.

perfmon /rel을 실행해 안정성 모니터를 열고 날짜별 앱 오류 기록을 확인할 수도 있습니다. 시스템 보고서는 그래픽 인터페이스 충돌을 찾는 데 유용하고, 코어 로그는 YAML, 포트, 리소스 로드 문제를 진단하는 데 더 적합합니다. 두 기록은 서로 대체할 수 없습니다.

macOS: 진단 보고서와 콘솔

Finder에서 ‘이동’ → ‘폴더로 이동’을 선택하고 ~/Library/Logs/DiagnosticReports/를 입력합니다. 클라이언트 프로세스 이름과 오류 시각이 일치하는 .ips 또는 .crash 파일을 찾으세요. 앱 자체 로그는 ~/Library/Logs/ 또는 ~/Library/Application Support/ 아래의 전용 디렉터리에 있을 수도 있습니다. ‘콘솔’ 앱에서 프로세스 이름으로 오류를 필터링하고 예외 유형과 종료 원인을 확인하세요.

Linux: 터미널 실행과 사용자 로그

터미널에서 실제로 설치된 클라이언트 명령을 실행하면 아이콘을 두 번 클릭할 때 표시되지 않는 표준 오류 출력을 확인할 수 있습니다. 데스크톱 실행 명령은 해당 .desktop 파일의 Exec 필드에서 확인하세요. 프로그램이나 사용자 서비스가 journal에 로그를 기록한다면 최근 10분간의 기록을 확인할 수 있습니다.

journalctl --user --since "10 minutes ago" --no-pager

앱 데이터는 대개 ~/.config/, ~/.local/share/ 또는 ~/.local/state/ 아래의 프로젝트 디렉터리에 저장되지만, 정확한 위치는 클라이언트마다 다릅니다. systemd를 사용하고 충돌 정보가 보존된 경우 coredumpctl list를 실행해 기록을 확인하세요. 출력이 없다고 해서 프로그램이 충돌하지 않았다는 뜻은 아닙니다.

설정 문법 오류: 실제로 불러온 파일부터 확인

로그에 yaml, unmarshal 또는 설정 파싱 오류의 줄 번호가 표시되면 최근에 가져오거나 수정한 Profile부터 확인하세요. YAML 들여쓰기에는 탭이 아닌 공백을 사용하고 같은 수준의 필드는 들여쓰기를 일치시켜야 합니다. 구독 다운로드에 성공했다고 설정이 유효한 것은 아닙니다. 만료된 링크에서 로그인 페이지나 오류 문구, 변환되지 않은 노드 목록이 반환될 수 있습니다.

들여쓰기, 데이터 형식, 정책 이름 확인

• mixed-port: 7890은 숫자 필드의 예입니다. 전각 콜론을 사용하거나 들여쓰기 단계가 잘못되면 파싱에 실패할 수 있습니다.
• 목록 항목에는 올바른 - 접두사가 필요합니다. rules를 일반 문자열로 작성하면 형식 변환 오류가 발생할 수 있습니다.
• 규칙에서 참조하는 정책 이름은 설정의 프록시 또는 프록시 그룹 이름과 일치해야 합니다. 예를 들어 규칙은 Proxy를 사용하는데 설정에는 PROXY만 있다면 실제 이름을 확인하세요.
• 중복 필드와 새로 추가한 병합·재정의 설정도 확인하세요. 원본 구독이 올바르더라도 병합된 실행 설정에 오류가 있을 수 있습니다.

mihomo를 사용하는 Clash 클라이언트라면 코어 출처와 버전을 확인한 뒤 설정 사본으로 테스트할 수 있습니다. 아래 예시는 터미널의 현재 디렉터리에 config.yaml이 있고 mihomo를 바로 실행할 수 있다고 가정합니다.

mihomo -v
mihomo -t -f ./config.yaml

코어가 PATH에 없으면 클라이언트에서 실제로 사용하는 코어의 전체 경로를 지정하세요. 검증을 위해 다른 버전의 코어를 별도로 다운로드해 대체하지 마세요. 일부 설정은 규칙 리소스나 데이터베이스를 불러오려면 지정된 작업 디렉터리가 필요합니다. 이때는 -d로 확인된 작업 디렉터리를 지정할 수 있습니다. 테스트 결과를 문법 오류, 정책 참조 오류, 리소스 읽기 실패로 구분해 확인하세요.

클라이언트는 Profile, 전역 재정의, 인터페이스 설정을 바탕으로 최종 실행 설정을 생성할 수 있습니다. 따라서 원본 구독 테스트가 통과하더라도 실제로 불러온 파일에 오류가 없는지 확인해야 합니다. 가장 확실한 비교 방법은 수정 전 백업을 복원하고 클라이언트 버전을 바꾸지 않은 채 다시 시작하는 것입니다. 테스트를 위해 구독이나 규칙을 영구적으로 삭제하지 마세요.

코어 파일 누락: 설치 상태와 보안 기록 확인

no such file or directory, 실행 파일을 찾을 수 없다는 메시지, 코어 프로세스 생성 실패가 나타나면 로그에 표시된 실제 경로를 확인하세요. 업데이트 중단, 프로그램 디렉터리 직접 이동, 기본 프로그램 파일만 복사, 보안 프로그램의 구성 요소 격리 등으로 설치가 불완전해질 수 있습니다. 그래픽 인터페이스 파일이 있다고 해서 코어와 종속 구성 요소까지 모두 갖춰졌다는 뜻은 아닙니다.

1. 바로 가기의 대상과 설치 위치를 확인해 예전 압축 해제 디렉터리에서 실행하고 있지 않은지 살펴보세요.
2. 코어 파일이 있는지 확인하고 설치 파일의 아키텍처가 시스템과 일치하는지 확인하세요. Linux의 Exec format error는 실행 파일 형식이나 아키텍처가 맞지 않을 때 흔히 나타납니다.
3. Windows에서는 ‘Windows 보안’ → ‘바이러스 및 위협 방지’ → ‘보호 기록’을 열어 오류 발생 시각과 일치하는 격리 기록이 있는지 확인하세요.
4. 원래 프로젝트의 공식 배포 경로에서 전체 설치 파일을 다시 받아 클라이언트를 종료한 뒤 복구하거나 재설치하세요. 앱 데이터 백업은 보관하고 서로 다른 버전의 파일을 섞어 설치하지 마세요.

Windows 오류에 WebView2Loader.dll 또는 런타임 초기화가 언급된다면 YAML이 아니라 그래픽 인터페이스의 실행 환경에 문제가 있을 수 있습니다. WebView2에 의존하는 클라이언트에만 해당 런타임이 필요하며, 다른 클라이언트에 같은 해결 방법을 적용하면 안 됩니다. 클라이언트 배포 안내에 따라 종속성을 복구하고, 출처를 알 수 없는 웹사이트에서 DLL을 따로 다운로드해 시스템 디렉터리에 넣지 마세요.

macOS에서 시스템 보안이 앱 실행을 차단할 때는 대개 명확한 안내가 표시되며, 아무 메시지 없이 충돌하는 경우와는 다릅니다. 앱 출처, 시스템 호환성 요구 사항, 진단 보고서를 먼저 확인하세요. Gatekeeper를 끄거나 앱의 보안 속성을 한꺼번에 제거하는 방법을 일반적인 첫 단계로 삼지 마세요.

권한 문제: 디렉터리 권한과 TUN을 나눠서 확인

permission denied와 access is denied는 작업이 거부됐다는 뜻이지, 모든 경우에 관리자 권한으로 실행해야 한다는 뜻은 아닙니다. 일반적인 설정 파일 읽기·쓰기와 TUN 가상 네트워크 어댑터는 서로 다른 권한 문제입니다. 전자는 파일 소유자와 디렉터리 권한에 좌우되고, 후자는 권한 상승 서비스, 시스템 네트워크 확장 또는 장치 접근 권한이 필요할 수 있습니다.

디렉터리 읽기·쓰기 실패

먼저 로그에 표시된 정확한 파일 경로를 확인하세요. 설정이 읽기 전용 매체, 보호된 디렉터리 또는 동기화 폴더에 있으면 클라이언트가 캐시와 데이터베이스를 쓰지 못할 수 있습니다. Linux에서 그래픽 클라이언트를 sudo로 실행한 적이 있다면 앱 데이터 소유자가 root로 바뀌었을 수 있습니다. 사용자 디렉터리 전체의 권한을 넓히기보다 해당 디렉터리의 소유자를 확인하세요. 해결 방법으로 chmod -R 777을 사용하지 마세요.

TUN 또는 서비스 구성 요소 오류

1. TUN을 켜기 전 설정으로 되돌리고 그래픽 인터페이스와 일반 프록시가 정상적으로 작동하는지 먼저 확인하세요.
2. 사용 중인 클라이언트 문서에 따라 서비스 구성 요소를 설치하거나 복구한 뒤 인터페이스에서 제공하는 TUN 스위치를 사용하세요.
3. 시스템에서 권한 승인 요청, 네트워크 확장 차단 또는 서비스 시작 실패 메시지가 표시되는지 확인하고 해당 오류를 저장하세요.
4. 시스템 라우팅을 제어해야 하는 도구는 한 번에 하나만 켜세요. 가상 네트워크 어댑터와 라우팅 관리 프로그램 여러 개가 동시에 작동하지 않도록 합니다.

잔류 프로세스와 포트 충돌: 먼저 점유 프로세스 확인

업데이트 후 이전 코어가 계속 실행 중이면 새 코어가 수신 대기하려는 포트를 점유할 수 있습니다. 로그에 표시되는 address already in use는 단순한 ‘시작 실패’보다 원인을 파악하는 데 유용합니다. 프록시 수신 포트와 외부 제어 인터페이스 포트는 서로 다릅니다. 7890과 9090은 흔히 쓰이는 설정 예시일 뿐이므로 실제 설정과 오류 메시지에 표시된 포트를 기준으로 점검하세요.

포트를 사용하는 프로세스 확인

Windows 명령 프롬프트에서 다음 명령을 실행해 마지막 열의 PID를 확인한 다음 ‘작업 관리자’ → ‘세부 정보’에서 프로세스 이름과 실행 파일 경로를 대조하세요.

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

출력에 원격 주소가 일치하는 항목이 포함될 수도 있으므로 로컬 주소, 포트, 수신 대기 상태를 확인해야 합니다. macOS에서는 TCP 수신 프로세스를 조회할 수 있습니다.

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

Linux에서는 수신 대기 소켓을 확인할 수 있습니다. 프로세스 정보는 권한에 따라 제한되므로 일반 사용자는 다른 사용자의 프로세스를 확인하지 못할 수 있습니다.

ss -lntp 'sport = :7890'
ss -lntp 'sport = :9090'

1. 먼저 트레이에서 이전 클라이언트를 종료하세요. 독립 실행형 서비스는 설치 방식에 맞게 중지하고, 창만 닫지 마세요.
2. 포트를 다시 조회해 수신 대기가 사라졌는지 확인한 다음 대상 클라이언트를 시작하세요.
3. 포트 점유 프로세스가 다른 필수 서비스라면 대상 클라이언트의 포트를 변경하고 시스템 프록시와 관련 앱 설정도 함께 업데이트하세요.
4. 프로세스가 어떤 프로그램에 속하는지 확인한 뒤에만 종료하세요. ‘프록시처럼 보이는 이름’만 보고 시스템이나 네트워크 구성 요소를 한꺼번에 종료하지 마세요.

포트 충돌은 보통 코어 시작 실패를 일으키며 그래픽 인터페이스 자체를 바로 종료시키지는 않습니다. 포트를 비운 뒤에도 창이 즉시 닫힌다면 포트를 계속 바꾸지 말고 시스템 충돌 보고서를 다시 확인하세요.

백업 후 초기화: 설정을 단계별로 복원

로그만으로 원인을 찾기 어렵거나 이전 설정이 새 버전과 호환되지 않을 때는 깨끗한 앱 데이터로 비교 테스트를 할 수 있습니다. 앱 데이터는 설치 디렉터리와 분리되어 있는 경우가 많아 재설치만으로 설정이 초기화되지 않을 수 있습니다. 초기화 전에 현재 클라이언트가 사용하는 디렉터리를 확인해 다른 클라이언트의 데이터를 잘못 건드리지 않도록 하세요.

1. 프로그램을 종료합니다. 트레이에서 클라이언트를 종료하고 코어나 서비스가 더 이상 데이터를 쓰지 않는지 확인하세요.
2. 전체 백업을 만듭니다. 앱 데이터 디렉터리를 복사해 로컬 YAML, 구독 정보, 재정의 규칙, 인터페이스 설정을 보관하세요. 백업에는 민감한 정보가 들어 있으므로 접근을 통제할 수 있는 로컬 위치에 저장해야 합니다.
3. 기존 데이터를 분리합니다. 확인된 앱 데이터 디렉터리의 이름을 바꾸세요. 예를 들어 원래 이름 뒤에 .backup-20260917을 붙이고 바로 삭제하지 마세요.
4. 기본 상태로 시작합니다. 클라이언트가 새 디렉터리를 만들고 계속 실행되는지 확인하세요. 이 단계에서는 자동 연결, TUN, 전체 구독을 복원하지 마세요.
5. 항목별로 복원합니다. 먼저 유효한지 확인한 설정 하나를 가져오고, 다음으로 재정의 규칙을 복원한 뒤, 마지막으로 TUN과 서비스 설정을 복원합니다. 각 단계마다 로그를 다시 확인하세요.

어떤 항목을 복원한 뒤 문제가 다시 발생하면 반복해서 확인할 수 있는 원인 조건을 찾은 것입니다. 새 데이터에서도 계속 충돌한다면 설정 문제의 우선순위는 낮아지므로 클라이언트 버전, 런타임 종속성, 시스템 호환성을 확인하세요. 이전 버전으로 되돌릴 때도 별도 백업을 사용해 새 버전에서 마이그레이션된 데이터베이스를 구버전이 바로 읽지 않도록 하세요.

수정 결과 확인 및 문제 제보에 필요한 정보

창이 열린 것은 첫 번째 확인 단계일 뿐입니다. 코어가 계속 실행되는지, 설정을 정상적으로 불러왔는지, 수신 포트가 예상한 값인지 확인하세요. 시스템 프록시를 사용한다면 브라우저 요청이 해당 포트를 통과하는지 살펴보고, TUN을 사용한다면 라우팅과 DNS 동작도 확인하세요. 노드 연결 시간 초과는 연결 계층의 문제이므로 시간 초과만으로 클라이언트가 계속 시작 중에 충돌한다고 판단하지 마세요.

• 프로그램을 완전히 종료한 뒤 다시 시작해 잔류 프로세스에 의존하지 않고 문제가 해결됐는지 확인하세요.
• 수정 전후 로그를 저장하고 설정, 설치 파일, 권한, 서비스 상태 중 무엇을 변경했는지 기록하세요.
• 문제를 제보할 때는 클라이언트 및 코어 버전, 시스템 아키텍처, 재현 단계, 민감 정보를 가린 주요 오류를 함께 첨부하세요.
• 보고서에 오류 모듈이나 예외 코드가 포함되어 있다면 원문 그대로 남기세요. ‘열리지 않음’이라고만 적거나 창 스크린샷만 보내지 마세요.

점검 순서는 다음과 같습니다. 종료된 구성 요소를 확인하고 로그를 확보한 뒤 오류에 따라 설정, 파일, 권한, 포트를 점검하고, 마지막으로 백업 후 초기화해 비교합니다. 설치 파일을 다시 선택해야 한다면 클라이언트 다운로드 페이지를 확인하세요. 설정 가져오기와 시스템 프록시 사용 방법은 사용 가이드에서, TUN과 DNS 설정은 고급 설정에서 확인할 수 있습니다.