Shadowsocks
SS라고도 부르며 암호화된 프록시 전송을 기반으로 합니다. 노드에는 보통 서버 주소, 포트, 암호화 방식, 비밀번호가 필요합니다. 암호화 방식은 서버와 일치해야 하고, 일부 노드는 추가 플러그인이 필요하므로 주소와 비밀번호만 복사해서는 충분하지 않습니다. 설정을 가져올 수 있는데도 연결되지 않는다면 규칙을 계속 바꾸기보다 코어가 해당 암호화 방식과 플러그인을 지원하는지 확인하세요.
설정 개념 · 용어 25개
Clash 용어집
프록시 프로토콜, 코어, 설정 항목을 범주별로 찾아볼 수 있는 색인입니다. 먼저 각 개념이 속한 계층을 구분한 다음 클라이언트의 실제 설정을 확인하세요. 프로토콜 이름이 같아도 전송 매개변수와 코어 지원 범위까지 동일한 것은 아닙니다.
프록시 프로토콜
프로토콜은 클라이언트와 서버가 프록시 데이터를 주고받는 방식을 정의합니다. 전송 방식, 인증, 인증서는 서로 연관되어 있지만 각각 다른 설정 계층이므로 프로토콜 이름만으로 연결 성능을 판단할 수 없습니다.
VMess
V2Ray 계열의 프록시 프로토콜로 UUID 등의 매개변수로 사용자를 식별하며, WebSocket이나 TLS 같은 전송 설정과 함께 쓰이는 경우가 많습니다. VMess는 프로토콜이고 WebSocket은 전송 방식이므로 서로 대체할 수 없습니다. 기존 설정을 옮길 때는 인증 관련 항목, 전송 경로, 시스템 시간을 확인하세요. 코어가 프로토콜 이름을 인식하더라도 과거의 모든 매개변수 조합을 그대로 사용할 수 있는 것은 아닙니다.
Trojan
일반적으로 TLS 연결을 통해 프록시 데이터를 전송하고 비밀번호로 인증합니다. 서버 주소, 포트, 비밀번호, TLS 서버 이름을 함께 확인해야 합니다. 연결에 사용하는 IP 주소와 인증서에 설정된 도메인은 서로 다를 수 있습니다. 인증서 검증에 실패하면 인증서 유효기간, 시스템 시간, 서버 이름을 확인하세요. 인증서 검증을 끄면 연결의 신원 확인이 약화되므로 일반적인 해결책으로 사용하지 않는 것이 좋습니다.
VLESS
인증과 전송 보호를 분리하는 프록시 프로토콜로, 프로토콜 자체는 완전한 전송 암호화를 제공하지 않습니다. 실제 연결에는 보통 TLS나 REALITY 같은 방식이 추가로 필요합니다. UUID, 전송 유형, 서버 이름, flow 등의 매개변수는 서버 설정과 일치해야 합니다. 클라이언트를 선택할 때는 VLESS 지원 여부뿐 아니라 노드에서 요구하는 전송 방식과 핸드셰이크 조합을 코어가 지원하는지도 확인하세요.
Hysteria2
QUIC 기반 프록시 프로토콜로 하위 계층에서 UDP를 사용하며, 패킷 손실과 혼잡 상태가 중요한 연결에 자주 쓰입니다. 프로토콜 이름만으로 높은 처리량이 보장되지는 않습니다. UDP 연결 가능 여부, 서버 부하, 대역폭 설정이 모두 결과에 영향을 줍니다. 같은 네트워크에서 TCP 기반 노드는 연결되는데 Hysteria2가 시간 초과된다면 먼저 UDP 경로를 확인하고 2세대 프로토콜용 설정 항목을 사용했는지 살펴보세요.
TUIC
QUIC 기반 프록시 프로토콜로, 다중화 등의 기능을 활용해 프록시 연결을 처리하며 UDP 포워딩 관련 동작 설정도 포함합니다. 클라이언트와 서버의 프로토콜 버전, 인증 매개변수, 관련 옵션이 일치해야 합니다. 오래된 설정 예제가 현재 구현에도 그대로 적용되는 것은 아닙니다. 모바일 네트워크에서의 실제 사용 경험은 네트워크 전환, 신호 품질, 백그라운드 정책에도 영향을 받으므로 한 번의 지연 시간 측정만으로 판단하지 마세요.
코어·클라이언트
코어는 네트워크 처리를 담당하고 클라이언트는 인터페이스와 시스템 연동을 맡습니다. 문제를 신고할 때 앱 이름, 코어 이름, 실제 적용된 설정을 각각 기록하면 호환성 판단이 훨씬 명확해집니다.
Clash 오리지널 코어
초기 Clash 생태계에서 사용된 규칙 기반 프록시 코어로, 설정 형식과 정책 그룹, 라우팅 방식의 기반을 마련했습니다. Clash for Windows 같은 GUI 앱과는 다르며, 오픈소스 오리지널 코어와 과거 Premium 코어의 기능 범위도 구분해야 합니다. 오래된 튜토리얼을 참고할 때는 먼저 어느 포크를 기준으로 했는지 확인하고, 이후 코어에서 추가된 프로토콜이나 설정 항목을 구버전에 그대로 적용하지 마세요.
Clash Meta
mihomo 프로젝트가 과거에 사용한 이름으로, 오래된 글과 설정 안내, 일부 클라이언트 이름에서 여전히 Meta를 볼 수 있습니다. 이는 코어 발전 계보 중 하나를 가리키며 Clash라는 이름이 붙은 모든 앱의 공통 버전을 뜻하지는 않습니다. Meta 지원으로 표시된 설정을 사용할 때는 실제 코어 버전과 설정 항목을 확인하세요. 구버전 코어에는 현재 mihomo의 모든 기능이 포함되어 있지 않을 수 있습니다.
mihomo 코어
Clash Meta 계보를 이어 발전한 규칙 기반 프록시 코어로, 프로토콜 연결, 규칙 매칭, DNS 처리, TUN 등의 하위 기능을 담당합니다. GUI 클라이언트에서 관리할 수도 있고, 호환되는 환경에서 독립적으로 사용할 수도 있습니다. 앱 인터페이스 업데이트와 코어 업데이트가 항상 동시에 이루어지는 것은 아닙니다. 알 수 없는 설정 항목이나 프로토콜 미지원 문제를 해결할 때는 설치 파일 이름만 보지 말고 실제 실행 중인 코어 정보를 확인하세요.
GUI 클라이언트
구독 관리, 정책 선택, 로그 확인, 시스템 설정 기능을 제공하는 앱입니다. 예를 들면 Clash Verge Rev가 있습니다. 클라이언트는 구독, 화면 옵션, 로컬 덮어쓰기 설정을 결합해 실행 설정을 만들기 때문에 구독 원본을 수정해도 실제 동작이 바로 바뀌지 않을 수 있습니다. 선택할 때는 플랫폼 연동, 설정 관리 방식, 코어 호환성을 함께 고려하고, 자세한 차이는 클라이언트 비교에서 확인하세요.
규칙·라우팅
라우팅을 확인할 때는 두 가지를 살펴봐야 합니다. 연결이 어떤 조건에 해당하는지, 일치한 뒤 어떤 아웃바운드를 사용하는지입니다. 규칙 데이터를 내려받았다고 해서 기본 규칙에서 자동으로 참조되는 것은 아닙니다.
규칙 기반 라우팅
도메인, 대상 IP, 프로세스 등의 조건에 따라 연결을 직접 연결, 프록시 정책, 차단 중 하나로 보냅니다. 규칙은 보통 위에서 아래로 확인하며, 가장 먼저 일치한 항목이 연결 경로를 결정합니다. 마지막에는 나머지 연결을 처리하도록 MATCH를 두는 경우가 많습니다. 순서를 바꾸기 전에 연결 기록에서 어떤 규칙이 일치했는지 확인하고 현재 모드가 규칙 모드인지 살펴보세요. 전역 모드에서는 규칙을 수정해도 예상한 라우팅 변경이 일어나지 않는 경우가 많습니다.
GeoIP 주소 분류
데이터베이스를 기준으로 IP 주소를 지역 등의 범주로 분류해 대상 주소를 일괄 라우팅할 때 활용합니다. 데이터베이스상의 분류 결과가 서버의 실제 위치와 일치한다고 보장할 수 없고, 웹사이트를 소유한 기업을 나타내지도 않습니다. 도메인이 여러 지역의 CDN 주소로 해석될 수 있어 같은 서비스도 매칭 결과가 달라질 수 있습니다. 문제를 해결할 때는 실제 대상 IP와 데이터 출처를 함께 기록하세요.
GeoSite 도메인 목록
서비스, 용도, 관리 주체별로 도메인을 묶어 하나의 태그로 여러 도메인 매칭 조건을 참조할 수 있게 합니다. 태그의 존재 여부와 포함 도메인은 실제로 불러온 데이터 소스에 따라 달라지며, 모든 목록이 같은 분류를 사용하는 것은 아닙니다. GeoIP와의 차이는 매칭 대상입니다. GeoSite는 도메인, GeoIP는 IP 주소를 대상으로 하므로 IP만 있고 도메인 정보가 없다면 도메인 분류가 적용되지 않을 수 있습니다.
규칙 제공자
규칙 목록을 기본 설정에서 분리해 별도로 불러오고 업데이트할 수 있는 기능으로, 규모가 큰 도메인이나 주소 목록을 관리하는 데 적합합니다. 제공자의 behavior, format 등의 설정은 파일 내용과 일치해야 하며, 선언한 뒤에는 rules에서 RULE-SET으로 참조해야 합니다. 목록을 성공적으로 내려받았다는 것은 리소스에 접근할 수 있다는 뜻일 뿐입니다. 참조 이름이나 정책 이름, 규칙 순서가 올바르지 않으면 라우팅이 예상대로 작동하지 않을 수 있습니다.
정책 그룹
노드나 다른 정책으로 구성된 아웃바운드 선택 그룹입니다. 규칙은 보통 특정 서버가 아니라 그룹 이름을 참조합니다. select는 수동 선택, url-test는 지정한 테스트 결과에 따른 선택, fallback은 사용 가능 여부와 순서에 따른 대체 연결에 사용됩니다. 그룹 유형이 선택 로직을 결정하고 이름은 참조용 식별자입니다. 정책 그룹을 중첩했다면 최종 선택까지 이어지는 경로를 따라 실제 아웃바운드를 확인하세요. 가장 바깥쪽 그룹 이름만 보는 것으로는 부족합니다.
DNS·네트워크 스택
DNS 조회 경로와 트래픽 경로를 함께 확인해야 합니다. 시스템 프록시, 앱 자체 DNS, 가상 네트워크 인터페이스는 서로 다른 진입 경로이므로 한 설정을 켰다고 나머지 경로도 자동으로 일치하는 것은 아닙니다.
DNS 도메인 조회
네트워크 연결을 시작하기 전에 도메인을 주소 등의 레코드로 변환하는 시스템입니다. 운영체제, 브라우저, 프록시 코어가 각자 캐시를 유지하거나 서로 다른 DNS 서비스를 사용할 수 있으므로 시스템 DNS를 바꿔도 브라우저의 조회 경로는 달라지지 않을 수 있습니다. 설정할 때는 대상 웹사이트 도메인 조회와 프록시 서버 도메인 조회도 구분해야 합니다. 후자에 문제가 있으면 노드 자체가 연결되지 않을 수 있습니다.
Fake-IP 가상 주소 매핑
코어가 먼저 앱에 가상 주소를 반환하고 도메인 매핑을 저장합니다. 앱이 연결을 시작하면 이 매핑을 바탕으로 도메인 정보를 복원해 아웃바운드를 처리합니다. 가상 주소는 대상 서버의 실제 주소가 아니므로 조회 결과만 보고 출구 위치를 판단할 수 없습니다. 실제 주소가 필요한 앱은 예외 설정이 필요할 수 있습니다. 필터 목록을 변경하기 전에 문제가 매핑 호환성 때문인지 규칙이나 라우팅 오류 때문인지 확인하세요.
TUN 모드
가상 네트워크 인터페이스를 통해 IP 트래픽을 받아 처리하므로 시스템 프록시 설정을 따르지 않는 일부 앱의 트래픽도 처리할 수 있습니다. 프록시 프로토콜이나 전역 프록시와 같은 개념은 아닙니다. 트래픽을 가로챈 뒤에도 규칙에 따라 직접 연결하거나 프록시를 사용할 수 있습니다. 실행에는 보통 시스템 권한, 라우팅, 네트워크 스택 설정이 필요합니다. 다른 VPN이나 가상 네트워크 인터페이스와 함께 사용할 때는 라우팅 충돌과 DNS 가로채기 범위를 중점적으로 확인하세요.
DNS 누수
도메인 조회가 예상한 경로로 전송되지 않고 앱이 코어를 우회해 시스템 DNS를 직접 사용하는 등 다른 조회 경로로 빠지는 현상입니다. 검사 페이지에 특정 DNS 서비스가 표시되더라도 프록시 연결 전체가 실패했다고 단정할 수는 없으며, 예상한 설정과 함께 판단해야 합니다. 문제를 해결할 때는 브라우저의 암호화 DNS, 시스템 DNS 조회, TUN 가로채기, IPv6 경로를 확인하고 요청이 시작된 곳부터 하나씩 점검하세요.
노드 지연 시간
지정한 테스트 조건에서 클라이언트가 요청을 완료하는 데 걸리는 시간입니다. 연결과 핸드셰이크, 응답 대기 시간이 포함될 수 있어 시스템 ping과 측정 기준이 다릅니다. 지연 시간이 짧다고 다운로드 대역폭이 높은 것은 아니며, 한 번 시간 초과가 발생했다고 노드를 계속 사용할 수 없는 것도 아닙니다. 결과를 비교할 때는 테스트 주소, 시간 초과 설정, 네트워크 환경을 맞춘 뒤 패킷 손실, 실제 전송 속도, 대상 서비스의 상태까지 함께 살펴보세요.
구독·설정 파일
원격 구독은 입력 데이터를 제공하고, 로컬 설정은 이를 조합하는 방식을 결정합니다. 코어가 실제로 읽는 것은 최종 실행 설정입니다. 업데이트 전에 복구 가능한 설정 사본을 보관하면 변경 내용을 비교하기 쉽습니다.
구독
링크를 통해 노드나 전체 설정을 배포하고 업데이트하는 방식입니다. 형식에 따라 노드만 포함할 수도 있고 정책 그룹, 규칙, DNS 설정까지 담을 수도 있습니다. 브라우저에서 링크를 열 수 있어도 현재 클라이언트와 호환된다는 뜻은 아니므로 응답 형식과 코어 설정 항목을 확인해야 합니다. 구독 주소에 개인 접근 정보가 포함될 수 있으니 로그나 스크린샷을 공유할 때는 전체 주소를 가려 개인 설정이 노출되지 않도록 하세요.
노드
코어가 아웃바운드 연결을 설정하는 데 사용하는 서버 매개변수입니다. 보통 프로토콜 유형, 주소, 포트, 인증, 전송 설정이 포함됩니다. 화면에 표시되는 노드 이름은 구분을 위한 라벨일 뿐 서버 위치나 대역폭, 사용 가능 여부를 보장하지 않습니다. 노드가 작동하려면 서버 상태와 로컬 네트워크 경로도 정상이어야 합니다. 가져온 뒤에는 먼저 연결을 테스트하고 정책 그룹에서 실제로 해당 노드를 선택했는지 확인하세요.
YAML 설정 형식
Clash 설정에 널리 쓰이는 구조화 텍스트 형식으로, 들여쓰기로 계층을 나타내고 목록과 키·값으로 매개변수를 구성합니다. 들여쓰기는 공백을 사용해야 합니다. 잘못된 계층, 중복 키, 특수 문자 처리 오류는 파싱 실패나 예상과 다른 결과를 일으킬 수 있습니다. 문법 검사를 통과해도 텍스트 구조를 읽을 수 있다는 뜻일 뿐입니다. 항목 이름과 데이터 유형, 코어 지원 범위를 확인해야 하며 파일 확장자가 올바르다고 내용 형식까지 맞는 것은 아닙니다.
설정 병합·덮어쓰기
구독과 로컬 설정, 추가 규칙을 결합해 최종 실행 설정을 만드는 과정입니다. 사용자 지정 DNS, 규칙, 포트 설정을 유지하는 데 활용할 수 있습니다. 덮어쓰기 순서, 목록 대체 방식, 스크립트 실행 시점은 클라이언트마다 다르므로 이름이 같은 기능이 항상 똑같이 동작한다고 가정하면 안 됩니다. 구독 업데이트 후 설정이 되돌아간다면 어느 계층에서 수정했는지 확인하고 생성된 최종 설정을 직접 살펴보세요.
노드 제공자
노드 목록을 독립적으로 불러오는 기능으로, 기본 설정의 정책 그룹 및 규칙과 별도로 노드를 관리할 수 있습니다. 일반적으로 정책 그룹에서 use로 참조해야 하며 리소스 다운로드에 성공했다고 현재 선택 목록에 노드가 추가된 것은 아닙니다. 규칙 제공자와는 용도가 다릅니다. proxy-providers는 아웃바운드 노드를 제공하고 rule-providers는 매칭 조건을 제공하므로 서로 바꿔 사용할 수 없습니다.