Clash 프로토콜과 코어 기술 가이드

선택 기준 세우기: 프로토콜은 연결의 일부

클라이언트에 표시되는 프로토콜 이름은 연결 방식의 일부만 설명합니다. 일반적인 요청은 앱에서 시작해 시스템 프록시나 가상 네트워크 인터페이스를 거쳐 로컬 코어에 전달됩니다. 코어가 도메인을 처리하고 규칙을 적용한 뒤, 선택한 아웃바운드 프로토콜로 원격 서버에 연결합니다. 어느 한 단계에서든 문제가 생기면 웹페이지가 열리지 않거나, 연결이 늦게 설정되거나, 다운로드가 중단될 수 있습니다. 이런 증상을 모두 프로토콜 탓으로 돌리면 유형만 바꿔 보다가 실제 문제 지점을 놓치기 쉽습니다.

클라이언트, 코어, 프로토콜, 전송 방식 구분하기

클라이언트는 화면과 설정 관리, 시스템 연동을 담당합니다. 코어는 설정을 해석하고 트래픽을 분기·송수신합니다. 프로토콜은 클라이언트와 서버가 트래픽을 인증하고 캡슐화해 전달하는 방식을 정합니다. 전송 방식은 TCP, WebSocket, HTTP/2, QUIC 같은 메커니즘으로 데이터를 실어 나릅니다. TLS는 특정 연결 계층에서 인증과 암호화를 담당합니다. 각 요소는 서로 다른 계층에 있으므로 “VLESS 지원”이 “모든 VLESS 전송 조합 지원”을 뜻하지는 않습니다. 화면에 옵션이 있다고 해서 현재 코어가 해당 기능을 제공한다고 단정할 수도 없습니다.

노드에는 주소, 포트, 인증 정보, 서버 이름과 전송 매개변수도 포함됩니다. 같은 프로토콜이라도 서버 장비와 네트워크 경로, 부하 조건은 전혀 다를 수 있습니다. SS와 Hysteria2 노드가 있다고 해서 이름만 보고 후자가 더 빠르다고 판단할 수는 없습니다. 서버 위치와 가용 대역폭, 클라이언트에서 서버까지의 경로가 캡슐화 오버헤드보다 체감 성능에 더 큰 영향을 줄 수 있습니다. 먼저 환경의 제약을 확인한 뒤 구현 방식을 비교하세요. 프로토콜에 영구적인 속도 등급을 붙이는 것은 적절하지 않습니다.

목표를 먼저 정하고 성능을 비교하세요

짧은 웹페이지를 여는 작업은 최초 DNS 조회와 핸드셰이크, 첫 응답이 중요합니다. 연속 다운로드에서는 장시간 처리량과 혼잡 제어를 살펴봐야 합니다. 음성 통화, 회의, 게임에서는 지터와 패킷 손실, UDP 전달이 중요하고, 휴대전화 대기 시간에는 연결 유지와 기기를 깨우는 횟수가 영향을 줍니다. 목표는 서로 충돌할 수 있습니다. 적극적인 탐지와 잦은 재연결은 끊어진 연결을 빨리 찾아내지만 무선 모듈의 활동을 늘릴 수 있습니다. “최적의 프로토콜”을 말할 때는 어떤 네트워크, 기기, 부하 조건에서인지 함께 밝혀야 합니다.

보안 비교도 계층별로 구체적으로 해야 합니다. 인증 방식, 암호화 알고리즘, 인증서 검증, 자격 증명 보관, 서버 유지 관리가 함께 보안 경계를 이룹니다. 새 프로토콜이라는 이유만으로 자동으로 더 안전해지는 것은 아니며, 오래된 프로토콜 이름만으로 실제 설정을 확인할 수 있는 것도 아닙니다. TLS를 사용하는 방식은 인증서 체인과 이름 일치 여부, 기기 시간을 확인해야 합니다. 공유 키를 사용하는 방식은 구독 주소와 인증 정보가 유출되지 않도록 주의하세요. 암호화 전송은 해당 연결 구간을 보호하지만 원격 서비스까지 종단 간 콘텐츠를 보호해 주지는 않습니다.

이후 장에서는 이 세 계층을 기준으로 점차 점검 범위를 좁혀 갑니다. 먼저 코어가 무엇을 읽을 수 있는지 확인하고, 프로토콜 설계의 차이를 이해한 다음, 실제 작업으로 검증합니다. 결과를 기록할 때는 네트워크 유형, 클라이언트와 코어 정보, 사용한 전송 방식, 오류 증상을 적어 두세요. 네트워크가 바뀌어도 다시 판단할 수 있고, 우연한 결과를 언제나 통하는 경험으로 착각하지 않게 됩니다. 클라이언트가 필요하다면 클라이언트 다운로드 페이지에서 운영체제와 아키텍처에 맞는 항목을 선택하세요.

코어 계열: 기존 Clash, Meta, mihomo

Clash 생태계에는 모든 환경을 하나로 해결하는 단일 클라이언트가 있는 것이 아닙니다. 기존 Clash는 설정, 프록시 그룹, 규칙, 로컬 제어 인터페이스 등 널리 쓰이는 구조를 마련했고, 이후 포크 프로젝트들이 프로토콜과 네트워크 기능을 확장했습니다. Clash.Meta는 발전 과정에서 사용된 프로젝트 이름이며, mihomo는 해당 프로젝트가 이후 사용한 이름입니다. 자료에서 Meta와 mihomo를 볼 때는 대체로 같은 기술 계보를 가리키지만, 이름에 Meta가 들어간 과거 설치 패키지가 현재 문서에 나오는 모든 기능을 갖췄다고 볼 수는 없습니다.

같은 계열이어도 기능이 모두 같지는 않습니다

기존 Clash의 공개 오픈소스 구현과 과거의 다른 Premium 구현도 구분해야 합니다. 일부 오래된 문서에서는 규칙 프로바이더, 가상 네트워크 인터페이스, 스크립트 같은 기능을 뭉뚱그려 “기존 Clash 기능”으로 설명하지만, 실제로는 특정 구현에만 해당할 수 있습니다. 기존 upstream은 유지 관리가 중단되었으며, 오래된 설정이 새 코어에서 호환될 수는 있어도 새 기능이 오래된 코어에 추가되지는 않습니다. 가이드를 읽을 때는 제목에 Clash라는 단어가 있는지만 보지 말고 구체적인 필드와 구현 설명을 확인하세요.

mihomo는 널리 쓰이는 YAML 설정 구조를 이어받으면서 VLESS, Hysteria2, TUIC, DNS, 스니핑, TUN 관련 기능을 추가하거나 개선했습니다. 여기서도 “지원” 여부는 사용하는 빌드와 버전에 따라 달라집니다. 같은 프로토콜이라도 특정 전송 방식, 인증 방식, 확장 필드는 기본 지원보다 나중에 추가됐을 수 있습니다. 서드파티 클라이언트는 코어를 고정하거나 교체를 허용할 수 있고, 설정을 생성하는 자체 계층을 둘 수도 있습니다. 따라서 웹사이트 문서, 코어 문서, 클라이언트 화면을 함께 확인해야 합니다.

클라이언트에서 실제 실행 중인 코어 확인하기

먼저 클라이언트의 정보, 코어 관리 또는 실행 로그 화면에서 실제로 구동 중인 코어 이름과 빌드 정보를 확인하세요. 이어 설정을 직접 불러오는지, 구독 변환이나 덮어쓰기, 병합 과정을 거쳐 코어에 전달하는지 살펴봅니다. 화면에서 가져오기에 성공했다는 것은 관리 계층이 파일을 받았다는 뜻일 뿐입니다. 시작 로그에 파싱 오류가 없어야 생성된 설정이 최소한 기본적으로 읽힌 것입니다. 마지막으로 실제 연결을 시도해 선택한 아웃바운드가 인증과 데이터 전송을 완료하는지 확인하세요.

업그레이드 전에 정상 작동하는 설정 사본을 보관하고 시스템 프록시, TUN, DNS, 수신 대기 포트 상태를 기록하세요. 클라이언트와 코어, 구독 템플릿을 한꺼번에 바꾸면 문제의 원인을 찾기 어려워집니다. 기존 연결 방식을 유지하면서 한 계층만 업그레이드하고, 검증을 마친 뒤 새 필드를 적용하는 편이 안전합니다. 클라이언트가 시작할 때 설정을 다시 생성한다면, 곧 덮어쓰일 실행 파일을 직접 수정하지 말고 클라이언트가 제공하는 덮어쓰기 기능을 사용하세요.

그래픽 클라이언트로는 Clash Plus를 우선 추천합니다. 플랫폼과 사용 방식에 따라 다운로드 페이지에 소개된 Clash Verge Rev, FlClash 등도 비교해 볼 수 있습니다. 추천 순서와 별개로 기능을 확인해야 하며, 이름에 Clash가 들어간다는 이유만으로 mihomo를 사용한다고 추정해서는 안 됩니다. 보관용 Clash for Windows와 ClashX Meta는 과거 환경을 살펴보는 데는 도움이 되지만, 새 프로토콜 호환성을 판단하는 기준으로 삼기 어렵습니다. 화면별 차이는 클라이언트 선택 가이드에서 확인하고, 기능은 언제나 현재 실행 중인 코어를 기준으로 판단하세요.

SS와 VMess: 간결한 캡슐화와 구조화된 인증

Shadowsocks는 보통 SS로 줄여 부르며, 비교적 단순한 암호화 프록시 모델을 중심으로 발전했습니다. 클라이언트가 대상 주소를 지정하고, 앱 데이터를 정해진 암호화 및 전달 절차에 넘깁니다. 복잡한 설정 구성보다는 제한된 프로토콜 구조 안에서 안정적으로 트래픽을 전달하는 데 초점을 둡니다. VMess는 V2Ray 생태계에서 나온 프로토콜로, 자체 인증 및 데이터 캡슐화 방식을 갖추고 여러 전송 방식과 조합해 사용하는 경우가 많습니다. 두 프로토콜 모두 다양한 구현이 있지만, 오래 사용됐다는 사실만으로 설정 매개변수가 올바른지 확인할 필요가 없어지는 것은 아닙니다.

SS: 약칭보다 알고리즘과 구현이 중요합니다

SS 노드에는 최소한 서버 주소, 포트, 비밀번호, 암호화 방식이 필요합니다. 초기 스트림 암호 방식, 이후 널리 쓰인 AEAD 방식, Shadowsocks 2022 계열은 같은 매개변수를 임의로 섞어 쓸 수 있는 방식이 아닙니다. AEAD는 암호화와 함께 무결성 보호도 제공합니다. 암호화 방식에 따라 키 파생, 메시지 구조와 구현 요구 사항이 다릅니다. 클라이언트와 서버가 공통으로 지원하는 방식을 사용해야 하며, “연결될지 시험해 보려고” 알고리즘 이름을 임의로 바꾸면 안 됩니다.

하드웨어 가속을 지원하는 기기에서는 일부 AES 구현이 효율적일 수 있고, 다른 프로세서에서는 ChaCha20 계열이 더 적합할 수 있습니다. 하지만 운영체제, 암호화 라이브러리, 프로세서 특성이 모두 결과에 영향을 주므로 알고리즘 목록만으로 성능 순위를 매길 수는 없습니다. 암호화 방식 미지원 오류가 나타나면 시스템 프록시를 바꾸기 전에 코어 기능과 구독 내용을 확인하세요. 시스템 프록시는 앱이 로컬 프록시에 연결되는 방식을 정할 뿐, 없는 알고리즘 구현을 추가해 주지 않습니다.

SS는 TCP와 UDP를 전달할 수 있지만, 클라이언트 설정과 서버 구현, 네트워크 경로 모두 해당 전달 방식을 허용해야 합니다. 일부 확장은 플러그인을 사용해 전송 계층 기능을 추가하며, 플러그인 이름과 옵션, 서버 설정도 서로 일치해야 합니다. SS 링크를 가져올 수 있다고 해서 가져오기 도구가 플러그인 필드를 모두 보존한 것은 아닙니다. 기본 SS는 작동하지만 플러그인 조합이 실패한다면 암호화 자체만 탓하지 말고 변환 과정과 플러그인 지원 범위를 점검하세요.

VMess: 인증, 시간, 외부 전송 방식

VMess는 일반적으로 UUID 형식의 사용자 식별자를 사용하며, 과거 인증 방식과 비교적 새로운 AEAD 인증 방식을 구분합니다. 오래된 가이드의 호환성 매개변수는 구형 구현에서만 유효할 수 있습니다. 과거 설정을 현재 노드에 그대로 옮기거나 경험에 의존해 인증 관련 숫자를 바꾸지 마세요. 기기 시간이 크게 어긋나면 인증 판단에 영향을 줄 수 있으므로, 여러 기기 중 한 대에서만 실패한다면 자동 시간 설정부터 확인한 뒤 사용자 식별자, 전송 방식, TLS 관련 매개변수를 점검하세요.

VMess가 WebSocket 등 외부 전송 방식을 사용하는 경우 경로, 요청 호스트 이름, TLS 서버 이름은 각각 다른 역할을 합니다. WebSocket 경로는 서버 라우팅에 영향을 주고, HTTP 호스트 이름은 애플리케이션 계층 요청에 사용되며, TLS 이름은 연결에서 서버 신원을 확인하는 데 쓰입니다. 이 값들이 항상 같아야 하는 것은 아닙니다. 구독 변환 과정에서 필드 하나가 빠지면 핸드셰이크가 실패하거나 일반 웹사이트 응답이 돌아올 수 있습니다. 이런 오류는 서버에서 받은 전체 연결 정보를 기준으로 각 계층을 나눠 확인하세요.

이미 안정적으로 작동하는 SS 또는 VMess 서버를 사용 중이라면, 프로토콜 이름을 바꾸기보다 호환성 유지와 UDP 요구 사항 확인, 변환 손실 방지를 우선하세요. SS의 간결한 구조는 기본 연결 문제를 찾기 쉽고, VMess의 다양한 전송 조합은 매개변수를 더 꼼꼼히 기록해야 합니다. 실제 성능은 모두 서버 구성과 네트워크 경로에 달려 있습니다. 바꾸기 전에 같은 앱 작업을 사용해 콜드 스타트, 지속 전송, 네트워크 변경 후 복구를 각각 관찰하세요.

Trojan과 VLESS: TLS와 계층형 설계

Trojan과 VLESS는 최신 TLS 연결 방식을 지원하는 클라이언트에서 자주 볼 수 있지만, 이름만 다른 같은 프로토콜은 아닙니다. Trojan은 TLS 연결 안에서 인증과 프록시 전달을 수행하도록 설계되었으며, 비밀번호를 인증 정보로 사용하는 경우가 많습니다. VLESS는 V2Ray 관련 생태계에서 나온 프로토콜로, 간결한 프로토콜 구조와 외부 계층 기능을 지향하며 UUID로 사용자를 식별하는 경우가 일반적입니다. 두 프로토콜을 이해하려면 “프로토콜 자체의 역할”과 “외부 연결이 제공하는 기능”을 나눠서 봐야 합니다.

Trojan: TLS를 확인한 뒤 전달을 확인하세요

일반적인 Trojan 연결은 먼저 TLS 채널을 만든 다음 그 안에서 인증하고 대상 트래픽을 전달합니다. 따라서 인증서 검증, 서버 이름, 시스템 시간이 연결 성립 여부에 직접 영향을 줍니다. 주소는 도메인일 수도 있고 IP일 수도 있습니다. 하지만 IP로 연결한다고 해서 인증서도 반드시 해당 IP를 기준으로 검증해야 하는 것은 아닙니다. 클라이언트에서 기대하는 서버 이름을 별도로 지정할 수 있습니다. 이 이름은 실제 배포 설정과 일치해야 하며, 정상처럼 보이는 사이트 도메인을 임의로 입력해서는 안 됩니다.

TLS 핸드셰이크 오류가 발생하면 인증서 만료, 이름 불일치, 인증서 체인 누락, 기기 시간 오류, 포트에서 TLS 서비스가 실행되지 않는 경우를 먼저 구분하세요. 인증 실패는 다른 계층에서 일어납니다. 인증서 검증을 통과해도 비밀번호가 맞지 않으면 프록시를 사용할 수 없습니다. 모든 문제를 “노드가 죽었다”고 처리하면 진단에 필요한 정보를 놓칩니다. 로그에 핸드셰이크 단계가 명시되어 있다면 우선 그 단계부터 해결하고 DNS, 프록시 그룹, 규칙 순서를 한꺼번에 바꾸지 마세요.

Trojan은 UDP 전달을 지원할 수 있지만, UDP 캡슐화 방식과 서버 활성화 여부, 클라이언트 구현이 해당 동작을 지원하는지 확인해야 합니다. 외부의 신뢰성 있는 연결을 사용한다고 해서 실시간 앱이 항상 더 잘 작동하는 것은 아닙니다. 하위 TCP 계층에서 패킷이 손실되면 이후 데이터가 재전송을 기다릴 수 있습니다. 일반 웹 탐색과 흔한 앱에서는 캡슐화 계층 수보다 현재 배포의 호환성과 연결 안정성을 먼저 고려하는 편이 좋습니다. 실시간 통신은 지터와 복구 과정도 따로 검증하세요.

VLESS: 간결한 프로토콜이 보안 설정 생략을 뜻하지는 않습니다

VLESS 기본 프로토콜은 전통적인 의미의 독립적인 콘텐츠 암호화를 제공하지 않으므로, 실제 사용 시 배포 환경에 맞는 TLS, REALITY 등의 보안 메커니즘을 사용해야 합니다. 다양한 전송 방식과 조합할 수 있지만 프로토콜 이름은 인증 및 전달 구조의 일부만 설명합니다. 설정에 기존 암호화 방식 필드가 없다고 해서 연결 전체가 암호화되지 않았다고 단정할 수는 없습니다. 반대로 VLESS라는 이름만 보고 외부 계층이 올바르게 보호되고 있다고 가정해서도 안 됩니다. 전체 조합을 확인해야 합니다.

REALITY는 특정 연결 보안 방식이지 필요할 때마다 바꿔 끼우는 범용 TLS 옵션이 아닙니다. 공개 키, 짧은 ID, 서버 이름과 관련 동작이 서버 설정과 일치해야 합니다. Vision은 특정 흐름 제어 조합에 속하며, 적용 가능한 프로토콜과 전송 방식, 구현 조건이 있습니다. 임의의 WebSocket 연결에 복사해 넣는다고 빨라지지 않습니다. 구독에 이런 확장 기능이 있다면 VLESS를 인식하는지만 확인하지 말고 실제 클라이언트 코어와 변환 도구가 모두 지원하는지 확인하세요.

올바르게 인증서를 관리하는 Trojan 서버를 이미 사용 중이라면 안정적인 후보로 계속 고려할 수 있습니다. 특정 VLESS 조합이 필요하다면 먼저 서버 정보가 완전한지 확인한 다음 해당 조합을 지원하는 코어를 선택하세요. 어느 쪽이든 고급 옵션을 무작위로 켜고 끄며 문제를 찾는 방식은 피해야 합니다. 오류와 관련된 필드만 한 번에 하나씩 바꾸고, 원본 구독 사본을 보관하며, 변경 전후 로그의 단계를 기록하세요. 그러면 프로토콜 선택이 적절하지 않은지, 가져오기나 변환 과정에서 설정이 누락됐는지 구분할 수 있습니다.

Hysteria2와 TUIC: QUIC의 이점과 비용

Hysteria2와 TUIC는 모두 QUIC를 사용해 프록시 연결을 구성하지만 서로 다른 프로토콜이므로 서버와 클라이언트가 서로 대체되지 않습니다. QUIC는 일반적으로 UDP 위에서 실행되며 암호화 핸드셰이크, 신뢰성 있는 스트림, 연결 관리 기능을 제공합니다. 그렇다고 이를 통과하는 모든 앱 트래픽이 신뢰성 없는 UDP로 바뀌는 것은 아닙니다. 앱의 TCP 데이터는 신뢰성 있는 스트림에 매핑될 수 있고, 앱의 UDP 데이터는 데이터그램이나 프로토콜이 정한 다른 방식으로 전달될 수 있습니다. 실제 동작은 구현과 설정에 따라 달라집니다.

QUIC를 기반으로 사용하는 이유

기존 멀티플렉싱이 하나의 TCP 연결을 공유하면 하위 계층의 패킷 손실로 여러 논리 스트림이 함께 대기할 수 있습니다. QUIC는 신뢰성 있는 전송 상태를 스트림 단위로 관리해 스트림 간 헤드 오브 라인 블로킹의 영향을 줄이고, 연결 ID 같은 메커니즘으로 경로 변경을 관리할 수 있습니다. 그러나 하나의 연결에서 네트워크 용량과 혼잡 상태를 공유하므로 패킷 손실 자체가 사라지는 것은 아닙니다. 서버 부하, 접속 네트워크 정책, 구현 품질에 따라 프로토콜 구조의 이점이 상쇄될 수도 있습니다.

이런 프로토콜을 사용하려면 UDP 연결이 가능해야 합니다. 일부 네트워크는 DNS 같은 소량의 UDP만 허용하고 다른 포트나 장시간 UDP 세션은 제한합니다. NAT 매핑 유지 시간이 짧은 기기에서는 백그라운드에 오래 머문 뒤 경로가 끊기기 쉽습니다. 연결 시간 초과가 발생하면 TLS 이름을 반복해서 바꾸기보다 서버 리스닝, 방화벽, UDP 전달, 포트 정책을 먼저 확인하세요. 같은 기기가 다른 네트워크에서는 정상 작동한다면 자격 증명보다 경로가 원인일 가능성이 큽니다.

Hysteria2: 대역폭 설정은 마법 같은 가속 옵션이 아닙니다

Hysteria2는 지연이 크고 패킷 손실이 있는 경로에서 데이터를 전송하도록 설계되었으며, 대역폭 추정과 혼잡 제어 관련 메커니즘을 제공합니다. 클라이언트의 업로드·다운로드 대역폭 설정은 해당 방향의 전송 동작과 협상에 영향을 주므로, 구체적인 의미는 사용하는 구현의 문서를 확인해야 합니다. 실제 접속 능력보다 훨씬 높은 추정치를 입력하면 큐가 쌓이고 패킷 손실이 늘어 다른 앱에도 영향을 줄 수 있습니다. 통신사 요금제에 적힌 이상적인 최고 속도가 아니라 지속해서 낼 수 있는 실제 성능을 기준으로 설정하세요.

Hysteria 1세대와 Hysteria2도 이름만 바꿔 호환되는 것은 아닙니다. 인증 구조와 설정 필드, 프로토콜 동작이 다르므로 구독 도구가 해당 유형을 명시적으로 지원해야 합니다. 서버에서 추가 난독화 매개변수를 요구한다면 클라이언트에서도 그에 맞는 방식과 값을 사용해야 합니다. 서버가 요구하지 않는데 임의로 추가해서는 안 됩니다. 일부 네트워크는 패킷 크기에 민감하며, 지속 전송 중단은 경로 MTU 문제와 관련될 수도 있습니다. 로그와 네트워크 테스트를 함께 살펴보고 혼잡 제어가 실패했다고 성급히 판단하지 마세요.

TUIC: 연결 관리와 앱 요구 사항을 함께 고려하세요

TUIC도 QUIC 기반의 프록시 및 전달 메커니즘을 사용하며, 일반적인 설정에는 사용자 식별자, 비밀번호, 혼잡 제어, UDP 전달 방식이 포함됩니다. 프로토콜 버전과 구현의 지원 범위가 일치하는지 확인해야 합니다. 유형 이름에 TUIC가 적혀 있는지만 봐서는 부족합니다. 연결 재사용은 채널을 반복해서 만드는 비용을 줄일 수 있지만 여러 앱이 하나의 연결 상태를 공유하게 됩니다. 서버 재시작이나 경로 장애가 발생하면 여러 앱이 동시에 영향을 받을 수도 있으므로 시작 속도와 장시간 사용 결과를 함께 확인하세요.

QUIC에 경로 마이그레이션 관련 기능이 있다고 해서 모든 클라이언트가 Wi-Fi와 모바일 데이터 사이를 전환해도 기존 세션을 유지하는 것은 아닙니다. 운영체제의 네트워크 권한, 가상 네트워크 인터페이스 동작, 클라이언트 처리 방식, 서버 설정이 모두 영향을 줍니다. “모바일 네트워크에 적합하다”는 말이 “네트워크를 바꿔도 절대 끊기지 않는다”는 뜻은 아닙니다. 앱이 제때 복구되는지, 재연결이 반복되는지, 백그라운드에서 돌아온 뒤 이미 끊어진 연결 상태를 계속 사용하는지 실제로 확인하세요.

이 두 프로토콜을 후보로 고려할 이유는 현재 경로와 업무가 전송 방식의 이점을 얻을 수 있기 때문이지, “최신 프로토콜이 항상 더 빠르기 때문”이 아닙니다. 같은 네트워크에서 짧은 웹페이지 열기, 연속 다운로드, 실시간 앱, 장시간 대기 후 복구를 각각 확인하세요. 다운로드만 나아지고 휴대전화의 백그라운드 재연결이 늘어난다면 주된 용도에 맞춰 선택해야 합니다. 맥락을 잃은 속도 결과보다 테스트 조건을 기록해 두는 편이 더 유용합니다.

연결 속도, 자원 사용량, 모바일 배터리

프로토콜 성능은 최소한 연결 설정, 첫 응답, 지속 처리량, 장애 복구의 네 가지로 나눠 봐야 합니다. 클라이언트 연결 테스트는 보통 그중 일부만 측정합니다. 특정 대상에 요청을 보내고 걸린 시간을 표시하는 방식일 수 있습니다. DNS 캐시, 연결 재사용, 테스트 주소, 서버 응답이 결과에 영향을 주므로 동영상, 회의, 다운로드 성능을 그대로 나타내지는 않습니다. 비교하기 전에 테스트가 무엇을 측정하는지 파악하고 실제 작업과 관련 있는 결과인지 판단하세요.

핸드셰이크와 지속 전송을 구분하세요

새 연결에서는 도메인 조회, 하위 연결, TLS 또는 QUIC 핸드셰이크, 프로토콜 인증, 대상 연결 설정이 차례로 필요할 수 있습니다. 기존 연결을 재사용하면 일부 단계가 생략되므로 테스트를 연달아 실행해 얻은 좋은 결과가 앱의 콜드 스타트에도 그대로 적용되지는 않습니다. TLS 세션 재개와 QUIC의 초기 데이터 전송 기능에도 사용 조건과 보안 경계가 있습니다. 연결 설정 시간을 줄이려고 모든 옵션을 무작정 켜지 마세요. 먼저 기본 설정의 안정적인 조합을 유지하고, 분명한 병목이 확인된 뒤 조정하세요.

지속 처리량은 혼잡 제어, 수신 윈도우, 경로 용량, 양쪽 기기의 처리 능력에 따라 달라집니다. 암호화는 CPU 자원을 사용하지만 속도 저하가 모두 암호화 때문인 것은 아닙니다. 기기 프로세서 부하가 높지 않은데 앱이 오래 기다린다면 원격 대역폭, 큐잉, 대상 사이트 응답이 원인일 수 있습니다. 반대로 저전력 라우터가 최대 부하에 도달하면 알고리즘 구현과 동시 연결 수가 병목이 될 수 있습니다. 자원을 확인할 때는 클라이언트 관련 프로세스 전체를 살펴보세요. 실제 송수신을 담당하는 코어를 놓치지 않도록 화면을 표시하는 프로세스만 확인하지 마세요.

배터리 소모는 무선 활동과 백그라운드 동작에서 커지는 경우가 많습니다

휴대전화 배터리는 암호화 연산만으로 소모되지 않습니다. 무선 모듈 활성 상태 유지, 잦은 하트비트, 연결 탐지, DNS 요청, 재시도, 백그라운드 로그 기록도 자원을 사용합니다. TUN이나 시스템 VPN이 더 많은 앱의 트래픽을 처리하면 클라이언트 이름으로 트래픽과 배터리 사용량이 집중 표시될 수 있지만, 해당 트래픽을 모두 클라이언트가 직접 만든 것은 아닙니다. 배터리 목록의 순위만 보고 프로토콜을 평가하지 말고 시스템 배터리 통계, 백그라운드·포그라운드 활동, 실제 앱 사용량을 함께 살펴보세요.

하트비트 주기를 줄이면 연결 장애를 빨리 발견할 수 있지만 기기를 깨우는 횟수도 늘어날 수 있습니다. 주기를 늘리면 백그라운드 활동은 줄어들지만 복구가 늦어질 수 있습니다. 적절한 값은 NAT, 서버, 시스템의 백그라운드 관리 방식에 따라 달라지므로 네트워크가 바뀌어도 같은 값을 그대로 쓰면 안 됩니다. 프록시 그룹의 자동 상태 확인, 구독 업데이트, 규칙 데이터베이스 업데이트도 네트워크 활동을 유발합니다. 대기 시간을 늘리고 싶다면 먼저 필요 없는 고빈도 작업을 정리하고, 여러 클라이언트가 시스템 프록시나 가상 네트워크 인터페이스를 동시에 사용하지 않도록 하세요.

한 번의 순위 측정이 아니라 재현 가능한 비교를 하세요

기기, 네트워크, 대상 사이트, 앱 동작을 고정하고 다운로드와 조작 응답을 동시에 비교하지 마세요. 먼저 콜드 스타트를 각각 확인하고, 이어 지속 사용, 장시간 대기 후 복구, 네트워크 전환 후 복구를 테스트합니다. 한 차례에 하나의 변수만 바꾸세요. 서버 지역과 프로토콜, 클라이언트를 함께 바꾸면 차이를 프로토콜 탓으로 돌릴 수 없습니다. 서로 다른 시간대에도 반복해 관찰하고 문제가 일관되게 나타나는지 기록하세요. 서버와 경로 조건을 통제하지 못했다면 결과를 두 연결 간 비교로 표현해야지, 두 프로토콜의 일반적인 성능 차이라고 단정해서는 안 됩니다.

클라이언트의 테스트 메뉴를 더 알아보려면 사용 가이드에서 조작 방법을 확인한 뒤 로그를 보고 실제로 선택된 아웃바운드를 점검하세요. 프로토콜마다 고정된 메모리 사용량이나 배터리 소모량, 속도가 있다고 수치를 만들어 내지 마세요. 구현과 하드웨어, 부하가 달라지면 결과도 충분히 달라질 수 있습니다. 선택에 도움이 되는 기록은 현재 기기에서 어떤 조합이 작업을 안정적으로 끝냈는지, 어떤 동작이 문제를 일으켰는지, 이점을 얻기 위해 어떤 자원을 더 사용했는지입니다.

구독 형식: 가져오기와 실행은 다릅니다

구독은 하나의 고정된 파일 형식이 아니라 설정을 전달하고 업데이트하는 방식입니다. 같은 주소가 완전한 Clash YAML, 개별 프록시 프로바이더 파일, 인코딩된 공유 링크 목록, 다른 생태계에서 사용하는 JSON을 반환할 수 있습니다. 파일 확장자나 링크 형태만으로 반환 형식을 보장할 수는 없습니다. 서버는 요청 정보에 따라 다른 내용을 반환하기도 합니다. 가져오기 전에 제공업체가 안내하는 대상 클라이언트와 형식을 확인하고 알맞은 메뉴를 선택하세요.

전체 설정, 노드 목록, 공유 링크

완전한 Clash YAML에는 일반적으로 리스닝, DNS, 프록시, 프록시 그룹, 규칙 등이 들어 있습니다. 프록시 프로바이더 파일은 보통 노드 목록만 전달하며, 기본 설정에서 프로바이더를 참조해 사용합니다. 둘 다 YAML이라는 이유만으로 후자를 전체 설정처럼 바로 실행할 수는 없습니다. 공유 링크에는 개별 연결의 매개변수가 들어 있고, Base64 목록은 여러 링크를 인코딩해 묶는 경우가 많습니다. Base64는 표현 방식이지 암호화가 아닙니다. 임의의 프로토콜을 자동으로 Clash 설정으로 변환하는 도구도 아닙니다.

가져오기에 실패하면 먼저 어느 단계에서 막혔는지 구분하세요. 주소에 접근하지 못했는지, 예상한 형식이 아닌 내용이 반환됐는지, 파일 구조 파싱에 실패했는지, 특정 노드를 코어가 지원하지 않는지 확인해야 합니다. 주소에서 로그인 페이지나 오류 페이지, 빈 내용이 반환된다면 YAML 들여쓰기를 고쳐도 소용없습니다. YAML을 읽었지만 알 수 없는 프록시 유형이라고 표시된다면 코어 기능을 확인하세요. 실행은 되지만 특정 연결만 실패한다면 해당 연결의 인증과 전송 방식, 서버 상태를 살펴보세요. 구독 전체를 처음부터 다시 설정할 필요는 없습니다.

변환 도구가 ‘인식하는 항목’만 보존할 수 있습니다

변환 도구는 원본 형식의 필드를 대상 형식에 맞게 매핑해야 합니다. 최신 프로토콜 확장, 플러그인 옵션, REALITY 매개변수, 흐름 제어, UDP 전송 방식, 특정 TLS 설정은 오래된 도구에서 대응하는 항목이 없을 수 있습니다. 출력 파일의 문법이 유효하다고 설정의 의미까지 완전한 것은 아닙니다. 원래 클라이언트에서는 작동하지만 변환 후 작동하지 않는다면 노드 이름이나 서버 주소만 비교하지 말고 연결에 필요한 주요 필드를 대조하세요. 이름이 같다는 것은 이름이 보존됐다는 뜻일 뿐입니다.

구독 주소에는 접근 권한이 포함되어 있는 경우가 많으므로 서드파티 변환 서비스에 전달하면 설정을 가져올 수 있는 권한도 넘기는 셈입니다. 제공업체가 명시적으로 지원하는 대상 형식이나 로컬 변환 방식을 우선 사용하세요. 실제 구독 주소를 공개 문의 게시판, 스크린샷, 로그에 붙여 넣지 마세요. 도움을 요청할 때는 전체 주소, 사용자 식별자, 비밀번호와 다른 인증 정보를 제거하되 오류 유형, 필드 이름, 민감 정보가 없는 구조는 남겨 두세요. 접근 권한을 보호하면서도 문제를 찾는 데 필요한 정보를 제공할 수 있습니다.

업데이트와 덮어쓰기의 역할을 구분하세요

원격 구독을 업데이트하면 직접 수정한 노드, 규칙, 프록시 그룹이 바뀔 수 있습니다. 계속 유지해야 하는 설정은 클라이언트가 지원하는 덮어쓰기, 병합 기능 또는 별도의 기본 설정에 두세요. 구체적인 위치는 클라이언트 문서를 확인해야 합니다. 병합이 목록을 교체하는지 내용을 추가하는지도 먼저 이해하세요. 특히 규칙 순서와 프록시 그룹 참조가 중요합니다. 규칙을 추가해도 MATCH 뒤에 배치되면 파일에서 보이기만 할 뿐, 실제로 적용될 기회가 없을 수 있습니다. 문법은 사용자 지정 규칙과 매칭 순서 참고 자료에서 확인하세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

위 YAML은 독립 실행이 가능한 기본 예시입니다. 원격 프록시를 포함하지 않으며 트래픽을 구독 노드로 보내지도 않습니다. “코어가 시작되지 않는 문제”와 “원격 연결이 성립하지 않는 문제”를 구분하는 데 도움이 되지만, 로컬 포트가 사용 중이 아닌지 확인해야 합니다. 예시가 시작된다는 것은 기본 설정과 리스닝이 작동한다는 뜻일 뿐, 구독 형식이나 프록시 인증, 원격 서버의 사용 가능 여부를 보장하지 않습니다. 형식 차이와 가져오기 절차는 구독 링크 가져오기 및 형식 안내를 참고하세요.

사용 환경별 선택: 후보 조합부터 검증 기록까지

최종 선택은 영구적인 순위가 아니라 조건의 조합으로 정리해야 합니다. 현재 클라이언트와 코어가 무엇을 지원하는지, 서버가 어떤 기능을 제공하는지, 네트워크에서 무엇을 허용하는지, 주로 사용하는 앱이 무엇을 필요로 하는지 확인하세요. 지원하지 않는 조합을 먼저 제외한 뒤 사용 가능한 후보를 비교하면 고급 매개변수를 계속 바꾸는 것보다 시간을 절약할 수 있습니다. 일반 사용자에게는 이론적으로 복잡한 방식보다 안정적으로 가져오고 올바르게 검증할 수 있으며 쉽게 복구할 수 있는 조합이 더 적합한 경우가 많습니다.

데스크톱 업무와 일반적인 웹 탐색

데스크톱에서 웹, 문서, 코드 저장소를 주로 사용한다면 안정성이 확인된 SS, VMess, Trojan 또는 지원되는 VLESS 조합부터 사용하고 최초 응답, 장시간 연결, 절전 모드에서 복귀한 뒤의 동작을 살펴보세요. 이는 흔히 사용 가능한 후보이지, 서로 다른 성능 등급을 보장하는 것은 아닙니다. 네트워크에서 UDP를 제한한다면 TCP 전송 경로를 유지하세요. 다운로드량이 많을 때는 최고 속도만 보지 말고 다운로드 중 다른 앱이 눈에 띄게 느려지는지도 확인해 큐잉 문제를 앱 서버 오류로 오해하지 않도록 하세요.

새로 설치한다면 우선 추천하는 Clash Plus부터 사용해 보고, 플랫폼과 관리 방식에 따라 다른 클라이언트도 확인하세요. 클라이언트를 바꾸기 전에 필요한 로컬 설정을 내보내고 구독 정보를 안전하게 보관하세요. 모든 앱의 TUN, DNS, 병합 방식이 똑같다고 가정해서는 안 됩니다. 기존 설정이 정상 작동한다면 마이그레이션 중에는 아웃바운드 프로토콜과 규칙을 그대로 두고 클라이언트 연동 차이만 확인하세요. 설치 메뉴는 다운로드 페이지에서, 처음 시스템 프록시와 포트를 확인하는 방법은 초기 설정 점검 목록에서 확인할 수 있습니다.

모바일 업무, 실시간 앱, 불안정한 네트워크

휴대전화가 여러 접속 네트워크 사이를 오간다면 백그라운드 복구, 배터리 사용량, 권한의 안정성을 점검해야 합니다. UDP 연결이 가능한 네트워크에서는 Hysteria2와 TUIC를 후보로 고려할 수 있지만, 네트워크 전환과 대기 후 동작을 직접 검증하고 작동하는 TCP 방식도 대안으로 남겨 두세요. 실시간 앱의 트래픽이 실제로 프록시를 통과하는지도 확인해야 합니다. 시스템 프록시는 모든 UDP 앱을 처리하지 않습니다. TUN은 트래픽을 가로채는 수단일 뿐, 시스템 권한과 라우팅, DNS 처리의 영향을 받으며 프로토콜 인증 문제를 자동으로 해결하지는 않습니다.

라우터나 서버 사용자는 먼저 아키텍처와 가용 메모리, 서비스 관리 방식, 네트워크 스택의 제약을 확인하세요. 데스크톱 설치 패키지를 기기에 옮기지 말고 다운로드 페이지의 mihomo 코어 항목을 사용하세요. 탐지 작업과 상세 로그, 복잡한 매칭을 동시에 많이 켜 놓은 뒤 그로 인해 생긴 자원 부담을 프로토콜 성능으로 판단하지 않도록 주의하세요. 가정 내 LAN에서 사용할 때는 리스닝 범위와 접근 제어도 명확히 해야 합니다. 기기 하나를 연결하기 위해 모든 인터페이스를 외부에 노출하는 것은 별도로 검토해야 할 설정입니다.

무작정 프로토콜을 바꾸지 말고 단계별로 문제 범위를 좁히세요

첫째, 시작 단계의 파싱 오류는 들여쓰기와 필드, 코어 지원 여부부터 확인합니다. 둘째, 트래픽 처리 단계에서는 앱이 시스템 프록시나 TUN을 사용하는지, 규칙이 예상한 프록시 그룹에 매칭되는지 확인합니다. 셋째, 연결 단계에서는 주소 조회, 포트 연결, TLS, 인증, 대상 전달을 구분합니다. 넷째, 장시간 사용 중에는 대기, 네트워크 전환, 동시 사용, 다운로드 중에 연결이 끊기는지 살펴봅니다. 각 단계에서 정상 작동이 확인된 비교 경로를 하나씩 유지해야 변경으로 실제 개선이 있었는지 알 수 있습니다.

mihomo -t -f config.yaml

이 명령은 mihomo를 설치해 터미널에서 실행할 수 있는 환경에서 사용합니다. 파일 이름은 로컬의 실제 설정 파일에 맞춰야 합니다. 문법 검사를 통과해도 원격 연결이 정상이라고 보장되지는 않습니다. 그래픽 클라이언트는 별도의 실행 설정을 생성하거나 내부 메뉴에서 검사를 실행하도록 요구할 수 있으므로, 검사 대상이 같은 파일인지 먼저 확인하세요. GeoIP 또는 GeoSite 데이터를 불러오는 데 문제가 있다면 데이터베이스 업데이트 및 규칙 적용 안내를, 도메인 매핑 현상은 Fake-IP 모드 설명을 참고하세요.

프로토콜 선택에 모든 환경에 통하는 정답은 없지만 문제를 찾는 순서는 일정하게 정할 수 있습니다. 먼저 지원 기능을 확인하고, 다음으로 매개변수를 점검한 뒤, 실제 작업으로 검증하세요. 복구가 필요하면 가장 최근에 정상 작동한 설정으로 돌아가면 됩니다. 이 순서를 익혀 두면 서버나 클라이언트, 네트워크를 바꾸더라도 어떤 지점을 확인해야 하는지 알 수 있어 프로토콜 이름부터 다시 추측할 필요가 없습니다.