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

공통 준비: 플랫폼, 설정, 트래픽 처리 방식 확인

클라이언트·코어·구독 구분하기

클라이언트는 설정 목록, 프록시 전환, 로그 화면을 제공하고, 코어는 설정을 해석해 규칙에 따라 연결을 구성합니다. 구독은 서비스 제공자가 설정이나 노드 정보를 전달하는 경로입니다. 클라이언트를 설치해도 사용할 수 있는 노드가 자동으로 생기지는 않습니다. 시작하기 전에 사용 권한이 있는 구독 URL이나 로컬 설정 파일을 준비하고, 선택한 클라이언트에서 지원하는 형식인지 확인하세요. 계정 로그인·결제 페이지나 브라우저 주소창의 관리 페이지 URL을 구독 링크로 사용하면 안 됩니다.

mihomo는 프록시 코어이며 특정 그래픽 클라이언트를 뜻하지 않습니다. mihomo를 사용하는 클라이언트도 설정 병합 방식, 권한 관리, 업데이트 방식이 서로 다를 수 있습니다. 이 페이지에서는 Windows, macOS, Android, iOS에 Clash Plus를 우선 추천하고, Linux 데스크톱에서는 Clash Verge Rev를 먼저 살펴보도록 안내합니다. 플랫폼에 맞는 도구를 고른 뒤 설정 형식을 확인해 이름이 비슷한 제품의 서로 다른 형식을 섞어 쓰지 않도록 하세요.

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

Windows에서는 ‘설정 → 시스템 → 시스템 정보’에서 시스템 종류를 확인하세요. Mac에서는 ‘이 Mac에 관하여’에서 칩 또는 프로세서를 확인합니다. Android는 기기 정보를 확인하고 다운로드 페이지의 아키텍처 안내에 맞춰 설치 파일을 선택하세요. Linux에서는 uname -m을 실행해 아키텍처를 확인할 수 있습니다. 일반적으로 x86_64는 AMD64, aarch64는 ARM64에 해당합니다. 아키텍처가 맞지 않으면 프로그램이 실행되지 않을 수 있으며, 설정을 반복해서 재설치해도 해결되지 않습니다.

설치 파일의 최소 시스템 요구 사항, 사용 가능한 디스크 공간, 계정 권한도 확인하세요. 그래픽 클라이언트, 보조 서비스, 코어마다 호환 범위가 다를 수 있으므로 다운로드 페이지와 프로젝트 안내를 우선 참고하세요. 조직에서 관리하는 기기라면 프록시 변경, 서비스 설치, 가상 네트워크 어댑터 생성이 허용되는지 먼저 확인해야 합니다. 관리 정책을 우회하려고 시스템 프로파일을 삭제하거나 출처가 불분명한 보안 구성 요소를 비활성화하지 마세요.

구독과 로컬 YAML 구분하기

URL 구독은 클라이언트가 주기적으로 요청하는 주소입니다. YAML은 들여쓰기로 항목의 계층을 표현하는 구조화된 설정 파일 형식입니다. Base64는 텍스트 인코딩 방식일 뿐, 그 자체가 완전한 Clash 설정을 의미하지 않습니다. 어떤 주소는 완전한 YAML을 반환하지만, 다른 주소는 노드 문자열만 반환합니다. 가져오기 오류가 나면 코어를 바꾸기 전에 먼저 형식을 확인하세요. 자세한 내용은 구독 링크와 가져오기 형식 안내를 참고하세요.

구독 URL에는 접근 자격 증명이 포함되는 경우가 많으므로 비밀번호처럼 관리하세요. 복사할 때 전체 쿼리 매개변수를 유지하고 따옴표, 공백, 줄바꿈을 추가하지 마세요. 도움을 요청할 때는 도메인 외의 민감한 경로와 매개변수를 가리고, 스크린샷에 QR 코드, 노드 비밀번호, 제어 인터페이스 정보가 보이지 않는지도 확인하세요. 실제 주소를 낯선 변환 사이트에 붙여 넣지 마세요. 변환이 꼭 필요하다면 서버 측에서 어떤 설정 정보에 접근하는지 먼저 확인하세요.

먼저 시스템 프록시를 사용하고, 필요할 때 TUN 검토하기

시스템 프록시는 운영체제 프록시 설정을 따르는 앱의 요청을 로컬 리스닝 포트로 전달하므로 브라우저 연결을 먼저 확인하기에 적합합니다. TUN은 가상 네트워크 인터페이스로, 라우팅 조건을 충족하는 더 많은 트래픽을 네트워크 계층에서 처리할 수 있습니다. 다만 우회 규칙, 앱 범위, 방화벽의 영향을 받으며 모든 트래픽이 자동으로 프록시를 통과하는 것은 아닙니다. 보통 추가 권한이 필요하고 다른 VPN이나 가상 네트워크 어댑터와 라우팅 충돌이 생기기 쉽습니다.

준비 단계에서는 다른 프록시 도구를 종료하고 기존 프록시와 DNS 설정을 기록한 뒤, 최소 구성으로 연결을 확인하세요. 규칙, 노드, DNS, 트래픽 처리 방식을 한꺼번에 바꾸면 문제가 생겼을 때 원인을 찾기 어렵습니다. 아래 내용은 로컬 리스닝 설정의 범위만 설명합니다. 사용 가능한 기존 설정에 적용해야 하며 원격 노드를 포함하지 않으므로 단독으로 프록시 연결을 제공하지 않습니다.

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

Windows: 클라이언트 설치와 로컬 프록시 확인

다운로드 후 첫 실행하기

Windows 설치 파일 목록을 열고 Clash Plus를 우선 선택하세요. 다른 선택지로 Clash Verge Rev, FlClash, Clash Nyanpasu가 있으며, Clash for Windows는 유지 관리가 중단된 상태입니다. 새 환경에서는 보관 상태인 클라이언트부터 선택하지 않는 편이 좋습니다. 이전 인터페이스, 코어 기능, 최신 설정 항목이 서로 맞지 않을 수 있습니다. 이전이 필요하다면 기존 설정을 복사해 보관하고, 작동 중인 환경을 먼저 삭제하지 마세요.

시스템 종류에 맞는 설치 파일을 선택해 로컬 디스크에 설치한 다음 시작 메뉴에서 실행하세요. 시스템에서 보안 경고가 표시되면 다운로드 경로, 게시자 정보, 파일 출처를 먼저 확인하고 보안 기능 전체를 바로 끄지 마세요. 첫 실행은 일반 권한으로 진행하세요. 보조 서비스 설치나 가상 네트워크 어댑터 변경처럼 명확히 필요한 작업에 한해 시스템 권한 창을 통해 권한을 높이면 됩니다. 회사 기기에서 실행이 차단되면 기기 관리자에게 먼저 문의하세요.

구독을 가져와 현재 설정으로 선택하기

클라이언트의 ‘설정’ 또는 ‘구독’ 페이지에서 URL 가져오기를 선택하고 전체 주소를 붙여 넣어 저장하세요. 가져오기가 성공하면 설정 목록에 항목이 추가됐는지 확인한 뒤 현재 설정으로 선택합니다. 목록에 구독이 있다고 해서 코어가 그 설정을 사용 중인 것은 아닙니다. 일부 클라이언트는 여러 설정을 저장할 수 있지만, 시작 시 적용되는 것은 현재 선택된 설정뿐입니다. 이어서 프록시 그룹 페이지를 열어 해당 설정에 정의된 그룹 이름이 표시되는지 확인하세요.

로컬 YAML을 가져올 때는 파일 가져오기 기능을 사용하고 원본 파일을 백업해 두세요. 파일 이름이 텍스트 편집기에서 추가한 확장자와 합쳐져 이중 확장자가 되지 않았는지 확인하고, 공백 들여쓰기 대신 탭을 사용하지 마세요. 구독을 업데이트하면 직접 수정한 내용이 덮어써질 수 있으므로 계속 유지해야 하는 로컬 규칙은 클라이언트가 지원하는 재정의 또는 병합 영역에 두세요. 업데이트할 때마다 먼저 오류 로그를 확인한 다음 이전 설정으로 되돌릴지 결정하세요.

시스템 프록시를 켜고 단계별로 확인하기

코어가 실행 중인지 확인한 다음 클라이언트의 시스템 프록시를 켜세요. Windows의 ‘설정 → 네트워크 및 인터넷 → 프록시’를 열고 클라이언트가 설정한 로컬 주소와 포트를 확인합니다. 포트는 클라이언트에 현재 표시된 값을 사용하세요. 안내서에 7890이 적혀 있다고 그대로 따라 하면 안 됩니다. 포트가 다른 프로그램에서 사용 중이면 충돌하는 프로그램을 종료하거나 리스닝 포트를 바꾸고, 프록시를 수동 설정한 앱도 모두 같은 값으로 업데이트하세요.

평소 직접 연결되는 웹사이트에 먼저 접속한 다음 프록시가 필요한 대상에 접속하면서 클라이언트 연결 기록을 확인하세요. 첫 번째 접속은 기본 네트워크 상태를, 두 번째 접속은 규칙과 프록시 출구를 확인하는 데 도움이 됩니다. 브라우저에서 접속된다고 PowerShell, 앱 스토어, 다른 앱의 트래픽까지 처리된다는 뜻은 아닙니다. 터미널에서 아래와 같은 일회성 요청으로 로컬 HTTP 프록시를 테스트할 수 있습니다. 포트는 현재 설정에 맞춰야 하며 이 테스트는 전역 환경 변수를 변경하지 않습니다.

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

TUN, UWP, 방화벽의 적용 범위

시스템 프록시를 따르지 않는 앱이 실제로 있을 때 TUN을 검토하세요. 클라이언트 안내에 따라 보조 서비스를 설치하거나 실행하고 시스템 권한을 승인한 뒤 가상 네트워크 어댑터를 통한 처리를 켭니다. 테스트 중에는 다른 VPN을 먼저 끄고 라우팅이 중복 처리되는지 확인하세요. 원격 근무용 터널, 가상 머신 네트워크 어댑터, 게임 가속 도구도 라우팅을 바꿀 수 있습니다. TUN을 켠 뒤 네트워크 전체에 문제가 생기면 DNS 변경을 계속 추가하지 말고 TUN을 끈 뒤 이미 확인한 시스템 프록시 방식으로 돌아가세요.

일부 UWP 앱은 루프백 격리 때문에 로컬 프록시에 접근하지 못할 수 있습니다. 특정 앱에서만 문제가 발생하는지 먼저 확인한 뒤, 클라이언트에 루프백 관리 기능이 있는지 살펴보고 필요한 앱에만 예외를 허용하세요. 모든 앱의 격리를 한꺼번에 해제하지 마세요. 방화벽에서 네트워크 접근을 허용할지 묻는 경우에는 로컬 연결과 LAN 공유를 구분해야 합니다. 로컬 기기에서만 사용하는 경우 같은 Wi-Fi에 연결된 다른 기기에 프록시 포트를 공개할 필요가 없는 경우가 많습니다.

절전 모드, 종료, 클라이언트 이전 문제 해결

절전 모드에서 깨어난 뒤 또는 네트워크를 바꾼 뒤 연결되지 않으면 코어가 계속 실행 중인지 확인한 다음 시스템 프록시를 껐다가 다시 켜세요. 일부 환경에서는 관리 정책이나 다른 소프트웨어가 프록시 설정을 다시 기록해 스위치는 켜져 있어도 시스템 주소가 바뀔 수 있습니다. 로그에 리스닝 실패가 표시되면 포트 충돌을 확인하세요. 연결은 만들어졌지만 대상이 시간 초과되면 노드와 규칙을 살펴보세요. 모든 문제를 Windows 권한 탓으로 돌리지는 마세요.

정상적으로 종료하기 전에 시스템 프록시와 TUN을 먼저 끄세요. 프로그램이 비정상 종료된 뒤 브라우저가 네트워크에 연결되지 않으면 시스템 프록시 설정에서 클라이언트가 남긴 수동 프록시 값을 지우고 직접 연결을 테스트하세요. 새 클라이언트로 옮길 때는 기존 클라이언트의 트래픽 처리와 자동 실행을 먼저 끄고 필요한 설정만 가져온 뒤 확인을 마치고 이전 프로그램을 제거하세요. 두 클라이언트가 로그인 후 같은 포트와 시스템 프록시 설정을 두고 충돌하지 않도록 하세요.

macOS: Applications로 옮긴 뒤 트래픽 처리 설정하기

칩에 맞는 앱을 선택해 설치하기

‘Apple 메뉴 → 이 Mac에 관하여’를 여세요. Apple 칩이 표시되면 Apple Silicon 또는 ARM64 설치 파일을, Intel 프로세서가 표시되면 Intel 또는 x64 설치 파일을 선택하세요. macOS 다운로드 항목에서 Clash Plus를 우선 설치하고 Clash Verge Rev, FlClash도 선택할 수 있습니다. ClashX Meta는 유지 관리가 중단되었습니다. 보관 용도로만 유지하고 사용 전 설정 호환성과 시스템 지원 범위를 확인하세요.

DMG 디스크 이미지를 열고 앱 아이콘을 Applications 폴더로 드래그한 뒤 복사가 끝나면 ‘응용 프로그램’ 폴더에서 실행하세요. 디스크 이미지에서 앱을 계속 실행하면 업데이트, 권한 기록, 경로 인식에 문제가 생길 수 있습니다. 복사가 끝나면 디스크 이미지를 추출해도 됩니다. 기존 앱을 교체할 때는 이전 프로세스를 종료하고 설정을 백업한 다음 시스템 안내에 따라 교체하세요.

처음 실행할 때 보안 안내가 표시되면 다운로드 출처와 안내 내용을 먼저 확인하세요. 앱을 신뢰할 수 있다고 확인한 경우에만 시스템 설정에서 제공하는 열기 허용 기능을 사용하세요. 격리 속성을 삭제하거나 시스템 보호를 비활성화하는 터미널 명령을 그대로 따라 하지 마세요. 보조 서비스 권한과 앱 최초 실행 승인은 별개의 작업입니다. 나중에 서비스를 설치할 때 관리자 인증이 다시 표시되면 승인 대상을 매번 확인하세요.

구독을 가져오고 프록시 그룹 선택하기

설정 페이지에서 URL 또는 로컬 파일 가져오기를 선택해 저장한 뒤 해당 항목을 현재 설정으로 지정하세요. 코어가 정상적으로 로드될 때까지 기다린 다음 프록시 그룹에서 노드를 선택합니다. 규칙 모드는 설정의 매칭 조건에 따라 직접 연결 또는 프록시를 선택합니다. 전역 모드는 보통 우회되지 않은 트래픽을 전역 정책 그룹으로 보내며 시스템 차원의 트래픽 처리를 대신하지 않습니다. 전역 모드로 바꿔도 연결 기록이 나타나지 않으면 앱 트래픽이 클라이언트에 들어오는지 먼저 확인하세요.

노드 테스트 결과만 보지 마세요. 테스트 대상, 프로토콜, 실제 앱 요청은 서로 다를 수 있으며 테스트 한 번에 성공했다고 모든 사이트에 접속할 수 있는 것은 아닙니다. 사용 가능한 노드 하나를 고정하고 같은 대상으로 반복 테스트한 뒤 자동 선택을 단계별로 복구하세요. 구독 업데이트는 실패했지만 기존 노드를 계속 사용할 수 있다면 현재 설정을 보존하고 구독을 가져오는 경로만 따로 점검하세요. 모든 노드와 정책 선택을 바로 지울 필요는 없습니다.

시스템 프록시와 네트워크 서비스 확인

클라이언트에서 시스템 프록시를 켠 뒤 ‘시스템 설정 → 네트워크’에서 현재 사용하는 네트워크 서비스를 선택하고 세부 정보의 프록시 설정을 확인하세요. macOS 버전에 따라 메뉴 이름이 조금씩 다를 수 있으므로 실제 연결된 서비스가 Wi-Fi, 이더넷 또는 다른 인터페이스인지 확인해야 합니다. 네트워크 인터페이스를 바꾼 뒤 클라이언트가 설정을 동기화하지 않았다면 메뉴 막대의 스위치만 보지 말고 시스템 프록시를 다시 전환한 뒤 현재 인터페이스를 확인하세요.

브라우저는 시스템 프록시를 확인하는 데 유용하지만 터미널 도구는 프록시 매개변수를 별도로 지정해야 할 수 있습니다. 아래 명령은 이번 요청에만 적용되며 리스닝 포트가 작동하는지 확인할 수 있습니다. 연결이 거부되면 코어와 포트를 확인하세요. 로컬 프록시에는 연결되지만 원격 연결이 시간 초과되면 프록시 그룹, 노드, 대상 규칙을 점검합니다. SOCKS를 사용할 때는 도메인을 로컬에서 조회하는지 프록시에 맡기는지도 구분해야 합니다.

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

보조 서비스 설치와 TUN 활성화

TUN은 가상 인터페이스, 라우팅, DNS 설정과 관련되므로 클라이언트에서 해당 기능을 지원해야 합니다. 화면 안내에 따라 보조 서비스를 설치하고 시스템 권한 안내를 확인한 다음 TUN을 켜세요. 일부 클라이언트는 일반 시스템 프록시에도 보조 구성 요소가 필요할 수 있습니다. ‘서비스 설치’를 ‘TUN 활성화’와 같은 뜻으로 보면 안 됩니다. 작업 후에는 권한 창이 닫혔는지만 보지 말고 현재 상태와 로그를 확인해 서비스가 작동하고 설정이 정상적으로 로드됐는지 확인하세요.

TUN을 켠 뒤 로컬 기기, 사내 네트워크, 원격 연결에 접근할 수 없으면 먼저 TUN을 꺼서 연결을 복구한 다음 사설 네트워크 우회와 라우팅 정책을 확인하세요. 시스템 라우팅 테이블을 바로 삭제하지 말고, 원격 관리 세션에서 전체 트래픽 처리를 처음 시험하지 마세요. 두 방식의 적용 범위를 더 알아보려면 macOS 시스템 프록시와 TUN 원리 비교를 참고한 뒤 장기 사용 여부를 결정하세요.

업데이트, 이전, 남은 설정 처리

앱 업데이트 후 권한에 문제가 생기면 앱을 완전히 종료했다가 다시 실행하고, 클라이언트 안내에 따라 보조 서비스를 업데이트해야 하는지 확인하세요. Apple 칩 기기에서 구형 아키텍처 프로그램이 실행되더라도 해당 설치 파일을 계속 사용할 필요는 없습니다. 네이티브 설치 파일은 호환성 계층 의존을 줄일 수 있지만 구체적인 기능은 클라이언트 구현에 따라 다릅니다. 이전할 때는 구독 출처, 로컬 재정의, 필요한 설정을 각각 백업하고 용도를 알 수 없는 캐시 디렉터리 전체를 복사하지 마세요.

앱을 제거하기 전에 시스템 프록시와 TUN을 끄고 클라이언트가 제공하는 서비스 제거 기능을 사용하세요. 앱을 휴지통으로 옮기는 것만으로 시스템 프록시가 복구되거나 별도 서비스가 제거되는 것은 아닙니다. 제거 후 네트워크에 연결되지 않으면 현재 네트워크 서비스의 프록시 페이지에서 남은 주소를 확인하고 기존 설정을 복구한 뒤 직접 연결을 테스트하세요. 계속 원인을 찾기 어렵다면 오류가 발생한 작업과 로그 시점을 기록하고 자주 묻는 질문에서 같은 증상을 찾아보세요.

Android: VPN 권한 승인과 백그라운드 실행 관리

설치 파일을 고르고 기존 설정 보존하기

Android 다운로드 항목에서 Clash Plus를 우선 선택하세요. 그 밖에 Clash Meta for Android, FlClash, Surfboard를 사용할 수 있습니다. 클라이언트마다 지원하는 설정 내용이 완전히 같지는 않습니다. 프록시를 지원한다는 이유만으로 전체 YAML을 서로 바꿔 쓸 수 있다고 가정하지 마세요. 구독 제공자가 지원하는 클라이언트와 형식을 확인한 뒤 기기 아키텍처에 맞는 설치 파일을 고르세요. 확실하지 않다면 기기 제조업체의 시스템 정보를 참고하세요.

APK를 설치할 때 Android에서 브라우저나 파일 관리자에 알 수 없는 앱 설치 권한을 요청할 수 있습니다. 실제로 사용할 출처에만 필요한 권한을 부여하고 설치가 끝난 뒤에는 권한을 끌 수 있습니다. 설치 중 충돌이 발생하면 같은 패키지 이름의 앱이 이미 있는지, 서명이 다른지 확인하세요. 로컬 설정이 함께 삭제될 수 있으므로 바로 앱을 제거하지 마세요. 출처를 바꿔 이전하기 전에 복구 가능한 정보를 내보내고 구독을 다시 가져올 수 있는지 확인하세요.

가져온 뒤 설정과 실행 상태 확인

클라이언트의 설정 페이지를 열고 클립보드, URL, 로컬 파일에서 설정을 가져오세요. 저장한 뒤 업데이트 결과를 확인하고 해당 설정을 현재 사용 항목으로 지정합니다. 시스템 공유 메뉴로 가져왔다면 클라이언트로 돌아와 새 항목이 실제로 추가됐는지 확인하세요. ‘공유 완료’가 ‘코어 로드 성공’을 뜻하지는 않습니다. 파싱 오류가 나면 로그에 표시된 필드나 줄 번호를 확인하세요. 브라우저에서 같은 주소가 열려도 설정 본문이 아니라 로그인 페이지가 반환될 수 있습니다.

처음 연결하기 전에 프록시 그룹 선택을 하나로 고정하고 규칙 모드를 유지해 비교하기 쉽게 하세요. 앱별 프록시 기능이 있다면 ‘선택한 앱만 프록시’인지 ‘선택한 앱 우회’인지 확인하세요. 두 설정의 의미는 서로 반대입니다. 활성화한 뒤 일부 앱만 프록시를 사용한다면 적용 범위와 관련된 경우가 많습니다. 연결 기록을 먼저 확인하고 노드가 작동하지 않는다고 바로 판단하지 마세요.

시스템 VPN 권한 이해하기

대부분의 Android 프록시 클라이언트는 시스템 VPN 서비스를 이용해 기기의 트래픽을 처리하며, 처음 실행하면 시스템 권한 대화상자가 표시됩니다. 권한을 요청하는 앱이 맞는지 확인한 뒤 연결을 허용하고 상태 표시줄이나 시스템 VPN 페이지를 살펴보세요. 여기서 VPN은 시스템이 제공하는 트래픽 처리 경로를 뜻하며, 원격 서비스가 전통적인 VPN 프로토콜을 사용한다는 의미는 아닙니다. 프록시 프로토콜, DNS, 규칙은 실제 설정에 따라 결정됩니다.

일반적으로 같은 사용자 공간에서 일반 VPN 앱 두 개가 동시에 트래픽을 처리할 수 없습니다. 광고 차단, 회사 네트워크 연결, 다른 네트워크 도구도 해당 경로를 사용할 수 있습니다. 앱을 실행하자마자 연결이 끊기면 다른 VPN을 중지하고 현재 클라이언트를 테스트하세요. 여러 앱을 번갈아 실행해 연결을 차지하게 하지 마세요. 기기에 VPN 항상 사용 또는 연결 끊김 시 차단이 설정되어 있다면 어느 앱을 대상으로 하는지도 확인하세요.

백그라운드 제한과 네트워크 전환 처리

화면을 잠근 뒤 연결이 끊기면 배터리 최적화, 백그라운드 활동, 제조업체의 자동 실행 관리 설정을 먼저 살펴보세요. 기기 설정에서 클라이언트의 필요한 백그라운드 실행을 허용하고 시스템에서 요구하는 상시 알림을 유지하세요. 제조업체마다 설정 이름이 다르므로 절전 설정을 한꺼번에 모두 끌 필요는 없습니다. 먼저 화면을 몇 분간 잠근 뒤 상태를 확인하고, 이후 더 긴 대기 시간도 시험해 프로세스 종료, 네트워크 절전, 원격 연결 시간 초과를 구분하세요.

Wi-Fi에서 모바일 네트워크로 전환하면 기존 연결을 다시 만들어야 할 수 있습니다. 네트워크가 연결될 때까지 기다리면서 코어 로그에 재연결이 나타나는지 확인하세요. 계속 실패하면 클라이언트 연결을 중지했다가 다시 시작합니다. 모바일 네트워크에서는 시스템이 해당 앱의 데이터 사용을 제한하는지, 구독 업데이트가 Wi-Fi에서만 실행되도록 설정됐는지도 확인하세요. 데이터 사용량은 시스템 또는 서비스 제공자의 과금 기준에 따릅니다. 클라이언트의 연결 상태로 요금제 잔여량을 확인할 수는 없습니다.

비공개 DNS, LAN, 종료 후 복구 확인

Android의 비공개 DNS, 앱 내부 암호화 DNS, 클라이언트의 DNS 처리는 서로 다른 경로로 작동할 수 있습니다. 로컬 리스닝은 정상인데 도메인이 열리지 않으면 비공개 DNS의 기존 값을 기록한 뒤 클라이언트 안내에 따라 한 가지 설정씩 테스트하세요. 암호화 DNS를 끄면 모든 문제가 해결된다고 단정하지 말고 실패한 대상, DNS 오류, 매칭 규칙을 확인한 뒤 필요한 설정을 복구하세요.

프린터, 화면 전송, 가정용 기기 검색에는 LAN 접근이 필요합니다. 프록시를 켠 뒤 기기가 검색되지 않으면 해당 사설 주소를 우회하는지, 클라이언트가 필요한 로컬 트래픽 처리를 지원하는지 확인하세요. 라우팅을 변경하기 전에 연결을 끄고 비교해 문제가 실제로 트래픽 처리 때문에 발생했는지 확인합니다. 클라이언트를 중지한 뒤에도 네트워크가 연결되지 않으면 시스템에서 VPN 연결 해제 시 차단을 켰는지 확인하고 정상 네트워크 설정을 복구하세요.

평소에는 먼저 클라이언트에서 구독을 새로고침한 다음 앱 업데이트가 필요한지 판단하세요. 로그를 내보내기 전에 구독 주소, 비밀번호, 접속 대상의 개인정보를 삭제하세요. 특정 앱이 계속 직접 연결되면 앱별 프록시 범위와 기존 연결을 확인하세요. 필요하다면 작업을 저장한 뒤 앱을 재시작하고 새 연결 기록을 살펴보세요.

iOS: Clash Plus 설치와 시스템 연결 설정

스토어에서 설치하고 앱 정보 확인

iPhone과 iPad에서는 Clash Plus를 우선 사용하세요. Clash Plus App Store 페이지를 열고 스토어에 표시된 안내에 따라 설치하세요. 제품 웹사이트는 clashplus.io입니다. 이 사이트의 iOS 다운로드 항목에서도 같은 스토어 페이지로 이동할 수 있습니다. 시스템 요구 사항과 현재 제공되는 기능은 스토어 및 앱 안내를 확인하세요. 다른 플랫폼의 화면을 보고 모바일 메뉴를 판단하지 마세요.

설치 전에 기기 저장 공간이 충분하고 스토어에 정상적으로 접속할 수 있는지 확인하세요. 조직에서 관리하는 기기는 VPN 설정이나 앱 설치가 제한될 수 있으므로 제한이 나타나면 관리 요구 사항을 먼저 살펴보세요. 연결을 강제로 설정하려고 조직에서 제공한 구성 프로파일을 삭제하지 마세요. 설치 후 앱을 열어 설정 가져오기 위치와 연결 스위치를 확인하고, 처음 연결을 테스트할 때는 여러 네트워크 도구를 함께 사용하지 마세요.

앱이 지원하는 형식으로 구독 가져오기

앱에서 구독 또는 설정 가져오기 메뉴를 찾아 서비스 제공자가 안내한 호환 주소를 붙여 넣은 뒤 가져오기나 업데이트를 실행하세요. QR 코드로 가져올 때는 신뢰할 수 있는 출처인지 확인하고 자격 증명이 포함된 화면을 다른 사람이 볼 수 있는 곳에 표시하지 마세요. 주소의 쿼리 매개변수를 빠뜨리지 마세요. 메신저에서 자동으로 추가하는 마침표, 공백, 줄바꿈 때문에 요청이 실패할 수도 있습니다.

가져온 뒤 선택 가능한 정책이나 노드가 표시되는지 확인하고 명확한 파싱 오류가 있는지도 살펴보세요. 데스크톱에서 사용 가능한 모든 YAML 항목이 모바일 앱에서도 같은 의미로 유지된다고 가정하지 마세요. 앱마다 자체 가져오기 및 변환 방식을 사용할 수 있습니다. 지원하지 않는 항목이 있다면 DNS, 규칙, 정책 그룹을 임의로 삭제하기보다 호환 설정을 제공받거나 앱 문서를 확인하세요. 겉으로는 로드되지만 동작이 달라진 설정이 남을 수 있습니다.

앱에서 설정을 선택할 수 있다면 방금 가져온 항목이 현재 활성화되어 있는지 확인하세요. 구독이 여러 개라면 용도를 구분할 수 있도록 이름을 지정해 오래된 설정을 현재 항목으로 잘못 선택하지 않도록 하세요. 업데이트가 실패해도 기존 항목은 보존하고 실패 원인과 서비스 계정 상태를 확인하세요. 기존 노드는 연결되지만 구독 업데이트가 되지 않는다면 설정을 가져오는 경로의 문제입니다. 시스템 VPN 설정을 반복해서 삭제하며 해결하려 하지 마세요.

시스템의 VPN 구성 추가 허용

처음 연결할 때 iOS에서 앱의 VPN 구성 추가를 허용하고 시스템 인증을 진행하라는 메시지가 표시될 수 있습니다. 앱 이름을 확인한 뒤 권한을 승인하고 앱으로 돌아와 상태를 확인하세요. 시스템 VPN 표시는 네트워크 확장이 실행 중이라는 뜻이지, 원격 노드에 대한 모든 연결이 성공했다는 뜻은 아닙니다. 대상에 접속해 보거나 앱 연결 기록과 오류 정보를 확인해야 합니다. 스위치 하나만 보고 설정이 끝났다고 판단하지 마세요.

모바일에서는 보통 시스템 네트워크 확장으로 트래픽을 처리하므로 데스크톱의 로컬 시스템 프록시 설정을 그대로 따라 하면 안 됩니다. ‘혹시 모르니’ Wi-Fi에 수동 프록시까지 설정하지 마세요. 모바일 네트워크에서는 해당 설정이 적용되지 않을 수 있고 프록시가 이중으로 설정될 수도 있습니다. 트래픽 처리 경로를 하나로 유지하고 먼저 Wi-Fi에서 연결을 확인한 다음 모바일 네트워크를 테스트하세요. LAN 프록시가 필요하다면 별도의 사용 사례로 설정하세요.

Wi-Fi, 모바일 네트워크, 로컬 접근을 각각 확인

먼저 안정적인 Wi-Fi에 연결해 평소 직접 접속되는 페이지를 연 다음 프록시가 필요한 대상에 접속하세요. 첫 번째는 정상인데 두 번째만 실패하면 정책 그룹, 노드, 매칭 규칙을 확인하세요. 둘 다 실패하면 클라이언트를 연결 해제해 기본 네트워크를 확인한 뒤 설정과 트래픽 처리 단계로 돌아가 점검합니다. 결과를 재현하기 쉽도록 테스트 중에는 대상과 노드를 고정하고 설정을 여러 개 연속으로 바꾸지 마세요.

이어서 모바일 네트워크로 전환하고 앱의 셀룰러 데이터 사용이 허용되어 있는지, 연결이 다시 설정되는지 확인하세요. 네트워크를 전환하면 기존 세션이 끊길 수 있으므로 이전 페이지가 그대로 보이는지만 확인하지 말고 페이지를 새로 여세요. 호텔, 학교 등의 인증이 필요한 Wi-Fi를 사용할 때는 프록시를 잠시 중지하고 네트워크 로그인을 완료한 다음 연결을 시작하세요. 인증이 끝나지 않았다면 노드나 DNS 오류는 상위 네트워크에서 아직 접속을 허용하지 않았기 때문일 수 있습니다.

프린터, 라우터 관리 페이지, 다른 로컬 기기에 접근할 때는 클라이언트에 로컬 네트워크 권한이 필요한지, 규칙에서 해당 직접 연결 경로를 유지하는지 확인하세요. 시스템의 개인정보 보호 네트워크 기능, 다른 VPN, 관리 정책도 접근에 영향을 줄 수 있습니다. 개인정보 보호 설정을 모두 장기간 끄지 말고 하나씩 일시 중지해 테스트하세요. 테스트마다 기존 값을 기록하고 원인을 확인한 뒤 필요한 항목만 바꾸세요.

자동 연결과 설정 복구 관리

앱에서 필요 시 연결이나 자동 복구를 지원한다면 수동 연결이 안정된 뒤 켜고 화면 잠금, 깨우기, 네트워크 전환을 각각 테스트하세요. 앱이 포그라운드에서 종료되는 것과 네트워크 확장이 중지되는 것은 같은 현상이 아닙니다. 시스템 VPN 페이지와 실제 접속 결과를 함께 확인하세요. Android의 백그라운드 허용 목록 설정을 그대로 적용하지 마세요. iOS는 권한과 앱 생명주기 방식이 다르고 앱에서 제공하는 옵션도 서로 다릅니다.

사용을 중지할 때는 먼저 앱에서 연결을 끊으세요. VPN 구성을 제거해야 한다면 시스템 설정의 VPN 관리 메뉴에서 진행합니다. 시스템 구성을 제거해도 서비스 구독이 취소되거나 앱의 구독 데이터가 함께 삭제되는 것은 아니므로 각각 확인해야 합니다. 앱을 재설치하기 전에 복구 가능한 설정 출처를 백업하고 서비스 계정에 다시 로그인할 수 있는지 확인하세요. 도움을 요청할 때는 기기 시스템, 네트워크 종류, 실패 단계만 설명하고 구독 QR 코드 전체를 공개하지 마세요.

Linux: 데스크톱 설치와 systemd 코어 실행

그래픽 클라이언트와 독립 코어 중 선택하기

데스크톱 사용자는 Linux 다운로드 항목을 먼저 확인하세요. Clash Verge Rev를 권장하며 FlClash도 선택할 수 있습니다. 배포판에 맞는 DEB 또는 RPM을 선택하고 패키지 아키텍처가 시스템과 일치하는지 확인하세요. 그래픽 세션이 없는 서버에 데스크톱 클라이언트를 설치해도 시스템 트레이 창은 나타나지 않습니다. 서버, 라우터, 스크립트 관리 환경에서는 독립 코어인 mihomo를 사용할 수 있지만 설정, 권한, 서비스 실행 주기를 직접 관리해야 합니다.

데스크톱 패키지를 설치할 때는 배포판의 패키지 관리자로 의존성을 처리하세요. 런타임 라이브러리가 없다는 오류가 나오면 패키지 관리자의 출력을 먼저 읽고, 출처를 알 수 없는 공유 라이브러리를 무작위로 내려받아 시스템 디렉터리에 덮어쓰지 마세요. 실행 후 시스템 트레이, 설정 저장 위치, 시스템 프록시 기능이 현재 데스크톱 환경과 호환되는지 확인하세요. GNOME, KDE 등은 프록시 설정 메뉴가 다르며 명령줄 프로그램은 데스크톱 프록시를 읽지 않을 수 있습니다. 따라서 그래픽 스위치만으로 모든 프로세스가 처리된다고 볼 수 없습니다.

설정을 가져오고 리스닝 포트 테스트하기

그래픽 클라이언트에서는 설정 페이지를 통해 구독을 가져와 선택한 뒤 시스템 프록시를 켜세요. 독립 코어에는 실제 사용할 수 있는 프록시와 규칙을 포함한 완전한 YAML이 필요합니다. 아래 명령은 아키텍처에 맞는 실행 파일을 /usr/local/bin/mihomo에 설치하고 사용 가능한 설정을 지정된 경로에 저장했다고 가정합니다. 명령은 설정만 확인하며 노드를 가져오거나 시스템 서비스를 설치하지 않습니다.

/usr/local/bin/mihomo -t -f /etc/mihomo/config.yaml

검사에 성공하면 먼저 포그라운드에서 실행해 설정, 규칙 파일, 필수 데이터베이스를 읽을 수 있는지 확인한 뒤 다른 터미널에서 프록시 요청을 보내세요. 작업 디렉터리에 필요한 읽기·쓰기 권한이 있어야 합니다. 상대 경로를 사용하는 설정이라면 데이터 디렉터리도 확인하세요. 프로덕션 서버에서 처음부터 전체 라우팅 처리를 켜지 마세요. 특히 기본 경로를 변경할 수 있는 설정을 유일한 SSH 세션에서 시험하지 마세요.

/usr/local/bin/mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml
# 다른 터미널에서 실행하세요. 포트는 실제 설정에 맞추세요
curl --proxy http://127.0.0.1:7890 --head https://example.com

일반 사용자 계정으로 systemd 서비스 만들기

항상 실행해야 한다면 먼저 전용 서비스 계정과 데이터 디렉터리를 만들고, 검증된 설정을 설정 디렉터리에 저장하세요. 아래 예시는 일반 HTTP 및 SOCKS 리스닝을 대상으로 하며 TUN에 필요한 네트워크 관리 권한은 부여하지 않습니다. systemd를 사용하는 일반적인 배포판 기준의 명령으로 관리자가 실행해야 합니다. 계정이나 디렉터리가 이미 있다면 현재 상태를 확인하고 기존 설정과 권한을 무작정 덮어쓰지 마세요.

sudo useradd --system --home-dir /var/lib/mihomo --shell /usr/sbin/nologin mihomo
sudo install -d -o mihomo -g mihomo -m 750 /var/lib/mihomo
sudo install -d -o root -g mihomo -m 750 /etc/mihomo
sudo chown root:mihomo /etc/mihomo/config.yaml
sudo chmod 640 /etc/mihomo/config.yaml

다음 내용을 /etc/systemd/system/mihomo.service로 저장하세요. 설정 파일과 실행 파일이 이미 준비되어 있어야 합니다. 설정에서 사용하는 다른 로컬 파일도 서비스 계정이 읽을 수 있어야 하며 데이터 디렉터리에는 쓰기 권한이 필요합니다. 코어 전체를 계속 관리자 권한으로 실행하기보다 일반 계정의 로컬 프록시 서비스부터 시작하면 파일 권한 문제와 네트워크 권한 문제를 구분하기 쉽습니다.

[Unit]
Description=Mihomo local proxy
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
WorkingDirectory=/var/lib/mihomo
ExecStart=/usr/local/bin/mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
UMask=0077

[Install]
WantedBy=multi-user.target

로그를 확인한 뒤 부팅 시 자동 실행 설정

먼저 서비스 정의를 다시 불러오고 서비스를 시작한 다음 상태와 로그를 확인하세요. 리스닝, 프록시 요청, 설정 로드가 모두 정상인지 확인한 후 부팅 시 자동 실행을 설정합니다. 포그라운드 테스트 프로세스가 실행 중이면 먼저 종료해야 서비스와 포트가 충돌하지 않습니다. 서비스가 종료되면 마지막 재시작 안내보다 로그에 처음 표시된 명확한 오류가 더 중요할 수 있습니다. 설정 경로, 권한, 포트 점유, 누락된 파일부터 확인하세요.

sudo systemctl daemon-reload
sudo systemctl start mihomo
systemctl status mihomo --no-pager
journalctl -u mihomo -b -n 80 --no-pager
sudo systemctl enable mihomo

네트워크 온라인 대상은 서비스 시작 순서를 지정할 뿐, 구독 사이트나 원격 노드에 접속할 수 있음을 보장하지 않습니다. 설정을 업데이트하기 전에 기존 파일을 저장하고 설정 검사를 실행하세요. 검사를 통과한 뒤 서비스를 다시 시작합니다. 새 설정이 작동하지 않으면 이전 파일을 복구한 뒤 재시작하고, 설정을 계속 바꾸면서 서비스가 반복적으로 재시작되게 두지 마세요. 더 자세한 절차는 Linux 데스크톱 및 systemd 배포 노트를 참고하세요.

TUN 권한과 서비스 공개 범위 설정

Linux에서 TUN을 사용하려면 장치 노드, 네트워크 관리 권한, 라우팅, DNS도 고려해야 합니다. 위의 일반 사용자 서비스에는 이러한 권한이 설정되어 있지 않으므로 tun.enable만 켠다고 배포가 완료되는 것은 아닙니다. 배포판, 커널 환경, mihomo 문서를 바탕으로 최소 권한 방식을 마련하세요. 컨테이너에서는 호스트의 권한 설정도 고려해야 합니다. 원격 환경에서는 트래픽 처리를 시험하기 전에 콘솔 등 복구 경로를 준비하세요.

로컬에서만 사용할 때는 프록시와 제어 인터페이스를 루프백 주소에 바인딩하세요. 패널 연결을 위해 모든 네트워크 인터페이스에서 리스닝하도록 설정하지 마세요. LAN 공유가 꼭 필요하다면 접근 가능한 네트워크 범위를 제한하고 인증과 방화벽을 설정하세요. 제어 인터페이스는 별도로 보호해야 합니다. 독립 코어를 중지해도 수동으로 설정한 프록시 환경 변수와 라우팅은 자동으로 복구되지 않습니다. 종료할 때 기존 설정으로 되돌리고 직접 연결 요청으로 네트워크 상태를 확인하세요.

설정 및 문제 해결: 실패 단계별 확인

먼저 문제 범위 파악하기

플랫폼, 클라이언트 이름, 트래픽 처리 방식, 오류 발생 시각을 기록한 다음 기본 네트워크, 구독 가져오기, 설정 파싱, 코어 실행, 트래픽 처리, 규칙 선택, 원격 연결 중 어느 단계의 문제인지 판단하세요. 클라이언트를 끈 뒤 일반 웹사이트에도 연결되지 않는다면 노드를 바꾸지 말고 네트워크 로그인, 게이트웨이, 시스템 프록시부터 복구하세요. 기존 설정은 계속 사용할 수 있는데 구독 업데이트만 실패한다면 구독 주소와 서비스 계정 상태를 먼저 확인하세요.

한 번에 변수 하나만 바꾸고 같은 네트워크, 같은 대상, 같은 노드로 다시 테스트하세요. 가장 최근에 정상 작동한 설정을 보존하고 변경 사항과 결과를 로컬 메모에 기록합니다. 로그 시각과 시스템 시각이 다르면 과거 오류를 현재 원인으로 오해하기 쉽습니다. 일시적으로 로그 상세도를 높였더라도 점검이 끝나면 평소 수준으로 되돌리세요. 접속 대상이 포함된 기록이 계속 쌓일 수 있습니다.

구독 오류와 YAML 파싱 오류를 구분해 처리

업데이트가 실패하면 주소가 완전한지, 자격 증명이 만료됐는지, 서비스 제공자가 특정 구독 형식을 요구하는지 먼저 확인하세요. 요청 결과가 로그인 페이지, 접근 제한 페이지, 노드 문자열이면 클라이언트에서 파싱 오류가 발생할 수 있습니다. 브라우저에 내용이 표시된다는 이유만으로 형식이 올바르다고 판단하지 마세요. 일부 클라이언트는 구독 업데이트에 직접 연결 또는 프록시 경로를 별도로 지정할 수 있습니다. 기존 프록시가 작동하는지 확인한 뒤 테스트하세요. 작동하지 않는 설정을 사용해 그 설정 자체를 업데이트하지 않도록 주의하세요.

YAML 줄 번호 오류가 표시되면 해당 줄과 앞뒤 항목의 들여쓰기, 콜론, 따옴표를 확인하세요. 한 항목의 오류가 다음 줄에서야 보고될 수 있습니다. 코드 예시의 일부를 완성된 설정 끝에 바로 붙여 넣어 최상위 키를 중복시키지 마세요. 아래는 규칙 구조 예시입니다. PROXY는 전체 설정에 실제로 정의된 프록시 또는 정책 그룹이어야 합니다. 이름만 복사하고 대상을 정의하지 않으면 안 됩니다.

rules:
  - DOMAIN-SUFFIX,apple.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,PROXY

규칙은 보통 순서대로 매칭되며 규칙에 일치하면 해당 정책을 사용합니다. 따라서 구체적인 조건은 기본 규칙보다 앞에 두세요. 로컬 재정의가 순서를 바꾸지 않았는지, 구독 업데이트가 직접 수정한 내용을 덮어쓰지 않았는지도 확인하세요. 설정을 파싱할 수 있다는 것은 구조를 읽을 수 있다는 뜻일 뿐, 모든 노드가 사용 가능하거나 규칙이 예상대로 동작한다는 뜻은 아닙니다.

연결 기록에 따라 다음 점검 항목 결정

앱에서 요청을 보냈는데 연결 기록이 전혀 없다면 시스템 프록시, TUN, 앱 자체의 프록시 설정부터 확인하세요. 기록은 있지만 출구가 잘못되면 매칭 규칙과 정책 그룹을 점검합니다. 규칙은 맞지만 연결되지 않으면 노드, 프로토콜 지원, 원격 접속 가능 여부를 확인하세요. 규칙 모드와 시스템 프록시를 하나의 스위치처럼 생각하지 마세요. 규칙 모드는 트래픽이 코어에 들어온 뒤 어떻게 분배할지 결정하고, 시스템 프록시는 일부 앱의 트래픽이 코어로 들어가는 경로를 결정합니다.

‘연결 거부’는 보통 대상 포트에서 서비스가 실행 중이지 않거나 연결을 거부했다는 뜻입니다. ‘시간 초과’는 제한 시간 안에 작업을 마치지 못했다는 뜻일 뿐, 노드가 차단됐다고 단정할 수 없습니다. 오류 문구 하나만 보는 것보다 로컬 리스닝, 원격 핸드셰이크, 대상 응답 중 어느 단계에서 발생했는지 확인하는 편이 유용합니다. 오류를 공유할 때는 필요한 맥락을 남기되 자격 증명과 개인적인 접속 대상은 삭제하세요.

DNS, IPv6, UDP는 각각 따로 확인

DNS는 도메인을 IP 주소로 변환합니다. 브라우저의 암호화 DNS, 시스템 리졸버, 코어 DNS가 서로 다른 경로를 사용할 수 있으므로 DNS 서버 하나만 바꾼다고 모든 요청이 바뀌는 것은 아닙니다. Fake-IP는 도메인을 가상 주소에 연결한 뒤 코어가 이를 처리하는 방식입니다. 트래픽이 코어를 우회하면서 가상 주소를 사용하면 접속 문제가 생길 수 있습니다. 활성화하기 전에 트래픽 처리 경로가 완전한지 확인하고 앱 호환성에 맞게 예외를 설정하세요.

IPv6 사용 가능 여부는 로컬 네트워크, 노드, 설정에 따라 다릅니다. IPv6 비활성화는 기록을 남기고 비교하는 테스트로만 사용하고 고정된 해결책으로 삼지 마세요. UDP는 앱, 트래픽 처리 방식, 노드, 프로토콜이 모두 지원해야 합니다. 브라우저 웹페이지가 열린다고 게임이나 실시간 통신도 정상이라는 뜻은 아닙니다. 도메인 대신 IP 주소로 HTTPS에 접속한 결과로 도메인 접속을 판단하지 마세요. 인증서 검증과 사이트 선택은 도메인에 따라 달라질 수 있습니다.

업데이트, 되돌리기, 네트워크 복구

업데이트 전에 구독 출처, 로컬 재정의, 현재 설정을 각각 백업하세요. 앱, 코어, 설정은 가능하면 한 번에 하나씩 업데이트하고 확인을 마친 뒤 다음 항목으로 넘어갑니다. 보관 상태인 클라이언트는 최신 설정 항목을 인식하지 못할 수 있으므로 이전할 때는 계속 유지 관리되는 클라이언트를 우선 선택하고 필요한 설정을 단계별로 복구하세요. 오래된 캐시, 보조 서비스, 새 클라이언트 파일을 모두 한꺼번에 복사한 뒤 문제 원인을 추측하지 마세요.

네트워크를 복구할 때는 설정을 역순으로 되돌리세요. TUN 또는 시스템 VPN을 중지하고 시스템 프록시를 끈 다음 수동으로 변경한 DNS, 앱 프록시, 터미널 환경 변수를 복구하고 직접 연결을 확인합니다. 앱을 제거해야 한다면 먼저 클라이언트가 제공하는 서비스 정리 절차를 실행하세요. 그래도 해결되지 않으면 민감한 정보를 제거한 로그를 준비해 자주 묻는 질문에서 같은 증상을 찾아보세요. 연결 순서만 기억나지 않는다면 빠른 시작 가이드로 돌아가 최소 연결을 다시 설정하면 됩니다.