Clash 문제 해결 매뉴얼

진단 전 준비: 변수를 고정한 후 시작하기

프록시 체인에는 변할 수 있는 요소가 매우 많습니다: 로컬 네트워크, 클라이언트, 코어, 설정 파일, 구독, 노드 서버, 대상 웹사이트까지 어느 한 단계라도 문제가 생기면 "페이지가 안 열림"으로 나타날 수 있습니다. 진단의 첫 번째 원칙은 한 번에 하나의 변수만 바꾸는 것입니다. 그렇지 않으면 문제가 사라져도 어느 단계가 원인이었는지 알 수 없어 재발 시 처음부터 다시 시작해야 합니다.

시작 전 기본 정보 네 가지 기록하기

• 클라이언트와 코어: 사용 중인 클라이언트가 무엇인지(Clash Plus, Clash Verge Rev, FlClash 등), 코어가 Meta/mihomo인지 오리지널인지 확인하세요. 코어 차이는 특정 설정 필드가 인식되는지 여부를 직접 결정합니다. 자세한 내용은 블로그 글 세 가지 코어 비교를 참고하세요.
• 실행 모드: 현재 시스템 프록시인지 TUN인지, 분기 모드가 규칙(Rule), 전역(Global), 직접 연결(Direct) 중 무엇인지 확인하세요. "이랬다저랬다" 하는 문제의 대다수는 모드 선택 오류입니다.
• 설정 출처: 구독 링크로 가져왔는지, 로컬 YAML 파일인지, 아니면 구독 변환 서비스를 거쳤는지 확인하세요. 변환된 설정은 변환 템플릿에서 발생한 문제도 추가로 고려해야 합니다.
• 문제 범위: 모든 웹사이트가 안 되는지 일부만 이상한지, 모든 기기에서 문제가 있는지 한 대에서만 그런지 확인하세요. 범위가 명확할수록 건너뛸 수 있는 챕터가 많아집니다.

로그 레벨을 debug로 조정하기

각 클라이언트는 로그 패널을 제공하며, 기본 레벨은 보통 info로 연결 수립과 규칙 매칭만 기록합니다. 진단 단계에서는 debug로 임시 조정하는 것을 권장합니다: DNS 조회 과정, 규칙 매칭 순서, 핸드셰이크 실패 원인이 모두 출력됩니다. 로컬 설정 파일의 해당 필드:

log-level: debug   # 진단이 끝나면 info로 되돌리세요. debug 로그는 양이 매우 많습니다

이분 탐색법

문제가 어느 계층에 있는지 확신이 안 될 때는 "비용이 적게 드는 것부터 큰 것까지" 순서로 하나씩 교체해 보세요: 먼저 노드 변경(단일 노드 장애 배제) → 전역 모드로 전환(분기 규칙 문제 배제) → 정상 작동이 확인된 다른 설정으로 교체(구독 문제 배제) → 마지막으로 클라이언트 또는 네트워크 환경 변경(로컬 기기와 로컬 네트워크 문제 배제). 각 단계마다 한 번씩 테스트하고, 어느 단계에서 문제가 사라지는지 확인하면 그 단계가 원인입니다.

↑ 목차로 돌아가기

인터넷 불가: 프록시를 켠 후 모든 웹사이트가 안 열림

증상 정의: 클라이언트는 연결됨으로 표시되지만 브라우저로 어떤 웹사이트에 접속해도 실패하며, 직접 연결로도 원래 열리던 사이트까지 포함됩니다. 이 유형의 핵심은 "트래픽이 애초에 프록시로 들어가지 않는지" 아니면 "프록시로 들어갔지만 출구가 막혔는지"를 먼저 구분하는 것이며, 둘의 해결법은 완전히 다릅니다.

1단계: curl로 로컬 프록시 포트 직접 테스트

브라우저와 시스템 프록시 설정을 건너뛰고 로컬 포트로 직접 요청을 보내면 코어 자체가 작동하는지 즉시 판단할 수 있습니다:

# 국내 접근 가능한 주소 테스트 (코어와 직접 연결 규칙 검증)
curl -I -x http://127.0.0.1:7890 https://www.baidu.com

# 204 감지 주소 테스트 (프록시 출구 검증)
curl -I -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204

결과는 세 가지로 나뉩니다: 둘 다 통과하면 코어는 정상이며 문제는 시스템 프록시 계층에 있으므로 7장으로 바로 이동하세요; 첫 번째만 통과하고 두 번째가 타임아웃이면 직접 연결은 정상이지만 프록시 출구가 막힌 것이므로 3장으로 이동해 노드를 진단하세요; 둘 다 연결 거부(connection refused)라면 코어가 이 포트를 리스닝하지 않는 것이므로 아래를 계속 확인하세요.

2단계: 포트가 리스닝되지 않는 세 가지 원인

• 설정 해석 실패로 코어가 시작조차 안 됨. 로그에 error 레벨의 YAML 해석 오류가 나타나며, 수동으로 설정을 수정할 때 들여쓰기가 어긋나거나 오리지널 코어가 Meta 전용 필드를 만난 경우가 흔합니다. 설정을 수정하거나 해당 문법을 지원하는 코어로 교체하세요.
• 포트가 다른 프로그램에 점유됨. 로그에 bind: address already in use가 표시됩니다. Windows는 netstat -ano | findstr 7890, Linux/macOS는 lsof -i :7890으로 점유 중인 프로세스를 찾아 종료하거나, 설정에서 mixed-port를 바꾸고 재시작하세요.
• 포트가 IPv6만 리스닝하거나 방화벽에 막힘. 설정에 비정상적인 bind-address가 적혀 있는지 확인하세요. Windows에서 처음 실행할 때 방화벽 허용 팝업을 거부했다면 "Windows 보안 → 방화벽 → 앱이 방화벽을 통과하도록 허용"에서 클라이언트를 수동으로 허용해야 합니다.

3단계: "프록시를 꺼도 인터넷이 안 되는" 잔여 문제 진단

클라이언트가 비정상 종료(크래시, 강제 종료)되면 시스템 프록시를 복원할 시간이 없어 시스템이 여전히 존재하지 않는 127.0.0.1 포트를 가리키게 되며, 결과적으로 "Clash를 안 켜면 오히려 인터넷이 안 됨"으로 나타납니다. 해결법: 클라이언트를 다시 시작하고 정상적으로 한 번 종료해 설정을 복원시키거나, 수동으로 정리하세요 — Windows는 "설정 → 네트워크 및 인터넷 → 프록시"에서 수동 프록시를 끄고, macOS는 "시스템 설정 → 네트워크 → 세부 정보 → 프록시"에서 항목을 하나씩 해제하세요. TUN 모드가 비정상 종료되면 가상 네트워크 카드 라우팅이 간혹 남을 수 있는데, 시스템을 재시작하면 정리됩니다.

↑ 목차로 돌아가기

노드 타임아웃: 지연 테스트가 모두 실패하거나 대부분 빨간불

클라이언트의 지연 테스트는 ping이 아니라 해당 노드를 통해 감지 URL(보통 HTTP 204를 반환하는 주소)에 완전한 요청을 보내고 시간을 측정하는 방식입니다. 따라서 "타임아웃"은 전체 프록시 체인 — 로컬 기기 → 노드 서버 → 감지 주소 — 중 최소 한 곳이 끊어졌다는 의미입니다.

모든 노드가 타임아웃일 때의 진단 순서

1. 먼저 로컬 네트워크 확인: 프록시를 끄고 국내 웹사이트에 직접 접속해보세요. 로컬 네트워크가 끊어져 있으면 모든 노드가 필연적으로 타임아웃되는데, 이는 가장 쉽게 놓치는 단계입니다.
2. 구독 만료 여부 확인: 서비스 제공사의 만료 또는 트래픽 소진 후 서버가 인증을 거부하며, 모든 노드가 동시에 타임아웃되는 것이 전형적인 특징입니다. 서비스 제공사의 사용자 패널에서 상태를 확인하고, 클라이언트 안에서 시간을 낭비하지 마세요.
3. 시스템 시간 확인: 일부 암호화 프로토콜은 시간 오차에 민감하며, 기기 시간이 표준 시간과 크게 차이 나면 핸드셰이크가 조용히 실패합니다. 휴대폰과 컴퓨터 모두 "시간 자동 설정"을 켜세요.
4. 감지 주소를 바꿔 재테스트: 감지 URL 자체가 차단되거나 불안정할 때는 정상인 노드도 타임아웃으로 표시됩니다. 클라이언트 설정에서 테스트 주소를 다른 204 엔드포인트로 바꿔 다시 테스트하세요.
5. 구독 업데이트: 서비스 제공사가 서버 IP나 포트를 변경하면 기존 설정의 노드는 자연히 모두 실패합니다. 구독을 수동으로 업데이트해 최신 노드 목록을 가져오세요. 업데이트가 실패하면 4장으로 이동하세요.

일부 노드 타임아웃: 정상 현상과 이상 현상의 경계

구독 서비스의 노드가 개별적으로 장애를 일으키는 것은 흔한 일이며, 소수 노드의 타임아웃은 별다른 처리 없이 사용 가능한 노드로 전환하면 됩니다. 경계해야 할 것은 같은 프로토콜의 노드가 집단으로 타임아웃되는 경우입니다 — 예를 들어 특정 프로토콜의 노드가 모두 죽고 다른 프로토콜은 정상이라면, 보통 해당 프로토콜의 특징이 현재 네트워크 환경에서 표적이 되고 있다는 뜻이므로 단기적으로 다른 프로토콜을 사용하고 서비스 제공사에 피드백하세요. 또 다른 패턴은 "유선은 타임아웃, 핫스팟은 정상" 또는 그 반대인데, 이는 로컬 네트워크가 특정 포트/프로토콜을 차단하고 있다는 것을 가리키며 회사, 학교 네트워크 환경에서 흔히 발생합니다.

테스트 수치 해석하기

또한 주의할 점: 지연이 낮다고 속도가 빠른 것은 아닙니다. 지연은 왕복 시간을 나타내며, 대역폭이 충분한지는 5장의 속도 측정 방법을 참고하세요. 자동 선택 그룹(url-test)은 주기적으로 자동 재테스트하고 전환하는데, 노드가 자주 바뀌는 문제도 5장에서 함께 다룹니다.

↑ 목차로 돌아가기

구독 실패: 가져오기 오류와 업데이트 실패 대응표

구독 문제는 두 단계로 나뉩니다: 처음 가져올 때 실패하는 것은 대부분 형식 문제이고, 이전에는 정상이었는데 특정 업데이트부터 실패하는 것은 대부분 네트워크 또는 서버 문제입니다. 먼저 클라이언트가 어떤 오류를 표시하는지 확인한 후 대응하세요.

오류 메시지 대응표

형식 문제: 먼저 받은 것이 무엇인지 구분하기

Clash 클라이언트는 YAML 구조의 설정만 인식하지만, 시중에 유통되는 구독에는 Base64 노드 목록과 각 프로토콜 전용 형식도 있습니다. Base64 구독을 그대로 Clash 클라이언트에 넣으면 "해석 실패"가 발생합니다. 구분법은 간단합니다: 브라우저에서 구독 링크를 열어보고, 반환된 내용이 proxies:, proxy-groups: 같은 필드로 시작하면 Clash 형식이고, 공백 없는 긴 문자와 숫자 뭉치면 Base64입니다. 형식 차이와 변환 원리는 블로그 글 Clash 구독 형식 상세 설명에서 자체 구축 변환 서비스 방법까지 완전히 다룹니다.

"이랬다저랬다" 하는 업데이트 실패

구독 도메인 자체가 일부 네트워크 환경에서 방해받는 것은 흔한 상황이며, 이 때문에 역설이 생깁니다: 구독을 업데이트하려면 프록시가 필요한데, 프록시 설정 자체가 구독에서 나옵니다. 대부분의 클라이언트는 "프록시를 통한 업데이트" 스위치를 제공하니 현재 상태에 따라 반대로 시도해보세요: 프록시가 사용 가능할 때는 켜서 업데이트하고, 프록시가 이미 실패했다면 끄고 직접 연결로 업데이트하세요. 둘 다 실패하면 휴대폰 데이터로 핫스팟을 켜서 컴퓨터를 한 번 업데이트하고, 사용 가능한 설정을 받아 프록시를 먼저 복구한 뒤 정상 네트워크로 전환하세요. 또한 일부 클라이언트는 구독 자동 업데이트 간격을 설정할 수 있는데, 12시간이나 24시간 간격으로 설정하면 충분합니다. 너무 빈번한 자동 업데이트는 서버가 속도 제한을 걸 때 오히려 실패를 유발하기 쉽습니다.

↑ 목차로 돌아가기

속도 저하: 연결은 되지만 대역폭이 기대에 못 미침

속도 문제 진단의 전제는 기준선을 세우는 것입니다: 먼저 프록시를 끄고 로컬 실제 속도를 한 번 측정하고, 프록시를 켜서 다시 측정해야 비교가 의미 있습니다. 로컬 실제 속도가 50 Mbps밖에 안 된다면 어떤 노드도 200 Mbps를 낼 수 없습니다.

병목이 어느 구간에 있는지 파악하기

1. 지역이 다른 노드로 여러 번 속도 테스트. 모든 노드가 비슷하게 느리다면 병목은 대부분 로컬에 있습니다(라우터 성능, 통신사 국제 출구, Wi-Fi 신호); 개별 노드만 느리다면 노드 자체의 부하나 회선 문제이며, 특히 피크 시간대(저녁)에 두드러집니다.
2. 프로토콜 오버헤드 비교. 같은 서버에서 다중 전송 캡슐화(예: WebSocket + TLS 조합)를 사용하는 프로토콜이 경량 프로토콜보다 처리량이 낮은 것은 정상적인 물리적 오버헤드이며 장애가 아닙니다.
3. 이중 프록시가 걸려 있는지 확인. 브라우저 플러그인 프록시, 시스템에 남아 있는 다른 VPN이 Clash와 겹치면 트래픽이 두 번 돌아가며 속도가 절반 이하로 떨어집니다. 진단 중에는 다른 모든 프록시 도구를 끄세요.

분기 오류로 인한 "가짜 속도 저하"

국내 웹사이트가 갑자기 느려지는 경우 대부분 노드 문제가 아니라 이 트래픽이 잘못 프록시로 보내진 것입니다. 흔한 원인은 GeoIP/GeoSite 데이터베이스가 오래되어 새로 추가된 국내 도메인과 IP 대역이 데이터베이스에 없어 규칙이 매칭되지 않고 기본 프록시로 빠지는 것입니다. 판단 방법: 프록시를 켜고 국내 웹사이트에 접속해 클라이언트의 연결 패널에서 이 연결이 DIRECT인지 프록시 그룹인지 확인하세요. 해결 방법(Geo 데이터베이스 업데이트, 규칙 적용 확인)은 블로그 글 GeoIP와 GeoSite 데이터베이스 업데이트 방법에 단계별로 설명되어 있습니다.

자동 선택 그룹의 파라미터 튜닝

url-test 자동 선택을 사용할 때 두 파라미터가 직접적으로 사용감에 영향을 줍니다: interval은 재테스트 주기를 결정하고, tolerance는 "새 노드가 현재 노드보다 몇 밀리초 빨라야 전환할지"를 결정합니다. tolerance를 설정하지 않거나 너무 작게 설정하면 몇 밀리초의 흔들림 때문에 노드가 빈번하게 전환되며, 전환할 때마다 기존 연결이 끊어져 체감상 "인터넷이 들쭉날쭉"하게 느껴집니다. 참고 예시:

proxy-groups:
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300      # 5분마다 재테스트
    tolerance: 60      # 새 노드가 60ms 이상 빨라야 전환
    proxies:
      - 노드A
      - 노드B
      - 노드C

↑ 목차로 돌아가기

DNS 문제: 해석 실패, 오염과 Fake-IP 부작용

DNS는 프록시 체인에서 가장 은밀한 계층입니다: 증상은 "일부 웹사이트가 안 열림", "처음 열 때 느리다가 이후 정상", "표시되는 IP 주소가 이상함" 등으로 나타나며 직접적으로 DNS 오류를 보여주지 않습니다. Clash의 두 가지 DNS 강화 모드를 이해하는 것이 진단의 전제입니다.

fake-ip와 redir-host의 차이

fake-ip 모드에서는 코어가 각 도메인 조회에 즉시 예약된 대역(기본값 198.18.0.0/16) 안의 가짜 IP를 반환하고, 실제 해석은 트래픽이 실제로 발생할 때 체인 원격지에서 완료됩니다 — 지연이 낮고 오염이 없어 현재 주류 클라이언트의 기본값입니다; 대가로 로컬 기기가 받는 IP는 실제 주소가 아니어서, 실제 IP에 의존하는 일부 프로그램(LAN 검색, 일부 게임 온라인 모드, 일부 은행 클라이언트)이 이상 작동할 수 있습니다. redir-host는 로컬에서 먼저 실제 해석을 완료한 뒤 규칙을 매칭하므로 호환성은 좋지만 해석 결과가 오염될 수 있습니다. 두 모드는 절대적인 우열이 없으니 증상에 따라 전환하세요.

전형적인 증상과 해결법

• 네트워크 전환 후 많은 웹사이트가 안 열리다가 클라이언트 재시작으로 복구: fake-ip 매핑 캐시가 새 네트워크 환경과 일치하지 않는 상태입니다. 대부분의 클라이언트는 "fake-ip 캐시 지우기" 버튼을 제공하거나, 코어를 직접 재시작하세요.
• LAN 기기(프린터, NAS) 접근 이상: LAN 도메인이 fake-ip에 넘어간 상태입니다. fake-ip-filter에서 로컬 도메인을 제외하세요. 아래 예시 참고.
• 프록시를 꺼도 DNS가 여전히 이상함: TUN 모드가 시스템 DNS를 넘겨받았는데 비정상 종료로 복원되지 않은 상태입니다. 시스템 네트워크 서비스를 재시작하거나 기기를 재부팅하세요.
• 특정 도메인이 명백히 잘못된 주소로 해석됨: 상위 DNS가 오염된 상태이니 nameserver를 암호화 DNS(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"
    - "+.msftconnecttest.com"   # 시스템 인터넷 연결 감지는 실제 해석 사용
  nameserver:
    - https://223.5.5.5/dns-query
    - https://120.53.53.53/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

이 기준의 아이디어: 국내 암호화 DNS로 주 해석을 하여 속도를 보장하고, 해외 DoH를 fallback으로 사용하며, fallback-filter가 GeoIP로 해석 결과의 소속을 판단합니다 — 결과가 CN 대역에 속하지 않으면 fallback의 답을 사용해 오염을 피합니다. 주의할 점은 fallback-filter가 GeoIP 데이터베이스에 의존하므로 데이터베이스가 오래되면 마찬가지로 오판이 발생할 수 있으며, 이는 5장에서 언급한 Geo 업데이트와 같은 사안입니다.

↑ 목차로 돌아가기

시스템 프록시 미작동: 브라우저는 정상인데 일부 앱만 프록시를 안 탐

증상 정의: 클라이언트는 정상 작동하고 브라우저도 모두 정상이지만, 일부 애플리케이션(명령줄 도구, 스토어 앱, 게임 클라이언트)의 트래픽이 전혀 프록시를 거치지 않습니다. 근본 원인은 "시스템 프록시"가 운영체제 수준의 제안값일 뿐이며, 애플리케이션이 이를 읽을 수도 안 읽을 수도 있고, 애플리케이션 유형별로 동작이 크게 다르다는 것입니다.

시스템 프록시를 읽지 않는 세 가지 애플리케이션 유형

명령줄 프로그램: 환경 변수 작성법

# Windows PowerShell (현재 세션에서만 유효)
$env:HTTP_PROXY  = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"

# Linux / macOS (shell 설정 파일에 작성하면 영구 적용)
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# 검증
curl -I https://www.gstatic.com/generate_204

UWP 앱: 루프백 제한 해제

Windows 스토어 앱은 기본적으로 127.0.0.1 접근이 금지되어 있어, 시스템 프록시가 로컬 포트를 가리킬 때 이런 앱은 곧바로 연결이 끊깁니다. 관리자 권한으로 CheckNetIsolation LoopbackExempt -a -n=<패키지 패밀리 이름>을 실행해 하나씩 예외 처리하거나, 그래픽 도구로 일괄 체크할 수 있습니다. 전체 조작 단계, 패키지 패밀리 이름 조회법과 검증 방법은 블로그 글 Windows UWP 앱이 프록시를 안 탈 때 해결법을 참고하세요.

근본 해결책: TUN 모드

TUN은 가상 네트워크 카드를 통해 네트워크 계층에서 모든 트래픽을 넘겨받으므로, 앱이 시스템 프록시를 읽는지 여부와 무관하게 작동하며 "일부 앱이 프록시를 안 타는" 문제의 근본적인 해결책입니다. 활성화 요점: 데스크톱에서는 가상 네트워크 카드 서비스를 설치하려면 관리자/root 권한이 필요합니다; 활성화 후에는 코어의 DNS 하이재킹도 함께 켜는 것을 권장합니다. 그렇지 않으면 앱이 자체적으로 DNS를 지정할 때 분기가 부정확해집니다; 다른 VPN 소프트웨어의 가상 네트워크 카드와는 상호 배타적이므로 동시에 하나만 켤 수 있습니다. Linux 환경의 TUN 배포 세부 사항은 블로그 글 Linux에서 Clash 설치 전 과정을 참고하세요.

↑ 목차로 돌아가기

클라이언트 크래시: 시작 실패, 강제종료와 리소스 이상

크래시 문제는 먼저 세 가지 형태로 구분하세요: 시작하자마자 종료되는 경우, 실행 중 무작위로 강제종료되는 경우, 그리고 종료되지 않았지만 메모리/CPU 사용량이 이상한 경우. 세 가지의 진단 진입점이 다릅니다.

시작하자마자 종료: 거의 모두 설정 문제

클라이언트 GUI 시작은 코어가 설정을 성공적으로 로드하는 것에 의존하며, 설정 해석에 실패하면 일부 클라이언트는 오류를 보고하지 않고 그냥 종료됩니다. 진단 방법: 설정 디렉터리의 활성 설정을 최소한으로 작동 가능한 설정(DIRECT 규칙 하나만 남김)으로 교체해보세요. 정상적으로 시작되면 설정 문제임이 증명되므로, 내용을 조금씩 다시 추가하며 오류 필드를 찾아내세요. 가장 흔한 유발 지점:

• YAML 들여쓰기 오류 — 수동 편집 후 공백을 더 넣거나 빼먹은 경우, YAML은 들여쓰기에 무관용;
• 코어 불일치 — 설정에서 Meta/mihomo 전용 필드(예: 일부 규칙 유형과 아웃바운드 프로토콜)를 사용했는데 클라이언트가 오리지널 코어를 실행 중인 경우. 필드 지원 범위 대조표는 코어 비교를 참고하세요;
• 규칙 세트/Geo 리소스 다운로드 불완전 — 첫 시작 시 외부 리소스를 가져와야 하는데 네트워크가 불통이면 일부 코어는 오류를 내며 종료됩니다. 먼저 직접 연결로 네트워크를 통하게 하여 초기화를 완료하세요.

실행 중 무작위 강제종료

1. 클라이언트 로그와 시스템 로그 확인: Windows는 이벤트 뷰어의 애플리케이션 로그, macOS는 콘솔의 크래시 리포트를 보고, GUI가 죽었는지 코어가 죽었는지 파악하세요. GUI가 죽고 코어는 살아 있으면(포트가 여전히 curl로 통함) 대부분 인터페이스 계층 문제이니 재설치하거나 클라이언트를 교체하세요; 코어가 죽으면 설정과 리소스를 중점적으로 확인하세요.
2. 대형 구독 진단: 수천 개 노드의 구독은 저사양 기기에서 해석과 지연 테스트 시 메모리 부담이 큽니다. 구독을 간소화하거나 자동 속도 테스트를 끄고 관찰하세요.
3. 보안 소프트웨어와의 충돌: 프록시 소프트웨어의 동작 특성은 오탐되기 쉬우므로, 클라이언트 디렉터리를 보안 소프트웨어의 화이트리스트에 추가한 후 재테스트하세요.

메모리/CPU 사용량 이상

연결 수는 사용량에 영향을 주는 첫 번째 요인입니다: P2P 다운로드처럼 순식간에 수천 개의 연결을 여는 상황에서는 메모리 상승이 정상 현상이며, 연결이 해제되면 다시 낮아져야 합니다. 지속적으로 낮아지지 않는다면 지나치게 촘촘한 자동 속도 테스트가 켜져 있는지 확인하세요(여러 url-test 그룹 × 짧은 interval × 많은 노드 = 지속적인 테스트 폭풍). interval을 300초 이상으로 늘리세요. 데스크톱 플랫폼에서 장기간 상주한다면 유지보수가 활발한 클라이언트를 우선 선택하세요 — 각 클라이언트의 유지보수 상태와 리소스 사용량 비교는 비교 평가 페이지를 참고하세요. 유지보수가 중단된 클라이언트(예: Clash for Windows)는 크래시가 발생해도 수정 경로가 없으니 Clash Plus나 Clash Verge Rev로 이전을 권장합니다.

↑ 목차로 돌아가기

Android 전용: 백그라운드 강제종료, VPN 충돌과 시스템 설정 간섭

Android용 프록시 클라이언트는 시스템 VpnService 형태로 실행되며, 장애 패턴이 데스크톱과 뚜렷이 다릅니다: 데스크톱의 문제는 대부분 설정 계층에 있지만, Android의 문제는 절반이 시스템의 백그라운드 서비스 관리에서 발생합니다. 이 챕터는 Clash Plus, Clash Meta for Android, FlClash 등 클라이언트의 공통 동작을 기준으로 합니다.

연결이 자주 자동 끊김: 백그라운드가 시스템에 의해 회수됨

화면을 잠근 지 시간이 지나면 프록시가 끊기고 알림 아이콘이 사라지는 것은 국내 제조사 ROM의 공격적인 절전 정책이 VPN 서비스를 강제종료하는 전형적인 현상입니다. 항목별로 설정하세요:

1. 시스템 설정 → 배터리 → 클라이언트 찾기 → "제한 없음/백그라운드 실행 허용"으로 변경, "자동 관리" 끄기;
2. 최근 작업 화면에서 클라이언트를 잠그기(대부분의 ROM이 아래로 당기거나 길게 눌러 잠그는 기능을 지원)해서 일괄 정리 시 실수로 종료되지 않도록 하기;
3. 시스템 설정 → 앱 → 클라이언트 → "자동 시작"과 "연관 시작" 허용;
4. 클라이언트 내에서 "부팅 시 자동 시작"을 켜고 시스템의 상시 연결 VPN(설정 → 네트워크 → VPN → 톱니바퀴 → 항상 켜진 VPN)을 함께 설정하면, 강제종료되어도 시스템이 자동으로 다시 시작시켜줍니다.

VPN 채널 충돌

Android는 한 번에 하나의 앱만 VPN 채널을 보유할 수 있습니다. 다른 VPN류 앱(일부 "가속기", "광고 차단" 도구 포함)이 실행되면 시스템이 조용히 Clash의 채널을 끊어버리며, 클라이언트 쪽에서는 "연결 끊김"만 보게 됩니다. 진단: 설정 → 네트워크 → VPN에서 현재 활성화된 VPN이 무엇인지 확인하고 충돌하는 앱을 비활성화하세요. 마찬가지로 "개인 DNS"(Private DNS)가 특정 호스트명으로 설정되어 있으면 DNS 조회가 클라이언트의 DNS 모듈을 건너뛰어 분기가 부정확해지므로, DNS 관련 문제를 진단할 때는 먼저 개인 DNS를 "자동" 또는 "끄기"로 설정하세요.

설치와 업데이트 문제

• "패키지 분석 중 오류 발생" 메시지: 다운로드한 APK가 기기 아키텍처와 맞지 않습니다. 최근 몇 년의 주류 기기는 모두 arm64-v8a 버전을 선택해야 하며, 매우 오래된 기기만 armeabi-v7a가 필요합니다. 아키텍처별 설치 파일은 다운로드 페이지 Android 영역에서 클라이언트별로 나열되어 있습니다; 다운로드 중단으로 파일이 불완전해도 같은 오류가 발생하므로 다시 다운로드하면 됩니다.
• 덮어쓰기 설치 실패: 서명이 일치하지 않으면(예: 다른 경로에서 다운로드한 동명 앱) 덮어쓸 수 없으므로 제거 후 재설치가 필요합니다. 재설치 전 클라이언트에서 설정을 내보내서 구독을 잃지 않도록 하세요.
• 설치 후 VPN 권한 팝업이 나타나지 않음: 일부 ROM이 권한 팝업을 차단하므로, 시스템 VPN 설정에서 해당 앱에 수동으로 권한을 부여하세요.

로그 수집: adb logcat

화면에서 원인을 찾을 수 없을 때는 adb로 실행 로그를 수집하세요. 컴퓨터에 플랫폼 도구를 설치하고 휴대폰에서 USB 디버깅을 켠 후:

# 오류 레벨 출력만 확인, 끊기는 순간의 오류 관찰
adb logcat *:E

# 앱 패키지명으로 필터링 (패키지명은 실제 설치된 클라이언트 기준)
adb shell pidof com.github.metacubex.clash.meta
adb logcat --pid <이전 단계에서 출력된 프로세스 번호>

로그에 VpnService revoked가 나타나면 채널을 다른 앱이 가로챈 것입니다; 메모리 관련 kill 기록이 나타나면 이 챕터 초반의 절전 정책 처리로 돌아가세요. 모바일에서 체계적인 초기 설정 흐름이 필요하다면 설정 가이드로 돌아가 단계별로 진행하세요. "설치했는데 바로 이상함" 문제의 대부분은 가이드의 메인 흐름에서 이미 피할 수 있습니다.

↑ 목차로 돌아가기

원하는 증상을 찾지 못했나요?

이 페이지는 명확한 재현 경로가 있는 8가지 문제를 다룹니다. 만약 문제가 여기 없다면: "처음 설정부터 안 됐다"에 속하면 설정 가이드로 돌아가 처음부터 확인하세요; 클라이언트 자체의 기능 한계라고 의심되면 비교 평가에서 사용 중인 클라이언트가 해당 기능을 지원하는지 확인하세요; 클라이언트를 교체하거나 추가 설치해야 한다면 다운로드 페이지로 이동하세요 — 전 플랫폼 1순위 추천은 Clash Plus이며, Android에서는 Clash Meta for Android와 FlClash도 선택할 수 있습니다. 프로토콜, 코어, 구독 관련 배경 지식과 전문 진단은 기술 노트에서 계속 업데이트됩니다.