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

공통 준비 사항

운영체제, 아키텍처, 구성 출처 확인

설치하기 전에 운영체제와 프로세서 아키텍처를 확인하세요. macOS에서는 ‘이 Mac에 관하여’에서 칩을 확인하고, Windows에서는 ‘설정 → 시스템 → 정보’에서 시스템 종류를 확인할 수 있습니다. Linux에서는 uname -m을 실행하세요. 아키텍처는 프로그램 실행 가능 여부를, 파일 형식은 설치 방법을 결정하므로 서로 대체할 수 없습니다. 파일 이름에 운영체제가 표시되어 있는지만 보지 말고 다운로드 항목의 아키텍처와 프로젝트가 안내하는 최소 시스템 요구 사항도 확인하세요.

클라이언트 자체가 프록시 서비스인 것은 아닙니다. 클라이언트는 설정 관리, 프록시 연결, 트래픽 처리 기능을 제공하며 실제 사용에는 유효한 구독 주소나 사용할 수 있는 아웃바운드가 포함된 로컬 구성이 필요합니다. 구독이 신뢰할 수 있는 출처에서 제공되고 아직 유효한지, 호환되는 클라이언트나 코어가 무엇인지 확인하세요. 구독 링크에는 계정 식별 정보가 포함되는 경우가 많으므로 공개 댓글이나 스크린샷, 문제 보고서에 올리지 마세요.

마이그레이션 전에 기존 구성을 저장하고 사용 중인 프록시 그룹, 혼합 포트, 트래픽 경로를 기록하세요. 구독 내용은 원격 업데이트로 덮어써질 수 있습니다. 계속 유지해야 할 변경 사항은 클라이언트의 오버라이드, 확장 또는 병합 기능을 활용하는 것이 좋습니다. 이런 기능이 없다면 로컬 구성으로 복사해 테스트할 수 있지만, 이후 구독 업데이트가 복사본에 자동 반영되지 않는다는 점에 유의하세요.

구성, 아웃바운드, 트래픽 경로 구분하기

연결은 서로 독립적인 세 단계로 이뤄집니다. 구성을 불러오고, 요청을 전달할 아웃바운드를 정한 다음, 앱의 트래픽을 클라이언트로 보내야 합니다. 가져오기에 성공했다는 것은 내용이 저장되었다는 뜻일 뿐, 설정이 활성화되었다는 의미는 아닙니다. 프록시 그룹이 표시되어도 시스템 프록시가 켜져 있다는 뜻은 아닙니다. 처음 설정할 때는 이 순서대로 확인해 설정이 적용되기 전에 네트워크 옵션을 반복해서 바꾸지 않도록 하세요.

규칙 모드에서는 규칙 순서에 따라 요청을 처리하므로 모든 요청이 프록시를 통과하지는 않습니다. 전역 모드는 일반적으로 클라이언트에 들어온 요청을 선택한 전역 아웃바운드로 전달하며, 클라이언트를 거치지 않는 앱까지 자동으로 처리하지는 않습니다. 직접 연결 모드도 클라이언트를 종료하는 것은 아니므로 트래픽은 로컬 리스너와 DNS 처리를 거칠 수 있습니다. 자세한 내용은 가상 네트워크 인터페이스와 시스템 프록시의 작동 방식 비교를 참조하세요.

처음에는 하나의 트래픽 경로만 사용하세요

데스크톱에서는 먼저 시스템 프록시만 켜고 브라우저로 설정을 확인하세요. 시스템 프록시를 따르지 않는 프로그램이 있을 때 TUN 모드를 고려하면 됩니다. 모바일에서는 일반적으로 시스템이 승인한 VPN 인터페이스로 트래픽을 처리하므로 데스크톱의 수동 프록시 절차를 그대로 적용할 필요가 없습니다. 첫 테스트에서는 다른 VPN, 이전 프록시 클라이언트, 트래픽 처리 도구를 종료하고 일반 방화벽은 유지한 상태에서 결과를 확인하세요. 여러 설정을 동시에 바꾸지 않는 것이 좋습니다.

복구 가능한 테스트 기준 만들기

기본 네트워크 확인용으로 원래 직접 연결할 수 있는 웹사이트 하나를 선택하고, 분할 라우팅 확인용으로 현재 규칙에 따라 프록시를 사용해야 하는 사이트 하나를 선택하세요. 연결 화면에서 도메인, 적용된 규칙, 프록시 그룹, 최종 아웃바운드를 확인합니다. 페이지가 열리는지만으로 구성이 올바르다고 판단하지 마세요. 캐시, 기존 연결, 직접 연결 규칙이 결과에 영향을 줄 수 있습니다. 테스트할 때는 새 요청을 보내고, 필요하면 앱을 닫았다가 다시 여세요.

클라이언트를 종료하기 전에 시스템 프록시를 끄거나 VPN 연결을 끊고 네트워크가 복구되는지 확인하세요. 시스템에 로컬 포트를 가리키는 프록시 설정이 남아 있는데 클라이언트가 리스닝을 중지하면 앱이 인터넷에 연결되지 않을 수 있습니다. 재설치보다 복구 방법을 미리 알아두는 것이 효과적입니다. 이후 문제를 해결할 때는 설정을 한 번에 하나씩 바꾸고 변경 사항을 기록하세요. 그래야 구성, 권한, 트래픽 경로 중 무엇이 원인인지 파악할 수 있습니다.

macOS 설치 및 설정

칩 아키텍처를 선택하고 설치하기

macOS 클라이언트에서 Clash Plus를 먼저 확인하세요. 구성 호환성에 따라 Clash Verge Rev 또는 FlClash를 선택할 수도 있습니다. Apple Silicon 기기는 해당 아키텍처용 설치 파일을, Intel 기기는 Intel용 패키지를 선택하세요. ClashX Meta는 유지 관리가 중단된 보관용 옵션으로 기존 환경에 주로 사용됩니다. 보관된 클라이언트가 새 시스템과 호환된다고 보장되는 것은 아닙니다.

디스크 이미지를 연 다음 앱을 ‘응용 프로그램’ 폴더로 드래그하고 해당 위치에서 실행하세요. 디스크 이미지 안에서 계속 실행하면 이후 업데이트, 보조 서비스 위치 지정, 권한 등록이 불안정해질 수 있습니다. 다른 형식으로 다운로드했다면 다운로드 페이지와 설치 프로그램의 안내를 따르세요. 처음 실행할 때 앱 출처와 이름을 확인하고, 경고를 피하려고 시스템 보안 기능을 일괄 해제하지 마세요.

앱이 열리지 않거나 보안 경고가 표시되면 아키텍처 불일치, 시스템 요구 사항 미충족, 첫 실행 차단 중 무엇인지 먼저 확인하세요. 출처가 확인된 앱은 ‘시스템 설정 → 개인정보 보호 및 보안’에서 열기 옵션을 제공하는지 확인할 수 있습니다. 시스템 버전에 따라 안내 문구가 다릅니다. 앱이 손상되었다는 메시지가 분명히 표시되면 보안 속성을 삭제하는 명령을 무작정 실행하지 말고, 먼저 설치 파일을 다시 다운로드하고 출처를 확인하세요.

구독을 가져와 현재 사용 중인 구성을 확인하기

구성 화면에서 링크 가져오기를 선택하고 전체 구독 주소를 붙여넣은 뒤 저장한 다음 다운로드가 끝날 때까지 기다리세요. 일부 클라이언트에서는 구성 추가 또는 새 구성 메뉴에 가져오기 기능이 있습니다. 가져온 뒤 해당 구성을 직접 선택하고 실행 상태와 로그를 확인해 코어가 정상적으로 로드되었는지 확인하세요. 항목은 표시되는데 프록시 화면이 비어 있다면 구성이 활성화되지 않았거나 구성 자체에 유효한 프록시 그룹이 없는지 확인하세요.

로컬 YAML 파일은 파일 가져오기로 불러올 수 있지만, 파일의 상대 경로 참조, 규칙 세트, 외부 리소스는 네트워크 연결이 필요할 수 있습니다. 편집 전에 복사본을 보관하세요. 특히 구독에서 생성된 파일을 직접 수정한 뒤 업데이트를 누르면 변경 사항이 사라질 수 있습니다. 업무용 도메인에 직접 연결 규칙을 추가하려면 클라이언트의 지속적인 확장 기능을 사용하고, 구독 업데이트 후 실제 적용된 내용도 다시 확인하세요.

먼저 시스템 프록시를 켜고 필요할 때 TUN 설정하기

프록시 화면에서 규칙 모드를 선택하고 수동 선택이 필요한 프록시 그룹에 사용할 수 있는 아웃바운드를 지정한 다음 시스템 프록시를 켜세요. 시스템 네트워크 설정을 처음 변경할 때 클라이언트가 권한을 요청할 수 있습니다. 현재 작업과 명확히 관련된 경우에만 승인하세요. ‘시스템 설정 → 네트워크’에서 현재 네트워크 서비스를 선택하고 프록시가 로컬 주소를 가리키는지, 포트가 클라이언트의 혼합 포트와 일치하는지 확인하세요. macOS 버전에 따라 시스템 메뉴 경로가 조금씩 다릅니다.

브라우저는 대개 시스템 프록시를 사용하지만 명령줄 도구는 그렇지 않을 수 있습니다. 앱의 동작을 구분하려면 요청 하나를 로컬 포트로 직접 보내 테스트하세요. 아래 내용은 혼합 포트가 7890으로 설정된 경우에만 해당합니다. 실제 포트가 다르면 먼저 클라이언트에 표시된 값으로 바꾸세요. 명령은 일반 테스트 주소를 사용하며, 명시적 프록시 경로가 연결되는지만 확인합니다. 모든 규칙이 올바르다는 것을 단독으로 증명하지는 않습니다.

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

게임, 명령줄 도구 또는 시스템 프록시를 따르지 않는 다른 앱의 트래픽을 처리해야 할 때 TUN 모드를 시도하세요. 클라이언트에서 보조 서비스 설치나 네트워크 확장 권한을 요청할 수 있습니다. 안내에 따라 설정을 마친 뒤 로그를 다시 확인하세요. 일반적인 데스크톱 사용을 위해 LAN 연결 허용을 켤 필요는 없습니다. TUN의 DNS, 라우팅, 인터페이스 자동 감지는 현재 클라이언트의 안내에 따라 설정하세요. 다른 플랫폼의 가상 네트워크 인터페이스 매개변수를 그대로 복사하면 안 됩니다.

절전 모드, 네트워크 전환, 종료 후 남은 설정 처리

Wi-Fi에서 유선 네트워크로 전환하거나 절전 모드에서 복귀한 뒤 프록시 요청만 실패한다면 먼저 연결을 다시 설정하고 실제 사용 중인 네트워크 인터페이스를 확인하세요. 시스템 프록시는 네트워크 서비스별로 저장되므로 이전 인터페이스의 설정이 새 인터페이스에도 적용되는 것은 아닙니다. TUN을 사용한다면 네트워크 변경 후 경로가 다시 설정되었는지 확인하세요. 먼저 TUN을 껐다 켜서 비교하고, 네트워크 설정 전체를 동시에 초기화하지 마세요.

종료 후 인터넷에 연결되지 않으면 현재 네트워크 서비스의 웹 프록시와 보안 웹 프록시가 여전히 로컬 주소를 가리키는지 확인하세요. 앱을 삭제하기 전에 남아 있는 프록시 설정부터 정리하세요. 보조 서비스를 설치했다면 클라이언트가 안내하는 제거 방법을 따르고 시스템 디렉터리에서 임의로 파일을 삭제하지 마세요. 연결 화면과 로그 화면의 역할은 클라이언트 화면 안내에서 확인해 오류가 발생한 단계를 파악할 수 있습니다.

Windows 설치 및 설정

설치 파일, 계정 권한, 첫 실행

Windows 클라이언트에서 Clash Plus를 먼저 선택하세요. 다른 옵션으로 Clash Verge Rev, FlClash, Clash Nyanpasu가 있으며, Clash for Windows는 유지 관리가 중단된 보관용 클라이언트입니다. 선택할 때 시스템 종류와 다운로드 항목의 설명을 확인하세요. 시스템이 ARM64라고 해서 모든 설치 파일이 네이티브로 호환되는 것은 아닙니다. 설치 프로그램과 포터블 압축 파일의 사용 방법도 혼동하지 마세요.

설치 프로그램을 실행하고 안내에 따라 설치 위치를 선택하세요. 포터블 패키지를 사용한다면 현재 계정에서 쓸 수 있는 고정 폴더에 압축을 완전히 푼 다음 실행하세요. 압축 프로그램의 미리보기 창에서 바로 실행하지 마세요. 구성, 로그, 업데이트 파일은 사용자 데이터 폴더에 저장될 수 있으므로 프로그램 위치가 곧 구성 위치인 것은 아닙니다. PC를 옮길 때는 클라이언트의 내보내기 기능이나 안내된 백업 방법을 사용하세요. 바탕 화면 바로 가기만 복사해서는 안 됩니다.

일반적인 시스템 프록시 사용에는 주 화면을 계속 관리자 권한으로 실행할 필요가 없습니다. 서비스를 설치하거나 가상 네트워크 인터페이스를 만들거나 특정 네트워크 설정을 변경할 때만 클라이언트가 권한 상승을 요청할 수 있습니다. 보안 경고가 표시되면 게시자, 출처, 경로를 먼저 확인하세요. 조직에서 관리하는 기기는 정책의 제한을 받을 수 있습니다. ‘관리자 권한으로 실행’을 모든 오류의 해결책으로 여기지 마세요. 유효하지 않은 구독이나 잘못된 아웃바운드는 이 방법으로 해결되지 않습니다.

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

구성 화면에서 구독을 가져오고 업데이트가 완료되면 해당 항목을 선택해 코어를 다시 로드하세요. 프록시 화면에서 프록시 그룹을 확인하고 사용할 아웃바운드를 선택한 다음 규칙 모드를 사용하세요. 시스템 프록시를 켠 뒤 ‘설정 → 네트워크 및 인터넷 → 프록시’에서 수동 프록시가 적용되었는지 확인합니다. 클라이언트가 보통 로컬 주소와 리스닝 포트를 설정하지만 최종적으로는 현재 시스템 설정을 기준으로 확인해야 합니다.

브라우저는 정상인데 특정 데스크톱 앱만 실패한다면 앱에 별도 프록시 설정이 있는지 확인하세요. 시스템 설정을 따르는 프로그램도 있고 자체 프록시 옵션만 사용하는 프로그램도 있으며, 다른 Windows 네트워크 구성 요소를 사용하는 프로그램도 있습니다. 시스템 프록시는 모든 프로세스에 강제로 적용되는 경로가 아닙니다. 한 앱 때문에 전역 모드를 반복해서 바꾸지 마세요. 전역 모드는 아웃바운드 선택을 바꿀 뿐, 앱이 클라이언트로 들어오는 경로를 바꾸지 않습니다.

PowerShell에서 curl.exe를 호출해 프록시를 명시적으로 테스트하면 환경에 따라 curl 명령의 동작이 달라지는 문제를 피할 수 있습니다. 먼저 혼합 포트가 예시의 값인지 확인한 다음 명령을 실행하세요. 명시적 프록시 요청은 성공하는데 대상 앱의 연결 기록이 없다면 DNS를 먼저 바꾸기보다 앱의 트래픽 경로를 확인하세요. 테스트 결과는 연결 화면에 표시된 규칙과 아웃바운드 정보와 함께 판단해야 합니다.

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

TUN 서비스, 방화벽, UWP 루프백

더 많은 프로그램의 트래픽을 클라이언트로 보내려면 소프트웨어 안내에 따라 서비스를 설치하고 TUN을 켤 수 있습니다. 활성화 후 로그에서 권한, 네트워크 인터페이스 생성, 라우팅 오류가 보고되는지 확인한 다음 대상 프로그램을 테스트하세요. 방화벽 안내는 네트워크 프로필에 맞춰 확인하고 필요한 범위에만 권한을 부여하세요. 로컬에서만 사용할 경우 LAN 공유를 함께 켜지 마세요. 방화벽은 인바운드 접근을 제어하며, TUN과 프록시 규칙은 다른 계층을 담당하므로 서로 대체할 수 없습니다.

일부 스토어 앱은 AppContainer 격리 환경에서 실행되어 로컬 프록시 리스너에 접근하지 못할 수 있습니다. 일반 브라우저가 인터넷에 연결되어도 이런 앱은 실패할 수 있습니다. 클라이언트가 UWP 루프백 도구를 제공한다면 먼저 앱의 ID를 확인한 뒤 필요한 앱에만 예외를 설정하세요. 명령줄 사용법과 복구 방법은 UWP 루프백 예외 및 CheckNetIsolation 설정 방법을 참조하세요. 모든 앱을 한꺼번에 허용하지 마세요.

포트 충돌, 남은 프록시 설정, 네트워크 복구

로그에 주소 사용 중 또는 리스닝 실패가 표시되면 클라이언트가 중복 실행되었거나 이전 프로세스가 종료되지 않았는지 확인하세요. 혼합 포트는 현재 코어가 정상적으로 리스닝해야 하며 시스템 설정의 포트도 일치해야 합니다. 리스닝 포트를 변경했다면 수동 설정도 함께 업데이트할 수 있습니다. 클라이언트의 포트는 그대로 둔 채 시스템 프록시 포트만 바꾸면 요청이 서비스가 없는 위치로 전송됩니다.

사용을 중지할 때는 시스템 프록시와 TUN을 끈 다음 프로그램을 종료하세요. 비정상 종료 후 인터넷이 연결되지 않으면 시스템 프록시 화면에서 남은 설정을 정리하세요. 명령줄에서만 문제가 발생한다면 현재 터미널의 프록시 환경 변수도 확인해야 합니다. VPN, 가상 머신 네트워크, 회사 보안 소프트웨어가 동시에 라우팅을 바꿀 수 있습니다. 문제를 해결할 때는 직접 제어할 수 있는 트래픽 처리 도구를 하나씩 끄고 변경 사항을 기록하세요. 네트워크 설정 전체를 바로 초기화하는 것은 권장하지 않습니다.

Android 설치 및 설정

설치 파일을 선택하고 설치 권한 설정하기

Android 클라이언트에서 Clash Plus를 먼저 확인하고, 필요에 따라 Clash Meta for Android, FlClash, Surfboard를 선택할 수도 있습니다. 클라이언트마다 지원하는 구성 형식이 완전히 같지는 않습니다. 구독 이름이 비슷하다고 호환된다고 단정하지 마세요. 먼저 서비스 제공업체가 지원하는 형식을 확인한 다음 클라이언트를 선택하면 가져오기에 실패한 뒤 형식 변환을 반복하는 시간을 줄일 수 있습니다.

설치 전에 시스템 버전과 프로세서 아키텍처를 확인하세요. 최신 기기 대부분은 ARM64를 사용하지만 휴대전화의 외관이나 출시 시기로 실제 정보를 대신할 수는 없습니다. 기기 설정이나 신뢰할 수 있는 시스템 정보 화면에서 확인하세요. 범용 패키지는 아키텍처 선택을 간소화할 뿐 시스템 버전 제한까지 해결하지는 않습니다. 설치 프로그램에서 호환되지 않는다고 표시되면 이름이 비슷한 파일을 계속 바꾸어 시도하지 말고 다운로드 페이지에서 요구 사항을 확인하세요.

브라우저나 파일 관리자로 설치 패키지를 열 때 Android에서 해당 출처의 앱 설치 권한을 허용하라고 요청할 수 있습니다. 신뢰할 수 있는 현재 출처에만 일시적으로 권한을 부여하고 설치가 끝나면 원래 설정으로 되돌리세요. 기존 앱과 새 패키지의 서명이 맞지 않으면 덮어쓰기가 거부될 수 있습니다. 먼저 구성과 구독을 저장한 뒤 기존 앱을 삭제할지 결정하세요. 백업하지 않은 상태에서 데이터를 지우지 마세요.

구독을 가져오고 VPN 연결 승인하기

구성 관리 화면에서 원격 구독을 추가하거나 로컬 파일을 가져온 뒤 콘텐츠 다운로드가 끝날 때까지 기다리세요. 그런 다음 현재 구성으로 선택합니다. 다른 앱에서 링크를 열었다면 선택한 클라이언트가 실제 수신 앱인지 확인하세요. 클립보드나 QR 코드의 링크도 전체 내용이 맞는지 확인해야 합니다. 가져오기에 실패하면 링크가 구성 본문이 아닌 로그인 페이지, 웹 안내, 오류 메시지를 반환하는 것은 아닌지 먼저 확인하세요.

연결을 시작하면 시스템에 VPN 연결 요청이 표시됩니다. 승인해야 Android VPN 인터페이스를 통해 앱 트래픽을 받을 수 있습니다. 시스템 권한을 승인했다고 원격 아웃바운드 연결까지 성공한 것은 아닙니다. 프록시 그룹에서 사용 가능한 아웃바운드를 선택하고 로그를 확인하세요. VPN 아이콘은 인터페이스가 작동 중임을 나타낼 뿐 구독, 규칙, DNS가 올바른지 단독으로 판단하는 기준은 아닙니다.

Android 클라이언트에서는 트래픽 처리 옵션이 네트워크, 라우팅, VPN 설정에 있을 수 있으며 데스크톱과 같은 이름의 ‘시스템 프록시’ 스위치가 없을 수도 있습니다. 일반적으로 Wi-Fi 설정에 로컬 HTTP 프록시를 별도로 입력할 필요는 없습니다. 이전에 Wi-Fi 프록시를 수동으로 설정했다면 기록한 뒤 정리해 추가 전달 경로가 생기지 않도록 하세요. 해당 Wi-Fi를 벗어나면 모바일 네트워크에는 수동 프록시 설정이 적용되지 않습니다.

앱별 정책, 백그라운드 실행, 배터리 제한

일부 앱을 직접 연결해야 한다면 앱별 목록과 도메인 규칙을 구분하세요. 앱별 설정은 VPN 인터페이스를 통과하거나 우회할 앱을 결정하고, 규칙은 코어에 들어온 요청을 어떤 아웃바운드로 보낼지 결정합니다. 허용 목록과 차단 목록의 의미는 클라이언트마다 다를 수 있으므로 저장 전에 ‘선택한 앱만 프록시’인지 ‘선택한 앱 우회’인지 확인한 다음 연결 화면에서 검증하세요.

구성을 변경한 뒤에도 일부 프로그램은 기존 연결을 계속 사용할 수 있습니다. 대상 앱을 완전히 닫았다가 다시 열고 새 연결 기록이 나타나는지 확인해야 앱별 설정의 적용 여부를 판단할 수 있습니다. 업무용 프로필, 듀얼 앱, 여러 사용자 공간에서는 시스템 격리로 인해 클라이언트가 볼 수 있는 앱 범위가 제한될 수 있습니다. 한 공간의 VPN이 다른 공간까지 자동으로 처리한다고 가정하지 마세요.

화면을 잠근 뒤 연결이 끊기거나 잠시 후 업데이트가 멈추는 문제는 시스템 배터리 관리나 백그라운드 제한과 관련된 경우가 많습니다. 먼저 클라이언트의 백그라운드 실행이 허용되어 있는지, 유지해야 할 포그라운드 서비스 알림이 있는지 확인한 다음 기기 설정에서 배터리 정책을 조정하세요. 제조사마다 메뉴 경로가 다르므로 다른 휴대전화의 절차를 그대로 따라 하지 마세요. 꼭 필요한 앱에만 권한을 조정한 뒤 화면 잠금과 복귀를 테스트하세요.

모바일 네트워크 전환과 DNS 문제 확인

Wi-Fi와 모바일 네트워크 사이를 전환하면 기존 연결이 끊길 수 있으므로 새로 연결해야 할 수 있습니다. 새 요청을 보내 코어가 여전히 트래픽을 받는지 확인하세요. 기록이 전혀 없다면 다른 앱이 VPN을 대체했는지 확인합니다. Android에서는 동일한 사용자 환경에서 일반적으로 활성 VPN 하나만 사용할 수 있습니다. 광고 차단, 기업용 연결, 다른 프록시 도구가 VPN 자리를 차지할 수도 있습니다.

도메인으로만 접속할 수 없다면 시스템 비공개 DNS, 클라이언트 DNS, 규칙 모드의 관계를 확인하세요. 기존 설정을 기록하고 시스템 자동 모드와 비교한 다음 클라이언트의 DNS 처리 경로를 조정할지 결정하세요. 모든 네트워크 보호 기능을 한꺼번에 끄지 마세요. Surfboard 등의 구성 문법은 mihomo YAML과 다르므로 이 문서의 YAML 예시를 호환되지 않는 설정 화면에 그대로 붙여 넣을 수 없습니다.

iOS 설치 및 설정

App Store에서 Clash Plus 설치

iPhone과 iPad에서는 iOS 클라이언트에서 Clash Plus를 확인할 수 있습니다. 설치는 Clash Plus App Store 페이지에서 진행하고 공식 웹사이트는 clashplus.io입니다. 설치 전에 App Store에 표시된 시스템 호환 요구 사항을 읽어보세요. 구체적인 기능, 메뉴 이름, 권한 안내는 현재 앱을 기준으로 확인하고 데스크톱의 서비스 설치 절차를 모바일 기기에 적용하지 마세요.

처음 실행한 뒤 구성 관리와 연결 화면을 열 수 있는지 확인한 다음 구독을 준비하세요. 앱 설치와 시스템 VPN 구성 추가는 별개의 단계입니다. 앱이 홈 화면에 표시된다고 시스템에서 트래픽 처리를 허용한 것은 아닙니다. 학교나 조직에서 관리하는 기기는 기기 관리 정책에 따라 VPN 구성이 제한될 수 있습니다. 이런 제한은 앱을 반복해서 삭제하는 대신 관리자의 정상적인 절차로 해결하세요.

기존 클라이언트에서 옮길 때는 구독 출처, 프록시 그룹 선택, 사용자 지정 규칙을 먼저 기록하세요. 앱마다 내부 데이터베이스와 백업 형식이 다를 수 있으므로 앱 전용 파일을 직접 복사하기보다 원본 구독이나 호환되는 구성을 우선 사용하세요. 구독 사용 가능 여부는 클라이언트가 지원하는 형식과 프로토콜에 달려 있으며 브라우저에서 링크가 열리는지와는 관계가 없습니다.

구성을 가져오고 VPN 권한 추가하기

앱에서 구성 추가, 구독 또는 파일 가져오기 메뉴를 사용해 전체 주소를 입력하고 콘텐츠를 불러오세요. 가져오기가 끝나면 해당 구성을 선택하고 프록시 그룹이 표시되는지 확인한 뒤 연결을 시도합니다. 공유 메뉴나 클립보드에서 가져올 때는 내용이 잘리지 않았는지 확인하세요. 특히 쿼리 매개변수가 포함된 링크를 주의해야 합니다. 구독은 개인 설정 정보이므로 문제 해결용 스크린샷에서는 주소의 식별 정보를 가리세요.

처음 연결할 때 iOS에서 VPN 구성 추가를 허용하라는 메시지가 표시되고 기기 암호나 시스템 인증을 요구할 수 있습니다. 승인한 다음 앱으로 돌아가 연결을 완료하세요. 이전에 권한 요청을 취소했다면 앱에서 다시 연결을 시작하면 됩니다. 먼저 관련 없는 VPN 유형을 직접 만들 필요는 없습니다. 시스템 설정의 VPN 목록에서 현재 구성을 확인할 수 있지만 구독 업데이트와 프록시 그룹 선택은 앱에서 진행해야 합니다.

모바일 기기는 시스템의 네트워크 확장 기능으로 트래픽을 처리하므로 보통 Wi-Fi의 HTTP 프록시를 입력할 필요가 없습니다. Wi-Fi 프록시는 해당 네트워크에만 적용되고 모바일 데이터에는 적용되지 않습니다. 이를 클라이언트 VPN과 동시에 설정하면 문제 해결이 더 어려워질 수 있습니다. 앱에 TUN과 유사한 옵션이 있더라도 iOS 안내를 따르세요. 데스크톱의 가상 네트워크 인터페이스 이름, 서비스 명령, 라우팅 매개변수를 그대로 복사하면 안 됩니다.

규칙 모드, 연결 확인, DNS

먼저 규칙 모드를 사용하고 수동 선택이 필요한 프록시 그룹에 유효한 아웃바운드가 있는지 확인하세요. 규칙에 따라 프록시를 사용해야 하는 페이지를 열고 앱의 연결 기록이나 로그를 확인합니다. 규칙에 따라 직접 연결된다고 VPN이 꺼진 것은 아닙니다. 구성에서 의도한 결과일 수도 있습니다. 페이지는 열리지만 예상과 다른 아웃바운드가 사용된다면 연결 아이콘만 보고 분할 라우팅을 판단하지 말고 규칙 순서를 먼저 확인하세요.

전역 모드는 규칙 때문에 결과가 달라지는지 임시로 확인할 때 유용하지만 장기적인 문제 해결 방법은 아닙니다. 전역 모드에서 정상화되면 원래 규칙의 도메인, 규칙 세트, 최종 대체 규칙을 비교하세요. 여전히 실패한다면 아웃바운드, 네트워크, DNS를 계속 확인합니다. 테스트가 끝나면 원래 모드로 되돌려 직접 연결해야 하는 LAN 서비스나 업무 앱의 경로가 바뀌지 않도록 하세요.

일부 브라우저, 네트워크 개인정보 보호 기능, 사용자 지정 DNS 설정은 요청 경로를 예상과 다르게 만들 수 있습니다. 먼저 기기의 현재 설정을 기록한 다음 클라이언트 로그와 하나씩 비교하세요. 사이트 하나가 열리지 않는다고 시스템 DNS, 앱 DNS, 모든 프록시 그룹을 한꺼번에 바꾸지 마세요. 복구되더라도 원인을 알 수 없게 됩니다. 인증서 경고가 표시될 때도 알 수 없는 인증서를 신뢰해 일반적인 연결 문제를 우회해서는 안 됩니다.

백그라운드, 주문형 연결, 네트워크 전환

VPN 네트워크 확장과 앱 화면은 서로 다른 수명 주기를 가집니다. 앱 화면이 백그라운드로 전환되었다고 연결이 반드시 중지되는 것은 아니며, 앱을 강제 종료하는 것으로 연결을 명확히 끊을 수도 없습니다. 사용을 중지할 때는 앱이나 시스템 VPN 스위치에서 연결이 끊겼는지 확인하세요. 주문형 연결 기능이 있다면 켜기 전에 작동 조건을 확인하고 연결을 끊은 뒤 규칙에 따라 다시 연결되는지 살펴보세요. 스위치가 작동하지 않는다고 오해하지 않도록 주의해야 합니다.

Wi-Fi, 셀룰러 네트워크, 핫스팟 사이를 전환한 뒤에는 기존 연결을 다시 설정해야 할 수 있습니다. 먼저 현재 네트워크에서 직접 연결할 수 있는지 확인한 다음 VPN에 다시 연결하고 새 요청을 보내세요. 특정 Wi-Fi에서만 실패한다면 인증 포털, DNS, 아웃바운드 제한을 비교하세요. 프록시를 테스트하기 전에 네트워크 로그인을 완료해야 정상적인 네트워크 접속이 없는 문제를 클라이언트 오류로 오해하지 않습니다.

구독을 백그라운드에서 업데이트할 수 있는지, 앱을 전면에 두어야 하는지는 앱 구현과 시스템 스케줄링에 따라 달라집니다. 중요한 업데이트 후에는 앱을 직접 열어 구성이 로드되었는지 확인하세요. 예약 설정만으로 업데이트가 완료되었다고 판단하면 안 됩니다. 다른 기기에서는 작동하는 아웃바운드가 이 기기에서만 실패한다면 시스템 네트워크 설정을 전부 삭제하기보다 프로토콜 지원, 구성 형식, 현재 네트워크를 비교하세요.

Linux 설치 및 설정

데스크톱 클라이언트와 코어를 각각 선택하기

Linux 클라이언트에서 데스크톱 환경에는 Clash Verge Rev 또는 FlClash를 선택할 수 있습니다. 서버, 라우터 또는 서비스를 직접 관리해야 하는 사용자는 Mihomo 코어를 확인하세요. 그래픽 클라이언트는 구성 관리와 상태 표시를 담당하고, 독립 코어는 구성 실행을 담당합니다. 설치와 권한 관리 방법이 다르므로 처음부터 두 가지를 동시에 배포해 같은 포트에서 리스닝하게 하지 않는 것이 좋습니다.

먼저 uname -m으로 아키텍처를 확인한 다음 배포판에서 사용하는 패키지 형식과 대조하세요. 일반적으로 x86_64는 AMD64, aarch64는 ARM64에 해당하지만 실제 사용 가능 여부는 빌드 요구 사항에 따라 달라집니다. 해당 패키지 관리 환경이 없는 시스템에서 다른 배포판의 설치 명령을 그대로 사용하지 말고, 모든 Linux 설치 파일이 데스크톱 환경이 없는 서버에 적합하다고 가정하지 마세요.

배포판의 패키지 관리 도구로 설치하면 의존성 확인과 제거 기록을 관리할 수 있습니다. 데스크톱 구성 요소, 런타임 라이브러리, 트레이 지원이 없다는 메시지가 표시되면 먼저 구체적인 오류를 확인한 다음 현재 세션 환경을 점검하세요. Wayland, X11, 데스크톱 환경마다 트레이 구현이 다릅니다. 창은 실행되지만 트레이 아이콘이 보이지 않더라도 프록시 코어의 실행 실패를 뜻하지 않을 수 있으므로 화면과 코어 로그를 따로 확인하세요.

그래픽 인터페이스에서 가져오기와 데스크톱 프록시 설정

클라이언트의 구성 화면에서 구독을 가져와 선택하고 코어가 정상적으로 로드되었는지 확인한 다음 시스템 프록시를 켜세요. Linux에는 모든 데스크톱과 프로그램에 공통으로 적용되는 단일 프록시 경로가 없습니다. GNOME, KDE, 명령줄 앱은 데스크톱 설정, 환경 변수, 자체 프록시 설정을 각각 참조할 수 있습니다. 따라서 클라이언트에 시스템 프록시가 켜져 있다고 표시되어도 대상 앱에서 직접 확인해야 합니다.

브라우저에 별도의 프록시 설정이 있다면 시스템 설정을 따르는지, 주소를 수동 지정하는지 확인하세요. 터미널 프로그램은 먼저 명시적 프록시 명령으로 테스트해 로컬 리스너가 작동하는지 확인한 뒤 환경 변수 설정을 결정할 수 있습니다. 같은 변수를 모든 시작 스크립트에 넣지 마세요. 데스크톱 세션, 대화형 터미널, 시스템 서비스는 환경 변수를 서로 다르게 상속하므로 잘못된 위치에 설정하면 일부 프로그램이 계속 이전 프록시를 사용할 수 있습니다.

아래 예시는 혼합 포트가 7890으로 설정된 경우에만 사용할 수 있으며 현재 셸과 이후에 실행되는 하위 프로세스에만 영향을 줍니다. NO_PROXY는 이를 지원하는 프로그램에 로컬 주소를 우회하도록 알려주는 변수일 뿐, 코어의 전체 직접 연결 규칙을 의미하지 않습니다. 변수 이름의 대소문자와 와일드카드 지원은 도구마다 다르므로 실제 사용 전 해당 도구의 문서를 확인하세요.

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

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

unset HTTP_PROXY HTTPS_PROXY NO_PROXY

독립 코어 구성 확인과 TUN 권한

Mihomo 코어를 사용하려면 먼저 완전한 구성과 별도의 데이터 디렉터리를 준비한 다음 일반 사용자 권한으로 구성을 확인하세요. 아래 명령은 코어가 mihomo로 설치되어 있고 구성이 표시된 경로에 저장되어 있다고 가정합니다. 구독을 생성하거나 프록시 그룹을 자동으로 채우지는 않습니다. 검사에 통과했다는 것은 구성 구문을 해석할 수 있다는 의미일 뿐, 원격 규칙 리소스와 실제 아웃바운드는 실행 후 별도로 확인해야 합니다.

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

TUN은 가상 네트워크 인터페이스에 접근하고 라우팅을 변경해야 하므로 일반적으로 네트워크 관리 권한이나 제한된 권한의 서비스가 필요합니다. 데스크톱 클라이언트에 서비스 설치 기능이 있다면 안내에 따라 설정하세요. 서비스를 직접 배포할 경우 실행 사용자, 파일 권한, 권한 범위를 명확히 정해야 합니다. 편의를 위해 전체 구성 디렉터리를 모든 사용자가 쓸 수 있게 설정하거나 알 수 없는 스크립트를 최고 권한으로 계속 실행하지 마세요.

컨테이너, 가상 머신, 호스트는 서로 다른 네트워크 환경입니다. 컨테이너 내부의 루프백 주소는 컨테이너 자체를 가리키므로 호스트의 로컬 프록시가 자동으로 컨테이너에 제공되지는 않습니다. 리스너를 공유해야 한다면 먼저 주소 연결 가능성, 리스닝 범위, 방화벽 규칙을 설계한 뒤 LAN 연결 허용을 고려하세요. 리스닝을 모든 인터페이스로 바로 확장하면 로컬 전용 서비스가 다른 기기에 노출될 수 있습니다.

서비스 상태, 로그, 종료 후 복구

백그라운드 서비스가 시작되지 않으면 먼저 서비스 관리자 보고서와 코어 로그를 확인해 구성 경로 오류, 디렉터리 읽기 권한, 포트 충돌, 권한 부족 중 무엇인지 구분하세요. 그래픽 클라이언트가 이미 코어를 실행 중인데 다른 프로세스를 수동으로 시작하면 리스닝 충돌이 발생할 수 있습니다. 배포 방식에 따라 구성을 다시 불러오거나 서비스를 재시작하세요. 파일을 편집했다고 실행 중인 코어에 변경 사항이 즉시 적용되는 것은 아닙니다.

TUN을 켠 뒤 LAN, 컨테이너, 가상 머신 네트워크에 문제가 생기면 새 라우팅이 기존 사설 네트워크 대역을 덮어쓰는지, DNS 요청이 최종적으로 어떤 해석 경로를 거치는지 확인하세요. 먼저 TUN을 끄고 일반 프록시 사용과 비교하세요. 라우팅이나 방화벽 규칙을 모두 지우면 원격 관리 연결이 끊길 수 있으므로 주의해야 합니다. 서버에서 작업하기 전에 별도의 복구 경로를 확보하세요.

사용을 중지할 때는 데스크톱 프록시 설정, 셸 환경 변수, 백그라운드 서비스를 각각 처리해야 합니다. 이 설정들은 자동으로 동기화되지 않습니다. 특정 터미널에서만 문제가 계속되면 새 터미널을 열고 상속된 환경 변수를 확인하세요. 모든 데스크톱 앱에서 실패한다면 데스크톱 네트워크 설정을 확인합니다. 코어 필드 호환성은 mihomo와 원본 Clash의 구성 차이에서 더 확인할 수 있습니다. 이전 필드가 작동하지 않는 문제를 배포판 탓으로만 돌리지 마세요.

구성 관련 자주 묻는 질문과 문제 해결 순서

구성을 가져왔는데 왜 연결되지 않나요?

구성 로드, 리스닝 경로, 규칙 적용, 원격 연결 순서로 확인하세요. 먼저 현재 활성화된 구성이 방금 가져온 항목인지 확인하고 로그에서 구문 분석 실패나 리소스 다운로드 실패가 보고되는지 살펴보세요. 다음으로 시스템 프록시, VPN, TUN이 대상 앱의 트래픽을 코어로 전달하는지 확인합니다. 연결 화면에 기록이 전혀 없다면 경로부터 해결하세요. 기록이 있다면 적용된 규칙과 최종 아웃바운드를 확인해 엉뚱한 설정을 반복해서 바꾸지 않도록 합니다.

모든 아웃바운드가 실패하면 기본 네트워크와 구독 상태부터 확인하세요. 하나만 실패한다면 해당 아웃바운드나 프로토콜 지원을 먼저 점검합니다. 구성 업데이트 실패와 프록시 연결 실패는 서로 다른 경로에서 발생할 수 있습니다. 구독을 업데이트하려면 원격 콘텐츠를 가져와야 하지만 기존 구성은 여전히 연결될 수 있습니다. 업데이트 오류가 표시되더라도 유일하게 작동하는 구성을 바로 삭제하지 마세요. 먼저 복사본과 오류 정보를 저장하세요.

로그는 문제 발생 단계를 파악하는 데 사용하며 지나치게 상세한 로그 수준을 계속 켜둘 필요는 없습니다. 오류를 보고할 때는 필요한 정보만 남기고 구독 주소, 아웃바운드 계정, 개인 도메인, 기기 정보를 가리세요. 같은 증상이라도 테스트 시각, 사용 네트워크, 모드, TUN 사용 여부를 기록하면 ‘연결할 수 없음’ 한마디만 남기는 것보다 도움이 됩니다. 제출 전에 로그가 이전 실행의 오류가 아니라 이번에 보낸 새 요청에 해당하는지 확인하세요.

규칙, 혼합 포트, YAML은 어떻게 연결되나요?

혼합 포트는 일반적으로 하나의 로컬 리스너가 HTTP 프록시와 SOCKS 요청을 모두 받도록 합니다. 원격 서버 포트를 뜻하는 것은 아닙니다. 규칙은 위에서 아래로 적용되므로 구체적인 예외를 앞쪽에 두고 마지막에 최종 대체 규칙을 배치하세요. 아래는 로컬 리스너를 확인하기 위한 최소 직접 연결 구성입니다. 원격 프록시는 포함되지 않습니다. 단독 실행은 가능하지만 요청을 원격 아웃바운드로 전달하지 않으며 기존 구독을 대체하는 용도로 사용해서는 안 됩니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - DOMAIN-SUFFIX,localhost,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

원격 프록시를 사용하려면 전체 구성에 실제 아웃바운드나 프록시 그룹을 정의하고 규칙에서 정확한 이름을 참조해야 합니다. 예시의 사설 주소 규칙은 나열된 네트워크 대역만 처리하며 모든 LAN 환경에 적용되는 일반적인 해답은 아닙니다. YAML은 공백 들여쓰기를 사용하며 목록의 하이픈과 필드 계층이 중요하므로 탭을 섞지 마세요. 변경한 뒤 먼저 구성을 확인하고 다시 로드하세요. 검사가 실패하면 마지막으로 작동했던 복사본으로 되돌리세요.

시스템 프록시, TUN, DNS, 속도 테스트는 어떻게 구분하나요?

시스템 프록시는 시스템 설정을 따르는 앱에 적합합니다. TUN은 더 많은 트래픽을 처리할 수 있지만 라우팅, 권한, DNS 설정이 필요합니다. 모든 플랫폼에서 둘을 함께 켜야 하는 것은 아닙니다. Fake-IP는 DNS 매핑과 연결 복원 방식이지 프록시 모드나 속도 향상 옵션이 아닙니다. LAN 도메인, 하드코딩된 IP, 특정 앱의 호환성 문제가 발생하면 용어만 보고 모두 끄지 말고 DNS 응답과 연결 기록을 바탕으로 조정하세요.

브라우저의 암호화 DNS, 운영체제 리졸버, 클라이언트 DNS가 각각 요청 처리에 관여할 수 있습니다. 시스템 DNS만 바꿔도 브라우저의 DNS 경로는 달라지지 않을 수 있습니다. 도메인 규칙을 사용하더라도 클라이언트가 항상 도메인을 확인할 수 있는 것은 아닙니다. 요청에 도메인과 IP 중 무엇이 전달되는지 확인한 뒤 DNS 해석 및 스니핑 방식을 살펴보세요. 근거 없이 DNS 하이재킹, 스니핑, 여러 대체 리졸버를 무작정 함께 설정하지 마세요.

노드 지연 시간 테스트는 특정 시점에 특정 요청을 보낸 결과일 뿐 다운로드 대역폭이나 모든 웹사이트의 체감 속도를 뜻하지 않습니다. 테스트 시간 초과는 측정 주소, 인증서, DNS, 연결 재사용 문제로도 발생할 수 있습니다. 자주 사용하는 사이트, 안정성, 실제 업무 요청을 함께 고려해 아웃바운드를 선택하세요. 자세한 원리는 노드 지연 시간과 실제 인터넷 속도의 차이를 참조하세요. 아웃바운드를 변경한 뒤 새 연결을 설정해야 하며 기존 연결이 즉시 새 경로로 바뀌지 않을 수 있습니다.

구독 업데이트, LAN 공유, 복구 확인

자동 업데이트는 구독 콘텐츠를 다시 가져오므로 생성된 파일에 직접 추가한 규칙이 초기화될 수 있습니다. 장기간 유지할 변경 사항은 클라이언트가 지원하는 지속 확장 기능에 넣고 병합 순서를 확인하세요. 구독 변환을 사용하면 변환 서비스가 구성 내용을 처리하게 되므로 사용 전에 처리 범위를 확인하세요. 호환되는 구독을 바로 사용할 수 있다면 변환 단계를 추가할 필요는 없습니다. 무료 노드도 출처, 유효성, 이용 조건을 확인해야 하며 클라이언트가 제공처를 대신 보증할 수는 없습니다.

가장 간단한 설정 절차를 다시 진행하려면 빠른 시작 가이드로 돌아가세요. 클라이언트를 바꾸려면 다운로드 페이지에서 플랫폼에 맞는 항목을 선택하세요. 검증된 구성과 해당 설정 기록을 보관하면 여러 매개변수를 동시에 시도하는 것보다 복구 가능한 네트워크 환경을 유지하기 쉽습니다.