Clash 실행 직후 종료될 때 해결 방법: 로그 확인 및 설정 롤백 가이드

1. 창 종료, 커널 종료, 연결 실패를 구분하세요

Clash를 실행한 뒤 창이 사라져도 원인이 하나라고 단정할 수는 없습니다. 데스크톱 클라이언트는 보통 그래픽 인터페이스와 프록시 커널, 그리고 선택적으로 서비스나 TUN 구성 요소로 이루어집니다. 인터페이스가 종료되어도 커널은 백그라운드에서 실행 중일 수 있고, 커널 실행에 실패해도 설정 창은 계속 열려 있을 수 있습니다. 먼저 어느 부분이 종료됐는지 확인한 다음 설정을 수정할지 설치 파일을 복구할지 결정하세요.

화면에 나타난 증상	먼저 확인할 항목	다음 단계
창은 닫혔지만 트레이 아이콘은 남아 있음	창을 닫을 때 트레이로 최소화하도록 설정했는지	트레이에서 다시 열어 프로세스가 실행 중인지 확인
창과 주 프로세스가 모두 사라짐	인터페이스 로그 및 시스템 충돌 보고서	오류 발생 시각과 예외 모듈 기록
인터페이스는 정상이나 커널이 계속 재시작됨	설정 파싱, 리스닝 포트, 커널 파일	커널 종료 직전의 첫 오류 확인
프로세스는 정상이나 웹사이트가 열리지 않음	시스템 프록시, DNS, 정책 그룹 선택	연결 문제로 진단하고 바로 재설치하지 않기

Windows에서는 Ctrl + Shift + Esc를 눌러 작업 관리자를 열고, ‘세부 정보’에서 클라이언트와 커널 프로세스를 확인하세요. macOS에서는 ‘활성 상태 보기’에서 해당 프로세스를 찾을 수 있습니다. 프로세스 이름은 클라이언트 패키징 방식에 따라 달라지므로 clash.exe가 있는지만으로 판단하지 마세요.

2. 로그 위치를 찾아 종료 직전 오류 기록 보존하기

인터페이스가 열리는 경우

먼저 클라이언트의 ‘로그’ 페이지를 확인하고, 설정에서 ‘설정 디렉터리’, ‘데이터 디렉터리’ 또는 ‘로그 디렉터리’라고 표시된 항목을 찾아보세요. 클라이언트마다 메뉴가 다르며 설치 디렉터리와 데이터 디렉터리는 같지 않을 수 있습니다. 디렉터리를 열고 수정 시간순으로 정렬해 이번 실행 시각에 해당하는 파일을 찾으세요. 인터페이스 로그와 커널 로그도 함께 보관하세요.

로그 수준은 일시적으로 info에서 debug로 높인 뒤, 한 번 재현하고 바로 원래대로 돌리세요. 디버그 로그에 접속 도메인, 노드 이름, 로컬 경로가 포함될 수 있으므로 문의를 보내기 전에 민감한 정보를 가려야 합니다. 커널이 아직 시작되지 않았다면 커널 로그 수준을 높여도 인터페이스 충돌 보고서는 생성되지 않습니다.

창이 전혀 열리지 않는 경우

Windows 데이터 디렉터리: Win + R을 누르고 %APPDATA%와 %LOCALAPPDATA%를 각각 열어 클라이언트 이름이나 앱 식별자로 디렉터리를 찾은 다음, 최근 수정된 로그를 확인하세요. 포터블 버전은 프로그램 옆의 데이터 폴더도 살펴보세요.
Windows 시스템 기록: Win + R을 누르고 eventvwr.msc를 입력한 다음 ‘Windows 로그’ → ‘응용 프로그램’에서 해당 시각의 Application Error를 확인하세요. perfmon /rel을 실행해 안정성 모니터를 열어도 됩니다.
macOS 충돌 보고서: Finder에서 ‘이동’ → ‘폴더로 이동’을 선택해 ~/Library/Logs/DiagnosticReports/를 여세요. 앱 로그는 ~/Library/Logs/ 아래의 클라이언트 디렉터리에 있을 수도 있습니다. 일부 보고서는 ‘콘솔’에서도 확인할 수 있습니다.
Linux 데스크톱 환경: 터미널에서 클라이언트의 실제 실행 파일을 실행하고 표준 오류 출력을 보관하세요. 사용자 서비스가 설치되어 있다면 먼저 systemctl --user --type=service로 서비스 이름을 확인한 뒤 해당 로그를 조회하세요.

마지막에 나온 ‘실행 실패’ 한 줄만 캡처하지 말고, 첫 오류 앞뒤 약 20줄을 복사하세요. 예를 들어 yaml: line 18은 설정 파싱 오류, address already in use는 리스닝 포트 충돌, permission denied는 권한이나 실행 제한을 가리킵니다. 마지막에 표시되는 재시도 메시지는 앞선 오류의 결과인 경우가 많습니다.

3. YAML 구문 오류: 실제로 불러온 설정 확인

구독을 업데이트하거나 규칙을 붙여 넣거나 Profile을 바꾼 직후 종료됐다면, 먼저 커널에 실제로 전달된 설정을 확인하세요. 클라이언트가 구독 설정과 로컬 오버라이드, 실행 매개변수를 합쳐 별도의 파일을 만들 수 있습니다. 다운로드한 구독 원문만 확인하면 병합 과정에서 생긴 문제를 놓칠 수 있습니다.

자주 발생하는 오류 네 가지 확인

들여쓰기: YAML은 공백으로 들여쓰며 Tab은 사용하지 않습니다. 같은 수준의 필드는 줄을 맞추고, 목록 항목의 하이픈 뒤에는 공백을 넣으세요.
문장 부호: 키 뒤에는 반각 콜론을 사용하세요. 노드 이름이나 비밀번호에 특수 문자가 포함되어 있다면 YAML 규칙에 따라 따옴표로 감싸야 합니다.
참조 이름: 규칙에서 참조하는 정책 그룹과 정책 그룹에서 참조하는 노드 또는 다른 그룹의 이름이 정의와 정확히 일치해야 합니다. 전각 괄호나 이름 끝의 공백도 서로 다른 이름으로 처리될 수 있습니다.
커널 호환성: Clash와 Clash Meta(현재 이름은 mihomo)는 지원하는 필드와 프로토콜 범위가 다릅니다. 설정 구문이 올바르더라도 현재 커널이 모든 설정 항목을 지원하는 것은 아닙니다.

클라이언트에서 mihomo를 사용한다면 동일한 커널 프로그램으로 설정을 테스트할 수 있습니다. 아래는 Windows PowerShell 예시입니다. 먼저 커널이 있는 디렉터리로 이동하고 검사할 파일을 현재 디렉터리에 config-check.yaml이라는 이름으로 복사하세요. 명령의 프로그램 이름은 실제 파일명에 맞춰야 합니다.

New-Item -ItemType Directory -Force .\check-data | Out-Null
.\mihomo.exe -t -d ".\check-data" -f ".\config-check.yaml"
$LASTEXITCODE

-t는 설정 테스트, -f는 설정 파일 지정, -d는 테스트 데이터 디렉터리 지정에 사용합니다. 테스트 중 GeoIP, GeoSite 또는 규칙 제공자 같은 리소스가 필요할 수도 있습니다. 오류가 리소스 누락을 가리킨다면 YAML 들여쓰기 오류와 구분해 해결하세요. 종료 코드가 0이면 이번 테스트가 통과했다는 뜻이지만, 포트 사용 가능 여부나 노드 연결, TUN 실행까지 보장하지는 않습니다.

4. 포트 충돌: 리스닝 프로세스를 확인한 뒤 포트 변경

일반적인 설정에서는 7890을 HTTP 또는 혼합 프록시 포트로, 7891을 SOCKS 포트로, 9090을 컨트롤러 포트로 사용하는 경우가 많지만 정해진 표준값은 아닙니다. 현재 설정의 port, socks-port, mixed-port, external-controller 값을 확인하세요. DNS 리스닝 포트도 충돌할 수 있습니다.

Windows: 리스닝 포트와 PID 확인

Get-NetTCPConnection -State Listen -LocalPort 7890,7891,9090 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

두 번째 명령의 1234는 예시 PID입니다. 실행하기 전에 앞 명령 결과의 OwningProcess 값으로 바꾸세요. 결과가 없다는 것은 조회한 TCP 포트가 그 시점에 리스닝 상태가 아니었다는 뜻일 뿐, UDP 포트 충돌까지 배제하는 것은 아닙니다.

macOS: 지정한 TCP 포트의 리스닝 상태 확인

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

점유 프로세스가 다른 클라이언트 인스턴스라면 해당 클라이언트의 트레이 메뉴에서 정상 종료한 뒤 중복된 시작 프로그램이 있는지 확인하세요.
다른 앱이 포트를 사용 중이라면 로컬 테스트 설정의 mixed-port를 일시적으로 17890으로 바꾸고 다시 시작해 확인하세요.
포트를 바꾼 뒤에는 시스템 프록시와 브라우저 자체 프록시 설정도 확인하세요. 커널 포트만 변경하면 시스템 프록시 주소가 이전 값인 127.0.0.1:7890을 계속 가리킬 수 있습니다.

정체를 알 수 없는 시스템 프로세스를 강제 종료하지 마세요. 오류를 없애려고 컨트롤러 포트를 외부에서 접근할 수 있는 주소로 설정해서도 안 됩니다. 로컬 전용 컨트롤러는 127.0.0.1:9090처럼 루프백 주소에 바인딩하세요.

5. 커널 파일 누락, 아키텍처 불일치, TUN 권한

로그에 ‘파일을 찾을 수 없음’, ‘실행할 수 없음’ 또는 ‘액세스 거부’가 표시되면 로그에 나온 커널의 전체 경로를 확인하세요. 프로그램 업데이트 중단, 보안 소프트웨어의 격리, 실행 파일만 복사하고 관련 파일을 빠뜨린 경우에는 인터페이스만 남고 커널이 시작되지 않을 수 있습니다.

아키텍처 확인: Windows에서는 ‘설정’ → ‘시스템’ → ‘시스템 정보’에서 시스템 종류를 확인하세요. macOS에서는 Apple 메뉴 → ‘이 Mac에 관하여’에서 칩을 확인하고, Linux에서는 uname -m을 실행하세요. 운영체제와 클라이언트 요구 사항에 맞는 설치 파일을 선택해야 합니다.
격리 기록 확인: Windows에서 ‘Windows 보안’ → ‘바이러스 및 위협 방지’ → ‘보호 기록’을 열어 해당 시각과 파일 경로를 확인하세요. 파일 출처와 이벤트 세부 정보를 먼저 확인한 뒤 설치 복구 여부를 결정하고, 시스템 보호 기능을 일괄 해제하지 마세요.
전체 디렉터리 보존: 포터블 패키지는 압축을 완전히 푼 뒤 실행하세요. 압축 파일 미리보기 창에서 바로 실행하거나 실행 파일 하나만 따로 옮기지 마세요.
TUN 분리 테스트: 일반 프록시 모드에서는 실행되지만 TUN을 켤 때만 실패한다면 노드 비밀번호를 계속 수정하지 말고 서비스 상태, 시스템 권한, 가상 네트워크 어댑터 관련 로그를 먼저 확인하세요.

TUN은 플랫폼과 클라이언트 구현에 따라 추가 시스템 권한이나 서비스가 필요할 수 있습니다. 먼저 TUN 자동 활성화를 끄고 일반 프록시 모드에서 커널이 계속 실행되는지 확인하세요. 그런 다음 클라이언트가 제공하는 서비스 설치 또는 권한 부여 기능을 통해 TUN을 복구하세요. 일반 프록시가 작동해도 TUN의 DNS 및 라우팅 설정까지 올바르다는 뜻은 아닙니다.

6. 설정 롤백: 별도 복사본으로 기존 데이터 분리

재설치 후에도 계속 종료된다면 새 프로그램이 이전 데이터 디렉터리를 다시 읽는 경우가 많습니다. 롤백의 목적은 모든 데이터를 바로 삭제하는 것이 아니라, 원래 설정에서 문제가 재현되는지 비교할 수 있는 되돌릴 수 있는 테스트 환경을 만드는 것입니다.

단계별 롤백 순서

관련 프로세스 종료: 클라이언트를 정상적으로 종료하고 커널이 백그라운드에서 데이터를 계속 쓰지 않는지 확인하세요. 백그라운드 서비스가 실행 중이라면 클라이언트의 서비스 관리 기능을 이용하세요.
데이터 디렉터리 전체 백업: Profile, 구독 정보, 로컬 오버라이드, 규칙 파일과 인터페이스 설정을 보관하세요. 백업 이름은 clash-backup-2026-08-06처럼 지정할 수 있습니다. 백업에 구독 인증 정보가 포함될 수 있으므로 안전한 비공개 위치에 저장하세요.
이전 디렉터리 분리: 실제 데이터 경로를 확인한 뒤 이름을 바꿔 보관하세요. 일부 클라이언트는 포터블 모드나 별도 데이터 디렉터리를 지원합니다. 해당 클라이언트의 안내에 따라 테스트 환경을 만들고 다른 클라이언트의 실행 옵션을 그대로 적용하지 마세요.
최소 설정 만들기: 기존 구독 자동 가져오기, 자동 오버라이드, TUN을 끄고 설정 파싱과 로컬 리스닝만 확인하세요.
항목별 복원: 구독, 정책 그룹, 규칙, 로컬 오버라이드, TUN 순으로 복원하세요. 매번 한 항목만 복원하고 한 번 재시작한 뒤 결과를 기록하세요.

아래 설정은 해당 필드를 지원하는 Clash 또는 mihomo 커널의 테스트용입니다. 혼합 포트는 17890이며 모든 트래픽은 직접 연결되고 프록시 노드는 포함하지 않습니다. 별도의 로컬 파일로 저장하고 원래 구독 파일을 덮어쓰지 마세요. 이 포트도 사용 중이면 앞의 절차에 따라 비어 있는 포트로 바꾸세요.

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

proxies: []
proxy-groups: []

rules:
  - MATCH,DIRECT

이 설정으로 확인할 수 있는 것은 기본 실행 여부뿐이며 프록시 노드의 유효성은 검사할 수 없습니다. 이 설정에서는 계속 실행되지만 원래 설정을 복원하자마자 오류가 나면 원래 설정, 오버라이드 또는 종속 리소스에 원인이 있을 가능성이 큽니다. 이 설정으로도 실행되지 않는다면 설치 파일, 그래픽 인터페이스 실행 환경, 시스템 충돌 기록을 계속 확인하세요.

7. 복구 확인 및 문의 자료 준비

한 번 실행에 성공했다고 점검이 끝난 것은 아닙니다. 클라이언트를 연속으로 3회 재시작해 같은 오류가 더는 로그에 나타나지 않는지 확인하세요. 구독도 한 번 업데이트해 로컬 수정 사항이 원격 설정에 덮어쓰이지 않는지 살펴보세요. 마지막으로 실제 사용에 필요한 시스템 프록시와 TUN을 각각 복원해 따로 테스트하면 동시에 켰을 때 원인을 구분하기 어려운 상황을 피할 수 있습니다.

기본 실행: 창이 정상적으로 열리고 커널이 반복해서 재시작되지 않으며, 로그에 지속적인 파싱 또는 리스닝 오류가 없습니다.
리스닝 상태: 현재 설정 포트를 예상한 프로세스가 사용하고 있으며 시스템 프록시 포트도 실제 설정과 일치합니다.
설정 복원: 어떤 Profile과 로컬 오버라이드를 복원했는지 확인할 수 있고, 구독을 업데이트한 뒤에도 정상 실행됩니다.
TUN 복원: 필요한 경우에만 활성화하고 시스템 권한, DNS 확인, 라우팅이 모두 정상인지 점검합니다.

추가 문의가 필요하다면 클라이언트 전체 버전, 커널 버전, 운영체제 버전과 아키텍처, 문제 발생 시각, 첫 오류 앞뒤 로그, 최소 설정의 실행 여부를 함께 보내세요. 구독 URL, 노드 비밀번호, 컨트롤러 인증 키, 개인 디렉터리 이름은 가려야 합니다. 원인을 계속 확인할 수 있도록 필드 구조, 오류 줄 번호, 예외 유형은 남겨 두세요.

점검 순서는 종료된 구성 요소 확인, 첫 오류 확인, 실제 설정 테스트, 포트 확인, 커널 점검, 기존 데이터 분리로 진행하면 됩니다. 재설치가 필요하다면 먼저 다운로드 페이지에서 플랫폼 지원 여부를 확인하세요. 필드와 규칙 관계는 고급 설정에서, 기본 설정은 입문 가이드에서 확인할 수 있습니다.