Clash 프로토콜 및 커널 기술 레퍼런스

01 · SELECTION MODEL

프로토콜·전송 계층·클라이언트 기능을 먼저 구분하세요

프로토콜 이름만으로는 완전한 연결 구성이 아닙니다

Clash 클라이언트의 노드 목록에서는 보통 ss, vmess, trojan, vless, hysteria2, tuic를 먼저 확인하게 됩니다. 이 이름은 프록시 세션의 인증·캡슐화·데이터 전송 방식을 나타내지만, 완전한 네트워크 조건 전체를 의미하지는 않습니다. 실제 성능은 TCP 또는 UDP 사용 여부, TLS 적용 여부, WebSocket이나 gRPC 사용 여부, 서버와의 거리, 경로의 패킷 손실, 혼잡 제어, 도메인 해석 방식, 클라이언트 커널 구현에도 좌우됩니다.

예를 들어 같은 VLESS라도 TCP 연결과 WebSocket 기반 연결은 핸드셰이크 비용이 다릅니다. 같은 Shadowsocks라도 암호화 방식에 따라 구형 기기의 CPU 부담이 달라집니다. Hysteria2와 TUIC은 모두 QUIC을 기반으로 하지만 세션 관리, 인증 필드와 혼잡 제어 방식은 서로 다릅니다. 전송 설정을 무시하고 프로토콜 이름만 비교하면 서버 품질, 네트워크 경로와 프로토콜 설계를 뒤섞기 쉽습니다.

따라서 세 계층으로 나누어 확인해야 합니다. 첫째는 노드 프로토콜로, 인증과 기본 캡슐화를 결정합니다. 둘째는 전송·보안 설정으로 network, tls, servername, ALPN, 혼잡 제어와 UDP 릴레이 등이 해당합니다. 셋째는 클라이언트 기능입니다. 커널이 해당 필드를 인식하는지, 그래픽 인터페이스에서 모두 편집할 수 있는지, Android 백그라운드에서 안정적으로 동작하는지, 구독 변환 과정에서 원본 설정이 보존되는지를 확인해야 합니다. 세 계층이 모두 맞아야 노드가 예상대로 연결됩니다.

속도 결론은 테스트 조건과 함께 해석해야 합니다

프로토콜에는 환경과 무관한 고정 속도 순위가 없습니다. 가까운 거리와 낮은 손실률의 회선에서는 TCP만으로도 충분히 안정적이며, 속도 차이는 서버 부하에서 비롯될 수 있습니다. 왕복 지연이 크거나 변동이 심한 모바일 네트워크에서는 QUIC 계열이 전송을 더 빠르게 복구할 수 있지만, 통신사가 UDP를 처리하는 방식에 따라 장점이 사라질 수도 있습니다. 노드 지연 시간은 탐색 요청의 왕복 시간일 뿐, 웹페이지 최초 로딩 속도·파일 처리량·동영상 버퍼링 성능과 같지 않습니다.

합리적인 비교 방법은 클라이언트, 커널, 서버 지역, 테스트 시간과 규칙 모드를 고정한 뒤 최초 연결 시간, 지속 처리량, 네트워크 전환 후 복구 시간, 기기 배터리 소모를 각각 기록하는 것입니다. 단 한 번의 무선 흔들림을 배제하려면 여러 차례 테스트해야 합니다. 구독의 여러 프로토콜이 서로 다른 서버에서 제공된다면 결과는 노드 전체 품질 비교에만 사용할 수 있으며, 프로토콜 자체의 우열을 판단할 수 없습니다.

프로토콜 인기도보다 사용 조건부터 확인하세요

프로토콜 선택은 먼저 네 가지 질문에 답해야 합니다. 클라이언트 커널이 지원하는가, 구독 설정이 온전히 전달되는가, 현재 네트워크에서 UDP가 안정적으로 제공되는가, 기기를 장시간 백그라운드에서 실행해야 하는가입니다. 데스크톱은 더 많은 메모리 사용량을 감수할 수 있지만, 모바일에서는 무선 통신 모듈 깨우기, 재연결 빈도와 배터리 최적화를 추가로 고려해야 합니다. 라우터는 CPU 아키텍처, 메모리 용량과 하드웨어 가속 능력의 제약도 받습니다. 컴퓨터에서 안정적인 노드가 저전력 기기에서 온 가족의 트래픽을 장시간 처리하기에 적합하다는 뜻은 아닙니다.

안정적인 연결과 폭넓은 호환성이 목적이라면 검증된 SS와 Trojan이 배포와 마이그레이션에 유리한 경우가 많습니다. 최신 전송 조합이 필요하다면 커널 지원을 확인한 뒤 VLESS를 선택할 수 있습니다. 지연이 크거나 패킷 손실이 있는 회선에서는 Hysteria2와 TUIC을 테스트하되, TCP 노드를 대체용으로 함께 보관하세요. VMess는 기존 구독에서 흔히 사용되므로 계속 사용해도 문제없습니다. 새 설정에 적용할지는 이름의 신구가 아니라 서버 생태계와 클라이언트 호환 범위로 판단해야 합니다.

이후 섹션에서는 프로토콜 계열, 성능 요소, 커널 관계와 상황별 선택을 차례로 다룹니다. 현재 문제가 “연결은 됐지만 웹페이지가 열리지 않음”이라면 즉시 프로토콜을 바꾸기보다 8단계 네트워크 문제 해결 체크리스트에 따라 노드, DNS, 규칙과 시스템 시간을 먼저 확인하세요. 연결 장애와 프로토콜 선택은 별개의 문제이므로 나누어 처리해야 안정적인 결론을 얻기 쉽습니다.

02 · SS / VMESS

Shadowsocks와 VMess: 검증된 구현과 상태 기반 세션

Shadowsocks의 설계 핵심

Shadowsocks는 설정에서 보통 ss로 표기하며, 핵심 구조가 비교적 단순합니다. 클라이언트가 사전 공유 비밀번호로 키를 파생한 뒤 프록시 트래픽을 암호화해 서버로 전달합니다. 최신 설정은 대개 AEAD 또는 2022 계열 암호화 방식을 사용합니다. 프로토콜 헤더가 가볍고 클라이언트 구현이 널리 보급되어 있으며 TCP와 UDP 전달 경로도 성숙해 호환성 기준으로 자주 활용됩니다.

SS의 장점은 “어떤 환경에서도 가장 빠르다”는 데 있지 않고, 구현 수가 많고 설정 필드가 적으며 리소스 사용량을 예측하기 쉽다는 데 있습니다. 일반 웹 탐색, 소프트웨어 업데이트, 장시간 연결과 보편적인 UDP 애플리케이션에서는 대체로 안정적인 결과를 제공합니다. 성능이 낮은 라우터에서는 암호화 방식이 CPU 사용률에 큰 영향을 줍니다. 하드웨어 가속을 지원하는 AES 플랫폼은 AES-GCM이 적합할 수 있고, 일부 모바일 프로세서나 다른 아키텍처에서는 ChaCha20-Poly1305가 더 균형 잡힌 결과를 낼 수 있습니다. 알고리즘 이름만 보고 속도를 판단하지 말고 실제 기기 부하를 확인해야 합니다.

2022 계열 방식은 키와 세션 처리 방식을 개선했지만 클라이언트와 서버가 모두 지원해야 합니다. 구독이 새 방식을 잘못된 이전 필드로 낮춰 변환하면 흔히 속도가 느려지는 대신 인증 자체가 실패합니다. 가져온 뒤 cipher와 password가 온전히 유지되었는지, 특히 비밀번호가 서버에서 요구하는 키 형식에 맞는지 확인하세요. 그래픽 인터페이스에 노드 이름만 표시된다면 설정을 내보내거나 원본 Profile을 열어 확인할 수 있습니다.

VMess의 상태와 시간 조건

VMess는 사용자 식별자로 인증하고 세션 관련 처리를 포함합니다. Clash 설정에서 흔히 확인하는 필드는 uuid, alterId, cipher, 전송 네트워크와 TLS 설정입니다. 최신 서버는 단순화된 인증 조합을 사용하는 경우가 많지만, 오래된 구독에는 과거 필드가 남아 있을 수 있습니다. 설정 출처가 다양하므로 VMess 노드에서는 이름보다 필드 조합이 서버와 일치하는지를 우선 확인해야 합니다.

VMess는 시스템 시간의 영향을 더 크게 받습니다. Android나 데스크톱의 시간이 크게 어긋나면 노드가 표시되고 네트워크 권한도 정상인데 핸드셰이크만 계속 실패할 수 있습니다. 이때 클라이언트를 다시 설치해도 소용이 없으므로 시스템 자동 시간과 자동 시간대를 먼저 켠 뒤 다시 연결하세요. 기업 네트워크, 가상 머신 스냅샷과 장기간 오프라인 상태였던 기기에서는 시간 오차가 더 쉽게 발생합니다.

VMess는 TCP, WebSocket, HTTP, gRPC 등의 전송 위에 구성할 수 있습니다. 전송 계층은 배포 유연성을 높이지만 설정 항목도 늘립니다. WebSocket 노드는 경로와 Host가 일치해야 하고, TLS 노드는 서버 이름과 인증서 이름이 맞아야 하며, gRPC 노드는 서비스 이름이 정확해야 합니다. 구독 변환 과정에서 어느 하나의 필드라도 빠지면 연결이 실패할 수 있습니다. 따라서 VMess 호환성은 “커널이 VMess를 지원하는가”만으로 판단할 수 없고, 구독에서 사용하는 구체적인 전송 조합까지 확인해야 합니다.

적용 범위와 한계

설정이 단순하고 여러 클라이언트 간 마이그레이션이 편해야 한다면 SS가 대체로 무난한 선택입니다. 기존 VMess 구독이 안정적으로 작동한다면 프로토콜 이름만 보고 설정을 바꿀 필요는 없습니다. 여러 클라이언트 사이를 자주 오가는 사용자라면 VMess 노드는 원본 구독을 우선 보존하고 여러 단계의 변환을 피하는 것이 좋습니다. 변환을 거칠 때마다 필드 이름 변경, 기본값 변화와 전송 매개변수 누락 가능성이 커집니다.

Android에서 장시간 실행할 때 두 프로토콜의 기본 배터리 소모는 보통 프로토콜 이름이 아니라 실제 트래픽, TLS 연결 수, UDP 활동량, DNS 모드와 지연 테스트 빈도로 결정됩니다. 백그라운드 배터리 사용량이 갑자기 늘었다면 Android 백그라운드 배터리 소모와 백그라운드 실행 설정을 참고해 고빈도 자동 속도 측정을 끄고 제조사 배터리 정책이 VPN 서비스를 반복 종료하는지 확인하세요.

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

이 예시는 mihomo에서 호환되는 기본 필드 구조를 보여줍니다. 도메인, 포트와 비밀번호는 구독에서 제공한 실제 값으로 바꿔야 합니다. 수동으로 입력할 때는 YAML 들여쓰기를 일관되게 유지하고 탭을 사용하지 마세요. 클라이언트가 구독을 관리한다면 업데이트 때마다 로컬 사본을 다시 수정하기보다 원본 설정에서 우선 고치는 것이 좋습니다.

03 · TROJAN / VLESS

Trojan과 VLESS: TLS 세션과 간결한 인증

Trojan의 연결 구조

Trojan은 보통 TLS를 연결 기반으로 사용하며, 클라이언트는 비밀번호로 인증합니다. 핵심 설정은 서버 주소, 포트, 비밀번호, SNI에 해당하는 servername, 인증서 검증과 UDP 활성화 여부입니다. 필드 수는 많지 않지만 TLS 이름은 정확해야 합니다. 서버 주소는 IP를 사용할 수 있어도 SNI에는 인증서에 대응하는 도메인을 입력해야 합니다. IP를 서버 이름으로도 사용하면 인증서 검증이 통과되지 않는 경우가 많습니다.

Trojan의 일반적인 장점은 성숙한 TLS 스택을 기반으로 한다는 점이며, 데스크톱과 모바일 시스템 모두에서 구현이 안정적입니다. 성능은 TLS 핸드셰이크, 연결 재사용, 서버 설정과 회선 품질의 영향을 주로 받습니다. 이미 연결된 장시간 세션은 전송할 때마다 전체 핸드셰이크를 반복하지 않으므로 지속 처리량이 대체로 안정적입니다. 짧은 연결이 많은 환경에서는 연결 재사용과 DNS 결과가 더 중요하며, 암호화 비용만으로는 충분히 설명하기 어렵습니다.

클라이언트에는 “인증서 검증 건너뛰기”와 같은 옵션이 있지만 장기적인 해결책으로 사용해서는 안 됩니다. 인증서 오류는 대개 시스템 시간, SNI, 도메인 또는 서버 인증서 설정이 서로 맞지 않음을 의미합니다. 검증을 임시로 끄면 원인을 가리고 기존 보안 경계를 바꾸게 됩니다. 자동 시간 설정을 확인하고 servername을 대조한 뒤 구독에서 해당 필드가 유지되었는지 점검하고, 마지막으로 서버 관리자가 인증서 체인을 확인하는 순서가 올바릅니다.

VLESS의 역할 범위

VLESS는 인증과 전송 보안을 분리해 처리하며, 전통적인 의미의 내장 암호화 계층은 제공하지 않습니다. 보통 TLS나 지원되는 다른 보안 전송에 의존합니다. UUID 계열 식별자로 인증하고 프로토콜 헤더가 비교적 간결하며 TCP, WebSocket, gRPC 등의 전송과 조합할 수 있습니다. 일부 설정에는 흐름 제어 또는 Reality 관련 필드도 포함되지만, 사용 가능 여부는 서버 구현과 클라이언트 커널에 달려 있습니다.

“VLESS 지원”은 커널이 기본 프로토콜을 인식한다는 뜻일 뿐 모든 확장을 지원한다는 의미는 아닙니다. 구형 오리지널 Clash는 VLESS와 후속 확장의 지원 범위가 제한적이었고, Meta 계열을 이어받은 mihomo는 더 많은 필드를 지원합니다. Clash Plus, Clash Verge Rev, FlClash 등을 사용할 때는 실제로 내장된 커널과 설정 입력 경로도 확인해야 합니다. 그래픽 인터페이스에서 일반 필드만 제공해도 구독 가져오기로 더 많은 매개변수를 보존할 수 있지만, 반대로 인터페이스가 인식하지 못하는 값이 내부 변환 과정에서 삭제될 수도 있습니다.

VLESS 설정은 기본 계층부터 순서대로 점검해야 합니다. 먼저 주소, 포트와 UUID를 확인하고, 다음으로 TLS, 서버 이름과 전송 유형을 살핀 뒤, 마지막으로 경로, 서비스 이름, 흐름 제어와 Reality 매개변수를 확인하세요. 여러 필드를 한꺼번에 바꾸면 연결이 복구된 뒤 실제 원인을 알 수 없습니다. 구독 업데이트가 로컬 수정을 덮어쓰는 것도 흔한 문제이므로, 검증이 끝나면 수정 사항을 구독 원본이나 클라이언트의 영구 오버라이드 계층에 반영해야 합니다.

두 프로토콜 중 무엇을 선택할까

Trojan은 필드가 비교적 집중되어 있고 TLS 설정이 명확하며 여러 클라이언트로 옮기기 쉬운 환경에 적합합니다. VLESS는 서버가 해당 생태계를 사용하고 클라이언트가 mihomo 등 호환 커널을 명확히 사용하는 경우에 더 적합합니다. 어느 쪽도 서버 회선 품질을 뛰어넘을 수는 없습니다. Trojan과 VLESS가 서로 다른 서버에 있다면 속도 측정 결과로 특정 프로토콜이 더 효율적이라고 증명할 수 없습니다. 같은 서버·같은 회선·같은 시간대에 비교해야 참고할 만한 결과를 얻을 수 있습니다.

모바일에서 사용할 때 지속적인 TLS 세션 자체가 비정상적인 배터리 소모를 일으키는 경우는 드뭅니다. 실제 배터리에 영향을 주는 요인은 연결이 자주 끊기는지, 시스템이 VPN 서비스를 반복 실행하는지, 앱이 URL 테스트를 계속 수행하는지, QUIC·음성·게임 등의 UDP 트래픽이 장시간 활성 상태인지입니다. 올바르게 설정되어 안정적으로 연결되는 Trojan 노드가 계속 재연결하는 가벼운 프로토콜보다 배터리를 덜 사용할 수도 있습니다. 안정성 자체가 전력 소모 요인입니다.

proxies:
  - name: vless-tls
    type: vless
    server: proxy.example.com
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    network: ws
    tls: true
    servername: edge.example.com
    ws-opts:
      path: /proxy
      headers:
        Host: edge.example.com

이 조각은 필드 계층을 설명하기 위한 것으로, 실제로 연결 가능한 노드를 의미하지 않습니다. WebSocket 경로는 대소문자를 구분하며 Host와 SNI는 같을 수도 있고 서버에서 다르게 지정할 수도 있습니다. 가져오기에 실패하면 다른 노드의 필드를 복사하지 말고 구독 원문과 대조하세요. 서버마다 경로와 인증 정보가 다르므로 서로 섞어 사용할 수 없습니다.

04 · QUIC TRANSPORT

Hysteria2와 TUIC: 변동이 큰 회선을 위한 QUIC 프로토콜

QUIC은 연결 동작을 어떻게 바꾸는가

Hysteria2와 TUIC은 모두 UDP 기반 QUIC 전송을 사용합니다. QUIC은 암호화 핸드셰이크, 신뢰성 있는 전송과 다중화를 사용자 공간에서 결합해 구현하므로, 전통적인 TCP 다중 연결에서 각각 독립적으로 발생하는 헤드 오브 라인 블로킹을 피할 수 있습니다. 왕복 지연이 높거나 패킷 손실이 변동하는 회선에서는 적절히 설정된 QUIC 세션이 처리량을 더 빠르게 회복할 수 있습니다. Wi-Fi에서 모바일 데이터로 전환할 때 일부 구현은 연결 마이그레이션을 통해 세션 재수립 비용을 줄이기도 합니다.

이러한 특성이 모든 UDP 환경에서 더 빠르다는 뜻은 아닙니다. 접속망이 UDP 세션 시간을 제한하거나 라우터가 대용량 UDP 처리에 약하거나 NAT 매핑이 자주 바뀌면 QUIC 노드에서 연결은 되지만 처리량이 불안정하고, 대기 후 복구가 느리며, 음성은 정상인데 웹페이지가 간헐적으로 시간 초과되는 현상이 나타날 수 있습니다. 이때는 프로토콜 매개변수를 조정하기 전에 UDP의 기본 사용 가능 여부부터 확인해야 합니다. 대역폭 값을 높이는 것만으로 네트워크 경로 문제를 해결할 수는 없습니다.

Hysteria2의 대역폭 및 혼잡 설정

Hysteria2는 초기 설정 구조를 단순화했으며, 일반적인 필드로 서버, 포트, 비밀번호, SNI, 인증서 검증, 업로드·다운로드 대역폭 힌트가 있습니다. 대역폭 값은 클라이언트가 임의로 얻는 가속 한도가 아니라 혼잡 제어가 전송 속도를 추정할 때 사용하는 입력값입니다. 실제 접속 능력보다 지나치게 높은 값을 입력하면 순간적인 패킷 손실과 재전송이 늘 수 있고, 너무 낮으면 처리량이 제한됩니다. 별도 요구가 없다면 구독에서 제공한 값이나 커널의 기본 정책을 우선 사용하세요.

Hysteria2는 UDP 경로 품질에 민감합니다. 테스트할 때는 지연 시간뿐 아니라 지속 다운로드가 주기적으로 느려지는지, 네트워크 전환 후 복구되는지, 대기 모드에서 깨어난 뒤 첫 요청이 시간 초과되는지도 관찰해야 합니다. Android 제조사의 배터리 정책이 클라이언트를 동결하면 QUIC keepalive가 중단될 수 있습니다. 포그라운드 복귀 후 재연결되는 현상은 시스템 백그라운드 제한 때문일 수 있으며 반드시 프로토콜 장애는 아닙니다. 먼저 클라이언트에 적절한 백그라운드 실행 정책을 적용한 뒤 프로토콜을 비교하세요.

인증서 처리는 다른 TLS 프로토콜과 동일합니다. SNI는 서버 인증서와 일치해야 하고 시스템 시간은 정확해야 하며, 검증 건너뛰기는 일상 설정으로 사용하지 않아야 합니다. 구독에서 난독화 비밀번호나 포트 호핑 같은 확장 필드를 제공한다면 mihomo 커널과 현재 클라이언트 버전이 사용하는 필드 이름이 일치하는지 반드시 확인하세요. 설정 변환기가 기본 Hysteria2는 인식해도 확장 항목은 무시할 수 있습니다.

TUIC의 세션 및 동시성 특징

TUIC 역시 QUIC을 기반으로 하며, 일반적인 인증은 UUID와 비밀번호로 구성되고 혼잡 제어, UDP 릴레이 모드, SNI와 ALPN 등의 매개변수를 제공합니다. 동시 스트림과 지연 시간이 짧은 데이터 전송을 중시하는 설계입니다. 웹페이지의 다중 요청, 실시간 통신, TCP와 UDP 트래픽이 동시에 존재하는 환경에서는 안정적인 회선에서 우수한 응답성을 유지할 수 있습니다. 다만 서버와 클라이언트가 프로토콜 버전과 필드 정의에서 일치해야 하며, 오래된 형식의 설정은 type만 바꿔 계속 사용할 수 없습니다.

TUIC의 혼잡 제어 옵션은 서버 권장 사항과 회선 특성에 따라 선택해야 합니다. 다른 사람의 매개변수를 무작정 복사하면 대역폭과 큐 관리 조건이 다른 환경에서 정반대의 결과가 나올 수 있습니다. UDP 릴레이 모드도 호환 범위에 영향을 줍니다. 어떤 모드는 네이티브 UDP 동작을 중시하고, 다른 모드는 QUIC 스트림을 통한 전달에 더 적합합니다. 게임·음성·DNS에서 개별 장애가 발생하면 노드 전체가 “연결 성공”인지보다 릴레이 모드를 먼저 확인하세요.

Hysteria2와 TUIC은 특정 회선의 후보로 정책 그룹에 추가하면 좋으며, 모든 TCP 노드를 대체할 필요는 없습니다. 수동 선택 그룹을 만들어 검증된 TCP 노드와 QUIC 노드를 함께 보관하고, 같은 웹사이트·파일·시간대에서 비교할 수 있습니다. 이렇게 하면 변동이 큰 회선에서 복구 능력을 활용하면서 UDP 조건이 달라질 때 빠르게 전환할 수 있습니다.

05 · PERFORMANCE / POWER

연결 속도·리소스 사용량·모바일 배터리

“빠르다”를 네 가지 지표로 나누기

사용자가 체감하는 속도에는 최소한 연결 설정 시간, 첫 바이트까지의 시간, 지속 처리량과 장애 복구 시간이 포함됩니다. 웹페이지가 느린 이유는 DNS, TLS 또는 최초 연결 지연일 수 있고, 대용량 파일이 느린 것은 지속 처리량 문제에 가깝습니다. 지하철이나 모바일 핫스팟 전환 후 오래 응답하지 않는다면 연결 복구 문제입니다. 프로토콜마다 최적화하는 지점이 다르므로 한 번의 지연 테스트만으로는 모든 지표를 확인할 수 없습니다.

SS는 기본 캡슐화가 가벼워 패킷 손실이 적은 환경에서 연결과 전송이 모두 비교적 직접적입니다. Trojan과 TLS를 활성화한 VMess·VLESS는 핸드셰이크 과정이 추가되지만, 장시간 연결이 수립된 뒤에는 지속 전송 차이가 대체로 줄어듭니다. Hysteria2와 TUIC은 지연이 높거나 변동·간헐적 손실이 있는 회선에서 더 빠르게 복구할 수 있지만 UDP 경로가 안정적이어야 합니다. 프로토콜 속도는 고정된 속성이 아니라 프로토콜 메커니즘과 현재 회선이 상호작용한 결과입니다.

클라이언트의 지연 테스트에도 측정 한계가 있습니다. URL-Test는 보통 지정된 주소로 HTTP 요청을 보내며, 결과에는 DNS, 연결과 서버 응답이 함께 포함됩니다. 여러 노드를 동시에 테스트하면 짧은 시간에 많은 연결이 생성되어 모바일 기기의 무선 통신과 CPU가 활성화됩니다. 측정 간격이 너무 짧으면 자주 변하는 숫자를 보게 되는 대신 백그라운드 배터리 소모와 추가 트래픽이 늘어납니다. 일상적인 사용에서 초 단위 지연을 계속 새로 고칠 필요는 없습니다.

CPU·메모리·연결 수

CPU 사용량은 암호화, TLS, 데이터 복사, 규칙 매칭, DNS 처리와 TUN 프로토콜 스택에서 주로 발생합니다. 일반적인 연결 하나가 데스크톱 프로세서에 큰 부담을 주는 경우는 드물지만, 고속 다운로드·수백 개의 동시 연결·성능이 낮은 라우터에서는 차이가 커집니다. SS 암호화 방식은 하드웨어 성능을 고려해 선택해야 합니다. TLS 계열 프로토콜은 시스템 또는 커널 암호화 라이브러리를 사용하고, QUIC은 사용자 공간에서 패킷 손실 복구와 혼잡 제어를 유지하므로 단순 TCP 프록시보다 더 많은 계산 자원을 사용할 수 있습니다.

메모리 사용량은 프로토콜만으로 판단할 수 없습니다. 규칙 세트 규모, Geo 데이터, Fake-IP 매핑, 연결 추적과 로그 수준도 상주 메모리를 늘립니다. 같은 노드라도 규칙 모드와 전역 모드의 리소스 차이는 프로토콜이 아니라 규칙 매칭에서 생길 수 있습니다. 문제를 확인할 때는 설정을 고정하고 노드 하나만 바꾼 뒤, 일정 시간 안정적으로 실행한 후의 CPU와 메모리를 관찰하세요. 시작 시 규칙을 로드할 때의 일시적인 피크를 장기 상태로 오해하지 않아야 합니다.

연결 재사용은 핸드셰이크를 줄일 수 있지만, 장시간 연결이 지나치게 많으면 상태 유지 비용이 늘어납니다. 브라우저, 메신저와 시스템 동기화 서비스가 동시에 연결을 유지할 수 있습니다. TUN 모드는 더 많은 앱을 인계하므로 시스템 프록시만 사용할 때보다 연결 수가 많은 편입니다. TUN 전환 후 배터리 소모가 증가하면 어떤 앱이 프록시에 포함되었는지, DNS 루프가 생겼는지, 백그라운드 동기화 앱이 계속 재시도하는지 확인하세요.

Android 배터리는 깨우기 패턴에 좌우됩니다

Android의 Clash 클라이언트는 VpnService를 통해 로컬 VPN 인터페이스를 만듭니다. VPN 아이콘이 표시되는 동안 시스템은 일치하는 트래픽을 클라이언트로 전달하지만, 상주 서비스 자체가 계속 높은 부하를 발생시키는 것은 아닙니다. 배터리에 실제로 영향을 주는 요인은 초당 처리 데이터량, 무선 통신이 활성 상태로 유지되는 시간, 예약 속도 측정, 로그 기록, 연결 재설정과 제조사의 백그라운드 정책입니다.

서비스를 자주 종료했다가 다시 실행하는 방식은 안정적으로 상주하는 것보다 배터리를 더 많이 소모하는 경우가 많습니다. 배터리 최적화로 클라이언트가 동결되어도 시스템 앱은 요청을 계속 만들 수 있고, 복귀 시 재연결이 몰리면서 짧은 CPU 피크와 트래픽 급증이 발생합니다. 장기간 사용할 때는 클라이언트가 필요한 백그라운드 실행을 유지하도록 허용하고, 자동 속도 측정 빈도를 낮추며, 문제 해결 후에는 상세 로그를 끄세요. 여러 VPN 또는 네트워크 필터 앱이 동시에 인계하지 않도록 하는 것도 중요합니다.

QUIC 프로토콜은 UDP 매핑과 keepalive를 유지할 수 있으며, 모바일 네트워크에서의 배터리 소모는 구현과 네트워크 타임아웃 정책에 따라 달라집니다. 대기 중 배터리 소모가 비정상적이라면 TCP 노드 하나와 QUIC 노드 하나를 각각 테스트하되, 규칙·DNS·앱 사용 방식을 동일하게 유지하세요. 프로토콜 그룹만 바꾸고 다른 설정은 변경하지 않습니다. 화면을 끈 뒤 배터리 변화, 클라이언트 재연결 횟수와 시스템 네트워크 상태를 기록해야 차이의 원인을 판단할 수 있습니다.

클라이언트에 연결됨으로 표시되지만 앱에서 트래픽이 전혀 없다면 DNS, 규칙과 시스템 프록시 문제부터 배제해야 합니다. 브라우저와 터미널은 프록시를 읽는 경로가 서로 다르므로 자세한 확인 방법은 시스템 프록시가 적용되지 않을 때의 두 가지 문제 해결 경로를 참고하세요. 트래픽이 실제로 커널에 도달하는지 확인한 뒤에야 프로토콜 성능 비교가 의미를 갖습니다.

06 · KERNEL FAMILY

오리지널 Clash·Clash.Meta·mihomo의 계열 관계

오리지널 Clash의 설정 기반

오리지널 Clash는 proxies, proxy-groups, rules, DNS, 수신 포트와 실행 모드를 포함한 널리 사용되는 YAML 설정 구조를 확립했습니다. 많은 구독과 클라이언트 인터페이스가 여전히 이 구조를 기반으로 합니다. 핵심 가치는 노드, 정책 그룹과 규칙 기반 분할을 통일된 방식으로 표현해 서로 다른 프로토콜을 동일한 선택 및 자동 테스트 체계에 편입할 수 있게 한 데 있습니다.

오리지널 프로젝트가 유지 보수를 중단한 뒤에도 기존 클라이언트는 과거 커널을 계속 사용할 수 있지만, 새 프로토콜·DNS 동작·플랫폼 대응이 후속 개선을 자동으로 받는 것은 아닙니다. 따라서 “Clash 설정”과 “오리지널 Clash 커널”은 구분해서 이해해야 합니다. 전자는 생태계에서 통용되는 설정 형식이고, 후자는 특정 구현을 가리킵니다. 파일이 Clash YAML 형식이라고 해서 오리지널 커널에서만 읽을 수 있는 것은 아닙니다.

Clash.Meta에서 mihomo로

Clash.Meta는 기존 설정 모델을 바탕으로 프로토콜, TUN, DNS, 규칙 제공자와 플랫폼 기능을 확장했으며 이후 커널 이름을 mihomo로 바꾸어 계속 발전했습니다. 실제 사용 환경에서는 여전히 Meta 설정, Meta 노드, Clash Meta for Android 같은 이름을 볼 수 있습니다. 이러한 이름은 프로젝트의 발전 과정과 클라이언트 브랜드를 나타낼 뿐, 서로 완전히 독립적인 세 가지 설정 문법이 존재한다는 뜻은 아닙니다.

mihomo는 오리지널 Clash 설정과 높은 호환성을 유지하면서 VLESS, Hysteria2, TUIC, Reality 관련 매개변수와 더 많은 DNS·TUN 옵션을 추가했습니다. 호환의 방향은 주로 “새 커널이 이전 설정을 읽는 것”입니다. 반대 방향은 성립하지 않습니다. 새 프로토콜과 확장 필드를 포함한 mihomo 설정을 오리지널 커널에 그대로 넘겨 완전히 실행할 수는 없습니다. 구형 커널은 알 수 없는 프록시 유형을 보고하거나 인식하지 못하는 전역 필드를 무시해 일부 기능만 작동하고 일부 동작은 예상과 달라질 수 있습니다.

설정 호환성은 필드의 기본값에도 영향을 받습니다. 새 커널은 과거 동작을 수정하거나 엄격한 검사를 추가하고 일부 경계 조건을 바꿀 수 있습니다. 마이그레이션 후 파일이 문법 검사를 통과하더라도 DNS, 규칙 일치, UDP, LAN 수신과 TUN 인계를 검증해야 합니다. 문법 통과는 구조를 해석할 수 있다는 뜻일 뿐 실행 결과가 완전히 같다는 의미는 아닙니다.

클라이언트 이름만으로 커널 기능을 단정할 수 없습니다

Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, Clash Meta for Android 등은 그래픽 클라이언트 또는 앱 이름이며, mihomo는 이들에서 흔히 사용되는 프록시 커널입니다. 클라이언트는 설치, 권한, 설정 관리, 트레이 또는 모바일 인터페이스를 담당하고, 커널은 프로토콜 연결, DNS, 규칙과 트래픽 처리를 담당합니다. 두 계층의 업데이트 일정은 다를 수 있으므로 클라이언트 이름만 보고 모든 프로토콜 지원 여부를 판단해서는 안 됩니다.

이 사이트의 다운로드 페이지는 플랫폼별로 현재 선택 가능한 클라이언트를 소개하며 Clash Plus를 모든 플랫폼의 우선 선택으로 안내합니다. VLESS, Hysteria2, TUIC 등 최신 프로토콜이 필요하다면 mihomo 또는 호환 구현을 명확히 사용하는 클라이언트를 선택하세요. Clash for Windows와 ClashX Meta는 유지 보수가 중단된 것으로 표시되어 기존 환경이나 보관 목적에는 사용할 수 있지만, 새 프로토콜 필드를 검증하는 첫 번째 선택으로는 적합하지 않습니다.

Android에서는 앱 버전, 커널 아키텍처와 설치 패키지 아키텍처도 구분해야 합니다. ARM64 기기는 보통 해당 아키텍처 패키지를 사용하고, 범용 패키지는 더 많은 기기와 호환됩니다. 설치에 성공했다고 해서 구독의 모든 프로토콜을 사용할 수 있는 것은 아닙니다. 커널이 Profile을 불러올 때 프록시 유형과 필드를 다시 검사하기 때문입니다. “일부 노드가 사라지는” 경우 설정 로드 로그를 확인해 구독에서 전달되지 않은 것인지, 클라이언트가 필터링한 것인지, 커널이 알 수 없는 필드를 거부한 것인지 구분하세요.

마이그레이션할 때 먼저 정적 검사를 실행하세요

mihomo에는 설정 검사 기능이 제공됩니다. 명령줄 환경이 있다면 시작 전에 YAML을 해석할 수 있는지 확인할 수 있습니다. 이 검사는 들여쓰기, 알 수 없는 유형과 일부 필드 오류를 찾아내지만 노드 비밀번호, 서버 인증서나 실제 네트워크 경로를 테스트하지는 않습니다.

mihomo -t -f ./config.yaml

검사를 통과한 뒤 “DNS 해석—단일 노드 연결—규칙 일치—UDP—TUN” 순서로 확인하세요. 처음부터 모든 오버라이드, 스크립트와 복잡한 규칙을 활성화하면 오류 발생 계층을 찾기 어렵습니다. Profile 각 영역의 역할을 이해하려면 설정 파일 구조와 다중 설정 관리를 이어서 읽어 보세요.

07 · PROFILE COMPATIBILITY

구독 형식·필드 변환·설정 호환성의 경계

링크 구독과 YAML Profile

Clash 클라이언트에서 흔히 사용하는 가져오기 소스는 두 가지입니다. 첫째는 노드, 정책 그룹, 규칙과 DNS 설정을 모두 포함한 완전한 YAML Profile입니다. 둘째는 URI 또는 통합 구독으로, 서버가 노드 링크를 반환하면 클라이언트나 변환 서비스가 Clash 설정을 생성합니다. 전자는 구조가 완전해 규칙과 고급 필드를 보존하기 좋고, 후자는 여러 앱에 배포하기 편하지만 변환 과정에서 특정 프로토콜 확장이 빠질 수 있습니다.

단일 노드 URI의 표현력은 프로토콜 형식의 제약을 받습니다. SS, Trojan, VMess, VLESS, Hysteria2와 TUIC은 각각 링크 필드가 다르고, 클라이언트 파서마다 허용하는 오류 범위도 다를 수 있습니다. 링크의 도메인, 경로, SNI와 노드 이름은 URL 인코딩이 필요합니다. 서버 출력 형식이 올바르지 않으면 한 클라이언트는 허용하고 다른 클라이언트는 거부할 수 있습니다. 이는 노드 자체가 고장 난 것이 아니라 파싱 단계가 일치하지 않는 문제입니다.

문제 확인에는 완전한 YAML이 더 적합합니다. 노드 필드를 하나씩 읽을 수 있고 정책 그룹의 참조 관계도 명확합니다. 구독이 업데이트되면 클라이언트는 보통 원격 내용으로 캐시된 Profile을 교체하므로, 생성된 파일을 직접 편집하면 다음 업데이트 때 사라질 수 있습니다. 장기적으로 수정해야 한다면 클라이언트가 제공하는 오버라이드, 병합 또는 스크립트 진입점을 사용하고 오버라이드 실행 순서도 확인하세요.

변환기에서 가장 자주 누락되는 필드

서버, 포트와 인증 정보 같은 기본 필드는 대체로 보존되지만 전송 확장은 누락되기 쉽습니다. VMess와 VLESS의 WebSocket Host·경로·gRPC 서비스 이름·흐름 제어 매개변수, Trojan의 SNI, Hysteria2의 난독화와 대역폭 힌트, TUIC의 혼잡 제어와 UDP 릴레이 모드는 변환기가 명시적으로 이해해야 합니다. 변환기가 프로토콜의 기본 구조만 인식하면 노드는 목록에 남아도 연결 단계에서 실패할 수 있습니다.

또 다른 문제는 필드 이름의 차이입니다. 일부 구독은 상위 프로젝트의 원래 이름을 사용하지만 Clash 설정은 다른 키 이름을 요구할 수 있습니다. 일부 클라이언트는 자동 매핑하고, 일부는 알 수 없는 필드를 그대로 보존합니다. 문제를 확인할 때는 변환 전 원본 노드 정보와 가져온 뒤의 YAML을 대조하세요. 그래픽 인터페이스에서 노드 이름만 보는 것으로는 필드가 완전한지 알 수 없습니다.

정책 그룹도 변환 과정에서 실제 사용 경험을 바꿀 수 있습니다. 노드가 모두 가져와졌더라도 현재 선택한 그룹에 포함되지 않을 수 있고, 규칙이 최종적으로 다른 정책을 가리킬 수도 있습니다. 자동 테스트 그룹은 테스트 URL에 접근하지 못해 사용 가능한 노드를 실패로 표시할 수도 있습니다. 프로토콜을 판단하기 전에 수동 선택 그룹에서 단일 노드를 직접 지정해 정책 그룹의 자동 전환을 배제하세요.

최소 검증 설정

전체 구독을 불러올 수 없을 때는 수신 포트, 노드 하나, 수동 정책 그룹 하나와 최종 규칙만 남긴 최소 설정을 만들 수 있습니다. 이를 통해 노드 필드 오류와 대규모 규칙·DNS·Provider 문제를 구분할 수 있습니다. 최소 설정 검증에 성공한 뒤 DNS, 규칙 제공자와 TUN을 단계별로 추가하세요. 매번 한 종류의 기능만 추가하고, 직전의 정상 파일을 보관해야 합니다.

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: test-node
    type: trojan
    server: proxy.example.com
    port: 443
    password: "your-password"
    sni: edge.example.com
    udp: true

proxy-groups:
  - name: MANUAL
    type: select
    proxies:
      - test-node
      - DIRECT

rules:
  - MATCH,MANUAL

이 설정 구조는 mihomo의 기본 검증에 사용할 수 있으며, 예시 주소와 인증 값은 실제 값으로 바꿔야 합니다. 테스트 중에는 log-level: info 정도면 충분합니다. 핸드셰이크 필드를 확인할 때만 잠시 로그 상세도를 높이고 완료 후 되돌려 장기간 대량 기록이 남지 않도록 하세요. 클라이언트가 포트를 직접 관리한다면 클라이언트가 생성한 기본 템플릿을 따르고, 인터페이스 설정과 중복으로 선언하지 마세요.

호환성 점검 체크리스트

여러 설정을 함께 사용할 때는 Profile에 명확한 이름을 지정하고 “기본 호환”, “mihomo 확장”, “모바일 저전력”처럼 필요한 커널을 기록하세요. 이름은 설정 목적을 설명하는 데 사용하고 날짜만으로 구분하지 마세요. 클라이언트에서 Profile을 전환한 뒤에는 현재 정책 그룹 선택도 확인해야 합니다. 일부 앱은 Profile마다 상태를 따로 저장하고, 다른 앱은 같은 이름의 정책 그룹에서 마지막 선택을 이어갈 수 있습니다.

08 · DECISION GUIDE

사용 상황에 따라 프로토콜을 선택하고 대체 경로를 보존하세요

일상적인 웹 탐색과 여러 기기 간 마이그레이션

주요 용도가 웹 탐색, 소프트웨어 업데이트와 일반 앱이고 Windows, macOS, Android, Linux 사이에서 설정을 옮겨야 한다면 필드가 적고 클라이언트 지원 범위가 넓은 프로토콜을 우선 선택하세요. SS와 Trojan은 기본 노드로 적합한 경우가 많습니다. SS는 암호화 방식이 모든 기기에서 지원되는지 확인하고, Trojan은 SNI와 인증서를 확인해야 합니다. DNS, 음성 또는 일부 앱만 별도로 실패하지 않도록 두 프로토콜 모두 서버가 실제로 지원하는 UDP 전달을 활성화하는 것이 좋습니다.

클라이언트는 이 사이트의 모든 플랫폼 우선 선택인 Clash Plus가 통합 인터페이스와 설정 진입점을 원하는 사용자에게 적합합니다. Clash Verge Rev와 FlClash 등은 데스크톱 대안으로 사용할 수 있고, Clash Meta for Android와 Surfboard는 서로 다른 Android 사용 환경을 지원합니다. 클라이언트를 고를 때는 먼저 플랫폼과 커널을 확인하고 인터페이스 기능을 살펴보세요. 두 앱에 Clash라는 이름이 함께 들어간다고 설정 기능까지 완전히 같다고 가정해서는 안 됩니다.

높은 지연·변동이 큰 네트워크와 실시간 트래픽

네트워크 왕복 시간이 높거나 이동 중 패킷 손실 변동이 크다면 Hysteria2 또는 TUIC을 테스트할 수 있습니다. 테스트 전에 UDP 연결 가능 여부를 확인하고 TCP 노드도 하나 남겨 두세요. 같은 앱과 같은 테스트 콘텐츠를 고정한 뒤 연결 복구, 최초 로딩과 지속 전송을 관찰하고 지연 숫자만 비교하지 마세요. QUIC 노드가 Wi-Fi에서는 안정적이지만 모바일 데이터에서 자주 끊긴다면 두 프로토콜을 함께 둔 정책 그룹을 유지하고 네트워크 환경에 따라 수동 전환하는 편이 좋습니다.

게임, 음성 통화와 화상 회의에서는 지터, 패킷 손실 복구와 UDP 릴레이가 더 중요합니다. 웹페이지가 열린다고 해서 실시간 트래픽이 정상이라는 뜻은 아닙니다. TUIC은 UDP 릴레이 모드를, Hysteria2는 UDP와 혼잡 제어 매개변수를 확인해야 하며, SS·Trojan·VLESS는 클라이언트와 서버에서 모두 UDP를 활성화했는지 확인해야 합니다. 테스트할 때는 실제 앱을 관찰하고 웹 속도 측정으로 실시간 상황을 대신하지 마세요.

저전력 기기와 라우터

성능이 낮은 라우터에서는 프로토콜을 비교하기 전에 규칙 세트, 로그와 동시 연결 수를 먼저 줄이세요. 하드웨어에 맞는 암호화 방식을 사용한 가벼운 SS는 리소스 사용량을 예측하기 쉽습니다. Trojan과 VLESS TLS는 핸드셰이크와 암호화 라이브러리를 고려해야 하고, Hysteria2와 TUIC의 사용자 공간 QUIC은 CPU와 메모리 부담을 늘릴 수 있습니다. 높은 처리량을 목표로 할 때는 라우터 CPU가 먼저 한계에 도달해 속도가 더 이상 오르지 않을 수 있습니다.

Android에서 장시간 백그라운드로 실행할 때는 이론적으로 캡슐화가 가장 가벼운 노드보다 연결이 안정적인 노드를 우선 선택하세요. 자주 끊겼다가 다시 핸드셰이크하는 노드는 기기를 더 자주 깨웁니다. 속도 측정 주기는 분 단위 또는 필요할 때만 실행하도록 설정하고 로그는 일반 수준으로 유지하며, 시스템이 VPN 서비스를 반복 종료하지 않는지 확인하세요. 특정 앱에서만 프록시를 사용할 경우 앱별 분할을 활용해 불필요한 백그라운드 연결을 줄일 수 있습니다.

기존 구독과 새 커널로의 마이그레이션

기존 VMess, SS 또는 Trojan 구독이 정상 작동한다면 mihomo로 옮길 때 먼저 프로토콜을 바꿀 필요가 없습니다. 첫 단계에서는 Profile 내용을 유지한 채 커널이나 클라이언트만 교체하고, 두 번째 단계에서 DNS·규칙·UDP·TUN을 확인한 뒤, 세 번째 단계에서 VLESS·Hysteria2·TUIC 같은 새 노드를 추가하세요. 단계적으로 옮기면 커널 차이와 프로토콜 차이를 분리할 수 있습니다.

mihomo에서 구형 커널로 되돌릴 때는 구형 커널이 인식하지 못하는 노드와 필드를 삭제하거나 교체해야 합니다. 파일 이름만 다시 바꾸는 것으로는 해결되지 않습니다. 정책 그룹이 삭제된 노드를 참조하면 로드에도 실패합니다. 복귀용 설정은 별도의 Profile로 저장하고 기본 프로토콜과 범용 필드를 사용하세요. 새 설정에 문제가 생겼을 때 복잡한 주 설정을 임시로 수정하지 않고 빠르게 복구할 수 있습니다.

실행 가능한 선택 순서

1. 클라이언트를 확인합니다. 운영체제, CPU 아키텍처와 실제 커널을 점검하세요. 최신 프로토콜이 필요하다면 mihomo를 사용하는 클라이언트를 우선 선택합니다.
2. 구독을 확인합니다. 노드 유형과 확장 필드가 온전히 포함되었는지 확인하고, 대상 프로토콜을 지원하지 않는 변환기는 피하세요.
3. 기본 노드를 구성합니다. 먼저 SS, Trojan 또는 기존의 안정적인 노드로 DNS, 규칙, 시스템 프록시와 TUN을 검증합니다.
4. 후보 프로토콜을 추가합니다. 같은 수동 정책 그룹에 VLESS, Hysteria2 또는 TUIC을 추가하고 한 번에 하나의 변수만 테스트합니다.
5. 상황별로 테스트합니다. 웹페이지 최초 로딩, 지속 다운로드, 실시간 UDP, 네트워크 전환과 대기 후 복구를 각각 관찰합니다.
6. 복귀용 설정을 저장합니다. 정상 작동하던 Profile을 보관해 구독 업데이트가 유일한 사용 가능 설정을 덮어쓰지 않도록 합니다.

프로토콜 선택의 최종 목표는 고정된 순위를 얻는 것이 아니라 설명 가능하고 되돌릴 수 있는 연결 조합을 만드는 것입니다. 안정적인 노드는 일상적인 기준선으로 사용하고, 최신 프로토콜은 특정 네트워크 조건에 대응하며, 수동 정책 그룹은 빠른 전환을 담당하고, 독립 Profile은 변경 사항을 격리합니다. 장애가 발생하면 구독, 파싱, 정책, 연결, DNS와 시스템 인계 순서로 단계별 판단을 내려 모든 문제를 프로토콜 탓으로 돌리지 마세요.

선택을 마쳤다면 설치 파일 페이지에서 해당 플랫폼의 클라이언트를 확인하거나 사용 가이드에 따라 가져오기와 최초 연결을 진행하세요. Profile 업데이트 후 구조가 달라졌다면 Profile 구조 해설을 참고하고, 연결은 성공했지만 인터넷에 접속할 수 없다면 연결됐지만 인터넷이 되지 않을 때의 문제 해결 체크리스트로 돌아가 항목별로 확인하세요.