문제 해결
예상 읽기 시간 12분

Clash 클라이언트 실행 직후 종료되는 문제 해결 체크리스트: 포트 충돌·설정 오류·권한 문제별 해결법

실행 충돌의 주요 원인인 포트 충돌, YAML 문법 오류, 손상된 커널 파일, 부족한 시스템 권한, 잔여 프로세스 충돌을 빈도순으로 정리하고 확인·해결 방법을 안내합니다.

먼저 창이 닫힌 것인지 Clash 커널 실행에 실패한 것인지 구분하세요

“더블 클릭해도 창이 나타나지 않음”, “창이 1초 후 사라짐”, “트레이 아이콘은 있지만 인터넷에 연결되지 않음”은 비슷해 보이지만 실제로는 서로 다른 계층의 문제입니다. Clash 그래픽 클라이언트는 일반적으로 UI 프로세스, Clash Meta(mihomo) 커널, 시스템 프록시 또는 TUN 서비스로 구성됩니다. UI 프로세스가 종료되면 클라이언트 자체 문제이고, UI는 유지되지만 커널이 반복해서 중지되면 설정·포트·커널 파일을 확인해야 합니다. 커널은 정상적으로 실행되는데 네트워크에 접속할 수 없다면 클라이언트를 계속 재설치하기보다 시스템 프록시, DNS, 규칙, TUN을 점검하세요.

문제 해결을 시작하기 전에 “시작 시 자동 실행”과 “자동 실행(무음)”을 잠시 끄세요. 클라이언트 화면에 잠시라도 진입할 수 있다면 「설정」→「일반」에서 시작 시 자동 실행을 끄고, 「도구」 또는 「로그」 화면에서 최근 실행 기록을 복사하세요. 클라이언트마다 메뉴 이름은 조금씩 다르지만 「설정」→「로그」, 「도구」→「앱 로그」, 「커널」→「실행 로그」에서 확인할 수 있습니다. 종료 시각 전후의 마지막 20~50줄을 기록하는 것이 중요합니다.

증상 우선 확인할 항목 자주 표시되는 로그 키워드
창이 나타난 직후 사라짐 앱 권한, 사용자 디렉터리, UI 런타임 permission denied、access denied、panic
UI는 정상이나 커널 상태가 반복해서 중지됨 포트, YAML, 커널 파일 bind、parse、unmarshal、config error
TUN을 켠 후 종료됨 서비스 권한, 드라이버, 라우팅 충돌 tun、service、route、operation not permitted
재시작 후 이미 실행 중인 인스턴스가 있다고 표시됨 잔여 프로세스, 잠금 파일 already running、lock、address in use

첫 번째: 7890, 7891 및 컨트롤 포트가 사용 중인지 확인

포트 충돌은 커널 실행 실패의 가장 흔한 원인 중 하나입니다. 일반적인 설정에서는 HTTP 포트 7890, SOCKS5 포트 7891을 사용하거나 mixed-port: 7890으로 두 프록시 진입점을 통합합니다. 외부 컨트롤러 주소로는 보통 127.0.0.1:9090을 사용합니다. 이 숫자들이 강제 표준은 아니지만, 같은 기기에서 두 프로그램이 완전히 동일한 주소와 포트를 동시에 수신할 수는 없습니다.

Windows에서 포트 사용 여부 확인

현재 Clash 클라이언트를 완전히 종료한 다음 PowerShell 또는 명령 프롬프트를 열고 아래 명령을 차례로 실행하세요:

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

결과에 LISTENING이 표시되면 가장 오른쪽 숫자가 PID입니다. 예를 들어 127.0.0.1:7890에 해당하는 PID가 8420이라면 다음과 같이 프로세스를 조회할 수 있습니다:

tasklist /FI "PID eq 8420"

오래된 Clash, mihomo, 프록시 프로그램 또는 디버깅 서비스인지 확인한 뒤에는 먼저 원래 프로그램의 종료 메뉴로 정상 종료하세요. 해당 프로세스가 다른 작업을 수행하지 않는 것이 확실할 때만 다음 명령으로 종료하세요:

taskkill /PID 8420 /F

macOS 및 Linux에서 수신 프로세스 확인

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

Linux에서는 ss도 사용할 수 있습니다:

ss -lntp | grep -E ':7890|:7891|:9090'

두 클라이언트를 동시에 유지해야 한다면 한쪽 클라이언트의 「설정」→「네트워크」→「포트」에서 수신 포트를 변경하세요. 예를 들어 mixed 포트를 7897, 컨트롤 포트를 9097로 바꿀 수 있습니다. 변경 후에는 운영체제의 프록시 설정도 함께 확인해 시스템이 여전히 이전 주소인 127.0.0.1:7890을 가리키지 않도록 하세요.

두 번째: YAML 설정 오류와 구독 문제를 분리해 확인

Clash Meta는 실행 단계에서 YAML을 파싱합니다. 들여쓰기 오류, 잘못된 필드 유형, 동일 레벨 키의 중복, 잘못된 규칙 형식 때문에 커널이 설정을 바로 거부할 수 있습니다. 로그에는 yaml: line 42, cannot unmarshal, proxy group not found, invalid mode 같은 메시지가 자주 나타납니다. 이때는 연쇄적으로 이어지는 후속 오류를 하나씩 처리하기보다 최초 설정 오류를 찾는 데 집중하세요.

최소 설정으로 커널이 독립적으로 실행되는지 확인

현재 설정을 먼저 백업한 뒤 로컬 수신과 직접 연결 규칙만 포함한 테스트 설정을 만드세요:

mixed-port: 7897
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups: []

rules:
  - MATCH,DIRECT

이 설정에는 구독 노드가 없으며 일상적인 프록시 용도로 사용하지 않습니다. 목적은 YAML 파싱, 포트 수신, 커널 프로세스가 정상적으로 실행을 완료하는지 확인하는 것입니다. 최소 설정이 실행된다면 문제는 원래 설정의 DNS, 노드, 프록시 그룹, 규칙 또는 오버라이드에 있을 가능성이 큽니다. 그래도 종료된다면 커널 파일, 디렉터리 권한, 잔여 서비스를 계속 확인하세요.

전체 내용을 한 번에 되돌리지 말고 구간별로 복원하세요

  1. 먼저 dns 블록을 복원하고 커널을 재시작한 뒤 현재 mihomo 버전이 해당 필드를 인식하는지 확인하세요.
  2. 그다음 proxies 또는 구독 제공자를 복원하고 노드 프로토콜 매개변수와 인증서 필드를 확인하세요.
  3. proxy-groups를 추가하고 그룹에서 참조하는 노드 이름, 제공자 이름, 다른 프록시 그룹이 실제로 존재하는지 확인하세요.
  4. 마지막으로 rules를 복원하되 규칙 세트 이름, 대상 프록시 그룹 이름, 마지막 MATCH 규칙을 특히 확인하세요.

YAML 들여쓰기는 계층만 표현하며, 공백 들여쓰기에 Tab 문자를 섞어서는 안 됩니다. 목록 항목의 하이픈 뒤에는 공백이 필요합니다. 예: - MATCH,DIRECT. 불리언, 숫자, 문자열의 유형도 임의로 바꾸면 안 됩니다. 콜론, 샵 또는 특수 문자가 포함된 일부 노드 이름은 따옴표로 감싸야 하며, 그렇지 않으면 샵 뒤의 내용이 주석으로 처리됩니다.

proxy-groups:
  - name: "수동 선택"
    type: select
    proxies:
      - DIRECT
      - "노드 A"

구독을 새로고침한 뒤 문제가 발생했다면 「설정」 페이지에서 마지막으로 정상 작동한 설정으로 되돌린 다음 자동 업데이트를 끄고 비교하세요. 구독 다운로드가 성공했다는 것은 서버가 콘텐츠를 반환했다는 뜻일 뿐, 그 콘텐츠가 파싱 가능한 Clash 설정이라는 의미는 아닙니다. 로그인 페이지, HTML 오류 페이지, 잘린 YAML이 반환되면 파일은 저장될 수 있지만 커널은 로드 단계에서 오류를 냅니다.

세 번째: mihomo 커널 파일과 시스템 아키텍처가 일치하는지 확인

그래픽 클라이언트가 열리더라도 커널 실행 파일이 정상적으로 작동한다는 뜻은 아닙니다. 업데이트 중단, 보안 정책에 의한 파일 격리, 잘못된 아키텍처의 수동 교체로 인해 “커널 실행”을 누르자마자 중지될 수 있습니다. Windows에서 흔한 아키텍처는 amd64와 arm64입니다. Apple 실리콘 Mac은 arm64, Intel Mac은 amd64를 사용합니다. Linux도 amd64, arm64 등 빌드를 구분해야 합니다.

클라이언트의 「설정」→「커널」 또는 「커널 관리」로 이동해 현재 표시된 커널 이름과 버전을 먼저 기록하세요. 예를 들어 로그에 mihomo v1.19.10 windows amd64가 표시되면 파일이 실행되어 버전 정보를 출력했다는 사실을 최소한 확인할 수 있습니다. 버전 정보조차 없고 로그에 “프로세스를 시작할 수 없음” 또는 “파일이 존재하지 않음”만 나타난다면 파일 경로와 실행 권한을 확인하세요.

클라이언트에 내장된 커널 관리 기능을 우선 사용하세요

커널을 수동으로 복사할 때는 파일 이름만으로 아키텍처를 판단하지 마세요. 잘못된 아키텍처는 Windows에서 “이 앱은 사용자 PC에서 실행할 수 없습니다”라는 메시지를 표시할 수 있고, Linux에서는 Exec format error가 발생할 수 있습니다. macOS에서 개발자 또는 격리 속성 때문에 차단된다는 메시지가 나타나면 파일 출처와 클라이언트 버전을 먼저 확인하고, 「시스템 설정」의 「개인정보 보호 및 보안」에서 실제 차단 기록을 확인하세요. 계속 더블 클릭하는 방법은 권장하지 않습니다.

네 번째: 권한, TUN 서비스 및 보호된 디렉터리 처리

일반적인 시스템 프록시는 보통 로컬의 높은 번호 포트만 수신하면 되지만, TUN 모드는 가상 네트워크 인터페이스 생성, 라우팅 변경 또는 시스템 서비스 호출이 필요하므로 더 높은 권한을 요구합니다. 대표적인 증상은 TUN을 끄면 클라이언트가 안정적인데 켜면 커널이 즉시 종료되는 경우입니다. 이때는 TUN을 별도의 변수로 두고 점검해야 합니다.

Windows: 앱 권한과 서비스 권한을 먼저 구분하세요

클라이언트를 마우스 오른쪽 버튼으로 클릭해 “관리자 권한으로 실행”하는 방법은 일회성 진단에 사용할 수 있지만 모든 문제의 정답으로 여겨서는 안 됩니다. 관리자 권한으로 실행했을 때 TUN이 정상 작동하고 일반 실행에서는 실패한다면 클라이언트의 「설정」→「TUN 모드」 또는 「서비스 모드」에서 시스템 서비스를 다시 설치하세요. 그런 다음 관리자 세션을 종료하고 일반 방식으로 다시 테스트하세요.

앱이 추가 쓰기 권한이 필요한 디렉터리에 설치되어 있지 않은지도 확인하세요. 클라이언트 실행 데이터는 C:\Program Files 아래의 읽기 전용 위치에 저장해서는 안 되며, 압축 파일 미리보기 창에서 직접 실행해서도 안 됩니다. 프로그램 전체를 사용자가 쓸 수 있는 디렉터리에 압축 해제한 뒤 실행하세요. 예를 들어 사용자 디렉터리 아래에 별도의 앱 폴더를 만들 수 있습니다.

macOS 및 Linux: 실행 권한과 네트워크 권한 확인

Linux에서 수동으로 배포한 커널에 실행 권한이 없으면 Permission denied가 바로 반환됩니다. 먼저 권한을 확인하세요:

ls -l ./mihomo
chmod u+x ./mihomo

이는 파일 실행 권한만 해결할 뿐 TUN 장치를 생성하는 데 필요한 권한까지 자동으로 부여하지는 않습니다. 데스크톱 클라이언트에서 TUN을 사용할 때는 클라이언트가 제공하는 서비스 설치 절차를 우선 이용하세요. systemd로 배포했다면 서비스 유닛의 사용자, 네트워크 권한, 작업 디렉터리, 설정 경로를 확인해야 합니다. 데스크톱 클라이언트를 실행하면서 동일한 포트를 수신하는 별도의 systemd 서비스를 함께 시작하지 마세요.

macOS에서는 「시스템 설정」→「개인정보 보호 및 보안」에서 차단된 시스템 확장 프로그램이나 앱 기록을 확인하고, 「시스템 설정」→「네트워크」에서 중복된 VPN 설정이 남아 있는지 점검하세요. 변경 후에는 클라이언트를 완전히 종료했다가 다시 시작해 이전 네트워크 확장 상태가 테스트에 영향을 주지 않도록 하세요.

다섯 번째: 잔여 프로세스, 잠금 파일 및 중복 시작 항목 정리

클라이언트 창이 사라진 뒤에도 mihomo 커널이나 시스템 서비스가 백그라운드에서 실행 중일 수 있습니다. 이 상태에서 다시 시작하면 새 인스턴스가 포트 충돌, 데이터베이스 잠금 또는 “이미 실행 중인 인스턴스” 문제를 만날 수 있습니다. Windows에서는 작업 관리자의 “세부 정보” 탭에서 클라이언트 주 프로세스, mihomo.exe, 이전 버전의 clash.exe를 확인하세요. macOS에서는 활성 상태 보기를 사용하고, Linux에서는 다음 명령을 실행할 수 있습니다:

ps -ef | grep -E 'mihomo|clash'
systemctl --user status mihomo
systemctl status mihomo

같은 프로그램이 시스템 서비스, 사용자 서비스, 데스크톱 시작 프로그램에 동시에 등록되어 있으면 로그인 시 2~3번 실행될 수 있습니다. 시작 방식은 하나만 남기세요. Windows에서는 「설정」→「앱」→「시작 프로그램」과 작업 관리자의 “시작 앱”을 확인할 수 있습니다. macOS에서는 「시스템 설정」→「일반」→「로그인 항목」을 확인하세요. Linux에서는 systemd 서비스와 데스크톱 환경의 자동 시작 디렉터리를 함께 점검해야 합니다.

모든 관련 프로세스가 종료된 것을 확인한 후에만 잠금 파일을 처리하세요. 커널이 실행 중일 때 데이터베이스, 캐시, 실행 디렉터리를 삭제하지 마세요. 클라이언트에 「실행 상태 초기화」 또는 「캐시 삭제」 버튼이 있다면 내장 기능을 우선 사용하세요. 사용자 데이터를 다시 만들어야 한다면 먼저 구독 주소, 로컬 YAML, 규칙 오버라이드, 앱 설정을 백업한 뒤 기존 디렉터리의 이름을 바꿔 보존하세요. 바로 영구 삭제하지 않는 것이 좋습니다.

여섯 번째: 정해진 순서대로 재현 가능한 점검 수행

실행 직후 종료되는 문제는 “설정 다섯 가지를 한꺼번에 변경하는” 순간 가장 쉽게 해결이 늦어집니다. 다음 순서는 위험이 낮고 확인하기 쉬운 항목부터 시작하며, 각 단계에서 변수 하나만 변경합니다:

  1. 클라이언트를 완전히 종료하고 UI, mihomo 또는 clash 프로세스가 남아 있지 않은지 확인하세요.
  2. 7890, 7891, 9090 등 실제 설정 포트를 확인하고 충돌하는 프로세스를 종료하거나 포트를 변경하세요.
  3. TUN, 시스템 서비스, 시작 시 자동 실행을 끄고 일반 mixed-port만 유지하세요.
  4. 최소 YAML을 로드하고 커널이 최소 30초 동안 안정적으로 실행되는지 관찰하세요.
  5. 커널 아키텍처와 버전을 기록한 뒤 클라이언트의 커널 관리 메뉴에서 한 번 다시 배포하세요.
  6. DNS, 노드, 프록시 그룹, 규칙을 구간별로 복원하고, 복원할 때마다 재시작 후 로그를 확인하세요.
  7. 마지막으로 시스템 프록시를 다시 켠 다음 TUN과 시작 시 자동 실행을 테스트하세요.

각 테스트마다 “작업, 결과, 마지막 오류 로그”를 기록하세요. 예: “포트를 7890에서 7897로 변경하고 최소 설정으로 60초간 정상 실행됨. 구독으로 되돌리자 184번째 줄 파싱 오류 발생”. 이런 기록이 있으면 문제를 막연히 클라이언트 버전 탓으로 돌리지 않고 설정 문제로 빠르게 좁힐 수 있습니다.

클라이언트를 재설치해야 하는 경우

UI 프로세스 자체가 열리지 않거나, 앱 파일이 누락되었거나, 내장 커널 관리로 복구할 수 없거나, 최소 설정에서도 사용자 데이터 디렉터리에서 계속 읽기·쓰기 오류가 발생할 때만 재설치가 합리적입니다. 재설치 전에 시스템 프록시와 TUN 서비스를 종료하고 필요한 설정을 백업한 뒤 기존 버전을 제거하세요. 설치 후에는 이전 데이터를 즉시 전부 가져오지 말고 기본 설정으로 한 번 실행한 다음, 파싱 가능 여부를 확인한 설정 하나만 가져오세요.

재설치가 필요하지 않은 경우

클라이언트 다운로드 Windows, macOS, Android, iOS, Linux