용어 가이드 / 설정 개념 색인
먼저 트래픽이 클라이언트에 어떻게 들어오는지 확인한 다음, 규칙에 따라 연결 경로가 선택되는 방식을 살펴보세요. 설정 항목별로 자주 쓰이는 용어 25개를 정리했으며, 각 항목은 주소창의 앵커 링크로 바로 참조할 수 있습니다. 실제 사용 방법은 입문 가이드와 고급 설정에서 확인하세요.
읽는 순서: 클라이언트가 트래픽을 가로챔 → 규칙이 정책을 선택함 → 노드가 연결을 설정함. DNS는 도메인 조회에 필요한 주소를 제공하고, 구독과 YAML은 이 과정에 필요한 설정을 담습니다.
인터페이스, 트래픽 진입 경로, 네트워크 처리는 각각 역할이 다릅니다. 스위치가 켜져 있어도 모든 앱의 요청이 코어에 전달되는 것은 아닙니다.
Mihomo는 연결 처리, 규칙 매칭, 프록시 프로토콜, DNS 등의 네트워크 로직을 담당하는 코어로, 이전에는 Clash.Meta라는 이름을 사용했습니다. Clash Verge Rev는 그래픽 인터페이스를 제공하지만 실제 네트워크 요청은 코어가 처리하므로, 인터페이스 기능과 코어 기능은 구분해서 봐야 합니다. 설정 호환성 문제를 점검할 때는 클라이언트 이름만 보지 말고 현재 실행 중인 코어와 지원 필드를 먼저 확인하세요.
코어 관련 설정 보기 →클라이언트는 설정, 프록시 그룹, 연결 기록, 로그, 시스템 설정을 관리하는 앱입니다. Clash Verge Rev는 데스크톱 그래픽 클라이언트입니다. 클라이언트, 코어, 원격 프록시 서비스는 서로 다른 객체입니다. 인터페이스는 관리하고, 코어는 연결을 처리하며, 원격 서비스는 프록시 출구를 제공합니다. 클라이언트를 설치한 뒤에도 원하는 연결을 설정하려면 호환되는 설정을 가져오고 올바른 정책을 선택해야 합니다.
클라이언트 및 플랫폼 보기 →시스템 프록시는 운영체제에 로컬 프록시 주소와 포트를 등록해, 이 설정을 따르는 앱의 요청을 클라이언트로 전달합니다. 모든 네트워크 트래픽을 가로채는 기능은 아니므로 일부 명령줄 도구, 게임, 자체 네트워크 설정을 사용하는 앱은 시스템 프록시를 사용하지 않을 수 있습니다. 브라우저는 연결되는데 특정 앱이 직접 연결된다면 먼저 해당 앱의 프록시 설정을 확인하고, 필요할 때 TUN 모드를 고려하세요.
TUN 모드는 가상 네트워크 인터페이스와 라우팅 설정을 사용해 가로채기 조건에 맞는 트래픽을 코어로 전달하므로, 시스템 프록시를 따르지 않는 앱에 적합합니다. 코어에 들어온 연결은 규칙에 따라 직접 연결하거나 프록시를 사용합니다. TUN을 켰다고 모든 연결이 프록시를 통해 나가는 것은 아닙니다. 활성화하려면 보통 시스템 권한이나 서비스 지원이 필요하며, 다른 VPN과 함께 사용할 때는 라우팅과 DNS 충돌도 확인해야 합니다.
혼합 포트는 하나의 로컬 수신 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받으며, YAML의 mixed-port에 해당합니다. Clash Verge Rev에서 흔히 사용하는 설정은 7897입니다. 포트 번호가 고정된 것은 아니므로 변경한 뒤에는 해당 포트를 수동으로 입력한 모든 앱도 함께 수정해야 합니다. 다른 프로세스의 포트 사용, 잘못된 수신 주소, 허용되지 않은 LAN 접근은 각각 별도로 확인해야 합니다.
프로토콜은 클라이언트와 서버가 통신하는 방식을 정합니다. 매개변수는 서버 설정과 일치해야 하며, 프로토콜 이름만으로 속도나 안정성을 판단할 수는 없습니다.
노드는 코어에서 사용할 원격 프록시 연결 매개변수 모음으로, 일반적으로 서버 주소, 포트, 프로토콜, 인증 정보를 포함합니다. 표시 이름은 노드를 구분하기 위한 이름일 뿐입니다. 노드에 연결된다고 모든 웹사이트에 접속할 수 있는 것은 아니며, 규칙, 출구 네트워크, 대상 서비스도 함께 살펴봐야 합니다. 목록의 지연 시간은 테스트 주소와 방법에 따라 달라지므로 다운로드 속도로 환산할 수 없고, 실제 요청 성공을 보장하지도 않습니다.
Shadowsocks는 약속된 암호화 방식과 키를 사용해 프록시 연결을 설정하며, 설정에서는 보통 type: ss로 표시합니다. 서버, 포트, 암호화 방식, 비밀번호를 각각 일치시켜야 합니다. 서비스에 플러그인이 필요하다면 플러그인 유형과 매개변수도 호환성에 영향을 줍니다. 가져온 뒤 연결되지 않으면 암호화 방식을 임의로 바꾸기보다 서비스 제공자가 안내한 원래 매개변수를 확인하세요.
VMess는 사용자 ID 등의 매개변수로 인증하며, 다양한 전송 방식과 TLS 설정을 함께 사용할 수 있는 프록시 프로토콜입니다. 노드 정보에는 사용자 ID뿐 아니라 경로, Host, 서버 이름 등의 전송 매개변수가 포함될 수 있습니다. 관련 항목이 하나라도 빠지면 핸드셰이크에 실패할 수 있습니다. 점검할 때 시스템 시간도 확인해 시간 오류로 인한 인증 문제를 포트 오류로 오해하지 않도록 하세요.
VLESS는 사용자 ID 등의 정보로 인증하지만 프로토콜 자체는 전송을 암호화하지 않습니다. 실제 연결에는 보통 TLS, REALITY 또는 다른 전송 설정이 필요합니다. 서버 이름, 공개 키, 전송 경로 등 서버가 요구하는 매개변수는 프로토콜 이름만으로 알 수 없습니다. 가져오기 전에 현재 코어가 해당 노드의 전체 조합을 지원하는지 확인하고, type만 변경해 프로토콜을 변환할 수 있다고 생각하지 마세요.
Trojan은 일반적으로 TLS 연결로 프록시 트래픽을 전달하고 비밀번호로 인증합니다. 서버 주소에 연결할 수 있다는 것은 네트워크 경로에 접근할 가능성이 있다는 뜻일 뿐입니다. 이후에도 올바른 비밀번호, 서버 이름, 인증서 검증이 필요합니다. 인증서 오류가 발생하면 인증서 검증을 끄는 대신 시스템 시간, 도메인, 서버 인증서를 먼저 확인하세요.
규칙은 연결을 어디로 보낼지 결정하고, 프록시 그룹은 사용할 출구를 선택합니다. 먼저 매칭된 규칙을 확인한 뒤 그룹 내 선택을 살펴보세요.
규칙 기반 라우팅은 도메인, IP, 포트 등의 조건에 따라 연결을 직접 연결, 차단 또는 지정된 정책으로 전달합니다. 규칙 모드에서는 보통 위에서 아래로 확인해 먼저 매칭된 규칙의 정책을 적용하므로, 구체적인 규칙을 범위가 넓은 규칙보다 앞에 두는 것이 일반적입니다. 웹사이트가 예상과 다른 경로로 나간다면 노드만 바꾸지 말고 연결 기록에서 실제 매칭된 규칙을 확인한 뒤 규칙 순서를 조정하세요.
규칙 관리 방법 보기 →프록시 그룹은 노드나 다른 그룹을 묶어 규칙에서 참조할 수 있는 이름으로 만들며, 선택 방식은 그룹 유형에 따라 달라집니다. select는 수동 선택, url-test는 지정한 조건에 따른 테스트 선택, fallback은 사용 가능한 항목을 순서대로 선택하는 유형입니다. 규칙에 지정한 그룹 이름은 설정과 일치해야 하며, 테스트 결과는 지정된 테스트 대상과 당시 네트워크 환경에 한해서만 유효합니다.
DOMAIN-SUFFIX는 지정 도메인과 하위 도메인을 매칭합니다. 예를 들어 DOMAIN-SUFFIX,github.com,PROXY는 설정에 해당하는 PROXY 정책이 있을 때 github.com과 하위 도메인에 적용됩니다. 임의 문자열 포함 매칭이 아니므로 관계없는 도메인에 같은 문자열이 있다는 이유만으로 매칭되지는 않습니다. 정확한 도메인 하나만 매칭하려면 DOMAIN을 사용하세요.
GeoIP는 IP 주소 데이터베이스의 소속 분류를 기준으로 연결을 매칭합니다. 예를 들어 GEOIP,CN,DIRECT는 해당 분류에 속하는 대상을 직접 연결로 전달합니다. 결과는 실제 대상 IP와 로컬 데이터베이스 내용에 따라 달라지며, 회사 등록지, 접속자 위치와는 관계가 없습니다. CDN을 사용하는 웹사이트는 다른 주소로 해석될 수 있으므로 잘못된 라우팅이 발생하면 DNS 결과와 데이터베이스 업데이트 여부를 함께 확인해야 합니다.
MATCH에는 도메인이나 IP 조건을 추가하지 않으며, 앞선 규칙에 매칭되지 않은 연결을 처리하기 위해 보통 rules의 마지막 줄에 둡니다. MATCH,PROXY는 남은 트래픽을 PROXY라는 정책으로 전달한다는 뜻이지, 특정 노드를 자동으로 찾는다는 뜻은 아닙니다. 이 규칙을 앞에 두면 뒤의 규칙은 해당 연결을 처리할 기회를 얻지 못하는 경우가 많습니다.
DNS 조회, 트래픽 가로채기, 프록시 출구는 서로 다른 단계입니다. 먼저 요청이 어디서 시작되는지 확인한 뒤 예상한 경로를 거치는지 살펴보세요.
DNS는 도메인 이름을 IP 주소 등의 레코드로 변환하며, 웹사이트에 연결하기 전에 거치는 일반적인 단계입니다. 클라이언트의 DNS 설정에는 수신 주소, 상위 DNS 서버, 요청 라우팅, 캐시가 포함됩니다. DNS 서버 주소를 입력했다고 모든 앱이 해당 서버를 사용하는 것은 아닙니다. 점검할 때는 ‘DNS 조회 결과를 얻지 못하는 문제’와 ‘주소를 얻은 뒤 연결에 실패하는 문제’를 구분하세요. 로그 단서와 해결 방법이 서로 다릅니다.
Fake-IP 모드는 앱에 가상 주소를 반환하고 코어에서 가상 주소와 원래 도메인의 매핑을 유지합니다. 관련 연결이 코어에 들어오면 도메인 정보를 바탕으로 처리합니다. 도메인 정보를 유지하는 데 도움이 되지만 DNS 조회와 연결이 모두 올바른 경로를 거쳐야 합니다. DNS 모드만 켜고 트래픽 가로채기를 확인하지 않으면 문제가 해결되지 않을 수 있습니다. 실제 주소가 필요한 LAN 서비스나 특정 앱은 상황에 맞게 필터 범위를 설정하세요.
DNS 누수는 조회가 예상한 경로를 벗어나 사용하지 않으려는 DNS 서버에 도달하는 현상입니다. 특정 지역의 DNS 서버 이름이 보인다는 이유만으로 문제가 발생했다고 단정할 수는 없습니다. 앱 내장 암호화 DNS, 시스템 DNS 설정, 다른 VPN, 라우팅 규칙이 조회 경로를 바꿀 수 있습니다. 테스트 조건, 클라이언트 로그, 앱 설정을 함께 확인하고 먼저 예상하는 DNS 서버가 누구인지 정한 뒤 실제 경로와 비교하세요.
도메인 스니핑은 HTTP 요청 정보나 TLS 핸드셰이크 정보처럼 연결 초기 데이터에서 확인할 수 있는 정보를 바탕으로 대상 도메인을 추정해 규칙 매칭에 활용합니다. 임의의 HTTPS 본문을 복호화하는 기능이 아니며, 모든 연결에서 도메인을 식별할 수 있는 것도 아닙니다. 식별 결과 때문에 라우팅 문제가 생기면 해당 대상의 스니핑 및 대상 설정을 확인하고, 모든 연결로 범위를 바로 확대하지 마세요.
클라이언트 TUN 설정에서 DNS 리다이렉션은 일반적으로 조건에 맞는 기존 DNS 요청을 코어의 DNS 리졸버로 보내 일괄 처리하는 것을 뜻합니다. 공용 네트워크에서 DNS 응답을 악의적으로 변조하는 행위와는 설정 목적이 다르므로 문맥을 구분해야 합니다. 기존 DNS 포트를 가로채더라도 앱이 직접 보내는 DoH 또는 DoT 요청에는 영향을 주지 않을 수 있으므로 앱 내부의 DNS 설정도 확인하세요.
DNS 및 TUN 설정 보기 →구독은 설정을 배포하고, YAML은 설정을 표현하며, 로컬 오버라이드는 변경 사항을 유지합니다. 콘텐츠를 가져온 뒤에는 설정이 활성화되었는지도 확인해야 합니다.
구독은 링크를 통해 노드 목록이나 전체 설정을 배포하며, 클라이언트가 링크에 접속해 콘텐츠를 가져옵니다. 구독에 따라 Clash YAML, 인코딩된 노드 목록, 그 밖의 형식이 제공될 수 있으므로 링크가 열린다고 현재 클라이언트에서 바로 사용할 수 있는 것은 아닙니다. 구독 주소에 개인 접근 인증 정보가 포함될 수 있습니다. 로그나 스크린샷을 공유하기 전에 전체 링크를 가려 다른 사람이 같은 접근 권한을 사용하지 못하게 하세요.
구독 가져오기 단계 보기 →YAML은 들여쓰기로 매핑, 목록, 계층 구조를 표현합니다. Clash 설정에서는 dns, proxies, proxy-groups, rules 등의 항목을 기술할 때 주로 사용합니다. 편집할 때는 공백으로 들여쓰고 같은 단계의 항목을 정렬해야 합니다. 목록 항목의 하이픈도 장식이 아니라 구조의 일부입니다. 문법 분석에 성공해도 현재 코어가 해당 필드를 지원한다는 뜻은 아니므로 저장한 뒤 설정 검사 결과와 실행 로그를 확인하세요.
구독 변환은 원본 노드나 설정을 대상 클라이언트가 읽을 수 있는 형식으로 정리하며, 템플릿을 이용해 프록시 그룹과 규칙을 생성하기도 합니다. 형식 변환으로 서버 매개변수를 새로 만들 수는 없으며, 지원되지 않는 프로토콜이 자동으로 호환되는 것도 아닙니다. 온라인 서비스가 원본 구독 링크와 노드 인증 정보에 접근할 수 있으므로 사용 전에 서비스 출처를 확인하세요. 이미 호환되는 형식의 구독은 바로 가져올 수 있습니다.
로컬 오버라이드는 구독 설정에 로컬 변경 사항을 적용해 사용자 지정 DNS, 규칙, 기타 설정을 유지합니다. 구독이 업데이트될 때마다 같은 내용을 다시 편집하지 않아도 됩니다. 기능에 따라 필드 병합, 목록 교체, 스크립트 처리가 적용될 수 있으므로 모든 목록이 자동으로 추가된다고 가정해서는 안 됩니다. 수정 전에 원본을 보관하고, 수정 후에는 최종 적용 설정에서 규칙 순서, 정책 이름, 목록이 예상대로인지 확인하세요.
구독 업데이트는 원격 콘텐츠를 다시 가져오는 작업으로, 노드 매개변수, 프록시 그룹, 규칙이 바뀔 수 있습니다. 현재 설정을 전환하는 작업과는 다릅니다. 다운로드 성공, 콘텐츠 파싱 성공, 설정 활성화, 코어 재로드는 각각 별개의 단계이므로 문제가 발생하면 순서대로 확인하세요. 업데이트 주기는 서비스 제공자의 권장 사항과 실제 사용 상황에 맞추세요. 업데이트 후 연결에 문제가 생기면 노드 이름 변경 여부와 로컬 오버라이드에서 참조하는 항목이 여전히 유효한지 먼저 확인하세요.