01 / CORE & CLIENT
커널과 클라이언트
인터페이스는 관리하고 커널은 실행합니다. 먼저 두 계층을 구분한 뒤, 기능 지원 여부와 설정이 적용되는 위치를 확인하세요.
- mihomomihomo core
- Clash Meta에서 파생된 프록시 커널로, 프로토콜 연결, DNS 처리, 규칙 매칭을 담당하며 여러 Clash 생태계 클라이언트에서 실행 구성 요소로 사용됩니다. 클라이언트 이름에 mihomo가 포함되지 않을 수도 있으므로 설정이나 커널 정보에서 실제 사용 중인 커널을 확인하세요. 새 프로토콜과 필드의 지원 여부는 현재 커널 버전과 해당 문서를 기준으로 확인해야 하며, 설치 파일 이름만으로 판단해서는 안 됩니다.
- Clash MetaClash Meta
- Clash 생태계에서 커널 기능을 확장하던 프로젝트의 옛 이름으로, 이후 사용된 mihomo라는 이름과 계보상 관계가 있습니다. 오래된 가이드, 구독 분류, 일부 앱 이름에는 여전히 Meta라는 표현이 남아 있습니다. Meta용이라는 안내가 있어도 모든 Clash 클라이언트에서 쓸 수 있다고 단정하지 말고, 해당 필드와 프로토콜 매개변수, 커널 버전을 확인하세요.
- 클라이언트Client
- 사용자가 직접 조작하는 애플리케이션으로, 구독 관리, 노드 선택, 연결 확인, 시스템 설정 등의 인터페이스를 제공합니다. Clash Verge Rev는 이 계층에 속하며, 일반적으로 제어 인터페이스를 통해 커널을 관리합니다. 같은 커널을 사용하는 클라이언트라도 설정 병합, 권한 관리, 로그 표시 방식은 다를 수 있으므로 가이드의 버튼 위치를 실제 인터페이스와 비교하세요.
- 커널Core
- 실행 설정을 읽고 연결을 수립하는 소프트웨어 구성 요소로, 수신 포트, DNS 처리, 라우팅 규칙 실행을 담당합니다. 클라이언트를 업데이트하면 커널도 함께 업데이트될 수도 있고, 별도의 커널 업데이트 메뉴가 유지될 수도 있습니다. 호환성 문제를 진단할 때는 클라이언트 버전, 커널 버전, 오류가 난 필드를 함께 기록하세요. 커널 계보는 프로토콜 가이드에서 확인할 수 있습니다.
02 / PROTOCOLS
프록시 프로토콜
프로토콜은 클라이언트와 서버의 통신 방식을 정합니다. 노드 매개변수는 서버 측 설정과 일치해야 하며, 유형 이름을 바꾼다고 다른 프로토콜로 전환되지는 않습니다.
- ShadowsocksSS
- 공유 키와 지정된 암호화 방식을 사용해 프록시 연결을 설정하는 프로토콜입니다. 노드에는 보통 서버 주소, 포트, 비밀번호, 암호화 방식이 포함됩니다. 클라이언트는 노드가 사용하는 암호화 방식과 선택적 플러그인을 모두 지원해야 합니다. 가져온 뒤 인증 또는 핸드셰이크 오류가 발생하면 먼저 해당 매개변수를 확인하세요. 이름이 비슷한 암호화 방식도 서로 바꿔 쓸 수 있는 것은 아닙니다.
- VMess와 VLESSVMess / VLESS
- V2Ray 및 Xray 생태계에서 흔히 사용하는 서로 다른 두 프로토콜로, 설정에는 보통 사용자 식별자, 전송 방식, 보안 계층 옵션도 포함됩니다. VLESS 자체는 페이로드를 암호화하지 않으며, 실제 보안 수준은 TLS 등 외부 계층 설정에 따라 달라집니다. 연결 문제를 진단할 때는 프로토콜 유형뿐 아니라 WebSocket 경로, 서비스 이름, 기타 전송 매개변수도 확인해야 합니다. 서버 주소만 확인해서는 충분하지 않습니다.
- TrojanTrojan over TLS
- 보통 TLS로 전송을 보호하고 비밀번호로 인증하는 프록시 프로토콜입니다. 인증서 검증은 연결 과정에서 중요한 역할을 합니다. 서버 이름은 TLS 핸드셰이크의 SNI와 인증서 검증에 사용되며, 입력한 연결 주소와 다를 수 있습니다. 인증서 오류가 발생하면 인증서 검증을 건너뛰는 방식으로 해결하려 하지 말고 시스템 시간, 서버 이름, 서버 인증서를 확인하세요.
- Hysteria2와 TUICQUIC 기반 프록시 프로토콜
- QUIC 기반의 두 프록시 프로토콜로, 일반적으로 UDP를 통해 데이터를 전송하지만 인증 매개변수와 혼잡 제어 등의 설계는 서로 다릅니다. 네트워크의 UDP 제한, 서버 설정 불일치, 경로 품질 변화가 사용 가능성에 영향을 줄 수 있습니다. 프로토콜 이름만으로 속도나 모바일 기기의 배터리 소모를 판단하지 말고, 같은 기기와 비슷한 네트워크에서 동일한 작업으로 실제 성능을 비교하세요.
03 / RULES & ROUTING
규칙과 라우팅
규칙은 연결을 어떤 출구로 보낼지 결정합니다. 규칙을 확인할 때는 매칭 조건뿐 아니라 순서와 참조하는 정책 이름도 살펴보세요.
- 규칙 기반 라우팅Rule-based Routing
- 설정 순서에 따라 도메인이나 주소 등의 조건을 매칭한 뒤 연결을 직접 연결, 프록시 그룹 또는 차단 정책으로 보냅니다. 일반적으로 위에서 아래 순서로 확인하며, 먼저 일치한 규칙이 이후 처리를 결정합니다. 따라서 너무 포괄적인 규칙을 앞에 두면 뒤의 세부 규칙이 적용되지 않을 수 있습니다. 클라이언트의 규칙 화면에서 규칙을 확인하고 연결 화면에서 실제로 적용된 결과를 살펴보면 규칙 파일만 보는 것보다 문제를 찾기 쉽습니다.
- GeoIPIP-based Classification
- 주소 데이터베이스를 사용해 지역이나 주소 유형별로 대상 IP를 매칭하는 방식입니다. 예를 들어
GEOIP,private,DIRECT,no-resolve는 사설 주소를 매칭하는 데 사용할 수 있습니다. 매칭 결과는 데이터베이스 내용에 따라 달라지며 서버의 물리적 위치를 실시간으로 증명하지는 않습니다.no-resolve는 규칙 매칭을 위해 도메인을 별도로 조회하지 않도록 하지만, 연결에 대상 IP가 이미 있는 경우에는 매칭에 사용될 수 있습니다.
- GeoSiteDomain-based Classification
- 데이터베이스에 등록된 도메인 목록과 매칭하는 방식으로, 같은 서비스나 분류의 도메인을 하나의 규칙으로 묶을 때 자주 사용합니다. 예를 들어
GEOSITE,cn,DIRECT와 같습니다. 분류 이름은 현재 불러온 데이터 파일에 있어야 하며, 데이터 출처에 따라 목록 내용이 달라질 수 있습니다. 이 방식은 도메인 목록을 기준으로 하고 GeoIP는 대상 주소를 기준으로 하므로 서로 대체할 수 없습니다.
- MATCH와 내장 정책MATCH / DIRECT / REJECT
MATCH는 앞선 규칙에 해당하지 않은 연결을 처리하는 최종 매칭 유형으로, 보통 규칙 맨 끝에 둡니다.DIRECT는 직접 연결,REJECT는 연결 거부를 뜻하는 내장 정책입니다. 예시의PROXY는 일반적으로 설정 작성자가 지정한 프록시 그룹 이름입니다. 설정에 같은 이름의 정의가 있어야 하며, 고정된 내장 키워드로 취급해서는 안 됩니다.
04 / GROUPS & NODES
프록시 그룹과 노드
노드는 서버에 연결하는 방식을 나타내고, 프록시 그룹은 출구를 선택하는 방식을 나타냅니다. 인터페이스에서 현재 선택한 그룹과 노드는 규칙의 참조 관계와 함께 살펴봐야 합니다.
- 프록시 그룹Proxy Group
- 여러 노드나 다른 프록시 그룹을 묶어 규칙에서 참조할 출구 이름으로 사용합니다.
select는 수동 선택,url-test는 테스트 결과에 따른 선택,fallback은 사용 가능 여부와 순서에 따른 전환,load-balance는 알고리즘에 따른 연결 분산에 사용됩니다. 프록시 화면에서 그룹을 변경해도 실제로 해당 그룹을 참조하는 트래픽에만 영향을 줍니다. 그룹끼리 중첩되어 있을 수도 있습니다.
- 노드Proxy Node
- 프록시 서버 연결 방식을 정의하는 매개변수 모음으로, 보통 프로토콜, 서버 주소, 포트, 인증 정보를 포함합니다. 노드 표시 이름은 단순한 라벨이므로 이름만으로 출구 위치, 성능, 사용 가능 여부를 판단할 수 없습니다. 오류를 공유할 때 프로토콜 유형과 오류 메시지는 남겨도 되지만 비밀번호, 사용자 식별자, 전체 구독 주소 등 민감한 정보는 가려야 합니다.
- 지연 시간 테스트Latency Test
- 지정한 테스트 주소에 요청을 보내 응답 시간을 측정해 프록시 경로의 반응성을 추정합니다. 일반적으로 시스템 명령의 ICMP ping과는 다릅니다. 테스트 사이트, 연결 재사용, 핸드셰이크 과정, 네트워크 상태에 따라 결과가 달라지며 다운로드 속도를 나타내지는 않습니다. 시간 초과가 표시되어도 노드를 사용할 수 없는 경우뿐 아니라 테스트 대상에 접근하지 못한 경우일 수 있으므로 실제 서비스와 연결 로그를 함께 확인하세요.
- url-testAutomatic Test Group
- 주기적인 테스트 결과에 따라 노드를 자동 선택하는 프록시 그룹 유형으로, 수동 전환을 줄이고 싶을 때 유용합니다.
interval은 테스트 간격을 설정하고tolerance는 응답 시간의 작은 변동으로 노드가 자주 바뀌는 것을 줄여 줍니다. 테스트 대상은 실제 사용 환경을 잘 반영해야 합니다. 테스트 응답이 빠르다고 모든 서비스가 더 빨라지는 것은 아니며, 정책이 바뀌어도 이미 연결된 세션이 즉시 이동하지 않을 수 있습니다.
05 / SUBSCRIPTIONS & CONFIG
구독과 설정 파일
구독은 설정을 가져오는 방법이고, 설정 파일은 커널이 읽는 구조입니다. 가져오기, 선택, 덮어쓰기, 실행은 각각 별개의 단계입니다.
- 구독Subscription
- 주소를 통해 프록시 노드나 전체 설정을 받아오는 배포 방식이며, 제공 업체에 따라 반환하는 형식이 다를 수 있습니다. 설정 페이지에서 가져온 뒤에는 해당 설정을 선택하고 프록시 페이지에서 프록시 그룹을 확인해야 합니다. 구독 주소에는 접근 인증 정보가 포함될 수 있으므로 공개된 곳에 그대로 붙여 넣지 마세요. 업데이트에 실패하면 계속 버튼을 누르기보다 먼저 주소가 유효한지와 어떤 내용이 반환되는지 확인하세요.
- YAMLYAML Configuration Format
- Clash 설정에 널리 쓰이는 구조화 텍스트 형식으로, 들여쓰기로 계층을 표현하고 목록과 키-값으로 설정을 구성합니다. 들여쓰기에는 탭 대신 공백을 사용하고, 특수 문자가 포함된 문자열은 따옴표 규칙에 유의하세요. 문법 분석에 성공했다는 것은 기본 구조가 성립한다는 뜻일 뿐, 현재 커널이 필드를 지원하거나 노드 매개변수와 규칙 참조가 올바르다는 뜻은 아닙니다.
- 설정 파일Profile / config.yaml
- 노드, 프록시 그룹, 규칙, DNS, 수신 포트 등의 설정을 담는 파일로, 구독에서 내려받거나 로컬 파일을 가져올 수 있습니다. 설정 페이지에 저장된 원본 파일이 커널에서 실제로 읽는 전체 내용과 같지 않을 수 있습니다. 클라이언트가 전역 설정이나 덮어쓰기 규칙을 추가할 수 있기 때문입니다. 파일을 수정했는데 동작이 바뀌지 않는다면 현재 선택한 설정, 다시 불러온 결과, 실제 실행 설정을 확인하세요.
- 덮어쓰기와 병합Override / Merge
- 원본 구독 설정에 로컬 설정을 추가하는 방식으로, 개인 포트, DNS, 사용자 지정 규칙을 유지해 구독 업데이트 후 반복해서 수정할 필요를 줄여 줍니다. 필드를 교체할지 병합할지, 배열을 어떻게 처리할지, 여러 변경 사항을 어떤 순서로 적용할지는 클라이언트 구현에 따라 다릅니다. 수정 전에 백업하고 다시 불러온 뒤 최종 설정을 확인해 같은 설정이 다른 계층에서 덮어쓰이지 않도록 하세요.
06 / NETWORK & SYSTEM
네트워크와 시스템 설정
트래픽 처리, 이름 확인, 출구 선택은 서로 다른 단계입니다. 스위치를 켰다고 조회와 연결이 모두 예상대로 처리되는 것은 아닙니다.
- 시스템 프록시System Proxy
- 운영체제의 프록시 설정을 클라이언트의 로컬 수신 주소로 지정해, 해당 설정을 따르는 앱의 요청을 프록시 포트로 보냅니다. 시스템 프록시를 무시하는 프로그램은 처리하지 못하며, 명령줄 도구의 환경 변수도 자동으로 설정하지 않습니다. 켠 뒤에는 연결 페이지에서 대상 앱의 요청이 표시되는지 확인하세요. 설정 순서는 시스템 프록시 설정 가이드를 참고하세요.
- TUN 모드TUN Mode
- 가상 네트워크 인터페이스와 라우팅 규칙을 통해 IP 패킷을 받아 처리합니다. 더 많은 앱의 트래픽을 관리해야 할 때 적합하며, 일반적으로 해당 시스템 권한이나 서비스가 필요합니다. 라우팅, 인터페이스, DNS, 제외 설정에 따라 트래픽 처리가 달라집니다. TUN은 트래픽이 커널로 들어오는 방식을 설명할 뿐, 들어온 뒤에는 규칙에 따라 직접 연결 또는 프록시가 결정됩니다. 전역 프록시 모드와 같은 뜻은 아닙니다.
- DNSDomain Name System
- 도메인을 IP 주소 등의 레코드로 변환하는 조회 시스템입니다. 도메인이 올바르게 해석되는지는 연결 설정과 일부 규칙 매칭에도 영향을 줍니다. 클라이언트 DNS, 시스템 DNS, 앱 자체의 암호화 DNS가 함께 작동하며 각각 다른 조회를 처리할 수 있습니다. 문제를 진단할 때는 대상 도메인, 프록시 서버 도메인, DNS 서버 자체의 연결 경로를 구분하세요. 한 곳만 바꾸고 전체 결과가 달라졌다고 오해하지 않도록 주의해야 합니다.
- Fake-IPSynthetic IP Mapping
- 프록시 DNS가 가상 주소를 반환하고 커널 내부에 주소와 도메인의 매핑을 저장하는 방식으로, 이후 연결을 원래 도메인에 따라 라우팅하는 데 도움이 됩니다. 조회 결과에 가상 주소가 표시된다고 해서 실제 웹사이트가 그 주소를 사용하는 것은 아니며, 그것만으로 DNS 조회 실패를 의미하지도 않습니다. 일부 앱은 필터 설정을 통해 실제 주소 조회로 전환해야 할 수 있습니다. 설정을 바꾼 뒤에는 기존 DNS 캐시와 연결도 확인하세요.
- DNS 유출DNS Leak
- DNS 조회가 예상한 경로를 벗어나는 현상입니다. 예를 들어 지정한 DNS 서버에서 처리할 예정이던 조회가 시스템이나 앱의 다른 경로로 전송될 수 있습니다. 판단하기 전에 먼저 설정 의도를 확인하세요. 직접 연결을 통한 조회 자체가 항상 문제인 것은 아닙니다. 테스트 페이지에 표시된 DNS 서버의 지역만으로 유출을 단정할 수는 없으며, 앱의 이름 확인 방식, 클라이언트 로그, 실제 DNS 설정을 함께 확인해야 합니다. 자세한 내용은 DNS 자주 묻는 질문을 참고하세요.
- UWP 루프백UWP Loopback
- 일부 Windows 앱 컨테이너가 로컬 루프백 주소에 접근할 때 적용되는 네트워크 격리 제한입니다. 로컬 프록시에서 자주 쓰는
127.0.0.1도 루프백 주소입니다. 루프백 예외를 설정하면 지정한 앱이 로컬 서비스에 접근할 수 있지만, 노드를 자동으로 선택하거나 앱의 프록시 동작을 바꾸지는 않습니다. 특정 스토어 앱만 연결되지 않는다면 모든 네트워크 설정을 초기화하기 전에 UWP 루프백 문제 해결을 확인하세요.