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

공통 준비 사항

클라이언트, 커널, 연결 설정

Clash 생태계에서는 세 가지 계층을 구분해야 합니다. 클라이언트는 인터페이스, 설정 관리, 시스템 연동을 담당하고, 커널은 프로토콜 연결, 규칙 판정, DNS를 처리합니다. 구독이나 로컬 설정에는 서버, 프록시 그룹, 규칙이 포함됩니다. 설치를 마쳤다고 해서 사용할 수 있는 연결 경로까지 준비된 것은 아닙니다. 이 문서의 데스크톱 설정 예제는 mihomo 기준입니다. 다른 구현체는 지원하는 필드를 확인하고 사용해야 하며, 이름이 비슷하다는 이유만으로 그대로 적용해서는 안 됩니다.

클라이언트를 고를 때는 Clash Plus를 먼저 살펴보고, 운영체제와 사용 방식에 따라 다른 클라이언트와 비교하세요. Windows, macOS, Android, iOS용 클라이언트가 있으며 Linux에서는 Clash Verge Rev나 FlClash를 선택할 수 있습니다. 인터페이스에 따라 같은 기능을 설정, 구독, 프로필 등으로 부를 수 있습니다. 이름보다 기능을 기준으로 판단하세요. 원격 주소를 저장하는 것은 설정 소스, 연결 출구를 선택하는 것은 프록시 그룹, 어떤 앱의 트래픽을 프록시로 보낼지 정하는 것은 트래픽 처리 설정입니다.

아키텍처와 설정 출처 확인

먼저 시스템 정보에서 운영체제, 프로세서 아키텍처, 사용 가능한 저장 공간을 확인하세요. Intel 및 AMD 데스크톱 프로세서는 보통 x64 또는 AMD64 패키지를, Apple Silicon은 ARM64 패키지를 사용합니다. Windows ARM 기기도 별도로 확인해야 합니다. 파일 확장자는 배포 형식만 나타낼 뿐 아키텍처를 알려주지 않습니다. 프로그램이 실행되지 않으면 네트워크 설정부터 바꾸지 말고 설치 파일과 시스템이 맞는지 먼저 확인하세요.

신뢰할 수 있는 서비스에서 제공한 Clash 호환 구독 주소나 검증된 YAML 파일을 준비하세요. 구독 링크에는 계정을 식별할 수 있는 정보가 포함될 수 있으므로 로그, 스크린샷, 설정 파일을 공유하기 전에 쿼리 매개변수와 서버 인증 정보를 삭제해야 합니다. 브라우저에서 링크가 열린다고 해서 클라이언트가 가져올 수 있는 것은 아닙니다. 로그인 페이지나 트래픽 안내 페이지, 다른 형식의 내용이 반환될 수 있습니다. 클라이언트의 파싱 결과와 설정의 실제 필드를 기준으로 확인하세요.

재현 가능한 연결 기준선부터 만들기

첫 테스트에서는 다른 프록시 클라이언트를 종료하고 불필요한 VPN을 잠시 끈 뒤, 기존 시스템 프록시와 DNS 설정을 기록하세요. 설정을 가져온 다음 규칙 모드를 선택하고, 정상 작동이 확인된 경로 하나를 직접 지정합니다. 같은 브라우저로 원래 직접 연결되는 사이트와 프록시가 필요한 사이트에 접속하면서 연결 로그를 확인하세요. 두 사례를 함께 테스트하면 직접 연결 경로와 프록시 경로를 각각 확인할 수 있어 지연 시간 하나만 보는 것보다 원인을 파악하기 쉽습니다.

시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 연결 경로를 제공하며, 브라우저 같은 데스크톱 소프트웨어에 적합합니다. TUN은 가상 인터페이스와 라우팅을 이용해 더 많은 IP 트래픽을 처리하며, 관리자 권한, DNS 가로채기, 다른 VPN과의 충돌이 발생할 수 있습니다. 어느 쪽도 연결 경로 자체를 바꾸거나 서버 측 장애를 해결하지는 않습니다. 먼저 프록시 출구를 확인한 뒤 처리 범위를 넓히면 출구 문제를 가상 네트워크 카드 문제로 오인하는 일을 줄일 수 있습니다.

아래는 로컬 진단용 최소 설정입니다. 프록시 노드는 포함하지 않으며, 지원되는 연결을 직접 연결합니다. YAML을 불러올 수 있는지와 포트에서 연결을 수신할 수 있는지 확인하는 용도이지 해외 프록시 연결을 테스트하는 용도는 아닙니다. 실제 사용 시에는 서비스에서 제공한 설정을 불러오고, 클라이언트가 포트를 덮어쓰는지 확인하세요. 기존 설정에 같은 최상위 필드가 있다면 해당 필드를 수정해야 하며, 파일 끝에 중복해서 추가하면 안 됩니다.

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

백업에는 노드 목록뿐 아니라 트래픽 처리 방식과 권한 상태도 포함해야 합니다. 이 장의 준비를 마쳤다면 사용하는 플랫폼의 장만 확인하세요. 다섯 플랫폼의 명령을 모두 실행할 필요는 없습니다. 커널, 프록시 그룹, fake-ip 같은 용어를 먼저 이해하고 싶다면 용어집을 확인한 뒤, 각 용어를 인터페이스의 해당 옵션과 비교해 보세요.

Windows 설치 및 설정

설치 파일 선택 및 첫 실행

Windows 다운로드 페이지에서 Clash Plus를 선택하세요. 다른 인터페이스가 필요하다면 Clash Verge Rev, FlClash, Clash Nyanpasu 순으로 비교해 볼 수 있습니다. Clash for Windows는 유지 관리가 중단되었으므로 기존 환경을 보관하는 용도로만 고려하고, 새 기기의 기본 선택으로는 권장하지 않습니다. 클라이언트를 바꿀 때는 이전 프로그램을 먼저 종료해 여러 프로세스가 시스템 프록시를 동시에 수정하거나 로컬 수신 포트를 점유하지 않도록 하세요.

설정의 시스템 정보에서 시스템 유형을 확인하고 x64와 ARM 기기를 구분하세요. 설치 경로를 쉽게 확인할 수 있도록 유지하고, 실행 후 기본 창과 시스템 트레이 아이콘이 모두 작동하는지 확인합니다. 시스템 보안 경고가 나타나면 다운로드 출처와 배포 정보를 확인하고 시스템 안내에 따라 조치하세요. 프로그램 실행을 위해 보안 기능 전체를 끄지 마세요. 회사에서 관리하는 기기는 설치나 서비스 등록이 제한될 수 있으므로 기기 관리 정책을 따라야 합니다.

처음 실행하면 커널 상태와 설정 목록부터 확인하세요. 일부 클라이언트는 인터페이스가 열린 뒤 설정을 선택해야 커널을 사용할 수 있습니다. 창은 표시되지만 로그에 포트 점유 경고가 계속 나타난다면 다른 프록시 프로그램을 종료하고 백그라운드에 이전 프로세스가 남아 있는지 확인하세요. 반복해서 재설치해도 다른 상주 서비스가 원인인 포트 충돌은 해결되지 않을 수 있습니다.

구독을 가져오고 프록시 그룹 확인

설정 또는 구독 관리 페이지에서 원격 설정 추가를 선택하고 이름과 구독 주소를 입력한 뒤 저장하세요. 가져오기와 파싱이 완료되면 해당 설정을 직접 선택해야 합니다. 추가에 성공했다고 자동으로 전환되는 것은 아닙니다. 프록시 페이지에 노드와 프록시 그룹이 표시되는지 확인한 다음, 규칙에서 실제로 참조하는 그룹으로 이동해 경로를 선택하세요. DIRECT 같은 기본 전략만 보인다면 시스템 프록시를 계속 켜지 말고 설정 로그에서 구독 내용을 확인하세요.

원격 업데이트에 실패하면 다운로드 실패와 파싱 실패를 구분하세요. 다운로드 실패는 주소 만료, 인증, 접근 경로 문제일 수 있고, 파싱 실패는 웹페이지가 반환되거나 들여쓰기가 잘못되었거나 커널이 필드를 지원하지 않을 때 흔히 발생합니다. 기존에 사용 가능한 설정은 유지하고 바로 삭제한 뒤 다시 만들지 마세요. 클라이언트에 프록시를 통한 업데이트 옵션이 있다면 현재 프록시가 정상 작동할 때만 시도하세요. 그렇지 않으면 설정을 다운로드하려면 먼저 연결해야 하는 순환 문제가 생깁니다.

시스템 프록시, TUN, 권한

먼저 시스템 프록시를 켜고 브라우저에서 규칙 모드를 테스트하세요. 시스템 프록시 주소는 실제로 수신 중인 로컬 포트를 가리켜야 합니다. 여기 예시의 7890이 모든 클라이언트의 고정 포트는 아닙니다. Windows 수동 프록시와 자동 구성 스크립트는 서로 다른 설정이며, 오래된 스크립트가 남아 있으면 예상한 설정을 덮어쓸 수 있습니다. 클라이언트의 프록시를 끈 뒤에도 시스템 설정이 복원되었는지 확인하세요. 특히 프로그램이 비정상 종료된 경우에는 꼭 확인해야 합니다.

시스템 프록시를 따르지 않는 앱의 트래픽도 처리해야 한다면 클라이언트가 TUN을 지원하는지 확인하세요. 보통 서비스를 설치하거나 허용된 권한으로 관련 구성 요소를 실행해야 합니다. 서비스 설치와 매번 인터페이스를 관리자 권한으로 실행하는 것은 다릅니다. 클라이언트 자체의 서비스 관리 기능을 우선 사용하고 안내에 따라 커널을 다시 시작하세요. 활성화한 뒤에는 가상 인터페이스, 기본 경로, DNS 로그를 확인하세요. 스위치 색상만으로 트래픽 처리 성공 여부를 판단하면 안 됩니다.

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

이 설정은 mihomo의 TUN 매개변수만 보여 주며 전체 구독을 대신하지 않습니다. 클라이언트가 해당 필드를 관리할 수 있으므로 파일을 직접 수정하기 전에 인터페이스에서 덮어쓰는지 확인하세요. auto-route는 경로를 추가하고, auto-detect-interface는 출구 인터페이스를 식별하며, dns-hijack은 조건에 맞는 DNS 트래픽을 커널에서 처리하도록 전달합니다. 활성화 후 인터넷이 끊기면 먼저 TUN을 꺼서 기준 상태를 복구한 다음 라우팅과 DNS를 하나씩 확인하세요.

Windows에서만 발생하는 문제와 종료 순서

브라우저는 정상인데 명령줄에서 실패한다면 명령줄 도구가 시스템 프록시를 읽지 않는 경우가 흔합니다. 요청 한 번에 프록시를 명시해 앱 연동 문제와 노드 장애를 구분할 수 있습니다. 아래 명령은 Windows 기본 curl 실행 파일을 사용합니다. 포트는 현재 실제 수신 포트로 바꾸세요. 테스트 주소만으로 프록시 출구가 정상이라고 판단할 수는 없으므로 로그에서 요청에 어떤 정책이 적용되었는지 함께 확인해야 합니다.

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

절전 모드에서 복귀하거나 Wi-Fi와 유선 네트워크를 전환하면 출구 인터페이스가 바뀔 수 있습니다. 시스템 프록시 모드는 정상인데 TUN만 작동하지 않는다면 먼저 커널을 다시 시작해 인터페이스를 재인식시키고, 다른 VPN, 가상 머신 네트워크, 방화벽 규칙을 확인하세요. 종료할 때는 트래픽 처리를 끄고 시스템 프록시가 복원되었는지 확인한 뒤 프로그램을 종료합니다. 가상 네트워크 카드를 바로 삭제하거나 네트워크를 일괄 초기화하지 마세요. 영향 범위가 커지고 문제를 파악하는 데 필요한 기존 상태도 사라집니다.

macOS 설치 및 설정

칩 아키텍처와 설치 방식 구분

Apple 메뉴의 ‘이 Mac에 관하여’에서 칩 정보를 확인하세요. Apple Silicon에는 ARM 패키지, Intel 모델에는 x64 패키지가 해당합니다. macOS 다운로드 페이지에서 Clash Plus를 우선 확인하고, 다른 선택지로 Clash Verge Rev와 FlClash를 비교할 수 있습니다. ClashX Meta는 유지 관리가 중단되었습니다. 이전 설정을 확인하는 용도로 남겨 둘 수 있지만, 현재의 모든 설정 필드를 해당 커널이 지원한다고 가정해서는 안 됩니다.

디스크 이미지 파일을 받았다면 열어서 배포 안내에 따라 앱을 응용 프로그램 폴더로 옮긴 다음 그곳에서 실행하세요. 이미지 볼륨에서 계속 실행하면 업데이트, 보조 구성 요소 경로, 재시작 후 실행 경로가 달라질 수 있습니다. 처음 실행할 때 보안 제한이 나타나면 시스템의 개인정보 보호 및 보안 설정에서 해당 안내를 읽고 출처를 확인하세요. 출처가 불분명한 터미널 명령으로 시스템 보안 제한을 일괄 해제하지 마세요.

일부 데스크톱 클라이언트는 메뉴 막대에 상주하므로 창을 닫아도 커널이 종료되지 않습니다. 설정을 시작하기 전에 메뉴 막대와 활성 상태 보기를 확인해 다른 프록시가 백그라운드에서 실행 중이지 않은지 살펴보세요. 인터페이스에 설정이 표시되지 않는다면 현재 사용자의 데이터 디렉터리 접근 권한부터 확인하세요. 응용 프로그램 폴더와 설정 폴더를 혼동하지 마세요. 기기를 옮길 때는 클라이언트에서 설정을 내보내거나 지정된 디렉터리를 백업해야 하며, 앱 자체만 복사해서는 안 됩니다.

구독 가져오기 및 설정 유지

설정 관리에서 원격 주소를 추가하고, 가져오기가 완료될 때까지 기다린 다음 현재 설정으로 지정하세요. 노드 목록과 프록시 그룹이 표시되는지 확인하고 원하는 경로를 선택합니다. macOS 클라이언트의 메뉴 막대 단축 메뉴는 프록시 그룹만 전환하고 설정 출처는 바꾸지 않는 경우가 많습니다. 노드가 바뀌지 않으면 같은 프록시 그룹을 반복해서 누르기보다 현재 설정 이름을 먼저 확인하세요. 설정 이름에 용도를 표시하면 같은 이름의 항목을 잘못 고르는 일을 줄일 수 있습니다.

로컬 YAML의 상대 경로는 보통 다운로드 폴더가 아니라 클라이언트 설정 디렉터리를 기준으로 합니다. 설정에서 규칙 세트, 인증서 또는 다른 파일을 참조한다면 커널이 실제로 해당 파일을 읽을 수 있는지 확인하세요. 원격 구독은 업데이트 기능을 유지하고, 사용자 필드는 클라이언트가 지원하는 덮어쓰기 기능으로 관리해야 합니다. 업데이트할 때마다 최종 설정의 규칙 순서를 확인하세요. 로컬에서 추가한 규칙이 MATCH 뒤에 놓이면 적용되지 않을 수 있습니다.

네트워크 서비스 프록시 및 보조 구성 요소

시스템 프록시를 켜고 브라우저로 연결을 테스트하세요. macOS의 프록시 설정은 네트워크 서비스별로 관리되므로 Wi-Fi, 유선 네트워크 카드, 다른 네트워크 서비스마다 설정이 다를 수 있습니다. 연결 방식을 바꾼 뒤 갑자기 작동하지 않는다면 현재 활성 서비스가 올바른 로컬 주소와 포트를 가리키는지 확인하세요. 클라이언트를 종료한 뒤에도 네트워크에 문제가 있으면 DNS를 바로 수정하지 말고 해당 서비스의 프록시 설정부터 확인해야 합니다.

아래 읽기 전용 명령으로 현재 시스템 프록시 요약을 확인할 수 있습니다. 활성화 여부, 호스트, 포트를 중점적으로 살펴보세요. 이 명령은 설정을 바꾸지 않으며 앱마다 다른 프록시 동작을 보여 주지도 않습니다. 요약 내용이 클라이언트 인터페이스와 다르면 시스템 프록시를 껐다가 다시 켜고, 다른 네트워크 도구가 설정을 계속 덮어쓰는지 확인하세요. 조직에서 관리하는 구성 프로파일이 옵션을 잠가 놓았을 수도 있습니다.

scutil --proxy

TUN은 가상 인터페이스와 경로를 설정하기 위해 클라이언트의 권한이 있는 보조 구성 요소를 사용하는 경우가 많습니다. 보조 구성 요소를 설치할 때는 시스템 권한 요청을 읽고 현재 사용하는 클라이언트에서 요청한 것인지 확인하세요. 권한 부여에 실패하면 앱 로그에 표시된 구체적인 서비스 오류부터 확인하고, 암호를 반복해서 입력하지 마세요. 학교나 회사 기기는 네트워크 확장 기능이나 시스템 서비스 설치가 제한될 수 있습니다. 이 경우 관리 정책을 우회하려 하지 말고 허용된 트래픽 처리 방식을 사용하세요.

절전 복귀, 로컬 네트워크, 앱별 차이

절전 모드에서 복귀하면 현재 네트워크에 다시 인증해야 하는지, 커널이 인식한 출구가 바뀌었는지 먼저 확인하세요. TUN만 작동하지 않는다면 구독을 다시 가져올 필요 없이 커널을 먼저 재시작할 수 있습니다. 프린터, 네트워크 저장 장치, 로컬 네트워크 서비스에 문제가 있으면 해당 연결이 프록시로 전달되는지와 적용 규칙을 확인하세요. 사용 중인 네트워크에 맞는 정확한 직접 연결 규칙을 추가하고, 모든 사설 주소 범위를 원격 출구로 보내지 마세요.

터미널 프로그램의 프록시 사용 여부는 메뉴 막대 아이콘이 아니라 프로그램 자체와 환경 변수에 따라 달라집니다. 명시적인 프록시 매개변수로 한 번 테스트한 뒤 터미널 환경을 설정할지 결정하세요. 사용을 마치면 TUN과 시스템 프록시를 끈 다음 클라이언트를 종료하고 네트워크 서비스 설정이 복원되었는지 확인하세요. 제거 전에 클라이언트가 제공하는 기능으로 더 이상 필요하지 않은 보조 서비스를 삭제해야 앱을 지운 뒤에도 구성 요소가 실행되는 일을 막을 수 있습니다.

Android 설치 및 설정

설치 출처, 아키텍처, 업데이트

Android 다운로드 페이지에서 Clash Plus를 선택하거나 Clash Meta for Android, FlClash, Surfboard를 비교해 보세요. 앱마다 지원하는 설정 형식과 고급 필드가 다르며, 특히 모든 앱이 mihomo의 전체 YAML을 그대로 사용한다고 가정해서는 안 됩니다. 기존 구독 형식과 호환되는 앱을 먼저 고른 뒤 인터페이스 사용성을 비교하면 이후 변환과 문제 해결을 줄일 수 있습니다.

최근 스마트폰은 대부분 ARM64를 사용하지만 구형 기기, 에뮬레이터, 특수 시스템은 다를 수 있습니다. 확인이 어려우면 기기 사양이나 다운로드 페이지의 호환 안내를 살펴보세요. 앱 패키지를 설치할 때는 실제로 사용할 브라우저나 파일 관리자에만 필요한 설치 권한을 부여하고, 설치 후에는 권한을 회수할 수 있습니다. 설치된 앱과 충돌한다는 메시지가 나오면 패키지 이름, 서명, 출처를 확인하세요. 설정과 로컬 규칙이 사라질 수 있으니 기존 앱을 성급하게 삭제하지 마세요.

업데이트 전에 구독 주소, 프록시 그룹 선택, 앱별 설정을 기록하세요. 덮어쓰기 업데이트로 데이터가 유지되는지는 앱 ID와 서명이 같은지에 따라 달라집니다. 아이콘이나 표시 이름만으로 판단해서는 안 됩니다. 서로 다른 클라이언트 사이에서는 앱 내부 설정을 완전히 옮기기 어려운 경우가 많습니다. 같은 구독을 가져오더라도 VPN 권한, 앱 제외 설정, 백그라운드 실행 권한을 다시 확인해야 합니다. 가져오기 전에 기존 클라이언트의 정상 작동 상태를 보존하세요.

설정 가져오기 및 시스템 VPN 권한

설정 관리 페이지에서 구독 주소를 추가하고 다운로드가 끝나면 해당 설정을 선택한 뒤 프록시 또는 정책 페이지에서 경로를 확인하세요. 반환된 내용을 파싱할 수 없다면 먼저 클라이언트가 지원하는 형식을 확인하고 설정 제공자에게 호환 방법을 문의하세요. 계정 정보가 포함된 주소를 출처가 불분명한 변환 페이지에 입력하지 마세요. 오프라인 파일 가져오기는 다운로드 경로를 확인하는 데 유용하지만 원격 구독 변경 사항을 자동으로 반영하지 않으므로 이후 관리 방법을 정해야 합니다.

연결을 누르면 Android에서 보통 VPN 연결을 설정할지 시스템 확인 창이 표시됩니다. 이 권한은 앱이 로컬 가상 인터페이스를 만들도록 허용하는 것으로, 기존 VPN 서비스 사업자에 연결된다는 뜻은 아닙니다. 실제 출구는 설정의 정책에 따라 결정됩니다. 상태 표시줄에 VPN 아이콘이 나타나도 인터페이스가 생성되었다는 의미일 뿐입니다. 웹페이지를 열고 연결 로그를 확인해 대상 앱이 실제로 선택한 경로를 사용하는지 살펴보세요.

Android에서는 일반적으로 일반 VPN 서비스를 하나만 활성화할 수 있어 다른 VPN 앱이 현재 클라이언트를 대체할 수 있습니다. 로컬 방화벽, 트래픽 필터, 일부 가속 앱도 같은 방식을 사용할 수 있습니다. 연결 직후 끊어진다면 노드를 바꾸기 전에 이런 앱과 시스템의 상시 연결 VPN 설정을 확인하세요. 데스크톱 시스템 프록시의 설정 절차를 휴대전화에 그대로 적용할 수는 없습니다. 트래픽을 처리하는 진입점이 다릅니다.

앱별 프록시 및 백그라운드 실행

앱별 기능에는 보통 선택한 앱만 프록시로 보내는 방식과 선택한 앱을 제외하는 방식이 있으며, 두 기능의 의미는 반대입니다. 설정 전에 현재 모드를 확인하고 앱 하나로 테스트하세요. 제외된 앱은 커널을 완전히 우회할 수 있으므로 로그에 연결이 나타나지 않아도 규칙이 로드되지 않은 것이 아닙니다. 앱 목록을 바꾼 뒤 VPN 인터페이스를 다시 만들어야 할 수 있습니다. 클라이언트 안내에 따라 연결을 끊었다가 다시 연결하세요.

화면이 켜져 있을 때는 정상인데 잠금 후 연결이 끊긴다면 배터리 최적화, 백그라운드 활동 제한, 제조사별 자동 실행 관리 설정을 확인하세요. 사용 중인 클라이언트에 필요한 권한만 허용하고 문제가 해결되는지 확인하세요. 모든 앱의 권한을 한꺼번에 풀 필요는 없습니다. 절전 모드, 장시간 대기, 메모리 부족 시 일부 시스템은 여전히 서비스를 종료할 수 있습니다. 매번 연결이 복구될 때마다 회선 문제로 단정하지 말고 끊긴 시점의 시스템 상태와 비교하세요.

모바일 네트워크, DNS, 핫스팟 범위

Wi-Fi에서 모바일 데이터로 전환하면 네트워크 주소와 경로가 바뀌고 기존 연결이 끊길 수 있습니다. 잠시 재연결을 기다린 뒤 클라이언트가 네트워크를 다시 인식했는지 확인하세요. 특정 네트워크에서만 실패한다면 네트워크 인증, DNS 접근성, 프록시 서버 접근성을 구분해야 합니다. 공항이나 호텔처럼 웹페이지 로그인 인증이 필요한 네트워크는 프록시 연결 전에 인증을 완료해야 할 수 있습니다. 인증하지 않으면 모든 노드가 작동하지 않는 것처럼 보입니다.

시스템 비공개 DNS, 앱 자체의 보안 DNS, 클라이언트 DNS가 동시에 작동할 수 있으므로 스위치 하나만 바꿔 전체 DNS 경로가 통일되었다고 판단해서는 안 됩니다. 클라이언트 로그와 테스트 결과를 함께 확인해 도메인을 누가 처리하는지 파악하세요. 검사 페이지에 표시된 DNS 위치를 곧바로 유출 여부와 동일시하지 마세요. 프록시 서버가 있는 네트워크, 재귀 리졸버의 출구, 검사 페이지의 식별 방식이 결과에 영향을 줄 수 있습니다.

장시간 사용하기 전에 세 가지를 확인하세요. 잠금 후 연결이 복구되는지, 네트워크 전환 후 수동으로 다시 연결해야 하는지, 제외한 앱이 의도대로 직접 연결되는지 테스트합니다. 일반 규칙 모드 설정을 기준선으로 보관하세요. 문제가 생기면 먼저 앱별 설정 같은 추가 옵션을 끈 다음 하나씩 다시 켜세요. 기본 연결, 시스템 백그라운드 제한, 앱 선택 규칙 중 어디에서 문제가 발생하는지 확인할 수 있습니다.

iOS 설치 및 설정

스토어 설치 및 기능 범위

iPhone과 iPad에서는 Clash Plus를 우선 선택하세요. App Store의 Clash Plus 페이지에서 설치하고 공식 사이트 clashplus.io에서 제품 정보를 확인할 수 있습니다. 다운로드 링크는 iOS 플랫폼 페이지에도 모아 두었습니다. 설치 전에 스토어의 시스템 호환 요건을 읽고 기기에 실제로 표시되는 정보를 기준으로 판단하세요. 클라이언트 이름만 보고 지원 범위를 추측하지 마세요.

iOS 앱은 시스템 네트워크 확장 기능과 샌드박스의 제약을 받으므로 데스크톱 클라이언트와 사용 방식이 다릅니다. 이 문서에서는 설정, 정책, 연결 등의 기능 이름으로 절차를 설명하며 구체적인 버튼 이름은 현재 인터페이스를 기준으로 확인하세요. 데스크톱 설정에 특정 mihomo 필드가 있다고 해서 모바일 앱도 같은 필드를 해석한다고 가정하면 안 됩니다. 가져오기 결과, 앱 안내, 실제 연결 동작을 기준으로 판단하세요. 특히 데스크톱 TUN 설정을 그대로 붙여 넣어 모바일 연결 설정을 대신하지 마세요.

구독 가져오기, 선택, 업데이트

앱이 지원하는 구독 주소를 준비한 뒤 설정 관리에서 링크로 추가를 선택하고 알아보기 쉬운 이름을 입력해 저장하세요. 가져오기가 끝나면 해당 설정을 선택하고 예상한 프록시 그룹과 경로가 표시되는지 확인합니다. 앱에서 파일 가져오기를 지원하더라도 파일 인코딩과 형식이 완전한지 확인하세요. 메신저에서 복사하는 과정에서 줄바꿈이 빠질 수 있습니다. 계정 정보가 포함된 링크를 공개 메모에 저장하거나 단체 채팅방에 보내지 마세요.

가져오기에 성공하는 것과 현재 설정이 적용되는 것은 별개입니다. 새 설정을 추가한 뒤 현재 선택된 항목을 확인하고 프록시 그룹이 사용 가능한 경로를 가리키는지 확인하세요. 노드 목록만 포함된 구독은 앱에서 지원하는 규칙이나 설정 템플릿이 추가로 필요할 수 있습니다. 규칙이 없다는 메시지가 나타나면 앱 안내에 따라 처리하세요. 다른 클라이언트의 설정 파일 전체를 그대로 붙여 넣으면 안 됩니다. 반복해서 가져와도 호환되지 않는 필드는 해결되지 않으며 같은 이름의 설정만 늘어나 구분하기 어려워집니다.

구독을 업데이트할 때는 이전에 사용할 수 있었던 설정을 보존하고 가져오기가 성공했는지, 노드나 정책이 바뀌었는지 차례로 확인하세요. 연결된 상태에서만 업데이트할 수 있다면 업데이트 요청이 어떤 경로를 사용하는지 확인해야 합니다. 사용할 수 있는 경로가 전혀 없다면 연결 가능한 네트워크에서 설정을 먼저 받아야 합니다. 수동 변경 사항은 다음 업데이트에서 덮어써질 수 있습니다. 장기간 유지할 사용자 설정은 앱에서 명확하게 지원하는 방식으로 관리하고 업데이트 후 다시 확인하세요.

연결 권한 및 처리 범위

처음 연결할 때 시스템에서 VPN 설정 추가를 허용하고 기기 인증을 하라는 메시지가 나타날 수 있습니다. 허용한 뒤 앱으로 돌아가 연결을 시작하고 시스템 상태와 앱 로그를 확인하세요. VPN 아이콘은 네트워크 확장이 작동 중이라는 뜻일 뿐, 노드 연결이나 모든 앱의 동일한 트래픽 처리 방식을 보장하지 않습니다. 직접 연결과 프록시 연결이 각각 확인되는 사이트를 이용해 테스트하고 정책 선택을 확인하세요. 스위치 상태만 보고 성공 여부를 판단하지 마세요.

iOS에는 데스크톱과 완전히 같은 전역 HTTP 시스템 프록시 스위치가 없습니다. Wi-Fi 세부 정보의 HTTP 프록시는 해당 무선 네트워크에만 적용되는 설정이고, 앱의 터널 연결은 네트워크 확장이 처리하므로 두 기능을 혼동해서는 안 됩니다. 일반적으로 앱에서 제공하는 연결 절차를 사용하면 됩니다. Wi-Fi 수동 프록시도 함께 사용한다면 용도를 기록하고 프록시가 중복되거나 앱 종료 후에도 인터넷에 영향을 주지 않는지 확인하세요.

기기의 다른 VPN, 네트워크 필터, 관리형 네트워크 설정이 현재 연결과 충돌할 수 있습니다. 연결을 누른 직후 끊어진다면 시스템에서 다른 설정이 활성화되어 있는지 확인하고 앱에 표시된 실패 원인을 읽으세요. 회사나 학교 기기는 관리 정책에 따라 네트워크를 사용해야 합니다. 출처를 알 수 없는 프로파일을 시험 삼아 삭제하지 마세요. 설정의 출처와 용도를 알고 있을 때만 상태를 변경하세요.

네트워크 전환, DNS, 복구

Wi-Fi와 셀룰러 데이터 사이를 전환하면 기존 연결을 다시 설정해야 할 수 있습니다. 먼저 앱에 셀룰러 데이터 권한이 있는지 확인하고 같은 경로가 두 네트워크에서 어떻게 작동하는지 비교하세요. Wi-Fi에서만 실패하면 웹 인증이 필요한지 확인하고, 셀룰러 데이터에서만 실패하면 네트워크 권한과 서버 주소 접근성을 확인하세요. 한 번의 테스트에서 경로, 모드, DNS를 모두 바꾸지 마세요. 문제가 해결되어도 어떤 변경이 효과가 있었는지 알 수 없습니다.

웹페이지에 표시된 출구 정보는 요청 경로와 함께 해석해야 합니다. 지원되는 환경에서는 iCloud 비공개 릴레이가 일부 Safari 트래픽에 영향을 줄 수 있으며, 앱 자체의 DNS 조회와 연결 정책도 결과에 영향을 줍니다. 문제를 해결할 때는 해당 기능의 원래 상태를 기록하고 허용된 범위에서 한 번에 하나씩 비교한 뒤 설정을 복원하세요. 브라우저 하나의 테스트 결과가 기기의 모든 앱을 대표하지 않으며, 모든 DNS 요청 경로를 판단하는 근거도 아닙니다.

잠금 후 연결이 끊기면 네트워크 자체의 변화, 연결 경로 시간 초과, 확장 기능 재시작을 구분해야 합니다. 앱을 다시 열었을 때 자동으로 복구되는지 먼저 확인하고 로그의 시간대를 살펴보세요. 앱 강제 종료를 일상적인 백그라운드 유지 방법으로 사용하지 마세요. 기본 연결을 복구하려면 먼저 앱에서 연결을 끊고 시스템 VPN 상태와 Wi-Fi 프록시를 확인하세요. 이전 설정을 삭제할 때는 시스템 설정에서 이름과 출처를 확인해 다른 업무에 필요한 네트워크 설정을 실수로 지우지 않도록 주의하세요.

Linux 설치 및 설정

그래픽 클라이언트와 독립 커널

Linux 데스크톱에서는 다운로드 페이지에서 Clash Verge Rev를 먼저 살펴보고 FlClash도 고려할 수 있습니다. 배포판의 패키지 관리 방식, 프로세서 아키텍처, 데스크톱 환경을 확인한 다음 맞는 설치 형식을 선택하세요. 독립 mihomo 커널은 서버, 라우터 또는 서비스를 직접 관리하는 사용자에게 적합합니다. 완전한 데스크톱 설정 인터페이스는 제공하지 않으므로 설치 후 설정 준비, 프로세스 관리, 로그 확인 방법도 마련해야 합니다.

DEB와 RPM은 범용 압축 파일이 아니므로 서로 다른 배포판에서 바꿔 사용할 수 없습니다. 그래픽 앱은 데스크톱 환경과 실행 라이브러리에도 의존합니다. 설치에 실패하면 파일 권한부터 바꾸지 말고 패키지 관리자가 보고한 의존성 문제를 읽으세요. 시스템 패키지 관리자로 로컬 패키지를 설치하면 의존성과 제거 기록을 유지할 수 있습니다. 의존성 오류를 피하려고 데스크톱 앱 전체를 root 권한으로 실행하지 마세요.

아래는 자주 사용하는 로컬 패키지 설치 명령입니다. 파일 이름은 사용 예시일 뿐 실제 다운로드 주소가 아닙니다. 실행 전에 경로를 다운로드한 파일의 경로로 바꾸고 현재 시스템에 맞는 패키지인지 확인하세요. 설치 후 앱 메뉴에서 실행해 트레이 표시, 설정 읽기, 커널 실행이 정상인지 확인합니다. 창이 나타나는 것만으로는 그래픽 계층만 확인한 것이며 프록시 수신이나 네트워크 권한까지 사용할 수 있다는 뜻은 아닙니다.

sudo apt install ./client.deb
sudo dnf install ./client.rpm

구독 가져오기와 데스크톱 프록시의 차이

그래픽 클라이언트의 구독 절차는 다른 데스크톱 플랫폼과 비슷합니다. 원격 설정을 추가하고 파싱을 기다린 뒤 설정을 선택하고 프록시 그룹에서 경로를 지정하세요. Linux 데스크톱 환경마다 시스템 프록시를 저장하고 읽는 방식이 다릅니다. 어떤 앱은 환경 변수를 읽고, 다른 앱은 데스크톱 설정이나 자체 설정을 읽습니다. 시스템 프록시를 켠 뒤 브라우저는 정상인데 터미널만 실패하더라도 커널 오류라고 단정하지 마세요. 터미널 도구가 실제로 어떤 프록시 경로를 사용하는지 먼저 확인해야 합니다.

명령줄에서는 세션 전체의 환경 변수를 바로 바꾸기보다 요청 하나에 로컬 프록시를 지정해 테스트할 수 있습니다. 아래에서는 HTTP 진입점과 SOCKS 진입점을 각각 테스트합니다. 호스트 이름 형식의 SOCKS 주소를 사용하면 curl이 대상 도메인을 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
ss -lntp

환경 변수를 설정하려면 먼저 현재 터미널에서만 임시로 테스트하고, 변수의 대소문자와 앱별 지원 여부를 확인하세요. NO_PROXY 제외 목록이 있으면 일부 요청이 프록시를 우회할 수 있으며 sudo는 환경 변수를 지울 수도 있습니다. 문제를 해결할 때는 실제 실행 환경을 기록하세요. 일반 사용자로 테스트에 성공했다고 해서 시스템 서비스나 컨테이너의 프로그램에도 같은 설정이 전달된다고 가정하면 안 됩니다.

독립 커널 설정 및 서비스 권한

독립 커널 전용 데이터 디렉터리를 만들고 설정과 다운로드가 필요한 데이터 파일을 보관하세요. 먼저 포그라운드에서 실행해 로그를 확인한 뒤 설정이 올바른 것을 확인하고 백그라운드 서비스를 구성합니다. 처음부터 로그를 숨기고 자동 재시작을 설정하면 구문 오류로 프로세스가 반복 종료되는 상황을 놓치기 쉽습니다. 아래 명령은 실행 파일이 설치되어 있고 설정 디렉터리가 이미 존재한다고 가정합니다. 경로는 실제 환경에 맞게 바꾸세요.

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

-t는 설정을 테스트해 구문 오류와 참조 문제를 찾는 데 도움이 됩니다. 테스트가 통과해도 서버 접근성이나 라우팅이 정상이라는 뜻은 아닙니다. 백그라운드 서비스에는 작업 디렉터리, 실행 사용자, 파일 권한도 명확히 지정해야 합니다. 인증 정보가 포함된 설정을 읽어야 한다면 접근 범위를 제한하세요. 다른 사용자가 설정을 만들었다면 서비스 계정에 필요한 파일을 읽을 권한이 있는지 확인하고, 전체 디렉터리 권한을 열어 문제를 해결하지 마세요.

TUN, DNS, 배포판별 차이

Linux에서 TUN을 사용하려면 가상 장치와 네트워크를 관리할 권한이 필요합니다. 그래픽 클라이언트에서는 자체 서비스 설치 기능을 우선 사용하세요. 독립적으로 배포할 때는 서비스 관리 방식에 따라 필요한 권한만 부여하고 모든 프로그램에 상시 권한을 높이지 마세요. 컨테이너나 제한된 호스트는 가상 장치에 접근할 수 없을 수도 있습니다. YAML만 수정해서 이런 환경 제한을 해결할 수는 없습니다. 호스트 환경에서 지원되는지 먼저 확인한 뒤 커널 매개변수를 살펴보세요.

시스템에서 NetworkManager, systemd-resolved 또는 다른 DNS 구성 요소를 함께 사용할 수 있습니다. /etc/resolv.conf를 직접 수정하면 네트워크 서비스가 변경 사항을 덮어쓰거나 기존 심볼릭 링크가 손상될 수 있습니다. 먼저 어떤 구성 요소가 관리하는지 확인한 뒤 DNS를 커널로 전달하는 방법을 정하세요. TUN을 켠 뒤 IP 주소로는 연결되지만 도메인 이름으로 실패한다면 노드 프로토콜을 바꾸기 전에 DNS 진입점, 53번 포트 처리, 업스트림 접근성을 확인하세요.

로컬 프록시가 컨테이너, 가상 머신, 같은 로컬 네트워크의 다른 기기 트래픽까지 자동으로 처리하지는 않습니다. 각각 별도의 네트워크 네임스페이스, 게이트웨이, 방화벽 경로를 사용하므로 포워딩 방식을 따로 설계해야 합니다. 서비스를 중지할 때는 자동 경로가 제거되었는지, 데스크톱 프록시와 터미널 변수가 복원되었는지 확인하세요. 원격 서버에서 기본 경로를 변경하기 전에는 예비 관리 연결을 확보하세요. 현재 관리 연결마저 검증하지 않은 프록시 경로로 보내는 일을 막을 수 있습니다.

설정 관련 자주 묻는 질문과 단계별 문제 해결

설정은 불러와지는데 인터넷에 연결되지 않는 이유

설정 가져오기, 커널 실행, 로컬 수신, 앱의 트래픽 처리, DNS 조회, 정책 매칭, 원격 연결 순서로 문제를 확인하세요. 각 단계에서 한 가지씩만 검증합니다. 설정이 정상적으로 파싱되는지, 포트가 수신 중인지, 대상 앱의 연결 로그가 생성되는지, 어떤 정책이 적용되는지, 원격 연결 핸드셰이크가 완료되는지 확인하세요. 가장 먼저 실패한 단계를 찾아 해당 설정만 수정하면 구독과 네트워크 모드를 동시에 바꾸는 것보다 원인을 안정적으로 파악하기 쉽습니다.

파싱 오류가 발생하면 먼저 오류 행과 주변 내용을 확인하세요. YAML의 계층은 공백으로 표현하므로 탭을 들여쓰기에 사용하면 안 됩니다. 같은 맵에서 dns, tun, rules를 중복 정의하지 마세요. 특수 문자가 포함된 문자열은 올바르게 인용해야 합니다. 원본 구독, 덮어쓰기 조각, 최종 설정은 서로 다른 객체일 수 있습니다. 현재 편집 중인 대상이 무엇인지 확인한 뒤 수정하세요. 저장에 성공해도 커널이 실제로 읽는 파일에 반영되지 않을 수 있습니다.

규칙 모드, 전역 모드, 정책 참조

규칙 모드는 목록 순서에 따라 규칙을 확인하고 보통 처음 일치하는 항목에서 멈춥니다. 전역 모드는 처리 대상으로 지정된 연결을 전역 정책으로 보내지만, 원래 커널이 처리하지 않는 앱까지 자동으로 포함하지는 않습니다. 직접 연결 모드도 클라이언트나 가상 네트워크 카드가 꺼졌다는 뜻은 아닙니다. 모드는 문제 해결을 위한 비교 조건으로 활용할 수 있습니다. 전역 모드는 작동하지만 규칙 모드가 실패한다면 매칭 결과와 프록시 그룹을 확인하고, 둘 다 실패한다면 출구와 트래픽 처리 설정부터 확인하세요.

아래 예제는 지정한 도메인 접미사만 수동 선택 그룹으로 보내고 나머지는 직접 연결합니다. 선택 그룹에는 현재 DIRECT만 있으므로 규칙 구조를 보여 주는 예제일 뿐 원격 프록시는 제공하지 않습니다. 실제 설정에서는 기존 노드나 구독 제공자를 그룹에 연결해야 합니다. 규칙에서 참조하는 정책 이름은 그룹 이름과 정확히 일치해야 합니다. 철자가 다르면 설정을 불러오지 못하거나 예상과 다르게 작동할 수 있습니다. 규칙 순서 예제는 중국 본토 및 해외 트래픽 분류 실전 가이드에서 확인하세요.

proxy-groups:
  - name: SELECT
    type: select
    proxies:
      - DIRECT
rules:
  - DOMAIN-SUFFIX,example.com,SELECT
  - MATCH,DIRECT

DNS, fake-ip, 트래픽 처리 범위

DNS는 도메인을 주소와 연결하고 프록시는 연결을 설정합니다. 서로 협력하지만 같은 계층은 아닙니다. fake-ip는 매핑에 사용할 가상 주소를 반환하며, 이후 연결에서 커널이 도메인 정보를 복원합니다. 대상 사이트가 실제로 해당 주소를 사용한다는 뜻은 아닙니다. 앱에 이전 캐시가 남아 있거나 커널을 우회해 조회하거나 자체 암호화 DNS를 사용하면 규칙에서 확인되는 정보가 달라질 수 있습니다. 연결 메타데이터를 함께 살펴보세요.

아래는 mihomo DNS 설정의 일부 예제이며 수신 주소는 로컬 기기에서만 열립니다. 이 설정만으로 시스템 DNS가 자동 변경되거나 모든 외부 DNS 조회가 차단되지는 않습니다. TUN의 DNS 가로채기는 조건에 맞는 일반 DNS 트래픽을 처리합니다. 앱에 내장된 암호화 DNS는 라우팅 및 앱 설정을 함께 살펴봐야 합니다. 업스트림 주소에 현재 네트워크에서 접근할 수 없으면 모든 도메인 조회가 실패할 수 있습니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

DNS 모드를 바꾸어도 이전 캐시가 남아 증상이 한동안 지속될 수 있습니다. 클라이언트에서 지원하는 방식으로 DNS 캐시를 지우고 테스트 앱의 연결을 다시 만든 뒤 결과를 비교하세요. 문제가 있는 도메인에 필요한 예외만 지정하고 앱 하나의 문제를 해결하려고 모든 규칙을 해제하지 마세요. 검사 단계와 결과의 한계는 DNS 유출 검사 및 해결 방법에서 확인할 수 있습니다. 가상 인터페이스 매개변수는 TUN 모드 설정 안내를 참고하세요.

진단 자료를 저장하고 정상 상태 복구

로그에는 발생 시간, 대상 앱, 네트워크 유형, 모드, 적용된 규칙, 오류 요약을 남기고 구독 주소, 서버 인증 정보, 개인 접속 기록은 삭제하세요. 일시적으로 로그 수준을 높이면 단서를 더 얻을 수 있지만 테스트가 끝난 뒤에는 평소 수준으로 되돌려 정보가 쌓이지 않도록 합니다. 노드 지연 시간 테스트는 특정 확인 요청만 검사합니다. 실제 웹사이트 접속을 대신할 수 없으며 UDP, 장시간 연결, 모든 대상이 정상이라는 증거도 아닙니다.

최근 업데이트 이후 문제가 생겼다면 먼저 이전에 정상 작동하던 설정으로 복원하고 프록시 그룹 이름, 규칙 세트, DNS 업스트림, 클라이언트 덮어쓰기를 하나씩 비교하세요. 규칙 세트 다운로드 실패와 노드 연결 실패는 다른 문제입니다. GeoIP 및 GeoSite 데이터도 별도로 업데이트해야 하므로 데이터베이스 업데이트 및 규칙 참조 방법을 확인하세요. 오류가 발생한 계층을 파악하는 대신 반복해서 재설치하지 마세요.

처음부터 다시 시작해야 한다면 먼저 클라이언트의 트래픽 처리를 끄고 시스템 프록시와 기존 DNS를 복원한 뒤 일반 네트워크가 작동하는지 확인하세요. 그런 다음 저장해 둔 설정 사본을 가져오면 됩니다. 첫 연결 절차는 가이드 페이지에서 단계별로 확인하고, 모드별 차이는 규칙, 전역, 직접 연결 모드 비교를 참고하세요. 이 안내서의 예제는 매개변수와 진단 범위를 설명하기 위한 것이며, 실제로 사용할 수 있는 연결 설정을 대신하지 않습니다.