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

공통 준비: 설정 출처와 트래픽 처리 범위

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

클라이언트는 설정 화면과 구성을 관리하고 시스템 권한을 요청합니다. 코어는 설정을 해석하고 규칙을 적용해 연결을 만듭니다. 구독에는 노드와 프록시 그룹이 포함되며, DNS 및 라우팅 규칙이 함께 제공되기도 합니다. 이 셋은 서로 다른 요소입니다. 클라이언트를 설치해도 연결할 원격 서비스가 자동으로 제공되지는 않으며, 구독이 있다고 해서 모든 클라이언트에서 바로 사용할 수 있는 것도 아닙니다. 시작하기 전에 구독 유효 기간과 지원 형식, 서비스 제공업체가 현재 클라이언트에 맞는 가져오기 방법을 제공하는지 확인하세요.

일반적인 데스크톱과 모바일 사용자는 다운로드 페이지에서 Clash Plus를 먼저 확인하고, 운영체제에 따라 다른 클라이언트와 비교해 보세요. 서비스 프로세스와 라우팅, 설정 디렉터리를 직접 관리해야 할 때는 mihomo 코어를 별도로 사용하는 방법을 고려할 수 있습니다. Clash, Clash.Meta, mihomo는 이름과 계보가 이어지지만, 그렇다고 모든 이전 설정과 호환되는 것은 아닙니다. 프로토콜, 규칙 필드, DNS 기능은 실제 코어 지원 여부를 확인해야 합니다. 자세한 내용은 코어 및 설정 호환성 정리를 참고하세요.

기기와 현재 네트워크 상태 기록하기

다운로드 전에 운영체제, 프로세서 아키텍처, 설치 파일 형식을 확인하세요. 데스크톱에서는 VPN, 프록시 프로그램, 가상 머신 네트워크 어댑터, 기업 보안 프로그램이 이미 설치되어 있는지도 살펴봐야 합니다. 다른 프록시 도구를 종료한 뒤 프록시 없이 일반 웹페이지가 열리는지 테스트하세요. 직접 연결부터 문제가 있다면 먼저 기본 네트워크를 복구해야 합니다. 테스트 후 되돌릴 수 있도록 기존 프록시와 DNS 설정을 기록해 두고, 네트워크 어댑터 제거·라우팅 변경·DNS 서버 교체를 한꺼번에 진행하지 마세요.

구독 주소는 설정에 접근할 수 있는 권한을 제공하는 경우가 많습니다. 로그나 스크린샷을 공유하기 전에는 전체 주소와 사용자 식별 정보, 쿼리 매개변수를 가리세요. 가져올 때는 신뢰할 수 있는 출처에서 링크 전체를 복사하고, 메신저의 줄바꿈이나 끝 공백, 한글 문장 부호가 섞이지 않도록 주의하세요. 설정 대신 웹페이지가 표시된다면 로그인이 필요한지, 링크가 만료되었는지, 클라이언트가 반환 형식을 지원하는지 확인하세요. 개인 식별 정보가 포함된 구독을 출처가 불분명한 변환 사이트에 입력하지 마세요.

시스템 프록시와 TUN 사용 순서 정하기

시스템 프록시는 시스템 프록시 설정을 따르는 앱의 연결을 로컬 수신 포트로 전달합니다. 브라우저는 보통 이를 이용해 기본 연결을 테스트할 수 있지만, 일부 게임과 명령줄 도구, 자체 네트워크 스택을 사용하는 앱은 시스템 설정을 따르지 않을 수 있습니다. TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 통해 더 많은 트래픽을 처리하므로, 더 높은 권한과 DNS 및 네트워크 어댑터 설정이 필요한 경우가 많습니다. 데스크톱 문제를 해결할 때는 먼저 시스템 프록시를 확인하고, 필요에 따라 TUN으로 전환하세요. 모바일에서는 보통 시스템 VPN 확장으로 트래픽을 처리하므로 데스크톱의 설정 방법을 그대로 적용할 수 없습니다.

최소 설정으로 연결 확인하기

아래는 기본 필드 예시일 뿐입니다. 노드와 프록시 그룹이 포함되어 있지 않으므로, 이미 정상 작동하는 설정에 병합해야 합니다. 포트는 클라이언트에 표시된 값을 사용하세요. 일부 클라이언트는 설정 화면의 포트로 구독 필드를 덮어쓸 수 있습니다. 로컬 연결과 규칙 모드를 유지하고, 처음에는 LAN 연결을 허용하지 마세요. YAML은 공백으로 들여쓰기하고 콜론 뒤에 공백을 넣으며 같은 단계의 필드를 맞춰야 합니다. 로드 오류가 발생하면 먼저 표시된 줄 번호를 확인하고, 문법 오류를 감추려고 규칙 전체를 삭제하지 마세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

가져온 뒤 세 단계로 확인하세요. 설정이 정상적으로 로드되었는지, 선택한 노드가 연결되는지, 대상 요청에 예상한 정책이 적용되는지 점검합니다. 먼저 노드 하나를 선택하고 잦은 자동 속도 측정은 끄세요. 직접 연결할 대상과 프록시를 사용할 대상을 각각 열어 연결 화면에서 적용된 정책과 출구를 확인하세요. 테스트가 성공하면 설정 사본을 저장하고 트래픽 처리 방식을 기록하세요. 이후 규칙이나 DNS 설정을 추가할 때마다 한 번에 하나씩 변경하면 어떤 단계가 영향을 미쳤는지 파악하기 쉽습니다.

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

아키텍처에 맞게 설치하고 이전 설정 보관하기

시스템 설정에서 ‘시스템 → 정보’를 열어 시스템 종류를 확인하고, 일반적인 x64와 ARM 기기를 구분하세요. 먼저 Windows 다운로드에서 Clash Plus를 확인하세요. 다른 선택지는 Clash Verge Rev, FlClash, Clash Nyanpasu 순으로 살펴볼 수 있습니다. Clash for Windows는 지원이 중단되었으므로, 명확한 호환성 요구가 있는 경우에만 아카이브를 참고하세요. 이름이 익숙하다는 이유만으로 새 기기의 기본 클라이언트로 이전 버전을 선택하거나, 서로 다른 아키텍처의 설치 파일을 섞어 반복 설치하지 마세요.

이전 클라이언트에서 옮기기 전에 구독 출처, 직접 선택한 프록시 그룹, 사용자 지정 규칙, 앱별 프록시 설정을 기록하세요. 내보낼 수 있는 로컬 설정은 별도 디렉터리에 저장하되, 새 클라이언트의 데이터 디렉터리 전체를 덮어쓰지는 마세요. 데이터베이스, 화면 설정, 서비스 상태가 호환되지 않을 수 있습니다. 새 클라이언트는 기본 데이터 디렉터리로 설치하고, 기본 연결을 확인한 뒤 사용자 설정을 하나씩 옮기세요. 자세한 이전 방법은 Clash for Windows 마이그레이션 단계를 참고하세요.

설치 프로그램을 실행할 때 파일 출처와 시스템 알림을 확인하세요. 설치가 끝나면 먼저 일반 사용자 권한으로 클라이언트를 실행하세요. 일상적인 사용에 항상 관리자 권한이 필요한 것은 아닙니다. 보안 프로그램이 실행을 차단하면 차단된 항목과 조직 정책을 확인하고, 프로그램을 실행하려고 시스템 보호 기능 전체를 끄지 마세요. 회사에서 관리하는 PC는 프록시, 드라이버, 서비스 설치가 제한될 수 있습니다. 이런 제한은 기기 관리자에게 확인해야 하며, 권한 요청을 반복해도 정책상 차단이 해제되지는 않습니다.

구독 가져오기와 시스템 프록시 확인

설정 또는 구독 관리 화면에서 링크 추가를 선택하고 구독 주소 전체를 붙여 넣은 뒤 다운로드가 끝날 때까지 기다리세요. 설정 항목이 표시되면 현재 설정으로 선택한 다음 프록시 화면에서 프록시 그룹과 노드가 로드되었는지 확인합니다. 구독 이름이 보인다고 해서 코어가 전환된 것은 아닙니다. 목록이 비어 있다면 업데이트 결과와 설정 파싱 로그를 먼저 확인하세요. 업데이트가 실패하면 기존 설정을 유지하세요. 정상 작동하던 캐시까지 삭제될 수 있으므로 계속해서 삭제와 재등록을 반복하지 마세요.

규칙 모드를 선택하고 수동 선택이 필요한 프록시 그룹에서 노드를 지정한 다음 시스템 프록시를 켜세요. Windows의 네트워크 및 인터넷 프록시 설정에서 주소와 포트를 확인합니다. 보통 로컬 루프백 주소와 클라이언트에 표시된 수신 포트를 사용해야 합니다. 브라우저에 프록시 확장 프로그램을 설치했다면 해당 확장 프로그램의 트래픽 처리를 잠시 끄세요. 확장 프로그램에 저장된 이전 포트를 통해 요청이 전송되면 시스템 설정이 올바르더라도 현재 코어에 연결되지 않을 수 있습니다.

테스트 페이지를 열고 클라이언트의 연결 목록을 함께 확인하세요. 웹페이지가 열리지 않고 해당 요청도 목록에 없다면 브라우저 자체 프록시, 시스템 우회 목록, 로컬 수신 설정을 먼저 확인하세요. 요청은 표시되지만 연결에 실패한다면 노드 인증, 원격 서버 연결 여부, 규칙 선택을 살펴보세요. 일부 앱은 시스템 프록시 설정을 다시 읽으려면 재시작해야 합니다. 명령줄 도구는 환경 변수만 확인할 수도 있으므로 브라우저에서 성공했다고 모든 프로그램이 프록시를 사용한다고 단정할 수 없습니다.

TUN 활성화와 권한 오류 해결

시스템 프록시를 따르지 않는 앱이 실제로 있을 때 TUN을 활성화하세요. 클라이언트에 따라 서비스 모드를 설치하거나 보조 프로세스를 승인해야 할 수 있습니다. 화면의 안내를 따라 설정한 뒤 스위치가 켜졌는지만 보지 말고 서비스가 실행 중인지 확인하세요. 처음 테스트할 때는 시스템 프록시를 끄고 TUN만 유지하면 트래픽 경로를 확인하기 쉽습니다. 가상 네트워크 어댑터 생성에 실패하면 권한 또는 드라이버 오류를 살펴보세요. 라우팅 추가에 실패하면 다른 VPN, 가상 머신 네트워크, 남아 있는 서비스를 확인하세요.

로컬 포트가 사용 중이라면 PowerShell에서 수신 중인 프로세스를 확인할 수 있습니다. 아래 명령은 예시 포트만 확인하며 프로그램을 종료하지 않습니다. 설정 화면의 포트가 다르면 실제 값으로 바꾸세요. 프로세스 식별자를 확인한 뒤 작업 관리자에서 어떤 앱인지 확인하고, 기존 도구를 정상적으로 종료한 다음 현재 클라이언트를 다시 실행하세요. 포트가 사용 중이라는 이유만으로 알 수 없는 프로세스를 일괄 종료하지 마세요. 시스템 서비스나 개발 도구도 로컬 포트를 사용할 수 있습니다.

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

절전 모드에서 복귀하거나 유선 네트워크에서 Wi-Fi로 전환한 뒤 연결이 끊기면 현재 트래픽 처리 방식을 껐다가 다시 켜고, 코어가 기본 네트워크 어댑터를 다시 인식하는지 확인하세요. TUN만 문제이고 시스템 프록시는 정상이라면 라우팅과 네트워크 어댑터를 집중적으로 확인하세요. 구독을 다시 구매하거나 노드 프로토콜을 무작정 바꿀 필요는 없습니다. 방화벽 허용 범위도 필요한 프로그램과 네트워크로 제한하세요. allow-lan: false 상태라면 로컬 브라우저로 접속하기 위해 LAN 전체의 인바운드 연결을 허용할 필요가 없습니다.

마지막으로 종료 동작을 확인하세요. 먼저 클라이언트에서 시스템 프록시나 TUN을 끈 뒤 정상적으로 종료하고, 브라우저가 계속 직접 연결되는지 테스트합니다. 프로그램이 비정상 종료된 뒤 인터넷이 되지 않는다면 시스템에 로컬 프록시 주소가 남아 있는지 확인하고, 이전에 기록한 설정을 복원하세요. 연결이 안정된 뒤에 시작 프로그램 등록을 고려하세요. 로그인 시 자동 실행, 서비스 자동 시작, 자동 연결은 서로 다른 옵션이므로 각각 테스트해야 합니다. 여러 클라이언트가 동시에 프록시 설정을 차지하지 않도록 주의하세요.

macOS: 칩 아키텍처, 보조 서비스, 네트워크 위치

설치 파일 선택과 첫 실행 문제 해결

Apple 메뉴의 ‘이 Mac에 관하여’를 열어 Apple 칩인지 Intel 프로세서인지 확인한 뒤 macOS 다운로드에서 아키텍처에 맞는 파일을 선택하세요. Clash Plus를 우선 고려하고, Clash Verge Rev와 FlClash도 비교해 볼 수 있습니다. ClashX Meta는 지원이 중단되었으므로 이전 설정의 과거 동작을 확인할 때만 참고하세요. 호환성 계층에서 실행할 수 있다고 해서 장기 사용에 적합한 것은 아닙니다. 기기 칩에 맞는 설치 파일을 선택해 불필요한 호환성 단계를 줄이세요.

디스크 이미지로 설치할 때는 앱을 ‘응용 프로그램’ 폴더로 복사한 뒤 실행하세요. 마운트된 이미지나 다운로드 폴더에서 계속 실행하지 마세요. 이렇게 하면 업데이트와 보조 서비스 경로, 시스템 권한 기록을 일관되게 유지하기 쉽습니다. 처음 실행할 때 시스템이 차단하면 다운로드 출처를 확인한 뒤 ‘개인정보 보호 및 보안’의 안내에 따라 처리하세요. 출처가 불분명한 터미널 명령을 사용해 모든 앱의 보안 속성을 제거하지 말고, 실행 실패를 곧바로 구독 문제로 단정하지 마세요.

보조 서비스가 필요하다면 클라이언트 자체와 클라이언트가 설치하는 백그라운드 구성 요소를 구분하세요. 시스템 프록시 변경, 가상 네트워크 어댑터 생성, 라우팅 관리에는 관리자 승인이 한 번 필요할 수 있습니다. 승인한 뒤에는 클라이언트에서 서비스 상태를 확인하세요. 앱 위치를 옮기거나 같은 종류의 도구를 바꾼 적이 있다면 이전 서비스 경로가 유효하지 않을 수 있습니다. 앱 아이콘을 휴지통으로 옮겨 백그라운드 구성 요소를 남기는 대신 해당 클라이언트의 복구 또는 제거 기능을 사용하세요.

구독 가져오기와 시스템 프록시 확인

설정 화면에서 구독 주소를 추가하고 다운로드 및 파싱이 끝날 때까지 기다린 뒤 해당 설정을 선택하세요. 프록시 그룹이 있는지, 현재 선택한 항목이 유효한 노드를 가리키는지 확인하고 규칙 모드를 유지하세요. 구독에 클라이언트가 지원하지 않는 필드가 포함되어 있으면 로그에 필드명이나 프로토콜명이 표시되는 경우가 많습니다. 설정 제공업체에 호환되는 형식을 요청하거나 해당 필드를 지원하는 클라이언트를 사용하세요. 오류가 난 줄을 바로 삭제하지 마세요. 원격 연결에 필요한 핵심 매개변수일 수 있습니다.

시스템 프록시를 켠 뒤 시스템 설정의 네트워크에서 현재 사용 중인 네트워크 서비스를 열고 세부 정보의 프록시 항목을 확인하세요. Wi-Fi와 유선 네트워크에 각각 설정이 저장될 수 있으므로 실제로 트래픽을 사용하는 네트워크를 선택해야 합니다. 주소는 보통 로컬 루프백 주소이며, 포트는 클라이언트와 일치해야 합니다. 브라우저에서는 접속되지만 터미널에서는 안 된다면 터미널 도구가 시스템 프록시를 읽는지 확인하세요. 둘 다 실패한다면 수신 프로세스와 설정 로드 상태를 살펴보세요.

시스템 프록시의 우회 목록은 어떤 대상이 로컬 프록시를 거치지 않을지 결정합니다. 사내망, 프린터, 로컬 개발 주소는 직접 연결해야 할 수 있으므로 테스트를 위해 모든 예외를 영구 삭제하지 마세요. 반대로 도메인이나 주소 범위를 너무 넓게 지정하면 프록시를 사용해야 할 요청까지 클라이언트를 우회할 수 있습니다. 변경 전에 기존 값을 기록하고, 명확한 대상 하나로 다시 테스트한 뒤 연결 화면에서 요청이 표시되는지 확인하세요. 메뉴 막대의 스위치만으로는 실제 연결 경로를 알 수 없습니다.

TUN, 절전 복귀, DNS 캐시

TUN을 켜기 전에 보조 구성 요소를 승인하고 다른 VPN을 일시 중지하세요. 클라이언트마다 트래픽 처리 방식과 서비스 관리가 다르고 시스템 권한 안내도 다를 수 있으므로 현재 앱의 설명을 따르세요. 처음 확인할 때는 시스템 프록시를 잠시 끄고 규칙 로그에서 트래픽이 실제로 TUN을 통과하는지 확인하세요. 시작할 때 기본 네트워크 어댑터 인식이나 라우팅 오류가 발생하면 당시 네트워크 인터페이스와 다른 네트워크 확장 상태를 기록한 뒤 보조 서비스를 다시 시작할지 결정하세요.

노트북이 절전 모드에서 복귀하거나 핫스팟을 바꾸거나 웹 로그인이 필요한 공용 네트워크에 연결되면 기존 연결과 DNS 조회 결과가 일시적으로 유효하지 않을 수 있습니다. 먼저 프록시를 끄고 네트워크 포털 로그인을 완료한 뒤 다시 연결하세요. 특정 도메인만 계속 잘못 해석된다면 DNS 설정이 올바른지 확인한 뒤 시스템 캐시를 비울 수 있습니다. 아래 명령은 관리자 권한이 필요하며 로컬 캐시만 정리합니다. 구독, 원격 노드, 잘못된 DNS 설정을 해결하지는 않으므로 모든 문제의 첫 단계로 사용하지 마세요.

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

일부 브라우저는 자체 암호화 DNS를 사용하고 앱은 기존 연결을 오래 유지할 수 있습니다. DNS 정책을 변경한 뒤에는 관련 테스트 탭을 닫거나 앱을 다시 시작하고 새 요청을 확인하세요. fake-ip를 사용한다면 캐시에 저장된 가상 주소를 실제 서버 주소로 간주해 직접 연결 테스트하지 마세요. 해당 주소는 이를 생성한 코어에서 해석해야 합니다. DNS 동작과 대상 연결 경로는 연결 로그와 함께 확인해야 하며, 명령줄 조회 한 번만으로 결론을 내려서는 안 됩니다.

이전이 끝나면 브라우저, 프록시가 필요한 데스크톱 앱, 직접 연결해야 하는 LAN 서비스를 차례로 확인하세요. 마지막으로 트래픽 처리를 끄고 클라이언트를 종료한 뒤 네트워크가 정상적으로 복구되는지 확인합니다. 특정 네트워크 위치에서만 문제가 생기면 시스템 네트워크 서비스를 전부 삭제하기보다 해당 위치에 저장된 프록시와 DNS 설정을 비교하세요. 되돌릴 수 있는 설정 사본을 보관해 두면 시스템·클라이언트·구독 업데이트 중 무엇이 영향을 미쳤는지 구분하기 쉽습니다.

Android: 설치 아키텍처, VPN 승인, 백그라운드 실행

다운로드와 설치 전 기기 확인

Android 다운로드에서 Clash Plus를 먼저 확인하세요. 그다음에는 Clash Meta for Android, FlClash, Surfboard를 살펴볼 수 있습니다. 일반적인 스마트폰은 ARM64를 사용하지만 구형 기기나 특정 시스템은 다른 패키지가 필요할 수 있으므로 기기 정보와 다운로드 페이지 안내를 함께 확인하세요. 설치에 실패하면 시스템에 표시된 원인을 확인하세요. 아키텍처 불일치, 시스템 요구 사항 미충족, 저장 공간 부족, 서명 불일치는 해결 방법이 다릅니다. 같은 파일을 반복해서 다운로드하는 것만으로 해결되지 않습니다.

브라우저나 파일 관리자를 통해 설치할 때 시스템에서 해당 출처의 앱 설치를 허용하라고 요청할 수 있습니다. 현재 사용하는 출처에만 권한을 부여하고, 설치 후 필요에 따라 해제하세요. 이전 버전과 새 버전의 서명이 다르면 덮어쓰기 설치가 거부될 수 있습니다. 삭제하기 전에 구독과 로컬 규칙을 내보내고 설정을 다시 가져올 수 있는지 확인하세요. 앱을 제거하면 앱 전용 데이터도 보통 삭제됩니다. 백업 파일을 단체 채팅방이나 공개 클라우드에 올리지 마세요. 구독 주소만으로도 계정 설정에 접근할 수 있습니다.

Surfboard와 Clash 계열의 설정은 완전히 같은 형식이라고 볼 수 없습니다. 가져오기 전에 서비스 제공업체가 해당 형식을 지원하는지 확인하세요. 두 앱에 같은 프로토콜 이름이 표시되더라도 규칙 문법과 구독 내용이 호환된다는 뜻은 아닙니다. 클라이언트를 고를 때는 먼저 설정 출처를 확인하고, 그다음 화면 구성과 사용 편의성을 비교하세요. 형식 변환은 변수를 늘리므로 기본 연결이 되기 전에는 서비스 제공업체가 명시적으로 지원하는 기본 가져오기 방법을 우선 사용하세요.

설정 가져오기와 VPN 연결 승인

설정 관리 화면에서 원격 구독을 새로 만들고 주소를 붙여 넣어 다운로드한 뒤 해당 항목을 활성 설정으로 지정하세요. QR 코드로 가져온다면 인식된 내용이 구독인지, 단일 노드인지, 웹 로그인 주소인지 먼저 확인하세요. 스캔에 성공했다고 설정까지 유효한 것은 아닙니다. 다운로드가 실패하면 휴대폰 시간이 올바른지, 네트워크 포털 로그인이 필요한지, 구독이 유효한지 확인하세요. 가져오기는 성공했지만 프록시 그룹이 없다면 설정 형식과 파싱 결과를 더 살펴보세요.

처음 연결할 때 Android에서 VPN 연결 요청이 표시되는 경우가 많습니다. 앱이 시스템 인터페이스를 통해 기기 트래픽을 처리하려면 필요한 권한입니다. 방금 설치한 클라이언트에서 보낸 요청인지 확인한 뒤 허용하세요. 일반적인 기기에서는 동일한 사용자 공간에서 활성 VPN 하나만 유지할 수 있습니다. 다른 VPN, 방화벽, 로컬 VPN 기반 필터링 도구가 현재 연결을 대체할 수 있습니다. 상태 표시줄의 VPN 아이콘은 터널이 존재한다는 뜻일 뿐, 원격 노드나 DNS까지 정상이라는 의미는 아닙니다.

우선 규칙 모드를 유지하고 노드를 선택한 뒤 브라우저를 열어 연결 화면에서 적용된 정책을 확인하세요. 모바일에서는 VPN을 통해 트래픽을 처리하므로 데스크톱 안내처럼 시스템 HTTP 프록시를 설정할 필요가 없습니다. Wi-Fi 고급 설정의 수동 프록시는 해당 무선 네트워크에 적용됩니다. 두 가지 트래픽 처리 방식을 섞으면 문제 해결이 더 어려워집니다. 다른 기기의 프록시에 연결해야 하는 경우가 아니라면 Wi-Fi 프록시 설정을 먼저 원래대로 되돌린 다음 클라이언트의 VPN 연결을 테스트하세요.

앱별 프록시 설정과 백그라운드 제한

앱별 프록시에는 보통 ‘선택한 앱만 프록시 사용’과 ‘선택한 앱 우회’처럼 서로 반대되는 옵션이 있습니다. 선택하기 전에 화면 설명을 꼼꼼히 읽으세요. 처음에는 앱 필터를 설정하지 않고 전체 트래픽 처리를 확인한 뒤 예외를 하나씩 추가하는 것이 좋습니다. 특정 앱의 연결이 목록에 표시되지 않으면 제외 목록에 있는지, 업무 프로필이나 다른 사용자 공간에서 실행 중인지, 다른 VPN이 연결을 처리하는지 확인하세요. 바로 노드 문제라고 단정하지 마세요.

화면을 끈 뒤 연결이 끊기는 흔한 원인은 배터리 최적화, 백그라운드 활동 제한, 제조사 자체 자동 실행 관리입니다. 먼저 클라이언트를 백그라운드 실행 허용 목록에 추가하고 필요한 포그라운드 서비스 알림을 유지하세요. 제조사마다 메뉴 이름이 다르므로 시스템 검색으로 배터리 및 백그라운드 관리 항목을 찾으세요. 모든 앱의 제한을 한 번에 풀지는 마세요. 백그라운드 실행을 허용한 뒤에도 화면 끄기, 네트워크 전환, 시스템 정리 작업을 각각 테스트해야 어떤 동작이 서비스를 끊는지 알 수 있습니다.

시스템의 ‘항상 켜진 VPN’과 ‘VPN 연결 없이 차단’은 기기 전체에 적용되는 정책입니다. 후자를 켜면 클라이언트 연결이 끊겼을 때 일반 네트워크도 차단될 수 있으므로 기본 연결이 안정되기 전에 활성화하지 않는 것이 좋습니다. 휴대폰의 비공개 DNS, 브라우저의 암호화 DNS, 클라이언트 DNS가 서로 다른 경로로 조회할 수도 있습니다. 현재 설정을 기록한 뒤 로그에서 실제 요청을 확인하세요. 모든 DNS 설정을 동시에 바꾸면 비교할 기준을 잃게 됩니다.

배터리 소모를 확인할 때는 자동 속도 측정 빈도와 불필요한 로그를 줄이고, 지속적인 데이터 전송·잦은 재연결·백그라운드 업데이트 중 무엇이 기기를 깨우는지 살펴보세요. 상태 확인 간격을 줄인다고 연결이 안정되는 것은 아닙니다. 네트워크 전환 때 연속으로 속도를 측정하면 오히려 부하가 커질 수 있습니다. 모바일 백그라운드 및 배터리 설정 비교를 참고해 항목별로 조정하세요. 연결에 필요한 기능만 남기고, 시스템을 업데이트한 뒤 백그라운드 권한을 다시 확인하세요.

iOS: 앱 스토어 설치, 설정 가져오기, 필요 시 연결

앱과 설정 형식을 스토어에서 확인하기

iPhone과 iPad에서는 Clash Plus를 우선 사용하세요. iOS 다운로드에서 App Store로 이동하거나 Clash Plus App Store 페이지를 바로 열 수 있습니다. 제품 공식 웹사이트는 clashplus.io입니다. 설치 전 스토어에 표시된 최신 시스템 호환 조건을 확인하고 기기에 설치할 수 있는지 살펴보세요. 데스크톱의 파일 설치 절차를 휴대폰에 그대로 적용하지 마세요. 모바일은 권한과 설정 저장 방식이 다릅니다.

구독을 준비할 때 Clash Plus가 현재 지원하는 가져오기 형식을 먼저 확인하세요. 파일 확장자가 같거나 링크가 모두 HTTPS로 시작한다고 해서 내용까지 호환되는 것은 아닙니다. 데스크톱 설정에는 로컬 경로, 외부 스크립트, 특정 코어 전용 필드가 포함될 수 있으며 모바일에서 실행되지 않을 수 있습니다. 서비스 제공업체가 전용 구독을 제공한다면 해당 경로를 우선 사용하세요. 단일 노드 정보만 있다면 앱의 노드 추가 절차에 따라 입력하세요. 원격 설정 주소 입력란에 붙여 넣으면 안 됩니다.

iOS는 앱 샌드박스와 백그라운드 확장 기능에 명확한 제한이 있어 컴퓨터에서 직접 편집할 수 있는 설정 디렉터리를 휴대폰에 그대로 적용하기 어렵습니다. 로컬 파일을 가져오려면 앱에서 지원하는 파일 가져오기 또는 공유 기능을 사용하세요. 가져온 뒤 별도 사본이 만들어졌는지, 자동 업데이트되는지 확인하세요. ‘파일’ 앱에서 파일을 볼 수 있다고 해서 클라이언트가 해당 위치를 계속 읽는 것은 아닙니다. 컴퓨터에서 수정하면 휴대폰에도 자동으로 반영된다고 생각해서도 안 됩니다.

구독 추가와 VPN 설정 승인

앱의 설정 또는 구독 관리 화면에서 원격 구독을 추가하고 내용이 로드될 때까지 기다리세요. 프록시 그룹, 노드, 규칙이 표시되는지 확인한 뒤 활성 설정을 선택합니다. 구독 업데이트가 멈추면 일반 네트워크로 인터넷에 접속할 수 있는지, 공용 Wi-Fi 로그인 화면에 머물러 있지는 않은지 확인하세요. 링크 만료 여부와 필요한 형식도 살펴보세요. 한 번의 테스트에서 Wi-Fi, 구독 출처, 클라이언트 설정을 동시에 바꾸면 무엇이 영향을 미쳤는지 파악하기 어렵습니다.

처음 연결할 때 시스템에서 VPN 설정 추가를 허용하라는 메시지가 표시될 수 있습니다. 시스템 안내에 따라 인증을 완료하세요. 승인 후 앱에서 연결 상태를 확인하고 시스템 VPN 관리 화면에서 올바른 설정이 활성화되었는지 확인합니다. 이전 VPN, 조직에서 배포한 설정, 다른 네트워크 확장이 있다면 각각의 용도를 먼저 확인하세요. 관리 대상 기기는 변경이 제한될 수 있습니다. 용도를 모르는 기업용 설정을 삭제해 연결을 시도하지 말고 기기 관리자에게 허용 범위를 확인하세요.

연결 버튼이 켜져 있다는 것은 앱이 트래픽 처리 터널을 만들려고 했다는 뜻일 뿐입니다. 실제 요청을 보내고 앱에서 제공하는 연결 또는 로그 화면에서 결과를 확인하세요. 직접 연결해야 하는 로컬 서비스도 따로 테스트해야 합니다. 모바일 VPN 확장은 데스크톱 시스템 프록시와 이름만 다른 대체 기능이 아닙니다. 보통 Wi-Fi 설정에 로컬 포트를 다시 입력할 필요가 없습니다. 실수로 남아 있는 수동 프록시는 현재 값을 기록한 뒤 원래대로 복원해 다른 경로가 테스트에 영향을 주지 않도록 하세요.

필요 시 연결, 네트워크 전환, LAN 접속

앱에서 필요 시 연결을 지원한다면 기본 연결이 안정된 뒤 설정하고 트리거 조건을 하나씩 확인하세요. 네트워크 유형이나 Wi-Fi 조건을 기준으로 동작하는 정책도 있고 도메인 요청에 따라 연결되는 정책도 있습니다. ‘자동’이라는 표시만 보고 동작을 짐작하지 마세요. 처음 테스트할 때는 화면 잠금 후 복귀, Wi-Fi에서 셀룰러로 전환, 셀룰러에서 Wi-Fi로 전환하는 세 가지 상황을 모두 확인하세요. 전환 후 잠깐 끊기는 정도라면 확장 재연결과 DNS 갱신을 먼저 살펴보세요. 곧바로 모든 규칙을 전역으로 바꾸지 마세요.

공용 네트워크에서 웹 인증이 필요하면 자동 재연결을 잠시 중지하고 로그인한 뒤 연결을 다시 시작하세요. 그렇지 않으면 필요 시 연결 규칙이 아직 사용할 수 없는 네트워크로 트래픽을 계속 보낼 수 있습니다. 가정용 저장 장치, 프린터, 화면 미러링 기기에 접속하려면 앱의 LAN 접근 권한과 설정의 직접 연결 규칙을 확인하세요. 기기 검색에는 브로드캐스트나 멀티캐스트도 필요한 경우가 있어 도메인 규칙 하나만 추가해서 해결되지 않을 수 있습니다. 기기 검색 실패와 알고 있는 주소로 연결 실패를 구분하세요.

mihomo의 TUN 또는 DNS 설정 전체를 휴대폰 설정에 그대로 붙여 넣으면 작동한다고 가정하지 마세요. 모바일 클라이언트는 설정 모델이 다르거나 일부 필드만 지원할 수 있으므로 가져오기 결과와 기능 안내를 기준으로 판단하세요. 브라우저 자체의 DNS 정책, 시스템 개인정보 보호 기능, VPN 확장의 상호작용도 관측 결과에 영향을 줍니다. 비교가 필요하면 한 번에 한 항목만 임시로 바꾸고 원래 상태를 기록한 뒤, 테스트가 끝나면 관련 없는 설정을 복원하세요.

화면이 꺼진 뒤 배터리 소모가 눈에 띄게 늘었다면 잦은 속도 측정, 지속적인 로그 기록, 과도한 업데이트, 네트워크 불안정으로 인한 재연결이 있는지 먼저 확인하세요. 백그라운드 확장이 계속 실행될 수 있는지는 시스템 스케줄링과 리소스 상황에도 달려 있습니다. 데스크톱의 상시 실행 프로세스 경험만으로 모바일 동작을 예측할 수 없습니다. 앱을 반복해서 강제 종료하고 다시 시작하기보다 적절한 업데이트 간격을 설정하는 편이 원인을 찾기 쉽습니다. 자세한 내용은 모바일 실행 및 배터리 관리 안내를 참고하세요.

기기를 바꾸기 전에 구독 출처와 필요한 사용자 지정 규칙을 별도로 저장하세요. 시스템 백업에 민감한 설정이 모두 포함된다고 가정하지 마세요. 이전이 끝나면 활성 구독, 프록시 선택, 필요 시 연결 조건을 다시 확인하고 두 종류의 네트워크에서 테스트하세요. 앱을 오랫동안 사용하지 않을 때는 앱에서 연결을 끊고 시스템 VPN 상태를 확인하세요. 웹페이지에 문제가 생기면 필요 시 연결이 자동으로 다시 시작되는지 먼저 확인하세요. 앱 화면만 닫았다고 트래픽 처리가 완전히 중지되었다고 볼 수는 없습니다.

Linux: 데스크톱 설치, 코어 실행, 라우팅 확인

데스크톱 클라이언트와 패키지 형식 선택

Linux 데스크톱 사용자는 Linux 다운로드에서 Clash Verge Rev를 먼저 확인하고, 다음으로 FlClash를 살펴보세요. 배포판에 맞는 DEB 또는 RPM 패키지를 선택하고 프로세서 아키텍처도 확인해야 합니다. 패키지 형식은 소프트웨어 관리 체계와 관련되고 아키텍처는 프로세서와 관련되므로, Linux용이라는 이유만으로 서로 바꿔 쓸 수는 없습니다. 서버, 라우터, 그래픽 환경이 없는 기기에서는 코어 섹션을 참고할 수 있지만 설정 디렉터리, 프로세스, 로그, 라우팅을 직접 관리해야 합니다. 파일이 작다는 이유만으로 코어만 사용하는 방식을 우선 선택하지 마세요.

설치 전에 다음 명령으로 아키텍처와 배포판 정보를 확인할 수 있습니다. 일반적인 x86_64는 보통 AMD64에, aarch64는 보통 ARM64에 해당합니다. 라우터는 부동소수점 및 명령어 지원이 다를 수도 있으므로 기기별 정보를 확인하세요. 다운로드 페이지의 데스크톱 패키지가 모든 아키텍처를 지원하지는 않습니다. 호환되지 않는 경우 의존성을 강제로 무시하고 설치하지 마세요. 시작 단계에서 문제가 생길 뿐입니다.

uname -m
cat /etc/os-release

배포판의 소프트웨어 설치 도구로 로컬 패키지를 설치하고, 누락된 의존성이나 그래픽 실행 환경 관련 안내가 있는지 확인하세요. 클라이언트 창이 열린 다음에 프록시와 서비스 권한을 설정하면 디스플레이 서버, 데스크톱 라이브러리, 네트워크 문제를 구분하기 쉽습니다. 비슷한 도구를 여러 개 설치했다면 다른 인스턴스와 백그라운드 서비스를 먼저 중지하세요. 같은 포트를 여러 프로그램이 사용하거나 여러 서비스가 동시에 라우팅을 변경하면 클라이언트가 실행 직후 연결을 끊는 것처럼 보일 수 있습니다.

구독 가져오기와 데스크톱 시스템 프록시

그래픽 클라이언트에서 원격 구독을 추가하고 다운로드가 끝나면 현재 설정으로 선택한 뒤 프록시 그룹을 확인하세요. Linux의 시스템 프록시 동작은 데스크톱 환경과 앱 구현에 따라 다릅니다. 일부 브라우저는 데스크톱 설정을 읽지만 터미널 도구는 환경 변수만 읽을 수 있습니다. 시스템 프록시를 켠 뒤 먼저 브라우저를 테스트하고, 터미널에서는 프록시 매개변수를 명시해 테스트하세요. 이렇게 하면 코어 자체가 작동하지 않는지, 앱이 데스크톱 프록시 설정을 사용하지 않는지 구분할 수 있습니다.

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

포트는 클라이언트에서 실제로 수신 중인 값과 일치해야 합니다. 테스트 URL은 요청을 보내기 위한 것이며, 특정 HTTP 상태 코드가 돌아왔다고 모든 서비스가 정상이라는 뜻은 아닙니다. 연결 로그에서 해당 요청이 표시되는지, 어떤 정책이 선택되었는지 확인해야 경로를 판단할 수 있습니다. 환경 변수를 임시로 설정해야 한다면 먼저 현재 터미널 세션에서 테스트하고 시스템 전체 설정에 바로 추가하지 마세요. 도구마다 변수 이름의 대소문자 처리와 SOCKS·HTTP 프록시 지원이 다를 수 있고, 별도 설정이 환경 변수를 덮어쓸 수도 있습니다.

코어 단독 실행과 최소 권한

mihomo를 단독으로 사용할 때는 전용 설정 디렉터리를 만들고 검증된 전체 설정을 config.yaml로 저장하세요. 설정에서 참조하는 규칙 파일 등 필요한 리소스도 준비해야 합니다. 아래 예시는 압축을 푼 실행 파일의 이름이 mihomo이고, 설정 파일이 사용자 디렉터리의 전용 위치에 있다고 가정합니다. 설정을 검사한 뒤 포그라운드에서 실행하고 오류 메시지를 직접 확인하세요. 문법 검사를 통과하기 전에 서비스 등록부터 서두르지 마세요.

mkdir -p "$HOME/.config/mihomo"
chmod u+x ./mihomo
./mihomo -t -d "$HOME/.config/mihomo"
./mihomo -d "$HOME/.config/mihomo"

기본 프록시 수신에는 관리자 권한이 필요하지 않을 수 있지만 TUN 생성, 라우팅 변경, 일부 DNS 작업에는 추가 권한이 필요합니다. 그래픽 클라이언트는 서비스 관리 기능을 제공할 수 있으며, 코어만 사용하는 경우에는 배포판의 서비스 및 권한 관리 방식에 맞춰 설정해야 합니다. 전체 데스크톱 세션을 계속 높은 권한으로 실행하지 말고, 검증하지 않은 구독을 광범위한 시스템 권한을 가진 프로세스에 전달하지 마세요. 원격 제어 인터페이스는 꼭 필요할 때만 켜고 수신 범위와 접근 권한을 제한하세요.

TUN, DNS 관리, 원격 기기 복구 방법

TUN을 켜기 전에 시스템에 필요한 가상 네트워크 장치가 있는지 확인하고 현재 라우팅, 다른 VPN, 방화벽 규칙을 점검하세요. 시스템은 NetworkManager, systemd-resolved 또는 다른 DNS 관리 방식을 사용할 수 있습니다. /etc/resolv.conf를 직접 덮어쓰면 관리자가 곧바로 원래대로 바꾸거나 기존 설정이 손상될 수 있습니다. 먼저 파일이 심볼릭 링크인지 확인하고 DNS를 관리하는 주체를 파악한 뒤 클라이언트가 지원하는 방식으로 DNS를 설정하세요. 서로 덮어쓰는 DNS 가로채기 기능을 여러 개 동시에 켜지 마세요.

SSH로 서버를 원격 관리할 때는 특히 주의하세요. 기본 경로를 변경하면 관리 연결도 프록시를 통과해 세션이 끊길 수 있습니다. 콘솔이나 다른 복구 경로를 확보하고 관리 대상 주소가 직접 연결되도록 규칙을 확인한 뒤 트래픽 처리 범위를 테스트하세요. ip route와 ip rule로 변경 사항을 확인하고 클라이언트 로그에서 실제 요청을 검증하세요. 가상 네트워크 어댑터가 표시된다고 정책 라우팅과 DNS까지 올바르다는 뜻은 아닙니다.

기본 실행이 안정된 뒤 서비스 관리자로 전환하세요. 실행 파일, 작업 디렉터리, 설정 경로를 고정해 업데이트 후 서비스가 임시 다운로드 디렉터리를 참조하지 않도록 합니다. 서비스는 수동 실행과 사용자, 환경 변수, 터미널 환경이 다르므로 수동 실행은 성공하지만 백그라운드 실행이 실패하면 경로, 읽기 권한, 로그부터 확인하세요. 노드를 다시 바꿀 문제가 아닙니다. 마지막으로 서비스를 중지했을 때 라우팅이 복구되고 DNS가 원래대로 돌아오는지 확인하세요. 정상 작동하는 설정을 보관하고 이후 업데이트에서는 한 번에 한 요소만 교체하세요.

설정 문제 해결: 구독, 규칙, DNS, 연결 확인

구독 업데이트 실패와 설정 덮어쓰기

먼저 ‘주소에서 다운로드할 수 없음’과 ‘다운로드 후 파싱 실패’를 구분하세요. 전자는 네트워크, 시간, 포털 인증, 구독 권한, 서비스 상태를 확인합니다. 후자는 응답 형식, 프로토콜 지원, YAML 오류 줄을 살펴보세요. 로그인 페이지나 오류 페이지가 반환되면 다운로드 요청에 응답이 있더라도 유효한 설정이 아닙니다. 일부 클라이언트에서는 업데이트 요청을 직접 연결 또는 프록시로 보낼 수 있습니다. 이미 사용 가능한 설정이 있을 때만 두 경로를 비교하세요. 아직 연결되지 않은 프록시를 통해 유일한 구독을 업데이트하려고 해서는 안 됩니다.

구독을 업데이트한 뒤 사용자 지정 규칙이 사라졌다면 원격 설정 캐시를 직접 수정했을 가능성이 큽니다. 장기적으로 유지할 설정은 클라이언트의 오버라이드 또는 병합 기능으로 옮기고 규칙을 앞에 추가하는지 뒤에 추가하는지 확인하세요. 일반적인 규칙은 순서대로 처음 일치하는 항목을 적용하므로 끝에 넣은 사용자 지정 규칙이 적용되지 않을 수 있습니다. 원격 원본 설정과 로컬 확장을 각각 보관하고 문제가 생기면 먼저 확장을 일시적으로 꺼서 테스트하세요. 더 자세한 사례는 구독 업데이트 자주 묻는 질문을 참고하세요.

규칙 모드, 전역 모드, 노드 테스트

규칙 모드는 규칙에 따라 정책을 선택합니다. 전역 모드는 코어에 들어온 연결을 전역 프록시 그룹으로 보내며, 직접 연결 모드는 보통 해당 연결을 직접 전송합니다. 모드 설정은 이미 코어에 들어온 트래픽만 제어합니다. 트래픽이 처리되지 않는 앱을 자동으로 프록시로 연결하지는 않습니다. 전역 모드는 작동하지만 규칙 모드가 실패한다면 규칙에서 직접 연결 또는 빈 정책을 선택했는지 확인하세요. 두 모드 모두 실패한다면 노드와 트래픽 처리 설정을 살펴보세요. 전역 모드가 DNS나 권한 문제까지 해결해 주는 것은 아닙니다.

노드 테스트는 일반적으로 특정 테스트 주소에 대한 한 번의 요청만 보여줍니다. 실제 다운로드 속도, 모든 웹사이트의 접속 가능 여부, 장기 안정성을 보장하지는 않습니다. 테스트는 성공하지만 대상에 접속할 수 없다면 대상에 적용된 규칙, 원격 서비스 제한, 연결 프로토콜을 확인하세요. 테스트는 실패해도 웹페이지가 열린다면 테스트 주소와 시간 초과 조건을 살펴보세요. 한 번의 결과만으로 노드를 대량 삭제하지 말고 같은 네트워크와 대상으로 비교하세요. 노드 지연 시간 설명과 연결 속도 단계별 점검도 참고할 수 있습니다.

fake-ip, DNS 가로채기, 앱 캐시

fake-ip는 도메인에 가상 주소를 할당합니다. 이후 연결이 같은 코어로 들어오면 주소를 도메인으로 다시 매핑해 규칙을 적용합니다. 이는 도메인과 연결을 연동하기 위한 기능이지, 켠다고 모든 DNS 조회가 동일한 출구를 사용하도록 보장하는 기능은 아닙니다. 앱이 시스템 DNS를 우회하거나 브라우저가 별도의 암호화 DNS를 사용하거나 이전 캐시에 실제 주소가 남아 있으면 관측 결과가 달라질 수 있습니다. 아래는 mihomo 설정 조합의 일부입니다. 기존 설정과 클라이언트 지원 여부에 맞춰 병합해야 하며 모바일 공통 템플릿이 아닙니다.

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

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

예시에 나온 상위 DNS 서버는 현재 네트워크와 라우팅 정책에서 접속할 수 있어야 합니다. DNS 서버에 연결할 수 없다면 캐시를 반복해서 지워도 해결되지 않습니다. 53번 포트의 트래픽을 가로챈다고 모든 암호화 DNS까지 처리되는 것도 아닙니다. 도메인별로 상위 DNS를 선택한다면 해당 DNS 서버 도메인을 처음 해석하는 방법과 원격 노드 도메인의 DNS 조회가 순환하는 문제도 고려해야 합니다. LAN 도메인, 기기 검색, 특정 앱은 필요에 따라 예외로 지정할 수 있지만 범위를 구체적으로 정해 전체 도메인이 우회되지 않도록 하세요.

DNS를 확인할 때는 시스템 조회, 앱 요청, 연결 로그를 함께 살펴보세요. 탐지 페이지에 특정 지역이 표시된다는 이유만으로 DNS 유출이라고 단정하지 마세요. 재귀 DNS 서버의 위치와 웹사이트에서 확인하는 출구 주소는 일대일로 연결되지 않습니다. 캐시, 공용 DNS의 요청 분산, 탐지 방식도 결과에 영향을 줄 수 있습니다. DNS 요청이 외부로 빠져나가는지 확인하려면 먼저 예상 경로를 정하고 특정 조회를 비교하세요. 자세한 방법은 DNS 테스트와 fake-ip 설정 실전 가이드를 참고하세요.

전체 설정을 초기화하지 말고 문제 단계별로 되돌리기

속도가 느리면 먼저 대상 서비스가 속도를 제한하는 것은 아닌지 확인한 뒤 같은 노드와 네트워크, 비슷한 시간대의 결과를 비교하세요. 대용량 연결만 멈추는 경우에 한해 MTU, UDP 경로, 네트워크 장비 호환성을 살펴보세요. 인터넷에서 찾은 고정 MTU 값을 모든 플랫폼에 적용하지 마세요. 문제를 재현하는 동안 로그 수준을 일시적으로 높이면 원인 파악에 도움이 됩니다. 재현 후에는 일반 수준으로 되돌리고 외부에 공유하기 전에 구독 정보, 인증 정보, 개인 접속 기록을 삭제하세요.

최종 점검에서는 프록시 연결 대상, 직접 연결 대상, LAN 서비스, 네트워크 전환, 트래픽 처리 중지의 다섯 항목을 확인하세요. 정상 작동할 때의 수신 포트, 활성 설정, 모드, 권한 상태를 기록해 두면 이후 변경 사항을 비교할 수 있습니다. 전체 가이드에서 설정 범위와 다양한 경우를 확인하고 구체적인 문제는 자주 묻는 질문을 참고하세요. 연결이 안정되었다면 설정 항목을 늘리기 위해 이미 필요한 작업을 하는 설정을 계속 바꿀 필요는 없습니다.