Clash 주요 용어집

mihomo는 Clash Meta에서 발전한 프록시 코어로, 설정을 읽고 규칙을 매칭하며 DNS를 처리하고 연결을 전달합니다. Clash 생태계의 여러 GUI 클라이언트가 이 코어를 내장하지만, 클라이언트의 UI 이름이 코어 이름과 같다는 뜻은 아닙니다. 특정 프로토콜이나 설정 항목의 지원 여부를 확인하려면 클라이언트 이름만 보지 말고 실제로 실행 중인 코어와 버전을 확인하세요.

클라이언트는 구독 가져오기, 노드 선택, 시스템 프록시 전환, 로그 확인 등의 인터페이스를 제공하고, 코어는 설정에 따라 네트워크 작업을 수행합니다. 클라이언트 업데이트에 코어 업데이트가 포함될 수도 있고 UI 기능만 바뀔 수도 있습니다. 새 설정 항목이 적용되지 않거나 시작에 실패하거나 권한 오류가 나타나면 설정 파싱, 코어 실행, 시스템 연동 중 어느 단계에서 문제가 발생했는지 먼저 구분하세요.

노드는 프록시 서버에 연결하는 데 필요한 매개변수 모음으로, 보통 서버 주소와 포트, 프로토콜, 인증 정보, 전송 설정을 포함합니다. 이름이 다른 여러 노드가 같은 서버를 이용할 수도 있으므로 이름만으로 회선 위치나 연결 품질을 판단할 수 없습니다. 로그나 스크린샷을 공유할 때는 표시 이름만 가리지 말고 노드의 비밀번호와 키, 기타 접속 정보도 숨기세요.

지연 시간 테스트는 보통 노드를 통해 지정된 탐색 주소에 접속하는 데 걸린 시간을 기록하며, ICMP ping이나 다운로드 속도와 같은 의미는 아닙니다. 처리량 테스트는 일정 시간 동안 전송할 수 있는 데이터의 양을 측정하며, 대상 서버와 혼잡도, 기기 성능에도 영향을 받습니다. 결과를 비교할 때는 같은 테스트 주소와 네트워크 조건을 사용하세요. 한 번의 시간 초과만으로 노드가 영구적으로 작동하지 않는다고 단정할 수는 없습니다.

혼합 포트는 하나의 수신 포트에서 HTTP 프록시와 SOCKS 프록시 연결을 모두 받습니다. 앱에서는 해당 앱이 지원하는 프록시 유형에 맞춰 설정해야 합니다. 포트 번호는 로컬 서비스의 진입점일 뿐, 원격 노드의 포트가 아니며 코어가 정상적으로 시작되었다는 뜻도 아닙니다. 다른 기기에서 이 포트에 접속할 수 있는지는 수신 주소와 LAN 연결 허용 설정, 시스템 방화벽에 따라 달라집니다.

HTTP 프록시는 앱이 프록시 서버에 직접 연결한 뒤 요청을 전달하는 방식입니다. HTTPS 웹사이트에 접속할 때는 보통 CONNECT 메서드로 터널을 만듭니다. 웹사이트가 HTTPS를 사용한다고 해서 앱과 프록시 서버 사이에도 TLS가 적용되는 것은 아닙니다. 원격 HTTP 프록시를 설정할 때는 프록시 연결의 암호화 여부와 인증 필요 여부, 앱의 연결 방식 지원 여부를 별도로 확인하세요.

SOCKS5는 TCP 전달에 사용할 수 있고 UDP 연결 기능도 정의하는 범용 프록시 프로토콜입니다. 프로토콜 자체는 전송 암호화를 제공하지 않으며, 앱과 프록시 구현이 모두 UDP를 지원하는 것도 아닙니다. 도메인을 로컬에서 해석할지 프록시로 전달할지는 앱이 보내는 주소 유형에 따라 달라집니다. 따라서 같은 SOCKS5 주소를 입력해도 모든 앱이 동일한 DNS 경로를 사용하는 것은 아닙니다.

Shadowsocks는 합의된 암호화 방식과 인증 매개변수를 사용해 클라이언트와 서버 사이에서 프록시 트래픽을 전달합니다. 주소와 포트, 암호화 방식, 비밀번호 또는 키가 서버 설정과 일치해야 하며 암호화 방식을 임의로 바꿔 쓸 수 없습니다. 일부 배포 환경에는 플러그인이나 추가 전송 설정이 필요합니다. 가져온 뒤 연결되지 않는다면 노드 이름을 반복해서 수정하지 말고 노드 정의 전체를 확인하세요.

Trojan은 일반적으로 TLS를 통해 프록시 연결을 전달하며, 설정에는 보통 서버 주소와 비밀번호, TLS에 사용할 서버 이름이 포함됩니다. 연결 주소와 인증서에 등록된 도메인이 다를 수 있으므로 SNI 등의 설정도 확인해야 합니다. 인증서 검증에 실패하면 먼저 기기 시간과 도메인, 인증서 체인을 점검하세요. 인증서 검증을 건너뛰는 방법을 장기적인 해결책으로 삼아서는 안 됩니다.

Hysteria 2는 QUIC 기반 프록시 프로토콜이며 연결에 UDP를 사용하므로 네트워크의 UDP 제한이 사용 가능 여부에 직접 영향을 줄 수 있습니다. 인증 정보와 TLS, 선택적 난독화 설정은 서버와 일치해야 합니다. 1세대와 2세대 프로토콜은 같은 방식으로 설정할 수 없습니다. 이 유형의 노드만 시간 초과가 발생한다면 UDP 경로를 먼저 확인한 뒤 코어 로그에서 핸드셰이크 단계를 살펴보세요.

규칙 기반 라우팅은 규칙 모드에서 연결 조건을 순서대로 확인하고, 일치하는 연결을 지정된 정책으로 전달합니다. 예를 들어 DOMAIN-SUFFIX,example.com,PROXY는 해당 도메인과 하위 도메인을 PROXY라는 정책으로 보냅니다. 조건이 넓은 규칙이 트래픽을 먼저 처리할 수 있으므로 예상과 다른 출구로 연결될 때는 특정 규칙의 존재 여부만 확인하지 말고 연결 기록에서 실제로 매칭된 규칙을 살펴보세요.

정책 그룹은 여러 노드나 다른 정책을 묶어 규칙에서 참조할 수 있는 출구 모음으로 만듭니다. select는 수동 선택에, url-test는 탐색 결과에 따른 선택에, fallback은 후보 순서에 따른 사용 가능 여부 전환에 적합합니다. 자동 테스트 결과는 탐색 주소와 매개변수에 따라 달라지며 모든 웹사이트에서 같은 성능을 보장하지 않습니다. 그룹 내 선택을 바꿔도 이미 연결된 세션은 그대로일 수 있습니다.

GeoIP는 IP 데이터베이스를 바탕으로 대상 주소의 지역을 판별합니다. 대표적인 규칙은 GEOIP,CN,DIRECT입니다. 도메인 연결에서 추가 DNS 조회가 발생하는지는 코어 동작과 no-resolve 등의 매개변수에 따라 달라집니다. 주소 할당이나 CDN 라우팅이 바뀌면 데이터베이스 결과가 예상과 다를 수도 있습니다. 범위를 판별하는 데는 유용하지만, IP의 소속 지역을 웹사이트 운영 주체의 소재지로 간주해서는 안 됩니다.

규칙 세트는 여러 매칭 조건을 기본 설정에서 분리해 rule-providers로 출처를 선언하고, RULE-SET으로 가져옵니다. 콘텐츠 형식은 선언한 동작 유형 및 파일 형식과 맞아야 합니다. 예를 들어 도메인 목록과 클래식 규칙 목록은 임의로 혼용할 수 없습니다. 규칙 세트 업데이트에 성공했다는 것은 콘텐츠를 가져왔다는 뜻일 뿐이며, 특정 연결에 영향을 주는지는 기본 규칙 목록에서 참조되는 위치에 따라 달라집니다.

MATCH는 앞서 다른 규칙에 매칭되지 않은 연결을 처리하므로 규칙 목록의 마지막 줄에 두어야 합니다. 기본 대상으로 프록시 정책 그룹이나 DIRECT, REJECT를 지정할 수 있으며 원하는 기본 동작에 따라 선택하면 됩니다. 도메인 규칙보다 앞에 두면 뒤에 있는 규칙은 연결을 처리할 기회가 거의 없습니다. 순서를 바꾼 뒤에는 새 연결을 만들어 매칭 결과를 확인하세요.

DNS는 도메인을 IP 주소로 변환합니다. 조회는 시스템 리졸버와 클라이언트 내장 리졸버, 브라우저의 보안 DNS를 거칠 수 있습니다. DNS 조회가 어떤 경로를 거치는지와 웹사이트 연결이 어떤 출구를 사용하는지는 별개의 문제입니다. 도메인은 열리지 않지만 IP 주소로는 연결될 때 조회 결과와 리졸버 접근성을 확인할 수 있습니다. 다만 HTTPS 인증서나 가상 호스트 동작 때문에 IP 주소로 직접 접속하는 것도 실패할 수 있습니다.

Fake-IP는 DNS 조회에 매핑용 주소를 반환하고, 연결이 코어에 도달하면 해당 매핑으로 원래 도메인을 찾아 후속 처리를 진행합니다. 이렇게 하면 도메인 정보를 유지하고 일부 환경에서는 로컬에서 실제 주소를 조회할 필요를 줄일 수 있습니다. LAN 서비스나 실제 조회 결과에 의존하는 앱에는 필요에 따라 fake-ip-filter를 조정하세요. 모드를 변경한 뒤에는 시스템과 앱의 DNS 캐시도 확인해야 합니다.

DNS 누수는 도메인 조회가 예상한 해석 경로를 우회하는 현상을 말합니다. 예를 들어 앱이 기존 네트워크 리졸버로 계속 조회를 보낼 수 있습니다. 시스템 DNS와 브라우저 보안 DNS, IPv6, TUN이 트래픽을 처리하는 범위를 함께 확인하세요. 테스트 페이지에 표시된 리졸버 위치는 참고 자료일 뿐이므로 지역 이름 하나만으로 결론을 내려서는 안 됩니다. 필요하면 로그나 패킷 캡처로 조회가 실제로 어디로 전송되는지 확인하세요.

TUN 모드는 가상 네트워크 인터페이스를 통해 IP 트래픽을 받아 시스템 프록시를 사용하지 않는 앱도 코어에서 처리할 수 있게 합니다. 실제로 어떤 연결이 처리되는지는 시스템 권한과 라우팅, 제외 항목, DNS 설정에 따라 달라집니다. TUN을 켰다고 모든 네트워크 동작이 자동으로 지원되는 것은 아닙니다. 다른 VPN과 함께 실행할 때는 라우팅 충돌을 확인하고, 가상 인터페이스 자체를 원격 암호화 터널로 오해하지 마세요.

시스템 프록시는 로컬 프록시 주소를 운영체제 설정을 따르는 앱에 알려줄 뿐, 모든 프로그램의 트래픽을 강제로 처리하지는 않습니다. 브라우저는 이 설정을 따를 수 있지만 명령줄 도구와 게임, 자체 프록시 옵션이 있는 앱은 다른 경로를 사용할 수 있습니다. 특정 앱의 트래픽만 기록되지 않는다면 앱 자체의 프록시 설정부터 확인하세요. 클라이언트가 비정상적으로 종료된 뒤 직접 연결되지 않는다면 시스템에 이전 프록시 주소가 남아 있는지도 살펴보세요.

구독은 원격 주소를 통해 업데이트할 수 있는 노드나 설정을 제공합니다. 서비스마다 반환 형식은 다릅니다. 어떤 링크는 완전한 Clash 설정을 반환하고, 어떤 링크는 노드 목록만 반환하므로 클라이언트가 해당 형식의 가져오기를 지원해야 합니다. 구독 주소에 접속 정보가 포함될 수 있으니 비밀번호처럼 안전하게 보관하세요. 업데이트에 실패하면 네트워크 요청 실패와 계정 상태 문제, 콘텐츠 파싱 오류를 구분해 확인하세요.

YAML은 Clash 설정에 널리 쓰이는 구조화 텍스트 형식으로, 들여쓰기로 계층을 나타내고 하이픈으로 목록 항목을 표시합니다. 들여쓰기에는 공백을 사용하세요. 특수 문자가 포함된 값에는 따옴표가 필요할 수 있으며, 같은 키를 중복해서 쓰면 오류나 덮어쓰기가 발생할 수 있습니다. YAML 문법 검사를 통과했다는 것은 텍스트 구조를 해석할 수 있다는 뜻일 뿐, 필드 이름과 참조 관계, 노드 매개변수가 올바르다는 뜻은 아닙니다. 실제 코어로 설정을 확인해야 합니다.

설정 파일에는 수신 포트와 노드, 정책 그룹, 규칙, DNS 등의 설정이 포함되며 외부 목록으로 일부 항목을 보충할 수도 있습니다. 클라이언트에 여러 파일이 저장되어 있어도 코어가 사용하는 것은 현재 선택한 설정과 클라이언트가 병합한 결과입니다. 파일을 수정했는데 변경 사항이 보이지 않는다면 편집기 내용만 확인하지 말고 저장 여부와 해당 설정 선택 여부, 다시 불러오기가 성공했는지 확인하세요.

프록시 목록은 노드 출처를 기본 설정과 분리해 원격 주소나 로컬 파일에서 노드를 불러오고, 정책 그룹은 use로 이를 참조합니다. 프록시 목록은 프록시 후보를 제공하고 rule-providers는 매칭 조건을 제공하므로 용도가 다릅니다. 목록을 내려받았는데 그룹에 노드가 나타나지 않으면 파일 형식과 정책 그룹의 참조 이름, 노드 필터 조건을 확인하세요.

설정 오버라이드는 기본 설정이나 구독과 별도로 로컬 변경 사항을 저장하고, 업데이트하거나 불러올 때 최종 설정에 병합하는 방식입니다. 사용자 지정 DNS와 포트, 규칙을 유지할 때 유용하지만 클라이언트마다 병합 순서가 다를 수 있고 배열을 추가하는 대신 교체할 수도 있습니다. 설정을 마친 뒤에는 최종 적용 설정을 확인하세요. 오버라이드 파일이 있다는 이유만으로 사용자 지정 규칙이 코어에 반영되었다고 단정해서는 안 됩니다.