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

시작하기 전 준비

공통 준비: 클라이언트, 아키텍처, 설정 출처

클라이언트, 코어, 구독의 차이

Clash 생태계는 그래픽 클라이언트, 네트워크 처리를 담당하는 코어, 프록시와 규칙을 정의하는 설정 파일로 구성됩니다. 클라이언트에서는 설정 가져오기, 전환, 로그 확인, 권한 관리 등을 할 수 있고, 코어는 연결, 도메인 이름 조회, 규칙 매칭을 처리합니다. 설치에 성공했다는 것은 프로그램이 실행된다는 뜻일 뿐, 사용할 수 있는 프록시 출구가 있다는 의미는 아닙니다. 구독은 보통 서비스 제공자가 발급하며, 클라이언트 다운로드 페이지에서 함께 제공하지는 않습니다. 시작하기 전에 설정 출처와 유효 기간, 지원 형식, 여러 기기에서 사용할 수 있는지 확인하세요.

그래픽 인터페이스가 필요하다면 Windows, macOS, Android, iOS에서는 Clash Plus를 먼저 살펴보세요. Linux에서는 Clash Verge Rev 또는 FlClash를 사용할 수 있습니다. 플랫폼별 설치 파일은 다운로드 센터에서 확인하세요. 제품 이름이 비슷해도 설정 호환성이 완전히 같지는 않습니다. 특히 최신 프로토콜, 규칙 항목, 스크립트 기능은 차이가 날 수 있습니다. 클라이언트를 바꿀 때는 기존 설정을 먼저 보관하고, 파일 확장자만으로 호환 여부를 판단하지 말고 새 코어가 어떤 항목을 지원하는지 확인하세요.

운영체제와 프로세서 아키텍처 확인

데스크톱에서는 먼저 운영체제 버전과 프로세서 종류를 확인하세요. Windows는 ‘설정 → 시스템 → 정보’에서 시스템 종류를, macOS는 Apple 메뉴의 ‘이 Mac에 관하여’에서 칩 정보를 확인할 수 있습니다. Linux에서는 아래 명령으로 아키텍처를 확인하세요. Android 설치 파일은 ARM64, ARM, 범용 패키지로 나뉠 수도 있습니다. 앱 설치가 실패했다고 해서 파일 손상이라고 단정하지 마세요. 아키텍처가 맞더라도 클라이언트의 최소 시스템 요구 사항을 확인해야 합니다. 오래된 시스템에 실행 구성 요소가 없다면 같은 아키텍처의 설치 파일로 바꿔도 문제가 해결되지 않습니다.

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

현재 네트워크 환경도 기록해 두세요. 학교나 회사 네트워크에 연결되어 있는지, 웹 페이지에서 먼저 인증해야 하는지, 기존 프록시나 VPN이 실행 중인지 확인합니다. 네트워크 인증이 끝나지 않았다면 트래픽 처리를 끄고 먼저 인증을 완료하세요. 클라이언트 여러 개에서 시스템 프록시나 가상 네트워크 인터페이스를 동시에 켜면 진입점과 라우팅이 서로 덮어쓸 수 있습니다. 처음 설정할 때는 클라이언트 하나만 실행하고, 이후에는 한 번에 한 항목씩 바꿔야 어떤 변경이 결과에 영향을 줬는지 알 수 있습니다.

되돌릴 수 있도록 설정 백업

링크를 가져오기 전에 신뢰할 수 있는 출처인지 확인하고 민감 정보로 취급하세요. 링크에는 계정 식별 정보나 액세스 자격 증명이 포함될 수 있으므로 공개 스크린샷, 로그 공유, 온라인 변환 사이트에 노출하지 마세요. 파일을 가져올 때는 원본 YAML을 따로 보관하세요. 클라이언트 설정 내보내기를 지원한다면 해당 설정도 백업해 두세요. 구독 내용과 클라이언트의 로컬 설정은 별도로 저장되는 경우가 많습니다. 이전할 때 YAML만 복사하면 시작 시 자동 실행, 서비스 모드, 인터페이스 설정 등이 옮겨지지 않을 수 있습니다.

구성을 쉽게 식별할 수 있는 로컬 이름으로 저장하고, 가져온 방식과 마지막으로 업데이트에 성공한 시각, 사용한 코어를 기록하세요. 그런 다음 혼합 포트, 트래픽 모드, 트래픽 처리 방식을 확인합니다. 먼저 시스템 프록시를 따르는 브라우저 하나로 접속을 확인한 뒤 TUN, LAN 공유, 복잡한 DNS 설정을 고려하세요. 기본 연결이 되지 않는 상태에서 옵션을 한꺼번에 켜면 설정, 권한, 네트워크 문제가 뒤섞여 원인을 찾기 어려워집니다.

설치 전에 시스템 시간이 맞는지, 디스크 여유 공간이 있는지, 로그를 어디서 확인하는지 알아두세요. 인증서 관련 오류는 시간 차이로 발생할 수 있고, 포트 시작 실패는 대개 포트 충돌을 확인해야 합니다. 최초 설치 권한과 일반적인 오류는 멀티 플랫폼 초기 설정 점검표를 참고하세요. 재설치하기 전에 오류 메시지와 발생 단계를 먼저 기록하는 것이 좋습니다.

Windows

Windows: 설치, 시스템 프록시, 서비스 권한

설치 파일을 선택하고 처음 실행하기

Windows 다운로드에서 Clash Plus를 먼저 확인하세요. 인터페이스와 설정 관리 방식을 비교하려면 Clash Verge Rev, FlClash 또는 Clash Nyanpasu도 살펴볼 수 있습니다. Clash for Windows는 유지 관리가 중단된 보관용 클라이언트이므로 새 기기에서 기본 선택으로 권장하지 않습니다. 다운로드 전에 시스템 종류와 설치 파일 요구 사항을 확인하세요. 모든 Windows 기기가 같은 프로세서를 사용한다고 가정하면 안 됩니다.

설치 마법사에서 경로를 선택한 뒤 처음 실행하여 기본 화면에 진입할 수 있는지, 코어가 정상적으로 작동하는지 확인하세요. 보안 소프트웨어가 차단한다면 어떤 파일이 차단됐는지, 출처와 차단 사유가 무엇인지 확인하고 조직이나 기기의 보안 정책에 따라 처리하세요. 모든 보호 기능을 바로 끄면 안 됩니다. 포터블 버전과 설치 버전은 데이터 저장 위치가 다를 수 있습니다. 이전하기 전에 클라이언트의 ‘설정 폴더 열기’와 비슷한 메뉴에서 실제 위치를 확인하고, 다른 제품의 경로를 기준으로 파일을 삭제하지 마세요.

구독을 가져오고 현재 설정 확인

‘설정’, ‘구독’ 또는 이에 해당하는 페이지에서 원격 설정을 추가하고 로컬 이름과 구독 주소를 입력한 뒤 저장하고 업데이트하세요. 업데이트가 끝나면 해당 설정을 선택해 적용해야 합니다. 목록에 항목이 표시된다고 해서 코어에 이미 적용된 것은 아닙니다. 프록시 또는 정책 그룹 페이지에서 예상한 항목이 있는지 확인하세요. 직결 옵션만 보인다면 시스템 프록시를 반복해서 켜고 끄지 말고 구독 응답과 파싱 로그를 확인하세요.

로컬 파일은 가져오기 메뉴에서 YAML을 선택하면 됩니다. 불러오기에 실패하면 먼저 오류가 난 줄 주변의 들여쓰기, 항목, 정책 이름을 확인한 다음 코어가 해당 설정을 지원하는지 살펴보세요. 원격 설정을 로컬에서 덮어써야 한다면 클라이언트의 덮어쓰기 또는 병합 기능을 사용하세요. 캐시 파일을 직접 수정하면 다음 업데이트 때 변경 내용이 사라질 수 있습니다. 테스트 전에 현재 혼합 포트를 기록하세요. 흔한 예시는 7890이지만 실제 연결에는 클라이언트가 현재 수신 중인 포트를 사용해야 합니다.

먼저 시스템 프록시를 확인한 뒤 TUN 사용

클라이언트에서 ‘시스템 프록시’를 켠 다음 Windows의 ‘설정 → 네트워크 및 인터넷 → 프록시’에서 주소와 포트를 확인하세요. 보통 로컬 주소는 127.0.0.1이며 포트는 클라이언트 설정과 일치해야 합니다. 브라우저에 프록시 확장 프로그램이 설치되어 있다면 요청을 어느 계층에서 제어할지 정해 시스템 설정이 덮어써지지 않도록 하세요. 규칙 모드에서 대상에 접속한 뒤 연결 기록에서 적용된 규칙과 아웃바운드 정책을 확인하세요. 스위치가 켜져 있는지만 확인해서는 안 됩니다.

명령줄 도구는 시스템 프록시를 사용하지 않을 수도 있습니다. 아래 변수를 PowerShell 세션에서 임시로 설정한 뒤 대상 도구를 테스트할 수 있습니다. 이 환경 변수를 지원하는 프로그램만 해당 설정을 사용하며, 도구 자체의 프록시 옵션이 우선할 수도 있습니다. 창을 닫으면 이번 세션의 설정은 사라집니다. 사용자 또는 시스템 수준에서 변수를 따로 설정했다면 해당 위치에서 직접 지워야 합니다. 임시 세션의 결과만으로 전체 시스템 설정이 복구됐다고 판단하지 마세요.

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"

# 테스트가 끝나면 이 세션의 설정을 지우세요
Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue

TUN은 시스템 프록시를 따르지 않는 프로그램을 위한 기능이며, 클라이언트에 필요한 권한이 있어야 합니다. 제품에 ‘서비스 모드’나 ‘서비스 설치’가 있다면 안내에 따라 먼저 완료한 다음 TUN을 켜고 로그를 확인하세요. 서비스 설치, 코어 시작, 가상 네트워크 인터페이스 생성은 서로 다른 단계입니다. 서비스가 정상으로 표시되는데 TUN이 실패한다면 구독을 다시 가져오는 대신 드라이버, 권한, 라우팅을 확인하세요. 회사 기기에서는 가상 네트워크 인터페이스가 제한될 수 있으므로 기기 관리 정책을 따라야 합니다.

절전 모드 복귀, 포트 충돌, 종료 후 정리

컴퓨터가 절전 모드에서 깨어나거나 Wi-Fi를 바꾼 뒤 연결에 문제가 생기면 먼저 트래픽 처리를 중지하고 기본 네트워크가 정상인지 확인한 다음 다시 켜세요. 포트 충돌은 Get-NetTCPConnection -LocalPort 7890으로 수신 기록을 확인하고 프로세스 정보를 함께 살펴보면 원인을 찾는 데 도움이 됩니다. 알 수 없는 프로세스를 바로 종료하지 마세요. 이전 클라이언트를 종료하거나 새 클라이언트의 포트를 바꾼 뒤 해당 포트를 참조하는 모든 항목을 함께 수정할 수 있습니다.

시작 시 자동 실행과 자동 연결은 별개의 옵션이므로 수동 연결을 확인한 뒤 사용하세요. 브라우저는 되는데 터미널이 안 된다면 브라우저와 터미널 문제를 따로 점검하는 방법을 참고하세요. 특정 앱만 실패한다면 자체 프록시 설정, 특수 전송 프로토콜, 앱의 네트워크 제한을 확인하세요.

macOS

macOS: 칩 아키텍처, 보조 서비스, 네트워크 설정

칩에 맞는 클라이언트 선택

‘이 Mac에 관하여’에서 Apple 칩인지 Intel 프로세서인지 확인한 다음 macOS 다운로드에서 맞는 설치 파일을 선택하세요. Clash Plus를 먼저 살펴보고 Clash Verge Rev 또는 FlClash를 사용할 수도 있습니다. ClashX Meta는 유지 관리가 중단된 보관용 선택지입니다. 이전 설정을 가져올 때는 항목과 새 코어의 차이에 특히 주의하세요. 호환 변환을 사용하더라도 시스템 요구 사항을 확인해야 합니다. 일반적으로 기본 아키텍처용 패키지가 유지 관리하기 편리합니다.

디스크 이미지가 제공되는 경우 열어서 앱을 ‘응용 프로그램’으로 옮긴 뒤 해당 위치에서 실행하세요. 디스크 이미지 안에서 계속 실행하지 마세요. 시스템에서 앱을 열 수 없다는 알림이 표시되면 먼저 다운로드 출처와 알림 내용을 확인하고 ‘개인정보 보호 및 보안’의 시스템 절차를 따르세요. 모든 보안 제한을 해제하는 방법을 일반적인 설치 절차로 삼으면 안 됩니다. 조직에서 관리하는 Mac은 백그라운드 항목, 네트워크 확장, 관리자 권한이 제한될 수 있으므로 기기 정책을 먼저 확인하세요.

설정을 가져오고 클라이언트 설정 보존

설정 관리 페이지에서 링크로 원격 구독을 추가하고 업데이트한 뒤 현재 설정으로 지정하세요. 로그에서 불러오기가 성공했는지 확인한 다음 정책 그룹에서 아웃바운드를 선택합니다. 파일을 가져와도 메뉴 막대 동작, 시스템 프록시 제어, 보조 서비스 상태까지 함께 설정되는 것은 아닙니다. 이전 클라이언트에서 옮길 때는 기존 파일과 로컬 덮어쓰기를 먼저 내보낸 뒤 새 클라이언트 설정을 하나씩 적용하세요. 여러 제품의 백그라운드 서비스를 동시에 복원하지 마세요.

원격 구독 업데이트 후 사용자 규칙이 사라졌다면 규칙이 구독 캐시에 작성된 것인지 별도 덮어쓰기로 저장된 것인지 확인하세요. 두 방식의 업데이트 주기는 다릅니다. 수정하기 전에 클라이언트 메뉴에서 현재 설정 폴더를 열어 실제 적용 파일을 확인하세요. ‘다운로드’ 폴더의 원본 파일이 클라이언트와 계속 동기화된다고 가정하면 안 됩니다. 설정 파싱에는 성공했지만 예상한 정책 그룹이 없다면 앱을 다시 설치하기보다 구독 형식과 선택된 설정을 확인하세요.

현재 네트워크 서비스의 프록시 확인

시스템 프록시를 켠 뒤 ‘시스템 설정 → 네트워크’에서 사용 중인 Wi-Fi 또는 이더넷 서비스를 선택하고 ‘세부사항 → 프록시’에서 주소를 확인하세요. 네트워크 서비스마다 설정이 따로 있으므로 Wi-Fi에서 유선 연결로 바꿨다면 다시 확인해야 합니다. 클라이언트가 웹 프록시, 보안 웹 프록시, SOCKS 프록시를 함께 설정할 수 있습니다. 실제 항목은 제품 구현에 따라 다르지만, 주소와 포트가 현재 실행 중인 클라이언트를 가리키는지 확인하는 것이 중요합니다.

터미널에서 아래 명령으로 시스템 프록시 상태를 확인할 수 있지만, 설정을 읽는 것일 뿐 모든 명령줄 프로그램이 자동으로 프록시를 사용한다는 뜻은 아닙니다. 특정 HTTP 요청을 진단하려면 로컬 프록시를 명시적으로 지정하세요. 예시에서는 테스트 전용 도메인에 접속하므로 요청 경로만 확인할 수 있습니다. 요청 성공이 모든 사이트와 프로토콜의 정상 작동을 보장하지는 않습니다. 연결 기록을 확인해 요청이 실제로 코어에 전달됐는지 살펴보세요.

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

‘웹 페이지는 열리는데 명령줄은 실패’한다면 도구 자체의 프록시 설정, 환경 변수, 도메인 이름 조회 동작을 확인해야 합니다. 도구에서 SOCKS를 지원하고 프록시를 통해 도메인을 조회해야 한다면 문서에 따라 적절한 모드를 선택하세요. HTTP 프록시 주소를 모든 프로토콜 옵션에 입력하면 안 됩니다. 인증서 오류도 별도로 진단해야 합니다. 먼저 시스템 시간, 인증서 체인, 네트워크 차단 여부를 확인하고 인증서 검증 생략을 장기 설정으로 사용하지 마세요.

TUN 권한 및 네트워크 복구

TUN을 켜기 전에 클라이언트 안내에 따라 보조 서비스를 설치하거나 권한을 승인하세요. 보조 서비스는 추가 권한이 필요한 시스템 작업을 수행하기 위한 것이며, GUI가 모든 네트워크 권한을 자동으로 얻는다는 의미는 아닙니다. 설치 성공 메시지가 나오는데 스위치가 즉시 꺼진다면 서비스 로그, 코어 로그, 시스템 권한 상태를 확인하세요. 클라이언트를 바꾸기 전에 이전 클라이언트의 TUN을 먼저 중지해 기존 라우트와 새 트래픽 처리 방식이 겹치지 않게 하세요.

절전 모드에서 깨어나기, 네트워크 서비스 전환, 다른 VPN의 시작 및 종료는 라우팅을 바꿀 수 있습니다. 문제를 확인할 때는 먼저 TUN과 시스템 프록시를 끄고 직접 연결이 되는지 확인한 뒤 트래픽 처리 방식을 하나만 다시 켜세요. 직접 연결은 되지만 활성화 후 모든 도메인에 접속할 수 없다면 DNS와 라우팅을 먼저 확인하세요. 특정 대상만 실패한다면 규칙과 아웃바운드를 살펴보세요. 처음부터 시스템 네트워크 전체를 초기화하면 업무용 네트워크의 고정 IP와 인증 설정을 잃을 수 있습니다.

마지막으로 로그인 시 자동 실행을 설정하고 백그라운드 항목이 실행을 허용하는지 확인하세요. 시스템 업데이트 후 권한이 바뀌었다면 같은 구독을 반복해서 가져오지 말고 권한 설정 위치를 다시 확인하세요. 플랫폼 설정은 정상인데 파싱 오류가 계속된다면 설정 및 문제 해결로 이동해 파일, 코어, 규칙 순서로 원인을 찾아보세요.

Android

Android: 설치 파일, VPN 권한, 백그라운드 실행

아키텍처 선택 및 설치 제한 확인

Android 다운로드에서 클라이언트를 선택하세요. Clash Plus를 먼저 권장하며 Clash Meta for Android, FlClash, Surfboard도 선택할 수 있습니다. 제품마다 지원하는 구독 형식과 규칙 기능이 다르므로 한 클라이언트의 전체 YAML을 다른 제품에 확인 없이 가져오면 안 됩니다. 먼저 지원 형식을 확인하고 기기 아키텍처에 맞는 패키지를 선택하세요. 확실하지 않다면 제품에서 범용 패키지를 제공하는지 확인할 수 있습니다.

외부 앱을 설치할 때는 현재 사용하는 브라우저나 파일 관리 앱에 설치 권한을 허용해야 할 수 있습니다. 이번에 사용하는 출처에만 권한을 주고 설치가 끝난 뒤 시스템 설정에서 다시 해제할 수 있습니다. 파싱 오류가 표시되면 시스템 요구 사항, 아키텍처, 파일 다운로드 완료 여부, 저장 공간 순으로 확인하세요. 서명 충돌은 기존 앱의 서명이나 배포 출처가 다를 때 발생할 수 있습니다. 앱을 삭제하기 전에 설정과 로컬 데이터를 내보내세요.

구독 가져오기 및 현재 설정 전환

‘설정’ 또는 ‘구독’ 페이지에서 링크를 추가하거나 파일 선택기로 로컬 YAML을 가져오세요. Android 파일 선택기는 선택한 파일을 읽을 권한만 클라이언트에 부여할 수 있으므로 가져온 설정이 원본 파일의 변경 사항을 계속 반영하지 않을 수 있습니다. 저장 후 직접 업데이트하고 내용과 정책 그룹을 확인한 다음 현재 설정으로 지정하세요. ‘가져오기 성공’ 표시는 가져오기 작업이 완료됐다는 뜻일 뿐, 코어가 설정을 불러왔는지는 별도로 확인해야 합니다.

원격 링크가 웹 페이지, 로그인 화면, 지원하지 않는 형식을 반환하면 설정이 비어 있거나 파싱 오류가 발생할 수 있습니다. 이때 구독 만료 여부, 해당 클라이언트에 맞는 주소인지, 시스템 시간이 정확한지 먼저 확인하세요. 전체 링크를 채팅방에 공개해 도움을 요청하지 마세요. 로그 공유를 지원하는 클라이언트라면 구독 주소, 계정 식별 정보, 노드 자격 증명을 지우고 오류 종류, 관련 항목, 필요한 주변 정보만 남기세요.

VPN 인터페이스와 앱별 분할 라우팅

연결을 시작하면 Android에서 VPN 연결 요청이 표시됩니다. 클라이언트가 맞는지 확인하고 권한을 승인한 다음 시스템 상태 표시줄과 앱 내 상태를 확인하세요. VPN 인터페이스는 시스템이 제공하는 트래픽 처리 경로입니다. 모든 연결이 원격 프록시를 통과한다는 뜻은 아닙니다. 최종 동작은 규칙, 정책 그룹, 앱별 설정에 따라 달라집니다. 일반적으로 Wi-Fi의 수동 프록시는 변경할 필요가 없습니다. 모바일 네트워크와 Wi-Fi 설정을 별개의 진입점으로 혼동하지 마세요.

같은 사용자 환경에서 일반 VPN 앱은 보통 이 인터페이스를 동시에 사용할 수 없습니다. 회사 VPN, 방화벽, 로컬 필터링 도구가 이미 실행 중이라면 어떤 도구가 트래픽을 처리할지 정하세요. ‘항상 켜져 있는 VPN’ 또는 ‘VPN 없이 연결 차단’을 켜기 전에 클라이언트의 시작과 재연결을 테스트하세요. 후자는 클라이언트가 중지되면 네트워크를 차단할 수 있어 Wi-Fi 장애로 오해하기 쉽습니다.

앱별 분할 라우팅에는 보통 선택한 앱만 처리하거나 선택한 앱을 제외한 나머지를 처리하는 두 가지 방식이 있습니다. 저장하기 전에 목록의 의미를 확인하고 체크 표시만으로 판단하지 마세요. 테스트할 때는 처리 대상에 포함된 앱 하나로 요청을 보내고 로그와 적용된 규칙을 확인하세요. 업무 프로필, 앱 복제, 별도 사용자 공간에는 제한이 따로 적용될 수 있으므로 기본 공간의 선택이 다른 공간에도 적용된다고 단정하면 안 됩니다.

백그라운드 제한, 네트워크 전환, 배터리 사용 확인

화면을 잠근 뒤 연결이 끊긴다면 먼저 시스템의 배터리 최적화, 백그라운드 활동, 자동 실행 설정을 확인하세요. 제조사마다 메뉴 이름이 다르므로 앱 정보 페이지의 실제 옵션을 기준으로 살펴봐야 합니다. 포그라운드 서비스 알림은 실행을 유지하고 연결 상태를 표시하는 데 사용되는 경우가 많습니다. 알림이 계속 표시된다는 이유만으로 클라이언트 오류라고 판단하지 마세요. 설정을 마친 뒤 화면 켜짐, 화면 잠금, Wi-Fi에서 모바일 네트워크로 전환하는 상황을 각각 테스트하고 처음 실패한 단계를 기록하세요.

모바일 네트워크에서만 실패한다면 해당 앱의 모바일 데이터 사용이 제한되어 있는지, 데이터 절약 모드가 켜져 있는지, 현재 네트워크에서 구독의 프록시 출구로 연결할 수 있는지 확인하세요. 연결은 되지만 일부 앱만 사용할 수 없다면 앱별 분할 라우팅과 DNS를 확인하세요. LAN 기기 접속 문제는 사설 IP가 예상대로 직접 연결되는지 살펴보세요. 모든 트래픽을 한 아웃바운드로 강제로 보내 분할 라우팅 문제를 덮으면 로컬 서비스의 접속 경로가 바뀔 수 있습니다.

네트워크 공유 시 휴대폰 자체의 VPN 처리가 핫스팟에 연결된 기기까지 적용되지 않을 수 있습니다. 실제 동작은 시스템과 구현에 따라 다릅니다. 컴퓨터가 휴대폰을 통해 인터넷에 접속하더라도 프록시 설정을 자동으로 이어받는다고 가정하면 안 됩니다. 먼저 컴퓨터에서 요청 경로를 따로 확인하세요. 앱의 규칙 모드, 전역 모드, 직접 연결 모드는 Clash 초보자를 위한 10가지 질문에서 자세히 살펴볼 수 있습니다.

iOS

iOS: 앱 다운로드, 설정 가져오기, 네트워크 확장

App Store에서 Clash Plus 다운로드

iPhone과 iPad에서는 Clash Plus를 먼저 사용해 보세요. iOS 다운로드에서 이동 경로를 확인하거나 Clash Plus App Store 페이지를 직접 열 수 있습니다. 제품 웹사이트는 clashplus.io입니다. 다운로드 전에 스토어에 표시된 운영체제 호환 요구 사항과 기기 지원 여부를 확인하세요. 설치 후 앱을 열어 화면이 정상적으로 표시되는지 확인한 다음 설정을 가져오세요. 앱 다운로드와 구독 가져오기는 별개의 단계입니다.

iOS 설정 호환성은 여러 항목을 나누어 확인해야 합니다. 특정 규칙 문법을 지원한다고 해서 다른 클라이언트의 모든 인터페이스 설정, 스크립트, 확장 항목까지 지원하는 것은 아닙니다. 서비스 제공자가 구독 주소를 여러 개 제공한다면 현재 클라이언트에 맞는 형식을 선택하세요. 기존 기기에서 옮길 때는 정책 그룹 선택과 사용자 규칙을 먼저 기록하세요. 시스템 백업에서 앱 데이터까지 복원했는지도 새 기기에서 직접 확인해야 합니다. 앱 아이콘이 표시된다는 사실만으로 복원 여부를 판단하면 안 됩니다.

링크, 파일, QR 코드 가져오기 시 유의 사항

링크는 보통 설정 관리 페이지에서 원격 설정을 추가한 뒤 주소를 붙여 넣고 이름을 지정해 저장합니다. 그런 다음 업데이트하고 선택해 적용하세요. 일부 메뉴는 클립보드에서 가져오기를 지원하며 시스템에서 붙여넣기 권한을 묻는다면 현재 작업에 필요한지 판단해 허용하세요. 붙여넣은 뒤 링크에 공백, 줄바꿈, 메신저가 덧붙인 문자가 포함되지 않았는지 확인하세요. 업데이트가 완료되면 구독 목록에 머무르지 말고 프록시나 정책 그룹에 항목이 표시되는지 살펴보세요.

파일을 가져오려면 시스템의 ‘파일’ 앱에서 저장된 설정을 선택하세요. 클라우드 파일을 아직 기기에 다운로드하지 않았다면 먼저 열 수 있는지 확인한 다음 클라이언트에서 읽으세요. 파일 가져오기는 보통 한 번 복사하는 방식이므로 이후 원본 파일을 수정해도 앱 내 설정이 자동으로 바뀌지 않을 수 있습니다. 계속 업데이트해야 하는 구독은 원격 링크로 관리하는 편이 좋습니다. 로컬에서 관리한다면 수정할 때마다 다시 가져와 적용하는 방법을 정해 두세요.

QR 코드는 클라이언트에서 지원하는 형식일 때 사용할 수 있습니다. 구독 링크, 단일 프록시, 특정 제품 전용 가져오기 주소가 인코딩되어 있을 수 있으므로 스캔에 성공했다고 전체 규칙 설정을 가져온 것으로 보면 안 됩니다. 스캔 후 인식된 내용과 가져오기 유형을 확인하고 출처를 알 수 없는 항목은 가져오지 마세요. 카메라 권한은 스캔 메뉴에만 필요합니다. QR 코드를 사용하지 않는다면 링크나 파일로 설정할 수 있으므로 다른 시스템 권한을 바꿀 필요는 없습니다.

VPN 권한 승인 및 실제 트래픽 처리 확인

처음 연결할 때 시스템에서 VPN 설정 추가를 허용하라는 메시지가 표시되며 기기 잠금 해제로 확인해야 할 수도 있습니다. 승인이 끝나면 클라이언트로 돌아가 연결을 시작하고 시스템 설정에서 VPN 상태를 확인하세요. 이 기능은 네트워크 확장을 통해 트래픽을 처리하며 데스크톱 시스템의 HTTP 프록시 스위치와는 다릅니다. 설정 불러오기, 시스템 터널 시작, 원격 아웃바운드 연결은 각각 별개의 단계입니다. 어느 하나라도 실패하면 웹 페이지가 열리지 않을 수 있습니다.

먼저 규칙 모드에서 사용할 수 있는 정책을 선택하고 대상에 접속한 뒤 클라이언트 로그를 확인하세요. 직접 연결 대상은 되지만 프록시가 필요한 대상은 실패한다면 정책 그룹 선택과 원격 연결을 중점적으로 살펴보세요. 모든 도메인이 실패한다면 DNS, 네트워크 확장 상태, 기본 네트워크를 확인하세요. 연결 중으로 표시되어도 규칙이 모두 올바르다는 뜻은 아닙니다. 상태 표시줄 아이콘만 보지 말고 실제 요청을 테스트하세요. 플랫폼에서 앱 로그를 더 자세히 확인할 수 있다면 오류 발생 시각과 네트워크 종류도 함께 기록하세요.

요청 시 연결, 백그라운드 동작, 네트워크 충돌

클라이언트에서 요청 시 연결을 지원하더라도 수동 연결이 안정적으로 작동한 뒤에 켜세요. 연결 조건과 Wi-Fi 예외를 하나씩 확인해 웹 인증이 필요한 네트워크에서 요청이 먼저 처리되지 않도록 하세요. 호텔, 학교, 공용 Wi-Fi에 접속하면 인증 페이지를 완료할 수 있는지 먼저 확인하세요. 필요한 경우 인증을 마칠 때까지 클라이언트를 잠시 연결 해제한 뒤 다시 연결하세요. 인증 게이트웨이 문제를 구독 오류로 오해하지 마세요.

iOS의 전면 앱과 네트워크 확장은 실행 주기가 다릅니다. 앱 화면을 나갔다고 네트워크 확장이 반드시 중지되는 것은 아닙니다. 반대로 최근 사용 앱 목록에 앱이 남아 있어도 터널이 정상적으로 작동한다고 볼 수 없습니다. 백그라운드 문제를 확인할 때는 앱을 반복해서 전면으로 가져오지 말고 시스템 VPN 상태와 실제 요청을 확인하세요. 다른 VPN이나 네트워크 필터링 제품을 켜기 전에 기존 설정을 대체하는지 확인하고, 문제 해결 중에는 트래픽 처리 진입점을 하나만 남겨 두세요.

Wi-Fi에서는 정상인데 셀룰러 네트워크에서 실패한다면 앱의 셀룰러 데이터 권한과 현재 네트워크 제한을 확인하세요. 특정 앱만 이상하다면 해당 앱의 자체 네트워크 기능과 규칙 적용 여부를 살펴보세요. 자세한 가져오기 방법은 iPhone에서 클라이언트 다운로드 및 설정 가져오기를 참고하세요. 기기를 바꾸거나 클라이언트를 더 이상 사용하지 않을 때는 자동 연결 옵션을 먼저 끄고 시스템 설정에서 필요 없는 VPN 설정을 확인하세요.

Linux

Linux: 배포판 설치, 데스크톱 프록시, 코어 실행

그래픽 클라이언트와 설치 패키지 형식

Linux 데스크톱에서는 Clash Verge Rev와 FlClash를 먼저 살펴보고 배포판에서 사용할 수 있는 패키지를 선택하세요. Debian 및 Ubuntu 계열은 보통 deb, Fedora 등은 대개 rpm을 사용하지만 설치 가능 여부는 아키텍처, 시스템 라이브러리, 데스크톱 환경에 따라서도 달라집니다. 파일 확장자만 보고 호환성을 판단하면 안 됩니다. 설치 전에 배포판 정보와 uname -m 출력을 확인해 패키지 요구 사항이 현재 시스템과 맞는지 살펴보세요.

시스템 패키지 관리자를 사용하면 개별 압축을 푸는 것보다 의존성을 처리하기 쉽습니다. 아래 명령은 패키지가 있는 디렉터리로 이동한 다음 APT로 사용자가 선택한 로컬 deb 파일을 설치합니다. 실행 전에 해당 디렉터리의 파일이 신뢰할 수 있는 출처에서 왔는지 확인하세요. 의존성 오류가 발생하면 패키지 관리자 출력을 읽고 저장소 문제, 라이브러리 버전 부족, 아키텍처 불일치를 구분하세요. 의존성을 강제로 무시해 유지 관리가 어려운 상태로 만들지 마세요.

cd ~/Downloads
read -r -p "현재 디렉터리에 있는 deb 파일 이름을 입력하세요: " package_file
if [ -f "$package_file" ]; then
  sudo apt install "./$package_file"
else
  printf '지정한 파일을 찾을 수 없습니다\n'
fi

구독 가져오기 및 데스크톱 프록시

설치가 끝나면 데스크톱에서 클라이언트를 실행해 원격 구독 또는 로컬 설정을 가져오고, 선택해 적용한 다음 코어 로그를 확인하세요. 데스크톱 그래픽 환경에서는 세션 버스로 시스템 프록시를 관리할 수 있지만 GNOME, KDE, 경량 윈도 관리자마다 동작이 다릅니다. 클라이언트의 시스템 프록시 스위치가 적용되지 않는다면 데스크톱 네트워크 설정에서 실제 값을 확인하세요. 스위치가 켜져 있다고 모든 프로그램이 해당 설정을 읽는 것은 아닙니다.

브라우저는 데스크톱 프록시를 따를 수 있지만 터미널, 컨테이너, 서비스 프로세스는 따르지 않는 경우가 많습니다. 단일 요청을 진단하려면 curl --proxy http://127.0.0.1:7890 --head https://example.com처럼 프록시를 명시적으로 지정할 수 있습니다. 프록시를 지정했을 때 성공하고 기본 실행은 실패한다면 대상 프로그램의 프록시 설정을 우선 확인하세요. 컨테이너 안의 127.0.0.1은 호스트가 아닌 컨테이너 자체를 가리키므로 데스크톱 주소를 그대로 사용할 수 없습니다.

TUN 권한 및 여러 네트워크 관리 도구

TUN은 보통 /dev/net/tun에 접근하고 라우팅을 수정해야 합니다. 그래픽 클라이언트는 보조 서비스로 권한을 얻을 수 있습니다. 제품에서 제공하는 권한 관리 방법을 먼저 사용하고, 그래픽 프로그램 전체를 관리자 권한으로 실행해야 한다고 단정하지 마세요. 아래 명령으로 장치와 라우트가 있는지 확인할 수 있지만 출력은 상태 확인용입니다. 역할을 이해하지 못한 채 라우트를 삭제하거나 방화벽을 비우거나 시스템 DNS 서비스를 중지하지 마세요.

ls -l /dev/net/tun
ip route
resolvectl status
ss -lntp 'sport = :7890'

resolvectl은 해당 이름 조회 서비스를 사용하는 시스템에서만 쓸 수 있습니다. 명령이 없다고 DNS가 손상된 것은 아닙니다. NetworkManager, systemd-resolved, 다른 VPN, 클라이언트 자체 DNS 모듈이 함께 이름 조회에 영향을 줄 수 있습니다. TUN을 켠 뒤 도메인 접속에 실패하면 요청이 코어에 도착하는지, 이름 조회가 어디로 전달되는지 먼저 확인한 뒤 어느 계층을 조정할지 결정하세요. 이름 조회 서비스를 모두 끄면 문제 원인을 찾을 근거가 사라집니다.

서버와 라우터에서 Mihomo 사용

데스크톱 환경이 없는 서버나 라우터에서는 다운로드 센터에서 Mihomo 코어를 확인할 수 있습니다. 다만 이는 GUI 클라이언트 설치와는 다른 방법입니다. 프로세스, 설정 디렉터리, 로그, 권한을 직접 관리해야 합니다. 아키텍처뿐 아니라 실행 환경 요구 사항도 확인하세요. 특히 라우터는 제품 설명에 표시된 프로세서 계열만 보고 파일을 고르면 안 되며 아키텍처 이름과 부동소수점 지원 여부를 확인해야 합니다. 규칙에 따라 트래픽을 나누기 위해 일반 데스크톱 사용자가 먼저 서비스 배포를 배울 필요는 없습니다.

실행 파일이 명령 검색 경로에 있고 파일 이름이 실제 설정 파일과 일치한다면 mihomo -t -f config.yaml로 설정을 검증할 수 있습니다. 검증을 통과하면 먼저 전면 모드로 실행해 로그를 살펴보고 수신 포트와 아웃바운드가 정상인지 확인한 다음 서비스 관리자로 실행하세요. 설정에서 외부 규칙 세트를 참조한다면 작업 디렉터리, 파일 권한, 다운로드 경로도 확인해야 합니다. 서비스 환경과 대화형 터미널 환경은 다를 수 있습니다.

자동 시작 문제는 데스크톱 로그인 시 실행과 시스템 서비스 실행을 구분해 진단하세요. 전자는 사용자 세션에 의존하고, 후자는 네트워크가 준비되기 전에 시작될 수 있습니다. 수동 실행은 정상인데 서비스만 실패한다면 이미 확인된 구독을 수정하지 말고 실제 실행 사용자, 작업 디렉터리, 로그를 살펴보세요. 사용을 중단할 때는 환경 변수, 데스크톱 프록시, 서비스 시작 항목도 함께 해제해 백그라운드 프로세스가 새 클라이언트와 포트를 놓고 충돌하지 않도록 하세요.

설정 및 문제 해결

설정 관련 문제: 항목, 규칙, DNS, 연결 확인

설정 출처와 실제 적용 내용을 구분

클라이언트에 표시된 구독 원문이 코어가 실제로 읽는 최종 파일과 다를 수 있습니다. 원격 설정, 로컬 덮어쓰기, 인터페이스 설정, 자동 생성 항목이 병합된 뒤 적용될 수 있습니다. ‘파일을 수정했는데 동작이 바뀌지 않는다’면 클라이언트의 실행 설정이나 코어 로그에서 현재 설정 이름, 불러오기 결과, 최종 항목을 확인하세요. 원본 구독, 캐시 파일, 인터페이스 스위치를 동시에 수정하면 어떤 값이 다른 값을 덮어썼는지 파악하기 어렵습니다.

YAML은 들여쓰기와 자료형에 민감합니다. 탭 대신 공백을 사용하고 같은 계층의 항목은 같은 간격으로 들여쓰세요. 목록 항목이 어떤 필드에 속하는지는 상위 구조를 기준으로 확인해야 합니다. 오류가 표시된 줄은 파서가 멈춘 위치일 뿐 실제 원인은 이전 줄의 따옴표, 콜론, 들여쓰기일 수 있습니다. 마지막으로 정상 작동했던 파일로 되돌린 뒤 변경 사항을 한 부분씩 다시 적용하세요. 응답 및 형식 문제는 구독 업데이트 실패 및 설정 파싱 오류에서 더 확인할 수 있습니다.

규칙 순서와 아웃바운드 모드

규칙은 보통 위에서 아래로 확인하며 일치하면 해당 정책을 적용합니다. 특정 도메인 규칙은 일반적인 규칙보다 앞에 두고, 최종 대체 규칙은 끝에 배치하세요. 규칙에서 참조하는 정책 그룹이 실제로 존재하는지, 이름이 정확히 일치하는지도 확인해야 합니다. 아래는 구조 설명을 위한 직접 연결 진단 설정입니다. 원격 프록시가 포함되어 있지 않아 불러온 뒤에는 일치하는 요청도 모두 직접 연결됩니다. 실제 사용 시에는 서비스 제공자의 프록시와 정책 그룹을 유지하고 코어 문서에 따라 규칙을 병합하세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

전역 모드는 짧은 비교 테스트에 적합하지만 올바른 규칙을 대신할 수는 없습니다. 규칙 모드는 실패하고 전역 모드는 성공한다면 클라이언트 불안정으로 단정하지 말고 적용된 규칙, 정책 그룹, 규칙 세트를 확인하세요. 직접 연결 모드도 시스템 프록시가 꺼졌다는 뜻은 아닙니다. 앱이 먼저 로컬 진입점에 연결한 뒤 코어에서 직접 연결할 수 있습니다. 원래 네트워크를 확인하려면 아웃바운드 모드만 직접 연결로 바꾸지 말고 트래픽 처리를 명시적으로 끄세요.

DNS와 TUN 점검 범위

DNS는 도메인을 주소로 변환하고 프록시는 이후 연결을 담당하므로 두 기능이 서로 다른 위치에서 실행될 수 있습니다. TUN을 켜면 라우팅과 이름 조회 경로가 바뀔 수 있습니다. 설정의 DNS 스위치, 시스템 이름 조회 서비스, 클라이언트 덮어쓰기를 함께 확인하세요. 다른 기기의 fake-ip 주소 범위, 제외 목록, 상위 DNS 서버를 그대로 복사하지 마세요. 현재 네트워크와 코어 기능, 실제 요구 사항에 맞아야 합니다. 설정이 맞지 않으면 특정 도메인에서만 문제가 생길 수 있습니다.

기본 네트워크가 정상인지 확인한 다음 코어 수신 상태, 요청 전달, 도메인 조회, 규칙 적용, 원격 아웃바운드 순으로 점검하세요. 도메인은 실패하지만 이미 알고 있는 주소로는 연결된다면 이름 조회 경로를 확인해야 합니다. 그렇더라도 인증서 문제나 도메인 기반 서버 라우팅을 배제할 수는 없습니다. 브라우저의 암호화 DNS가 예상한 경로를 우회할 수도 있으므로 진단 중에는 해당 설정 상태를 기록하고 한 번에 한 항목만 바꿔 결과를 비교하세요.

지연 시간, 속도 테스트, 인터넷 연결 실패 판단

노드 지연 시간 테스트는 특정 대상, 프로토콜, 시점의 결과만 보여줍니다. 테스트 시간이 초과됐다고 모든 서비스에 연결할 수 없는 것은 아니며, 지연 시간이 낮다고 대용량 전송 속도도 빠르다고 보장할 수 없습니다. 먼저 테스트 주소와 방식을 확인한 다음 실제 대상에 요청을 보내 검증하세요. 정책 그룹에 자동 선택 기능이 있다면 목록의 특정 테스트 결과를 실제 연결 경로로 오해하지 말고 현재 적용된 아웃바운드를 확인하세요.

속도 테스트 결과는 로컬 대역폭, Wi-Fi 신호, 원격 서버 제한, 동시 작업, 테스트 사이트의 영향을 받습니다. 비교할 때는 네트워크, 시간대, 대상을 가능한 한 같게 하고 대용량 작업을 중지한 뒤 사용한 아웃바운드를 기록하세요. 한 번의 테스트에서 클라이언트, DNS, 규칙 모드를 함께 바꾸지 마세요. 특정 앱에서만 속도가 느리다면 모든 노드를 반복해서 새로 고치기보다 해당 앱의 연결 기록과 프로토콜을 먼저 확인하세요.

Clash에서 인터넷에 연결할 수 없다면 먼저 트래픽 처리를 끄고 직접 연결이 되는지 확인한 다음 현재 설정이 적용됐는지, 진입 포트가 수신 중인지, 정책 그룹에 사용 가능한 항목이 있는지 확인하세요. 이후 오류가 이름 조회 실패, 연결 시간 초과, 인증 실패, 연결 거부 중 무엇인지 살펴보세요. 도움을 요청할 때는 플랫폼, 클라이언트 이름, 트래픽 처리 방식, 오류 메시지, 이미 확인한 항목을 함께 제공하고 민감 정보는 삭제하세요. 증상에 따라 FAQ를 확인하거나 빠른 시작 가이드로 돌아가 최소 연결 확인 절차를 다시 진행할 수 있습니다.