Clash 프로토콜 완전 정리: 6가지 프록시 프로토콜과 mihomo 코어 선택 가이드

R-01클라이언트, 코어, 프로토콜: 3단계부터 구분하기

클라이언트는 껍데기일 뿐

Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu 같은 이름은 모두 그래픽 인터페이스 클라이언트를 가리킵니다. 클라이언트는 노드 목록 표시, 프록시 모드 전환, 시스템 프록시 켜기/끄기 관리를 담당하며, 그 자체로는 어떤 프록시 연결도 맺지 않습니다. 인터페이스 차이는 조작 경험에만 영향을 주고 실제 연결 동작에는 영향을 주지 않습니다. 같은 구독을 두 클라이언트에 각각 불러오면 노드 목록, 지연 측정, 분기 결과가 동일해야 하며, 다르다면 원인은 대부분 설정 차이이지 클라이언트 자체의 차이가 아닙니다.

코어가 곧 엔진

실제로 원격 서버와 통신하는 것은 코어, 즉 클라이언트 실행 시 함께 뜨는 백그라운드 프로세스입니다. 현재 다운로드 페이지에 있는 유지보수 중인 클라이언트는 거의 전부 mihomo 코어(구 Clash Meta)를 내장하고 있습니다. 같은 노드 설정이라도 클라이언트가 다르더라도 코어 버전이 비슷하면 연결 동작, 지원 프로토콜 범위, 규칙 적용 결과가 대체로 일치합니다. 즉 「프로토콜 선택」은 사실상 「코어가 지원하는 프로토콜 목록 안에서 고르는 것」이며, 클라이언트 화면에서 고르는 게 아닙니다. 사용 중인 클라이언트의 코어를 확인하려면 설정이나 정보 화면을 열어보면 코어 이름과 버전이 표시됩니다. mihomo 또는 Clash Meta라는 표시가 보인다면 프로토콜 지원 범위는 이 페이지의 R-08 챕터를 기준으로 보면 됩니다.

프로토콜은 캡슐화 규약

노드 정보에 표시되는 SS, VMess, Trojan, VLESS, Hysteria2, TUIC가 바로 프로토콜 종류입니다. 프로토콜은 세 가지를 규정합니다: 데이터를 어떻게 캡슐화하는지, 어떤 방식으로 암호화하는지, TCP를 쓰는지 UDP를 쓰는지. 구독을 불러오면 클라이언트가 각 노드를 코어 설정 안의 proxy 항목으로 해석하고, 코어는 프로토콜 규격에 따라 서버와 핸드셰이크를 수행하고 트래픽을 전달합니다. 프로토콜 선택은 「클라이언트-노드」 구간에만 영향을 주며, 노드에서 목적 사이트까지의 마지막 구간은 서버 측이 결정하는 부분이라 클라이언트가 개입할 수 없습니다.

이 페이지와 튜토리얼 페이지의 역할 구분은 이제 명확합니다. quickstart.html은 「따라 하면 연결되는」 메인 플로우이고, 이 페이지는 「찾아보고 이해하는」 참고 매뉴얼입니다. 모르는 설정 항목이 나오면 먼저 용어집을 확인한 뒤, 이 페이지의 해당 챕터로 돌아와 자세히 살펴보세요.

R-02프록시 프로토콜의 발전 흐름

범용 프록시: SOCKS5와 HTTP

가장 초기의 프록시 프로토콜은 범용 목적이었습니다. SOCKS5는 전달만 담당하고 암호화나 내용 검증을 하지 않아 주로 로컬 환경이나 사내망에서 쓰였고, HTTP 프록시도 마찬가지로 주로 브라우저용이었습니다. 두 프로토콜은 지금도 Clash 계열 설정에 남아 있지만 역할은 인바운드입니다. 즉 로컬 앱이 클라이언트가 열어둔 포트에 연결하는 용도이며, 원격 서버로 나가는 아웃바운드 용도가 아닙니다. 설정의 mixed-port는 SOCKS5와 HTTP 두 가지 인바운드를 동시에 제공하는 혼합 포트이고, allow-lan은 같은 네트워크 내 다른 기기의 접속 허용 여부를 결정합니다.

# 로컬 인바운드 설정(앱이 클라이언트에 연결할 때 사용, 노드 설정이 아님)
mixed-port: 7890
allow-lan: false
mode: rule

전용 프로토콜의 세 번의 전환점

원격 서버를 향한 전용 프록시 프로토콜은 대략 세 번의 설계 전환을 거쳤습니다. 첫 번째 전환에서 Shadowsocks가 「가볍게 암호화한 스트림」이라는 방향을 확립했습니다. 페이로드만 암호화하고 불필요한 구조를 더하지 않아 네 가지 값만으로 동작합니다. 두 번째 전환에서 VMess는 「기능 우선」 노선을 택했습니다. 타임스탬프 검증, 다중 전송 계층, 프로토콜 자체 암호화까지 모두 넣었고, 기능은 강력해졌지만 구조도 무거워졌습니다. 세 번째 전환은 두 방향으로 갈렸습니다. Trojan과 VLESS는 암호화를 TLS에 맡겨 트래픽이 겉보기에 일반 HTTPS와 비슷하게 보이도록 했고, Hysteria2와 TUIC는 UDP 위의 QUIC로 전환해 열악한 네트워크에서의 처리량과 네트워크 전환 시 연결 유지를 확보했습니다.

여섯 가지가 공존하는 지금

지금도 구독에서 가장 흔히 보이는 것은 여섯 가지, 즉 SS, VMess, Trojan, VLESS, Hysteria2, TUIC입니다. 모든 면에서 앞서는 프로토콜은 없습니다. 오버헤드가 작은 쪽은 위장 능력이 상대적으로 약하고, 위장에 강한 쪽은 도메인과 인증서에 의존하며, 속도가 빠른 쪽은 UDP 환경에 의존합니다. 프로토콜 간 관계는 대체가 아니라 트레이드오프이며, 바로 이 때문에 선택 가이드가 필요합니다.

R-03Shadowsocks(SS): 가볍게 암호화한 스트림

등장 배경과 설계 목표

SS는 2012년 전후로 등장했으며 설계 목표가 극도로 절제되어 있습니다. SOCKS5의 전달 구조 위에 스트림 암호화 계층만 추가해 전송 중 데이터를 읽을 수 없게 만들었을 뿐, 그 외에는 어떤 구조도 더하지 않았습니다. SS 노드 하나에 필요한 정보는 서버 주소, 포트, 비밀번호, 암호화 방식 네 가지뿐입니다. 동작 가능한 SS 클라이언트를 코드 몇백 줄로 구현할 수 있다는 점이 빠르게 확산되고 거의 모든 코어와 클라이언트에서 지원되는 직접적인 이유입니다.

AEAD 암호화와 현재 사용법

초기 SS는 스트림 암호(aes-256-cfb 등)를 썼지만 능동 탐지가 가능한 약점이 밝혀져 커뮤니티가 AEAD(추가 데이터 인증 암호화)를 도입했습니다. 현재 흔히 쓰이는 세 가지 알고리즘은 aes-128-gcm, aes-256-gcm, chacha20-ietf-poly1305입니다. 데스크톱 CPU는 대부분 AES 하드웨어 명령어를 지원해 두 AES-GCM 방식이 거의 부담 없이 동작하지만, 대부분의 모바일 SoC에는 해당 명령어가 없어 모바일에서는 chacha20-ietf-poly1305가 더 빠르고 배터리도 덜 소모합니다. SS는 UDP 전달(설정의 udp 항목)도 지원하지만 서버 측에서 함께 활성화해야 합니다.

proxies:
  - name: "예시 노드-SS"
    type: ss
    server: example.com
    port: 8388
    cipher: chacha20-ietf-poly1305
    password: "your-password"
    udp: true

적합한 상황과 한계

SS의 장점은 공학적인 부분에 집중됩니다. 여섯 프로토콜 중 오버헤드가 가장 작고, 구현이 성숙하며, 거의 모든 코어에서 지원하고, 모바일 배터리 효율이 가장 좋습니다. 한계도 분명합니다. 프로토콜 자체에 위장 계층이 없어 트래픽 특징이 상대적으로 고정적이며, 암호화만 정의할 뿐 신원이나 인증서는 다루지 않아 서버의 신뢰성은 운영자에게 의존합니다. 일상용 범용 프로토콜로서 SS는 지금도 안정적인 기본 선택이며, 구형 기기나 라우터에서는 우선 고려 대상입니다.

R-04VMess: 기능 우선의 일체형 설계

설계 배경

VMess는 V2Ray 프로젝트의 자체 프로토콜로, 설계 방향이 SS와는 정반대입니다. 신원 인증, 시간 검증, 암호화, 전송 위장까지 모두 프로토콜 자체에 포함시켰습니다. 요청마다 타임스탬프를 실어 서버 시간과 차이가 크면 즉시 거부해 프로토콜 계층에서 재전송 공격을 막고, UUID를 사용자 식별자로 써서 하나의 서버가 여러 독립 사용자를 수용하고 각각 통계를 낼 수 있습니다.

전송 계층과 구조적 오버헤드

VMess는 TCP, WebSocket, gRPC 등 다양한 전송 계층을 지원합니다. WebSocket 형태는 프록시 트래픽을 일반 웹 서비스 구조에 감쌀 수 있어 CDN 경유와 함께 흔히 쓰이고, gRPC 형태는 HTTP/2의 다중화를 빌려 씁니다. 기능이 완전한 대신 구조가 복잡해지는 대가가 있어, 핸드셰이크 과정이 길고 여섯 프로토콜 중 헤더 오버헤드가 가장 큽니다. 구현 난이도도 높습니다. 또한 VMess는 자체 암호화를 포함하는데 여기에 TLS를 덧씌우면 이중 암호화가 되어 CPU 사용량이 눈에 띄게 늘어나는 반면 보안상 얻는 이득은 제한적입니다.

현재 상황

VMess는 기존 구독에서 여전히 흔히 볼 수 있으며 mihomo는 각 전송 계층 형태를 온전히 지원합니다. 새로 구축되는 서버는 구조가 더 가벼운 VLESS로 점차 옮겨가면서 VMess는 서서히 구형 설정으로 밀려나고 있습니다. 클라이언트 쪽에서는 일부러 피할 필요는 없습니다. 노드가 연결되고 속도가 기준을 만족하면 프로토콜의 신구 여부는 교체 이유가 되지 않습니다. 설정을 직접 관리할 때는 alterId 항목에 유의하세요. 최신 서버와 코어는 이 값을 0으로 고정했으며, 예전 가이드에 나오는 0이 아닌 값은 더 이상 적용되지 않습니다.

proxies:
  - name: "예시 노드-VMess"
    type: vmess
    server: example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    network: ws
    ws-opts:
      path: /ray

R-05Trojan과 VLESS: TLS 위장 노선

공통된 방향: 암호화를 직접 설계하지 않음

Trojan과 VLESS는 같은 노선에 속합니다. 프로토콜 계층에서 암호화를 구현하지 않고 TLS, 즉 HTTPS가 쓰는 보안 계층을 그대로 빌려 씁니다. 서버는 실제 도메인과 유효한 인증서를 갖고 있고, 클라이언트와 서버 사이에는 표준 TLS 연결이 맺어져 핸드셰이크, 암호화, 인증서 검증이 모두 성숙한 구현을 그대로 따르므로 외부에서 관찰하면 일반 HTTPS 사이트 접속과 거의 구분되지 않습니다. mihomo는 client-fingerprint 항목(예: chrome)도 지원해 uTLS로 지정 브라우저의 TLS 지문을 모방함으로써 핸드셰이크 특징을 실제 브라우저와 더 가깝게 만듭니다.

Trojan: 극도로 단순한 구조

Trojan은 「프로토콜이 없다」에 가까운 설계입니다. TLS 핸드셰이크가 끝나면 클라이언트가 세션 안에서 비밀번호의 해시값을 보내 인증을 마치고, 이후 데이터는 그대로 전달됩니다. 프로토콜 자체 구조가 적을수록 동작이 일반 HTTPS에 가까워지고 오버헤드도 줄어듭니다. 설정에는 도메인, 포트, 비밀번호 세 가지만 필요하며 sni 항목은 보통 도메인과 일치시킵니다.

VLESS: VMess를 가볍게 다시 쓴 버전

VLESS는 VMess를 단순화해 새로 작성한 것으로, 프로토콜 계층 암호화와 타임스탬프를 제거하고 UUID 신원 확인만 남기며 암호화는 전부 외부 TLS에 맡깁니다. 구조는 VMess보다 훨씬 가볍고 헤더 오버헤드는 Trojan과 같은 수준이며, XTLS 같은 전송 최적화와 함께 쓰면 코어와 TLS 라이브러리 사이의 데이터 복사가 한 번 줄어 고대역폭 상황에서 처리량이 더 좋습니다. 강조할 점은 VLESS는 반드시 TLS와 함께 써야 한다는 것입니다. 평문 형태의 VLESS는 의미가 없고 정상적인 구독에도 등장해서는 안 됩니다.

공통 전제: 도메인과 인증서

TLS 노선은 실제 도메인과 유효한 인증서에 의존하며, 이 때문에 대부분 자체 구축이거나 관리가 비교적 체계적인 서버에서 채택됩니다. 클라이언트 측에서 유의할 점은 한 가지뿐입니다. 노드의 sni(또는 servername) 항목이 인증서 도메인과 일치해야 하며, 일치하지 않으면 핸드셰이크가 즉시 실패합니다. 구독으로 불러온 노드는 이 항목이 이미 설정되어 있으므로 직접 노드를 추가하거나 수정할 때만 주의하면 됩니다.

proxies:
  - name: "예시 노드-Trojan"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    udp: true
  - name: "예시 노드-VLESS"
    type: vless
    server: example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    tls: true
    servername: example.com
    client-fingerprint: chrome

R-06Hysteria2와 TUIC: QUIC 기반 UDP 노선

QUIC이 가져온 변화

QUIC은 UDP 위에 구축된 현대적인 전송 프로토콜이며 HTTP/3의 기반이기도 합니다. 암호화, 혼잡 제어, 다중화를 전송 계층에 통합해 핸드셰이크는 보통 한 번의 왕복으로 끝나고 0-RTT 세션 재개를 지원합니다. 연결은 소스 주소 4-튜플이 아니라 연결 식별자로 유지되므로 Wi-Fi에서 셀룰러로 전환해도 세션을 다시 맺지 않고 이어갈 수 있습니다. Hysteria2와 TUIC 모두 QUIC을 기반으로 하지만 방향성이 다릅니다.

Hysteria2: 대역폭을 적극적으로 점유하는 혼잡 제어

Hysteria2의 핵심은 Brutal이라는 자체 혼잡 제어 방식입니다. 전통적인 방식처럼 가용 대역폭을 탐색하는 대신 설정된 목표 대역폭에 맞춰 적극적으로 패킷을 보냅니다. 손실률과 지연이 높은 회선에서는 이 방식이 어떤 TCP 계열 프로토콜보다도 뚜렷하게 높은 처리량을 냅니다. TCP 계열은 손실이 생기면 지수적으로 속도를 줄이지만 Brutal은 물러서지 않습니다. 대가도 분명합니다. 패킷 전송이 공격적이라 서버 대역폭에 요구 조건이 있으며, 설정의 up과 down 값은 실제 회선에 가깝게 맞춰야 합니다. 너무 높거나 낮게 설정하면 실제 속도가 오히려 떨어집니다. 이 프로토콜은 포트 호핑(지정한 포트 구간 내에서 순환)도 지원해 단일 포트 제한을 피하는 데 쓰이며, mihomo에서는 ports 항목으로 설정합니다.

TUIC: 다중화와 저지연

TUIC의 설계 목표는 저지연과 낮은 오버헤드입니다. 여러 TCP 연결을 하나의 QUIC 세션에 다중화해 앱이 새 연결을 열 때마다 다시 핸드셰이크할 필요가 없습니다. UDP 릴레이를 기본으로 지원해 게임, 음성 통화처럼 지연에 민감한 트래픽이 직접적인 혜택을 봅니다. 혼잡 제어는 QUIC 표준 알고리즘 계열을 따르므로 Hysteria2보다 동작이 온화하고 회선에 대한 부담도 적어 대역폭이 크지 않은 서버에도 더 적합합니다.

UDP 노선의 한계

두 프로토콜 모두 UDP 통신이 가능해야 동작합니다. 일부 네트워크 환경은 UDP를 제한하거나 완전히 차단하는데, 이 경우 두 프로토콜은 바로 쓸 수 없거나 속도가 급격히 떨어지며 클라이언트로는 이 제한을 우회할 수 없어 TCP 계열 프로토콜로 돌아가는 것이 유일한 방법입니다. 또 한 가지는 리소스입니다. QUIC의 암호화, 재전송, 혼잡 제어가 모두 사용자 영역에서 처리되어 순수 TCP 프로토콜보다 CPU 사용량이 높으며, 장시간 대용량 다운로드 시 모바일 기기의 발열과 배터리 소모 차이가 체감될 수 있습니다.

proxies:
  - name: "예시 노드-Hysteria2"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    up: 50
    down: 200
  - name: "예시 노드-TUIC"
    type: tuic
    server: example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    password: "your-password"
    alpn: [h3]

R-07비교 분석: 속도, 리소스, 배터리

연결 수립

TCP 계열 프로토콜(SS, VMess, Trojan, VLESS)은 먼저 TCP 핸드셰이크를 마치고, TLS를 쓰는 경우 TLS 핸드셰이크가 하나 더 붙어 첫 연결 수립에 보통 한두 번에서 세 번의 왕복이 필요합니다. QUIC 계열은 전송과 암호화 핸드셰이크를 합쳐 보통 한 번의 왕복이면 되고 세션 재개는 0-RTT로도 가능합니다. 일상적인 웹 서핑에서는 체감 차이가 크지 않지만, 짧은 연결이 잦은 시나리오, 예를 들어 피드 새로고침이나 API 호출이 빈번한 앱에서는 QUIC 계열이 유리합니다.

처리량과 오버헤드

프로토콜 헤더 오버헤드는 작은 순서로 대략 SS < Trojan ≈ VLESS < VMess이며, QUIC 계열은 헤더 자체는 작지 않지만 다중화로 핸드셰이크 비용이 분산되어 실제 처리량은 혼잡 제어 방식에 더 크게 좌우됩니다. 같은 회선에서 손실률이 낮고 안정적일 때는 SS, Trojan, VLESS 간 차이가 크지 않지만, 손실률이 높을 때는 Hysteria2가 처리량이 가장 높고 TUIC가 그다음이며 TCP 계열 프로토콜은 전체적으로 눈에 띄게 뒤처집니다.

CPU와 메모리

데스크톱(Windows, macOS, Linux)에서는 여섯 프로토콜 모두 CPU 사용량이 무시할 만한 수준이라 성능을 선택 기준으로 삼을 필요가 없습니다. 모바일은 다릅니다. 스마트폰 SoC의 저전력 코어에서는 AES와 ChaCha20의 전력 효율 차이가 뚜렷하고, QUIC의 사용자 영역 재전송과 혼잡 제어는 CPU를 계속 소비합니다. 메모리 사용량은 프로토콜 간 차이가 크지 않으며, 코어 전체의 메모리 점유는 주로 규칙 수와 활성 연결 수에 좌우되고 프로토콜 종류와는 관계가 적습니다.

모바일 배터리 소모

같은 트래픽량에서의 상대적인 배터리 소모는 적게 쓰는 순서로 대략 SS(chacha20-ietf-poly1305) < Trojan ≈ VLESS < VMess < TUIC < Hysteria2입니다. 푸시 알림이나 메신저처럼 백그라운드 중심 사용에서는 프로토콜 간 차이가 크지 않지만, 연속적인 동영상 재생이나 대용량 다운로드에서는 차이가 체감되기 시작합니다. iOS의 Clash Plus와 Android 각 클라이언트는 동일한 mihomo 코어를 쓰므로 위 결론은 플랫폼과 무관하게 동일합니다. iOS에서의 설치와 설정 과정은 기술 노트를 참고하세요(아이폰에서 Clash 쓰는 방법).

제대로 속도 측정하는 법

선택 전에는 같은 시간대, 같은 목적지, 같은 기기 기준으로 통일해서 측정하는 것을 권장합니다. 클라이언트 측정으로 얻는 값은 지연이며 핸드셰이크와 왕복 비용을 반영하고, 처리량은 실제 다운로드로 검증해야 합니다. 단일 연결 다운로드는 프로토콜 오버헤드 영향을 크게 받고 다중 연결 다운로드는 혼잡 제어 영향을 크게 받으므로 두 값을 모두 확인하는 것이 지연만 보는 것보다 신뢰할 수 있습니다.

R-08코어 계보: Clash, Clash Meta, mihomo

원조 Clash의 역사적 위치

원조 Clash 코어는 2023년 유지보수가 중단되고 저장소가 보관 처리되었습니다. SS, VMess, Trojan 같은 초기 프로토콜은 지원하지만 VLESS, Hysteria2, TUIC은 인식하지 못합니다. 원조 버전에는 비공개 강화판인 Clash Premium도 있었는데 TUN과 스크립트 기능을 제공했지만 마찬가지로 유지보수가 중단되었습니다. Clash for Windows나 ClashX Meta처럼 업데이트가 멈춘 클라이언트를 여전히 쓰고 있다면, 실제로 돌아가는 것은 이 시대의 코어나 그 초기 분기입니다. 기존 노드는 연결되지만 새 프로토콜이나 새 기능은 추가되지 않고, 구독 안의 신규 프로토콜 노드는 그대로 무시됩니다.

Meta에서 mihomo로: 계승과 확장

Clash Meta는 커뮤니티가 원조 버전을 기반으로 활발히 개발한 분기이며 2023년 말 mihomo로 이름을 바꿨습니다. 원조의 YAML 설정 형식을 그대로 계승하면서 VLESS, Hysteria2, TUIC 지원을 추가하고, TUN 모드 강화, 규칙 제공자(rule-providers), 외부 컨트롤러 확장 같은 기능을 더했습니다. TUN 모드는 가상 네트워크 카드로 전체 트래픽을 가져오는 방식인데, 원리와 활성화 방법은 기술 노트에 별도로 정리되어 있습니다(Clash TUN 모드란 무엇인가). 다운로드 페이지에서 유지보수 중인 클라이언트인 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu는 모두 mihomo를 코어로 내장하고 있습니다.

설정 호환성

호환은 한 방향으로만 이루어집니다. mihomo는 원조 Clash의 예전 설정을 그대로 실행할 수 있지만 반대는 성립하지 않습니다. 새 프로토콜 노드나 새 항목(rule-providers 등)이 들어간 설정은 원조 코어에서 파싱에 실패합니다. 구독 변환 도구는 보통 「Clash」와 「Clash Meta」 두 가지 출력 형식을 제공하는데, mihomo 클라이언트를 쓴다면 Meta 출력을 선택해야 합니다. 잘못 선택해 예전 형식이 되면 신규 프로토콜 노드가 변환 단계에서 누락되어 「구독에는 분명 있는 노드인데 불러오면 안 보인다」는 현상이 나타납니다.

R-09구독 형식과 상황별 선택 가이드

구독 형식의 세 가지 형태

구독 링크가 반환하는 내용은 보통 세 가지 형태로 나뉩니다. 첫째는 Base64 노드 목록으로, 한 줄에 하나씩 ss://나 vmess:// 공유 링크가 들어 있어 범용성이 가장 좋지만 Clash의 정책 그룹이나 규칙 구조는 포함하지 않으므로 불러온 뒤 클라이언트가 스스로 구성해야 합니다. 둘째는 Clash YAML로, proxies, proxy-groups, rules 세 부분을 포함한 완전한 설정이라 불러오면 바로 쓸 수 있으며 mihomo 클라이언트에서 가장 선호되는 형태입니다. 셋째는 온라인 구독 변환의 출력으로, Base64 목록을 Clash YAML로 바꿔주어 예전 구독도 완전한 구조를 얻을 수 있지만 변환 서비스가 노드 정보를 그대로 볼 수 있으므로 신뢰도를 따져봐야 합니다. 구독을 받고 불러오는 자세한 방법은 기술 노트에 별도로 정리되어 있습니다(Clash 구독 링크 불러오는 방법).

사용 시나리오별 선택 가이드

• 일상적인 웹 서핑과 동영상: SS 또는 Trojan, VLESS. 오버헤드가 작고 배터리에 우호적이며 데스크톱과 모바일 모두 적합합니다.
• 고손실 회선: Hysteria2. 대륙 간 회선이나 저녁 혼잡 시간대에서 처리량 우위가 가장 뚜렷하며, 사용 중인 네트워크가 UDP를 제한하지 않아야 합니다.
• 게임과 음성 통화: TUIC 또는 Hysteria2. UDP 릴레이 지연이 낮으며, 클라이언트에서 UDP 전달이 켜져 있는지도 함께 확인하세요.
• 네트워크 전환이 잦은 환경: QUIC 계열 프로토콜. 네트워크가 바뀌어도 연결이 유지되어 이동 중 끊김이 눈에 띄게 줄어듭니다.
• 구형 기기와 라우터: SS. CPU 사용량이 가장 낮고 구현이 가장 성숙해 장시간 안정적으로 돌릴 수 있습니다.

흔히 하는 세 가지 오해

「프로토콜이 최신일수록 빠르다」는 사실이 아닙니다. 속도는 회선 품질과 혼잡 제어에 좌우되며 발표 시기와는 무관해, 안정적인 회선에서는 SS와 최신 프로토콜의 차이가 크지 않습니다. 「암호화 계층이 많을수록 안전하다」도 사실이 아닙니다. VMess에 TLS를 덧씌우는 이중 암호화는 CPU 부담만 늘릴 뿐 안전성은 가장 바깥 계층이 결정합니다. 「클라이언트를 바꾸면 프로토콜 성능도 달라진다」 역시 사실이 아닙니다. 같은 코어에서는 프로토콜 동작이 동일하며 클라이언트는 조작 경험에만 영향을 줍니다. 클라이언트 간 차이 비교는 기술 노트를 참고하세요(주요 클라이언트 비교 가이드).

마무리: 4단계 선택 흐름

1. 클라이언트 코어가 mihomo인지 확인합니다(다운로드 페이지의 유지보수 중인 클라이언트는 모두 해당됩니다).
2. 구독을 불러오고 프로토콜 종류별로 노드 목록을 살펴봅니다.
3. 주로 쓰는 네트워크에서 후보 프로토콜을 각각 한 번씩 측정해 지연과 처리량을 모두 확인합니다.
4. 실측 결과가 가장 좋은 종류를 정책 그룹의 기본값으로 설정하고 나머지는 백업으로 남겨둡니다.

프로토콜 관련 내용은 여기까지입니다. 구독 불러오기, 모드 선택, 시스템 프록시 켜기, 연결 확인 같은 나머지 작업은 사용 가이드의 단계를 따라 진행하세요. 클라이언트 다운로드가 필요하면 다운로드 페이지로, 모르는 용어가 나오면 용어집을 확인하세요.