플랫폼에 맞는 클라이언트를 선택하고 구독 가져오기, 규칙 분류, 연결 확인을 완료하세요.
설정 예시 / 단계별로 보기
설정, 규칙, 트래픽을 가로채는 범위를 먼저 구분한 다음 설정을 변경하세요. 아래 내용은 각 기능의 관계를 설명하기 위한 예시이며, 정책 그룹이 모두 포함된 완전한 설정 파일을 대신하지 않습니다.
config.yaml / rules
mode: rule
rules:
- DOMAIN-SUFFIX,github.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY구체적인 도메인 규칙을 앞에 두고, 지역 규칙을 이어 배치한 뒤 MATCH로 나머지를 처리하세요. Clash는 규칙을 위에서부터 확인하며, 일치하는 규칙을 찾으면 해당 출구를 사용하고 뒤의 규칙은 더 이상 확인하지 않습니다. 예시의 PROXY는 정책 이름이므로 설정에 정의된 정책 그룹과 일치해야 합니다. DIRECT는 프록시를 거치지 않는 직접 연결을 뜻합니다. 설정을 바꾼 뒤 새 연결을 시도하고 연결 페이지에서 적용된 규칙을 확인하세요. 전역 모드와 달리 규칙 모드에서는 대상에 따라 서로 다른 출구를 사용할 수 있어 일반적인 웹 탐색과 로컬 서비스 이용을 함께할 때 유용합니다.
구독 / 설정 적용 순서
구독 페이지에서 제공업체의 호환 링크를 가져오고, 업데이트가 완료되면 해당 설정을 선택하세요. 구독에는 노드, 정책 그룹, 규칙, DNS 설정이 포함될 수 있으므로 가져오기에 성공했다고 모든 연결이 자동으로 프록시를 통과하는 것은 아닙니다. 오류가 발생하면 먼저 내용이 웹페이지나 다른 클라이언트 전용 형식이 아닌 완전한 YAML인지 확인하세요. 개인 규칙을 추가할 때는 원격 구독 파일을 직접 수정하지 말고 클라이언트의 덮어쓰기 또는 병합 기능을 우선 사용하세요. 이후 업데이트 시 원본 파일에 적용한 로컬 수정 내용이 사라질 수 있습니다.
트래픽 가로채기 범위 / 한 가지 방식으로 먼저 확인
먼저 시스템 프록시로 브라우저 연결을 확인한 뒤 TUN이 필요한지 판단하세요. 시스템 프록시는 운영체제 설정을 통해 앱에 로컬 포트를 사용하도록 알리지만, 일부 프로그램은 이 설정을 따르지 않습니다. TUN은 가상 네트워크 어댑터를 통해 코어로 라우팅되는 트래픽을 받으며, 보통 추가 권한과 DNS·라우팅 설정이 필요합니다. 두 방식은 트래픽을 가로채는 범위가 다를 뿐, 노드 품질을 자동으로 바꾸거나 전역 모드로 전환하지는 않습니다. 특정 앱만 가로채지 못하는 경우에 TUN을 설정하고, 다른 VPN이나 가상 네트워크 어댑터와 충돌하는지 확인하세요.
연결 확인 / 진입부터 출구까지
대상 도메인 → DNS 확인
앱 요청 → 시스템 프록시 또는 TUN
규칙 일치 → 정책 그룹
선택한 출구 → 대상 서비스새 웹 요청을 한 번 보낸 다음 연결 페이지를 열어 대상, 일치한 규칙, 실제 출구를 확인하세요. 메인 화면의 스위치만 봐서는 앱의 트래픽이 코어에 전달됐는지 알 수 없고, 지연 시간 테스트만으로는 실제 웹사이트 접속 여부를 확인할 수 없습니다. 연결 기록이 없다면 트래픽 가로채기 설정을 확인하세요. 예상과 다른 규칙이 적용됐다면 규칙 순서나 정책을 조정하고, 출구가 맞는데도 연결되지 않으면 노드, DNS, 대상 서비스를 확인하세요. 한 번에 변수 하나만 바꾸고 다시 테스트하면 문제를 추적하기 쉽고, 여러 설정을 동시에 바꾸는 것보다 원인을 빠르게 찾을 수 있습니다.
설정의 출발점은 ‘트래픽 가로채기’와 ‘출구 선택’을 구분하는 것입니다. 시스템 프록시와 TUN은 어떤 요청을 클라이언트로 전달할지 결정하고, 규칙 모드와 전역 모드는 전달된 요청이 출구를 선택하는 방식을 결정합니다. 두 가지는 서로 독립적입니다. TUN을 켜도 규칙에 따라 트래픽을 분기할 수 있으며, 전역 모드를 선택해도 시스템 프록시를 무시하는 모든 프로그램이 자동으로 연결되는 것은 아닙니다. 처음 설정할 때는 기본값을 유지하고, 재현 가능한 연결을 먼저 확인한 뒤 사용 범위를 점차 넓히세요.
설정 예시를 볼 때는 주변 맥락도 확인해야 합니다. 규칙에서 참조하는 정책은 미리 정의되어 있어야 하고 YAML 들여쓰기도 정확해야 합니다. 일부 필드는 클라이언트가 사용하는 코어에 따라 달라집니다. 온라인 예시를 통째로 구독 설정에 붙여 넣으면 기존 구조를 덮어쓸 수 있습니다. 필드 의미는 용어집에서 확인하고, 구체적인 실패 지점을 찾으려면 증상별 문제 해결 가이드를 살펴보세요.
클라이언트 / 플랫폼별 선택
시스템과 프로세서 아키텍처를 확인한 뒤 설치 파일을 선택하세요. 데스크톱 그래픽 클라이언트, 모바일 앱, 명령줄 코어는 사용 방식이 다르며 설정 파일도 그대로 호환되지 않을 수 있습니다.
먼저 Clash Plus를 살펴보고 사용 방식에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu를 선택할 수도 있습니다. 시스템 정보에서 프로세서 종류를 확인한 다음 설치 파일 안내를 살펴보세요. x64 설치 파일과 ARM 아키텍처를 혼동하지 마세요. 설치 후 시스템 프록시를 먼저 확인하고, 트래픽 가로채기가 필요할 때 서비스와 TUN 권한을 설정하세요.
Clash for Windows는 유지 관리가 중단되었으며 다운로드 페이지에 보관용 안내가 제공됩니다. 기존 사용자가 이전할 때는 구독과 개인 규칙을 먼저 백업하세요. 새 클라이언트의 포트와 덮어쓰기 방식을 다시 확인하고, 기존 설정 폴더 전체를 그대로 옮기지 마세요.
다운로드 페이지로 이동Apple Silicon과 Intel을 구분한 뒤 Clash Plus, Clash Verge Rev, FlClash 중 해당하는 패키지를 선택하세요. ‘이 Mac에 관하여’에서 칩 정보를 확인하는 편이 외관으로 판단하는 것보다 정확합니다. 처음 실행할 때는 시스템 안내에 따라 필요한 권한을 허용한 다음 클라이언트에서 설정을 가져오고 프록시 상태를 확인하세요.
이전 클라이언트의 프록시 설정이 새 클라이언트에 영향을 줄 수 있습니다. 전환하기 전에 기존 프로세스를 종료하고 두 프로그램이 동시에 시스템 프록시를 변경하지 않는지 확인하세요. ClashX Meta 보관 자료와 유지 관리 상태는 다운로드 페이지에 별도로 표시되어 있습니다.
다운로드 페이지로 이동Clash Plus, Clash Meta for Android, FlClash, Surfboard의 지원 정보를 확인하세요. 대부분 최신 기기는 ARM64를 사용하지만 기기 정보를 기준으로 판단해야 합니다. 설치 후 호환되는 설정을 가져오고, 처음 연결할 때 시스템 VPN 권한 안내를 확인하세요. 다른 VPN 앱을 동시에 실행하면 트래픽 가로채기 충돌이 발생할 수 있습니다.
백그라운드에서 연결을 계속 유지해야 한다면 휴대전화 설정에서 배터리 최적화와 백그라운드 실행 권한을 확인하세요. 화면을 끈 뒤에만 연결이 끊긴다면 구독을 계속 바꾸기보다 시스템이 프로세스를 중지하는지 먼저 확인하세요. Surfboard는 Clash YAML과 설정 체계가 다르므로 가져오기 전에 형식을 확인해야 합니다.
다운로드 페이지로 이동다운로드 페이지에서 Clash Plus의 App Store 상세 페이지로 이동해 기기 호환성과 앱 정보를 확인하세요. 클라이언트 공식 사이트는 clashplus.io입니다. 설치 후 앱 안내에 따라 설정을 가져오고 시스템 메시지가 표시되면 VPN 구성을 추가하세요. 이후에는 앱의 연결 상태와 실제 접속 결과를 함께 확인해 설정이 적용됐는지 판단하세요.
Wi-Fi와 모바일 네트워크를 전환한 뒤 같은 대상에 다시 연결해 보세요. 연결 결과가 달라지면 사용 중인 네트워크, 오류 메시지, 선택한 정책을 기록한 다음 모바일 문제 해결 항목을 확인하세요. 클라이언트는 연결을 처리하며, 구독 제공처와 사용 가능한 회선은 별도로 확인해야 합니다.
다운로드 페이지로 이동데스크톱 환경에서는 Clash Verge Rev 또는 FlClash를 선택한 뒤 배포판에 맞는 패키지 형식으로 설치할 수 있습니다. GUI가 없는 서버나 라우터, 백그라운드 서비스가 필요한 환경에는 mihomo 코어를 별도로 배포할 수 있습니다. 그래픽 클라이언트는 보통 설정 관리 기능을 제공하지만, 명령줄 코어는 설정 디렉터리와 실행 인수, 서비스 권한을 직접 관리해야 합니다.
데스크톱 프록시 설정이 터미널 프로그램에 적용되지 않을 수 있습니다. 명령줄 다운로드 도구는 프록시 환경 변수를 따로 설정해야 할 수 있으며, 백그라운드 서비스는 대화형 터미널의 환경 변수를 자동으로 상속하지 않습니다. 먼저 네트워크에 연결해야 하는 프로세스를 확인한 뒤 앱별 프록시, 시스템 프록시, TUN 중 적절한 방식을 선택하세요. 서로 다른 범위의 설정을 혼동하지 않도록 주의하세요.
다운로드 페이지로 이동클라이언트를 다운로드해도 프록시 회선이 제공되는 것은 아닙니다. 설정을 가져오기 전에 신뢰할 수 있는 출처에서 제공된 구독인지, 선택한 클라이언트와 형식이 호환되는지 확인하고 링크를 안전하게 보관하세요. 링크에 접근 인증 정보가 포함될 수 있으므로 공개 댓글이나 스크린샷, 낯선 변환 사이트에 붙여 넣지 마세요. 설정을 업데이트한 뒤에는 예상한 정책 그룹이 선택되어 있는지 확인하세요.
빠른 시작 / 연결 확인 절차 유지하기
기본 설정으로 연결을 한 번 확인한 다음 사용자 지정 규칙을 추가하세요. 다음은 사용법의 간단한 미리 보기이며, 메뉴 이름은 클라이언트에 따라 다를 수 있습니다.
클라이언트에서 ‘구독’ 또는 ‘설정’ 메뉴를 열고 호환되는 구독 링크를 붙여 넣은 뒤 다운로드나 업데이트를 실행하세요. 설정 이름이 표시되면 해당 설정을 선택하고 프록시 페이지에 정책 그룹이 나타나는지 확인하세요. 가져오기에 실패하면 링크가 완전한지, 만료되지 않았는지, 응답 형식이 클라이언트에서 지원되는지 확인하세요. 설정이 아직 로드되지 않았다면 시스템 프록시를 반복해서 변경하지 마세요.
로컬 파일도 설정 출처로 사용할 수 있지만 유효한 프록시 또는 프록시 제공자와 관련 정책이 포함되어야 합니다. rules 몇 줄만 있는 예시는 단독으로 연결을 제공할 수 없습니다. 정상 작동하는 설정을 하나 보관해 두면 나중에 되돌리기 쉽습니다.
먼저 규칙 모드로 전환한 다음 규칙에서 실제로 참조하는 정책 그룹에서 출구를 선택하세요. 규칙 모드는 로컬 대상과 다른 서비스를 구분해 처리할 때 적합합니다. 전역 모드는 출구 동작을 임시로 비교할 때 쓸 수 있고, 직접 연결 모드에서는 프록시 출구를 사용하지 않습니다. 이름이 비슷한 정책 그룹도 용도가 다를 수 있으므로 목록의 첫 번째 그룹만 바꾸지 말고 규칙이 어떤 그룹을 가리키는지 먼저 확인하세요.
처음 연결할 때 모든 고급 옵션을 바로 켤 필요는 없습니다. DNS와 라우팅은 기본 설정으로 두고 기본 연결이 되는지 확인하세요. 특정 도메인을 직접 연결하려면 범위가 명확한 규칙을 추가하고, 더 포괄적인 규칙보다 앞에 배치했는지 확인하세요.
데스크톱에서는 먼저 시스템 프록시를 켜고, 모바일에서는 안내에 따라 VPN 연결을 시작하세요. 테스트 페이지를 다시 열고 클라이언트 연결 페이지에서 대상과 출구를 확인합니다. 이미 연결된 세션은 기존 경로를 계속 사용할 수 있으므로 필요하면 해당 앱을 종료하고 다시 시도하세요. 스위치가 켜져 있는지만 보는 것보다 동일한 접속 결과를 재현할 수 있는지 확인하는 편이 더 확실합니다.
클라이언트를 종료한 뒤에도 인터넷에 연결되지 않는다면 시스템에 로컬 포트를 가리키는 프록시 설정이 남아 있는지 확인하세요. 일부 앱에서만 연결 기록이 보이지 않으면 앱 프록시, TUN, VPN 제외 항목을 살펴보세요. 연결 기록은 있지만 접속에 실패한다면 규칙, 정책, DNS, 회선 순서로 확인하세요.
연결을 확인한 다음 시작 시 자동 실행을 설정하세요. 먼저 클라이언트가 정상적으로 종료되고 다시 연결되는지 확인한 뒤 시작 프로그램 등록, 자동 연결, 백그라운드 서비스를 활성화하세요. 프로그램 시작과 네트워크 트래픽 가로채기는 별개의 설정입니다. 재부팅 후 설정이 로드됐는지, 코어가 실행 중인지, 프록시 포트를 사용할 수 있는지도 확인해야 합니다.
오픈 소스 생태계 / 프로젝트와 클라이언트 구분
소스 코드, 릴리스 노트, 설정 문서에서 기능을 확인하세요. 클라이언트는 관리를 담당하고 코어는 연결을 처리하며 구독은 설정을 제공합니다. 각 요소의 업데이트 주기는 서로 다릅니다.
Clash는 규칙에 따라 출구를 선택하는 설정 방식을 구축했고, Clash Meta는 이 생태계를 확장했습니다. 이후 관련 코어 프로젝트는 mihomo라는 이름으로 유지 관리되고 있습니다. 오래된 문서에서는 여전히 Clash Meta라는 명칭을 사용할 수 있습니다. 글을 읽을 때는 코어, 그래픽 클라이언트, 설정 형식 중 무엇을 다루는지 먼저 확인하세요. 이름이 같다고 유지 관리 상태까지 같은 것은 아닙니다.
Clash for Windows는 그래픽 클라이언트의 이름일 뿐 Clash 생태계 전체를 뜻하지 않습니다. 해당 클라이언트의 유지 관리가 중단된 뒤에도 다른 클라이언트와 mihomo 코어는 각각 별도의 릴리스 절차를 따릅니다. 이전할 때 기존 구독 출처는 계속 사용할 수 있지만, 설정 지원 범위와 기본 포트, 서비스 모드, 개인 덮어쓰기 기능은 다시 확인해야 합니다.
그래픽 클라이언트는 보통 구독 관리, 정책 전환, 로그 확인, 시스템 프록시 설정 기능을 제공합니다. 코어는 설정을 해석하고 DNS, 규칙 일치, 프록시 연결을 처리합니다. 특정 프로토콜이나 필드를 사용할 수 있는지는 코어의 지원 여부와 클라이언트가 설정을 올바르게 전달하는지에 따라 달라집니다. 화면에 스위치가 보인다고 모든 매개변수가 적용된 것은 아닙니다.
클라이언트를 비교할 때는 외관보다 운영체제 호환성, 설정 관리 방식, 일상적인 문제 해결 기능을 우선 살펴보세요. 백그라운드 실행이 필요한 기기라면 서비스 관리와 권한 복구도 중요합니다. 클라이언트 선택은 다운로드 페이지의 플랫폼 안내를 기준으로 하고, 필드가 다르면 사용 중인 코어 문서와 대조하세요.
클라이언트 업데이트는 코어, 인터페이스, 권한 처리 방식을 바꿀 수 있고 구독 업데이트는 주로 제공업체의 설정을 교체합니다. 서로 대체할 수 없으므로 업데이트 전에 개인 규칙과 정상 작동하는 설정을 보관하고 현재 시스템과 관련된 릴리스 노트를 확인하세요. 업데이트 후에는 구독 로드, 정책 선택, 연결 경로를 다시 점검하고, 특히 서비스 모드와 TUN의 권한을 다시 허용해야 하는지 확인하세요.
원격 구독은 제공업체가 관리하도록 두고, 개인 설정은 클라이언트가 지원하는 덮어쓰기, 병합, 별도 규칙 파일로 적용하세요. 클라이언트마다 병합 순서가 다를 수 있으므로 이전 후 특정 도메인 하나를 테스트해 개인 규칙이 최종 설정에 반영됐는지 확인하세요. 편집기에서 저장에 성공했다고 실행 중인 코어가 다시 로드된 것은 아닙니다.
문제가 발생하면 운영체제, 클라이언트 이름, 트래픽 가로채기 방식, 오류 발생 시각, 재현 절차를 기록하세요. 로그의 구독 링크, 서버 주소, 인증 정보에는 민감한 내용이 포함될 수 있으므로 공개하기 전에 삭제하세요. ‘특정 네트워크에서 특정 앱의 연결 기록이 나타나지 않는다’고 설명하면 단순히 ‘작동하지 않는다’고 쓰는 것보다 원인을 찾기 쉽고 DNS 문제를 규칙 오류로 오해할 가능성도 줄어듭니다.
Clash 가이드는 다운로드 경로와 설정 절차를 정리하는 사이트로, 코어 프로젝트나 모든 클라이언트의 공식 유지 관리자가 아니며 프록시 회선을 제공하지 않습니다. 특정 클라이언트의 결함은 해당 프로젝트의 릴리스 노트와 문제 제보 채널에서 확인하세요. 구독 권한이나 내용은 구독 제공처에 문의해야 합니다. 사용 시에는 거주 지역의 법률, 네트워크 관리 규정, 관련 서비스 약관을 함께 준수하세요.
아닙니다. 규칙 모드는 일치한 규칙에 따라 직접 연결이나 프록시를 선택하며, 먼저 요청이 코어로 전달되어야 합니다. 트래픽이 가로채지는 범위를 확인한 뒤 적용된 규칙을 살펴보세요. 관련 개념은 용어집에서 확인할 수 있습니다.
네. TUN은 가상 네트워크 어댑터로 라우팅된 트래픽을 받고, 정책 그룹은 계속 출구를 선택합니다. DNS, 라우팅, 다른 VPN의 영향도 확인해야 합니다. 용어집에서 네트워크 스택과 정책의 차이를 먼저 살펴보세요.
테스트 결과는 지정한 주소에 당시 조건으로 연결된 상태만 보여 줍니다. 대상 웹사이트, DNS, 앱의 트래픽 가로채기가 정상이라고 보장하지는 않습니다. 실제 요청을 보내고 연결 기록을 확인한 뒤 단계별로 문제를 살펴보세요. 기본 용어는 용어집에서 확인할 수 있습니다.
정보 / 주제별 읽을거리
기본 연결을 확인한 뒤 문제에 맞는 주제를 선택하세요. 아래 세 글에서는 Linux 백그라운드 실행, 지연 시간 테스트 결과 해석, 사용자 지정 규칙 순서를 다룹니다. 설정에서 확인한 증상을 바탕으로 이어서 살펴보세요.
데스크톱 Linux 배포판의 그래픽 클라이언트와 헤드리스 서버 환경을 다룹니다. mihomo 설치, 설정 디렉터리, systemd 서비스, 터미널 프록시 환경 변수 설정 방법을 안내합니다.
대화형 터미널과 백그라운드 서비스의 실행 환경 차이를 중점적으로 설명합니다. 수동으로 실행할 때는 연결되지만 재부팅 후 서비스가 작동하지 않거나 터미널 도구가 예상한 프록시를 사용하지 않는 경우에 유용합니다.
글 읽기 →클라이언트의 지연 시간 테스트 방식, 테스트 주소와 제한 시간이 결과에 미치는 영향, 패킷 손실·대역폭·회선 혼잡이 밀리초 수치에 반영되지 않는 이유를 설명합니다.
같은 조건에서 테스트한 뒤 실제 앱 사용 환경을 비교하세요. 테스트 결과는 정상처럼 보이지만 다운로드, 동영상, 웹페이지 접속에서 차이가 큰 경우에 적합합니다.
글 읽기 →자주 사용하는 규칙 유형의 문법을 하나씩 살펴보고, 위에서부터 확인해 처음 일치한 규칙을 적용하는 방식을 설명합니다. rule-providers 참조와 규칙 충돌 해결 방법도 안내합니다.
도메인 규칙 하나부터 시작한 다음 규칙 모음 참조와 기본 규칙의 위치를 확인하세요. 올바른 정책을 선택했는데도 특정 웹사이트가 예상과 다른 출구를 사용하는 경우에 유용합니다. 수정 전에 원래 설정을 보관하고, 변경 후에는 새 연결로 적용된 규칙을 확인하세요. 브라우저가 기존 연결을 재사용하면 결과가 혼동될 수 있습니다.
글 읽기 →