구독 가져오기부터 네트워크 연결까지, 설정 단계별로 용어를 살펴봅니다. 프로토콜은 클라이언트와 서버의 연결 방식을, 코어는 설정 실행을, 규칙은 연결에 적용할 정책을 결정합니다. 시스템 프록시와 TUN은 앱 트래픽이 코어로 들어오는 방식을 정합니다.
각 개념은 서로 연결되어 있지만 서로 대신할 수는 없습니다. 구독을 가져와도 시스템 연결이 자동으로 켜지는 것은 아니며, 노드를 바꿔도 트래픽 분할 규칙이 바뀌지는 않습니다. 각 항목에서 용어의 역할과 사용 조건, 흔한 오해를 확인하세요. 실제 지원 범위는 실행 중인 클라이언트와 코어를 기준으로 판단해야 합니다.
프로토콜 이름은 연결 및 인증 방식을 나타내며 속도 순위를 뜻하지 않습니다. 노드를 선택할 때는 서버 설정, 하위 전송 방식, TLS 설정과 코어의 구현 지원 여부도 확인해야 합니다.
Shadowsocks는 공유 키와 지정된 암호화 방식으로 연결을 전달합니다. 노드에는 보통 서버 주소, 포트, 비밀번호, 암호화 방식이 설정됩니다. 클라이언트와 서버의 암호화 방식은 일치해야 하며, 기존 구현과 Shadowsocks 2022는 필요한 설정도 다릅니다. 추가 플러그인이나 프로토콜 확장을 사용하는 경우 코어가 지원하는지 별도로 확인하세요. SS라는 표시만으로 가져오기가 가능하다고 단정할 수 없습니다.
프로토콜 선택 가이드 보기 →VMess는 V2Ray 생태계에서 시작되었으며, 일반적으로 UUID로 사용자를 식별하고 자체 인증 및 전송 보호 기능을 포함합니다. 같은 VMess 노드라도 하위 전송 방식과 TLS 설정은 다를 수 있어 주소가 맞더라도 다른 항목을 생략할 수는 없습니다. 일부 인증 방식에는 정확한 시스템 시간이 필요합니다. 인증 오류가 발생하면 기기 시간과 구독에 포함된 설정을 먼저 확인하세요.
프로토콜 차이 보기 →Trojan은 일반적으로 TLS로 클라이언트와 서버 간 전송을 보호하고 비밀번호로 인증합니다. 서버 이름과 인증서 신뢰 여부가 핸드셰이크에 영향을 주므로 서버 주소, SNI, 인증 비밀번호를 각각 확인해야 합니다. 인증서 오류를 검증 생략으로 해결하기보다 이름 일치 여부, 기기 시간, 인증서 체인의 신뢰성을 먼저 확인하세요.
TLS 및 프로토콜 설명 보기 →VLESS는 간소화된 인증 구조를 사용하며 일반적으로 UUID로 사용자를 식별하지만, 프로토콜 자체는 전송을 암호화하지 않습니다. 노드의 보안과 호환성을 파악하려면 TLS, REALITY, 하위 전송 방식, flow 등의 관련 설정을 함께 살펴야 합니다. 가져오기에 실패하면 노드 이름만 비교하지 말고 현재 코어가 해당 조합을 지원하는지 확인하세요. 설정은 서버 구성과 일치해야 합니다.
코어 호환성 보기 →Hysteria2는 QUIC 기반으로 작동하며, 사용 가능한 UDP 경로가 필요하고 대역폭 관련 혼잡 제어 설정을 제공합니다. 패킷 손실이 큰 일부 환경에서는 TCP 방식과 다른 성능을 보일 수 있지만, 속도는 서버 성능과 연결 품질, 설정에 따라 달라집니다. 네트워크에서 UDP가 차단되거나 대역폭 설정이 적절하지 않으면 연결이 실패하거나 불안정할 수 있습니다. 모바일에서는 실제 배터리 소모도 함께 비교하세요.
사용 환경별 선택 가이드 보기 →TUIC 역시 QUIC 기반으로 연결 다중화와 UDP 전달을 지원합니다. 설정할 때 서버 프로토콜 버전과 인증 항목, 클라이언트 코어가 지원하는 형식을 확인해야 합니다. 버전이 다른 설정을 그대로 섞어 쓰면 안 됩니다. UDP 통신이 가능한 네트워크가 필요하므로 노드를 테스트할 때는 한 번의 연결 테스트 결과뿐 아니라 대상 앱이 실제로 작동하는지도 확인하세요.
QUIC 프로토콜 비교 보기 →클라이언트 인터페이스, 실행 코어, 설정 파일은 서로 다른 계층입니다. 호환성 문제를 해결할 때는 먼저 실제로 불러온 코어를 확인한 뒤 설정 문법과 기능 항목이 지원되는지 살펴보세요.
프록시 코어는 설정을 읽고 로컬 수신 포트를 열며, 규칙을 적용하고 DNS를 처리해 프록시 서버에 연결합니다. 그래픽 클라이언트는 보통 구독 관리, 설정 화면, 실행 제어를 담당합니다. 인터페이스에서 변경한 설정도 최종적으로 코어가 인식할 수 있는 형태여야 합니다. 모양이 비슷한 클라이언트라도 서로 다른 코어를 사용할 수 있으므로 프로토콜 지원 여부는 실제 코어 정보를 확인하세요.
코어 계보 보기 →mihomo는 Clash Meta 프로젝트에서 발전한 프록시 코어로 규칙 라우팅, DNS, TUN 및 다양한 프록시 프로토콜을 지원합니다. 기존 Clash 설정을 이어받았지만 확장 항목이 다른 코어에서도 읽힌다고 보장할 수는 없습니다. 구독에 새 프로토콜이나 특정 DNS 옵션이 있다면 클라이언트 이름만 보고 기능을 추측하지 말고 실제 실행 버전의 문서를 확인하세요.
mihomo 설정 호환성 보기 →Clash Meta는 Clash 생태계의 확장 코어를 가리키던 과거 프로젝트 이름입니다. 후속 프로젝트는 mihomo라는 이름을 사용하지만, 예전 가이드와 클라이언트에는 Meta가 남아 있을 수 있습니다. 이름에 Meta가 포함되어 있어도 현재 코어 버전이나 소프트웨어 업데이트 여부를 알 수는 없습니다. 문서를 볼 때 과거 프로젝트명, 그래픽 클라이언트 이름, 실제 실행 중인 코어 정보를 구분하세요.
이름과 기능 차이 보기 →YAML은 들여쓰기로 계층 구조를 나타내는 데이터 형식이며 Clash 설정에서는 포트, 노드, 정책 그룹, 규칙 등을 기술할 때 자주 사용됩니다. 들여쓰기에는 공백을 사용하고 목록과 키-값 구조도 문법에 맞춰야 합니다. 특수 문자가 포함된 문자열은 적절히 따옴표로 감싸야 합니다. YAML 문법 검사를 통과해도 구조만 유효하다는 뜻이며, 항목 이름과 값, 참조 관계는 코어가 추가로 확인해야 합니다.
설정 가져오기 단계 보기 →config.yaml은 흔히 사용하는 설정 파일 이름입니다. 파일에는 보통 로컬 수신 설정, 프록시 노드, 정책 그룹, DNS, 라우팅 규칙이 포함되지만 실제 파일명은 다를 수 있습니다. 클라이언트가 구독 원문에 로컬 재정의를 적용할 수 있어 최종 실행 설정이 다운로드한 내용과 완전히 같지 않을 수 있습니다. 수정하기 전에 원본 설정과 생성된 파일을 구분하세요. 그렇지 않으면 다음 구독 업데이트 때 직접 수정한 내용이 덮어써질 수 있습니다.
규칙은 연결에 적용할 정책을 판단하고 정책 그룹은 실제로 사용할 노드를 결정합니다. 로그를 확인할 때는 프록시 스위치만 볼 게 아니라 일치한 규칙과 최종 적용된 정책을 함께 살펴야 정확합니다.
규칙 기반 라우팅은 도메인, IP, 프로세스 등의 조건에 따라 연결 처리 정책을 선택하며 보통 규칙 모드에서 적용됩니다. 규칙은 일반적으로 위에서 아래로 검사하므로 먼저 일치한 규칙이 연결 경로를 결정합니다. 구체적인 규칙을 포괄적인 규칙보다 앞에 두세요. DIRECT는 직접 연결, REJECT는 연결 거부를 뜻합니다. PROXY는 설정에서 정의한 정책 그룹 이름인 경우가 많으며 기본 제공 그룹이 아닙니다.
규칙 순서와 정책 보기 →GeoIP는 데이터베이스를 바탕으로 IP 주소를 국가나 지역 범주에 분류합니다. 예를 들어 GEOIP,CN,DIRECT는 CN 범주에 해당하는 주소를 직접 연결한다는 뜻입니다. 데이터베이스 정보가 실제 위치를 정확하게 측정하는 것은 아니며 IP 할당 변경과 데이터 업데이트에 따라 결과가 달라질 수 있습니다. 연결 대상이 도메인뿐이면 IP 규칙에 DNS 조회가 관여할 수도 있으므로 DNS 설정과 함께 매칭 방식을 살펴보세요.
GeoSite는 서비스, 용도, 지역 등의 태그에 따라 도메인을 분류한 목록으로, 여러 도메인을 범주별로 매칭할 때 사용할 수 있습니다. GeoIP와 달리 IP의 지역이 아니라 도메인을 기준으로 매칭하며 태그의 구체적인 의미는 데이터 출처에 따라 달라집니다. 관련 규칙을 사용하기 전에 코어 지원 여부, 데이터 파일 사용 가능 여부, 해당 태그의 존재를 확인하세요. 분류 이름이 모든 데이터 출처에서 동일한 기준을 뜻하는 것은 아닙니다.
도메인 규칙 참고하기 →MATCH는 앞선 규칙과 일치하지 않은 연결을 처리하며 보통 규칙 목록의 마지막에 둡니다. 예를 들어 MATCH,PROXY는 나머지 연결을 PROXY라는 정책으로 보냅니다. 단, 해당 정책이 설정에 있어야 합니다. 기본 규칙을 너무 앞에 두면 뒤에 있는 규칙이 적용되지 않습니다. 예상과 다른 경로로 연결될 때는 규칙 위치와 대상 정책을 먼저 확인하세요.
정책 그룹은 노드나 다른 정책을 묶어 규칙에서 참조할 선택 항목을 만듭니다. 그룹 이름은 설정에서 지정합니다. select는 보통 수동 선택, url-test는 테스트 결과에 따른 자동 선택, fallback은 설정된 순서에 따라 장애 시 대체하는 데 사용됩니다. 그룹에서 노드를 선택해도 모든 연결이 그 노드를 사용하는 것은 아닙니다. 해당 그룹과 일치한 연결에만 선택한 항목이 적용됩니다.
구독은 설정을 업데이트하는 경로이고, 노드는 연결 매개변수이며, 테스트 결과는 특정 시점의 측정값입니다. 각각 따로 확인하면 다운로드 실패, 설정 비호환, 연결 경로 문제를 구분할 수 있습니다.
구독은 보통 링크를 통해 노드나 설정을 가져오고 업데이트합니다. 응답에는 전체 YAML 설정이 포함될 수도 있고 노드 목록만 들어 있을 수도 있습니다. 클라이언트가 해당 형식을 인식해야 하며, 다운로드에 성공한 뒤에도 설정을 선택하거나 활성화해야 실제 실행에 반영됩니다. 구독 링크에는 인증 정보가 포함될 수 있으니 비밀번호처럼 안전하게 보관하세요. 스크린샷이나 로그를 공유할 때는 전체 구독 주소를 가려야 합니다.
구독 링크 가져오기 보기 →노드는 프록시 서버에 연결하는 데 필요한 설정 항목의 모음으로, 보통 서버 주소, 포트, 프로토콜, 인증 정보와 TLS 및 전송 설정을 포함합니다. 노드 이름은 구분을 위한 표시일 뿐이며, 지역 표기가 실제 진입 지점이나 출구 위치를 보장하지는 않습니다. 노드를 선택할 때는 이름만 보지 말고 프로토콜 호환성, 서비스 상태, 대상 앱의 작동 여부도 확인해야 합니다.
노드 선택 및 연결 보기 →클라이언트의 노드 지연 시간은 보통 노드를 통해 지정된 테스트 대상에 접속하는 데 걸린 시간입니다. 핸드셰이크나 연결 재사용이 측정에 포함되는지는 구현 방식에 따라 다릅니다. 이 값은 사용 가능한 대역폭과 다르며 동영상, 다운로드, 게임 성능을 그대로 예측하지도 않습니다. 테스트 대상을 바꾸면 결과도 달라질 수 있습니다. 시간 초과는 해당 테스트가 예상대로 완료되지 않았다는 뜻이므로 로그와 실제 접속을 함께 확인해 인증, DNS 조회, 연결 경로 문제를 구분하세요.
노드 속도 테스트 결과 보기 →proxy-providers는 mihomo 설정에서 외부 노드 목록을 불러오는 항목입니다. 원격 주소나 로컬 파일을 소스로 사용할 수 있으며 정책 그룹은 보통 use로 이 목록을 참조합니다. 이를 통해 노드 업데이트와 로컬 정책 및 규칙을 따로 관리할 수 있습니다. 제공자 파일은 노드 목록 형식에 맞아야 하므로 모든 전체 구독을 그대로 사용할 수 있다고 단정하지 마세요. 업데이트 간격과 캐시도 각각 확인해야 합니다.
시스템 프록시와 TUN은 트래픽이 들어오는 경로를 정하고, 규칙 모드는 코어에 들어온 트래픽의 라우팅을 결정합니다. DNS는 도메인이 주소로 변환되는 방식에 영향을 주므로 연결 경로 및 라우팅과 함께 확인해야 합니다.
TUN 모드는 가상 네트워크 인터페이스로 IP 패킷을 받은 뒤 코어에서 처리하고 라우팅합니다. 시스템 프록시 설정을 따르지 않는 일부 앱의 트래픽도 처리할 수 있습니다. 트래픽을 가로채는 범위는 시스템 라우팅, 권한, 제외 설정에 따라 달라지며 스위치 하나만으로 정해지지 않습니다. UDP를 프록시로 전달할 수 있는지는 노드 지원 여부도 확인해야 합니다. 다른 VPN이나 가상 네트워크 어댑터와 함께 사용할 때는 라우팅과 DNS 충돌 여부를 점검하세요.
TUN 권한 및 설정 보기 →시스템 프록시는 운영체제 설정에서 프록시 주소를 클라이언트의 로컬 수신 포트로 지정하는 방식입니다. 이 설정을 따르는 앱만 프록시를 사용합니다. 일부 명령줄 도구, 자체 네트워크 스택을 사용하는 앱, UDP 트래픽은 이 경로를 거치지 않을 수 있습니다. 켜기 전에 클라이언트가 수신 중인지 확인하세요. 종료 후 이전 프록시 설정이 남아 있으면 시스템 프록시를 따르는 앱의 연결이 실패할 수 있습니다.
시스템 프록시 연결 점검 보기 →혼합 포트는 하나의 수신 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받습니다. 예를 들어 mixed-port: 7890은 흔한 설정이지만 포트 번호는 변경할 수 있습니다. 시스템 프록시와 앱 설정의 주소 및 포트가 실제 수신 설정과 일치해야 하며, 다른 프로세스가 포트를 사용하지 않도록 해야 합니다. 혼합 포트는 로컬 트래픽 진입점이지 원격 노드 포트가 아닙니다. 로컬 네트워크에서 접근하도록 열 때는 수신 범위와 접근 제어도 고려하세요.
DNS 누수는 도메인 조회가 예상한 경로를 벗어나 다른 DNS 서버로 전송되는 현상입니다. 조회 중인 도메인이 노출되거나 DNS 응답과 실제 접속 경로가 달라질 수 있습니다. 운영체제, 브라우저, 앱이 각각 조회를 보낼 수 있으며 암호화 DNS를 사용한다고 해서 예상한 라우팅이 보장되는 것은 아닙니다. DNS 설정과 브라우저 옵션, 코어 로그를 함께 확인하세요. 테스트 페이지에 특정 사업자 이름이 표시된다는 이유만으로 결론 내리면 안 됩니다.
DNS 및 연결 설정 보기 →Fake-IP는 관리 대상 DNS 조회에 합성 IP를 반환하고 원래 도메인과의 매핑을 유지합니다. 이후 연결이 코어에 들어오면 도메인을 복원해 규칙을 적용할 수 있습니다. 이 주소는 대상 서버의 실제 주소가 아니므로 출구 위치를 판단하는 데 사용할 수 없습니다. 일부 로컬 네트워크 서비스, 게임, 특수 앱은 예외 설정이 필요합니다. DNS 모드를 바꾼 뒤에는 앱이나 시스템에 남은 이전 DNS 캐시를 지워야 할 수도 있습니다.
도메인 라우팅 참고하기 →