Clash Android 사용 가이드: VpnService 및 배터리 최적화 예외 설정

Android 휴대폰에서 Clash 클라이언트를 사용할 때 연결에 실패하거나 한동안 실행된 뒤 자동으로 멈추는 원인은 구독 내용만이 아닐 수 있습니다. Android의 네트워크 권한 모델, VpnService 승인, 배터리 최적화 정책, 제조사별 백그라운드 관리, 클라이언트의 실행 모드가 프록시의 지속적인 작동 여부에 영향을 줍니다. 클라이언트를 설치한 뒤에는 먼저 프록시 모드와 시스템 권한을 확인하고 배터리 절전 설정을 조정하는 순서가 노드를 반복해서 바꾸는 것보다 효과적입니다.

이 글에서는 Clash Meta(mihomo) 코어를 지원하는 Android 클라이언트를 기준으로 시스템 프록시, VpnService, TUN 모드의 관계를 설명하고 최초 승인부터 백그라운드 유지까지 점검 절차를 안내합니다. 휴대폰 브랜드에 따라 메뉴 이름은 조금 다를 수 있지만 판단 기준은 대체로 같습니다. 클라이언트에 VPN 권한이 있는지, 시스템이 백그라운드 실행을 허용하는지, 대상 앱의 트래픽이 프록시를 통과하는지, 구성의 DNS와 규칙이 정상적으로 해석되는지를 확인하면 됩니다.

1. Android에서 프록시 연결에 필요한 요소

Android 앱은 일반적으로 Clash의 로컬 포트를 직접 읽지 않습니다. Clash 클라이언트는 기기에서 프록시 코어를 실행한 다음 시스템 프록시 설정이나 Android의 VpnService를 통해 앱 트래픽을 처리합니다. 두 방식은 적용 범위가 다르므로 단순히 “스위치를 켜면 완전히 같다”고 볼 수 없습니다. 어떤 방식을 사용할지는 클라이언트 구현, 앱의 시스템 프록시 준수 여부, HTTP 프록시를 지원하지 않는 프로그램까지 처리해야 하는지에 따라 달라집니다.

시스템 프록시와 VpnService의 차이

시스템 프록시는 보통 앱에 HTTP 또는 SOCKS 프록시 주소를 제공합니다. Android 시스템 프록시 설정을 따르는 브라우저, 일부 네트워크 도구와 앱은 요청을 Clash의 로컬 수신 포트로 보내고, 규칙 그룹이 직접 연결, 프록시 또는 차단 여부를 결정합니다. 시스템 프록시는 경로가 비교적 단순해 모든 앱의 네트워크 인터페이스를 가로채지는 않지만, 일부 앱은 시스템 프록시를 무시하거나 특정 요청에 자체 네트워크 스택만 사용합니다.

VpnService는 Android가 제공하는 가상 네트워크 인터페이스 서비스입니다. 클라이언트가 권한을 승인받으면 로컬 VPN 인터페이스를 만들고 해당 인터페이스를 통과하는 트래픽을 읽어 mihomo 코어로 전달할 수 있습니다. 여기서 VPN은 Android의 로컬 트래픽 처리 방식이며, 클라이언트가 원격 VPN 서버를 자동으로 제공한다는 뜻은 아닙니다. 실제 외부 연결 경로는 구성에 지정된 프록시 노드, 정책 그룹 및 규칙에 따라 결정됩니다. 처음 활성화하면 시스템에 VPN 연결 승인 창이 표시되며, 사용자가 명시적으로 허용해야 클라이언트가 터널을 만들 수 있습니다.

시스템 프록시를 따르지 않는 앱이 있거나 더 많은 TCP 및 UDP 트래픽을 규칙으로 처리해야 한다면 VpnService가 보통 더 적합합니다. 대신 시스템에 VPN 상태가 표시되고 이 권한은 다른 VPN 앱과 동시에 사용할 수 없는 경우가 많습니다. 한 번에 하나의 앱만 시스템 VPN 인터페이스를 사용할 수 있으므로 다른 VPN, 일부 방화벽 또는 네트워크 가속 도구를 켜면 Clash가 시작되지 않거나 실행 중인 연결이 시스템에 의해 전환될 수 있습니다.

Clash Meta와 로컬 네트워크 경로

Clash Meta(mihomo)는 YAML 구성 파일을 읽고 프록시 연결을 만들며 규칙을 매칭하고 DNS, HTTP, SOCKS, 투명 프록시 등의 기능을 제공합니다. Android 클라이언트는 코어를 앱에 포함하고 시스템 권한을 요청하며 그래픽 인터페이스를 제공합니다. “클라이언트는 열려 있지만 특정 앱에 접속할 수 없음” 문제가 발생하면 이 두 계층을 나누어 확인해야 합니다. 전자는 코어, 구성, 노드 상태를 확인하고 후자는 VpnService, 백그라운드 실행, 앱 트래픽 제외 여부를 확인합니다.

시스템 프록시만 사용하는 경우 일반적인 로컬 수신 주소는 127.0.0.1이며 HTTP 또는 SOCKS 포트와 함께 사용됩니다. TUN을 활성화하면 앱 트래픽이 먼저 가상 네트워크 카드로 들어간 다음 코어가 라우팅과 규칙에 따라 처리합니다. 원격 구독 주소, 노드 서버 주소, 로컬 수신 포트를 혼동하지 마세요. 구독은 구성이나 노드 정보를 제공하고, 로컬 포트는 휴대폰의 앱이 접근하는 용도로 사용되므로 역할이 다릅니다.

2. 최초 설치 및 VpnService 승인 순서

설치가 끝나면 정해진 순서대로 작업하는 것이 좋습니다. 여러 변수를 동시에 바꾸면 문제의 원인을 판단하기 어려워지기 때문입니다. 먼저 구성을 준비한 뒤 연결을 시작하고, 개별 노드가 작동하는지 확인한 다음 규칙과 앱을 테스트하세요. 구독을 가져온 직후 고급 매개변수를 대량으로 수정하지 말고 되돌릴 수 있는 기본 구성을 보관하면 DNS, 라우팅 또는 규칙 그룹으로 인한 문제를 찾는 데 도움이 됩니다.

클라이언트 출처와 코어 지원 여부를 확인합니다. 클라이언트의 정보 페이지나 코어 정보 페이지를 열어 현재 버전이 mihomo 또는 해당 Clash Meta 기능을 지원하는지 확인하고 Android 버전 요구 사항도 살펴보세요. 클라이언트마다 TUN, 스크립트, DNS 기능이 완전히 같지는 않습니다.
구독을 가져온 뒤 한 번 업데이트합니다. 구독 주소에 접속할 수 있는지 확인하고 업데이트가 끝나면 프록시 노드 목록과 정책 그룹을 살펴보세요. 업데이트에 실패했다면 먼저 네트워크, 시스템 시간, 구독 주소의 완전성을 확인하세요. 업데이트 실패를 VpnService 문제로 잘못 판단하지 않아야 합니다.
명확한 프록시 모드를 선택합니다. 최초 테스트에는 규칙 모드를 사용하고 프록시 정책 그룹에서 노드를 직접 선택하는 것이 좋습니다. 전체 프록시 모드는 기본 연결 상태를 확인하는 데 적합하지만 장기적으로는 규칙에 따른 분할 라우팅을 사용해야 합니다. 직접 연결 모드에서는 대부분의 요청에 프록시 노드가 사용되지 않습니다.
시스템 VPN 승인을 시작합니다. 클라이언트의 연결 스위치를 누르면 Android에 VPN 연결 요청이 표시됩니다. 앱 이름을 확인한 뒤 허용을 선택하세요. 시스템에서 이미 VPN이 사용 중이라고 표시되면 다른 VPN, 트래픽 방화벽 또는 유사 네트워크 도구의 연결을 먼저 끊고 승인을 다시 요청하세요.
로컬 상태를 확인합니다. 클라이언트에 실행 중 상태가 표시되는지, VPN 아이콘이 나타나는지, 코어 로그가 계속 출력되는지 확인하세요. 그다음 직접 연결되어야 하는 사이트와 프록시를 사용해야 하는 사이트를 각각 테스트해 하나의 대상만으로 전체 구성을 판단하지 않도록 합니다.

Android의 VPN 승인은 시스템 수준의 작업이므로 클라이언트가 확인 절차를 우회할 수 없습니다. 일부 시스템은 최초 승인 후 “항상 허용”과 비슷한 옵션을 제공하지만, 재부팅이나 사용자 전환 또는 보안 정책 변경 후 다시 확인을 요구할 수도 있습니다. 승인 창이 나타나지 않으면 클라이언트를 먼저 중지하고 다른 VPN을 끈 다음 시스템 설정의 VPN 페이지에서 기존 연결 기록을 삭제하거나 해당 앱을 다시 선택해 보세요.

TUN 모드는 언제 켜야 하나요

TUN 모드는 가상 네트워크 카드를 통해 트래픽을 수신하므로 시스템 프록시를 따르지 않는 앱을 처리하거나 TCP 및 UDP 요청을 mihomo 규칙 흐름으로 통합해야 할 때 적합합니다. 노드 속도를 높이는 스위치가 아니며 잘못된 구독, DNS 오류 또는 사용할 수 없는 노드를 자동으로 수정하지도 않습니다. TUN을 켜면 시스템 라우팅, DNS 가로채기, 앱 제외 목록이 더 중요해지고, 구성이 잘못되면 모든 앱의 네트워크가 끊긴 것처럼 보일 수 있습니다.

먼저 시스템 프록시나 클라이언트 기본 모드에서 기본 연결을 테스트한 뒤 TUN을 켜는 것이 좋습니다. 활성화하기 전에 기존 DNS, 모드, 노드 선택을 기록하고, 활성화한 뒤에는 설정 하나만 바꿔 다시 테스트하세요. TUN을 켠 후 인터넷에 연결할 수 없다면 바로 구독을 삭제하지 말고 TUN 권한, 자동 라우팅, DNS 모드, IPv6 처리, 다른 VPN과의 충돌을 우선 확인하세요.

3. 배터리 제한으로 백그라운드 연결이 끊기는 이유

Android는 앱 사용 빈도, 화면 상태, 충전 상태 및 제조사 정책에 따라 백그라운드 프로세스를 제한합니다. Clash 클라이언트가 백그라운드에서 실행되려면 코어 프로세스, VPN 서비스, 노드 연결, DNS 요청을 유지해야 합니다. 시스템이 서비스를 일시 중지하거나 프로세스를 회수하면 상태 표시줄의 VPN 아이콘이 사라지거나, 앱으로 돌아오기 전에 중지되거나, 화면을 잠근 뒤 접속할 수 없거나, 연결은 켜진 것으로 보이지만 실제 요청이 시간 초과되는 현상이 나타날 수 있습니다.

“배터리 최적화 예외”는 모든 휴대폰에서 동일한 이름으로 제공되지 않습니다. 일반적인 경로로는 “배터리”, “앱 배터리 관리”, “백그라운드 활동”, “자동 시작 관리”, “배터리 최적화”, “백그라운드 팝업”, “화면 잠금 시 정리” 등이 있습니다. 설정 대상은 브라우저나 프록시 대상 앱이 아니라 클라이언트 자체입니다. 클라이언트를 “제한 없음” 또는 “백그라운드 활동 허용”으로 설정하면 시스템이 VpnService를 일시 중지하거나 코어 프로세스를 회수할 가능성을 낮출 수 있습니다.

일반적인 설정 경로

시스템 설정을 열고 앱 목록으로 이동한 다음 사용 중인 Clash Android 클라이언트를 찾습니다.
배터리 또는 전력 관리 페이지에서 백그라운드 사용 정책을 “제한 없음”, “무제한” 또는 같은 의미의 옵션으로 변경합니다.
모바일 네트워크 및 WLAN 페이지에서 백그라운드 데이터 사용을 허용했는지 확인합니다. 시스템에 데이터 절약 모드 예외가 있다면 클라이언트도 허용 목록에 추가하세요.
시스템에 자동 시작 관리 기능이 있다면 클라이언트의 부팅 시 시작 또는 백그라운드 서비스 시작을 허용합니다. 부팅 후 자동 연결이 실제로 필요할 때만 켜서 백그라운드 앱 범위를 불필요하게 넓히지 않도록 하세요.
최근 앱 화면에서 클라이언트를 잠급니다. 일부 제조사의 “모두 정리” 기능은 배터리 정책을 완화했더라도 잠기지 않은 백그라운드 앱을 종료합니다.
화면을 잠근 뒤 5~10분 후 다시 테스트합니다. 앱이 전면에 열려 있을 때만 테스트하면 백그라운드 제한을 확인할 수 없습니다.

일부 제조사는 같은 제한을 여러 페이지에 나누어 배치합니다. 예를 들어 배터리 페이지에서는 백그라운드 실행을 허용해도 “절전 대기 최적화”가 밤에 네트워크를 정지시킬 수 있습니다. 또는 클라이언트 자체는 제한되지 않았지만 시스템의 백그라운드 팝업 권한이 꺼져 연결 상태를 다시 표시하지 못할 수도 있습니다. 설정을 마친 뒤에는 클라이언트를 한 번 재시작하고 실제 동작을 확인하세요. 문제가 화면 잠금, 앱 전환 또는 모바일 네트워크 전환 때만 발생한다면 배터리 절전과 네트워크 전환 정책의 연관성이 높습니다.

배터리 최적화 예외 설정의 장단점

백그라운드 실행을 허용하면 클라이언트 프로세스와 네트워크 연결을 유지할 가능성이 커지지만 대기 중 배터리 소모가 늘어날 수 있습니다. 장기 사용 시에는 먼저 “제한 없음”으로 설정해 안정성을 확인한 뒤 원인을 파악하면 제한을 하나씩 되돌리는 방법이 좋습니다. 주로 집에서 사용하고 화면을 잠근 뒤 프록시가 필요하지 않다면 클라이언트의 자동 시작을 끌 수 있습니다. 즉시 알림, 동기화 또는 원격 접속이 필요하다면 VPN 서비스의 백그라운드 실행 권한을 유지해야 합니다.

4. 구독, 규칙, DNS를 함께 점검하기

권한과 백그라운드 설정이 정상이어도 “일부 앱은 되지만 일부 앱은 안 되는” 문제가 발생할 수 있습니다. 이런 경우에는 구성 계층을 다시 확인해야 합니다. 구독 업데이트는 구성 내용을 클라이언트로 내려받는 작업일 뿐, 모든 노드와 정책 그룹 및 규칙이 현재 네트워크에 적합하다는 보장은 없습니다. 먼저 구독 업데이트 시간을 확인한 뒤 현재 모드, 정책 그룹 선택, 규칙 매칭 결과를 살펴보세요.

증상으로 문제 범위 구분하기

모든 앱에 접속할 수 없음: VPN이 실제로 연결되었는지, 현재 노드를 사용할 수 있는지, TUN에 시스템 권한이 있는지, 다른 VPN이 실행 중인지, 기본 정책 그룹이 유효한 노드를 선택했는지 확인하세요.
브라우저는 되지만 특정 앱은 안 됨: 해당 앱이 클라이언트에서 제외되었는지, 자체 DNS·QUIC 또는 특수 네트워크 인터페이스를 사용하는지 확인하세요. TUN 모드는 처리 범위를 넓힐 수 있지만 클라이언트의 앱 우회 설정은 여전히 적용됩니다.
도메인은 열리지 않지만 직접 IP는 가끔 연결됨: DNS 모드, 상위 DNS 연결 가능 여부, Fake-IP 설정, DNS 요청에 대한 규칙 처리를 중점적으로 확인하세요. 프록시 노드만 바꾸는 것으로 해결하려 하지 마세요.
화면을 잠그면 끊기고 전면으로 돌아오면 복구됨: 배터리 최적화, 자동 시작, 백그라운드 데이터, 최근 앱 잠금을 우선 다시 확인하고 규칙은 먼저 수정하지 마세요.
특정 지역 또는 서비스만 이상함: 규칙이 매칭된 정책과 노드의 출구 지역을 확인하세요. 정책 그룹이 직접 연결을 선택했거나 규칙이 대상 도메인을 적합하지 않은 정책으로 보냈을 수 있습니다.

규칙 모드는 위에서 아래 순서로 규칙을 매칭하고, 일치한 요청을 해당 정책으로 전달합니다. 마지막의 MATCH는 보통 기본 처리 역할을 맡습니다. 서로 다른 출처의 구독을 가져오면 규칙 세트 이름, 정책 그룹 이름, DNS 동작이 달라질 수 있습니다. 규칙이나 정책 그룹을 수정한 뒤에는 저장하고 구성을 다시 로드한 다음 요청을 재시도해야 합니다. 클라이언트의 연결 로그에서 도메인, 매칭된 규칙, 최종 정책을 확인하면 브라우저의 오류 페이지만 보는 것보다 실제 경로에 가까운 정보를 얻을 수 있습니다.

Fake-IP와 Android 앱 호환성

Fake-IP 모드는 도메인에 가상 주소를 할당하고 이후 연결에서 매핑에 따라 도메인을 복원한 뒤 규칙으로 처리합니다. 일부 DNS 해석 대기 시간을 줄일 수 있지만 모든 로컬 네트워크 검색, 금융 앱, 게임 또는 실제 로컬 네트워크 주소가 필요한 프로그램에 적합한 것은 아닙니다. 특정 유형의 앱만 이상하다면 관련 도메인을 Fake-IP 필터에 추가하거나 클라이언트가 제공하는 호환 모드를 사용해 보세요. 구체적인 필드는 현재 코어가 지원하는 구성 문서를 기준으로 확인해야 합니다.

DNS 구성은 TUN 및 규칙 설계와 일치해야 합니다. TUN을 켠 뒤 DNS 요청이 코어를 우회하면 규칙 판단과 실제 해석 경로가 달라질 수 있습니다. 상위 DNS에 현재 네트워크에서 연결할 수 없으면 모든 도메인이 시간 초과되는 현상으로 나타납니다. 점검할 때는 클라이언트가 권장하는 기본 DNS 구성으로 임시 변경해 연결을 확인한 뒤 사용자 지정 상위 DNS를 복원하세요. 매번 매개변수 하나만 바꾸고 변경 전후 결과를 기록해야 합니다.

5. 연결이 끊긴 뒤 표준 문제 해결 절차

문제 해결을 “시스템 계층, 클라이언트 계층, 구성 계층, 대상 앱 계층”의 네 단계로 나누는 것이 좋습니다. 이렇게 하면 백그라운드 프로세스 회수, 노드 장애, 규칙 오설정을 한데 섞지 않을 수 있습니다. 다음 절차는 화면을 잠근 뒤 연결이 끊기거나 Wi-Fi와 모바일 네트워크를 전환한 뒤 작동하지 않거나 Android에는 VPN 연결로 표시되지만 앱이 인터넷에 연결되지 않는 경우에 적합합니다.

시스템 계층을 확인합니다. 상태 표시줄의 VPN 아이콘을 확인하고 시스템 VPN 페이지에서 현재 앱이 계속 연결되어 있는지 확인하세요. 다른 VPN, 프록시, 비공개 DNS 또는 트래픽 방화벽이 활성화되어 있는지도 점검합니다.
클라이언트 계층을 확인합니다. 클라이언트를 열어 실행 상태, 코어 로그, 활성 연결을 확인하세요. 프로세스가 이미 중지되었다면 다시 시작하고 배터리 제한을 확인합니다. 프로세스가 계속 실행 중이라면 구성을 이어서 점검하세요.
구성 계층을 확인합니다. 구독이 만료되지 않았는지, 노드를 사용할 수 있는지, 정책 그룹이 사용 가능한 노드를 가리키는지, 현재 모드가 규칙 또는 전체 프록시인지 확인하고 요청에 해당하는 규칙 매칭 결과도 살펴보세요.
DNS와 라우팅을 확인합니다. TUN 모드에서는 자동 라우팅과 DNS 설정을 점검하고, 시스템 프록시 모드에서는 대상 앱이 시스템 프록시를 따르는지 확인하세요. 필요하면 IPv6 또는 Fake-IP 관련 옵션을 잠시 끄고 비교 테스트를 진행합니다.
대상 앱을 확인합니다. 대상 앱의 네트워크 상태를 초기화한 뒤 다시 시도하고 앱 자체 프록시, 인증서 검증, 지역 제한 또는 로그인 세션 문제를 확인하세요. 특정 앱 하나만 실패했다면 Clash 전체의 장애로 바로 판단해서는 안 됩니다.

클라이언트를 재시작하면 즉시 복구되지만 다시 화면을 잠갔을 때 끊긴다면 백그라운드 정책을 중점적으로 확인하세요. Wi-Fi를 바꾼 뒤 작동하지 않는다면 네트워크 전환 시 VPN이 다시 연결되는지, 새 네트워크가 구독이나 노드 포트를 차단하는지 살펴보세요. VPN 아이콘은 계속 표시되지만 모든 도메인을 해석할 수 없다면 DNS를 중점적으로 확인하고, 도메인은 해석되지만 연결이 시간 초과되면 노드, 규칙 정책, 전송 프로토콜을 확인하세요. 증상으로 계층을 좁히면 목적 없이 구독을 반복해서 가져오는 일을 줄일 수 있습니다.

점검 순서:
1. VPN 승인 및 다른 VPN과의 충돌
2. 클라이언트 백그라운드 실행 및 배터리 최적화
3. 코어 상태, 구독 업데이트 시간, 노드 사용 가능 여부
4. 모드, 정책 그룹, 규칙 매칭, DNS
5. 대상 앱의 독립적인 네트워크 동작

6. 장기간 사용에 적합한 Android 구성 습관

장기간 실행할 때는 작동이 확인된 기본 구성을 하나 보관하고, 수정하기 전에 현재 구성을 내보내거나 복사하는 것이 좋습니다. 구독 업데이트, 코어 업그레이드, 시스템 업데이트, 제조사의 보안 정책 변경은 모두 네트워크 동작을 바꿀 수 있습니다. 업데이트 후에는 자주 사용하는 브라우저, 메신저, 로그인이 필요한 앱을 먼저 테스트한 다음 TUN, Fake-IP, IPv6, 사용자 지정 규칙과 같은 고급 기능을 단계적으로 활성화하세요.

노드를 선택할 때는 먼저 지연 시간이 안정적이고 연속 테스트에 성공하는 노드를 고른 뒤 실제 접속을 확인하세요. 지연 시간 테스트는 테스트 대상과 노드 사이의 일부 경로만 보여 주므로 모든 서비스가 작동한다는 것을 단독으로 증명하지 못합니다. 구독 업데이트 후 사용할 수 없거나 적합하지 않은 노드가 자동 선택되지 않도록 정책 그룹에 명확한 기본 노드를 하나 지정해 두는 것이 좋습니다. 규칙 분할 라우팅도 읽기 쉽게 유지해야 문제가 생겼을 때 도메인에 적용된 정책을 빠르게 찾을 수 있습니다.

Android 시스템을 업그레이드한 뒤에는 네 가지 설정을 다시 확인해야 합니다. VPN 승인이 여전히 유효한지, 클라이언트의 백그라운드 활동이 허용되어 있는지, 배터리 최적화가 다시 활성화되지 않았는지, 최근 앱 잠금이 유지되는지 확인하세요. 업무 프로필, 앱 복제 또는 다중 사용자 기능을 사용한다면 실제로 클라이언트를 실행하는 사용자 공간에 별도의 VPN 권한이 있는지도 확인해야 합니다. 일부 시스템은 업무 프로필과 개인 프로필의 네트워크 서비스를 별도로 관리하므로 한쪽만 확인해서는 안 됩니다.

설정을 마친 뒤에는 전체 검증을 한 번 진행할 수 있습니다. 클라이언트를 전면에서 시작해 VPN 아이콘이 나타나는지 확인하고, 규칙 모드에서 직접 연결 대상과 프록시 대상에 접속해 보세요. 몇 분간 화면을 잠근 뒤 다시 테스트하고 Wi-Fi와 모바일 네트워크도 한 번 전환합니다. 마지막으로 로그에 연결 오류가 계속 기록되는지 확인하세요. 이 과정은 Android에서 Clash를 사용할 때 흔한 권한, 백그라운드, 구성 문제를 폭넓게 확인하고 시스템 제한과 노드 자체 장애를 구분하는 데 도움이 됩니다.