설정 용어 가이드 · 주요 용어 25개
구독 가져오기부터 TUN 설정까지, 각 용어가 가리키는 계층을 먼저 구분한 뒤 어떤 항목을 수정할지 판단하세요. 자주 쓰는 용어를 다섯 가지로 나눠 정리했으며, 각 카드는 앵커 링크로 바로 공유할 수 있습니다.
처음 설정한다면 구독, 설정 파일, 프록시 그룹부터 살펴보세요. 실제 사용 방법은 사용 가이드에서 확인할 수 있습니다. 프로토콜과 코어 선택의 차이는 기술 문서를 참고하세요.
프로토콜은 클라이언트와 서버가 연결을 설정하는 방식을 정합니다. 선택할 때는 인증 방식, 보안 계층, 전송 매개변수, 코어 지원 여부를 함께 확인하세요. 이름만 비교해서는 안 됩니다.
Shadowsocks · ss
Shadowsocks는 암호화 프록시 프로토콜로, 설정에서 보통 ss로 표기합니다. 연결하려면 서버 주소, 포트, 암호화 방식, 비밀번호가 필요합니다. 암호화 방식마다 클라이언트 지원 여부가 다르며, 최신 방식은 키 형식에도 별도 조건이 있을 수 있습니다. 가져오기에 실패하면 비밀번호만 확인하지 말고 전체 매개변수를 점검하세요. 프로토콜 이름만으로 회선 속도를 판단할 수도 없습니다.
VMess · UUID
VMess는 V2Ray 생태계의 프록시 프로토콜로, 일반적으로 UUID를 인증 정보로 사용하며 여러 전송 방식을 조합할 수 있습니다. 노드의 네트워크 유형, TLS 설정, 경로, 호스트 이름은 서버 설정과 일치해야 하며 UUID만으로 연결할 수는 없습니다. 공유 링크를 파싱할 수 있어도 현재 코어가 모든 전송 방식 조합을 지원한다는 뜻은 아닙니다.
Trojan · TLS
Trojan은 일반적으로 TLS 기반의 암호화 연결을 사용하는 프록시 프로토콜입니다. 주요 설정에는 서버 주소, 포트, 비밀번호, TLS에 사용할 서버 이름이 포함됩니다. 인증서 검증은 이름 일치뿐 아니라 기기의 시간과 인증서 신뢰 체인에도 영향을 받습니다. 핸드셰이크 오류가 발생하면 먼저 이 설정을 확인하고, 인증서 검증을 건너뛰는 방법을 장기적인 해결책으로 삼지 마세요.
VLESS · Transport
VLESS는 경량 프록시 프로토콜로, 자체적으로 범용 데이터 암호화를 제공하지 않습니다. 보통 TLS 또는 지원되는 다른 보안 전송 방식과 함께 사용합니다. UUID뿐 아니라 전송 방식과 보안 계층 설정도 연결 성립 여부를 좌우합니다. 노드를 선택할 때는 설정 조합 전체가 코어와 호환되는지 확인하세요. VLESS라는 이름만으로 암호화 기능이나 속도를 보장할 수는 없습니다.
Hysteria 2 · QUIC / UDP
Hysteria 2는 QUIC 기반 프록시 프로토콜로, UDP를 사용하며 프록시 환경에 맞춘 전송 방식을 채택합니다. 실제 성능은 UDP 연결 가능 여부, 패킷 손실, 혼잡도, 서버 대역폭에 따라 달라집니다. 네트워크에서 UDP를 제한하면 연결되지 않을 수 있습니다. 이전 버전 Hysteria와 설정을 그대로 바꿔 쓸 수 없으므로 구독 형식과 코어 지원 여부를 각각 확인하세요.
TUIC · QUIC / UDP
TUIC는 QUIC 기반 프록시 프로토콜로, 암호화된 연결을 통해 TCP와 UDP 트래픽을 전달합니다. 하위 네트워크에서 UDP가 정상적으로 전송되어야 하며, 프로토콜 버전에 따라 인증 매개변수와 구현 지원이 다를 수 있습니다. 모바일 네트워크 전환, 유휴 연결 정책, 서버 설정도 사용 경험에 영향을 줍니다. 프로토콜 이름만 보고 안정성을 판단하지 마세요.
클라이언트 인터페이스, 프록시 코어, 인터페이스 프레임워크는 서로 다른 역할을 합니다. 인터페이스에 옵션이 표시된다고 해서 모든 코어 버전이 해당 설정을 지원하는 것은 아닙니다.
Clash Core
Clash 원본 코어는 Clash 설정 체계의 기반이 된 프로젝트로, 연결 처리와 규칙 매칭, 프록시 트래픽 전달을 담당합니다. 창이 있는 클라이언트와는 다릅니다. 오픈소스 원본 코어와 과거에 제공된 Premium 브랜치의 기능은 완전히 같지 않습니다. 이전 가이드를 참고할 때는 어떤 브랜치를 대상으로 했는지 먼저 확인하고, 모든 필드를 현재 코어에서도 그대로 쓸 수 있다고 가정하지 마세요.
Clash Meta
Clash Meta는 Clash 설정 체계를 확장한 코어 프로젝트의 이름이며, 후속 프로젝트는 mihomo라는 이름으로 개발을 이어가고 있습니다. 이전 문서나 구독 형식, 클라이언트 이름에는 여전히 Meta가 남아 있을 수 있으므로 이름이 다르다고 서로 완전히 독립된 설정 체계인 것은 아닙니다. 기능을 비교할 때는 클라이언트 제목만 보지 말고 실제 코어 버전과 지원 필드를 확인하세요.
mihomo Core
mihomo는 Clash Meta 프로젝트의 후속 코어 이름으로, 프로토콜 연결, DNS 처리, 규칙 라우팅, 트래픽 전달을 담당합니다. Clash Nyanpasu는 그래픽 인터페이스를 제공하며, 실제 설정 기능은 선택한 코어와 버전에 따라 달라집니다. 코어를 바꾼 뒤에는 설정을 불러올 수 있는지 확인하세요. Alpha 빌드는 새 기능을 시험하기 위한 것으로, 모든 환경에서 더 안정적이라는 뜻은 아닙니다.
Tauri · Application Framework
Tauri는 데스크톱 앱을 만드는 기술 프레임워크이며, Clash Nyanpasu는 이를 사용해 인터페이스와 로컬 기능을 구성합니다. Tauri는 프록시 프로토콜이 아니며 특정 도메인의 연결 경로를 결정하지도 않습니다. 이 작업은 프록시 코어가 처리합니다. 창이 빈 화면으로 표시되는 문제와 연결 시간 초과 문제는 각각 앱 실행 환경과 코어 로그를 확인해 따로 진단하세요.
규칙은 “어떤 연결을 어디에서 처리할지” 정하고, 프록시 그룹은 “최종적으로 어떤 출구를 사용할지” 정합니다. 라우팅 문제를 확인할 때는 일치한 규칙, 대상 프록시 그룹, 실제 노드 순서로 살펴보세요.
Rule Routing · rules
규칙 라우팅은 도메인, IP, 프로세스 등의 조건에 따라 연결마다 직접 연결, 프록시 또는 다른 처리 방식을 선택하는 기능입니다. 규칙은 보통 위에서 아래 순서로 적용되므로, 범위가 넓은 규칙을 너무 앞에 두면 뒤에 있는 세부 규칙이 적용되지 않을 수 있습니다. 전역 모드와는 다릅니다. 잘못된 연결 경로를 점검할 때는 현재 모드, 일치한 규칙, 최종 선택된 정책을 함께 확인하세요.
Proxy Group · proxy-groups
프록시 그룹은 여러 노드나 정책을 규칙에서 참조할 수 있는 하나의 출구로 묶습니다. 대표적인 유형으로는 수동 선택, 자동 테스트, 장애 조치가 있습니다. 규칙이 프록시 그룹과 일치한 뒤에는 그룹의 동작 방식에 따라 실제 노드가 결정됩니다. 그룹 이름을 바꾸면 규칙에서 참조하는 이름도 함께 확인하세요. 그룹에서 노드를 선택했더라도 모든 트래픽이 그 그룹을 통과하는 것은 아닙니다.
IP Geolocation · GEOIP
GeoIP는 IP 데이터베이스를 이용해 주소를 국가나 지역별로 분류하며, 규칙은 이를 바탕으로 연결 경로를 선택할 수 있습니다. 도메인 문자열이 아니라 IP 정보를 기준으로 하므로, 한 서비스의 모든 주소가 항상 같은 지역으로 분류된다고 보장할 수는 없습니다. 데이터베이스 출처와 업데이트 상태, DNS 조회 결과가 판단에 영향을 줍니다. 특정 서비스에 정확한 규칙 라우팅을 적용하려면 도메인 규칙도 함께 사용하는 편이 좋습니다.
Domain Categories · GEOSITE
GeoSite는 서비스, 용도, 지역별로 도메인을 모아 둔 목록입니다. 도메인을 하나씩 직접 입력하지 않고도 규칙에서 해당 목록을 참조할 수 있습니다. IP를 분류하는 GeoIP와는 다르며, 분류 이름과 포함 범위는 데이터 소스에 따라 달라집니다. 목록을 사용하기 전에 코어가 해당 규칙 유형을 지원하고 데이터 파일을 사용할 수 있는지 확인하세요. 오래된 목록에는 새 도메인이 빠져 있을 수 있습니다.
Rule Providers · RULE-SET
rule-providers는 설정에서 외부 규칙 모음을 관리하는 항목입니다. 규칙을 기본 설정과 분리해 관리하고 설정에 따라 업데이트할 수 있습니다. 제공자를 정의한 다음에는 rules에서 RULE-SET으로 참조해야 규칙 매칭에 사용할 수 있습니다. 규칙 모음의 형식과 동작 유형, 파일 내용이 서로 맞아야 합니다. 다운로드에 성공했더라도 참조 순서와 라우팅 결과가 올바르다는 뜻은 아닙니다.
더 읽어보기: 규칙 매칭 순서와 원격 규칙 모음 설정 방법.
DNS 조회 경로와 연결 경로는 서로 관련이 있지만 같지는 않습니다. 연결이 실제로 어떤 경로를 거치는지 파악하려면 시스템 프록시, TUN, 앱 자체의 DNS 설정을 함께 살펴봐야 합니다.
Domain Name System
DNS는 도메인을 IP 등의 레코드로 변환하며, 앱은 보통 연결을 시작하기 전에 먼저 DNS 조회를 합니다. 프록시 코어의 DNS 설정, 운영체제 리졸버, 브라우저의 보안 DNS가 동시에 작동할 수 있으며 실제 조회 경로는 트래픽을 어떻게 가로채는지에 따라 달라집니다. nameserver를 바꾼 뒤에도 이전 결과가 나타난다면 캐시, 라우팅 정책, 앱 자체의 DNS 처리 방식도 확인하세요.
Fake IP · fake-ip
Fake-IP는 DNS 처리 방식 중 하나입니다. 코어가 먼저 앱에 가상 IP를 전달하고, 이후 매핑 정보를 바탕으로 도메인을 복원해 연결을 처리합니다. 가상 주소는 대상 사이트의 실제 주소가 아니므로 이런 주소가 보인다고 해서 반드시 DNS 오류인 것은 아닙니다. 일부 로컬 네트워크나 실제 DNS 결과에 의존하는 앱에는 예외 규칙이 필요할 수 있으니, 호환성 문제에 맞춰 설정하세요.
TUN · Virtual Network Interface
TUN 모드는 가상 네트워크 인터페이스로 IP 트래픽을 받아 라우팅 설정과 함께 시스템 프록시를 따르지 않는 앱의 연결을 처리합니다. 보통 추가 권한이 필요하며 네트워크 스택, 자동 라우팅, DNS 가로채기 등의 설정도 관련됩니다. 켜기만 하면 모든 트래픽을 처리하는 단일 스위치는 아닙니다. 다른 VPN이나 가상 네트워크 어댑터와 함께 사용할 때는 라우팅과 DNS가 충돌하지 않는지 특히 확인하세요.
DNS Leak
DNS 유출은 일반적으로 도메인 조회가 예상한 경로를 우회해 사용자가 원하지 않는 DNS 서비스로 전송되는 현상을 말합니다. 검사 페이지에 표시된 DNS 서버 위치는 참고 자료일 뿐, 특정 국가가 표시된다는 이유만으로 모든 트래픽이 프록시를 통과하는지 판단할 수는 없습니다. 실제 요청 경로를 확인하려면 브라우저의 보안 DNS, 시스템 DNS 설정, TUN 처리 범위, 코어 로그를 함께 살펴보세요.
System Proxy
시스템 프록시는 운영체제가 앱에 제공하는 프록시 설정입니다. 클라이언트가 이를 로컬 수신 포트로 지정하면 해당 설정을 따르는 앱이 연결을 전달합니다. TUN 모드와는 다르며, 일부 프로그램은 시스템 설정을 무시하거나 자체 프록시 설정을 사용합니다. 클라이언트를 종료한 뒤에도 인터넷에 연결되지 않으면 시스템 프록시 설정이 남아 있는지, 해당 로컬 포트에서 서비스가 계속 실행 중인지 확인하세요.
더 읽어보기: DNS 유출 검사 결과와 DNS 설정 점검 방법.
구독은 콘텐츠를 가져오는 경로이고, 설정 파일은 실행 설정이며, 노드는 그 일부입니다. 연결이나 업데이트 문제를 살펴보기 전에 콘텐츠 형식과 현재 활성화된 항목부터 확인하세요.
Subscription
구독은 노드나 전체 설정을 가져오는 링크로, 클라이언트가 링크에 요청을 보내 콘텐츠를 다운로드하고 설정에 따라 정기적으로 업데이트할 수 있습니다. 구독에 따라 노드 목록, 공유 링크 모음, Clash 설정이 제공되며, 형식이 맞지 않으면 서로 바꿔 사용할 수 없습니다. 구독 주소에 계정 정보가 포함될 수 있으므로 민감 정보로 취급하세요. 스크린샷, 로그, 공개 질문에 전체 링크를 노출하지 마세요.
Proxy Node
노드는 프록시 연결 대상과 관련된 설정 묶음으로, 보통 프로토콜, 서버 주소, 포트, 인증 정보를 포함하며 TLS와 전송 설정이 추가될 수도 있습니다. 노드 이름은 주로 식별을 위한 것으로, 이름에 표시된 지역이나 배율이 실제 회선 정보를 대신하지는 않습니다. 노드 사용 가능 여부는 로컬 네트워크와 서버 상태에도 영향을 받으므로 같은 노드라도 네트워크 환경에 따라 체감이 크게 달라질 수 있습니다.
YAML · Configuration Syntax
YAML은 Clash 설정에 자주 쓰이는 텍스트 형식으로, 키와 값, 목록, 들여쓰기로 계층 구조를 나타냅니다. 들여쓰기에는 공백을 사용하고 같은 수준의 항목은 일관되게 맞춰야 합니다. 특수 문자가 포함된 값에는 따옴표가 필요할 수도 있습니다. YAML 문법으로 파일을 파싱할 수 있다는 것은 텍스트 구조가 유효하다는 뜻일 뿐입니다. 필드 이름과 참조 관계, 프로토콜 매개변수가 올바른지는 현재 코어에서 확인해야 합니다.
Configuration Profile
설정 파일은 코어의 실행 방식을 정의하며, 수신 포트, DNS, 노드, 프록시 그룹, 규칙 등을 포함할 수 있어 단일 노드 정보보다 범위가 넓습니다. 설정을 가져오는 것과 활성화하는 것은 별개의 단계이므로 저장한 뒤 현재 선택된 항목도 확인해야 합니다. 클라이언트가 로컬 덮어쓰기 설정을 추가할 수도 있으니 문제를 점검할 때는 구독 원문만 보지 말고 최종 적용된 설정을 확인하세요.
Latency · URL Test
클라이언트의 지연 시간 테스트는 보통 지정한 노드를 통해 테스트 주소에 접속하고 요청이 완료되기까지 걸린 시간을 기록합니다. 측정 범위는 구현 방식과 연결 재사용 여부에 따라 달라집니다. 이 결과는 대역폭 측정이 아니며 동영상 다운로드 속도를 바로 예측할 수도 없습니다. 테스트 주소, 시간 초과 설정, 로컬 네트워크, 서버 부하가 결과에 영향을 주므로 실제 사용할 앱의 성능도 함께 고려해 노드를 선택하세요.
문제에 맞는 다음 단계: 설정 파일을 가져오는 방법을 모르겠다면 사용 가이드를 확인하세요. 가져온 뒤 업데이트 오류가 발생했다면 구독 업데이트 실패 문제 해결을 참고하세요. 구체적인 오류 해결 방법은 자주 묻는 질문에서 찾아볼 수 있습니다.