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

클라이언트 화면과 프록시 코어 구분하기

Clash 생태계에서 클라이언트는 보통 구독 관리, 프록시 그룹 선택, 로그 표시, 시스템 네트워크 설정을 담당하고, 코어는 설정을 읽어 연결을 만들고 규칙을 적용합니다. mihomo는 독립 실행이 가능한 프록시 코어이며 특정 GUI 클라이언트와 같은 것이 아닙니다. 비슷한 코어를 사용하는 클라이언트라도 설정 병합 방식, 권한 서비스, 업데이트 방식이 다를 수 있습니다. 문제를 해결할 때는 클라이언트 이름, 코어 정보, 운영체제 아키텍처, 트래픽 처리 모드를 함께 기록하세요. 증상을 단순히 “Clash 오류”라고 뭉뚱그려서는 안 됩니다.

데스크톱과 모바일에서는 먼저 설치 파일 페이지에서 기기에 맞는 클라이언트를 선택하세요. Windows, macOS, Android, iOS에서는 Clash Plus를 우선 추천하며, Linux에서는 Clash Verge Rev를 먼저 고려할 수 있습니다. 구형 환경과의 호환성이 필요하다면 시스템 요구 사항을 확인한 뒤 다른 클라이언트를 선택하세요. Clash for Windows와 ClashX Meta는 유지 관리가 중단된 보관용 프로젝트이므로 새 시스템에 장기간 설치할 기본 선택지로는 적합하지 않습니다. GUI, 설정 호환성, 시스템 권한 지원을 함께 살펴야 하며, 이름이 비슷하다는 이유만으로 대체해서는 안 됩니다.

구독을 준비하고 설정 형식 확인하기

구독 URL은 설정을 가져오는 경로이지 프록시 노드 자체가 아닙니다. 가져오기 전에 제공 업체가 대상 클라이언트를 지원하는지, 또는 Clash/mihomo에서 읽을 수 있는 YAML을 제공하는지 확인하세요. 노드 링크만 포함한 텍스트와 프록시 그룹, 규칙, DNS까지 포함한 전체 설정은 서로 다른 형식입니다. 처음 가져온 뒤에는 선택 가능한 설정과 프록시 그룹이 표시되어야 합니다. 가져오기 성공 메시지만 나오고 노드가 없다면 시스템 프록시를 반복해서 전환하기보다 응답 내용, 구독 상태, 형식을 확인하세요. 구독 요청이 실패한 것은 다운로드 주소에 일시적으로 접속할 수 없기 때문일 수도 있습니다.

구독 링크에는 로그인 정보가 포함되는 경우가 많습니다. 공개 변환 사이트, 문제 화면 캡처, 공개 저장소에 올리지 마세요. 구독 변환이 꼭 필요하다면 데이터 처리 환경을 직접 제어할 수 있는 방법을 우선 사용하고, 변환 결과에 규칙과 프록시 그룹이 유지되는지도 확인하세요. 설정 백업도 민감한 자료로 취급해 안전한 위치에만 보관해야 합니다. 수정하기 전에 현재 정상 작동하는 설정을 내보내고 기존 프록시 포트, DNS 설정, 프록시 그룹 선택을 기록해 두세요. 복구할 때는 연결 성공 화면보다 이 정보가 더 유용합니다.

먼저 시스템 프록시를 사용하고 TUN 필요 여부를 판단하세요

시스템 프록시는 해당 설정을 따르는 앱의 트래픽을 로컬 프록시 포트로 보냅니다. 보통 모든 앱의 트래픽을 처리하지 않으며, 기기 전체를 대상으로 하는 터널과도 다릅니다. TUN은 가상 네트워크 인터페이스와 라우팅을 이용해 트래픽을 처리하지만, 적용 범위는 라우팅 제외 설정, 앱 동작, 권한에 따라 달라집니다. 처음 설치할 때는 일반 프록시 연결부터 확인한 뒤 TUN을 켜세요. 구독 자체가 작동하지 않는 상황에서 가상 네트워크 어댑터와 DNS까지 함께 바꾸면 변수가 늘어 원인을 찾기 어려워집니다.

규칙 모드, 전역 모드, 직접 연결 모드는 코어가 어떤 출구를 선택할지 결정합니다. 시스템 프록시와 TUN은 앱 트래픽이 코어로 들어오는 방식을 결정하므로 서로 다른 계층의 설정입니다. 규칙 모드는 설정의 규칙을 순서대로 적용하고, 전역 모드는 출구가 작동하는지 잠시 비교할 때 유용합니다. 직접 연결 모드라고 해서 가상 인터페이스까지 반드시 꺼지는 것은 아닙니다. 변경 전후의 모드를 기록하고 한 번에 한 항목만 바꿔 테스트하세요. 회사 VPN, 다른 프록시 클라이언트, 네트워크 필터링 도구가 있다면 먼저 비활성화해도 되는지 확인해 라우팅 충돌과 로컬 포트 점유를 방지하세요.

반복 가능한 테스트 기준 마련하기

시작하기 전에 시스템 시간, 일반 직접 연결 네트워크, 남은 디스크 공간을 확인하고 설정을 저장해 앱을 실행할 수 있는지 점검하세요. 접속 가능한 HTTPS 페이지와 실제로 프록시가 필요한 서비스를 하나씩 준비하고, 설정을 켜기 전후의 상태를 기록합니다. 브라우저에서 페이지가 열린다고 해서 터미널, 게임, 업데이트 서비스까지 트래픽이 처리되는 것은 아닙니다. 지연 시간 테스트에 결과가 나와도 계정 로그인이나 대용량 전송이 정상이라는 뜻은 아닙니다. 테스트할 때마다 요청이 연결 목록에 표시되는지, 어떤 규칙이 적용됐는지, 어떤 출구를 사용했는지 확인하고 필요하면 로그의 오류도 살펴보세요.

설치 파일을 고르고 단일 클라이언트 환경 만들기

먼저 시스템 설정의 ‘시스템 정보’에서 프로세서와 시스템 종류를 확인한 다음 Windows 설치 파일 섹션에서 파일을 선택하세요. Clash Plus를 우선 추천하며, 필요에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu도 고려할 수 있습니다. Clash for Windows는 보관용 선택지로만 안내합니다. 설치 파일의 비트 수와 브라우저의 비트 수를 혼동하지 마세요. ARM 기기는 클라이언트뿐 아니라 코어와 서비스 구성 요소가 현재 환경을 지원하는지도 확인해야 합니다. 앱이 에뮬레이션으로 실행된다고 해서 가상 네트워크 어댑터 구성 요소까지 정상 작동하는 것은 아닙니다.

설치 전에 다른 프록시 클라이언트를 종료하세요. 먼저 시스템 프록시를 끈 뒤 트레이 메뉴에서 앱을 종료해 이전 프로세스가 포트를 계속 점유하지 않도록 합니다. 설치 마법사에서 디렉터리를 선택하고, 처음 실행할 때 보안 소프트웨어와 시스템 권한 안내를 확인하세요. 설치가 차단되면 구체적인 차단 이유와 파일 출처를 살펴보세요. 모든 보안 기능을 바로 끄지 마세요. 조직에서 관리하는 기기는 네트워크 서비스나 가상 어댑터 설치가 제한될 수 있습니다. 이 경우 보안 정책을 우회하려 하지 말고 먼저 조직의 정책을 확인하세요.

구독을 가져오고 로컬 포트 확인하기

설정 관리 화면에서 URL 가져오기를 선택하고 구독 주소를 입력한 뒤 업데이트하세요. 그런 다음 해당 설정으로 명확히 전환합니다. 일부 클라이언트는 ‘구독 추가’와 ‘현재 설정으로 지정’을 별도 단계로 나누므로, 추가만 해서는 실행 중인 코어가 새 파일을 자동으로 사용하지 않습니다. 프록시 그룹을 열어 실제로 선택할 수 있는 출구가 하나 이상 있는지 확인하고 설정 로드 로그도 살펴보세요. 지원하지 않는 필드라는 메시지가 나오면 구독이 대상 코어 형식인지 확인하세요. 파싱 오류를 방화벽이 연결을 차단한 것으로 오해하지 마세요.

시스템 프록시를 켜기 전에 클라이언트가 실제로 수신 중인 HTTP 또는 혼합 프록시 포트를 확인하세요. 아래 예시는 혼합 포트 7890을 사용합니다. 클라이언트가 실제로 해당 포트를 수신 중일 때만 그대로 실행하고, 그렇지 않으면 실제 포트로 바꾸세요. PowerShell에서는 curl.exe를 명시적으로 호출해 같은 이름의 명령 별칭과 혼동하지 않도록 합니다. 명시적 프록시 테스트는 해당 명령의 요청 경로만 확인하며, 다른 프로그램의 네트워크 설정을 자동으로 바꾸지는 않습니다.

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

명시적 프록시가 작동하는 것을 확인한 뒤 시스템 프록시를 켜세요. 브라우저에서 테스트 페이지를 열고 연결 목록에서 프로세스, 규칙, 출구를 확인합니다. Windows 사용자 프록시 설정, WinHTTP 설정, 앱 자체 프록시 설정은 항상 동기화되는 것이 아닙니다. 터미널 서비스나 백그라운드 작업은 현재 사용자의 설정을 전혀 따르지 않을 수도 있습니다. 특정 프로그램 하나를 프록시로 연결하려고 시스템 전체 서비스 프록시를 바로 변경하지 마세요. 먼저 해당 프로그램에 별도 프록시 매개변수가 있는지 확인하거나 TUN 처리가 실제로 필요한지 판단하세요.

필요한 경우 서비스 모드와 TUN 사용하기

TUN은 보통 클라이언트가 제공하는 권한 서비스를 설치하거나 실행해야 합니다. 권한 요청이 현재 사용 중인 클라이언트의 것인지 확인하세요. 권한을 부여한 뒤 서비스 상태를 확인하고 TUN을 켜 가상 인터페이스와 라우팅이 설정되는지 살펴봅니다. 올바른 서비스 설정 대신 모든 GUI를 관리자 권한으로 계속 실행할 필요는 없습니다. 실행에 실패했다면 권한 부족, 인터페이스 생성 실패, 라우팅 추가 실패를 로그에 따라 각각 해결하세요. 다른 터널 도구를 먼저 중지한 뒤 클라이언트의 복구 기능으로 서비스를 다시 설치합니다.

Windows 방화벽에서 허용하는 네트워크 프로필에 따라 기기 자체 및 로컬 네트워크와의 연결 동작이 달라집니다. 기기에서만 사용할 경우 ‘LAN 연결 허용’을 켤 필요가 없으며, 모든 네트워크에 대해 전체 인바운드 범위를 열어서도 안 됩니다. 다른 기기에서 사용해야 한다면 수신 주소, 인증, 방화벽의 허용 범위를 각각 제한하세요. UWP 앱은 로컬 프록시를 사용할 때 루프백 제한이 적용될 수 있습니다. 해당 앱이 실제로 제한 대상임을 확인한 경우에만 클라이언트에서 제공하는 루프백 예외 기능을 사용하고, 모든 앱에 권한을 확대하지 마세요.

절전 모드, 종료, 이전 후 확인할 사항

절전 모드에서 깨어나거나 무선 네트워크를 바꾼 뒤에는 클라이언트에 코어 프로세스가 남아 있는지, 구독이 정상적으로 로드됐는지 확인한 다음 트래픽 처리 기능을 다시 시작하세요. 클라이언트를 종료한 뒤 인터넷이 연결되지 않으면 시스템 설정의 수동 프록시가 종료된 로컬 포트를 가리키는지 확인합니다. 남은 프록시를 끄고 직접 연결을 테스트하세요. 이는 구독이 만료된 문제와 다릅니다. 새 클라이언트로 옮기기 전에는 기존 클라이언트에서 시스템 프록시와 TUN을 끄고 앱을 종료한 다음 백업을 가져오세요. 새 클라이언트가 독립적으로 작동하는 것을 확인한 후 기존 설정을 정리합니다. Windows 방화벽, 포트 점유, 권한 관련 문제는 Windows 설치 문제 해결 가이드를 참고하세요.

Apple Silicon과 Intel 구분하기

‘이 Mac에 관하여’에서 칩 정보를 확인한 뒤 해당 설치 파일을 선택하세요. Apple Silicon은 보통 ARM64, Intel은 x64에 해당합니다. 범용 설치 파일이 있다면 지원 범위를 릴리스 안내에서 확인하세요. macOS 다운로드에서는 Clash Plus를 우선 추천하며 Clash Verge Rev와 FlClash도 제공합니다. ClashX Meta는 유지 관리가 중단된 보관용 프로젝트입니다. 구형 클라이언트가 실행된다는 이유만으로 새 시스템의 네트워크 확장, 보안 체계, 권한 절차를 지원한다고 단정하지 마세요. 장기간 사용할 클라이언트는 현재 유지 관리 중인 것을 우선 선택하세요.

디스크 이미지를 연 뒤 안내에 따라 앱을 응용 프로그램 폴더로 옮기고, 해당 폴더에서 실행하세요. 마운트된 이미지에서 계속 실행하지 않는 것이 좋습니다. 처음 실행할 때 시스템이 차단하면 출처와 시스템 안내를 확인한 뒤 시스템 설정에서 해당 앱을 정상적으로 허용하세요. 보안 표시를 일괄 제거하거나 시스템 보호를 끄는 명령은 실행하지 마세요. 네트워크 확장, 백그라운드 보조 구성 요소, 시스템 권한을 요청하면 요청 주체의 이름과 용도를 확인합니다. 일반적인 구독 가져오기에는 네트워크와 무관한 광범위한 권한이 필요하지 않습니다.

설정 로드 및 활성 네트워크 서비스 확인

클라이언트의 설정 가져오기 메뉴에서 구독을 추가하고, 업데이트가 끝나면 현재 설정으로 선택한 뒤 프록시 그룹에서 출구를 고르세요. 먼저 명시적 프록시 요청을 실행한 다음 시스템 프록시를 켭니다. macOS 프록시 설정은 네트워크 서비스별로 적용됩니다. 무선 네트워크, 유선 어댑터, USB 어댑터가 서로 다른 설정을 유지할 수 있습니다. 도킹 스테이션을 연결하거나 네트워크를 전환한 후에는 이전에 변경했던 무선 네트워크의 프록시 화면만 보지 말고 현재 사용 중인 네트워크 서비스를 확인하세요. 네트워크 서비스 이름은 사용자가 바꿀 수 있으므로 명령 예시의 이름이 실제로 존재한다고 가정하면 안 됩니다.

아래 명령으로 먼저 서비스를 나열한 뒤 일반적인 무선 서비스의 HTTP 및 HTTPS 프록시를 확인할 수 있습니다. 목록의 서비스 이름이 Wi-Fi가 아니라면 실제 이름으로 바꾸세요. 조회 결과는 시스템에 기록된 프록시 설정만 보여 줍니다. 포트가 수신 중인지, 대상 앱이 해당 설정을 따르는지는 확인할 수 없습니다. 프록시 주소가 클라이언트에 표시된 주소와 일치하는지 확인하세요. 로컬 사용에서는 보통 루프백 주소를 가리키며, 구독 서버나 노드 서버 주소를 잘못 입력해서는 안 됩니다.

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"

TUN 권한과 여러 터널의 관계

클라이언트의 TUN 구현은 보조 서비스, 가상 인터페이스, 네트워크 확장에 의존할 수 있으며 권한 절차도 모두 같지는 않습니다. 사용 중인 클라이언트의 안내에 따라 구성 요소를 설치하고 시스템 설정에서 필요한 확인을 완료하세요. TUN을 켠 뒤 로그에 인터페이스 준비 및 라우팅 설정 완료가 표시되는지 확인합니다. 메뉴 막대 아이콘만 보고 상태를 판단하지 마세요. 시작할 때마다 권한을 반복해서 요청한다면 구성 요소가 예상한 위치에 설치됐는지, 관리 정책에 의해 차단됐는지, 앱이 임시 디렉터리에서 실행 중인지 확인하세요.

회사 VPN, 다른 네트워크 필터링 소프트웨어, 기존 터널은 TUN과 함께 기본 라우팅 및 DNS를 변경할 수 있습니다. 일부 도메인에 접속할 수 없다면 허용되는 경우 추가 터널을 끄고 단일 클라이언트 환경에서 테스트하세요. 알 수 없는 가상 인터페이스나 시스템 네트워크 설정 파일을 바로 삭제하지 마세요. 조직에서 관리하는 소프트웨어의 구성일 수 있습니다. 여러 터널을 함께 사용해야 한다면 목적지 네트워크별로 어떤 터널이 처리하는지 정하고, 내부 도메인 조회에 필요한 DNS에 계속 접속할 수 있는지도 확인하세요. 프록시 처리 후 사내 서비스에 접근하지 못하는 상황을 방지할 수 있습니다.

터미널 프록시, 인증서, 절전 후 복구

터미널 프로그램은 메뉴 막대에서 시스템 프록시가 켜져 있다는 이유만으로 해당 프록시를 자동 사용하지 않는 경우가 많습니다. 명령 자체의 프록시 옵션을 사용하거나 현재 터미널 세션에 프록시 환경 변수를 설정하세요. 테스트가 끝나면 변수를 해제해 클라이언트를 종료한 뒤에도 명령이 로컬의 빈 포트에 연결하지 않도록 합니다. HTTP, HTTPS, SOCKS 옵션은 의미가 다르며, 원격 DNS 조회와 로컬 DNS 조회도 다를 수 있습니다. 문제 해결 시에는 명확한 프록시 프로토콜 하나로 먼저 테스트하세요. 환경 변수, 앱 설정, TUN을 동시에 적용하면 요청 경로를 파악하기 어려워집니다.

HTTPS 인증서 오류를 인증서 검증을 끄는 방식으로 해결해서는 안 됩니다. 먼저 시스템 시간, 대상 사이트, 네트워크의 인증서 교체 정책을 확인하고 클라이언트 설정에서 트래픽 복호화 기능이 뜻하지 않게 켜져 있지 않은지 살펴보세요. 일반 프록시 연결에는 모든 웹사이트의 루트 인증서를 설치할 필요가 없습니다. 절전 모드에서 깨어난 뒤 일부 주소에만 접속할 수 있다면 네트워크를 다시 연결하고 프록시 처리를 재시작한 다음 DNS와 라우팅을 확인하세요. 클라이언트를 종료해도 문제가 계속되면 활성 네트워크 서비스의 남은 프록시 설정을 점검합니다. 업데이트 전에 구독과 오버라이드 설정을 보관하되, 기존 보조 구성 요소 파일을 새 설치 디렉터리에 수동으로 복사하지 마세요.

기기 아키텍처에 맞는 클라이언트 설치하기

Android 다운로드에서 클라이언트를 선택하세요. Clash Plus를 우선 추천하며, 설정 호환성에 따라 Clash Meta for Android, FlClash, Surfboard도 고려할 수 있습니다. 최신 기기는 대부분 ARM64를 사용하지만 실제 지원 아키텍처는 기기 사양을 기준으로 확인해야 합니다. 칩이 64비트라고 해서 모든 소프트웨어 환경이 64비트라고 단정할 수는 없습니다. 설치 중 기존 앱과 충돌한다면 패키지 이름, 서명 출처, 설치 경로를 먼저 확인하세요. 복구할 수 있도록 설정을 보관한 뒤 삭제 여부를 결정해야 합니다. 서명이 다른 설치 파일은 기존 앱 위에 바로 덮어쓸 수 없습니다.

브라우저나 파일 관리자에서 설치할 때 Android에서 해당 출처의 앱 설치를 허용하라고 요청할 수 있습니다. 현재 사용하는 출처에만 필요한 권한을 부여하고 설치 후에는 제한을 복원할 수 있습니다. 설치에 실패하면 시스템 버전 미지원, 아키텍처 불일치, 저장 공간 부족, 서명 충돌을 구분하세요. 같은 파일을 반복 다운로드해도 이 조건은 바뀌지 않습니다. 처음 실행할 때는 설정 목록, 프록시 그룹, 로그, 연결 스위치의 위치부터 확인하세요. 시작 시 자동 실행, VPN 상시 사용, 앱별 목록 등 모든 옵션을 한꺼번에 켜지 마세요.

구독 가져오기 및 VPN 연결 권한 승인

설정 화면에 구독 URL을 추가하고 업데이트한 뒤 해당 설정을 선택해 유효한 노드와 프록시 그룹이 있는지 확인하세요. Android 클립보드 접근, 파일 선택, QR 코드 가져오기 기능은 클라이언트마다 구현이 다르므로 메뉴 이름이 다를 수 있습니다. 링크를 가져온 뒤 설정 이름만 표시된다면 실제로 내용이 다운로드됐는지, 파싱 오류가 있는지 추가로 확인하세요. 모바일 네트워크에서는 구독을 가져올 수 없지만 Wi-Fi에서는 된다면 앱별 우회 목록을 바꾸기 전에 요청 경로와 제공 업체의 제한부터 확인하세요.

연결을 시작하면 시스템에 VPN 연결 요청이 표시되는 경우가 많습니다. 허용하면 클라이언트가 Android VPN 서비스를 통해 기기의 트래픽을 받습니다. 이는 데스크톱 TUN의 설정 항목과 모든 면에서 같은 기능이라는 뜻은 아닙니다. 시스템의 VPN 아이콘은 서비스가 만들어졌다는 것만 보여 줍니다. 실제 출구는 클라이언트 규칙과 연결 기록으로 확인해야 합니다. 일반적으로 같은 사용자 공간에서는 VPN 서비스 하나만 활성화할 수 있습니다. 다른 도구도 VPN 인터페이스를 사용한다면 나중에 실행한 도구가 먼저 실행된 서비스를 대체할 수 있으므로 어떤 연결을 유지할지 먼저 정하세요.

앱별 목록과 백그라운드 실행

앱별 설정에는 보통 ‘선택한 앱만 프록시 사용’과 ‘선택한 앱 우회’ 두 가지 방식이 있으므로 수정 전에 현재 모드를 확인해야 합니다. 브라우저를 목록에 추가한다고 해서 반드시 프록시를 우회하는 것은 아닙니다. 브라우저만 트래픽 처리 대상이 되는 설정일 수도 있습니다. 테스트용 앱 하나만 포함한 최소 목록을 만들고 저장한 뒤 클라이언트 안내에 따라 다시 연결하고 연결 기록을 확인하세요. 시스템 구성 요소, 업무 프로필, 다중 사용자 환경의 앱은 같은 목록에 나타나지 않을 수 있으므로 패키지 이름이 비슷하다는 이유만으로 처리 범위를 판단하지 마세요.

화면을 잠근 뒤 연결이 끊기면 배터리 최적화, 백그라운드 활동 제한, 클라이언트 알림 권한을 확인하세요. 일부 기기는 자동 실행 관리가 기본 배터리 설정과 별도로 제공되므로 해당 기기의 실제 화면을 기준으로 설정해야 합니다. 사용하는 클라이언트에 필요한 백그라운드 실행 권한만 부여하고 관련 앱 전체의 제한을 모두 풀 필요는 없습니다. 알림이 계속 표시돼도 코어가 작동한다는 보장은 없습니다. 잠금 해제 후 연결 시간, 로그, 요청이 코어에 계속 들어오는지 확인해 프로세스 종료와 네트워크 전환으로 인한 재연결을 구분하세요.

비공개 DNS, 핫스팟, 네트워크 전환

Android 비공개 DNS, 브라우저 보안 DNS, 클라이언트 DNS가 동시에 사용될 수 있으며 반드시 같은 경로로 조회하는 것은 아닙니다. ‘연결은 되지만 도메인이 열리지 않는’ 문제가 생기면 현재 비공개 DNS 설정을 기록한 다음 시스템 자동 모드로 잠시 바꿔 비교하고 클라이언트 DNS 로그를 확인하세요. 옵션을 끄는 것으로 장기적인 해결책을 삼기보다 어떤 조회 경로에 접속할 수 없거나 규칙과 맞지 않는지 찾아야 합니다. 회사나 학교에서 DNS 정책을 관리하는 기기라면 해당 관리 요구 사항을 따르세요.

휴대전화 핫스팟에 연결된 다른 기기의 트래픽이 자동으로 휴대전화 VPN을 통과한다고 볼 수 없습니다. 핫스팟 트래픽을 전달할 수 있는지는 시스템과 클라이언트 기능에 달려 있으므로 휴대전화에서 프록시가 작동한다는 이유만으로 단정하지 마세요. Wi-Fi에서 모바일 네트워크로 전환하면 기존 연결이 끊기고 새 DNS와 라우팅이 적용될 수 있습니다. 이전 페이지를 새로 고치는 데 그치지 말고 새 요청을 만들어 확인하세요. VPN 상시 사용이나 VPN 미사용 연결 차단을 켜 두었다면 클라이언트가 시작되지 않을 때 시스템이 전체 네트워크를 차단할 수 있습니다. 비활성화하거나 제거하기 전에 시스템 설정을 확인하고 복구 방법을 마련하세요.

Clash Plus 설치 및 기능 메뉴 확인하기

iPhone과 iPad에서는 Clash Plus를 우선 추천합니다. App Store의 Clash Plus 페이지에서 설치할 수 있으며 제품 웹사이트는 clashplus.io입니다. 이 사이트의 iOS 설치 페이지에서 App Store로 이동할 수도 있습니다. 설치 전에 스토어 페이지에서 시스템 요구 사항과 기기 호환성을 확인하세요. 기능 이름과 사용 가능한 설정은 실제 앱 화면을 기준으로 해야 합니다. 데스크톱 클라이언트의 메뉴 화면을 iOS 안내로 사용하지 마세요. 플랫폼마다 권한과 네트워크 인터페이스가 다릅니다.

처음 실행한 뒤 설정 관리, 연결 상태, 프록시 정책, 로그 메뉴를 먼저 찾으세요. 시스템에서 로컬 네트워크 접근이나 알림을 요청하면 실제 용도에 따라 허용 여부를 결정합니다. 이 권한은 VPN 설정 생성 권한과 별개입니다. 구독을 가져왔다고 트래픽이 바로 처리되는 것은 아니며, VPN 설정을 허용했다고 구독이 정상이라는 뜻도 아닙니다. ‘앱 설치 → 설정 로드 → 연결 승인 → 요청 확인’ 순서로 진행하면 화면, 설정, 시스템 권한 문제를 구분하기 쉽습니다.

클라이언트가 지원하는 구독 형식 사용하기

구독 주소를 복사한 뒤 앱의 설정 추가 또는 가져오기 메뉴에 붙여 넣고 업데이트한 다음 현재 설정으로 선택하세요. 구독 제공 업체가 해당 클라이언트의 가져오기 형식을 지원하는지 확인해야 합니다. Clash라는 이름이 붙은 구독이라고 모두 같은 기능을 제공하는 것은 아닙니다. 파일 가져오기를 지원한다면 시스템 파일 선택기로 읽을 수 있는 파일을 열고, 웹 페이지나 오류 응답이 아니라 실제 텍스트 설정을 가져왔는지 확인하세요. 공유 메뉴에 앱이 표시되는 것은 해당 앱이 콘텐츠를 받을 수 있다는 뜻일 뿐, 형식 호환성을 보장하지 않습니다.

가져오기가 끝나면 프록시 그룹에 선택 가능한 출구가 있는지, 설정이 활성화되어 있는지 확인한 뒤 처음 연결하세요. 구독 업데이트 중 인증 오류가 표시되면 링크가 온전한지, 계정이 유효한지, 제공 업체가 요청을 제한하는지 확인하세요. 모든 로컬 설정을 지우고 앱을 다시 설치하는 것은 첫 번째 해결 방법이 아닙니다. 직접 수정한 규칙은 업데이트 후 덮어써질 수 있으므로 클라이언트의 지속성 있는 확장 기능을 우선 사용하세요. 앱이 특정 mihomo 필드를 지원하지 않으면 설정 출력 형식을 바꾸거나 해당 기능을 지원하는 클라이언트를 사용하세요. 데스크톱 YAML을 억지로 복사해서는 안 됩니다.

VPN 설정 승인 및 실제 출구 확인

연결을 시작하면 iOS에서 VPN 설정 추가를 요청하고 기기 인증을 요구할 수 있습니다. 권한을 승인한 뒤 앱으로 돌아와 연결 상태를 확인하고, 필요하다면 시스템 설정에서 현재 VPN을 확인하세요. 이 터널은 앱이 시스템 네트워크 확장 기능과 연동해 만드는 것으로, 데스크톱의 ‘시스템 프록시’ 스위치를 휴대전화로 옮긴 것이 아닙니다. 화면에 연결됨이라고 표시되는 것은 터널 세션의 상태만 나타냅니다. 규칙이 예상대로 적용되는지, 대상 서비스가 현재 출구를 받아들이는지는 실제 접속과 클라이언트 기록으로 확인해야 합니다.

테스트할 때 먼저 접속 가능한 HTTPS 페이지를 연 다음 대상 앱을 확인하고, 두 요청이 클라이언트 연결 목록에 표시되는지 기록하세요. 웹페이지는 열리지만 특정 앱만 문제가 있다면 앱 자체 캐시, 계정 제한, UDP 필요 여부, 별도의 DNS 동작을 구분해 살펴보세요. VPN 표시가 있다고 해서 모든 연결이 선택한 노드를 통과한다고 단정하지 마세요. 규칙에 따라 로컬 네트워크, 특정 도메인, 그 밖의 대상은 직접 연결될 수 있습니다. 프록시 정책을 바꾼 뒤 새 연결을 테스트하세요. 기존 장기 연결은 이전 경로로 계속 통신할 수 있습니다.

필요 시 연결, LAN, 시스템 서비스의 범위

앱에서 필요 시 연결 기능을 제공한다면 먼저 수동 연결이 안정적인지 확인한 뒤 조건을 추가하세요. 여러 VPN 앱을 자주 전환하면 현재 활성 설정이 바뀔 수 있으므로 문제를 찾는 동안에는 명확한 연결 경로 하나만 유지하세요. 무선 네트워크 페이지의 수동 HTTP 프록시는 해당 네트워크에서 해당 설정을 따르는 트래픽에만 적용됩니다. 앱 터널과는 다른 계층입니다. 둘을 동시에 사용하면 프록시가 중복되거나 더 이상 작동하지 않는 LAN 주소를 가리킬 수 있으므로 설정을 따로 기록하고 각각 테스트하세요.

프린터, 홈 저장 장치, 기타 LAN 기기에 접속할 수 없다면 클라이언트에 LAN 우회 기능이 있는지, 시스템의 로컬 네트워크 권한이 해당 앱에 허용되어 있는지 확인하세요. iCloud 비공개 릴레이 같은 시스템 기능도 일부 요청 경로를 바꿀 수 있습니다. 조건이 허용된다면 원래 설정을 기록한 뒤 잠시 꺼서 비교할 수 있습니다. 회사에서 관리하는 기기나 앱별 VPN을 사용하는 경우 관리자가 정책 범위를 확인해야 합니다. 일반 프록시를 복구하려고 관리 프로필을 바로 삭제해서는 안 됩니다.

네트워크 전환, 시스템 업데이트, 기기 재시작 후에는 앱을 수동으로 다시 연결해야 하는지, 구독 업데이트가 가능한지, 필요 시 연결 조건이 현재 네트워크와 맞는지 다시 확인하세요. 앱을 삭제하기 전에 연결을 끊고 관련 필요 시 연결 설정을 정리한 뒤 구독 출처와 필요한 규칙을 백업하세요. 앱 샌드박스의 파일은 삭제 시 함께 사라질 수 있습니다. VPN을 끈 뒤에도 네트워크 문제가 계속되면 새 VPN 설정을 반복해서 만들기보다 무선 네트워크의 수동 프록시, DNS, 기기 관리 정책을 확인하세요. 인증서 오류는 시스템 시간, 사이트, 네트워크 인증서 체인을 살펴야 하며 검증을 꺼서 감춰서는 안 됩니다.

배포판과 아키텍처에 맞는 설치 방법 선택하기

Linux 데스크톱에서는 Clash Verge Rev를 우선 고려하고 FlClash도 사용할 수 있습니다. 패키지 형식은 Linux 다운로드에서 확인하세요. 먼저 uname -m으로 아키텍처를 확인한 뒤 배포판의 패키지 관리 시스템을 살펴봅니다. AMD64와 ARM64는 서로 바꿔 쓸 수 없고 DEB와 RPM도 직접 호환되는 파일이 아닙니다. 데스크톱 패키지의 호환 여부는 그래픽 세션과 런타임 라이브러리에도 달려 있습니다. 설치 프로그램에서 의존성 누락을 보고하면 배포판의 신뢰할 수 있는 저장소를 통해 해결하세요. 출처를 알 수 없는 공유 라이브러리 파일 하나를 내려받아 추가하지 마세요.

설치 후에는 일반 데스크톱 사용자로 앱을 실행하고 구독을 가져와 현재 설정으로 선택한 다음 프록시 그룹과 코어 로그를 확인하세요. GUI 앱을 설치할 때 필요한 권한과 코어의 네트워크 권한은 다릅니다. 데스크톱 앱 전체를 root로 계속 실행하지 마세요. 데스크톱 환경의 시스템 프록시는 해당 설정을 참조하는 앱에만 적용되는 경우가 많습니다. 터미널, 컨테이너, 패키지 관리자, 시스템 서비스는 별도의 설정을 사용할 수 있습니다. 명시적 프록시 테스트는 성공하지만 소프트웨어 업데이트 서비스가 연결되지 않는다면 해당 서비스의 프록시 설정부터 확인하세요. 코어가 고장 났다고 바로 판단해서는 안 됩니다.

mihomo 독립 실행 시 최소 확인 사항

서버나 라우터에서는 코어 다운로드에서 해당 빌드를 선택할 수 있습니다. 압축을 푼 뒤 실제 파일 이름을 확인해 변경하고 실행 권한을 부여한 다음 도움말 명령으로 실행 파일과 플랫폼의 호환성을 확인하세요. 설정은 별도 디렉터리에 저장하고 테스트 옵션으로 검사합니다. 테스트 중 규칙 집합 같은 리소스를 읽어야 할 수 있으므로 네트워크 오류와 문법 오류를 구분하세요. 아래 예시는 바이너리를 현재 디렉터리의 mihomo로 저장하고 설정을 config.yaml로 저장했다고 가정합니다. 명령만으로 시스템 서비스가 설치되지는 않습니다.

uname -m
chmod u+x ./mihomo
./mihomo -h
./mihomo -t -f ./config.yaml
./mihomo -f ./config.yaml

아래는 로컬 직접 연결 프록시만 제공하는 최소 기준 설정으로, 포트 수신 여부와 앱의 프록시 매개변수를 확인하는 데 사용할 수 있습니다. 원격 프록시 노드는 없으므로 원격 프록시 출구를 검증할 수는 없습니다. 이 설정으로 로컬 진입점을 확인한 뒤 신뢰할 수 있는 구독을 불러오세요. 정상 작동하는 구독 파일 끝에 최상위 키를 중복해서 붙이지 마세요. 같은 키를 여러 번 정의하면 파서가 오류를 내거나 값을 덮어써 실제 결과가 파일을 읽는 순서와 달라질 수 있습니다.

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

TUN, 라우팅, DNS에 필요한 권한

Linux에서 TUN을 사용하려면 시스템이 해당 장치와 필요한 네트워크 권한을 제공해야 합니다. 제한된 컨테이너, 공유 호스트, 최소 설치 시스템에는 사용할 수 있는 /dev/net/tun이 없을 수 있습니다. YAML만 수정해서는 호스트 환경의 기능을 추가할 수 없습니다. 로그에 권한 부족이 표시되면 실행 사용자, 서비스 제한, 장치 접근 가능 여부를 확인하세요. 모든 프로그램의 권한을 바로 확대하지 마세요. 필요한 코어 프로세스에만 권한을 부여하고, 업그레이드 후 바이너리 교체로 기존 권한 설정이 달라졌는지 확인하세요.

자동 라우팅을 켜기 전에 기본 경로, 원격 관리 접속 경로, 기존 방화벽 규칙을 기록하세요. 원격 서버에서 잘못된 라우팅 처리는 SSH 연결을 끊을 수 있으므로 작업 전에 콘솔이나 다른 복구 경로를 준비해야 합니다. DNS는 NetworkManager, systemd-resolved 또는 다른 서비스가 관리할 수 있습니다. 클라이언트의 DNS가 어느 포트에서 수신하는지, 시스템 요청이 그곳으로 어떻게 전달되는지 명확히 확인하세요. 코어의 DNS만 설정하고 시스템의 조회 경로를 바꾸지 않았다면 모든 앱이 해당 DNS를 사용하는 것은 아닙니다. 반대로 관리 대상인 해석 설정 파일을 덮어쓰고 계속 유지되기를 기대해서도 안 됩니다.

서비스, 컨테이너, LAN 경계

포그라운드 실행이 정상인지 확인한 뒤 배포판 방식에 맞춰 백그라운드 서비스를 설정하세요. 실행 파일의 절대 경로, 설정 경로, 작업 디렉터리, 실행 사용자를 명확히 지정해야 합니다. 서비스의 상대 경로는 대화형 터미널과 다를 수 있으며 규칙 파일과 캐시에도 적절한 쓰기 권한이 필요합니다. 시작에 실패하면 시스템 전체를 반복해서 재시작하지 말고 서비스 로그를 확인하세요. 서비스를 중지한 뒤 자동으로 추가된 라우팅과 DNS 설정이 복구됐는지 확인하고, 특히 기기 자체의 도메인 조회와 원격 관리가 가능한지 점검하세요.

컨테이너 내부의 루프백 주소는 컨테이너 자신을 가리키며 호스트를 가리키지 않습니다. 호스트 프록시 주소로 127.0.0.1을 입력해도 브리지 컨테이너에서 호스트에 연결되지 않는 경우가 많습니다. 프록시를 공유하려면 네트워크 진입점, 바인딩 주소, 방화벽 범위를 명확히 설계하고 인증도 고려해야 합니다. 모든 인터페이스로 수신 주소를 바꿔 인터넷에 노출해서는 안 됩니다. 라우터 배포에는 게이트웨이, DNS 전달, 투명 프록시 경로도 필요하므로 데스크톱 설정을 그대로 적용하지 마세요. 관련 네트워크 구성과 적용 범위는 OpenWrt 보조 라우터 설치 개요에서 확인할 수 있습니다. 일반 데스크톱 사용자는 프록시를 쓰기 위해 보조 라우터를 설치할 필요가 없습니다.

계층별로 확인한 뒤 수정하기

문제 해결은 ‘설정 로드 → 코어 수신 → 트래픽 처리 → 규칙 적용 → 출구 연결 → 대상 응답’ 순서로 진행하세요. 설정 파싱에 실패했다면 시스템 프록시와 TUN 스위치를 바꿔도 YAML 오류는 해결되지 않습니다. 코어가 포트를 수신하지 않으면 브라우저 프록시를 올바르게 설정해도 연결할 수 없습니다. 요청이 코어에 들어오지 않는다면 노드를 바꿔도 효과가 없습니다. 가장 먼저 실패한 계층을 찾아 구체적인 오류, 발생 시각, 작업 절차를 기록한 뒤 변수 하나만 변경하세요. 다른 사람에게 도움을 요청하기 전에 구독 인증 정보, 노드 로그인 정보, 연결 기록의 민감한 부분을 가리세요.

가져오기에 성공했지만 작동하지 않는다면 현재 어떤 설정이 적용됐는지, 시작할 때 클라이언트가 오버라이드를 병합하는지 확인하세요. YAML 들여쓰기는 공백을 사용하고 탭은 사용하지 마세요. 목록 계층, 콜론 뒤의 공백, 문자열 따옴표가 파싱에 영향을 줄 수 있습니다. 규칙에서 참조하는 프록시 그룹 이름은 실제로 존재하며 정확히 일치해야 합니다. 구독 제공 업체가 그룹 이름을 바꾼 뒤에도 기존 사용자 지정 규칙이 삭제된 그룹을 가리킬 수 있습니다. 이런 문제는 규칙 대상을 수정해야 하며 시스템 DNS를 바꿔서는 해결되지 않습니다.

규칙은 위에서부터 적용하고 기본 규칙은 마지막에 두세요

mihomo의 일반 규칙은 위에서 아래로 적용하며 처음 일치하는 규칙이 선택됩니다. 도메인 규칙은 서비스별 트래픽 분기에, IP 대역 규칙은 명확한 네트워크 범위를 지정하는 데 적합합니다. MATCH는 앞선 규칙에 일치하지 않은 연결을 처리합니다. 아래 예시는 규칙 순서를 보여 주기 위한 것으로 내장 직접 연결 및 거부 정책만 사용하며 전체 구독 설정은 아닙니다. no-resolve는 해당 IP 규칙을 적용하기 위해 도메인 조회를 새로 시작하지 않도록 합니다. 모든 DNS를 끄는 옵션은 아닙니다. 기존 구독은 클라이언트 확장 기능을 통해 규칙을 넣고 구독의 기본 규칙보다 앞에 배치됐는지 확인하세요.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - DOMAIN-SUFFIX,invalid,REJECT
  - MATCH,DIRECT

수정 후 새 연결을 만들어 실제로 적용된 규칙을 확인하세요. 규칙 파일에 대상 도메인이 있다는 것만으로는 충분하지 않습니다. 앱이 여러 도메인에 연결하거나 캐시된 주소를 사용하거나 기존 연결을 재사용하면 페이지 하나를 열 때도 서로 다른 정책의 기록이 여러 개 나타날 수 있습니다. 프록시가 필요하다면 규칙 대상이 설정에 실제로 존재하는 프록시 그룹인지 확인하세요. 임의의 그룹 이름만 붙여 넣어서는 안 됩니다. 규칙 종류, 우선순위, 적용 관계는 사용자 지정 규칙 문법과 우선순위에서 자세히 확인할 수 있습니다.

요청 경로와 함께 DNS 설정 확인하기

DNS는 도메인을 IP 주소로 변환하고, 규칙과 라우팅은 이후 연결을 어디로 보낼지 결정합니다. Fake-IP 모드는 가상 주소를 이용해 도메인 매핑을 유지합니다. Redir-Host는 보통 앱에 실제 조회 결과를 반환합니다. 두 방식은 단순히 속도를 비교할 수 있는 기능이 아닙니다. Fake-IP를 켠 뒤 특정 LAN 서비스나 기기에 문제가 생기면 예외 범위부터 마구 넓히지 말고 예외 도메인과 실제 트래픽 처리 경로를 확인하세요. DNS 유출 여부도 요청이 실제로 어디로 전송되는지 살펴봐야 합니다. 검사 페이지에 표시된 DNS 서비스 이름만으로 결론 내리지 마세요.

브라우저의 자체 암호화 DNS, Android 비공개 DNS, 시스템 리졸버, 코어 리졸버가 동시에 동작할 수 있습니다. 문제를 해결할 때는 명확한 경로 하나로 먼저 테스트한 뒤 다른 설정을 하나씩 복원하세요. 암호화 DNS 주소에도 접속 가능한 연결 경로가 필요합니다. 잘못된 프록시 의존성은 시작 단계의 순환 문제를 일으킬 수 있습니다. 노드 도메인을 조회해야 노드에 연결할 수 있는데, 조회 요청은 아직 연결되지 않은 노드를 거치도록 설정하는 경우입니다. GeoIP 또는 GeoSite에 의존하는 규칙은 데이터베이스 다운로드 성공 여부와 현재 코어에서 지원하는 필드인지도 확인하세요. 자세한 방법은 GeoIP 및 GeoSite 업데이트 안내를 참고하세요.

지연 시간, 대역폭, 연결 안정성을 구분하세요

노드 지연 시간 테스트는 특정 조건에서 지정한 테스트 주소에 요청하는 데 걸린 시간을 주로 측정하며 실제 다운로드 대역폭을 나타내지는 않습니다. 지연 시간이 낮은 노드도 혼잡, 출구 제한, 대상 서비스 정책에 따라 성능이 좋지 않을 수 있습니다. 테스트 대상, 시간대, 네트워크 종류, 출구를 기록하고 같은 조건에서 결과를 비교하세요. 여러 설정을 연속해서 바꾼 뒤 하나의 결론만 남기지 마세요. 핸드셰이크와 URL Test의 차이는 지연 시간 테스트와 실제 속도 비교에서 확인하고, 다른 문제는 자주 묻는 질문을 참고하세요.

설치 순서의 반대로 복구하세요. 먼저 TUN 또는 앱 터널을 끄고, 다음으로 시스템 프록시를 끈 뒤 마지막에 코어를 종료합니다. 시스템 DNS와 기본 라우팅이 예상대로 돌아왔는지 확인하세요. 마지막으로 정상 작동한 설정과 변경 기록을 보관해 다음 문제 발생 시 해당 기준으로 되돌릴 수 있도록 합니다. 특정 서비스 하나만 작동하지 않고 다른 프록시 요청과 직접 연결은 정상이라면 클라이언트를 다시 설치하기보다 해당 서비스의 계정, 인증서, 지역 제한, 프로토콜 요구 사항을 확인하세요. 처음 설치하는 과정은 빠른 시작 가이드로 돌아가 단계별로 다시 점검할 수 있습니다.