Clash 프로토콜과 코어 기술 참고서

Clash 계열 클라이언트는 자체적으로 프로토콜을 만들지 않습니다. "다중 프로토콜 아웃바운드 프레임워크"에 가깝습니다: 설정 파일 안에서 각 노드가 자신의 type을 선언하면, 코어가 그 유형에 맞는 프로토콜 구현을 호출합니다. 따라서 프로토콜 선택의 첫 단계는 "어떤 것이 가장 빠른가"를 따지는 것이 아니라, 각 프로토콜이 설계상 무엇을 포기하고 무엇을 얻었는지 파악하는 것입니다. 6가지 주요 프로토콜은 두 가지 기준으로 대략 나눌 수 있습니다: 전송 계층이 TCP인지 UDP(QUIC)인지, 그리고 프로토콜 자체가 암호화를 위해 TLS에 의존하는지 여부입니다.

Shadowsocks: 극단적으로 단순한 암호화 전달

Shadowsocks는 6가지 중 가장 먼저 등장한 세대로, 설계 목표가 단 하나였습니다: 최소한의 코드로 클라이언트와 서버 사이에 암호화된 SOCKS 전달 통로를 만드는 것. 프로토콜 헤더가 매우 짧고 핸드셰이크 협상 단계가 없어, 연결이 만들어지면 곧바로 암호문을 전송합니다. 초기의 스트림 암호화 방식은 이미 폐기되었고, 현재 구현은 통일된 AEAD 암호화 스위트(예: aes-128-gcm, chacha20-ietf-poly1305)를 사용해 기밀성과 무결성 검증을 동시에 제공합니다. 트레이드오프는 명확합니다: 프로토콜 계층의 확장성을 포기(멀티플렉싱 없음, 내장 UDP over TCP 없음)한 대신, 가장 낮은 구현 복잡도와 가장 작은 패킷당 오버헤드를 얻었습니다. 지금도 저사양 기기와 구형 라우터에서 우선적으로 선택되며, 많은 구독에서 "최소 보장 노드" 유형으로 쓰입니다. SS2022 계열 스위트는 키 관리와 재전송 공격 방어를 강화했으며, 코어 관점에서는 같은 ss 유형의 다른 cipher로 취급됩니다.

VMess: V2Ray 시대의 다기능 프로토콜

VMess는 V2Ray 프로젝트와 함께 탄생했으며, SS와는 반대의 방향을 지향합니다: 복잡해지더라도 기능은 모두 갖추자는 방식입니다. 프로토콜 헤더에 사용자 ID, 암호화 방식, 타임스탬프 등 메타데이터를 담고, 동적 포트 같은 기능을 지원하며, V2Ray의 전송 계층 플러그인 체계(WebSocket, gRPC, HTTP/2)와 자연스럽게 결합됩니다. 대가는 SS보다 큰 프로토콜 헤더 오버헤드이며, 초기에는 클라이언트와 서버의 시간 동기화에 의존했습니다. 로컬 시간 오차가 크면 핸드셰이크가 실패하는데, 이는 VMess 노드 연결 실패를 진단할 때 반드시 확인하는 항목입니다. VMess의 가치는 생태계에 있습니다: 수많은 패널과 구독 변환 도구가 VMess를 중심으로 만들어져 호환성 범위가 넓습니다. 순수 프로토콜만 보면 암호화와 캡슐화 설계가 이미 무겁게 느껴지며, 이는 후속으로 등장한 VLESS를 직접적으로 촉발했습니다.

Trojan: 자신을 HTTPS의 형태 속에 숨기다

Trojan의 발상은 덜어내기입니다: TLS가 이미 충분한 암호화를 제공하므로, 프로토콜 계층에서 다시 암호화하지 않고 TLS 터널 안에 단순한 인증 헤더와 원본 트래픽만 실어 보냅니다. 외부에서 관찰하면 Trojan 연결은 일반적인 HTTPS 접속과 전송 형태가 매우 유사하며, 인증에 실패한 연결은 서버에서 실제 웹사이트로 우회(fallback)됩니다. 트레이드오프는: 사용 가능한 도메인과 인증서 세트에 강하게 의존해 배포 난이도가 SS보다 높지만, 클라이언트 구현은 매우 가볍고 실행 오버헤드가 낮습니다. 사용자 입장에서 Trojan 노드의 연결 동작은 안정적이고 예측 가능하며, TCP + TLS 조합은 다양한 네트워크 환경에서 호환성이 가장 좋고 "통신사가 이런 트래픽만 별도로 속도 제한을 건다"는 문제가 거의 없습니다.

VLESS: 불필요한 부분을 제거한 차세대 프레임워크

VLESS는 Xray 생태계가 VMess를 재구성한 결과물입니다: 프로토콜 자체 암호화를 제거(TLS에 위임)하고, 타임스탬프 의존성을 제거해 프로토콜 헤더를 최소화했으며, UUID 인증과 필수 라우팅 정보만 남겼습니다. 이로써 VLESS는 하나의 "얇은 껍질"이 되었고, 실제 차별화된 성능은 함께 쓰이는 전송 방식에서 나옵니다. XTLS Vision은 흐름 제어를 통해 TLS in TLS의 이중 암호화 오버헤드를 줄이고, REALITY는 자체 인증서 보유 요구를 없애줍니다. 선택할 때 주의할 점: VLESS 자체는 오버헤드가 거의 없으며, 성능은 서버가 어떤 조합을 구성했는지에 따라 결정됩니다. 구독에 똑같이 vless라고 적힌 두 노드도 실제 동작은 크게 다를 수 있습니다. 클라이언트 측 코어도 해당 전송 특성을 지원해야 하며, 이는 뒤에서 mihomo를 강조하는 이유 중 하나입니다.

Hysteria2: 패킷 손실 환경을 위해 태어난 QUIC 프로토콜

Hysteria2는 QUIC 위에서 만들어졌으며, 핵심 강점은 커스텀 혼잡 제어입니다: 전통적인 TCP 혼잡 제어 알고리즘은 손실률이 높은 링크에서 크게 양보하는 경향이 있어, 해외 구간의 실제 처리량이 대역폭의 일부분에 그치는 경우가 흔합니다. Hysteria2는 더 적극적인 전송 전략을 채택해, 사용자가 업/다운로드 대역폭을 직접 선언할 수 있게 하고, 손실률 5% 이상의 링크에서도 명목 속도에 가까운 성능을 유지합니다. 트레이드오프도 명확합니다: 적극적인 패킷 전송은 혼잡한 네트워크에서 다른 사용자의 대역폭을 잠식할 수 있고, 일부 통신사는 지속적인 대용량 UDP 세션에 QoS 속도 제한을 적용합니다. 이런 네트워크에서는 QUIC 계열 프로토콜이 오히려 TCP 계열보다 불안정합니다. "링크 품질은 나쁘지만 UDP 제한이 없는" 상황에 적합하며, 무조건적인 기본 선택으로 삼기에는 적절하지 않습니다.

TUIC: 저지연을 지향하는 또 다른 QUIC 노선

TUIC은 Hysteria2와 같은 QUIC 계열이지만 초점이 다릅니다: 적극적인 대역폭 경쟁을 하지 않고, QUIC의 네이티브 기능을 충분히 활용합니다. 0-RTT 핸드셰이크로 재연결이 거의 체감되지 않고, 연결 내 멀티플렉싱으로 헤드오브라인 블로킹을 피하며, UDP 트래픽의 네이티브 릴레이(native 모드)는 게임이나 실시간 음성처럼 작은 패킷을 자주 주고받는 애플리케이션에 특히 유리합니다. 혼잡 제어는 cubic, new_reno, bbr 중에서 선택할 수 있으며, 동작이 Hysteria2보다 완만합니다. 약점은 생태계가 작다는 점입니다: TUIC 노드를 제공하는 서비스가 다른 프로토콜보다 적고, 클라이언트 지원을 위해서는 코어가 Meta 계열이어야 합니다. 지연에 민감하고 손실률이 심하지 않은 환경에서는 여섯 프로토콜 중 TUIC의 체감이 대체로 가장 좋습니다.

6가지 프로토콜을 전송 계층 기준으로 나누면, 성능 논의에서 나오는 대부분의 현상을 이 계층으로 귀결시킬 수 있습니다. SS, VMess, Trojan, VLESS의 주류 형태는 TCP를 사용하고, Hysteria2와 TUIC은 UDP 위의 QUIC을 사용합니다. 두 노선의 차이는 네 가지 측면에서 드러납니다.

핸드셰이크 비용

TCP + TLS 1.3으로 새 연결을 맺으려면 TCP 3-way 핸드셰이크 한 번과 TLS 핸드셰이크 한 번이 필요해, 첫 바이트 지연이 약 2 RTT입니다. QUIC은 전송 핸드셰이크와 암호화 핸드셰이크를 합쳐, 첫 연결은 1 RTT, 세션을 재사용할 때는 0-RTT로 바로 데이터를 보냅니다. 물리적 지연이 200ms인 해외 구간에서, 연결을 자주 새로 맺는 상황(웹페이지를 열 때 순간적으로 발생하는 수십 개의 동시 요청)에서는 이 차이가 뚜렷하게 체감됩니다. TCP 계열 프로토콜은 연결 멀티플렉싱(mux)으로 이를 완화하지만, mux는 다음 문제를 불러옵니다.

헤드오브라인 블로킹

TCP는 단일한 순서 보장 바이트 스트림입니다: 패킷 하나가 손실되면 관련 없는 요청의 데이터까지 포함해 이 연결의 이후 데이터가 모두 막힙니다. TCP 연결 위에서 멀티플렉싱을 하면, 여러 요청을 쉽게 막히는 하나의 스트림에 묶는 셈이 되어 패킷 손실 환경에서는 오히려 체감이 나빠집니다. 이것이 "mux는 함부로 켜면 안 된다"는 원리입니다. QUIC은 프로토콜 내에서 독립된 스트림(stream)으로 전송하므로, 한 스트림의 손실이 다른 스트림에 영향을 주지 않고, 멀티플렉싱은 부담 없는 네이티브 기능입니다.

중간 장비 친화도

TCP 443 포트의 TLS 트래픽은 인터넷에서 가장 흔한 형태로, 어떤 네트워크 환경에서도 허용되어야 합니다. 반면 UDP 장시간 세션은 일부 통신사와 기업 네트워크에서 QoS 속도 제한, NAT 타임아웃 단축, 심지어 드롭까지 당할 수 있습니다. 이것이 QUIC 계열 프로토콜이 "빠를 때는 매우 빠르지만 때로는 아예 안 되는" 근본 원인입니다. 선택 기준: 환경을 모를 때는 TCP 계열이 안전한 선택이며, QUIC 계열은 실측으로 확인이 필요합니다.

위장 전송의 위치

WebSocket, gRPC 같은 전송 플러그인은 TCP 계열 프로토콜의 선택적 외피로, CDN을 경유하는 시나리오에서 자주 쓰입니다. 대가는 각 캡슐화 계층마다 지연과 오버헤드가 추가되고, CDN 오리진 회귀 자체도 추가 홉을 만든다는 점입니다. QUIC 계열 프로토콜은 이 체계를 사용하지 않습니다. 구독에서 같은 이름의 프로토콜이라도 전송 외피가 다르면 지연이 두 배 가까이 차이 날 수 있으므로, 속도 측정 시 구분해서 봐야 합니다.

프로토콜 자체의 암복호화 오버헤드는 현대 하드웨어에서는 매우 작습니다. 실제 차이를 만드는 것은 핸드셰이크 모델, 혼잡 제어, 캡슐화 계층 수입니다. 아래 표는 동일한 링크 조건에서의 정성적 비교로, 방향성은 신뢰할 수 있지만 배수는 환경에 따라 다릅니다.

두 가지 부연 설명. 첫째, QUIC 계열 프로토콜의 CPU 사용량이 높은 것은 암호화 때문이 아니라, QUIC 프로토콜 스택이 사용자 공간(user space)에서 동작해 송수신 패킷 경로가 커널 공간의 TCP보다 길기 때문입니다. 데스크톱에서는 체감되지 않지만, 저전력 기기에서는 차이가 측정됩니다. 둘째, "고손실 링크 처리량" 항목의 차이는 표로 표현할 수 있는 정도를 훨씬 뛰어넘습니다: 손실률 10%인 같은 링크에서 TCP 계열 프로토콜은 대역폭의 10분의 1 정도만 낼 수 있는 반면, Hysteria2는 절반 이상을 유지할 수 있습니다. 링크 품질이 이 표에서 어느 행이 자신에게 중요한지를 결정합니다.

속도 측정 방법 제안: 클라이언트 안에서 같은 서비스의 다른 프로토콜 노드에 대해 지연 테스트를 하는 것은 핸드셰이크 RTT만 반영할 뿐 처리량을 반영하지 않습니다. 처리량은 실제 다운로드나 스트리밍 로딩으로 확인해야 하며, 출퇴근 피크 시간대와 새벽 시간대를 각각 한 번씩 측정하는 것이 좋습니다. 다운로드 페이지에서 제공하는 각 클라이언트는 모두 지연 테스트가 내장되어 있고, Clash Plus의 그룹 테스트는 같은 그룹의 모든 노드를 한 번에 비교할 수 있습니다.

휴대폰에서 프록시 클라이언트의 배터리 소모는 세 가지로 구성됩니다: VPN 서비스가 상주하며 발생하는 기본 오버헤드, 프로토콜 스택이 트래픽을 처리할 때의 CPU 오버헤드, 그리고 가장 중요한 것—네트워크 동작이 셀룰러/Wi-Fi 무선 모듈을 웨이크업시키는 것입니다. 세 번째 항목이 대부분을 차지합니다. 프로토콜이 배터리에 미치는 영향은 주로 하트비트와 재연결 동작을 통해 전달됩니다.

하트비트와 연결 유지

TCP 계열 프로토콜은 NAT 매핑 유지에 의존하며, 클라이언트나 서버가 대개 수십 초 단위의 keepalive로 연결을 유지합니다. 하트비트마다 이미 잠들어 있던 셀룰러 모듈을 고전력 상태로 깨워 몇 초간 유지시킬 수 있습니다. QUIC 계열 프로토콜도 연결 유지가 필요하지만, QUIC의 연결 마이그레이션(connection migration)은 네트워크가 전환(Wi-Fi와 셀룰러 사이)된 후에도 기존 연결을 그대로 사용할 수 있게 해, 완전한 재연결 한 번을 생략합니다. TCP 계열 프로토콜은 네트워크가 전환될 때마다 모든 연결을 처음부터 다시 맺어야 하며, 이때 집중적인 핸드셰이크 트래픽과 무선 모듈 활성화가 동반됩니다. Wi-Fi와 셀룰러를 자주 전환하는 사용 패턴에서는 QUIC 계열 프로토콜의 배터리 성능이 대체로 더 좋습니다.

암호화와 프로토콜 스택 오버헤드

AEAD 암복호화는 하드웨어 명령어 가속을 받기 때문에 프로토콜 간 차이는 무시할 수 있습니다. QUIC의 사용자 공간 프로토콜 스택이 모바일 칩에서 추가로 소모하는 CPU는 측정은 가능하지만 두드러지지는 않으며, 장시간 대용량 전송(긴 시간 동영상 시청) 시에만 드러납니다. 가벼운 웹서핑 상황에서는 신경 쓸 필요가 없습니다.

프로토콜보다 더 큰 영향을 주는 요소

실측에서 클라이언트 설정이 배터리 소모에 미치는 영향은 프로토콜 선택보다 훨씬 큽니다: 규칙 세트 자동 업데이트 간격이 너무 짧거나, 로그 레벨이 debug로 설정되어 있거나, DNS 동시 해석 전략이 지나치게 적극적이거나, 노드 자동 속도 테스트 간격이 너무 촘촘한 경우 등 어느 하나라도 프로토콜 차이보다 한 자릿수 더 큰 배터리 소모를 유발할 수 있습니다. 항목별 진단 방법은 블로그 글 모바일에서 Clash 배터리 소모가 심할 때 확인하는 방법에 있으며, 안드로이드 배터리 최적화 화이트리스트와 iOS의 필요 시 연결 설정도 이 글에 정리되어 있습니다.

"Clash"라는 이름은 오늘날 최소 세 가지를 가리킵니다: 개발이 중단된 오리지널 코어 프로젝트, 그 커뮤니티 강화 분기인 Clash.Meta, 그리고 Meta가 이름을 바꾸어 지금까지 이어지는 mihomo. GUI 클라이언트(Clash Plus, Clash Verge Rev, FlClash 등)는 모두 코어를 감싸는 그래픽 인터페이스이며, 코어가 프로토콜 지원 범위와 설정 문법의 상한을 결정합니다. 세 계열의 계보와 차이는 다음과 같습니다.

3세대 코어 계보

오리지널 Clash는 YAML 설정 형식, 규칙 분기 모델, RESTful 제어 인터페이스를 확립했고, 당시 주류였던 SS, VMess, Trojan 등을 지원했습니다. 프로젝트 개발이 중단되고 저장소가 삭제된 뒤로는 오리지널 코어가 어떤 업데이트도 받지 못했으며, 새로운 프로토콜은 전혀 지원하지 않습니다. Clash.Meta는 오리지널을 기반으로 커뮤니티가 강화한 분기로, VLESS, Hysteria 계열, TUIC 등 새로운 프로토콜과 다양한 분기 기능을 보완했습니다. 이후 이름 관련 분쟁을 피하기 위해 mihomo로 명칭을 바꿨으며, 프로젝트 본체와 설정 형식, 개발팀은 끊기지 않았습니다—즉 mihomo는 곧 Meta이며 이름만 바뀐 것입니다. 현재 생태계에서 활발히 유지보수되는 Clash 계열 코어는 mihomo 하나뿐이며, 주요 GUI 클라이언트도 모두 mihomo로 이전을 완료했습니다. 3세대 코어의 전체 흐름은 블로그 글 Clash 오리지널, Meta, mihomo 코어 차이 정리에서 확인할 수 있습니다.

기능 차이 대조표

설정 호환성

mihomo는 오리지널 설정과 대체로 하위 호환됩니다: 오리지널 코어에서 동작하는 YAML은 대부분 mihomo에서도 그대로 로드할 수 있습니다. 역방향은 성립하지 않습니다—설정에 mihomo 확장 필드(예: hysteria2 노드 유형, TUN 섹션, 강화된 DNS 필드)가 하나라도 있으면 오리지널 코어는 곧바로 오류를 내고 종료합니다. 어떤 설정이 mihomo에 의존하는지 판단하려면 다음과 같은 필드를 확인하면 됩니다:

proxies:
  - name: hy2-node
    type: hysteria2      # 원본 코어가 인식하지 못하는 유형
    server: example.com
    port: 443
    password: your-password

tun:                     # 원본 오픈소스 코어에는 없는 섹션
  enable: true
  stack: system
  auto-route: true

선택 기준을 곧바로 말하면: 오늘날 오리지널 코어를 새로 설치할 이유는 없습니다. 프로토콜 커버리지, TUN 모드, 유지보수 상태 세 가지 모두 mihomo를 가리킵니다. 본 사이트의 다운로드 페이지에서 제공하는 GUI 클라이언트는 모두 mihomo 또는 그 파생 버전을 기반으로 하며, 코어 섹션에서는 각 플랫폼용 mihomo 순수 코어도 제공해 서버와 라우터 사용자가 이용할 수 있습니다.

구독은 서비스가 클라이언트에 노드를 배포하는 매체이며, 형식 불일치는 가져오기 실패의 첫 번째 원인입니다. 현재 유통되는 구독은 주로 세 가지 유형이 있습니다.

세 가지 구독 형식

첫 번째는 Clash YAML 구독입니다: 완전하거나 부분적인 Clash 설정 파일로, proxies, proxy-groups, rules 등의 섹션을 포함합니다. Clash 계열 클라이언트가 네이티브로 지원하며 정보가 가장 완전하고, 그룹과 분기 규칙을 서비스 측에서 미리 구성해 둘 수 있습니다. 두 번째는 Base64 범용 구독입니다: ss://, vmess:// 등의 노드 공유 링크를 줄 단위로 이어 붙인 뒤 전체를 인코딩한 것으로, 노드만 포함하고 규칙은 포함하지 않으며 역사가 가장 오래되고 호환 범위가 가장 넓습니다. 현대 Clash 클라이언트는 대부분 자동으로 인식하고 변환할 수 있지만, 변환 후에는 클라이언트가 스스로 그룹과 규칙을 보완해야 합니다. 세 번째는 다른 생태계의 전용 형식(예: sing-box의 JSON)으로, Clash 계열 클라이언트가 직접 지원하지 않아 구독 변환 서비스를 거쳐 번역이 필요합니다.

프로토콜 지원이 구독에 미치는 영향

형식이 맞다고 해서 모든 노드가 사용 가능한 것은 아닙니다: YAML 구독에 hysteria2, tuic, vless 유형 노드가 포함되어 있는데 클라이언트 코어가 구버전이거나 오리지널이면, 가볍게는 해당 노드가 조용히 무시되고, 심하게는 설정 전체가 로드에 실패합니다. "구독 가져오기는 성공했지만 노드 목록이 남들보다 적다" 또는 "구독을 업데이트한 뒤 클라이언트가 오류를 낸다"로 나타납니다. 처리 순서: 먼저 클라이언트 코어가 mihomo 계열인지 확인한 뒤, 구독 링크에 서비스가 제공하는 Clash 전용 파라미터가 붙어 있는지 확인하세요(같은 구독 주소가 URL 파라미터에 따라 다른 형식을 출력하는 서비스가 많습니다).

proxy-providers로 구독 관리하기

설정을 직접 관리하는 사용자라면 proxy-providers를 사용해 "노드 출처"와 "그룹 규칙"을 분리하는 것을 권장합니다: 노드는 구독 주소에서 주기적으로 가져오고, 그룹과 규칙은 로컬 설정에 작성해 구독을 업데이트해도 개인 커스터마이징이 사라지지 않습니다. 최소 예시:

proxy-providers:
  main:
    type: http
    url: "구독 주소"
    interval: 86400        # 가져오기 간격(초), 모바일에서는 너무 짧지 않게
    path: ./providers/main.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

앞의 내용을 종합해 바로 실행할 수 있는 판단 흐름을 정리합니다. 전제: 노드 프로토콜은 서비스가 결정하며, 아래 제안은 "같은 서비스가 여러 프로토콜 노드를 제공할 때 어느 것을 고를지"와 "서비스를 바꿀 때 무엇을 우선 고려할지"에 사용됩니다.

데스크톱 일상 사용(업무 / 웹서핑 / 동영상)

Trojan 또는 VLESS를 우선 선택하세요. TCP + TLS 조합은 어떤 네트워크에서도 호환성이 가장 좋고, 오버헤드가 낮으며 동작이 안정적이라 장시간 켜둬도 문제가 잘 생기지 않습니다. 링크 손실이 뚜렷한 경우(저녁 피크 시간 해외 구간)이면서 네트워크가 UDP를 제한하지 않는다면, Hysteria2 노드를 대체 옵션으로 두고 피크 시간에 수동 전환하세요. 클라이언트는 Clash Plus를 선택하면 그룹 속도 테스트와 규칙 관리가 바로 사용 가능하며, 오픈소스 데스크톱 방식을 선호한다면 Clash Verge Rev를 선택할 수 있습니다.

모바일(휴대폰 / 태블릿)

신호가 안정적인 환경에서는 Trojan / VLESS를, 통근처럼 네트워크 전환이 잦은 시나리오에서는 TUIC을 우선 고려하세요(연결 마이그레이션이 재연결을 줄이고, 0-RTT가 네트워크 전환 후 복구 지연을 낮춥니다). Hysteria2를 백그라운드에서 장시간 사용하는 것은 피하세요—적극적인 패킷 전송 모델이 배터리에 우호적이지 않습니다. 클라이언트 설정이 프로토콜보다 더 중요합니다: 업데이트 간격, 로그 레벨을 배터리 항목의 제안에 따라 조여 두세요. iOS 사용자는 App Store에서 Clash Plus를 받으면 되며, 절차는 사용 가이드 페이지에 있습니다.

불안정한 네트워크와 고손실 링크

Hysteria2는 이 시나리오를 위해 설계되어 이점이 가장 큽니다. 대역폭 파라미터는 실제 링크 기준으로 입력해야 하며, 업로드 값을 과장하면 오히려 손실이 심해질 뿐입니다. UDP가 속도 제한을 당하는 경우(QUIC 노드 속도가 주기적으로 떨어지는 형태로 나타남)에는 TCP 계열 프로토콜로 돌아가고, 서버가 BBR 혼잡 제어를 사용하는 노드를 우선 선택하세요.

게임과 실시간 애플리케이션

UDP 전달과 지연 지터에 주목하세요: TUIC(native UDP 모드)와 Hysteria2는 UDP를 네이티브로 전달해 1순위입니다. SS는 서버 측에서 UDP 지원을 켜야 하며, VMess / Trojan의 UDP 능력은 서버 구현에 따라 다르고 대체로 QUIC 계열보다 못합니다. 선택 전에 먼저 게임이 UDP를 쓰는지 TCP를 쓰는지 확인하세요. 턴제나 웹 게임은 TCP를 사용하므로 프로토콜 차이가 크지 않습니다.

서버와 라우터

mihomo 코어를 단독 실행하는 경우, 프로토콜은 SS(리소스 사용량 최소)나 Trojan을 선택하세요. MIPS / ARMv7 등 저사양 기기에서는 QUIC 계열 프로토콜의 사용자 공간 프로토콜 스택 오버헤드를 피하는 것이 좋습니다. 각 아키텍처용 코어 패키지는 다운로드 페이지의 코어 섹션에 있으며, 다음과 같이 명령줄로 실행합니다:

mihomo -d /etc/mihomo    # 설정 디렉터리를 지정해 시작

결정 요약표

오해 1: 어떤 프로토콜이 "가장 빠르다"고 모든 시나리오에 통용된다. 그런 것은 존재하지 않습니다. 속도는 링크 품질, 서버 부하, 혼잡 제어가 함께 결정하며 프로토콜은 그중 하나의 변수일 뿐입니다. 같은 프로토콜이라도 링크에 따라 순위가 완전히 뒤바뀔 수 있으며, 결론은 오직 자신의 링크에서 여러 번 실측한 결과에서 나와야 합니다.

오해 2: 새 프로토콜이 항상 옛 프로토콜보다 좋다. SS는 가장 먼저 등장했지만 저사양 기기와 안정적인 링크에서는 여전히 오버헤드가 가장 낮은 선택입니다. VLESS + REALITY 조합은 매우 최신이지만 코어와 서버 버전이 맞아야 하고, 문제가 생기면 진단 난이도도 더 높습니다. 프로토콜은 도구이며, 시나리오에 맞는 것이 최신을 좇는 것보다 중요합니다.

오해 3: 클라이언트가 프로토콜 성능을 결정한다. GUI 클라이언트는 코어를 감싸는 외피일 뿐이며, 같은 mihomo 코어에서는 클라이언트가 달라도 프로토콜 처리량에 본질적인 차이가 없습니다. 클라이언트 간 차이는 상호작용, 플랫폼 적응, 설정 관리 능력에 있으며, 프로토콜 측면에서는 코어 버전만 확인하면 됩니다.

오해 4: 지연 테스트 값이 낮으면 체감도 좋다. 클라이언트에 표시되는 지연 값은 대체로 한 번의 HTTP 핸드셰이크 RTT일 뿐, 처리량과 손실률, 안정성을 반영하지 않습니다. 지연이 80ms지만 저녁 피크 시간에 손실이 심한 노드는, 지연이 150ms지만 하루 종일 안정적인 노드보다 체감이 나쁩니다.

오해 5: 설정 오류가 나면 먼저 프로토콜을 탓한다. 로드 실패의 대부분 원인은 YAML 들여쓰기 오류, 구독 형식 불일치, 코어 버전이 너무 오래된 것이며, 프로토콜 자체의 문제일 확률은 가장 낮습니다. "형식 → 코어 → 노드 → 프로토콜" 순서로 진단하는 것이 가장 효율적입니다.

더 구체적인 오류 처리 경로는 헬프 센터의 문제 해결 카테고리에서 확인할 수 있으며, 이 페이지에 나온 모든 용어는 용어 사전 페이지에서 하나씩 대조할 수 있습니다. 선택을 마쳤다면 사용 가이드 페이지로 돌아가 흐름대로 가져오기와 확인을 완료하거나, 바로 다운로드 페이지로 이동해 클라이언트를 받으세요.