Clash 클라이언트 실행 직후 종료될 때: 로그 확인, 포트 충돌 해결 및 설정 복원

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

먼저 작업 표시줄의 시스템 트레이나 메뉴 막대를 확인한 다음 프로세스 목록을 살펴보세요. 창을 닫은 뒤에도 트레이 아이콘이 남아 있다면, 클라이언트가 ‘트레이로 최소화’ 설정에 따라 동작한 것일 수 있으며 강제 종료된 것은 아닙니다. 창은 열리지만 연결 실패 또는 프록시를 사용할 수 없다는 메시지가 표시된다면 커널이 시작되지 않았을 가능성이 큽니다. 커널은 설정을 읽고 규칙을 적용해 연결을 전달하는 프로그램이며, 그래픽 인터페이스는 이를 조작하는 창구입니다.

문제가 발생하기 직전에 마지막으로 한 작업을 기록하세요. 구독을 업데이트한 뒤 문제가 생겼다면 설정을 먼저 확인하고, TUN을 켠 뒤라면 권한과 가상 네트워크 어댑터를 확인하세요. 클라이언트를 업그레이드한 뒤 창조차 나타나지 않는다면 앱 충돌 보고서와 설치 파일의 아키텍처를 확인해야 합니다. 소프트웨어 업데이트, 구독 변경, 포트 변경을 한꺼번에 하지 마세요. 어느 조치가 문제를 해결했는지 알 수 없게 됩니다.

로그 확인: 첫 번째 오류 전후의 기록을 보관하세요

인터페이스가 열리면 먼저 커널 로그를 확인하세요

클라이언트의 ‘로그’ 페이지를 열거나 ‘설정’에서 ‘설정 폴더 열기’, ‘로그 폴더 열기’와 같은 메뉴를 찾아보세요. 클라이언트마다 메뉴 이름이 다르므로 다른 클라이언트의 폴더 경로를 그대로 적용하지 마세요. 이번에 시작한 시간대의 기록을 우선 확인하고 오류 전후 약 20줄을 저장하세요. 로그 끝부분에 반복해서 표시되는 ‘연결 재시도’는 대개 실패의 원인이 아니라 결과입니다.

앱 로그와 커널 로그를 구분하세요. 앱 로그에는 창, 업데이트 및 서비스 호출 기록이 남고, 커널 로그에는 설정 파싱, 포트 수신 대기, 규칙 로드 및 연결 처리 기록이 남습니다. 인터페이스에 ‘제어 포트에 연결할 수 없음’이라고 표시되더라도, 커널이 설정 오류로 먼저 종료됐는지 앞선 로그부터 확인하세요. 제어 포트가 사용 중이라고 바로 단정해서는 안 됩니다.

창이 열리지 않으면 시스템 기록을 확인하세요

• Windows: Win + R을 누르고 eventvwr.msc를 실행한 다음 ‘Windows 로그’ → ‘응용 프로그램’에서 발생 시간에 해당하는 앱 오류를 찾으세요. perfmon /rel을 실행해 안정성 모니터에서 해당 프로그램의 실패 기록을 확인할 수도 있습니다.
• macOS: ‘콘솔’ 앱을 열고 ‘충돌 보고서’에서 프로세스 이름과 시간을 기준으로 해당 보고서를 찾으세요. 예외 유형, 종료 원인 및 오류 스레드를 확인하고 보고서 제목만 잘라서 공유하지 마세요.
• Linux: 터미널에서 실제 클라이언트 실행 파일을 시작하고 표준 오류 출력을 확인하세요. 사용자 서비스로 실행했다면 journalctl --user -b를 사용해 이번 부팅에서 발생한 사용자 서비스 로그를 확인하세요.

먼저 키워드로 범위를 좁히세요. yaml, unmarshal, parse는 설정 파싱 문제를 가리키는 경우가 많고, address already in use는 주소 또는 포트 충돌을, permission denied와 operation not permitted는 권한 문제를 가리킵니다. 로그에 error가 있다고 모두 프로그램 충돌을 뜻하는 것은 아닙니다. 예를 들어 규칙 소스 하나를 내려받지 못했더라도 이후 시작이 계속되는지 확인해야 합니다.

설정 확인: YAML을 먼저 검증한 뒤 커널 지원 여부를 확인하세요

최근에 수정한 몇 줄부터 살펴보세요. YAML은 들여쓰기로 계층을 표현하는 설정 형식이므로 공백을 사용하고 탭은 섞지 마세요. 흔한 오류로는 콜론 뒤에 공백을 빠뜨리는 경우, 목록 항목의 하이픈 누락, 닫히지 않은 따옴표, rules를 dns 아래에 작성하는 경우가 있습니다. 오류가 표시된 줄은 파서가 문제를 최종적으로 발견한 위치일 수 있으므로 바로 앞 구간도 함께 확인하세요.

현재 실행 중인 커널을 확인하세요. Clash, Clash Meta, mihomo는 지원하는 설정 범위가 완전히 같지 않으며 그래픽 인터페이스에 표시된 이름이 커널 이름과 일치하는 것도 아닙니다. ‘정보’ 메뉴나 시작 로그에서 클라이언트 버전과 커널 버전을 확인하세요. 설치 파일 이름만으로 특정 설정 항목의 지원 여부를 판단하지 마세요.

같은 커널로 설정 복사본을 테스트하세요

확인할 파일을 recovery.yaml로 복사한 뒤 복사본에서 작업하세요. 아래 명령은 mihomo용입니다. 먼저 -v로 버전을 확인하고, 이어서 -t로 설정을 테스트하세요. 클라이언트가 실제로 사용하는 커널로 테스트해야 하며, 다른 버전을 임의로 내려받아 대신 사용하지 마세요.

# Windows PowerShell: 커널 및 테스트 파일이 있는 폴더에서 실행
.\mihomo.exe -v
.\mihomo.exe -t -d . -f .\recovery.yaml

# macOS / Linux: 해당 폴더에서 실행
./mihomo -v
./mihomo -t -d . -f ./recovery.yaml

-f는 설정 파일을 지정하고 -d는 작업 폴더를 지정합니다. 여기서 .은 현재 폴더를 의미합니다. 원래 설정에서 상대 경로로 규칙 파일을 참조한다면 필요한 파일도 테스트 폴더에 함께 복사하세요. 로컬 리소스가 없어 테스트가 실패할 수도 있으므로 이를 모두 YAML 문법 오류로 간주해서는 안 됩니다.

최소 설정으로 구독 및 덮어쓰기 문제를 분리하세요

어느 구간에서 문제가 생겼는지 알 수 없다면 복사본에 아래 mihomo 설정을 임시로 사용해 보세요. TUN과 내장 DNS를 끄고 로컬 혼합 프록시 포트만 열어 요청을 대상에 직접 연결합니다. 기본 실행 여부를 확인하기 위한 설정이며 원격 프록시 기능은 제공하지 않고, 완전한 구독 설정을 대신할 수도 없습니다.

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

tun:
  enable: false

dns:
  enable: false

rules:
  - MATCH,DIRECT

최소 설정으로 시작할 수 있다면 ‘구독 기본 설정 → 사용자 지정 규칙 → DNS → TUN’ 순서로 구간별 복원하고, 각 구간을 복원할 때마다 한 번씩 재시작하세요. 구독이 자동 새로고침된 뒤에만 문제가 재발한다면 구독 형식과 클라이언트의 덮어쓰기 로직을 확인하세요. 많은 클라이언트는 실행 설정을 다시 생성하므로 생성된 파일을 직접 수정해도 다음 시작 때 변경 사항이 사라질 수 있습니다.

포트 충돌 해결: 프로세스를 먼저 확인한 뒤 포트 변경 여부를 결정하세요

로그에 표시된 포트를 기준으로 확인하세요. 7890은 HTTP와 SOCKS 혼합 프록시 포트로, 9090은 제어 인터페이스 포트로 자주 사용되지만 둘 다 변경할 수 있습니다. 수신 대기 실패와 연결 실패도 구분해야 합니다. bind 근처에서 오류가 발생했다면 로컬 수신 대기 문제일 가능성이 높지만, 원격 노드 연결 시간 초과는 로컬 포트 충돌이 아닙니다.

Windows: 수신 대기 중인 프로세스의 PID 확인

PowerShell을 열고 아래 명령을 실행하세요. PID는 프로세스 식별자로, 포트를 사용하는 프로세스를 찾는 데 쓰입니다. 명령 결과가 비어 있다면 조회 시점에 해당 TCP 수신 항목이 발견되지 않았다는 뜻이며, 프로그램이 시작되는 순간에도 충돌이 없었다는 뜻은 아닙니다.

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

# 수신 대기 중인 프로세스 이름 표시
Get-NetTCPConnection -State Listen -LocalPort 7890,9090 -ErrorAction SilentlyContinue |
  Select-Object -ExpandProperty OwningProcess -Unique |
  ForEach-Object { Get-Process -Id $_ -ErrorAction SilentlyContinue }

macOS / Linux: TCP 포트를 수신 대기 중인 프로세스 확인

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

기존 클라이언트를 정상적으로 종료한 뒤 커널이나 백그라운드 서비스가 남아 있는지 확인하세요. 포트가 사용 중이라는 이유만으로 정체를 모르는 프로세스를 강제 종료하거나 시스템 서비스를 중지하지 마세요. 혼합 포트를 7895로 바꾸기로 했다면 먼저 새 포트가 비어 있는지 확인한 다음 브라우저의 수동 프록시 설정, 터미널 환경 변수 및 다른 호출 프로그램도 함께 수정하세요.

제어 포트는 별도로 확인하세요. external-controller를 변경했다면 그래픽 인터페이스도 새 주소에 연결해야 합니다. 일부 클라이언트는 이 항목을 자체적으로 관리하므로 수동으로 덮어쓰면 인터페이스와 연결이 끊길 수 있습니다. 로그에 DNS의 53 포트가 표시된다면 UDP/TCP 수신 상태와 시스템 이름 확인 서비스를 별도로 점검하세요. 앞서 사용한 TCP 조회만으로는 DNS 포트 충돌을 확인할 수 없습니다.

권한 및 서비스 모드 확인: 먼저 TUN을 끄고 테스트하세요

먼저 TUN을 끄고 일반 프록시를 시작해 보세요. TUN은 가상 네트워크 어댑터를 통해 트래픽을 처리하는 방식으로, 보통 시스템 경로, 네트워크 어댑터 및 더 높은 권한이 필요합니다. TUN을 끈 상태에서 시작할 수 있다면 가상 네트워크 어댑터, 권한, 서비스 또는 관련 설정으로 점검 범위를 좁힐 수 있습니다. 구독을 계속 바꿔 볼 필요는 없습니다.

1. 백그라운드 서비스 상태를 확인하세요. 클라이언트 설정에서 ‘서비스 모드’ 또는 이에 해당하는 서비스 관리 항목을 확인하세요. Windows에서는 services.msc를 실행해 클라이언트에 표시된 정확한 서비스 이름, 상태 및 실행 파일 경로를 대조하세요. 이름이 비슷하다는 이유로 추측하지 마세요.
2. 업그레이드 후 경로가 바뀌었는지 확인하세요. 포터블 버전의 폴더를 이동했거나 기존 서비스가 삭제된 파일을 가리키면 서비스가 시작되지 않을 수 있습니다. 먼저 클라이언트를 종료한 다음 해당 클라이언트에 포함된 서비스 복구 기능을 사용하거나 서비스 재설치 메뉴를 이용하세요.
3. 설정 폴더의 쓰기 권한을 확인하세요. 백업 폴더에 일반 텍스트 파일을 만들어 보세요. 앱 설정 폴더가 읽기 전용 위치에 있거나 다른 사용자가 소유하고 있거나 보안 소프트웨어에 의해 차단된 경우, 로그에 따라 해당 접근 권한을 수정하세요.
4. 마지막으로 TUN을 다시 켜세요. 일반 프록시가 안정적으로 작동한 뒤 TUN을 단독으로 켜고 로그를 확인하세요. 경로를 가로채는 프록시나 VPN을 여러 개 동시에 실행하지 마세요. 가상 네트워크 어댑터와 라우팅 규칙이 서로 영향을 줄 수 있습니다.

‘항상 관리자 권한으로 실행’을 만능 해결책으로 여기지 마세요. 권한 문제인지 확인하기 위해 잠시 권한을 높일 수는 있지만, 장기적으로는 클라이언트가 제공하는 서비스 설치 절차를 따라야 합니다. macOS의 백그라운드 보조 구성 요소와 Linux 서비스 권한도 해당 클라이언트의 안내에 따라 설정하세요. 프로그램 폴더 전체에 제한 없는 쓰기 권한을 주는 것은 피해야 합니다.

안전한 설정 복원: 마지막으로 정상 작동한 설정으로 되돌리고 폴더 전체를 지우지 마세요

문제 발생 당시 상태를 먼저 보존한 뒤 마지막으로 정상 작동한 상태로 돌아가세요. 설정 폴더 전체를 바로 삭제하면 구독 정보, 규칙 덮어쓰기 및 문제 분석에 필요한 기록까지 함께 사라질 수 있습니다. 초기화하기로 했더라도 즉시 삭제하지 말고 백업한 뒤 이름을 바꾸세요.

1. 완전히 종료하세요. 창을 닫은 뒤 시스템 트레이, 메뉴 막대 및 관련 프로세스를 확인하세요. 백그라운드 서비스가 여전히 커널을 관리한다면 클라이언트에서 서비스를 정상적으로 중지하세요.
2. 복사본을 백업하세요. 실제 설정 폴더를 clash-backup-2026-09-30처럼 날짜가 포함된 이름으로 복사하고, 문제 발생 당시의 로그도 별도로 저장하세요.
3. 문제와 관련된 항목만 복원하세요. 규칙을 수정한 뒤 문제가 생겼다면 먼저 규칙 덮어쓰기를 되돌리세요. 구독을 업데이트한 뒤 문제가 생겼다면 마지막으로 정상 작동한 설정으로 전환하세요. 처음부터 모든 앱 설정을 교체하지 마세요.
4. 자동 업데이트를 잠시 중지하세요. 클라이언트에서 지원한다면 해당 구독의 예약 새로고침을 잠시 중지해 복원한 내용이 다시 덮어써지지 않게 하세요. 문제를 해결한 뒤 업데이트를 다시 활성화하면 됩니다.
5. 세 가지 상태를 확인하세요. 인터페이스가 계속 실행되는지, 로그에서 재시작이 반복되지 않는지, 필요한 포트가 정상적으로 수신 대기 중인지 확인하세요. 이후 전체 구독 설정으로 실제 프록시 접속을 테스트하세요.

앱 설정 자체가 손상된 것으로 의심된다면 백업한 뒤 설정 폴더의 이름을 바꾸고 클라이언트가 새 폴더를 만들도록 할 수 있습니다. 클라이언트마다 데이터 폴더 위치가 다릅니다. 일부 포터블 버전은 프로그램 폴더 옆에 데이터를 저장하고, 다른 버전은 사용자 데이터 폴더를 사용하므로 로그에서 실제 위치를 먼저 확인하세요. 초기화 후 이전 설정 전체를 바로 가져오지 마세요. 문제가 다시 생길 수 있습니다.

버전 업그레이드 직후 문제가 발생했다면 업그레이드 전후의 클라이언트 및 커널 버전을 기록한 뒤 프로젝트의 공식 배포 채널에서 정상 작동이 확인된 버전으로 되돌리는 방안을 고려하세요. 새 버전에서 저장한 데이터 구조가 이전 버전과 호환되지 않을 수 있으므로 업그레이드 전후 설정을 각각 백업하세요. 이전 버전이 유일한 데이터 폴더를 반복해서 수정하지 않도록 주의해야 합니다.

계속 종료된다면: 재현 가능한 문제 해결 기록을 정리하세요

정보를 빠짐없이 정리한 뒤 문제를 제출하세요. ‘켜자마자 꺼져요’라는 설명만으로는 그래픽 인터페이스 충돌, 커널 종료, 백그라운드 서비스 실패를 구분할 수 없습니다. 시스템 관련 오류라면 문제 해결 안내를 참고하고, 설정을 어디에 가져와야 할지 모르겠다면 사용 설명서를 확인하세요.

• 환경: 운영체제 버전, CPU 아키텍처, 클라이언트 및 커널의 전체 버전, 설치 버전 또는 포터블 버전 여부.
• 재현 과정: 시작 후 종료되기까지 걸리는 시간, 특정 구독을 가져오거나 TUN을 켜거나 서비스 모드를 변경했을 때만 문제가 발생하는지 여부.
• 확인 결과: 최소 설정으로 시작할 수 있는지, 설정 테스트를 통과했는지, 7890 또는 실제 사용 포트를 어느 프로세스가 수신 대기 중인지.
• 로그 일부: 이번 오류가 발생한 시간, 첫 번째 주요 오류 및 그 전후의 기록. 창이 충돌했다면 시스템 보고서에 표시된 오류 모듈이나 예외 유형도 함께 첨부하세요.

‘로그 → 설정 → 포트 → 권한 → 복원’ 순서로 점검하고 매번 조건 하나만 바꾸세요. 이렇게 하면 종료 원인을 좁히고 명확한 복구 경로를 유지할 수 있어, 시작 문제를 해결하려다 새로운 설정 차이가 생기는 일도 막을 수 있습니다.