Clash 용어 가이드

구독은 링크를 통해 프록시 설정을 가져와 업데이트하는 방식입니다. 전체 Clash YAML을 받을 수도 있고, 변환이 필요한 노드 목록만 받을 수도 있습니다. 가져오기 전에 서버에서 제공하는 형식이 클라이언트와 호환되는지 확인하고, 업데이트한 뒤에는 해당 설정이 현재 활성화되어 있는지도 살펴보세요.

구독 링크에는 계정 정보가 포함되는 경우가 많으므로 공개 스크린샷이나 게시물에 노출되지 않도록 주의하세요. 가져오는 방법은 구독 가져오기 가이드에서 확인할 수 있습니다.

노드는 프록시 서버에 연결할 때 필요한 설정 정보로, 보통 서버 주소, 포트, 프로토콜, 인증 정보를 포함하며 설정의 proxies 아래에 표시됩니다. 정책 그룹에서 노드를 선택하더라도 규칙이 해당 그룹으로 보낸 연결에만 적용됩니다.

노드 이름은 설정에서 구분하기 위한 표시일 뿐, 실제 연결 경로의 위치나 대역폭, 사용 가능 여부를 보장하지 않습니다. 실제 접속 결과와 연결 로그를 함께 확인하세요.

클라이언트는 보통 지정된 프록시를 통해 테스트 주소에 요청을 보내고 요청에 걸린 시간을 표시합니다. 정확한 측정 방식은 구현에 따라 다릅니다. 테스트 URL, 연결 핸드셰이크, 서버 응답, 네트워크 상태가 결과에 영향을 주므로 다운로드 속도와 동일하게 볼 수 없습니다.

테스트 시간 초과는 테스트 주소에 연결할 수 없다는 뜻일 수 있으며, 테스트에 성공해도 모든 웹사이트에 접속할 수 있는 것은 아닙니다. 노드를 선택한 뒤에는 실제 대상 사이트에 접속하고 연결 목록에서 사용된 연결 경로를 확인하세요.

YAML은 Clash 설정에 널리 쓰이는 구조화된 텍스트 형식입니다. 들여쓰기로 계층을 나타내고 하이픈으로 목록 항목을 표시합니다. 편집할 때는 공백을 사용하고 같은 수준의 들여쓰기를 일관되게 유지하세요. 특수 문자가 포함된 값은 YAML 문법에 맞게 따옴표로 묶어야 합니다.

문법을 해석할 수 있어도 설정이 실행된다는 뜻은 아닙니다. 현재 커널이 해당 항목을 지원하는지, 참조한 정책 그룹이 존재하는지, 클라이언트가 시작할 때 설정을 덮어쓰는지 확인해야 합니다.

SOCKS5는 앱과 프록시 진입점 사이에서 사용하는 프로토콜로 TCP 연결을 처리할 수 있습니다. UDP를 전달하려면 앱과 프록시 구현이 모두 이를 지원해야 합니다. 앱에서 로컬 SOCKS 진입점을 사용할 때는 보통 루프백 주소를 입력하고, 포트는 클라이언트의 실제 수신 설정을 확인하세요.

도메인 조회를 프록시에 맡길지는 앱의 연결 방식에 따라 달라집니다. SOCKS5를 선택해도 원격 DNS 조회를 활성화하지 않았다면 로컬에서 먼저 DNS 조회가 이루어질 수 있습니다.

HTTP 프록시는 앱에서 보낸 프록시 요청을 받으며, HTTPS 대상에 연결할 때는 보통 CONNECT 방식으로 터널을 만듭니다. 브라우저, 명령줄 도구, 개발 환경에서 흔히 지원하지만 시스템 프록시 설정을 자동으로 사용하는 것은 아닐 수 있습니다.

설정 화면의 HTTPS 프록시 항목은 HTTPS 웹사이트에 접속할 때 사용하는 프록시를 뜻할 수 있으며, 프록시 진입점까지 TLS로 연결한다는 의미는 아닐 수 있습니다. 앱 안내에 따라 프로토콜과 포트를 입력하세요.

Shadowsocks는 정해진 암호화 방식과 키를 사용해 프록시 트래픽을 전송합니다. Clash 설정에서는 보통 type: ss로 유형을 지정합니다. 서버 주소, 포트, 암호화 방식, 비밀번호는 서버 설정과 일치해야 하며, 프로토콜 이름만으로 나머지 값을 추측해서는 안 됩니다.

커널마다 지원하는 암호화 방식이 다를 수 있습니다. 설정을 불러올 수 없다면 먼저 지원 범위를 확인하세요. 프로토콜 유형만으로 노드 속도나 현재 네트워크에서의 사용 가능 여부를 알 수는 없습니다.

Trojan은 보통 TLS 연결에서 인증을 수행하고 프록시 요청을 전달합니다. 주소, 포트, 비밀번호 외에 서버 이름과 전송 설정이 필요할 수도 있습니다. 서버 이름은 TLS 연결 과정에 사용되므로 서버 인증서와 배포 설정에 맞춰야 합니다.

연결에 실패하면 시스템 시간, 인증서, 서버 이름, 포트가 올바른지 확인하세요. 인증서 검증을 끄면 서버 신원 확인을 건너뛰므로 일반적인 해결 방법으로 사용해서는 안 됩니다.

규칙 기반 라우팅은 도메인이나 대상 주소 등의 조건에 따라 연결을 직접 연결, 차단 또는 지정된 정책 그룹으로 보냅니다. Rule 모드에서는 보통 위에서 아래로 규칙을 확인하며, 먼저 일치한 규칙이 연결 경로를 결정합니다. 따라서 구체적인 조건을 MATCH 같은 기본 규칙보다 앞에 배치해야 합니다.

예를 들어 DOMAIN-SUFFIX,github.com,PROXY는 일치하는 도메인의 연결을 PROXY라는 경로로 보냅니다. 이 이름은 설정에 존재해야 합니다. 구체적인 설정 방법은 규칙 기반 라우팅 가이드에서 확인하세요.

정책 그룹은 규칙에서 선택할 수 있는 연결 경로를 모아 둔 것입니다. 노드, 다른 정책 그룹 또는 설정에서 허용하는 기본 경로를 포함할 수 있습니다. 대표적인 유형으로는 수동 선택하는 select, 테스트 결과에 따라 선택하는 url-test, 순서대로 사용 가능한 경로를 찾는 fallback이 있습니다.

한 그룹을 변경해도 모든 연결의 경로가 바뀌는 것은 아닙니다. 대상 연결에 어떤 규칙이 적용되어 어느 그룹으로 들어가는지 확인한 다음, 해당 그룹이 최종적으로 어떤 노드를 가리키는지 살펴보세요.

GeoIP는 IP 주소 데이터베이스를 이용해 대상 IP의 지역을 판별합니다. 흔히 GEOIP,CN,DIRECT처럼 사용합니다. 웹페이지 내용이나 도메인 등록 지역이 아니라 IP 주소 정보를 기준으로 매칭하므로 CDN 라우팅이나 데이터베이스 업데이트 지연이 결과에 영향을 줄 수 있습니다.

GeoIP를 업데이트해도 구독이나 도메인 규칙 목록이 업데이트되는 것은 아닙니다. 예상과 다른 규칙이 적용되면 실제 대상 주소를 먼저 확인하고 GeoIP 업데이트 설정을 살펴보세요.

규칙 제공자는 규칙 모음을 별도 리소스로 관리하는 기능입니다. 기본 설정에서 RULE-SET으로 불러오면 광고 도메인, 앱 도메인, IP 대역 등을 각각 관리하기 좋습니다. 리소스 형식, behavior, 새로고침 주기를 확인해 도메인 목록을 다른 유형으로 읽지 않도록 하세요.

규칙 리소스 자체는 보통 연결 경로를 결정하지 않습니다. 경로는 해당 리소스를 참조하는 규칙이 지정합니다. 리소스 다운로드에 성공해도 적용 순서를 확인해야 합니다. 앞에 있는 포괄적인 규칙이 먼저 일치할 수 있습니다.

DNS는 도메인을 IP 주소 등의 레코드로 변환합니다. 시스템, 브라우저, 앱, 프록시 커널이 모두 이 과정에 관여할 수 있습니다. 커널의 dns 항목은 커널이 조회를 받았을 때의 처리 방식을 정할 뿐, 기기의 모든 조회가 자동으로 커널에 전달된다는 뜻은 아닙니다.

이름 조회에 문제가 생기면 시스템 DNS 서버, 앱 자체의 암호화 DNS, TUN의 DNS 처리, 캐시를 확인하세요. 도메인을 조회하지 못하는 문제와 조회는 됐지만 연결에 실패하는 문제도 구분해야 합니다.

Fake-IP는 조회한 도메인에 내부 매핑 주소를 할당합니다. 앱이 이 주소로 연결하면 커널이 도메인 이름을 복원하고 연결 경로를 선택합니다. 이 주소는 대상 서버의 실제 주소가 아니므로 조회 결과만으로 대상 위치를 판단해서는 안 되며, 커널을 우회하는 기기에서 직접 사용하기에도 적합하지 않습니다.

로컬 네트워크 서비스나 실제 주소가 필요한 앱에서 호환성 문제가 발생하면 fake-ip-filter를 필요한 항목에 한해 확인하고, 설정을 변경한 뒤에는 이전 DNS 캐시를 비우세요.

DNS 누수는 도메인 조회가 예상한 경로를 벗어나 다른 DNS 서비스에 대상 도메인이 노출되는 현상입니다. DNS 서버가 특정 지역에 있다는 사실만이 아니라, 조회 경로가 예상과 다른지가 핵심입니다. 일부 도메인을 로컬 DNS로 조회하도록 규칙을 설정할 수도 있으므로 의도적인 설정과 프록시 우회를 구분해야 합니다.

진단할 때는 테스트 결과, 커널 로그, 앱의 DNS 설정을 함께 확인하세요. 암호화 DNS는 조회 전송 방식만 바꾸므로 조회가 예상한 프록시 경로를 거친다는 증거가 되지는 않습니다.

TUN 모드는 가상 네트워크 인터페이스로 트래픽을 받아 시스템 프록시를 따르지 않는 일부 앱까지 처리할 수 있습니다. 적용 범위는 라우팅, 권한, 제외 설정에 따라 달라집니다. 데스크톱 클라이언트는 서비스 실행이나 관리자 권한이 필요할 수 있고, 모바일 플랫폼은 보통 시스템 VPN 인터페이스를 사용합니다.

활성화한 뒤에도 DNS 경로와 다른 VPN, 가상 네트워크 어댑터, 로컬 네트워크 라우팅과의 충돌을 확인해야 합니다. TUN이 트래픽을 받더라도 모든 연결이 규칙에 따라 프록시 경로로 지정되는 것은 아닙니다.

mihomo는 Clash Meta에서 발전한 프록시 커널로, 프로토콜 연결, 규칙 매칭, DNS, 트래픽 전달을 처리합니다. 그래픽 클라이언트에 커널과 관리 화면이 포함될 수 있으며, 클라이언트가 지원하는 방식으로 커널 관련 설정을 변경할 수도 있습니다.

앱 화면과 커널은 업데이트 시점이 다를 수 있습니다. 설정을 사용하기 전에 클라이언트 이름이나 설정 파일 확장자만 보지 말고 실제 실행 중인 커널과 지원 범위를 확인하세요.

그래픽 클라이언트는 구독 관리, 정책 선택, 로그 확인, 시스템 연동 화면을 제공합니다. 플랫폼별로 Clash Plus, Clash Verge Rev, FlClash 등이 있습니다. 클라이언트가 시작할 때 구독 설정, 재정의 설정, 로컬 설정을 병합할 수 있으므로 실행 중인 설정은 원본 구독 파일과 다를 수 있습니다.

수정 사항을 계속 유지하려면 클라이언트의 재정의 또는 병합 방식을 먼저 확인하세요. 구독을 새로고침할 때 직접 수정한 내용이 덮어써질 수 있습니다. 플랫폼에 맞는 클라이언트는 다운로드 페이지에서 선택할 수 있습니다.

시스템 프록시는 시스템 프록시 설정을 따르는 앱에 로컬 프록시 진입점을 제공합니다. 보통 루프백 주소와 클라이언트의 수신 포트를 입력합니다. 모든 네트워크 트래픽을 처리하는 기능은 아니므로 일부 게임, 터미널 도구, 자체 네트워크 설정이 있는 앱은 진입점을 무시할 수 있습니다.

클라이언트를 종료한 뒤 브라우저에도 접속할 수 없다면 시스템에 작동하지 않는 프록시 주소가 남아 있는지 확인하세요. 진입점 설정을 지우면 직접 연결은 복구할 수 있지만 노드나 구독 자체의 문제까지 해결되지는 않습니다.

mixed-port는 HTTP와 SOCKS 요청에 같은 진입점을 제공하고, external-controller는 커널을 제어하고 상태를 확인하는 관리 API를 제공합니다. 일반적으로 포트는 각각 7890과 9090이지만 클라이언트에서 변경할 수 있으므로 입력 전에 실제 설정을 확인하세요.

앱의 프록시 주소에 제어 포트를 입력하면 안 됩니다. 로컬에서 사용할 때는 루프백 주소에 바인딩하는 것이 좋습니다. 다른 기기에서 접속하도록 허용하려면 인증과 방화벽도 확인하세요. 자세한 내용은 포트 설정 안내를 참고하세요.