SERVICE MANUAL · 증상별 진단

Clash 문제 해결 매뉴얼

이 페이지는 진단 작업대이지 입문 강좌가 아닙니다. Clash를 처음 설치했다면 먼저 튜토리얼 페이지에서 「구독 가져오기 → 모드 선택 → 연결 → 확인」 흐름을 한 번 따라가 보세요. 실행 후 문제가 생기면 이 페이지로 돌아와 증상별로 해당 장을 찾으면 됩니다. 아직 클라이언트가 없다면 다운로드 센터에서 받으세요. 전 플랫폼 공통으로 Clash Plus를 우선 추천합니다.

8개 장 모두 같은 방식입니다: 먼저 유형을 나누고, 원인을 짚고, 마지막에 해결법을 제시합니다. 처음부터 끝까지 읽지 말고 아래 표에서 증상을 찾아 바로 이동하세요.

발생한 증상	바로가기
Clash를 켜면 어떤 사이트도 열리지 않음	C1 · 인터넷 완전 불가
지연 목록이 전부 빨간색이거나 특정 노드가 계속 타임아웃	C2 · 노드 타임아웃
구독 가져오기 오류, 업데이트 실패, 가져온 내용이 깨짐	C3 · 구독 실패
연결은 되지만 동영상이 끊기고 다운로드가 느림	C4 · 속도 저하
일부 사이트는 즉시 열리고 일부는 로딩만 계속되거나 DNS 누출이 감지됨	C5 · DNS 문제
클라이언트는 연결됨으로 표시되지만 브라우저/터미널은 직접 연결됨	C6 · 시스템 프록시 미적용
클라이언트가 열리지 않거나 실행 즉시 종료됨	C7 · 강제 종료
휴대폰에서 백그라운드 연결 끊김, 권한 팝업, 연결 불가	C8 · 모바일 전용

C1 / 인터넷 완전 불가

인터넷 불가: 세 단계로 원인 계층 찾기

Clash를 켠 뒤 모든 사이트가 열리지 않는다면 노드부터 바꾸려 하지 마세요. 원인은 대체로 세 가지뿐입니다: 로컬 네트워크 자체가 끊긴 경우, 노드가 전부 다운된 경우, 규칙이 트래픽을 잘못된 곳으로 보낸 경우. 세 단계만 거치면 10분 안에 원인이 어느 계층에 있는지 특정할 수 있습니다.

1단계: 프록시를 끄고 로컬 네트워크 확인

시스템 프록시를 끄거나 클라이언트를 완전히 종료한 뒤, 평소 바로 열리던 한국 국내 사이트에 접속해 보세요. 열리지 않는다면 로컬 네트워크 문제이며 Clash와는 무관합니다 — 먼저 Wi-Fi, 라우터, 인터넷 회선을 점검하세요. 열린다면 회선은 정상이니 다음 단계로 넘어갑니다.

이 단계를 건너뛰고 오후 내내 클라이언트만 붙잡고 있다가 알고 보니 라우터 요금 문제로 재시작이 필요했던 경우도 흔합니다. 먼저 직접 연결로 전환해 확인하는 것이 프록시 문제 진단의 첫 번째 동작입니다.

2단계: 글로벌 모드로 전환해 규칙 배제

클라이언트를 글로벌 모드(GLOBAL)로 전환하고, 평소 안정적인 노드를 직접 선택한 뒤 프록시가 필요한 사이트에 접속해 보세요. 연결되면 노드는 정상이며 문제는 규칙 분기에 있는 것이므로 규칙 모드로 되돌리고 3단계로 넘어갑니다. 연결되지 않으면 노드 쪽이나 로컬 인바운드 문제이므로 C2 노드 타임아웃으로 바로 이동하세요.

글로벌 모드는 진단용일 뿐 원인을 찾은 뒤에는 규칙 모드로 다시 전환하세요. 글로벌 모드를 계속 유지하면 국내 트래픽까지 지구를 한 바퀴 돌게 되어 속도와 데이터 모두 손해입니다. 글로벌 모드와 규칙 모드의 선택 기준은 문제 해결에 별도로 정리되어 있습니다.

3단계: 로그를 열어 규칙 매칭 확인

설정에서 로그 레벨을 올린 뒤, 클라이언트의 연결/로그 패널에서 대상 도메인이 어느 규칙에 매칭되어 어떤 정책 그룹으로 보내졌는지, 정책 그룹이 현재 어떤 노드를 선택했는지 확인하세요. 흔한 사고 사례는 두 가지입니다: 최종 폴백 MATCH 규칙이 DIRECT를 가리켜 프록시가 필요한 트래픽이 전부 직접 연결되는 경우, 또는 특정 DOMAIN-SUFFIX 범위가 너무 넓어 직접 연결되면 안 되는 도메인까지 가져가 버리는 경우입니다.

# config.yaml: 진단 중에는 로그를 자세히, 완료 후 원래대로
log-level: debug
mode: rule

커널이 아예 실행되지 않은 것 같다면, 명령어로 로컬 인바운드 포트를 직접 확인해 보세요(포트 번호는 설정의 mixed-port 값을 따릅니다):

curl -x http://127.0.0.1:7890 -I https://www.gstatic.com/generate_204

정상이라면 204가 반환됩니다. curl조차 응답이 없다면 커널이 리스닝하지 않고 있다는 뜻입니다 — 설정 포트가 잘못됐거나 프로세스 자체가 실행되지 않은 것이니 C7 강제 종료로 이동하세요.

C2 / 노드 타임아웃

노드 타임아웃: 전체 빨간색과 일부 빨간색은 다른 문제

지연 테스트가 전부 빨간색이라면 먼저 유형을 나누세요: 모든 노드가 타임아웃되는 경우와 일부 노드만 타임아웃되는 경우는 원인이 완전히 다릅니다. 전체가 빨간색이면 대부분 내 쪽의 문제이고, 일부만 빨간색이면 노드 자체의 문제입니다.

전체 타임아웃: 먼저 내 쪽 확인

구독 만료 또는 트래픽 소진. 서비스 제공업체 패널에 로그인해 요금제 상태를 확인하세요. 전체 타임아웃의 가장 흔한 원인이며, 확인하는 데 10초밖에 안 걸리니 가장 먼저 체크할 가치가 있습니다.
테스트용 URL 자체가 차단됨. 지연 테스트에 쓰이는 URL(흔히 generate_204 계열)이 현재 네트워크에서 차단되면 실제로는 사용 가능한 노드도 전부 타임아웃으로 표시됩니다. 다른 테스트 URL로 다시 측정해 수치가 정상으로 돌아오면 이 원인이 맞습니다.
로컬 방화벽이 커널을 차단. Windows에서 처음 실행할 때 뜨는 방화벽 허용 팝업에서 「거부」를 눌렀다면, 이후 커널이 패킷을 내보내지 못해 전체 타임아웃이 발생합니다. 방화벽의 앱 허용 목록에서 커널 프로세스를 허용해 주세요.
시스템 시간 오차가 큼. 일부 암호화 프로토콜은 로컬 시간에 민감해 오차가 허용 범위를 넘으면 핸드셰이크가 바로 실패합니다. 시스템 시간 자동 동기화를 켜고 보정 후 다시 테스트하세요.

일부 타임아웃: 노드 자체의 문제

특정 노드가 계속 빨간색이면 대부분 서버가 다운됐거나 회선이 나빠진 경우이니 노드를 바꾸면 됩니다. 특정 지역의 노드가 전부 빨간색이면 보통 해당 국제 회선의 장애나 유지보수 때문이니 잠시 기다리거나 다른 지역 노드로 바꾸세요. 일부 타임아웃은 고칠 게 아니라 바꿀 문제입니다.

증상	가능성 높은 원인	처리 방법
모든 노드 타임아웃, 패널에는 요금제 정상 표시	테스트 URL 차단 또는 방화벽이 커널 차단	테스트 URL 변경, 커널 프로세스 허용
전체 타임아웃, 브라우저에 인증서 오류까지 표시	시스템 시간 오차	시간 자동 동기화 켜기
특정 지역 노드 전체가 빨간색	회선 장애	지역 변경 또는 회선 복구 대기
수치는 정상인데 실제로 연결 안 됨	규칙이 잘못된 출구로 전송	C1 3단계로 돌아가 로그 확인

지연 수치 해석 방법

지연 테스트는 HTTP 요청 한 번의 왕복 시간을 측정하는 것으로 대역폭과는 다릅니다. 80ms 노드가 10Mbps도 못 채울 수 있고, 200ms 노드가 오히려 최대 속도를 낼 수도 있습니다 — 지연은 「응답이 빠른가」를, 대역폭은 「다운로드가 빠른가」를 결정하는 별개의 지표입니다. 서로 다른 프로토콜의 지연을 비교 가능하게 만들려면 통합 지연을 켜세요:

# config.yaml
unified-delay: true
tcp-concurrent: true

자동 테스트 정책 그룹의 url, interval, tolerance 세 파라미터가 각각 무엇을 담당하는지는 블로그에 실측 글이 있습니다: url-test, fallback, load-balance 세 정책 그룹의 차이.

C3 / 구독 실패

구독 실패: 오류 메시지가 곧 진단서

구독을 가져오지 못할 때 클라이언트가 표시하는 오류 키워드가 원인을 거의 알려줍니다. 먼저 표에서 대조하고, 그다음 직접 확인하세요.

오류 키워드	의미	처리 방법
`404` / not found	구독 주소가 만료됐거나 제공업체가 재설정함	제공업체 패널에서 구독 링크를 다시 복사
`timeout` / 타임아웃	구독 도메인이 현재 네트워크에서 차단됐거나 응답이 느림	사용 가능한 노드로 프록시를 켜고 구독을 다시 업데이트
`403` / forbidden	제공업체가 요청 측 UA를 제한함	제공업체가 요구하는 클라이언트 유형으로 가져오기
invalid / yaml decode error	가져온 내용이 올바른 설정 형식이 아님	아래 방법으로 내용을 직접 확인

구독이 실제로 무엇을 반환하는지 직접 확인

클라이언트 오류 메시지가 모호할 때는 명령어로 구독을 로컬에 직접 받아서 확인하면 바로 명확해집니다:

curl -sSL -A "clash.meta" "https://구독-주소" -o sub.yaml
head -n 20 sub.yaml

앞쪽 몇 줄은 YAML 구조여야 합니다(proxies:, port:, proxy-groups: 같은 필드). <html>로 시작한다면 제공업체의 오류 페이지나 차단 페이지를 받은 것이고, 공백 없이 이어진 긴 문자열이라면 base64로 인코딩된 범용 구독을 받은 것이므로 구독 변환을 거쳐야 Clash에서 사용할 수 있습니다.

구독 변환의 장단점

변환 서비스는 구독 주소를 거쳐 가며, 구독 주소는 계정 인증 정보와 같습니다. 제공업체가 Clash용 구독을 직접 제공한다면 변환하지 마세요. 변환이 꼭 필요하다면 직접 구축한 변환 서비스를 우선하고, 그럴 수 없다면 믿을 수 있는 인스턴스만 사용하세요. 변환 후 노드가 전부 사라지거나 정책 그룹이 뒤섞인다면 대부분 변환 템플릿과 구독 형식이 맞지 않는 경우이니 템플릿을 바꿔 다시 시도하세요.

구독 주소 = 계정 인증 정보 그룹 채팅에 붙여넣지 말고, 출처가 불분명한 변환 사이트에 입력하지 말고, 링크가 포함된 스크린샷도 공유하지 마세요. 유출됐다면 즉시 패널에서 구독을 재설정해 기존 링크를 무효화하세요.

C4 / 속도 저하

속도 저하: 먼저 기준을 세우고 최적화는 그다음

'느리다'는 가장 오해를 사기 쉬운 증상입니다. 기준을 세우지 않으면 모든 최적화는 감에 의존하게 됩니다. 먼저 두 번 속도를 측정하세요: 한 번은 직접 연결, 한 번은 프록시 경유. 두 수치의 차이가 바로 프록시 경로가 유발하는 손실입니다.

기준값 해석 방법

프록시 속도가 직접 연결의 30% 이하라면 더 살펴볼 가치가 있습니다. 10~20% 정도의 차이라면 대체로 노드의 물리적 한계입니다 — 국제 회선의 대역폭은 원래 국내 초고속인터넷보다 훨씬 비싸므로, 프록시 속도가 직접 연결과 같아지길 기대하지는 마세요.

흔한 병목 세 가지, 순서대로 배제하기

노드 측: 대역폭이 작거나 야간 피크 시간에 회선이 혼잡한 경우입니다. 시간대를 바꿔 다시 측정해 낮에는 빠르고 밤에는 느리다면 회선 혼잡으로 판단할 수 있습니다. 노드나 요금제를 바꿔야 하며, 로컬에서 아무리 조정해도 효과가 없습니다.
프로토콜 측: 전송 프로토콜마다 오버헤드와 방해 저항력이 크게 다릅니다. UDP가 노드나 회선에서 제한되면 영상 통화나 QUIC에 의존하는 일부 앱의 성능이 크게 떨어집니다. 같은 서버에서 프로토콜을 바꿔 비교하거나 노드가 UDP 포워딩을 지원하는지 확인하세요.
로컬 측: 라우터에 이미 프록시 한 겹이 걸려 있는데 컴퓨터에서 또 한 겹을 켜면 이중 암호화로 손실이 두 배가 됩니다. 오래된 기기가 무거운 암호화 프로토콜을 돌리면 CPU가 먼저 한계에 도달합니다. 한 겹으로 충분하니 여러 겹 쌓지 마세요.

커널 쪽에는 비용 없이 켤 수 있는 유용한 옵션이 두 가지 있습니다: 동시 핸드셰이크는 연결 수립 시간을 줄이고, 통합 지연은 측정값을 실제 체감에 더 가깝게 만듭니다:

# config.yaml
tcp-concurrent: true
unified-delay: true

피크 시간대 저속 문제의 구조적 해법

노드를 직접 바꾸는 것은 임시 대응이고, 정책 그룹을 구성하는 것은 근본적인 해법입니다. 자주 쓰는 지역의 노드 여러 개를 자동 테스트 그룹으로 묶고, tolerance로 흔들림 방지 임계값을 설정해 두 노드의 지연이 비슷할 때 계속 오가는 현상을 막으세요:

proxy-groups:
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies: [노드A, 노드B, 노드C]

대용량 다운로드 상황에서는 로드 밸런싱 그룹으로 트래픽을 여러 노드에 분산하는 것도 고려할 수 있습니다. 세 가지 정책 그룹 유형을 어떻게 선택할지는 블로그 실측 글을 참고하세요: url-test, fallback, load-balance 차이.

C5 / DNS 문제

DNS 문제: '이유를 알 수 없는 장애'의 절반이 여기서 발생

DNS 장애의 전형적인 모습은 이렇습니다: 어떤 사이트는 바로 열리고 어떤 사이트는 계속 로딩만 되거나, 프록시는 분명 연결됐는데 검사 사이트에서는 해석 출구가 로컬 통신사로 나오거나, 노드를 바꿔도 어떤 사이트는 좋아지고 어떤 사이트는 여전히 문제인 경우입니다. 겉보기엔 무작위 같은 현상이지만 대부분 원인은 해석 계층에 있습니다.

두 가지 해석 모드, 먼저 이해하고 조정하기

Clash 계열 커널에는 두 가지 향상된 해석 모드가 있습니다. redir-host는 전통적인 방식으로 도메인을 실제 IP로 먼저 해석한 뒤 규칙을 매칭합니다. 해석 경로가 길어 로컬 단계에서 누출되기 쉽습니다. fake-ip는 커널이 예약된 네트워크 대역의 「가상 주소」를 바로 반환하고(기본값 198.18.0.0/16), 실제 해석은 프록시 출구 쪽에서 처리합니다 — 연결 수립이 더 빠르고 로컬에서 평문 조회가 발생하지 않아 현재 더 권장되는 기본 선택입니다.

바로 적용 가능한 dns 설정

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
  nameserver:
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query

한 줄씩 설명하면: fake-ip-filter는 면제 목록으로, 나열된 도메인에는 가상 주소를 내보내지 않으며 LAN 기기 검색, 프린터처럼 실제 주소가 반드시 필요한 경우에 사용합니다. nameserver는 암호화 DNS로 일반적인 해석을 처리하고 fallback은 해외 도메인을 위한 대체 경로입니다. 두 그룹의 역할이 다르니 모든 도메인을 같은 상위 서버에 몰아넣지 마세요.

누출 자가 점검 두 가지 방법

프록시가 연결됐다고 해서 DNS가 누출되지 않았다는 뜻은 아닙니다. 빠른 방법: 온라인 DNS 누출 검사 사이트를 열어 해석 출구의 소속이 로컬 통신사로 나오는지 확인하세요. 확실한 방법: 로컬에서 패킷을 캡처해 53번 포트에서 평문 조회가 그대로 나가는지 관찰하세요. 두 방법의 전체 절차와 누출 방지 설정법은 블로그에 실습 글이 있습니다: Clash DNS 누출 검사와 fake-ip 누출 방지 설정.

fake-ip의 부작용과 해법

fake-ip에도 대가가 있습니다: 일부 앱이 가상 주소를 캐시해 버려, Clash를 끄고 직접 연결로 전환한 뒤에도 198.18로 시작하는 주소를 계속 붙잡고 있다가 접속이 막힙니다. 「프록시를 끄니 오히려 인터넷이 안 된다」는 증상으로 나타납니다. 해법은 시스템 DNS 캐시를 새로 고치는 것입니다:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

경험 법칙 게임 플랫폼, LAN 화면 공유, NAS처럼 실제 IP에 민감한 도메인은 모두 fake-ip-filter에 추가하세요. 면제 목록은 넓게 잡는 편이 안전합니다. 프린터까지 프록시에 주소를 물어보게 만들지 마세요.

C6 / 시스템 프록시 미적용

시스템 프록시 미적용: 안내문일 뿐 강제력은 없다

먼저 원리를 짚습니다: 「시스템 프록시」는 운영체제가 붙여둔 안내문일 뿐입니다 — 「127.0.0.1의 이 포트를 이용하는 것을 권장합니다」라는 뜻입니다. 앱은 이를 볼 수도 있고 못 본 척할 수도 있습니다. 브라우저는 대체로 참고하지만 터미널은 애초에 참고하지 않으며, 일부 클라이언트 소프트웨어는 자체 방식을 사용합니다. 그래서 이 장은 대상별로 나눠 진단해야 합니다.

브라우저가 프록시를 타지 않을 때

브라우저의 프록시 설정이 「시스템 프록시 사용」인지 확인하세요. Firefox는 기본적으로 자체 프록시 설정을 사용하며 시스템 설정을 읽지 않으므로 127.0.0.1과 해당 포트를 직접 지정해야 합니다.
프록시 관련 확장 프로그램은 시스템 설정을 덮어씁니다. SwitchyOmega 같은 확장을 설치했다면 먼저 비활성화한 뒤 다시 테스트하세요 — 확장에 남아 있는 이전 규칙이 이 증상의 가장 흔한 원인입니다.
다른 브라우저로 교차 확인하세요: A 브라우저는 연결되고 B 브라우저는 안 된다면 문제는 확실히 B 자체의 설정에 있으니 클라이언트를 더 만지지 마세요.

터미널이 프록시를 타지 않을 때

터미널 프로그램은 환경 변수만 인식하고 시스템 안내문은 참고하지 않습니다. Clash를 켠 상태에서도 curl, git, 패키지 매니저가 여전히 직접 연결되는 것은 정상이며 고장이 아닙니다. 현재 세션에 수동으로 걸어 주세요:

# macOS / Linux(현재 세션에만 적용, 포트는 설정값에 맞춰 조정)
export https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890 all_proxy=socks5://127.0.0.1:7890

# Windows PowerShell
$env:HTTP_PROXY  = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"

git, docker 같은 도구는 자체 프록시 설정 항목을 따로 갖고 있어 환경 변수만으로는 모두 커버되지 않을 수 있으니, 연결이 안 될 때는 각 도구의 설정 파일도 확인해 보세요.

TUN 모드: 모든 트래픽을 한 번에 인수

앱마다 일일이 손볼 필요 없이 TUN 모드를 쓰면 됩니다: 커널이 가상 네트워크 카드를 만들어 네트워크 계층에서 모든 트래픽을 직접 인수하므로 못 본 척할 여지가 없습니다. 대가로 관리자 권한이나 시스템 승인이 필요하며, 처음 켤 때 가상 네트워크 카드 설치 확인 단계가 나타납니다. TUN을 켠 뒤에는 시스템 프록시 스위치를 꺼서 트래픽이 두 번 처리되는 것을 피하세요. 브라우저와 터미널의 전체 분기 진단 기록은 블로그를 참고하세요: 시스템 프록시 미적용 시 브라우저와 터미널 분기 진단.

C7 / 강제 종료

강제 종료: 4단계로 대부분 해결

클라이언트가 열리지 않거나 실행 즉시 종료되는 문제는 90%가 세 가지에서 비롯됩니다: 설정 파싱 실패, 포트 점유, 이전 비정상 종료 시 남은 커널 잔류 프로세스. 아래 4단계를 순서대로 따라가세요, 건너뛰지 마세요.

1단계: 로그 확인

강제 종료에도 유언은 있습니다. 유언은 모두 로그에 남습니다. 클라이언트 설정에서 「로그 디렉토리 열기」나 「앱 디렉토리 열기」를 찾아 로그의 마지막 몇 줄을 확인하세요. YAML 파싱 실패는 줄 번호와 필드명을 바로 알려주고, 포트 충돌은 address already in use라고 표시됩니다. 오류 메시지를 따라가는 것이 무작정 추측하는 것보다 열 배는 빠릅니다.

2단계: 설정 검증

클라이언트의 「새 빈 설정 만들기」나 기본 설정 복원 기능으로 한 번 실행해 보세요. 정상적으로 실행된다면 원인은 설정 파일에 있으므로 로그가 알려준 줄 번호로 돌아가 YAML을 수정하세요. 흔한 오류는 세 가지뿐입니다: 들여쓰기에 탭과 공백이 섞임, 복사·붙여넣기 시 전각 인용부호가 섞여 들어감, 인용부호가 필요한 필드값에 넣지 않음. 고치기 어렵다면 구독을 다시 가져와 제공업체의 원본 설정으로 로컬 변경 사항을 덮어쓰세요.

3단계: 포트 확인

커널이 리스닝하려는 포트를 다른 프로그램이 점유하고 있으면 실행이 바로 실패합니다. 누가 점유하고 있는지 확인하세요(포트 번호는 설정값으로 교체):

# Windows
netstat -ano | findstr 7890

# macOS / Linux
lsof -i :7890

점유 중인 프로세스를 찾았다면 종료하거나, Clash의 포트를 바꾸세요: 설정의 mixed-port를 비어 있는 값으로 수정하고 저장 후 재시작하세요.

4단계: 잔류 프로세스 정리

지난번 비정상 종료 시 커널 프로세스가 함께 죽지 않고 포트와 TUN 가상 네트워크 카드를 계속 점유하고 있으면, 새 인스턴스가 실행될 때 충돌이 발생합니다. 수동으로 한 번 정리하세요:

# Windows(프로세스명은 작업 관리자에 표시되는 실제 이름 기준)
taskkill /f /im mihomo*

# macOS / Linux
pkill -f mihomo

4단계를 모두 마쳐도 해결되지 않으면 마지막 방법으로 완전히 제거한 뒤 다운로드 센터에서 최신 버전을 다시 설치해 손상된 실행 환경을 통째로 교체하세요. Windows와 macOS 각각의 흔한 충돌 사례는 블로그에 별도로 정리했습니다: 실행 시 강제 종료의 로그 기반 원인 파악과 수정 절차.

C8 / 모바일 전용

모바일 전용: Android와 iOS는 각자 다른 특성이 있음

모바일 기기의 문제는 데스크톱과 논리가 다릅니다: Android는 권한과 백그라운드 관리에 문제가 집중되고, iOS는 시스템 VPN 프레임워크의 상태 동기화에 문제가 집중됩니다. 나눠서 설명합니다.

Android: 세 가지만 관리하면 90% 해결

VpnService 권한. Android용 Clash는 시스템의 VpnService로 로컬 터널을 만들며, 첫 연결 시 반드시 「연결 요청」 권한 창이 뜨는데 반드시 허용을 눌러야 합니다. 잘못해서 거부를 눌렀다면 시스템 설정의 VPN 페이지에서 해당 앱의 VPN 설정을 삭제하고 클라이언트로 돌아가 다시 연결하면 권한 창이 다시 나타납니다.
절전 화이트리스트. 중국산 커스텀 ROM의 백그라운드 정리 기능은 매우 강력해서 커널 프로세스가 종료되면 곧 연결이 끊기며, 「화면을 잠근 지 몇 분 후 인터넷이 끊긴다」는 증상으로 나타납니다. 클라이언트를 절전 화이트리스트에 추가하고 자동 실행을 허용하는 것은 Android에서 반드시 해야 할 작업입니다. 주요 제조사 시스템별 설정 경로는 블로그에 정리해 두었습니다: VpnService 권한과 절전 화이트리스트.
앱별 프록시. 지정한 앱만 터널을 통과시키고 나머지는 직접 연결하게 할 수 있습니다. 배터리도 절약되고 특정 앱과 VPN 터널 간의 호환성 문제도 피할 수 있습니다 — 어떤 앱이 프록시를 켜면 오작동한다면 먼저 터널에서 제외해 보세요.

Android 설치 파일은 다운로드 센터 Android 섹션에서 받으세요. Clash Plus를 우선 추천합니다.

iOS: 상태는 시스템 설정이 기준

iOS는 시스템의 Network Extension 프레임워크를 사용하며 클라이언트는 App Store에서 설치합니다. Clash Plus를 우선 추천합니다. 흔한 문제 두 가지:

스위치 상태 불일치. 앱 내에서는 연결됨으로 표시되지만 상태 표시줄에 VPN 아이콘이 없는 경우 — 시스템 설정이 기준이므로 「설정 → VPN」에서 해당 설정의 스위치를 직접 켜세요.
이전 설정 잔류로 충돌. 여러 프록시 앱을 설치했던 기기는 시스템 VPN 목록에 설정이 여러 개 쌓여 서로 인수 권한을 다투게 됩니다. 더 이상 쓰지 않는 설정을 모두 삭제하고 현재 사용 중인 것만 남기세요.

모바일 공통 안내 휴대폰이 Wi-Fi와 셀룰러 네트워크를 전환할 때 터널이 재구성되면서 몇 초간 끊기는 것은 정상 현상입니다. 계속 끊긴다면 이 장의 절차를 따라 진단하세요.

EXIT · 다른 경로로

확인해도 안 될 때?

증상이 딱 맞지 않는다면 세 가지 방법이 있습니다: 문제 해결에서 키워드로 검색하거나, 클라이언트 자체가 맞지 않는 것 같다면 클라이언트 비교에서 다른 것을 골라보거나, 주제별로 깊이 파고들고 싶다면 아티클 목록의 글마다 하나의 주제를 집중적으로 다룹니다. 그래도 안 되면 재설치가 언제나 마지막 만능 해법입니다.

Clash 다운로드 튜토리얼로 돌아가기