Clash 용어집

Clash는 규칙 매칭, 정책 기반 라우팅과 로컬 프록시를 중심으로 하는 네트워크 프록시 생태계입니다. 일상적인 문맥에서 Clash는 초기 커널, 호환 설정 형식 또는 관련 커널을 사용하는 그래픽 클라이언트를 통칭할 수 있습니다.

문서를 읽을 때는 먼저 대상이 무엇인지 확인해야 합니다. 클라이언트는 인터페이스와 시스템 통합을 담당하고, 커널은 연결, 해석과 전달을 담당합니다. 두 구성 요소의 버전, 지원 필드와 업데이트 주기는 다를 수 있습니다.

mihomo는 Clash Meta에서 발전한 프록시 커널입니다. 설정 파일을 읽고 프록시 프로토콜, 규칙 매칭, DNS, TUN 제어와 제어 인터페이스 등의 하위 기능을 처리합니다.

Clash Verge Rev, FlClash 등의 그래픽 클라이언트는 mihomo를 호출하거나 관리할 수 있지만, 클라이언트 이름이 곧 커널 이름을 뜻하지는 않습니다. 필드 지원 여부를 확인할 때는 클라이언트에 통합된 커널과 설정 문법을 함께 확인해야 합니다.

그래픽 클라이언트는 커널에 설정 가져오기, 정책 전환, 로그 확인, 시스템 프록시 제어와 업데이트 관리 화면을 제공합니다. 또한 시스템 권한 요청, 사용자 환경 설정 저장과 커널 프로세스 시작을 담당하는 경우가 많습니다.

화면에 연결 성공이 표시되더라도 관련 스위치나 프로세스가 예상 상태에 들어갔다는 뜻일 뿐입니다. 실제 트래픽이 프록시를 통과하는지는 시스템 프록시, TUN 라우팅, 규칙 매칭과 로그를 함께 확인해야 합니다.

시스템 프록시는 운영체제가 애플리케이션에 HTTP, HTTPS 또는 SOCKS 프록시 주소를 알리는 방식입니다. 브라우저와 시스템 네트워크 설정을 따르는 대부분의 데스크톱 프로그램은 이 주소를 읽고 요청을 Clash의 로컬 수신 포트로 보냅니다.

일부 게임, 명령줄 도구와 자체 네트워크 스택을 구현한 애플리케이션은 시스템 프록시를 무시할 수 있습니다. 이런 트래픽은 별도로 프록시 환경 변수를 설정하거나 TUN 모드로 제어해야 합니다.

TUN 모드는 가상 네트워크 인터페이스로 운영체제가 전달한 IP 트래픽을 받은 뒤, 커널이 규칙에 따라 직접 연결, 프록시 또는 거부를 결정합니다. 시스템 프록시보다 더 많은 애플리케이션을 처리하며 프록시 설정을 읽지 않는 일부 프로그램도 제어할 수 있습니다.

TUN을 활성화하려면 일반적으로 관리자 권한, VPN 권한 또는 해당 시스템 확장이 필요합니다. 라우팅 충돌, 다른 VPN, 가상 머신 네트워크 카드와 방화벽 정책이 제어 결과에 영향을 줄 수 있습니다.

노드는 설정에서 원격 프록시 진입점을 설명하는 객체로, 일반적으로 서버 주소, 포트, 프로토콜, 인증 매개변수와 전송 옵션을 포함합니다. 정책 그룹은 노드 이름으로 이 객체를 참조합니다.

노드 이름은 주로 식별에 사용되며, 이름에 포함된 지역이나 배율 정보는 설정 제공자가 정합니다. 사용 가능 여부는 실제 연결, 대상 사이트 접속과 지속적인 안정성을 함께 확인해야 합니다.

프록시 프로토콜은 클라이언트와 원격 서비스가 연결을 수립하고 신원을 인증하며 트래픽을 캡슐화하는 방식을 정합니다. 프로토콜마다 TLS, 전송 계층, UDP, 플러그인 매개변수와 서버 구현에 대한 요구 사항이 다릅니다.

설정의 프로토콜 필드는 서버 설정과 일치해야 합니다. 프로토콜 이름만 바꿔서는 형식을 변환할 수 없으며, 필드가 없거나 매개변수가 맞지 않으면 대개 핸드셰이크가 실패합니다.

지연 시간은 보통 클라이언트가 탐색 요청을 보낸 뒤 응답을 받을 때까지 걸리는 시간이며 단위는 밀리초입니다. 클라이언트의 지연 시간 테스트는 지정된 URL에 접속하므로 테스트 주소, DNS와 당시 네트워크 경로의 영향도 받습니다.

지연 시간이 짧다고 다운로드 속도가 빠른 것은 아니며, 장시간의 패킷 손실과 대역폭 변동도 나타내지 못합니다. 노드를 선택할 때는 지연 시간을 1차 필터로 사용한 뒤 대상 서비스에서의 실제 성능을 함께 확인하세요.

UDP 전달은 프록시 경로가 UDP 데이터그램을 처리할 수 있음을 의미하며, 실시간 통신, 일부 게임, QUIC과 DNS 조회에서 자주 사용됩니다. TCP와 같은 신뢰성 있는 바이트 스트림을 만들지 않으므로 시간 초과와 세션 관리 방식이 다릅니다.

실제 지원 여부는 커널, 프록시 프로토콜, 노드 서버와 정책 그룹에 따라 함께 결정됩니다. 노드 필드에 UDP 지원이 표시되어도 경로의 모든 구성 요소가 올바르게 활성화되었다는 뜻은 아닙니다.

다중화는 적은 수의 하위 연결에서 여러 논리 요청을 전달하는 방식입니다. 주된 목적은 반복적인 핸드셰이크와 연결 수립 비용을 줄이는 것이며, 회선 대역폭을 직접 높이는 기능은 아닙니다.

패킷 손실이 크거나 서버 구현이 맞지 않는 네트워크에서는 다중화로 여러 요청이 서로 영향을 받을 수도 있습니다. 활성화 여부는 프로토콜 문서와 실제 테스트를 바탕으로 결정해야 합니다.

정책 그룹은 노드, 하위 정책 그룹 또는 내장 동작을 묶은 집합입니다. 일반적인 유형으로 수동 선택, 자동 속도 테스트, 장애 전환과 부하 분산이 있으며 실제 지원 유형은 커널에 따라 달라집니다.

규칙은 보통 정책 그룹 이름을 가리키므로 출구 선택과 규칙 조건을 분리할 수 있습니다. 따라서 규칙을 수정하지 않고도 노드를 바꾸거나 선택 로직을 변경할 수 있습니다.

규칙 기반 라우팅은 도메인, IP, 포트, 프로세스 또는 규칙 집합 등의 조건에 따라 요청을 지정된 정책 그룹으로 전달합니다. 모든 트래픽을 하나의 노드로 고정하지 않고 대상별로 다른 출구를 사용하게 하는 기능입니다.

규칙은 일반적으로 선언 순서에 따라 위에서 아래로 매칭되므로, 너무 포괄적인 조건을 앞에 두면 뒤의 정밀한 규칙이 가려집니다. 라우팅 결과를 확인할 때는 먼저 연결 기록에서 실제로 매칭된 규칙을 확인하세요.

DIRECT는 요청이 원격 프록시 노드로 전달되지 않고 로컬 네트워크를 통해 대상 주소에 직접 연결됨을 의미합니다. 로컬 네트워크 리소스나 현재 네트워크 출구를 반드시 사용해야 하는 대상에 적합합니다.

직접 연결이라고 해서 Clash의 모든 처리를 우회하는 것은 아닙니다. 요청은 여전히 커널의 DNS, 규칙 판단 또는 TUN 라우팅을 거친 뒤 로컬 네트워크를 최종 출구로 사용할 수 있습니다.

REJECT는 조건에 맞는 연결 또는 요청을 거부함을 의미합니다. 특정 도메인, IP 주소 또는 규칙 집합의 트래픽을 차단할 때 주로 사용됩니다.

거부된 애플리케이션은 연결 즉시 실패, 대기 시간 초과 또는 리소스 로드 실패로 나타날 수 있으며, 구체적인 동작은 커널의 응답 방식과 애플리케이션의 네트워크 구현에 따라 다릅니다. 오탐 차단을 확인할 때는 규칙 순서와 규칙 집합 내용을 점검해야 합니다.

GeoIP는 데이터베이스를 사용해 IP 주소를 국가 또는 지역 코드로 분류하고 이를 기준으로 규칙을 매칭합니다. 네트워크 주소의 소속을 기준으로 대략적인 라우팅을 나눌 때 적합합니다.

데이터베이스 기록은 주소 할당에 따라 바뀌며, 콘텐츠 전송 네트워크는 위치에 따라 서로 다른 IP를 반환할 수 있습니다. GeoIP 결과를 서버의 정확한 물리적 위치로 해석해서는 안 됩니다.

MATCH는 규칙 목록의 최종 대체 조건으로, 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 일반적으로 규칙 영역의 마지막에 배치하며 범용 정책 그룹 또는 DIRECT를 가리킵니다.

MATCH가 목록 앞부분에 있으면 뒤의 규칙이 매칭될 기회를 얻기 어렵습니다. 라우팅이 예상과 다를 때는 대체 규칙의 위치와 대상 정책을 확인해야 합니다.

DNS는 도메인을 IP 주소 또는 다른 리소스 레코드로 변환하는 분산 시스템입니다. Clash 커널은 로컬 DNS 요청을 수신한 뒤 설정에 따라 서로 다른 상위 해석 서버로 조회를 보낼 수 있습니다.

DNS 성공은 해석 결과를 얻었다는 뜻일 뿐 대상 연결이 반드시 가능하다는 의미는 아닙니다. 연결에는 규칙 매칭, 라우팅 선택, 프록시 핸드셰이크와 대상 서비스의 응답도 필요합니다.

Fake-IP 모드는 먼저 도메인에 예약 주소를 반환하고 커널 내부에 해당 주소와 도메인의 매핑을 기록합니다. 애플리케이션이 이 예약 주소에 연결하면 커널이 원래 도메인을 복원해 규칙 매칭과 원격 해석을 계속 수행할 수 있습니다.

이 방식은 도메인 정보를 보존하는 데 유리하지만 실제 로컬 네트워크 주소에 의존하거나 특수한 DNS 검사를 수행하는 일부 애플리케이션은 필터 범위에 추가해야 할 수 있습니다. 필터를 조정할 때는 해당 도메인에 맞춰 처리하세요.

Redir-Host는 먼저 일반적인 DNS 해석을 수행한 뒤 실제 IP를 애플리케이션에 반환합니다. 이후 연결은 이 주소를 바탕으로 커널에 진입하므로 처리 경로가 Fake-IP와 다릅니다.

이 모드는 일부 로컬 네트워크와 특수 애플리케이션 환경에서 더 직관적일 수 있지만, 도메인 정보 보존 정도는 스니핑과 연결 방식의 영향을 받을 수 있습니다. 모드를 바꾼 뒤에는 도메인 규칙의 실제 매칭 결과를 다시 확인해야 합니다.

DNS 누출은 원래 지정된 해석 경로에서 처리하려던 조회가 시스템, 라우터, 브라우저 내장 기능 또는 다른 네트워크 소프트웨어에 의해 다른 해석기로 직접 전송되는 현상입니다. 일반적으로 DNS 제어 범위가 예상과 다름을 나타냅니다.

문제 해결 시 시스템 DNS 주소, 클라이언트 수신 포트, TUN의 DNS 하이재킹 설정, 브라우저 보안 DNS 설정과 다른 VPN을 확인해야 합니다. 상위 해석 서버 주소 하나만 바꾸는 것으로는 전체 경로를 파악하기 어렵습니다.

nameserver-policy는 도메인 조건에 따라 DNS 조회에 사용할 지정 상위 해석 서버를 선택합니다. 서로 다른 도메인을 다른 해석 서비스로 보내거나 특정 도메인에 고정된 해석 경로를 설정할 수 있습니다.

이 필드는 DNS 조회의 목적지만 처리하며 업무 연결이 프록시를 사용할지 직접 연결할지를 결정하지 않습니다. 연결 출구는 여전히 규칙과 정책 그룹이 결정합니다.

구독은 원격 주소에서 노드 목록 또는 전체 설정을 가져오는 업데이트 원본입니다. 클라이언트는 사용자의 조작이나 설정된 주기에 따라 콘텐츠를 다시 요청하고 결과를 사용 가능한 설정으로 저장합니다.

구독 응답은 YAML, 인코딩된 노드 목록 또는 서버에서 변환한 특정 형식일 수 있습니다. 가져오기에 실패하면 먼저 응답 내용과 상태를 확인한 다음 클라이언트가 지원하는 필드를 점검하세요.

YAML은 Clash 설정에 흔히 사용하는 구조화된 텍스트 형식으로, 공백 들여쓰기로 객체 계층을 표현하고 하이픈으로 목록 항목을 나타냅니다. 필드명 뒤의 콜론, 문자열 따옴표와 들여쓰기 깊이가 모두 파싱에 영향을 줍니다.

YAML에서는 탭과 공백을 들여쓰기에 섞어 사용하지 않아야 합니다. 같은 수준의 필드는 동일한 들여쓰기를 유지하고, 특수 기호가 포함된 값은 따옴표로 감싸 파싱의 모호성을 줄일 수 있습니다.

설정 파일은 포트, 실행 모드, DNS, 노드, 정책 그룹과 규칙 등의 필드를 저장하는 YAML 문서입니다. 커널은 시작할 때 설정을 읽고 수신기와 트래픽 전달 로직을 구성합니다.

그래픽 클라이언트는 YAML과 별도로 시작 시 실행, 시스템 프록시 스위치와 커널 경로 같은 인터페이스 설정을 저장할 수 있습니다. 설정 파일을 복사해도 이러한 클라이언트 환경 설정까지 동기화되지는 않습니다.

프록시 컬렉션은 일반적으로 proxy-providers로 정의하며, 독립 파일 또는 원격 주소에서 노드 그룹을 불러옵니다. 정책 그룹은 provider를 통해 이 노드를 참조할 수 있으므로 주 설정에 각 노드를 반복해서 작성할 필요가 없습니다.

컬렉션의 업데이트 간격, 저장 경로, 상태 확인과 형식은 각각 설정해야 합니다. 컬렉션 로드에 성공해도 그 안의 모든 노드가 연결된다는 뜻은 아닙니다.

오버라이드 및 병합은 클라이언트가 구독 콘텐츠에 로컬 필드를 추가, 교체 또는 결합하는 과정입니다. 사용자 지정 규칙 삽입, DNS 조정, 정책 그룹 추가 또는 로컬 포트 설정 유지 등에 활용됩니다.

클라이언트마다 병합 문법과 우선순위가 완전히 같지는 않습니다. 같은 이름의 필드에 적용되는 최종 값은 처리 순서에 따라 달라지므로 수정 후에는 오버라이드 조각만 보지 말고 클라이언트가 생성한 최종 설정을 확인해야 합니다.