Clash 문제 해결 총정리

1장. 진단 원칙: 먼저 구간을 특정하고, 그다음 처방한다

문제 해결에서 가장 피해야 할 일은 여기저기 손대다가 결국 무엇이 효과가 있었는지 모르게 되는 것입니다. 손대기 전에 먼저 지도를 그려보세요. 프록시 요청 하나가 나가서 돌아오기까지 아래 구간들을 거칩니다. 어느 구간에 문제가 생겨도 겉으로는 똑같이 '인터넷이 안 된다'로 보이지만, 해법은 전혀 다릅니다.

애플리케이션 → 시스템 프록시 / TUN 모드 → Clash 코어(로컬 포트) → 규칙 매칭(정책 그룹) → 노드 → 목표 사이트

단계별 설명: ①애플리케이션이 트래픽을 시스템 프록시에 넘겼는지 — 일부 앱(게임, CLI 도구 등)은 기본적으로 시스템 프록시 설정을 읽지 않습니다. ②시스템 프록시가 실제로 적용됐는지, 지정된 포트가 Clash 코어의 리스닝 포트와 일치하는지. ③코어가 요청을 받은 뒤 규칙 세트를 순서대로 매칭해 직접 연결할지 특정 정책 그룹에 넘길지 결정하고, 정책 그룹이 실제 노드를 선택합니다. ④노드가 살아있는지, 프로토콜을 코어가 지원하는지, 도중에 통신사에 의해 차단되지 않았는지. 문제가 생긴 구간에 해당하는 장으로 이동하세요.

진단 3원칙

1. 먼저 구간을 특정한 뒤 손을 댄다. 문제가 어느 구간에서 발생했는지 먼저 판단하고 해당 장에서 해법을 찾으세요. 구간을 특정하지 않고 설정을 바꾸는 것은 눈을 감고 약을 짓는 것과 같습니다. 맞으면 운이고, 틀리면 새 문제가 생깁니다.
2. 한 번에 변수 하나만 바꾼다. 한 곳을 바꾸고 한 번 테스트하세요. 세 곳을 동시에 바꾸면 해결됐을 때 어디가 효과를 냈는지, 악화됐을 때 어디가 원인인지 알 수 없어 진단이 끝없이 늘어집니다.
3. 먼저 로그를 보고, 그다음 결론을 낸다. 로그는 Clash의 진료 기록입니다. 요청이 들어왔는지, 어떤 규칙에 매칭됐는지, 어떤 오류가 발생했는지 모두 로그에 남습니다. 진단 전에 로그 레벨을 기본값 warning에서 info나 debug로 올리고 문제를 재현한 뒤 로그를 읽으세요. error 레벨은 치명적 오류만 기록하고, info는 각 연결의 경로를 볼 수 있으며, debug는 가장 상세하지만 노이즈도 많습니다. 진단이 끝나면 다시 되돌려 놓으세요.

기본 테스트 3가지

아래 세 가지 테스트는 전체 문서에서 반복적으로 참조되며, 이후 각 장에서 여기로 돌아오라고 안내합니다.

테스트 1, 로컬 포트 테스트 — 코어부터 노드까지 구간이 원활한지 확인:

HTTP 응답 헤더가 반환되면 코어, 규칙, 노드까지 전체 구간이 정상이며 문제는 시스템 프록시나 애플리케이션 계층에 있습니다. 타임아웃이나 오류가 나면 코어부터 노드까지 구간에 문제가 있는 것입니다. 포트 7890은 흔한 기본값이며, 클라이언트에 표시된 통합 포트(mixed-port)를 기준으로 하세요.

테스트 2, 지연시간 테스트 — 클라이언트 패널의 지연시간 테스트는 노드가 TCP 연결을 맺을 수 있는지만 보여주며, 속도와는 무관합니다. 전체 timeout과 일부만 timeout은 서로 다른 문제이니 3장의 다른 두 경로로 진행하세요.

테스트 3, 직접 연결 대조 — 시스템 프록시를 잠시 끄거나(또는 클라이언트를 종료하고) 로컬 네트워크 자체가 인터넷에 연결되는지 확인하세요. 로컬 네트워크가 안 되면 먼저 로컬 네트워크를 고쳐야 합니다. Clash로는 해결할 수 없는 문제입니다.

2장. 연결 후 인터넷이 안 되는 경우

증상 클라이언트가 실행 중이고 시스템 프록시 스위치도 켜져 있지만 브라우저에서 어떤 페이지도 열리지 않음. 또는 일부 사이트만 열리고 나머지는 계속 로딩되다 타임아웃됨.

진단 순서

1. 새 연결 로그가 있는지 확인. 클라이언트의 로그 패널을 열고 안 열리던 페이지를 다시 새로고침하세요. 새 기록이 전혀 없다면 요청이 Clash에 도달조차 하지 않은 것이며, 시스템 프록시가 작동하지 않는 것이니 바로 7장으로 이동하세요. 기록이 있다면 다음 단계로.
2. 전역 모드로 전환해 테스트. 프록시 모드를 '규칙'에서 '전역'으로 바꾸고 다시 새로고침하세요. 전역 모드에서 열린다면 코어와 노드는 문제없고, 규칙이 요청을 직접 연결이나 잘못된 정책 그룹으로 보낸 것입니다. 이 장의 '규칙 오작동' 부분을 참고하세요. 전역 모드에서도 안 열리면 다음 단계로.
3. 노드를 바꿔서 테스트. 정책 그룹에서 다른 노드를 수동으로 선택한 뒤 새로고침하세요. 노드를 바꾼 뒤 열린다면 원래 노드에 문제가 있는 것이니 3장으로 이동하세요. 여러 노드를 바꿔도 안 되면 다음 단계로.
4. TUN과 시스템 프록시의 충돌 확인. TUN 모드와 시스템 프록시를 동시에 켜면 일부 시스템에서 루프가 발생해 트래픽이 두 계층 사이를 오가며 모든 요청이 타임아웃되는 증상이 나타납니다. 둘 중 하나를 끄고 다시 테스트하세요.
5. 보안 프로그램의 차단 확인. 일부 백신·방화벽이 로컬 프록시 포트의 루프백 연결을 막거나 Clash 코어의 아웃바운드를 직접 차단할 수 있습니다. 잠시 꺼서 재확인하고, 원인이 확인되면 클라이언트를 화이트리스트에 등록한 뒤 보호 기능을 다시 켜세요.

규칙 오작동: 전역은 되는데 규칙 모드는 안 되는 경우

규칙 모드에서는 각 요청이 규칙 세트를 위에서 아래로 순서대로 매칭합니다. DIRECT에 매칭되면 직접 연결, 특정 정책 그룹에 매칭되면 프록시 경유, 아무것도 매칭되지 않으면 기본(fallback) 규칙으로 갑니다. 목표 사이트가 열리는지는 어느 규칙에 매칭되느냐에 달려 있습니다. 흔한 오작동 3가지:

• 규칙 세트가 오래됨: 새로 생긴 도메인이 아직 등록되지 않아 기본 규칙에 의해 직접 연결로 보내집니다. 구독이나 규칙 데이터(GeoIP / GEOSITE)를 업데이트한 뒤 재시도하세요.
• 사용자 정의 규칙 오류: 수동으로 추가한 규칙에서 도메인 접미사를 잘못 입력했거나, 위치가 너무 앞에 있어 요청을 미리 가로챈 경우입니다. 규칙은 위에서 아래로 매칭되므로, 의심되는 사용자 정의 규칙을 임시로 주석 처리하고 테스트하세요.
• 정책 그룹 지정 이상: 목표 사이트가 특정 정책 그룹에 매칭됐는데 해당 그룹에서 현재 선택된 노드가 이미 죽어 있는 경우입니다. 그룹 내 노드를 바꾸거나, 해당 그룹을 url-test로 바꿔 자동으로 최적 노드를 선택하게 하세요.

특정 애플리케이션만 인터넷이 안 되는 경우

브라우저는 정상인데 특정 앱만 계속 프록시를 타지 않는다면, 대부분 그 앱이 시스템 프록시 설정을 읽지 않는 경우입니다 — 일부 게임, CLI 도구, 데스크톱 앱이 그렇습니다. 해법은 두 가지: TUN 모드를 켜서 네트워크 인터페이스 계층에서 트래픽을 가로채면 앱이 협조하는지와 무관하게 작동합니다. 또는 해당 앱의 네트워크 설정에서 수동으로 프록시 127.0.0.1:7890을 입력하세요. TUN 모드를 켜는 조건과 대가는 7장 마지막 부분을 참고하세요.

3장. 노드 타임아웃과 연결 실패

증상 지연시간 테스트가 전부 timeout으로 나오거나, 특정 노드만 빨간색으로 표시되고 로그에 connect timeout, connection refused, handshake failure가 반복적으로 나타남.

'전부 사망'인지 '일부만 사망'인지 먼저 구분

모든 노드가 동시에 타임아웃되는 경우, 원인은 거의 항상 로컬이나 구독 쪽에 있습니다 — 수십 개 노드가 동시에 고장 날 확률은 극히 낮기 때문입니다. 일부 노드만 타임아웃될 때 비로소 노드 자체를 봐야 합니다. 두 경우의 진단 경로는 완전히 다르니 먼저 구분한 뒤 진행하세요.

전체 타임아웃: 순서대로 4가지 확인

1. 로컬 네트워크: 프록시를 끄고 직접 연결로 본인 네트워크가 정상인지 확인하세요. 로컬이 안 되면 먼저 로컬을 고쳐야 하며, 그 이후 항목은 확인할 필요가 없습니다.
2. 구독 상태: 서비스 제공사 관리 페이지에 로그인해 요금제가 만료됐는지, 트래픽을 다 썼는지 확인하세요. 구독이 만료돼도 노드 목록은 클라이언트에 그대로 남아 있지만 노드가 전부 사용 불가능한 경우가 많습니다 — 이것이 '전부 사망'의 가장 흔한 원인입니다. 확인 후 4장을 참고해 구독을 업데이트하세요.
3. 시스템 시간: TLS 핸드셰이크는 인증서 유효 기간을 검증하는데, 시스템 시간이 몇 분 이상 어긋나 있으면 모든 노드의 핸드셰이크가 실패해 전체 사망처럼 보입니다. 시스템 시간을 동기화한 뒤 재시도하세요. 자주 놓치는 부분입니다.
4. 로컬 포트와 방화벽: 코어의 프록시 포트가 다른 프로그램에 점유됐거나 방화벽에 막혀 모든 요청이 실패하는 경우입니다. 포트 점유 확인 방법은 8장을 참고하세요.

일부 타임아웃: 순서대로 3가지 확인

1. 노드 자체 장애 또는 차단: 저녁 시간대 백본망 혼잡, 노드 IP가 목표 지역 통신사에 차단된 경우 모두 단일 노드 타임아웃으로 나타납니다. 다른 지역, 다른 입구의 노드로 비교해 보세요.
2. 프로토콜과 커널 불일치: 구독에 여러 프로토콜의 노드가 섞여 있고, 오래된 Clash 커널이 VLESS, Hysteria2 같은 신규 프로토콜을 인식하지 못하면 해당 노드들만 전부 사용 불가능하고 나머지는 정상인 증상이 나타납니다. mihomo 커널 기반 클라이언트로 바꾸면 인식할 수 있습니다 — 다운로드 페이지에 나열된 클라이언트는 모두 mihomo 커널입니다.
3. 노드 파라미터 변경: 서비스 제공사가 포트, 비밀번호, 접속 주소를 바꿨는데 로컬 구독이 업데이트되지 않아, 옛 파라미터로는 당연히 연결되지 않습니다. 구독을 업데이트한 뒤 재시도하세요.

4장. 구독 업데이트 실패

증상 '구독 업데이트' 클릭 시 다운로드 실패, 요청 타임아웃, 파싱 실패, 설정 비어있음 등의 오류가 발생하거나, 업데이트 버튼이 한참 로딩되다가 노드 목록에 변화가 전혀 없음.

진단 순서

1. 구독 링크를 브라우저에 직접 붙여넣어 열어보세요. 텍스트 파일(YAML 또는 Base64 콘텐츠)이 다운로드된다면 링크는 유효하며 문제는 클라이언트 쪽에 있으니 2단계로 이동하세요. 열리지 않거나 404/403 오류, 또는 서비스 제공사 공지 페이지로 리디렉션된다면 링크가 만료됐거나 요금제 문제이니 3단계로 이동하세요.
2. 클라이언트 쪽: '프록시로 구독 업데이트' 옵션을 끄고 재시도. 여기에는 순환 의존성이 있습니다. 프록시가 이미 죽어 있으면 프록시를 경유한 구독 업데이트는 반드시 실패하고, 새 노드가 없으면 프록시는 더더욱 살아나지 못합니다. 구독 업데이트는 반드시 직접 연결로 해야 합니다. 계속 실패하면 TUN 모드가 업데이트 요청까지 가로채고 있는지 확인하고, 필요하면 클라이언트를 종료한 뒤 브라우저로 다운로드해 로컬 파일로 가져오세요.
3. 링크 쪽: 서비스 제공사 관리 페이지에서 구독 주소를 다시 복사. 관리 페이지에서 구독 토큰을 재설정하면 기존 링크는 즉시 무효화됩니다. 요금제가 만료되거나 트래픽을 다 쓴 경우 일부 서비스 제공사는 구독이 빈 콘텐츠나 오류 페이지를 반환하도록 하며, 재충전 후 복구됩니다. 구독 변환 서비스를 사용 중이라면 변환 서비스 자체가 다운됐을 때도 다운로드 실패가 발생합니다 — 서비스 제공사의 원본 구독 링크로 바꿔 한 번 시도해 보세요.

다운로드는 되는데 파싱에 실패하는 경우

파싱 실패는 클라이언트가 받은 내용이 인식할 수 없는 형식임을 의미합니다. 흔한 경우 3가지:

• HTML 오류 페이지가 반환됨: 구독 주소가 리버스 프록시나 변환 서비스에 막혀 설정이 아닌 웹페이지가 반환된 경우입니다. 브라우저로 해당 링크를 열어 내용을 확인하면 바로 알 수 있습니다.
• 형식이 클라이언트와 맞지 않음: 구독 내용이 다른 클라이언트의 전용 형식으로 되어 있는 경우입니다(일부 패널은 기본적으로 다른 형식을 출력합니다). 서비스 제공사 관리 페이지나 변환 링크의 파라미터에서 Clash / mihomo 형식으로 출력하도록 지정하세요.
• 콘텐츠가 잘림: 네트워크 불안정으로 다운로드가 불완전해 YAML 구조가 손상된 경우입니다. 다시 업데이트하거나, 브라우저로 완전한 파일을 다운로드한 뒤 로컬로 가져오세요.

로컬 가져오기로 임시 대응

구독 주소가 당장 복구되지 않을 때는, 브라우저로 열린 구독 내용을 .yaml 파일로 저장한 뒤 클라이언트에서 '파일에서 가져오기'를 선택하세요. 로컬 파일은 자동으로 업데이트되지 않으므로, 구독이 복구되면 다시 구독 링크 방식으로 바꿔야 노드 변경 사항이 계속 동기화됩니다. 설정 파일(Profile)의 더 많은 관리 방법 — 다중 설정 전환, 병합, 업데이트 정책 — 은 《Clash 설정 파일이란?》을 참고하세요.

5장. 속도 저하, 끊김, 버퍼링

증상 프록시는 연결되지만 페이지 로딩이 느리거나, 영상이 계속 버퍼링되거나, 다운로드 속도가 기대치보다 현저히 낮음. 또는 낮에는 정상이고 밤에만 규칙적으로 끊기고 느려짐.

먼저 어느 구간에서 느린지 구분

대조 테스트를 해보세요: 프록시를 끄고 직접 연결로 속도를 측정한 뒤 프록시를 켜고 다시 측정하세요. 직접 연결도 느리면 로컬 인터넷이나 Wi-Fi 문제이니 먼저 로컬을 고치세요. 직접 연결은 정상인데 프록시가 느리면 노드나 규칙 쪽 문제이니 아래를 확인하세요.

지연시간 숫자는 속도와 다릅니다

클라이언트의 지연시간 테스트는 TCP 연결을 맺는 데 걸린 시간(밀리초)만 나타내며 대역폭과는 별개입니다. 지연시간 300ms인 노드가 100Mbps를 꽉 채울 수도 있고, 지연시간 80ms인 노드가 몇 Mbps밖에 안 나올 수도 있습니다. 노드를 고를 때는 지연시간 순위가 아니라 실제로 페이지를 열거나 영상을 재생해 보는 체감, 또는 속도 측정 사이트의 실측치를 기준으로 하세요.

노드 쪽의 느린 원인 3가지

• 저녁 피크타임 부하: 저녁 8시부터 11시는 노드가 가장 혼잡한 시간대로, 같은 노드라도 낮과 밤의 속도가 몇 배 차이 날 수 있습니다. 이 시간대에는 부하가 낮은 노드로 바꾸거나 다른 지역을 시도해 보세요.
• 회선 우회: 노드에서 목표 사이트까지의 회선 품질이 체감 속도를 결정합니다. 일본 사이트에 접속하는데 미국 노드를 쓰면 데이터가 태평양을 두 번 건너야 합니다. 목표 사이트의 소재 지역에 맞춰 가까운 노드를 선택하세요.
• 배율과 속도 제한: 일부 서비스 제공사는 낮은 배율 노드나 단일 연결에 속도 제한을 걸어둡니다. 대용량 작업(시스템 업데이트, 클라우드 동기화)은 가능하면 직접 연결 규칙으로 처리해 프록시 대역폭을 아끼세요.

규칙 쪽의 느린 원인 2가지

• 목표 사이트가 잘못된 정책 그룹으로 이동: 로그를 열어 목표 도메인이 어느 규칙에 매칭됐고 어느 그룹으로 분류됐는지 확인하세요. 스트리밍 도메인이 '기본 직접 연결' 그룹으로 분류되면 느려질 뿐만 아니라 지역 제한 콘텐츠도 못 볼 수 있습니다.
• 자동 선택 그룹의 오작동: url-test 그룹은 지연시간을 기준으로 노드를 선택하는데, 지연시간은 낮지만 대역폭이 작은 노드를 선택할 수도 있습니다. 피크타임에는 주요 정책 그룹을 수동 지정으로 바꾸는 것이 오히려 더 안정적입니다.

본인 기기 쪽의 느린 원인 2가지

• TUN 모드 오버헤드: TUN은 네트워크 인터페이스 계층에서 모든 트래픽을 처리하기 때문에 대용량 다운로드 시 추가 오버헤드가 발생합니다. 최고 속도를 원한다면 브라우저는 시스템 프록시, 다운로더는 직접 연결로 조합하는 것이 더 효율적입니다.
• 이중 프록시: 시스템 프록시와 TUN을 동시에 켜거나, 브라우저 프록시 확장 프로그램과 시스템 프록시가 겹치면 트래픽이 한 단계 더 돌아가면서 속도가 그만큼 손실됩니다. 한 계층만 트래픽을 처리하도록 유지하세요.

노드를 고르는 체계적인 방법 — 지연시간, 배율, 지역, 프로토콜 네 가지 기준을 어떻게 따질지 — 은 별도 글로 정리했습니다: 《Clash 노드 선택 가이드》.

6장. DNS 해석 이상

증상 브라우저에 '서버 IP를 찾을 수 없음' 오류; 일부 도메인은 안 열리지만 대응하는 IP로는 연결됨; 페이지를 처음 열 때 대기 시간이 유난히 길고 두 번째부터는 정상.

Clash의 두 가지 DNS 동작 방식 이해하기

Clash 코어에는 내장 DNS 모듈이 있으며 두 가지 해석 전략이 있습니다. 동작 방식과 호환성이 다르므로 잘못 선택하면 위와 같은 증상이 나타납니다:

진단 순서

1. DNS 장애인지 확인. 열리지 않는 사이트를 IP로 직접 연결(또는 다른 기기에서 모바일 데이터로 접속)했을 때 열리면 원인이 해석 단계에 있는 것으로 확인할 수 있으며 노드 문제가 아닙니다.
2. 현재 DNS 설정 확인. 설정에서 dns.enable이 true인지, 클라이언트 화면의 'DNS 가로채기' 관련 스위치가 꺼져 있는지 확인하세요. 코어가 DNS를 가로채지 않으면 오염과 하이재킹이 시스템 해석에 그대로 적용됩니다.
3. fake-ip 호환성 진단. 게임, 로컬 네트워크 서비스(프린터, NAS, 화면 미러링), 일부 공공기관·은행 앱에서 문제가 집중된다면 fake-ip 비호환일 가능성이 높습니다. 해당 도메인을 fake-ip-filter에 추가하거나 전체를 redir-host 모드로 되돌리세요.
4. 통신사 하이재킹 진단. 가정용 인터넷의 기본 DNS는 흔히 UDP 53 포트의 평문 쿼리를 가로채 조작된 결과를 반환합니다. nameserver에 DoH / DoT 암호화 해석을 설정하면 하이재킹이 무력화됩니다.

그대로 사용할 수 있는 DNS 설정 예시

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.home.arpa"
    - localhost.ptlogin2.qq.com
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

설정 설명: nameserver는 국내(중국 본토) 도메인 해석을 담당하며 빠른 경로를 사용합니다. fallback은 해외 도메인 해석을 담당하며 오염 방지를 위해 암호화 채널을 사용합니다. fake-ip-filter에는 가상 주소를 인식하지 못하는 도메인을 넣으며 와일드카드 표기법은 위와 같습니다. 설정을 변경한 뒤에는 코어를 재시작해야 적용됩니다.

검증 명령어:

198.18.x.x 대의 주소가 반환되면 fake-ip가 작동 중이라는 뜻입니다. 타임아웃이 반환되면 코어의 DNS가 제대로 작동하지 않는 것이니 2단계로 돌아가 dns.enable과 리스닝 포트를 확인하세요.

7장. 시스템 프록시가 작동하지 않는 경우

증상 클라이언트가 실행 중이고 노드도 정상이지만 로그에 새 연결 기록이 전혀 없음. 시스템 설정에서 프록시 항목이 보이지 않거나, 프록시 항목이 가리키는 포트가 클라이언트와 일치하지 않음.

각 플랫폼별 시스템 프록시 적용 여부 확인

적용 실패의 흔한 원인

1. 권한 부족: 시스템 프록시를 설정하려면 해당 권한이 필요합니다. Windows에서 일반 권한으로 실행된 클라이언트는 그룹 정책에 의해 제한될 수 있습니다. macOS는 처음 켤 때 권한 요청 창이 뜨는데 '허용 안 함'을 눌렀다면 시스템 설정의 네트워크 프록시 화면에서 수동으로 켜세요.
2. 브라우저 확장 프로그램의 권한 탈취: SwitchyOmega 같은 프록시 확장 프로그램이 브라우저를 장악하면 시스템 프록시를 완전히 무시하고 확장 프로그램 자체 규칙을 따릅니다. '시스템 프록시는 켜져 있는데 브라우저가 따르지 않는' 증상으로 나타납니다. 확장 프로그램을 비활성화하거나 '시스템 프록시 사용' 모드로 전환하세요.
3. 다른 프록시 소프트웨어의 잔여 설정: 이전에 설치한 VPN, 가속기가 종료 시 시스템 프록시를 정리하지 않아 시스템 설정에 옛 포트가 그대로 남아 있는 경우입니다. 시스템 프록시를 수동으로 127.0.0.1과 현재 클라이언트 포트로 바꾸거나, 먼저 끈 뒤 클라이언트가 다시 적용하도록 하세요.
4. 포트 불일치: 클라이언트마다 기본 포트가 다르고(흔히 7890, 일부는 7897) 설정 파일에서 mixed-port를 변경했을 수도 있는데 시스템 프록시는 여전히 옛 값을 가리키고 있는 경우입니다. 양쪽을 일치시키거나, 클라이언트에서 시스템 프록시를 한 번 껐다 켜서 현재 설정으로 다시 쓰도록 하세요.

수동 설정과 TUN 대체 방안

자동 적용이 계속 실패할 때는 시스템 설정에서 수동으로 입력할 수 있습니다: 주소 127.0.0.1, 포트는 클라이언트의 mixed-port와 일치. 수동 설정의 단점은 클라이언트를 종료해도 시스템 프록시가 자동으로 지워지지 않는다는 것으로, 종료 전 수동으로 꺼야 하며 그렇지 않으면 다음번 클라이언트를 켜지 않고 부팅할 때 인터넷 전체가 안 될 수 있습니다.

더 확실한 해법은 TUN 모드입니다: 네트워크 인터페이스 계층에서 모든 트래픽을 가로채므로 시스템 프록시에 의존하지 않으며, 시스템 프록시를 읽지 않는 앱(게임, CLI)도 가로챌 수 있습니다. 대가는 서비스 모드 설치나 관리자/root 권한이 필요하고, 시스템 프록시와 동시에 켜면 루프가 발생할 수 있다는 점입니다 — 둘 중 하나만 선택하세요. Windows에서는 클라이언트를 관리자 권한으로 실행한 뒤 TUN을 켜고, macOS에서는 클라이언트 안내에 따라 도우미 도구 설치를 승인하며, Linux에서는 root 권한이나 capabilities 설정이 필요합니다.

8장. 클라이언트 충돌과 실행 실패

증상 클라이언트를 더블클릭해도 반응 없음, 실행 즉시 강제 종료, '코어 시작 실패' 알림, 화면이 멈춰 응답 없음, 부팅 시 자동 시작 후 조용히 종료됨.

먼저 실제 오류 메시지를 확보

그래픽 화면이 강제 종료될 때는 명령줄로 클라이언트를 실행하거나 코어를 단독으로 실행해 보세요. 오류가 터미널에 직접 출력됩니다. 오류 텍스트가 이 장의 모든 해법의 출발점이니 먼저 이를 확보하고 아래 네 가지 흔한 원인과 대조하세요. 그래픽 화면은 오류를 숨기므로 아이콘만 보고는 추측할 수 없습니다.

흔한 원인 4가지

설정 파일 문법 오류

YAML은 들여쓰기에 매우 민감합니다: 반드시 공백을 사용하고, 같은 레벨은 정렬해야 하며, Tab을 쓸 수 없고, 콜론 뒤에는 반드시 공백이 하나 있어야 합니다. 설정을 수동으로 편집한 뒤 코어가 시작되지 않는다면 십중팔구 들여쓰기나 구두점 문제입니다. 변경 내용을 되돌리거나, 설정을 YAML 검증 도구에 붙여넣어 확인한 뒤 다시 시작하세요.

포트 점유

프록시 포트(기본 7890)나 외부 제어 포트(기본 9090)가 다른 프로그램에 점유되면 코어가 시작 즉시 종료됩니다. 점유 확인 방법:

첫 번째 명령은 Windows용, 두 번째는 macOS / Linux용입니다. 점유한 것이 완전히 종료되지 않은 이전 Clash 프로세스라면 종료 후 재시작하고, 다른 소프트웨어라면 클라이언트 포트나 해당 소프트웨어의 포트를 변경하세요.

권한 부족

TUN 모드, 강화 모드는 특권이 필요하며 권한이 부족하면 코어 시작 실패나 TUN 네트워크 인터페이스 생성 실패가 발생합니다. Windows는 마우스 우클릭 후 '관리자 권한으로 실행', macOS는 안내에 따라 비밀번호를 입력해 도우미를 설치, Linux는 sudo나 setcap으로 권한을 부여하세요.

설정 디렉터리 손상

비정상적인 전원 차단, 강제 종료로 캐시나 설정 인덱스가 손상되면 클라이언트는 열리지만 조작할 때마다 튕기는 증상이 나타납니다. 먼저 구독 링크와 사용자 정의 규칙을 백업한 뒤 설정 디렉터리를 삭제해 클라이언트가 다시 생성하도록 하세요. 설정 디렉터리 위치: Windows는 %APPDATA% 아래 클라이언트 이름으로 된 디렉터리, macOS는 ~/Library/Application Support/, Linux는 ~/.config/.

백신 오탐

일부 보안 소프트웨어가 프록시 코어를 의심 프로그램으로 인식해 차단하거나 격리합니다. 코어 파일이 갑자기 사라지거나 업데이트마다 차단당하는 것이 전형적인 증상입니다. 클라이언트 설치 디렉터리와 설정 디렉터리를 화이트리스트에 추가하고, 격리된 코어 파일을 복원한 뒤 다시 시작하세요.

9장. 모바일 전용 진단 (Android / iOS)

증상 Android에서 잠금화면 시 연결이 끊기거나 앱 전환 시 프록시가 작동하지 않음. iOS에서 백그라운드로 일정 시간 지나면 연결이 끊김. 또는 모바일 특유의 'VPN 아이콘 사라짐', '스위치가 자동으로 꺼짐' 현상.

Android 전용

1. 절전 정책의 백그라운드 종료(가장 흔함): 중국산 커스텀 롬은 기본적으로 백그라운드를 강하게 정리해 잠금화면 몇 분 만에 프록시 코어를 종료시킵니다. 시스템 설정에서 클라이언트를 배터리 최적화 화이트리스트에 추가하고, 자동 실행을 허용하며, 최근 앱 목록에 고정하세요. 롬마다 경로가 다르니(샤오미는 '절전 및 배터리', 화웨이는 '앱 실행 관리') 찾기 어려우면 설정에서 '배터리 최적화'로 검색하세요.
2. VPN 단일 점유 충돌: Android는 한 번에 하나의 앱만 VPN 서비스를 가질 수 있습니다. 다른 VPN, 가속기, 광고 차단 앱이 VPN 자리를 차지하면 Clash의 스위치가 꺼집니다. 충돌하는 앱을 끈 뒤 다시 켜세요.
3. 앱별 프록시 설정: 클라이언트의 '앱별 프록시'에서 대상 앱이 제외되어 있으면 해당 앱은 프록시를 타지 않는 것처럼 보입니다. 목록을 확인하거나, 임시로 '모든 앱 프록시'로 전환해 대조해 보세요.
4. 프라이빗 DNS 충돌: 시스템의 '프라이빗 DNS'(Private DNS)를 켜면 프록시의 DNS 가로채기를 건너뛰어 일부 상황에서 해석 오류가 발생할 수 있습니다. 프록시 동작이 이상할 때는 먼저 프라이빗 DNS를 끄고 대조해 보세요.

iOS 전용

1. 백그라운드 새로고침 제한: iOS는 백그라운드 네트워크 활동을 엄격히 제한해, 잠금화면이나 앱 전환 후 일정 시간이 지나면 연결이 시스템에 의해 일시 중단되고 앱으로 돌아오면 자동 재연결됩니다. 이는 시스템 동작이며 장애가 아닙니다. 끊김이 자주 발생한다면 저전력 모드가 켜져 있는지 확인하세요 — 백그라운드 활동을 더 강하게 억제합니다.
2. VPN 설정 충돌: 여러 프록시 앱을 설치했다면 시스템에 여러 VPN 설정이 남아 서로 스위치를 방해할 수 있습니다. '설정 → 일반 → VPN 및 기기 관리'에서 사용하지 않는 설정을 삭제하세요.
3. Wi-Fi와 셀룰러 전환: 네트워크 전환 순간 프록시 터널이 재구성되며 몇 초간 끊기는 것은 정상적인 재연결 과정입니다. 전환 후 오랫동안 복구되지 않으면 비행기 모드를 한 번 켰다 꺼서 강제로 재연결하세요.

모바일 클라이언트 선택: Android는 Clash Plus를 우선 추천하며 Clash Meta for Android, FlClash도 선택 가능합니다. iOS는 Clash Plus를 우선 추천합니다(App Store 출시, 공식 사이트 clashplus.io). 각 플랫폼 클라이언트의 상세 비교는 클라이언트 비교 페이지를 참고하고, 설치 파일은 다운로드 페이지에서 받으세요.