Clash 프로토콜 가이드

1장 · 가이드 목적과 활용법

이 가이드와 사이트 내 다른 페이지의 역할 분담을 먼저 정리합니다. 입문 가이드는 '설치부터 연결까지'의 핵심 절차를 담당합니다. 클라이언트 다운로드, 구독 가져오기, 모드 선택, 연결 확인까지 네 단계만 거치면 바로 사용할 수 있으며 프로토콜 용어를 몰라도 무방합니다. 반면 이 가이드는 노드 목록에 표시되는 ss, vmess, trojan, hysteria2 같은 표기가 무엇을 뜻하는지, 같은 구독인데 왜 어떤 노드는 빠르고 어떤 노드는 느린지, 예전 클라이언트가 특정 노드를 인식하지 못하는 이유가 무엇인지처럼 원리 이해가 필요한 질문에 답하는 역할을 맡습니다. 즉 튜토리얼 페이지는 '사용'을, 가이드 페이지는 '선택'을 책임진다고 정리할 수 있습니다. 아직 설치를 마치지 않았다면 먼저 튜토리얼 페이지를 따라 진행한 뒤 필요할 때 이 페이지를 참고하는 것을 권장합니다. 클라이언트 설치 파일은 다운로드 페이지에서 제공하며, 플랫폼별로 Clash Plus를 최우선으로 추천합니다.

전체 구성은 실제 참고 습관에 맞춰 정리했습니다. 2장부터 4장까지는 기술적 흐름에 따라 6종 프로토콜을 세 그룹으로 나누어 소개합니다. Shadowsocks와 VMess는 초기의 자체 암호화 방식, Trojan과 VLESS는 표준 TLS를 그대로 활용하는 위장 방식, Hysteria2와 TUIC은 QUIC 전송 기반의 신세대 방식을 대표합니다. 5장에서는 여섯 프로토콜을 하나의 표로 비교하고 모바일 배터리 소모를 별도로 다룹니다. 6장에서는 원본 Clash, Clash.Meta, mihomo 세 세대 커널의 계보와 기능 차이를 정리하는데, 이는 클라이언트가 인식할 수 있는 프로토콜을 직접적으로 좌우합니다. 7장에서는 Clash 구독과 다른 공유 형식 간의 호환 관계를 설명합니다. 8장은 사용 상황별로 실행 가능한 선택 기준을 정리해 마무리합니다.

먼저 확인해야 할 용어 두 가지가 있습니다. 첫째, 이 가이드에서 말하는 '프로토콜'은 Clash 설정 파일의 proxies 항목 중 type 필드에 해당하며, 클라이언트와 원격 서버 간의 전송 규약을 가리킵니다. '규칙'이나 '정책 그룹' 같은 개념과는 다른 층위입니다. 둘째, 대부분의 사용자는 프로토콜 필드를 직접 작성하지 않습니다. 노드 정보는 구독으로 전달되고 클라이언트가 이를 해석해 노드 목록으로 보여줍니다. 따라서 '프로토콜 선택'은 실제로는 두 가지 행동으로 나타납니다. 여러 프로토콜이 섞인 구독에서 특정 유형의 노드를 우선 선택하는 것, 그리고 서비스 제공처와 협의할 때 특정 유형의 노드를 명확히 요청하는 것입니다. 이를 이해해야 이후 각 장의 선택 기준이 실질적으로 활용됩니다.

2장 · Shadowsocks와 VMess: 두 세대 고전 프로토콜의 설계 방식

Shadowsocks: 최소한의 암호화 전달

Shadowsocks(이하 SS)는 6종 프로토콜 중 구조가 가장 단순하고 등장 시기도 가장 오래되었습니다. 설계 목표는 단 하나, 로컬과 원격 서버 사이에 암호화된 데이터 전달 통로를 만드는 것뿐이며 그 외에는 아무것도 덧붙이지 않습니다. 동작 방식은 클라이언트가 로컬에서 트래픽을 받아 사전에 공유된 비밀번호로 암호화한 뒤 원격 서버로 전송해 복호화하는 구조입니다. 프로토콜 자체에 별도의 핸드셰이크 단계나 세션 상태, 버전 협상이 없어 첫 패킷부터 곧바로 실제 데이터를 담습니다. 현재는 AEAD 암호화 스위트를 일반적으로 사용하며 aes-128-gcm, aes-256-gcm, chacha20-ietf-poly1305가 대표적입니다. 이 중 ChaCha20 계열은 AES 하드웨어 가속을 지원하지 않는 오래된 휴대폰이나 라우터에서 속도가 눈에 띄게 빠릅니다.

이런 극단적으로 단순한 구조는 장단점이 뚜렷합니다. 장점은 오버헤드가 전 프로토콜 중 가장 낮다는 점입니다. 핸드셰이크가 없어 즉시 연결되고 암호화 계층이 하나뿐이라 CPU와 메모리 사용량을 거의 무시할 수 있어, SS는 지금도 저사양 기기나 임베디드 환경에서 자주 선택됩니다. 단점은 프로토콜의 통신 특징이 오랫동안 충분히 연구되어 왔다는 점으로, 최신 배포 환경에서는 전송 계층 플러그인으로 보완하는 경우가 많습니다. 이는 서버 측의 책임이며 클라이언트는 구독으로 전달된 plugin 필드를 그대로 해석하면 됩니다.

VMess: 구조화된 세션 프로토콜

VMess는 V2Ray 프로젝트가 만든 고유 프로토콜로, SS보다 등장 시기가 늦으며 접근 방식도 전혀 다릅니다. 극단적으로 단순한 통로 대신 구조가 완비된 세션 프로토콜을 지향합니다. VMess는 사용자 UUID를 신원 증명으로 사용하고 요청 헤더에 명령과 암호화 방식 등 메타데이터를 담으며, 시간 검증 메커니즘을 내장하고 있습니다. 클라이언트와 서버의 시스템 시간 차이가 허용 범위(약 90초)를 넘으면 핸드셰이크가 실패합니다. 이는 '노드가 전부 타임아웃되면 먼저 휴대폰 시간을 확인하라'는 흔한 트러블슈팅 노하우의 배경이기도 합니다. VMess의 또 다른 특징은 전송 계층 조합이 매우 자유롭다는 점입니다. TCP를 그대로 쓸 수도 있고, WebSocket이나 gRPC 등 전송 방식에 TLS를 함께 적용할 수도 있습니다. WebSocket과 TLS를 결합하면 외부에서는 평범한 암호화 웹 세션처럼 보여 공유 호스팅 환경에서 자주 사용됩니다.

장단점도 명확합니다. 구조화된 헤더와 다층 전송은 유연성을 가져다주지만 SS보다 핸드셰이크 지연과 CPU 부담이 커집니다. 과거의 alterId 동적 포트 난독화 방식은 AEAD 헤더로 대체되었으므로 최신 구독에서는 이 값이 0이어야 합니다. 0이 아닌 값을 가진 구형 노드를 받았다면 호환성과 보안성 모두 의심해봐야 합니다. 두 프로토콜의 대표적인 설정 필드는 다음과 같으며 구독 해석 결과를 확인하는 용도로만 참고하고 직접 수정하지 않는 것을 권장합니다.

proxies:
  - name: "예시-SS"
    type: ss
    server: node.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
  - name: "예시-VMess"
    type: vmess
    server: node.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    network: ws
    ws-opts:
      path: /ws

3장 · Trojan과 VLESS: 표준 TLS를 활용한 위장 방식

Trojan: HTTPS 속에 숨기다

Trojan의 설계 방향은 앞의 두 프로토콜과 정반대입니다. 새로운 암호화 구조를 만들지 않고 인터넷에서 가장 흔한 TLS를 그대로 활용합니다. 외부에서 보면 Trojan 연결은 표준 HTTPS 접속과 동일하게 보이며, 실제 도메인과 유효한 인증서, 표준 핸드셰이크를 모두 갖추고 있습니다. 올바른 비밀번호를 가진 클라이언트만이 TLS 통신 내부에서 프록시 요청으로 인식되고, 그 외 접속(브라우저로 해당 도메인을 직접 열었을 때 포함)은 서버에 올려둔 실제 웹사이트로 되돌려집니다. 이 방식은 서버가 도메인과 인증서를 반드시 갖춰야 하므로 배포 부담은 서비스 제공자에게 쏠리지만, 클라이언트 측은 오히려 매우 단순합니다. 핵심 필드는 password와 sni 두 가지뿐입니다.

성능 측면에서 Trojan의 연결 비용은 딱 한 번의 TLS 핸드셰이크뿐입니다. 데이터 전송 시 TLS 단일 계층 암호화만 사용하므로 VMess에 WebSocket과 TLS를 결합한 다층 구조보다 CPU 부담이 낮고 처리량 상한도 더 높습니다. 선택 시 유일하게 주의할 필드는 skip-cert-verify입니다. 이 값이 true이면 인증서 검증을 건너뛴다는 뜻이므로, 원인을 명확히 아는 트러블슈팅 상황에서만 잠시 사용해야 하며 평소 설정에 이 값이 있다면 서비스 제공처에 이유를 확인해야 합니다.

VLESS: 한 단계 더 덜어내다

VLESS는 VMess를 체계적으로 덜어낸 결과물로 이해할 수 있습니다. 외부 TLS가 이미 기밀성을 담당하는 만큼 프로토콜 내부의 암호화는 중복 작업이라는 판단 아래, VLESS는 내장 암호화를 제거하고 프로토콜 헤더를 최소화했습니다. 신원 확인은 여전히 UUID로 하며 기밀성은 전적으로 외부 TLS에 맡깁니다. 이를 바탕으로 VLESS 생태계는 두 가지 중요한 확장을 발전시켰습니다. XTLS 플로우 제어(대표 값 xtls-rprx-vision)는 내외 이중 암호화의 중복 처리를 줄여 대용량 처리량을 높이고, REALITY는 제3의 실제 웹사이트의 TLS 지문을 빌려 핸드셰이크를 완료해 서버가 별도의 도메인과 인증서를 갖출 필요가 없게 합니다.

클라이언트 사용자 입장에서 VLESS 계열은 실무적으로 두 가지를 짚어야 합니다. 첫째, 프로토콜 지원 여부는 전적으로 커널 세대에 달려 있습니다. mihomo 커널은 VLESS, XTLS, REALITY를 완전히 지원하지만 원본 Clash 커널은 전혀 인식하지 못합니다. 이런 노드를 받았는데 unsupported proxy type 오류가 뜬다면 먼저 클라이언트 커널을 확인해야 합니다(자세한 내용은 6장 참고). 둘째, VLESS는 6종 프로토콜 중 필드 수가 가장 많습니다. flow, reality-opts, client-fingerprint 등 어느 하나라도 서버 측과 일치하지 않으면 연결이 실패하므로, 이런 노드는 구독으로 자동 전달받는 것이 바람직하며 직접 옮겨 적으면 오류가 발생하기 쉽습니다.

4장 · Hysteria2와 TUIC: QUIC 기반의 신세대 프로토콜

공통 기반: QUIC이 가져다준 것

앞선 3개 장에서 다룬 네 프로토콜은 모두 TCP 위에서 동작하지만, 이번 장의 두 프로토콜은 QUIC 위에서 동작합니다. QUIC은 UDP 위에서 동작하는 사용자 공간 전송 프로토콜이며 HTTP/3의 기반이기도 합니다. 이 전환은 세 가지 공통 이점을 가져옵니다. 첫째, 0-RTT 세션 복구로 재연결 시 추가 핸드셰이크 왕복이 거의 없어 'TCP 3방향 핸드셰이크에 TLS 핸드셰이크를 더한' 구조보다 첫 연결 경험이 훨씬 낫습니다. 둘째, 연결 마이그레이션 기능으로 휴대폰이 Wi-Fi와 셀룰러 네트워크를 전환해도 세션이 이어져 다시 연결할 필요가 없습니다. 셋째, 혼잡 제어가 사용자 공간에서 구현되어 운영체제 커널의 TCP 스택에 얽매이지 않고 더 적극적인 알고리즘으로 교체할 수 있습니다.

서로 다른 두 가지 구현 방향

Hysteria2는 대역폭을 적극적으로 활용하는 방향을 택했습니다. 대표적인 설계는 사용자가 링크 대역폭을 직접 선언(설정의 up/down 필드)하게 하고, 내장된 혼잡 제어가 이를 근거로 링크를 적극적으로 채운다는 점입니다. 손실률과 지연이 높은 열악한 네트워크에서는 표준 혼잡 제어에 의존하는 TCP 계열 프로토콜보다 처리량이 뚜렷하게 앞서는 경우가 많습니다. TCP 계열은 손실 발생 시 보수적으로 속도를 줄이지만 Hysteria2는 그렇지 않습니다. 외형적으로는 HTTP/3로 위장해 일반적인 최신 웹 트래픽과 같은 계층에 위치합니다. TUIC은 반대로 '더 표준적인 QUIC'을 지향합니다. 적극적인 채움 방식을 쓰지 않고 혼잡 제어 알고리즘을 bbr, cubic, new_reno 중에서 선택할 수 있으며, 두 가지 UDP 전달 모드(over stream와 native)를 기본 지원해 게임이나 음성 통화 같은 UDP 기반 서비스의 전달 방식이 TCP 계열보다 훨씬 깔끔합니다.

반드시 알아야 할 대가

QUIC 계열의 대가 역시 이점만큼 뚜렷합니다. 첫째, 링크가 UDP에 의존하는데 일부 접속 네트워크는 UDP 트래픽에 속도 제한이나 낮은 우선순위를 적용합니다. 이 경우 QUIC 계열 프로토콜의 실제 속도가 오히려 평범한 Trojan 연결보다 못할 수도 있으며, 제한 여부는 실제로 테스트해봐야만 알 수 있습니다. 둘째, 사용자 공간 프로토콜 스택에 전체 암호화가 더해져 CPU 사용량이 TCP 계열보다 높고, 이는 곧바로 모바일 배터리 소모 증가로 이어집니다(5장에서 자세히 설명). 셋째, QUIC은 주기적인 탐지로 연결 상태를 유지하므로 휴대폰이 백그라운드에 상주할 때 깨어나는 빈도가 조용한 TCP 장기 연결보다 많습니다. 종합하면 QUIC 계열 프로토콜은 기본값이 아니라 '특정 상황에 강한 도구'로 이해해야 합니다.

5장 · 접속 속도, 리소스 사용량, 모바일 배터리 소모 비교

비교 기준

먼저 기준을 밝힙니다. 프로토콜 성능은 서버 사양, 회선 품질, 전송 계층 조합에 크게 좌우되므로 '어떤 프로토콜의 지연이 몇 밀리초'라는 절대 수치는 맥락 없이는 의미가 없습니다. 아래 표는 동일한 서버와 회선 조건에서의 상대적인 수준을 나타낸 것으로, 같은 구독 안에서 여러 유형의 노드를 서로 비교할 때만 참고용으로 활용하며 특정 노드의 성능을 보증하는 것은 아닙니다. 표에서 VMess는 가장 흔한 WebSocket과 TLS 조합, VLESS는 REALITY 조합을 기준으로 합니다.

각 항목의 원인

첫 연결 속도는 핸드셰이크 계층 수에 따라 결정됩니다. SS는 핸드셰이크가 없어 첫 패킷부터 데이터가 전달되고, Trojan은 TLS 핸드셰이크가 한 번뿐입니다. VMess에 WebSocket과 TLS를 결합하면 TCP, TLS, WebSocket 세 계층을 순서대로 맺어야 하므로 가장 느립니다. QUIC 계열 두 프로토콜은 세션 복구 시 0-RTT를 구현할 수 있어 재연결 상황에서 특히 강점을 보입니다. 열악한 네트워크에서의 처리량은 혼잡 제어 방식에 따라 갈립니다. TCP 계열 프로토콜은 운영체제의 표준 혼잡 제어에 묶여 손실 발생 시 보수적으로 속도를 줄이지만, Hysteria2의 적극적인 채움 전략은 손실 환경에서 양보를 가장 적게 합니다. CPU 사용량은 암호화 계층 수와 프로토콜 스택 위치에 따라 결정됩니다. 단일 계층 암호화를 사용하는 SS, Trojan, VLESS가 가장 가볍고, QUIC 계열의 사용자 공간 프로토콜 스택 자체가 지속적인 연산 부담이 됩니다.

모바일 배터리 소모에 대한 별도 설명

모바일 배터리 소모는 별도로 다룰 만한 주제입니다. 데스크톱과 결정 요인이 다르기 때문입니다. 휴대폰에서 Clash는 VpnService로 가상 네트워크 어댑터를 만들어 백그라운드에 상주하며, 배터리 소모는 세 부분으로 나뉩니다. 커널이 트래픽을 처리하는 CPU 시간, 연결 상태를 유지하기 위한 하트비트 웨이크업, 그리고 무선 베이스밴드가 깨어나는 횟수입니다. TCP 계열 프로토콜은 유휴 시간에 거의 조용한 반면 QUIC의 활성 탐지는 더 자주 일어나며, 셀룰러 네트워크에서는 탐지마다 베이스밴드가 깨어날 수 있어 장시간 대기 시 누적 차이가 상당합니다. 실제 점검 방법과 백그라운드 정책 최적화는 블로그 글 《Clash로 인한 배터리 소모 빠를 때 점검 방법》에 전체 절차가 정리되어 있으며, 안드로이드의 VpnService 권한과 유지 메커니즘은 《Clash 안드로이드 클라이언트 사용 핵심 정리》에서 확인할 수 있습니다.

6장 · 커널 계보: 원본 Clash, Meta, mihomo의 관계

세 세대의 흐름

오늘날 'Clash'라는 단어는 최소 세 가지를 가리킵니다. YAML 설정 형식, 커널 계보, 그리고 여러 GUI 클라이언트입니다. 커널 계보를 명확히 이해해야 호환성 문제도 이해할 수 있습니다. 최초의 원본 Clash 커널이 이 생태계의 기본 틀을 확립했습니다. YAML 설정, proxies/proxy-groups/rules 3단 구조, 규칙 기반 분기와 정책 그룹 등이 여기서 시작되었고, 비공개 소스인 Premium 빌드는 TUN 모드 등 추가 기능을 제공했습니다. 이후 커뮤니티 포크인 Clash.Meta가 설정 호환성을 유지하면서 지원 프로토콜을 대폭 확장했습니다. 원본 저장소가 보관 처리되어 개발이 멈춘 뒤, Meta 포크는 개발을 이어가며 mihomo로 이름을 바꾸었고 현재 실질적인 주력 커널로 자리 잡았습니다. 본 사이트 홈에 표시되는 인증 번호 줄의 KERNEL mihomo가 바로 이 커널을 가리킵니다.

기능 차이 비교

설정 호환성과 클라이언트 대응

설정 호환성은 단방향 원칙을 따릅니다. 원본 커널용으로 작성된 설정 파일은 mihomo에서 대부분 그대로 실행되며, mihomo는 구형 필드와 좋은 호환성을 유지합니다. 반대는 성립하지 않습니다. VLESS 노드나 신형 규칙셋, 스니핑 설정이 포함된 파일을 원본 커널에 넘기면 시작 단계부터 오류가 발생합니다. 이 원칙은 클라이언트 선택으로 이어집니다. 본 사이트 다운로드 페이지에 등재된 유지보수 중인 클라이언트(플랫폼별로 최우선 추천되는 Clash Plus, 그리고 Clash Verge Rev, FlClash 등)는 모두 mihomo 커널을 내장해 6종 프로토콜을 전부 사용할 수 있습니다. 유지보수가 종료된 Clash for Windows와 ClashX Meta 보관 항목은 원본 커널을 탑재해 QUIC 계열과 VLESS 노드를 인식하지 못합니다. 노드 목록에서 unsupported proxy type 같은 오류가 나타난다면 이 표를 참고해 mihomo 계열 클라이언트로 교체해야 하며 구독을 수정할 필요는 없습니다. 클라이언트별 전체 비교는 클라이언트 비교 페이지에서 확인할 수 있습니다.

7장 · 구독 형식과 설정 호환성

흔히 접하는 세 가지 형식

일상적으로 접하는 '구독'은 실제로 세 가지 형태가 있으며 호환 범위가 각각 다릅니다. 첫 번째는 Clash 전용 구독으로, proxies, proxy-groups, rules 세 부분을 모두 포함한 완전한 YAML 문서입니다. Clash 계열 클라이언트가 바로 사용할 수 있는 가장 이상적인 형태입니다. 두 번째는 단일 노드 공유 링크로, ss://, vmess://, trojan:// 같은 URI 형식이며 링크 하나가 노드 하나를 나타낼 뿐 그룹이나 규칙 정보는 담지 않습니다. 세 번째는 범용 통합 구독으로, 여러 줄의 공유 링크를 Base64로 인코딩해 HTTP로 배포하는 방식이며 여러 클라이언트 생태계에서 공통으로 쓰이는 형식입니다. 뒤의 두 형식은 Clash 고유 형식이 아니므로 변환이 필요합니다. 대부분의 구독 서비스는 Clash 전용 주소도 함께 제공하므로 이를 우선 사용하는 것이 좋습니다. mihomo 계열 클라이언트는 일반적인 공유 링크를 해석하는 기능을 내장하고 있지만 변환된 결과에는 노드 정보만 담기므로 그룹과 규칙은 설정 파일로 별도 보완해야 합니다.

노드와 설정의 분리: proxy-providers

고급 활용법 중 알아둘 만한 기능은 proxy-providers입니다. 노드 소스를 외부 리소스로 선언하면 메인 설정은 그룹과 규칙만 담당하고 커널이 주기적으로 노드를 자동으로 갱신합니다. 이 방식의 장점은 사용자 정의 규칙과 구독 업데이트가 서로 간섭하지 않는다는 점입니다. 구독으로 받은 전체 설정을 직접 수정하면 다음 업데이트 때 덮어써지지만, providers 구조는 장기적으로 유지할 수 있습니다. 대표적인 선언 예시는 다음과 같습니다.

proxy-providers:
  main:
    type: http
    url: "https://example.com/sub?token=xxxx"
    interval: 86400
    path: ./providers/main.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

호환성 관련 주의사항

실무에서 기록해둘 만한 사항이 세 가지 있습니다. 첫째, 같은 구독 주소라도 클라이언트에 따라 다른 내용이 반환될 수 있습니다. 서버는 요청의 User-Agent를 기준으로 클라이언트 유형을 판단해 그에 맞는 형식을 내려주는 경우가 많아, '브라우저로 구독 주소를 열었을 때 보이는 내용'과 '클라이언트가 실제로 받는 내용'이 다를 수 있습니다. 구독 문제를 점검할 때는 브라우저에서 본 내용을 기준으로 삼으면 안 됩니다. 둘째, 신형 프로토콜 노드의 사용 가능 여부는 구독 출력 측과 커널이 함께 결정합니다. 클라이언트가 mihomo를 사용하더라도 구독 측이 원본 필드로만 출력한다면 Hysteria2, VLESS 같은 노드는 목록에 나타나지 않으므로, 이 경우 서비스 제공처에 mihomo 형식 구독 주소를 요청해야 합니다. 셋째, 구독을 가져온 뒤에는 자동 갱신 주기를 설정해야 합니다. 오랫동안 갱신되지 않은 구독은 '노드가 전부 타임아웃되는' 흔한 원인 중 하나입니다. 가져오기 전체 절차는 입문 가이드를 참고하고, 각 형식의 차이에 대한 상세한 설명은 블로그 글 《Clash 구독 링크 가져오기 튜토리얼》을 참고하세요.

8장 · 사용 상황별 프로토콜 선택 가이드

선택 전에 알아야 할 전제

먼저 흔한 오해 하나를 짚습니다. Clash 클라이언트에는 '프로토콜 선택 스위치'가 따로 존재하지 않습니다. 이른바 선택이란 구독으로 전달받은 노드 목록에서 노드 유형에 따라 취향에 맞게 고르는 것을 뜻합니다. 대부분의 구독은 여러 프로토콜이 섞여 있으며 같은 지역이라도 여러 유형의 노드가 함께 제공되는 경우가 많습니다. 정책 그룹으로 서로 다른 프로토콜의 노드를 같은 그룹에 넣고 지연에 따라 자동 전환하도록 설정할 수도 있습니다. 따라서 아래 가이드의 활용법은 상황에 맞춰 우선 유형을 정하고, 노드 목록에서 해당 유형을 우선 선택하며, 대비책으로 다른 한 유형을 남겨두는 것입니다.

상황별 비교표

추가 조항 세 가지

첫째, 게임과 회의 상황은 프로토콜 외에 트래픽 처리 방식도 관련됩니다. 이런 프로그램은 시스템 프록시 설정을 따르지 않는 경우가 많아 클라이언트에서 TUN 모드를 켜야 완전히 처리할 수 있습니다. 두 처리 방식의 차이는 블로그 글 《Clash TUN 모드와 시스템 프록시의 차이점》을 참고하세요. 둘째, 모바일 환경에서 배터리와 속도 사이에서 고민한다면 5장의 배터리 소모 항목을 우선 기준으로 삼는 것을 권장하며, QUIC 계열 노드는 열악한 네트워크나 대용량 전송이 실제로 필요한 경우에만 사용하세요. 셋째, 어떤 가이드도 실제 테스트를 대체할 수 없습니다. 같은 유형의 노드라도 서버와 회선에 따라 성능 차이가 프로토콜 간 차이보다 클 수 있으므로, 유형을 정한 뒤에도 실제 사용 시간대에 직접 비교해 확인해야 합니다.

선택 절차 3단계 정리

전체 내용을 세 단계 절차로 정리하면 다음과 같습니다. 첫째, 클라이언트 커널을 확인합니다. 유지보수 중인 mihomo 계열 클라이언트(플랫폼별로 최우선 추천되는 Clash Plus, 설치 파일은 다운로드 페이지에서 확인)는 6종 프로토콜을 전부 사용할 수 있으며, 구형 커널 클라이언트는 먼저 교체해야 합니다. 둘째, 구독 제공 상태를 확인합니다. 노드 목록에 실제로 어떤 유형이 포함되어 있는지 점검하고 필요한 유형이 없다면 서비스 제공처에 mihomo 형식 구독을 요청하세요. 셋째, 위 표의 상황에 맞춰 우선순위를 정하고 실제로 테스트해 확인하며, TCP 계열 노드 하나는 대비책으로 남겨둡니다. 실행 방법에 관한 궁금증은 입문 가이드를 따라 단계별로 진행하고, 오류가 발생하면 FAQ 페이지를 참고해 점검하세요.