노드
노드는 프록시 연결을 설정하는 서버 항목으로, 일반적으로 주소, 포트, 프로토콜 및 인증 정보가 포함됩니다. 클라이언트 화면에 표시되는 노드 이름은 주로 식별을 위한 것이며, 실제 연결 방식은 항목 내부의 프로토콜 매개변수가 결정합니다. 노드 연결 가능 여부는 로컬 네트워크, 원격 서버 상태 및 시스템 시간 등의 조건에도 영향을 받습니다.
구성 파일에서 낯선 필드를 발견했다면 먼저 이곳에서 어느 계층에 속하는지 확인해 보세요. 각 항목은 개념 자체와 일반적인 용도, 인접한 설정과의 관계를 설명합니다.
용어를 클릭하면 해당 설명으로 바로 이동합니다.
클라이언트가 프록시 정보를 가져오고 연결을 설정하는 방법과 테스트 결과를 해석하는 방법을 설명합니다.
노드는 프록시 연결을 설정하는 서버 항목으로, 일반적으로 주소, 포트, 프로토콜 및 인증 정보가 포함됩니다. 클라이언트 화면에 표시되는 노드 이름은 주로 식별을 위한 것이며, 실제 연결 방식은 항목 내부의 프로토콜 매개변수가 결정합니다. 노드 연결 가능 여부는 로컬 네트워크, 원격 서버 상태 및 시스템 시간 등의 조건에도 영향을 받습니다.
구독은 원격 구성 또는 프록시 항목 목록을 가져오는 주소입니다. 클라이언트에 가져온 뒤 설정한 주기에 따라 다시 받아 프록시, 프록시 그룹 및 규칙 변경 사항을 동기화할 수 있습니다. 구독을 업데이트하면 원격에서 제공하는 일부 내용이 덮어써질 수 있으므로, 장기간 유지할 개인 규칙은 구성 오버라이드에 넣는 편이 적합합니다.
프록시 프로토콜은 클라이언트와 원격 서버가 연결하고 인증하며 데이터를 전송하는 방식을 정의합니다. 프로토콜마다 지원하는 전송 계층, 암호화 매개변수 및 확장 필드가 다르므로 구성은 원격 서버와 일치해야 합니다. 특정 프로토콜 지원 여부는 코어 버전과 클라이언트의 패키징 방식에도 좌우됩니다.
지연 시간은 클라이언트가 지정된 테스트 주소로 요청을 보낸 뒤 응답을 받기까지 걸리는 시간입니다. 주로 연결 설정과 왕복 응답을 나타내며 다운로드 속도, 안정성 또는 장시간 전송 성능과는 다릅니다. 결과를 비교할 때는 모든 노드가 동일한 테스트 주소와 방식을 사용해야 합니다.
WebSocket은 일부 프록시 프로토콜에서 선택할 수 있는 전송 방식으로, 하나의 장기 연결을 통해 양방향으로 데이터를 전달합니다. 구성에서는 경로, 요청 헤더 또는 TLS 설정과 함께 사용되는 경우가 많습니다. 클라이언트와 원격 서버 중 어느 한쪽이라도 설정이 다르면 핸드셰이크에 실패하거나 연결이 조기에 종료될 수 있습니다.
Clash는 규칙을 위에서 아래로 확인하며, 처음 매칭된 규칙을 적용한 뒤 추가 매칭을 중단합니다.
규칙 설정은 도메인, IP, 프로세스 또는 규칙 집합에 따라 연결을 프록시 정책으로 보낼지, 직접 연결할지, 거부할지를 결정합니다. 대부분의 연결을 하나의 정책으로 보내는 글로벌 모드와 달리, 규칙 모드는 연결마다 규칙을 판단합니다. 라우팅 결과를 점검할 때는 규칙 순서, 대상 유형 및 최종 프록시 그룹을 함께 확인해야 합니다.
DOMAIN-SUFFIX는 도메인 접미사로 대상을 매칭합니다. example.com을 예로 들면 일반적으로 해당 도메인의 하위 도메인에도 적용되므로 같은 사이트 체계에 통일된 정책을 설정할 때 적합합니다. 하나의 전체 도메인만 매칭하려면 범위가 더 좁은 DOMAIN을 사용할 수 있습니다.
IP-CIDR은 CIDR 네트워크 표기법으로 대상 IP 주소를 매칭합니다. 끝의 no-resolve는 이 규칙이 매칭을 위해 도메인 조회를 적극적으로 실행하지 않음을 뜻하며, 불필요한 DNS 조회를 줄일 수 있습니다. 네트워크 길이가 매칭 범위를 결정하므로 입력 전에 네트워크 프리픽스가 정확한지 확인해야 합니다.
GeoIP는 대상 IP가 지리 데이터베이스에서 어느 지역에 속하는지를 기준으로 규칙을 적용합니다. 이미 IP 주소를 얻은 연결을 처리하는 데 적합하지만, 데이터베이스의 결과가 서비스 운영 주체나 실제 접속 환경을 의미하지는 않습니다. 라우팅 정확도는 데이터베이스 버전, IP 변경 및 DNS 조회 결과의 영향을 받습니다.
GEOSITE는 많은 도메인을 지역이나 용도별 그룹으로 정리해, 하나의 규칙으로 전체 분류를 참조할 수 있게 합니다. 도메인 정보를 매칭하는 기능이며 IP를 기준으로 분류하는 GeoIP와는 다른 계층입니다. 규칙 집합이 업데이트되면 분류에 포함된 도메인도 바뀔 수 있습니다.
MATCH는 규칙 목록 마지막에 두는 대표적인 최종 대체 항목으로, 앞선 규칙에 매칭되지 않은 연결을 처리합니다. 남은 트래픽을 모두 받을 수 있으므로 중간에 배치하면 뒤의 규칙이 매칭될 기회를 잃습니다. 구성을 확인할 때는 MATCH 뒤에 계속 적용되어야 할 일반 규칙이 없는지 확인해야 합니다.
그래픽 클라이언트는 조작 화면을 담당하고, 코어는 구성을 읽어 실제 네트워크 연결을 처리합니다.
mihomo는 Clash Meta의 기능을 계승한 오픈 소스 프록시 코어로, 구성을 해석하고 규칙 설정을 실행하며 DNS를 처리하고 네트워크 연결을 인계받습니다. 데스크톱이나 모바일 클라이언트는 일반적으로 그래픽 인터페이스에서 mihomo를 호출합니다. 특정 설정의 사용 가능 여부는 mihomo 버전과 클라이언트가 해당 기능을 제공하는지를 함께 확인해야 합니다.
Clash Meta는 Clash 생태계에서 프로토콜, 규칙, DNS 및 TUN 기능을 확장한 코어 브랜치의 이름입니다. 이후 프로젝트 명칭과 유지 관리 체계가 mihomo로 전환되면서 새 문서에서는 mihomo를 더 자주 볼 수 있습니다. 오래된 구성에 Meta라는 표기가 있다면 대개 코어의 출처나 호환 범위를 설명하는 것입니다.
YAML은 Clash 구성에 자주 사용하는 데이터 형식으로, 들여쓰기로 계층을 표현하고 키-값과 목록으로 설정을 구성합니다. 들여쓰기 오류, Tab과 공백의 혼용, 콜론 뒤 공백 누락은 파싱 실패를 일으킬 수 있습니다. 편집을 마친 뒤에는 클라이언트 로그에 구성 문법 오류가 보고되는지 먼저 확인해야 합니다.
config.yaml은 클라이언트에서 흔히 사용하는 기본 구성 파일 이름으로, 수신 포트, DNS, 프록시, 프록시 그룹 및 규칙을 저장할 수 있습니다. 일부 클라이언트는 구독마다 별도의 구성을 생성하므로 파일 이름이 항상 고정되지는 않습니다. 생성된 파일을 직접 수정하면 다음 구독 업데이트 때 덮어써질 수 있습니다.
프록시 그룹은 여러 프록시, 다른 프록시 그룹 또는 직접 연결 동작을 하나의 이름으로 묶고, 규칙에서 해당 이름을 참조하도록 합니다. 흔한 그룹 유형으로는 수동 선택, 자동 테스트 및 장애 전환이 있습니다. 프록시 그룹을 전환해도 해당 그룹을 참조하는 연결만 영향을 받으며 규칙 자체가 자동으로 수정되지는 않습니다.
Rule Provider는 규칙을 별도 파일이나 원격 리소스로 분리하고, 기본 구성에서 이름으로 참조하도록 합니다. 이를 통해 다운로드 주소, 업데이트 주기 및 규칙 동작을 각각 설정할 수 있습니다. 원격 내용을 불러오지 못하면 경로, 형식 유형, 저장 위치 및 현재 네트워크 상태를 확인해야 합니다.
DNS 설정은 도메인 조회 방식을 결정하며, 도메인 규칙이 완전한 매칭 정보를 유지할 수 있는지에도 영향을 줍니다.
DNS는 도메인을 네트워크 주소로 변환합니다. Clash는 조회를 인계받아 구성에 따라 로컬, 암호화 또는 지정된 상위 DNS 서버를 선택할 수 있습니다. 도메인은 접속되지 않지만 IP로는 연결되는 경우 DNS 경로를 우선 점검해야 합니다.
Fake-IP 모드는 먼저 앱에 예약 주소를 반환한 다음, 연결이 코어로 들어오면 원래 도메인을 복원합니다. 이를 통해 도메인 정보를 유지하고 도메인 규칙을 더 일찍 적용할 수 있습니다. 일부 LAN 서비스나 실제 DNS 결과에 의존하는 앱은 필터 목록에 추가해야 합니다.
Redir-Host 모드는 실제 DNS 조회 결과를 반환하고 도메인과 연결 사이의 매핑을 유지하려고 합니다. Fake-IP와의 주요 차이는 앱이 실제 주소를 전달받는다는 점입니다. 이 모드의 제공 여부와 구현 세부 사항은 클라이언트마다 다를 수 있으므로 코어 버전을 기준으로 확인해야 합니다.
DNS 누수는 도메인 조회가 예상한 DNS 경로를 우회해 시스템, 브라우저 또는 다른 네트워크 인터페이스에서 직접 전송되는 현상입니다. 이로 인해 실제 라우팅이 구성 의도와 달라질 수 있습니다. 점검할 때는 시스템 DNS, 브라우저 보안 DNS, TUN 인계 범위 및 Clash DNS 수신 상태를 함께 확인해야 합니다.
nameserver-policy는 도메인이나 규칙 집합별로 DNS 상위 서버를 지정해 조회마다 서로 다른 해석 경로를 사용하게 합니다. 지역별 DNS 조회나 특정 도메인에 고정된 DNS 서버가 필요한 경우에 적합합니다. 매칭 조건이 겹치면 구성 순서와 코어 규칙도 확인해야 합니다.
IPv6는 차세대 네트워크 주소 프로토콜로, IPv4와 함께 사용할 수 있습니다. Clash에서 IPv6를 활성화하면 DNS 조회, 수신 주소 및 출구 연결에 IPv6가 사용될 수 있습니다. 로컬 네트워크나 원격 출구의 지원이 불완전하면 일부 웹사이트만 연결에 문제가 생길 수 있습니다.
이 설정은 트래픽이 코어로 들어가는 방식과 운영체제의 앱을 인계받을 수 있는지를 결정합니다.
시스템 프록시는 운영체제의 프록시 설정을 Clash의 로컬 수신 포트로 지정합니다. 브라우저와 시스템 프록시 설정을 따르는 앱은 이 포트를 통해 연결을 전송합니다. 일부 게임, 명령줄 프로그램 및 독립 네트워크 구성 요소는 시스템 프록시를 읽지 않으므로 별도 설정이나 TUN 모드가 필요합니다.
TUN 모드는 가상 네트워크 인터페이스를 만들어 네트워크 계층에서 시스템 트래픽을 인계받습니다. 시스템 프록시 설정을 읽지 않는 앱에도 적용할 수 있지만, 일반적으로 시스템 권한이 필요하고 라우팅, DNS 및 방화벽 설정이 함께 관련됩니다. 시스템 프록시와 TUN은 서로 다른 사용 환경에 대응하므로 같은 스위치로 이해할 필요는 없습니다.
혼합 포트는 일반적으로 하나의 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받아 여러 로컬 앱이 하나의 진입점을 사용하게 합니다. 이는 로컬 수신 방식만 설명하며 원격에서 사용하는 프록시 프로토콜을 결정하지는 않습니다. 포트를 다른 프로그램이 사용 중이면 코어가 시작 로그에 수신 실패를 기록합니다.
LAN 연결을 허용하면 로컬 프록시 포트에 같은 네트워크의 다른 기기가 접속할 수 있습니다. 활성화한 뒤에는 수신 주소, 시스템 방화벽 및 기기가 속한 네트워크 대역도 확인해야 합니다. 연결을 공유할 때는 신뢰할 수 있는 네트워크에서만 사용하고, 제어 인터페이스가 신뢰할 수 없는 네트워크에 노출되지 않도록 해야 합니다.
구성 오버라이드는 구독 내용에 로컬 설정을 추가하거나 수정하는 기능으로, DNS, 규칙 및 포트 설정을 유지할 때 사용합니다. 구독 업데이트가 개인 설정에 미치는 영향을 줄일 수 있습니다. 클라이언트마다 병합, 스크립트 또는 패치 방식으로 구현하므로 필드 우선순위는 해당 클라이언트 문서를 확인해야 합니다.
GUI 클라이언트는 프록시 코어에 그래픽 인터페이스를 제공하며, 구성 가져오기, 정책 선택, 시스템 통합 및 로그 확인을 담당합니다. 클라이언트 이름과 실제 코어 이름이 다를 수 있고, 같은 클라이언트도 업데이트 과정에서 코어 버전을 바꿀 수 있습니다. 기능 지원 여부를 판단할 때는 클라이언트 버전, 코어 유형 및 현재 구성을 함께 확인해야 합니다.
필드의 의미를 이해했다면 시작 안내서에 따라 구독 가져오기, 정책 선택 및 연결 확인을 진행할 수 있습니다. 플랫폼별 설치 차이를 자세히 확인해야 한다면 전체 사용 문서로 이동하세요.