Clash 프로토콜과
mihomo 코어 선택 가이드

코어 관계: 화면과 실행 계층을 먼저 구분하세요

클라이언트 이름만으로 프로토콜 지원 여부를 알 수 없습니다

설정이 작동하는지 판단하기 전에 클라이언트의 코어 정보를 확인하세요. 그래픽 클라이언트는 구독 가져오기, 정책 그룹 선택, 시스템 프록시 전환, 로그 표시를 담당합니다. 프록시 코어는 설정을 해석하고 규칙을 적용하며 연결을 만들고 도메인 조회를 처리합니다. 비슷한 화면을 제공하는 클라이언트라도 배포 버전에 따라 포함된 코어가 다를 수 있고, 하나의 코어를 여러 인터페이스에서 사용할 수도 있습니다. 따라서 클라이언트 이름에 Clash가 들어간다고 해서 Clash 생태계의 모든 설정을 지원한다고 단정할 수 없습니다.

원본 Clash는 프록시 목록에 노드를 배치하고, 정책 그룹으로 노드를 구성하며, 규칙에 따라 연결의 출구를 지정하고, 도메인 조회 설정으로 대상 정보를 확인하는 일반적인 설정 구조를 정립했습니다. 오픈소스 원본 코어와 추가 기능을 제공했던 Premium 브랜치도 구분해야 합니다. 구체적인 브랜치와 빌드 범위를 밝히지 않고 ‘원본 지원’이라고만 적은 온라인 가이드는 마이그레이션의 근거로 삼기 어렵습니다. 실제 기기에서 실행 중인 코어의 안내와 설정 검사 결과를 기준으로 판단하세요.

Meta에서 mihomo로 이어지는 관계

Clash.Meta는 Clash 생태계에서 프로토콜과 기능을 확장한 코어 브랜치이며, 이후 프로젝트는 mihomo라는 이름으로 계속 개발되고 있습니다. 이전 자료의 Meta 설정은 현재 mihomo 문서와 역사적으로 이어져 있지만, 이름이 비슷하다고 해서 모든 시기의 필드가 완전히 같다는 뜻은 아닙니다. 새 프로토콜, 전송 매개변수, 도메인 조회 옵션은 순차적으로 추가되므로 구형 클라이언트에 포함된 코어는 해당 필드를 인식하지 못할 수 있습니다. 마이그레이션할 때는 원본 설정이 대상으로 삼는 코어와 로컬 코어의 지원 범위를 모두 확인하세요.

호환성은 세 단계로 나눠 점검하세요. 첫째, 들여쓰기와 필드 유형, 노드 유형 등 구문을 해석할 수 있는지 확인합니다. 둘째, 지정한 전송 방식과 보안 기능, 가상 네트워크 인터페이스 매개변수를 실제로 지원하는지 확인합니다. 셋째, 시스템 권한, 라우팅 설정, 포트 등 실행 환경이 허용하는지 확인합니다. 설정을 불러오는 데 성공해도 일부 검사만 통과했을 수 있습니다. 모든 노드의 서버 인증이 끝났거나 모든 앱 트래픽이 클라이언트로 들어온다는 보장은 없습니다.

클라이언트를 바꿀 때 보존할 정보

클라이언트를 바꾸기 전에 현재 설정의 출처, 활성화된 설정 이름, 정책 그룹 선택 및 필요한 오버라이드를 저장하세요. 설정이 그대로 이어질 것이라고 생각해 프로그램 디렉터리 전체를 복사하지는 마세요. 인터페이스 데이터베이스, 구독 캐시, 코어 설정은 각각 다른 위치에 저장될 수 있습니다. 새 클라이언트에서 설정을 가져온 다음 노드 수가 예상과 맞는지, 정책 그룹 참조가 온전한지, 규칙이 제대로 적용됐는지 확인하세요. 기존 설정에 절대 경로가 있다면 규칙 파일이나 인증서 위치도 다시 지정해야 합니다.

운영체제에 맞는 설치 파일을 선택하려면 Clash 다운로드 페이지에서 우선 추천하는 Clash Plus를 확인한 뒤 같은 플랫폼의 다른 클라이언트와 비교해 보세요. 선택 기준은 화면 모양이 아니라 시스템 요구 사항, 실제 코어 지원 여부, 유지 관리 상태여야 합니다. 오래된 가이드를 참고할 때는 설정 방식만 활용하고 필드 이름은 다시 확인하세요. 오래된 예제를 그대로 따라 하려고 지원이 중단된 클라이언트로 되돌아가지는 마세요. 인터페이스별 사용 방법을 비교하려면 그래픽 클라이언트 선택 가이드도 참고하세요.

SS: 간결한 구조와 암호화 방식

Shadowsocks의 설계 목적 이해하기

Shadowsocks는 흔히 SS라고 부르며, 비교적 간결한 암호화 프록시 채널을 제공하도록 설계됐습니다. 클라이언트가 앱의 연결을 받아 대상 주소와 데이터를 프로토콜 형식에 맞춰 서버로 보내면, 서버가 대상에 접속합니다. 완전한 가상 사설망은 아니며, 노드의 프로토콜 이름만으로 기기의 모든 앱을 자동으로 연결하지도 않습니다. 앱 트래픽이 코어로 들어오는 방식은 시스템 프록시, 앱별 설정, TUN 등의 트래픽 처리 방식에 따라 달라집니다. 진입 방식과 노드 프로토콜을 혼동하지 마세요.

SS 설정은 대개 서버 주소, 포트, 암호화 방식, 비밀번호를 중심으로 구성되며 필드가 비교적 간단합니다. 그래서 기본적인 서비스를 이미 갖춘 경우 일상적인 연결에 자주 사용됩니다. 여기서 ‘가볍다’는 표현은 프로토콜 구조와 배포 복잡성을 뜻할 뿐, 모든 기기에서 높은 성능을 보장한다는 뜻은 아닙니다. 서버 부하, 네트워크 품질, 암호화 구현, 기기 프로세서가 실제 사용 경험에 영향을 줍니다. 같은 노드라도 네트워크에 따라 성능 차이가 달라 프로토콜 간 차이보다 크게 느껴질 수 있습니다.

암호화 방식부터 확인한 다음 인증 정보를 점검하세요

암호화 방식은 프로토콜 호환성의 핵심이지 임의로 고르는 옵션이 아닙니다. 기존 스트림 암호화 방식, 최신 인증 암호화 방식, Shadowsocks 2022 계열은 데이터 형식이 다르므로 클라이언트가 서버에서 지정한 방식을 구현해야 합니다. 비밀번호가 맞는다는 이유로 더 흔해 보이는 다른 방식으로 바꾸면 안 됩니다. 인증 암호화는 메시지 변조 여부도 검사합니다. 방식이나 키가 일치하지 않으면 ‘비밀번호 오류’가 명확히 표시되는 대신 핸드셰이크 실패, 즉시 연결 종료, 지속적인 시간 초과로 나타날 수 있습니다.

암호화 방식마다 필요한 키 자료도 다릅니다. 일부 설정은 일반 비밀번호를 받지만, 어떤 방식은 지정된 형식과 길이로 인코딩한 키가 필요합니다. 구독에서 생성된 값은 그대로 유지하세요. 인코딩된 문자열을 직접 디코딩해 다시 입력하거나 끝 문자를 임의로 지우지 마세요. 직접 입력할 때는 전각 문장 부호, 복사 과정에서 들어간 공백과 줄바꿈에 주의하세요. 로그를 다른 사람에게 전달해 문제를 해결할 때는 방식과 오류 유형만 남기고 비밀번호와 서버 주소의 민감한 정보는 가리세요.

플러그인과 UDP도 별도로 확인하세요

일부 SS 노드는 플러그인으로 추가 전송 기능을 제공합니다. 설정에 플러그인 이름만 입력한다고 항상 작동하는 것은 아닙니다. 코어가 해당 구현을 지원해야 하고, 클라이언트가 사용할 수 있는 매개변수를 제한할 수도 있습니다. 기존 서비스에서 플러그인을 요구한다면 설정을 삭제할 경우 전송 형식이 바뀌므로 유효한 단순화 방법이 아닙니다. 반대로 서버에서 플러그인을 사용하지 않는데 클라이언트에 추가해도 연결되지 않습니다. 가져온 뒤 노드가 사라졌다면 변환 과정에서 플러그인 유형이나 옵션이 누락됐는지 확인하세요.

UDP를 사용하려면 클라이언트, 노드 설정, 서버, 네트워크 경로가 모두 지원해야 합니다. 웹페이지가 열리는지는 주로 TCP 연결 상태를 보여 주므로 음성 통화, 게임 또는 다른 UDP 앱도 작동한다고 판단할 수 없습니다. 일부 앱은 자체 도메인 조회나 직접 연결 경로를 사용해 현재 트래픽 진입 방식을 우회하기도 합니다. 테스트할 때는 먼저 앱 연결이 코어로 들어왔는지 확인하고 예상한 노드가 선택됐는지 점검하세요. SS 비밀번호만 반복해서 바꾸지 말고 서버의 UDP 전달 설정과 로컬 방화벽도 확인하세요.

이미 안정적으로 작동하는 SS 서비스가 있다면 새 프로토콜이 등장했다는 이유만으로 일상적인 웹 탐색이나 일반 앱 사용을 위해 옮길 필요는 없습니다. 먼저 노드 유지 관리 상태, 네트워크 품질, 현재 코어의 지원 범위를 확인하세요. 프로세서 사용량을 비교하려면 같은 기기와 비슷한 네트워크 경로, 동일한 작업에서 관찰해야 합니다. 하드웨어 가속을 지원하는 컴퓨터에서 특정 암호화 방식이 효율적이라고 해서 다른 휴대전화에서도 배터리를 덜 쓴다는 뜻은 아닙니다. 프로토콜을 단순한 속도 표시가 아니라 전체 연결 구성의 일부로 보세요.

VMess와 VLESS: 인증, 전송, 보안 계층

VMess의 역할

VMess는 자체 생태계에서 사용자 인증, 데이터 보호, 프록시 요청 표현을 포함하도록 설계된 프로토콜입니다. 일반적인 설정에는 사용자 식별자, 암호화 옵션, 하위 전송 매개변수가 포함됩니다. 과거에 구현 방식이 바뀌었으므로 오래된 설정의 필드가 현재 서비스에도 맞는 것은 아닙니다. 특히 이전 자료에 나오는 추가 식별 매개변수를 모든 노드에 그대로 복사해서는 안 됩니다. 오래된 가이드를 고정된 설정법으로 따르기보다 클라이언트와 서버가 서로 호환되는 프로토콜 방식을 사용하도록 하세요.

VMess 연결 문제를 해결할 때는 시스템 시간이 우선 확인할 항목입니다. 인증 과정에 시간 관련 메커니즘이 포함되므로 기기 시간이 크게 어긋나면 인증이 실패할 수 있습니다. 네트워크 모드를 무작정 바꾸기보다 시스템 자동 시간 설정을 켜고 사용자 식별자와 서버 설정을 확인하세요. 사용자 식별자는 노드 표시 이름과 다릅니다. 인터페이스의 메모를 바꿔도 인증 정보는 바뀌지 않습니다. 구독 업데이트 후 서비스 제공업체가 인증 정보를 변경했다면 기존 노드 제목만 수정하지 말고 유효한 설정을 다시 불러오세요.

VLESS는 어떤 역할을 단순화했나요?

VLESS는 프로토콜 자체의 인증과 전달 구조를 단순화하고, 데이터 기밀성은 외부 보안 계층에 더 많이 맡기는 방향으로 설계됐습니다. VMess의 다른 암호화 방식도 아니며 노드 유형만 바꿔 서로 교체할 수 있는 형식도 아닙니다. 일반적인 배포에서는 TLS나 REALITY 같은 메커니즘을 함께 사용하므로 클라이언트가 서버에서 실제로 사용하는 조합을 지원해야 합니다. 이름에 ‘가벼움’을 연상시키는 뜻이 있다고 해서 보안 계층을 끈 채 데이터가 똑같이 보호된다고 생각하지 마세요.

REALITY, TLS, 전송 유형, flow는 서로 다른 설정 항목입니다. 특정 조합이 작동한다고 해서 다른 가이드에 나온 값으로 그중 하나를 바꿔도 되는 것은 아닙니다. 서버에서 요구하는 공개 키, 짧은 ID, 서버 이름, 흐름 제어 옵션은 원본에 따라 입력하고 누락된 항목은 설정 제공자에게 확인하세요. 특히 웹사이트 인증서의 공개 키와 서버가 명시한 REALITY 공개 키를 혼용하지 마세요. 두 키는 출처와 용도가 다르므로 잘못 입력하면 보안 핸드셰이크 단계에서 실패하는 경우가 많습니다.

노드 설정을 세 계층으로 나눠 살펴보세요

이러한 설정은 ‘프록시 프로토콜—전송 방식—보안 메커니즘’의 세 계층으로 나눠 이해할 수 있습니다. 프록시 프로토콜은 인증과 요청 형식을, 전송 방식은 일반 연결·WebSocket 등 지원되는 형식으로 데이터를 전달하는 방식을, 보안 메커니즘은 인증서 확인과 암호화 핸드셰이크를 결정합니다. 세 계층의 조합은 실제 서버 배포에 따라 달라집니다. 구독 변환 과정에서 노드 유형과 사용자 식별자만 남고 경로, 서비스 이름, 서버 이름이 빠지면 인터페이스에 가져오기 성공이라고 표시돼도 연결되지 않을 수 있습니다.

WebSocket 요청의 Host와 TLS 핸드셰이크에서 사용하는 서버 이름도 구분해야 합니다. 둘은 같을 수도 있고 서버의 리버스 프록시 구성에 따라 다를 수도 있으므로 도메인 두 개를 봤다고 임의로 하나로 합치지 마세요. 경로도 그대로 보존해야 합니다. 대소문자, 맨 앞의 슬래시, 쿼리 문자열이 서버 라우팅에 영향을 줄 수 있습니다. 노드가 도메인 대신 주소로 직접 연결되고 인증서는 도메인으로 발급됐다면 서버 이름 필드가 특히 중요합니다. 그렇다고 인증서 검사를 건너뛴 채 계속 사용해도 된다는 뜻은 아닙니다.

어떤 조합을 선택할지는 먼저 설정 출처에서 제공한 전체 구성을 확인한 다음 로컬 코어가 이를 구현할 수 있는지 점검하세요. 이미 VMess 노드가 안정적으로 작동한다면 VLESS 필드가 더 적다는 이유만으로 옮길 필요는 없습니다. 새 설정을 만들 때도 이름만 보고 더 빠르다고 판단하지 마세요. 첫 연결에 걸리는 시간은 전송 방식과 보안 핸드셰이크가 함께 좌우하며 연결 재사용, 서버 구현, 네트워크 왕복 시간에 따라 결과가 달라집니다. 두 프로토콜을 번갈아 선택하기보다 로그에서 실패한 단계를 확인해 문제를 해결하세요.

Trojan: TLS 연결 점검

TLS 채널 안의 프록시 요청 이해하기

Trojan은 TLS 연결 안에 프록시 요청을 넣고 비밀번호 인증과 비교적 간단한 요청 형식으로 트래픽을 전달합니다. 바깥쪽 보안 채널과 안쪽 프록시 인증을 나눠 이해해야 합니다. 먼저 외부 채널에서 서버 신원을 확인하고 암호화 연결을 만든 다음, 내부에서 프록시 인증 정보와 대상 요청을 확인합니다. 비밀번호가 맞아도 인증서가 일치하지 않으면 인증 전에 연결이 실패할 수 있습니다. 인증서 검사가 통과돼도 프록시 비밀번호, 전달 권한, 대상 접근이 정상이라는 보장은 없습니다.

일반적인 매개변수에는 서버, 포트, 비밀번호, 서버 이름이 포함됩니다. 배포에 따라 전송 옵션이 추가될 수 있지만 Trojan이라는 이름만 보고 모든 구현이 같은 확장 기능을 지원한다고 단정하지 마세요. 서버에서 명시한 설정 형식을 따르세요. 노드를 직접 추가할 때는 먼저 핵심 필드를 입력해 기본 연결이 되는지 확인한 다음 필요한 추가 옵션을 넣으세요. 서로 다른 노드 예제의 매개변수를 조합해 서버에서 구성한 적 없는 설정을 만들지 마세요.

서버 주소와 인증서 이름은 서로 다른 필드입니다

서버 주소는 클라이언트가 연결할 위치를 지정하고, TLS 서버 이름은 핸드셰이크와 인증서 이름 확인에 사용됩니다. 서버 주소에 도메인을 사용하면 둘이 같은 경우가 많지만 고정 주소로 연결할 때는 인증서에 해당하는 이름을 별도로 지정해야 할 수 있습니다. 서버 주소를 서버 이름에 그대로 입력한다고 인증서가 자동으로 일치하는 것은 아닙니다. 인증서 이름 오류가 발생하면 제공업체가 요구한 이름과 인증서 적용 범위를 확인하세요. 검사를 꺼서 문제가 해결됐다고 여기지 마세요.

인증서에서는 유효 기간, 신뢰 체인, 기기 시간도 확인해야 합니다. 휴대전화 날짜가 잘못되면 정상 인증서가 아직 유효하지 않거나 이미 만료된 것으로 표시될 수 있고, 서버에 중간 인증서가 빠져 있으면 기기마다 결과가 달라질 수 있습니다. 컴퓨터에서는 연결되지만 휴대전화에서는 실패한다고 해서 휴대전화의 코어가 Trojan을 지원하지 않는 것은 아닙니다. 먼저 두 기기의 시간과 시스템 신뢰 저장소, 오류 로그를 비교하세요. 실제로 비공개 인증서를 사용하는 서비스라면 지원되는 방식으로 신뢰 인증서나 인증서 고정 기능을 설정하고 검사를 계속 건너뛰지 마세요.

핸드셰이크 단계별로 오류 원인 좁히기

로그에 연결 시간 초과가 표시되면 먼저 주소 조회, 포트 접근성, 서비스 상태를 확인하세요. TLS 핸드셰이크나 인증서 오류가 있다면 보안 계층을 점검합니다. 핸드셰이크가 성공한 직후 연결이 끊긴다면 비밀번호, 프로토콜 형식, 서버 권한을 확인하세요. 중간 네트워크 장비가 연결을 끊을 수도 있어 오류 유형만으로 원인을 단정할 수는 없지만, 한 번에 여러 옵션을 바꾸기보다 단계별로 범위를 좁히는 편이 정확합니다. 한 번에 하나만 조정하고 변경 전후 로그의 시간을 기록하세요.

Trojan에서 앱 데이터는 대개 TLS를 거치지만 대상 웹사이트의 HTTPS 연결은 별개의 계층입니다. 프록시 채널의 인증서는 프록시 서버가 제공하고 웹사이트 인증서는 대상 웹사이트가 제공합니다. 브라우저에 웹사이트 인증서 오류가 표시되면 대상 사이트 연결 문제인지 확인하고, 클라이언트 로그에 프록시 인증서 오류가 표시되면 노드 보안 매개변수를 점검하세요. 두 계층의 오류를 구분하면 브라우저 설정을 잘못 바꾸거나 관계없는 문제 해결 담당자에게 노드 비밀번호를 보내는 일을 피할 수 있습니다.

속도 면에서 TLS가 반드시 느리거나 빠른 것은 아닙니다. 첫 연결 시간은 네트워크 왕복, 인증서 처리, 전송 설정에 영향을 받고, 지속적인 전송 성능은 대역폭, 혼잡, 서버 리소스의 영향을 더 많이 받습니다. 안정적으로 관리되는 TLS 환경은 검증된 인증서와 운영 절차를 활용하기 쉽지만 인증서 갱신도 계속 관리해야 합니다. 프로토콜 이름의 길이를 비교하기보다 서비스 제공업체가 지속적으로 관리하는지, 매개변수가 완전한지, 현재 기기에서 인증서를 올바르게 확인할 수 있는지를 우선 살펴보세요.

신뢰할 수 있는 Trojan 설정이 있다면 일상적인 연결 후보로 두고 웹페이지, 장시간 연결, 필요한 UDP 앱을 실제로 확인해 보세요. 테스트 버튼 결과만 보고 모든 환경에서 사용할 수 있다고 판단하지 마세요. 테스트 대상과 방식은 앱의 실제 연결과 다릅니다. 웹페이지가 열려도 백그라운드 푸시, 음성 통화, 모든 도메인 조회 경로가 정상이라는 뜻은 아닙니다.

Hysteria2와 TUIC: QUIC 기반 연결의 장단점

먼저 UDP 경로가 적합한지 확인하세요

Hysteria2와 TUIC는 모두 QUIC를 주요 기반 기술로 사용하지만 서로 다른 프로토콜이므로 인증, 데이터 구성, 설정 필드는 호환되지 않습니다. QUIC는 일반적으로 UDP 위에서 작동하며 보안 핸드셰이크, 스트림 관리, 혼잡 제어 등을 결합합니다. 한 연결에서 여러 데이터 스트림을 함께 처리하고 일부 전송 계층의 병목을 개선할 수 있지만, 네트워크가 UDP를 제한하거나 주소 매핑이 불안정하거나 패킷 손실이 지속되면 프로토콜만으로 사용할 수 없는 경로를 만들어낼 수는 없습니다.

QUIC의 다중 스트림 기능이 패킷 손실의 영향을 없애 주는 것은 아닙니다. 각 스트림의 데이터는 프로토콜 규칙에 따라 복구해야 하고, 여러 스트림은 제한된 대역폭과 혼잡 상태를 공유합니다. 무선 신호가 약하거나 서버 출구가 혼잡하거나 경로 용량이 부족하면 실제 전송량은 떨어집니다. 사용할 가치가 있는지는 현재 네트워크의 UDP 연결 상태, 장시간 연결의 안정성, 사용 중인 작업의 이점을 살펴 판단하세요. 소개에 ‘다중화’가 나온다고 모든 환경에서 더 빠르다고 단정하지 마세요.

Hysteria2의 대역폭 및 인증 매개변수

Hysteria2는 QUIC 기반 프록시 전송을 위한 프로토콜로, 인증 정보, TLS 서버 이름, 서버에서 사용하는 추가 메커니즘을 확인해야 합니다. 첫 번째 Hysteria와 표시 이름만 바꿔 서로 대체할 수는 없습니다. 일부 배포에서는 대역폭 관련 설정으로 데이터 전송 방식을 조절하고 조건에 따라 혼잡 제어 방식을 선택하기도 합니다. 클라이언트의 대역폭 값은 속도 측정 결과가 아니며 숫자를 높인다고 실제 회선 속도가 빨라지지도 않습니다. 현재 구현과 서버 제약을 함께 고려해야 합니다.

대역폭 추정에 따라 전송하는 방식을 사용한다면 실제 회선에 맞는 값을 입력하세요. 지나치게 높게 잡으면 다른 트래픽을 방해하고 패킷 손실을 늘릴 수 있으며, 너무 낮으면 사용 가능한 전송량이 제한될 수 있습니다. 인터넷 요금제에 표시된 속도를 현재 무선 네트워크가 지속적으로 처리할 수 있는 속도와 같다고 보지 마세요. Mbps와 MB/s도 혼동하지 마세요. 서버에서 난독화나 포트 관련 옵션을 사용한다면 클라이언트에서도 일치시켜야 합니다. 정보가 없다면 원본 설정 제공처에 확인하세요.

TUIC 전송 옵션과 모바일 네트워크

TUIC도 QUIC 기반으로 프록시 연결을 구성하며, 일반적인 설정에는 사용자 식별자, 비밀번호, 혼잡 제어, UDP 전달 옵션이 포함됩니다. 프로토콜 개정판마다 차이가 있으므로 구형 클라이언트가 특정 TUIC 구현을 지원한다고 해서 현재 서비스 전체에 연결할 수 있는 것은 아닙니다. 가져오기에 실패하면 사용자 식별자를 계속 바꾸기보다 코어가 지원하는 개정판과 필드를 먼저 확인하세요. 서버에서 지정한 애플리케이션 계층 프로토콜 협상 매개변수도 지침에 따라 유지해야 하며 다른 노드 설정을 그대로 복사하면 안 됩니다.

일부 설정에는 초기 데이터나 빠른 복구와 관련된 옵션이 있습니다. 이러한 기능은 기존 세션 상태와 양쪽 구현에 의존하므로 매번 완전히 새로운 연결에서 같은 비용을 줄여 주지는 않으며 재전송 공격 같은 보안 경계도 고려해야 합니다. 일반 사용자는 신뢰할 수 있는 설정의 기본값을 유지하고 테스트 버튼의 일회성 결과를 높이려고 옵션을 임의로 켜지 않는 것이 좋습니다. 휴대전화가 Wi-Fi와 모바일 데이터 사이를 전환하면 주소, 포트 매핑, 시스템 네트워크 상태가 모두 달라질 수 있습니다. 연결이 원활히 복구되는지는 직접 확인해야 하며 QUIC라는 이름만으로 판단할 수 없습니다.

이런 노드를 사용할 때는 확인이 끝난 다른 전송 방식도 비교용으로 남겨 두는 것이 좋습니다. 같은 네트워크에서 TCP 계열 노드는 정상인데 QUIC 계열 노드가 계속 실패한다면 전역 도메인 조회 설정을 바로 바꾸지 말고 UDP 경로와 서버의 수신 대기 상태부터 점검하세요. 대용량 전송에서만 문제가 발생하면 경로의 최대 전송 단위, 패킷 손실, 전송 설정, 기기 리소스를 확인하세요. 반복 가능한 조건에서 나타난 차이만 선택의 근거가 될 수 있습니다. 우연히 한 번 빨랐거나 느렸다는 것만으로 프로토콜의 우열을 판단하기는 어렵습니다.

속도와 배터리: 작업별 리소스 비용 확인

‘속도’를 단계별로 나눠 살펴보세요

먼저 개선하려는 것이 페이지 첫 로딩, 지속 다운로드, 네트워크 전환 후 복구 중 무엇인지 정하세요. 앱 요청 하나에도 도메인 조회, 연결 설정, 보안 핸드셰이크, 프록시 인증, 대상 서버 응답 등이 포함될 수 있습니다. 속도 테스트 버튼은 대개 일부 단계만 측정하고 기존 연결 상태를 재사용할 수도 있습니다. 첫 요청이 빠르다고 지속 전송량이 더 많다는 뜻은 아니며, 다운로드 속도가 빨라도 대화형 앱의 응답이 빨라지는 것은 아닙니다. 프로토콜은 각 단계에 다르게 영향을 주므로 실제 작업을 기준으로 비교하세요.

SS, VMess, Trojan, VLESS, Hysteria2, TUIC를 빠른 순서대로 나열할 수 있는 신뢰할 만한 일반 기준은 없습니다. 서로 다른 서버와 네트워크 경로를 사용하는 두 회선의 테스트 결과는 주로 회선 차이를 반영합니다. 같은 서버를 사용하더라도 수신 포트, 전송 방식, 혼잡 제어, 서버 부하에 따라 결과가 달라질 수 있습니다. 프로토콜 차이를 평가하려면 하드웨어, 네트워크, 서버 리소스, 테스트 대상을 최대한 고정하고 비교하려는 항목 하나만 바꾸세요.

프로세서, 메모리, 연결 수를 함께 확인하세요

프로세서 사용량은 암호화, 데이터 복사, 프로토콜 해석, 혼잡 제어, 트래픽 처리 등 여러 작업에서 발생합니다. 기기가 특정 암호화 방식의 하드웨어 가속을 지원하는지에 따라 알고리즘별 효율도 달라집니다. 메모리는 연결 수, 버퍼, 규칙 모음, 도메인 조회 캐시의 영향을 받으므로 클라이언트의 전체 메모리를 특정 노드 프로토콜 탓으로 돌릴 수는 없습니다. 상세 로그, 반복적인 테스트, 대시보드 새로 고침도 리소스를 더 사용하므로 비교할 때 조건을 동일하게 유지하세요.

연결을 재사용하면 일부 핸드셰이크를 줄일 수 있지만 항상 일정한 이득이 생기는 것은 아닙니다. 여러 작업이 연결을 공유하면 스케줄링과 혼잡이 서로 영향을 줄 수 있고, 이미 다중 스트림을 지원하는 프로토콜에 다른 다중화 기능을 추가해도 필요하지 않을 수 있습니다. 지원 여부와 적합성, 매개변수 설정은 현재 코어와 서버에 따라 달라집니다. 일반적으로는 설정 출처의 기본값을 유지하세요. 짧은 연결이 많아지는 문제가 명확할 때만 통제된 비교를 하고, ‘가속’ 옵션을 한꺼번에 모두 켜지 마세요.

휴대전화 배터리는 백그라운드 활동부터 확인하세요

모바일 기기의 배터리 소모는 암호화 복잡성만으로 결정되지 않습니다. 셀룰러 무선 모듈의 활성화, 장시간 연결 유지, 연결 유지 신호 빈도, 반복 재연결, 백그라운드 앱 트래픽이 주요 원인일 수 있습니다. 노드가 유휴 상태인데도 배터리가 줄어든다면 앱이 계속 네트워크를 사용하는지, 연결이 반복해서 끊기는지, 구독 업데이트나 상태 확인이 너무 잦은지 먼저 확인하세요. QUIC를 사용한다는 이유만으로 배터리를 더 쓴다고 단정할 수도 없고, 프로토콜 설정 필드가 적다는 이유만으로 배터리를 절약한다고 볼 수도 없습니다.

배터리 사용량을 비교할 때는 화면 밝기, 네트워크 유형, 앱 작업, 관찰 시간을 비슷하게 맞추고 유휴 상태와 지속 전송을 구분하세요. 시스템 배터리 통계는 가상 네트워크 인터페이스의 트래픽 전달 작업을 클라이언트 사용량에 포함할 수 있습니다. 따라서 클라이언트 비중이 늘어도 기기 전체 소비 전력이 같은 비율로 늘었다고 단정할 수 없습니다. 반대로 시스템이 백그라운드 작업을 중지해 배터리가 절약된 것처럼 보여도 앱 연결이 끊길 수 있습니다. 앱별 사용 비율만 보지 말고 필요한 작업이 계속 가능한지도 함께 확인하세요.

기기, 네트워크 유형, 선택한 노드, 트래픽 처리 방식, 테스트 작업, 이상 현상을 간단히 기록해 두세요. 먼저 평소처럼 웹페이지와 앱을 사용한 뒤 장시간 전송과 네트워크 전환 후 복구를 확인합니다. 몇 차례 반복해 일관된 경향이 있는지 살펴보세요. 종합 점수를 만들 필요는 없습니다. 테스트 중 기기가 뜨거워지면 대용량 작업을 멈추고 기기가 정상 상태로 돌아온 다음 비교하세요. 발열로 인한 성능 저하가 후속 결과를 바꾸면 프로토콜 차이가 아니라 온도 차이를 비교하게 됩니다.

트래픽 진입 방식도 별도로 통제해야 합니다. 시스템 프록시는 시스템 프록시 설정을 따르는 앱에만 영향을 주는 경우가 많고, TUN은 라우팅 조건에 맞는 트래픽을 네트워크 계층에서 처리하지만 제외 항목과 플랫폼 제한이 남아 있습니다. TUN을 켜면 처리하는 트래픽이 늘어나므로 리소스 변화가 노드 프로토콜 때문이 아닐 수 있습니다. 두 방식의 차이를 알아보려면 TUN 모드와 시스템 프록시 비교를 참고하세요. 최종 선택은 사용 환경과 무관한 단일 테스트 결과가 아니라 필요한 작업을 안정적으로 마치는 데 초점을 맞춰야 합니다.

구독 호환성: 형식이 맞아도 기능이 모두 포함된 것은 아닙니다

가져온 데이터의 형식부터 확인하세요

구독 URL은 설정을 가져오는 입구일 뿐 반환되는 콘텐츠가 한 가지 형식이라는 뜻은 아닙니다. 제공되는 콘텐츠는 전체 Clash 설정, 프록시 노드 목록, 인코딩된 공유 링크 모음, 다른 코어에서 사용하는 설정일 수 있습니다. 전체 설정에는 보통 프록시, 정책 그룹, 규칙, 도메인 조회 설정이 포함됩니다. 노드 목록에는 연결 매개변수만 들어 있어 그대로 활성화할 라우팅 규칙이 없을 수도 있습니다. 가져오기 전에 클라이언트에서 전체 설정, 노드 구독, 프록시 목록 중 무엇을 요구하는지 확인해 서로 다른 형식의 데이터를 같은 위치에 넣지 마세요.

공유 링크도 모든 배포 정보를 완벽히 담는 것은 아닙니다. 일부 프로토콜 매개변수는 링크의 쿼리 부분으로 전달되는데 변환 도구가 해당 필드를 인식하지 못하면 누락될 수 있습니다. 일부 링크 규약은 특정 클라이언트에서만 구현되기도 합니다. 가져온 노드 이름이 맞다고 해서 보안 계층, 전송 경로, 플러그인 옵션까지 모두 보존됐다고 볼 수는 없습니다. 복잡한 노드는 원본 안내와 핵심 필드를 대조하세요. 필수 매개변수가 빠졌다면 같은 정보를 반복 변환하기보다 대상 코어에 맞는 원본 설정을 요청하는 편이 좋습니다.

프록시 목록과 전체 설정을 구분하세요

mihomo의 프록시 목록 기능을 사용하면 외부에서 노드를 가져온 뒤 정책 그룹에서 참조할 수 있습니다. 목록 데이터와 전체 설정은 바깥쪽 구조가 다르므로 서로 바꿔 사용할 수 없습니다. 아래 예시는 로컬 목록을 참조하는 방법만 보여 줍니다. 기존 설정에 병합하고 지정된 경로에 유효한 프록시 목록 파일을 두어야 합니다. 서버 정보나 인증 정보는 포함하지 않으므로 이 조각만으로 노드를 사용할 수는 없습니다. 파일 경로는 현재 클라이언트가 접근할 수 있는 작업 디렉터리에 있어야 합니다.

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml

proxy-groups:
  - name: Proxy
    type: select
    use:
      - local-nodes

설정 검사를 통과한 뒤에도 정책 그룹에서 해당 목록을 실제로 참조하는지 확인해야 합니다. 노드를 가져왔는데 정책 그룹에 보이지 않는다면 참조가 빠졌거나 필터 조건이 노드를 제외했을 수 있습니다. 모든 문제가 프로토콜 때문인 것은 아닙니다. 전체 설정에서 규칙이 참조하는 정책 그룹 이름이 실제로 존재해야 하며 대소문자와 문자도 일치해야 합니다. Proxy라는 그룹 이름을 한국어로 바꾸고 규칙에는 기존 이름을 남겨 두면 참조 오류가 발생할 수 있습니다. 이름을 변경하기 전에 모든 참조 위치를 검색하세요.

변환과 오버라이드에서 주의할 점

구독 변환은 이미 존재하는 정보를 다시 구성할 뿐 누락된 인증서 이름, 공개 키, 플러그인 비밀번호를 알아내거나 구형 코어에 새 프로토콜 지원을 추가하지는 못합니다. 변환 서비스가 구독 URL과 노드 인증 정보를 볼 수도 있으므로 신뢰할 수 있는 방식으로 처리하고 개인 구독을 출처를 알 수 없는 페이지에 붙여 넣지 마세요. 다른 사람의 도움이 필요하다면 민감한 정보를 제거한 설정 구조와 오류 유형만 공유하세요. 전체 구독 링크를 공개하거나 인증 정보가 담긴 화면을 공개 게시판에 올리지 마세요.

클라이언트 오버라이드는 진입 포트, 규칙 추가, 도메인 조회 설정 등 로컬 기본 설정을 보존할 때 사용하지만 병합 순서와 배열 처리 방식은 클라이언트마다 다릅니다. 어떤 작업은 목록 전체를 덮어쓰고, 어떤 작업은 이름을 기준으로 병합하며, 스크립트로 최종 설정을 생성하는 방식도 있습니다. 구독 업데이트 후 노드는 정상인데 규칙이 작동하지 않으면 원본 구독 파일만 보지 말고 실제 적용된 설정을 확인하세요. 문제를 찾을 때는 불필요한 오버라이드를 끄고 원본 설정이 작동하는지 확인한 다음 로컬 변경 사항을 하나씩 다시 적용하세요.

YAML은 들여쓰기와 데이터 유형이 중요합니다. 목록 항목에는 올바른 하이픈을 사용하고 계층은 공백으로 표시해야 합니다. 문자열에 특수 문자가 있으면 알맞은 따옴표로 감싸세요. 숫자나 불리언처럼 보이는 비밀번호가 잘못된 유형으로 해석되지 않도록 주의하세요. 영문 콜론 대신 전각 콜론을 쓰거나 보기 좋게 정렬하려고 탭 문자를 넣지 마세요. 편집한 뒤에는 설정을 활성화하기 전에 클라이언트의 설정 검사나 미리보기 기능을 사용하세요. 구문 오류와 네트워크 오류는 발생 단계가 다르므로 함께 다루지 마세요.

마지막으로 업데이트 범위를 확인하세요. 콘텐츠를 한 번 가져왔다는 것은 서버가 응답했다는 뜻일 뿐입니다. 콘텐츠가 유효한지, 코어가 불러왔는지, 새 결과가 현재 설정으로 전환됐는지도 확인해야 합니다. 업데이트에 실패했을 때 최근에 사용한 설정을 보존하면 계속 사용할 수 있지만 인터페이스에 표시되는 노드가 이전 캐시일 수도 있습니다. 최초 가져오기, 권한, 포트 충돌은 첫 설치 후 초기 설정을 참고하세요. Fake-IP 로컬 설정은 시작 가이드의 Fake-IP 안내에서 확인할 수 있습니다.

사용 환경별 선택: 필수 조건을 확인한 뒤 사용 경험을 비교하세요

사용 중인 서비스와 기기 지원 범위에 따라 후보를 좁히세요

선택은 특정 프로토콜을 최고로 정하는 대신 실제 사용 가능한 조건부터 확인해야 합니다. 서비스 제공업체가 제공하는 노드 유형, 기기에서 실행할 수 있는 클라이언트, 코어가 지원하는 프로토콜 조합, 현재 네트워크에서 필요한 전송 방식을 사용할 수 있는지 적어 보세요. 하나라도 맞지 않으면 설정을 계속 바꿔도 해결되지 않습니다. 일반 사용자는 다운로드 페이지에서 우선 추천하는 Clash Plus를 선택해 운영체제 요구 사항에 맞게 설치한 뒤 실제 코어와 설정 지원 범위를 확인하면 됩니다. 프로토콜 자료는 판단을 돕기 위한 것이며 현재 클라이언트의 지원 안내를 대신하지 않습니다.

데스크톱에서 웹 탐색이나 업무를 할 때는 매개변수가 완전하고 안정적으로 관리되며 실제 업무에서 검증된 노드를 우선 선택하세요. 기존 SS, Trojan, VMess, VLESS 노드도 요구 사항을 충족할 수 있으므로 프로토콜 이름이 새로워졌다는 이유로 설정 전체를 다시 만들 필요는 없습니다. 명령줄이나 특정 앱이 프록시를 거치지 않는 것이 문제라면 노드 유형을 바꾸기 전에 트래픽 진입 설정과 라우팅을 확인하세요. 앱 트래픽이 코어에 들어오지 않는다면 어떤 서버 프로토콜을 사용해도 앱의 연결 경로는 바뀌지 않습니다.

휴대전화, 장시간 전송, 제한된 네트워크를 구분하세요

휴대전화에서 네트워크를 자주 전환한다면 정지 상태의 첫 연결만 측정하지 말고 복구 성능, 백그라운드 연결 유지, 배터리를 우선 확인하세요. 시스템이 절전 정책으로 클라이언트를 일시 중지하거나 네트워크 전환 후 가상 네트워크 인터페이스와 라우팅을 다시 구성할 수 있습니다. 먼저 필요한 권한을 허용하고 운영체제 안내에 따라 백그라운드 실행을 설정한 뒤 노드를 비교하세요. 화면을 잠근 뒤에만 연결이 끊기고 로그에 명확한 프로토콜 오류가 없다면 시스템 작업 관리를 먼저 확인하세요. 네트워크를 전환할 때마다 재인증에 실패한다면 세션 복구와 서버 상태를 점검하세요.

장시간 다운로드, 대규모 동기화, 지속적인 데이터 전송을 한다면 필수 지원 조건을 충족하는 Hysteria2·TUIC와 기존 TCP 계열 방식을 함께 비교할 수 있습니다. UDP 경로가 안정적이고 전송 설정이 회선 용량에 맞는 경우에만 비교하세요. 회사, 학교, 방문자용 네트워크는 지정 프록시를 통해 연결해야 할 수 있으므로 특정 연결을 외부로 직접 설정하는 방식이 네트워크 조건에 맞지 않을 수 있습니다. 네트워크 사용 규칙을 따르고 허용된 연결 방식을 사용하세요. 네트워크 정책 때문에 접속할 수 없는 상황을 특정 프로토콜의 ‘성능 저하’로 오해하지 마세요.

정해진 순서로 문제를 해결하고 설정 전체를 한꺼번에 바꾸지 마세요

문제가 발생하면 먼저 설정 출처가 유효한지, 구독 업데이트 결과가 실제로 적용됐는지 확인한 다음 시스템 시간과 기본 네트워크 연결을 점검하세요. 그다음 주소 조회, 연결 설정, 보안 핸드셰이크, 프록시 인증 중 어느 단계에서 실패했는지 살펴보세요. 특정 노드만 문제라면 해당 노드의 매개변수와 서버 상태를 우선 비교하고 모든 노드에 문제가 있다면 로컬 트래픽 진입, 도메인 조회, 포트, 네트워크 경로를 먼저 확인하세요. 문제 범위를 제대로 판단하는 것이 고급 옵션을 하나씩 켜 보는 것보다 대개 효과적입니다.

연결은 되지만 특정 사이트만 실패한다면 규칙 적용, 대상 도메인 조회, 앱 자체 설정을 확인하세요. 웹페이지는 열리지만 게임이나 음성 통화에 문제가 있으면 UDP 지원, 트래픽 처리 범위, 방화벽을 점검하세요. TUN을 켠 뒤 로컬 네트워크에 접근할 수 없다면 노드 비밀번호를 먼저 바꾸지 말고 라우팅 제외 항목과 로컬 주소 처리를 확인하세요. 현상과 변경 사항을 매번 기록하고 검증한 뒤 다음 단계로 넘어가세요. 자세한 문제 해결 순서는 노드 시간 초과 및 속도 테스트 실패 문제 해결 목록을 참고하세요.

서버와 라우터에서는 기기 아키텍처, 사용 가능한 메모리, 서비스 실행 권한, 저장 장치 쓰기 성능도 고려해야 합니다. 코어를 설치할 수 있다고 해서 많은 연결을 처리하기에 적합한 것은 아닙니다. 로그가 지나치게 많거나 상태 확인을 계속하면 저사양 기기에 부담이 될 수 있습니다. 일반 컴퓨터와 휴대전화에서는 그래픽 클라이언트로 설정을 관리하고, 무인 실행이 필요할 때 코어 패키지를 사용하세요. 데스크톱 클라이언트에서 생성한 시스템 경로 전체를 라우터에 그대로 복사하지 말고 목록 파일, 캐시 디렉터리, 인증서 파일을 읽을 수 있는지 확인하세요.

복구할 수 있는 기준 설정을 하나 보관하고 유효한 노드, 필요한 보안 매개변수, 트래픽 진입 방식을 기록하세요. 일상적인 작업에서 안정적으로 재현되는 개선만 장기 설정에 반영할 가치가 있습니다. 어떤 프로토콜도 올바른 인증 정보, 신뢰할 수 있는 서비스, 적절한 네트워크 환경을 대신할 수 없습니다. 이 페이지는 필드와 원리를 확인하는 참고 자료로 활용하고 처음 설정할 때는 시작 가이드를 따르세요. 설치 파일을 바꿔야 한다면 다운로드 페이지에서 플랫폼에 맞는 항목을 고르세요. 클라이언트, 코어, 구독 전체를 동시에 바꾸면 비교 기준을 잃을 수 있습니다.