Clash 실행 직후 종료될 때 해결 방법: 시작 충돌 원인과 단계별 점검

먼저 설정을 삭제하거나 반복해서 재설치하지 마세요. Clash를 실행하자마자 종료된다면 우선 화면 프로세스가 충돌한 것인지, 프록시 코어가 시작되지 못한 것인지 구분해야 합니다. 전자는 실행 환경, 화면 캐시, 설치 파일과 관련된 경우가 많고, 후자는 YAML, 수신 포트, 코어 파일, 권한을 먼저 확인해야 합니다. 웹페이지가 열리지 않는 것은 결과일 뿐, 클라이언트가 종료됐다는 뜻은 아닙니다.

1. 종료된 것이 창인지, 화면 프로세스인지, 코어인지 확인

많은 클라이언트는 닫기 버튼을 눌러도 시스템 트레이로 최소화될 뿐입니다. 창이 사라졌다고 프로세스까지 종료된 것은 아닙니다. Windows에서는 작업 표시줄 오른쪽의 숨겨진 아이콘을 펼친 다음 Ctrl + Shift + Esc를 눌러 작업 관리자를 여세요. macOS에서는 메뉴 막대 아이콘과 ‘활성 상태 보기’를 확인하고, Android에서는 알림 창에 VPN 상시 알림이 남아 있는지 살펴보세요.

관찰된 증상	우선 확인할 내용	다음 단계
창은 사라졌지만 트레이 아이콘과 프로세스는 남아 있음	백그라운드 실행 중이거나 창 상태에 문제가 있을 수 있음	먼저 트레이에서 창 복원
화면은 열리지만 코어 시작 실패 메시지가 표시됨	설정, 포트 또는 코어 문제	코어 로그에서 첫 번째 오류 확인
화면과 프로세스가 모두 즉시 사라짐	애플리케이션 충돌 또는 실행 환경 문제	시스템 애플리케이션 오류 기록 확인
TUN을 켰을 때만 종료되거나 오류가 발생함	서비스 권한, 드라이버 또는 가상 네트워크 어댑터 문제	TUN을 끄고 비교 테스트

Windows에서는 Win + R을 누르고 eventvwr.msc를 입력한 다음 ‘Windows 로그’ → ‘응용 프로그램’에서 오류 발생 시각의 애플리케이션 오류를 확인하세요. perfmon /rel을 실행해 안정성 모니터를 열어도 됩니다. 오류가 발생한 애플리케이션, 오류 모듈, 예외 코드를 기록하세요. 이 정보는 원인을 추적하는 단서일 뿐, 특정 시스템 DLL이 표시됐다고 해서 해당 파일을 삭제하거나 교체해야 한다는 뜻은 아닙니다.

2. 로그를 보존하고 최소 설정으로 YAML 오류 분리

로그와 설정 파일 찾기

화면을 열 수 있다면 먼저 ‘로그’ 페이지를 확인하고, ‘설정’에서 ‘설정 디렉터리 열기’, ‘로그 디렉터리 열기’와 같은 메뉴를 찾아보세요. 클라이언트마다 메뉴 이름과 경로가 다르므로 특정 제품의 디렉터리를 모든 Clash 클라이언트에 그대로 적용하면 안 됩니다. 화면이 열리지 않으면 설치 방식과 클라이언트 문서를 참고해 사용자 데이터 디렉터리를 찾으세요. 포터블 버전은 프로그램 디렉터리에 데이터를 저장할 수 있고, 설치 버전은 일반적으로 사용자 데이터 경로를 사용합니다.

yaml, unmarshal, parse, permission denied, address already in use 등의 오류를 검색하세요. 시작 단계에서 발생한 첫 번째 유효 오류부터 확인하는 것이 좋습니다. 뒤이어 나오는 ‘코어에 연결할 수 없음’은 앞선 오류의 연쇄 결과인 경우가 많습니다.

설정 검사는 연결 테스트와 다릅니다

mihomo 코어를 사용한다면 코어가 있는 디렉터리에서 아래 PowerShell 명령을 실행할 수 있습니다. 해당 디렉터리에 mihomo.exe와 검사할 config.yaml이 실제로 있어야 합니다. 클라이언트에 포함된 코어 파일 이름은 다를 수 있으므로 실제 파일 이름을 사용하세요.

.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml

-v는 실제 코어 버전을 확인하고, -t는 설정을 검사하는 옵션입니다. 검사를 통과해도 노드 연결이 된다는 뜻은 아니며, 정상 실행 시 포트를 사용할 수 있다는 보장도 없습니다. 외부 규칙 세트, 구독 제공자, Geo 데이터가 포함된 전체 설정은 데이터 디렉터리와 리소스 파일에 의존할 수 있습니다. 클라이언트와 분리해 검사할 때는 경로 차이에 유의하세요.

흔한 문법 오류로는 Tab으로 들여쓰기, 콜론 뒤 공백 누락, 목록 계층의 들여쓰기 오류, 구독 응답으로 받은 로그인 페이지나 오류 페이지를 YAML로 착각하는 경우가 있습니다. 오류 메시지에 표시된 줄 번호를 단서로 삼되, 실제 문제는 바로 앞 줄에 있을 수도 있습니다. # 같은 특수 문자가 포함된 비밀번호나 URL 매개변수는 주석이나 다른 YAML 문법으로 처리되지 않도록 따옴표로 감싸는 편이 좋습니다.

구독을 덮어쓰지 말고 별도 진단 파일 사용

아래 내용을 별도의 diagnostic.yaml 파일로 저장한 뒤 설정 검사를 실행하세요. 프록시 노드는 포함되어 있지 않으며, 기본적인 구문 분석과 실행 환경을 확인하기 위한 파일입니다. 평소 사용하는 구독 설정을 대체하는 용도로는 사용할 수 없습니다.

mixed-port: 17890
allow-lan: false
mode: direct
log-level: debug
ipv6: false
tun:
  enable: false
dns:
  enable: false
rules:
  - MATCH,DIRECT

.\mihomo.exe -t -f .\diagnostic.yaml
.\mihomo.exe -f .\diagnostic.yaml

두 번째 명령을 실행하기 전에 클라이언트와 백그라운드 코어를 완전히 종료해 중복 실행으로 인한 간섭을 방지하세요. 명령은 포그라운드에서 실행되며 Ctrl + C를 누르면 중지됩니다. 최소 설정은 실행되지만 기존 설정은 실패한다면 DNS, 프록시 제공자, 규칙 세트, TUN을 차례로 추가하고 매번 다시 검사하세요. 구독, 코어, DNS를 한꺼번에 바꾸지 마세요. 어떤 변경이 효과가 있었는지 파악하기 어렵습니다.

3. 코어 파일 누락, 아키텍처 불일치, 보안 차단

Clash 클라이언트는 그래픽 인터페이스이며, Clash와 Clash Meta(mihomo)는 코어 계열의 서로 다른 구현 또는 발전 분기입니다. 화면이 표시된다고 해서 해당 코어가 함께 설치되어 있다는 뜻은 아닙니다. 새 구독을 구형 코어에서 사용하면 지원하지 않는 필드나 프로토콜 때문에 불러오지 못할 수도 있습니다. 실행 파일을 임의로 교체해 모든 클라이언트를 ‘업그레이드’하려고 하지 마세요.

설치 파일이 제대로 압축 해제됐는지 확인하세요. 압축 파일 미리보기 창에서 프로그램을 바로 실행하거나 리소스 디렉터리를 빠뜨린 채 주 프로그램만 복사하지 마세요. 재설치 전에는 사용자 데이터를 백업하고 해당 클라이언트의 배포 안내를 따르세요.
시스템 아키텍처를 확인하세요. Windows는 ‘설정’ → ‘시스템’ → ‘시스템 정보’에서 시스템 종류를 확인하고, macOS는 ‘이 Mac에 관하여’에서 칩을 확인하세요. Linux에서는 uname -m을 실행하면 됩니다. x64, ARM64, x86용 설치 파일은 서로 바꿔 사용할 수 없습니다.
차단 기록을 확인하세요. Windows에서 ‘Windows 보안’ → ‘바이러스 및 위협 방지’ → ‘보호 기록’으로 이동해 코어 파일이 격리됐는지 확인하세요. 배포 출처와 해당 파일을 먼저 검토하고, 모든 보안 기능을 바로 끄지는 마세요.
클라이언트에서 지원하는 코어 업데이트 방법을 사용하세요. 클라이언트와 코어 버전을 기록해 두세요. 교체 후 문제가 발생했다면 파일을 계속 조합하기보다 마지막 변경을 우선 되돌리세요.

macOS의 ‘열 수 없음’, ‘개발자를 확인할 수 없음’ 메시지는 프로세스 충돌과 다릅니다. 출처를 신뢰할 수 있고 시스템 정책상 허용되는 경우 ‘시스템 설정’ → ‘개인정보 보호 및 보안’에서 관련 안내를 확인하세요. 조직에서 관리하는 기기는 관리 정책을 따라야 합니다. Linux에서 Permission denied가 표시되면 실행 권한 부족, 디렉터리 접근 불가, 파일 시스템의 noexec 제한을 각각 확인해야 합니다. 설치 프로그램을 반복해서 실행하는 것만으로는 해결되지 않습니다.

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

일반 HTTP/SOCKS 프록시는 높은 번호의 포트에서 수신하므로 보통 화면을 항상 관리자 권한으로 실행할 필요는 없습니다. TUN은 가상 네트워크 어댑터, 라우팅, DNS 가로채기와 관련되어 데스크톱 클라이언트에 서비스 모드나 권한 상승 보조 프로그램이 필요할 수 있습니다. TUN을 켰을 때만 오류가 발생한다면 먼저 TUN을 끄고 일반 프록시를 테스트해 서비스 또는 네트워크 가로채기 단계로 원인을 좁히세요.

Windows: 클라이언트 설정에서 ‘서비스 모드’ 또는 ‘TUN’ 관련 상태를 확인하세요. 서비스가 설치되지 않았거나 사용할 수 없다는 메시지가 나오면 클라이언트 안내에 따라 서비스를 복구하세요. 관리자 권한으로 한 번 실행하는 방법은 진단에 쓸 수 있지만, 정상적인 서비스 설치 절차를 대신할 수는 없습니다.
macOS: 클라이언트에서 요구하는 보조 프로그램에 권한이 부여됐는지 확인하세요. 앱을 업그레이드한 뒤 권한 안내가 표시된다면 시스템 네트워크 구성 요소를 직접 삭제하지 말고 권한 상태를 다시 확인하세요.
Linux: TUN을 사용하려면 일반적으로 /dev/net/tun에 접근할 수 있어야 하며 적절한 네트워크 관리 권한도 필요합니다. 컨테이너 환경에서는 장치 매핑과 기능 설정에도 영향을 받으므로 일반적인 데스크톱 설치 방법이 그대로 적용되지 않을 수 있습니다.
Android: 시스템 VPN 권한을 거부하면 연결을 설정할 수 없지만, 앱이 강제 종료된 것은 아닐 수 있습니다. 다른 VPN 앱을 끈 다음 연결을 다시 시도하고 권한을 허용하세요. 업무용 프로필이나 기기 관리 정책이 VPN 사용을 제한할 수도 있습니다.

5. 7890 포트 충돌은 설정 문법 오류가 아닙니다

로그에 bind 또는 address already in use가 표시된다면 설정 구문 분석은 끝났지만 수신 포트를 열지 못했을 수 있습니다. Windows에서는 아래 명령으로 TCP 7890 포트를 수신 중인 프로세스를 확인할 수 있습니다. 수신 기록이 없으면 첫 번째 명령에서 개체를 찾을 수 없다는 메시지가 나올 수 있습니다.

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

netstat -ano | findstr :7890

두 번째 명령에는 원격 포트나 다른 상태의 정보가 포함될 수 있으므로 로컬 주소 열과 수신 상태를 함께 확인하세요. 결과에 나온 PID를 기준으로 작업 관리자의 ‘세부 정보’에서 프로세스 이름을 확인하면 됩니다. macOS에서는 lsof -nP -iTCP:7890 -sTCP:LISTEN, Linux에서는 ss -ltnp 'sport = :7890'을 실행하세요. 일부 프로세스 정보는 추가 권한이 있어야 확인할 수 있습니다.

이전 클라이언트 프로세스가 남아 있다면 해당 클라이언트의 정상 종료 메뉴를 사용하세요. 필요한 다른 프로그램이 포트를 사용 중이라면 비어 있는 것이 확인된 7891로 mixed-port를 변경하고 시스템 프록시와 브라우저의 수동 프록시 포트도 함께 수정할 수 있습니다. 별도의 port, socks-port, external-controller도 충돌할 수 있으므로 7890만 확인해서는 안 됩니다.

일부 화면은 시작할 때 실행 설정을 다시 생성합니다. 디스크의 파일을 수정해도 재시작 후 원래 값으로 돌아간다면 임시 생성 파일을 반복해서 편집하지 말고 클라이언트의 포트 설정이나 덮어쓰기 기능을 사용하세요.

6. 런타임과 화면 캐시: 설정 외의 원인도 확인

오류 메시지에 나온 의존성만 설치하고 개별 DLL은 내려받지 마세요

Windows에서 VCRUNTIME140.dll, MSVCP140.dll 등의 파일이 없다는 오류가 나오면 먼저 클라이언트 안내를 참고해 Microsoft Visual C++ 2015–2022 Redistributable을 복구하고 프로그램 아키텍처에 맞는 버전을 설치하세요. 64비트 시스템에서도 32비트 프로그램을 실행할 수 있으므로 필요한 런타임은 시스템 비트 수가 아니라 프로그램에 따라 달라집니다.

WebView2 기반 클라이언트는 Microsoft Edge WebView2 Runtime에 의존할 수 있지만, Electron이나 Flutter 클라이언트라고 해서 모두 해당 런타임이 필요한 것은 아닙니다. 로그나 프로젝트 안내에서 이 의존성을 명확히 지목할 때만 설치하거나 복구하세요. ‘런타임 전부 설치’를 만능 해결책으로 삼지 마세요. Linux에서 GLIBC 버전 오류가 발생하면 대개 현재 배포판을 지원하는 빌드를 선택해야 합니다. 다른 시스템의 libc 파일을 복사해 해결할 수는 없습니다.

되돌릴 수 있는 방법으로 사용자 데이터 손상 여부 확인

코어를 단독으로 실행하면 정상인데 화면이 시작 중 계속 충돌한다면 프로세스를 완전히 종료한 다음 클라이언트의 사용자 데이터 디렉터리를 백업하고 이름을 바꾼 뒤 다시 실행해 새 데이터를 생성해 보세요. 디렉터리 전체를 바로 삭제하지 마세요. 구독, 규칙 덮어쓰기, 화면 상태, 인증 정보가 서로 다른 파일에 저장될 수 있습니다.

새 디렉터리에서 정상 실행되면 먼저 구독을 복원하고, 다음으로 덮어쓰기 규칙을 복원한 뒤, 마지막으로 화면 상태와 캐시를 복원하세요. 이전 파일을 한꺼번에 모두 복사하면 문제까지 다시 가져올 수 있습니다. 로그에서 GPU 프로세스를 지목한다면 클라이언트 문서를 참고해 하드웨어 가속을 끄고 테스트하세요. 특정 화면의 실행 옵션을 모든 Clash 클라이언트에 그대로 적용하지 마세요.

7. 복구 후 항목별 확인 및 문의할 때 필요한 정보

창이 열린 것은 첫 단계일 뿐입니다. 아래 항목을 순서대로 확인하고 각 단계가 정상일 때 다음 기능을 복원하세요.

화면이 계속 실행되는지, 로그에 코어 재시작이나 설정 구문 분석 실패가 반복해서 나타나지 않는지 확인하세요.
실제로 사용하는 설정이 올바른지, 구독 업데이트 후에도 불러올 수 있는지 확인하세요. 덮어쓰기 설정에서 오류 필드가 다시 추가되지 않았는지도 살펴보세요.
규칙 모드에서 브라우저 요청을 테스트하고 연결 기록에서 실제로 적용된 규칙과 출구 노드를 확인하세요.
TUN이 필요한 경우에만 활성화한 뒤 DNS 확인, 절전 모드 복귀, 네트워크 전환을 테스트하세요.
클라이언트를 종료한 뒤 시스템 프록시가 원래 상태로 돌아오는지 확인하세요. 클라이언트가 비정상 종료된 후에도 웹페이지가 열리지 않는다면 시스템에 로컬의 이전 포트를 가리키는 수동 프록시 설정이 남아 있는지 먼저 살펴보세요.

해결되지 않으면 클라이언트 이름과 전체 버전, 코어 버전, 시스템 버전, CPU 아키텍처, 문제가 처음 발생하기 직전에 한 작업, 시작 시각 전후의 오류 로그를 제공하세요. ‘최소 설정으로 실행되는지’, ‘TUN을 끄면 정상인지’, ‘새 사용자 데이터 디렉터리에서는 정상인지’도 함께 알려주면 ‘연결 실패’ 화면만 보내는 것보다 원인 파악에 훨씬 도움이 됩니다.

설정 필드를 확인하려면 YAML 가이드를 참고하고, 일반적인 네트워크 문제는 문제 해결 가이드에서 확인하세요. 전체 점검 과정의 핵심은 먼저 문제가 발생한 계층을 찾고 해당 설정만 수정하는 것입니다. 원인을 찾지 못한 채 재설치로 덮으려 하지 마세요.