CONFIG.YAML / 용어 찾아보기

Clash 설정 용어 사전.

화면에 표시된 항목을 설정의 의미와 연결해 보세요. 5개 주제에서 자주 쓰이는 용어 25개를 살펴보고, 트래픽 가로채기·DNS 해석·규칙 선택을 구분해 서로 다른 문제를 혼동하지 않도록 정리했습니다.

단계별 가이드 보기 전체 문서 보기

코어와 클라이언트

사용 중인 앱과 코어, 설정 출처부터 확인하세요. 같은 이름의 버튼도 클라이언트에 따라 설정을 처리하는 방식이 다를 수 있습니다.

mihomo / Clash.Metamihomo 코어: mihomo는 Clash.Meta에서 발전한 프록시 코어로, 프로토콜 연결과 DNS 처리, 규칙 매칭 등을 담당합니다. Clash.Meta는 발전 과정에서 사용된 이전 이름입니다. GUI는 보통 코어를 관리하는 인터페이스일 뿐이며, GUI 업데이트와 코어 업데이트가 동시에 이루어지지는 않을 수 있습니다. 설정 필드가 지원되지 않는다면 앱 이름만 보지 말고 클라이언트의 정보 또는 코어 정보에서 실제 버전을 확인하세요.

client / GUI클라이언트: 클라이언트는 구독을 가져오고, 노드를 선택하고, 시스템 프록시를 설정하고, 코어를 관리하는 앱입니다. 실행 전에 구독 설정을 병합하거나 덮어쓰고 추가 설정을 적용할 수 있으므로, 구독 원본 파일을 수정해도 최종 적용 내용이 바뀌지 않을 수 있습니다. 문제를 확인할 때는 클라이언트의 스위치와 실제 실행 설정을 모두 살펴보세요. 앱을 선택할 때는 클라이언트 비교 리뷰를 참고하세요.

subscription / profile구독: 구독은 보통 노드나 전체 설정을 가져오는 원격 접속 경로를 뜻하며, 업데이트하면 해당 리소스를 다시 요청합니다. 응답은 전체 YAML일 수도 있고 노드 목록만 포함할 수도 있으므로 클라이언트나 변환 과정에서 형식을 확인해야 합니다. 모든 링크를 서로 바꿔 쓸 수 있는 것은 아닙니다. 링크에 개인 인증 정보가 포함되는 경우가 많으니 스크린샷, 공개 로그, 온라인 문의에 노출하지 마세요. 자세한 가져오기 방법은 구독 가져오기를 참고하세요.

proxies / server노드: 노드는 프록시 서버에 연결하는 데 필요한 설정 정보로, 보통 서버 주소, 포트, 프로토콜, 인증 정보를 포함합니다. 노드 이름에 표시된 지역은 제공자가 붙인 표기일 뿐, 서버의 진입 위치나 실제 접속 출구를 증명하지 않습니다. 노드 하나만 연결되지 않으면 같은 설정의 다른 노드로 먼저 비교해 보세요. 해당 서버에 연결할 수 없는지, 인증 정보가 만료됐는지, 로컬 트래픽 가로채기 설정에 문제가 있는지 구분할 수 있습니다.

config.yaml / indentationYAML 설정 형식: YAML은 설정 계층을 표현하는 텍스트 형식으로, 들여쓰기로 상위·하위 필드를 구분하고 목록 항목은 보통 하이픈으로 시작합니다. 탭 대신 공백을 사용하고 같은 계층의 필드는 들여쓰기를 맞춰야 합니다. 필드가 파일에 그대로 있어도 계층이 바뀌면 예상대로 적용되지 않을 수 있습니다. 수정 전 원본을 보관하고 한 번에 한 항목만 변경하세요. 먼저 클라이언트에서 설정을 검사한 뒤 실제 동작을 확인하는 것이 좋습니다.

프록시 프로토콜

로컬 앱이 프록시 접속 지점에 연결할 때 쓰는 프로토콜과 코어가 원격 노드에 연결할 때 쓰는 프로토콜은 서로 다릅니다. 설정을 입력하기 전에 어느 연결 구간에 해당하는 값인지 확인하세요.

HTTP / CONNECTHTTP 프록시: HTTP 프록시는 앱이 프록시 접속 지점에 요청을 전달하는 방식입니다. HTTPS 사이트에 접속할 때는 보통 CONNECT 메서드로 터널을 만듭니다. 대상 사이트가 HTTPS라고 해서 로컬 프록시 접속 지점도 TLS를 사용한다는 뜻은 아닙니다. 브라우저나 명령줄에 주소를 입력할 때는 클라이언트가 실제로 수신 중인 포트를 사용하세요. mixed-port를 사용하면 하나의 접속 지점에서 HTTP와 SOCKS 연결을 모두 받을 수 있습니다.

SOCKS5 / UDP ASSOCIATESOCKS5: SOCKS5는 앱에서 직접 지정할 수 있는 프록시 프로토콜입니다. TCP 연결을 지원하며 UDP 전달 방식도 정의하지만, 실제로 UDP를 전달할 수 있는지는 앱과 연결 경로 전체에 달려 있습니다. 일부 도구는 로컬에서 도메인을 해석할지 프록시 서버에 맡길지 선택할 수 있으며, 선택에 따라 DNS 경로가 달라집니다. 앱에서 SOCKS5를 설정했다면 이 설정도 함께 점검해야 합니다. 시스템 프록시만 확인해서는 부족할 수 있습니다.

ss / cipherShadowsocks: Shadowsocks는 코어와 원격 프록시 서버 사이에서 사용하는 암호화 프록시 프로토콜이며, 설정에서는 흔히 type: ss로 표시합니다. 주소, 포트, 암호화 방식, 비밀번호를 서버 설정과 일치시켜야 하며 일부 노드에는 추가 플러그인 설정이 필요합니다. 가져오기에 성공했다는 것은 설정을 인식했다는 뜻일 뿐, 인증과 네트워크 연결까지 성공했다는 의미는 아닙니다. 이전 버전 코어는 최신 암호화 방식을 지원하지 않을 수도 있습니다.

trojan / TLS / SNITrojan: Trojan은 보통 TLS 연결을 통해 프록시 트래픽을 전달하며, 비밀번호뿐 아니라 서버 이름과 인증서 검증도 확인해야 합니다. 연결 주소와 인증서의 도메인이 다르면 검증을 끄기보다 구독에 지정된 SNI 등의 설정을 확인하세요. 시스템 시간이 맞지 않거나 인증서가 만료됐거나 서버 이름이 잘못된 경우에도 핸드셰이크가 실패할 수 있습니다. 이는 일반 네트워크에서 서버가 응답하는지와는 별개의 문제입니다.

hysteria2 / QUICHysteria 2: Hysteria 2는 QUIC 기반 프록시 프로토콜로, 사용 중인 네트워크에서 해당 UDP 통신을 허용해야 합니다. 패킷 손실이 있는 일부 연결에서 유용할 수 있지만, 프로토콜 이름만으로 더 빠르다고 단정할 수는 없습니다. 같은 네트워크에서 TCP 기반 노드는 정상인데 Hysteria 2 노드만 계속 시간 초과된다면 UDP 제한, 서버 포트, 방화벽을 확인하세요. 대역폭 설정도 서버 측 요구 사항에 맞춰야 합니다.

작동 모드

트래픽 가로채기 방식은 요청이 코어에 들어오는지를 결정하고, 작동 모드는 코어에 들어온 요청을 어떻게 처리할지 결정합니다. 두 단계를 구분한 뒤 필요한 설정을 선택하세요.

mode: rule규칙 모드: 규칙 모드는 설정된 매칭 조건에 따라 코어로 들어온 연결을 직접 연결, 프록시 또는 차단 정책으로 보냅니다. 일반적으로 이 모드부터 사용하고 연결 목록에서 대상 도메인에 어떤 규칙이 적용됐는지 확인합니다. 규칙 모드가 모든 앱의 트래픽을 자동으로 코어에 넣어 주는 것은 아닙니다. 연결 목록에 대상 요청이 전혀 없다면 먼저 트래픽 가로채기 방식을 확인하세요. 모드 선택은 모드 선택하기를 참고하세요.

mode: global / GLOBAL전역 모드: 전역 모드는 코어로 들어온 연결을 전역 정책으로 처리하므로 규칙 때문에 접속 결과가 달라지는지 잠시 비교할 때 유용합니다. ‘전역’이라고 해서 기기의 모든 트래픽을 가로채는 것은 아닙니다. 시스템 프록시를 무시하는 앱은 코어를 우회할 수 있습니다. 테스트가 끝나면 규칙 모드로 되돌리고 전역 정책에서 선택된 노드를 확인하세요. 전역 그룹과 평소 사용하는 정책 그룹의 노드가 달라 결과를 잘못 판단할 수 있습니다.

system proxy / mixed-port시스템 프록시: 시스템 프록시는 운영체제에 프록시 주소와 포트를 등록해, 이 설정을 따르는 앱이 요청을 로컬 클라이언트로 보내도록 합니다. 일부 게임, 명령줄 도구, 자체 네트워크 스택을 사용하는 앱은 이 설정을 읽지 않으므로 스위치가 켜져 있어도 모든 트래픽이 가로채지는 것은 아닙니다. 클라이언트를 종료한 뒤에도 웹페이지에 접속할 수 없다면, 운영체제에 종료된 포트를 가리키는 프록시 설정이 남아 있는지 확인하세요.

tun / auto-routeTUN 모드: TUN은 가상 네트워크 인터페이스로 IP 패킷을 받고 라우팅 설정을 통해 트래픽을 코어로 전달하므로, 시스템 프록시를 따르지 않는 일부 앱도 처리할 수 있습니다. 데스크톱 운영체제에서는 관리자 권한, 서비스 또는 드라이버가 필요할 수 있고, 모바일에서는 VPN 권한을 사용합니다. 켜지지 않으면 먼저 권한과 다른 VPN 앱의 충돌 여부를 확인하세요. TUN은 트래픽을 받아들이는 경로일 뿐 DNS 경로나 규칙 기반 트래픽 분할까지 자동으로 올바르게 설정해 주지는 않습니다.

url-test / timeout지연 시간 테스트: 클라이언트의 지연 시간 테스트는 보통 노드를 통해 지정한 주소에 접속하는 데 걸리는 시간을 측정합니다. 핸드셰이크 등이 측정에 포함되는지는 구현에 따라 다릅니다. 다운로드 속도 측정과는 다르며, 테스트 주소와 제한 시간, 네트워크 상태가 다른 결과를 직접 비교해서는 안 됩니다. 시간 초과가 발생해도 모든 웹사이트에 접속할 수 없는 것은 아닙니다. 실제 접속과 로그를 함께 확인하세요. 자세한 방법은 노드 지연 시간 문제를 참고하세요.

DNS와 이름 해석

DNS 조회 요청과 실제 연결은 서로 다른 경로를 사용할 수 있습니다. 설정을 살펴볼 때는 어떤 주체가 어디에 조회를 보내는지, 조회 연결은 무엇이 처리하는지 함께 확인하세요.

dns / nameserverDNS 이름 해석: DNS는 도메인을 IP 주소 등의 레코드로 변환해 앱이 연결할 대상을 찾도록 합니다. 운영체제, 브라우저, 앱, 프록시 코어가 각각 결과를 캐시하거나 조회할 수 있으므로 코어 DNS를 변경해도 기존 연결이 바로 달라지지 않을 수 있습니다. 도메인으로 접속하면 실패하지만 IP 주소로는 되는 경우 조회 로그와 캐시를 확인하세요. 다만 인증서나 가상 호스트 설정 때문에 IP 주소로 직접 접속해도 실패할 수 있습니다.

enhanced-mode: fake-ipFake-IP 가상 주소: Fake-IP는 앱에 가상 주소를 돌려주고 코어에 주소와 도메인 간 매핑을 저장해 이후 연결에서도 도메인 규칙을 적용할 수 있게 합니다. 가상 주소가 표시된다고 실제 서버 주소로 해석된 것은 아니며, 설정에 문제가 있다는 뜻도 아닙니다. 일부 로컬 네트워크 서비스나 앱이 이 방식과 호환되지 않으면 해당 도메인에 대해 fake-ip-filter를 확인하세요. DNS 모듈 전체를 끌 필요는 없습니다.

DNS leak / resolver pathDNS 유출: DNS 유출은 조회 요청이 예상한 경로를 벗어나 다른 DNS 서버에 도달하는 현상입니다. 중요한 것은 사전에 정한 정책에 맞게 처리됐는지 여부입니다. 검사 페이지에 표시된 DNS 서버의 지역은 참고 정보일 뿐, 통신사가 특정 조회 내용을 알았다는 증거가 될 수는 없습니다. 브라우저의 암호화 DNS, 시스템 설정, TUN 가로채기, 연결 로그를 함께 확인하세요. 직접 연결 도메인이 의도적으로 로컬 DNS를 사용한다면 이를 모두 이상으로 볼 필요는 없습니다.

DoH / DoT암호화 DNS: DoH는 HTTPS로 DNS 조회를 전송하고 DoT는 TLS를 사용합니다. 조회 전송을 보호하지만 DNS 조회가 자동으로 프록시 노드를 거치는 것은 아닙니다. DNS 서비스는 전달받은 도메인 요청을 처리하며, 연결 경로도 별도로 확인해야 합니다. 도메인으로 지정한 상위 DNS 서버를 설정할 때는 해당 서버 주소를 처음에 어떻게 해석할지도 고려해 DNS 조회가 반복되는 순환 구조를 피하세요.

nameserver-policy도메인별 DNS 서버 선택: nameserver-policy는 도메인이나 지원되는 매칭 조건에 따라 사용할 상위 DNS 서버를 지정합니다. 예를 들어 내부 도메인을 조직 내부 DNS 서버에서 해석하도록 설정할 수 있습니다. 이 설정은 DNS 서버 선택에 영향을 줄 뿐 실제 연결의 최종 출구를 바꾸지는 않으므로 규칙 기반 트래픽 분할과 함께 연결 경로를 확인해야 합니다. 이 필드는 dns 계층 안에 작성하며, 복잡한 매칭 문법은 현재 코어의 지원 여부를 확인하세요. 다른 버전의 예시를 그대로 복사하지 않는 것이 좋습니다.

규칙과 트래픽 분할

규칙은 연결을 매칭하고 정책 그룹은 경로를 선택하며, 제공자는 리소스를 불러옵니다. 이름이 비슷한 설정 항목도 담당하는 역할은 서로 다를 수 있습니다.

rules / DIRECT / REJECT / MATCH규칙 기반 트래픽 분할: 규칙 기반 트래픽 분할은 도메인, IP 주소 등의 조건에 따라 연결을 해당 정책으로 보냅니다. 일반적인 rules 목록은 위에서 아래로 검사하고 처음 일치하는 규칙이 경로를 결정합니다. DIRECT는 직접 연결, REJECT는 차단을 뜻하며, 마지막의 MATCH는 흔히 다른 규칙에 일치하지 않은 트래픽을 처리합니다. 예외 규칙은 먼저 적용될 수 있는 포괄적인 규칙보다 위에 배치하고 연결 기록으로 결과를 확인하세요.

proxy-groups / select / url-test정책 그룹: 정책 그룹은 노드나 다른 정책을 규칙에서 참조할 수 있는 대상으로 묶습니다. 수동 선택, 지연 시간 기반 선택, 장애 조치 유형이 자주 쓰입니다. 그룹을 바꿔도 모든 연결이 새 노드를 사용하는 것은 아닙니다. 규칙이 다른 그룹을 가리킬 수 있고, 이미 연결된 세션은 이전 경로를 계속 사용할 수도 있습니다. 테스트할 때는 먼저 어떤 그룹이 적용됐는지 확인한 다음 그룹에서 실제로 선택된 항목을 살펴보고, 필요하면 대상 연결을 새로 만드세요.

GEOIP / geodataGeoIP 주소 지역 정보: GeoIP는 주소 데이터베이스를 사용해 대상 IP의 지역 등 소속 정보를 판단하며, 주소 범위에 따라 트래픽을 분할할 때 자주 사용합니다. 데이터베이스에는 업데이트 주기와 오차가 있으므로 결과를 기기 위치나 서비스 운영 회사의 소재지와 동일하게 볼 수 없습니다. 예상과 다른 규칙이 적용되면 실제 대상 IP와 데이터베이스 출처, 업데이트 상태를 확인하세요. 설정에서 no-resolve를 사용하는지도 도메인 연결의 매칭 과정에 영향을 줍니다.

rule-providers / RULE-SET규칙 제공자: rule-providers는 로컬 또는 원격 규칙 모음을 불러와 큰 도메인·주소 목록을 기본 설정에서 분리해 관리하는 데 사용합니다. 제공자를 선언하는 것만으로 트래픽 분할에 적용되지는 않습니다. 규칙 목록에서 RULE-SET 등의 방식으로 참조하고 연결 경로도 지정해야 합니다. 업데이트에 실패하면 리소스 주소와 콘텐츠 형식, 동작 유형이 맞는지 확인하세요. 다운로드 성공을 규칙 적용 성공으로 오해하지 않도록 주의해야 합니다.

proxy-providers / use노드 제공자: proxy-providers는 노드 목록을 별도로 불러오고 업데이트하며, 보통 정책 그룹에서 use로 참조합니다. 클라이언트 전체 설정 구독과는 다르므로 모드, DNS, 규칙 설정을 대신할 수 없으며, 응답 리소스도 코어가 요구하는 형식이어야 합니다. 제공자를 업데이트한 뒤에도 그룹이 비어 있다면 참조 이름, 필터 조건, 로딩 로그를 확인하세요. 자주 발생하는 문제의 해결 방법은 구독 업데이트 실패를 참고하세요.