▶프로토콜 상세 정리: 6가지 프로토콜과 3세대 커널 선택 가이드

프로토콜 전체 지도: 6가지 주류 프로토콜은 어디서 왔고 무엇을 해결하는가

먼저 큰 흐름을 기억해두세요. 프록시 프로토콜의 진화 과정은 곧 "암호화, 위장, 속도라는 세 가지 사이에서 균형을 찾아온" 역사입니다. 클라이언트 구독에서 흔히 보이는 6가지 프로토콜—Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC—은 세 세대로 나뉘며, 각 세대는 이전 세대의 약점에 대한 직접적인 대응입니다. 각자의 출발점을 이해하고 나면 이후의 모든 비교표를 훨씬 쉽게 읽을 수 있습니다.

Shadowsocks: 경량 암호화의 시작점

Shadowsocks(약칭 SS)는 6가지 프로토콜 중 가장 오래된 것입니다. 설계 목표는 한 문장으로 정리됩니다. 가능한 적은 오버헤드로 TCP 트래픽에 대칭 암호화를 씌우는 것입니다. 별도의 핸드셰이크 협상이나 세션 개념 없이, 클라이언트와 서버가 사전에 동일한 비밀번호와 암호화 방식을 약속해두고 연결이 성립되면 곧바로 암호문을 전송합니다. 장점은 즉각적입니다. 구현이 매우 단순하고 CPU 사용량이 낮으며 거의 모든 플랫폼에 성숙한 구현체가 존재합니다. 대가도 분명합니다. 트래픽 특징이 비교적 고정적이어서 메타데이터 수준의 위장 능력이 부족합니다. 이후 커뮤니티가 AEAD 암호화 스위트(aes-128-gcm, chacha20-ietf-poly1305 등)를 추가해 초기 스트림 암호화의 무결성 결함을 해결했고, 이것이 오늘날 설정에서 AEAD 방식만 권장하는 이유입니다.

VMess와 VLESS: 세션 계층을 가진 두 세대의 프로토콜

VMess는 V2Ray 프로젝트에서 나왔으며 SS보다 한 단계 더 나아간 방식을 취합니다. 사용자 ID(UUID), 타임스탬프 검증, 동적 메타데이터를 도입해 매 연결마다 헤더가 달라지고, WebSocket, gRPC 등 다양한 전송 계층을 얹을 수 있습니다. 유연함이 최대 장점이지만 복잡함도 최대 부담입니다. 프로토콜 헤더 계산량이 크고, 타임스탬프 메커니즘 때문에 클라이언트와 서버의 시계 오차가 너무 크면 연결이 되지 않는데, 휴대폰 시간이 맞지 않아 연결이 안 되는 것은 VMess의 전형적인 오류입니다. VLESS는 같은 커뮤니티가 VMess를 "가볍게 만든" 버전입니다. 내장 암호화와 타임스탬프 검증을 없애고 암호화 책임을 전부 하위 TLS에 위임하며, 프로토콜 본체는 신원 식별과 라우팅 정보만 남깁니다. 결과적으로 헤더가 작아지고 전달 속도가 빨라지지만, 반드시 TLS(또는 REALITY 같은 파생 방식)와 함께 사용해야 하며 TLS 없는 VLESS는 아무런 기밀성도 갖지 못합니다.

Trojan: HTTPS 인파 속에 자신을 숨기는 방식

Trojan은 방향을 바꿨습니다. 새로운 암호화 형식을 만드는 대신, 프록시 트래픽이 외형상 일반 HTTPS와 완전히 동일하게 보이도록 만드는 것입니다. 표준 TLS 핸드셰이크를 그대로 재사용하고 서버에는 실제 인증서를 설정하며, 검증에 실패한 접속은 일반 웹사이트로 되돌려집니다. 관찰자 입장에서는 Trojan 연결과 정상적인 웹 브라우징을 구분할 수 없습니다. 그만큼 설계상의 대가도 따릅니다. 도메인과 유효한 인증서가 반드시 필요해 배포 난이도가 SS보다 높고, 모든 트래픽이 완전한 TLS를 거치므로 단일 코어 암복호화 처리량은 경량 프로토콜보다 다소 낮지만, 그 대가로 가장 안정적인 "배경 속으로의 위장" 능력을 얻습니다.

Hysteria2와 TUIC: QUIC 세대의 속도파

앞의 네 프로토콜은 모두 TCP 위에서 동작하며 TCP의 혼잡 제어와 헤드 오브 라인 블로킹의 제약을 받습니다. 패킷 하나만 손실돼도 연결 전체가 재전송을 기다려야 합니다. Hysteria2와 TUIC는 기반을 UDP 기반의 QUIC로 바꿨습니다. Hysteria2의 핵심은 자체적인 공격적 혼잡 제어 전략으로, 손실률과 지연이 높은 장거리 링크를 겨냥해 열악한 네트워크 환경에서 처리량이 눈에 띄게 향상됩니다. TUIC는 더 "표준을 따르는" 편으로, QUIC 규격에 최대한 밀착해 멀티플렉싱과 0-RTT 빠른 핸드셰이크를 구현하며 저지연을 추구하면서도 프로토콜 동작을 온화하게 유지합니다. 두 프로토콜의 공통된 약점은 일부 네트워크가 UDP에 속도 제한이나 차단 정책을 두는 경우, QUIC 계열 프로토콜이 오히려 얌전한 TCP 계열보다 불안정해질 수 있다는 점입니다. 그래서 이들은 "선택적 가속 옵션"이지 무조건 기본값으로 삼을 대상은 아닙니다.

전송 계층 설계의 선택: TCP, TLS, QUIC 세 갈래 노선

프로토콜 비교는 흔히 "어느 것이 빠른가"로 단순화되지만, 실제 체감 속도를 결정하는 첫 번째 변수는 전송 계층 노선입니다. 6가지 프로토콜을 기반에 따라 세 계열로 나누면 많은 현상이 한꺼번에 설명됩니다.

TCP 직결파: SS와 경량 VMess

SS와 TLS를 얹지 않은 VMess는 TCP 위에서 곧바로 자체 암호문을 전송합니다. 장점은 호환성이 가장 뛰어나 TCP를 허용하는 어떤 네트워크에서도 동작하고, 구현이 가벼워 오래된 기기나 라우터에서도 충분히 돌아간다는 점입니다. 단점은 자체 암호문 자체가 하나의 특징이 되며, 손실이 있는 링크에서는 TCP 헤드 오브 라인 블로킹이 체감 속도를 크게 떨어뜨린다는 점입니다. 지연 수치는 나쁘지 않아 보여도 웹페이지 로딩이 끊기듯 진행되는데, 이는 지연 테스트 수치 읽는 법에서 다룬 "수치는 좋아도 체감은 나쁜" 대표적인 원인 중 하나입니다.

TLS 캡슐화파: Trojan, VLESS, WebSocket을 얹은 VMess

이 계열은 트래픽을 표준 TLS 세션 안에 담습니다. 외형이 일반 HTTPS와 동일해 각종 중간 장비를 통과하는 성공률이 가장 높고, CDN 경유(VMess/VLESS + WebSocket 조합에서 흔함)를 함께 쓰면 서버의 실제 주소도 숨길 수 있습니다. 대가는 핸드셰이크 라운드가 많다는 점입니다. TCP 3-way handshake에 TLS 핸드셰이크가 더해져 첫 패킷 지연이 직결파보다 자연히 높고, 모든 바이트가 TLS 암복호화를 한 번씩 거치므로 처리량 상한이 CPU 단일 코어 성능에 뚜렷하게 좌우됩니다.

QUIC파: Hysteria2와 TUIC

QUIC는 암호화 핸드셰이크와 전송 핸드셰이크를 합쳐, 이상적인 경우 한 번의 왕복으로 연결이 성립하고 0-RTT를 지원하면 그보다도 빠릅니다. 스트림 단위 멀티플렉싱이 헤드 오브 라인 블로킹을 완전히 회피해 하나의 스트림에서 발생한 손실이 다른 스트림에 영향을 주지 않습니다. 모바일 네트워크 전환(Wi-Fi에서 5G로) 시에도 QUIC의 연결 마이그레이션 능력 덕분에 재연결이 더 매끄럽습니다. 약점은 앞서 언급한 대로 UDP가 일부 네트워크에서 "이등 시민"으로 취급되어 속도 제한을 받으면 성능이 급격히 떨어진다는 점입니다.

연결 속도와 리소스 사용: 수치 뒤에 숨은 규칙

결론부터 말하면, 같은 서버·같은 회선에서 6가지 프로토콜의 "최대 대역폭" 차이는 보통 회선 자체의 변동보다 작습니다. 체감 격차를 실제로 벌리는 것은 첫 패킷 지연, 손실 복구, CPU 병목 이 세 가지입니다. 하나씩 살펴봅니다.

첫 패킷 지연: 핸드셰이크 라운드가 하한선을 결정

새 웹사이트를 열면 클라이언트는 먼저 프록시 서버와 연결을 맺어야 합니다. SS는 TCP 3-way handshake만으로 데이터를 보낼 수 있어 라운드가 가장 적고, Trojan/VLESS는 TCP 위에 TLS 핸드셰이크를 추가로 완료해야 해 한두 번의 왕복이 더 필요합니다. Hysteria2/TUIC는 QUIC로 두 단계를 합쳐 장거리 링크에서 이점이 뚜렷하며, TUIC의 0-RTT는 같은 서버에 재접속할 때 "보내는 즉시 데이터를 실어 나르는" 수준까지 가능합니다. 링크 지연이 50ms일 때는 이 차이가 잘 느껴지지 않지만, 지연이 200ms를 넘으면 왕복 하나를 줄이는 것만으로도 눈에 보이는 속도 향상이 나타납니다.

처리량과 CPU: 암호화 경로의 대가

최대 속도로 다운로드할 때 병목은 회선이 아니라 암복호화인 경우가 많습니다. AEAD 스위트를 쓴 SS는 바이트당 오버헤드가 가장 낮아 오래된 라우터도 회선 속도에 근접할 수 있습니다. Trojan/VLESS의 TLS 경로는 AES-NI 명령어 세트를 지원하는 최신 CPU에서는 오버헤드가 관리 가능한 수준이지만, 저가형 ARM 기기에서는 대역폭보다 먼저 한계에 도달합니다. QUIC 계열 프로토콜은 현재 대부분 사용자 공간에서 구현되어 같은 처리량에서도 커널 공간 최적화가 성숙한 TCP 스택보다 CPU 점유율이 대체로 높은데, 이것이 "Hysteria2는 속도는 빠른데 발열도 빠른" 이유입니다. 데스크톱 환경에서는 대체로 무감각하지만, 소프트웨어 라우터와 셋톱박스에서는 신중하게 고려해야 합니다.

손실 복구: 열악한 네트워크에서 갈리는 갈래

손실률이 1%를 넘는 링크에서는 TCP 계열 프로토콜의 처리량이 혼잡 제어 알고리즘에 의해 크게 억제되며, 같은 연결을 공유하는 모든 요청이 함께 막힙니다. Hysteria2의 공격적 보상 전략은 이런 환경에서 가용 대역폭을 몇 배로 끌어올리는 경우가 많고, TUIC의 스트림 격리도 "하나의 요청이 막혀도 다른 요청에 영향을 주지 않는" 것을 보장합니다. 반대로 손실률이 낮은 양질의 링크에서는 세 계열의 실제 속도 차이는 무시할 만하므로, 이때는 벤치마크가 아니라 위장 능력과 호환성을 기준으로 프로토콜을 선택해야 합니다.

모바일 배터리 소모: 프로토콜이 배터리에 미치는 영향

휴대폰에 클라이언트를 켜둔 채 밤새 배터리가 빠진다면 프로토콜 선택도 변수 중 하나지만 대개 가장 큰 변수는 아닙니다. 이 장에서는 "프로토콜과 관련된" 배터리 소모 요인만 따로 짚어보고, 시스템 차원의 점검(절전 화이트리스트, 백그라운드 정책, 프로브 간격)은 블로그의 안드로이드 배터리 소모 점검 체크리스트를 참고하세요.

무선 모듈 웨이크업: 작은 패킷 빈도가 숨은 주범

모바일 칩의 베이스밴드에는 "슬립—웨이크업" 상태 머신이 있어, 데이터를 주고받을 때마다 베이스밴드를 저전력 상태에서 끌어올릴 수 있고, 끌어올린 뒤에는 한동안 고전력 상태를 유지합니다. 그래서 배터리 소모는 전체 트래픽량과는 크게 상관없고, "패킷이 얼마나 자주 오는가"와 깊이 연관됩니다. 프로토콜 또는 그 상위 구현의 하트비트, 킵얼라이브, 프로브가 빈번할수록 베이스밴드가 잠들기 어려워지고, 밤새 대기 상태에서 소모되는 배터리도 더 늘어납니다.

세 계열 프로토콜의 배터리 소모 프로필

TCP 계열 프로토콜은 자체적으로 강제 하트비트가 없어 연결이 조용할 때는 추가 웨이크업이 거의 발생하지 않아 대기 상태에 유리합니다. 주의할 점은 WebSocket을 얹은 VMess/VLESS로, 일부 서버가 주기적인 ping 프레임을 설정해두는 경우 간격이 너무 짧으면 전형적인 "배터리 킬러"가 됩니다. QUIC 계열 프로토콜은 NAT 매핑과 연결 마이그레이션 능력을 유지하기 위해 대개 내장 킵얼라이브 프로브를 가지고 있어, 조용한 상태에서의 웨이크업 횟수가 태생적으로 TCP 계열보다 많습니다. 그 대가로 얻는 이점은 네트워크 전환 시 재연결을 처음부터 다시 할 필요가 없다는 점이며, Wi-Fi와 셀룰러를 자주 오가는 통근 상황에서는 한 번의 완전한 재연결(재핸드셰이크, 재프로브)이 몇 번의 킵얼라이브보다 배터리를 더 많이 소모할 수 있습니다. 그래서 결론은 한쪽으로 쏠리지 않습니다. 이동이 잦은 사용자는 QUIC 계열이 오히려 더 절전일 수 있고, 하나의 네트워크에 오래 머무는 사용자는 TCP 계열이 더 안정적입니다.

실천 가능한 절전 원칙

• 대기 위주 기기: SS나 Trojan을 우선하고, 하트비트 간격이 공격적인 WebSocket 설정은 피하세요.
• 통근 시 네트워크 전환이 빈번한 경우: TUIC나 Hysteria2를 시도해 연결 마이그레이션으로 재핸드셰이크를 줄여보세요.
• 어떤 프로토콜이든: 정책 그룹의 자동 속도 측정 간격을 10분 이상으로 늘리세요. 프로브 자체도 웨이크업 원인입니다.
• TUN 모드를 상시 켜두면 전체 트래픽을 가로채므로, 일부 앱만 프록시할 때보다 배터리 소모가 높은 것은 정상이니 필요할 때만 켜세요.

커널 계보: 오리지널, Meta, mihomo는 어떤 관계인가

먼저 한 문장으로 정리하겠습니다. 이 세 이름은 세 개의 경쟁 제품이 아니라 하나의 진화 선상에 있는 세 단계입니다. 계보를 정확히 이해하면 클라이언트 선택과 설정 호환성 문제가 크게 줄어듭니다. 더 완전한 타임라인은 블로그의 커널 계보 비교에서 확인할 수 있습니다.

오리지널 커널: 규칙 기반 분기 방식의 기초를 세운 존재

최초의 Clash 커널은 오늘날 모든 파생 버전이 따르는 골격을 확립했습니다. YAML 설정, proxies 노드 목록, proxy-groups 정책 그룹, rules 규칙 섹션, 그리고 "도메인과 IP 규칙으로 트래픽 경로를 결정하는" 분기 방식입니다. 당시 주류였던 SS, VMess, Trojan 등을 네이티브로 지원했지만, 이후 등장한 VLESS, Hysteria2, TUIC는 지원하지 않습니다. 원본 저장소는 이미 업데이트가 중단되어 오리지널 커널은 이제 "역사적 단계"에 속하며, 신규 사용자가 이를 중심으로 환경을 구성하는 것은 권장하지 않습니다.

Meta 브랜치: 커뮤니티가 이어받은 기능 확장판

오리지널이 활발히 운영되던 시기, 커뮤니티가 관리하는 Clash.Meta 브랜치가 병행해서 발전하고 있었습니다. 새 프로토콜 지원(VLESS, Hysteria 계열, TUIC)을 보완하고, TUN 모드를 강화하고, DNS와 스니핑 능력을 확장하고, sub-rules 같은 더 유연한 규칙 작성 방식을 도입했습니다. 오리지널 설정과의 하위 호환성을 유지해, 기존 설정 파일은 대체로 Meta 커널에 그대로 넣어 실행할 수 있지만 반대는 성립하지 않습니다. Meta 확장 필드를 사용한 설정을 오리지널 커널에 넣으면 "unsupported" 류의 오류가 발생합니다.

mihomo: 같은 커널의 현재 이름

오리지널 저장소가 아카이브된 뒤, Meta 브랜치는 mihomo로 이름을 바꾸어 지금까지 개발을 이어오고 있습니다. **mihomo는 곧 Clash.Meta의 현재 이름이며, 둘은 같은 프로젝트**로 설정 형식, 커맨드라인 동작, API가 전부 그대로 이어집니다. 오늘날 주류 클라이언트—다운로드 페이지에서 첫손에 추천하는 Clash Plus를 비롯해 Clash Verge Rev, FlClash, Clash Nyanpasu, Clash Meta for Android 등—의 하위 커널은 모두 mihomo 또는 그 파생 버전입니다. 클라이언트를 고를 때 "mihomo/Meta 커널 기반"이라는 표기를 본다면 6가지 프로토콜과 TUN, 스니핑 등의 기능이 모두 지원 범위 안에 있다는 뜻입니다.

설정 필드와 커널 호환성: 새 커널에서만 인식하는 항목은 무엇인가

구독을 받거나 설정을 직접 작성할 때 가장 흔한 실패 지점은 "필드와 커널이 맞지 않는" 경우입니다. 이 장에서는 필드 계층별로 호환성 경계를 살펴보고, 설정 파일 전체 구조를 단락별로 정독하려면 설정 파일 구조 해설을 참고하세요.

모든 커널이 공통으로 인식하는 골격 필드

port, socks-port, mixed-port, allow-lan, mode, log-level, external-controller 같은 최상위 필드는 오리지널 시절부터 지금까지 이어져 어떤 커널이든 인식합니다. proxies 안의 SS, VMess, Trojan 세 가지 노드의 기본 작성법도 마찬가지로 범용입니다. 이 필드들만 사용한 설정은 어떤 클라이언트에 넣어도 실행됩니다.

Meta/mihomo에서만 지원하는 확장 필드

다음 항목 중 하나라도 등장하면 그 설정은 Meta/mihomo 계열 커널에서만 실행됩니다. type이 vless, hysteria2, tuic인 노드, tun 섹션의 완전한 설정(stack, auto-route, dns-hijack 포함), sniffer 스니핑 섹션, GEOSITE류 규칙과 일부 확장 규칙 유형, proxy-providers와 rule-providers의 강화 파라미터입니다. 최소한의 Hysteria2 노드 예시입니다:

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

모든 커널에서 공통으로 인식하는 Shadowsocks 노드와 비교하면, 확장 프로토콜은 필드가 몇 개 더 있을 뿐 골격은 완전히 동일합니다:

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

호환성 문제 해결 3단계

1. 커널 확인: 클라이언트 설정 페이지를 열어 커널 표기를 확인하세요. mihomo나 Meta라고 적혀 있으면 새 커널입니다. 버전 번호 옆에 대체로 커널 이름이 함께 표시됩니다.
2. 오류 키워드 확인: 로그에 unsupported type이나 unknown field가 나타나면 오래된 커널이 새 필드를 만난 경우로 거의 확정할 수 있습니다.
3. 낮추지 말고 높이기: 설정 필드를 지워서 오래된 커널에 맞추는 대신, 클라이언트를 mihomo 커널 기반 버전으로 바꾸세요(다운로드 페이지에 있는 관리 중인 클라이언트는 모두 이 조건을 만족합니다).

구독 형식 호환성: 클라이언트를 바꾸면 무슨 일이 생기는가

구독은 "하나의 URL로 노드 설정 전체를 받아오는" 메커니즘이지만, 生态마다 형식이 통일되어 있지 않습니다. 흔히 볼 수 있는 세 가지 형태를 정리해두면 클라이언트나 플랫폼을 바꿀 때 헷갈리지 않습니다.

Clash YAML 구독: 이 생태계의 네이티브 형식

구독 링크가 완전한 YAML 설정(또는 최소한 proxies 섹션을 포함한 것)을 반환하면, 클라이언트가 이를 받아 그대로 로드합니다. 이것은 Clash 계열 클라이언트의 네이티브 형식으로 필드 정보가 가장 완전합니다. 노드 파라미터, 정책 그룹 구조, 규칙 섹션을 함께 내려받을 수 있습니다. 주의할 점은 하나뿐입니다. 반환된 설정에 Meta 확장 필드가 포함되어 있으면 오래된 커널 클라이언트에서는 로드에 실패하며, 오류 양상은 앞 장에서 다룬 내용과 같습니다.

공유 링크와 Base64 통합: 생태계를 넘나드는 최대공통 형식

ss://, vmess://, trojan://로 시작하는 단일 노드 공유 링크와, 이런 링크 여러 개를 Base64로 묶은 통합 구독은 클라이언트 생태계를 넘나드는 범용 교환 형식입니다. 노드 자체만 기술하며 정책 그룹과 규칙은 포함하지 않습니다. mihomo 계열 클라이언트는 대부분 이런 구독을 바로 인식하고 자동으로 기본 정책 그룹을 씌워줍니다. 반대 방향 호환성은 대상 클라이언트에 따라 다른데, 일부 프로토콜(특히 Hysteria2, TUIC)의 공유 링크 형식은 구현체마다 세부 사항이 달라 생태계를 넘어 가져올 때 파라미터가 간간이 누락되는 것은 흔한 현상입니다.

구독 변환: 편리하지만 무엇이 사라지는지 알아야 함

구독 변환 서비스는 한 형식을 다른 형식으로 바꿔주며, "서버 제공자는 범용 구독만 주는데 클라이언트는 완전한 YAML을 원하는" 상황에서 자주 쓰입니다. 세 가지는 반드시 알아둬야 합니다. 첫째, 변환은 템플릿에 따라 정책 그룹과 규칙을 생성하므로 원본 구독에 없던 분기 로직은 템플릿이 추가한 것이며 서비스 제공자의 의도가 아닙니다. 둘째, 흔하지 않은 프로토콜 파라미터(예: Hysteria2의 대역폭 힌트 필드)는 변환 과정에서 조용히 사라질 수 있으니 연결이 안 될 때는 이 부분을 먼저 의심하세요. 셋째, 구독 링크에는 신원 정보가 담겨 있어 공용 변환 서비스에 제출하는 것은 곧 노드 정보를 넘기는 것과 같으므로, 직접 구축하거나 클라이언트 내장 로컬 변환을 쓰는 것이 더 안전합니다. 구독 관련 추가 질문은 헬프 센터를 참고하세요.

사용 환경별 선택: 바로 적용하는 답

앞의 모든 내용이 이 장으로 모입니다. 자신의 상황을 찾아 추천 순서대로 클라이언트에서 시도해보고, 처음으로 연결되고 안정적인 것이 현재 환경에 맞는 답입니다.

데스크톱 일상 사용: 웹, 업무, 개발

무엇을 할지: Trojan이나 VLESS + TLS를 우선하고 SS를 대안으로 두세요. 데스크톱은 CPU 성능이 넉넉해 TLS 오버헤드가 체감되지 않으니 위장 능력을 우선하면 됩니다. 확인되는 것: 지연이 안정적이고 장시간 켜둬도 끊기지 않습니다. Windows나 macOS 플랫폼에서는 Clash Plus를 사용하고, 규칙 분기는 입문 가이드의 기본 설정을 그대로 쓰면 됩니다.

모바일: 통근과 야외 활동

무엇을 할지: 네트워크 전환이 빈번하면 TUIC나 Hysteria2를 골라 QUIC의 연결 마이그레이션을 활용하고, 하나의 네트워크에 오래 머물며 배터리를 중시한다면 SS나 Trojan을 고르세요. 확인되는 것: 네트워크 전환 후 더 빠르게 복구되거나, 밤새 대기 시 배터리 소모가 줄어듭니다. 위의 배터리 장에서 다룬 프로브 간격 설정도 함께 조정하세요.

열악한 네트워크와 장거리 링크: 높은 손실률, 높은 지연

무엇을 할지: Hysteria2를 우선하고 TUIC를 다음으로 시도하세요. 확인되는 것: 같은 나쁜 회선에서도 처리량이 뚜렷하게 회복되고, 영상 재생 시 로딩이 멈추지 않습니다. 사용 중인 네트워크가 UDP 속도를 제한한다면(QUIC 노드가 전부 타임아웃되거나 속도가 급락하는 형태로 나타남) Trojan으로 되돌리세요.

라우터와 상시 구동 서버

무엇을 할지: CPU 오버헤드가 가장 낮은 SS(AEAD)를 우선하고, 기기 성능이 여유롭다면 Trojan을 고려하세요. 커널은 mihomo 커맨드라인 버전을 바로 실행하면 되고, 다운로드 페이지 커널 섹션에서 각 아키텍처별 패키지를 제공합니다. 확인되는 것: 저가형 ARM 기기에서도 회선 속도에 가까운 전달 성능을 냅니다. QUIC 계열 프로토콜은 소프트웨어 라우터에서 CPU 점유율이 다소 높으니 상시 구동에는 신중해야 합니다.

하나의 구독에 여러 프로토콜 공존: 추천 방식

대부분의 서비스 제공자는 같은 노드에 여러 프로토콜 입구를 제공합니다. 추천하는 방식은 정책 그룹 안에서 서로 다른 프로토콜의 같은 지역 노드를 한 그룹에 묶어 며칠간 수동으로 전환하며 비교해보는 것입니다. 클라이언트는 mihomo 커널 기반 버전을 골라 6가지 프로토콜이 모두 사용 가능하도록 하고, 프로토콜에 맞춰 클라이언트를 선택하지 않아도 되게 하세요.

흔한 오해와 추가 읽을거리

마지막으로 빈도 높은 오해를 한 번에 정리합니다. 각 항목은 실제 문의 게시글에서 반복되는 패턴에 대응합니다.

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

성립하지 않습니다. Hysteria2, TUIC는 특정 환경(열악한 네트워크, 빈번한 네트워크 전환)을 위한 특화 방안으로, 양질의 유선 네트워크에서는 Trojan에 비해 체감 우위가 없고 CPU와 배터리를 더 소모합니다. 프로토콜 선택은 발표 연도가 아니라 환경 적합도로 판단해야 합니다.

오해 2: 지연이 낮으면 프로토콜이 빠른 것이다

그렇지 않습니다. 클라이언트가 표시하는 지연은 한 번의 프로브 왕복일 뿐, 처리량, 손실 복구, 핸드셰이크 오버헤드 정보는 담고 있지 않습니다. 같은 노드에서 SS와 Trojan의 프로브 값은 거의 같아도 열악한 네트워크에서 실제 체감은 몇 배 차이 날 수 있습니다. 자세한 원리는 지연 수치 해석을 참고하세요.

오해 3: Meta와 mihomo는 두 개의 커널이라 둘 중 하나를 골라야 한다

같은 프로젝트가 전후로 사용한 두 이름일 뿐입니다. 클라이언트 설명에 어느 이름이 나오든 지원 기능 집합은 동일하며 선택의 문제가 존재하지 않습니다.

오해 4: A 클라이언트에서 구독이 됐다면 B 클라이언트에서도 반드시 된다

구독 형식과 커널 버전의 교집합에 따라 달라집니다. YAML 구독에 확장 필드가 포함되면 오래된 커널은 로드를 거부하고, 범용 구독을 다른 생태계로 가져올 때 파라미터가 누락될 수 있습니다. 클라이언트를 바꾼 뒤 연결이 안 된다면 먼저 설정 호환성 장의 3단계 방법으로 점검하고, 그다음 헬프 센터의 문제 해결 분류에서 해당 항목을 찾아보세요.

오해 5: 분기가 작동하지 않는 것은 프로토콜 탓이다

대부분 그렇지 않습니다. 분기는 규칙 섹션과 DNS 동작으로 결정되며 노드 프로토콜과는 무관합니다. 규칙이 제대로 작동하지 않는 가장 흔한 원인은 DNS 누출이나 fake-ip 설정 오류이며, 점검 방법은 DNS 누출 탐지와 수정을 참고하세요.

이 페이지를 다 읽었다면 프로토콜과 커널 선택 근거는 이미 갖춰졌습니다. 다음 단계로 설치 파일 페이지에서 플랫폼에 맞는 클라이언트를 받고, 입문 가이드를 따라 구독 가져오기, 모드 선택, 연결 확인까지 메인 루트를 한 번 완료하세요.