Clash 클라이언트 실행 즉시 종료될 때 해결 방법: 설정·권한·잔류 프로세스 점검

먼저 즉시 종료, 백그라운드 실행, 창 미표시를 구분하세요

Clash 그래픽 클라이언트는 보통 인터페이스 프로그램, 프록시 코어, 시스템 서비스로 구성됩니다. 아이콘을 두 번 클릭한 뒤 기본 창이 나타나지 않아도 세 구성 요소가 모두 종료된 것은 아닙니다. 인터페이스가 시스템 트레이로 숨겨졌거나, 창 좌표가 연결이 끊긴 모니터에 남아 있을 수 있으며, 프록시 코어가 백그라운드에서 포트를 계속 수신 중일 수도 있습니다. 문제 해결의 첫 단계는 반복 실행이 아니라 현재 상태를 확인하는 것입니다.

먼저 Windows 작업 표시줄 알림 영역, macOS 메뉴 막대 또는 Linux 데스크톱 트레이를 확인하세요. 클라이언트 아이콘이 보이면 메뉴에서 기본 화면을 열어 보세요. 듀얼 모니터나 원격 데스크톱을 사용했거나 배율을 변경한 적이 있다면 창이 화면 바깥에 있는지도 확인해야 합니다. 이런 경우는 인터페이스 복구 문제이지 프록시 코어 충돌이 아닙니다.

그다음 시스템 프로세스 관리 도구를 열고 클라이언트 인터페이스 프로세스와 Clash, mihomo 또는 사용 중인 클라이언트에 해당하는 코어 프로세스를 찾으세요. 다음 상태를 기준으로 원인을 좁힐 수 있습니다.

• 인터페이스와 코어 프로세스가 모두 즉시 사라짐: 실행 로그, 설정 파싱, 런타임과 로컬 데이터를 우선 점검하세요.
• 인터페이스는 사라졌지만 코어는 실행 중: 인터페이스 로그, 창 상태 파일, 그래픽 실행 환경을 집중적으로 확인하세요.
• 인터페이스는 남아 있지만 코어가 반복 재시작: YAML 설정, 포트 점유, TUN 권한과 코어 버전을 중점적으로 점검하세요.
• 프로세스는 계속 존재하지만 창이 없음: 먼저 트레이에서 창을 복원한 뒤 창 배치를 초기화하세요. 모든 설정을 바로 삭제하지 마세요.

로그로 클라이언트가 어느 단계에서 멈췄는지 확인하세요

갑작스러운 종료가 발생하면 팝업보다 로그가 더 정확합니다. 클라이언트마다 로그 저장 위치는 다르지만, 일반적으로 사용자 설정 디렉터리, 앱 데이터 디렉터리 또는 클라이언트 설치 폴더 주변에서 찾을 수 있습니다. 파일 이름에는 app, main, service, core 또는 runtime이 포함될 수 있습니다. 인터페이스가 잠시라도 열리면 설정이나 로그 화면에서 실제 경로를 먼저 확인하세요. 다른 클라이언트의 경로를 기준으로 파일을 바로 삭제하면 안 됩니다.

로그는 마지막 실행 시각부터 확인하고 error 하나만 검색하지 마세요. 일부 경고는 실행을 막지 않으며, 실제 종료 원인은 마지막 몇 줄에 나타나는 경우가 많습니다. 실행 단계를 기준으로 살펴보면 원인을 더 쉽게 찾을 수 있습니다.

1. 인터페이스 프로그램이 설정과 창 상태를 불러옵니다.
2. 현재 설정 파일 또는 구독에서 생성된 설정을 읽습니다.
3. Clash 또는 mihomo 코어를 실행합니다.
4. mixed-port, HTTP, SOCKS, 제어 포트 또는 DNS 포트에 바인딩합니다.
5. 규칙 세트, GeoIP, GeoSite 등의 데이터를 불러옵니다.
6. 시스템 프록시를 설치하거나 TUN 및 시스템 서비스를 시작합니다.

로그가 설정을 읽는 단계에서 멈췄다면 먼저 YAML을 점검하세요. address already in use, bind failed와 같은 메시지가 나오면 포트를 확인하고, permission denied, operation not permitted가 나오면 디렉터리 권한이나 TUN 권한을 확인하세요. 동적 라이브러리, WebView 또는 그래픽 구성 요소를 찾을 수 없다는 메시지는 인터페이스 실행 환경 문제입니다. 모든 오류를 구독 노드 탓으로 돌리면 안 됩니다. 노드를 사용할 수 없는 경우 연결에는 영향을 주지만, 인터페이스를 읽기도 전에 클라이언트가 즉시 종료되지는 않는 경우가 일반적입니다.

YAML 설정 문법과 코어 호환성 점검

설정 오류는 코어 실행 직후 종료되는 흔한 원인입니다. Clash 설정은 YAML을 사용하므로 들여쓰기, 목록 계층과 데이터 형식이 파싱 결과에 영향을 줍니다. Tab 문자, 전각 콜론, 누락된 공백, 닫히지 않은 따옴표, 목록을 일반 문자열로 작성한 경우에는 코어가 로드를 거부할 수 있습니다. 구독 다운로드가 성공했다고 해서 생성된 설정이 현재 코어와 호환된다는 의미는 아닙니다.

현재 설정을 먼저 백업한 다음 클라이언트에 포함된 기본 설정이나 이전에 정상 작동을 확인한 설정으로 전환하세요. 클라이언트가 정상 실행되면 원인은 현재 구독, 덮어쓰기 스크립트 또는 직접 수정한 내용으로 좁혀집니다. 처음부터 클라이언트를 삭제하지 마세요. 삭제 후 같은 잘못된 설정을 다시 가져오면 문제가 반복됩니다.

다음 예시는 혼동하기 쉬운 계층을 보여 줍니다. 규칙은 문자열 목록이고 프록시 그룹의 proxies 역시 목록이므로 들여쓰기 수준을 동일하게 유지해야 합니다.

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

프록시 코어를 직접 실행할 수 있다면 코어에 포함된 설정 테스트 옵션으로 파일을 점검할 수 있습니다. mihomo에서 흔히 사용하는 테스트 방법은 다음과 같으며, 실제 실행 파일 이름과 경로는 클라이언트 설치 내용에 따라 달라질 수 있습니다.

mihomo -t -f /path/to/config.yaml

테스트 결과의 줄 번호는 보통 파싱 실패 지점 주변을 가리키지만, 원인은 앞선 줄에 있을 수도 있습니다. 예를 들어 따옴표 하나가 닫히지 않으면 파서는 다음 필드에 도달한 뒤 오류를 보고할 수 있습니다. 점검할 때는 오류가 표시된 줄만 수정하지 말고 같은 설정 블록을 위쪽까지 다시 확인하세요.

업데이트 후에만 발생하는 필드 호환성 문제

Clash Meta는 이후 mihomo로 이어졌으며, 지원하는 설정 필드는 초기 Clash 코어와 완전히 같지 않습니다. 구독 변환 규칙, TUN 설정, DNS 강화 모드, 규칙 세트 형식과 프록시 프로토콜 매개변수는 특정 코어 버전에 의존할 수 있습니다. mihomo용으로 생성된 설정을 오래된 코어에 넘기면 unknown field, unsupported proxy type 또는 규칙 프로바이더 로드 실패가 발생할 수 있습니다.

반대로 코어를 업데이트한 뒤 이전 설정에서 그동안 무시되던 문제가 드러날 수도 있습니다. 이때는 클라이언트가 현재 사용하는 코어 종류와 버전을 확인한 뒤 구독 변환 대상을 점검하세요. 낯선 필드를 무작정 삭제해 강제로 실행하지 마세요. DNS, 규칙 세트 또는 프록시 매개변수를 삭제하면 문법은 통과하더라도 실제 트래픽 분기 결과가 달라질 수 있습니다.

실행 권한, 설정 디렉터리와 TUN 서비스 점검

일반적인 시스템 프록시 모드에서는 클라이언트를 항상 관리자 권한으로 실행할 필요가 없습니다. 하지만 보호된 디렉터리에 파일을 쓰거나 시스템 서비스를 설치하거나 TUN 네트워크 인터페이스를 만들 때는 필요한 권한이 있어야 합니다. 권한 부족은 명확한 메시지로 나타나기도 하고, 일부 클라이언트가 서비스 초기화 단계에서 바로 종료되는 형태로 나타나기도 합니다.

Windows 사용자는 클라이언트가 특별한 쓰기 권한이 필요한 시스템 디렉터리에 설치되어 있지 않은지 확인하고, 보안 정책이 자체 설정 디렉터리 쓰기를 차단하지 않는지도 점검하세요. 클라이언트가 별도 서비스 모드를 제공한다면 관리자 권한 실행에 계속 의존하지 말고 클라이언트 설정에서 서비스를 다시 설치하거나 복구하세요. 서비스 프로그램과 인터페이스 버전이 다르면 코어 실행 실패나 반복 재연결이 발생할 수도 있습니다.

macOS 사용자는 앱이 정상적인 응용 프로그램 디렉터리에 있는지, 시스템의 개인정보 보호 및 보안 설정이 네트워크 확장이나 백그라운드 항목을 차단하지 않는지 확인하세요. 출처가 불분명한 프로그램을 해결하기 위해 시스템 보안 기능을 끄지 마세요. 설치 패키지의 출처를 확인하고 현재 시스템 아키텍처에 맞는 버전을 사용해야 합니다. Linux 사용자는 설정 디렉터리 소유자, 실행 권한과 TUN 장치 접근 권한을 점검하세요.

TUN 모드 개별 검증

TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅을 변경하므로 일반 HTTP 또는 SOCKS 프록시보다 높은 권한이 필요합니다. 로그가 tun, route, interface, service 등의 지점에서 멈춘다면 TUN을 끄고 시스템 프록시만 활성화해 테스트해 보세요. 일반 프록시 모드가 실행된다면 YAML 본문과 인터페이스는 대체로 정상이며, 문제는 TUN 서비스·드라이버·권한 또는 라우팅 환경에 집중됩니다.

TUN을 끄는 것은 진단을 위한 단계일 뿐입니다. TUN을 다시 사용하려면 클라이언트의 서비스 설치 상태, 시스템에 이전 가상 네트워크 카드가 남아 있는지, 다른 VPN이나 네트워크 필터링 프로그램이 라우팅을 동시에 제어하는지 확인하세요. 여러 네트워크 도구가 동시에 작동하면 포트가 달라도 라우팅 테이블과 DNS 제어에서 충돌이 발생할 수 있습니다.

포트 충돌과 잔류 프로세스 처리

프록시 코어는 시작할 때 설정에 지정된 포트를 수신해야 합니다. 일반적인 포트에는 mixed-port, port, socks-port, external-controller 및 DNS listen이 있습니다. 이전 코어가 종료되지 않았거나 다른 프록시 프로그램이 같은 포트를 사용하면 새 코어는 바인딩 단계에서 실패합니다. 클라이언트 인터페이스가 코어 종료를 치명적 오류로 처리하면 함께 닫히면서, 아이콘을 두 번 클릭한 뒤 즉시 종료되는 것처럼 보일 수 있습니다.

Windows에서는 먼저 작업 관리자에서 해당 프로세스를 종료한 뒤 명령어로 지정 포트를 확인할 수 있습니다.

netstat -ano | findstr :7890

출력 마지막의 PID로 포트를 점유한 프로세스를 확인할 수 있습니다. macOS와 Linux에서는 다음 명령을 사용할 수 있습니다.

lsof -nP -iTCP:7890 -sTCP:LISTEN

포트 점유가 보인다고 해서 알 수 없는 시스템 프로세스를 바로 종료하지 마세요. 먼저 PID에 해당하는 프로그램 이름을 확인하세요. 이전 실행에서 남은 Clash 또는 mihomo라면 정상적으로 종료해도 되지만, 계속 사용해야 하는 다른 서비스라면 클라이언트 설정에서 포트를 변경하고 시스템 프록시 설정이 새 포트를 참조하는지도 함께 확인하세요.

잔류 프로세스가 반복해서 나타나는 이유

일부 클라이언트는 인터페이스를 종료해도 프록시 연결을 유지하기 위해 코어를 남겨 둡니다. 충돌 후 정리 로직이 실행되지 않는 클라이언트도 있습니다. 다시 실행하면 이전 코어가 포트, 제어 인터페이스 또는 설정 파일 잠금을 계속 보유할 수 있습니다. 먼저 트레이에서 완전히 종료하고 몇 초 기다린 뒤 프로세스를 확인하는 것이 올바른 방법입니다. 프로세스가 끝나지 않으면 시스템 도구로 종료하세요.

시스템을 재시작하면 일반적인 잔류 프로세스는 정리할 수 있지만 자동으로 시작되는 오래된 서비스까지 해결되지는 않습니다. 부팅할 때마다 충돌이 발생한다면 시스템 시작 항목과 서비스 목록을 확인해 서로 다른 버전의 클라이언트가 동시에 자동 실행되지 않는지 점검하세요. 현재 사용하는 클라이언트 진입점 하나만 남기고 해당 설정에서 코어 서비스를 통합 관리하세요.

백업 후 손상된 로컬 데이터 재구성

설정 문법, 권한과 포트가 모두 정상이라면 클라이언트가 저장한 자체 상태 데이터를 확인해야 합니다. 비정상 종료, 디스크 쓰기 중단 또는 버전 간 마이그레이션으로 창 배치, 설정 인덱스, 데이터베이스, 캐시 또는 설정 파일이 손상될 수 있습니다. 전체 데이터 디렉터리를 바로 삭제하면 프로그램이 복구될 수도 있지만 구독 기록, 덮어쓰기 규칙과 사용자 설정까지 함께 사라집니다. 따라서 단계적으로 격리해야 합니다.

1. 인터페이스, 코어와 관련 서비스를 완전히 종료합니다.
2. 클라이언트가 실제로 사용하는 데이터 디렉터리를 찾아 별도의 백업 위치에 복사합니다.
3. 먼저 창 상태, 캐시 또는 로그 디렉터리의 이름을 바꾼 뒤 실행을 테스트합니다.
4. 계속 즉시 종료되면 설정 데이터베이스 또는 설정 인덱스의 이름을 바꿉니다.
5. 클라이언트가 새 데이터 디렉터리를 생성하도록 한 뒤 기본 화면에 진입할 수 있는지 확인합니다.
6. 필요한 구독 주소와 검증된 설정만 복원하고 전체 디렉터리를 그대로 덮어쓰지 마세요.

삭제 대신 이름을 바꾸면 언제든 되돌릴 수 있고, 항목별 복원을 통해 손상된 파일도 찾을 수 있습니다. 클라이언트마다 데이터 구조가 크게 다르므로 파일 이름을 서로 그대로 적용하면 안 됩니다. 특히 Electron, WebView 또는 다른 데스크톱 컨테이너 기반 인터페이스는 캐시와 코어 설정이 서로 다른 하위 디렉터리에 있을 수 있으므로 로그와 클라이언트 설정을 기준으로 용도를 확인하세요.

새 데이터 디렉터리에서는 실행되지만 이전 구독을 가져온 뒤 다시 종료된다면 설정 호환성 점검으로 돌아가세요. 인터페이스 설정만 복원했을 때 충돌한다면 창 배치, 테마 상태 또는 로컬 데이터베이스를 우선 초기화하세요. 이렇게 하면 반복적인 재설치 대신 문제를 하나의 데이터 유형으로 좁힐 수 있습니다.

업데이트 후 충돌: 아키텍처·코어·실행 환경 확인

클라이언트 업데이트 후 처음 실행할 때 즉시 종료된다면 앱 아키텍처, 내장 코어, 운영체제 버전과 설정 마이그레이션을 함께 고려해야 합니다. Windows 설치 패키지는 x64, ARM64 등의 아키텍처로 나뉠 수 있고 macOS는 Intel과 Apple Silicon을 구분해야 합니다. 맞지 않는 빌드를 선택하면 실행되지 않거나 코어를 불러오는 중 종료될 수 있습니다. 시스템 정보에서 프로세서 아키텍처를 확인한 뒤 해당 버전을 선택하세요.

일부 그래픽 클라이언트는 시스템 WebView 또는 특정 런타임 구성 요소에 의존합니다. 로그에 실행 환경 누락이 명확히 표시되면 운영체제 또는 클라이언트 문서에서 안내하는 방법으로 구성 요소를 복구하세요. 다른 컴퓨터의 동적 라이브러리 파일을 복사하면 버전과 아키텍처 불일치가 생기기 쉬우므로 안정적인 해결 방법이 아닙니다.

덮어쓰기 설치를 해도 이전 코어, 이전 서비스 또는 기존 설정 마이그레이션 표시가 남을 수 있습니다. 이 경우 먼저 데이터를 백업하고 시스템 제거 절차로 기존 프로그램을 삭제한 뒤 현재 버전을 설치하세요. 삭제 전에 구독 주소, 사용자 규칙, 포트와 DNS 설정을 반드시 기록해야 합니다. 재설치 후에는 기본 상태로 먼저 실행해 인터페이스와 코어가 정상인지 확인한 다음 설정을 하나씩 복원하세요.

새 운영체제가 현재 클라이언트를 더 이상 지원하지 않는다면 해당 시스템에 맞고 계속 유지 관리되는 Clash 그래픽 클라이언트를 선택하세요. 마이그레이션에서는 인터페이스 이름만 비교하지 말고 설정과 코어의 호환성을 확인해야 합니다. mihomo 설정의 일부 필드는 해당 코어의 지원이 필요하며, 기존 Clash 설정을 새 코어로 옮길 때도 DNS, TUN과 규칙 프로바이더 동작을 다시 점검해야 합니다.

복구 절차를 정해진 순서대로 실행

즉시 종료 문제를 점검할 때 가장 흔한 실수는 여러 항목을 동시에 변경하는 것입니다. 다음 순서는 위험이 낮은 작업부터 시작하며 각 단계에서 명확한 결론을 얻을 수 있어, 실행 직후 종료·창 미표시·업데이트 후 충돌·코어 반복 중지에 모두 적용할 수 있습니다.

1. 트레이와 프로세스 확인: 창이 숨겨진 것인지, 인터페이스가 충돌한 것인지, 코어가 종료된 것인지 판단합니다.
2. 이전 인스턴스 완전히 종료: 인터페이스, 코어와 잔류 서비스를 닫아 여러 인스턴스가 포트를 경쟁하지 않도록 합니다.
3. 마지막 로그 확인: 마지막에 이어진 연쇄 오류만 보지 말고 중단 단계와 첫 번째 핵심 오류를 기록합니다.
4. 기본 설정으로 전환: 클라이언트 기본 설정으로 YAML과 구독이 원인인지 확인합니다.
5. 일반 프록시 모드 테스트: TUN을 잠시 끄고 코어 실행 문제와 시스템 네트워크 권한 문제를 구분합니다.
6. 수신 포트 점검: mixed-port, 제어 포트와 DNS 포트를 다른 프로그램이 사용하고 있지 않은지 확인합니다.
7. 프로그램 아키텍처와 코어 버전 확인: 클라이언트, 코어, 운영체제와 설정 대상이 서로 맞는지 확인합니다.
8. 로컬 상태 재구성: 백업한 뒤 캐시, 창 상태와 데이터베이스의 이름을 하나씩 변경합니다.
9. 마지막에 재설치: 먼저 기본 상태를 확인한 다음 구독과 사용자 설정을 복원합니다.

위 단계를 완료한 뒤에도 종료된다면 클라이언트 버전, 운영체제 버전, 프로세서 아키텍처, 코어 종류, 핵심 로그와 재현 절차를 저장하세요. 문제를 제출할 때는 구독 주소, 노드 인증 정보와 제어 인터페이스 키를 가리고 오류와 관련된 필드만 남기세요. 완전한 환경 정보가 있으면 클라이언트 인터페이스, mihomo 코어, 설정 생성기 또는 시스템 네트워크 구성 요소 중 어디에서 문제가 발생했는지 판단하는 데 도움이 됩니다.