Clash 문제 해결 총정리

공통 진단 절차: 문제가 어느 단계에 있는지 먼저 확인

「작동 안 함」이라는 말만으로는 정보가 너무 부족합니다. Clash가 네트워크 요청 하나를 처리할 때는 네 단계를 거칩니다. 클라이언트와 커널이 트래픽을 주고받고, 시스템 프록시가 어떤 트래픽을 넘길지 결정하고, 노드 링크가 트래픽을 해외로 내보내고, 규칙과 DNS가 각 연결의 실제 경로를 정합니다. 이 중 어느 한 단계라도 끊기면 브라우저에는 똑같이 「접속 불가」로 보입니다. 문제 해결의 핵심은 문제를 정확히 어느 단계로 좁힌 뒤 그에 맞는 조치를 취하는 것입니다—단계 판단이 틀리면 서버(기)를 열 개 바꿔도 시스템 프록시가 설정 안 된 문제는 해결되지 않습니다.

1단계 확인: 로그와 포트

클라이언트의 로그 페이지를 열고 레벨을 info로 맞추세요. 커널이 정상이면 설정 로드와 포트 리스닝 기록이 보입니다. 로그가 텅 비어 있거나 계속 에러만 뜬다면 문제는 클라이언트 자체에 있으니 바로 8장으로 넘어가세요. 로그에서 눈에 익혀둘 만한 키워드가 몇 가지 있습니다. bind 관련은 대부분 포트 충돌, parse 관련은 설정 파싱 실패, dial 관련은 노드 연결 실패를 의미합니다. 다음 명령어로 포트 리스닝 여부를 다시 확인하세요.

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

HTTP 204가 반환되면 클라이언트, 노드, 규칙까지 전체 링크가 정상이며 문제는 시스템 프록시나 브라우저 단계에 있다는 뜻입니다. 타임아웃이나 연결 거부가 뜨면 계속해서 노드와 규칙을 확인하세요. 이 명령어는 매뉴얼 전체에서 가장 자주 쓰이는 확인 방법이니 꼭 기억해 두세요.

이분법 배제법

세 단계로 원인을 최소 범위까지 좁힐 수 있습니다. 노드 교체(단일 노드 문제 배제) → 네트워크 교체(휴대폰 테더링으로 전환해 유선망 차단 배제) → 기기 교체(휴대폰에서 같은 구독을 가져와 본체 환경 문제 배제). 각 단계마다 변수를 하나씩만 바꾸면 결과를 바로 읽을 수 있습니다. 세 단계를 모두 마치면 원인은 거의 하나로 좁혀집니다.

증상별 빠른 검색표

절차를 다 읽고 싶지 않다면 증상별로 바로 해당 챕터로 이동하세요.

인터넷 접속 안 됨: 프록시는 켜져 있지만 웹페이지가 안 열림

가장 흔한 증상입니다. 클라이언트 스위치는 모두 켜져 있는데 브라우저는 전부 타임아웃됩니다. 아래 순서대로 진행하세요. 각 단계마다 명확한 「통과/불통과」 기준이 있으니 단계를 건너뛰지 마세요.

1단계: 클라이언트-노드 간 링크 확인

앞 장의 curl 명령어로 확인하세요. 통과하면 클라이언트, 노드, 규칙 모두 정상이니 바로 3단계 시스템 프록시 확인으로 넘어가세요. 통과하지 않으면 2단계를 계속 진행하세요.

2단계: 프록시 모드와 노드 확인

클라이언트에는 보통 세 가지 모드가 있습니다. 글로벌(모든 트래픽을 프록시로), 규칙(규칙에 따라 분배), 직접 연결(전부 프록시 우회). 「직접 연결」을 잘못 눌렀을 때의 증상이 바로 「켰는데 안 켠 것과 같음」입니다. 먼저 글로벌 모드로 바꿔서 테스트하세요. 글로벌에서 웹페이지가 열리면 링크는 정상이며, 규칙이 해당 사이트를 직접 연결이나 실패한 노드 그룹으로 보낸 것이니 규칙과 정책 그룹을 다시 정리하세요. 글로벌에서도 안 되면 노드를 바꿔서 테스트하고, 모든 노드가 안 되면 3장을 참고하세요.

3단계: 시스템 프록시가 실제로 적용되었는지 확인

Windows: 설정 → 네트워크 및 인터넷 → 프록시에서 「프록시 서버 사용」이 켜져 있어야 하며, 주소는 127.0.0.1, 포트는 클라이언트의 혼합 포트와 일치해야 합니다(기본값 7890). 보안 소프트웨어나 다른 유틸리티가 이 설정을 되돌리는 경우가 흔합니다. macOS: 시스템 설정 → 네트워크 → 현재 네트워크 어댑터 → 세부사항 → 프록시에서 웹 프록시와 보안 웹 프록시의 체크 상태와 포트를 확인하세요. 이 항목에 대한 자세한 진단은 7장을 참고하세요.

4단계: 방화벽과 보안 소프트웨어

Windows 방화벽이나 서드파티 백신이 커널 프로세스의 네트워크 접근을 막을 수 있습니다. 처음 실행할 때 뜨는 「접근 허용」 팝업에서 거부를 눌렀다면, 클라이언트는 실행 중인 것처럼 보여도 패킷이 하나도 나가지 못합니다. 방화벽 허용 목록에 클라이언트와 커널 프로세스를 추가하거나, 클라이언트를 재설치하면서 팝업에서 허용을 누르세요.

노드 타임아웃: 지연시간 테스트가 전부 Timeout

지연시간 테스트가 전부 빨갛다고 당황하지 마세요. 「전체 실패」와 「일부만 실패」는 완전히 다른 두 가지 문제이며, 해결 경로도 전혀 다릅니다.

전체 실패: 로컬 환경이나 구독의 문제

모든 노드가 동시에 Timeout이라면, 노드가 전부 다운된 게 아니라 다음이 원인일 가능성이 큽니다. 로컬 네트워크 차단(유선망, 학교/회사 네트워크가 프록시 포트를 막음), 요금제 만료 또는 트래픽 소진, 시스템 시간 오류. 먼저 휴대폰 테더링으로 바꿔서 테스트해 보세요. 테더링에서는 전부 정상이면 유선망 문제이니, 프로토콜 종류를 바꾸거나(예: Trojan에서 Hysteria2로) 포트 특성이 다른 노드로 바꾸세요.

시스템 시간 오차는 숨은 원인

Trojan, VLESS, Hysteria 같은 프로토콜은 모두 TLS 기반이며, 핸드셰이크 시 인증서 유효기간을 검증합니다. 시스템 시간이 실제 시간과 몇 분만 어긋나도 모든 TLS 노드에서 핸드셰이크가 동시에 실패하며, 증상은 노드 전체 다운과 똑같이 나타납니다. 시간 동기화 명령어:

# Windows(관리자 권한 터미널)
w32tm /resync

# macOS
sudo sntp -sS time.apple.com

# Linux
timedatectl set-ntp true

시간을 맞춘 후 클라이언트를 재시작해서 다시 테스트하세요. 오랫동안 네트워크에 연결되지 않아 시간 동기화가 안 된 기기(공유기형 라우터, 장기간 꺼둔 낡은 기기)가 특히 이 문제를 겪기 쉽습니다.

일부만 실패: 노드 자체 문제

일부 노드만 타임아웃이라면 보통 해당 노드가 다운되었거나, 통신사에 의해 표적 차단되었거나, 로컬 네트워크가 해당 노드의 프로토콜 특성을 감지한 경우입니다. 바로 노드를 바꾸세요. 같은 지역의 노드가 전부 실패하면 지역을 바꾸세요. 지연시간 테스트의 원리를 알아두세요: 클라이언트가 테스트 URL로 HTTPS 요청을 보내고 시간을 재는 방식이며 ICMP ping이 아닙니다. 테스트 주소 자체가 접속 불가능하면 Timeout으로 표시될 수 있으니, 설정에서 테스트 URL을 더 안정적인 주소로 바꿔서 다시 확인하세요.

요금제와 구독 상태

서비스 요금제가 만료되거나 트래픽이 소진되면 구독 링크와 노드 목록은 그대로 있지만 전부 사용할 수 없게 됩니다. 서비스 관리 페이지에 로그인해 요금제 상태를 확인하세요. 일부 클라이언트는 구독 응답의 트래픽 정보 헤더를 표시해 주니 함께 확인하면 좋습니다. 구독 자체가 갱신되지 않는 경우는 4장을 참고하세요.

구독 실패: 구독 갱신 에러

「갱신 실패」는 겉으로 보이는 현상일 뿐이며, 클라이언트는 보통 더 구체적인 원인을 함께 표시합니다. 네트워크 오류(timeout, connection refused), 파싱 실패(yaml, base64), HTTP 상태 코드(403, 404). 먼저 에러 메시지를 전부 읽고, 해당 항목을 찾아보세요.

구독 링크 자체 확인

구독 링크를 그대로 브라우저 주소창에 붙여넣으세요. 텍스트 파일이 다운로드되면 링크가 유효한 것입니다. 403은 대부분 토큰 만료나 요금제 만료, 404는 링크 오타나 구독 재설정입니다. 수동 복사는 문자가 빠지거나 공백이 섞이기 쉬우니 서비스 관리 페이지에서 전체 링크를 다시 복사하세요. 일반적인 구독 링크는 이런 형태입니다:

https://example.com/api/v1/client/subscribe?token=xxxx

토큰은 접속 인증 정보이며, 유출되면 요금제를 그대로 남에게 넘기는 것과 같으니 진단 중에 전체 링크를 공개된 곳에 올리지 마세요.

구독 도메인이 차단된 경우

구독 서버의 도메인 자체가 차단된 경우 직접 연결로는 갱신이 반드시 실패합니다. 두 가지 방법이 있습니다. 클라이언트 설정에서 「프록시를 통해 구독 갱신」(클라이언트마다 명칭이 조금 다름)을 켜거나, 임시 노드로 먼저 프록시에 연결한 뒤 구독을 갱신하세요. 갱신에 성공하면 구독 안의 노드들을 정상적으로 사용할 수 있습니다.

형식과 파싱 문제

구독이 반환하는 내용은 Clash가 인식할 수 있는 YAML 설정이거나 변환 가능한 노드 목록이어야 합니다. 서비스가 범용 v2ray 구독만 제공한다면 「Clash 구독」 전용 링크나 구독 변환 서비스를 사용해야 합니다. 구독 파일을 직접 수정한 경우 YAML 들여쓰기에 주의하세요. 들여쓰기가 틀리면 파싱 실패로 나타납니다.

자동 갱신 주기

노드 목록은 서비스 측 조정에 따라 수시로 바뀌며, 오랫동안 갱신하지 않으면 「노드는 다 있는데 전부 사용 불가」로 보이는 현상이 생길 수 있습니다. 클라이언트 설정에서 자동 갱신을 켜고 주기는 24시간 전후로 두는 것이 좋습니다—너무 오래되지도, 너무 자주 방해받지도 않습니다. 구체적인 설정 위치와 실패 원인별 상세 진단은 블로그 문서 《Clash 구독 갱신 실패의 흔한 원인과 자동 갱신 설정 방법》을 참고하세요.

속도 저하: 사용은 되지만 끊김

느림은 상대적인 문제입니다. 링크는 정상이지만 체감이 나쁜 상태입니다. 먼저 병목 구간을 파악한 뒤 노드를 바꿀지, 프로토콜을 바꿀지, 규칙을 손댈지 결정하세요.

3단계 병목 진단

한 연결의 속도는 세 구간 중 가장 좁은 구간에 좌우됩니다. 로컬-노드 구간, 노드 자체 대역폭, 노드-목적지 구간. 판단 방법: 같은 노드에서 여러 목적지 사이트에 접속해 봤을 때—일부 사이트만 느리면 병목은 노드-해당 사이트 구간 회선, 모든 사이트가 느리면 노드를 바꿔서 비교—바꾸고 나서 크게 나아지면 노드 대역폭이나 로컬-노드 구간 문제, 바꿔도 계속 느리면 로컬 네트워크와 클라이언트 자체를 확인하세요.

지연시간이 낮다고 속도가 빠른 건 아님

지연시간은 「반응이 빠른가」를 결정하고, 대역폭은 「길이 넓은가」를 결정합니다. 저녁 피크 시간대에는 지연시간이 낮은 노드도 여전히 혼잡할 수 있습니다. 속도는 실제 다운로드나 영상 로딩 상태로 판단해야 하며, 지연시간 숫자만 보고 노드를 고르지 마세요—지연시간 50ms 노드와 150ms 노드가 영상 재생에서는 차이가 없을 수도 있습니다.

정책 그룹 선택

url-test 정책 그룹은 지연시간이 가장 낮은 노드를 자동 선택하지만 가장 혼잡한 노드를 고를 수도 있습니다. 로드 밸런싱은 연결을 여러 노드로 분산해 다운로드 같은 상황에 적합합니다. 수동 선택이 가장 제어하기 쉬운데, 지연시간이 비슷한 노드 몇 개를 번갈아 써보며 현재 시간대에 가장 안정적인 노드를 찾으세요. 목적지 사이트가 규칙에 의해 우회 경로의 노드 그룹으로 분배되면서 느려지는 경우도 있으니, 연결 패널을 열어 이 연결이 실제로 어떤 규칙과 노드를 탔는지 확인하고 필요하면 규칙 순서를 조정하거나 해당 사이트에 고정 노드를 지정하세요.

프로토콜과 커널 차이

UDP 기반 신규 프로토콜(Hysteria2, TUIC)은 패킷 손실과 지터가 큰 회선에서 전통적인 TCP 기반 프로토콜보다 확실히 덜 끊깁니다. mihomo 커널은 이 두 프로토콜을 완전히 지원하며, 데스크톱에서 가장 추천하는 Clash Plus와 Clash Verge Rev, FlClash 모두 mihomo를 내장하고 있습니다. 커널과 프로토콜 차이에 대한 자세한 설명은 블로그 《mihomo(Clash Meta) 커널 특징과 오리지널 Clash의 차이》를 참고하세요.

DNS 문제: 해석 오류와 오염

전형적인 증상

프록시는 연결되지만 일부 사이트가 안 열림, 열린 사이트가 「잘못된 지역 버전」, 광고 차단 규칙이 어떤 때는 되고 어떤 때는 안 됨, nslookup 결과가 명백히 이상한 IP를 반환. 이런 증상들은 모두 노드가 아닌 DNS 단계를 가리킵니다.

Clash의 DNS 모듈 동작 방식

클라이언트 내장 DNS 모듈이 시스템의 도메인 해석을 대신 맡아 설정된 상위 서버로 질의하고, 규칙과 함께 「누가 해석하고 결과를 누구에게 줄지」를 정합니다. 두 가지 동작 모드가 있습니다. redir-host는 실제 해석된 IP를 반환하고, fake-ip는 198.18.0.0/16 대역의 가상 IP를 반환한 뒤 연결이 성립되는 시점에 커널이 도메인 기준으로 다시 라우팅합니다. 해석이 빠르고 오염에 자연스럽게 강해서 대부분의 클라이언트가 기본값으로 사용합니다.

설정 예시

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fake-ip-filter:
    - "*.lan"
    - localhost.ptlogin2.qq.com

nameserver는 직접 연결 도메인의 해석을 맡고, fallback은 프록시로 나가는 도메인을 맡습니다. fake-ip-filter에는 반드시 실제 IP를 반환해야 하는 도메인(로컬 네트워크 기기, IP에 민감한 일부 앱)을 나열합니다. dns 섹션을 수정한 후에는 커널을 재시작하거나 설정을 다시 불러와야 적용되며, 대부분 클라이언트 설정에 원클릭 버튼이 있습니다.

설정 변경 후 캐시 삭제

시스템과 브라우저 모두 DNS를 캐시하므로 예전 캐시를 지우지 않으면 새 설정이 안 적용된 것처럼 보입니다.

DNS 유출 자가 진단

프록시를 켠 상태에서 DNS 유출 테스트 사이트에 접속하세요. 표시되는 해석 서버는 프록시 출구나 설정한 상위 서버여야 하며 로컬 통신사 서버가 아니어야 합니다. 로컬 통신사 DNS가 표시된다면 시스템 DNS가 고정 설정되어 있는지, 브라우저에서 「보안 DNS」가 켜져 있어 시스템 해석을 우회하는지 확인하세요.

시스템 프록시 미적용: 스위치는 켰는데 트래픽이 프록시를 안 탐

먼저 「적용됨」의 기준을 확인

시스템 프록시를 켠 후 브라우저로 IP 조회 사이트에 접속하면 출구가 노드가 위치한 지역으로 표시되어야 합니다. 여전히 로컬 통신사로 표시된다면 적용되지 않은 것입니다. 확인은 10초면 되니 먼저 해보고 다음으로 넘어가세요.

Windows: 프록시 항목이 되돌려졌는지 확인

설정 → 네트워크 및 인터넷 → 프록시: 「프록시 서버 사용」이 켜져 있어야 하고, 주소는 127.0.0.1, 포트는 클라이언트와 일치해야 합니다. 보안 소프트웨어나 다른 프록시 도구가 이 항목을 되돌릴 수 있습니다. 클라이언트가 시스템 설정에 쓰려면 권한이 필요하므로 필요하면 한 번 관리자 권한으로 실행해 클라이언트가 쓰기 권한을 얻도록 하세요.

macOS: 권한과 프록시 항목

시스템 설정 → 네트워크 → 현재 네트워크 어댑터 → 세부사항 → 프록시에서 웹 프록시, 보안 웹 프록시의 체크와 포트를 확인하세요. 클라이언트가 처음 시스템 프록시를 켤 때 시스템이 권한 요청을 표시하는데, 「허용 안 함」을 눌렀다면 다시는 설정에 쓸 수 없으니 「개인정보 보호 및 보안」 설정에서 허용한 뒤 다시 시도하세요.

브라우저 단계의 간섭

SwitchyOmega 같은 확장 프로그램은 브라우저 프록시를 직접 제어하며 시스템 프록시와 충돌할 수 있으니 둘 중 하나만 사용하세요. 브라우저의 「보안 DNS」는 도메인 해석이 클라이언트의 DNS 로직을 우회하게 만들어 「IP는 바뀌었는데 내용이 이상함」으로 나타납니다. 진단할 때는 먼저 꺼두고 확인하세요.

터미널과 개발 도구는 시스템 프록시를 안 탐

터미널은 기본적으로 시스템 프록시를 무시하므로 명시적으로 환경 변수를 설정해야 합니다.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890

git, npm, pip은 각자 별도의 프록시 설정 항목이 있어 환경 변수가 전부 적용되지 않을 수 있습니다. 브라우저와 터미널 두 갈래의 상세 진단은 블로그 문서 《Clash 시스템 프록시 미적용 진단 방법》을 참고하세요.

최종 해결책: TUN 모드

TUN 모드는 가상 네트워크 어댑터로 기기 전체 트래픽을 처리하며 시스템 프록시 설정에 의존하지 않아, 시스템 프록시를 따르지 않는 앱(게임, 일부 명령줄 도구)에도 효과적이고 「프록시 항목이 되돌려짐」 같은 반복되는 문제도 피할 수 있습니다. 원리와 활성화 절차는 블로그 《Clash TUN 모드 활성화 가이드》를 참고하세요.

클라이언트 충돌 및 실행 불가

먼저 무엇이 문제인지 구분하기

화면 강제 종료와 커널 실행 실패는 다른 문제입니다. 커널이 실패하면 클라이언트가 보통 명확한 안내(코어 시작 실패, 포트 충돌, 설정 파싱 오류)를 보여주니 안내를 먼저 확인하세요. 화면 자체가 열리지 않으면 재설치나 다른 클라이언트로 교체하는 것이 우선입니다.

포트 충돌

혼합 포트나 외부 제어 포트가 이미 사용 중이면—흔한 원인은 완전히 종료되지 않은 이전 클라이언트 프로세스입니다—커널이 실행되지 못합니다. 점유 확인:

# Windows(관리자 권한 터미널)
netstat -ano | findstr :7890

# macOS / Linux
lsof -i :7890

점유 중인 프로세스를 종료하거나, 클라이언트 설정에서 포트를 다른 값으로 바꾸세요. 포트를 바꾼 후에는 시스템 프록시 설정의 포트도 일치하는지 확인하세요.

설정 파일 문법 오류

YAML은 들여쓰기에 극히 민감합니다. 반드시 공백을 써야 하며 Tab은 안 되고, 계층이 한 칸만 틀려도 파싱 실패로 이어집니다. config.yaml을 직접 수정한 후에는 클라이언트 내장 설정 검사나 YAML 검증 도구로 한 번 확인하세요. 올바른 노드 항목은 다음과 같은 형태입니다.

proxies:
  - name: "노드A"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com

권한과 시스템 구성 요소

Windows에서 TUN 모드, 서비스 모드는 시스템 서비스 설치가 필요합니다(클라이언트 내에 보통 원클릭 설치 항목이 있음). macOS에서는 향상된 모드를 처음 켤 때 권한 승인이 필요합니다. 보안 소프트웨어가 커널 파일을 오탐으로 격리할 수 있으니 화이트리스트에 추가한 뒤 클라이언트를 재설치하면 됩니다.

초기화와 재설치

설정 디렉터리 손상의 일반적인 해결법: 구독 링크 백업 → 클라이언트 종료 → 설정 디렉터리 이름 변경 → 클라이언트 재시작 후 다시 가져오기. 여전히 해결되지 않으면 클라이언트를 교체하세요. Windows와 macOS에서는 Clash Plus를 우선 추천하며, Clash Verge Rev, FlClash를 대안으로 고려할 수 있습니다. Clash for Windows와 ClashX Meta는 유지보수가 중단되어 신규 설치에는 권장하지 않습니다. 전체 플랫폼 클라이언트 목록은 다운로드 페이지에 있습니다.

모바일 전용: Android와 iOS

Android: 백그라운드 종료가 가장 흔한 원인

국내 제조사 커스텀 ROM의 배터리 최적화 기능이 상시 실행되는 VPN 프로세스를 정리하는 경우가 있어, 화면을 잠근 지 일정 시간이 지나면 프록시가 「알아서 꺼지는」 증상이 나타납니다. 해결 순서: 시스템 설정 → 앱 → 해당 클라이언트 → 배터리/전력 관리에서 「최적화 안 함」 또는 「백그라운드 활동 허용」으로 설정. 최근 실행 앱 목록에서 클라이언트를 잠금. 자동 실행을 허용. Clash Meta for Android, FlClash, Surfboard는 모두 다운로드 페이지의 Android 항목에 있으며, 전체 플랫폼에서는 Clash Plus를 우선 추천합니다.

Android: VPN 슬롯 배타성

시스템은 동시에 하나의 VPN만 허용합니다. 다른 VPN이나 가속기가 슬롯을 점유하고 있으면 클라이언트 실행이 실패하거나 상대방을 강제로 밀어낼 수 있습니다. 클라이언트의 앱별 프록시 기능을 사용해 처리 범위를 좁히면 다른 도구와의 충돌도 줄일 수 있습니다.

iOS: Clash Plus와 시스템 관리

iOS에서는 App Store를 통해 Clash Plus를 설치하세요(공식 사이트 clashplus.io). iOS의 VPN은 시스템이 직접 관리하므로 화면 잠금 후에도 대체로 연결이 유지됩니다. 저전력 모드와 「백그라운드 앱 새로고침」 끄기는 구독 자동 갱신과 상시 연결 유지에 영향을 주므로, 「방치했더니 갱신이 안 됨」 증상이 있으면 이 두 가지를 먼저 확인하세요.

데스크톱 설정과의 상호 호환

구독 링크는 전 플랫폼에서 동일하게 사용됩니다. 같은 서비스 구독을 휴대폰과 PC에 동시에 가져올 수 있으며, 규칙과 트래픽 분배 로직도 동일합니다. 이 매뉴얼의 앞선 챕터에서 다룬 DNS, 규칙, 프로토콜에 관한 내용은 모바일에도 똑같이 적용되며, 차이는 시스템 단계의 상시 연결 유지와 권한 부분뿐입니다.

모바일 증상 빠른 검색