Clash 전체 플랫폼
설치 및 설정 가이드

공통 준비 사항: 아키텍처, 구독, 트래픽 연결 방식

기기를 확인한 뒤 클라이언트를 선택하세요

설치 전에 운영체제 이름과 아키텍처, 관리자 권한 보유 여부를 확인하세요. 아키텍처에 따라 설치 파일의 실행 가능 여부가 달라지고, 권한에 따라 서비스 설치나 가상 네트워크 어댑터 생성이 제한될 수 있습니다. 운영체제가 64비트라고 해서 반드시 x64인 것은 아닙니다. ARM 프로세서가 탑재된 컴퓨터도 64비트 운영체제를 실행할 수 있습니다. Windows에서는 ‘시스템 정보’, macOS에서는 ‘이 Mac에 관하여’를 확인하고, Linux에서는 아래 명령어를 사용하세요. 휴대기기는 다운로드 페이지에 안내된 기기 호환 패키지를 우선 선택하고, 구형 기기는 프로세서 지원 범위도 확인하세요.

GUI를 사용할 수 있는 기기에서는 그래픽 클라이언트를 우선 고려하세요. 지원 플랫폼에서는 Clash Plus를 먼저 추천합니다. 클라이언트는 설정 관리와 프록시 전환, 시스템 연동을 담당하고, 코어는 설정을 해석하고 규칙을 실행하며 연결을 만듭니다. 둘은 서로 다른 구성 요소입니다. 클라이언트를 바꿔도 시스템 권한, 백그라운드 서비스, 로컬 덮어쓰기 설정이 자동으로 이전되지는 않습니다. 같은 구독을 다른 클라이언트에서 사용해도 코어 기능이나 설정 병합 방식에 따라 결과가 달라질 수 있습니다. 클라이언트 선택은 클라이언트 비교를, 코어와의 관계는 mihomo와 GUI 클라이언트 관계 정리를 참고하세요.

uname -m
# x86_64는 일반적으로 x64 / AMD64에 해당
# aarch64 또는 arm64는 일반적으로 ARM64에 해당

가져올 구독 링크 또는 설정 파일 준비

클라이언트는 프록시 도구이며, 사용할 수 있는 회선을 자동으로 만들어 주지는 않습니다. 시작하기 전에 사용 권한이 있는 구독 URL이나 로컬 YAML 파일을 준비하고, 서비스 이용 기간이 유효한지 확인하세요. 일반적인 전체 설정에는 노드, 프록시 그룹, 규칙이 포함됩니다. 노드 목록만 있는 경우 실행 가능한 설정을 만들기 위해 템플릿이 필요할 수 있습니다. 형식 오류가 표시되더라도 모든 노드가 작동하지 않는다는 뜻은 아닙니다. 먼저 링크에서 실제로 설정 파일, 노드 문자열, 로그인 페이지 또는 오류 메시지 중 무엇이 반환되는지 확인하세요. 자세한 차이는 구독 형식 및 변환 안내를 참고하세요.

구독 URL에는 개인 인증 정보가 포함되는 경우가 많으므로 비밀번호처럼 관리하세요. 공개 스크린샷이나 온라인 변환 사이트, 공개 저장소에 올리지 마세요. 설정을 공유할 때는 노드 비밀번호, 컨트롤 인터페이스 키, 로컬 경로도 확인해야 합니다. 원격 구독을 업데이트하면 직접 수정한 내용이 덮어써질 수 있으므로, 개인 설정은 클라이언트에서 지원하는 덮어쓰기 또는 병합 기능을 이용하는 것이 좋습니다. 수정 전에는 정상 작동하는 설정을 내보내고 현재 선택된 프록시 그룹도 기록해 두세요. 문제가 생겼을 때 복구하기 쉽고, 여러 입력란에서 같은 항목을 반복해서 수정하는 일도 줄일 수 있습니다.

시스템 프록시와 TUN 구분하기

시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 프록시 연결을 제공합니다. 브라우저는 대체로 사용할 수 있지만, 명령줄 도구나 게임, 일부 앱은 시스템 설정을 무시할 수 있습니다. TUN은 가상 네트워크 인터페이스를 통해 지정된 경로의 트래픽을 처리하며, 추가 권한과 라우팅 및 DNS 설정이 필요합니다. 그렇다고 모든 문제를 해결하는 기능은 아닙니다. 먼저 시스템 프록시로 구독과 회선이 작동하는지 확인한 뒤, 필요한 앱에 따라 TUN을 활성화하세요. 모바일 기기는 대개 시스템 VPN 인터페이스를 통해 연결합니다. 화면에 표시되는 명칭은 다를 수 있지만 시스템 권한이 승인되었는지 확인해야 합니다.

아래는 설정 항목을 설명하는 예시일 뿐 노드는 포함하지 않으므로, 완전한 구독 설정으로 단독 사용할 수 없습니다. 루프백 주소는 이 기기에서만 접속할 수 있습니다. LAN에 공개하려면 방화벽과 인증 설정도 함께 계획하세요. 특히 외부 제어 인터페이스를 공용 네트워크에 직접 노출해서는 안 됩니다. 원격 관리에는 접근을 제한하는 별도의 방법을 사용하세요.

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

마지막으로 시스템 시간이 정확한지, 기기가 로컬 네트워크에 정상적으로 접속할 수 있는지 확인하고 프록시나 라우팅을 변경하는 다른 소프트웨어는 잠시 중지하세요. 기존 프록시 설정과 DNS 출처를 기록해 두세요. 특히 사무실 기기의 자동 설정 URL은 꼭 보관해야 합니다. 나중에 클라이언트를 종료해도 인터넷이 되지 않을 때 원래 상태로 복구하는 데 도움이 됩니다. 조직에서 관리하는 기기라면 관리자의 네트워크 정책을 먼저 따르세요.

Windows: 서비스 설치와 시스템 프록시

다운로드, 설치, 첫 실행

Windows 다운로드 섹션에서 Clash Plus를 우선 선택하세요. 필요에 따라 Clash Verge Rev, FlClash 또는 Clash Nyanpasu도 고려할 수 있습니다. Clash for Windows는 더 이상 유지 관리되지 않습니다. 호환성을 확인한 구형 환경에서 참고할 수는 있지만, 새 기기의 기본 선택으로는 권장하지 않습니다. ‘설정 → 시스템 → 정보’에서 시스템 종류를 확인하고 다운로드 페이지 안내에 따라 아키텍처에 맞는 파일을 선택하세요. 해당 기기용 기본 패키지가 없더라도 파일 이름이 비슷하다는 이유만으로 설치하지 말고, 운영체제와 클라이언트가 해당 실행 방식을 지원하는지 먼저 확인하세요.

설치 중 운영체제 안내를 확인하고 일반적인 앱 설치 위치를 사용하세요. 처음 실행할 때 백그라운드 서비스나 네트워크 구성 요소를 설치해야 할 수 있습니다. 권한을 요청한 앱이 설치하려는 클라이언트와 일치하는지 확인하세요. 서비스 설정을 대신하기 위해 앱 전체를 항상 관리자 권한으로 실행하지 마세요. GUI가 열리는 것과 코어 서비스에 필요한 권한이 있는 것은 별개의 문제입니다. 보안 경고로 실행이 차단되면 파일 출처와 운영체제 호환성, 서명 정보를 확인하세요. 설치를 완료하려고 시스템 보호 기능 전체를 끄지 마세요. 회사 컴퓨터에서 서비스를 설치할 수 없다면 허용된 일반 프록시 기능을 먼저 사용하세요.

구독을 가져와 연결 확인하기

‘설정’ 또는 ‘구독’에서 URL 가져오기를 선택하고 주소를 붙여넣은 뒤 다운로드하세요. 설정 이름이 표시되는 것만으로는 완료가 아닙니다. 해당 설정을 활성화하고 ‘프록시’ 화면에서 그룹이 나타나는지 확인하세요. 목록이 비어 있다면 먼저 가져오기 알림에서 다운로드 상태와 파싱 오류를 확인하고 TUN은 나중에 켜세요. 구독이 여러 개라면 출처와 용도를 알 수 있도록 이름을 구분하세요. 현재 선택된 항목이 방금 가져온 설정인지 확인해야 다른 파일을 수정하고 실제로는 별도의 설정을 실행하는 일을 막을 수 있습니다.

처음 확인할 때는 규칙 모드를 선택하고, 프록시가 필요한 그룹에서 회선 하나를 직접 선택한 다음 시스템 프록시를 켜세요. Windows의 ‘설정 → 네트워크 및 인터넷 → 프록시’에서 수동 프록시 주소와 포트가 클라이언트의 수신 설정과 일치하는지 확인하세요. 흔히 로컬 주소는 127.0.0.1, 포트는 7890이지만 반드시 현재 클라이언트에 표시된 값을 사용해야 합니다. 브라우저에 별도의 프록시 확장 프로그램이 설치되어 있다면 먼저 비활성화하거나 시스템 설정을 덮어쓰지 않는지 확인하세요. 그렇지 않으면 시스템 프록시가 작동하는지 정확히 테스트할 수 없습니다.

PowerShell에서 프록시를 명시적으로 지정하면 브라우저 자체 설정과 별도로 비교 테스트할 수 있습니다. 아래 명령은 로컬 HTTP 프록시 연결만 테스트합니다. 대상 사이트의 HTTP 응답을 받으면 요청과 응답이 한 차례 오간 것이며, 상태 코드가 성공 페이지를 의미하지는 않습니다. 이 명령 하나만으로 모든 앱이나 UDP가 정상이라고 판단하지 마세요.

curl.exe --proxy http://127.0.0.1:7890 -I https://example.com

TUN 권한, 네트워크 어댑터, 라우팅

시스템 프록시가 작동하는데 대상 앱이 프록시 설정을 따르지 않는다면 클라이언트의 TUN을 활성화하세요. 처음 켤 때는 서비스 구성 요소와 관리자 권한이 필요한 경우가 많습니다. 화면의 안내에 따라 설치한 뒤 서비스가 실제로 실행 중인지 확인하세요. TUN을 켠 후에는 스위치 표시만 보지 말고 연결 화면에 대상 앱의 요청이 나타나는지도 확인해야 합니다. 가상 네트워크 어댑터가 있다는 사실만으로 라우팅이 올바르다고 볼 수 없고, 코어가 실행 중이어도 DNS가 연결되었다는 뜻은 아닙니다. 각 단계를 따로 확인하세요.

TUN을 켠 뒤 LAN 기기나 프린터, 사무실 리소스에 연결할 수 없다면 먼저 TUN을 끄고 비교하세요. 끄자마자 복구된다면 클라이언트의 LAN 우회, 라우팅 제외 설정, 조직 VPN의 주소 범위를 확인하세요. 일부 클라이언트는 사설 네트워크 라우트를 자동 관리하지만 네트워크 환경에 따라 기존 게이트웨이와 충돌할 수 있습니다. 고정된 제외 규칙을 무작정 복사해 넣지 마세요. 원격 접속에 필요한 사설 주소까지 모두 직접 연결로 처리하는 것도 피해야 합니다. 제외 범위는 실제 네트워크 용도에 맞게 정하세요.

포트 충돌과 종료 후 네트워크 복구

‘주소가 이미 사용 중’이라는 오류가 표시되면 다른 클라이언트나 남아 있는 코어 프로세스, 개발용 프록시가 포트를 점유하는지 확인하세요. 아래 명령으로 수신 대기 상태를 확인한 뒤 작업 관리자에서 프로세스 ID를 조회해 어떤 프로그램인지 파악하세요. 프로세스 ID만 보고 시스템 프로세스를 종료하지 마세요. 포트를 변경한다면 브라우저 확장 프로그램, 터미널 환경 변수, 다른 기기의 설정도 함께 바꿔야 합니다. 클라이언트의 포트만 변경해도 외부 설정이 자동으로 갱신되지는 않습니다.

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

시작 프로그램 설정도 항목별로 확인해야 합니다. GUI 실행, 코어 서비스 실행, 설정 자동 활성화, 시스템 프록시 자동 복원은 각각 다른 옵션입니다. 설정을 마친 뒤 한 번 재부팅하여 로그인 후에도 구성이 활성화되고 포트가 수신 대기 중인지 확인하세요. 절전 모드에서 복귀한 다음에만 문제가 생긴다면 구독을 반복해서 다운로드하기 전에 네트워크 전환과 서비스 상태부터 확인하세요. 백그라운드 복구 문제가 구독 갱신으로 가려질 수 있습니다.

macOS: 칩 아키텍처, 네트워크 서비스, 권한

Apple Silicon과 Intel 설치 파일 구분

Apple 메뉴의 ‘이 Mac에 관하여’에서 칩 또는 프로세서를 확인하세요. Apple Silicon은 일반적으로 ARM64, Intel은 x64에 해당합니다. macOS 다운로드 섹션에서 Clash Plus를 우선 선택하고, 인터페이스 취향에 따라 Clash Verge Rev 또는 FlClash도 고려할 수 있습니다. ClashX Meta는 더 이상 유지 관리되지 않으므로 보관된 클라이언트를 사용하기 전에 운영체제 호환성을 확인하세요. 가능하면 기기 아키텍처에 맞는 설치 파일을 선택하세요. 호환 모드로 실행할 수 있더라도 백그라운드 서비스와 네트워크 구성 요소, 업데이트 절차가 현재 기기에 적합하다는 뜻은 아닙니다.

설치 파일이 디스크 이미지 형식이면 열어서 앱을 ‘응용 프로그램’ 폴더로 드래그한 뒤 그 위치에서 실행하세요. 이미지 파일을 마운트한 상태로 계속 실행하면 경로와 로그인 시 실행 항목, 업데이트에 문제가 생길 수 있습니다. 앱을 열 수 없다는 시스템 경고가 표시되면 출처와 시스템 요구 사항, 전체 오류 내용을 먼저 확인한 뒤 시스템에서 제공하는 방법으로 처리하세요. 온라인에서 찾은 보안 속성 제거 명령을 무작정 실행하지 말고 앱 폴더 전체의 권한을 광범위하게 변경하지도 마세요.

설정 가져오기와 현재 네트워크 서비스 확인

클라이언트 설정 화면에서 URL이나 로컬 파일을 가져와 다운로드한 다음 활성화하세요. 프록시 화면에서 그룹과 규칙이 있는지 확인하고 회선 하나를 직접 선택하세요. 이어서 시스템 프록시를 켜고 ‘시스템 설정 → 네트워크’로 이동해 현재 사용 중인 Wi-Fi 또는 유선 연결의 세부 정보에서 프록시 설정을 확인하세요. macOS 프록시 설정은 대개 네트워크 서비스별로 저장됩니다. Wi-Fi에서 설정해도 유선 인터페이스로 전환하면 같은 설정이 적용된다고 보장할 수 없습니다.

기기가 유선과 무선 네트워크에 동시에 연결되어 있다면 현재 기본 출구와 네트워크 서비스 순서를 먼저 확인하세요. 문제를 테스트할 때는 경로를 하나로 명확히 두는 편이 원인을 찾기 쉽습니다. 브라우저에서는 연결되지만 터미널에서는 연결되지 않는다면 시스템 DNS를 바로 변경하지 말고 프록시를 명시한 명령으로 테스트하세요. 터미널 도구가 시스템 프록시를 읽는지는 도구 구현에 따라 다르며, 자체 옵션이나 환경 변수가 필요한 경우도 있습니다. 이것만으로 시스템 프록시가 작동하지 않는다고 단정할 수는 없습니다.

scutil --proxy
curl --proxy http://127.0.0.1:7890 -I https://example.com

scutil --proxy는 현재 프록시 설정을 확인하는 명령입니다. 활성화 여부와 주소, 포트를 중점적으로 살펴보세요. 명령 출력만으로 원격 회선의 가용성이 입증되지는 않습니다. 브라우저의 자동 프록시 설정이나 확장 프로그램, 업무 프로필이 실제 연결 경로를 바꿀 수도 있습니다. 일반 브라우저 창과 프록시를 명시한 요청을 함께 테스트하면 브라우저 설정과 클라이언트 연결 지점을 구분할 수 있어 같은 화면에서 스위치만 반복해서 조작하는 일을 줄일 수 있습니다.

보조 서비스, TUN, 다른 VPN

TUN을 사용하려면 클라이언트가 보조 서비스나 네트워크 구성 요소를 설치해야 할 수 있습니다. 권한 요청 창이 표시되면 앱 이름을 확인하고 클라이언트 안내에 따라 완료한 뒤 활성화 여부를 확인하세요. 현재 기능에 필요한 권한만 허용하세요. ‘전체 디스크 접근 권한’을 일반적인 해결 방법처럼 사용해서는 안 됩니다. 시스템 업그레이드 후 권한이나 백그라운드 항목을 다시 확인해야 할 수 있으니, 재설치하기 전에 ‘로그인 항목 및 확장 프로그램’ 같은 시스템 설정을 확인하세요.

TUN을 켜기 전에 다른 VPN이나 유사 프록시 클라이언트를 종료하세요. 메뉴 막대에서는 꺼진 것처럼 보여도 네트워크 확장 기능이 남아 있는 앱에 특히 주의해야 합니다. 두 도구가 기본 라우트나 DNS를 동시에 변경하면 요청이 우회되거나 순환하고 일부 도메인만 실패할 수 있습니다. 조직 VPN과 함께 사용해야 한다면 관리 요구 사항을 따르고 해당 라우팅 범위에 맞춰 트래픽을 분리하세요. 개인 클라이언트의 전역 모드만으로 조직 네트워크의 주소 충돌을 자동 해결할 수는 없습니다.

아래는 mihomo TUN 설정 예시로 필드 설명에만 사용합니다. 모든 macOS 클라이언트에 그대로 붙여 넣어야 하는 정답은 아닙니다. GUI 클라이언트가 시스템 환경에 맞춰 설정을 다시 생성할 수 있으므로 해당 앱의 설정 화면을 우선 사용하세요. 자동 라우팅과 인터페이스 감지는 트래픽을 코어로 보내는 경로를 설정할 뿐, 원격에 연결하려면 작동하는 설정과 올바른 정책도 필요합니다.

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

절전 모드, 네트워크 전환, 제거 후 복구

덮개를 닫았다가 열었을 때 클라이언트는 연결된 것으로 표시되지만 웹페이지가 열리지 않는다면 먼저 Wi-Fi에 IP 주소가 할당되었는지와 추가 로그인 절차가 필요한지 확인한 뒤 코어가 복구되었는지 살펴보세요. 핫스팟을 전환한 뒤 문제가 발생하면 연결 기능을 끄고 일반 네트워크 연결을 확인한 다음 다시 켜서 기본 네트워크와 프록시 문제를 구분하세요. 복구에 실패하자마자 모든 설정을 삭제하지 마세요. 한 번의 절전 모드로 구독 자체가 변경되는 경우는 드뭅니다.

로그인 시 자동 실행을 설정한 뒤에는 백그라운드 실행이 로그인 항목에서 허용되는지 확인하고 재부팅 후 설정이 자동으로 활성화되는지 점검하세요. 터미널에서 임시로 설정한 프록시 환경 변수는 대개 현재 세션에만 적용됩니다. 셸 설정 파일에 기록했다면 GUI 클라이언트를 종료해도 변수가 남을 수 있습니다. 문제를 해결할 때 터미널 환경 변수와 시스템 프록시를 모두 확인해 한쪽만 복구하는 일이 없도록 하세요.

Android: VPN 권한과 백그라운드 실행

설치 파일 선택과 최초 권한 승인

Android 다운로드 섹션에서는 Clash Plus를 우선 추천합니다. 기능에 따라 Clash Meta for Android, FlClash 또는 Surfboard를 선택할 수도 있습니다. 설치 전에 운영체제 요구 사항과 아키텍처를 확인하세요. 최신 기기는 대개 ARM64를 사용하고 구형 기기는 ARM 또는 범용 패키지가 필요할 수 있습니다. 다운로드한 파일은 시스템 설치 프로그램으로 여세요. 파일 관리자나 브라우저에 앱 설치 권한을 허용해야 하는 경우에만 해당 앱에 권한을 부여하세요. 설치 후에는 이 출처 권한을 회수할 수 있으며, 모든 앱에 설치 권한을 계속 허용할 필요는 없습니다.

앱을 실행한 뒤 먼저 구독을 가져오고 연결을 시작하세요. Android는 VpnService를 통해 시스템 VPN 권한을 요청합니다. 승인해야 클라이언트가 로컬 가상 네트워크 인터페이스를 만들 수 있습니다. 상태 표시줄에 VPN 아이콘이 나타나는 것은 시스템 터널이 만들어졌다는 뜻일 뿐, 구독 노드나 규칙이 올바르다는 증거는 아닙니다. 권한 요청 창이 반복해서 나타나거나 확인 버튼을 누를 수 없다면 화면 오버레이와 접근성 안내, 기기 관리 제한을 확인하고 시스템 안내에 따라 해결하세요. 권한을 우회하려고 서로 다른 패키지를 여러 개 설치하지 마세요.

구독 가져오기, 프록시 그룹 선택, 앱 연결

설정 화면에서 원격 설정을 새로 만들고 구독 링크를 입력해 다운로드한 다음 현재 설정으로 전환하세요. 붙여넣을 때 앞뒤 공백과 줄바꿈에 주의하세요. 일부 메신저 앱은 링크를 여러 줄로 나눌 수 있습니다. 가져오기에 실패하면 전체 오류 메시지를 확인해 네트워크 요청 실패, 인증 만료, 형식 비호환을 구분하세요. 전체 YAML과 노드 문자열은 처리 방법이 다를 수 있습니다. 브라우저에서 열리는 주소라고 해서 모두 바로 가져올 수 있는 구독 URL은 아닙니다.

설정을 활성화한 뒤 프록시 화면에서 규칙 모드와 프록시 그룹 출구를 선택하고 VPN을 시작하세요. 모바일 VPN을 통한 트래픽 연결은 데스크톱 시스템 프록시와 같은 기능이 아니며, 보통 Wi-Fi 설정에 로컬 프록시를 따로 입력할 필요도 없습니다. 이전에 Wi-Fi 프록시를 수동 설정했다면 테스트 전에 기록하고 계속 필요한지 확인하세요. 시스템 요청이 이미 종료된 예전 포트로 다시 전달되는 일을 막을 수 있습니다. 먼저 클라이언트의 기본 연결 방식을 사용해 정상 작동을 확인한 뒤 고급 네트워크 스택 설정을 조정하세요.

앱별 프록시에는 ‘선택한 앱만 프록시 사용’과 ‘선택한 앱 우회’처럼 서로 반대되는 방식이 있습니다. 선택하기 전에 화면 설명을 확인하세요. 목록을 수정한 뒤 VPN을 다시 연결해야 적용되는 클라이언트도 있습니다. 시스템 다운로드 구성 요소와 브라우저, 앱 내 웹페이지, 기본 앱이 서로 다른 프로세스나 패키지에 속할 수 있습니다. 기본 앱만 선택해도 로그인이나 다운로드 과정 전체에 적용된다고 보장할 수 없습니다. 페이지는 열리는데 첨부 파일을 받지 못한다면 노드를 바꾸기 전에 실제 요청을 보낸 구성 요소가 무엇인지 확인하세요.

배터리 최적화와 화면 잠금 후 연결 끊김

앱을 사용할 때는 연결되지만 화면을 잠근 뒤 끊긴다면 백그라운드 제한부터 확인하세요. 앱 정보에서 필요한 백그라운드 실행을 허용하고 시스템 옵션에 따라 배터리 최적화를 조정하세요. 클라이언트의 포그라운드 서비스 알림도 유지해야 합니다. 일부 제조사 시스템은 자동 시작과 연동 실행, 작업 정리를 별도로 제어하며 설정 메뉴 이름도 다를 수 있습니다. 한 항목만 설정한 뒤 백그라운드 실행이 완전히 허용되었다고 판단하지 마세요. 세부 경로와 차이는 Android 권한 및 배터리 최적화 예외 안내를 참고하세요.

백그라운드 실행을 허용한다고 해서 휴대전화 전체의 배터리 절약 기능을 꺼야 하는 것은 아닙니다. 먼저 클라이언트에 필요한 최소한의 설정만 조정하고 화면을 잠근 상태에서 알림과 웹페이지 복구, 연결 상태를 테스트하세요. 배터리 소모가 계속 크다면 로그가 상세 수준으로 계속 기록되는지, 구독 업데이트가 지나치게 잦은지, 특정 앱이 실패한 요청을 반복하는지 확인하세요. 점검 순서는 모바일 배터리 소모와 백그라운드 실행 분석을 참고하세요. 한 번의 배터리 소모 비율만으로 클라이언트를 평가하기는 어렵습니다. 신호 상태와 화면 사용 시간, 작업량에 따라 결과가 달라집니다.

상시 VPN, 핫스팟, 네트워크 전환

Android의 상시 VPN과 ‘VPN을 사용하지 않는 연결 차단’은 시스템 수준의 정책입니다. 후자를 켜면 클라이언트가 중지되거나 실행에 실패할 때 기기 전체의 인터넷이 차단되어 Wi-Fi 문제처럼 보일 수 있습니다. 설정 전에 이런 제한이 필요한지 확인하고 해제 방법도 기억해 두세요. 일반적인 환경에서는 같은 사용자 공간에서 VPN 인터페이스를 사용하는 도구 두 개를 동시에 사용할 수 없습니다. 다른 방화벽이나 트래픽 필터 앱이 VPN 인터페이스를 점유할 수도 있습니다.

Wi-Fi에서 모바일 네트워크로 전환한 뒤 연결에 실패한다면 모바일 데이터 권한과 시스템 시간, 통신사 네트워크가 정상인지 확인한 뒤 VPN을 다시 연결하세요. 공용 Wi-Fi에 웹 로그인 절차가 필요하면 시스템 제한을 준수하면서 연결 기능을 잠시 끄고 인증을 완료한 다음 다시 켜세요. 설정이 성공했다고 표시되는데 모든 앱의 연결 기록이 비어 있다면 먼저 권한과 앱별 목록을 확인하세요. 연결 기록은 있지만 모두 시간 초과라면 회선과 DNS, 기본 네트워크를 점검하세요.

Surfboard와 mihomo 기반 클라이언트는 설정 형식과 기능 메뉴가 완전히 같지 않습니다. 특정 YAML 파일을 모든 클라이언트에 억지로 적용하지 마세요. 앱을 바꿀 때는 먼저 구독이 어떤 형식을 제공하는지 확인한 다음 트래픽 연결 권한과 앱별 목록을 다시 설정하세요. 동기화할 수 있는 설정과 시스템 권한은 별도로 관리해야 합니다. 시스템 권한은 기기마다 다시 승인해야 합니다.

iOS: App Store 설치와 터널 설정

Clash Plus 설치와 설정 출처 확인

iPhone과 iPad에서는 Clash Plus를 우선 추천합니다. App Store의 Clash Plus 페이지에서 설치할 수 있으며, 제품 정보는 공식 웹사이트 clashplus.io에서 확인하세요. iOS 다운로드 섹션에서도 통합 다운로드 페이지로 이동할 수 있습니다. 설치 전 App Store에 표시된 운영체제 호환 요구 사항을 확인하세요. 설치 후에는 사용할 구독 URL이나 설정 파일을 준비해야 합니다. 앱 설치가 완료되었다고 회선까지 준비된 것은 아닙니다.

처음 실행하면 설정 목록과 프록시 그룹, 연결 스위치, 로그 메뉴를 확인하세요. 배포 버전에 따라 화면 문구가 달라질 수 있으므로 이 장에서는 버튼 이름보다 기능을 기준으로 안내합니다. 다른 앱에서 파일을 공유해 가져온다면 확장자와 파일 내용을 확인하세요. 웹페이지 저장 파일이나 구독 안내 페이지를 가져오지 않도록 주의해야 합니다. 설정의 계정 정보는 개인 인증 정보이므로 스크린샷을 찍을 때 전체 구독 URL과 노드 인증 항목을 가리세요.

구독 가져오기와 VPN 설정 추가

설정 관리에서 링크로 추가를 선택하고 구독을 붙여넣어 다운로드한 뒤 활성화하세요. 설정 이름이 표시되면 프록시 그룹이 나타나는지, 선택할 수 있는 출구가 있는지 확인하세요. 반환된 구독 형식이 호환되지 않으면 서비스에서 제공하는 호환 형식을 사용하거나 신뢰할 수 있는 환경에서 설정을 변환해야 합니다. 파일 확장자를 YAML로 바꾸는 것만으로 형식이 변환되지는 않습니다. 정기적으로 업데이트해야 하는 원격 설정은 원래 출처를 보존하세요. 정적 사본을 한 번 가져온 뒤 노드가 자동으로 동기화된다고 오해하지 않도록 주의하세요.

처음 연결을 시작할 때 시스템에서 VPN 설정 추가를 요청하고 기기 암호나 생체 인증을 요구할 수 있습니다. 권한을 승인한 뒤 클라이언트로 돌아와 터널을 시작하고 시스템 VPN 화면에서 연결 상태를 확인하세요. 시스템이 설정 추가를 허용하지 않으면 스크린 타임이나 기기 관리, 조직 정책의 제한 여부를 먼저 확인하세요. 관리 기기라면 관리자가 승인한 방법을 사용하세요. 개인 프록시를 사용하려고 기기 관리 프로파일을 삭제해서는 안 됩니다.

iOS 네트워크 연결은 시스템 네트워크 확장 기능이 담당합니다. 모든 앱에 같은 데스크톱 HTTP 프록시 주소를 입력하는 방식이 아닙니다. 클라이언트에 TUN이나 네트워크 스택 또는 비슷한 옵션이 있더라도 실제 구현을 확인하고 사용하세요. Windows의 서비스 설치나 가상 네트워크 어댑터 설정을 그대로 적용하지 마세요. 처음 테스트할 때는 기본 네트워크 설정을 유지하고 규칙 모드와 프록시 그룹 출구를 명확히 선택한 다음 재현 가능한 HTTPS 페이지를 브라우저에서 여세요.

규칙, DNS, 앱 내 연결

브라우저는 작동하지만 특정 앱이 실패한다면 먼저 연결 기록에 해당 앱의 요청이 있는지 확인하세요. 기록이 없다면 특수 네트워크 경로를 쓰는지, 다른 VPN이 실행 중인지, 앱 자체 제한이 있는지 살펴보세요. 기록이 있다면 적용된 규칙과 프록시 그룹, 오류 유형을 확인하세요. 일부 앱은 UDP나 별도 DNS, 자체 주소 캐시를 사용할 수 있으므로 웹페이지가 열린다고 앱도 정상이라고 볼 수 없습니다. 규칙을 수정한 뒤 대상 앱을 종료하고 다시 실행하세요. 필요하면 터널을 다시 만들어 새 요청에 변경된 설정이 적용되도록 하세요.

DNS 설정은 도메인의 해석 방법을 결정하고 프록시 그룹은 연결 경로를 정하므로 서로 맞아야 합니다. DNS 서버만 바꾼다고 모든 데이터 트래픽이 프록시로 전환되지는 않습니다. 반대로 프록시 출구를 선택해도 연결할 수 없는 DNS 서버가 복구되지는 않습니다. 특정 도메인만 실패하면 도메인과 DNS 결과, 적용 규칙을 기록한 뒤 최소한의 설정만 변경해 테스트하세요. fake-ip의 작동 방식과 한계는 DNS 테스트 및 fake-ip 설정 안내를 참고하세요. 테스트 페이지의 결과 하나만으로 결론을 내리지 마세요.

네트워크 전환, 자동 연결, 설정 이전

가정용 Wi-Fi에서 모바일 네트워크로 전환하면 기존 연결이 잠시 끊길 수 있고, 새 연결도 네트워크 주소 변경의 영향을 받을 수 있습니다. 먼저 시스템 네트워크가 안정될 때까지 기다린 뒤 터널이 복구되는지 확인하세요. 계속 실패하면 연결을 중지했다가 다시 시작하고 클라이언트와 대상 앱의 모바일 데이터 사용이 허용되어 있는지 확인하세요. 공용 Wi-Fi에 인증 페이지가 있다면 네트워크 로그인을 먼저 완료한 뒤 프록시를 테스트하세요. 네트워크 인증이 끝나지 않은 상태에서 노드와 규칙을 바꾸면 문제만 더 복잡해질 수 있습니다.

필요 시 연결이나 자동 복구 기능을 켜면 수동으로 연결을 끊어도 시스템 규칙에 따라 다시 연결될 수 있습니다. 잠시 중지하려면 주 스위치를 반복해서 누르지 말고 클라이언트의 자동 연결 설정과 시스템 VPN 상태를 모두 확인하세요. 자동 동작은 실제 네트워크 사용 환경에 맞게 설정해야 합니다. 낯선 네트워크에 연결하거나 사내 리소스를 이용할 때, 또는 로컬 기기 문제를 점검할 때는 항상 연결 상태로 표시되는 것보다 터널이 언제 시작되는지 명확히 아는 것이 중요합니다.

기기를 바꿀 때 구독과 필요한 규칙은 이전할 수 있지만 시스템 권한과 자동 연결 동작, 로컬 네트워크 권한은 다시 확인해야 합니다. 클라우드 동기화 전에 어떤 항목이 동기화되는지 알아보세요. 로그와 키, 모든 로컬 설정이 함께 이전된다고 가정하지 마세요. 이전 기기를 더 이상 사용하지 않는다면 필요 없는 구독 사본을 삭제하세요. 링크가 유출되었다고 의심되면 클라이언트에서 기록만 지우지 말고 구독 제공업체에서 인증 정보를 갱신하세요.

잠금 화면에서만 문제가 발생한다면 잠금을 해제한 뒤 새 요청을 보내는 경우와 잠금 중 푸시 알림을 받는 경우를 따로 테스트하세요. 두 요청은 서로 다른 시스템 메커니즘을 거칠 수 있습니다. 네트워크 종류와 신호 전환 여부, 연결 복구에 재연결이 필요한지를 기록해야 시스템 스케줄링과 네트워크 전환, 특정 앱 동작을 구분할 수 있습니다. 모든 백그라운드 문제를 노드 오류로 단정하지 마세요.

Linux: 그래픽 클라이언트와 코어 실행

배포판에 맞는 패키지 선택

데스크톱 사용자는 Linux 다운로드 섹션에서 Clash Verge Rev 또는 FlClash를 선택할 수 있으며, 이 플랫폼에서는 Clash Verge Rev를 우선 추천합니다. 배포판 정보와 아키텍처를 확인해 패키지 형식을 선택하세요. Debian 및 Ubuntu 계열은 보통 deb, Fedora 환경은 대개 rpm을 사용하지만 실제로는 다운로드 페이지에서 제공하는 패키지를 기준으로 해야 합니다. AMD64 패키지를 ARM64 호스트에 설치하지 마세요. 코어 압축 파일은 메뉴와 구독 편집기, 시스템 트레이가 포함된 완전한 데스크톱 앱과 다릅니다.

cat /etc/os-release
uname -m

시스템 소프트웨어 설치 프로그램이나 배포판의 패키지 관리자로 로컬 패키지를 설치하고 의존성 해결 안내를 확인하세요. GUI가 열리지 않으면 터미널에서 설치된 클라이언트를 실행해 오류를 확인하고 그래픽 라이브러리 누락, 디스플레이 세션 문제, 코어 설정 오류를 구분하세요. Wayland와 X11, 데스크톱 환경에 따라 시스템 트레이 지원이 다릅니다. 트레이 아이콘이 보이지 않는다고 프로그램이 실행되지 않는 것은 아닙니다. 먼저 창과 프로세스를 확인한 뒤 데스크톱 구성 요소를 조정할지 결정하세요.

구독 가져오기와 데스크톱 프록시 설정

그래픽 클라이언트에서 다른 데스크톱 플랫폼과 비슷한 방식으로 구독을 가져와 설정을 활성화하고 프록시 그룹 출구를 선택하세요. 차이점은 모든 데스크톱과 앱에 공통으로 적용되는 시스템 프록시 메뉴가 없다는 것입니다. GNOME과 KDE의 설정은 다르며 터미널 프로그램이 데스크톱 프록시를 읽지 않을 수도 있습니다. 먼저 프록시를 명시한 명령으로 코어 포트를 확인하고, 정상 작동을 확인한 뒤 현재 데스크톱 환경을 설정하세요. 데스크톱 프록시와 셸 환경 변수, 패키지 관리자 설정을 동시에 바꾸고 웹 요청 한 번만으로 어느 설정이 적용되었는지 판단하지 마세요.

curl --proxy http://127.0.0.1:7890 -I https://example.com

# 현재 셸과 이후에 실행되는 하위 프로세스에만 적용
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1

여기서 HTTPS 프록시 변수는 HTTP 프록시 연결을 사용합니다. 즉 도구가 해당 연결을 통해 터널을 만드는 것이지 로컬 포트에서 HTTPS 서비스를 켜야 한다는 뜻은 아닙니다. 도구마다 변수 이름의 대소문자 처리와 설정 우선순위가 다를 수 있으므로 설명서를 확인하세요. 테스트가 끝나면 unset http_proxy https_proxy no_proxy를 실행해 이번 설정을 지울 수 있습니다. 셸 시작 파일에 기록하기 전에 이 기기에서 로컬 프록시를 계속 사용할지 확인하세요. 클라이언트가 종료된 후 터미널에서도 인터넷을 사용할 수 없게 될 수 있습니다.

TUN, 권한, DNS 서비스

Linux TUN은 일반적으로 /dev/net/tun과 네트워크 관리 권한이 필요합니다. 그래픽 클라이언트에서는 자체 서비스 설치 절차를 우선 사용하고 편의를 위해 전체 사용자 세션에 관리자 권한을 부여하지 마세요. 컨테이너나 제한된 호스트에서는 필요한 장치나 권한이 없을 수 있으며, 관리자 권한으로 실행해도 인터페이스를 만들지 못할 수 있습니다. 먼저 실행 환경이 네트워크 트래픽 연결을 허용하는지 확인한 뒤 설정 항목을 점검하세요. 컨테이너 문제라면 호스트와 컨테이너 네트워크, 앱의 라우팅도 따로 구분해야 합니다.

자동 라우팅을 활성화한 뒤 기존 VPN과 가상 머신 네트워크, 컨테이너 브리지 사이에 충돌이 없는지 확인하세요. DNS는 NetworkManager나 systemd-resolved가 관리할 수도 있습니다. DNS 설정 파일을 직접 덮어쓰면 시스템이 원래 설정으로 되돌리거나 현재 네트워크에 문제가 생길 수 있습니다. 먼저 시스템의 실제 DNS 확인 경로를 파악한 뒤 클라이언트가 처리할 요청을 정하세요. TUN의 DNS 하이재킹은 해당 경로에 들어오는 트래픽만 처리할 수 있으며 앱 자체의 암호화 DNS는 별도로 검토해야 합니다.

ip route
ip rule
resolvectl status
ss -lntp

일부 배포판에는 resolvectl이 없습니다. 명령을 찾을 수 없어도 DNS 오류라는 뜻은 아니므로 해당 배포판에서 실제로 사용하는 네트워크 관리 도구를 이용하세요. 라우팅 출력을 확인할 때는 기본 출구와 정책 라우팅, 중복된 가상 인터페이스를 살펴보세요. 수신 대기 정보를 확인할 때는 루프백 인터페이스와 모든 인터페이스를 구분해야 합니다. 내부 네트워크 대역과 인터페이스 주소, 조직 네트워크 정보가 포함될 수 있으므로 출력 전체를 공개하지 마세요.

서버에서 mihomo를 사용할 때의 범위

서버나 라우터에서 사용하거나 GUI가 필요 없는 경우 다운로드 페이지의 mihomo 코어 섹션을 이용할 수 있습니다. 설치 전에 운영체제와 프로세서 아키텍처, 바이너리 지원 범위를 확인하세요. 전체 설정을 준비한 뒤 먼저 문법을 검사하고 포그라운드에서 실행해 로그를 확인하세요. 아래 명령은 코어가 명령 검색 경로에 설치되어 있고 지정한 위치에 유효한 설정 파일이 있다고 가정합니다. 노드와 프록시 그룹을 생성하는 명령은 아닙니다.

mihomo -t -f "$HOME/.config/mihomo/config.yaml"
mihomo -f "$HOME/.config/mihomo/config.yaml"

서비스를 장기간 실행할 때는 설정 파일을 읽을 수 있는 범위를 제한해 일반 사용자가 구독 인증 정보에 접근하지 못하도록 하세요. 로그는 필요한 만큼만 보관하고 문제를 해결한 뒤에는 일반 로그 수준으로 되돌리세요. LAN에 프록시를 공유한다면 필요한 수신 주소와 방화벽 출처만 허용하고 프록시 포트나 제어 인터페이스를 인터넷에 직접 공개하지 마세요. 제거하거나 비활성화할 때는 관련 서비스와 프록시 환경 변수, 남은 라우트를 정리한 뒤 시스템의 직접 연결이 복구되었는지 확인하세요.

자주 발생하는 설정 문제: 요청 경로에 따라 점검하기

설정이 로드되지 않음: 다운로드와 파싱 확인

오류가 발생하면 원문과 발생 시각을 보존한 뒤 구독 요청 실패인지 설정 파싱 실패인지 구분하세요. 요청 실패는 만료된 링크와 서버 접속 불가, 기본 네트워크 인증 미완료가 원인일 수 있습니다. 파싱 오류는 들여쓰기와 필드 유형, 프로토콜 지원, 참조 이름 문제인 경우가 많습니다. YAML은 공백으로 들여쓰기해야 하며 목록 계층과 문자열 유형도 올바르게 지정해야 합니다. 특정 줄이 오류 위치로 표시되더라도 바로 위 줄에서 콜론이나 따옴표가 빠졌는지 확인하세요. 표시된 줄만 삭제하지 마세요.

가져온 뒤 노드가 보이지 않는다면 반환된 내용이 프록시 목록뿐인지 또는 구독 다운로드가 로그인 페이지로 리디렉션되었는지 확인하세요. 노드는 있지만 프록시 그룹 오류가 발생하면 그룹에서 참조하는 이름이 정확한지, 구독 제공자가 설정을 성공적으로 내려받았는지 확인하세요. 일부 규칙 집합은 별도로 리소스를 가져와야 하므로 기본 설정이 정상적으로 로드되었다고 외부 파일까지 모두 준비된 것은 아닙니다. 업데이트 후 문제가 생겼다면 백업을 복원하고 변경 범위를 비교하세요. 유일하게 작동하는 사본에 계속 덮어쓰지 마세요.

연결 기록이 없음: 트래픽 진입 경로 확인

대상 앱에서 새 요청을 보냈는데 클라이언트에 기록이 전혀 없다면 회선보다 트래픽 연결 설정부터 확인하세요. 시스템 프록시는 주소와 포트를, TUN은 서비스 권한과 라우팅을, 모바일 기기는 VPN 권한과 앱별 목록을 점검해야 합니다. 앱이 기존 연결을 재사용할 수도 있으므로 설정을 바꾼 뒤 대상 앱을 다시 실행하거나 새 요청을 보내세요. 연결 화면의 필터 조건도 확인해야 합니다. 특정 유형의 연결만 표시되고 있다는 이유만으로 모든 트래픽이 들어오지 않는다고 판단하지 마세요.

이 기기의 브라우저에서는 되지만 터미널에서 안 된다면 프록시를 명시해 테스트하세요. 다른 기기에서 공유 프록시에 연결할 수 없다면 LAN 연결 허용 여부와 수신 주소, 방화벽을 확인하세요. 루프백 주소는 현재 기기에서만 사용할 수 있습니다. 다른 기기는 프록시가 실행 중인 기기의 LAN 주소에 연결해야 하며 자신의 127.0.0.1에 연결하면 안 됩니다. 외부 제어 포트는 혼합 포트를 대신할 수 없습니다. 인증을 설정했다면 연결 도구에도 해당 인증 정보를 입력하세요.

연결은 있지만 결과가 잘못됨: 모드와 규칙 확인

규칙은 순서대로 적용되므로 앞쪽의 포괄적인 규칙이 뒤에 있는 세부 규칙을 가릴 수 있습니다. 프록시 그룹 규칙이 적용되더라도 그룹에서 현재 어떤 항목을 선택했는지 확인해야 합니다. 프록시처럼 보이는 이름의 그룹에서도 직접 연결을 선택할 수 있습니다. 전역 모드는 일반적인 분기 규칙을 우회하므로 짧은 비교 테스트에는 사용할 수 있지만 규칙 수정 대신 계속 사용해서는 안 됩니다. 직접 연결 모드는 기본 네트워크 확인에 적합합니다. 모드 변경을 확인하려면 새 연결을 테스트하세요. 기존 연결은 이전 경로를 계속 사용할 수 있습니다.

아래는 규칙 순서를 보여주는 예시입니다. PROXY는 실제로 존재하는 프록시 그룹 이름이어야 합니다. 완전한 설정이 아니므로 구독 전체를 대신해 붙여 넣을 수 없습니다. 도메인 규칙이 적용되는지는 코어가 대상 도메인을 파악할 수 있는지에 따라서도 달라집니다. 앱이 IP 주소로 직접 요청하면 도메인 접미사 규칙이 적용된다고 가정하지 마세요.

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

시간 초과, DNS 오류, 프로토콜 차이

시간 초과는 DNS 조회와 원격 연결, 프로토콜 핸드셰이크, 대상 서버 응답 중 어느 단계에서든 발생할 수 있습니다. 같은 대상과 네트워크, 프록시 정책으로 재현 가능한 테스트를 한 뒤 한 번에 변수 하나만 바꾸세요. 특정 회선만 실패하고 다른 회선은 정상이라면 해당 회선을 우선 확인하세요. 특정 네트워크에서 모든 회선이 실패한다면 네트워크 제한과 DNS 경로를 점검하세요. 속도 테스트 결과 하나는 보조적인 선택 기준일 뿐 모든 프로토콜과 웹사이트, 시간대의 상태를 보여 주지는 않습니다.

웹페이지는 주로 TCP를 사용하지만 음성 통화와 일부 게임은 UDP에 의존할 수 있습니다. 노드 프로토콜과 서버, 클라이언트 설정이 모두 해당 연결을 지원해야 합니다. HTTPS 페이지가 열린다고 UDP도 작동한다고 볼 수 없습니다. 시스템 시간이 크게 어긋나면 암호화 연결 검증도 실패할 수 있으므로 먼저 신뢰할 수 있는 시간 동기화를 활성화하세요. DNS를 변경한 뒤에도 이전 캐시가 테스트 결과에 영향을 줄 수 있습니다. 새 연결을 만든 뒤 필요하다면 시스템 방법에 따라 캐시를 새로고침하고 네트워크 설정을 무작정 초기화하지 마세요.

업데이트, 덮어쓰기, 복구 기록

구독 자동 업데이트는 원격 설정 변경을 반영하는 데 유용하지만 제공업체 안내에 맞춰 빈도를 조정하세요. 너무 자주 설정할 필요는 없습니다. 업데이트할 때마다 개인 규칙이 사라진다면 클라이언트에서 지원하는 덮어쓰기 기능으로 옮기고 병합 순서를 확인하세요. 일부 기능은 항목을 추가하지만 다른 기능은 목록 전체를 대체합니다. 저장된 원본 파일이 코어에서 실제 실행 중인 설정과 다를 수 있으므로 클라이언트의 실행 설정 화면이나 로그에서 최종 결과를 확인하세요.

문제 해결이 끝나면 일반 로그 수준으로 되돌리고 임시 전역 모드와 더 이상 사용하지 않는 LAN 수신을 끄세요. 현재 설정의 백업도 확인하세요. 처음부터 다시 따라 하려면 사용 가이드를 참고하세요. 용어의 의미만 확인하려면 용어집이 더 빠릅니다. 설치 문제는 해당 플랫폼 장에서, 연결 문제는 요청 경로에 따라 단계별로 확인하세요. 매번 앱을 제거하고 다시 설치할 필요는 없습니다.