Clash 용어집: 구독, TUN, DNS, mihomo 한눈에 보기

01 / PROJECTS

커널 및 프로젝트

커널은 연결을 처리하고 클라이언트는 조작 인터페이스를 제공합니다. 두 요소의 이름과 버전을 구분해 확인하세요.

Clash

Clash는 원래 규칙에 따라 네트워크 연결을 처리하는 프록시 커널 프로젝트의 이름입니다. 현재는 관련 클라이언트 생태계 전반을 가리키는 말로도 자주 쓰입니다. 원본 프로젝트와 이후 파생 프로젝트는 관리 주체가 다르며, 지원하는 프로토콜과 설정 필드도 완전히 같지 않습니다. ‘Clash용’이라고 표시된 파일은 확장자만 보고 호환 여부를 판단하지 말고, 어떤 커널을 요구하는지 확인해야 합니다.

mihomo / Clash Meta

mihomo

mihomo는 Clash Meta의 기술 계보를 이어받아 프록시 프로토콜 연결, 규칙 매칭, DNS 처리, TUN 트래픽 수신을 담당합니다. 커널이지 특정 데스크톱이나 모바일 앱을 뜻하는 것은 아닙니다. 여러 GUI 클라이언트에서 같은 종류의 커널을 사용할 수 있습니다. 특정 기능의 지원 여부를 확인할 때는 클라이언트와 커널 버전을 모두 기록해 두세요.

Graphical user interface client

GUI 클라이언트

GUI 클라이언트는 스위치를 조작하고, 구독을 가져오고, 정책을 선택하고, 로그를 확인할 때 사용하는 앱입니다. Clash Verge Rev, FlClash 등이 여기에 해당합니다. 인터페이스 설정을 커널 설정으로 변환하며 시스템 프록시, 서비스 권한, 자동 시작을 추가로 관리하기도 합니다. 같은 종류의 커널을 사용하더라도 클라이언트마다 설정 저장 위치와 오버라이드 순서가 다를 수 있으므로, 다른 클라이언트로 옮길 때 앱 설정을 그대로 복사하지 마세요.

External controller

외부 제어 인터페이스

프런트엔드나 제어판에서 커널을 관리할 때 사용하는 진입점입니다. 연결 상태 확인, 정책 전환, 설정 업데이트에 쓰이며 브라우저 트래픽을 전달하는 프록시 포트가 아닙니다. 127.0.0.1:9090은 로컬에서 수신하는 설정의 예시일 뿐, 혼합 프록시 포트로 입력하면 안 됩니다. 원격 접속이 필요하다면 접근 키를 설정하고 네트워크 접근 범위를 제한해 관리 기능이 외부에 노출되지 않도록 하세요.

Core log / log-level

커널 로그

로그에는 커널이 실행되는 동안 발생한 연결 및 오류가 기록됩니다. DNS 조회 실패, 프록시 핸드셰이크 실패, 규칙 매칭 여부를 확인하는 데 직접적인 단서가 됩니다. log-level로 기록 상세도를 조절할 수 있습니다. 문제를 해결할 때만 잠시 로그 수준을 높이고 재현 후에는 평소 설정으로 되돌리세요. 로그를 공유하기 전에는 구독 주소, 인증 정보, 공개하고 싶지 않은 도메인을 삭제하세요.

02 / PROTOCOLS

프록시 프로토콜

프로토콜은 연결 방식을 나타낼 뿐, 회선 품질을 보장하지 않습니다. 가져올 때는 필요한 매개변수를 빠짐없이 유지하세요.

Shadowsocks / SS

Shadowsocks

Shadowsocks는 암호화 프록시 프로토콜입니다. 노드에는 보통 서버 주소, 포트, 비밀번호, 암호화 방식이 필요합니다. 클라이언트와 서버에서 호환되는 매개변수를 사용해야 합니다. 일부 설정에는 플러그인과 플러그인 옵션도 포함되므로 주소와 비밀번호만 복사하면 연결되지 않을 수 있습니다. 암호화 방식에 따라 지원 범위가 다르므로 가져오기는 성공했지만 연결되지 않는다면 먼저 커널이 해당 방식을 지원하는지 확인하세요.

VMess / VLESS

VMess와 VLESS

VMess와 VLESS는 서로 다른 프록시 프로토콜이므로 설정의 유형 이름만 바꿔 서로 전환할 수 없습니다. VLESS 자체는 암호화를 제공하지 않으며, 연결 보호는 TLS나 REALITY 같은 보안 계층에 따라 달라집니다. 문제를 확인할 때는 서버가 온라인인지에만 집중하지 말고 사용자 ID, 전송 유형, 서버 이름, 관련 보안 매개변수를 하나씩 점검하세요.

Trojan

Trojan은 일반적으로 TLS로 클라이언트와 서버 간 프록시 연결을 보호합니다. 비밀번호뿐 아니라 올바른 서버 이름과 인증서 검증도 필요합니다. 서버 주소는 연결에 사용하고 TLS 서버 이름은 핸드셰이크와 신원 확인에 사용하므로 두 값이 다를 수 있습니다. 인증서 오류가 발생하면 설정과 시스템 시간을 먼저 확인하세요. 인증서 검증을 끄는 방법을 장기적인 해결책으로 삼지 않는 것이 좋습니다.

Hysteria 2 / HY2

Hysteria 2

Hysteria 2는 QUIC 기반 프록시 프로토콜로, 연결 여부는 현재 네트워크에서 UDP 통신이 가능한지에 영향을 받습니다. 구형 Hysteria와 프로토콜 및 설정이 호환되지 않으므로 가져올 때 유형이 올바르게 인식됐는지 확인하세요. 프로토콜 이름만으로 실제 속도를 보장할 수는 없습니다. 네트워크 제한, 서버 부하, 대역폭 설정이 모두 사용 환경에 영향을 주므로 주로 사용하는 네트워크에서 직접 테스트하세요.

SOCKS5 / HTTP proxy

SOCKS5 및 HTTP 프록시

이 두 진입점은 보통 앱의 트래픽을 로컬 클라이언트로 전달하는 데 사용하며, 클라이언트가 원격 노드에 연결할 때 사용하는 프로토콜과는 다릅니다. HTTP 프록시도 CONNECT를 통해 HTTPS 연결을 전달할 수 있으므로 HTTP 웹사이트만 접속할 수 있는 것은 아닙니다. 혼합 포트는 HTTP와 SOCKS 요청을 모두 받을 수 있습니다. 앱에서 프록시를 수동 설정할 수 있다면 설정에 표시된 주소와 실제 포트를 입력하세요. 포트가 항상 7890이라고 가정하면 안 됩니다.

03 / ROUTING

규칙 및 라우팅

트래픽이 어느 출구로 전달될지는 규칙 순서, 매칭 조건, 정책 그룹의 현재 선택에 따라 결정됩니다.

Rule-based routing

규칙 기반 라우팅

규칙 기반 라우팅은 설정 순서대로 연결을 확인하고 조건에 맞는 규칙의 정책을 적용합니다. 일반적인 처리 결과는 직접 연결, 프록시, 차단입니다. 구체적인 도메인 규칙은 포괄적인 규칙보다 앞에 두고, 마지막에는 MATCH로 나머지 연결을 처리하는 경우가 많습니다. TUN을 켠 상태에서도 규칙 기반 라우팅을 사용할 수 있습니다. 트래픽을 받아들이는 방식과 출구를 선택하는 방식은 별개입니다.

Proxy group

정책 그룹

정책 그룹은 노드나 다른 정책을 하나의 출구 이름으로 묶어 참조할 수 있게 합니다. 규칙은 보통 특정 노드가 아니라 그룹을 가리킵니다. select는 수동 선택, url-test는 테스트 결과를 바탕으로 선택, fallback은 사용 가능 여부와 순서에 따른 장애 조치에 사용됩니다. 그룹 내 선택을 바꿔도 주로 새 연결에 적용되며, 기존 장시간 연결은 바로 출구가 바뀌지 않을 수 있습니다.

GeoIP / GeoSite

GeoIP 및 GeoSite

GeoIP는 IP 주소 데이터로 분류하고 GeoSite는 도메인 목록으로 분류하므로 서로 대체할 수 없습니다. IP 주소의 소재지와 실제 서비스 위치가 항상 일치하는 것은 아니며, CDN을 사용하면 같은 도메인도 지역에 따라 다른 주소로 확인될 수 있습니다. 매칭 결과는 데이터 출처와 업데이트 상태, 커널 지원에 따라 달라집니다. 잘못 라우팅된다면 노드 이름만 보지 말고 해당 규칙과 데이터를 먼저 확인하세요.

Rule provider / RULE-SET

규칙 세트

규칙 세트는 여러 규칙을 별도 파일로 관리하는 방식입니다. 기본 설정에서 rule-providers로 소스를 선언하고 RULE-SET으로 참조합니다. 분류 데이터를 편리하게 업데이트할 수 있지만 출구를 자동으로 결정하지는 않습니다. 규칙을 참조할 때 적용할 정책도 지정해야 합니다. 형식과 동작 유형에 따라 요구사항이 다르므로 파일을 다운로드했다고 해서 현재 선언 방식으로 반드시 올바르게 파싱되는 것은 아닙니다.

Latency test / URL test

지연 시간 테스트

클라이언트에 표시되는 지연 시간은 지정한 URL에 연결하거나 요청해 측정한 값인 경우가 많으며, 일반적인 ICMP Ping과 다를 수 있습니다. 특정 대상에 대해 특정 시점에 측정한 시간이므로 다운로드 속도, 영상 재생 안정성, 모든 웹사이트의 접속 가능 여부와 같다고 볼 수 없습니다. 노드를 비교할 때는 가능한 한 같은 테스트 대상을 사용하고 실제 앱에서도 확인하세요. 한 번 시간 초과가 발생했더라도 테스트 사이트 자체에 접속할 수 없는 경우일 수 있습니다.

04 / NETWORK STACK

DNS 및 네트워크 스택

먼저 트래픽이 커널에 들어오는 경로를 확인하고, 다음으로 도메인이 어떻게 조회되는지 살펴보세요. 연결에 성공했다고 해서 DNS 경로까지 예상대로 작동하는 것은 아닙니다.

System proxy

시스템 프록시

시스템 프록시는 운영체제의 프록시 진입점을 로컬 클라이언트로 지정합니다. 이 설정을 따르는 앱에 주로 적용됩니다. 일부 명령줄 도구, 자체 네트워크 스택을 사용하는 앱, 게임은 시스템 프록시 설정을 따르지 않을 수 있으므로 브라우저가 작동한다고 모든 프로그램이 연결된 것은 아닙니다. 클라이언트를 종료하기 전에 시스템 프록시 설정이 복원됐는지 확인하세요. 설정이 그대로 남으면 앱이 더 이상 수신하지 않는 로컬 포트에 요청을 보낼 수 있습니다.

TUN mode

TUN 모드

TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 커널로 전달하며, 시스템 프록시 설정을 따르지 않는 앱을 연결할 때 주로 사용합니다. 필요한 권한이나 서비스가 있어야 할 수 있으며, 적용 범위는 라우팅, 제외 항목, 다른 VPN의 영향을 받습니다. TUN을 켠다고 모든 연결이 프록시를 사용하는 것은 아닙니다. 커널로 들어온 뒤에도 규칙에 따라 직접 연결하거나 전달할 수 있습니다.

Domain Name System / DNS

DNS 조회

DNS는 도메인에 연결된 주소 등의 레코드를 조회하며, 대부분의 연결을 시작하기 전에 거치는 중요한 단계입니다. 어떤 DNS 서버를 사용하고 어떤 네트워크 경로로 질의하는지에 따라 응답과 이후 규칙 판정이 달라질 수 있습니다. DNS 질의 경로와 웹 연결 경로는 따로 살펴봐야 합니다. 노드를 바꿔도 문제가 계속된다면 DNS 캐시나 설정이 여전히 영향을 주고 있을 수 있습니다.

Fake-IP

Fake-IP 모드는 앱에 가상 주소를 반환하고 커널에 주소와 도메인의 매핑을 저장합니다. 연결이 들어오면 도메인 정보를 복원해 규칙 기반 라우팅에 활용합니다. 이 주소는 웹사이트의 실제 서버 주소가 아니므로 가상 주소가 보인다고 DNS 오류라고 볼 수는 없습니다. 실제 주소를 필요로 하거나 LAN 기기를 검색하는 일부 앱은 필터 목록에 추가해야 할 수 있습니다. DNS 모드를 바꾼 뒤에는 필요한 경우 앱과 시스템의 캐시를 비우세요.

DNS leak

DNS 누수

DNS 누수는 질의가 예상한 경로를 벗어나는 현상입니다. 특정 지역의 DNS 서버가 보인다는 이유만으로 누수라고 단정할 수는 없습니다. 브라우저의 보안 DNS, 시스템 리졸버, IPv6, 앱 자체 DNS가 각각 별도의 경로를 사용할 수 있습니다. 점검할 때는 어떤 질의가 직접 연결되고 어떤 질의가 프록시를 거쳐야 하는지 먼저 정한 뒤 연결 로그와 테스트 결과를 함께 확인하세요. DNS 암호화만으로 질의가 프록시를 거친다고 볼 수도 없습니다.

05 / CONFIGURATION

구독 및 설정 파일

구독은 설정을 가져오고, 설정 파일은 프로그램의 동작을 결정합니다. 업데이트 소스와 로컬 수정 사항은 따로 관리하는 것이 좋습니다.

Subscription

구독은 설정이나 노드 목록을 반복해서 가져올 수 있는 리소스 주소입니다. 서비스 제공자가 내용을 업데이트하면 클라이언트에서 다시 가져올 수 있습니다. 비슷한 형태의 링크라도 전체 YAML, Base64 인코딩 목록, 단일 프로토콜 링크를 반환할 수 있으므로 형식에 맞는 방법으로 가져와야 합니다. 구독 주소는 계정 권한과 연결된 경우가 많습니다. 민감한 정보로 취급하고 공개 스크린샷이나 신뢰할 수 없는 온라인 변환 도구에 노출하지 마세요.

Proxy node / Outbound

Clash 용어집