운영체제에 맞는 클라이언트를 고르고 구독 가져오기부터 시작해 규칙 기반 라우팅과 mihomo 코어 설정의 차이를 알아보세요.
먼저 설정 파일이 정상적으로 불러와지는지 확인한 다음, 트래픽을 코어에 전달할 방법과 규칙에 따른 출구를 정하세요. 아래는 일반적인 설정 구성을 보여주는 예시이며 실제 서비스에는 연결되지 않습니다. 클라이언트마다 메뉴 이름은 조금씩 다를 수 있습니다.
원격 프로필
예시 주소는 구독을 제공하지 않습니다. 클라이언트에서 본인의 설정을 사용하세요.
클라이언트의 ‘프로필’ 또는 ‘구독’ 메뉴에 서비스 제공자가 안내한 주소를 붙여 넣고 다운로드한 뒤 해당 프로필을 선택하세요. 전체 Clash YAML에는 노드, 프록시 그룹, 규칙이 함께 포함될 수 있지만, 단일 노드 링크에는 보통 연결 정보만 있어 완전한 라우팅 설정을 대신할 수 없습니다. 가져오기에 실패하면 주소가 만료되지 않았는지, 응답이 YAML인지 확인한 다음 코어가 해당 프로토콜을 지원하는지 살펴보세요. 원격 프로필을 업데이트하면 수동 수정 내용이 덮어써질 수 있으므로, 계속 유지할 규칙은 클라이언트의 오버라이드 또는 병합 설정에 넣는 편이 좋습니다. 구독 주소에는 접근 권한 정보가 포함되므로 공개적으로 공유하지 마세요.
모드 예시 · 규칙
mixed-port모드는 코어에 들어온 트래픽의 라우팅 방식을 정합니다. 앱이 프록시를 사용할지는 별개의 문제입니다.
‘규칙’ 모드는 설정에 따라 목적지별 규칙을 적용하므로 직접 연결과 프록시를 함께 쓰기 좋습니다. ‘전역’ 모드는 코어에 들어온 트래픽을 전역 정책으로 보내고, ‘직접 연결’은 해당 연결을 목적지에 바로 전달합니다. 보통 프록시 페이지나 트레이 메뉴에서 모드를 고른 뒤 프록시 그룹에서 출구를 선택합니다. 전역 모드를 켜도 기기의 모든 앱이 자동으로 트래픽을 넘기는 것은 아닙니다. 시스템 프록시를 따르지 않는 앱은 코어를 우회할 수 있습니다. 문제를 확인할 때는 잠시 전역 모드로 바꿔 결과를 비교한 뒤 규칙 모드로 되돌리세요. 규칙 문제와 노드 연결 문제를 혼동하지 않는 데 도움이 됩니다.
순서대로 매칭 · 설정 문법 예시
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- GEOIP,LAN,DIRECT
- MATCH,PROXYPROXY는 설정에 정의된 프록시 그룹 이름이어야 합니다.
규칙 페이지에서는 불러온 규칙의 적용 순서를 확인할 수 있습니다. 실제 규칙 편집은 설정 파일, 규칙 오버라이드 또는 구독 병합 메뉴에서 해야 할 수 있습니다. DOMAIN-SUFFIX는 도메인 접미사로, GEOIP는 IP 주소의 지리 정보로 매칭하며 MATCH는 보통 마지막에 기본 규칙으로 둡니다. 규칙은 위에서 아래로 적용되므로 먼저 일치하는 항목이 있으면 뒤의 더 구체적인 규칙까지 확인하지 않습니다. 따라서 규칙 순서와 대상 프록시 그룹을 모두 신경 써야 합니다. 전역 모드와 달리 규칙 기반 라우팅은 로컬 서비스의 직접 연결을 유지할 수 있지만 DNS, 규칙 데이터, 프록시 그룹 이름이 서로 맞아야 합니다. 변경 후에는 연결 패널에서 어떤 규칙이 적용됐는지 확인하세요.
mixedauto-route사용할 수 있는 stack과 라우팅 옵션은 코어 및 운영체제에 따라 다릅니다.
지원되는 데스크톱 클라이언트에서 TUN을 켜고 안내에 따라 서비스를 설치하거나 필요한 권한을 부여하면, 코어가 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 받을 수 있습니다. 시스템 프록시 설정을 읽지 않는 앱에도 적용할 수 있다는 점에서 브라우저나 시스템 프록시만 설정하는 방식과 다릅니다. 먼저 일반 프록시 연결이 되는지 확인한 뒤 자동 라우트, DNS 가로채기, 다른 VPN과의 충돌을 살펴보세요. system, gvisor, mixed 등의 stack 지원 여부는 플랫폼마다 다르므로 화면 예시를 그대로 따라 하지 않는 것이 좋습니다. TUN은 트래픽을 전달하는 범위를 넓혀 줄 뿐, 만료된 구독이나 잘못된 인증 정보, 사용할 수 없는 노드까지 해결해 주지는 않습니다.
실제 연결 기록은 표시하거나 수집하지 않습니다.
로그 페이지에서는 먼저 info 수준으로 설정 불러오기, DNS 조회, 연결 오류를 확인하세요. 더 자세히 살펴봐야 할 때만 잠시 debug 수준으로 올리면 됩니다. 연결 페이지에서는 대상 도메인, 적용된 규칙, 실제 출구를 확인할 수 있어 노드를 계속 바꿔 보는 것보다 효과적입니다. 연결 기록이 없다면 시스템 프록시나 TUN 진입점을 먼저 확인하세요. 인증 오류가 발생하면 노드 정보와 구독 상태를 점검하고, 일부 도메인만 실패한다면 DNS와 규칙 순서를 살펴보세요. 문제 해결 정보를 공유하기 전에는 구독 주소, 서버 주소, 인증 정보를 가리고, 점검이 끝나면 평소 로그 수준으로 되돌리세요.
설정 파일, 트래픽 진입점, 라우팅 정책은 서로 다른 단계입니다. 구독은 ‘사용할 노드와 규칙’을 제공하고, 시스템 프록시나 TUN은 ‘어떤 앱의 연결이 코어로 들어오는지’를 정하며, 프록시 모드와 프록시 그룹은 ‘들어온 연결이 어느 출구로 나가는지’를 결정합니다. 이 순서대로 설정하면 문제가 생겨도 여러 옵션을 한꺼번에 바꾸지 않고 단계별로 되짚을 수 있습니다.
단계별로 첫 설정 완료하기 →그래픽 클라이언트는 구독 관리, 트레이 메뉴, 시스템 연동을 담당하고 코어는 프로토콜 연결과 트래픽 분배를 처리합니다. 기기에 맞는 설치 파일을 고른 뒤 필요한 프로토콜과 기능을 확인하세요. 화면이 비슷해도 코어의 기능까지 모두 같다는 뜻은 아닙니다.
먼저 Clash Plus를 살펴보고, 인터페이스 취향에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu도 비교해 보세요. 다운로드 전에 운영체제와 프로세서 아키텍처를 확인하세요. 그래픽 인터페이스가 실행된다고 해서 TUN에 필요한 서비스까지 제대로 설치됐다는 뜻은 아닙니다.
일상적인 웹 사용은 시스템 프록시부터 켜고, 구독과 규칙이 정상인지 확인한 다음 TUN을 설정하는 편이 좋습니다. 클라이언트를 종료한 뒤 브라우저가 인터넷에 연결되지 않으면 시스템 프록시 설정이 남아 있는지 확인하세요. 기본 진입점이 복구되지 않은 상태에서 노드를 계속 바꾸지 않는 것이 좋습니다. 지원이 종료된 Clash for Windows는 다운로드 페이지의 보관 자료에서 확인할 수 있습니다. 이전하기 전에는 로컬 설정을 백업하고, 새 프로토콜 필드는 구형 코어가 계속 처리할 수 있다고 기대하지 마세요.
다운로드 페이지로 이동MacBook을 비롯한 Mac 기기는 Apple Silicon과 Intel을 구분한 뒤 알맞은 설치 파일을 선택하세요. Clash Plus, Clash Verge Rev, FlClash를 선택지로 살펴볼 수 있습니다. 지원되는 macOS 버전은 다운로드 페이지와 앱 안내를 확인하세요.
처음 실행할 때 시스템 권한과 네트워크 확장 관련 안내를 확인하세요. 일반적으로 시스템 프록시와 TUN을 동시에 조정할 필요는 없습니다. 터미널 도구에서 프록시를 사용하려면 해당 도구가 시스템 프록시를 읽는지 확인하거나, 명령을 실행할 때 프록시 주소를 별도로 지정해야 합니다. 지원이 종료된 ClashX Meta는 보관 자료로만 참고하세요. 이름에 Meta가 들어간다고 해서 현재 mihomo의 모든 기능을 지원한다고 볼 수는 없습니다.
다운로드 페이지로 이동Clash Plus, Clash Meta for Android, FlClash, Surfboard를 비교해 보세요. 최근 출시된 휴대전화는 대부분 ARM64를 사용하지만, 실제 기기 아키텍처를 확인하는 것이 좋습니다. 앱마다 지원하는 구독 형식이 다를 수 있으므로 파일 확장자만으로 호환성을 판단하지 마세요.
모바일 클라이언트는 보통 시스템 VPN 인터페이스로 연결을 전달하므로 처음 실행할 때 권한을 승인해야 합니다. 같은 사용자 환경의 다른 VPN과 동시에 사용할 수 없는 경우도 있습니다. 화면을 잠근 뒤 연결이 끊기면 시스템 배터리 관리와 백그라운드 실행 권한을 확인한 다음 노드 문제를 점검하세요. 앱별 라우팅, LAN 우회, DNS 설정 메뉴는 클라이언트마다 다릅니다. 데스크톱 설정을 가져온 뒤에도 모바일에서 실제로 어떤 트래픽이 전달되는지 확인해야 합니다.
다운로드 페이지로 이동iPhone과 iPad에서는 다운로드 페이지를 통해 Clash Plus의 App Store 페이지로 이동할 수 있습니다. 프로젝트 공식 사이트는 clashplus.io입니다. 설치 전에 스토어에 표시된 시스템 요구 사항을 확인하고, 사용할 때는 앱 안내에 따라 VPN 구성을 추가하세요.
데스크톱의 시스템 프록시 설정과 모바일의 VPN 권한은 서로 다른 방식입니다. 구독을 가져온 뒤 프록시 그룹, 규칙, 앱이 지원하는 설정 필드를 확인하고 연결 상태와 출구가 예상대로인지 점검하세요. Clash 형식을 지원한다고 해서 데스크톱의 모든 기능까지 지원하는 것은 아닙니다. 백그라운드 실행, 네트워크 전환, 시스템 확장 동작은 iOS의 작동 방식과 앱 구현에 따라 달라집니다.
다운로드 페이지로 이동데스크톱 환경에서는 Clash Verge Rev와 FlClash를 먼저 비교하고, 배포판에 맞는 패키지 형식을 선택할 수 있습니다. 서버, 라우터, 자체 구축 환경이라면 다운로드 페이지의 Mihomo 코어 항목에서 프로세서 아키텍처와 배포 방식에 맞는 파일을 고르세요. 코어만 설치하면 그래픽 구독 관리 인터페이스는 포함되지 않습니다.
데스크톱의 시스템 프록시가 앱에 적용되는지는 데스크톱 환경과 앱 구현에 따라 다르며, 명령줄 프로그램은 별도 설정이 필요할 수도 있습니다. 코어를 배포하기 전에 실행 계정, 설정 디렉터리, 로그 위치를 정하세요. TUN을 켜거나 라우팅을 바꿀 때는 필요한 권한도 처리해야 합니다. 원격 서버의 라우팅을 변경할 때는 복구 경로를 확보하고, 외부 컨트롤 인터페이스는 로컬이나 보호된 네트워크로 제한하세요. 공용 네트워크에 직접 노출해서는 안 됩니다.
다운로드 페이지로 이동설치 파일, 시스템 요구 사항, 보관 여부는 다운로드 센터에서 확인할 수 있습니다. 클라이언트 업데이트와 코어 업데이트를 혼동하지 않도록 홈 화면에는 구체적인 버전을 표시하지 않습니다.
전체 클라이언트 보기 →Clash는 역사적으로 연관된 코어와 클라이언트 생태계를 가리키는 이름으로, Clash가 들어간 모든 앱을 같은 프로젝트에서 배포하는 것은 아닙니다. 이 사이트는 다운로드와 한국어 안내를 제공합니다. 개별 소프트웨어의 기능, 라이선스, 유지 관리 상태는 해당 프로젝트 기록을 확인하세요.
원본 Clash는 노드, 프록시 그룹, 라우팅 규칙을 YAML로 작성하는 방식을 정착시켰고, 여러 그래픽 클라이언트가 이 설정 구조를 이어받았습니다. 원본 프로젝트의 공개 유지 관리가 중단된 뒤에도 생태계의 포크는 계속 발전했습니다. Clash.Meta는 이후 mihomo라는 이름으로 개발을 이어 갔습니다. 따라서 가이드에서 언급하는 Meta와 mihomo는 역사적으로 연결되어 있지만, Clash라는 이름을 쓰는 모든 앱을 같은 것으로 봐서는 안 됩니다. 오래된 가이드를 읽을 때는 코어, 그래픽 클라이언트, 구독 형식 중 무엇을 가리키는지 먼저 확인하세요.
클라이언트는 대개 코어를 내장하거나 호출하고, 설정 다운로드, 시스템 프록시, 서비스 관리, 연결 확인 기능을 제공합니다. 인터페이스를 바꿔도 프로토콜 지원은 달라지지 않을 수 있고, 코어를 교체해도 인터페이스에 관련 옵션이 자동으로 추가되지는 않습니다. 일반 사용자라면 유지 관리 안내가 분명한 클라이언트를 먼저 고른 뒤 사용 중인 코어와 기능 메뉴를 확인하는 편이 안전합니다. 생소한 필드가 나오면 들여쓰기를 반복해서 바꾸기보다 해당 코어 문서를 확인하세요. 구형 코어가 새 문법을 받아들이지 못할 수 있습니다.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC는 연결 매개변수와 전송 방식이 서로 다르며, 프로토콜 이름만으로 실제 속도를 예측할 수는 없습니다. 회선 품질, 서버 설정, 패킷 손실, 기기 성능도 결과에 영향을 줍니다. 특히 UDP 기반 전송 방식은 사용 중인 네트워크에서 해당 트래픽을 허용해야 합니다. 클라이언트가 설정 필드를 인식하더라도 연결에 필요한 조건이 갖춰졌다는 뜻은 아닙니다. 먼저 서비스 제공자가 안내한 매개변수를 지원하는지 확인한 뒤 모바일 네트워크 전환, 배터리 소모, 관리 복잡성을 고려하세요.
Clash YAML에서 자주 쓰이는 노드, 프록시 그룹, 규칙 필드는 여러 프로젝트에서 이어져 왔지만, 새 프로토콜이나 DNS 옵션, 규칙 데이터 형식까지 구형 코어가 인식한다고 보장할 수는 없습니다. 전체 설정 파일, 노드 제공자, 단일 노드 링크는 서로 다른 자료입니다. 구독을 변환하면 특정 클라이언트 전용 필드가 사라지거나 규칙과 프록시 그룹 이름의 연결이 끊길 수 있습니다. 가져오기 오류가 나면 로그를 확인해 형식 해석, 필드 지원, 리소스 다운로드 중 어느 단계의 문제인지 파악하세요. 문법 검사를 통과하는 것은 연결 확인의 첫 단계일 뿐입니다.
프로젝트를 장기간 사용해도 좋을지 판단하려면 공개된 소스 코드, 릴리스 노트, 이슈 논의와 기능 변경에 맞춰 문서가 갱신되는지 확인하세요. 클라이언트와 내장 코어의 업데이트 주기는 다를 수 있으며, 규칙 데이터베이스도 별도로 관리됩니다. 인터페이스 앱, 코어, 구독을 업데이트하는 일은 각각 다른 문제를 해결합니다. 하나가 성공적으로 업데이트됐다고 나머지까지 모두 최신이라고 볼 수는 없습니다. 다운로드 페이지에서는 현재 사용 중인 선택지와 지원이 종료된 보관 항목을 구분합니다. 보관 항목은 이전이나 과거 설정을 참고할 때 활용하세요.
업데이트 전에는 정상 작동하는 설정과 오버라이드 설정을 백업하고, 현재 프록시 모드, DNS 방식, TUN 상태를 기록해 두세요. 업데이트 후에는 설정을 다시 불러오고 자주 쓰는 앱, 로컬 서비스, 출구 선택을 확인하세요. 문제가 생기면 모든 설정을 기본값으로 되돌리기보다 변경 기록을 항목별로 대조하는 편이 좋습니다. 공개적으로 문제를 문의할 때는 시스템, 클라이언트 이름, 사용 중인 코어, 민감 정보를 가린 오류 내용을 함께 제공하면 ‘연결이 안 된다’는 설명만으로 문의하는 것보다 원인을 파악하기 쉽습니다.
노드 지연 시간 테스트는 지정된 테스트 대상과의 연결 결과를 보여줄 뿐, 모든 웹사이트와 앱이 같은 경로를 사용한다는 뜻은 아닙니다. 설정이 적용됐는지 확인하려면 클라이언트의 연결 기록, 적용된 규칙, 실제 출구를 함께 살펴본 뒤 앱이 시스템 프록시를 읽는지 또는 TUN 라우팅에 포함됐는지 확인하세요. 일부 앱만 문제라면 진입점과 앱 자체 프록시 설정을 먼저 점검하고, 일부 도메인만 문제라면 DNS와 규칙 매칭을 먼저 살펴보세요. 불필요한 설정 변경을 줄이는 데 도움이 됩니다.
Fake-IP, 프록시 그룹, 규칙 제공자, UWP 루프백 같은 용어가 낯설다면 용어집에서 개념을 먼저 확인한 뒤 가이드를 따라 설정해 보세요. 기술 참고 자료에서는 프로토콜 설계, 코어 간 관계, 구독 호환성을 비교하므로 클라이언트나 서버 구성을 바꾸기 전에 읽어보면 좋습니다. 이 사이트의 예시 창은 설정 간 관계를 설명하기 위한 것으로, 모든 운영체제에서 특정 클라이언트의 전체 화면을 재현하거나 설치 후 실제 연결을 확인하는 일을 대신하지 않습니다.
첫 연결을 마친 뒤 구체적인 문제에 맞는 자료를 확인하세요. 프록시 그룹 선택, 규칙 데이터베이스 업데이트, 노드 시간 초과는 각각 다른 단계의 문제입니다. 문제가 발생한 위치부터 파악한 다음 해당 설정을 조정하세요.
세 가지 자동 프록시 그룹의 속도 측정 방식, 전환 조건, interval·tolerance 매개변수를 살펴보고 일상적인 웹 사용, 안정성 우선, 다중 회선 분산에 맞는 설정 예시를 제공합니다.
프록시 그룹 가이드 보기 →구독 만료 여부, 시스템 시간 오차, 포트 점유, 로그 오류를 바깥 단계부터 차례로 확인해 노드 시간 초과 원인을 찾고 각 문제의 해결 방법을 안내합니다.
시간 초과 문제 해결 순서 보기 →GeoIP·GeoSite 데이터 파일의 역할과 주요 출처를 설명하고 geox-url 및 자동 업데이트 주기를 설정하는 방법과 GEOIP·GEOSITE 규칙 작성 예시를 안내합니다.
규칙 데이터 업데이트 알아보기 →