연결 진입부터 아웃바운드 정책까지 역할별로 살펴봅니다. 아래 예시는 설정 항목의 형태를 보여 주며, 그대로 실행할 수 있는 완성된 설정은 아닙니다. 실제로 사용하려면 프록시 정의를 추가하고 이름 참조가 일치하는지 확인하세요.
규칙 모드는 목록을 위에서 아래로 확인하며, 처음 일치하는 항목이 연결에 적용할 정책을 결정합니다. 도메인 접미사 규칙은 사이트별 분류에, IP 대역 규칙은 로컬 네트워크 처리에 적합하며, 마지막의 MATCH가 나머지 요청을 처리합니다. 모든 연결에 동일한 출구를 지정하는 글로벌 모드와 달리 규칙 기반 분기는 용도에 따라 연결을 나눠 처리할 수 있습니다. 수정하기 전에 프록시 그룹 이름을 확인하고, 구체적인 규칙을 포괄적인 규칙보다 앞에 배치하세요. 의도와 다른 분기가 발생하면 출구를 계속 바꾸기보다 연결 기록에서 어떤 규칙이 적용됐는지 확인하세요.
프록시 그룹을 사용하면 규칙의 대상과 실제 출구를 분리해 관리할 수 있습니다. select는 사용자가 직접 선택하고, url-test는 지정한 테스트 주소의 결과에 따라 출구를 고르며, fallback은 후보 순서대로 사용 가능한 항목을 찾습니다. 자동 테스트 결과는 테스트 대상에 연결할 수 있는지를 보여 줄 뿐, 모든 사이트의 실제 사용 경험을 보장하지는 않습니다. 규칙마다 출구 이름을 직접 적는 것보다 프록시 그룹을 참조하면 나중에 출구를 바꾸기 쉽습니다. 구독을 가져온 뒤에는 그룹 참조가 유효한지, 자동 선택 그룹의 테스트 주소와 간격이 사용 목적에 맞는지 확인하세요.
DNS는 도메인 이름을 조회하고, Fake-IP는 매핑 주소를 사용해 도메인과 이후 연결의 관계를 유지하므로 코어가 도메인 규칙을 적용할 수 있습니다. Fake-IP는 프록시 출구가 아니며, 출구에 연결할 수 없는 문제를 단독으로 해결하지도 않습니다. 실제 IP 주소를 바로 반환하는 방식과 달리 매핑 방식은 요청이 동일한 코어 처리 경로를 통과해야 효과적으로 작동합니다. 로컬 네트워크 기기 검색이나 특정 앱 호환성에 문제가 생기면 해당 도메인의 필터 설정을 조정할 수 있습니다. 문제를 살펴보기 전에 시스템의 DNS 조회가 실제로 코어에 전달되는지 확인한 다음, 상위 DNS 서버를 점검하세요. 여러 설정을 동시에 바꾸지 않는 것이 좋습니다.
TUN은 가상 네트워크 인터페이스로 트래픽을 받아 시스템 프록시 설정을 따르지 않는 앱을 처리합니다. 브라우저나 시스템 프록시만 바꾸는 방식과 달리 라우팅, 권한, DNS 처리까지 관련되므로 영향 범위가 더 큽니다. 먼저 일반 프록시 연결이 작동하는지 확인한 뒤 TUN을 따로 켜서 테스트하세요. 자동 라우팅을 사용해도 모든 네트워크 인터페이스가 올바르게 처리된다고 보장할 수는 없습니다. 기기에서 다른 VPN, 컨테이너 네트워크 또는 가상 머신을 함께 사용한다면 라우팅 테이블과 제외 범위를 확인하세요. TUN을 끈 뒤에는 시스템 네트워크 설정이 정상적으로 복구됐는지도 점검해야 합니다.
외부 제어 인터페이스는 클라이언트나 대시보드가 연결 정보를 읽고, 정책을 전환하거나 실행 상태를 조정할 때 사용합니다. 프록시 트래픽을 받는 mixed-port와는 별개의 접점이므로 서로 대신할 수 없습니다. 설정 파일을 직접 편집하는 대신 제어 인터페이스에서 상태를 확인하거나 일시적으로 조작할 수 있지만, 실행 중 변경 사항이 저장되는지는 클라이언트에 따라 다릅니다. 로컬에서만 사용할 때는 루프백 주소에 바인딩하세요. 원격 관리가 필요하면 인증과 접근 제한을 설정해야 합니다. 신뢰할 수 없는 네트워크에 제어 인터페이스를 직접 노출하거나 인증 정보가 포함된 설정을 공개하지 마세요.
설정은 정해진 순서로 확인하세요. 먼저 연결이 코어에 들어오는지 확인하고, 다음으로 도메인 조회와 규칙 적용 결과를 점검한 뒤, 프록시 그룹과 실제 출구를 확인합니다. 클라이언트의 연결 스위치만 봐서는 앱이 프록시를 우회하는지, DNS 조회가 실패하는지, 원격 연결에 문제가 있는지 구분할 수 없습니다. 로그와 연결 기록은 구체적인 접속 시도와 함께 확인해야 설정 변경이 실제로 반영됐는지 판단하기 쉽습니다.
클라이언트는 인터페이스, 설정 관리, 시스템 연동을 담당하고 코어는 연결 처리를 담당합니다. 같은 설정이라도 플랫폼에 따라 트래픽을 처리하는 방식이 다를 수 있으므로 설치 전에 프로세서 아키텍처와 시스템 요구 사항을 확인하세요.
데스크톱 브라우저, 개발 도구, 일상 앱 사용에 적합합니다. 다운로드 페이지에는 Clash Plus, Clash Verge Rev 등의 클라이언트가 순서대로 정리되어 있어 인터페이스와 시스템 연동 방식을 비교할 수 있습니다.
설치 전에 시스템 정보에서 아키텍처를 확인하세요. 처음 사용할 때는 시스템 프록시를 켜고 브라우저 접속을 확인한 뒤, 다른 앱까지 처리해야 할 때 TUN을 고려하세요. 리스너를 열 수 없다는 오류가 나오면 먼저 포트 사용 여부를 확인하고, 같은 포트를 쓰는 코어를 여러 개 동시에 실행하지 마세요.
다운로드 페이지로 이동먼저 Apple Silicon과 Intel 프로세서를 구분한 다음 알맞은 설치 파일을 선택하세요. Clash Plus, Clash Verge Rev 등은 설정 위치가 서로 다르므로 설정을 가져온 뒤 규칙과 프록시 그룹이 올바른지도 확인해야 합니다.
시스템 프록시, 백그라운드 서비스, 네트워크 확장은 서로 다른 계층의 기능입니다. 권한 요청이 표시되면 방금 설치한 클라이언트에서 보낸 요청인지 확인한 후 시스템 안내에 따라 허용하세요. 클라이언트를 바꾸기 전에 기존 프로그램을 종료해 이전 프록시 설정이 연결 확인을 방해하지 않도록 하세요.
다운로드 페이지로 이동기기 아키텍처에 맞는 설치 파일을 선택하고, 설치 후 호환되는 설정을 가져온 다음 시스템의 VPN 연결 권한을 허용하세요. 모바일 기기는 보통 VPN 인터페이스로 트래픽을 처리하므로 시스템 프록시만 설정하는 데스크톱 방식과 다릅니다.
Wi-Fi와 모바일 데이터 환경에서 모두 테스트하세요. 네트워크를 전환한 뒤 문제가 생기면 DNS 조회와 출구 연결을 다시 확인하고, 백그라운드 연결이 자주 끊기면 배터리 최적화와 백그라운드 실행 제한을 살펴보세요. 앱별 분기와 도메인 규칙도 각각 점검해야 합니다.
다운로드 페이지로 이동다운로드 페이지에서 Clash Plus의 App Store 링크와 공식 사이트 clashplus.io를 확인할 수 있습니다. 설치 후 클라이언트가 지원하는 방식으로 설정을 가져온 다음 시스템 연결 권한을 허용하세요.
이름이 비슷한 클라이언트라도 설정 기능이 완전히 같지는 않습니다. 가져오기 전에 지원 프로토콜과 설정 항목을 확인하고, 연결한 뒤에는 프록시 선택과 실제 접속 결과를 점검하세요. 다른 VPN 설정이 이미 있다면 현재 어떤 연결이 활성화되어 있는지 먼저 확인해 시스템 상태를 코어 상태로 오해하지 않도록 하세요.
다운로드 페이지로 이동데스크톱 사용자는 Clash Verge Rev와 FlClash를 비교해 볼 수 있습니다. 서버, 라우터에서 사용하거나 서비스를 직접 관리하려면 다운로드 페이지에서 mihomo 코어를 확인하세요. 패키지 형식, 프로세서 아키텍처, 데스크톱 실행에 필요한 구성 요소를 각각 확인해야 하며, 파일명에 Linux가 포함됐는지만으로 판단해서는 안 됩니다.
명령줄에서 코어를 실행해도 브라우저가 해당 리스너 포트를 자동으로 사용하지는 않습니다. 용도에 따라 앱, 데스크톱 프록시 설정 또는 환경 변수에서 접속 지점을 지정하고 TUN 설정 여부를 결정하세요. 시스템 서비스로 실행할 때는 실행 사용자, 설정 파일 경로, 작업 디렉터리, 로그 출력 위치도 확인해야 합니다. 대화형 터미널에서는 작동하지만 서비스가 시작되지 않는 문제를 예방할 수 있습니다.
다운로드 페이지로 이동먼저 확인 가능한 기본 연결을 구성한 뒤 자동 속도 측정, 설정 덮어쓰기, TUN을 추가하세요. 한 번에 변수 하나만 바꾸고 이전 상태로 복구할 수 있는 설정 사본을 보관하세요.
STEP 01
클라이언트의 설정 또는 구독 페이지에서 링크를 추가하거나 로컬 YAML 파일을 가져오세요. 다운로드가 끝나면 프록시 그룹과 규칙이 표시되는지 확인한 다음 해당 설정을 현재 설정으로 지정하세요. 목록에 추가하는 것만으로 설정이 적용되는 것은 아닙니다.
구독 링크에는 접근 인증 정보가 포함될 수 있으므로 신뢰할 수 있는 곳에 보관하세요. 가져오기 오류가 나면 오류가 발생한 줄과 항목 이름을 확인하고, 링크가 설정 내용이 아니라 로그인 페이지를 반환하는 것은 아닌지 점검하세요. 전체 링크를 공개 게시판에 올리지 마세요.
STEP 02
일상적인 사용은 규칙 모드로 시작하고 주요 프록시 그룹에서 사용할 수 있는 출구를 선택하세요. 글로벌 모드는 일시적인 비교에 활용할 수 있지만, 분기 방식만 바꿀 뿐 잘못된 DNS 설정이나 코어에 전달되지 않는 앱 트래픽을 해결하지는 못합니다.
먼저 코어가 실행 중인지 확인한 다음 플랫폼에 맞게 시스템 프록시나 연결 스위치를 켜세요. 데스크톱에서는 시스템 프록시와 TUN을 따로 테스트할 수 있습니다. 기본 접속이 가능한지 확인하기 전에는 모든 트래픽 처리 옵션을 한꺼번에 켤 필요가 없습니다.
STEP 03
확인할 웹사이트를 열고 연결 페이지에서 적용된 규칙, 프록시 그룹, 출구를 확인하세요. 이어서 직접 연결되어야 하는 대상도 테스트해 두 경로 모두 설정대로 작동하는지 살펴보세요. 스위치 색상만 보고 성공 여부를 판단하지 마세요.
접속에 실패하면 발생 시간과 사용한 앱을 기록하고 시스템 프록시, 모드, 출구, DNS, 방화벽을 차례로 확인하세요. 클라이언트를 종료한 뒤 시스템 프록시가 정상적으로 복구됐는지도 점검해야 합니다. 남아 있는 설정 때문에 네트워크가 끊긴 것을 회선 문제로 오해할 수 있습니다.
전체 가이드 보기 →가져오기부터 연결 확인까지의 단계는 사용 가이드에서 확인하세요.
클라이언트가 기기에 적합한지 판단할 때는 코어 기능, 클라이언트 연동, 릴리스 정보를 각각 확인하세요. 오픈소스 라이선스는 코드 사용 조건을 설명할 뿐 설정이나 실행 권한까지 검증해 주지는 않습니다.
Clash는 이 프록시 설정 생태계의 주요 기반입니다. Clash Meta는 관련 포크에서 사용했던 이름이며, mihomo는 현재 해당 포크에서 사용하는 코어 이름입니다. 따라서 예전 가이드의 Clash Meta와 현재 문서의 mihomo는 기술적으로 이어지는 경우가 많지만, 모든 이전 설정 항목의 의미가 그대로 유지된다고 단정할 수는 없습니다. 예전 설정을 살펴볼 때는 현재 코어 문서를 확인하고, 특히 DNS, TUN, 프로바이더 관련 옵션을 주의 깊게 살펴보세요.
이름에 Clash가 들어간 소프트웨어라고 해서 모두 같은 코어를 사용하는 것은 아닙니다. 클라이언트에 특정 코어 빌드가 고정되어 있을 수도 있고, 사용자가 코어를 바꿀 수 있는 경우도 있습니다. 설정 항목이 지원되지 않거나 프로토콜을 인식하지 못하거나 가져오기 결과가 다르면, 먼저 클라이언트가 실제로 불러온 코어 정보를 확인하세요. 그런 다음 구문 오류인지, 기능 차이인지, 클라이언트의 설정 변환 문제인지 판단하면 됩니다. 이 사이트는 클라이언트 다운로드와 설정 자료를 제공하며, 각 클라이언트나 코어의 개발 프로젝트는 아닙니다.
그래픽 클라이언트는 보통 구독 업데이트, 시스템 프록시 전환, 서비스 설치, 연결 상태 표시를 담당합니다. mihomo 코어는 최종 설정을 받아 네트워크 처리를 수행합니다. 클라이언트 화면의 스위치는 설정 항목을 생성하거나 실행 중 제어 명령을 보내는 기능일 수도 있고, 단순한 UI 옵션일 수도 있습니다. 복잡한 문제를 해결할 때는 처음 받은 구독 파일만 확인하지 말고 실제 적용된 설정을 살펴보세요.
로컬 오버라이드로 개인 규칙을 유지할 수 있지만 설정 병합 우선순위를 이해해야 합니다. 구독 파일을 직접 수정하면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 같은 항목을 구독, 오버라이드, UI 설정에 모두 지정하면 어떤 설정이 적용됐는지 파악하기도 어렵습니다. 구독은 출구를 관리하고 로컬 오버라이드는 필요한 개인 설정만 관리하도록 나눈 뒤, 업데이트할 때마다 핵심 규칙을 확인하는 편이 안전합니다.
클라이언트와 코어가 항상 함께 업데이트되는 것은 아닙니다. 업데이트 전에 릴리스 안내를 읽고 설정 마이그레이션, 시스템 권한, 네트워크 스택 변경 여부를 확인하세요. 현재 환경이 안정적으로 작동한다면 설정과 오버라이드 파일을 백업한 뒤 한 번에 하나씩 업데이트하는 편이 좋습니다. 업데이트 후에는 리스너 포트, DNS 처리, 규칙 적용, TUN 라우팅을 다시 확인하고, 의미가 바뀐 이전 설정 항목이 있는지 특히 살펴보세요.
커뮤니티에 문제를 신고할 때는 운영체제, 클라이언트 이름, 코어 정보, 재현 단계, 민감 정보를 가린 로그를 함께 제공하세요. 구독 주소의 인증 정보, 프록시 비밀번호, 개인 도메인은 삭제하되 관련 설정 항목의 계층 구조와 오류 전후 맥락은 유지하세요. 최소 설정으로 재현할 수 있는 문제라면 코어 동작과 클라이언트 래퍼의 영향을 구분하기 쉽고, 다른 사용자도 문제 해결 과정을 참고할 수 있습니다.
설정 가이드의 예시는 일부 동작만 설명합니다. 규칙 대상, 프로바이더 이름, 파일 경로, 리스너 주소는 실제 환경에 맞춰야 합니다. 여러 출처의 예시를 합칠 때는 최상위 키가 중복되는지 먼저 확인하고 참조 경로가 모두 연결되는지 점검하세요. 새 규칙을 추가한 뒤 변경 내용을 기록해 두세요. 문제가 생기면 검증된 설정으로 되돌리는 편이 설정 전체를 한꺼번에 바꾸는 것보다 원인을 찾기 쉽습니다.
포트, 기기 간 동기화, 연결 문제를 중심으로 반복해서 따라 할 수 있는 확인 방법을 정리합니다. 글은 게시일 역순으로 표시되며, 설정 안내는 사용 중인 클라이언트의 실제 화면에 맞춰 참고하세요.
시스템 프록시, 모드와 규칙, 노드 상태, DNS 조회, TUN, 방화벽 순으로 확인해 프록시에 연결됐는데 인터넷을 사용할 수 없는 원인을 찾아보세요.
글 읽기 →구독 링크로 설정 배포, 클라우드 드라이브로 설정 폴더 동기화, 로컬 오버라이드 파일 사용의 세 가지 방식을 비교하고 데스크톱과 모바일에 적합한 동기화 방법 및 주의 사항을 설명합니다.
글 읽기 →운영체제 기본 명령으로 7890 등의 포트를 사용하는 프로세스를 찾은 다음, 설정 파일과 클라이언트에서 mixed-port를 각각 변경하고 시스템 프록시 설정도 함께 업데이트하세요.
글 읽기 →