Clash 프록시 프로토콜과 커널 선택 가이드

1프로토콜 개요: SOCKS5부터 QUIC 세대까지

프록시 프로토콜은 클라이언트와 원격 서버 사이의 약속입니다. 데이터를 어떤 형식으로 감싸고, 어떻게 암호화하고, 인증 정보를 어떻게 확인하고, TCP와 UDP 중 무엇으로 전송할지를 정의합니다. Clash 계열 클라이언트는 규칙을 실행하고 프로토콜을 구현하는 역할을 합니다. 프로토콜을 새로 만드는 것이 아니라 커뮤니티에서 공개한 프로토콜을 구현해 규칙 엔진이 다룰 수 있게 합니다. 따라서 어떤 프로토콜을 쓸지는 서버와 클라이언트가 공통으로 지원하는 형식을 고르는 문제이며, 클라이언트가 아무리 뛰어나도 서버가 지원하지 않는 프로토콜은 쓸 수 없습니다.

프로토콜에는 두 가지 방향이 있다는 점도 구분해야 합니다. 인바운드는 로컬 앱이 클라이언트에 접속하는 방식으로, 브라우저와 시스템 프록시는 HTTP나 SOCKS5 포트를 사용합니다. 이 두 프로토콜은 진입 통로일 뿐 구독에는 나타나지 않습니다. 아웃바운드가 이 문서의 핵심으로, 클라이언트가 트래픽을 SS나 VLESS 같은 형식으로 감싸 원격 서버로 보내는 방향입니다. 흔히 말하는 프로토콜 선택은 항상 아웃바운드 쪽을 가리킵니다.

계보와 등장 배경

SOCKS5와 HTTP 프록시는 가장 오래된 범용 프록시 방식으로, 전달만 담당하고 암호화는 정의하지 않으며 지금도 Clash의 로컬 인바운드 프로토콜로 쓰입니다. 2012년 무렵 Shadowsocks가 대칭키 암호화를 프록시 프로토콜에 도입해, 트래픽을 암호화해 원격 서버로 보내고 서버가 복호화 후 전달하는 방식을 채택했습니다. 프로토콜 자체는 매우 단순해 10여 개 프로그래밍 언어로 구현되어 있습니다. 2016년 무렵 등장한 V2Ray 프로젝트의 자체 프로토콜 VMess는 전체 암호화, 타임스탬프 인증, 교체 가능한 전송 계층을 채택해 설정 자유도를 크게 높였습니다. 2018년 무렵 등장한 Trojan은 위장을 최우선으로 삼아, 프록시 연결을 겉보기에 일반 HTTPS 접속과 똑같이 보이도록 하고 인증은 비밀번호 하나로 처리합니다. 2020년 무렵 VMess를 단순화한 VLESS가 등장해 암호화 역할을 TLS에 맡기고 헤더를 가볍게 만들었습니다. 비슷한 시기 QUIC 기반의 Hysteria와 TUIC가 잇달아 등장해 UDP로 불안정한 네트워크에서의 처리량을 높였고, Hysteria2는 Hysteria의 개선판입니다. 이 여섯 갈래가 오늘날 Clash 설정 파일의 proxies 항목에 올라오는 주요 선택지입니다.

한눈에 보는 프로토콜

아래 표는 6종 프로토콜을 나란히 정리해 전체적인 흐름을 먼저 보여줍니다. 자세한 내용은 이후 각 장에서 다룹니다.

이 표는 세 가지 기준으로 보면 됩니다. 캡슐화와 외형 - 위장 기능이 있는지, 트래픽이 어떤 형태로 보이는지. 오버헤드와 성능 - 핸드셰이크 왕복 수, 암호화가 차지하는 프로세서 자원, 불안정한 네트워크에서의 처리량 유지력. 생태계와 지원 범위 - 서버 쪽 지원 여부, 클라이언트 커널 구현 여부, 구독 형식 지원 여부. 이후 각 항목은 이 세 기준으로 설명합니다.

규칙 엔진과의 관계

두 계층을 분명히 구분해야 합니다. 프로토콜은 개별 연결이 어떻게 전송되는지를, 규칙은 어떤 연결이 어떤 프로토콜을 타는지를 결정합니다. Clash의 규칙 엔진은 프로토콜 위에서 동작합니다. 하나의 설정에 SS, VLESS, Hysteria2 노드가 함께 있을 수 있고, 규칙이 도메인·IP 대역·프로세스명에 따라 트래픽을 서로 다른 정책 그룹으로 나누며, 정책 그룹은 특정 노드에 연결됩니다. 프로토콜 선택과 트래픽 분배는 서로 다른 문제입니다. 전자는 이 문서를 참고하고, 후자의 실전 활용은 《Clash 규칙 기반 트래픽 분배 실전》 글을 참고하세요.

2Shadowsocks: 가벼운 암호화의 출발점

Shadowsocks(줄여서 SS)는 Clash가 지원한 지 가장 오래된 프로토콜이며 구독에서 가장 자주 볼 수 있는 프로토콜이기도 합니다. 설계 목표는 한 문장으로 정리됩니다. 최소한의 핸드셰이크와 최대한 단순한 형식으로 TCP·UDP 트래픽을 암호화해 원격지로 전달하는 것입니다.

설계 목표와 캡슐화 형식

SS 세션에는 별도의 핸드셰이크 단계가 없습니다. 클라이언트는 목적지 주소, 포트, 페이로드를 함께 암호화해 바로 전송하고, 서버는 동일한 사전 공유 키로 복호화해 목적지 주소를 읽어 전달합니다. 키는 사용자 비밀번호에서 키 유도 함수로 생성되며, 마스터 키 외에 각 연결마다 하위 키를 다시 유도해 재전송 공격을 막습니다. 핸드셰이크가 없으므로 SS는 TCP 계열 프로토콜 중 첫 바이트 지연이 가장 낮고, 형식이 단순해 완전한 구현이 수백 줄이면 충분해 라우터 펌웨어부터 브라우저 확장까지 널리 이식되어 있습니다.

SS는 UDP 릴레이도 기본으로 지원합니다. 클라이언트가 UDP 데이터그램을 암호화해 서버로 보내 대신 처리하게 하는 방식으로, 게임·음성 통화·QUIC 연결 수립이 이 기능에 의존합니다. Clash 설정의 udp: true가 이 옵션을 켜는 항목이며, 게임용 노드라면 이 옵션을 켜는 것 외에도 서비스 제공자 쪽에서 UDP 릴레이를 제한하지 않는지 확인해야 합니다.

SS에는 simple-obfs, v2ray-plugin 같은 플러그인 생태계도 있어 SS 바깥에 위장이나 WebSocket 전송을 한 겹 더 씌울 수 있으며, mihomo는 plugin과 plugin-opts 항목으로 일부를 지원합니다. 플러그인은 덧붙이는 계층일 뿐 SS 본체 형식은 바뀌지 않습니다.

암호화 방식: AEAD로의 전환

초기 SS는 aes-256-cfb, chacha20-ietf 같은 스트림 암호를 사용해 암호화만 하고 무결성은 검증하지 않았는데, 이후 능동 탐지에 취약한 결함이 드러나 커뮤니티 전체가 AEAD(인증 기능이 있는 암호화) 방식으로 전환했습니다. 현재 주로 쓰이는 세 가지는 aes-128-gcm, aes-256-gcm, chacha20-ietf-poly1305입니다. 앞의 두 가지는 AES-NI 명령어를 지원하는 데스크톱·서버용 프로세서에서 거의 오버헤드가 없고, 뒤의 것은 하드웨어 명령어에 의존하지 않아 스마트폰이나 저사양 라우터의 ARM 칩에서 오히려 더 빠릅니다. 이후 커뮤니티는 2022-blake3-aes-128-gcm 같은 새 암호 방식도 제안했으며, shadowsocks-rust와 mihomo 모두 구현했습니다. BLAKE3로 키를 유도해 재전송 방지를 강화했으므로 신규 배포 시 우선 고려할 만합니다.

적합한 상황과 한계

SS의 한계도 단순함에서 비롯됩니다. 위장 계층이 없어 암호화된 트래픽은 길이가 무작위이고 엔트로피가 높은 데이터 흐름으로 보여 정상 HTTPS의 TLS 레코드와는 형태가 다릅니다. 또한 서버 측 다중 사용자 관리도 정의하지 않아 포트 하나에 키 하나가 대응됩니다. 따라서 SS는 실용적인 범용 선택지로 적합합니다. 구현이 널리 퍼져 있고 오버헤드가 낮으며 유지 관리가 편합니다. 외형 위장이 필요하다면 4장의 Trojan과 3장의 VLESS를 참고하세요.

클라이언트 설정 요점

Clash 설정에서 SS 노드는 server, port, cipher, password 네 항목만 필수이며 udp로 UDP 전달을 제어합니다. cipher는 서버 쪽과 정확히 일치해야 합니다. 암호 방식을 잘못 입력하는 것이 SS 노드가 연결되지 않는 가장 흔한 원인이므로 문제 발생 시 이 항목부터 확인한 뒤 비밀번호와 포트를 확인하세요. 서비스 제공자가 ss:// 공유 링크를 준다면 클라이언트에 가져올 때 아래 항목으로 자동 변환되므로 직접 입력할 필요는 없습니다.

proxies:
  - name: "ss-aead"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

3VMess와 VLESS: V2Ray 계열의 두 세대

VMess와 VLESS는 모두 V2Ray 프로젝트에서 시작됐습니다(이후 V2Fly, Xray 등으로 분화). 전자는 프로젝트의 주력 프로토콜이고, 후자는 전자의 복잡함을 되돌아본 뒤 경량화한 버전입니다. 이 두 세대의 차이를 이해하면 프록시 프로토콜의 핵심 갈림길인 암호화를 어느 계층에 둘 것인가를 이해하게 됩니다.

VMess: 전체 암호화 방식

VMess는 프로토콜 자체가 모든 보안을 처리하는 방식을 택했습니다. 요청 헤더에는 사용자 UUID, 타임스탬프, 검증값이 들어가며 세션 전체가 AES-128-GCM이나 ChaCha20-Poly1305로 암호화되어 외부 TLS에 의존하지 않습니다. 타임스탬프 인증은 클라이언트와 서버의 시계 오차가 약 2분 이내여야 하며, 이는 VMess 문제 해결 시 가장 먼저 확인할 항목입니다. 기기 시간대 오류나 네트워크 시간 동기화 미설정이 인증 실패를 일으킵니다. 초기 VMess의 alterId 항목은 여러 키를 유도하는 용도였지만 안전성을 약화시킨다는 점이 밝혀져 최신 구현에서는 폐기됐습니다. 설정에서 alterId가 0이 아니면 오래된 방식으로 봐야 합니다.

VMess의 UUID는 동시에 사용자 식별 역할도 하며, 서버는 이를 기준으로 다중 사용자 분리와 트래픽 통계를 처리합니다. 이 때문에 vmess:// 공유 링크는 필드가 가장 많습니다. Base64로 인코딩된 JSON에 주소, 포트, UUID, 전송 계층, TLS 여부, 위장 도메인까지 담아야 하기 때문입니다.

VLESS: 암호화를 TLS에 되돌려주다

VLESS라는 이름 자체가 태도를 보여줍니다. VMess의 암호화 계층을 제거하고 프로토콜 헤더에는 UUID와 최소한의 제어 필드만 남기며 암호화는 전부 외부 TLS에 맡깁니다. 이점은 두 가지입니다. 헤더가 짧아져 프로세서가 이중 암호화를 하지 않아도 되고, XTLS Vision 흐름 제어(flow: xtls-rprx-vision)와 함께 쓰면 TLS 레코드를 그대로 전달할 수 있어 암복호화 복사 과정을 한 번 더 줄일 수 있습니다. 대가는 VLESS가 반드시 TLS와 함께 써야 한다는 점입니다. TLS 없이 맨몸으로 쓰는 VLESS는 기밀성이 전혀 없고, mihomo 같은 커널도 TLS가 적용된 VLESS 노드만 받아들입니다.

Xray 계열은 이후 VLESS 위에 REALITY 방식을 추가로 제안했습니다. 자체 인증서를 발급하지 않고 실제 사이트의 TLS 외형을 빌려 핸드셰이크를 완료해 도메인·인증서 유지 관리를 없앤 방식으로, mihomo는 reality-opts 항목으로 지원합니다. 이 역시 TLS 계층에서의 또 다른 절충안으로, 배포는 더 간단해지지만 설정 항목은 늘어나며 일반 사용자는 서비스 제공자가 주는 구독을 그대로 쓰면 됩니다.

전송 계층: WS, gRPC와 중계

V2Ray 계열의 또 다른 퍼즐 조각은 전송 계층(network)입니다. ws는 트래픽을 WebSocket 프레임에 담고, grpc는 HTTP/2 스트림에 담으며 둘 다 TLS를 씌워 일반 웹사이트 트래픽처럼 위장할 수 있습니다. 이 조합의 실질적인 가치는 CDN 뒤에 둘 수 있다는 점입니다. 도메인이 CDN으로 연결되고 CDN이 서버로 되돌아가므로 실제 주소가 드러나지 않고, CDN 접속 지점을 활용해 우회 경로를 개선할 수도 있습니다. Clash 계열 커널은 ws와 grpc 전송을 완전히 지원하며 설정에서는 network, ws-opts, grpc-opts 항목으로 표현합니다.

둘 중 하나를 고른다면

신규 배포라면 VLESS + TLS를, 기존 노드는 VMess를 그대로 쓰면 됩니다. VMess의 전체 암호화는 TLS가 없는 환경에서 여전히 의미가 있지만, 인증서가 있는 조건이라면 VLESS의 낮은 오버헤드와 직접 전달 방식이 전반적으로 우위입니다. 설정은 다음과 같은 형태입니다.

proxies:
  - name: "vless-vision"
    type: vless
    server: example.com
    port: 443
    uuid: "00000000-0000-0000-0000-000000000000"
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: example.com

4Trojan: 위장을 최우선으로 하는 설계 철학

Trojan의 설계 문서는 서두에서 한 마디로 요점을 밝힙니다. 프록시 트래픽을 애써 다른 모습으로 위장시키기보다, 처음부터 다른 것이 되게 하자는 것입니다. Trojan 연결은 겉으로 보면 그냥 표준 TLS 세션이고, 프로토콜 본체는 TLS 안에 숨어 있으며 인증은 비밀번호의 해시값 하나로 처리합니다.

TLS가 곧 본체

Trojan 서버는 443 포트를 열어 두고 겉으로는 평범한 HTTPS 사이트처럼 보입니다. 인증서가 유효하고 핸드셰이크도 표준입니다. 인증에 실패한 연결이 들어오면 실제 웹사이트로 트래픽을 되돌려(fallback) 처리하게 할 수 있습니다. 인증에 통과한 뒤 TLS 레코드 안에 담기는 것은 매우 단순한 Trojan 요청 헤더입니다. 비밀번호 해시, 목적지 주소, 페이로드뿐이며 프로토콜 자체는 어떤 암호화도 하지 않습니다. 암호화는 전부 TLS가 담당합니다. 이는 VLESS의 방향과 같지만 Trojan이 더 먼저 등장했고 형식이 더 단순합니다.

Trojan의 위장은 한 가지를 더 필요로 합니다. 서버가 실제로 웹사이트처럼 보여야 한다는 점입니다. 유효한 인증서만 있고 443 포트에 아무 콘텐츠도 없는 사이트는 능동 탐지 시 오히려 눈에 띄므로, 대부분의 배포는 fallback 뒤에 실제 웹페이지를 붙여 둡니다. 이 부분은 서버 운영에 해당해 클라이언트가 신경 쓸 일은 아니지만, 선택 시 알아 두어야 할 점은 위장이 얼마나 자연스러운지는 서버 쪽 완성도에 달려 있다는 것입니다.

VMess + TLS와의 차이

둘 다 TLS 안에서 프록시를 태우지만, Trojan과 VMess + WS + TLS의 차이는 계층 수에 있습니다. 후자는 TLS 위에 WebSocket, 그 위에 VMess까지 3중 캡슐화이고, 전자는 TLS 위에 Trojan뿐인 2중 구조입니다. 계층이 적을수록 오버헤드가 작고 구현이 간단하지만, 설정할 수 있는 항목도 적어집니다. Trojan에는 전송 계층 옵션이 따로 없고 TCP + TLS 한 가지 형태뿐입니다. CDN 중계가 필요하면 Trojan도 WebSocket을 탈 수 있지만(대부분의 커널이 지원), 그러면 다시 다중 캡슐화 구조로 돌아가게 됩니다.

Trojan의 UDP 지원은 프로토콜 내부 명령어로 처리됩니다. UDP 데이터그램이 TLS 스트림 안에 감싸여 전송되며 클라이언트 설정도 마찬가지로 udp: true로 켭니다. UDP가 TCP 안에 싸여 있어 패킷 손실에 민감한 상황에서는 TCP의 특성을 그대로 물려받는다는 점이 5장에서 다룰 원생 QUIC의 UDP 전달과 대비됩니다.

배포 조건과 클라이언트 설정

Trojan의 단순함에는 조건이 따릅니다. 배포자는 도메인과 유효한 인증서를 갖고 있어야 하며, 인증서는 보통 ACME로 자동 발급하고 도메인을 서버로 연결해 둡니다. 일반 사용자는 이 부분을 서비스 제공자가 처리해 두므로 클라이언트 쪽에서는 server, port, password, sni 네 항목만 필요합니다. sni는 인증서 도메인과 반드시 일치해야 합니다. skip-cert-verify: true는 인증서 검증을 끄는 옵션으로, 이는 TLS의 위조 방지 기능을 포기하는 것과 같아 자체 서명 인증서로 테스트할 때만 임시로 쓰고 정식 설정에서는 false를 유지해야 합니다.

proxies:
  - name: "trojan-tls"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    skip-cert-verify: false
    udp: true

성능 면에서 Trojan의 오버헤드는 순수 TLS 세션과 거의 같습니다. 핸드셰이크는 2~3회 왕복(TLS 1.3은 세션 재사용 시 더 단축)이고 전송 중에는 한 번의 대칭 암복호화만 일어납니다. 데스크톱과 서버에서는 일반 HTTPS 브라우징과 다를 바 없으며, 모바일에서는 TLS 세션 유지와 TCP 킵얼라이브가 배터리 소모의 주요 원인이 됩니다. 자세한 내용은 6장에서 다룹니다.

5Hysteria2와 TUIC: QUIC 세대의 속도 지향 프로토콜

앞의 4개 장에서 다룬 프로토콜은 모두 TCP 위에서 동작합니다. TCP의 신뢰성 있는 전송에는 대가가 따릅니다. 패킷 손실이 발생하면 스트림 전체가 재전송을 기다리며 밀리는 헤드 오브 라인 블로킹 현상이 생겨, 손실률이 높은 회선에서는 처리량이 급격히 떨어집니다. QUIC은 신뢰성 있는 전송을 사용자 공간으로 옮기고 UDP 위에서 동작시켜, 스트림별로 독립적인 재전송이 가능하며 0-RTT 핸드셰이크와 연결 마이그레이션이라는 기본 기능도 함께 제공합니다. Hysteria2와 TUIC은 QUIC 기반 프록시 프로토콜 중 가장 널리 구현된 두 가지입니다.

Hysteria2: 속도 우선

Hysteria2는 Hysteria의 개선판으로, 인증을 단순화하고 제어 로직을 줄이면서 핵심 포인트를 혼잡 제어에 두었습니다. 자체 개발한 Brutal 혼잡 제어는 패킷 손실에도 물러서지 않고 사용자가 지정한 목표 대역폭으로 계속 전송합니다. 패킷 손실률은 높지만 물리적 대역폭은 충분한 회선(대륙 간 무선망, 저녁 혼잡 시간대 출구 회선 등)에서는 TCP 계열 프로토콜보다 처리량이 몇 배나 높아질 수 있습니다. 대가도 분명합니다. Brutal은 네트워크 상황을 살피지 않으므로 목표 대역폭을 너무 높게 잡으면 같은 회선의 다른 트래픽을 밀어낼 수 있고, 통신사의 UDP 제한 정책을 유발할 수도 있습니다. 설정의 up과 down 항목이 이 속도 목표값이며 단위는 Mbps로, 서버의 실제 대역폭에 맞춰 입력해야 하며 무조건 높게 잡는 것이 좋은 것은 아닙니다.

Hysteria2 생태계에는 mihomo가 이미 구현한 실용적인 기능도 있습니다. 포트 호핑입니다. 서버가 포트 구간을 열어 두고 클라이언트가 정해진 규칙에 따라 구간 안에서 포트를 바꿔가며 패킷을 보내며, 설정에서는 ports 항목에 구간 형태로 씁니다. 이 기능은 특정 포트에 대한 속도 제한을 피하기 위한 것으로 링크 계층의 우회 기법이며 프로토콜 본체 형식에는 영향을 주지 않습니다.

TUIC: 저오버헤드 QUIC 캡슐화

TUIC의 목표는 Hysteria2와 다릅니다. QUIC 위에서 추가 오버헤드를 최대한 줄이는 데 집중합니다. 프로토콜 자체가 UDP 전달을 지원하며 두 가지 UDP 모드를 제공합니다. native는 UDP 데이터그램을 QUIC 데이터그램에 직접 매핑하고, quic은 UDP 패킷도 신뢰성 있는 스트림 전송에 포함시킵니다. 전자는 게임, 음성 통화 같이 지연에 민감한 실제 UDP 상황에 적합합니다. TUIC은 QUIC이 기본 제공하는 혼잡 제어를 그대로 사용해 과격한 가속을 하지 않으므로 동작이 더 얌전하고, UDP가 제한되는 네트워크에서도 완만하게 성능이 낮아집니다.

QUIC은 혼잡 제어를 교체 가능한 모듈로 만들었습니다. TUIC의 congestion_control 항목에서는 bbr, cubic 등을 선택할 수 있습니다. 대략적으로 cubic은 보수적인 범용 기본값이고, bbr은 대역폭과 지연을 모델링해 버퍼가 큰 회선에서 더 안정적입니다. 일반 사용자는 기본값을 유지하면 되지만, 속도가 이상할 때 시도해볼 수 있는 옵션이 하나 더 있다는 점은 알아 두면 좋습니다. TUIC의 heartbeat_interval은 하트비트 간격을 제어해 대기 중 배터리 소모에 직접 영향을 주므로 모바일에서는 몇 초 이상으로 넉넉히 잡아도 됩니다.

연결 마이그레이션과 0-RTT

QUIC의 두 가지 특별한 기능은 따로 짚어볼 만합니다. 0-RTT는 같은 서버에 다시 연결할 때 첫 데이터 패킷에 바로 페이로드를 담아 보낼 수 있어 핸드셰이크 왕복을 생략하며, 재연결 시 프록시 체감 속도가 직접 연결에 가까워집니다. 연결 마이그레이션은 연결을 4튜플이 아니라 Connection ID로 식별하므로, 휴대폰이 Wi-Fi에서 셀룰러로 전환되거나 기지국을 이동해 IP가 바뀌어도 연결이 끊기거나 다시 맺어지지 않아 진행 중인 다운로드나 통화가 끊김 없이 이어집니다. 이 두 기능은 데스크톱보다 모바일에서 훨씬 큰 의미를 가지며 6장에서 다시 다룹니다.

proxies:
  - name: "hy2"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    up: 30
    down: 200
    sni: example.com

6속도, 리소스 사용량, 모바일 배터리 소모: 성능 비교

프로토콜 비교는 어떤 게 가장 빠른가로 오해받기 쉽습니다. 솔직한 답은, 회선 상태가 좋을 때는 6종 프로토콜의 처리량 차이가 거의 느껴지지 않을 정도로 작고 병목은 서버 대역폭과 통신사 회선에 있다는 것입니다. 프로토콜 차이는 세 가지 극단적인 상황에서만 두드러집니다. 핸드셰이크 지연, 불안정한 네트워크에서의 처리량, 기기 오버헤드입니다. 이번 장은 이 세 기준으로 비교합니다.

과대평가되기 쉬운 또 다른 지표는 속도 테스트 점수입니다. 속도 테스트 사이트가 대역폭을 얼마나 채울 수 있는지는 서버 출구와 저녁 혼잡 상황에 더 크게 좌우됩니다. 프로토콜 점수보다 같은 회선에서 프로토콜만 바꿔 여러 번 측정해 비교하는 소박한 방법이 더 참고할 만합니다. 직접 실험해 보려면 서버와 시간대를 고정하고 프로토콜 종류만 바꿔 각각 세 번씩 측정해 중앙값을 구한 뒤, 시간대를 바꿔 다시 측정하세요. 변수가 프로토콜뿐일 때만 결론에 의미가 있습니다.

핸드셰이크와 첫 바이트 지연

TCP 계열 프로토콜은 먼저 TCP 핸드셰이크(1회 왕복)를 마치고, TLS를 쓰는 경우 TLS 핸드셰이크(TLS 1.3은 1회 왕복, 세션 재사용 시 0)가 추가됩니다. SS는 프로토콜 차원의 핸드셰이크가 없어 전체 오버헤드가 가장 낮고, Trojan과 VLESS가 그 다음입니다. QUIC 계열은 첫 연결이 1회 왕복이고 재연결은 0-RTT입니다. 200밀리초급 지연의 대륙 간 회선에서 재접속 상황이라면 Hysteria2와 TUIC의 첫 바이트가 TCP + TLS 계열보다 거의 0.5초 가까이 빠를 수 있어, 웹 서핑이나 짧은 API 호출에서 체감이 확실합니다.

프로세서, 메모리, 기기 오버헤드

전송 중 프로세서 소모는 주로 대칭 암호화에서 발생합니다. AES-NI가 있는 x86 기기에서는 AES-GCM이 코어 하나로도 수 Gbps를 처리할 수 있어 프로토콜 오버헤드를 무시할 수 있고, AES 명령어가 없는 ARM 기기에서는 ChaCha20-Poly1305가 AES-GCM보다 약 2~3배 빨라 모바일에서 chacha20 계열 암호를 추천하는 이유입니다. 메모리 측면에서는 각 프로토콜의 연결당 사용량이 모두 MB 단위 이하로, 실제 메모리를 많이 쓰는 것은 커널의 규칙 세트와 연결 추적 테이블이며 프로토콜과는 무관합니다. 성능이 낮은 라우터 같은 기기에서는 이중 암호화(VMess 내부 암호화에 외부 TLS까지)를 피하는 것만으로도 여유 자원을 상당히 확보할 수 있으며, 이는 VLESS와 Trojan이 VMess에 대해 갖는 실질적인 강점입니다.

모바일 배터리 소모

모바일에서 배터리를 많이 쓰는 요인은 암복호화가 아니라 무선 모듈이 깨어나는 횟수입니다. TCP 장기 연결은 킵얼라이브 패킷으로 주소 매핑을 유지하는데, 깨어날 때마다 전력을 소모합니다. Wi-Fi에서 셀룰러로 바뀌면 TCP 연결이 끊어지고 재연결 핸드셰이크도 또 한 번의 무선 활동을 일으킵니다. QUIC의 연결 마이그레이션은 전환 시에도 연결이 끊기지 않게 해 주고, 0-RTT는 필요한 재연결을 더 빠르게 만들어, 두 효과가 겹쳐 이동이 잦은 하루 사용 패턴에서는 Hysteria2와 TUIC이 TCP 계열보다 배터리와 트래픽 소모가 모두 낮습니다. 반대 요인도 있는데, 하트비트 간격을 너무 짧게 설정하면 대기 중 깨어나는 빈도가 오히려 늘어나므로 관련 값은 짧게보다는 길게 잡는 편이 낫습니다.

6가지 기준 비교표

표에서 볼 수 있듯 모든 면에서 완벽한 프로토콜은 없습니다. SS는 구현 범위와 낮은 지연에서 강점이 있고, QUIC 계열은 불안정한 네트워크와 모바일 상황에서, Trojan과 VLESS는 위장과 낮은 오버헤드에서 강점이 있습니다. 실제로는 먼저 구독이 제공하는 프로토콜을 확인하고(8장), 그중에서 이번 장의 세 기준으로 선택하는 것이 현실적입니다.

7커널 계보: 오리지널 Clash, Meta, mihomo

Clash라는 이름은 생태계 안에서 동시에 세 가지를 가리킵니다. 커널, 설정 형식, 클라이언트 계열입니다. 이 세 층을 구분하는 것이 호환성 논의를 이해하는 전제입니다. 커널은 실제로 동작하는 프로그램으로 로컬 포트를 감시하고 규칙을 해석해 프로토콜에 따라 패킷을 전송합니다. 클라이언트는 커널의 그래픽 껍데기입니다. 설정 형식은 둘 사이의 약속입니다.

오리지널 Clash의 종료

오리지널 Clash 커널은 Dreamacro가 Go로 작성해 유지 관리했으며, YAML 설정 형식과 규칙 엔진, 정책 그룹 체계를 확립했습니다. 오늘날 모든 Clash 계열 클라이언트의 문법은 이 정의에서 출발합니다. 2023년 말 작성자는 저장소를 아카이브 처리하고 유지 관리를 중단했으며, 비공개였던 Premium 분기도 함께 업데이트를 멈췄습니다. 아카이브 처리됐다고 못 쓰게 된 것은 아니어서, 오리지널 커널은 지금도 동작하며 SS, VMess, Trojan 같은 기존 프로토콜은 그대로 작동합니다. 다만 Hysteria2, TUIC, VLESS 같은 새 프로토콜이나 rule-set 같은 신규 기능은 오리지널 커널에 영원히 추가되지 않습니다.

Clash Meta와 mihomo로의 계승

Clash Meta는 오리지널이 업데이트를 멈추기 전부터 커뮤니티가 시작한 강화 분기로, 오리지널에 없던 프로토콜과 기능을 채우는 것이 목표였습니다. 오리지널이 아카이브된 뒤 사실상의 계승자가 되었고, 이후 mihomo로 이름을 바꿨습니다. 오리지널과 비교했을 때 mihomo의 주요 추가 사항은 다음과 같습니다. VLESS, Hysteria2, TUIC, WireGuard 등 프로토콜 지원, 대량의 규칙을 바이너리 형식으로 컴파일해 필요할 때만 불러오는 rule-set(줄 단위 텍스트 매칭 대체), DNS 모듈의 nameserver-policy·fallback-filter 같은 세밀한 제어, 그리고 TUN 인바운드·프로세스명 매칭 같은 시스템 수준 기능입니다. 현재 활발히 쓰이는 클라이언트 - Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, Clash Meta for Android - 는 모두 mihomo를 커널로 사용합니다. 생태계 각 프로젝트의 계보는 《Clash 오픈소스 생태계 정리》 글에 전체적으로 정리되어 있으며, 이 문서는 선택과 관련된 부분만 다룹니다.

설정 호환성

호환 방향은 한쪽으로만 흐릅니다. 오리지널용으로 작성한 설정은 대부분 mihomo에서 그대로 동작하지만, mihomo용으로 작성한 설정 중 새 항목을 쓴 부분은 오리지널이 인식하지 못합니다. 실무에서는 두 가지만 기억하면 됩니다. 첫째, 오래된 클라이언트(Clash for Windows, 구버전 ClashX)는 오리지널 항목만 인식해 구독에 hysteria2 같은 유형의 노드가 있으면 건너뛰거나 오류를 냅니다. 둘째, mihomo는 일부 항목의 의미를 조정했습니다. 예를 들어 dns 항목의 default-nameserver가 필수로 바뀌었습니다. 오리지널에서 설정을 옮겨 왔을 때 실행 오류가 나면 오류 줄을 공식 문서와 하나씩 대조하면 되며, 대부분은 항목을 다시 쓰는 것이 아니라 채워 넣는 정도로 해결됩니다.

클라이언트와 커널의 대응 관계

다운로드 페이지의 목록은 이 기준으로 구성되어 있습니다. 전 플랫폼에서 우선 추천하는 Clash Plus, 데스크톱 주류인 Clash Verge Rev와 FlClash, 안드로이드용 Clash Meta for Android는 모두 mihomo 계열입니다. 업데이트가 중단된 Clash for Windows와 ClashX Meta는 구형 커널 시대에 머물러 있어 아카이브 목적으로만 남겨 두었습니다. 그래픽 클라이언트에서는 커널 전환이 보통 설정 하나로 처리됩니다. Clash Plus와 Clash Verge Rev는 설정 페이지에서 커널 버전과 업데이트 채널을 제공하고, FlClash는 커널을 내장해 클라이언트 전체와 함께 업그레이드합니다. 일반 사용자는 커널 바이너리를 직접 교체할 필요가 없습니다. 수동 교체는 고급 사용자용 작업이며, 교체 후에는 -t 옵션으로 설정을 먼저 검증한 뒤 실행하는 것이 안전합니다. 실용적인 결론은, 새로 설치한다면 mihomo 계열 클라이언트를 고르고, 기존 클라이언트는 문제없이 동작하는 동안 계속 쓰다가 문제가 생기면 그때 옮기면 됩니다.

8구독 형식과 설정 호환성

구독은 서비스 제공자와 클라이언트 사이의 전달 형식입니다. URL 하나를 클라이언트가 주기적으로 가져와 노드와 규칙 묶음을 받습니다. 생태계에는 두 가지 형태가 함께 존재합니다. Clash 네이티브 구독(완전한 YAML 하나)과 범용 공유 링크(ss://, vmess:// 등 링크 모음)입니다. mihomo 계열 클라이언트는 둘 다 가져올 수 있지만 담긴 정보량은 다릅니다.

Clash 네이티브 구독

Clash 구독이 반환하는 것은 거의 완전한 config.yaml입니다. proxies 항목에 노드를 나열하고, proxy-groups 항목에 정책 그룹을 미리 구성하고, rules 항목에 분배 규칙을 담습니다. 서비스 제공자가 자동 선택, 수동 선택, 대체 그룹 등을 미리 배치해 두므로 가져오기만 하면 바로 쓸 수 있습니다. 장점은 규칙과 노드를 같은 곳에서 관리해 서비스 제공자가 규칙을 업데이트해도 사용자가 신경 쓸 필요가 없다는 것이고, 단점은 서비스마다 규칙 성향이 달라 구독을 바꾸면 분배 습관 전체가 바뀐다는 점입니다. mihomo 계열 클라이언트로 Clash 구독을 가져올 때는 보통 노드만 가져오기와 전체 가져오기를 선택할 수 있습니다. 전자는 로컬 규칙을 유지하고, 후자는 규칙까지 서비스 제공자 버전으로 통째로 바꿉니다. 이 옵션을 이해해 두면 규칙이 갑자기 바뀌어 당황하는 일을 줄일 수 있습니다.

범용 공유 링크와 구독 변환

범용 구독은 줄 단위로 나열된 공유 링크를 반환합니다. ss://와 trojan://는 URI 형식이고, vmess://는 Base64로 인코딩된 JSON이며, vless://, hysteria2://, tuic://도 각자의 URI 규칙을 따릅니다. 이런 구독에는 노드 정보만 있고 규칙은 없어 클라이언트가 자체 내장 규칙 템플릿을 적용합니다. 범용 구독을 Clash 형식으로 바꾸는 작업을 구독 변환이라고 하며, 온라인 서비스나 자체 호스팅 프로그램이 템플릿에 맞춰 YAML을 생성합니다. 변환의 개인정보 측면도 알아 두어야 합니다. 구독 링크에는 서버 주소와 인증 정보가 들어 있어 제3자 서비스로 변환하면 노드 정보를 그쪽에 넘기는 것과 같습니다. 민감한 노드는 자체 호스팅 변환이나 클라이언트 자체의 파싱 기능(mihomo 계열 클라이언트는 대부분 범용 구독을 직접 가져오기 지원)을 쓰는 것이 좋습니다.

필드 단위의 커널 차이

같은 노드라도 커널마다 필드 작성 방식은 거의 같지만, 차이는 세 곳에 집중됩니다. 첫째, 새 프로토콜 항목: hysteria2의 up, down이나 tuic의 udp_relay_mode는 mihomo만 인식합니다. 둘째, 전송 계층 중첩: ws-opts 아래의 headers, grpc-opts의 service-name은 각 파서마다 기본값 처리 방식이 다릅니다. 셋째, 규칙 항목: rule-providers와 rule-set은 mihomo 확장 기능으로 오리지널 커널에서는 오류가 발생합니다. 구독 YAML을 직접 수정할 때는 클라이언트의 설정 검증이나 커널의 테스트 옵션으로 한 번 확인한 뒤 실행하는 것이 재시작해서 오류를 찾는 것보다 빠릅니다.

mihomo -d /etc/mihomo -t

mihomo 설정에서 구독은 더 체계적인 형태를 가지기도 합니다. proxy-providers로 노드 목록을 외부 소스로 선언해 interval에 따라 주기적으로 갱신하고, health-check로 주기적으로 속도를 측정하며, url-test 정책 그룹과 함께 써서 자동으로 최적 노드를 고르게 할 수 있습니다. 서비스 제공자의 구독은 본질적으로 원격 proxy-provider 하나이며, 이 개념을 이해하면 여러 구독을 함께 쓰거나 로컬 노드와 구독을 섞어 구성하는 것도 같은 원리의 조합일 뿐입니다.

구독은 노드가 어디서 오는지를 해결하고, 규칙은 트래픽이 어디로 가는지를 결정합니다. 구독에 딸린 규칙이 맞지 않으면 클라이언트에서 덮어쓰거나 직접 규칙 세트를 만들 수 있습니다. 규칙 문법, 매칭 순서, MATCH 대체 규칙의 완전한 작성법은 《Clash 사용자 정의 규칙 작성법》과 《Clash 규칙 기반 트래픽 분배 실전》 두 글을 참고하세요. 이 문서에서는 더 다루지 않습니다.

9상황별 선택: 결정표와 전체 원칙

앞의 8개 장에서 다룬 내용을 결정표로 정리하기 전에 전체 원칙 하나를 먼저 세워 둡니다. 프로토콜 선택의 자유도는 대부분 서비스 제공자 쪽에 있습니다. 일반 사용자의 실제 선택 순서는 먼저 구독이 어떤 프로토콜을 제공하는지 확인하고, 그중에서 상황에 맞게 고르는 것입니다. 서버를 직접 운영하는 경우에만 완전한 프로토콜 선택권이 있으며, 그 고려 사항도 이번 장에서 함께 다룹니다.

데스크톱 일상 사용: 안정성 우선

데스크톱 환경은 회선이 안정적이고 기기 성능도 넉넉해 프로토콜 차이가 가장 작으므로 구독의 기본 노드를 그대로 쓰면 됩니다. 같은 구독에 여러 프로토콜이 있다면 VLESS나 Trojan(낮은 오버헤드) 또는 SS(낮은 지연)를 우선하세요. 클라이언트는 전 플랫폼에서 Clash Plus를 우선 추천합니다. mihomo 커널, 한국어 지원 여부와 무관하게 직관적인 인터페이스, 설정 덮어쓰기와 시각화 편집까지 갖추고 있으며, 다운로드와 설치 방법은 다운로드 페이지에서 확인할 수 있습니다.

모바일: 배터리와 네트워크 전환

모바일 환경의 두 가지 문제는 네트워크 전환과 대기 배터리 소모입니다. 구독에 Hysteria2나 TUIC 노드가 있다면 모바일 네트워크에서 우선 사용하세요. 연결 마이그레이션이 Wi-Fi와 셀룰러 전환 시 끊김을 없애 주고, 0-RTT가 필요한 재연결을 빠르게 해 줍니다. TCP 계열 노드만 있다면 킵얼라이브 관련 값을 넉넉히 늘리고 쓰지 않는 UDP 전달을 끄는 것만으로도 배터리를 절약할 수 있습니다. iOS와 Android의 구체적인 클라이언트와 가져오기 절차는 입문 가이드에 플랫폼별로 정리되어 있습니다.

게임과 실시간 음성·영상

게임, 음성 통화, 영상 회의는 UDP와 지연에 가장 민감합니다. udp: true가 켜져 있는 노드를 우선 선택하세요. QUIC 계열(특히 TUIC의 native 모드)이 모바일 네트워크에서 가장 안정적입니다. 게임을 프록시로 태우고 싶다면 게임 프로세스나 도메인을 지연이 가장 낮은 정책 그룹으로 지정하는 것도 잊지 마세요. 프로토콜은 개별 연결의 품질을 결정하고, 규칙은 그것이 실제로 쓰이는지를 결정합니다.

불안정한 네트워크와 손실률 높은 회선

대륙 간 회선, 저녁 혼잡 시간대, 무선 중계처럼 패킷 손실률이 늘 높은 환경은 QUIC 계열이 강점을 보이는 영역입니다. Hysteria2는 설정한 대역폭대로 계속 전송해 처리량 유지력이 TCP 계열보다 뚜렷하게 낫고, TUIC은 동작이 온화해 UDP가 제한될 수 있는 환경에 적합합니다. Hysteria2를 쓸 때는 up, down을 실제 대역폭에 맞게 입력해야 합니다. 과장해서 높이면 혼잡이 오히려 심해집니다. UDP를 전혀 쓸 수 없다면 SS나 Trojan으로 돌아가고 처리량 손실을 감수하세요. 이는 물리적 한계이지 설정 문제가 아닙니다.

라우터와 서버

라우터, NAS, 서버에는 그래픽 인터페이스가 없으므로 mihomo 커널을 직접 실행하는 것이 가장 깔끔한 방법입니다. config.yaml 하나와 부팅 시 자동 실행 서비스만 있으면 됩니다. 저성능 라우터의 프로토콜 선택은 6장의 기준을 따릅니다. SS(chacha20 계열)나 VLESS를 우선하고 이중 암호화는 피하세요. 메모리가 부족하면 대용량 텍스트 규칙 대신 rule-set을 쓰세요. OpenWrt 우회 라우터의 전체 배포 기록은 《OpenWrt 라우터에 mihomo 커널 배포하기》 글에서 확인할 수 있습니다.

서버 직접 운영

직접 운영하는 쪽의 선택 흐름은 다음과 같습니다. 도메인과 인증서가 있다면 Trojan이나 VLESS + TLS를 선택해 외형과 오버헤드 모두 좋은 결과를 얻을 수 있습니다. 도메인·인증서 관리를 원하지 않는다면 SS(2022 계열 암호)가 가장 손이 덜 갑니다. 회선의 패킷 손실이 심하고 UDP가 원활하다면 Hysteria2를 추가로 배치해 TCP 계열과 함께 두고 상황에 따라 전환하세요. 프로토콜 외에도 직접 운영에서는 시스템 업데이트, 키 강도, 관리 화면 노출 관리가 더 중요하며 이는 이 문서의 범위를 벗어나지만 프로토콜 자체보다 가볍게 볼 사안은 아닙니다.

결정표

프로토콜은 링크를 이루는 한 요소일 뿐 전부가 아닙니다. 규칙은 분배가 얼마나 정교한지를 결정하고, DNS는 해석이 얼마나 깨끗한지를 결정하며, 커널과 클라이언트는 기능의 한계를 결정합니다. 셋 다 프로토콜만큼 중요합니다. DNS의 nameserver와 fallback 역할 구분은 《Clash DNS 설정 상세 가이드》에서, 흔한 연결 오류 해결 방법은 자주 묻는 질문 페이지에서 확인할 수 있습니다. 이 문서를 읽고도 확신이 서지 않는다면 입문 가이드로 돌아가 기본 설정을 먼저 실행해 본 뒤 하나씩 바꿔가며 실험하는 순서가 가장 헤매지 않는 방법입니다.