1. VPN 실행과 실제 인터넷 연결을 구분하세요
‘연결됨’은 클라이언트의 로컬 서비스나 VPN 터널이 시작됐다는 뜻일 뿐, 노드·DNS·라우팅 규칙이 정상 작동한다는 의미는 아닙니다. 먼저 Clash를 중지하고 휴대전화 자체의 인터넷 연결을 확인하세요. 그런 다음 서비스를 시작해 ‘트래픽 가로채기 → 규칙 매칭 → 노드 연결 → 대상 주소 확인 및 접속’ 순서로 점검합니다. 한 번에 한 가지씩만 변경해야 문제가 해결됐을 때 원인을 파악하기 쉽습니다.
- 클라이언트 서비스를 중지한 뒤 브라우저에서 평소 직접 접속되는 사이트를 열어 보세요. 여전히 접속되지 않으면 Wi-Fi, 모바일 데이터, 요금 미납 또는 공용 네트워크 로그인 문제부터 해결하세요.
- Wi-Fi와 모바일 데이터에서 각각 테스트하세요. 한쪽에서만 실패한다면 해당 네트워크의 인증, DNS, 라우팅 제한과 노드 포트 연결 상태를 먼저 확인하세요.
- Clash를 시작한 뒤 같은 브라우저에서 같은 주소를 열어 보세요. 모든 사이트에서 실패하는지, 프록시가 필요한 사이트에서만 실패하는지, 특정 앱에서만 실패하는지 기록하세요.
- 테스트 시간, 현재 설정, 모드, 선택한 노드를 기록한 다음 해당 시점의 로그를 확인하세요.
2. 안드로이드 VPN 권한과 충돌 확인
Clash for Android에서 설정을 선택한 뒤 메인 화면으로 돌아가 서비스를 시작하세요. 처음 실행할 때 안드로이드 시스템의 VPN 연결 요청이 표시되면 권한을 허용해야 합니다. 알림창의 VPN 아이콘은 참고할 수 있지만, 시스템 VPN 화면에서 실제 연결을 사용하는 앱도 확인하세요.
시스템 설정에서 확인할 항목
- 순정 안드로이드에서는 보통 ‘설정’ → ‘네트워크 및 인터넷’ → ‘VPN’에서 확인할 수 있습니다. 제조사마다 메뉴가 다르므로 설정에서 ‘VPN’을 검색해도 됩니다. 현재 활성화된 항목이 점검 중인 클라이언트인지 확인하세요.
- 같은 안드로이드 사용자나 프로필에서는 보통 한 앱만 VPN 인터페이스를 사용할 수 있습니다. 다른 VPN, 로컬 VPN 방식의 필터링 앱, 패킷 캡처 도구를 먼저 중지한 다음 Clash를 다시 시작하세요.
- 해당 VPN의 설정에서 ‘VPN 상시 연결’과 ‘VPN을 사용하지 않는 연결 차단’을 확인하세요. 문제를 진단하는 동안에는 클라이언트가 중지된 뒤에도 시스템이 네트워크를 차단하지 않도록 후자를 잠시 끌 수 있습니다. 테스트가 끝나면 필요에 따라 원래 설정으로 되돌리세요.
- 업무용 프로필이나 앱 복제 기능을 사용한다면 문제가 발생한 브라우저와 Clash가 같은 프로필에 있는지 확인하세요. 개인 프로필의 VPN이 업무 프로필 트래픽까지 처리한다고 가정하면 안 됩니다.
시스템 권한 요청 창이 나타나지 않으면 먼저 서비스를 중지했다가 다시 시작하고, 시스템 VPN 목록에 다른 활성 연결이 남아 있는지 확인하세요. 연결 버튼을 반복해서 눌러도 다른 앱이 VPN을 사용 중인 문제는 해결되지 않습니다.
3. 설정, 프록시 모드와 정책 그룹 확인
‘구성’으로 이동해 실제로 활성화된 항목이 최근 업데이트되어 정상적으로 불러온 구성인지 확인하세요. 구독 업데이트가 성공해도 모든 노드를 사용할 수 있는 것은 아니며, 구성을 가져온 뒤 새 구성으로 자동 전환되지 않을 수도 있습니다. 메인 화면에서 구성 이름을 확인한 뒤 ‘프록시’를 열어 현재 모드와 정책 그룹을 점검하세요.
| 모드 | 용도 및 확인 사항 |
|---|---|
| 규칙 / Rule | 규칙 순서에 따라 연결 경로를 선택합니다. 대상 도메인이 어떤 정책 그룹에 매칭됐는지, 그룹에서 실제로 어떤 노드를 선택했는지 확인하세요. |
| 전역 / Global | 모든 트래픽을 전역 정책으로 보내는 임시 모드입니다. 전역 정책에서 DIRECT나 작동하지 않는 노드가 아니라 사용 가능한 프록시를 선택했는지 확인하세요. |
| 직접 연결 / Direct | 프록시를 거치지 않고 대상에 연결합니다. 로컬 네트워크를 비교할 때 쓸 수 있지만, 프록시 노드의 작동 여부를 판단하는 기준으로는 사용할 수 없습니다. |
테스트 중 자동 선택 그룹이 연결 경로를 계속 바꾸지 않도록 ‘프록시’에서 노드를 직접 선택하세요. 전역 모드에서는 연결되지만 규칙 모드에서는 실패한다면 클라이언트를 바로 재설치하기보다 규칙과 정책 그룹을 먼저 살펴보세요. 두 모드 모두 실패한다면 노드, DNS, VPN 트래픽 처리 여부를 확인하세요.
정책 그룹에서 최종 노드까지 확인하기
구성에 표시된 그룹 이름은 단순한 이름일 뿐입니다. 예를 들어 선택 그룹이 다른 자동 선택 그룹을 가리키면 실제 노드는 뒤에 있는 그룹이 정합니다. 관련 정책을 펼쳐 최종 연결 경로까지 확인하고, DIRECT, REJECT 또는 사용할 수 없는 노드를 잘못 선택하지 않았는지 살펴보세요. 노드를 바꾼 뒤에는 새 연결을 만들어야 합니다. 기존 웹페이지 연결은 새 노드로 즉시 전환되지 않을 수 있습니다.
4. 지연 시간 테스트와 실제 웹 접속은 따로 확인하세요
지연 시간 결과는 테스트 주소에 대한 노드의 응답만 보여 줍니다. 180ms로 표시돼도 대상 사이트의 HTTPS 연결, 계정 로그인, 동영상 요청까지 성공한다는 보장은 없습니다. 테스트 시간 초과 역시 테스트 주소에 접속할 수 없어서일 수 있습니다. 숫자 하나만으로 전체 연결 상태를 판단하지 마세요.
- 노드 A를 직접 선택하고 클라이언트의 지연 시간 테스트를 실행한 다음, 브라우저 새 탭에서 대상 주소를 여세요.
- 노드 B로 바꾸고 같은 작업을 반복하세요. 같은 회선에서 노드 이름만 바꾸기보다 서로 다른 회선을 선택하는 편이 좋습니다.
- 모든 노드에서 실패한다면 서비스를 중지하고 Wi-Fi와 모바일 데이터를 전환한 뒤, 서비스를 다시 시작해 테스트하세요.
- 휴대전화의 ‘날짜 및 시간’ 설정에서 자동 설정을 켜세요. 기기 시간이 크게 어긋나면 TLS 인증서 검증에 실패할 수 있습니다.
로그의 connection refused는 보통 대상 서버나 중간 장비가 연결을 거부했다는 뜻입니다. i/o timeout은 응답을 기다리다 시간이 초과됐다는 의미일 뿐, 비밀번호 오류라고 단정할 수 없습니다. 구독을 업데이트한 뒤 알 수 없는 필드나 프로토콜 오류가 발생했다면 클라이언트 커널이 해당 설정을 지원하는지 확인하세요. 원본 Clash와 Clash Meta(현재 이름: mihomo)는 지원하는 설정이 완전히 같지 않습니다.
5. DNS 변조, 비공개 DNS와 브라우저 DNS 확인
도메인을 확인할 수 없어도 VPN 연결은 유지되고 노드 지연 시간 테스트는 정상일 수 있지만, 웹페이지는 열리지 않을 수 있습니다. 먼저 로그에 lookup, DNS, no such host 또는 DNS 시간 초과가 있는지 확인한 뒤 현재 구성의 dns 항목을 살펴보세요. 모든 DNS 서버를 한꺼번에 바꾸지는 마세요.
DNS 확인 경로를 따라 차례로 점검하세요
- 안드로이드 ‘설정’에서 ‘비공개 DNS’를 검색하세요. 엄격한 제공업체 호스트 이름이 설정돼 있다면 원래 값을 기록한 뒤, 비교 테스트를 위해 잠시 ‘자동’으로 바꾸세요.
- 브라우저 자체의 ‘보안 DNS 사용’ 설정을 확인하세요. 브라우저가 HTTPS로 직접 DNS를 확인할 수 있어 일반적인 53번 포트 DNS 변조가 적용되지 않을 수 있습니다.
- 클라이언트의 VPN/DNS 설정과 구성 파일을 확인하세요. 안드로이드 클라이언트마다 DNS 트래픽 처리를 앱 화면에서 관리하기도 하고 커널의 TUN 설정을 읽기도 합니다. YAML 일부만 보고 설정이 적용됐다고 단정하지 마세요.
- 설정을 변경한 뒤 서비스를 중지했다가 다시 시작하고, 기존 탭을 닫은 다음 테스트하세요. 필요하면 브라우저도 재시작해 기존 연결과 앱 캐시의 영향을 줄이세요.
일반 DNS는 UDP 또는 TCP 53번 포트를 사용하는 경우가 많고, DNS over HTTPS는 보통 443번 포트를 사용합니다. 53번 포트만 가로챈다고 모든 암호화 DNS까지 처리되는 것은 아닙니다. 아래는 해당 필드를 지원하는 mihomo TUN 구성에서 DNS 변조 항목이 어떤 형태인지 보여 주는 예일 뿐이며, 원본 안드로이드 클라이언트에 그대로 붙여 넣을 수 있는 전체 구성은 아닙니다:
tun:
enable: true
dns-hijack:
- any:53
- tcp://any:53
커널 버전, 라우팅 처리 여부, dns.enable 등의 실제 설정도 확인해야 합니다. 안드로이드 클라이언트는 자체 VPN 서비스로 트래픽을 처리할 수 있으므로, 화면의 VPN 스위치와 커널의 tun.enable을 같은 의미로 보면 안 됩니다.
fake-ip가 DNS 조회 실패를 뜻하는 것은 아닙니다
fake-ip 모드에서는 도메인이 기본 주소 풀인 198.18.0.0/16의 매핑 주소로 확인될 수 있습니다. 이는 설계에 따른 동작이므로 주소가 낯설다는 이유만으로 오류라고 판단하면 안 됩니다. 대신 이후 연결도 같은 커널이 계속 처리하는지 확인하세요. fake-ip와 redir-host 사이를 전환한 뒤에는 서비스를 재시작하고 관련 앱도 다시 열어 기존 매핑이나 DNS 캐시가 계속 사용되지 않도록 하세요.
특정 앱에서만 문제가 생긴다면 구성을 백업한 뒤 모드를 비교해 볼 수 있습니다. 하지만 redir-host로 바꾸는 것이 모든 DNS 문제의 해결책은 아닙니다. 도메인 대신 웹사이트 IP 주소만으로 테스트하는 것도 권장하지 않습니다. HTTPS 인증서와 가상 호스트는 올바른 도메인 이름을 요구하는 경우가 많습니다.
6. 앱 접근 제어와 규칙 매칭 확인
브라우저나 특정 앱에서만 연결되지 않는다면 우선 VPN이 해당 앱의 트래픽을 처리하는지 확인하세요. Clash for Android에서는 ‘설정’ → ‘접근 제어’에서 앱 범위를 관리할 수 있습니다. 다른 클라이언트에서는 ‘앱별 프록시’라는 이름을 사용할 수 있습니다. 현재 설정이 ‘선택한 앱만 프록시 사용’인지 ‘선택한 앱 우회’인지 먼저 확인하세요. 두 모드에서는 같은 체크 표시도 의미가 반대입니다.
- 선택한 앱만 프록시 사용: 브라우저가 선택된 앱에 포함되지 않으면 시스템을 통해 직접 연결됩니다.
- 선택한 앱 우회: 체크된 브라우저는 프록시를 사용하지 않습니다. 잘못 선택된 앱이 없는지 확인하세요.
- VPN을 사용하지 않는 연결 차단: 앱 제외 규칙과 함께 적용되면 제외된 앱의 인터넷 연결이 차단될 수 있으므로 시스템 설정과 함께 확인해야 합니다.
그런 다음 ‘로그’ 또는 클라이언트의 연결 목록을 열고 실패한 페이지를 새로 고치세요. 연결과 규칙 매칭 기록이 보인다면 관련 트래픽이 적어도 커널에 들어온 것입니다. 기록이 전혀 없다면 노드 비밀번호부터 바꾸지 말고, 먼저 로그 수준과 앱 범위, VPN 트래픽 처리 여부를 확인하세요.
규칙은 대개 위에서 아래 순서로 적용되며 처음 일치한 규칙이 연결 경로를 결정합니다. 다음 예시는 특정 도메인을 직접 연결하고 나머지 트래픽은 PROXY라는 정책으로 보내는 구조입니다. 실제 구성에 해당 정책 그룹이 있어야 합니다:
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,PROXY
실패한 연결이 REJECT에 매칭되면 위쪽의 차단 규칙을 확인하세요. DIRECT로 잘못 연결된다면 도메인 규칙, 규칙 세트와 마지막 기본 규칙을 살펴보세요. 웹페이지는 이미지, 로그인, API에 서로 다른 도메인을 사용할 수 있습니다. 따라서 ‘홈페이지는 열리지만 로그인 실패’ 문제는 실패한 요청에 해당하는 연결을 확인해야 하며, 홈페이지 도메인에만 규칙을 추가해서는 해결되지 않을 수 있습니다.
7. 화면을 잠근 뒤 연결이 끊기면 배터리 최적화와 백그라운드 실행 확인
처음에는 정상인데 화면을 잠근 지 몇 분 뒤 연결이 끊기고, 잠금을 해제해 클라이언트를 열면 다시 정상이라면 백그라운드 제한을 먼저 의심하세요. 안드로이드 ‘설정’ → ‘앱’ → 해당 클라이언트 → ‘배터리’로 이동해 시스템에서 제공하는 옵션에 따라 백그라운드 실행을 허용하거나 ‘제한 없음’으로 설정하세요. 일부 제조사 기기는 배터리 관리에서 자동 시작도 허용해야 합니다.
- 클라이언트의 백그라운드 데이터 사용이 허용돼 있는지 확인하세요. 데이터 절약 모드를 켰다면 클라이언트의 백그라운드 인터넷 연결이 차단되지 않았는지도 살펴보세요.
- ‘설정’ → ‘알림’에서 알림 권한을 확인하세요. 지속 실행 알림은 서비스 상태를 살펴보는 데 도움이 되지만, 알림이 표시된다고 해서 시스템이 프로세스를 종료하지 않는다는 보장은 없습니다.
- 화면을 켠 상태에서 접속한 뒤 5분간 화면을 잠그고 다시 시도하세요. 서비스 알림, VPN 아이콘과 로그가 끊기는지 기록하세요.
- Wi-Fi에서 모바일 데이터로, 모바일 데이터에서 Wi-Fi로 각각 전환해 테스트하세요. 네트워크를 바꾼 뒤에만 실패한다면 서비스를 다시 연결하고 연결이 재설정되는지 확인하세요.
백그라운드 권한을 바꾼 뒤 문제가 사라진다면 불필요한 예외 설정을 하나씩 되돌리고 실제 실행에 영향을 준 설정만 유지하세요. 프록시 클라이언트를 위해 기기 전체의 배터리 절약 기능을 모두 끌 필요는 없습니다.
8. 반복해서 재설치하지 말고 테스트 결과로 다음 점검 항목을 찾으세요
| 테스트 결과 | 우선 확인할 항목 |
|---|---|
| Clash를 중지해도 인터넷에 연결되지 않음 | 시스템의 VPN 차단 옵션, 네트워크 인증, 신호 상태와 기본 네트워크. |
| 전역 모드는 연결되지만 규칙 모드는 실패 | 매칭된 규칙, 정책 그룹의 최종 선택, 규칙 세트가 정상적으로 불러와졌는지 확인하세요. |
| 노드를 바꾸면 연결이 복구됨 | 기존 노드 상태, 회선 제한, 노드 설정과 서버. |
| 특정 앱 하나에서만 실패 | 앱 접근 제어, 앱 내 보안 DNS, 실패한 요청에 해당하는 도메인. |
| 화면을 잠그거나 네트워크를 전환한 뒤에만 실패 | 백그라운드 실행 권한, 시스템 배터리 최적화, 네트워크 전환 후 재연결. |
원인을 찾지 못했다면 실패 전후 약 30초 동안의 관련 로그를 저장하고 안드로이드 버전, 클라이언트 버전, 커널 이름, 네트워크 유형, 프록시 모드와 테스트 결과를 기록하세요. ‘규칙 모드 실패, 전역 모드 성공, 모바일 데이터에서 재현’처럼 구체적으로 설명하면 ‘연결됨인데 인터넷이 안 됨’이라고만 하는 것보다 원인을 찾기 쉽습니다.
오래된 커널이 설정 기능을 지원하지 않는 것으로 확인됐다면 구성을 백업한 다음 필요한 프로토콜을 지원하는 클라이언트를 선택하세요. 설치, 구성 가져오기와 첫 VPN 권한 허용은 빠른 시작 안내를 참고하세요. 구성 항목과 모드 설명은 전체 문서에서 확인할 수 있습니다. 클라이언트를 바꾸기 전에 지금까지의 테스트 결과를 보관하면 새 환경에서 같은 문제를 다시 확인하는 일을 줄일 수 있습니다.