Clash 실행 중 강제 종료 문제 해결: 설정 파일 오류, 포트 충돌 및 권한 문제

Clash 클라이언트를 실행한 직후 종료되는 현상은 대개 하나의 원인으로 발생하지 않습니다. 그래픽 인터페이스, mihomo 또는 Clash 코어, 설정 파일, 수신 포트와 TUN 구성 요소가 순서대로 초기화되며, 이 중 어느 단계에서든 실패하면 창이 잠깐 나타났다가 사라지거나 트레이 아이콘이 없어지고 프로세스가 몇 초 뒤 종료될 수 있습니다. 계속 더블클릭하는 것만으로는 새로운 정보를 얻기 어렵습니다. 먼저 어느 단계에서 종료되는지 판단하는 것이 올바른 접근입니다.

인터페이스 종료, 코어 종료와 백그라운드 잔류를 구분하세요

실행 문제는 먼저 증상에 따라 세 가지로 나눌 수 있습니다. 첫째, 창이 전혀 나타나지 않고 작업 관리자나 활성 상태 보기에도 프로세스가 없다면 애플리케이션 파일, 실행 권한과 시스템 보안 경고를 확인해야 합니다. 둘째, 인터페이스가 나타난 직후 닫히면 설정 불러오기 실패나 그래픽 인터페이스 자체의 데이터 손상이 흔한 원인입니다. 셋째, 창은 사라졌지만 백그라운드 프로세스가 남아 있다면 클라이언트가 트레이로 최소화된 상태이거나 기존 프로세스가 새 인스턴스에 필요한 포트를 점유했을 수 있습니다.

60초 안에 1차 판단하기

1. 점검 중 네트워크 트래픽이 작동하지 않는 포트로 계속 유입되지 않도록 시스템 프록시와 TUN 모드를 끄세요.
2. 작업 관리자, 활성 상태 보기 또는 시스템 모니터를 열고 이름에 Clash, mihomo 또는 해당 클라이언트 이름이 포함된 잔류 프로세스를 종료하세요.
3. 클라이언트를 다시 실행하고 프로세스가 유지되는 시간을 확인하세요. 2초 이내에 종료되면 실행 권한과 애플리케이션 파일을 먼저 확인하고, 2~10초 후 종료되면 설정과 포트를 우선 점검하세요.
4. 클라이언트 데이터 디렉터리의 로그를 확인하세요. 인터페이스가 잠시라도 열리면 「설정」→「로그」 또는 「설정」→「실행 로그」로 이동해 로그 수준을 잠시 info로 설정하세요.
5. 그래픽 인터페이스에 로그가 남지 않는다면 터미널에서 코어를 직접 실행하고 설정 테스트를 수행해 오류 출력을 창에 남기세요.

설정 파일 오류: 먼저 YAML을 테스트한 뒤 최소 설정으로 복구하세요

Clash와 mihomo는 수신 포트를 만들기 전에 YAML 설정을 읽습니다. 들여쓰기 오류, 필드 형식 오류, 불완전한 규칙 형식, 존재하지 않는 노드를 참조하는 프록시 그룹 때문에 코어가 바로 종료될 수 있습니다. 구독을 업데이트한 직후 문제가 시작됐거나 설정을 수동으로 수정한 뒤 실행되지 않는다면 설정 파일을 가장 먼저 확인해야 합니다.

자주 발생하는 YAML 오류

• Tab으로 들여쓰기. YAML에서는 공백을 사용하고 같은 수준의 필드는 동일한 들여쓰기를 유지해야 합니다.
• 콜론 뒤에 공백이 없음. 예를 들어 mixed-port: 7890을 mixed-port:7890으로 작성하는 경우입니다.
• 규칙에 정책 이름이 없음. 예를 들어 DOMAIN-SUFFIX,example.com만 작성하고 마지막 프록시 그룹을 누락한 경우입니다.
• proxy-groups에서 존재하지 않는 노드나 그룹 이름을 참조합니다. 특히 노드 이름을 바꾼 뒤 그룹 구성원을 함께 수정하지 않았을 때 발생합니다.
• 웹페이지에서 내용을 복사하는 과정에서 전각 문장 부호가 섞여 영문 콜론, 쉼표 또는 따옴표가 다른 문자로 바뀝니다.
• mihomo 전용 필드를 더 오래된 Clash 코어로 읽게 하면 코어가 현재 설정 구조를 인식하지 못합니다.

터미널에서 설정 테스트 실행

mihomo는 -t로 설정을 테스트하고 -f로 파일을 지정할 수 있습니다. Windows 사용자는 코어가 있는 디렉터리에서 PowerShell을 열고, macOS와 Linux 사용자는 터미널에서 해당 디렉터리로 이동하세요. 다음 명령은 설정만 테스트하며 프록시 서비스를 계속 실행하지 않습니다:

# Windows PowerShell
& ".\mihomo.exe" -t -f ".\profiles\config.yaml"

# macOS 또는 Linux
./mihomo -t -f ./profiles/config.yaml

# 구버전 Clash 코어를 사용하는 경우
./clash -t -f ./profiles/config.yaml

출력에 구체적인 줄 번호가 표시되면 해당 줄과 그 위 3~5줄을 먼저 확인하세요. YAML 파서는 다음 필드를 읽을 때 앞부분의 구조 오류를 알아채는 경우가 많으므로 오류가 표시된 줄이 실제 문제가 시작된 위치가 아닐 수 있습니다. 문법 테스트는 통과했지만 클라이언트가 계속 종료된다면 프록시 그룹이 비어 있거나 provider 다운로드가 실패했는지, 규칙 세트 경로를 읽을 수 있는지 등 실행 단계의 오류를 확인하세요.

최소 설정으로 문제 범위 좁히기

원본 파일을 계속 직접 수정하며 시도하지 마세요. 먼저 원래 설정을 복사한 뒤 포트, 모드와 빈 규칙만 포함한 임시 설정을 만드세요. 이 설정으로 코어가 기본 실행을 완료할 수 있는지 확인할 수 있습니다:

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups: []
rules:
  - MATCH,DIRECT

최소 설정으로 실행된다면 코어 파일과 기본 권한은 대체로 정상이며, 문제는 원래 구독이나 사용자 지정 구간에 집중되어 있습니다. 다음으로 dns, proxy-providers, rule-providers, tun 순서대로 한 구간씩 복원하고 매번 다시 테스트하세요. 최소 설정도 실행되지 않으면 포트, 권한과 코어 파일을 확인하세요.

7890 포트 충돌: 숫자만 바꾸지 말고 점유 프로세스를 찾으세요

mixed-port: 7890은 Clash가 7890에서 HTTP와 SOCKS 프록시 연결을 동시에 수신한다는 뜻입니다. 기존 인스턴스가 종료되지 않았거나 다른 프록시 프로그램이 실행 중이거나 시스템 서비스가 이미 해당 포트를 수신 중이면 새 코어가 address already in use, bind failed 또는 유사한 메시지를 표시합니다. 일부 그래픽 클라이언트는 오류를 화면에 표시하지 않아 실행 직후 종료된 것처럼 보일 수 있습니다.

Windows에서 7890 확인

PowerShell에서 다음 명령을 실행하세요. 첫 번째 명령은 포트를 점유한 프로세스 ID를 반환하고, 두 번째 명령은 해당 ID로 프로그램 이름을 확인합니다:

Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue
Get-Process -Id 4321

예시의 4321을 첫 번째 명령에 표시된 OwningProcess 값으로 바꾸세요. 시스템 기본 명령으로 수신 대기 항목을 확인할 수도 있습니다:

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

macOS와 Linux에서 7890 확인

lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -lntp | grep 7890

lsof는 macOS와 대부분의 Linux 환경에서 사용할 수 있고 ss는 Linux에서 흔히 사용됩니다. 점유자가 기존 Clash 또는 mihomo 프로세스인지 확인한 뒤 먼저 클라이언트에서 정상적으로 종료하세요. 종료되지 않을 때만 해당 PID를 끝내세요. 이름이 불분명한 시스템 서비스를 바로 종료하지 말고 실행 파일 경로와 용도를 먼저 확인해야 합니다.

다른 포트로 바꿀 때 세 곳을 함께 수정하세요

7890을 다른 프로그램에 할당해야 한다면 Clash의 mixed-port를 7893으로 바꿀 수 있지만 설정, 클라이언트 옵션과 시스템 프록시가 모두 일치해야 합니다:

1. 설정 파일에서 mixed-port: 7893으로 지정하세요.
2. 「설정」→「매개변수 설정」→「포트」로 이동해 혼합 포트가 7893으로 표시되는지 확인하세요.
3. 시스템 프록시를 다시 켜고 HTTP와 SOCKS 주소가 127.0.0.1:7893을 가리키는지 확인하세요.

7890 외에도 7891, 7892와 9090을 확인해야 합니다. 이전 설정에서는 7891을 SOCKS 포트, 7892를 리디렉션 포트, 9090을 외부 제어 인터페이스로 사용하는 경우가 많습니다. 필요한 수신 항목 중 하나라도 충돌하면 코어가 종료될 수 있습니다. 점검할 때는 현재 YAML에서 실제로 활성화된 포트를 기준으로 하세요.

TUN 모드 실행 실패: 드라이버, 서비스와 관리자 권한 확인

일반 시스템 프록시는 로컬 수신 포트만 필요하지만 TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅을 변경하며 DNS를 처리하므로 더 높은 권한이 필요합니다. TUN을 끄면 클라이언트가 안정적으로 실행되지만 「설정」→「네트워크」→「TUN 모드」를 켜자마자 종료된다면 문제는 대개 드라이버, 서비스 권한 또는 남아 있는 가상 네트워크 어댑터에 있습니다.

Windows: 서비스 모드와 Wintun 인터페이스 확인

• 먼저 클라이언트를 관리자 권한으로 한 번 실행해 서비스 또는 가상 네트워크 어댑터를 초기화하세요. 이후 관리자 권한이 필요한지는 클라이언트의 서비스 모드에 따라 달라집니다.
• 「장치 관리자」→「네트워크 어댑터」에서 경고 표시가 있는 Wintun, Mihomo 또는 Clash 가상 인터페이스가 있는지 확인하세요.
• 클라이언트에 「설정」→「서비스 모드」가 있다면 기존 서비스를 먼저 중지한 뒤 서비스를 다시 설치해 인터페이스 버전과 백그라운드 서비스 버전이 일치하도록 하세요.
• Windows의 Internet Connection Sharing 또는 다른 가상 네트워크 소프트웨어가 충돌하는 라우팅을 계속 다시 만들고 있지 않은지 확인하세요.

로그에 Access is denied 또는 operation requires elevation이 나타나면 현재 프로세스에 권한이 부족하다는 뜻입니다. device already exists가 나타나면 남은 인터페이스를 확인하세요. start tun failed만 표시되고 자세한 정보가 없다면 로그 수준을 debug로 바꿔 한 번 더 시도한 뒤 info로 되돌리세요. 장기간 대량의 로그가 생성되는 것을 막을 수 있습니다.

macOS: 네트워크 확장 권한 확인

macOS 클라이언트에서 처음 TUN을 활성화할 때 보조 서비스 설치나 네트워크 확장 허용을 요청할 수 있습니다. 「시스템 설정」→「개인정보 보호 및 보안」을 열어 하단에 확인 대기 중인 시스템 소프트웨어 안내가 있는지 확인한 다음 「시스템 설정」→「네트워크」→「VPN 및 필터」에서 해당 구성이 반복 연결 상태인지 확인하세요. 클라이언트 업데이트 후 보조 서비스 버전이 동기화되지 않았다면 이전 보조 프로그램을 수동으로 복사하지 말고 클라이언트 설정에서 서비스를 다시 설치하세요.

Linux: TUN 장치와 권한 확인

먼저 시스템에 /dev/net/tun이 있는지 확인한 다음 현재 계정에 인터페이스 생성 및 라우팅 변경 권한이 있는지 점검하세요:

ls -l /dev/net/tun
ip tuntap list
ip route
getcap ./mihomo

터미널에서 직접 실행할 때 네트워크 관리 권한이 없으면 operation not permitted가 나타날 수 있습니다. systemd 서비스를 사용한다면 서비스 유닛의 사용자, 권한 제한과 작업 디렉터리도 확인해야 합니다. 데스크톱 클라이언트의 TUN과 별도의 mihomo systemd 서비스를 동시에 실행하지 마세요. 인터페이스 이름, DNS 포트 또는 정책 라우팅을 서로 점유할 수 있습니다.

Android와 iOS: VPN 권한 다시 설정

모바일 기기의 TUN은 보통 시스템 VPN 인터페이스로 구현됩니다. Android에서는 「설정」→「네트워크 및 인터넷」→「VPN」으로 이동해 작동하지 않는 상시 연결을 제거한 뒤 다시 권한을 부여하세요. 다른 VPN 앱이 시스템의 유일한 VPN 채널을 사용 중인지도 확인해야 합니다. iOS에서는 「설정」→「일반」→「VPN 및 기기 관리」에서 구성 상태를 확인할 수 있습니다. 앱이 연결을 시작하자마자 시스템에 의해 종료된다면 배터리 최적화와 백그라운드 실행 제한도 확인하세요.

코어 파일 누락 또는 손상: 경로를 확인하고 해당 버전을 다시 설치하세요

그래픽 클라이언트는 일반적으로 프록시 코어 자체가 아닙니다. 인터페이스는 실행 시 mihomo, Clash 또는 클라이언트에 포함된 코어 파일을 호출합니다. 코어가 이동되었거나 업데이트가 중단되었거나 아키텍처가 맞지 않으면 인터페이스가 실행 파일을 찾지 못하거나 코어를 실행한 직후 비정상 종료 상태를 받을 수 있습니다.

먼저 클라이언트가 실제로 호출하는 코어 확인

1. 클라이언트의 「설정」→「코어」 또는 「설정」→「버전 정보」를 열어 코어 이름, 버전과 파일 경로를 기록하세요.
2. 경로에 지정된 파일이 존재하는지, 파일 크기가 0KB에 가까울 정도로 비정상적이지 않은지 확인하세요.
3. 터미널에서 mihomo -v 또는 clash -v를 직접 실행해 버전 정보가 출력되는지 확인하세요.
4. 시스템 아키텍처를 확인하세요. Windows와 Linux는 보통 amd64 또는 arm64이며 Apple 칩이 탑재된 macOS는 arm64 아키텍처를 선택해야 합니다.

# Windows PowerShell
& ".\mihomo.exe" -v

# macOS 또는 Linux
./mihomo -v
uname -m

버전 명령도 즉시 종료된다면 구독 설정을 더 수정하지 마세요. 운영체제와 CPU 아키텍처에 맞는 클라이언트 또는 코어를 다시 설치한 뒤 최소 설정으로 테스트하세요. Linux에서는 실행 비트도 확인해야 합니다. 파일을 읽을 수 있지만 실행 권한이 없으면 터미널에 Permission denied가 표시됩니다.

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

클라이언트 업데이트 후 종료되기 시작했다면 인터페이스와 코어의 API 호환성도 확인해야 합니다. 일부 최신 설정은 mihomo의 새 필드에 의존하지만 구형 코어는 이를 읽지 못할 수 있습니다. 반대로 오래된 그래픽 인터페이스가 최신 코어가 반환하는 데이터를 인식하지 못할 수도 있습니다. 복구할 때는 동일한 배포 패키지에 포함된 인터페이스와 코어를 함께 설치하고, 여러 출처와 버전의 파일을 같은 디렉터리에 섞어 두지 마세요.

클라이언트 데이터 손상: 설정을 보존한 뒤 실행 디렉터리 재구성

설정 테스트가 통과하고 포트가 비어 있으며 코어를 독립적으로 실행할 수 있는데도 그래픽 인터페이스가 계속 종료된다면 창 상태, 데이터베이스, 캐시 또는 클라이언트 자체 설정에 문제가 있을 수 있습니다. 이때 앱 데이터를 재구성할 수 있지만 구독 주소, profiles 설정, 사용자 지정 규칙과 스크립트를 반드시 먼저 백업해야 합니다.

안전한 재구성 순서

1. 클라이언트를 완전히 종료하고 백그라운드에 Clash 또는 mihomo 프로세스가 남아 있지 않은지 확인하세요.
2. 설정 디렉터리를 데스크톱에 복사해 백업하세요. 현재 YAML만 보존하지 말고 provider 파일과 사용자 지정 규칙도 복구에 필요할 수 있습니다.
3. 원래 데이터 디렉터리는 즉시 삭제하지 말고 이름을 변경하세요. 예를 들어 디렉터리 이름 뒤에 -backup-20260722를 추가합니다.
4. 클라이언트를 다시 실행해 프로그램이 깨끗한 데이터 디렉터리를 생성하도록 하세요.
5. 먼저 정상 작동이 확인된 설정 하나를 가져오고 기존 캐시를 한꺼번에 모두 복사하지 마세요.
6. 실행이 안정적인지 확인한 뒤 구독과 사용자 지정 규칙을 하나씩 복원하세요.

Windows 앱 데이터는 보통 사용자 AppData 하위 디렉터리에 있고, macOS는 사용자 라이브러리의 Application Support, Linux는 대개 ~/.config에 있습니다. 구체적인 디렉터리 이름은 클라이언트마다 다릅니다. 클라이언트의 「설정」→「설정 디렉터리」나 로그의 home directory, config directory 필드로 확인하세요. 다른 클라이언트의 디렉터리 이름을 근거로 바로 삭제해서는 안 됩니다.

플랫폼별 전체 복구 절차

Windows 복구 단계

1. 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시를 끄세요.
2. 작업 관리자에서 남아 있는 클라이언트와 mihomo 프로세스를 종료하세요.
3. PowerShell로 7890, 7891, 7892, 9090이 LISTEN 상태인지 확인하세요.
4. 터미널에서 코어 버전 명령과 설정 테스트 명령을 실행하세요.
5. 일반 프록시를 실행할 수 있게 된 뒤 서비스 모드와 TUN 가상 인터페이스를 확인하세요.
6. 그래도 실패하면 데이터 디렉터리를 백업하고 클라이언트를 다시 설치한 뒤 검증된 설정 하나만 복원하세요.

macOS 복구 단계

1. 「시스템 설정」→「네트워크」에서 작동하지 않는 프록시 또는 VPN 구성을 끄세요.
2. 활성 상태 보기에서 남아 있는 프로세스를 종료하고 lsof로 수신 대기 포트를 확인하세요.
3. 터미널에서 코어를 실행해 버전과 YAML 설정을 각각 확인하세요.
4. 「개인정보 보호 및 보안」의 권한 안내와 「VPN 및 필터」의 네트워크 확장을 확인하세요.
5. 일반 프록시는 정상이고 TUN만 실패한다면 클라이언트에서 보조 서비스를 다시 설치하세요.

Linux 복구 단계

1. 데스크톱 클라이언트와 systemd 서비스가 동시에 실행 중인지 확인하세요.
2. ss -lntp로 포트를 확인하고 journalctl로 서비스 종료 원인을 확인하세요.
3. 코어 아키텍처, 실행 권한, 작업 디렉터리와 설정 파일 읽기 권한을 확인하세요.
4. TUN을 끈 상태에서 mixed-port를 테스트한 뒤 /dev/net/tun과 라우팅 권한을 확인하세요.
5. 복구 후에는 실행 방식을 하나만 남겨 두어 두 인스턴스가 같은 설정을 중복으로 불러오지 않게 하세요.

복구 후 검증 체크리스트

클라이언트가 더 이상 종료되지 않는다는 것은 프로세스가 실행될 수 있다는 뜻일 뿐입니다. 프록시 경로, DNS와 규칙 동작도 모두 복구되었는지 확인해야 합니다. 다음 순서로 검증하고 어느 단계에서든 실패하면 현재 단계에서 멈추세요. 여러 옵션을 동시에 수정하지 마세요.

• 클라이언트가 최소 5분 동안 계속 실행되고 로그에 error가 반복해서 나타나지 않습니다.
• 7890 또는 사용자 지정 mixed-port가 수신 대기 상태이며 프로세스 이름이 현재 코어와 일치합니다.
• 시스템 프록시 주소와 mixed-port가 완전히 일치합니다. 예: 127.0.0.1:7890.
• 규칙 모드로 전환한 뒤 DIRECT, 프록시 그룹과 MATCH가 예상대로 매칭됩니다.
• 구독을 수동으로 업데이트할 수 있고 업데이트 후 설정 검사도 통과합니다.
• 일반 프록시가 안정된 뒤 TUN을 활성화하고 가상 인터페이스, 기본 경로와 DNS가 정상인지 확인하세요.
• 운영체제를 재시작한 뒤 다시 테스트해 기존 서비스가 7890을 점유하거나 코어를 중복 실행하지 않는지 확인하세요.

가장 효과적인 점검 순서는 터미널에서 오류 정보를 먼저 보존하고, 설정을 테스트한 다음 포트를 확인한 뒤 마지막으로 TUN과 앱 데이터를 처리하는 것입니다. 설정 오류는 대개 줄 번호로 찾을 수 있고, 포트 충돌은 PID로 확인할 수 있으며, TUN 문제는 TUN을 꺼서 분리할 수 있습니다. 코어 문제는 버전 명령과 최소 설정으로 확인할 수 있습니다. 한 번에 하나의 변수만 바꿔야 어떤 조치가 실행 직후 종료 문제를 실제로 해결했는지 알 수 있습니다.