Clash 클라이언트가 열리지 않을 때: 시작 충돌·강제 종료 문제 해결 방법

먼저 문제가 시작 과정의 어느 단계에서 발생하는지 확인하세요

Clash 그래픽 클라이언트는 프로그램 하나만 실행하는 방식으로 시작되지 않습니다. 일반적으로 데스크톱 셸이 먼저 인터페이스를 불러오고, 앱 설정과 구독 설정을 읽은 다음 Clash Meta（mihomo）커널을 시작합니다. 마지막으로 프록시 포트, 컨트롤 포트, 선택한 TUN 가상 네트워크 인터페이스를 연결합니다. 어느 단계에서든 실패하면 “눌러도 반응이 없음”, “창이 나타났다가 바로 사라짐”, “인터페이스는 열리지만 커널이 계속 시작되지 않음”과 같은 증상으로 나타날 수 있습니다.

점검하기 전에 기존 프로세스를 완전히 종료하세요. Windows에서는 「작업 관리자」→「세부 정보」에서 클라이언트 프로세스와 mihomo.exe를 종료하고, macOS에서는 「활성 상태 보기」에서 클라이언트 이름과 mihomo를 검색하세요. Linux에서는 ps로 남아 있는 프로세스를 확인할 수 있습니다. 트레이 아이콘이 사라졌다고 백그라운드 프로세스까지 반드시 종료된 것은 아닙니다. 시작 버튼을 연속으로 누르면 두 번째 인스턴스가 실행되어 새로운 포트 충돌이 발생할 수 있습니다.

문제 원인 파악에 필요한 파일부터 보존하세요

초기화하기 전에 구독 설정, 직접 작성한 YAML, 규칙 세트와 로그를 복사해 두세요. 클라이언트 인터페이스에 들어갈 수 있다면 「설정」→「설정 파일 폴더」와 「설정」→「로그」를 차례로 확인하세요. 인터페이스가 열리지 않으면 시스템 사용자 데이터 폴더에서 찾아야 합니다. Windows의 일반적인 위치는 %APPDATA% 또는 %LOCALAPPDATA%이고, macOS는 ~/Library/Application Support/, Linux는 ~/.config/입니다. 클라이언트마다 폴더 이름이 다르므로 한 클라이언트의 전체 폴더를 다른 클라이언트에 그대로 덮어쓰면 안 됩니다.

1순위: 포트 충돌과 중복 프로세스부터 배제하세요

Clash 설정에서는 7890을 HTTP 또는 mixed 프록시 포트로, 7891을 SOCKS 포트로, 9090을 외부 컨트롤 포트로 사용하는 경우가 많습니다. 하지만 이는 흔한 예일 뿐 고정된 값은 아닙니다. 이전 버전의 Clash, 다른 프록시 클라이언트, 개발 서버 또는 종료되지 않은 mihomo가 같은 포트를 점유할 수 있습니다. 커널 로그에는 보통 address already in use, bind 또는 “하나의 소켓 주소만 사용할 수 있습니다”와 같은 메시지가 표시됩니다.

Windows 확인 방법

PowerShell 또는 명령 프롬프트를 열고 자주 사용하는 세 포트를 각각 확인하세요. 마지막 열의 값은 프로세스 PID이며, tasklist로 해당 프로그램을 조회할 수 있습니다:

netstat -ano | findstr :7890
netstat -ano | findstr :7891
netstat -ano | findstr :9090
tasklist /FI "PID eq 4321"

PID가 더 이상 사용하지 않는 이전 인스턴스에 해당하는지 확인한 뒤에는 먼저 해당 프로그램의 종료 메뉴를 이용하세요. 정상적으로 종료되지 않을 때만 「작업 관리자」→「세부 정보」에서 작업을 종료합니다. 포트를 수신 중이라는 이유만으로 시스템 프로세스를 바로 종료하지 마세요. 다른 필수 서비스가 해당 포트를 사용하도록 설정했을 수도 있습니다.

macOS 및 Linux 확인 방법

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

포트가 실제로 다른 프록시 도구에 속한다면 해당 도구를 종료하거나 Clash의 현재 설정을 변경할 수 있습니다. 예를 들어 mixed 포트를 7890에서 17890으로, 컨트롤 포트를 9090에서 19090으로 임시 변경하세요. 변경 후에는 시스템 프록시 설정, 브라우저 확장 프로그램, 로컬 네트워크 기기가 새 포트에 연결되어 있는지도 함께 확인해야 합니다.

mixed-port: 17890
external-controller: 127.0.0.1:19090
allow-lan: false
mode: rule

2순위: YAML 설정과 구독 내용을 확인하세요

구독 업데이트, 규칙 편집 또는 설정 전환 직후 문제가 발생했다면 설정 파싱 오류일 가능성이 높습니다. YAML은 들여쓰기로 계층을 표현하므로 Tab 문자, 빠진 콜론, 목록 앞의 하이픈 누락, 따옴표로 감싸지 않은 특수 문자가 있으면 커널이 로딩 단계에서 멈출 수 있습니다. 로그에는 보통 yaml, unmarshal, mapping values 또는 특정 줄 번호가 표시됩니다.

mihomo로 설정을 직접 검증하세요

mihomo 실행 파일의 위치를 알고 있다면 터미널에서 설정 테스트를 실행할 수 있습니다. -t는 설정 테스트를 의미하고, -f 뒤에는 파일 경로를 입력합니다. 경로에 공백이 있으면 따옴표로 감싸세요:

mihomo -t -f "C:\Users\Public\Documents\clash\config.yaml"

macOS와 Linux도 같은 방식으로 입력하고 경로만 바꾸면 됩니다:

./mihomo -t -f "$HOME/.config/mihomo/config.yaml"

테스트가 통과하면 보통 설정 초기화가 완료되었다는 메시지가 출력됩니다. 실패하면 문제가 있는 필드나 줄·열 위치가 표시됩니다. 가장 먼저 나타난 오류부터 수정하세요. 이후 오류는 첫 번째 들여쓰기 문제로 인해 연쇄적으로 발생했을 수 있습니다.

시작 실패를 일으키기 쉬운 작성 오류

• 들여쓰기 방식 혼용: 같은 계층에서는 공백 수를 일관되게 유지하세요. 편집기는 Tab 대신 공백을 삽입하도록 설정해야 합니다.
• 존재하지 않는 프록시 그룹 참조:rules가 가리키는 정책 이름은 proxy-groups 안에서 찾을 수 있어야 합니다. 이름에 공백이 포함되어 있다면 완전히 동일하게 작성하세요.
• 중복된 노드 이름: 구독을 수동으로 합친 뒤 여러 proxies 항목이 같은 이름을 사용하면 참조 관계에 문제가 생길 수 있습니다.
• 필드 타입 오류:port는 숫자여야 하고 allow-lan은 불리언 값이어야 합니다. 서로 다른 구조의 목록이나 객체로 작성하면 안 됩니다.
• 잘못된 규칙 순서:MATCH는 규칙 목록의 마지막에 배치해야 합니다. 보통 문법 오류를 일으키지는 않지만 뒤에 있는 규칙이 영원히 매칭되지 않습니다.
• provider 파일 문제: 기본 설정을 파싱할 수 있어도 참조된 프록시·규칙 집합을 반드시 읽을 수 있다는 뜻은 아닙니다. 다운로드 실패, 경로 변경, 파일 형식도 확인해야 합니다.

가장 빠른 격리 방법은 최소 설정으로 커널을 시작하는 것입니다. 아래 설정에는 노드와 구독이 포함되지 않으며, 커널이 설정을 파싱하고 로컬 포트에서 수신 대기할 수 있는지만 확인하는 용도입니다:

mixed-port: 17890
mode: direct
log-level: info
allow-lan: false

proxies: []
proxy-groups: []
rules:
  - MATCH,DIRECT

최소 설정은 시작되지만 원래 설정이 시작되지 않는다면 문제는 원본 YAML, 구독 생성 내용 또는 외부 provider에 있습니다. 최소 설정도 실패한다면 포트, 권한, 커널 자체를 계속 확인하세요. 테스트할 때는 원본 파일의 복사본을 보관하고, 유일한 구독 설정을 최소 설정으로 덮어쓰지 마세요.

3순위: 권한, 서비스 모드, TUN 시작 실패를 처리하세요

일반 시스템 프록시는 주로 로컬 TCP 포트만 수신하므로 필요한 권한이 적습니다. 반면 TUN 모드는 가상 네트워크 인터페이스 생성, 라우팅 테이블과 DNS 변경이 필요해 권한 문제가 더 자주 발생합니다. 대표적인 증상은 클라이언트 인터페이스와 시스템 프록시는 정상인데 「설정」→「TUN 모드」를 켜면 커널이 종료되고, 로그에 permission denied, operation not permitted, failed to set route 또는 가상 인터페이스 생성 실패가 나타나는 경우입니다.

Windows: 먼저 서비스 모드를 확인하세요

1. 클라이언트의 「설정」→「서비스 모드」 또는 「시스템 서비스」로 이동해 서비스가 설치되어 있고 실행 중인지 확인하세요.
2. 서비스 설치에 실패하면 클라이언트를 완전히 종료한 뒤 마우스 오른쪽 버튼 메뉴에서 “관리자 권한으로 실행”을 선택하세요. 서비스 설치 또는 복구에만 사용해야 합니다.
3. services.msc를 열고 해당 클라이언트 서비스의 상태를 확인하세요. 서비스 이름은 클라이언트마다 다르므로 인터페이스에 표시되는 안내를 기준으로 판단해야 합니다.
4. 서비스를 복구한 뒤에는 클라이언트를 일반 사용자 권한으로 다시 시작하고 TUN을 테스트하세요. 데스크톱 인터페이스를 장기간 관리자 권한으로 실행하는 것은 피해야 합니다.

이전 클라이언트를 제거한 뒤 유사한 서비스가 남아 있으면 새 클라이언트가 자체 서비스를 등록하지 못할 수 있습니다. 이 경우 먼저 이전 클라이언트가 제공하는 서비스 제거 기능을 사용한 다음 현재 클라이언트의 서비스 구성 요소를 설치하세요. 이름만 보고 시스템 네트워크 드라이버를 일괄 삭제하면 VPN, 가상 머신, 컨테이너 네트워크에 영향을 줄 수 있습니다.

macOS: 네트워크 확장과 시스템 권한을 확인하세요

TUN 또는 시스템 확장 기능을 처음 켤 때 macOS에서 관리자 확인을 요구할 수 있습니다. 「시스템 설정」→「개인정보 보호 및 보안」에서 시스템이 차단한 구성 요소 안내를 확인하고, 「시스템 설정」→「네트워크」→「VPN 및 필터」에서 관련 네트워크 구성을 확인하세요. 앱을 “응용 프로그램” 폴더로 옮긴 뒤 실행하면 임시 마운트 폴더에서 실행할 때 발생하는 경로·권한 변화를 줄일 수 있습니다.

Linux: 실행 권한과 네트워크 기능을 확인하세요

AppImage는 처음 실행하기 전에 실행 권한이 필요합니다. 파일 관리자 속성 창에서 설정하거나 다음 명령을 실행할 수 있습니다:

chmod +x ./Clash-Client.AppImage
./Clash-Client.AppImage

TUN에 필요한 권한은 클라이언트의 서비스 설계에 따라 다릅니다. 일부 클라이언트는 systemd 서비스로 mihomo를 관리하고, 다른 클라이언트는 네트워크 기능을 별도로 설정해야 합니다. 장기간 전체 그래픽 인터페이스를 root로 실행하기보다 클라이언트에 내장된 서비스 설치 메뉴를 우선 사용하세요. 로그에 /dev/net/tun이 없다고 표시되면 시스템이 TUN 장치를 제공하는지 먼저 확인할 수 있습니다:

ls -l /dev/net/tun
ip tuntap list
systemctl status NetworkManager

4순위: 커널 파일과 버전 불일치를 해결하세요

그래픽 클라이언트와 mihomo 커널은 서로 다른 계층입니다. 인터페이스 업데이트가 성공했다고 해서 커널 파일까지 올바르게 교체된 것은 아닙니다. 보안 프로그램의 격리, 디스크 쓰기 중단, 이전 프로세스의 파일 잠금, 다른 아키텍처의 바이너리를 수동으로 교체한 경우 등으로 “커널 시작” 단계가 실패할 수 있습니다. 로그에는 파일을 찾을 수 없음, 실행 거부, 비정상 프로세스 종료 코드 또는 x64 시스템에서 ARM64 빌드를 사용했다는 문제가 나타날 수 있습니다.

시스템 아키텍처 확인

• Windows에서는 「설정」→「시스템」→「시스템 정보」→「시스템 종류」에서 x64 또는 ARM64를 확인합니다.
• macOS에서는 「Apple 메뉴」→「이 Mac에 관하여」에서 칩을 확인합니다. Apple 칩은 arm64, Intel 프로세서는 x64에 해당합니다.
• Linux에서는 uname -m을 실행하세요. x86_64는 x64, aarch64는 ARM64에 해당합니다.

클라이언트에 「설정」→「커널」→「다시 다운로드」 또는 「업데이트 확인」 메뉴가 있다면 먼저 내장 기능을 사용하세요. 인터페이스가 열리지 않으면 시스템 아키텍처에 맞는 전체 클라이언트 패키지를 다시 설치할 수 있습니다. 설치하기 전에 클라이언트와 mihomo를 종료해 교체 중인 파일을 이전 프로세스가 점유하지 않도록 하세요. 커널 파일만 복사할 때는 클라이언트가 지원하는 API와 설정 필드도 고려해야 합니다. 버전 차이가 너무 크면 인식할 수 없는 필드가 생길 수 있습니다.

mihomo는 터미널에서 버전을 직접 확인할 수 있습니다. 버전 정보가 정상적으로 출력되면 최소한 파일을 실행할 수 있다는 뜻입니다:

mihomo -v

터미널에 형식 오류나 실행 불가 메시지가 표시되면 먼저 아키텍처를 확인하세요. 파일이 없다는 메시지가 나오면 클라이언트 설정에 기록된 커널 경로를 확인합니다. 프로세스가 시작 직후 종료되면 최소 설정으로 실행해 “커널 자체 문제”와 “설정 로딩 문제”를 분리해서 확인하세요.

5순위: 시스템 구성 요소를 보완하고 앱 데이터를 초기화하세요

일부 Windows 클라이언트는 WebView2로 인터페이스를 표시하고, 다른 클라이언트는 Electron 또는 별도의 데스크톱 런타임을 사용합니다. 창이 전혀 나타나지 않거나 인터페이스가 투명하게 보이고 이벤트 뷰어에 WebView 로딩 실패가 기록되면 「설정」→「앱」→「설치된 앱」에서 Microsoft Edge WebView2 Runtime이 설치되어 있는지 확인하세요. 클라이언트 설치 안내에 Visual C++ 2015–2022 Redistributable이 명시되어 있다면 앱 아키텍처에 맞는 x64 또는 ARM64 버전도 설치해야 합니다.

Windows의 「이벤트 뷰어」→「Windows 로그」→「응용 프로그램」에서 강제 종료 시점의 오류를 확인할 수 있습니다. “오류가 발생한 응용 프로그램 이름”, “오류가 발생한 모듈 이름”, 예외 코드를 중점적으로 기록하세요. 오류 모듈이 클라이언트 자체 실행 파일을 가리키면 클라이언트를 먼저 재설치하고, WebView나 시스템 런타임을 가리키면 해당 구성 요소를 먼저 복구하세요.

앱 데이터를 안전하게 초기화하세요

포트, 설정, 권한, 커널, 런타임이 모두 정상인데도 클라이언트가 로딩 화면에서 계속 강제 종료된다면 새 앱 데이터 폴더로 테스트해 보세요. 프로그램을 완전히 종료하고 기존 데이터 폴더 이름에 날짜가 포함된 백업 이름을 붙입니다. 예를 들어 clash-client를 clash-client-backup-20260818으로 변경한 뒤 다시 시작하세요. 클라이언트가 초기 데이터 세트를 새로 생성합니다.

1. 새 데이터 폴더에서 시작됨: 기존 폴더의 인터페이스 설정, 데이터베이스 또는 캐시에 문제가 있을 수 있습니다.
2. 새 데이터 폴더에서도 강제 종료됨: 설치 파일, 시스템 구성 요소 또는 그래픽 카드 렌더링 계층의 문제일 가능성이 큽니다.
3. 구독을 복원할 때는 설정 파일만 가져오고 기존 폴더 전체를 곧바로 덮어쓰지 마세요.
4. 항목을 하나 복원할 때마다 한 번씩 재시작하면 어떤 파일이 문제를 다시 불러오는지 확인하기 쉽습니다.

업데이트 후 문제가 발생했다면 포터블 버전과 설치 버전이 함께 남아 있는지도 확인하세요. 두 복사본이 서로 다른 데이터 폴더를 사용하면서 같은 포트와 시스템 프록시 설정을 공유할 수 있습니다. 실제로 사용할 설치본 하나만 남기고 오래된 바로 가기를 정리한 다음, 「작업 관리자」→「시작 앱」에서 현재 클라이언트만 시작 프로그램으로 설정되어 있는지 확인하세요.

증상별 전체 복구 순서

상황 1: 아이콘을 클릭해도 창이 전혀 보이지 않음

1. 10초간 기다린 뒤 작업 관리자 또는 활성 상태 보기에서 프로세스가 존재하는지 확인하세요.
2. 클라이언트와 mihomo의 남은 프로세스를 종료한 다음 한 번만 다시 시작하세요.
3. 시스템 이벤트 로그를 확인해 WebView2, 런타임 또는 앱 모듈 오류인지 판단하세요.
4. 앱 데이터 폴더 이름을 바꿔 백업하고 초기 데이터로 시작하세요.
5. 그래도 실패하면 x64 또는 ARM64 아키텍처에 맞는 클라이언트를 다시 설치하세요.

상황 2: 인터페이스는 열리지만 커널이 계속 “중지”로 표시됨

1. 「로그」 페이지에서 가장 먼저 나타난 error 기록을 확인하세요. 마지막 줄만 보지 마세요.
2. 7890, 7891, 9090 또는 설정에 지정된 실제 포트를 확인하세요.
3. mihomo -t -f로 현재 YAML을 검증하세요.
4. mixed 포트가 17890으로 설정된 최소 설정으로 테스트하세요.
5. mihomo -v를 실행해 커널 파일과 시스템 아키텍처를 확인하세요.

상황 3: TUN 모드만 열리지 않음

1. 먼저 TUN을 끄고 일반 시스템 프록시가 시작되는지 확인하세요.
2. Windows에서는 클라이언트 서비스 모드를 복구하고, macOS에서는 네트워크 확장을 확인하며, Linux에서는 /dev/net/tun을 확인하세요.
3. 다른 VPN, 가상 네트워크 인터페이스 도구, 두 번째 프록시 클라이언트를 종료한 뒤 다시 테스트하세요.
4. 로그의 라우팅, DNS, 인터페이스 오류를 확인하고 구체적인 인터페이스 이름을 기록하세요.
5. 서비스를 복구한 뒤 시스템을 다시 시작하고 네트워크 연결을 가로채는 도구는 하나만 활성화하세요.

상황 4: 구독 업데이트 직후 강제 종료되거나 커널이 종료됨

1. 이전에 정상 작동하던 설정으로 되돌리고 구독 자동 업데이트를 일시 중지하세요.
2. 새 YAML의 들여쓰기, 필드 타입, 프록시 그룹 참조를 확인하세요.
3. 기본 설정, proxy provider, rule provider를 각각 테스트하세요.
4. 실패한 임시 다운로드 파일을 삭제한 뒤 다시 한 번 업데이트하세요.
5. 구독으로 생성된 필드를 현재 mihomo 버전이 지원하는지 확인하세요.

정상 시작 후 프록시 상태를 확인하세요

클라이언트가 열린다고 네트워크 연결 가로채기까지 복구된 것은 아닙니다. 시작에 성공한 뒤 먼저 로그에서 설정 로딩 완료와 프록시 포트 수신 대기를 확인하고, 「프록시」 페이지에서 프록시 그룹을 선택하세요. 그런 다음 「설정」→「시스템 프록시」에서 시스템 프록시를 켜거나, 서비스 상태가 정상인 것을 확인한 뒤 TUN을 별도로 활성화합니다. 설정, DNS, TUN, 규칙 모드를 동시에 변경하지 마세요. 새 문제가 발생했을 때 무엇이 원인이었는지 추적하기 어려워집니다.

먼저 직접 연결되는 사이트와 프록시 규칙이 필요한 사이트에 각각 접속해 로그의 규칙 매칭과 프록시 그룹 이름을 확인하세요. 인터페이스는 정상인데 모든 요청이 실패한다면 클라이언트를 계속 재설치하기보다 노드 상태, 구독 유효 기간, DNS 확인, 규칙 매칭을 점검해야 합니다.