Clash 문제 해결 총정리

공통 점검 원칙과 도구

Clash의 데이터 경로는 네 단계로 나눌 수 있습니다: 앱이 요청을 보냄 → 시스템 프록시나 TUN이 트래픽을 클라이언트에 전달 → 클라이언트가 규칙에 따라 아웃바운드를 매칭 → 노드가 트래픽을 목적지까지 전달. 어느 한 단계라도 끊기면 겉으로는 모두 "인터넷이 안 됨"으로 보이지만, 원인과 해결법은 완전히 다릅니다. 점검의 핵심 동작은 단 하나입니다: 문제가 어느 단계에서 발생했는지 확인하고, 그 단계만 고치세요.

점검 순서: 가까운 곳부터 먼 곳으로

직감에 따라 단계를 건너뛰지 말고 항상 이 순서로 확인하세요: 먼저 클라이언트 프로세스가 실행 중이고 설정이 로드됐는지(화면에 노드 목록이 보이는지) 확인 → 트래픽이 실제로 클라이언트에 들어오는지(연결 패널에 새 연결 기록이 있는지) 확인 → 규칙 매칭이 예상대로인지(연결 기록의 아웃바운드가 원하는 정책 그룹인지) 확인 → 마지막에야 노드 자체를 의심하세요. 반대로 접근하는 것 — 다짜고짜 노드나 구독을 바꾸는 것 — 은 가장 흔한 시간 낭비입니다. 로컬 경로가 막혀 있으면 어떤 노드로 바꿔도 결과는 같기 때문입니다.

로그는 1차 증거

모든 Clash 계열 클라이언트는 로그 패널을 제공하며, 로그의 상세도는 설정 파일의 log-level 필드로 조절됩니다. 점검 중에는 일시적으로 debug로 올리고, 문제 해결 후 info로 되돌리세요. 그렇지 않으면 로그량이 매우 많아집니다.

명령 한 줄로 프록시 경로 검증하기

브라우저에 의존하지 말고 curl로 로컬 믹스 포트를 통해 요청을 한 번 보내보는 것이 "클라이언트 → 노드" 구간이 정상인지 가장 빠르게 판단하는 방법입니다. 204나 200이 반환되면 경로는 정상; 멈춰서 타임아웃되면 노드가 불통; 연결이 거부되면 로컬 포트가 리스닝되지 않고 있다는 뜻입니다.

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

믹스 포트가 기본값 7890이 아니라면 명령의 포트 번호를 설정 파일의 mixed-port 실제 값으로 바꾸세요. 이 명령은 시스템 프록시 설정을 우회하므로, 그 결과로 "시스템 프록시 설정이 잘못됨"과 "노드 불통" 두 종류의 문제를 명확히 구분할 수 있습니다: 명령은 통하는데 브라우저는 안 되면 시스템 프록시 챕터를 확인하고, 명령도 안 통하면 노드 타임아웃 챕터를 확인하세요.

변수 줄이기: 한 번에 조건 하나만 바꾸기

확신이 안 서는 문제를 만나면, 순서대로 세 가지 대조 실험을 해보세요: 노드를 바꿔보기(단일 노드 장애 배제), 글로벌 모드로 전환하기(규칙 문제 배제), 다른 프록시/가속기/보안류 소프트웨어를 잠시 종료하기(여러 프로그램이 트래픽을 다투는 상황 배제). 매번 조건 하나만 바꾸고 결과를 기록하면, 세 번의 실험 후 문제 범위가 보통 하나의 명확한 챕터로 좁혀집니다.

실행 후 완전히 인터넷 접속 불가

증상 정의: 클라이언트를 실행한 후 모든 웹사이트(중국 본토 사이트 포함)에 접속할 수 없거나, 클라이언트를 종료하면 네트워크가 정상으로 돌아오는 경우. 이 유형의 문제는 거의 모두 로컬 경로에서 발생하며 노드 문제가 아닙니다.

1단계: 물리적 네트워크 자체가 정상인지 확인

먼저 클라이언트를 완전히 종료하고(트레이로 최소화하는 것이 아니라 프로세스 종료를 의미) 중국 본토 웹사이트를 하나 열어보세요. 이때도 안 열린다면 문제는 Clash와 무관하니 먼저 로컬 네트워크를 해결하세요; 종료 후에는 열리는데 실행 후에는 안 열린다면 계속 아래로 진행하세요. 예외 상황도 주의해야 합니다: 클라이언트를 종료한 후에도 여전히 아무 사이트도 열리지 않는 경우 — 이는 보통 프록시 설정이 남아있는 잔존 상태이며, 클라이언트가 비정상 종료되면서 시스템 프록시 설정을 되돌리지 못한 것입니다. 처리 방법은 시스템 프록시 챕터의 "프록시 잔존" 항목을 참고하세요.

2단계: 트래픽이 클라이언트에 들어왔는지 확인

클라이언트의 연결(Connections) 패널을 열고 웹페이지를 새로고침한 뒤 새로운 연결 기록이 나타나는지 관찰하세요. 기록이 있으면 시스템 프록시 구간은 정상이고 문제는 그 이후 단계에 있습니다; 기록이 전혀 없으면 트래픽이 Clash로 전혀 가지 않았다는 뜻입니다 — 시스템 프록시가 제대로 적용되지 않았거나, 해당 앱이 시스템 프록시를 따르지 않는(대표적으로 커맨드라인 프로그램) 경우입니다. 두 경우 모두 시스템 프록시 챕터로 이동해 처리하세요.

3단계: 글로벌 모드로 대조 실험

아웃바운드 모드를 "규칙"에서 "글로벌"로 전환하고, 이전에 테스트해서 정상 작동했던 노드를 선택한 뒤 웹페이지를 다시 새로고침하세요. 글로벌 모드에서는 인터넷이 되는데 규칙 모드에서는 안 된다면 문제는 규칙에 있습니다: 규칙 세트가 없어서 대량의 요청이 잘못된 아웃바운드로 떨어졌거나, 기본 규칙 MATCH가 사용 불가능한 정책 그룹을 가리키는 경우가 대부분입니다. 설정 파일 끝의 기본 규칙을 확인해 가리키는 정책 그룹에 사용 가능한 노드가 있는지 확인하세요:

rules:
  # ……앞에는 구체적인 규칙들……
  - GEOIP,CN,DIRECT      # 중국 본토 IP는 직접 연결
  - MATCH,PROXY          # 나머지 트래픽은 PROXY 정책 그룹으로(그룹 내 사용 가능한 노드가 있는지 확인)

글로벌 모드에서도 인터넷이 안 된다면 규칙은 배제할 수 있고 문제는 노드나 로컬 포트에 있습니다. 노드 타임아웃 챕터로 이동하세요.

4단계: 국내 트래픽이 잘못 프록시를 타는지 확인

또 다른 "반쪼가리" 형태: 해외 사이트는 열리는데 중국 본토 사이트는 오히려 안 열리거나 매우 느린 경우. 이는 국내 트래픽도 노드로 보내지고 있으며, 노드의 본토 회선 품질이 나쁘다는 뜻입니다. 규칙에 GEOIP,CN,DIRECT와 자주 쓰는 국내 도메인의 직접 연결 규칙이 포함돼 있는지 확인하세요; 구독에서 제공하는 설정에 이 부분이 없다면 직접 rules 섹션의 앞쪽에 DOMAIN-SUFFIX 직접 연결 항목을 추가할 수 있습니다. 규칙은 위에서 아래로 매칭되며 매칭되면 즉시 멈추므로 순서가 중요합니다 — 직접 연결 규칙은 기본 규칙 MATCH 앞에 두어야 합니다.

노드 전체 타임아웃 또는 지연 이상

증상 정의: 지연 테스트에서 모든 노드가 타임아웃(timeout)으로 표시되거나, 노드에 지연 숫자가 표시되지만 실제로는 연결이 안 되는 경우. 먼저 지연 테스트가 무엇을 측정하는지 이해한 뒤 문제 층위를 판단하세요.

지연 테스트의 원리와 한계

클라이언트의 지연 테스트는 각 노드를 통해 테스트 URL(보통 http://www.gstatic.com/generate_204)로 HTTP 요청을 한 번 보내 완료 시간을 기록하는 방식입니다. 이것이 검증하는 것은 "로컬 → 노드 → 테스트 사이트"의 전체 경로이므로: 전부 타임아웃이면 대개 노드가 전부 죽은 게 아니라 로컬에서 노드까지의 구간이 전체적으로 막힌 것이고, 개별 타임아웃이 오히려 그 노드 자체의 문제일 가능성이 높습니다. 또한 지연 숫자는 소용량 요청 한 번의 왕복 시간만 반영하며 실제 다운로드 속도와는 다르다는 점에 주의하세요 — 이 오해는 속도 저하 챕터에서 자세히 다룹니다.

전체 타임아웃: 세 가지 원인을 순서대로 배제

첫째, 구독이 이미 만료됨. 노드 서버 정보(주소, 포트, 비밀번호)는 서비스 측에서 교체되며, 로컬 설정이 옛 정보에 머물러 있으면 전멸한 것처럼 보입니다. 먼저 구독을 수동으로 한 번 업데이트하고 다시 지연을 테스트하세요; 업데이트 자체가 오류를 낸다면 구독 실패 챕터로 이동하세요.

둘째, 로컬 네트워크가 노드 포트를 차단함. 회사, 학교, 호텔 네트워크에서는 흔히 80/443 포트만 허용하며, 노드가 높은 번호의 포트를 쓰면 전부 불통이 됩니다. 판단법: 휴대폰 테더링으로 바꿔 다시 테스트해보세요. 테더링에서는 전부 통하고 원래 네트워크에서는 전부 타임아웃이면 네트워크 환경 제한임을 확인할 수 있고, 해결 방법은 443 포트를 쓰는 노드를 우선 선택하는 것입니다.

셋째, 시스템 시간 오차. 일부 암호화 프로토콜은 시간에 민감해서, 로컬 시계와 실제 시간의 오차가 일정 범위(보통 약 90초)를 넘으면 핸드셰이크가 전부 실패하며 노드 전멸과 똑같이 보입니다. 시스템 시간의 자동 동기화가 켜져 있는지 확인하고, 수동 교정 후 다시 테스트하세요. 이는 가장 쉽게 간과되지만 가장 고치기 쉬운 원인입니다.

지연 숫자는 있는데 연결이 안 되는 경우

지연 테스트는 HTTP 소용량 패킷으로 가지만 실제 업무는 UDP나 장시간 연결로 갈 수 있어 통로가 다릅니다. 대표적인 예: 웹페이지는 열리는데 음성/영상 통화가 안 되는 경우 — 노드가 UDP 포워딩을 지원하지 않는 것입니다. 이는 노드 성능 문제이므로 UDP 지원이 표시된 노드로 바꾸면 되고, 클라이언트 쪽에서는 해결할 수 없습니다.

자동 선택으로 장애 허용하기

노드 장애 때마다 수동으로 전환하는 대신 url-test 유형의 정책 그룹을 사용하면 클라이언트가 현재 가장 빠른 노드를 자동으로 선택하고 장애 시 자동으로 전환합니다:

proxy-groups:
  - name: 자동선택
    type: url-test
    proxies: [노드A, 노드B, 노드C]
    url: http://www.gstatic.com/generate_204
    interval: 300        # 300초마다 재테스트
    tolerance: 50        # 신구 노드 지연 차이가 50ms 미만이면 전환하지 않음, 잦은 흔들림 방지

구독 업데이트 실패

증상 정의: 구독 업데이트 클릭 후 오류가 나거나 오랫동안 응답이 없는 경우. 구독 업데이트는 본질적으로 클라이언트가 구독 URL로 HTTP 요청을 한 번 보내고 반환된 내용을 설정 파일로 파싱하는 과정이므로, 점검도 "요청 실패"와 "파싱 실패" 두 종류로 나뉩니다.

먼저 오류 메시지를 읽기: 흔한 오류 대조표

요청 경로 문제: 먼저 클라이언트를 배제하고 검증

커맨드라인으로 구독 주소를 직접 요청해 클라이언트 요인을 배제하세요:

curl -v -o sub.yaml "https://구독주소"

명령으로는 정상 다운로드되는데 클라이언트 업데이트는 실패한다면, 대개 클라이언트의 업데이트 요청이 사용 불가능한 프록시를 경유한 것입니다: 많은 클라이언트가 기본적으로 "프록시를 통해 구독 업데이트"를 사용하는데, 노드가 전부 실패하면 "구독 업데이트에는 사용 가능한 노드가 필요한데, 사용 가능한 노드를 얻으려면 구독을 업데이트해야 하는" 교착 상태에 빠집니다. 해결 방법은 클라이언트 구독 설정에서 일시적으로 "직접 연결로 업데이트"로 바꾸고, 업데이트가 성공해 노드가 복구되면 다시 되돌리는 것입니다. 구독을 처음 가져올 때도 마찬가지입니다 — 이 시점에는 로컬에 사용 가능한 노드가 전혀 없으므로 직접 연결 요청을 반드시 허용해야 합니다.

명령으로도 다운로드가 안 된다면 구독 서버 자체가 현재 네트워크에서 접근 불가능한 것이며 클라이언트와는 무관합니다: 네트워크 환경(예: 휴대폰 테더링)을 바꿔 재시도하거나, 서비스 측에 구독 주소가 바뀌었는지 확인하세요.

파싱 문제: 반환된 것이 설정이 아님

YAML 파싱 오류가 날 때는 앞 단계에서 저장한 sub.yaml을 텍스트 편집기로 열어 내용을 확인하세요: HTML 조각(오류 페이지, 인증 페이지)이라면 구독 서버가 이 요청을 브라우저 접속으로 간주했거나 구독이 이미 만료된 것입니다; 완전한 YAML이 아니라 Base64나 다른 인코딩의 노드 목록이라면 이 구독 형식이 다른 커널을 대상으로 한 것이므로 구독을 받을 때 "Clash 형식"을 선택하거나 서비스 측이 제공하는 형식 변환 주소를 사용해야 합니다.

User-Agent에 따라 다르게 처리됨

일부 구독 서비스는 요청의 User-Agent에 따라 다른 형식을 반환하거나 낯선 UA를 거부하기도 합니다. Clash Verge Rev, FlClash 등의 클라이언트는 구독 요청의 UA를 커스텀할 수 있으므로, 403이나 형식 오류가 날 때 UA를 clash나 서비스 측이 지정한 값으로 설정해보면 바로 해결되는 경우가 많습니다.

연결은 되는데 속도가 느림

증상 정의: 네트워크는 사용 가능하지만 웹페이지 로딩이 느리거나, 영상 화질이 안 올라가거나, 다운로드 속도가 예상보다 훨씬 낮은 경우. 속도 문제는 변수가 가장 많으므로 먼저 기준을 세운 뒤 하나씩 원인을 파악해야 합니다.

1단계: 로컬 대역폭 기준 세우기

먼저 프록시를 끄고 직접 연결로 로컬 대역폭을 한 번 측정해 숫자를 기록하세요. 프록시를 켠 후의 속도는 이 상한을 넘을 수 없습니다; 직접 연결 자체가 20 Mbps밖에 안 나온다면 프록시 후 15 Mbps는 이미 정상적인 손실이므로 더 신경 쓸 필요 없습니다. 이 기준을 바탕으로 서로 다른 노드의 실제 속도를 비교하세요.

2단계: "지연 = 속도"라는 오해 깨기

지연 테스트는 소용량 패킷의 왕복 시간을 반영하고, 속도는 노드의 대역폭과 수용 인원수에 따라 결정됩니다. 60ms인 노드가 200ms인 노드보다 훨씬 느릴 수도 있습니다 — 전자는 공용의 혼잡한 회선일 수 있고, 후자는 여유 있는 대용량 회선일 수 있기 때문입니다. 지연만 보고 노드를 고르는 방식은 상호작용에 민감한 상황(예: 원격 터미널)에만 적합합니다; 다운로드, 영상류 수요는 실제 처리량을 측정해야 하며, 방법은 해당 노드를 통해 실제로 대용량 파일을 다운로드하며 안정적인 속도를 관찰하는 것입니다.

3단계: 국내 트래픽이 노드로 우회하는지 확인

규칙이 없으면 국내 사이트 트래픽이 해외로 나갔다가 다시 돌아오면서 속도가 급락하고 지연도 두 배가 됩니다. 연결 패널을 열고 국내 웹사이트에 접속해, 이 연결의 아웃바운드가 DIRECT인지 관찰하세요. 아니라면 직접 연결 규칙을 추가하세요:

rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

GEOIP 규칙은 로컬 GeoIP 데이터베이스에 의존하며, 클라이언트가 보통 자동으로 다운로드합니다; 로그에서 데이터베이스가 없다는 메시지가 나오면 클라이언트 설정에서 수동으로 데이터베이스 업데이트를 실행하세요.

4단계: 피크 시간대와 회선 유형

저녁에 다 같이 느려지고 심야에 회복되는 것은 국제 출구 혼잡의 전형적인 특징으로, 설정 문제가 아니라 회선 문제입니다: 다른 착지 지역의 노드로 바꾸거나(예: 근거리 홍콩/일본/싱가포르 노드가 대개 원거리 노드보다 낫습니다), 서비스 측이 표시한 우수 회선을 선택하세요. 모든 노드가 하루 종일 느리다면, 백그라운드에서 다운로드류 소프트웨어가 업링크를 다 쓰고 있는지, 라우터에 속도 제한이나 QoS 정책이 켜져 있는지 다시 확인해보세요.

5단계: 클라이언트와 커널 차원의 요인

현재 유지보수 중인 클라이언트(선택 가이드 참고)는 커널이 더 최신이라 새 프로토콜과 멀티플렉싱 지원이 더 좋습니다; 유지보수가 중단된 예전 클라이언트에 오래 머물러 있으면 속도와 호환성이 점차 떨어집니다. 또한 TUN 모드와 시스템 프록시 모드는 시스템마다 처리량 표현이 다르므로, 속도에 민감한 상황이라면 두 모드를 각각 테스트해 더 나은 쪽을 사용하세요.

DNS 관련 문제

증상 정의: 일부 웹사이트만 안 열리고 나머지는 정상; 도메인이 명백히 잘못된 IP로 해석됨; TUN을 켠 후 모든 도메인 해석이 실패함; 또는 일부 앱에 표시된 IP가 198.18.x.x로 시작하는 경우. 이런 문제들은 모두 DNS 설정을 가리킵니다.

enhanced-mode: fake-ip와 redir-host 이해하기

Clash의 DNS 모듈에는 두 가지 작동 방식이 있습니다. fake-ip 모드에서는 클라이언트가 각 도메인에 대해 먼저 198.18.0.0/16 대역의 가상 IP를 반환해 앱이 즉시 연결을 맺게 하고, 실제 해석은 트래픽이 아웃바운드될 때로 미룹니다 — 장점은 해석 대기 시간이 없고 도메인 정보가 규칙 매칭에 완전히 보존된다는 것; 단점은 일부 프로그램이 이 가상 IP를 캐시하거나 업로드하면서 혼란을 일으킬 수 있다는 것입니다. redir-host 모드는 착실하게 실제 IP를 해석해냅니다. 현재 주류 설정은 기본값이 fake-ip이며 보통 바꿀 필요가 없습니다; 198.18.x.x 주소를 보는 것 자체는 오류가 아닙니다.

바로 적용 가능한 dns 섹션 템플릿

dns:
  enable: true
  listen: 0.0.0.0:53          # TUN 모드에서는 53 포트를 리스닝하는 것을 권장
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"                  # 로컬 네트워크 호스트명은 fake-ip를 쓰지 않음
    - "+.stun.*.*"             # STUN 탐지에는 실제 IP가 필요
    - "time.*.com"             # 시간 동기화류 서비스
  nameserver:                  # 일반 해석: 국내 DoH, 빠르고 안정적
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:                    # 대체 해석: 해외 DoH, 오염 방지
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN             # 해석 결과가 중국 본토 IP면 nameserver를 신뢰, 아니면 fallback 사용

각 필드의 역할: nameserver는 일상적인 해석을 담당하며 국내 DoH를 선택해 국내 도메인 해석이 빠르고 정확하도록 보장합니다; fallback은 병행하는 두 번째 해석 경로로, fallback-filter가 nameserver의 결과가 의심스럽다고(예: 해외 도메인인데 이상한 결과가 나옴) 판단하면 fallback의 답을 채택해 해석 오염에 대응합니다. 항목별 원리와 더 많은 작성법은 블로그 《Clash DNS 설정 항목별 분석》에서 확인할 수 있습니다.

전형적인 오류와 대응 처리

일부 사이트만 안 열리고 나머지는 정상: 연결 패널에서 해당 도메인을 검색해 해석과 아웃바운드가 예상대로인지 확인하세요; 도메인이 잘못 직접 연결로 처리되고 해석 결과가 비정상이면, 프록시를 타는 도메인 규칙(DOMAIN-SUFFIX,example.com,PROXY)을 추가해주면 보통 해결됩니다.

TUN을 켠 후 해석이 전부 실패: TUN 모드는 시스템 DNS 요청도 클라이언트로 끌어들이므로, 이때 dns 섹션은 반드시 enable: true이고 53 포트를 리스닝해야 합니다(위 템플릿 참고). 그렇지 않으면 시스템이 보낸 해석 요청에 응답할 곳이 없습니다. 클라이언트 TUN 설정의 "DNS 하이재킹" 옵션이 켜져 있는지 확인하고, 설정 파일 방식이라면 listen: 0.0.0.0:53이 있는지 확인하세요.

로컬 네트워크 기기(프린터, NAS) 접속 이상: 로컬 네트워크 호스트명이 fake-ip에 접수된 것이 원인이니, 해당 도메인 패턴을 템플릿의 *.lan처럼 fake-ip-filter에 추가하세요.

게임이나 통화류 앱 동작 이상: 이런 앱은 STUN 탐지로 공개 IP를 확인하는 경우가 많은데, fake-ip가 탐지를 방해할 수 있습니다. 템플릿의 +.stun.*.* 같은 필터 항목이 바로 이를 위한 것이며, 앱이 실제로 사용하는 탐지 도메인에 맞춰 추가하면 됩니다.

시스템 프록시 미적용

증상 정의: 클라이언트가 정상 작동하고 1장의 curl 검증 명령이 통하는데, 브라우저나 일부 앱의 트래픽이 Clash를 타지 않는 경우; 또는 클라이언트를 종료해도 시스템이 여전히 프록시 상태에 있는 경우.

시스템 프록시가 적용됐는지 확인

클라이언트의 "시스템 프록시" 스위치가 하는 일은 127.0.0.1:7890을 운영체제의 프록시 설정에 써넣는 것입니다. 스위치를 켠 후 시스템에서 직접 한 번 확인해보세요:

스위치는 켜졌지만 시스템에 적용되지 않았다면: 다른 소프트웨어(브라우저 프록시 확장, 가속기, 또 다른 프록시 클라이언트)가 설정을 다시 덮어쓰고 있는지 확인하세요; macOS에서는 프록시가 "현재 활성화된 네트워크 서비스"에 적용된다는 점도 주의해야 합니다. 여러 네트워크 카드가 연결돼 있으면 다른 카드에 적용됐을 수 있습니다.

시스템 프록시를 따르지 않는 앱: 환경 변수와 TUN

시스템 프록시는 그저 하나의 "권고"이며 앱이 이를 무시할 수 있습니다. 커맨드라인 도구(git, 패키지 매니저, 각종 SDK)는 대부분 기본적으로 시스템 프록시를 무시하며, 환경 변수를 명시적으로 설정해야 합니다:

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

이 명령은 현재 터미널 세션에만 적용되므로 임시 용도에 적합합니다; 장기적으로 적용하려면 셸 설정 파일에 써넣으세요. 시스템 프록시도 따르지 않고 프록시 설정 항목도 없는 앱에는, TUN 모드가 근본적인 해결책입니다: 클라이언트가 가상 네트워크 카드를 만들어 네트워크 계층에서 모든 트래픽을 접수하므로 어떤 앱도 이를 피할 수 없습니다. 설정 파일 방식으로 켜기:

tun:
  enable: true
  stack: system          # 호환성 문제가 많으면 gvisor로 바꿔 대조 테스트
  auto-route: true       # 라우팅 자동 접수
  auto-detect-interface: true

TUN은 관리자/root 권한이 필요하며, DNS 섹션이 이전 챕터 템플릿대로 올바르게 설정돼 있어야 합니다; 주류 클라이언트(Clash Plus, Clash Verge Rev, FlClash)는 설정 화면에서 TUN 스위치와 필요한 권한 안내를 제공하니, 설정을 직접 손으로 고치기보다 화면 스위치를 우선 사용하세요.

프록시 잔존: 종료 후에도 인터넷이 안 되는 경우

클라이언트가 강제로 종료되면(크래시, 작업 관리자로 프로세스 종료, 시스템 정전) 시스템 프록시 설정을 되돌릴 시간이 없어, 재시작 후 브라우저가 이미 존재하지 않는 127.0.0.1:7890에 계속 연결을 시도하며 "아무것도 안 열림" 증상이 나타납니다. 해결 방법: 위 표의 위치로 가서 시스템 프록시 설정에 들어가 수동으로 프록시를 끄거나; 클라이언트를 다시 한 번 켰다가 정상적으로 종료해 스스로 설정을 회수하게 하세요. 평소 트레이 메뉴에서 정상적으로 종료하는 습관을 들이면 이를 피할 수 있습니다.

클라이언트 실행 실패와 크래시

증상 정의: 더블클릭해도 반응이 없음, 실행하면 바로 꺼짐, 커널이 반복적으로 재시작됨, 또는 로그가 특정 오류에서 멈춤. 이런 유형의 오류 메시지는 지시성이 매우 강하므로, 로그의 원문을 먼저 찾아보는 것이 우선입니다.

포트 충돌: bind: address already in use

실행 로그에 bind: address already in use가 나오면, 설정에서 리스닝하려는 포트(보통 7890/7891/9090)가 이미 다른 프로세스에 점유돼 있다는 뜻입니다 — 이전에 제대로 종료되지 않은 옛 커널일 수도 있고, 다른 소프트웨어일 수도 있습니다. 3개 플랫폼별 확인 명령:

점유하고 있는 것이 잔존한 옛 커널이면 종료하면 되고, 다른 상주 소프트웨어라면 자신의 포트를 바꾸는 것이 더 간단합니다 — 설정 파일에서 충돌하지 않는 포트로 바꾸세요:

mixed-port: 7893           # HTTP와 SOCKS5가 공용하는 믹스 포트
external-controller: 127.0.0.1:9097   # 컨트롤 인터페이스 포트도 함께 충돌 회피

포트를 바꾼 후에는 시스템 프록시와 환경 변수의 포트 번호도 동기화해서 업데이트하세요. 전체 단계별 절차는 블로그 《Clash 포트 충돌 오류 해결 방법》에서 확인할 수 있습니다.

설정 파일 문법 오류

로그에 yaml: line N: 같은 오류가 나오면 설정 파일 N번째 줄 근처에 문법 문제가 있다는 뜻입니다. YAML은 형식에 매우 민감하며, 자주 발생하는 세 가지 오류는: Tab 들여쓰기 사용(반드시 스페이스를 써야 함), 콜론 뒤 공백 누락(port:7890은 틀리고 port: 7890이 맞음), 특수문자가 포함된 문자열에 인용부호 미사용(노드 이름에 @, # 등이 포함되면 인용부호로 감싸야 함)입니다. 직접 설정을 편집했다면 오류 줄 번호에 맞춰 하나씩 확인하고, 구독으로 받은 설정에서 오류가 났다면 구독을 다시 업데이트해 로컬 수정을 덮어쓰세요.

권한 부족

TUN을 켜거나 낮은 번호의 포트(예: DNS의 53)를 리스닝하려면 권한 상승이 필요합니다: Windows에서는 우클릭 후 관리자 권한으로 실행하거나 클라이언트가 제공하는 서비스 모드를 사용하고; macOS에서는 클라이언트 안내에 따라 권한 부여를 완료하고; Linux에서는 커널 파일에 capability 비트를 부여(setcap cap_net_admin,cap_net_bind_service=+ep)하거나 systemd 서비스 방식으로 실행하세요. 로그에 operation not permitted가 나오면 이 경우입니다.

클린 재설치: 최후의 방법

반복적으로 크래시가 나고 로그에 명확한 지시가 없을 때는 클린 재설치를 한 번 해보세요: 구독 주소 백업 내보내기 → 클라이언트 삭제 → 잔존한 설정 디렉터리 수동 삭제(각 클라이언트의 데이터 디렉터리 위치는 설정 화면의 "설정 디렉터리 열기" 항목에서 확인) → 다운로드 페이지에서 현재 유지보수 중인 버전을 재설치 → 구독 다시 가져오기. 옛 설정 디렉터리를 삭제하지 않으면 재설치는 안 한 것과 마찬가지이고 문제가 그대로 돌아옵니다. 유지보수가 중단된 클라이언트(예: Clash for Windows)를 계속 쓰면서 자주 크래시가 난다면 유지보수 중인 클라이언트로 바로 바꾸는 것을 권장하며, 마이그레이션 대조는 선택 가이드를 참고하세요.

모바일 전용(Android / iOS)

모바일 시스템은 백그라운드 프로세스와 네트워크 인터페이스에 대한 관리가 데스크톱보다 훨씬 엄격해서, "데스크톱에서는 본 적 없는" 문제 상당수가 여기서 비롯됩니다. 이 챕터는 플랫폼별로 나눠 정리합니다.

Android: VPN 권한과 백그라운드 생존

Android용 Clash 클라이언트(우선 Clash Plus 권장, 그 외는 다운로드 페이지 Android 항목 참고)는 시스템 VPN 인터페이스를 통해 트래픽을 접수하며, 처음 실행 시 "VPN 연결 만들기" 시스템 팝업에 반드시 동의해야 합니다. 잘못 거부하면 클라이언트가 헛돌게 되고, 시스템 설정 → 앱 → 해당 앱 → 권한에서는 되돌릴 수 없으니 시스템의 "VPN" 설정 항목에서 연결 권한을 다시 요청해야 합니다. 상태 표시줄에 키 모양 아이콘이 없다면 VPN 터널이 만들어지지 않았다는 뜻입니다.

두 번째로 큰 문제는 백그라운드에서 종료되는 것입니다: 화면을 잠근 지 얼마 지나면 네트워크가 끊기고 앱으로 돌아왔을 때 커널이 멈춰 있다면, 시스템의 배터리 최적화가 프로세스를 정리한 것입니다. 세 가지를 처리하세요: 시스템 배터리 설정에서 해당 앱을 "무제한/백그라운드 실행 허용"으로 설정; 최근 작업 목록에서 해당 앱 잠금; 국산 커스텀 시스템(MIUI, ColorOS, HarmonyOS 등)에서는 각자의 "자동 시작 관리"에서도 허용해야 합니다. 세 곳을 모두 설정하면 백그라운드 생존률이 눈에 띄게 개선됩니다.

또한 Android 클라이언트는 대부분 "앱별 프록시"를 지원합니다: 지정한 앱만 프록시를 타게 하거나, 지정한 앱을 제외할 수 있습니다. 은행 앱이 프록시에 민감할 때는 제외 목록에 추가하면 프록시를 켠 채로 공존할 수 있으니, 전체를 끌 필요는 없습니다.

Android: 설정과 구독의 차이점

모바일에서 구독을 업데이트하는 것도 "프록시를 경유한 업데이트" 교착 상태의 영향을 받습니다(구독 실패 챕터 참고); 데이터 사용에 민감한 사용자는 자동 업데이트 주기에 주의하세요. 구독 파일 자체는 크지 않지만 잦은 백그라운드 지연 테스트는 지속적인 소량의 트래픽을 발생시킵니다. 여러 기기 간 설정을 일치시키는 몇 가지 방법은 블로그 《Clash 다중 기기 설정 동기화 방안 비교》에서 확인할 수 있습니다.

iOS: 설치 경로와 흔한 문제

iOS는 App Store를 통해 Clash Plus를 설치합니다(공식 사이트 clashplus.io, 스토어 링크는 다운로드 페이지 iOS 항목 참고). 설치 후 처음 실행할 때도 시스템 팝업에서 VPN 설정 추가를 허용해야 하며, 해당 설정은 시스템 설정 → 일반 → VPN 및 기기 관리에 나타납니다. 흔한 문제는 두 종류입니다: 첫째, 스위치를 켠 후 바로 튕겨 나감 — 대부분 구독을 가져오지 않았거나 설정에 사용 가능한 노드가 없는 경우이니, 먼저 앱 내에서 노드 목록이 비어있지 않고 지연 테스트에 결과가 있는지 확인한 뒤 연결을 켜세요; 둘째, Wi-Fi와 셀룰러 네트워크를 전환한 후 잠시 끊김 — 시스템 네트워크 전환 시 VPN 터널이 재구성되는 정상적인 과정으로, 몇 초 안에 자동으로 회복되며, 계속 회복되지 않으면 앱 내에서 수동으로 한 번 재연결하세요.

iOS 시스템은 한 시점에 하나의 VPN 설정만 활성화할 수 있는 제약이 있어, 여러 프록시류 앱을 설치했다면 서로 대체되는 것이 정상적인 동작이니 자주 쓰는 하나만 유지하면 됩니다. 또한 iOS 앱이 백그라운드에서 시스템에 의해 회수돼도 VPN 터널은 시스템 네트워크 확장 기능이 유지하므로, 보통은 연결에 영향이 없습니다; 자주 끊긴다면 앱을 반복 재설치하기보다 구독 유효성과 노드 품질을 먼저 확인하세요.

모바일 공통 자가 점검 목록

1. 상태 표시줄에 VPN 아이콘이 있는지(Android 키 모양 / iOS "VPN" 표시) — 없다면 터널이 만들어지지 않은 것이니 권한 부여 단계로 돌아가세요.
2. 앱 내 지연 테스트에 사용 가능한 노드가 있는지 — 전부 타임아웃이면 노드 타임아웃 챕터대로 처리하고, 셀룰러와 Wi-Fi를 각각 테스트해 네트워크 환경 요인을 구분하세요.
3. 구독의 가장 최근 업데이트가 성공했는지 — 실패했다면 구독 실패 챕터대로 처리하세요.
4. 문제가 특정 앱에서만 나타나는지 — 그렇다면 앱별 프록시 목록과 해당 앱 자체의 네트워크 정책을 고려하세요.

여전히 해결되지 않을 때의 권장 방향

이 페이지의 절차를 다 거쳤는데도 원인을 찾지 못했다면, 보통 세 가지 가능성이 남습니다. 첫째, 문제가 서비스 측에 있는 경우: 구독 서비스의 노드, 회선, 할당량 상태는 서비스 측만 확인할 수 있으니, 점검 중 수집한 증거(오류 원문, 어떤 노드가 통하고 어떤 노드가 안 통하는지, 언제부터 시작됐는지)를 들고 문의하는 것이 그냥 "안 돼요"라고 말하는 것보다 소통 효율이 훨씬 높습니다. 둘째, 문제가 클라이언트 구현에 있는 경우: 같은 구독을 유지보수 중인 다른 클라이언트로 바꿔 교차 검증해보세요. 새 클라이언트에서 모두 정상이라면 선택 가이드대로 마이그레이션을 완료하면 되니 굳이 붙잡고 있지 마세요. 셋째, 문제가 기본 단계의 누락에 있는 경우: 사용 문서로 돌아가 메인 흐름을 다시 한 번 따라가보세요. "오래 찾은 이상한 문제"들 상당수는 결국 어떤 기본 스위치가 켜지지 않았던 것으로 판명됩니다.

마지막으로, 클라이언트와 구독을 꾸준히 업데이트하는 습관, 유지보수 중인 클라이언트 우선 사용, 자주 쓰는 아웃바운드를 url-test 자동 선택에 맡기는 것 — 이 세 가지가 이 페이지에서 다룬 장애의 70% 이상을 예방할 수 있습니다. 도구의 가치는 안정적이고 예측 가능하다는 데 있으며, 한 번 설정하면 오랫동안 조용히 작동하는 것이 점검의 최종 목표입니다.