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

01 / PREPARATION

공통 준비 사항: 클라이언트, 구독 및 연결 방식

인터페이스, 코어, 서비스를 구분하세요

Clash 생태계에서 그래픽 클라이언트는 설정 목록과 정책 그룹 선택, 시스템 연결을 담당하고 코어는 설정을 해석해 규칙을 적용하고 연결을 구성합니다. mihomo는 널리 쓰이는 코어지만, 클라이언트마다 지원 기능과 설정 위치가 다릅니다. 클라이언트만 설치한다고 사용할 노드나 프록시 서비스가 생기는 것은 아닙니다. 시작하기 전에 서비스 제공업체가 발급한 구독 URL 또는 유효한 노드·정책 그룹·규칙이 포함된 전체 설정 파일을 준비하고, 계정 상태와 기기 수 제한도 확인하세요.

데스크톱과 Android에서는 우선 다운로드 페이지에서 Clash Plus를 선택하세요. 이미 안정적인 사용 환경이 있다면 운영체제에 맞춰 Clash Verge Rev, FlClash 등의 클라이언트도 비교할 수 있습니다. Linux 그래픽 환경에서는 Clash Verge Rev 또는 FlClash를 선택하세요. 설정을 다른 클라이언트에서 재사용할 수 있는지는 구독 형식, 프로토콜 지원 여부, 실제 코어에 따라 달라집니다. 이름이 비슷하다는 이유만으로 호환된다고 판단하지 마세요. 보관용 클라이언트는 기존 환경을 유지할 때 적합하며 새 기기의 기본 설치 경로로는 권장하지 않습니다. 자세한 목록은 클라이언트 선택 가이드를 참고하세요.

기기 아키텍처와 구독 내용 확인

다운로드 전에 운영체제와 프로세서 아키텍처를 확인하세요. 데스크톱에서는 x64와 ARM64를 주로 사용하며, macOS에서는 Intel과 Apple Silicon용 설치 파일이 나뉩니다. 설치 파일 실행 여부는 먼저 운영체제, 아키텍처, 최소 시스템 요구 사항에 따라 결정되며 구독 유효성과는 관계가 없습니다. 프로그램이 열리지 않는다고 구독을 계속 바꾸거나 모바일 앱 설치 파일을 데스크톱에 사용하지 마세요. 다운로드 페이지의 플랫폼과 시스템 요구 사항을 기기 정보와 하나씩 대조하세요.

구독 URL은 계정 접근 정보와 같은 역할을 하는 경우가 많습니다. 붙여넣을 때 전체 쿼리 매개변수를 유지하고 앞뒤 공백이나 메신저가 덧붙인 문장부호는 제거하세요. 서비스 제공업체가 준 것이 Clash YAML 구독인지, 단일 노드 링크인지, 브라우저 로그인용 관리 페이지인지 먼저 확인해야 합니다. 완전한 YAML에는 보통 노드 또는 프록시 제공자, 정책 그룹, 규칙이 포함됩니다. 인코딩된 문자열만 있다고 해서 현재 가져오기 메뉴에서 바로 인식되는 것은 아닙니다. 변환이 필요하다면 서비스 제공업체의 호환 URL을 우선 사용하고, 자세한 내용은 구독 형식 및 변환 안내를 확인하세요.

되돌릴 수 있는 최소 구성부터 시작하세요

처음에는 프록시 클라이언트 하나와 연결 방식 하나만 사용하세요. 규칙 모드에서 정책 그룹 하나를 직접 선택하고, 사용할 수 있는 노드 하나로 웹 페이지 접속을 확인한 다음 TUN, 오버라이드, 규칙 제공자, 복잡한 DNS 설정을 차례로 추가하세요. 시스템 프록시와 TUN을 반드시 동시에 켜야 하는 것은 아닙니다. 두 방식을 함께 사용하면 점검해야 할 항목이 늘어날 수 있습니다. 휴대폰은 대개 시스템 VPN 기능으로 터널을 구성하므로 데스크톱과 동일한 이름의 스위치가 있는 것은 아닙니다.

아래 예시는 흔히 쓰이는 필드를 이해하기 위한 것이며 원격 노드는 포함하지 않습니다. 서비스 제공업체의 구독을 대신할 수 없습니다. 혼합 포트는 HTTP와 SOCKS 요청을 모두 받을 수 있으며, 루프백 주소에만 바인딩하면 기기 외부에서의 접근을 제한할 수 있습니다. 예시 포트가 모든 클라이언트의 기본값은 아니므로 실제 포트는 현재 설정에서 확인하세요. 그래픽 클라이언트가 해당 필드를 자동 생성할 수 있으며, 생성된 파일을 직접 수정하면 다음 저장 때 변경 사항이 덮어써질 수 있습니다.

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

연결을 시작하기 전에 현재 시스템 프록시, DNS, 다른 VPN 상태를 기록하고 정상적으로 실행되는 설정 사본을 보관하세요. 테스트할 때는 ‘노드 연결 테스트 성공’, ‘요청이 프록시 규칙에 일치함’, ‘대상 웹 페이지가 정상적으로 열림’을 구분해야 합니다. 각각 서로 다른 단계를 확인합니다. 기본 연결을 확인한 뒤 실제로 사용할 앱을 테스트하세요. 대시보드의 지연 시간 결과 하나만으로 전체 네트워크가 정상이라고 판단하지 마세요.

02 / WINDOWS

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

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

Windows 다운로드에서 먼저 Clash Plus를 선택하세요. 기존 사용 환경에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu를 선택할 수도 있습니다. Clash for Windows는 개발이 중단된 보관용 클라이언트입니다. 설정에서 ‘시스템 > 정보’를 열어 시스템 종류를 확인하고, 아키텍처에 맞는 파일을 다운로드하세요. 기기 이름에 프로세서 브랜드가 포함되어 있다고 아키텍처를 단정하지 마세요. 설치 파일을 실행할 수 없다는 메시지가 나오면 시스템 요구 사항과 파일 유형부터 확인하세요.

설치 프로그램을 실행한 뒤 일반 사용자로 클라이언트를 시작하고 안내에 따라 설치 위치를 선택하세요. 시스템 서비스나 가상 네트워크 인터페이스가 필요하다면 클라이언트 설정에서 해당 기능을 설치한 후 시스템 권한 확인 절차를 진행하세요. 매번 화면을 열 때마다 관리자 권한으로 프로그램 전체를 실행할 필요는 없습니다. 처음 실행할 때 보안 소프트웨어가 차단하면 차단된 항목과 파일 출처를 확인하세요. 원인을 찾기 위해 시스템 보호 기능 전체를 끄지는 마세요.

구독을 가져오고 사용할 설정을 활성화하세요

‘프로필’, ‘구독’ 또는 비슷한 메뉴에서 원격 설정 추가를 선택하고 전체 URL을 입력한 뒤 다운로드하세요. 목록에 항목이 나타나도 해당 설정을 선택하거나 활성화해야 합니다. 다운로드가 완료됐다고 코어가 전환된 것은 아닙니다. 프록시 화면에서 정책 그룹과 그룹 내 노드가 표시되는지 확인하세요. 직접 연결만 보인다면 구독 내용과 가져오기 형식을 먼저 확인하고, 코어 로그에서 지원되지 않는 프로토콜이나 필드가 있는지 살펴보세요. 곧바로 시스템 라우팅을 바꾸지 마세요.

사용하려는 서비스에 해당하는 정책 그룹에서 노드를 직접 선택하세요. 설정에는 기본 프록시, 스트리밍, 다운로드 등 여러 그룹이 함께 있을 수 있으며 한 그룹을 변경해도 나머지 그룹까지 자동으로 바뀌지는 않습니다. 노드를 선택한 뒤 규칙 모드로 전환하고 실제 요청의 연결 기록에서 일치한 규칙과 최종 출구를 확인하세요. 지연 시간 테스트는 연결 실패 여부를 가려내는 데 도움이 되지만 웹 전송 속도나 앱 호환성을 보장하지는 않습니다. 노드 선택 방법은 노드 지연 시간·배수·지역 비교를 참고하세요.

시스템 프록시부터 확인한 뒤 TUN을 사용하세요

시스템 프록시를 켠 다음 Windows 프록시 설정에서 로컬 주소와 포트가 클라이언트 설정과 일치하는지 확인하세요. 자동 구성 스크립트를 쓰는 환경에서는 스크립트 주소도 확인해야 합니다. 서로 다른 연결 방식을 같은 설정으로 혼동하지 마세요. 브라우저는 대개 시스템 설정을 따르지만 터미널, 개발 도구, 자체 네트워크 스택을 사용하는 소프트웨어는 따르지 않을 수 있습니다. 특정 프로그램이 계속 직접 연결된다면 전체 규칙을 전역 프록시로 바꾸기 전에 해당 앱의 프록시 설정부터 확인하세요.

PowerShell에서 프록시를 명시한 요청을 보내면 시스템 설정의 영향을 분리해 확인할 수 있습니다. 아래 요청은 클라이언트가 같은 포트에서 실제로 수신 중일 때만 유효합니다. 로컬 HTTP 프록시 진입점과 이후 연결을 확인할 뿐, 모든 앱이 프록시를 통과한다는 뜻은 아닙니다. 프록시를 명시하면 연결되는데 브라우저에서 실패한다면 브라우저 확장 프로그램, 별도 프록시 설정, 캐시를 확인하세요. 로컬 포트 연결부터 실패한다면 코어 실행 상태, 수신 주소, 포트 충돌을 먼저 점검하세요.

curl.exe --proxy http://127.0.0.1:7890 -I https://example.com
Get-NetTCPConnection -State Listen -LocalPort 7890

시스템 프록시를 따르지 않는 앱까지 처리해야 할 때 TUN을 켜세요. 클라이언트에 따라 서비스 설치, 서비스 모드 활성화 또는 관리자 권한이 필요할 수 있으므로 화면 안내를 따르세요. 활성화 후 가상 네트워크 인터페이스가 생성됐는지, 코어 로그에 장치 생성 성공이 기록됐는지, 라우팅이 설정됐는지 확인하세요. VPN, 가상 머신, 컨테이너 네트워크, 기업 보안 소프트웨어가 라우팅에 영향을 줄 수 있습니다. 문제를 확인할 때는 불필요한 유사 터널을 잠시 중지하고 같은 요청을 다시 테스트하세요.

절전 모드, 업데이트, 비정상 종료 후 복구

절전 모드에서 깨어난 뒤 연결이 끊겨도 구독이 만료됐다고 단정할 수 없습니다. 먼저 네트워크 연결이 복구됐는지 확인한 다음 노드 연결을 새로고침하세요. Wi-Fi나 유선 네트워크를 바꾸면 기존 인터페이스의 경로를 다시 설정해야 할 수 있습니다. 클라이언트를 종료한 뒤 모든 웹 페이지가 열리지 않는다면 시스템 프록시가 꺼진 로컬 수신 포트를 가리키는지 확인하세요. 정상 종료 전에는 연결 기능을 끄세요. 비정상 종료 후에는 클라이언트 문제를 해결하기 전에 프록시 설정을 복원해 네트워크부터 복구하세요.

포트가 이미 사용 중이라면 수신 정보에 표시된 프로세스 ID로 점유 프로세스를 확인하고, 중복 클라이언트를 종료하거나 포트를 바꾸세요. 포트를 바꾼 뒤에는 앱별 프록시, 시스템 프록시, 터미널 환경 변수를 모두 맞춰야 합니다. 설정 파일 한 곳만 수정하면 일부 앱은 이전 포트에 계속 연결합니다. 클라이언트를 업데이트하기 전에 구독 출처, 오버라이드, 정책 그룹 선택을 백업하고, 업데이트 후 서비스 상태를 다시 확인하세요. 자세한 점검 명령은 로컬 포트 충돌 해결을 참고하세요.

03 / MACOS

macOS: 프로세서 아키텍처, 네트워크 서비스 및 백그라운드 구성 요소

Apple Silicon과 Intel 설치 파일 구분

‘이 Mac에 관하여’에서 칩 또는 프로세서 정보를 확인한 뒤 macOS 다운로드로 이동하세요. 새 기기에는 Clash Plus를 우선 권장하며 Clash Verge Rev나 FlClash를 선택할 수도 있습니다. ClashX Meta는 개발이 중단된 보관용 클라이언트입니다. Apple Silicon과 Intel은 서로 다른 아키텍처용 설치 파일을 사용합니다. 아키텍처를 맞추지 않은 채 변환 실행에 의존하지 마세요. 특히 네트워크 관련 백그라운드 구성 요소가 필요한 클라이언트는 화면이 실행되더라도 부속 구성 요소까지 호환된다는 보장이 없습니다.

디스크 이미지 형식의 앱은 이미지를 마운트한 상태로 계속 실행하지 말고 앱을 ‘응용 프로그램’ 폴더로 복사한 뒤 실행하세요. 처음 실행할 때 시스템 보안 경고가 나타나면 다운로드 출처, 파일 다운로드 완료 여부, 시스템 요구 사항을 확인한 다음 macOS의 정상적인 승인 절차를 따르세요. 보안 속성을 일괄 제거하는 것을 기본 설치 절차로 삼지 마세요. 조직에서 관리하는 컴퓨터는 관리 정책에 따라 제한될 수 있으므로 네트워크 도구 설치가 허용되는지 먼저 확인해야 합니다.

원격 설정을 가져오고 메뉴 막대 상태 확인

설정 관리에서 구독 URL을 추가하고 가져오기가 완료될 때까지 기다린 뒤 해당 항목을 직접 활성화하세요. 메뉴 막대 아이콘은 보통 앱이 실행 중임을 나타낼 뿐 구독 로드, 노드 선택, 시스템 프록시 활성화를 뜻하지 않습니다. 정책 그룹에 선택 가능한 노드가 있는지 확인한 다음 연결 화면에서 실제 요청을 살펴보세요. 가져오기에 성공했는데 예상한 그룹이 없다면 서비스 제공업체의 응답이 오류 페이지인지, 이용권이 만료됐는지, 현재 가져오기 메뉴가 전체 설정과 단일 노드 목록 중 무엇을 요구하는지 확인하세요.

계속 사용할 사용자 지정 규칙은 구독 캐시를 직접 수정하지 말고 클라이언트가 지원하는 오버라이드나 병합 기능에 저장하세요. 원격 업데이트는 캐시 내용을 바꿀 수 있어 임시 수정 사항이 다음 새로고침 때 사라질 수 있습니다. 수정 전에 사본을 내보내고 규칙 순서와 정책 그룹 이름이 정확히 일치하는지 확인하세요. 설정 이름은 문자 하나까지 구분됩니다. 끝의 공백, 전각 문장 부호, 이름을 바꾼 뒤 갱신하지 않은 참조 때문에 규칙이 원하는 출구를 가리키지 않을 수 있습니다.

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

macOS 프록시 설정은 네트워크 서비스별로 적용됩니다. Wi-Fi와 유선 네트워크 인터페이스의 설정이 다를 수 있으므로 인터페이스를 바꾼 뒤에는 이전에 연결했던 Wi-Fi가 아니라 현재 사용하는 서비스를 확인하세요. 클라이언트에서 시스템 프록시를 켠 뒤 시스템 네트워크 설정에서 프록시 주소와 포트를 확인합니다. 자동 프록시 구성, 브라우저 프록시 확장 프로그램, 다른 네트워크 도구를 함께 사용한다면 최종 설정을 담당하는 구성 요소를 명확히 정해 서로 덮어쓰지 않도록 하세요.

아래 명령은 네트워크 서비스 목록과 특정 서비스의 프록시 설정을 확인합니다. 예시에는 흔히 쓰이는 ‘Wi-Fi’라는 이름을 사용했지만 서비스 이름을 바꿨을 수 있으니 먼저 목록을 확인한 뒤 실제 이름으로 바꾸세요. HTTPS 웹 요청은 로컬 HTTP 프록시를 통과할 때 대개 CONNECT를 사용하므로 시스템의 보안 웹 프록시 항목도 확인해야 합니다. 웹 프록시가 켜져 있다는 사실만으로 HTTPS 앱에도 같은 설정이 적용된다고 볼 수 없습니다.

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
curl --proxy http://127.0.0.1:7890 -I https://example.com

TUN 권한과 개발 환경별 차이

TUN을 켜기 전에 시스템 프록시 연결을 먼저 테스트한 뒤 클라이언트 안내에 따라 보조 구성 요소를 설치하거나 네트워크 권한을 허용하세요. 구현 방식에 따라 특권 보조 프로그램, 시스템 확장 프로그램 또는 다른 연결 수단을 사용할 수 있으므로 권한 설정 위치가 서로 다를 수 있습니다. 시스템 설정에서 승인 상태를 확인하고 승인한 다음 터널을 다시 켜세요. 로그에 장치 생성 또는 권한 오류가 나타나면 노드를 계속 바꾸기보다 로컬 구성 요소 상태부터 해결하세요.

터미널 프로그램은 그래픽 인터페이스의 시스템 프록시를 따르지 않을 수 있습니다. 임시 테스트에는 명령의 프록시 매개변수로 연결 주소를 지정하세요. 환경 변수를 사용한다면 필요한 세션이나 도구에만 설정하고, 대소문자 변수와 도구별 지원 여부를 확인하세요. Docker, 가상 머신, 원격 개발 환경은 각각 별도의 네트워크 컨텍스트를 사용하며 내부의 루프백 주소는 호스트를 가리키지 않습니다. 컨테이너에서 호스트 프록시에 연결되지 않으면 먼저 어느 호스트에 접속해야 하는지 확인하고, 필요한 경우에만 제한된 LAN 수신 주소를 여세요.

절전 모드에서 깨어날 때, 네트워크 서비스 순서가 바뀔 때, 회사 VPN을 사용할 때 연결이 영향을 받을 수 있습니다. 같은 URL에 직접 연결하는 경우와 프록시를 명시한 경우를 비교한 다음 라우팅과 DNS를 확인하세요. LAN 프린터, 파일 공유, 개발 도메인이 작동하지 않는다면 로컬 도메인 처리와 직접 연결 규칙을 검토하세요. 모든 사설 주소를 원격으로 보내서는 안 됩니다. 클라이언트를 제거하기 전에 시스템 프록시와 터널을 끄고, 앱에서 제공하는 절차로 보조 서비스를 제거하세요. 앱만 삭제하고 실행 중인 구성 요소를 남기지 않도록 주의하세요.

04 / ANDROID

Android: 앱 설치, VPN 권한 및 백그라운드 실행

호환되는 설치 파일 선택 및 이전 경로 보관

Android 다운로드에서 Clash Plus, Clash Meta for Android, FlClash, Surfboard 순으로 살펴볼 수 있으며 처음이라면 Clash Plus를 우선 권장합니다. 설치 호환성은 기기 아키텍처와 최소 운영체제 요구 사항에 따라 달라지므로 휴대폰 브랜드만으로 선택하지 마세요. 최신 기기는 대부분 ARM64를 사용하지만 구형 기기와 일부 시스템은 실제 정보를 확인해야 합니다. 설치 프로그램에서 호환되지 않는다고 표시하면 다른 클라이언트를 찾기 전에 아키텍처와 시스템 요구 사항부터 확인하세요.

시스템 파일 관리자에서 다운로드한 파일을 열면 Android에서 현재 출처의 앱 설치를 허용하라는 메시지가 나올 수 있습니다. 현재 사용하는 브라우저나 파일 관리자에만 권한을 허용하고 설치 후에는 원래 설정으로 돌려놓으세요. 기존 앱 위에 설치하지 못하는 이유는 서명 불일치, 다른 배포 경로로 설치한 앱, 버전 되돌리기 제한일 수 있습니다. 앱을 삭제하기 전에 설정과 오버라이드를 내보내고 구독을 다시 받을 수 있는지 확인하세요. 앱을 바로 삭제하면 로컬 정책 그룹 선택과 일부 실행 설정도 함께 사라집니다.

구독 업데이트와 현재 실행 중인 설정 구분

설정 페이지에서 URL 구독을 추가하고 다운로드한 뒤 해당 설정으로 전환하세요. 프록시 페이지에서 대상 정책 그룹에 노드가 나타나는지 확인하고 하나를 직접 선택해 테스트합니다. 브라우저의 빠른 가져오기를 사용했다면 클라이언트로 돌아온 뒤 URL, 설정 이름, 현재 활성화 상태를 다시 확인하세요. 같은 링크를 처리할 수 있는 앱이 여러 개 설치되어 있으면 빠른 가져오기가 다른 클라이언트를 열 수 있습니다. 이 경우 현재 실행 중인 클라이언트의 설정은 바뀌지 않습니다.

Clash Meta for Android 등의 설정 메뉴는 다른 앱과 다를 수 있으며 Surfboard가 지원하는 설정 문법도 Clash YAML과 동일하다고 볼 수 없습니다. 서비스 제공업체가 여러 종류의 구독을 제공하면 현재 클라이언트에 맞는 형식을 선택하세요. 가져오기에 실패하면 형식이나 프로토콜 오류를 먼저 읽고 같은 URL을 여러 항목으로 반복 추가하지 마세요. 노드만 포함된 콘텐츠를 사용한다면 클라이언트에서 규칙과 그룹을 제공해야 합니다. 노드 목록만으로는 완전한 라우팅 정책이 되지 않습니다.

VPN 연결을 승인하고 적용 범위 확인

연결 또는 시작을 누르면 보통 시스템에서 VPN 연결 확인 메시지가 표시됩니다. 승인한 뒤 클라이언트에 서비스가 시작됐다고 표시되는지, 시스템의 VPN 상태가 어떤지 확인하세요. 일반적인 개인 사용자 환경에서는 같은 사용자 영역에서 VPN 서비스 하나만 해당 연결 지점을 사용할 수 있습니다. 광고 차단, 방화벽, 회사 네트워크, 다른 프록시 앱이 자리를 차지하고 있을 수 있습니다. 시작 직후 연결이 끊기면 원격 노드 매개변수를 수정하기 전에 다른 VPN이 실행 중인지 확인하세요.

Android의 VPN 연결은 반드시 TUN이라는 별도 스위치를 켜야 한다는 뜻이 아닙니다. 많은 모바일 클라이언트는 이미 플랫폼 VPN 인터페이스를 통해 트래픽을 코어로 전달하며 네트워크 스택, DNS, 앱별 분기도 앱 내부에서 처리합니다. 화면에 시스템 스택과 사용자 공간 스택 선택지가 있다면 우선 기본값을 사용하고, 명확한 호환성 문제가 있을 때만 비교 테스트하세요. 데스크톱용 auto-route 등의 필드는 모바일 앱에서 직접 사용하지 않을 수 있습니다. 설정 전체를 그대로 복사하면 무시되거나 자동 생성 설정과 충돌할 수 있습니다.

‘선택한 앱만 프록시’ 기능을 사용하면 새로 설치한 앱이 자동으로 목록에 추가되지 않을 수 있습니다. 제외 모드에서는 제외 목록에 있는 앱이 터널을 우회합니다. 현재 앱 목록이 포함 목록인지 제외 목록인지 확인한 뒤 대상 앱이 올바른 쪽에 있는지 확인하세요. 브라우저는 되지만 다른 앱이 안 된다면 앱별 분기, 비공개 DNS, 앱 자체 프록시, UDP 지원 여부를 각각 테스트하세요. 모든 차이를 구독 문제로 돌리지 마세요.

배터리 절약 제한 및 네트워크 전환

화면을 잠근 뒤 연결이 끊기면 먼저 시스템 배터리 설정에서 백그라운드 활동이 제한되는지, 필요한 자동 시작이 허용되는지, 포그라운드 서비스 알림이 유지되는지 확인하세요. 제조사마다 설정 이름은 다르며 최근 앱 화면에서 앱을 잠그는 것만으로 완전한 백그라운드 권한이 부여되지는 않습니다. 현재 클라이언트의 배터리 제한을 먼저 조정하고 잠금과 해제 시 로그를 확인하세요. 프로세스 종료 기록 없이 재연결만 반복된다면 모바일 네트워크 전환, 노드 연결 가능성, 터널 재구성을 계속 점검하세요.

Wi-Fi에서 모바일 데이터로 전환하면 외부 IP와 기본 연결이 바뀌어 기존 장기 연결을 다시 구성해야 할 수 있습니다. 네트워크가 안정될 때까지 기다린 다음 재연결하고 같은 대상으로 테스트하세요. 공용 Wi-Fi에 인증 페이지가 있다면 먼저 인증을 완료한 후 프록시를 켜세요. VPN의 ‘항상 켜기’와 ‘VPN 없이 연결 차단’이 활성화되어 있으면 클라이언트를 중지하는 순간 네트워크가 차단될 수 있습니다. 문제를 확인하기 전에 해당 시스템 설정을 기록해 예상된 차단을 앱 충돌로 오해하지 않도록 하세요.

05 / IOS

iOS: 앱 스토어 설치, 구독 호환성 및 터널 설정

App Store에서 Clash Plus 설치

iPhone과 iPad에서는 iOS 다운로드를 통해 Clash Plus App Store 페이지로 이동할 수 있으며, Clash Plus App Store 페이지를 직접 확인할 수도 있습니다. 앱 공식 웹사이트는 clashplus.io입니다. 설치 전에 App Store에 표시된 기기와 시스템 요구 사항을 확인한 뒤 앱을 실행하세요. iOS의 시스템 연결은 플랫폼 네트워크 기능으로 관리됩니다. 데스크톱의 서비스 설치, 백그라운드 트레이, 시스템 프록시 메뉴가 iOS에도 있다고 가정하지 마세요.

처음 사용하기 전에 기기 자체가 인터넷에 연결되는지 확인하고 현재 Wi-Fi의 웹 인증을 완료하세요. 구독 다운로드는 보통 터널을 본격적으로 연결하기 전에 이루어지므로 기본 네트워크가 연결되지 않으면 가져오기가 시간 초과된 것처럼 보일 수 있습니다. 조직에서 관리하는 기기는 네트워크 확장, 구성 프로파일, 접근 제한이 적용될 수 있습니다. 시스템에서 VPN 설정을 추가할 수 없다고 표시되면 구독의 노드 프로토콜을 바꾸기 전에 기기 관리 정책을 확인하세요.

전체 URL을 가져오고 설정 호환성 확인

앱의 설정 또는 구독 관리에서 원격 URL을 추가하고 모든 매개변수를 유지한 채 가져오세요. 빠른 가져오기 기능을 사용했다면 앱으로 돌아와 새 항목이 실제로 생겼는지 확인한 뒤 현재 설정으로 지정하세요. 하나의 구독에서 여러 클라이언트 형식을 제공할 수 있으므로 서비스 제공업체가 호환된다고 명시한 항목을 사용해야 합니다. 텍스트 편집기에서 YAML이 열린다는 이유만으로 모든 필드가 모바일 플랫폼에서 지원된다고 단정하지 마세요. 파일 형식이 올바른지와 기능이 지원되는지는 별개의 문제입니다.

가져오기에 실패하면 네트워크 요청 오류와 콘텐츠 파싱 오류를 구분하세요. 요청 시간이 초과되면 현재 네트워크, 구독 도메인, 서비스 제공업체 상태를 확인하세요. 파싱 오류라면 응답이 로그인 페이지나 오류 메시지인지, 지원되지 않는 설정인지 확인해야 합니다. 접근 인증 정보가 포함된 URL을 모르는 온라인 도구에 입력하지 마세요. 구독 변환이 필요하면 먼저 서비스 제공업체 안내를 읽고 변환 과정에서 정책 그룹, 규칙, 프로토콜 매개변수가 사라지지 않는지 확인하세요.

설정을 활성화한 뒤 정책 선택 화면에서 대상 그룹에 사용할 수 있는 노드가 있는지 확인하세요. 노드를 하나 직접 선택하고 연결을 시작한 다음 확인할 웹 페이지를 열어보세요. 자동 테스트 그룹은 상태 확인이 끝나야 사용할 수 있는 결과가 나올 수 있습니다. 그룹이 비어 있거나 테스트가 실패하면 그룹 구성원과 테스트 조건부터 확인하세요. 탐지 주소 하나가 실패했다고 모든 서비스를 사용할 수 없다고 단정하지 말고, 노드 하나가 연결된다고 모든 서비스 그룹 선택이 올바른 것도 아닙니다.

터널을 승인하고 실제 라우팅 확인

처음 연결을 시작하면 시스템 안내에 따라 앱이 VPN 설정을 추가하도록 허용하고 기기에서 요구하는 확인 절차를 완료하세요. 앱으로 돌아와 연결 상태를 확인하고 필요하면 시스템 VPN 설정에서 현재 활성화된 항목을 살펴보세요. 상태 표시줄의 VPN 아이콘은 터널이 작동 중이라는 뜻일 뿐 모든 요청이 원격 프록시를 거친다는 뜻은 아닙니다. 규칙 모드에서는 일부 대상이 직접 연결로 처리될 수 있으므로 실제 출구는 앱의 연결 기록에서 확인하세요.

다른 VPN이나 네트워크 필터링 앱도 설치되어 있다면 현재 어떤 설정이 활성화되어 있는지 먼저 확인하세요. 온디맨드 연결을 사용하면 네트워크 상태가 바뀔 때 시스템이 자동으로 다시 연결할 수 있습니다. 수동으로 끊은 뒤 다시 연결된다고 해서 버튼이 고장 난 것은 아닙니다. 문제를 확인할 때는 현재 앱의 온디맨드 규칙을 잠시 끄고 고정된 네트워크에서 연결을 테스트하세요. 기본 경로를 확인한 뒤 자동 동작을 다시 켜세요. 노드, 규칙, 온디맨드 조건을 한꺼번에 바꾸면 원인을 찾기 어렵습니다.

DNS, LAN 서비스 및 Wi-Fi 프록시의 적용 범위

Wi-Fi 상세 설정의 HTTP 프록시와 앱이 만드는 VPN 터널은 서로 다른 연결 방식입니다. 전자는 해당 네트워크에서 그 설정을 사용하는 트래픽에만 적용되며, 후자는 앱과 시스템이 함께 트래픽을 처리합니다. 문제를 확인할 때는 사용하지 않는 수동 Wi-Fi 프록시를 먼저 제거해 트래픽이 이전 로컬 주소나 LAN 주소로 향하지 않게 하세요. 휴대폰에서 설정한 루프백 주소는 휴대폰 자체를 가리키며 컴퓨터의 프록시에 연결되지 않습니다. 다른 기기에서 연결하려면 컴퓨터의 실제 LAN 주소와 명시적으로 연 수신 포트가 필요합니다.

LAN 기기 검색, 화면 미러링, 로컬 기기 제어는 라우팅과 이름 해석에 함께 영향을 받습니다. 공용 인터넷 페이지는 열리지만 로컬 기기에 접근할 수 없다면 로컬 주소가 잘못 프록시 처리되는지, 로컬 도메인의 DNS 요청이 부적절한 경로로 전달되는지, 앱에 필요한 로컬 네트워크 권한이 있는지 확인하세요. 시스템 개인정보 보호나 네트워크 옵션을 변경하기 전에 현재 상태를 기록하고 한 번에 하나씩 비교하세요. 특정 호환성 문제를 해결하려고 보호 기능을 모두 영구적으로 끄지 마세요.

iOS가 백그라운드 프로세스와 터널 리소스를 관리하므로 구독 예약 업데이트가 예상대로 실행되는지는 앱 구현과 시스템 스케줄링에 따라 다릅니다. 앱을 오래 열지 않았다면 먼저 설정을 수동으로 업데이트하고 결과를 확인한 뒤 연결을 테스트하세요. Wi-Fi를 바꾸거나 모바일 데이터에서 Wi-Fi로 돌아온 뒤에는 터널을 다시 구성하기 전에 기본 네트워크와 구독 상태를 확인하세요. 정상 작동하는 설정 사본은 보관하되 만료된 구독을 영구적으로 사용할 수 있는 오프라인 자료로 여기지는 마세요. 노드와 인증 정보는 서비스 제공업체에서 계속 갱신해야 합니다.

06 / LINUX

Linux: 그래픽 클라이언트 및 systemd 서비스 배포

데스크톱 환경에서는 그래픽 클라이언트 사용

데스크톱 환경에서는 Linux 다운로드에서 권장 클라이언트인 Clash Verge Rev 또는 FlClash를 선택하고 배포판의 패키지 형식에 맞는 파일을 설치하세요. 먼저 uname -m으로 아키텍처를 확인한 뒤 다운로드 페이지의 패키지 유형과 대조합니다. 패키지가 없거나 의존성이 부족하면 배포판 버전과 지원 범위를 확인하세요. 다른 플랫폼용 바이너리의 이름만 바꿔 실행하지 마세요. 그래픽 인터페이스를 실행한 뒤 구독과 네트워크 연결을 설정하세요.

데스크톱 클라이언트에서 원격 설정을 추가하고 구독을 활성화한 뒤 노드를 직접 선택하고 현재 데스크톱 환경에서 지원하는 시스템 프록시를 켜세요. GNOME, KDE, 터미널 도구는 시스템 프록시를 적용하는 방식이 서로 다르며 그래픽 설정이 모든 프로그램에 적용되지는 않습니다. 먼저 프록시를 명시한 요청으로 로컬 포트를 확인한 다음 개발 도구를 하나씩 설정하세요. TUN에는 기기 권한과 라우팅 관리 기능도 필요합니다. 클라이언트가 제공하는 서비스 설치 절차를 따르고 별도의 코어가 같은 포트를 사용하지 않도록 하세요.

서버에서는 별도의 mihomo 코어 사용

데스크톱 환경이 없다면 프로세서 아키텍처에 맞는 mihomo 코어를 다운로드해 압축을 푸세요. 아래 명령은 현재 디렉터리에 압축을 푼 실행 파일 mihomo와 완전한 설정 파일 config.yaml이 있다고 가정합니다. 설정에는 유효한 노드나 제공자가 미리 입력되어 있어야 합니다. 이 페이지의 필드 예시는 완전한 서비스 설정이 아닙니다. 파일에 구독 인증 정보가 포함될 수 있으므로 배포 시 디렉터리와 파일 권한을 제한하고 공개 웹 디렉터리에 두지 마세요.

sudo install -m 0755 ./mihomo /usr/local/bin/mihomo
sudo install -d -m 0700 /etc/mihomo
sudo install -m 0600 ./config.yaml /etc/mihomo/config.yaml
sudo /usr/local/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

먼저 설정을 테스트하고 구문 오류, 정책 그룹 참조, 리소스 파일 문제를 해결한 뒤 상시 실행 서비스를 시작하세요. 외부 규칙, 지리 데이터베이스, 제공자에 의존하는 설정이라면 실행 사용자가 해당 디렉터리에 접근할 수 있는지, 필요한 리소스를 가져올 수 있는지도 확인해야 합니다. 처음 시작할 때 접속에 실패해도 노드 문제라고 단정할 수 없습니다. 로컬 리소스가 없을 수도 있습니다. 리소스 다운로드에 프록시가 필요하다면 리소스를 미리 준비하거나 명확한 초기 연결 경로를 만드세요. 시작에 필요한 파일을 받기 위해 먼저 코어가 연결되어야 하는 순환 문제를 피해야 합니다.

systemd로 실행과 로그 관리

/etc/systemd/system/mihomo.service를 만드세요. 아래 예시는 TUN 관리 권한이 필요한 로컬 배포용이며 사용자를 지정하지 않으면 서비스가 root로 실행됩니다. 일반 로컬 프록시만 제공하는 환경에서는 별도의 최소 권한 사용자를 검토하세요. 가상 인터페이스 생성, 라우팅 변경, 제한된 리소스 바인딩에는 추가 권한이 필요합니다. 필요한 권한을 파악하지 않은 채 제한 옵션을 그대로 복사하면 서비스는 시작된 것처럼 보여도 네트워크 장치를 만들지 못할 수 있습니다.

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

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

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

서비스가 시작되면 ss -lntp로 실제 수신 상태를 확인한 뒤 로컬 프록시 요청으로 외부 연결을 테스트하세요. 제어 인터페이스를 활성화해야 한다면 루프백 주소에 바인딩하고 인증 정보를 설정하세요. 원격 관리는 접근이 제한된 터널을 우선 사용합니다. 제어 인터페이스 공개와 프록시 포트 공개는 서로 다른 위험이며 둘 다 인터넷에 직접 노출하지 마세요. 서버의 루프백 주소는 원격 컴퓨터에서 직접 접근할 수 없습니다. 브라우저 패널의 연결 대상은 배포 위치에 맞춰 설정해야 합니다.

TUN 및 유지 관리 시 복구 경로

Linux TUN에는 커널 장치와 네트워크 관리 권한이 필요합니다. 컨테이너에서 실행할 경우 장치 전달과 관련 권한도 필요하며 일반 컨테이너 프로세스는 호스트 라우팅을 직접 변경할 수 없습니다. 아래 항목은 테스트를 마친 mihomo 설정에 병합해야 하며 현재 코어가 해당 필드를 지원할 때만 사용하세요. auto-detect-interface는 출구 인터페이스를 찾는 데 도움을 주지만 다중 네트워크 인터페이스와 정책 라우팅 환경에서는 실제 결과를 확인해야 합니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

원격 서버에서 자동 라우팅을 켜기 전에 관리 세션을 하나 더 열어 두고 콘솔을 통한 복구 방법을 확인하세요. 관리 트래픽이 잘못 가로채이지 않는지도 확인해야 합니다. 네트워크가 정상인 것을 확인한 뒤 부팅 시 실행을 설정하고, 설정 변경은 테스트한 후 재시작하세요. 명령줄 코어는 그래픽 클라이언트의 구독 예약 업데이트 기능을 모두 자동으로 제공하지 않습니다. 업데이트 스크립트는 임시 다운로드, 설정 테스트, 성공 후 교체 순서로 작성하세요. 배포와 서비스 관리에 대한 자세한 내용은 Linux 데스크톱 및 systemd 배포 가이드를 참고하세요.

07 / DIAGNOSTICS

설정 관련 자주 묻는 질문: 포트, 규칙, DNS 및 복구

설정을 한꺼번에 바꾸지 말고 연결 경로를 따라 원인을 찾으세요

문제 해결 순서는 기본 네트워크, 설정 로드, 로컬 수신, 연결 방식, 규칙 일치, 원격 연결로 고정하세요. 프록시를 끈 상태에서 기기가 일반 웹 페이지에 접속되는지 확인한 뒤 코어 시작 오류가 없는지 살펴보고, 프록시를 명시한 요청으로 수신 포트를 테스트하세요. 이 순서대로 확인하면 로컬 문제와 원격 문제를 구분할 수 있습니다. 앞 단계에서 같은 요청이 성공해야 다음 테스트 결과도 의미가 있습니다. DNS, 노드, 모드를 동시에 바꾸면 성공 여부를 재현하기 어렵습니다.

로그는 우선 정보 수준으로 유지하고 실패 요청의 시간, 대상, 오류 유형을 기록하세요. 자세한 디버그가 필요할 때만 잠시 로그 수준을 높이고 작업이 끝나면 원래대로 되돌려 불필요한 접속 정보가 남지 않게 하세요. 연결 거부는 대상 포트에서 수신 중인 서비스가 없는 경우가 많습니다. 연결 시간 초과는 네트워크, 방화벽, 원격 서비스와 관련될 수 있습니다. 설정 파싱 오류는 외부 연결을 시도하기 전에 발생합니다. 오류 문구는 조사 범위를 좁혀줄 뿐 책임 소재를 단독으로 증명하지 않으므로 같은 조건의 비교 요청도 함께 확인해야 합니다.

규칙 순서와 유지되는 오버라이드

규칙은 보통 위에서 아래로 확인하며 먼저 일치한 항목의 정책이 적용됩니다. 따라서 더 구체적인 도메인 규칙을 포괄적인 규칙보다 앞에 두고 기본 처리 규칙은 마지막에 두세요. 아래 예시는 설정에 PROXY라는 정책 그룹이 있다고 가정합니다. 실제 그룹 이름이 다르면 함께 바꿔야 합니다. 존재하지 않는 그룹 이름을 그대로 복사하면 설정 로드에 실패하거나 규칙이 적용되지 않을 수 있습니다. 규칙을 갱신한 뒤에는 편집기에서 저장됐는지만 보지 말고 연결 기록으로 확인하세요.

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

노드 제공자 업데이트와 전체 구독 교체는 서로 다른 작업입니다. 전자는 노드 리소스만 갱신할 수 있지만 후자는 규칙과 정책 그룹까지 바꿀 수 있습니다. 유지할 사용자 지정 내용은 클라이언트에서 공식 지원하는 오버라이드 기능으로 관리하고, 병합 시점이 설정 생성 전인지 후인지 확인하세요. 그룹 이름이 바뀌면 이전 선택 기록이 새 그룹과 연결되지 않을 수 있습니다. 업데이트 후 일부 서비스가 작동하지 않는다면 현재 활성 설정과 관련 그룹을 다시 확인하세요.

DNS와 TUN의 연동 범위

TUN은 IP 패킷을 처리하지만 도메인 규칙에는 신뢰할 수 있는 도메인 정보가 필요합니다. DNS 가로채기, 코어 DNS, Fake-IP 및 기타 매핑 방식이 도메인과 연결을 연결하는 방법에 영향을 줍니다. 가상 인터페이스를 켜는 것만으로 모든 앱의 이름 조회가 코어로 전달되는 것은 아닙니다. 앱 내장 암호화 DNS, 시스템 비공개 DNS, 기존 캐시가 이름 해석 경로를 바꿀 수 있습니다. 문제를 확인할 때 같은 도메인의 DNS 응답과 연결 기록을 비교하고, 필요하면 앱 안내에 따라 캐시를 지운 뒤 다시 테스트하세요.

DNS 누수를 판단하기 전에 어떤 도메인을 어느 DNS가 조회해야 하는지 먼저 정하세요. 직접 연결 도메인이 로컬 DNS를 사용하는 것은 명시적인 분기 설계일 수 있으므로 검사 페이지에 현지 통신사가 표시된다는 이유만으로 전체 설정이 잘못됐다고 단정하지 마세요. 반대로 프록시 대상이 예상한 DNS 경로를 우회하면 개인정보 보호와 호환성 문제가 생길 수 있습니다. 모든 상황에 하나의 공용 DNS 주소를 적용하지 마세요. 기업 도메인, LAN 이름, 원격 서비스는 서로 다른 경로가 필요할 수 있습니다. 자세한 내용은 TUN·라우팅·DNS 처리 안내를 참고하세요.

주요 점검 및 복구 방법

문제를 해결한 뒤 최소한으로 작동하는 설정을 보관하고 변경 사항과 테스트 결과를 기록한 다음 자동 업데이트, 온디맨드 연결, 추가 규칙을 차례로 복원하세요. 연결 절차를 처음부터 다시 확인하려면 빠른 시작 가이드로 돌아가세요. 클라이언트를 바꾸기 전에 클라이언트 선택 가이드를 확인하세요. 이전의 목표는 설정이 어디에 속하는지와 연결 범위를 명확히 하는 것이지 여러 클라이언트가 같은 시스템 네트워크 설정을 동시에 관리하게 만드는 것이 아닙니다.