Clash 실행 직후 종료될 때 해결 방법: 시작 오류 로그 확인 및 복구 가이드

먼저 구분하세요: 창이 닫힌 건가요, 커널이 종료된 건가요, 클라이언트가 충돌한 건가요?

아이콘을 두 번 눌렀는데 창이 보이지 않는다고 해서 반드시 Clash가 종료된 것은 아닙니다. 데스크톱 클라이언트는 보통 그래픽 인터페이스, 프록시 커널, 선택적 백그라운드 서비스로 구성됩니다. 창이 트레이로 최소화됐을 수도 있고, 인터페이스는 정상 실행됐지만 설정 오류로 mihomo 커널이 종료됐을 수도 있습니다. 문제가 발생한 구성 요소부터 확인해야 불필요한 조치를 피할 수 있습니다.

1. 트레이 또는 메뉴 막대를 확인하세요. Windows에서는 작업 표시줄 오른쪽의 숨겨진 아이콘을 펼치고, macOS에서는 화면 상단의 메뉴 막대를 확인합니다. 아이콘이 보이면 먼저 “메인 창 표시”를 선택하고, 프로그램을 연달아 여러 번 실행하지 마세요.
2. 프로세스를 확인하세요. Windows에서는 “작업 관리자” → “세부 정보”, macOS에서는 “활성 상태 보기”, Linux에서는 시스템 모니터를 엽니다. 클라이언트 프로세스와 mihomo 같은 커널 프로세스가 실행 중인지 각각 확인하세요.
3. 문제가 시작된 시점을 기록하세요. 업데이트 직후 실행되지 않는다면 프로그램 환경, 구독 업데이트 후 종료된다면 설정, TUN 활성화 후 종료된다면 권한 문제를 우선 확인하세요.
4. 중복 실행을 종료한 뒤 다시 시도하세요. 먼저 트레이 메뉴에서 종료하고 프로세스가 끝났는지 확인하세요. 백그라운드 서비스가 계속 실행 중일 수 있으므로 창을 닫았다고 완전히 종료된 것은 아닙니다.

시작 로그 찾기: 운영체제별 확인 위치

인터페이스를 열 수 있다면 “설정”에서 “로그 폴더 열기”, “설정 폴더 열기” 또는 “앱 폴더” 메뉴를 먼저 찾아보세요. 인터페이스 로그에 커널 출력이 기록되는 경우가 많지만, 인터페이스 자체의 충돌 기록은 없을 수 있습니다. 아예 실행할 수 없다면 시스템 충돌 기록도 함께 확인해야 합니다.

Windows: “응용 프로그램 오류”만 보지 말고 오류 모듈도 확인하세요

Win + R을 누르고 eventvwr.msc를 입력한 다음 문제가 발생한 시각의 응용 프로그램 이벤트를 확인하세요. 이벤트 ID 1000은 응용 프로그램 충돌, 1001은 Windows 오류 보고 정보와 관련된 경우가 많습니다. 다만 이는 단서일 뿐 원인을 확정해 주지는 않습니다. “오류가 발생한 응용 프로그램 이름”, “오류가 발생한 모듈 이름”, “예외 코드”를 기록하고 클라이언트 로그와 대조하세요.

Linux 및 Android: 재현 가능한 출력 기록하기

Linux에서는 터미널에서 클라이언트의 실제 실행 파일을 실행할 수 있습니다. 사용자 단위 systemd 서비스를 사용한다면 최근 10분간의 로그를 먼저 확인하세요. 아래 Android 명령을 실행하려면 ADB가 설치되어 있고 USB 디버깅을 켠 뒤 컴퓨터를 승인해야 합니다. 문제를 재현한 직후 실행하는 것이 좋습니다.

# Linux: 사용자 세션 로그 확인
journalctl --user --since "10 minutes ago" --no-pager

# Android: 충돌 버퍼를 컴퓨터의 현재 폴더로 내보내기
adb logcat -b crash -d > clash-crash.txt

로그를 공유하기 전에 구독 URL의 토큰, 노드 비밀번호, UUID, 제어 인터페이스 키, 공개하고 싶지 않은 접속 도메인을 가리세요. 오류 전후 약 30줄만 공유하면 전체 설정 폴더를 올리는 것보다 문제를 찾기 쉽고 정보 노출도 줄일 수 있습니다.

원인 1: YAML 구문 오류 또는 커널과 호환되지 않는 설정

설정을 수정하거나 구독을 업데이트하거나 커널을 교체한 뒤 문제가 시작됐다면 yaml:, unmarshal, proxy group, not found 같은 로그를 먼저 찾아보세요. YAML 들여쓰기에는 공백을 사용해야 하며 Tab은 사용할 수 없습니다. 콜론 뒤에 공백이 없거나 목록 들여쓰기가 잘못된 경우에도 파싱에 실패합니다.

• 구문 오류: 로그에 line 18이 표시되면 18행과 그 앞의 몇 행을 확인하세요. 오류 위치는 파서가 더 이상 진행할 수 없게 된 지점일 뿐, 실제 문제가 시작된 곳이 아닐 수 있습니다.
• 참조 오류: 프록시 그룹이 존재하지 않는 노드 이름을 참조하거나, 규칙이 정의되지 않은 프록시 그룹 또는 규칙 세트를 참조하는 경우 설정의 의미상 오류입니다. 들여쓰기만 바꿔서는 해결되지 않습니다.
• 커널 호환성: Clash, Clash Premium, Clash Meta(현재 mihomo)는 지원하는 기능이 서로 다릅니다. 특정 프로토콜이나 설정 항목을 사용할 수 있는지는 인터페이스 브랜드만이 아니라 실제 실행 중인 커널과 버전에 따라 달라집니다.
• 잘못된 다운로드 내용: 만료된 구독 URL은 로그인 페이지나 오류 문구를 반환할 수 있습니다. 파일 첫 부분이 HTML로 바뀌지 않았는지 확인하고, 서버 오류 페이지를 YAML로 가져오지 마세요.

동일한 커널로 설정 테스트하기

구독에서 생성된 파일을 직접 수정하지 않도록 검사할 설정을 먼저 복사하세요. mihomo를 사용하는 클라이언트라면 실제 커널 실행 파일로 테스트할 수 있습니다. 설정에서 상대 경로 파일을 참조한다면 원래 작업 디렉터리도 지정해야 합니다. 다음은 Windows PowerShell 예시입니다. 실제 커널이 있는 폴더로 이동한 뒤 필요한 파일을 준비하세요.

.\mihomo.exe -v
.\mihomo.exe -t -d "C:\Clash-Debug" -f "C:\Clash-Debug\config.yaml"

-v는 버전 확인, -t는 설정 검사에 사용합니다. 설정 파일과 필요한 로컬 규칙 파일을 테스트 폴더에 넣고 실행하세요. 리소스가 없거나 원격 다운로드에 실패해도 테스트가 실패할 수 있으므로, 모든 실패를 YAML 들여쓰기 문제로 단정하지 마세요. 테스트 통과는 해당 검사 시점에 문제가 없었다는 뜻일 뿐 TUN 권한, 포트 바인딩, 네트워크 연결까지 정상임을 보장하지 않습니다.

원인 2: 7890 또는 제어 인터페이스 포트가 이미 사용 중

로그에 bind: address already in use가 표시되거나 Windows에서 “일반적으로 각 소켓 주소는 한 번만 사용할 수 있습니다”라는 메시지가 나오면 수신 포트를 확인하세요. 혼합 포트는 보통 7890, 제어 인터페이스 포트는 보통 9090이지만 둘 다 변경할 수 있으므로 현재 설정을 기준으로 확인해야 합니다. 포트 충돌은 대개 커널 시작을 막지만 그래픽 인터페이스까지 종료시키는 것은 아닙니다.

# Windows PowerShell: 실제 포트 번호로 수신 항목 필터링
Get-NetTCPConnection -State Listen -LocalPort 7890,9090 |
  Select-Object LocalAddress,LocalPort,OwningProcess

# macOS: 7890 TCP 수신 프로세스 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux: TCP 수신 포트 및 프로세스 목록 표시
ss -ltnp

Windows에서는 Get-Process -Id 프로세스 번호를 사용해 앞 단계에서 확인한 PID를 조회할 수 있습니다. 흔한 점유 원인은 다른 프록시 클라이언트, 이전 커널 프로세스 또는 아직 실행 중인 서비스입니다. 프로세스가 무엇인지 확인한 뒤 해당 프로그램에서 정상 종료하세요. 포트가 사용 중이라는 이유만으로 시스템 프로세스를 강제 종료하지 마세요.

1. 다른 프록시 클라이언트와 불필요한 백그라운드 서비스를 종료한 뒤 다시 실행하세요.
2. 두 프로그램을 동시에 실행해야 한다면 한쪽의 혼합 포트를 사용 중이 아닌 포트(예: 7897)로 변경하고 수신 상태를 다시 확인하세요.
3. 프록시를 수동으로 설정한 브라우저, 터미널, 로컬 네트워크 기기도 함께 수정하세요. 커널 포트만 바꾸고 앱의 프록시 주소를 바꾸지 않으면 “클라이언트는 실행되지만 앱에서 인터넷이 되지 않는” 문제가 생깁니다.

permission denied 또는 “허용되지 않는 액세스 권한으로 소켓에 액세스하려고 했습니다”라는 메시지는 포트 점유와 같은 뜻이 아닙니다. 시스템 예약 포트, 보안 정책 또는 바인딩 권한 문제일 수도 있으니 전체 오류 메시지를 확인하세요.

원인 3: 커널 파일 누락, 아키텍처 불일치 또는 불완전한 설치

no such file or directory, failed to spawn, exec format error가 표시되면 프로그램이 제대로 설치됐는지 먼저 확인하세요. 일부 배포판은 인터페이스와 커널을 별도로 두므로 주 프로그램만 복사하면 함께 제공되는 리소스나 보조 프로그램이 누락될 수 있습니다.

• 아키텍처 확인: Windows에서는 “설정” → “시스템” → “정보”에서 시스템 종류를, macOS에서는 “이 Mac에 관하여”에서 칩 정보를 확인하세요. Linux에서는 uname -m을 실행합니다. x86_64와 aarch64용 빌드는 서로 다르므로 임의로 바꿔 사용할 수 없습니다.
• 설치 방식 확인: 압축 파일은 고정된 폴더에 완전히 압축을 푼 뒤 실행하세요. macOS에서는 앱을 “응용 프로그램” 폴더로 복사해 실행하고, 디스크 이미지에서 계속 실행하지 마세요.
• 보안 소프트웨어 기록 확인: Windows에서 “Windows 보안” → “바이러스 및 위협 방지” → “보호 기록”을 엽니다. 파일 출처와 탐지 세부 정보를 먼저 확인하세요. 프로그램을 실행하려고 보안 기능 전체를 끄지는 마세요.
• 프로그램 파일 재설치: 프로젝트의 공식 배포 경로에서 운영체제에 맞는 설치 파일을 받으세요. 사용자 데이터는 먼저 보존하고, “프로그램 재설치”와 “설정 삭제”를 한 번에 처리하지 마세요.

Linux에서 “파일을 찾을 수 없음”이 표시되더라도 대상 파일이 실제로 존재한다면 동적 로더나 의존 라이브러리가 누락됐을 수 있습니다. 신뢰할 수 있는 출처의 바이너리는 file로 아키텍처를 확인한 다음 터미널에 표시된 의존성 오류를 해결하세요. 파일 크기가 정상이라는 이유만으로 실행에 문제가 없다고 판단하지 마세요.

원인 4·5: TUN 권한, 서비스 오류 및 런타임 누락

TUN을 켠 뒤에만 종료된다면 일반 프록시 모드로 먼저 테스트하세요

TUN은 가상 네트워크 어댑터를 만들고 라우팅을 설정하며, 일부 설정에서는 DNS도 처리합니다. 이러한 작업에는 보통 더 높은 권한이 필요합니다. TUN을 끄면 정상 실행된다면 구독을 계속 바꾸기보다 클라이언트의 “서비스 모드”나 권한이 필요한 보조 프로그램을 먼저 확인하세요.

1. 네트워크를 제어 중인 다른 VPN 또는 프록시 도구를 종료하고 클라이언트 하나만 실행해 테스트하세요.
2. 인터페이스를 열 수 있다면 TUN을 끄고 다시 시작해 일반 프록시가 작동하는지 확인하세요.
3. 현재 클라이언트에서 제공하는 설치 또는 복구 메뉴로 서비스를 처리하고, 서비스가 현재 설치 폴더를 가리키는지 확인하세요. 포터블 버전 폴더를 옮겼다면 기존 서비스가 이전 경로를 계속 참조할 수 있습니다.
4. macOS에서는 권한이 필요한 보조 프로그램의 승인을 확인하고, Linux에서는 서비스 로그에 권한 오류가 있는지 확인하세요. 설정 폴더 전체를 누구나 쓸 수 있게 바꾸거나, 문제를 감추려고 그래픽 인터페이스를 계속 root로 실행하지 마세요.

Android에서 VPN 권한을 거부했거나 다른 앱이 VPN 연결을 사용 중인 경우에는 보통 연결에 실패할 뿐 앱 프로세스가 충돌하지는 않습니다. 시스템 충돌 기록에서 앱 오류가 명확히 확인될 때만 실행 종료 문제로 계속 점검하세요.

창이 흰 화면으로 멈추거나 잠깐 나타났다가 사라진다면 인터페이스 런타임을 확인하세요

인터페이스 기술에 따라 필요한 구성 요소가 다릅니다. Tauri 기반 Windows 클라이언트는 보통 Microsoft Edge WebView2가 필요합니다. Electron 기반 클라이언트는 대개 자체 Chromium 환경을 포함하므로 모든 흰 화면 문제를 WebView2 탓으로 돌릴 수는 없습니다. 해당 클라이언트의 배포 안내에서 시스템 요구 사항을 확인한 뒤 Microsoft에서 제공하는 구성 요소를 설치하거나 복구하세요.

VCRUNTIME140.dll 또는 MSVCP140.dll이 없다는 메시지가 나오면 프로그램 요구 사항에 맞는 Microsoft Visual C++ Redistributable을 설치하고 아키텍처도 일치시키세요. DLL 다운로드 사이트에서 파일만 따로 받아 넣지 마세요. Linux에서 공유 라이브러리가 없다고 나오면 배포판과 프로젝트의 의존성 안내에 따라 해당 패키지를 설치하세요. 출처를 알 수 없는 라이브러리를 시스템 폴더에 복사해서도 안 됩니다.

안전하게 설정 초기화하기: 삭제보다 이름 변경으로 분리하세요

설정 검사로 원인을 찾지 못했거나 클라이언트 업데이트 후 이전 인터페이스 상태를 읽다가 충돌한다면 새 사용자 데이터로 확인할 수 있습니다. 이 과정에서 구독, 규칙 오버라이드, 프록시 그룹 선택, 단축키, 서비스, TUN 설정에 영향을 줄 수 있으므로 로그 확인 후 진행하세요.

1. 먼저 내보내거나 복사하세요. 구독 출처, 로컬 설정, 규칙 오버라이드, 스크립트와 클라이언트 설정을 저장하세요. 백업에 인증 정보가 들어 있다면 안전하게 관리할 수 있는 위치에 보관하세요.
2. 완전히 종료하세요. 트레이 프로세스를 종료하고 관련 커널도 멈췄는지 확인하세요. 서비스를 다뤄야 한다면 클라이언트에서 제공하는 서비스 관리 메뉴를 사용하세요.
3. 실제 사용자 데이터 폴더를 분리하세요. 현재 클라이언트가 사용하는 폴더가 맞는지 확인한 뒤 이름을 변경하세요. 예를 들어 뒤에 .backup-20261021을 붙일 수 있습니다. AppData나 .config 폴더 전체의 이름은 바꾸지 마세요.
4. 기본 상태로 실행하세요. 실행할 수 있다면 TUN은 켜지 말고, 정상 작동이 확인된 설정 하나만 가져와 실행과 종료를 확인하세요.
5. 항목별로 복원하세요. 구독, 규칙 오버라이드, 인터페이스 설정, TUN 순서로 하나씩 복원하고 매번 재시작하세요. 이전 폴더 전체를 다시 복사하면 문제도 함께 돌아올 수 있습니다.

새 데이터로 실행해도 계속 충돌한다면 프로그램 빌드, 실행 환경 또는 시스템 호환성을 중점적으로 확인해야 합니다. 이 경우 설정 초기화를 반복해도 대개 도움이 되지 않습니다. 백업을 보관하고 프로젝트 배포 안내에 따라 다른 호환 버전을 테스트하세요. 이전 버전이 새 버전의 데이터 폴더에 직접 기록하지 않도록 주의하세요.

문제 보고 전 확인할 항목

도움을 요청할 때는 “실행이 안 됩니다”라고만 하지 말고 재현할 수 있는 단계를 알려주세요. 다음 정보가 있으면 유지 관리자가 인터페이스, 커널, 시스템 환경 중 어디에 문제가 있는지 먼저 판단할 수 있어 추가 질문도 줄어듭니다.

• 클라이언트 이름과 전체 버전, 커널 이름과 버전, 운영체제 버전 및 CPU 아키텍처.
• 설치 파일 유형, 설치 폴더를 옮겼는지 여부, 이전 버전에서 업그레이드했는지 여부.
• “실행 후 2초 만에 종료” 또는 “TUN을 켠 직후 종료”와 같은 재현 절차를 적으세요. 관찰한 현상을 확인되지 않은 원인으로 단정하지 마세요.
• 문제가 발생한 시각, 관련 로그, 시스템 충돌 모듈, 설정 검사에서 나온 전체 오류.
• TUN을 끄거나 다른 클라이언트를 종료하거나 새 데이터 폴더를 사용했을 때 각각 어떤 결과가 나왔는지.

복구 후에는 시작부터 종료까지 다시 확인하세요. 메인 창이 반복해서 열리는지, 프록시 커널이 계속 실행되는지, 로컬 포트가 실제로 수신 중인지, 프록시를 수동 설정한 앱이 올바른 포트를 사용하는지, 정상 종료 후 시스템 프록시 설정이 남지 않는지 점검하세요. 이전에 TUN을 사용했다면 TUN도 별도로 켜고 끄며 확인하세요. 그래야 “창이 나타남”과 “프록시 연결이 정상 복구됨”을 구분할 수 있습니다.