클라이언트
Client일반적으로 클라이언트는 구독을 가져오고 정책을 전환하며 시스템 프록시를 관리하는 그래픽 앱을 가리킵니다. 실제 연결과 규칙 매칭은 앱 안에서 실행되는 코어가 담당하며, 같은 코어를 여러 인터페이스와 함께 사용할 수도 있습니다. 클라이언트를 선택할 때는 화면의 스위치 개수만 비교하지 말고 운영체제 지원, 권한 관리, 코어 호환성도 확인하세요.
설정 참고 자료 / 용어 색인
Clash 용어 정리
5개 범주로 클라이언트, 프록시 프로토콜, YAML 설정의 주요 용어를 살펴보세요. 트래픽이 코어에 들어오는 방식과 규칙이 아웃바운드를 선택하는 방식은 서로 다르므로, 문제를 해결할 때도 따로 확인해야 합니다.
각 용어 카드에는 개별 앵커가 있어 주소를 복사해 공유할 수 있습니다. 구체적인 필드 지원 여부는 사용 중인 클라이언트와 코어 버전, 최종 적용된 설정을 기준으로 확인하세요.
01 / 앱과 연결 정보
코어와 클라이언트
인터페이스는 조작을, 코어는 연결 처리를, 구독은 설정 제공을 담당합니다. 설정을 가져왔는데 접속할 수 없다면 먼저 문제가 어느 단계에서 발생하는지 확인하세요.
mihomo 코어
mihomo / Clash.Metamihomo는 Clash 생태계의 프록시 코어로, 연결 수신, DNS 조회, 규칙 매칭, 아웃바운드 연결을 담당합니다. Clash.Meta라는 이름으로 널리 사용된 적이 있습니다. 예전 튜토리얼의 Meta는 특정 그래픽 클라이언트가 아니라 이 코어 계열을 가리키는 경우가 많습니다. 설정을 확인할 때는 해당 필드가 현재 코어에서 지원되는지 살펴보세요. 인터페이스만 업데이트해도 코어까지 함께 업데이트되는 것은 아닙니다.
구독
Subscription구독은 보통 노드 목록이나 전체 설정을 가져오는 링크이며, 클라이언트는 필요할 때 또는 정해진 시간에 콘텐츠를 다시 가져올 수 있습니다. 링크마다 반환하는 데이터 형식이 다를 수 있으니 가져오기 전에 Clash 또는 사용 중인 클라이언트가 지원하는 형식인지 확인하세요. 구독 주소에는 계정 식별 정보나 액세스 토큰이 포함될 수 있으므로 공개 게시판에 올리지 않는 것이 좋습니다. 업데이트에 실패하면 먼저 구독 관련 문제를 확인하세요.
프록시 노드
Proxy node프록시 노드는 서버 주소, 포트, 프로토콜, 인증 정보, 선택적 전송 설정으로 이루어진 아웃바운드 연결 설정입니다. 노드 이름은 구분을 위한 라벨일 뿐이며, 이름에 적힌 지역이 실제 출구 위치나 서버 위치와 반드시 일치하지는 않습니다. 노드를 설정에 가져오면 선택 가능한 출구가 추가될 뿐입니다. 정책 그룹에서 해당 노드를 참조하고 앱의 트래픽이 코어에 들어오도록 설정해야 합니다.
지연 시간
Latency / URL test클라이언트의 지연 시간 테스트는 보통 노드를 통해 지정된 테스트 주소에 접속하는 데 걸린 시간을 측정합니다. 서버에 직접 ping을 보내는 방식과는 다를 수 있습니다. 테스트 주소와 제한 시간, 연결 재사용, 로컬 네트워크가 결과에 영향을 줍니다. 지연 시간이 짧다고 다운로드 속도가 빠른 것은 아니며 모든 웹사이트에 접속할 수 있다는 보장도 없습니다. 노드를 비교할 때는 동일한 조건으로 테스트하고 실제 사용 환경에서도 확인하세요.
02 / 연결 프로토콜
프록시 프로토콜
프로토콜은 클라이언트와 프록시 서버가 통신하는 방식을 정합니다. 지원 여부는 실제 사용하는 코어를 기준으로 확인해야 합니다. 프로토콜 이름을 설정해도 서버 매개변수와 일치하지 않으면 연결되지 않습니다.
HTTP 프록시
HTTP proxyHTTP 프록시는 HTTP 프록시 방식으로 요청을 전달하며, HTTPS 대상에 접속할 때는 보통 CONNECT로 터널을 만듭니다. 로컬 클라이언트는 브라우저나 명령줄 프로그램이 연결할 수 있도록 HTTP 프록시 리슨 포트를 제공하는 경우가 많습니다. 대상 웹사이트가 HTTPS를 사용하더라도 클라이언트와 프록시 서버 사이의 연결에 TLS가 적용된다는 뜻은 아닙니다. 두 구간의 암호화 여부를 따로 확인하세요.
SOCKS5
SOCKS version 5SOCKS5는 범용 프록시 프로토콜로, TCP 트래픽을 전달할 수 있으며 클라이언트와 서버 구현이 지원하면 UDP도 전달합니다. 프로토콜 자체에는 연결 암호화 기능이 없고, 사용자 이름과 비밀번호 인증도 전송 암호화를 의미하지 않습니다. 앱에서 SOCKS5를 사용할 때 도메인을 로컬에서 조회할지 프록시에서 조회할지는 앱과 매개변수에 따라 다릅니다. 프록시 주소만 보고 DNS 경로를 판단할 수는 없습니다.
Shadowsocks
Shadowsocks / SSShadowsocks는 암호화 프록시 프로토콜이며, 설정에는 보통 서버, 포트, 암호화 방식과 비밀번호가 포함됩니다. 암호화 방식과 추가 매개변수는 서버 설정과 일치해야 하며, 프로토콜 버전과 구현에 따라 지원 범위가 다를 수 있습니다. 인증 또는 핸드셰이크 오류가 발생하면 먼저 가져온 설정 내용과 코어 호환성을 확인하세요. 노드 표시 이름을 바꿔도 연결 매개변수는 바뀌지 않습니다.
Trojan
Trojan protocolTrojan은 보통 TLS로 프록시 연결을 보호합니다. 서버와 비밀번호뿐 아니라 인증서와 서버 이름 등의 매개변수도 올바르게 설정해야 합니다. 연결에 사용하는 주소와 인증서의 도메인은 다를 수 있지만, 서버 배포 방식에 맞아야 합니다. 인증서 오류가 발생하면 시스템 시간, 도메인, 인증서 체인을 먼저 확인하세요. 인증서 검증을 건너뛰는 방식은 장기적인 해결책으로 사용하지 않는 것이 좋습니다.
Hysteria 2
Hysteria 2 / HY2Hysteria 2는 QUIC 기반 프록시 프로토콜로 UDP를 사용하며, 클라이언트와 서버 모두 해당 프로토콜을 지원해야 합니다. 현재 네트워크에서 UDP가 차단되어 있다면 다른 TCP 노드가 연결된다고 해서 Hysteria 2도 사용할 수 있는 것은 아닙니다. 프로토콜 이름만으로 속도가 보장되지는 않습니다. 실제 성능은 회선, 혼잡 제어, 서버 자원에 따라 달라집니다. 설정 시 인증 정보와 TLS 설정을 확인하세요.
03 / 아웃바운드 선택
규칙과 라우팅
먼저 연결에 적용할 모드를 확인한 다음, 일치하는 규칙과 최종 정책을 살펴보세요. 노드는 연결되지만 예상과 다른 경로로 접속된다면 이 부분을 중점적으로 확인해야 합니다.
규칙 기반 라우팅
Rule-based routing규칙 기반 라우팅은 설정 순서에 따라 도메인, 대상 IP, 포트 등의 연결 정보를 확인하며, 처음 일치하는 규칙이 사용할 정책을 결정합니다. 구체적인 도메인 규칙은 보통 포괄적인 규칙보다 앞에 두고, 기본 규칙은 마지막에 둡니다. 규칙이 정책 그룹과 일치해도 실제 아웃바운드는 해당 그룹에서 다시 선택합니다. 따라서 로그를 확인할 때는 노드 이름만 보지 말고 일치한 규칙과 최종 아웃바운드를 함께 살펴보세요.
프록시 모드
Rule / Global / Direct규칙 모드는 규칙에 따라 정책을 선택하고, 전역 모드는 보통 수신된 연결을 전역 정책으로 전달하며, 직접 연결 모드는 프록시를 거치지 않고 처리합니다. 이 모드들은 트래픽이 코어에 들어온 뒤의 아웃바운드 방식을 정할 뿐, 모든 앱이 자동으로 코어를 거치게 하지는 않습니다. 전역 모드로 바꿔도 접속할 수 없다면 시스템 프록시나 TUN이 제대로 적용되는지 확인하세요. 설정 방법은 프록시 모드 설정을 참고하세요.
정책 그룹
Proxy group정책 그룹은 여러 노드나 다른 정책을 하나의 참조 가능한 아웃바운드 대상으로 묶습니다. 대표적인 유형으로 수동 선택을 위한 select, 테스트 결과에 따라 선택하는 url-test, 사용 가능 여부에 따라 전환하는 fallback이 있습니다. 자동 테스트 결과가 실제 서비스 접속 성능을 보장하지는 않습니다. 규칙에서 정책 그룹을 참조한다면 이름을 정확히 일치시켜야 합니다.
GeoIP
IP geolocationGeoIP는 IP 지리 정보 데이터베이스를 이용해 규칙을 매칭합니다. 예를 들어 GEOIP,CN,DIRECT는 해당 지역으로 분류된 대상에 직접 연결 정책을 적용합니다. 결과는 데이터베이스와 실제 대상 IP에 따라 달라지며, 웹사이트 운영 주체나 콘텐츠가 속한 지역을 뜻하지는 않습니다. CDN과 공유 인프라로 인해 지역 판정이 달라질 수 있습니다. 웹사이트별 접속 경로를 정밀하게 제어하려면 보통 도메인 규칙을 우선 고려하세요.
MATCH 기본 규칙
Final matching ruleMATCH는 앞선 규칙에 일치하지 않은 연결을 처리하며, 보통 rules 목록의 마지막에 둡니다. 예를 들어 MATCH,Proxy는 해당 연결을 Proxy라는 정책으로 전달합니다. 설정에 같은 이름의 정책이 있어야 합니다. MATCH를 목록 앞에 두면 뒤에 있는 일반 규칙은 더 이상 매칭될 기회가 없습니다.
04 / 트래픽 유입과 DNS 조회 경로
DNS와 네트워크
시스템 프록시, TUN, DNS 설정은 각각 적용 범위가 다릅니다. 스위치가 켜져 있다는 사실만으로 해당 기능이 설정되었음을 알 수 있을 뿐, 실제 연결 경로는 따로 확인해야 합니다.
DNS
Domain Name SystemDNS는 도메인을 IP 주소 등의 레코드로 변환하며, 앱이 연결을 시작하기 전에 거치는 중요한 단계입니다. 프록시 환경에서는 앱, 코어, 프록시 서버 도메인의 조회가 서로 다른 경로를 사용할 수 있으므로 DNS 스위치 하나로 모든 상황을 설명할 수 없습니다. IP 주소로는 접속되지만 도메인으로 접속할 수 없다면 어느 단계에서 조회가 실패하는지 먼저 구분한 다음 DNS 설정 필드를 확인하세요.
Fake-IP
Fake IP address mappingFake-IP는 도메인에 가상 주소를 할당하고 매핑 정보를 유지해, 이후 코어에 들어오는 연결을 원래 도메인과 연결합니다. 이를 통해 도메인 기준으로 트래픽을 분기할 수 있습니다. 앱에 표시되는 가상 주소는 대상 웹사이트의 실제 주소가 아니며 웹사이트 주소가 잘못되었다는 뜻도 아닙니다. 일부 앱이나 LAN 서비스는 예외 처리가 필요할 수 있습니다. 모드를 바꾼 뒤에도 이전 조회 결과가 남아 있다면 관련 DNS 캐시를 비우는 것도 고려하세요.
Fake-IP 설정 보기 →DNS 누수
DNS leakDNS 누수는 도메인 조회가 예상과 다른 경로로 전달되는 현상입니다. 예를 들어 제어된 리졸버에서 처리하려던 조회가 시스템이나 앱에서 다른 리졸버로 직접 전송될 수 있습니다. 누수 여부를 판단하려면 먼저 기대하는 정책을 명확히 해야 하며, 검사 페이지에 표시된 지역만으로 판단할 수는 없습니다. 브라우저 자체 DNS, 시스템 DNS, IPv6, TUN의 트래픽 가로채기 범위를 함께 살펴보고 조회가 어디서 나가는지 하나씩 확인하세요.
시스템 프록시
System proxy시스템 프록시는 운영체제에서 제공하는 프록시 설정으로, 클라이언트는 보통 이를 로컬 리슨 주소와 포트에 연결합니다. 이 설정을 따르는 프로그램만 프록시를 사용하며, 일부 터미널 도구, 게임, 백그라운드 서비스는 자체 네트워크 설정을 사용합니다. 따라서 브라우저에서는 접속되지만 터미널에서는 안 되는 상황도 발생할 수 있습니다. 노드를 계속 바꾸기보다 해당 도구에 프록시 매개변수나 환경 변수를 설정해야 하는지 확인하세요.
TUN 모드
Virtual network interfaceTUN 모드는 가상 네트워크 인터페이스와 라우팅 설정을 사용해 IP 트래픽을 받아 시스템 프록시를 따르지 않는 앱의 트래픽도 처리할 수 있습니다. 보통 적절한 권한이 필요하며, 다른 VPN이나 가상 네트워크 카드, 라우팅 규칙과 충돌할 수도 있습니다. TUN을 켜도 모든 연결이 프록시를 거치는 것은 아니며 DNS 경로가 예상대로 설정되었다는 보장도 없습니다. 최종 아웃바운드는 트래픽 가로채기 범위, 프록시 모드, 분기 규칙에 따라 달라집니다.
05 / 파일 구조와 참조 관계
용어 범주로 돌아가기 ↑
설정 파일 필드
각 필드의 용도와 적용 범위를 설명합니다. 전체 예시, 들여쓰기 구조, 규칙 문법은 YAML 가이드에서 확인하세요. 수정하기 전에 복구할 수 있도록 기존 설정을 따로 보관해 두세요.
YAML
YAML configuration formatYAML은 Clash 설정에 널리 쓰이는 데이터 형식입니다. 공백 들여쓰기로 계층을 나타내고 하이픈으로 목록 항목을 표시합니다. 들여쓰기에 탭을 사용하면 안 됩니다. 특수 문자가 포함된 문자열은 YAML 문법에 맞게 인용해야 하며, 예시를 복사할 때도 기존 계층 구조를 유지하세요. 파일이 문법 검사를 통과해도 구조를 읽을 수 있다는 뜻일 뿐입니다. 필드 지원 여부와 정책 이름의 존재 여부는 코어에서 추가로 확인해야 합니다.
mixed-port
Mixed inbound portmixed-port는 로컬 혼합 리슨 포트를 지정하며, 하나의 포트로 HTTP와 SOCKS 프록시 연결을 모두 받을 수 있습니다. 원격 노드의 포트가 아니며 값을 바꿔도 노드 서버 설정은 변경되지 않습니다. 앱에 프록시 주소를 직접 입력했다면 포트를 변경한 뒤 앱 설정도 업데이트해야 합니다. 다른 기기의 접근 허용 여부는 리슨 주소, 방화벽, LAN 접근 설정을 함께 확인하세요.
proxy-providers
Proxy providersproxy-providers는 프록시 목록의 출처와 업데이트 방식을 정의해 노드 목록을 기본 설정과 분리해 관리할 수 있습니다. 정책 그룹은 보통 use로 해당 목록을 참조합니다. 노드 목록을 업데이트해도 전체 설정이 교체되는 것은 아닙니다. 제공자 이름, 정책 그룹의 참조, 반환 콘텐츠 형식을 함께 확인하세요. 다운로드에 성공했는데 그룹에 노드가 없다면 참조 관계를 추가로 살펴보세요.
rule-providers
Rule providersrule-providers는 재사용 가능한 규칙 모음을 정의하며, 긴 도메인 또는 IP 규칙을 기본 설정과 분리해 저장할 때 유용합니다. 모음의 동작 유형과 파일 형식이 서로 맞아야 합니다. 이후 보통 RULE-SET 규칙에서 사용할 모음과 적용할 정책을 지정합니다. 규칙 제공자를 정의하기만 하고 참조하지 않으면 해당 규칙이 라우팅에 자동으로 적용되지 않습니다.
덮어쓰기와 병합
Override / Merge덮어쓰기와 병합은 구독 설정에 로컬 변경 사항을 적용하는 방법으로, 사용자 지정 DNS, 포트, 규칙을 유지할 때 유용합니다. 객체 병합, 목록 교체, 실행 순서는 클라이언트마다 다를 수 있어 같은 내용을 그대로 사용할 수 없는 경우도 있습니다. 편집기의 원본 파일만 확인하지 말고 최종 적용된 설정을 살펴보세요. 구독을 업데이트한 뒤에도 사용자 지정 내용이 예상대로 유지되는지 확인해야 합니다.