먼저 Android의 VpnService 트래픽 처리 방식 이해하기

Android용 Clash 계열 클라이언트는 일반적으로 시스템에서 제공하는 VpnService를 통해 로컬 가상 네트워크 인터페이스를 만듭니다. 서비스가 시작되면 Android는 지정된 범위의 네트워크 트래픽을 이 가상 인터페이스로 전달하고, 클라이언트의 코어가 설정 파일의 규칙, 프록시 그룹, 노드에 따라 연결을 처리합니다. 상태 표시줄에 열쇠 또는 VPN 아이콘이 나타난다는 것은 시스템 VPN 터널이 사용 중이라는 뜻이며, 휴대폰이 기존 기업용 VPN 서버에 직접 연결되었다는 의미는 아닙니다.

이 과정은 세 단계로 나누어 이해할 수 있습니다. 첫 번째 단계에서는 Android 시스템이 앱 트래픽을 가상 인터페이스로 전달합니다. 두 번째 단계에서는 Clash 또는 mihomo 코어가 대상 도메인, 주소, 포트 등의 정보를 읽고 규칙과 대조합니다. 세 번째 단계에서 DIRECT, 프록시 노드, 연결 거부 등의 정책 결과에 따라 실제 연결이 만들어집니다. 구독에서 제공하는 노드와 규칙 설정은 세 번째 단계의 동작을 결정하고, VpnService는 첫 번째 단계의 트래픽 진입점을 담당합니다.

Android의 동일한 사용자 공간에서는 일반적으로 하나의 주요 VPN 서비스만 동시에 유지할 수 있습니다. 시스템에 회사 VPN, 다른 프록시 클라이언트, 방화벽 또는 VpnService 기반 필터링 도구가 이미 연결되어 있다면 Clash 클라이언트를 시작할 때 기존 서비스가 중지되거나 새 서비스가 VPN 권한을 얻지 못할 수 있습니다. “시작을 눌렀는데 바로 중지되는” 경우에는 구독을 반복해서 업데이트하기보다 먼저 상태 표시줄과 시스템의 VPN 설정 화면을 확인하세요.

VpnService와 일반 시스템 프록시의 차이

일반 HTTP 시스템 프록시는 앱이 프록시 설정을 직접 따라야 하며, 일부 앱이나 UDP 트래픽, 자체 네트워크 스택을 사용하는 소프트웨어는 이를 우회할 수 있습니다. VpnService는 시스템 네트워크 계층에서 지정 범위의 트래픽을 받아 처리하므로 적용 범위가 대체로 더 넓고, Android 클라이언트가 이 방식을 많이 사용합니다. 일부 클라이언트에서는 이를 VPN 모드, TUN 모드 또는 서비스 모드라고 부릅니다. 명칭은 달라도 핵심은 Android 가상 인터페이스가 생성되었는지, 어떤 앱이 그 범위에 포함되는지입니다.

Android의 VpnService는 데스크톱에서 TUN을 수동으로 활성화하는 것과 완전히 같지는 않습니다. 데스크톱에서는 가상 네트워크 카드 설치, 라우팅 변경 또는 권한 상승이 필요할 수 있지만, Android는 공개 VPN API를 통해 권한을 부여합니다. 처음 시작할 때 시스템 확인 대화상자가 표시되는 것은 정상적인 권한 절차이며, 승인해야 클라이언트가 터널을 만들 수 있습니다.

처음 시작할 때 확인해야 할 핵심 설정

구독을 가져온 직후 모든 문제를 배터리 절약 정책 탓으로 돌려서는 안 됩니다. 먼저 설정이 정상적으로 로드되는지, 노드에 연결되는지, 프록시 그룹이 선택되었는지 확인한 다음 백그라운드 유지 설정을 조정하세요. 안정적인 점검 순서를 따르면 설정 오류와 시스템 제한을 구분할 수 있습니다.

  1. 설정이 활성화되어 있는지 확인합니다. 설정 목록에는 여러 구독이나 로컬 YAML 파일이 함께 저장될 수 있습니다. 업데이트 성공이 새 설정으로 전환되었다는 뜻은 아니므로 활성 표시, 업데이트 시간, 설정 이름을 확인하세요.
  2. 프록시 그룹 선택을 확인합니다. 설정의 프록시 그룹이 사용할 수 없는 노드를 기본으로 선택했거나 자동 지연 시간 측정 중일 수 있습니다. 먼저 지연 시간 측정을 완료했고 연결 가능한 노드를 선택한 뒤 웹페이지를 테스트하세요.
  3. 시스템 VPN 권한을 승인합니다. 처음 시작하면 일반적으로 연결 요청이 표시됩니다. 대화상자를 취소하면 클라이언트 화면은 정상적으로 열리지만 시스템 트래픽을 처리할 수 없습니다.
  4. 실행 모드를 확인합니다. 규칙 모드는 설정의 규칙에 따라 트래픽을 분류하고, 전역 모드는 대부분의 트래픽을 지정한 프록시로 보내며, 직접 연결 모드는 프록시를 우회합니다. 테스트할 때 현재 모드를 기록해 두어야 직접 연결 모드에서 노드가 고장 났다고 잘못 판단하지 않습니다.
  5. 실행 로그를 확인합니다. 설정 구문 분석 실패, DNS 요청 오류, 노드 핸드셰이크 실패, 네트워크 연결 불가에는 대체로 서로 다른 로그가 남습니다. 단순히 웹페이지가 열리는지만 보는 것보다 로그가 문제 지점에 더 가깝습니다.

앱별 트래픽 분류 범위 설정 방법

많은 Android 클라이언트는 “선택한 앱만 프록시” 또는 “선택한 앱 제외” 기능을 지원합니다. 전자는 허용 목록 방식으로, 선택한 앱만 VpnService에 포함됩니다. 후자는 차단 목록 방식으로, 선택한 앱은 직접 연결을 유지합니다. 이름만 보고 두 모드를 추측하지 말고, 변경 전에 현재 화면의 설명을 읽은 뒤 브라우저 하나로 확인하세요.

결제, 은행, 로컬 네트워크 기기 제어, 화면 미러링, 스마트홈 앱을 제외할지는 실제 네트워크 요구 사항에 따라 결정해야 합니다. 앱을 제외하면 해당 연결은 Clash 규칙을 거치지 않으므로 로그에서 관련 요청이 보이지 않는 것이 정상입니다. 브라우저는 접속되지만 특정 앱만 계속 연결되지 않는다면 앱별 프록시 목록을 우선 확인하세요.

화면 잠금 후 연결이 끊기는 일반적인 원인

“화면이 켜져 있을 때는 정상인데, 몇 분간 잠그면 연결되지 않고 잠금 해제 후 클라이언트를 열면 다시 복구되는” 현상은 설정 자체는 작동하지만 백그라운드 서비스가 제한되었거나 프로세스가 회수되었거나 대기 중 네트워크가 전환되었음을 의미하는 경우가 많습니다. Android의 기본 Doze, 제조사 배터리 관리, 백그라운드 실행 제한, 메모리 정리가 모두 원인이 될 수 있습니다.

Doze는 기기가 움직이지 않고 화면이 꺼진 상태에서 조건이 충족되면 백그라운드 활동과 네트워크 접근을 제한합니다. 포그라운드 서비스는 일반 백그라운드 프로세스보다 중지될 가능성이 낮기 때문에 클라이언트가 시작되면 보통 지속 알림을 표시합니다. 알림 권한을 끄거나 알림 채널을 허용하지 않도록 설정하면 일부 시스템에서는 서비스가 계속 실행될 수 있지만, 알림을 정상적으로 표시하지 못하는 포그라운드 서비스를 더 적극적으로 제한하는 시스템도 있습니다. 클라이언트의 실행 상태 알림을 유지하고 시스템 정리 도구로 한 번에 종료하지 않는 것이 좋습니다.

먼저 연결 끊김의 유형을 확인하세요

  • VPN 아이콘이 사라짐: VpnService가 중지되었거나 앱 프로세스가 정리되었거나 다른 VPN 서비스가 시스템 터널을 차지했을 가능성이 큽니다.
  • VPN 아이콘은 남아 있지만 모든 연결이 실패함: 상위 네트워크가 바뀐 뒤 기존 연결이 복구되지 않았거나 노드, DNS, 가상 인터페이스 상태에 문제가 있을 수 있습니다.
  • 일부 앱만 실패함: 앱별 프록시 범위, 규칙 적용 결과, IPv6, DNS, 대상 앱 자체의 백그라운드 제한을 우선 확인하세요.
  • Wi-Fi에서 모바일 데이터로 전환한 뒤 실패함: 네트워크 전환 후 클라이언트가 연결을 다시 만들 수 있는지, 모바일 데이터 사용 권한이 있는지 확인하세요.
  • 클라이언트를 열면 즉시 복구됨: 대개 백그라운드 제한을 가리킵니다. 화면이 다시 활성화되면 시스템이 실행 기회를 제공하고 서비스 또는 코어가 복구됩니다.

점검할 때는 반복 가능한 테스트를 진행하세요. 동일한 설정과 노드를 유지하고 계속 새로 고칠 수 있는 페이지를 연 다음 화면을 잠그고 10분간 기다립니다. 이후 잠금을 해제해 VPN 아이콘, 클라이언트 실행 상태, 로그의 시간 흐름을 확인하세요. Wi-Fi와 모바일 데이터에서도 각각 반복합니다. 한 번에 하나의 설정만 바꿔야 어떤 배터리 절약 정책이 영향을 주었는지 판단할 수 있습니다.

화면 잠금 중 로그가 완전히 멈췄다가 잠금 해제 후 다시 나타난다면 프로세스 유지와 배터리 제한을 중점적으로 확인하세요. 로그에 요청 기록이 계속 남지만 시간 초과가 많이 발생한다면 노드 사용 가능 여부, 네트워크 전환, DNS 문제를 확인해야 합니다. 시스템이 서비스를 중지한 경우 일부 클라이언트는 로그 끝에 서비스 삭제 또는 코어 종료 정보를 남깁니다. 다만 프로세스가 직접 종료되면 원인이 완전히 기록되기 전에 로그가 끊길 수 있습니다.

배터리 최적화 예외 및 백그라운드 실행 설정

제조사마다 사용하는 메뉴 이름은 다르지만 목표는 같습니다. 클라이언트가 백그라운드에서 계속 실행되도록 허용하고, 해당 앱의 배터리 최적화를 해제하며, 필요한 백그라운드 네트워크 활동을 허용하는 것입니다. 설정 메뉴는 “앱 정보”, “배터리”, “앱 자동 실행 관리” 또는 “특별한 앱 권한”에 있을 수 있습니다.

다음 순서로 조정하는 것이 좋습니다

  1. 배터리 사용을 제한 없음으로 설정합니다. 클라이언트의 앱 정보에서 배터리 설정을 찾아 “제한 없음”, “백그라운드 활동 허용” 또는 비슷한 의미의 항목을 선택하세요. Android 기본 시스템에서는 앱 정보의 배터리 사용량 관리가 일반적인 경로입니다.
  2. 자동 관리를 끕니다. 일부 시스템에는 자동 실행, 연결된 앱 자동 실행, 백그라운드 활동을 제어하는 세 가지 스위치가 있습니다. 자동 관리를 끈 뒤 화면 안내에 따라 클라이언트의 자동 실행과 백그라운드 실행을 허용하세요.
  3. 포그라운드 서비스 알림을 유지합니다. 클라이언트가 실행 알림을 표시하도록 허용하세요. 알림은 상태 표시뿐 아니라 Android 포그라운드 서비스 작동 방식과도 관련이 있습니다.
  4. 백그라운드 데이터를 허용합니다. 모바일 데이터와 Wi-Fi 권한을 확인하고 백그라운드 데이터가 차단되지 않았는지 확인하세요. 시스템 데이터 절약 모드를 사용 중이라면 클라이언트를 “제한 없는 데이터 사용” 목록에 추가할 수 있습니다.
  5. 최근 작업에서 앱을 잠급니다. 일부 제조사 시스템은 작업 카드 잠금 기능을 제공해 한 번에 정리할 때 앱이 종료될 가능성을 낮춥니다. 배터리 최적화 예외를 대신할 수는 없지만 보완책으로 사용할 수 있습니다.
  6. 클라이언트 서비스를 재시작합니다. 권한을 변경한 뒤 VpnService를 중지했다가 다시 시작하세요. 필요한 경우 휴대폰을 재부팅한 다음 화면 잠금과 네트워크 전환을 다시 확인합니다.

클라이언트를 배터리 최적화에서 제외하면 코어가 가상 인터페이스, DNS 처리, 필요한 연결 상태를 유지해야 하므로 백그라운드 배터리 사용량이 다소 늘어날 수 있습니다. 실제 배터리 소모량은 트래픽, 규칙 규모, 로그 수준, 노드 프로토콜, 앱의 지속적인 네트워크 요청 여부에 따라서도 달라집니다. 먼저 연결 안정성을 확보한 뒤 불필요하게 비용이 큰 설정을 하나씩 줄이고, 모든 백그라운드 권한을 한꺼번에 끄지는 마세요.

부팅 후 자동으로 복구되는지 확인

클라이언트의 부팅 후 자동 실행 여부는 앱이 해당 기능을 구현했는지, 시스템이 자동 실행을 허용하는지, VPN 권한과 시스템 정책이 계속 유효한지에 따라 달라집니다. 일부 Android 버전은 시스템 VPN 설정에서 앱을 지정하는 “항상 켜진 VPN” 옵션을 제공합니다. 다만 이 옵션을 사용해도 되는지는 클라이언트 기능 안내를 기준으로 판단하세요.

“VPN을 사용하지 않는 연결 차단”은 더 엄격한 시스템 옵션입니다. 활성화하면 지정한 VPN 서비스가 아직 연결되지 않은 동안 기기가 인터넷에 연결되지 않을 수 있습니다. 설정을 디버깅하거나 클라이언트 또는 구독 노드를 바꾸는 중 노드를 사용할 수 없으면 문제가 더 뚜렷하게 나타납니다. 트래픽을 계속 VPN으로 강제해야 할 때만 고려하고, 먼저 클라이언트가 안정적으로 자동 실행되어 서비스를 복구하는지 확인하세요.

DNS, 비공개 DNS 및 네트워크 전환 문제

백그라운드 실행이 정상이라고 해서 DNS 조회 경로까지 정상이라는 뜻은 아닙니다. Android의 “비공개 DNS”는 시스템 수준의 암호화 DNS 설정을 사용하며, Clash 설정에서도 내장 DNS, Fake-IP 또는 규칙 기반 DNS 처리를 활성화할 수 있습니다. 클라이언트와 설정에 따라 두 기능이 서로 다른 경로를 만들 수 있습니다. “IP로는 연결되지만 도메인이 열리지 않음”, “일부 앱이 계속 로딩만 함”과 같은 문제가 발생하면 DNS를 별도 점검 항목으로 분리하세요.

테스트할 때는 Android 비공개 DNS를 일시적으로 자동으로 바꾼 뒤 클라이언트 서비스를 재시작해 보세요. 문제가 사라진다면 기존에 지정한 비공개 DNS 호스트, 현재 네트워크 또는 설정의 DNS 경로에 호환성 문제가 있을 수 있습니다. 무작정 설정을 바꾸며 장기간 해결하기보다 DNS가 설정에서 명확히 활성화되어 있는지, 수신 방식이 Android 클라이언트에 적합한지, 규칙에서 특정 도메인 조회를 요구하는지 확인해야 합니다.

Fake-IP 모드는 도메인에 예약 주소 범위의 매핑 주소를 반환한 뒤 코어가 도메인을 복원하고 규칙과 대조합니다. 도메인 정보를 유지하고 규칙 적용의 일관성을 높이는 데 유리하지만, 일부 로컬 네트워크 서비스, 특수 앱 또는 실제 주소를 기준으로 판단하는 환경에서는 필터 항목을 추가해야 할 수 있습니다. Redir-Host 등 다른 모드는 DNS 처리 과정이 다르므로 필터 설정을 그대로 적용해서는 안 됩니다.

Wi-Fi와 모바일 데이터 전환 후 복구

휴대폰이 Wi-Fi를 벗어나면 하위 네트워크, 외부 IP 주소, DNS 환경이 모두 바뀝니다. 클라이언트는 기본 네트워크 변경을 감지하고 이후 연결이 새 네트워크를 사용하도록 해야 합니다. 전환 후 VPN 아이콘은 남아 있지만 접속되지 않는다면 몇 초간 기다린 뒤 클라이언트에서 서비스를 중지하고 다시 시작해 보세요. 전환할 때마다 수동 재시작이 필요하다면 클라이언트 버전, 백그라운드 네트워크 권한, 시스템의 VPN 제한을 확인하세요.

듀얼 SIM, 데이터 절약, 핫스팟 공유 또는 로컬 네트워크 접근을 동시에 사용하면 문제가 더 복잡해집니다. 핫스팟 기기의 트래픽이 휴대폰의 VpnService를 통과하는지는 Android 버전, 제조사 구현, 클라이언트 기능에 따라 달라집니다. 휴대폰 자체가 프록시를 사용한다고 해서 핫스팟 트래픽까지 처리된다고 단정할 수 없습니다. 휴대폰과 핫스팟에 연결된 단말에서 외부 IP와 DNS를 각각 테스트해야 합니다.

로그 분석과 전체 점검 순서

Android Clash 클라이언트의 로그에는 일반적으로 규칙 적용 결과, 연결 대상, 선택된 정책, DNS 처리, 오류 정보가 포함됩니다. 문제를 점검할 때는 로그 수준을 일시적으로 정보 또는 디버그로 높일 수 있지만, 상세 로그를 장기간 활성화하면 기록 및 처리 비용이 늘어납니다. 기록이 끝나면 평소 수준으로 되돌리세요.

자주 확인하는 로그 단서

  • timeout 또는 연결 시간 초과: 대상에 연결할 수 없거나 노드 응답이 느리거나 네트워크 전환이 복구되지 않았거나 DNS 요청이 완료되지 않았을 수 있습니다.
  • connection refused: 대상 포트가 연결을 명확히 거부했거나 로컬 리스너 또는 상위 서비스가 시작되지 않았을 수 있습니다.
  • 설정 구문 분석 오류: YAML 들여쓰기, 필드 형식, 구독 변환 결과 또는 현재 코어에서 지원하지 않는 설정 항목을 확인해야 합니다.
  • DIRECT가 계속 적용됨: 현재 규칙이 트래픽을 직접 연결로 판단한 것입니다. 규칙 순서, 실행 모드, 대상 도메인을 확인하세요.
  • 대상 앱의 로그가 전혀 없음: 해당 앱이 VpnService 범위에서 제외되었거나 트래픽이 현재 클라이언트로 들어오지 않는 것일 수 있습니다.

시스템이 프로세스를 중지했는지 추가로 확인하려면 Android 개발자 도구로 기기 로그를 볼 수 있지만, 이는 고급 방법입니다. 컴퓨터를 연결하고 디버깅을 승인한 뒤 앱 패키지명, VPN 서비스, 프로세스 상태를 기준으로 정보를 필터링하세요. 클라이언트마다 패키지명이 다르므로 앱 정보나 설치 패키지 정보에서 확인해야 하며, 다른 소프트웨어의 패키지명을 그대로 사용해서는 안 됩니다.

adb shell dumpsys vpn
adb shell dumpsys deviceidle
adb shell dumpsys activity services

dumpsys vpn은 현재 VPN 상태를 확인하는 데 도움이 되며, dumpsys deviceidle은 기기 유휴 상태와 Doze 상황을 확인하는 데 사용합니다. 서비스 목록으로 대상 프로세스와 서비스가 여전히 존재하는지도 확인할 수 있습니다. 명령 출력은 Android 버전에 따라 달라지므로 현상을 검증하는 용도로 사용하고, 특정 한 줄의 출력이 모든 기기에 적용된다고 단정하지 마세요.

권장 점검 절차

  1. 화면이 켜진 상태에서 검증된 노드 하나를 고정해 사용하고, 규칙 모드에서 정상적으로 접속되는지 확인합니다.
  2. 시스템 VPN 아이콘이 표시되는지 확인하고, 다른 VPN, 방화벽 또는 프록시 도구가 터널을 사용하고 있지 않은지 점검합니다.
  3. 대상 앱이 앱별 프록시 범위에 포함되어 있는지 확인합니다.
  4. 화면을 끄고 예약 테스트를 진행하면서 VPN 아이콘, 로그가 끊긴 시간, 복구 방식을 기록합니다.
  5. 클라이언트를 배터리 최적화 예외 목록에 추가하고 백그라운드 활동, 백그라운드 데이터, 실행 알림을 허용합니다.
  6. Wi-Fi, 모바일 데이터, 두 네트워크 간 전환을 각각 테스트합니다.
  7. 도메인 요청만 실패한다면 비공개 DNS, 설정의 DNS 모드, Fake-IP 호환 항목을 확인합니다.
  8. 문제가 계속되면 필요한 설정을 백업하고 유지 관리되는 클라이언트 버전으로 업데이트한 뒤 동일한 구독으로 다시 테스트합니다.

클라이언트를 업데이트한 뒤 설정을 불러올 수 없다면 기존 설정의 모든 필드를 새 코어에 그대로 복사해서는 안 됩니다. Clash Meta（mihomo）는 기존 Clash 설정과의 호환성을 바탕으로 규칙 및 프로토콜 기능을 확장했지만, 클라이언트마다 포함된 코어 버전, 지원 필드, 기본 동작이 다를 수 있습니다. 먼저 클라이언트 오류 로그에서 문제가 되는 필드를 찾은 다음 해당 코어의 문서를 참고해 수정하세요.

안정적으로 실행된 후 배터리 사용량 최적화

연결이 안정되면 로그, 속도 측정 빈도, 불필요한 백그라운드 요청부터 점검해 배터리 사용량을 줄일 수 있습니다. 모든 노드의 지연 시간을 자주 측정하면 동시에 많은 연결이 생성됩니다. 구독 자동 업데이트 주기가 지나치게 짧아도 기기 깨우기 횟수가 늘어납니다. 자동 측정 그룹의 검사 간격은 실제 사용 방식에 맞추고, 매분 최신 결과를 얻기 위해 모든 노드를 계속 확인할 필요는 없습니다.

규칙 수 자체가 유일한 배터리 소모 원인인 경우는 드뭅니다. 지속적으로 활성 상태인 앱, 연결 재시도, DNS 반복 실패, 상세 로그를 더 주의 깊게 확인하세요. 사용할 수 없는 노드가 정책 그룹에서 계속 선택되면 백그라운드 앱이 반복해서 재연결하므로 사용성이 떨어지고 배터리도 더 소모됩니다. 로그에 동일한 오류가 밀집해 나타나면 먼저 노드를 바꾸거나 규칙을 수정하세요.

배터리 최적화 예외의 목적은 필요할 때 VpnService가 안정적으로 실행되도록 하는 것이지, 클라이언트를 항상 높은 활동 상태로 유지하는 것이 아닙니다. 적절히 설정하면 트래픽이 없을 때 코어의 작업을 줄이고, 연결이 발생할 때 규칙 적용과 전달을 수행할 수 있습니다. 짧은 시간의 순간 배터리 비율보다 시스템 배터리 통계로 하루 전체 사용량을 확인하는 편이 더 유용합니다.

최종적으로 간결한 기준 설정을 유지하세요. 안정적인 설정 하나, 명확한 규칙 모드, 필요한 앱별 프록시 범위, 백그라운드 실행 허용, 정상적인 포그라운드 알림 표시, 비공개 DNS와 클라이언트 DNS 조합 기록이 기준이 될 수 있습니다. 이후 화면 잠금 후 연결이 끊기면 먼저 이 기준 설정으로 다시 테스트한 다음 시스템 업데이트, 클라이언트 버전, 구독 설정 중 무엇이 바뀌었는지 판단하세요.

Android Clash 클라이언트 설정 계속하기

Android에 적합한 클라이언트를 선택한 뒤 사용 가이드에 따라 구독을 가져오고 프록시 모드와 시스템 VPN 권한을 확인하세요.

다운로드 페이지로 이동 사용법 보기