아래는 설정 일부이며, 그대로 연결할 수 있는 완성된 설정이 아닙니다. 구독 주소는 실제 서비스 제공업체에서 받아야 합니다. 프록시 목록은 정책 그룹에서 참조하고, 규칙에서 사용할 정책을 지정해야 합니다. 설정을 업데이트하기 전에 로컬에서 수정한 내용을 보관하세요.
규칙 매칭 순서
rules · PROXY는 정의된 정책 그룹입니다
DOMAIN-SUFFIX,example.org,DIRECTDIRECT
DOMAIN-KEYWORD,ads,REJECTREJECT
GEOIP,LAN,DIRECTDIRECT
MATCH,PROXYPROXY
규칙은 동시에 적용되는 것이 아니라 순서대로 매칭됩니다. 일반적으로 구체적인 조건을 앞에 두고, 나머지 트래픽을 처리하는 MATCH는 맨 끝에 배치합니다. 여기서 PROXY는 정책 그룹 이름이므로 전체 설정에 정의되어 있어야 하며, 이름이 정확히 일치해야 합니다.
TUN 가상 네트워크 인터페이스: 더 많은 앱의 연결 처리
TUN은 가상 네트워크 인터페이스와 라우팅 설정을 이용해 대상 트래픽을 코어로 전달합니다. 시스템 프록시를 따르지 않는 명령줄 도구나 일부 앱에 적합합니다. 활성화하기 전에 구독을 가져오고 기본 연결을 테스트한 다음, 클라이언트 안내에 따라 서비스를 설치하거나 권한을 부여하세요. 시스템 프록시와 다른 점은 트래픽 처리 경로이며, 노드 품질과는 관계가 없습니다. UDP 처리 여부는 노드와 프로토콜에 따라 달라집니다. 다른 VPN, 가상 머신 또는 사용자 지정 라우팅을 사용하는 경우 경로와 DNS 설정을 확인해 트래픽이 중복 처리되지 않도록 하세요.
규칙 모드에서는 도메인이나 대상 주소 등의 조건에 따라 연결 경로를 정합니다. 구체적인 조건을 포괄적인 조건보다 앞에 두고, MATCH로 나머지 연결을 처리합니다. 사용할 노드는 정책 그룹에서 선택합니다. 설정을 바꾼 뒤에는 문법과 그룹 이름을 확인하고, 새 연결을 만들어 매칭 기록을 살펴보세요. 전역 모드와 달리 규칙 모드에서는 로컬 서비스, 자주 방문하는 사이트, 기타 요청을 각각 처리할 수 있지만 규칙 순서를 관리해야 합니다. 구독 업데이트로 직접 수정한 내용이 덮어써질 수 있으므로, 장기적으로 유지할 규칙은 클라이언트에서 지원하는 오버라이드 또는 병합 설정에 넣으세요.
Fake-IP는 도메인에 가상 IP 주소를 반환합니다. 코어는 매핑 정보를 이용해 이후 연결에서 도메인 정보를 복원하고 도메인 규칙을 적용합니다. Fake-IP는 원격 노드가 아니며 암호화 DNS와도 다릅니다. 사용하려면 DNS 요청이 의도한 경로로 전달되는지, 가상 IP 주소 범위가 LAN과 겹치지 않는지 확인하세요. 실제 주소가 필요한 일부 앱은 DNS 기능을 전체적으로 끄기보다 필요에 따라 필터 목록에 추가할 수 있습니다. 실제 주소를 반환하는 방식과의 주요 차이는 도메인 정보의 유지 여부와 연결 처리 순서입니다.
전체 설정 구독에는 노드, 정책 그룹, 규칙이 포함될 수 있습니다. 프록시 목록 구독은 일반적으로 노드 항목만 제공하므로 기본 설정에서 참조해야 합니다. 클라이언트의 예약 업데이트와 코어의 proxy-providers 업데이트는 서로 다른 계층의 기능이므로 문제를 확인할 때 각각 살펴보세요. 가져온 뒤 먼저 수동으로 업데이트해 항목을 읽을 수 있는지, 그룹에서 노드를 선택할 수 있는지 확인한 다음 업데이트 주기를 설정하세요. 로컬 정적 설정보다 구독은 서버 측 변경 사항을 쉽게 반영하지만, 원격 내용이 로컬 수정 사항을 덮어쓸 수 있으므로 오버라이드 설정을 미리 보관하세요.
그래픽 클라이언트는 UI, 권한, 설정 관리를 담당하고 코어는 프로토콜 연결, 규칙 매칭, DNS를 처리합니다. 일부 클라이언트는 코어를 바꿀 수 있지만, 다른 클라이언트는 특정 구현이 고정되어 있습니다. UI에 표시된 이름만으로 기능을 판단하지 마세요. 원본 Clash, Clash Meta, mihomo는 역사적으로 이어져 있지만 확장 프로토콜과 설정 필드가 완전히 호환되는 것은 아닙니다. 이전하기 전에 노드 유형, 전송 옵션, 규칙 프로바이더 문법을 확인하고 설정을 불러와 테스트하세요. 파일을 가져올 수 있다고 해서 모든 필드가 실제로 지원되는 것은 아닙니다.
연결 문제는 일정한 순서로 확인하세요. 설정이 로드되었는지, 정책 그룹에 노드가 있는지, 트래픽이 코어로 들어오는지, 규칙이 예상한 대상을 매칭하는지 살펴봅니다. 한 번에 설정 하나만 변경하고 같은 요청으로 다시 테스트하세요. 구독 내용, 시스템 프록시 설정, 노드 연결 문제를 구분할 수 있어 모드와 DNS를 동시에 바꿔 원인을 놓치는 일을 막을 수 있습니다.
프로토콜 이름은 클라이언트와 서버 사이의 연결 방식을 나타낼 뿐, 모든 앱의 동작을 직접 결정하지는 않습니다. 서버 설정, 네트워크의 UDP 허용 여부, 인증서와 전송 옵션도 서로 맞아야 합니다. SS, VMess, Trojan, VLESS, Hysteria2, TUIC의 기능과 제약은 프로토콜 안내에서 확인하세요. 이름만 보고 선택하기보다 실제 네트워크와 기기 환경에 맞춰야 합니다.
클라이언트 선택
플랫폼별 다운로드 센터로 이동
다운로드 센터에서 운영체제별 클라이언트와 설치 안내를 확인할 수 있습니다. 데스크톱과 모바일은 권한 부여 방식이 다르며, 같은 구독도 클라이언트가 지원하는 형식에 맞춰 가져와야 할 수 있습니다.
먼저 ‘이 Mac에 관하여’에서 Apple Silicon 또는 Intel 칩을 확인한 다음 해당 설치 파일을 선택하세요. 네트워크 트래픽 처리를 활성화할 때는 시스템 안내에 따라 권한을 부여해야 합니다. 다운로드 센터에서 ClashX Meta 아카이브 링크와 유지 관리 상태도 확인할 수 있습니다.
Clash Plus, Clash Meta for Android, FlClash, Surfboard를 확인해 보세요. 기기 아키텍처에 맞는 설치 파일을 선택하고, 처음 연결할 때 VPN 연결 생성을 허용하세요. 화면을 잠근 뒤 연결이 끊기면 배터리 최적화와 백그라운드 실행 제한을 확인하세요.
그래픽 데스크톱 환경에서는 Clash Verge Rev 또는 FlClash를 선택하고 배포판에 맞는 패키지 형식을 사용하세요. 서버, 라우터 또는 직접 관리하는 서비스에서 사용하려면 mihomo 코어 섹션을 참고해 서비스 시작, 권한, 수신 대기 범위를 별도로 설정하세요.
클라이언트와 노드 서비스는 별개입니다. 설치 후에도 유효한 로컬 설정이나 구독이 필요하며, 화면의 연결 스위치를 켠다고 사용할 수 있는 노드가 자동으로 생기지는 않습니다. 기존 설정을 새 기기로 옮길 때는 먼저 원본 파일을 보관한 뒤 프로토콜과 필드의 호환성을 확인하세요. 모바일 기기는 보통 시스템 VPN 인터페이스로 트래픽을 처리하며, 데스크톱에서는 시스템 프록시와 TUN을 함께 제공하기도 합니다.
처음 설정할 때는 규칙 모드를 사용하고, 사용 가능한 노드를 하나 선택한 다음 대상 앱을 열어 연결 기록을 확인하는 것이 좋습니다. 지연 시간 테스트는 특정 테스트 요청의 결과일 뿐 실제 접속 여부를 대신하지 않습니다. 브라우저는 연결되는데 명령줄 도구는 직접 연결된다면, 먼저 해당 도구가 시스템 프록시를 읽는지 확인하세요. 그다음 프록시 환경 변수를 설정할지 TUN을 활성화할지 결정하면 됩니다.
프로젝트 소스 코드, 설정 문서, 실제 연결 로그를 바탕으로 안내합니다. 클라이언트 이름, 코어 기능, 구독 서비스는 서로 다른 계층이므로 각각 확인해야 합니다.
프로젝트의 역사와 명칭
원본 Clash는 규칙에 따라 연결 경로를 선택하는 설정 체계를 만들었습니다. Clash Meta는 이 생태계에서 프로토콜과 네트워크 처리 기능을 확장했으며, 이후 mihomo라는 이름으로 발전을 이어가고 있습니다. 이전 가이드에 나오는 Meta라는 명칭은 클라이언트 옵션, 설정 안내, 로그에 계속 표시될 수 있으므로 실제 구현을 함께 확인하세요. 공통된 역사가 있다고 해서 모든 설정을 그대로 서로 바꿔 사용할 수 있는 것은 아닙니다. 특히 확장 필드와 신규 프로토콜에 주의하세요.
클라이언트 UI와 연결 코어
Clash Verge Rev, FlClash 등의 그래픽 클라이언트는 구독 관리, 정책 선택, 시스템 프록시, 서비스 제어 기능을 제공합니다. 실제로 사용할 수 있는 기능은 통합된 코어에 따라 달라집니다. UI와 코어는 서로 다른 일정으로 업데이트될 수 있습니다. 특정 필드를 인식하지 못하면 앱 이름만으로 지원 여부를 판단하지 말고, 먼저 실행 중인 코어와 설정 로드 결과를 확인한 뒤 업그레이드가 필요한지 살펴보세요.
오픈소스 생태계와 문제 재현
mihomo 공개 저장소에서 소스 코드, 이슈 토론, 릴리스 기록을 확인해 설정 동작을 자세히 알아볼 수 있습니다. 이슈를 등록하기 전에 구독 주소, 노드 비밀번호, 개인 경로 등 민감한 정보를 삭제하고 재현에 필요한 필드만 남기세요. 보고서에는 운영체제, 클라이언트, 코어, 트래픽 처리 모드, 재현 단계를 적고 관련 오류 문맥을 첨부하세요. 정리되지 않은 로그 전체를 붙여 넣기보다 실패한 연결을 정확하게 설명하는 편이 문제를 찾는 데 도움이 됩니다.
업데이트 방식과 설정 보존
클라이언트 업데이트, 코어 업데이트, 구독 업데이트는 각각 UI 프로그램, 연결 구현, 원격 설정 내용을 변경합니다. 실행 전에 무엇을 업데이트할지 구분하고 정책 그룹 선택, 사용자 지정 규칙, 오버라이드 설정을 보관하세요. 업데이트 후에는 먼저 설정이 로드되는지 확인하고, DNS, 규칙 매칭, 실제 접속을 차례로 점검합니다. 문제가 다시 발생하면 재현 가능한 최소 설정을 보관하고 해당 릴리스 노트를 확인하세요. 원인을 파악하는 대신 연이어 재설치하지 마세요.
설정 기록
클라이언트 사용 및 연결 문제 해결 글
설정 순서에 따라 읽어 보세요. 먼저 플랫폼과 가져오기 방법을 정하고, 실제 연결을 확인한 다음 DNS와 규칙 문제를 해결합니다. 최근 글 3개를 소개합니다.
클라이언트 업데이트에 따라 글에서 안내하는 메뉴 위치가 달라질 수 있지만, 점검 방법은 그대로 활용할 수 있습니다. 앱 요청, 트래픽 처리, 규칙 매칭, 노드 연결을 나누어 확인하세요. 포트 충돌, 권한 부족, 설정 문법 오류가 발생하면 오류 정보를 먼저 보관한 다음 해당 단계를 다시 확인하세요. 기본적인 문제는 FAQ에서 확인하고, 전체 가져오기 과정은 사용 가이드에서, 프로토콜과 코어의 차이는 프로토콜 안내에서 살펴보세요.