문제 해결 예상 읽기 시간 13분

Clash 연결됨에도 인터넷이 안 될 때: Android 단계별 문제 해결 체크리스트

구독 만료 여부부터 사용 가능한 노드 선택, DNS 확인, 시스템 프록시와 TUN 충돌, 앱별 라우팅까지 순서대로 점검해 프록시는 연결됐지만 웹페이지가 열리지 않는 원인을 찾습니다.

Android 상태 표시줄에 VPN 열쇠 아이콘이 나타났다는 것은 Clash가 시스템 VPN 권한을 얻어 서비스를 시작했다는 뜻일 뿐, 구독이 유효하거나 노드에 연결되거나 DNS가 정상이라는 의미는 아닙니다. 화면에 “연결됨”으로 표시되어도 인터넷이 끊기는 경우는 대개 트래픽이 클라이언트까지 들어온 뒤 노드, 규칙, 도메인 해석 또는 앱별 라우팅 중 한 단계에서 중단된 것입니다.

문제 해결 중에는 여러 옵션을 동시에 바꾸지 마세요. 먼저 장애 범위를 확인한 뒤 “기본 네트워크 → 구성 → 노드 → 정책 그룹 → DNS → TUN 및 시스템 설정 → 앱별 라우팅” 순서로 처리하세요. 각 단계를 마칠 때마다 테스트 페이지를 다시 열고 결과를 기록하면 일시적으로 복구된 뒤에도 실제 원인을 놓치지 않을 수 있습니다.

1단계: 프록시 문제인지 휴대폰 자체의 네트워크 문제인지 확인

먼저 끄기와 켜기 두 가지로 테스트하기

Clash 메인 화면에서 서비스를 중지하고 상태 표시줄의 VPN 아이콘이 사라질 때까지 기다리세요. 그런 다음 Wi-Fi와 모바일 데이터에서 평소 접속 가능한 웹사이트 두 곳을 각각 열어 보세요. Clash를 꺼도 접속되지 않는다면 프록시 설정 문제가 아니므로 라우터, 모바일 네트워크, 비행기 모드, 요금 미납 또는 시스템 네트워크 제한부터 확인해야 합니다.

  1. Clash 서비스를 끄고 Wi-Fi에서 일반 웹페이지와 메신저 앱을 테스트합니다.
  2. Wi-Fi를 끄고 4G 또는 5G로 전환한 뒤 다시 테스트합니다.
  3. Clash를 다시 시작하고 같은 네트워크에서만 재테스트합니다.
  4. “모든 앱이 인터넷에 연결되지 않음”인지, “브라우저만 연결되지 않음”인지, 아니면 “중국 본토 직결은 정상이나 프록시 대상에 접근할 수 없음”인지 기록합니다.

장애 범위는 가장 중요한 분기 기준입니다. 모든 앱에서 인터넷이 끊기면 유효하지 않은 노드, DNS, VPN 충돌 및 잘못된 전체 라우팅을 우선 확인하세요. 특정 앱만 이상하면 앱별 라우팅, 우회 목록, 해당 앱의 QUIC·IPv6·인증서 환경 의존성을 확인하세요. 직결 사이트는 정상인데 프록시 대상에 접근할 수 없다면 대개 노드나 정책 그룹 문제입니다.

IP와 도메인으로 DNS 문제 구분하기

도메인은 먼저 IP로 해석해야 하지만 IP 연결은 도메인 해석을 건너뜁니다. 브라우저에서 라우터 관리 주소(예: 192.168.1.1)를 열어 보세요. LAN IP는 열리는데 모든 도메인 접속이 실패한다면 DNS를 최우선으로 확인해야 합니다. 일부 사이트는 IP 주소로 직접 접속하는 것을 거부하므로 공인 IP 테스트만으로 단정하지 마세요.

증상 우선 확인할 항목 당장은 우선순위가 낮은 항목
Clash를 꺼도 인터넷이 끊김 Wi-Fi, 모바일 데이터, 시스템 네트워크 정책 그룹 및 규칙
직결은 정상, 프록시 대상은 실패 노드, 구독, 정책 선택 휴대폰 하드웨어
IP는 연결되지만 도메인은 실패 DNS, 비공개 DNS, Fake IP 노드 지연 시간 정렬
특정 앱 하나만 실패 앱별 라우팅, 우회, UDP 전체 구독이 작동하지 않음

2단계: 구독 상태와 구성이 실제로 적용됐는지 확인

선택한 구성이 오래된 복사본이 아닌지 확인

많은 문제는 “구독 업데이트는 성공했지만 실제로 실행 중인 것은 다른 로컬 구성”인 데서 발생합니다. Clash Meta for Android의 일반적인 화면을 예로 들면 「구성」으로 들어가 현재 구성 옆의 선택 표시, 업데이트 시간, 파일 이름을 확인하세요. 목록에 이름이 비슷한 구성이 여러 개라면 맨 위 항목만 보지 말고 출처를 하나씩 대조해야 합니다.

  • 구독 서비스가 아직 유효한지, 트래픽 한도를 모두 사용하지 않았는지 확인합니다.
  • 「구성」에서 현재 구독을 업데이트하고 화면에 성공 결과가 표시되는지 확인합니다.
  • 업데이트 후 해당 구성을 다시 선택한 다음 홈으로 돌아가 서비스를 중지하고 다시 시작합니다.
  • 업데이트 결과가 401, 403 또는 404라면 구독 주소나 계정 상태를 확인해야 합니다.
  • 업데이트 중 YAML 파싱 실패가 표시되면 서비스 제공자가 배포한 원본 구성을 복원하고 사용자 지정 오버라이드를 잠시 비활성화하세요.

구독 링크에서 텍스트를 내려받을 수 있다고 해서 그 내용이 반드시 실행 가능한 것은 아닙니다. 노드 목록이 비어 있거나, 정책 그룹이 존재하지 않는 노드를 참조하거나, 규칙 프로바이더 다운로드에 실패하면 코어가 시작된 뒤에도 정상적인 트래픽 전달을 완료하지 못할 수 있습니다. 「로그」로 들어가 서비스를 다시 시작하고 시작 후 처음 30초를 집중적으로 확인하세요. proxy not found, no such host, timeout 또는 규칙 세트 다운로드 오류가 반복되면 해당 항목을 기준으로 계속 원인을 좁혀 가세요.

원본 구성을 덮어쓸 수 있는 설정은 잠시 비활성화하기

클라이언트의 오버라이드 기능은 포트, DNS, 규칙 및 실행 모드를 변경할 수 있습니다. 오래된 오버라이드가 새 구독 구조와 호환되지 않으면 구독 자체는 정상이어도 mihomo 코어에 전달되는 최종 구성이 잘못될 수 있습니다. 「설정」→「오버라이드」 또는 현재 버전에 해당하는 오버라이드 메뉴에서 최근 추가한 DNS·규칙·스크립트 오버라이드를 잠시 끈 뒤 구성을 다시 불러오세요.

3단계: 노드와 정책 그룹 선택 확인

지연 시간 수치만으로는 완전한 사용 가능 여부를 알 수 없음

「프록시」 페이지에서 현재 정책 그룹의 지연 시간 테스트를 실행하세요. 한 번의 테스트에서 80–250ms라면 계속 검증해 볼 수 있습니다. 계속 시간 초과가 표시되거나 여러 노드가 모두 약 5000ms에 고정된다면 테스트 요청에 응답하지 않는 상태입니다. 지연 시간 테스트는 테스트 주소에 대한 연결 결과만 확인하므로 모든 TCP, UDP 및 대상 도메인의 사용 가능성을 보장하지 않습니다.

노드를 선택한 뒤 메인 화면으로 돌아가 실시간 트래픽을 확인하세요. 웹페이지를 열 때 업로드와 다운로드가 계속 0 B/s라면 앱이 VPN에 들어오지 않았거나 우회되었거나 시스템 서비스가 트래픽을 인계받지 못했을 수 있습니다. 업로드는 조금 발생하지만 다운로드가 계속 0이면 노드 연결 불가, 핸드셰이크 실패 또는 반환 경로 차단이 흔한 원인입니다. 양방향 트래픽이 있는데도 페이지가 로딩 상태에 머문다면 DNS, UDP 또는 앱 프로토콜을 계속 확인하세요.

고정 노드를 직접 선택해 자동 그룹 변수 제외하기

  1. 「프록시」에서 규칙이 실제로 참조하는 정책 그룹을 찾으세요. 예를 들면 PROXY, 노드 선택 또는 서비스 제공자가 지정한 그룹 이름입니다.
  2. 당분간 자동 선택, 장애 조치 또는 부하 분산 하위 그룹은 선택하지 마세요.
  3. 지연 시간 테스트 결과가 나온 특정 노드 하나를 선택합니다.
  4. 서로 다른 사이트 두 곳을 연속으로 테스트하고 최소 30초 동안 유지합니다.
  5. 그다음 다른 지역 또는 다른 프로토콜의 노드로 전환해 다시 테스트합니다.

고정 노드는 접속되지만 자동 그룹이 실패한다면 자동 테스트 주소, 허용 오차 설정 또는 그룹 내 후보 노드에 문제가 있는 것입니다. 모든 노드가 실패한다면 같은 지역의 비슷한 항목만 반복해서 바꾸지 말고 구독 상태, 현재 네트워크의 해당 포트 제한 여부, 로그의 핸드셰이크 오류를 확인하세요.

실행 모드 확인

Clash의 일반적인 실행 모드는 규칙, 전체 및 직결입니다. 문제 해결 중 잠시 전환해 볼 수 있지만 결과를 다음과 같이 이해해야 합니다.

  • 규칙 모드: 규칙에 따라 트래픽을 직결, 프록시 또는 거부 정책으로 보냅니다. 일상적으로 가장 많이 사용하는 방식입니다.
  • 전체 모드: 대부분의 트래픽을 전체 정책 그룹으로 보냅니다. 전체 그룹에서 여전히 사용할 수 없는 노드를 선택하고 있다면 모드만 바꿔서는 복구되지 않습니다.
  • 직결 모드: 클라이언트가 트래픽을 인계받은 뒤 직접 외부로 연결할 수 있는지 확인할 때 사용하며, 프록시 노드 검증에는 사용하지 않습니다.

규칙 모드는 실패하지만 전체 모드는 정상이라면 노드의 기본 연결 능력은 확인된 것이므로 다음으로 규칙 매칭 결과를 확인해야 합니다. 「로그」를 열고 실패한 대상에 접속한 뒤 해당 연결 기록을 찾아 최종적으로 어느 정책 그룹에 들어갔는지 확인하세요. 대상이 잘못 DIRECT, REJECT 또는 사용할 수 없는 그룹으로 전달됐다면 노드 포트가 아니라 규칙 출처나 오버라이드를 조정해야 합니다.

4단계: DNS, 비공개 DNS 및 Fake IP 점검

먼저 Android 비공개 DNS 충돌 처리

Android의 비공개 DNS는 암호화된 DNS 해석을 사용합니다. 일부 네트워크에서 지정된 비공개 DNS 호스트에 연결하지 못하면 시스템에 “Wi-Fi는 연결됐지만 도메인이 열리지 않음”으로 나타납니다. 시스템 「설정」→「네트워크 및 인터넷」→「비공개 DNS」로 들어가 임시로 “자동” 또는 “사용 안 함”으로 바꾼 뒤 Clash를 다시 시작하세요. 제조사에 따라 이 메뉴가 「연결 및 공유」 또는 「추가 연결 설정」에 있을 수 있습니다.

비공개 DNS를 끈 직후 복구된다면 기존 비공개 DNS 호스트가 현재 네트워크 또는 Clash의 DNS 처리 경로와 호환되지 않는다는 뜻입니다. 이때는 하나의 해석 경로만 유지해야 합니다. Android 비공개 DNS가 담당하게 하거나 mihomo의 DNS 모듈이 담당하게 하여 두 강제 규칙이 서로 덮어쓰지 않도록 하세요.

DNS 구성 필드 확인

mihomo 구성에서 흔히 사용하는 DNS 구조는 다음과 같습니다. 주소는 필드 간 관계를 설명하기 위한 예시일 뿐이므로 구독 환경과 무관하게 전체를 그대로 교체하지 마세요.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  fallback:
    - tls://1.1.1.1:853

enable은 코어의 DNS 모듈을 제어하고, listen은 로컬 수신 주소를 지정합니다. enhanced-mode의 일반적인 값은 fake-ip 또는 redir-host입니다. TUN을 사용할 때는 DNS 하이재킹 설정과 수신 포트도 일치하는지 확인해야 합니다. 요청을 1053으로 하이재킹하도록 구성했지만 DNS 모듈이 해당 포트에서 수신하지 않으면 도메인 요청이 응답 없는 대상으로 들어갑니다.

redir-host로 Fake IP 호환성 비교하기

Fake IP는 도메인에 예약 주소를 반환한 뒤 코어가 매핑을 바탕으로 트래픽을 전달합니다. 일반적으로 안정적인 규칙 매칭에 도움이 되지만 일부 LAN 기기, 은행 앱, 화면 미러링 도구 또는 특수한 DNS 응답에 의존하는 앱과는 호환되지 않을 수 있습니다. 대부분의 웹사이트는 정상인데 특정 앱만 로그인에 실패하거나, LAN 도메인이 작동하지 않거나, 기기 검색에 문제가 생기는 형태로 나타납니다.

구성 사본을 만들어 enhanced-mode를 fake-ip에서 redir-host로 임시 변경해 비교 테스트할 수 있습니다. 문제가 사라진다면 모든 강화된 DNS 해석을 장기간 끄기보다 해당 도메인에 Fake IP 필터를 추가하는 것이 우선입니다. 변경 후에는 구성을 다시 불러오고 서비스를 재시작해야 하며, 홈 화면으로 돌아가는 것만으로는 기존 매핑이 즉시 만료되지 않습니다.

5단계: TUN, 시스템 VPN 및 수동 프록시 충돌 처리

동시에 실행 중인 VPN 서비스가 하나뿐인지 확인

Android의 VPN 인터페이스는 일반적으로 한 앱만 사용할 수 있습니다. Clash가 시작된 뒤 다른 VPN, 방화벽, 트래픽 필터 또는 업무 프로필 VPN이 이를 대체하면 클라이언트 화면에는 잠시 실행 중으로 표시되어도 시스템 트래픽은 더 이상 Clash를 거치지 않을 수 있습니다. 시스템 「설정」→「네트워크 및 인터넷」→「VPN」으로 들어가 현재 연결된 항목이 실제로 사용 중인 Clash 클라이언트인지 확인하세요.

  • Android VPNService를 사용하는 다른 앱을 중지합니다.
  • 다른 VPN 항목의 “항상 켜진 VPN”을 끕니다.
  • 문제 해결 중에는 “VPN 없이 연결 차단”을 끕니다.
  • Clash의 VPN 요청을 다시 승인한 뒤 상태 표시줄 아이콘을 확인합니다.

“VPN 없이 연결 차단”은 구성이 안정된 뒤 사용하는 것이 좋습니다. 문제 해결 단계에서 Clash 서비스가 중단되거나 구성을 불러오지 못하거나 시스템이 서비스를 종료하면 이 옵션이 모든 네트워크를 차단해 노드가 고장 난 것처럼 보이게 합니다.

Wi-Fi에 남아 있는 수동 프록시 삭제

일부 사용자는 Wi-Fi 고급 설정에 127.0.0.1과 7890을 입력해 두기도 합니다. 현재 클라이언트가 TUN/VPN으로 트래픽을 인계받거나 로컬 mixed-port가 다른 값으로 바뀌었다면 이 수동 프록시가 브라우저 트래픽을 수신하지 않는 포트로 보냅니다. 시스템 「설정」→「Wi-Fi」→「현재 네트워크」→「프록시」에서 문제 해결 중에는 먼저 “없음”으로 설정하세요.

포트 7890은 mixed-port로 자주 사용되고, 7891은 SOCKS 또는 리디렉션 구성에서 흔히 사용되며, 9090은 외부 제어 인터페이스에 자주 쓰입니다. 하지만 실제 값은 현재 구성에 따라 완전히 다릅니다. 일반적인 포트 번호만 보고 로컬 수신 상태를 추측하지 말고 클라이언트 설정이나 로그에서 실제 포트를 확인하세요.

TUN 스택을 바꿔 호환성 테스트

mihomo의 TUN 구현은 system, gVisor 또는 mixed 같은 스택 옵션을 제공할 수 있으며, 지원 여부는 클라이언트 버전과 시스템에 따라 다릅니다. 시스템이나 클라이언트를 업데이트한 뒤 갑자기 “서비스는 시작되지만 모든 연결이 시간 초과됨” 상태가 되었다면 「설정」→「네트워크」→「TUN」 메뉴에서 현재 값을 기록하고 지원되는 다른 스택으로 바꿔 다시 테스트하세요.

전환 후에는 서비스를 완전히 중지하고 5초간 기다린 다음 다시 시작하세요. 실행 중 스위치만 바꾸면 이전 VPN 인터페이스와 연결 캐시가 남아 있을 수 있습니다. 한 스택에서 TCP는 정상인데 음성 통화, 게임 또는 HTTP/3만 이상하다면 노드 전체가 사용할 수 없다고 단정하지 말고 UDP 지원을 계속 확인하세요.

6단계: 앱별 라우팅, 우회 목록 및 배터리 절전 제한 확인

특정 앱만 인터넷이 끊길 때 앱별 라우팅 확인

앱별 라우팅은 Android 앱 패키지 이름을 기준으로 VPN에 들어갈지 결정합니다. 화이트리스트 모드는 선택한 앱만 인계받고, 블랙리스트 모드는 선택한 앱을 우회합니다. 두 모드를 반대로 이해하면 브라우저는 정상인데 대상 앱만 프록시를 사용하지 않거나, 일부 앱만 인터넷에 연결되는 문제가 발생합니다.

  1. Clash의 「설정」→「네트워크」→「앱별 라우팅」 또는 현재 버전에 해당하는 메뉴로 들어갑니다.
  2. 현재 화이트리스트와 블랙리스트 중 어떤 방식인지 확인합니다.
  3. 앱별 라우팅을 잠시 꺼서 일반 앱이 모두 VPN에 들어가도록 합니다.
  4. 서비스를 다시 시작하고 이전에 실패했던 앱을 테스트합니다.
  5. 라우팅을 복원할 때는 앱을 하나씩 추가하고 패키지 이름을 한꺼번에 대량으로 가져오지 마세요.

업무 프로필, 앱 복제 및 듀얼 앱은 서로 다른 UID를 사용할 수 있습니다. 기본 공간에서 앱을 선택했더라도 업무 프로필의 복제 앱에 같은 규칙이 적용된다는 뜻은 아닙니다. 복제 앱만 실패한다면 해당 사용자 공간에서 VPN 권한과 앱 목록을 확인하세요.

LAN 우회 및 라우팅 제외 설정 확인

프린터, 화면 미러링 및 라우터 관리 페이지를 사용할 수 있도록 구성에서 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 같은 사설 네트워크 대역을 우회하는 경우가 많습니다. 원격 서비스도 이 주소 대역으로 리소스를 제공한다면 우회 범위가 너무 넓어 트래픽이 로컬 인터페이스로 직접 나간 뒤 실패할 수 있습니다.

반대로 LAN 트래픽을 모두 원격 프록시로 보내면 라우터 관리 페이지와 로컬 기기에도 접근하지 못할 수 있습니다. 로그에서 대상 IP의 아웃바운드 정책을 확인해 사설 주소가 DIRECT로 들어가는지 점검하세요. 원격 접근이 필요한 내부 주소는 실제 네트워크 설계에 맞게 처리해야 합니다.

백그라운드 서비스에 대한 시스템 제한 해제

일부 Android 시스템은 화면을 잠근 뒤 백그라운드 VPN 서비스를 제한해 처음에는 작동하다가 몇 분 후 모든 연결이 멈추게 합니다. 시스템 「설정」→「앱」→「Clash 클라이언트」→「배터리」에서 “제한 없음”을 선택하거나 백그라운드 활동을 허용하세요. 이어서 「모바일 데이터 및 Wi-Fi」에서 백그라운드 데이터와 데이터 무제한 사용도 허용합니다.

화면을 잠근 뒤 5–10분 후에만 문제가 발생하고 화면을 켜면 복구된다면 노드보다 배터리 절전 정책이 더 의심스럽습니다. 제조사 시스템의 자동 시작, 백그라운드 팝업 및 작업 잠금 권한도 확인하세요. 한 번에 하나만 조정하고 매번 완전한 화면 잠금 테스트를 진행하세요.

7단계: 로그를 바탕으로 최종 원인 파악

재현 가능한 테스트 기록 만들기

로그가 많다면 먼저 로그를 지우거나 현재 시간을 기록한 뒤 실패한 대상 하나만 방문하세요. 다음 형식으로 기록하는 것이 좋습니다.

네트워크: 가정용 Wi-Fi
실행 모드: 규칙
구성 업데이트 시간: 2026-08-14 10:32
정책 그룹: PROXY → 노드 A
테스트 시간: 10:36:20
증상: 도메인 로딩 15초 후 시간 초과
로그 키워드: DNS timeout / connection refused

완전한 연결 기록 하나로 보통 세 가지를 확인할 수 있습니다. 도메인 해석이 완료됐는지, 규칙이 연결을 어디로 보냈는지, 아웃바운드 연결이 어느 단계에서 실패했는지입니다. timeout은 대기 시간 초과를 뜻하며 노드, 대상 또는 중간 네트워크에 접근하지 못했을 수 있습니다. connection refused는 상대방이 연결을 적극적으로 거부했다는 뜻이고, network unreachable은 라우팅, 인터페이스 또는 IPv6와 관련된 경우가 많습니다. TLS 핸드셰이크 오류가 발생하면 시간, SNI, 프로토콜 매개변수 및 네트워크 간섭을 추가로 확인하세요.

최소 구성으로 클라이언트와 구독 문제 구분하기

앞의 단계를 모두 수행해도 원인을 찾지 못했다면 서비스 제공자가 제공한 원본 구독을 사용하고 사용자 지정 오버라이드, 앱별 라우팅 및 추가 규칙을 끈 뒤 고정 노드 하나만 테스트하세요. 원본 구성이 정상이라면 로컬 수정이 원인입니다. 원본 구성도 실패하지만 같은 구독이 다른 네트워크에서는 정상이라면 현재 네트워크 환경을 집중적으로 확인해야 합니다. 여러 기기와 네트워크에서 모두 실패한다면 구독 제공자에게 노드 상태를 문의하세요.

테스트 중에는 클라이언트, 구독, 네트워크, DNS 및 노드를 동시에 바꾸지 마세요. 한 번에 변수 하나만 변경하고 최소한 서비스 시작, 도메인 접속, 로그 확인을 각각 한 번 완료하세요. “연결됨에도 인터넷이 안 되는” 문제에서는 자주 재설치하는 것보다 안정적으로 재현하는 편이 훨씬 유용합니다.

문제 해결 결과 빠른 확인표

테스트 결과 가능한 원인 다음 단계
Clash를 끈 뒤 복구됨 구성, 노드, DNS 또는 VPN 인계 문제 이 글의 순서대로 계속 확인
고정 노드는 사용 가능하지만 자동 그룹은 사용 불가 자동 그룹 후보 또는 테스트 주소 문제 그룹 구성원 및 상태 확인 조정
전체 모드는 사용 가능하지만 규칙 모드는 실패 규칙 매칭 또는 정책 그룹 참조 오류 로그에서 실제 아웃바운드 확인
비공개 DNS를 끈 뒤 복구됨 시스템 DNS 해석 경로 충돌 하나의 DNS 방식으로 통합
앱별 라우팅을 끈 뒤 복구됨 화이트리스트, 블랙리스트 또는 UID 선택 오류 최소 앱 목록을 다시 구성
모바일 데이터로 전환한 뒤 복구됨 Wi-Fi 네트워크 제한 또는 라우팅 문제 라우터 DNS, IPv6 및 포트 정책 확인
화면을 잠그면 작동 중지 절전 정책이 백그라운드 서비스를 종료 백그라운드 실행 및 배터리 무제한 사용 허용
설치 패키지 페이지로 이동