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

공통 준비: 설정 출처와 트래픽 처리 방식

클라이언트, 코어, 구독의 차이

클라이언트는 설정을 저장하고 코어를 실행하며 프록시를 설정하고 연결 상태를 보여 주는 인터페이스입니다. 코어는 프로토콜을 해석하고 규칙에 따라 트래픽을 전달합니다. 구독은 노드, 정책 그룹, 규칙, DNS 매개변수 등을 포함할 수 있는 설정 출처입니다. 클라이언트를 설치했다고 바로 사용할 수 있는 출구가 생기는 것은 아닙니다. 시작하기 전에 서비스 제공업체가 발급한 유효한 구독 주소나 선택한 코어와 호환되는 YAML 파일을 준비하세요.

이 가이드에서는 클라이언트 선택의 출발점으로 Clash Plus를 우선 안내합니다. 다른 클라이언트는 버튼 이름이 다를 수 있지만, 대체로 설정·프록시·연결·설정 메뉴를 중심으로 구성됩니다. 한 클라이언트에서 가져올 수 있다고 해서 다른 클라이언트도 모든 필드를 지원한다고 단정하지 마세요. 특히 프로토콜 확장, 규칙 제공자, 스크립트 관련 설정은 사용하려는 코어의 지원 범위를 확인해야 합니다. 파싱 오류가 발생하면 오류에 표시된 필드 이름과 줄 번호부터 살펴보세요.

구독 및 시스템 정보 준비

구독 주소에는 접근 자격 증명이 포함될 수 있으므로 계정 비밀번호처럼 안전하게 관리해야 합니다. 전체 링크를 공개 포럼이나 스크린샷, 출처를 알 수 없는 온라인 변환 사이트에 올리지 마세요. 도움을 요청할 때는 오류 유형, 클라이언트 이름, 운영체제와 네트워크 환경만 남기세요. 링크가 유출됐다면 로컬 기록만 삭제하지 말고 제공업체에 재설정을 요청해야 합니다. 기록을 삭제해도 이미 다른 사람이 얻은 접근 권한은 취소되지 않습니다.

설치 전에 운영체제 버전, 프로세서 아키텍처, 남은 저장 공간을 확인하세요. 데스크톱은 x64와 ARM64를, Mac은 Intel과 Apple Silicon을 구분해야 합니다. Android 기기는 ARM64 설치 파일을 지원하는지 확인하세요. 기존 설정과 사용자 지정 규칙을 먼저 백업한 뒤 클라이언트를 전환하세요. 테스트 중에는 다른 프록시나 VPN 프로그램을 종료해 시스템 프록시, 가상 네트워크 인터페이스, DNS 설정을 두 프로그램이 동시에 제어하지 않도록 합니다.

트래픽 처리 방식 선택

시스템 프록시와 TUN은 트래픽 처리 방식이고, 규칙·전역·직결은 라우팅 모드이므로 서로 다른 계층입니다. TUN을 켜도 규칙 모드를 사용할 수 있으며, 규칙에 따라 직결되는 트래픽도 먼저 코어를 거친 뒤 직접 전송될 수 있습니다. 문제를 해결할 때는 ‘앱 트래픽이 클라이언트에 들어오는지’와 ‘들어온 트래픽이 어떤 출구로 나가는지’를 각각 확인하세요. 토글 이름만 보고 연결이 프록시를 거친다고 판단하면 안 됩니다.

최소한의 작동 설정 만들기

첫 연결에서는 구독 가져오기, 설정 선택, 사용할 노드 선택, 서비스 시작의 네 단계만 진행하세요. 데스크톱은 먼저 시스템 프록시를 사용하고, 모바일은 VPN 권한을 확인합니다. 구독에 포함된 DNS와 규칙은 그대로 두고 오버라이드, 앱 제외, LAN 공유를 한꺼번에 추가하지 마세요. 연결에 성공하면 사용한 네트워크, 노드, 트래픽 처리 방식을 기록하세요. 이후 한 번에 설정 하나만 바꿔야 어느 단계가 영향을 미쳤는지 알 수 있습니다.

검증할 때는 평소 직결되는 사이트 하나와 규칙상 프록시를 사용해야 하는 사이트 하나에 접속한 뒤 연결 기록에서 적용된 정책을 확인하세요. 웹페이지가 열렸다고 해서 모든 앱, 모든 도메인, UDP 트래픽까지 정상이라는 뜻은 아닙니다. 기록에는 필요한 정보만 남기세요. 로그에 도메인, 구독 주소, 로컬 경로가 나타날 수 있으므로 공유하기 전에 민감한 부분을 하나씩 가려야 합니다.

Windows: 설치 및 시스템 프록시

설치 파일 선택 및 첫 실행

Windows 다운로드에서 Clash Plus를 먼저 확인하세요. 사용 방식에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu를 선택할 수도 있습니다. Clash for Windows는 지원이 종료됐으므로 보관된 다운로드 페이지는 기존 설정을 옮길 때 참고하는 정도로 활용하고, 새 기기에 설치할 기본 클라이언트로는 권장하지 않습니다. 기존 클라이언트 폴더를 다른 프로그램 위에 덮어쓰지 마세요. 설정 파일과 인터페이스 데이터베이스가 호환되지 않을 수 있습니다.

시스템 설정의 ‘시스템 → 시스템 정보’에서 시스템 종류를 확인하고 다운로드 페이지에 제공된 해당 설치 파일을 선택하세요. 설치 전에 실행 중인 프록시를 종료하고 설치 프로그램을 실행한 뒤 안내에 따라 설치 위치를 정합니다. 처음 실행할 때 시스템에서 네트워크 접근을 허용하라는 메시지가 나오면 프로그램 출처와 파일 위치를 확인한 다음 필요한 권한만 부여하세요. 창을 닫아도 알림 영역에서 계속 실행될 수 있으므로 포트 점유 문제를 확인할 때는 트레이 메뉴에서 완전히 종료해야 합니다.

구독 가져오기 및 설정 선택

설정 또는 구독 페이지에서 원격 설정 추가를 선택하고 서비스 제공업체의 구독 링크를 붙여 넣으세요. 다운로드와 파싱이 완료되어 설정 이름이 표시되면 활성화하거나 선택합니다. 일부 인터페이스에서 ‘추가됨’은 목록에 저장됐다는 뜻일 뿐, 현재 코어에 로드됐다는 의미는 아닙니다. 프록시 페이지로 돌아가 정책 그룹이 표시되는지 확인하세요. 목록이 비어 있다면 현재 설정을 올바르게 선택했는지, 구독 응답이 Clash 형식인지 먼저 확인합니다.

정책 그룹에서 실제 노드 하나를 선택해 첫 연결을 테스트하세요. 자동 선택 그룹은 연결성 검사 결과를 사용할 수 있으므로, 구독을 막 가져온 직후 결과가 나오지 않는다고 모든 노드가 작동하지 않는다고 판단할 필요는 없습니다. 구독을 업데이트하기 전에 사용자 지정 규칙을 저장하세요. 원격 설정 파일은 다음 업데이트 때 덮어써질 수 있습니다. 장기간 유지할 로컬 설정은 캐시 파일을 직접 수정하지 말고 클라이언트의 오버라이드 또는 확장 기능을 이용하세요.

시스템 프록시를 먼저 켜고 수신 포트를 확인하세요

코어를 시작한 뒤 ‘시스템 프록시’를 켭니다. 일반적으로 Windows 프록시 주소가 루프백 주소와 클라이언트 포트로 설정됩니다. 브라우저에서 새 연결을 만든 뒤 테스트하세요. 기존 탭은 이전 연결을 계속 재사용할 수 있습니다. 브라우저 확장 프로그램에 별도의 프록시가 설정되어 있다면 실제 요청이 다른 곳으로 우회하지 않도록 확장 프로그램의 프록시 제어를 먼저 끄세요. 앱에 직접 입력한 프록시는 시스템 토글을 자동으로 따르지 않는 경우가 많습니다.

아래 혼합 포트 예시는 HTTP와 SOCKS 프록시 연결을 모두 받을 수 있습니다. 이는 로컬 수신 방식만 설명하며 노드는 포함하지 않으므로 단독으로 완전한 구독으로 사용할 수 없습니다. 포트는 클라이언트의 현재 실행 설정을 기준으로 확인하세요. 인터페이스에 다른 값이 표시된다면 예시에 맞추려고 구독을 수정하지 마세요. 루프백 수신은 이 기기에서만 연결할 수 있어 기본 연결을 검증하기에 적합합니다.

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

포트를 확인한 뒤 PowerShell에서 아래 명령으로 HTTP 프록시 주소를 따로 테스트할 수 있습니다. 명령에 프록시를 명시하므로 시스템 프록시 토글에 의존하지 않습니다. 이 테스트는 성공하지만 브라우저에서 실패한다면 브라우저나 시스템 설정을 먼저 확인하세요. 로컬 포트에 연결할 수 없다는 메시지가 나오면 노드를 바꾸기보다 코어가 실행 중인지, 수신 주소가 올바른지부터 확인합니다. 요청 성공 여부는 연결 기록과 함께 확인해 실제 출구도 점검해야 합니다.

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

TUN, 서비스 권한 및 종료 후 복구

시스템 프록시를 따르지 않는 앱까지 처리해야 할 때 TUN을 고려하세요. 클라이언트에 따라 서비스 구성요소를 설치하거나 초기화 시 관리자 권한이 필요할 수 있으므로 해당 클라이언트의 안내를 따르세요. 활성화한 뒤 가상 네트워크 인터페이스와 연결 기록을 확인합니다. 시스템 전체에서 도메인이 갑자기 해석되지 않으면 TUN을 끄고 기준 설정으로 복구한 뒤 DNS, 라우팅 충돌, 보안 소프트웨어 차단을 점검하세요. 여러 네트워크 설정을 동시에 변경하지 마세요.

일상적인 사용을 위해 Windows 방화벽 전체를 끌 필요는 없습니다. 보안 소프트웨어가 차단한다면 출처가 확인된 프로그램과 필요한 네트워크 범위에만 규칙을 추가하세요. 절전 모드에서 복귀하거나 Wi-Fi를 바꾸거나 회사 VPN에 연결한 뒤 기존 경로가 작동하지 않을 수 있습니다. 이때는 코어를 중지했다가 다시 시작해 보세요. 자동 시작을 설정하기 전에 수동 실행이 안정적인지 확인한 뒤 시스템 시작 시 실행과 프록시 자동 활성화를 설정하세요. 부팅 직후부터 문제가 발생하는 상황을 피할 수 있습니다.

클라이언트를 종료하기 전에 시스템 프록시를 끄세요. 프로그램이 비정상 종료됐다면 Windows 설정의 ‘네트워크 및 인터넷 → 프록시’에서 수동 프록시가 남아 있는지 확인합니다. 프로그램은 멈췄는데 시스템이 로컬 포트를 계속 가리키면 프록시를 따르는 앱이 인터넷에 연결되지 않습니다. LAN 공유에는 수신 주소와 인바운드 규칙도 필요합니다. 자세한 내용은 혼합 포트 및 LAN 공유 안내를 참고하세요. LAN 허용 토글 하나만 켜고 설정을 끝내서는 안 됩니다.

macOS: 칩 아키텍처와 네트워크 권한

칩에 맞는 클라이언트 선택

Apple 메뉴에서 ‘이 Mac에 관하여’를 열어 칩 또는 Intel 프로세서로 표시되는지 확인한 뒤 macOS 다운로드에서 맞는 설치 파일을 선택하세요. Clash Plus를 우선 고려하고 Clash Verge Rev나 FlClash를 선택할 수도 있습니다. ClashX Meta는 지원이 종료됐습니다. 기존 설정을 옮길 때 구독과 규칙을 먼저 백업하고, 예전 프로그램이 실행된다는 이유만으로 새 설정 형식도 계속 처리할 수 있다고 판단하지 마세요.

디스크 이미지를 다운로드해 연 다음 앱을 ‘응용 프로그램’ 폴더로 드래그하고 해당 폴더에서 실행하세요. 디스크 이미지 안의 앱을 계속 직접 실행하면 업데이트, 권한, 로그인 시 실행 설정이 서로 다른 위치를 가리킬 수 있습니다. 시스템에서 실행을 차단하면 먼저 다운로드 출처를 확인한 뒤 ‘시스템 설정 → 개인정보 보호 및 보안’에서 구체적인 안내를 확인하세요. 출처가 불분명한 명령으로 시스템 보안 기능을 일괄 해제하지 마세요.

원격 설정을 가져와 로드 여부 확인

설정 페이지에서 원격 구독을 추가하고 이름과 링크를 입력하세요. 저장한 뒤 파싱이 끝나면 현재 설정으로 지정합니다. 파일에서 가져오려면 파일 선택기로 YAML을 여세요. 클라이언트가 파일을 복사하는지 기존 경로를 계속 참조하는지 확인해야 합니다. 임시 다운로드 폴더에 파일을 둔 채 나중에 폴더를 정리하면 다시 불러오기에 실패할 수 있습니다. 계속 참조할 파일은 안정적인 위치에 두세요.

정책 그룹이 표시되는지 확인하고 테스트 노드를 직접 선택하세요. 설정 업데이트 성공은 구독 요청과 파싱이 완료됐다는 뜻일 뿐, 노드 연결까지 성공했다는 의미는 아닙니다. 먼저 노드가 사용 가능한지 확인한 다음 트래픽 처리를 활성화하세요. 브라우저에서는 구독 주소에 접근되지만 클라이언트에서는 실패한다면 두 요청이 서로 다른 프록시 경로를 사용하는지, 시스템 시간이 정확한지 확인하세요. 공개 페이지에 전체 구독 주소를 노출하지 마세요.

현재 네트워크 서비스의 시스템 프록시 이해

클라이언트에서 시스템 프록시를 활성화하면 macOS는 보통 활성 네트워크 서비스의 HTTP, HTTPS 또는 SOCKS 프록시 설정을 변경합니다. Wi-Fi와 유선 네트워크가 서로 다른 서비스로 등록될 수 있으므로 네트워크를 바꾼 뒤 다시 확인하세요. 일부 터미널 도구는 환경 변수를 읽고 다른 앱은 자체 프록시 설정을 사용합니다. 브라우저는 정상인데 터미널에서 실패해도 이상한 일이 아닙니다. 먼저 해당 앱이 어떤 연결 방식을 사용하는지 확인하세요.

아래 읽기 전용 명령으로 현재 시스템 프록시 상태를 확인할 수 있습니다. 활성화 여부와 주소, 포트가 클라이언트 설정과 일치하는지 살펴보세요. 이 명령은 시스템 설정을 보여 줄 뿐 모든 앱이 그 설정을 따른다는 보장은 없습니다. 이미 종료된 이전 클라이언트의 주소가 남아 있다면 현재 클라이언트에서 시스템 프록시를 끈 뒤 다시 켜세요. 그래도 복구되지 않으면 해당 네트워크 서비스의 프록시 설정을 하나씩 확인합니다.

scutil --proxy

터미널에서 요청을 한 번만 테스트할 때는 셸 전체 설정을 수정하는 것보다 명령에 프록시를 임시 지정하는 편이 문제 해결에 편리합니다. 아래 명령은 해당 호출에만 적용되므로 사용 전에 포트가 실제 실행 값과 일치하는지 확인하세요. 셸 시작 파일에 프록시 환경 변수를 설정했다면 남아 있는 값도 살펴봐야 합니다. 그래픽 클라이언트를 종료해도 이 변수는 자동으로 삭제되지 않아 중지된 로컬 포트에 계속 연결을 시도할 수 있습니다.

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

TUN 권한 및 네트워크 전환 문제 해결

TUN을 사용할 때 클라이언트가 보조 서비스 설치, 네트워크 인터페이스 생성 권한, 시스템 확장 승인을 요청할 수 있습니다. 현재 프로그램의 안내에 따라 순서대로 진행하세요. 다른 클라이언트의 서비스 구성요소를 대신 설치하는 일을 반복하지 마세요. 권한을 승인했는데도 트래픽이 없다면 로그에서 권한, 인터페이스, 라우팅 생성 실패가 있는지 먼저 확인합니다. 이런 오류는 노드 연결 전에 발생하므로 구독을 바꿔도 해결되지 않는 경우가 많습니다.

기업용 VPN, 다른 네트워크 필터링 도구, 가상 머신 네트워크를 동시에 실행하면 라우팅 우선순위나 DNS 충돌이 발생할 수 있습니다. 먼저 트래픽 처리 도구 하나만 남겨 검증한 뒤 다른 구성요소를 하나씩 다시 활성화해 문제가 언제 생기는지 확인하세요. 회사 관리 기기에서는 기존 네트워크 정책을 따라야 합니다. 관리되는 설정을 삭제해 TUN을 강제로 켜서는 안 됩니다. 프록시 설정이 시스템의 모든 보안 및 접근 제한을 자동으로 덮어쓰는 것도 아닙니다.

Mac이 절전 모드에서 복귀하거나 유선에서 무선으로 전환된 뒤 연결이 끊기면 클라이언트를 중지했다가 다시 시작한 다음 현재 네트워크 서비스의 프록시를 확인하세요. 제거하기 전에 시스템 프록시와 TUN을 끄고 클라이언트 안내에 따라 보조 서비스를 삭제합니다. 앱을 휴지통으로 옮기는 것만으로는 로컬 포트를 가리키는 설정이 남을 수 있습니다. 제거 후 브라우저에서 인터넷에 연결되지 않으면 전체 네트워크 설정을 초기화하기 전에 시스템 프록시가 남아 있는지 먼저 확인하세요.

Android: VPN 권한 및 앱별 트래픽 분리

설치 파일, 업데이트 및 설정 이전

Android 다운로드에서 Clash Plus를 먼저 확인하세요. Clash Meta for Android, FlClash, Surfboard를 선택할 수도 있습니다. Surfboard는 Clash YAML과 설정 체계가 완전히 같지 않으므로 같은 YAML 파일을 모든 클라이언트에서 그대로 사용할 수는 없습니다. 서비스 제공업체가 Clash 구독만 제공한다면 해당 형식을 명시적으로 지원하는 클라이언트를 선택하세요. 설치한 뒤 설정이 호환되지 않는다는 사실을 알게 되는 상황을 피할 수 있습니다.

APK를 설치할 때 현재 브라우저나 파일 관리자에 앱 설치 권한을 허용하라는 메시지가 표시될 수 있습니다. 파일 출처를 확인한 뒤 실제 설치에 사용할 앱에만 권한을 부여하세요. 이미 설치된 앱과 충돌한다는 메시지가 나오면 패키지 이름, 서명, 출처를 확인하고 설정을 백업한 뒤 이전 여부를 결정하세요. 정상 작동 중인 앱을 바로 삭제하지 마세요. 서명이 다른 설치 파일은 대개 기존 앱을 덮어쓸 수 없으며 데이터를 지워도 서명 불일치는 해결되지 않습니다.

URL로 가져오기 및 VPN 서비스 시작

Clash for Android 계열 인터페이스에서는 ‘설정 → 새 설정 → URL에서 가져오기’를 열고 알아보기 쉬운 이름과 구독 링크를 입력하세요. 저장한 뒤 업데이트가 완료되면 설정 목록으로 돌아가 해당 항목을 선택합니다. 파일에서 가져오려면 시스템 파일 선택기에서 YAML을 선택하세요. 파일을 휴대폰에 다운로드하는 것만으로 클라이언트에 자동 로드되지는 않으므로 가져오기와 선택을 모두 완료해야 합니다.

홈으로 돌아가 시작 버튼을 누릅니다. 처음 실행하면 Android에서 VPN 연결 요청이 표시됩니다. 앱 이름을 확인한 뒤 승인하세요. 시스템 상태 표시줄에 VPN 아이콘이 나타나면 VPN 인터페이스가 만들어진 것입니다. 원격 노드가 사용 가능하다는 뜻은 아닙니다. 이어서 프록시 페이지에서 규칙 모드인지 확인하고 테스트 노드를 선택한 다음 브라우저를 열어 연결 기록을 확인하세요. 연결 진입부터 출구까지 전체 경로를 검증할 수 있습니다.

Android에서는 일반적으로 한 번에 일반 앱 하나만 현재 사용자의 VPN 서비스를 차지할 수 있습니다. 시작할 때 다른 VPN 연결이 끊겨도 시스템 리소스 제한 때문일 수 있으며, 반드시 클라이언트 오류인 것은 아닙니다. 로컬 VPN을 사용하는 필터링 도구와 충돌할 수도 있습니다. 업무용 프로필과 개인 프로필은 별도의 네트워크 정책을 적용받을 수 있습니다. 한 프로필의 앱이 다른 프로필에서 실행되는 클라이언트의 제어를 받지 않을 수 있으므로 기기 관리 범위를 확인해야 합니다.

접근 제어로 프록시를 사용할 앱 결정

설정의 접근 제어 또는 앱별 분리 메뉴를 열어 ‘선택한 앱만 프록시 사용’과 ‘선택한 앱 우회’ 중 어떤 방식인지 확인하세요. 같은 앱을 선택하더라도 두 방식의 결과는 정반대입니다. 처음 문제를 해결할 때는 모든 앱이 VPN을 통과하는 기준 상태로 잠시 되돌린 뒤 하나씩 제외하는 편이 좋습니다. 브라우저는 정상인데 특정 앱의 연결 기록이 전혀 없다면 노드 문제로 단정하지 말고 앱 목록과 프로필 공간을 먼저 확인하세요.

‘사설 네트워크 우회’는 보통 LAN 주소의 라우팅에 영향을 줍니다. 라우터, 프린터, 로컬 기기에 접근하는 데 도움이 될 수 있지만 설정 규칙도 함께 확인해야 합니다. 이 기능을 켠다고 다른 기기가 휴대폰 프록시를 사용할 수 있는 것은 아닙니다. ‘앱 우회 허용’은 시스템 VPN 계층의 다른 기능이며 구체적인 동작은 클라이언트 구현에 따라 달라집니다. 설정을 바꾸기 전에 각 토글의 설명을 읽고 서로 다른 계층의 우회 설정을 혼동하지 마세요.

DNS 하이재킹 및 백그라운드 실행

DNS 하이재킹은 VPN으로 들어오는 DNS 요청을 코어에서 처리하도록 하는 기능입니다. 앱이 자체적으로 암호화된 DNS 연결을 만드는 경우까지 처리한다고 보장하지는 않습니다. 브라우저에서 보안 DNS를 사용하거나 시스템에 비공개 DNS가 설정되어 있으면 예상과 다른 경로로 이름이 해석될 수 있습니다. 문제를 해결할 때 기존 설정을 기록한 뒤 시스템 기본값으로 잠시 되돌려 비교하세요. 노드, DNS 모드, 규칙을 동시에 바꾸면 어떤 변경이 효과가 있었는지 알 수 없습니다.

화면을 끈 뒤 연결이 끊긴다면 먼저 배터리 설정에서 클라이언트의 백그라운드 활동이 제한되는지 확인하고, 제조사에서 자동 시작이나 백그라운드 유지 옵션을 제공하는지 살펴보세요. 설정 이름은 시스템마다 다르므로 해당 클라이언트에만 필요한 항목을 조정하고 기기 전체의 절전 기능을 끌 필요는 없습니다. 화면을 끈 뒤에만 문제가 발생하는지, 클라이언트를 다시 열면 복구되는지, 로그에 프로세스 재시작이 기록되는지 확인하면 백그라운드 종료와 네트워크 전환에 따른 연결 중단을 구분할 수 있습니다.

상시 VPN과 ‘VPN을 사용하지 않는 연결 차단’은 기본 연결이 안정된 뒤에 켜세요. 후자는 클라이언트가 실행되지 않거나 재연결 중일 때 네트워크를 차단하므로 휴대폰 전체가 오프라인인 것처럼 보일 수 있습니다. 켠 뒤 LAN에 접근할 수 없다면 시스템 차단 정책과 앱 제외 설정이 충돌하는지도 확인하세요. 복구하려면 먼저 Android VPN 설정으로 돌아가 조정한 뒤 클라이언트 내부 규칙을 변경합니다.

휴대폰 핫스팟에 연결된 기기가 휴대폰의 VPN을 반드시 함께 사용하는 것은 아닙니다. 핫스팟의 트래픽 전달 경로, 시스템 권한, 프록시 수신 설정은 별도로 확인해야 합니다. 공유가 필요하면 LAN 프록시 방식에 따라 기기 주소와 포트를 설정하고 접근 가능한 범위를 제한하세요. 사용이 끝나면 필요 없는 수신 기능을 끄고, 신뢰할 수 없는 네트워크에 로컬 프록시 포트를 계속 노출하지 마세요.

iOS: 설치, 가져오기 및 네트워크 확장

App Store에서 Clash Plus 설치

iPhone과 iPad에서는 Clash Plus를 우선 사용하세요. Clash Plus App Store 페이지에서 설치하고 공식 웹사이트 clashplus.io에서 제품 정보를 확인할 수 있습니다. 시스템 요구 사항은 현재 App Store에 표시된 내용을 기준으로 확인하세요. 설치 버튼을 사용할 수 있는지는 기기 호환성과 계정에서 실제로 이용할 수 있는 스토어 콘텐츠에 따라 달라지므로 기기 모델만으로 판단할 수 없습니다.

먼저 사이트의 iOS 다운로드에서 링크를 확인할 수도 있습니다. 처음 실행하면 설정 및 연결 관련 화면을 살펴보고 사용 중인 앱 이름을 확인하세요. 클라이언트는 설정을 불러와 트래픽을 전달하며, 구독은 별도로 준비해야 합니다. App Store에서 설치했다고 사용 가능한 노드까지 준비된 것은 아닙니다. 네트워크 권한 요청을 구독 구매나 계정 인증과 혼동하지 마세요.

구독 가져오기 및 형식 차이 확인

클라이언트의 설정 또는 구독 메뉴에서 원격 설정을 추가하고 서비스 제공업체가 제공한 주소를 붙여 넣으세요. 다운로드와 파싱이 끝날 때까지 기다립니다. 인터페이스 업데이트에 따라 버튼 이름은 달라질 수 있으므로 원격 구독을 추가하는 작업을 기준으로 진행하세요. 가져온 뒤 정책 그룹과 노드 목록이 표시되는지 확인하고 현재 설정으로 선택합니다. 빈 항목만 보인다면 시스템 VPN 설정에서 권한을 반복 승인하기보다 다운로드가 성공했는지 먼저 확인하세요.

휴대폰에서 링크를 복사할 때 앞뒤 공백, 안내 문구, 줄바꿈이 함께 들어갈 수 있습니다. 내용을 로컬에서 확인하고 테스트를 위해 제삼자 도구에 업로드하지 마세요. 링크가 로그인 페이지, 계정 안내 또는 일반 웹페이지를 반환하면 클라이언트는 이를 YAML로 사용할 수 없습니다. 서비스 제공업체가 여러 형식을 제공한다면 현재 클라이언트나 코어에 맞는다고 명시된 형식을 선택하세요. 주소의 확장자만으로 호환성을 판단해서는 안 됩니다.

파일에서 가져올 때는 시스템 파일 선택기에서 실제 설정 파일을 선택하고 기기에 다운로드가 완료됐는지 확인하세요. 클라우드에만 표시되는 자리표시 항목일 수 있습니다. 가져온 뒤 외부 파일을 계속 참조하는지는 클라이언트 구현에 따라 다릅니다. 원격 규칙과 노드 제공자가 추가 리소스를 다운로드할 수도 있으므로 주 설정을 가져온 뒤에도 정책 그룹이 완전하지 않다면 관련 리소스의 다운로드 상태와 네트워크 접근성을 확인하세요.

VPN 설정 및 규칙 모드 확인

처음 연결을 시작하면 시스템에서 VPN 설정을 추가하라는 요청이 표시됩니다. 요청을 보낸 앱을 확인하고 시스템 안내에 따라 승인하세요. 필요하면 기기 인증을 완료해야 합니다. 클라이언트로 돌아가 연결을 시작한 뒤 시스템 설정에서 VPN 상태를 확인합니다. iOS는 네트워크 확장으로 트래픽을 처리하므로 Windows의 관리자 서비스 설치 절차를 그대로 따를 필요가 없습니다. 데스크톱과 같은 이름의 TUN 토글을 찾을 필요도 없습니다.

처음에는 규칙 모드를 선택하고 정책 그룹에서 노드를 직접 지정하세요. 전역 모드는 문제를 잠깐 비교할 때 유용하지만 규칙 문제를 해결하는 대안은 아닙니다. 특정 사이트가 전역 모드에서만 작동한다면 규칙 배정, 직결 경로, 정책 그룹 선택이 다른지 확인해야 합니다. 전역 모드를 계속 유지하기보다 해당 요청에 어떤 규칙이 적용됐는지 확인하는 편이 원하는 트래픽 분리를 복구하는 데 도움이 됩니다.

앱 범위, DNS, 온디맨드 연결 이해

iOS 클라이언트가 Android와 같은 앱별 선택 목록을 제공한다고 가정하지 마세요. 일반 기기에서 앱 단위로 제어할 수 있는 범위는 시스템 인터페이스의 제약을 받으며, 실제 지원 기능은 클라이언트 화면과 기기 관리 상태에 따라 달라집니다. 특정 사이트 유형을 직결하려면 대개 도메인 규칙과 정책 그룹을 먼저 조정합니다. 앱 이름 하나만으로 판단하면 해당 앱이 사용하는 여러 도메인과 시스템 서비스를 놓칠 수 있습니다.

DNS는 설정 파일, 클라이언트 오버라이드, 시스템 네트워크 설정, 다른 네트워크 확장의 영향을 함께 받을 수 있습니다. 일부 개인정보 보호 릴레이나 필터링 기능도 관찰되는 네트워크 경로를 바꿀 수 있습니다. 문제를 해결할 때 기존 구성요소를 먼저 살펴보고 모든 시스템 설정을 바로 삭제하지 마세요. 현재 프록시 클라이언트만 남겨 임시 테스트한 뒤 다른 기능을 하나씩 복구하면 충돌이 어느 계층에서 발생하는지 확인하고 원래 설정으로 되돌릴 근거도 남길 수 있습니다.

온디맨드 연결은 클라이언트에서 설정한 조건에 맞으면 네트워크 확장을 자동으로 시작합니다. 수동 연결이 안정적이고 구독을 업데이트할 수 있는지 확인한 뒤 켜고 어떤 네트워크에서 연결할지 명확히 정하세요. 앱 창을 닫은 뒤에도 VPN이 유지될 수 있으며, 이는 확장이 계속 실행되는 정상적인 동작일 수 있습니다. 앱 인터페이스가 작동하지 않는다는 뜻은 아닙니다. 완전히 중지하려면 클라이언트의 연결 토글을 사용하거나 시스템 VPN 설정에서 연결을 해제하세요.

네트워크 전환 및 설정 백업

Wi-Fi에서 셀룰러 네트워크로 전환하면 기존 연결이 끊길 수 있습니다. 다시 연결될 때까지 기다린 뒤 새 요청으로 테스트하세요. 호텔이나 공항처럼 웹페이지 인증이 필요한 Wi-Fi는 먼저 로그인해야 합니다. 프록시는 해당 네트워크의 접속 인증을 대신하지 않습니다. 특정 Wi-Fi에서만 실패한다면 셀룰러 결과와 비교한 뒤 로컬 DNS, 네트워크 제한, 노드 접근성을 확인하세요. 구독을 전부 삭제할 필요는 없습니다.

기기를 바꾸기 전에 구독 출처, 정책 그룹 선택, 필요한 오버라이드를 기록하세요. 모든 설정이 시스템 백업을 통해 완전히 이전된다고 가정하지 마세요. 내보낸 파일에는 노드 인증 정보가 포함될 수 있으므로 안전한 위치에 보관해야 합니다. 구독 업데이트 후 문제가 생기면 새 정책 그룹으로 전환됐는지, 원격 규칙 로드가 완료됐는지 확인한 뒤 되돌릴지 결정하세요. 이전 파일을 계속 사용할 수 있는지는 서비스 제공업체가 해당 노드를 유지하는지에 달려 있습니다.

Linux: 데스크톱 클라이언트와 코어 실행

데스크톱과 서버 환경 구분

Linux 데스크톱 사용자는 Linux 다운로드에서 우선 추천하는 Clash Verge Rev를 확인하세요. FlClash를 선택할 수도 있습니다. 서버, 라우터, 명령줄 환경에서는 다운로드 페이지의 코어 항목에서 Mihomo를 확인하세요. 그래픽 클라이언트는 보통 코어, 설정, 서비스 권한을 관리합니다. 코어를 직접 실행하면 디렉터리, 시작 방법, 로그, 트래픽 처리를 직접 관리해야 하므로 유지관리 방식이 다릅니다.

설치 전에 배포판, 프로세서 아키텍처, 패키지 형식을 확인하세요. Debian 계열은 보통 deb를 사용하고, RPM 계열은 다운로드 페이지에 실제로 제공된 rpm 패키지를 선택해야 합니다. 파일 확장자만 바꿔 설치할 수는 없습니다. 데스크톱 그래픽 프로그램은 디스플레이 서비스와 시스템 라이브러리에 의존할 수 있어 그래픽 환경이 없는 서버에서 바로 실행하기에 적합하지 않습니다. 공유 라이브러리가 없다는 메시지가 나오면 배포판 호환성을 먼저 확인하고, 무작위로 라이브러리 파일을 받아 시스템 디렉터리를 덮어쓰지 마세요.

설치 후 일반 프록시 연결 확인

시스템 소프트웨어 설치 프로그램으로 설치한 뒤 앱 메뉴에서 실행하세요. 명령줄로 패키지를 설치한다면 먼저 패키지 관리자가 표시하는 의존성과 변경 내용을 확인합니다. 설정 페이지에서 원격 구독을 추가하고 업데이트가 끝나면 현재 설정으로 선택한 뒤 정책 그룹에서 노드를 선택하세요. 처음에는 일반 사용자로 그래픽 인터페이스를 실행하세요. 서비스 설치나 네트워크 인터페이스 생성처럼 권한이 필요한 단계에서만 시스템 권한을 승인합니다.

GNOME, KDE 등 데스크톱 환경마다 프록시 설정 메뉴가 다르고, 앱이 데스크톱 설정을 읽는지도 다릅니다. 브라우저는 데스크톱 시스템 프록시를 사용할 수 있지만 터미널 도구는 대개 매개변수나 환경 변수를 명시해야 합니다. 시스템 프록시 토글이 켜져 있다고 패키지 관리자, 컨테이너, 백그라운드 서비스도 이를 사용한다고 단정하지 마세요. 먼저 프록시를 명시한 요청으로 로컬 포트에 연결할 수 있는지 확인한 뒤 앱별 연동을 설정합니다.

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

현재 터미널 세션에서 여러 도구가 HTTP 프록시를 사용하도록 하려면 아래 변수를 임시로 설정할 수 있습니다. 모든 도구가 이 변수를 따르는 것은 아니며 자체 설정이 필요한 도구도 있습니다. 검증 전에 모든 사용자의 시작 파일에 바로 추가하지 마세요. 사용 후 변수를 해제해 복구하면 클라이언트가 종료된 뒤 터미널이 중지된 수신 포트에 요청을 보내는 일을 막을 수 있습니다.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# 이번 세션의 프록시 설정 해제
unset http_proxy https_proxy

Mihomo 직접 실행 시 디렉터리 경로 확인

코어를 별도로 사용할 때는 먼저 아키텍처에 맞는 실행 파일을 준비해 시스템 실행 경로에 설치하세요. 아래 시작 명령은 시스템에서 mihomo라는 프로그램을 찾을 수 있고 사용자 설정 디렉터리에 완전한 config.yaml이 있다고 가정합니다. 설정 검사 명령을 실행한 다음 포그라운드에서 시작해 로그를 확인하세요. 문법 검사를 통과해도 설정을 읽을 수 있다는 뜻일 뿐, 노드·DNS·원격 규칙 리소스에 모두 접근할 수 있다는 보장은 없습니다.

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

디렉터리 매개변수는 설정과 일부 실행 데이터의 검색 위치를 결정합니다. 터미널에서는 시작되지만 시스템 서비스로 실행하면 실패하는 경우 실행 사용자, 작업 디렉터리, 파일 권한, 환경 변수가 원인일 수 있습니다. 서비스 환경은 대화형 셸의 프록시 환경 변수를 자동으로 이어받지 않습니다. 서비스가 실제로 읽는 설정 경로를 확인한 뒤 구독, 규칙 파일, 로그 디렉터리에 접근할 수 있는지 점검하세요. 서로 다른 설정 파일을 반복해서 복사해 덮어쓰며 테스트하지 마세요.

TUN, DNS 및 컨테이너 네트워크

TUN은 가상 인터페이스를 만들고 라우팅을 조정할 권한이 필요합니다. 그래픽 클라이언트는 대개 서비스 모드나 보조 구성요소를 제공하므로 해당 클라이언트의 설치 절차를 우선 따르세요. 독립 코어의 권한 설정은 배포판의 서비스 관리 방식에 맞춰야 합니다. 데스크톱 프로그램 전체를 불필요하게 높은 권한으로 계속 실행하지 마세요. TUN 장치를 열 수 없다는 메시지가 나오면 시스템 지원 여부와 실행 권한을 먼저 확인합니다. 원격 노드가 유효한지와는 별개의 문제입니다.

Linux DNS는 NetworkManager, systemd-resolved 또는 다른 구성요소가 관리할 수 있습니다. 설정에 DNS 수신 포트를 지정해도 모든 프로그램이 자동으로 해당 포트에 질의하는 것은 아닙니다. 시스템 이름 해석 경로나 TUN 하이재킹 설정도 올바르게 구성해야 합니다. DNS 설정을 바꾸기 전에 현재 관리자를 확인하세요. 네트워크 서비스가 수동으로 수정한 파일을 다시 생성할 수 있습니다. 클라이언트에서 지원하는 연동 방식을 우선 사용하고 원래 설정을 복구할 수 있도록 기록을 남기세요.

컨테이너 안의 루프백 주소는 호스트가 아니라 컨테이너 자신을 가리킵니다. 호스트에서 프록시를 실행 중이어도 컨테이너 안에 127.0.0.1을 입력하면 연결되지 않는 경우가 많습니다. 네트워크 네임스페이스를 넘어 연결해야 한다면 접근 가능한 주소, 수신 범위, 접근 제한을 설계하세요. 편의를 위해 프록시와 제어 인터페이스를 모든 네트워크 인터페이스에 노출하지 마세요. 백그라운드 서비스는 자체 환경 설정을 사용하므로 서비스별로 검증해야 하며 데스크톱 테스트 결과를 그대로 적용할 수 없습니다.

포그라운드 테스트가 끝난 뒤에만 시스템 시작 시 자동 실행을 설정하고 재부팅 후 서비스 상태와 로그를 확인하세요. 서비스를 중지할 때 시스템 프록시, 라우팅, DNS도 함께 복구하고 직결 네트워크가 정상인지 확인합니다. 원격 터미널로 서버를 관리한다면 기본 경로를 바꾸기 전에 현재 세션과 복구 방법을 유지하세요. 관리 연결까지 끊길 수 있습니다. 일반 데스크톱 사용자는 전체 코어 서비스를 직접 관리할 필요가 없는 경우가 많으며, 지속적으로 사용하려면 그래픽 클라이언트가 더 적합합니다.

설정 관련 자주 묻는 질문: 연결 경로별 문제 해결

구독 오류는 다운로드와 파싱을 구분해 확인

‘업데이트 실패’는 주소 요청, 연결, 콘텐츠 수신, YAML 파싱 중 어느 단계에서든 발생할 수 있습니다. 오류가 시간 초과, 인증서 문제, 권한 거부, 필드 또는 문법 오류 중 무엇인지 먼저 확인하세요. 네트워크 오류라면 현재 네트워크, 시스템 시간, 요청 경로를 점검합니다. 파싱 오류라면 반환된 내용과 호환되는 형식을 확인하세요. DNS를 바꿔도 들여쓰기 누락은 해결되지 않으며 YAML을 다시 작성해도 만료된 링크가 유효해지지는 않습니다.

같은 링크가 브라우저에서는 작동하고 클라이언트에서는 실패할 수 있습니다. 브라우저가 기존 프록시, 저장된 로그인 상태, 다른 요청 정보를 사용하기 때문일 수 있습니다. 브라우저에서 열린다는 이유만으로 클라이언트 문제라고 단정하지 마세요. 현재 설정이 작동하지 않는데 업데이트 요청이 현재 프록시에 의존하면 스스로 복구할 수 없는 순환이 생길 수도 있습니다. 클라이언트가 지원하는 다운로드 경로 설정을 확인하세요. 자세한 항목은 구독 만료 및 파싱 실패 자체 점검을 참고하세요.

규칙 순서 및 오버라이드 범위

규칙은 일반적으로 위에서부터 순서대로 검사하고, 일치하는 규칙의 정책을 사용합니다. 마지막 MATCH는 앞에서 일치하지 않은 연결을 처리합니다. 아래 내용은 일부 예시일 뿐 완전히 실행 가능한 구독이 아닙니다. PROXY는 설정에 실제로 존재하는 정책 그룹 이름으로 바꿔야 합니다. 그룹 이름이 다르면 설정 로드에 실패할 수 있습니다. 도메인 규칙은 도메인 정보를 확인할 수 있어야 하며 IP 주소로 직접 연결하면 도메인 항목과 일치하지 않을 수 있습니다.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

클라이언트 오버라이드는 전체 구간을 대체할 수도 있고 필드를 병합할 수도 있으므로 YAML 계층만 보고 병합 방식을 추측할 수 없습니다. 원격 규칙, 사용자 지정 규칙, 인터페이스 설정이 함께 적용된 뒤에는 최종 실행 설정이나 연결에 실제로 적용된 규칙을 확인해야 합니다. 구독 업데이트 후 사용자 지정 내용이 사라졌다면 원격 업데이트가 관리하는 파일을 수정했을 가능성이 큽니다. 장기적으로 사용할 규칙은 클라이언트가 공식 지원하는 로컬 확장 기능에 넣고 원본을 백업하세요.

DNS, Fake-IP, 포트는 각각 점검

Fake-IP는 일부 도메인에 매핑용 가상 주소를 할당하고 이후 연결에서 코어가 해당 주소를 도메인과 연결하는 방식입니다. 노드의 실제 주소가 아닙니다. 앱 호환성 문제가 생기면 DNS 요청이 코어에 들어오는지 확인한 다음 앱이 이전 결과를 캐시했는지 살펴보세요. 캐시에 있는 가상 주소를 장기 IP 규칙에 직접 넣지 마세요. DNS 모드를 바꾼 뒤 새 연결을 만들고, 필요하면 앱의 DNS 캐시를 지운 뒤 비교합니다.

nameserver, fallback, 필터 조건의 동작은 전체 DNS 설정에 따라 달라집니다. 공개 DNS 주소를 여러 개 무작정 추가하는 것만으로 성능이 개선되지는 않습니다. 특히 상위 DNS에 접근하려면 프록시 서버 도메인을 먼저 해석해야 하는 설정은 DNS 순환을 일으킬 수 있습니다. 각 항목을 자세히 이해하려면 DNS 필드 및 하이재킹 경로 안내를 읽고, 작동하는 설정을 먼저 백업한 뒤 테스트하세요.

LAN 공유 및 제어 인터페이스

혼합 포트는 앱의 프록시 트래픽을 받고 제어 인터페이스는 코어를 관리합니다. 두 기능의 용도는 다릅니다. 다른 기기와 프록시를 공유하려면 접근 가능한 주소로 프록시를 수신하고 LAN 접근을 허용한 뒤 방화벽 범위를 설정해야 합니다. 이때 제어 인터페이스를 열 필요는 없습니다. 다른 기기에는 프록시를 실행하는 기기의 LAN 주소를 입력해야 하며 상대 기기 자신의 루프백 주소를 입력하는 것이 아닙니다. 공유가 끝나면 네트워크를 신뢰할 수 있는지 확인하고 사용하지 않는 수신 기능을 바로 끄세요.

필요한 정보만 보존해 재현 가능한 문제 해결

테스트할 때 운영체제, 클라이언트, 트래픽 처리 방식, 문제가 발생한 앱, 발생 시간을 기록한 뒤 조건을 하나만 바꾸세요. 노드 검사에 성공해도 모든 프로토콜, 사이트, UDP가 작동하는 것은 아닙니다. 웹페이지가 열려도 백그라운드 앱까지 정상이라는 뜻은 아닙니다. 연결이 코어에 들어오는지, 규칙이 올바른지, 출구가 작동하는지 순서대로 확인한 뒤 어느 계층을 바꿀지 결정하면 관계없는 설정을 반복해서 바꾸는 일을 줄일 수 있습니다.