프로토콜 가이드: 프록시 프로토콜 및 코어 선택 기술 참고서

CL-01가이드 소개와 읽는 방법

먼저 이 가이드가 사이트 내에서 어떤 위치에 있는지 짚고 넘어갑니다. Clash자료관의 콘텐츠는 자료실 방식으로 구성되어 있습니다. 다운로드 센터는 플랫폼별 클라이언트 설치 파일을 제공하고, 튜토리얼 페이지는 "구독 가져오기 → 모드 선택 → 연결 확인"이라는 첫걸음을 안내하며, 클라이언트 비교 가이드는 클라이언트 소프트웨어 간의 비교를 다룹니다. 그리고 이 페이지는 그보다 한 단계 아래, 클라이언트가 실제로 사용하는 프로토콜과 코어를 어떻게 선택해야 하는지를 다룹니다. 많은 사용자가 노드 목록의 ss, vmess, trojan, vless, hysteria2, tuic 같은 유형 태그 때문에 혼란을 겪습니다. 겉보기엔 이름만 다른 것 같지만, 실제로는 연결 속도, 불안정한 네트워크에서의 성능, 모바일 배터리 소모, 심지어 일부 노드가 구버전 코어에서 아예 로드되지 않는 호환성 문제까지 결정합니다.

읽는 방법에 있어서 이 페이지는 처음부터 끝까지 순서대로 읽을 필요가 없습니다. 8개 챕터는 각각 독립적으로 구성되어 있습니다. CL-02는 6종 프로토콜의 "신상 카드"로 각각의 배경과 설계 방향을 소개하고, CL-03과 CL-04는 성능 측면의 비교로 전자는 속도, 후자는 리소스와 배터리를 다룹니다. CL-05는 코어 계열, 즉 오리지널 Clash, Clash Premium, Clash Meta, mihomo 간의 계승 관계를 설명하는데, 이는 "같은 설정이 어떤 클라이언트에서는 되고 어떤 클라이언트에서는 오류가 나는지"를 이해하는 핵심입니다. CL-06은 구독 형식과 설정 필드 호환성을, CL-07은 앞의 모든 결론을 환경별 선택표로 정리하며, CL-08은 선택 과정에서 가장 흔한 오해들을 모았습니다. 각 챕터 앞에는 짧은 안내문이 있으니 먼저 읽고 더 깊이 볼지 결정하시면 됩니다.

두 가지 서술 원칙을 미리 밝힙니다. 첫째, 이 페이지는 기술 소개와 선택 참고에만 집중하며 네트워크 규제 관련 주제는 다루지 않습니다. 프로토콜 비교는 엔지니어링 관점, 즉 핸드셰이크 오버헤드, 암호화 비용, 전송 계층 특성, 생태계 성숙도로 한정합니다. 둘째, 이 페이지는 긴 설정 코드를 싣지 않습니다. 프로토콜 파라미터는 수십 개 필드에 이르는 경우가 많아 그대로 옮겨 적는 것은 의미가 크지 않으며, 필요한 경우에만 필드 구조를 파악하는 데 도움이 되는 최소 예시를 제공합니다. 완전한 설정 작업은 튜토리얼 페이지의 단계를 따라 진행해 주세요. 본문에 나오는 서버 주소와 비밀번호는 모두 구조 설명용 예시 값이며 실제로 사용할 수 없습니다. 읽다가 낯선 용어가 나오면 기술 노트에서 관련 주제를 먼저 검색한 후 다시 이 페이지로 돌아오시면 됩니다.

CL-02프로토콜 개요: 6종 프로토콜의 등장 배경과 설계 방향

프로토콜은 클라이언트와 서버가 약속한 "소통 방식"입니다. 6종 주요 프로토콜은 등장 시기와 해결하고자 한 문제가 서로 다르므로 절대적인 우열은 없고 방향의 차이만 있습니다. 먼저 전체 표로 기준을 잡고 하나씩 살펴보겠습니다.

Shadowsocks: 극단적 단순함의 원조

Shadowsocks는 6종 중 가장 오래된 프로토콜로, "최소한만 한다"는 설계 철학을 따릅니다. 클라이언트와 서버가 비밀번호를 공유하고, 트래픽을 대칭 암호화로 감싸 바로 전달할 뿐 핸드셰이크 협상이나 인증서 체계가 없습니다. 최신 구현은 aes-128-gcm, chacha20-ietf-poly1305 같은 AEAD 암호화 스위트를 사용해 무결성 검증과 성능을 함께 확보합니다. 이런 단순함은 두 가지 확실한 장점을 줍니다. CPU 사용량이 가장 낮고 구현이 쉬워 거의 모든 코어와 클라이언트가 지원한다는 점입니다. 대신 프로토콜 특징이 오랫동안 충분히 연구되어 단독 사용 시 탐지 저항력이 제한적이며, 실무에서는 obfs, v2ray-plugin 같은 플러그인으로 전송 계층을 확장하는 경우가 많습니다. 선택의 기준선으로서 SS는 지금도 "구형 기기, 저사양 라우터, 배터리 절약 우선" 환경의 첫 번째 후보입니다.

VMess: 전송 계층 조합의 개척자

VMess는 V2Ray 프로젝트에서 나온 것으로, 핵심 기여는 "프로토콜 본체"와 "전송 계층"을 분리한 점입니다. 같은 VMess 세션이 순수 TCP, WebSocket, HTTP/2 등 다양한 전송 방식 위에서 동작할 수 있고, 필요에 따라 TLS를 한 겹 씌울 수 있습니다. 이 모듈식 설계 덕분에 오랫동안 유연성의 대표 격이었습니다. 대신 프로토콜 헤더에 사용자 ID, 암호화 방식 선언, 타임스탬프 검증 등의 필드가 들어가 패킷당 고정 오버헤드가 SS보다 뚜렷하게 큽니다. 타임스탬프 검증은 클라이언트와 서버의 시간 오차가 약 90초 이내여야 하는데, 휴대폰 시간이 부정확하면 곧바로 핸드셰이크 실패로 이어집니다. VMess 노드가 "갑자기 타임아웃"될 때 가장 먼저 확인해야 할 부분입니다. 요즘 VMess는 보통 WebSocket + TLS 조합으로 쓰이며 호환성은 매우 좋지만 성능 상한은 후발 프로토콜에 못 미칩니다.

Trojan: HTTPS 속에 자신을 숨기다

Trojan의 접근 방식은 앞의 두 프로토콜과 반대입니다. 새로운 암호화 방식을 만들지 않고 표준 TLS를 그대로 활용합니다. 클라이언트와 서버가 실제 TLS 핸드셰이크를 완료하며, 트래픽 동작은 일반 HTTPS 접속과 거의 동일합니다. 인증에 실패한 연결은 서버가 실제 웹사이트로 넘겨 식별 가능성을 더욱 낮춥니다. 이 설계 덕분에 Trojan의 구현은 매우 가볍습니다. 프로토콜 본체는 비밀번호 해시와 목적지 주소만 있을 뿐 추가 오버헤드가 거의 없어 성능이 순수 TLS의 이론적 한계에 가깝습니다. 진입 장벽은 서버 쪽에 있습니다. 도메인과 유효한 인증서가 반드시 필요해 배포가 SS보다 복잡합니다. 클라이언트 쪽에서는 sni 필드가 서버 인증서와 일치해야 하며, 잘못 설정하면 TLS 핸드셰이크 오류가 발생합니다. 클라이언트 사용자에게 Trojan은 "안정적이고, 오버헤드가 낮으며, 동작이 정상적인" 신뢰할 수 있는 선택지입니다.

VLESS: 덜어내기로 만든 차세대 프레임워크

VLESS는 VMess의 경량화된 후계자로, 같은 생태계에서 나왔습니다. VMess에서 불필요하다고 여겨진 부분을 전부 제거했습니다. 더 이상 자체 암호화를 하지 않고(외부 TLS에 위임), 타임스탬프 검증도 하지 않으며, 프로토콜 헤더를 최소로 압축했습니다. 본체가 가벼워진 대신 보안성은 함께 사용하는 전송 계층에 완전히 의존합니다. 흔한 조합은 VLESS + TLS + Vision 흐름 제어, 또는 VLESS + REALITY(자체 인증서 없이 실제 사이트의 TLS 지문을 빌려 쓰는 핸드셰이크 방식)입니다. 설계 방향은 명확합니다. "본체 무암호화"로 캡슐화 오버헤드를 최소화하고 현대적인 전송 계층으로 보안을 보완하는 것입니다. 다만 VLESS의 다양한 흐름 제어와 전송 조합은 업데이트가 빠른 편이라 구형 코어가 새 필드를 인식하지 못하는 경우가 많습니다. 이는 VLESS가 코어 버전에 가장 민감한 이유이며, 자세한 내용은 CL-05와 CL-06 두 챕터에서 다룹니다.

Hysteria2: 불안정한 네트워크를 위해 태어나다

Hysteria2는 QUIC 기반으로 구축되었으며 전체 프로토콜이 UDP 위에서 동작하고 암호화는 TLS 1.3이 담당합니다. 독특한 점은 자체적인 적극적인 혼잡 제어입니다. 전통적인 TCP는 패킷 손실이 생기면 크게 양보하는 방식이라 손실률이 높은 링크에서는 실제 처리량이 대역폭보다 훨씬 낮아집니다. Hysteria2는 설정된 대역폭만큼 계속 전송을 허용하고, 중복 전송과 빠른 재전송으로 패킷 손실에 대응합니다. 결론은 명확합니다. 국가 간 장거리 링크, 저녁 혼잡 시간대, 무선 신호가 약한 환경처럼 "높은 지연, 높은 손실률" 상황에서는 Hysteria2의 처리량이 TCP 계열 프로토콜보다 크게 앞서는 경우가 많습니다. 반면 원래부터 원활한 네트워크에서는 이점이 크지 않고, 적극적인 전송 방식이 오히려 같은 네트워크의 다른 기기를 압박할 수 있습니다. 필수 전제는 UDP 채널이 사용 가능해야 한다는 점입니다. 일부 통신사와 공공 Wi-Fi는 UDP를 제한하거나 차단하는데, 이 경우 Hysteria2는 전면적으로 작동하지 않으므로 선택 시 반드시 TCP 계열 프로토콜을 대체 수단으로 준비해야 합니다.

TUIC: QUIC 생태계의 경량 노선

TUIC 역시 QUIC 기반이지만 "표준화, 경량화" 노선을 택했습니다. QUIC의 다중화와 0-RTT 핸드셰이크 능력을 그대로 활용하며, Hysteria2처럼 혼잡 제어를 새로 만들지 않고 BBR, Cubic 같은 표준 알고리즘을 선택할 수 있게 제공합니다. 0-RTT는 한 번 연결했던 서버와 재연결할 때 왕복 시간이 거의 소모되지 않는다는 뜻으로, "네트워크를 자주 전환하는 모바일 환경"에 특히 유리합니다. QUIC 고유의 UDP 전달 능력 덕분에 게임, 음성 같은 UDP 트래픽도 자연스럽게 처리합니다. 단점은 생태계입니다. TUIC는 비교적 최근에 등장해 서버 배포 범위와 서비스 지원도가 앞의 다섯 프로토콜보다 부족하며, 마찬가지로 UDP 채널 가용성에 의존합니다. "온화한 버전의 QUIC 솔루션"이라고 이해하면 됩니다. QUIC의 낮은 지연이라는 장점은 원하지만 Hysteria2의 적극적인 방식은 원하지 않을 때 TUIC가 그 답이 됩니다.

CL-03연결 속도와 처리량: 체감을 결정하는 세 요소

사용자들이 말하는 "이 노드 빠르다"는 사실 세 가지 요소가 각각 결정합니다. 연결 수립 속도(새 웹사이트를 열 때 얼마나 기다리는지), 안정적인 처리량(다운로드와 동영상이 얼마나 꽉 차게 나오는지), 동시성 성능(웹페이지가 수십 개 요청을 동시에 보낼 때 서로 막히는지 여부)입니다. 세 요소를 좌우하는 원인이 서로 다르므로 나눠서 봐야 정확한 결론을 얻을 수 있습니다.

연결 수립: 핸드셰이크 왕복 횟수가 관건

프록시 연결을 수립하는 데 걸리는 시간은 기본적으로 "핸드셰이크 왕복 횟수 × 링크 지연"과 같습니다. SS는 핸드셰이크가 없어 첫 패킷을 보내는 순간 연결이 완료되므로 이론상 가장 빠릅니다. Trojan, VLESS + TLS, VMess + TLS는 모두 완전한 TLS 핸드셰이크가 필요하며 TLS 1.3에서는 한 번의 왕복입니다. VMess에 WebSocket까지 겹치면 HTTP Upgrade 왕복이 한 번 더 필요해 TCP 계열 중 연결 수립이 가장 느린 조합입니다. QUIC 계열인 Hysteria2와 TUIC는 전송 핸드셰이크와 TLS 핸드셰이크를 하나의 왕복으로 합치고, 재연결 시에는 0-RTT로 "첫 패킷이 곧 데이터"인 수준까지 가능합니다. 링크 지연이 클수록 이 차이는 더 뚜렷해집니다. 같은 핸드셰이크 차이라도 지연이 낮은 근거리 링크에서는 거의 느낄 수 없지만, 지연이 눈에 띄는 원거리 링크에서는 몇 배로 증폭되어 "새 페이지를 열기 전의 백지 시간" 차이로 나타납니다.

안정적인 처리량: 혼잡 제어와 암호화 비용

연결이 수립된 이후, 장시간 대용량 전송(다운로드, 고화질 동영상)의 병목은 혼잡 제어와 암호화 오버헤드로 옮겨갑니다. 원활한 링크에서는 6종 프로토콜의 안정적 처리량 차이가 크지 않아 대부분 링크 대역폭에 근접하며, 이때는 오히려 암호화 비용이 상한을 결정합니다. SS와 Trojan은 캡슐화가 가장 가볍고, VMess는 패킷마다 붙는 헤더 오버헤드 때문에 작은 패킷이 많은 환경(이미지가 많은 페이지 등)에서 다소 불리합니다. 링크에 지속적인 패킷 손실이 발생하면 구도가 바로 바뀝니다. TCP 계열 프로토콜(SS/VMess/Trojan/VLESS over TCP)은 커널 TCP의 양보 전략에 좌우되어 손실률이 올라갈수록 처리량이 급격히 떨어집니다. Hysteria2는 자체 혼잡 제어로 같은 손실률에서도 설정한 대역폭에 가까운 처리량을 유지하며, TUIC도 BBR을 사용할 경우 전통적인 TCP보다 뚜렷하게 우수합니다. 이것이 "저녁 혼잡 시간대에는 QUIC 계열 프로토콜이 체감상 더 낫다"는 말의 기술적 근거입니다.

동시성과 헤드 오브 라인 블로킹

요즘 웹페이지는 흔히 수십 개의 요청을 동시에 보냅니다. 하나의 TCP 연결 위에서 동작하는 다중화(VMess의 mux 등)는 헤드 오브 라인 블로킹 문제가 있어, 한 번의 패킷 손실이 그 연결의 모든 요청을 막아버립니다. QUIC는 전송 계층에서 이 문제를 원천적으로 해결해 각 스트림이 독립적으로 재전송되어 서로 영향을 주지 않습니다. 그래서 Hysteria2와 TUIC는 "웹페이지에서 작은 요청이 대량으로 동시에 발생하는" 상황에서 체감상 더 매끄럽습니다. TCP 계열 프로토콜은 다중화를 아예 쓰지 않고 요청마다 커널이 개별 연결을 맺는 방식으로 대응하며, 연결 재사용 풀과 함께라면 나쁘지 않은 동시성 성능을 얻을 수 있지만 연결 수립 오버헤드가 더 자주 발생하는 대가를 치릅니다. 실제 테스트할 때는 상황을 구분하는 것이 좋습니다. 대용량 파일 다운로드로 처리량을, 이미지가 많은 페이지로 동시성을, 새 도메인 첫 접속으로 연결 수립을 테스트해야 하며, 단순한 지연 수치(ping 값)만으로는 링크 거리만 알 수 있을 뿐 세 가지 중 어느 것과도 동일하지 않습니다. 이 오해는 CL-08에서 더 다룹니다.

CL-04리소스 사용량과 모바일 배터리 소모

데스크톱 사용자는 프록시 코어가 CPU를 얼마나 쓰는지 신경 쓰는 경우가 드물지만, 모바일 사용자는 매일 배터리를 아껴 씁니다. 이 챕터에서는 "리소스 사용량"을 암호화 연산, 프로토콜 스택 위치, 무선 모듈 웨이크업 세 가지 요소로 나누고 모바일 실전 팁을 제시합니다.

암호화 연산: 하드웨어 가속이 갈림길

대칭 암호화는 프록시 트래픽의 고정 비용입니다. 최근 10년 사이 대부분의 휴대폰과 PC CPU에는 AES 명령어 집합이 내장되어 있어 aes-128-gcm 같은 스위트의 암호화·복호화는 체감할 수 있는 CPU 부하를 거의 유발하지 않습니다. 하드웨어 가속이 없는 구형 기기(일부 저가형 라우터, 오래된 TV박스)라면 chacha20-ietf-poly1305를 선택해야 합니다. 순수 소프트웨어 구현에 최적화되어 있어 같은 보안 강도에서 소프트웨어 AES보다 몇 배 빠릅니다. 프로토콜 측면에서 SS와 Trojan은 암호화가 한 겹뿐이라 연산 비용이 가장 낮습니다. VMess는 자체 암호화에 외부 TLS까지 겹쳐 이중 암호화가 발생, 6종 중 트래픽 단위당 CPU 비용이 가장 높은 조합입니다. VLESS가 본체 무암호화를 택한 것도 바로 이 중복 비용을 없애기 위해서입니다. 라우터에서 mihomo 코어를 구동할 때는 이 비용이 대역폭을 다 쓸 수 있는지를 직접적으로 좌우합니다.

QUIC의 사용자 공간 비용

TCP 프로토콜 스택은 운영체제 커널에서 동작하며 수십 년간 최적화되어 왔습니다. QUIC는 현재 주로 사용자 공간에서 구현되어 같은 트래픽에서도 CPU 사용량이 TCP 계열보다 대체로 높고 메모리 사용량도 약간 높습니다. 데스크톱에서는 이 차이가 크게 문제되지 않지만, 휴대폰에서 대용량 트래픽이 Hysteria2/TUIC로 계속 흐르면 발열과 배터리 소모가 SS/Trojan보다 한 단계 뚜렷하게 높아집니다. 결론은 "휴대폰에서 QUIC를 쓰지 말라"가 아니라 "QUIC의 이점을 필요한 곳에만 써야 한다"는 것입니다. 네트워크가 나쁠 때는 체감 개선이 배터리 비용을 훨씬 상회하지만, 네트워크가 좋을 때는 쓸 일 없는 손실률 대응 능력에 배터리를 낭비할 필요가 없습니다. 자동 전환 정책 그룹을 지원하는 클라이언트에서는 QUIC 노드와 TCP 노드를 함께 편성해 규칙에 따라 필요할 때만 선택하게 할 수 있습니다.

무선 모듈 웨이크업과 하트비트: 모바일 배터리 소모의 주범

휴대폰 배터리 소모의 진짜 주범은 대개 연산이 아니라 셀룰러/Wi-Fi 모듈이 반복적으로 절전 모드에서 깨어나는 것입니다. 장기 연결 프로토콜이 빈번한 하트비트를 유지하면, 매번 몇십 바이트만 보내더라도 무선 모듈이 깊은 절전 모드로 들어가지 못하게 막습니다. 이 부분에서 QUIC 계열은 흔히 간과되는 장점이 있습니다. 바로 연결 마이그레이션입니다. 휴대폰이 Wi-Fi와 셀룰러 사이를 전환할 때 TCP 연결은 반드시 끊고 다시 맺어야 해(완전한 핸드셰이크와 트래픽 재전송 유발) 하지만, QUIC 연결은 새 네트워크로 그대로 옮겨가 이어서 쓸 수 있습니다. 통근 상황에서 빈번한 재연결이야말로 배터리 소모와 끊김의 주요 원인 중 하나입니다. 실전 팁은 다음과 같습니다. 모바일에서는 mihomo 코어 기반의 Android용 Clash Plus 또는 FlClash 같은 클라이언트를 우선 선택하고, TUN 모드는 필요할 때만 켜세요(가상 네트워크 카드가 전체를 넘겨받으면 추가적인 상시 오버헤드가 발생합니다. 원리는 기술 노트의 TUN 모드 완벽 이해를 참고하세요). 정책 그룹의 자동 속도 측정 간격을 너무 촘촘하게 설정하지 마세요. 수백 밀리초마다 상태 확인을 하면 휴대폰에서는 확실한 배터리 킬러가 됩니다.

CL-05코어 계열: 오리지널 Clash, Meta, mihomo의 관계

"코어"는 클라이언트 화면 아래에서 실제로 트래픽을 처리하는 엔진입니다. 시장의 모든 Clash 계열 클라이언트는 같은 설정 문법을 공유하지만 엔진에는 세대 차이가 있습니다. 이 관계를 이해하지 못하면 "같은 구독이 A 클라이언트에서는 되고 B 클라이언트에서는 오류가 나는" 현상을 설명할 수 없습니다.

3대 코어의 계승 관계

오리지널 Clash 코어는 이 생태계의 모든 기반을 확립했습니다. YAML 설정, 프록시 그룹(정책 그룹), 규칙 기반 분기 처리입니다. 지원 프로토콜은 SS, VMess, Trojan, Socks5, HTTP가 중심이었습니다. 원작자는 이후 클로즈드 소스인 Premium 버전을 유지보수하며 TUN 모드와 규칙집(rule providers) 같은 고급 기능을 추가했습니다. 오리지널 저장소 업데이트가 멈춘 후 커뮤니티 포크인 Clash Meta가 메인 라인을 이어받아 프로토콜 지원을 대폭 확장하며 활발히 개발을 이어갔습니다. 이후 Meta 프로젝트는 mihomo로 이름을 바꿨습니다. 오늘날 Clash Meta 코어와 mihomo는 사실 같은 프로젝트의 같은 메인 라인을 가리킵니다. 이 계승 관계를 이해하면 선택 원칙을 한 문장으로 압축할 수 있습니다. 설정 문법은 하위 호환되고, 프로토콜 지원은 늘어나기만 하니, 새 프로토콜은 무조건 mihomo를 기준으로 판단하세요.

기능 차이 비교

클라이언트와 코어의 대응 관계

클라이언트는 코어를 감싼 그래픽 껍데기일 뿐이므로, 클라이언트를 고르는 것은 본질적으로 코어를 고르는 일입니다. 본 사이트 다운로드 센터에 등록된 활성 클라이언트인 Clash Plus(전 플랫폼 최우선 추천), Clash Verge Rev, FlClash, Clash Nyanpasu, Clash Meta for Android는 모두 mihomo 코어 기반으로 6종 프로토콜 전부 사용 가능합니다. 아카이브에 있는 Clash for Windows와 ClashX Meta는 유지보수가 중단되었고, 이들이 사용하는 오리지널/Premium 코어는 VLESS, Hysteria2, TUIC 노드를 로드할 수 없어 구독에 이런 프로토콜이 포함되면 "unsupported proxy type" 오류가 뜨거나 설정 전체가 로드에 실패합니다. 이것이 바로 "Clash for Windows 대체 프로그램"이 자주 검색되는 이유입니다. 구소프트웨어가 고장 난 게 아니라 프로토콜 생태계가 앞으로 나아간 것입니다. 클라이언트별 화면과 기능 차이는 클라이언트 비교 가이드의 항목별 비교를 참고하세요. 서버와 라우터 사용자는 다운로드 센터에서 mihomo 코어 단독 바이너리를 받아 그래픽 화면 없이 직접 실행할 수 있습니다.

CL-06구독 형식과 설정 파일 호환성

프로토콜과 코어 외에 흔히 걸려 넘어지는 세 번째 지점이 구독 형식입니다. 같은 노드 묶음도 여러 형식으로 배포될 수 있고, 클라이언트가 그 구독을 받아들일 수 있는지, 받아들인 후 필드가 유실되는지는 뚜렷한 규칙을 따릅니다.

3대 주요 배포 형식

현재 유통되는 구독은 대체로 세 가지로 나뉩니다. 첫째는 Clash YAML 완전 설정입니다. proxies, proxy-groups, rules를 모두 포함하는 완전한 YAML 파일로, Clash 계열 클라이언트에 바로 가져올 수 있고 정보 보존이 가장 완전하며 본 사이트 튜토리얼에서 기본으로 채택하는 형식입니다. 둘째는 Base64 공유 링크 모음으로, ss://, vmess://, trojan:// 같은 개별 노드 URI를 인코딩해 줄바꿈으로 이어붙인 형태입니다. 범용성은 가장 좋지만 노드 연결 파라미터만 담고 있고 분기 규칙이나 정책 그룹은 없어 Clash 계열 클라이언트에 넣기 전에 변환이 필요합니다. 셋째는 sing-box JSON 등 다른 생태계의 형식으로, Clash 계열 클라이언트가 직접 호환하지 못해 변환 서비스로 옮겨야 합니다. 가지고 있는 구독이 어느 유형인지는 구독 링크를 브라우저에서 열어 내용을 보면 바로 알 수 있습니다. YAML은 들여쓰기 구조가 뚜렷하고, Base64는 공백 없는 긴 문자와 숫자의 나열입니다.

필드 호환성: 같은 YAML도 세대에 따라 다르다

Clash YAML 문법은 전체적으로 하위 호환되지만, mihomo가 확장한 필드는 오리지널 코어에서 거부되거나 무시됩니다. 대표적으로 신규 프로토콜의 type 값(vless, hysteria2, tuic), rule-providers 규칙집, sniffer 스니핑 섹션, GEOSITE 계열 규칙, 그리고 VLESS 관련 flow, reality-opts 같은 전송 필드가 있습니다. 반대 방향은 문제가 없습니다. 오리지널 코어용으로 작성된 옛 설정은 mihomo에서 그대로 로드됩니다. 노드 항목의 프로토콜 유형을 확인하려면 type 필드만 보면 됩니다. 아래는 구조 파악용 최소 예시입니다(모든 파라미터는 가상의 값이며 구조 확인용입니다).

proxies:
  - name: "예시-Hysteria2"
    type: hysteria2
    server: hy2.example.com
    port: 443
    password: "your-password"
    sni: hy2.example.com

  - name: "예시-Shadowsocks"
    type: ss
    server: ss.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

구독 변환과 다중 설정 관리

형식이 클라이언트와 맞지 않을 때 "Clash 구독 변환"이 등장합니다. 변환 서비스는 원본 구독을 읽어 목표 형식으로 출력하며, 변환 시 원격 템플릿을 적용해 정책 그룹과 분기 규칙을 채울 수도 있습니다. 변환 서비스를 쓸 때는 두 가지를 주의해야 합니다. 구독 링크가 제3자 서비스를 거치게 되므로 개인정보에 민감한 사용자는 구독 제공자에게 처음부터 Clash YAML 형식을 직접 요청하는 것이 낫습니다. 또한 변환 템플릿이 최종 정책 그룹 구조를 결정하는데, 템플릿이 지나치게 복잡하면 설정 로딩이 느려지므로 간결한 템플릿을 고르는 것이 좋습니다. 여러 구독을 동시에 관리할 때의 이름 규칙, 업데이트, 전환 전략은 기술 노트의 Profile 기본 개념 글에 정리되어 있습니다. 특정 클라이언트에서 가져오기 버튼이 어디 있는지, 업데이트 간격을 어떻게 설정하는지는 튜토리얼 페이지의 플랫폼별 안내를 참고하시면 되므로 여기서는 반복하지 않습니다.

CL-07사용 환경별 선택 가이드

앞 여섯 챕터의 결론을 여기서 정리합니다. 올바른 선택 순서는 먼저 코어를 확인하고(mihomo 계열 클라이언트, 프로토콜 전면 호환), 자신의 주요 사용 환경에 맞춰 프로토콜을 고른 다음, 마지막으로 전송 계층이 다른 프로토콜 하나를 대체 수단으로 남겨두는 것입니다. 아래는 다섯 가지 대표적인 환경별 참고 결론입니다.

데스크톱 일상 업무와 웹 서핑

링크 품질이 대체로 안정적이므로 연결 속도와 동시성 체감이 극한 처리량보다 중요합니다. Trojan이나 VLESS + TLS를 우선 추천합니다. 암호화가 한 겹이고 오버헤드가 가벼우며 동작이 안정적이고, TLS 1.3의 단일 왕복 핸드셰이크로 새 페이지가 깔끔하게 열립니다. SS도 충분히 쓸 만하고 어떤 클라이언트에서도 진입 장벽이 없습니다. 정책 그룹은 같은 프로토콜의 여러 노드를 url-test 자동 선택 그룹으로 묶고, 상태 확인 간격은 몇 분 단위면 충분합니다. 데스크톱에서는 백그라운드 트래픽이 크게 부담되지 않지만, 지나치게 촘촘한 확인은 노드 측에도 불필요한 부담을 줍니다. 클라이언트는 다운로드 센터 Windows 섹션의 순서를 따르며, Clash Plus를 최우선으로 추천합니다.

모바일 통근과 배터리 절약 우선

모바일 환경의 핵심 키워드는 네트워크 전환과 배터리입니다. 프로토콜은 TUIC 또는 Trojan 중 하나를 추천합니다. TUIC의 0-RTT와 연결 마이그레이션 특성은 "엘리베이터를 나오는 순간 끊기고 재연결되는" 문제에 특히 효과적이고, Trojan은 트래픽 단위당 소모 전력이 가장 낮다는 점에서 강점이 있습니다. VMess는 휴대폰에서 가장 손해가 큰 선택입니다. 이중 암호화로 전력을 많이 쓰고, 타임스탬프 검증이 휴대폰 시계 오차로 핸드셰이크 실패를 자주 일으킵니다. CL-04의 배터리 절약 체크리스트에 맞춰 클라이언트 설정을 조정하고, Android 사용자는 다운로드 센터 Android 섹션에서 Clash Plus나 FlClash를 받고, iOS 사용자는 다운로드 페이지 iOS 섹션 안내에 따라 App Store에서 Clash Plus를 설치하세요.

불안정한 네트워크, 높은 손실률, 저녁 혼잡 시간대

판단 기준은 지연이 크게 흔들리고, 다운로드 속도가 대역폭보다 훨씬 낮으며, 동영상이 자주 버퍼링되는 경우입니다. 이는 Hysteria2의 주 무대입니다. 자체 혼잡 제어가 손실률이 높은 링크에서 갖는 처리량 우위는 CL-03에서 이미 설명했으며, 체감 차이는 대체로 "고화질 영상을 끊김 없이 볼 수 있는가" 수준입니다. 반드시 확인해야 할 두 가지 전제가 있습니다. 사용 중인 네트워크의 UDP 채널이 제한되지 않았는지(공공 Wi-Fi와 일부 모바일 네트워크에서 흔한 문제입니다), 그리고 노드 측에 설정된 대역폭 값이 실제 회선과 맞는지입니다. 대역폭 값을 과장하면 무효 재전송이 대량으로 발생해 오히려 더 느려집니다. 대체 수단은 필수입니다. 같은 정책 그룹에 Trojan이나 SS 노드를 함께 넣어 UDP가 안 될 때 수동 또는 규칙에 따라 전환하세요.

게임, 실시간 음성, 낮은 지연이 필요한 경우

실시간 애플리케이션의 고민은 UDP 트래픽 전달과 지연 흔들림입니다. TUIC를 우선 추천합니다. QUIC 고유의 UDP 전달 경로가 깔끔하고, 표준 혼잡 제어는 Hysteria2처럼 처리량을 위해 안정성을 희생하지 않아 안정적인 소량 패킷 스트림에 더 적합합니다. 차선책은 Hysteria2입니다. TCP 계열 프로토콜이 UDP를 전달하려면 추가 캡슐화가 필요해 지연과 흔들림이 한 단계 더 커지니 가능하면 피하는 것이 좋습니다. 또한 분기 규칙에도 주의해야 합니다. 게임 트래픽은 프로세스나 목적지 대역에 따라 고정 노드를 직접 지정하는 것이 좋고, 자동 속도 측정 그룹에 맡기지 마세요. 속도 측정으로 전환되는 순간의 연결 마이그레이션은 다운로드에는 체감되지 않지만 진행 중인 게임에는 곧 접속 끊김입니다. 규칙 작성법은 튜토리얼 페이지의 규칙 섹션에서 확인할 수 있습니다.

구형 기기, 라우터, 상시 구동 서비스

라즈베리파이, 소프트웨어 라우터, NAS 같은 기기의 제약은 CPU와 메모리입니다. 프로토콜은 SS(하드웨어 AES가 없으면 chacha20 스위트 사용)나 Trojan을 선택해 QUIC 계열의 사용자 공간 오버헤드와 VMess의 이중 암호화를 피하세요. 코어는 mihomo 단독 바이너리를 직접 사용하고, 기기 아키텍처에 맞춰 AMD64/ARM64/ARMv7/MIPS 버전을 선택하며 그래픽 화면 없이 구동하세요. 상시 구동 서비스는 설정 복잡도도 관리해야 합니다. 수천 개의 규칙과 수십 개의 정책 그룹은 메모리 사용량을 크게 끌어올리므로, 라우터에서는 간결한 규칙집을 쓰고 복잡한 분기 처리는 데스크톱에 맡기는 것이 좋습니다.

CL-08선택 시 흔한 오해와 이어서 찾아볼 곳

마지막 챕터는 가장 자주 접하는 인식 오해 몇 가지를 모으고, 사이트 내에서 이어서 찾아볼 경로를 제시합니다. 이 오해들의 공통점은 결론만 보면 그럴듯하지만 추론 과정에서 핵심 단계가 빠져 있다는 것입니다.

오해 1: 프로토콜은 신형일수록 좋다

프로토콜의 "신형"은 특정 환경의 특정 문제를 해결하는 것일 뿐, 전면적인 업그레이드가 아닙니다. VLESS는 VMess에 비해 명확한 덜어내기 최적화지만, Hysteria2와 TUIC가 Trojan에 비해 세대 차이 나는 우위를 갖는 것은 아닙니다. 원활한 네트워크에서는 셋의 체감이 거의 차이 없고, 오히려 QUIC 계열은 사용자 공간 CPU와 UDP 가용성이라는 두 가지 비용을 더 치릅니다. 올바른 방법은 CL-07의 환경별 표에 맞춰 고르는 것이지, 무조건 신형을 좇는 것이 아닙니다. 마찬가지로 "어떤 프로토콜은 이미 구식이다"라는 말도 걸러서 들어야 합니다. SS는 가장 먼저 등장했지만 지금도 저사양 기기 환경에서는 대체 불가능한 최선의 선택입니다.

오해 2: 지연 수치가 곧 체감이다

클라이언트의 지연 테스트(테스트 URL에 대한 HTTP 요청 소요 시간 등)는 "지금 이 노드까지 한 번 다녀오는 데 얼마나 걸리는지"만 보여줄 뿐, 처리량, 손실률, 동시성 성능과는 전혀 다른 이야기입니다. 지연 수치가 좋아 보이는 노드가 대역폭은 매우 작을 수 있고, 혼잡 시간대에 손실률이 심한 노드가 심야 테스트에서는 좋은 수치를 보일 수도 있습니다. 노드를 고를 때는 시간대를 바꿔 여러 번 테스트하고, 대용량 트래픽 환경이라면 실제 다운로드 테스트를 한 번 더 해보는 것이 좋습니다. 노드가 전부 타임아웃될 때도 서둘러 구독을 바꾸지 말고, 기술 노트의 진단 순서에 따라 내 기기의 네트워크부터 확인하세요. 대부분의 문제는 자신과 가장 가까운 단계에서 발생합니다.

오해 3: 암호화 층수가 많을수록 안전하다

VMess over TLS의 이중 암호화는 역사적 유산일 뿐 보안 이득이 아닙니다. 외부 TLS가 이미 확립된 상황에서 내부 암호화는 추가적인 기밀성을 제공하지 않고 CPU만 소모합니다. VLESS가 본체 암호화를 없애고 TLS 1.3을 전적으로 신뢰하는 것도 보안 강도 손실 없이 이루어진 것으로, 이것이 바로 현대 프로토콜 설계의 공통된 견해입니다. 신뢰할 수 있는 한 겹의 암호화가 중복된 여러 겹의 암호화보다 낫다는 것입니다. 보안성은 암호화 스위트와 구현 품질로 평가해야 하며 층수로 평가할 것이 아닙니다.

오해 4: 코어 버전을 무조건 최신으로 쫓거나 무조건 구버전만 고집한다

양쪽 극단 모두 대가가 있습니다. 업데이트가 끊긴 코어를 고집하는 문제는 CL-05에서 이미 충분히 설명했습니다. 새 프로토콜을 전혀 쓸 수 없다는 점입니다. 반면 코어의 대규모 업데이트는 가끔 설정 필드 조정을 동반하는데, 무작정 곧바로 업그레이드하면 기존 설정을 조금 수정해야 하는 상황을 만날 수 있습니다. 안전한 방법은 클라이언트를 활발히 유지보수되는 버전 라인에 두고(다운로드 센터의 추천 순서가 바로 이 기준을 따릅니다), 대규모 업데이트 후에는 먼저 백업 설정으로 확인한 다음 일상 사용으로 전환하는 것입니다. 설정 파일 백업과 다중 프로필 관리 방법은 CL-06 챕터 끝에 있는 노트 링크를 참고하세요.

다음으로 어디로 갈까요

이 가이드를 다 읽으셨다면, 사이트 내에서 필요에 따라 다음 경로를 활용하세요. 실제 설치는 다운로드 센터에서 플랫폼별로 받고, 첫 설정은 튜토리얼 페이지의 3단계 안내를 따르고, 클라이언트 소프트웨어 중 고민이 된다면 클라이언트 비교 가이드의 비교표를 확인하세요. TUN 모드, DNS 유출, macOS 권한 같은 전문 주제는 기술 노트에서 태그로 검색하세요. 이 페이지는 프로토콜 생태계 변화에 따라 비정기적으로 갱신되며, 등록 정보는 상단의 자료 카드를 기준으로 합니다.