CLASH / CONFIG DICTIONARY

Clash 용어와 설정 필드

mihomo 코어부터 DNS 가로채기까지 설정이 속한 계층별로 용어를 찾아보세요. 용어부터 구분한 뒤 필드를 수정하면 프로토콜 문제를 들여쓰기 문제로 오인하는 일을 줄일 수 있습니다.

01 / CORE & CLIENT

코어와 클라이언트

클라이언트는 관리를 담당하고 코어는 연결을 처리합니다. 구독과 노드는 입력 데이터이므로 각 계층을 나누어 문제를 확인해야 합니다.

mihomo 코어 core / Clash Meta 기술 계열: mihomo는 프록시 연결, 규칙 매칭과 DNS 요청을 처리하는 네트워크 코어로, Clash Meta의 기술 흐름을 이어갑니다. GUI 클라이언트는 보통 mihomo를 백그라운드 프로세스로 실행하므로 클라이언트 버전과 코어 버전은 서로 다릅니다. 지원되지 않는 필드나 로드되지 않는 프로토콜이 있다면 앱 이름만 보지 말고 실제 실행 중인 코어 버전부터 확인하세요.

GUI 클라이언트 GUI / 설정 관리와 시스템 연동: GUI 클라이언트는 구독 관리, 정책 선택, 로그 확인과 시스템 프록시 설정을 클릭 가능한 화면에서 처리할 수 있게 합니다. 특정 기능을 사용할 수 있는지는 코어 지원 여부뿐 아니라 앱에서 해당 기능을 제공하는지, 시스템 권한이 있는지에 따라서도 달라집니다. 클라이언트를 옮길 때는 설정 내용과 앱 설정을 따로 확인하세요. 앱 설정은 보통 구독과 함께 옮겨지지 않습니다.

노드 proxy / 원격 연결 설정: 노드는 프록시 서버에 연결할 때 필요한 설정값의 묶음으로, 보통 서버 주소, 포트, 프로토콜, 인증 정보와 전송 설정을 포함합니다. 노드 이름은 목록에 표시되는 이름일 뿐 특정 지역으로 적혀 있다고 실제 접속 경로가 그 지역을 통과하는 것은 아닙니다. 문제를 확인할 때는 도메인 조회 실패, 포트 연결 실패, 인증 실패를 구분해야 합니다. 모드를 계속 바꾸는 것만으로는 해결되지 않습니다.

구독 subscription / 설정 배포: 구독은 주소를 통해 노드나 전체 설정을 배포하고 업데이트합니다. 형식에 따라 노드만 포함할 수도 있고 정책 그룹과 규칙까지 포함할 수도 있습니다. 업데이트 성공은 가져오기와 파싱이 끝났다는 뜻일 뿐, 모든 노드의 연결을 보장하지는 않습니다. 링크에 계정 인증 정보가 포함될 수 있으므로 로그나 스크린샷을 공유하거나 구독 변환을 할 때 제삼자에게 링크가 전달되는지 먼저 확인하세요.

지연 시간 테스트 latency / 지정 대상 요청 시간: 클라이언트는 노드를 거치는 테스트 요청을 보내 응답 시간을 표시하는 경우가 많습니다. 테스트 주소, 시간 제한 설정, 연결 재사용 여부에 따라 결과가 달라집니다. 단순한 서버 ping이나 다운로드 속도 테스트와는 다릅니다. 특정 노드의 테스트가 시간 초과되더라도 일부 웹사이트에 접속할 수 있다면 테스트 대상에 접근 가능한지 확인하세요. 노드를 비교할 때는 테스트 조건을 먼저 통일해야 합니다.

02 / PROXY PROTOCOLS

프록시 프로토콜

프로토콜은 연결을 설정하는 방식을 정의하며 전송 방식과 TLS는 별도 설정 계층입니다. 이름이 비슷해도 설정값을 서로 바꿔 쓸 수 있는 것은 아닙니다.

Shadowsocks SS / 암호화 프록시 프로토콜: Shadowsocks는 널리 쓰이는 암호화 프록시 프로토콜입니다. 연결하려면 서버 주소, 포트, 암호화 방식과 비밀번호가 서버 설정과 일치해야 합니다. 일부 설정은 특정 프로토콜 버전이나 플러그인 지원도 필요하므로 주소와 비밀번호만 복사해서는 충분하지 않을 수 있습니다. 가져온 뒤 암호화 방식을 지원하지 않는다는 오류가 나오면 코어의 지원 여부와 원본 설정을 확인하세요. 임의로 암호화 방식 이름을 바꾸어도 서버 설정은 바뀌지 않습니다.

VMess 사용자 식별자 / 전송 설정: VMess는 사용자 식별자 등의 설정값으로 프록시 연결을 수립하며 여러 하위 전송 방식을 사용할 수 있습니다. 프로토콜 인증, WebSocket 같은 전송 설정, TLS 인증서 검증은 각각 별개의 단계이므로 어느 한 곳이라도 맞지 않으면 연결이 실패할 수 있습니다. 문제를 확인할 때 원본 설정의 사용자 식별자, 전송 유형, 경로와 서버 이름을 대조하고 시스템 시간이 크게 어긋나 있지 않은지도 확인하세요.

VLESS 경량 프로토콜 / 보안 계층 조합: VLESS는 가벼운 프록시 프로토콜로, 보통 TLS나 REALITY 같은 보안 기능과 함께 사용합니다. 프로토콜 이름만으로 전체 연결이 암호화된다고 볼 수는 없습니다. 클라이언트가 사용 중인 전송 방식, 보안 기능과 각 설정 조합을 모두 지원해야 합니다. 가져오기에 실패하면 코어가 보고한 구체적인 필드를 확인하세요. GUI에 VLESS 옵션이 있다고 해서 관련 설정을 모두 지원하는 것은 아닙니다.

Trojan TLS / 비밀번호 인증: Trojan은 일반적으로 TLS를 통해 프록시 트래픽을 전달합니다. 연결하려면 비밀번호가 올바르고 인증서 검증 조건도 충족해야 합니다. 서버 이름, 인증서 체인이나 시스템 시간이 잘못되면 포트에 연결되더라도 핸드셰이크가 실패할 수 있습니다. 인증서 오류가 발생하면 서버 이름과 인증서 상태부터 확인하세요. 검증을 건너뛰면 서버 신원 확인이 약해지므로 일반적인 해결책으로 사용하면 안 됩니다.

Hysteria 2 QUIC / UDP 네트워크 조건: Hysteria 2는 QUIC 기반 프록시 프로토콜로, 네트워크 경로에서 해당 UDP 트래픽을 허용해야 합니다. 일반 HTTPS에 접속할 수 있다고 해서 이 연결도 허용되는 것은 아닙니다. 같은 서버의 TCP 포트 연결 여부로 UDP 연결 상태를 대신 판단할 수도 없습니다. 이런 유형의 노드만 실패한다면 먼저 네트워크를 바꿔 결과를 비교한 뒤 인증 정보, 인증서와 서버 설정을 확인하세요.

03 / RULES & ROUTING

규칙과 라우팅

먼저 트래픽이 코어로 들어오는지 확인한 다음 어떤 규칙에 매칭되는지 살펴보세요. 가로채지 않은 연결은 규칙을 추가해도 자동으로 코어에 들어오지 않습니다.

규칙 기반 라우팅 mode: rule / 순서대로 매칭: 규칙 기반 라우팅은 연결이 코어에 들어온 뒤 도메인이나 IP 등의 조건에 따라 직접 연결할지, 차단할지, 특정 프록시 정책을 사용할지 결정합니다. rule 모드에서는 보통 목록을 위에서 아래로 확인하다가 규칙이 매칭되면 멈추므로, 구체적인 도메인 규칙을 범위가 넓은 규칙보다 앞에 배치해야 합니다. 수정한 뒤에는 연결 상세 정보에서 매칭된 규칙과 최종 정책을 확인하세요. 설정이 저장됐다는 사실만으로 라우팅이 의도대로 동작한다고 볼 수는 없습니다.

GeoIP GEOIP / IP 지리 데이터베이스: GeoIP는 대상 IP의 지리 데이터베이스 기록을 기준으로 매칭합니다. 예를 들어 GEOIP,CN,DIRECT와 같이 사용할 수 있습니다. 도메인 접미사를 기준으로 판단하지 않으며, CDN 주소 변경이나 데이터베이스 업데이트에 따라 결과가 달라질 수 있습니다. 일부 IP 규칙은 도메인 조회를 유발하므로 문제를 확인할 때 조회 결과, 데이터베이스 상태와 no-resolve 설정도 함께 살펴보세요.

GeoSite GEOSITE / 분류별 도메인 목록: GeoSite는 도메인을 서비스나 주제별 목록으로 정리하므로 모든 도메인을 하나씩 나열하지 않고 목록 이름으로 규칙을 지정할 수 있습니다. 어떤 분류가 있는지, 분류마다 어떤 도메인이 포함되는지는 사용하는 데이터 파일과 버전에 따라 달라집니다. 규칙 로드 오류가 발생하면 해당 분류가 있는지 먼저 확인하세요. 일부 리소스만 잘못된 정책을 사용한다면 관련 하위 도메인이 목록에 포함되어 있는지 확인하세요.

정책 그룹 proxy-groups / 노드 선택 방식: 정책 그룹은 여러 노드나 다른 정책을 묶어 수동 선택, 테스트 결과에 따른 선택, 장애 조치 등을 제공합니다. 규칙에서 지정하는 그룹 이름은 설정에 정의된 이름과 정확히 일치해야 하며, 이름을 바꿨다면 참조하는 규칙도 함께 수정해야 합니다. 자동 선택은 테스트 대상과 검사 주기에 따라 달라지며 각 웹사이트의 실시간 사용 환경을 반영하지는 않습니다. 자동이라는 이름만 보고 안심하기보다 그룹 유형과 동작 방식을 확인하세요.

MATCH 기본 규칙 / 마지막 규칙: MATCH는 앞선 규칙에 매칭되지 않은 연결을 처리하며, 보통 규칙 목록의 마지막에 배치합니다. 예를 들면 MATCH,PROXY와 같습니다. 이때 PROXY는 실제로 설정에 존재하는 정책 이름이어야 하며 어디에나 그대로 쓸 수 있는 예약된 그룹 이름이 아닙니다. 기본 규칙은 이미 코어에 들어온 트래픽만 처리하므로 시스템 프록시나 TUN을 통한 트래픽 가로채기를 대신할 수 없습니다.

04 / DNS & NETWORK STACK

DNS와 네트워크 스택

트래픽 가로채기와 도메인 조회는 서로 연결되어 있지만 별개의 경로입니다. 한쪽 설정을 활성화했다고 다른 쪽까지 설정된 것은 아닙니다.

TUN 모드 가상 네트워크 인터페이스 / 라우팅 가로채기: TUN 모드는 가상 네트워크 인터페이스와 라우팅을 이용해 조건에 맞는 트래픽을 코어로 전달하므로 시스템 프록시를 사용하지 않는 일부 앱에도 적용할 수 있습니다. 실제로 트래픽을 가로챌 수 있는지는 시스템 권한, 라우팅, 제외 항목과 다른 VPN 앱의 영향을 받으므로 모든 연결이 반드시 프록시를 거치는 것은 아닙니다. 활성화에 실패하면 서비스 권한과 시작 로그를 확인하고, 활성화한 뒤에는 라우팅과 DNS 동작을 검증하세요. 스위치 상태만 확인해서는 충분하지 않습니다.

Fake-IP enhanced-mode: fake-ip / 도메인 매핑: Fake-IP 모드는 앱에 매핑된 주소를 반환하고 코어에 매핑 정보를 보관해, 이후 연결에서도 원래 도메인을 식별하고 규칙을 매칭할 수 있게 합니다. 앱에 매핑용 IP 대역이 표시되는 것은 정상적인 동작이며 DNS가 고장 났다는 뜻이 아닙니다. 실제 IP가 필요한 앱은 fake-ip-filter에 예외를 추가해야 할 수 있습니다. 문제가 발생하는 도메인만 필터링하고 모든 도메인을 예외로 지정하지 않도록 주의하세요.

DNS 누수 DNS 조회 경로 / 예상 경로를 벗어난 요청: DNS 누수는 조회 요청이 예상한 경로를 벗어나는 현상입니다. 예를 들어 지정한 DNS 경로를 거쳐야 할 요청이 다른 리졸버로 직접 전송될 수 있습니다. 테스트 사이트에 특정 지역의 DNS 서버가 표시된다는 사실만으로 누수라고 판단할 수는 없습니다. 직접 연결 규칙과 업스트림 설계도 함께 확인해야 합니다. 시스템 DNS, 브라우저 보안 DNS, 다른 VPN과 암호화 DNS 설정을 살펴보고, 설정을 바꾼 뒤에는 같은 조건으로 다시 테스트하세요.

dns-hijack tun.dns-hijack / DNS 가로채기 설정: dns-hijack는 TUN 설정에서 조건에 맞는 DNS 트래픽을 코어의 내장 리졸버로 전달하는 기능입니다. 기존 DNS 포트를 가로채더라도 브라우저가 보내는 모든 암호화 DNS 요청을 자동으로 찾아 차단하는 것은 아닙니다. 규칙을 올바르게 설정했는데도 DNS 요청이 다른 경로로 빠진다면 요청이 TUN을 통과하는지, 앱이 DoH나 DoT를 별도로 사용하는지 확인하세요.

nameserver와 fallback DNS 업스트림 / 결과 선택 조건: nameserver는 내장 DNS에서 사용할 업스트림 리졸버를 지정하고, fallback은 필터 조건과 함께 DNS 결과를 선택하는 데 사용합니다. 이를 단순히 “기본 리졸버가 시간 초과되면 사용하는 대체 주소”로 이해하면 안 됩니다. fallback-filter 등 관련 설정도 확인해야 합니다. 도메인별 정책이나 규칙 준수 옵션을 활성화했다면 해당 설정도 함께 살펴 DNS 경로 문제를 특정 업스트림의 장애로 오해하지 않도록 하세요.

문제를 더 확인하려면 DNS 누수 확인 및 Fake-IP 수정 방법을 참고하거나 mihomo DNS 설정 필드별 설명을 확인하세요.

05 / YAML & CONFIG FIELDS

설정 파일 필드

필드 값, 설정 계층과 실제로 적용되는 파일을 함께 확인해야 합니다. 클라이언트 화면의 입력 항목 이름이 YAML 필드 이름과 같지 않을 수도 있습니다.

YAML 설정 형식 / 들여쓰기로 계층 표현: YAML은 Clash 계열 설정에서 흔히 사용하는 데이터 형식입니다. 들여쓰기로 부모와 자식 관계를 나타내고 하이픈으로 목록 항목을 표시합니다. 탭 대신 공백으로 들여쓰고 같은 계층의 들여쓰기 폭을 통일해야 합니다. 특수 문자가 포함된 문자열은 문법에 맞게 인용해야 합니다. 파싱에 성공해도 형식이 올바르다는 뜻일 뿐 현재 코어가 필드를 지원한다는 의미는 아니므로 로드 로그와 최종 설정을 확인해야 합니다.

mixed-port HTTP + SOCKS / 프록시 수신 포트: mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받습니다. 예시로 7890을 자주 사용하지만 실제 포트는 현재 실행 중인 설정을 기준으로 확인해야 합니다. 앱에 입력한 프록시 주소와 포트는 코어가 실제로 수신 중인 주소 및 포트와 일치해야 합니다. 포트가 사용 중이라는 로그가 나오면 충돌하는 프로세스를 종료하거나 포트를 변경하고, 해당 포트를 사용하는 시스템 및 앱 설정도 함께 수정하세요.

allow-lan LAN 접근 / 수신 범위: allow-lan은 LAN 기기에서 클라이언트의 프록시 수신 서비스에 접근할 수 있는지를 설정하며, 현재 기기에서 프록시를 활성화하는 기능은 아닙니다. true로 설정해도 실제 연결 가능 여부는 바인딩 주소, 방화벽과 Wi-Fi 네트워크 격리 등에 따라 달라집니다. 프록시를 공유해야 한다면 신뢰할 수 있는 기기만 접근하도록 제한하고 필요에 따라 인증을 설정하세요. 프록시 수신 포트를 인터넷에 직접 공개하지 마세요.

external-controller 컨트롤 API / 프록시 포트가 아님: external-controller는 관리 인터페이스의 수신 주소를 지정합니다. 관리 패널은 이 인터페이스를 통해 연결을 조회하고 정책을 전환하는 등 관리 작업을 수행합니다. mixed-port와 용도가 다르므로 관리 포트를 브라우저의 프록시 설정에 입력해도 웹 트래픽이 프록시되지 않습니다. 우선 로컬에서만 접근할 수 있도록 제한하고 컨트롤 인터페이스 인증을 설정하세요. 원격 접근을 허용하기 전에 방화벽과 네트워크 노출 범위도 확인해야 합니다.

오버라이드 override / 클라이언트 설정 병합 기능: 오버라이드는 일반적으로 클라이언트가 구독 설정에 로컬 필드를 병합하거나 규칙을 추가하고 설정 수정 스크립트를 실행하는 기능을 말합니다. 모든 클라이언트에 공통으로 적용되는 최상위 필드는 아닙니다. 로컬 DNS, 포트나 라우팅 설정을 유지해 구독 업데이트 후 반복해서 수정하는 일을 줄일 수 있습니다. 구현에 따라 목록을 추가하거나 덮어쓸 수 있으므로 수정 후에는 오버라이드 편집기의 내용만 보지 말고 생성된 최종 설정을 확인해야 합니다.

분류 목차로 돌아가기 ↑ 설정 가이드 보기