Clash / Glossary
구독, 규칙 기반 라우팅, 네트워크 스택 관련 개념을 정리했습니다. 설정에서 나타나는 위치에 따라 찾아보고 연결 진입점, 매칭 조건, 출구 정책을 구분해 보세요.
Core concepts
설정의 출처부터 앱 연결 방식까지, 무엇을 가져오는지와 어떻게 사용하는지를 구분합니다.
하나의 주소를 통해 노드나 설정을 받아오고 업데이트하는 배포 방식입니다. 구독을 업데이트하면 출처에서 내용을 다시 가져옵니다. 구독은 전체 YAML, 노드 목록 또는 인코딩된 텍스트를 반환할 수 있으며, 바로 가져올 수 있는지는 클라이언트가 지원하는 형식에 따라 달라집니다. 구독은 프록시 서비스 자체가 아닙니다. 주소에 계정 정보가 포함될 수도 있으므로 민감한 정보로 취급하고, 문제 해결을 위해 전체 링크를 공개하지 마세요.
서버 주소, 포트, 프로토콜, 인증 정보로 구성된 프록시 연결 설정으로, 보통 설정의 proxies에 들어갑니다. 노드 이름은 정책 그룹과 규칙에서 참조하며, 이름에 적힌 지역이 실제 출구 위치를 보장하지는 않습니다. 연결 여부는 계정 상태, 프로토콜 설정, 현재 네트워크에도 영향을 받으며 이름을 바꿔도 연결 경로는 달라지지 않습니다.
클라이언트가 지정한 테스트 주소와 방식으로 측정한 응답 시간입니다. 측정에는 연결 설정과 대상 서버의 응답이 포함될 수 있습니다. 테스트 주소, 시간 제한, 네트워크 경로가 다르면 결과도 달라지므로 수치만으로 서로 다른 클라이언트를 비교하면 안 됩니다. 지연 시간이 짧다고 다운로드 속도가 빠른 것은 아닙니다. 시간 초과가 표시되면 노드가 고장 났다고 단정하기 전에 테스트 대상에 연결할 수 있는지 확인하세요.
클라이언트가 관리하는 설정과 출처, 업데이트 방식 등의 정보로, UI에서는 Profile이라고 부르기도 합니다. 프로필을 바꾸면 노드, 정책 그룹, 규칙, DNS 설정이 함께 바뀔 수 있어 출구만 바뀌는 것은 아닙니다. 원격 프로필을 직접 수정하면 업데이트 시 변경 내용이 사라질 수 있으므로, 로컬 맞춤 설정은 클라이언트가 지원하는 오버라이드 방식으로 보관하는 것이 좋습니다.
운영체제의 프록시 설정이 클라이언트의 로컬 수신 포트를 가리키도록 하는 연결 방식입니다. 시스템 프록시를 따르는 브라우저와 앱은 요청을 해당 포트로 보내지만, 별도의 네트워크 설정을 사용하는 프로그램은 계속 직접 연결할 수 있습니다. 클라이언트를 종료한 뒤 작동하지 않는 프록시 주소가 남아 있으면 앱이 인터넷에 연결되지 않을 수 있습니다. 이때는 클라이언트 실행 상태와 시스템 프록시 설정을 함께 확인하세요.
Proxy protocols
프로토콜은 클라이언트와 프록시 서비스가 통신하는 방식을 정합니다. 로컬 연결에 사용하는 프로토콜과 원격 노드의 프로토콜은 서로 다를 수 있습니다.
앱이 HTTP 프록시 포트로 요청을 전달하는 방식입니다. HTTPS는 보통 CONNECT로 터널을 만든 뒤 대상 사이트와 TLS 통신을 합니다. HTTP 프록시는 클라이언트가 제공하는 로컬 연결 지점일 수도 있고 설정에 지정하는 원격 프록시 유형일 수도 있습니다. HTTP라는 표기만으로 연결 전체가 암호화되는지 판단할 수 없으므로 앱과 프록시, 프록시와 대상 사이트 사이의 각 연결을 구분해야 합니다.
TCP 전달을 지원하고 UDP 전달 방식도 정의하는 범용 프록시 프로토콜로, 앱에서 프록시 진입점을 직접 지정할 때 자주 사용합니다. 프로토콜 자체는 트래픽을 암호화하지 않으며 사용자 이름과 비밀번호 인증도 암호화된 통신을 뜻하지 않습니다. UDP를 실제로 사용하려면 앱, 클라이언트 설정, 원격 서비스가 모두 지원해야 합니다. 도메인을 어느 쪽에서 조회하는지는 앱의 연결 방식에 따라 달라집니다.
합의된 암호화 방식과 인증 정보를 사용해 원격 서비스에 연결하는 프록시 프로토콜로, 설정 유형은 보통 ss로 표시합니다. 서버 주소, 포트, 암호화 방식, 비밀번호가 모두 일치해야 하며 하나라도 다르면 핸드셰이크에 실패할 수 있습니다. 플러그인이나 특정 프로토콜 변형이 필요한 경우 클라이언트 코어와 서버가 호환되는 구현을 사용하는지 확인하세요.
보통 TLS로 암호화 연결을 만들고 비밀번호로 인증하는 프록시 프로토콜입니다. 서버 주소와 TLS에 사용할 도메인이 서로 다를 수 있으며, SNI, 인증서 이름, 시스템 시간도 핸드셰이크에 영향을 줍니다. 인증서 오류가 발생하면 먼저 해당 매개변수와 서버 설정을 확인하세요. 인증서 검증을 건너뛰는 방법을 장기적인 해결책으로 사용해서는 안 됩니다.
Rules & routing
규칙은 연결 조건을 판별하고, 정책 그룹은 출구를 선택하며, 최종 출구가 연결을 만듭니다.
도메인, IP, 프로세스, 규칙 집합 등의 조건에 따라 연결 출구를 선택하는 방식입니다. 규칙 모드에서는 보통 위에서 아래로 확인하며, 먼저 일치한 규칙이 정책을 결정합니다. 마지막에 MATCH를 두면 나머지 연결을 처리할 수 있습니다. 규칙을 바꾸기 전에 연결 기록에서 어떤 규칙이 적용됐는지 확인하세요. 범위가 넓은 규칙을 너무 앞에 두면 뒤에 있는 세부 규칙이 적용되지 않을 수 있습니다.
노드나 다른 정책을 묶어 규칙에서 참조할 수 있는 출구로 만들어, 매칭 로직과 실제 노드를 분리합니다. select는 직접 선택하고, url-test는 테스트 결과에 따라 자동 선택하며, fallback은 순서대로 사용 가능한 항목을 찾습니다. 규칙은 그룹 이름을 참조하고 그룹 내부에서 선택된 항목이 실제 출구가 됩니다. 이름을 바꿀 때는 모든 참조도 함께 확인하세요.
rule-providers로 정의하고 RULE-SET에서 참조하는 규칙 모음으로, 규모가 큰 도메인 또는 주소 목록을 관리할 때 유용합니다. 규칙 집합에는 매칭할 내용이 저장되고, 참조 규칙은 출구를 지정하므로 두 부분이 함께 연결 동작을 결정합니다. 파일 형식, behavior, 캐시 경로를 확인하세요. 다운로드에 성공해도 항목이 예상한 형식이라는 보장은 없습니다.
IP 지리 정보 데이터베이스를 기준으로 매칭하는 규칙입니다. 예를 들어 GEOIP,CN,DIRECT와 같이 사용합니다. 결과는 데이터베이스 버전과 IP 주소 등록 정보에 따라 달라지므로 웹사이트의 서비스 지역이나 사용자의 위치를 정확히 판단하는 기준으로 볼 수 없습니다. 도메인 연결에 IP 규칙을 적용하면 DNS 조회가 발생할 수 있습니다. no-resolve를 추가하면 해당 규칙을 위해 별도로 조회하지 않지만, 대상 IP가 아직 없는 요청은 규칙에 매칭되지 않을 수 있습니다.
DIRECT는 로컬 네트워크 경로로 직접 연결하고 REJECT는 연결을 거부하는 내장 정책으로, 둘 다 규칙에서 참조할 수 있습니다. 직접 연결은 특정 물리 네트워크 어댑터를 지정하는 것이 아니며, 트래픽이 시스템 VPN이나 다른 네트워크 계층을 거칠 수 있습니다. 거부 규칙은 특정 대상을 차단할 때 유용하지만 범위가 너무 넓으면 로그인, CAPTCHA, 페이지에 필요한 리소스에 영향을 줄 수 있습니다.
DNS & network stack
도메인 조회와 트래픽 전달은 별개의 과정입니다. 앱, 시스템 라우팅, 코어 설정을 함께 살펴봐야 합니다.
도메인을 IP 주소 등의 레코드로 변환하는 시스템입니다. 조회 결과에 따라 이후 연결이 향하는 주소가 정해질 수 있습니다. 클라이언트의 DNS 설정은 전달받은 쿼리를 처리하지만, 시스템 캐시, 앱 내장 암호화 DNS, 쿼리가 클라이언트로 전달되는 방식도 결과에 영향을 줍니다. 문제를 해결할 때는 도메인 조회 성공 여부와 조회된 주소에 연결할 수 있는지를 나눠 확인하세요. 두 문제의 원인은 서로 다릅니다.
클라이언트가 앱에 매핑용 주소를 반환한 뒤, 이후 연결에서 도메인을 복원하는 DNS 작동 방식입니다. 라우팅에 필요한 도메인 정보를 유지하는 데 도움이 되며 앱에 표시되는 주소가 실제 대상 서버의 주소와 다를 수 있습니다. 실제 조회 결과에 의존하는 LAN 서비스나 특정 앱에는 fake-ip-filter가 필요할 수 있습니다. 설정을 바꾼 뒤에는 시스템과 앱에 남아 있는 이전 DNS 캐시도 확인하세요.
가상 네트워크 인터페이스로 IP 패킷을 받아 코어에서 처리하는 연결 방식으로, 시스템 프록시를 따르지 않는 일부 앱의 트래픽도 처리할 수 있습니다. 실제 트래픽 처리 범위는 라우팅, 권한, 네트워크 스택, 제외 설정에 따라 달라지며 스위치를 켠다고 반드시 모든 트래픽이 전달되는 것은 아닙니다. TUN은 트래픽이 클라이언트로 들어오는 방식을 처리합니다. 들어온 연결은 규칙에 따라 직접 연결하거나 프록시를 사용하거나 거부할 수 있습니다.
DNS 쿼리가 예상과 다른 경로나 DNS 서버를 통해 처리되는 현상입니다. 확인하기 전에 어떤 쿼리가 어느 출구를 거쳐야 하는지 먼저 정해야 합니다. 시스템 DNS, 브라우저 보안 DNS, IPv6, 클라이언트가 처리하지 않는 앱 때문에 결과가 예상과 다를 수 있습니다. 검사 페이지에 표시되는 DNS 서버는 단서로만 참고하고, 쿼리 로그와 실제 라우팅을 함께 확인하세요. 지역 표시만으로 결론을 내리면 안 됩니다.
연결 초기 단계에서 확인할 수 있는 프로토콜 메타데이터를 읽어 도메인을 식별하는 기능입니다. 예를 들어 일부 HTTP 정보나 TLS 핸드셰이크 정보를 읽을 수 있습니다. 원래 연결에 대상 IP만 포함된 경우 도메인 기반 라우팅에 도움이 되지만 HTTPS 내용을 복호화하지는 않습니다. 프로토콜이 바뀌거나 핸드셰이크 정보가 암호화되거나 식별 가능한 필드가 없으면 도메인을 알아내지 못할 수 있으므로 DNS와 라우팅 설정을 대체할 수 없습니다.
Client & core
UI는 관리 기능을, 코어는 실제 처리를 담당합니다. 호환성을 확인할 때는 설정의 출처와 최종 적용 내용도 함께 확인하세요.
클라이언트는 보통 UI, 구독 관리, 시스템 연동을 담당하고 코어는 프로토콜 연결, DNS, 규칙 실행을 담당합니다. 두 구성 요소는 각각 업데이트될 수 있으므로 UI 버전만으로 지원되는 설정 필드를 모두 알 수는 없습니다. 문제 해결 시 실제 코어 이름과 버전을 기록하고 최종 적용 설정을 확인하세요. 같은 필드라도 클라이언트마다 UI에서 찾는 위치나 오버라이드 방식이 다를 수 있습니다.
Clash 생태계에서 계속 발전해 온 프록시 코어로, 과거에는 Clash.Meta라는 이름을 사용했습니다. 프로토콜 처리, 정책 그룹, 라우팅, DNS 기능을 제공합니다. 연결 로직을 실행하는 구성 요소이지 모든 클라이언트 UI에서 공통으로 사용하는 이름은 아닙니다. 설정 예제를 복사하기 전에 실제 코어가 해당 필드를 지원하는지 확인하세요. 최신 설정 기능은 이전 버전이나 다른 코어에서 바로 사용할 수 없을 수 있습니다.
들여쓰기로 맵과 목록 등의 구조를 표현하는 텍스트 데이터 형식으로, Clash 설정에 주로 사용됩니다. 들여쓰기에는 공백을 사용하고 같은 단계의 필드는 일관되게 정렬하세요. 비슷해 보이는 문자열, 불리언, 목록도 파싱 결과에서는 서로 다른 유형입니다. 문법이 올바르더라도 정책 그룹 이름 참조 오류, 필드 오타, 코어 미지원으로 설정을 불러오지 못할 수 있습니다.
구독이나 원본 설정에 규칙, 병합 파일, 스크립트를 추가해 최종 설정을 수정하는 방식으로, 로컬 사용자 설정을 유지하는 데 유용합니다. 목록을 추가할지 교체할지, 필드를 어떤 순서로 병합할지는 클라이언트마다 달라 통일된 방식이 없습니다. 수정 후에는 구독 원본만 보지 말고 생성된 최종 설정과 로그를 확인하세요. 변경 전에는 복원할 수 있도록 설정 사본을 보관하는 것이 좋습니다.
클라이언트 UI나 제어 패널에서 상태를 확인하고 정책을 조정하기 위한 관리 인터페이스로, 보통 external-controller에서 수신 주소를 지정합니다. HTTP나 SOCKS 프록시 진입점과 달리 일반 앱의 네트워크 요청을 전달하는 기능은 없습니다. 수신 주소와 인증 설정에 따라 접근 범위가 정해집니다. 로컬에서만 사용할 때는 루프백 주소로 제한하고 신뢰할 수 없는 네트워크에 직접 노출하지 마세요.