전체 문서 · 설치 / 설정 / 문제 해결

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

운영체제별 다운로드, 설치, 구독 가져오기와 트래픽 처리 방법을 확인하세요. 이 페이지는 전체 설정을 찾아보기 위한 문서입니다. 처음 사용한다면 먼저 Clash 사용 가이드에 따라 연결한 뒤, 돌아와 플랫폼별 차이와 설정 범위를 확인하세요.

공통 준비: 클라이언트, 구독 및 설정 범위

클라이언트·코어·연결 서비스를 구분하세요

Clash 생태계에는 GUI 클라이언트, 프록시 코어, 설정 형식이 포함됩니다. GUI 클라이언트는 구독을 가져오고 아웃바운드를 선택하며 시스템 권한을 요청합니다. 코어는 설정을 파싱하고 규칙에 따라 트래픽을 처리해 연결을 수립합니다. mihomo는 널리 쓰이는 코어지만, 모든 클라이언트가 같은 항목을 지원한다고 단정할 수는 없습니다. 구독의 프로토콜 유형, 클라이언트에 포함된 코어의 기능, 설정 변환 방식이 서로 호환되는지 확인하세요. 특히 최신 전송 옵션과 DNS 항목을 주의 깊게 살펴봐야 합니다.

클라이언트를 설치했다고 바로 연결할 수 있는 것은 아닙니다. 시작하기 전에 신뢰할 수 있는 서비스 제공업체의 구독 링크나 아웃바운드 정의가 포함된 로컬 YAML 파일을 준비하고, 이용 범위와 만료 여부, 기기 제한을 확인하세요. 먼저 클라이언트 다운로드 페이지에서 운영체제에 맞는 Clash Plus를 선택하는 것이 좋습니다. 다른 인터페이스나 배포 방식이 필요하다면 플랫폼에 따라 Clash Verge Rev, FlClash 등의 클라이언트를 비교하세요. 프록시 코어 여러 개를 동시에 실행하지 마세요.

기기 아키텍처를 확인하고 현재 네트워크 설정을 기록하세요

다운로드 전에 운영체제, 프로세서 아키텍처, 설치 권한을 확인하세요. 데스크톱은 x64와 ARM64를 구분하고, macOS는 Intel과 Apple Silicon에 맞는 설치 파일을 선택해야 합니다. Android는 기기에서 지원하는 명령어 집합에 맞춰 설치 패키지를 고르세요. 아키텍처가 맞지 않으면 대개 앱이 실행되지 않거나 설치에 실패하며, 이는 구독 문제와는 별개입니다. 설치 전에는 기존 VPN, 수동 프록시, 회사 네트워크 프로그램, 사용자 지정 DNS를 기록해 두세요. 새 설정이 기존 설정을 덮어써도 원래대로 되돌릴 수 있습니다.

현재 정상적으로 작동하는 설정과 클라이언트 오버라이드 규칙을 백업하세요. 구독 주소에는 계정 식별 정보가 포함될 수 있으므로 스크린샷, 문의 티켓, 공개 저장소에 올릴 때 전체 주소를 가려야 합니다. 로컬에서 내보낸 YAML에도 비밀번호가 들어 있을 수 있습니다. 여러 기기에서 동기화한다면 서비스 제공업체가 관리하는 구독과 직접 관리하는 오버라이드를 분리하세요. 원격 구독에서 생성된 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 관리 방법은 여러 기기에서 설정 동기화하기를 참고하세요.

시스템 프록시와 TUN의 트래픽 처리 범위 이해하기

시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 로컬 HTTP 또는 SOCKS 연결 지점을 제공합니다. 모든 게임, 명령줄 도구, UDP 트래픽이 이 연결 지점을 사용한다고 보장하지는 않습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 처리하며, 보통 서비스 구성 요소나 시스템 권한이 필요합니다. 두 기능은 해결하는 문제가 다릅니다. 먼저 시스템 프록시로 작동 여부를 확인한 다음, 앱에 필요한 경우 TUN을 켜면 모든 옵션을 한꺼번에 활성화하는 것보다 문제를 찾기 쉽습니다.

아래 공통 항목은 일반적인 mihomo 설정에 사용할 수 있습니다. 혼합 포트는 HTTP와 SOCKS 요청을 모두 받으며, 루프백 주소에 바인딩하면 이 기기에서만 사용할 수 있습니다. 예시에는 아웃바운드가 없으므로 매개변수 확인용으로만 사용하세요. 이 설정만으로 프록시 출구를 테스트할 수는 없습니다. 클라이언트가 인터페이스에서 포트나 바인딩 주소를 생성한다면 구독 파일만 보지 말고 실제 실행 설정의 최종 값을 확인하세요.

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

구독을 가져온 뒤 확인할 순서

링크를 가져온 뒤 구독을 업데이트하고 새 설정을 현재 설정으로 지정하세요. 예상한 프록시 그룹이 표시되는지 확인하고, 선택 그룹을 열어 실제 아웃바운드를 지정하세요. ‘자동 선택’ 그룹에도 사용 가능한 구성원이 있어야 합니다. 구독 다운로드 성공은 설정을 가져올 수 있다는 뜻일 뿐, 아웃바운드 연결이 가능하다는 의미는 아닙니다. 다운로드에 실패하면 시스템 시간, 주소 전체가 복사됐는지, 서비스 제공업체가 특정 구독 형식을 요구하는지 확인하세요. 클라이언트의 가져오기 기능을 우선 사용하고, 검증되지 않은 서드파티 변환 서비스를 거치지 마세요.

그다음 규칙 모드에서 프록시를 거쳐야 하는 요청을 테스트하고, 연결 기록에서 적용된 규칙과 최종 아웃바운드를 확인하세요. 직접 연결되어야 하는 요청도 테스트해 분기 처리가 예상대로인지 확인합니다. 한 번에 변수 하나만 바꾸고 변경 전후 결과를 기록하세요. 브라우저에서 웹페이지가 열린다고 모든 앱의 트래픽이 처리되는 것은 아닙니다. 출구 주소가 바뀌었다고 DNS 경로가 올바르다는 뜻도 아닙니다. 요청, 규칙, DNS 해석을 모두 확인해야 합니다.

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

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

Windows 설정의 시스템 정보에서 시스템 종류를 확인한 뒤 다운로드 페이지에 표시된 아키텍처와 시스템 요구 사항에 맞는 설치 파일을 고르세요. Clash Plus를 우선 권장하며, 사용 환경에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu도 선택할 수 있습니다. Clash for Windows는 유지 관리가 중단됐습니다. 기존 설정을 확인하거나 이전하는 용도로는 쓸 수 있지만, 예전 가이드의 메뉴 위치를 현재 클라이언트에도 그대로 적용하면 안 됩니다. 새 클라이언트를 설치하기 전에 기존 클라이언트를 종료하고 시스템 프록시를 끄세요.

설치 프로그램이 관리자 권한을 요청하면 파일 출처와 요청 작업을 먼저 확인하세요. 일반 GUI와 관리자 권한이 필요한 백그라운드 서비스는 별개의 구성 요소이므로, GUI를 실행할 때마다 관리자 권한을 사용할 필요는 없습니다. 처음 실행한 뒤 코어가 정상적으로 시작되는지 확인하세요. 창은 열리지만 설정이나 로그 페이지에서 계속 연결 실패가 표시된다면, 시스템을 바로 재설치하거나 구독을 반복해서 바꾸지 말고 로컬 코어 프로세스와 제어 연결부터 확인하세요.

설정을 가져오고 시스템 프록시로 기본 연결 확인하기

구독 또는 설정 페이지에서 전체 링크를 붙여넣고 다운로드하세요. 알아보기 쉬운 이름을 지정하고, 업데이트가 끝나면 해당 설정을 선택해 현재 설정으로 사용하세요. 아웃바운드 페이지에서 선택 그룹을 열어 실제 노드를 지정한 뒤 설정에서 시스템 프록시를 켜세요. 브라우저에 고정 프록시가 설정되어 있거나 프록시 전환 확장 프로그램을 설치했다면, 잠시 시스템 설정을 사용하도록 바꾸세요. 그렇지 않으면 클라이언트의 시스템 프록시 옵션이 브라우저에 적용되지 않을 수 있습니다.

테스트할 때는 먼저 규칙 모드를 유지하세요. 트레이 아이콘만 보지 말고 연결 기록에서 대상 도메인, 적용 규칙, 아웃바운드 경로를 확인하세요. 로컬 HTTP 연결 지점을 직접 검증하려면 PowerShell에서 아래 명령을 명시적으로 실행할 수 있습니다. 환경에 따라 짧은 명령의 해석이 달라질 수 있으므로 여기서는 curl.exe를 사용합니다. 요청 성공은 지정한 연결 지점이 작동한다는 뜻일 뿐, 다른 앱도 시스템 프록시를 자동으로 사용한다는 뜻은 아닙니다.

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

필요한 경우 TUN 서비스 설치하기

대상 앱이 시스템 프록시를 무시하거나 더 많은 네트워크 트래픽을 처리해야 할 때 TUN 설정으로 이동하세요. 일부 클라이언트는 TUN을 켜기 전에 서비스 구성 요소를 설치해야 합니다. 서비스 설치, 서비스 실행, TUN 활성화는 각각 별개의 상태입니다. 권한을 부여한 뒤 가상 네트워크 어댑터와 라우팅, 초기화 관련 로그를 확인하세요. 활성화에 실패하면 먼저 시스템 프록시 기본 상태로 되돌리고 구체적인 오류를 확인하세요. 버튼을 반복해서 누르지 말고 권한, 드라이버, 서비스 상태를 점검하세요.

TUN은 다른 VPN, 가상 머신 네트워크, 컨테이너 네트워크, 기업 보안 소프트웨어와 라우팅 충돌을 일으킬 수 있습니다. 문제를 찾을 때는 트래픽을 처리하는 도구 하나만 남기고 나머지는 잠시 비활성화한 뒤 어떤 프로그램을 껐는지 기록하세요. 원격 데스크톱이나 회사 관리 기기에서는 기본 경로를 함부로 바꾸지 마세요. 관리 연결이 끊길 수 있습니다. 회사 정책으로 서비스 설치가 제한된다면 기기 관리 규칙을 따르세요. 보안 소프트웨어의 보호 기능을 모두 끄는 것은 일반적인 해결책이 아닙니다.

포트 충돌, 프록시 설정 잔여물, 권한 문제 해결

로그에 포트가 사용 중이라고 표시되면 위의 리스닝 조회 명령으로 프로세스 ID를 확인한 다음 어떤 프로그램인지 파악하세요. 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요. 중복 실행 중인 클라이언트를 닫거나 클라이언트 설정에서 사용 가능한 포트로 바꿀 수 있습니다. 포트를 바꾸면 브라우저, 터미널, 편집기의 수동 프록시 설정도 함께 변경해야 합니다. 설정 파일과 인터페이스의 오버라이드 값이 다르면 코어가 실제로 리스닝하는 최종 값을 기준으로 확인하세요.

클라이언트를 종료한 뒤 브라우저에서 인터넷이 되지 않는다면, 코어는 중지됐는데 시스템에 로컬 포트를 가리키는 수동 프록시가 남아 있는 경우가 많습니다. Windows 네트워크 설정의 프록시 페이지를 열어 수동 프록시가 켜져 있는지 확인하고 원래 네트워크 환경에 맞게 되돌리세요. 앱 하나에서만 문제가 발생한다면 앱 자체의 프록시 설정, 백그라운드 프로세스, 캐시된 연결을 먼저 확인하세요. 앱 하나의 오류만으로 TUN이나 구독 전체가 작동하지 않는다고 판단하지 마세요.

업그레이드 전에 구독 목록, 오버라이드 파일, 필요한 설정을 백업하고 업그레이드 후 서비스 상태와 시작 시 자동 실행 여부를 다시 확인하세요. 기기가 절전 모드에서 깨어나거나 무선 네트워크를 전환한 뒤 연결이 끊기면 클라이언트를 다시 연결하고 라우팅 변경을 확인한 다음 서비스를 재시작할지 판단하세요. 자세한 설치 절차와 오류 해결 방법은 Windows에 Clash Verge Rev 설치하기: 전체 과정을 참고하세요. 문서의 메뉴 이름을 다른 클라이언트에 그대로 적용하지 마세요.

macOS: 칩 아키텍처, 네트워크 권한, 프록시 복구

칩에 맞는 클라이언트를 선택해 설치하기

‘이 Mac에 관하여’에서 칩 또는 프로세서 정보를 확인한 뒤 macOS 다운로드에서 알맞은 설치 파일을 선택하세요. Clash Plus를 우선 권장하며 Clash Verge Rev나 FlClash도 사용할 수 있습니다. ClashX Meta는 유지 관리가 중단됐으므로 기존 설정을 옮길 때 코어 항목을 별도로 확인해야 합니다. 설치 파일 아이콘이나 용량만으로 아키텍처를 판단하지 마세요. 변환 기능을 통해 실행되더라도 해당 기기에 가장 적합한 설치 방식이라는 뜻은 아닙니다.

설치 파일 안내에 따라 앱을 응용 프로그램 폴더로 옮긴 뒤 고정된 위치에서 실행하세요. 디스크 이미지나 임시 다운로드 폴더에서 계속 실행하지 않는 것이 좋습니다. 출처나 권한 관련 시스템 안내가 표시되면 다운로드 경로와 앱 정보를 확인하고 운영체제에서 제공하는 정상적인 승인 절차를 따르세요. 시스템 보안 기능을 전부 해제하는 것은 설치 절차가 아닙니다. 처음 실행한 뒤 메뉴 막대 아이콘, 설정 페이지, 로그 페이지가 모두 정상적으로 열리는지 확인한 다음 구독을 가져오세요.

구독 가져오기 및 활성 네트워크 서비스 확인

클라이언트의 설정 관리 메뉴에서 원격 구독을 추가하고 업데이트한 뒤 현재 설정으로 지정하세요. 프록시 그룹에서 아웃바운드를 선택합니다. 같은 클라이언트에 설정이 여러 개 있다면 서비스 출처와 용도를 구분할 수 있도록 이름을 지정하세요. 처음에는 TUN을 끄고 시스템 프록시를 켠 다음 브라우저로 연결을 확인하세요. 설정 다운로드 오류가 발생하면 링크, 시스템 시간, 현재 네트워크 연결을 점검하세요. 브라우저에서 구독 주소가 텍스트로 표시된다고 클라이언트와 형식이 호환되는 것은 아닙니다.

macOS의 프록시 설정은 네트워크 서비스별로 다를 수 있습니다. Wi-Fi, 유선 네트워크, 기타 인터페이스마다 설정이 따로 저장될 수 있으므로 인터페이스를 바꾼 뒤 다시 확인하세요. 클라이언트에는 시스템 프록시가 켜져 있다고 표시되지만 요청이 연결 기록에 나타나지 않으면 현재 사용 중인 네트워크 서비스와 앱의 시스템 프록시 사용 여부부터 확인하세요. 브라우저 확장 프로그램, 개발 도구, 명령줄 환경은 각각 별도의 프록시 설정을 가질 수 있습니다. 메뉴 막대 상태만으로 모든 요청의 경로를 판단할 수는 없습니다.

scutil --proxy
curl --proxy http://127.0.0.1:7890 --head https://example.com
lsof -nP -iTCP:7890 -sTCP:LISTEN

위 명령은 각각 현재 프록시 정보 확인, 로컬 HTTP 연결 지점 직접 테스트, 리스닝 프로세스 조회에 사용됩니다. 터미널은 보통 GUI의 시스템 프록시를 자동으로 사용하지 않으므로 브라우저는 되지만 터미널은 안 되는 상황도 가능합니다. 특정 명령에 프록시를 지정해야 한다면 프로그램 자체의 프록시 옵션을 우선 사용하세요. 환경 변수를 사용한다면 현재 터미널과 하위 프로세스에만 영향을 준다는 점을 기억하세요. 시스템 전체 설정 스위치가 아닙니다.

TUN 권한 및 백그라운드 구성 요소

시스템 프록시를 따르지 않는 앱의 트래픽까지 처리해야 할 때 클라이언트가 제공하는 TUN 기능을 사용하세요. 클라이언트마다 권한 있는 보조 구성 요소, 백그라운드 서비스, 시스템 네트워크 기능 등 구현 방식과 권한 안내가 다릅니다. 시스템 안내를 하나씩 읽고 권한을 요청하는 앱이 맞는지 확인하세요. 승인 후 클라이언트에 초기화 성공이 명확히 표시되는지 확인합니다. 백그라운드 구성 요소가 허용되지 않은 경우 아웃바운드를 반복해서 바꿔도 해결되지 않을 수 있습니다. 먼저 서비스와 네트워크 권한 상태를 살펴보세요.

기존 VPN, 콘텐츠 필터, 가상화 네트워크, 회사 관리 설정이 있으면 TUN의 라우팅 규칙과 충돌할 수 있습니다. 현재 상태를 기록한 뒤 필수적이지 않은 트래픽 처리 구성 요소를 하나씩 비활성화해 비교하세요. 원격 업무 네트워크에 연결할 때는 내부 도메인과 사설 네트워크에 접속해야 하는지 특히 확인하세요. 모든 트래픽을 프록시로 보내면 내부 리소스에 접근하지 못할 수 있습니다. 유지해야 할 라우팅과 DNS 정책은 우연한 시작 순서에 기대지 말고 명확한 규칙으로 관리하세요.

절전 모드 복귀, 키체인, 앱 삭제 시 주의할 점

덮개를 열어 절전 모드에서 복귀하거나 Wi-Fi를 바꾸거나 도킹 스테이션에 연결하면 네트워크 인터페이스 상태가 달라질 수 있습니다. 복귀 후 연결이 끊기면 현재 설정이 여전히 활성화되어 있는지, 프록시가 리스닝 중인지 확인한 뒤 다시 연결하세요. 도메인만 실패하고 IP 주소로는 직접 연결이 된다면 DNS 경로를 집중적으로 살펴보세요. 여러 DNS 옵션을 한꺼번에 변경하지 마세요. 구독 인증 정보와 시스템 권한을 저장하는 위치는 클라이언트마다 다를 수 있으니 기기를 이전하기 전에 클라이언트가 지원하는 내보내기 기능을 사용하고 파일을 안전하게 보관하세요.

앱을 삭제하기 전에 시스템 프록시와 TUN을 끄고 클라이언트를 종료하세요. 클라이언트에 백그라운드 서비스 제거 메뉴가 있다면 안내에 따라 처리합니다. 앱을 휴지통으로 옮기는 것만으로 네트워크 프록시 설정이나 백그라운드 구성 요소까지 제거되지는 않을 수 있습니다. 삭제 후 네트워크에 문제가 생기면 현재 네트워크 서비스의 프록시 설정에서 로컬 주소를 확인하고 설치 전 기록한 설정을 복원하세요. 진단 로그를 공유할 때는 구독 링크와 아웃바운드 인증 정보를 삭제하세요. 설정 디렉터리 전체를 공개하지 마세요.

Android: 설치 경로, VPN 트래픽 처리, 백그라운드 실행

아키텍처에 맞는 앱을 선택하고 설치 권한 설정하기

Android 다운로드에서 클라이언트를 선택하세요. Clash Plus를 우선 권장하며 Clash Meta for Android, FlClash, Surfboard도 선택할 수 있습니다. 클라이언트별 설정 지원 범위는 완전히 같지 않습니다. 특히 특정 코어용 전체 YAML을 모든 앱에서 사용할 수 있다고 가정하면 안 됩니다. 설치할 앱을 정하기 전에 서비스 제공업체가 지원하는 클라이언트와 구독 형식을 확인하세요. 프로토콜이나 규칙 형식이 파싱되지 않는 문제를 설치 후에 겪지 않도록 해야 합니다.

설치 파일은 기기 아키텍처와 일치해야 합니다. 최근 휴대전화는 대개 ARM64를 사용하지만 실제 지원 여부는 기기에서 확인하세요. 구형 기기는 다른 빌드가 필요할 수 있습니다. 시스템에서 파일 관리자나 브라우저에 앱 설치를 허용하라고 요청하면 실제 사용하는 앱에만 필요한 권한을 부여하고, 설치 후에는 권한을 회수할 수 있습니다. ‘앱이 설치되지 않았습니다’라는 메시지가 나오면 시스템 요구 사항, 남은 저장 공간, 아키텍처, 기존 앱의 서명을 확인하세요. 모든 설치 오류가 네트워크 때문인 것은 아닙니다.

구독을 가져오고 올바른 설정 선택하기

구독 또는 설정 페이지에서 원격 설정을 추가하고 링크를 붙여넣으세요. 다운로드가 끝나면 목록에 표시되는 것만 확인하지 말고 해당 설정이 실제 선택되어 있는지 확인하세요. 프록시 그룹에서 아웃바운드를 선택한 뒤 홈 화면으로 돌아가 연결을 시작합니다. 일부 클라이언트에서는 구독 업데이트와 현재 설정 전환이 별도 작업입니다. 다른 설정을 업데이트해도 실행 중인 설정이 자동으로 바뀌지 않을 수 있으므로, 문제 해결 시 설정 이름과 마지막 업데이트 결과를 함께 확인하세요.

가져온 목록이 비어 있거나 항목 오류가 발생하면 서비스 제공업체가 지정한 형식, 구독 만료 여부, 클라이언트의 실제 프로토콜 지원 범위를 확인하세요. ‘저장 가능하게’ 만들려고 인식되지 않는 항목을 함부로 삭제하지 마세요. 전송 방식이나 인증 방법을 결정하는 항목일 수 있습니다. Surfboard 등의 클라이언트에는 지원되는 설정 형식을 사용하세요. 서비스 제공업체가 구독 링크를 여러 개 제공한다면 오류가 있는 설정을 반복해서 가져오기보다 알맞은 형식을 선택하는 편이 효과적입니다.

Android의 VPN 연결 방식 이해하기

Android 클라이언트는 보통 시스템 VPN 기능으로 앱 트래픽을 처리하며, 처음 연결할 때 시스템 확인 창이 표시됩니다. 이 확인은 로컬 VPN 인터페이스 생성을 허용한다는 뜻이지, 모든 트래픽이 프록시 아웃바운드를 통과한다는 뜻은 아닙니다. 실제 경로는 규칙에 따라 결정됩니다. 시스템의 VPN 아이콘은 인터페이스 상태만 보여줍니다. 선택한 아웃바운드를 실제로 거치는지는 클라이언트 연결 기록, 대상 도메인, 출구 확인 결과를 함께 살펴보세요.

일반적으로 Android에서는 동일한 사용자 공간의 여러 VPN 앱이 동시에 트래픽을 처리할 수 없습니다. 광고 차단 앱, 보안 도구, 회사 VPN, 다른 프록시 클라이언트가 이 기능을 사용 중일 수 있습니다. 시작에 실패하면 시스템 VPN 페이지를 확인하고 필수적이지 않은 다른 연결을 끄세요. 데스크톱에서 ‘시스템 프록시 켜기’를 안내하는 방법을 휴대전화에 그대로 적용하지 마세요. Android의 앱별 분기, VPN 트래픽 처리, Wi-Fi 수동 프록시는 서로 다른 설정입니다.

앱별 분기, 비공개 DNS, 배터리 관리

앱 허용 목록을 사용하면 목록에 없는 앱은 클라이언트로 전혀 들어오지 않을 수 있습니다. 우회 목록에서는 목록에 있는 앱이 직접 연결될 수 있습니다. 테스트 전에 목록이 허용 방식인지 우회 방식인지 확인하고, 대상 앱이 올바른 쪽에 있는지 살펴보세요. 브라우저는 되는데 다른 앱이 실패한다면 규칙 문제일 수도 있고 앱의 트래픽이 아예 처리되지 않는 것일 수도 있습니다. 분기 목록을 바꾼 뒤에는 클라이언트 안내에 따라 연결을 다시 설정해 이전 인터페이스 상태가 남지 않도록 하세요.

Android의 비공개 DNS, 브라우저 보안 DNS, 클라이언트 DNS는 서로 다른 경로로 도메인을 해석할 수 있습니다. 특정 도메인에 접속할 수 없다면 현재 설정을 기록하고 하나씩 비교하세요. 비공개 DNS를 바꾸면서 노드도 함께 변경해 결과를 남기지 않는 일은 피하세요. 일부 클라이언트는 VPN 설정으로 DNS 처리를 통합할 수 있지만, 구체적인 지원 여부는 구현에 따라 다릅니다. fake-ip와 DNS 경로 확인은 DNS 유출 검사 및 방지를 참고하세요.

화면을 잠근 뒤 연결이 끊기면 시스템이 클라이언트의 백그라운드 실행, 배터리 사용, 자동 시작을 제한하는지 확인하세요. 기기마다 메뉴 이름이 다르므로 해당 앱의 배터리 관리 화면을 기준으로 필요한 권한만 조정하세요. ‘항상 켜진 VPN’이나 ‘VPN 연결이 없으면 연결 차단’을 켜기 전에 동작을 이해해야 합니다. 특히 클라이언트가 정상적으로 시작되지 않으면 후자의 설정으로 기기에서 일시적으로 네트워크를 사용할 수 없게 될 수 있습니다. 먼저 인터페이스가 안정적으로 연결되는지 확인하세요.

업그레이드 전에 구독 주소와 로컬 오버라이드를 보관하고 앱 전용 설정을 내보내야 하는지 확인하세요. 다른 클라이언트로 옮기면 앱별 목록과 배터리 권한이 완전히 이전되지 않을 수 있으므로 다시 확인해야 합니다. 앱을 삭제하기 전에 연결을 중지하고 시스템 VPN 설정을 확인하세요. 오류 화면을 공유할 때 구독 정보, 아웃바운드 주소, 계정 정보를 가리고, 연결 로그는 문제를 찾는 데 필요한 시간대만 캡처하세요.

iOS: Clash Plus, 구독 가져오기, 네트워크 확장

App Store에서 설치하고 설정 출처 확인하기

iOS에서는 Clash Plus를 우선 선택하세요. App Store의 Clash Plus 페이지에서 설치할 수 있으며 제품 정보는 공식 웹사이트 clashplus.io에서 확인할 수 있습니다. 설치 전 App Store에 표시된 기기 호환 조건과 앱 설명을 확인하고 현재 기기와 맞는지 살펴보세요. 데스크톱 실행 파일이나 Android 설치 패키지는 iOS 설치 파일이 아닙니다. 앱을 설치한 뒤에도 유효한 구독은 별도로 준비해야 합니다.

구독은 연결 서비스 제공업체가 관리하며, App Store에서 앱을 설치하는 것과 구독 이용 권한은 별개입니다. 링크가 만료되지 않았는지, 계정에서 현재 기기 사용을 허용하는지, 제공업체가 안내한 설정 형식이 무엇인지 확인하세요. 구독 링크에는 접속 정보가 포함되는 경우가 많으므로 공유 메모, 공개 스크린샷, 게시판에 올리지 마세요. 가져오기 오류를 제공업체에 문의할 때는 민감 정보를 가린 오류 문구와 클라이언트 이름만 전달하고 전체 링크는 공개하지 마세요.

구독을 가져와 업데이트한 뒤 현재 설정으로 지정하기

클라이언트의 설정 또는 구독 관리 메뉴에서 원격 링크를 추가하고 다운로드가 완료될 때까지 기다리세요. 제공업체가 QR 코드를 제공했다면 클라이언트에서 지원하는 구독 주소가 들어 있는지 확인하세요. 계정 로그인 페이지나 일반 웹페이지일 수도 있습니다. 가져온 뒤 설정 내용과 프록시 그룹이 표시되는지 확인하고 현재 설정으로 지정한 다음 실제 아웃바운드를 선택하세요. 구독 이름이 보이는 것만으로 활성화가 끝났거나 프록시 그룹 구성원이 사용 가능하다고 단정할 수 없습니다.

구독 업데이트에 실패하면 기기 시간, 현재 네트워크, 링크 전체가 복사됐는지 먼저 확인하세요. 링크를 복사할 때 쿼리 매개변수가 빠지거나 공백과 줄바꿈이 포함될 수 있으므로 신뢰할 수 있는 출처에서 다시 복사하세요. 기존 설정이 작동한다면 문제를 찾는 동안 보존하세요. 백업 없이 모두 삭제하지 마세요. 클라이언트의 로컬 규칙이나 오버라이드 기능을 쓴다면 구독 업데이트 후에도 유지되는지 확인하세요. 업데이트 후 트래픽 분기 방식이 달라질 수 있습니다.

VPN 설정을 승인하고 실제 아웃바운드 확인하기

처음 연결할 때 시스템에서 VPN 설정 추가를 요청할 수 있습니다. 요청한 앱이 현재 사용하는 클라이언트인지 확인하고 시스템 절차에 따라 승인한 뒤 앱으로 돌아가 연결 상태를 확인하세요. iOS는 네트워크 확장으로 트래픽을 처리하므로 Windows처럼 로컬 시스템 프록시 스위치를 찾을 필요가 없습니다. 상태 표시줄이나 제어 센터에 VPN이 표시되는 것은 시스템 연결 상태만 보여줍니다. 요청이 실제로 어디로 전달되는지 확인하려면 클라이언트 설정, 프록시 그룹, 연결 기록을 살펴봐야 합니다.

규칙 모드에서 프록시를 거쳐야 하는 요청 하나를 테스트한 뒤 직접 연결되어야 하는 요청도 테스트하세요. 앱의 콘텐츠가 새로 표시되더라도 캐시를 사용했거나 기존 연결이 유지된 것일 수 있으니 테스트할 때 요청을 새로 시작하세요. 프록시 그룹을 바꿔도 이미 연결된 세션은 바로 출구가 바뀌지 않을 수 있습니다. 필요하면 클라이언트의 연결 관리 기능을 사용하거나 대상 앱을 다시 시작하세요. 이전에 열어 둔 화면만 보고 설정이 적용되지 않았다고 판단하지 마세요.

Wi-Fi, 셀룰러 네트워크 및 기타 네트워크 기능

Wi-Fi와 셀룰러 네트워크에서 각각 연결을 확인하면 로컬 네트워크 제한과 설정 오류를 구분할 수 있습니다. 특정 Wi-Fi에서만 실패한다면 먼저 해당 네트워크의 인증 페이지를 처리하고 프록시 연결을 끈 상태에서 인터넷이 되는지 확인하세요. 공용 네트워크는 외부 서비스에 접속하기 전에 로그인이 필요할 수 있습니다. 인증을 마치지 않으면 구독 업데이트와 아웃바운드 연결 모두 실패할 수 있으므로 이때 규칙 그룹을 여러 번 바꾸는 것은 도움이 되지 않습니다.

회사 VPN, 필요 시 연결 설정, 다른 네트워크 확장이 이미 있다면 여러 도구가 연결을 번갈아 처리하지 않도록 관리 관계를 먼저 확인하세요. 조직에서 관리하는 기기는 일부 네트워크 설정이 정책에 의해 제어될 수 있으므로 관리 규칙을 따르세요. 시스템의 개인정보 보호 네트워크 기능, 브라우저 설정, 클라이언트의 트래픽 처리도 테스트 결과에 영향을 줄 수 있습니다. 각 상태를 기록하고 한 번에 요소 하나만 바꾸세요. 테스트 후에는 유지해야 할 개인정보 보호 및 업무 설정을 복원하세요.

백그라운드 제한, 업데이트, 연결 복구

iOS의 백그라운드 동작을 데스크톱 프로세스와 같은 것으로 생각하지 마세요. 앱을 백그라운드로 보냈을 때 화면이 계속 실행되는지와 네트워크 확장이 연결을 유지하는지는 별개의 문제입니다. 연결이 반복해서 끊기면 시스템 VPN 상태, 클라이언트 오류 기록, 기기 저장 공간, 설정 규모를 확인하세요. 중복 규칙을 대량으로 가져온 뒤 화면이 느려졌다는 이유만으로 아웃바운드 문제라고 단정하지 마세요. 모바일 네트워크 전환 후 잠시 재연결되는 상황과 터널을 계속 설정하지 못하는 상황도 구분해야 합니다.

앱이나 시스템을 업그레이드하기 전에 구독 출처와 중요한 로컬 규칙을 저장하고 클라이언트가 지원하는 백업 방법을 확인하세요. 네트워크를 복구하려면 먼저 클라이언트에서 연결을 중지하고 시스템 설정에서 VPN 상태를 확인하세요. 처음부터 기기의 전체 네트워크 설정을 재설정할 필요는 없습니다. Wi-Fi 정보 등 기존 설정도 영향을 받습니다. 클라이언트 관련 상태가 모두 종료됐는데도 인터넷이 되지 않을 때 네트워크 인증, 기기 정책, 통신사 네트워크를 이어서 확인하세요.

Linux: 배포판, 데스크톱 프록시, 서비스 배포

데스크톱 클라이언트와 코어 직접 배포 구분하기

Linux 데스크톱에서는 다운로드 페이지에 따라 Clash Verge Rev를 선택할 수 있으며 FlClash도 사용할 수 있습니다. 서버나 라우터에서는 mihomo 코어를 별도로 실행할 수 있습니다. GUI 클라이언트와 코어 서비스는 서로 다른 배포 방식입니다. 같은 포트에서 동시에 실행하지 마세요. 트레이 아이콘, 데스크톱 시스템 프록시, 대화형 구독 관리가 필요한지 먼저 결정한 다음 GUI 클라이언트 사용 여부를 정하세요. 직접 관리할 경우 설정 디렉터리, 서비스 권한, 로그도 관리해야 합니다.

설치 전에 시스템 정보에서 배포판, 프로세서 아키텍처, 패키지 형식을 확인하세요. Debian 계열 배포판은 보통 해당 DEB 패키지를 사용하고 RPM 패키지 관리 배포판은 호환되는 패키지를 선택해야 합니다. 다만 의존성과 데스크톱 환경 지원 여부는 클라이언트 안내를 기준으로 확인하세요. 확장자가 같다고 모든 배포판에서 호환되는 것은 아닙니다. 설치 중 의존성 오류가 발생하면 배포판의 패키지 관리자로 원인을 찾으세요. 다른 시스템의 라이브러리 파일을 시스템 디렉터리에 임의로 복사하지 마세요.

uname -m
cat /etc/os-release
ss -lntp 'sport = :7890'

데스크톱 클라이언트의 구독 및 시스템 프록시

설치 후 데스크톱에서 클라이언트를 정상적으로 실행하고 구독을 가져와 현재 설정으로 지정한 다음 프록시 그룹의 아웃바운드를 선택하세요. 시스템 프록시를 켜고 데스크톱 환경 자체의 네트워크 프록시 설정을 확인합니다. 데스크톱 환경, 샌드박스 앱, 브라우저마다 시스템 프록시를 읽는 방식이 다릅니다. 터미널 프로그램도 보통 데스크톱의 프록시 값을 자동으로 사용하지 않습니다. 먼저 프록시 요청을 명시해 코어를 확인한 뒤 대상 프로그램의 연결 방식을 각각 점검하세요. 프로그램 하나가 실패했다고 코어가 실행되지 않는 것은 아닙니다.

아래 명령은 환경 변수를 사용해 현재 명령에만 HTTP 프록시를 지정합니다. 해당 명령과 관련된 실행 환경에만 영향을 줍니다. 장기간 사용하려면 프로그램 설명서를 기준으로 설정하고 우회 주소 목록도 검토하세요. 모든 사용자의 전역 환경 파일에 프록시를 함부로 넣지 마세요. 코어를 중지한 뒤에도 패키지 관리자나 백그라운드 작업이 존재하지 않는 로컬 연결 지점에 접속하려 할 수 있습니다.

HTTPS_PROXY=http://127.0.0.1:7890 curl --head https://example.com

TUN, 라우팅, 최소 권한

Linux에서 TUN으로 트래픽을 처리하려면 가상 네트워크 인터페이스와 라우팅 권한이 필요한 경우가 많습니다. GUI 클라이언트에 서비스 설치 메뉴가 있다면 해당 절차를 우선 사용하세요. 앱 전체 디렉터리에 과도한 권한을 부여하지 마세요. 먼저 서비스가 시작되는지 확인하고 TUN을 활성화한 뒤 로그에서 인터페이스 생성과 라우팅 결과를 살펴보세요. 보조 구성 요소의 권한 문제를 해결하려고 일반 데스크톱 사용자가 GUI 전체를 root로 계속 실행해서는 안 됩니다.

원격 서버에서는 자동 라우팅을 특히 신중하게 설정하세요. 별도의 관리 경로를 확보하고 SSH, 사설 네트워크, 로컬 게이트웨이의 연결 경로를 확인해야 합니다. 그렇지 않으면 기본 경로가 바뀌면서 현재 관리 연결이 끊길 수 있습니다. TUN의 자동 라우팅, 인터페이스 자동 인식, DNS 가로채기는 실제 네트워크 구성에 맞게 설정하세요. 컨테이너, 브리지, 다중 네트워크 어댑터 환경에는 단일 어댑터 노트북 설정을 그대로 적용할 수 없습니다. 라우터 배포는 라우터에서 mihomo 코어 실행하기 개요를 참고하세요.

코어 설정 확인 및 서비스 디렉터리

코어를 직접 실행하려면 먼저 아웃바운드, 프록시 그룹, 규칙이 포함된 전체 설정을 준비하고 구문을 검사하세요. 아래 명령은 mihomo가 시스템 명령 경로에 설치되어 있고 설정 파일이 현재 사용자의 설정 디렉터리에 있다고 가정합니다. 실제 경로가 다르면 배포 디렉터리에 맞게 수정하세요. 검사를 통과했다는 것은 설정을 파싱할 수 있다는 뜻이지 모든 아웃바운드 연결이나 규칙 공급자 업데이트가 성공했다는 뜻은 아닙니다.

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

설정 디렉터리에는 기본 설정 외에도 규칙 공급자 파일, 캐시, 데이터베이스가 들어갈 수 있습니다. 대화형 실행과 서비스 실행에 서로 다른 사용자를 쓰면 읽기 및 쓰기 권한이 달라져 수동 실행은 되지만 서비스는 실패할 수 있습니다. 서비스 실행 사용자, 작업 디렉터리, 설정 경로를 명확히 지정하고 디렉터리 권한을 확인하세요. 배포 방식에 맞는 로그 경로에서 로그를 읽어야 합니다. 오류 출력을 버린 채 서비스가 계속 재시작되게 두지 마세요.

방화벽, LAN, 업데이트 관리

기기에서는 프록시를 사용할 수 있지만 LAN 기기에서는 연결되지 않는다면 바인딩 주소, allow-lan, 방화벽을 각각 확인해야 합니다. 다른 기기에 포트 번호만 알려준다고 연결되는 것은 아닙니다. LAN 접속을 허용하면 외부에 노출되는 연결 지점이 늘어나므로 신뢰할 수 있는 네트워크 범위로 제한하고 필요하면 인증을 설정하세요. 제어 인터페이스와 프록시 연결 지점은 용도가 다릅니다. 제어 인터페이스를 신뢰할 수 없는 네트워크에 공개하지 말고 원격 관리 편의를 위해 방화벽 규칙 전체를 끄지 마세요.

클라이언트나 코어를 업데이트하기 전에 설정과 서비스 정의를 백업하고, 기존 프로세스를 중지한 뒤 새 프로세스를 시작하세요. 데스크톱 세션을 종료했을 때 클라이언트가 종료되는지와 시스템 서비스가 계속 실행되는지는 다릅니다. 배포 목적에 맞게 설정하세요. 삭제 전 데스크톱 프록시를 복원하고 서비스를 중지한 다음 추가 라우팅을 제거하세요. 환경 변수나 자동 시작 작업이 남아 있으면 프로그램 파일을 삭제한 뒤에도 다음 로그인 시 요청이 실패할 수 있습니다.

설정 문제 해결: 포트, DNS, 규칙

테스트 조건을 고정한 뒤 설정을 변경하세요

문제는 ‘앱이 연결되어 있는가, 규칙은 어디로 보내는가, 아웃바운드가 연결되는가, DNS가 올바르게 해석되는가’ 순서로 확인하세요. 대상 앱, 도메인, 아웃바운드를 하나씩 고정하고 시스템 프록시나 TUN 상태를 기록한 다음 연결 로그를 살펴보세요. 노드 변경, DNS 변경, 포트 수정, 클라이언트 재설치를 한꺼번에 하지 마세요. 연결이 복구돼도 원인을 알 수 없고 다음에 문제가 생겼을 때 재사용할 해결 방법을 얻지 못합니다.

아래는 자주 사용하는 항목의 용도와 한계입니다. 클라이언트가 인터페이스를 통해 구독의 값을 덮어쓸 수 있으므로 문제를 찾을 때는 최종 실행 설정을 확인하세요. DNS 리스닝 포트와 혼합 프록시 포트는 용도가 다릅니다. 숫자가 비슷하다고 서로 바꿔 쓸 수 없습니다. 로컬 연결 지점을 외부에 공개해야 한다면 모든 바인딩 주소를 무조건 전체 주소로 바꾸지 말고 먼저 접속자와 네트워크 범위를 정하세요.

항목용도 및 제한
mixed-portHTTP와 SOCKS가 함께 사용하는 연결 지점입니다. 앱은 실제 리스닝 포트를 지정해야 합니다.
allow-lanLAN 접속 허용 여부입니다. 바인딩 주소와 방화벽도 확인해야 합니다.
moderule, global, direct 모드를 선택합니다. 시스템 서비스를 자동으로 설치하지는 않습니다.
dns.enhanced-modeDNS 처리 방식을 선택합니다. 실제 DNS 경로 확인을 대신하지는 않습니다.
tun.auto-route코어에서 관련 라우팅을 설정합니다. 권한이 필요하며 기존 네트워크에 영향을 줄 수 있습니다.

증상에 따라 점검 항목 선택하기

구독 업데이트는 성공했는데 연결되지 않는 이유는 무엇인가요?

업데이트한 설정이 현재 활성 설정인지 확인한 뒤 선택 그룹이 빈 그룹이나 직접 연결이 아닌 실제 아웃바운드를 가리키는지 살펴보세요. 코어가 정상적으로 리스닝하는지, 앱 요청이 연결 기록에 나타나는지도 확인하세요. 기록이 전혀 없다면 시스템 프록시, 앱별 분기, TUN 트래픽 처리를 우선 점검하세요. 기록은 있지만 아웃바운드 연결이 실패한다면 계정 상태, 프로토콜 지원, 원격 서버 연결 가능성을 확인합니다. 구독 다운로드와 프록시 연결은 서로 다른 네트워크 과정입니다. 다운로드 성공만으로 연결을 확인할 수는 없습니다.

규칙 모드에서는 실패하지만 전역 모드에서는 성공합니다. 어떻게 확인하나요?

같은 아웃바운드를 유지한 채 두 모드에서 실패한 요청의 최종 경로를 비교하세요. 규칙 모드에서 직접 연결, 차단, 다른 프록시 그룹이 선택됐을 수 있습니다. 도메인 인식 결과가 예상과 달라 기본 규칙으로 넘어갔을 수도 있습니다. 규칙 순서와 규칙 공급자 업데이트 상태를 확인하고, 규칙 오류를 숨기기 위해 전역 모드를 계속 사용하지 마세요. 모드별 기본 차이는 가이드의 프록시 모드 설명을, 구체적인 문법은 용어집을 참고하세요.

도메인은 열리지 않지만 네트워크와 아웃바운드는 정상으로 보일 때 어떻게 하나요?

먼저 문제가 발생한 도메인이 DNS 해석 결과를 반환하는지 확인한 뒤 브라우저 보안 DNS, 시스템 DNS, 클라이언트 DNS가 서로 다른 경로를 사용하는지 살펴보세요. fake-ip는 내부 매핑에 사용하는 주소를 반환하므로 원격 서버 주소로 간주해 직접 테스트하면 안 됩니다. LAN 기기 탐색이나 특정 도메인 호환 문제라면 해당 도메인에 맞춰 필터와 DNS 정책을 검토하세요. 모든 도메인을 예외에 추가하지 마세요. 관련 설정은 현재 코어가 지원하는 항목과 일치해야 합니다.

TUN을 켠 뒤 LAN이나 회사 리소스에 접속할 수 없으면 어떻게 하나요?

먼저 TUN을 끄고 원래 네트워크가 정상인지 확인한 다음 사설 네트워크 라우팅, 내부 DNS, 회사 VPN의 우선순위를 점검하세요. 직접 연결 규칙을 하나 추가하는 것만으로 이미 잘못된 시스템 라우팅이나 DNS 경로가 해결되지는 않을 수 있습니다. 프록시 DNS와 직접 연결 DNS를 다르게 처리해야 하는 도메인에는 명확한 DNS 정책을 설정하세요. 관리되는 기기는 관리 담당자에게 네트워크 요구 사항을 확인하세요. 제한을 우회하려고 조직 설정이나 보안 구성 요소를 삭제하지 마세요.

설정의 프록시 그룹 이름과 규칙의 대상은 어떻게 연결되나요?

규칙의 아웃바운드 이름은 이미 정의된 프록시, 프록시 그룹, 내장 대상과 정확히 일치해야 합니다. 대소문자와 문자도 동일해야 합니다. 예시의 PROXY가 자동으로 생성되는 것은 아닙니다. 아래 예시는 ‘구독 아웃바운드’라는 유효한 프록시가 이미 있다고 가정하고 선택 그룹과 규칙의 관계만 보여줍니다. 설정에 합치기 전에 구성원 이름을 실제 존재하는 아웃바운드로 바꾸고, 앞선 규칙이 대상 도메인을 먼저 처리하는지도 확인하세요.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 구독 아웃바운드
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY
속도가 느리면 바로 TUN 스택이나 DNS를 바꿔야 하나요?

같은 시간대와 같은 대상에서 여러 아웃바운드를 비교한 다음 로컬 Wi-Fi, 대역폭 사용량, 원격 회선을 점검하세요. DNS는 주로 도메인 해석 단계에 영향을 주므로 다운로드가 계속 느린 현상을 DNS 서버 교체만으로 설명할 수는 없습니다. 로그와 비교 테스트에서 기기의 트래픽 처리 문제가 확인된 경우에만 TUN 옵션을 하나씩 조정하세요. 단계별 점검 방법은 Clash 속도 저하를 3단계로 점검하는 방법을 참고하고, 변경할 때마다 되돌릴 수 있도록 기록을 남기세요.

되돌릴 수 있는 방식으로 설정 관리하기

문제를 확인한 뒤 필요한 변경 사항은 클라이언트가 지원하는 오버라이드나 병합 설정에 넣으세요. 구독 다운로드 결과물을 직접 수정하는 방식은 피해야 합니다. 최소한의 정상 작동 설정을 기준으로 보관하고, 규칙을 추가할 때마다 구문을 검사한 뒤 프록시와 직접 연결 경로를 모두 검증하세요. 도움을 요청할 때는 문제와 관련된 민감 정보 제거 설정 조각, 오류 행 번호, 재현 절차만 제공하세요. 전체 설정, 계정 주소, 로컬 관리 키를 공개 첨부 파일로 올리면 안 됩니다.