Clash 연결됨에도 인터넷이 안 될 때? 순서대로 확인하는 8단계 문제 해결 체크리스트

이런 문제는 네트워크 경로를 바깥쪽부터 안쪽으로 확인하는 방식이 적합합니다. 기본 네트워크, 원격 노드, 기기 시간, 규칙 선택, DNS, 프록시 진입점, TUN 인계 순서로 확인하고 마지막에야 설정 파일과 코어 로그를 살펴보세요. 각 단계에서는 한 번에 변수 하나만 바꾸고 즉시 다시 테스트해야 합니다. 노드 변경, DNS 수정, TUN 활성화를 동시에 진행하면 실제 원인을 구분하기 어렵습니다.

1단계: Clash를 끄고 기본 네트워크 확인하기

먼저 프록시 서비스를 중지하세요. 모드만 ‘규칙’에서 ‘직접 연결’로 바꾸는 것으로는 부족합니다. Android 클라이언트에서는 메인 화면의 실행 스위치를 끄고 상태 표시줄의 VPN 표시가 사라졌는지 확인하세요. Windows 또는 macOS 클라이언트는 ‘시스템 프록시’도 꺼야 코어가 중지된 뒤에도 요청이 로컬 포트로 전송되는 일을 막을 수 있습니다.

Clash 또는 mihomo 코어를 끕니다.
시스템 프록시와 TUN 모드를 끕니다.
현재 Wi-Fi 연결을 끊었다가 다시 연결하거나, 비행기 모드를 한 번 켰다 끕니다.
이전에 방문하지 않았던 일반 웹페이지를 열어 브라우저 캐시로 인한 오판을 피합니다.
Wi-Fi와 모바일 데이터를 각각 테스트하고 어느 네트워크에서 실패하는지 기록합니다.

Clash를 꺼도 어떤 웹페이지에도 접속할 수 없다면 문제는 상위 네트워크에 있습니다. Wi-Fi 포털 인증 미완료, 라우터 DNS 이상, 모바일 데이터 제한, 현재 네트워크가 로컬 네트워크만 제공하는 상황 등이 흔한 원인입니다. 공용 Wi-Fi라면 먼저 일반 HTTP 페이지에 접속해 인증 페이지를 표시해 보세요. 직접 연결이 복구된 뒤에야 이후의 프록시 점검이 의미가 있습니다.

2단계: 노드를 바꿔 구독 정상 여부와 노드 사용 가능 여부 구분하기

구독이 업데이트된다고 해서 구독에 포함된 모든 노드가 연결된다는 뜻은 아닙니다. 구독 다운로드는 대개 한 번의 HTTPS 요청이지만, 프록시 접속에는 도메인 확인, TCP 또는 UDP 핸드셰이크, TLS 시간 검증, 프로토콜 매개변수 및 원격 서비스 상태가 함께 관여합니다.

먼저 지연 시간을 테스트한 뒤 실제 접속하기

‘프록시’ 또는 ‘Proxies’ 페이지에서 현재 전략 그룹을 찾아 서로 다른 회선 세 개 이상에 지연 시간 테스트를 실행하세요. 테스트 주소는 보통 설정의 url로 지정되며, 예를 들어 https://www.gstatic.com/generate_204를 사용할 수 있습니다. 결과는 다음과 같이 해석할 수 있습니다:

80–300 ms: 해당 노드가 적어도 현재 테스트 요청은 처리했다는 뜻이지만, 모든 웹사이트 접속을 보장하지는 않습니다.
800 ms 이상: 회선 혼잡, 우회 경로 또는 패킷 손실이 뚜렷해 실제 접속에서 시간 초과가 자주 발생할 수 있습니다.
timeout: 테스트 시간 내에 요청이 완료되지 않았으므로 먼저 노드를 바꿔 보세요.
0 ms, 빈 결과 또는 즉시 실패: 테스트 주소, DNS, 권한 또는 코어 상태에 문제가 있을 수 있습니다.

같은 자동 선택 그룹 안에서만 반복해서 클릭하지 마세요. 서로 다른 지역과 서버 이름을 가진 노드 두 개를 수동으로 선택한 뒤 각각 웹페이지에 접속해 보세요. 한 노드만 작동하고 다른 노드가 실패한다면 문제는 회선 측으로 좁혀진 것이므로 클라이언트를 재설치할 필요가 없습니다. 모든 노드가 동시에 시간 초과되면 기기 시간과 DNS를 계속 확인하세요.

전략 그룹이 DIRECT 또는 REJECT로 선택되어 있지 않은지 확인하기

설정에 따라 기본 선택 그룹의 이름이 ‘노드 선택’, ‘Proxy’ 또는 다른 이름일 수 있습니다. 해당 그룹을 열어 현재 선택 항목이 DIRECT, REJECT 또는 작동하지 않는 하위 전략 그룹이 아닌지 확인하세요. 자동 전략 그룹에는 이전 테스트 결과가 남아 있을 수 있으므로 수동으로 바꾼 뒤 약 5–10초 기다렸다가 다시 테스트하세요.

3단계: 시스템 시간과 시간대 보정하기

TLS 인증서 검증에는 정확한 시스템 시간이 필요합니다. 기기의 날짜가 몇 시간 또는 며칠 어긋나면 노드 핸드셰이크, 구독 업데이트 및 HTTPS 웹페이지 접속이 모두 실패할 수 있습니다. 로그에는 certificate has expired, not yet valid, TLS handshake failed 같은 메시지가 자주 나타납니다.

Android에서는 ‘설정’ → ‘시스템’ → ‘날짜 및 시간’으로 이동해 ‘자동으로 시간 설정’과 ‘자동 시간대 설정’을 켜세요. 일부 제조사 기기에서는 ‘설정’ → ‘추가 설정’ → ‘날짜 및 시간’에 있습니다. 활성화한 뒤 통신사 또는 네트워크 시간 동기화를 기다리고 Clash를 완전히 종료한 다음 다시 시작하세요.

데스크톱 시스템도 시간 동기화 상태를 확인해야 합니다. Windows에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 즉시 동기화를 실행할 수 있습니다. 시간대는 현재 위치와 일치해야 하며, 중국 표준시는 일반적으로 UTC+08:00으로 표시됩니다. 시계를 대략 맞추는 것만으로는 동기화가 완료되지 않습니다. 몇 분의 오차도 일부 단기 인증서나 인증 요청에 영향을 줄 수 있습니다.

4단계: 프록시 모드를 바꿔 규칙 매칭 문제 확인하기

Clash의 대표적인 모드는 rule, global, direct입니다. 규칙 모드는 설정 파일의 rules를 위에서 아래로 매칭하고, 일치하는 규칙을 지정된 전략 그룹으로 전달합니다. 규칙 순서가 잘못되었거나 전략 그룹 이름이 바뀌었거나 마지막 규칙이 빠지면 특정 웹사이트에 접속하지 못할 수 있습니다.

짧게 글로벌 모드로 비교 테스트하기

현재 모드와 선택된 노드를 기록합니다.
모드를 ‘규칙’에서 ‘글로벌’로 바꿉니다.
글로벌 전략 그룹에서 지연 시간이 정상인 노드 하나를 수동으로 선택합니다.
대상 웹페이지를 새로 열고 기존 탭만 새로 고치지 마세요.
테스트가 끝나면 ‘규칙’ 모드로 되돌려 프록시 적용 범위를 불필요하게 넓히지 않도록 합니다.

글로벌 모드에서는 접속되지만 규칙 모드에서는 접속되지 않는다면 노드와 기본 연결은 대체로 정상이며, 문제는 규칙 또는 전략 그룹에 있습니다. 이때 ‘연결’ 기록을 열어 대상 도메인에 해당하는 Rule, Rule Payload, Chains를 확인하세요. 대상 트래픽이 DIRECT로 처리된다면 도메인 규칙이 더 앞에 있는 직접 연결 규칙에 덮어쓰였는지 확인합니다.

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

규칙은 위에서 아래로 실행되며, 가장 먼저 일치한 항목이 적용됩니다. 마지막에는 일반적으로 MATCH,PROXY 같은 기본 처리 규칙이 필요합니다. 실제 전략 그룹 이름은 proxy-groups에 있는 이름과 대소문자 및 공백까지 완전히 일치해야 합니다. 구독으로 생성된 설정은 광범위하게 직접 수정하기보다 클라이언트의 오버라이드 기능을 우선 사용하고, 원본 구독은 복구용으로 보관하세요.

5단계: DNS 확인과 Fake-IP 매핑 점검하기

웹페이지에 서버를 찾을 수 없다는 메시지가 표시되거나 모든 노드 속도 테스트가 실패하고, IP 주소로는 접속되지만 도메인으로는 접속되지 않는다면 DNS를 중점적으로 확인하세요. Clash Meta, 즉 mihomo 코어에서는 fake-ip 또는 redir-host가 대표적인 향상 모드입니다. Fake-IP는 먼저 애플리케이션에 매핑 주소를 반환한 뒤 코어가 매핑 정보를 바탕으로 실제 도메인을 처리하므로 DNS 요청이 실제로 Clash를 거치는지 확인해야 합니다.

캐시를 지운 뒤 DNS 경로 다시 시작하기

Clash를 중지하고 약 5초 기다립니다.
Android에서 비행기 모드를 한 번 켰다 끄거나 Wi-Fi 연결을 끊었다가 다시 연결합니다.
브라우저의 DNS 캐시를 지웁니다. 가장 간단한 방법은 브라우저 프로세스를 완전히 종료한 뒤 다시 여는 것입니다.
Clash를 다시 시작한 뒤 이전에 테스트하지 않았던 도메인에 접속합니다.

Android의 ‘비공개 DNS’도 DNS 확인 경로를 바꿀 수 있습니다. ‘설정’ → ‘네트워크 및 인터넷’ → ‘비공개 DNS’로 이동해 임시로 ‘자동’으로 바꾸어 비교하세요. 제조사에 따라 메뉴 이름이 ‘연결 및 공유’ → ‘비공개 DNS’일 수도 있습니다. 지정한 암호화 DNS 호스트에 현재 네트워크에서 연결할 수 없으면 애플리케이션이 결과를 오래 기다릴 수 있습니다.

설정의 DNS 핵심 항목 확인하기

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

listen 포트를 다른 프로그램이 사용하고 있지 않아야 합니다. 위의 1053은 흔한 예시일 뿐 실제 설정은 다를 수 있습니다. 로그에 address already in use가 나타나면 포트 충돌입니다. 암호화 DNS 주소는 해당 포트가 네트워크에서 허용되는지에도 영향을 받으며, DoT는 보통 853, DoH는 보통 443을 사용합니다.

6단계: 시스템 프록시 주소, 포트 및 수신 상태 확인하기

데스크톱에서 가장 흔한 현상은 Clash 코어는 정상적으로 실행되지만 시스템 프록시가 이전 포트를 계속 가리키는 경우입니다. 대표적인 혼합 포트는 7890이고 SOCKS 포트는 7891일 수 있지만, 구독과 클라이언트에서 값을 변경할 수 있으므로 기본값만으로 판단해서는 안 됩니다.

클라이언트의 ‘설정’ → ‘매개변수 설정’ 또는 ‘General’ 페이지에서 mixed-port, port, socks-port 값을 기록하세요. 그런 다음 운영체제 프록시가 127.0.0.1과 동일한 포트를 가리키는지 확인합니다. 클라이언트가 SOCKS 수신만 활성화했는데 시스템 HTTP 프록시에 해당 포트를 입력하면 일부 프로그램은 즉시 연결에 실패합니다.

터미널에서 명시적 프록시 요청을 보내 시스템 프록시 설정을 우회하고 로컬 진입점이 작동하는지 확인할 수 있습니다. 아래 명령은 혼합 포트가 7890이라고 가정합니다:

curl -I --connect-timeout 10 \
  -x http://127.0.0.1:7890 \
  https://example.com

명시적 프록시 요청은 성공하지만 브라우저가 실패한다면 문제는 대개 시스템 프록시 또는 브라우저 자체 설정에 있습니다. 명령이 ‘connection refused’를 즉시 반환하면 해당 포트에서 수신 중인 서비스가 없다는 뜻이므로 코어 실행 여부와 포트 변경 여부를 확인하세요. 요청이 멈춘 뒤 시간 초과되면 로컬 포트는 정상일 수 있지만 노드, DNS 또는 외부 연결에 문제가 남아 있을 수 있습니다.

브라우저는 작동하지만 터미널 명령이 작동하지 않는다고 해서 반드시 Clash 문제인 것은 아닙니다. 많은 명령줄 프로그램은 운영체제 프록시를 자동으로 읽지 않으므로 HTTP_PROXY, HTTPS_PROXY를 설정하거나 명령 인자에 프록시를 명시해야 합니다.

7단계: TUN 모드, VPN 권한 및 애플리케이션 충돌 확인하기

Android에서 Clash는 보통 시스템 VpnService를 통해 로컬 VPN 인터페이스를 만듭니다. 연결 요청이 승인되었다는 것은 인터페이스를 생성할 수 있다는 뜻일 뿐입니다. 시스템이 권한을 철회했거나 배터리 절약 정책이 백그라운드 서비스를 종료했거나 다른 VPN 앱이 인터페이스를 점유하면 화면에는 잠시 실행 중으로 표시되어도 트래픽이 정상적으로 전달되지 않을 수 있습니다.

다른 VPN, 네트워크 필터링 및 방화벽 앱을 중지합니다.
Android 시스템의 VPN 설정에서 기존 연결을 끊습니다.
Clash로 돌아가 서비스를 다시 시작하고 시스템 연결 요청을 확인합니다.
먼저 TUN을 끄고 클라이언트의 기본 VPN 인계 방식만 사용해 테스트합니다.
데스크톱에서는 반대로 테스트합니다. 시스템 프록시가 작동하는 것을 확인한 뒤 프록시 설정을 읽지 않는 프로그램에 TUN 인계를 활성화합니다.

데스크톱 TUN 모드는 가상 네트워크 어댑터를 만들고 라우팅을 조정해야 합니다. mihomo에서 자주 사용하는 매개변수로는 stack: mixed, auto-route: true, auto-detect-interface: true가 있습니다. 기기가 유선 네트워크, Wi-Fi, 가상 머신 어댑터 및 기업 VPN에 동시에 연결되어 있으면 자동 외부 인터페이스 선택이 잘못될 수 있습니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

문제 해결 중에는 먼저 TUN을 끄고 시스템 프록시로 HTTP 및 HTTPS가 복구되는지 확인하세요. 시스템 프록시는 정상인데 TUN을 켠 뒤 실패한다면 라우팅 생성, 가상 네트워크 어댑터 권한, 현재 기본 게이트웨이 및 다른 VPN과의 충돌을 중점적으로 확인합니다. ‘TUN 활성화’를 모든 연결 문제의 만능 해결책으로 생각하지 마세요. TUN은 트래픽 인계 범위를 조정할 뿐, 사용할 수 없는 노드나 잘못된 DNS를 고쳐 주지는 않습니다.

8단계: 로그 확인, 설정 롤백 및 구독 재가져오기

앞의 7단계로도 원인을 찾지 못했다면 설정의 완전성과 실행 로그를 확인하세요. 먼저 로그 수준을 info로 설정하고 문제를 한 번 재현한 뒤 최신 기록을 바로 확인합니다. 정보가 부족할 때만 잠시 debug를 사용하세요. 상세 로그는 빠르게 늘어나 핵심 오류를 찾기 더 어려워질 수 있습니다.

로그 일부	우선 확인할 항목
`i/o timeout`	노드에 연결할 수 없음, 패킷 손실, 외부 연결 차단
`connection refused`	대상 포트가 수신 대기 중이 아니거나 원격 서비스가 연결을 거부함
`no such host`	DNS 확인 실패, 상위 DNS에 연결할 수 없음
`address already in use`	로컬 프록시 포트 또는 DNS 포트 충돌
`authentication failed`	노드 인증 정보, UUID, 비밀번호 또는 구독 내용 만료
`certificate` 관련 오류	시스템 시간, 인증서 체인 또는 TLS 매개변수

구독 업데이트 후 문제가 발생했다면 먼저 업데이트 전까지 작동하던 로컬 설정으로 전환하세요. 여러 설정이 함께 있을 때는 현재 활성화된 Profile이 방금 확인한 설정과 동일한지 확인합니다. 그런 다음 구독을 다시 가져오고 업데이트 시간과 설정 파싱 결과를 확인하세요. 파싱에 실패하면 불완전하게 로드된 상태를 계속 사용하지 말고 이전 설정으로 복구하거나 구독 제공자에게 설정 형식을 문의하세요.

수동 오버라이드도 자주 문제를 일으키는 원인입니다. dns, rules, proxy-groups, tun 및 포트 항목을 중점적으로 확인하세요. YAML은 들여쓰기에 민감하므로 공백으로 계층을 일관되게 유지해야 합니다. 전략 그룹이 존재하지 않는 노드 이름을 참조하거나, 규칙이 존재하지 않는 전략 그룹을 가리키거나, 같은 포트를 중복 정의하면 시작이 실패하거나 일부 기능이 작동하지 않을 수 있습니다.

마지막 최소 복구 순서

현재 설정 이름, 포트 및 주요 오버라이드 항목을 내보내거나 기록합니다.
TUN, 비공개 DNS 및 브라우저 자체 DNS를 끕니다.
파싱이 확인된 구독 설정을 가져옵니다.
지연 시간이 정상인 노드를 하나 선택합니다.
먼저 글로벌 모드로 테스트한 뒤 규칙 모드로 돌아갑니다.
기본 프록시가 복구되면 DNS 오버라이드와 TUN을 하나씩 다시 활성화합니다.

재테스트 기준: 웹페이지를 한 번 새로 고치는 것만으로 판단하지 않기

수정 후에는 최소 세 종류의 테스트를 실행하세요. 첫째, 서로 다른 도메인의 HTTPS 페이지 두 개를 엽니다. 둘째, Wi-Fi와 모바일 데이터를 한 번 전환해 네트워크가 바뀐 뒤에도 서비스가 다시 연결되는지 확인합니다. 셋째, ‘연결’ 기록에서 대상 도메인이 예상한 규칙과 노드에 매칭되었는지 확인합니다. 한 번의 속도 테스트가 정상이라는 것은 당시 테스트 주소에 접속할 수 있었다는 뜻일 뿐입니다.

Android에서는 화면을 잠근 채 약 3–5분 기다린 뒤 잠금을 해제하고 웹페이지에 접속해 보세요. 화면을 잠근 뒤에만 인터넷이 끊긴다면 노드 프로토콜을 계속 수정하지 말고 백그라운드 실행 권한, 배터리 최적화 및 제조사 절전 정책을 확인해야 합니다. 데스크톱에서는 브라우저나 터미널을 다시 시작해 기존 프록시 연결과 DNS 캐시가 해제되었는지 확인할 수 있습니다.

전체 문제 해결의 목표는 상태 버튼을 다시 ‘연결됨’으로 바꾸는 것이 아닙니다. 기기가 기본 네트워크를 확보하고, DNS가 도메인을 확인하며, 트래픽이 올바른 프록시 진입점으로 들어가고, 규칙이 예상한 전략 그룹을 선택하고, 노드가 외부 연결을 완료한 뒤 반환 데이터가 같은 경로로 애플리케이션에 전달되는지 반복적으로 확인하는 것입니다. 이 경로를 따라 단계별로 검증하면 대부분 8단계 안에 문제 범위를 명확하게 좁힐 수 있습니다.