Clash 프로토콜·코어·구독 호환성 기술 참고서

01 · Decision Model

제약 조건을 먼저 확인한 뒤 프로토콜 이름을 비교하세요

프로토콜·전송·클라이언트는 서로 다른 계층입니다

Clash 설정에서 “노드 유형”은 보통 ss, vmess, trojan, vless, hysteria2, tuic과 같은 프록시 프로토콜을 뜻합니다. 프로토콜은 클라이언트와 서버가 세션을 만들고, 신원을 확인하고, 대상 주소를 캡슐화하며, 애플리케이션 데이터를 전달하는 방식을 규정합니다. 이는 하위 전송 방식과 같은 개념이 아닙니다. VMess와 VLESS 등은 TCP, WebSocket, gRPC 또는 다른 전송 방식과 조합할 수 있고, Trojan은 보통 TLS와 함께 사용됩니다. Hysteria2와 TUIC은 QUIC 및 UDP 전송 기능을 중요한 기반으로 삼습니다. 구독에서 같은 프로토콜로 보이는 노드라도 전송 방식, TLS 매개변수 또는 서버 구현이 다르면 실제 동작은 크게 달라질 수 있습니다.

클라이언트는 더 바깥쪽의 조작 화면입니다. Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu와 같은 GUI 클라이언트는 설정 가져오기, 프록시 그룹 전환, 시스템 프록시 관리와 연결 정보 표시를 담당합니다. 실제로 노드 필드를 해석하고 연결을 만드는 것은 내장되었거나 별도로 호출되는 코어입니다. 클라이언트를 선택할 때는 플랫폼 지원과 코어 기능을 함께 확인해야 하며, 노드를 선택할 때는 현재 코어가 해당 프로토콜 필드를 인식하는지 확인해야 합니다. GUI에 노드 이름이 표시된다고 해서 하위 코어가 해당 노드의 모든 옵션을 완전히 처리한다는 뜻은 아닙니다. 특히 최신 프로토콜 확장이나 전송 매개변수에서 이런 차이가 자주 발생합니다.

네 가지 질문으로 범위를 좁히세요

첫 번째 제약 조건은 서버가 실제로 무엇을 제공하는가입니다. 클라이언트에서 Shadowsocks 노드를 VLESS로 직접 바꿀 수 없으며, type 필드만 수정한다고 프로토콜이 변환되지도 않습니다. 양쪽 프로토콜은 동일한 인증 및 캡슐화 규칙을 사용해야 하므로 노드 유형은 우선 서버 설정으로 결정됩니다. 구독이 하나의 프로토콜만 제공한다면 클라이언트에서 프로토콜 이름을 임의로 고치기보다 현재 코어의 지원 여부를 확인하고 노드, 프록시 그룹과 DNS를 조정하는 것이 올바른 방법입니다.

두 번째 제약 조건은 네트워크 경로가 UDP를 안정적으로 지원하는지입니다. Hysteria2와 TUIC의 주요 전송은 UDP와 QUIC을 기반으로 합니다. 로컬 네트워크, 라우터 또는 서버 진입점의 UDP 지원이 불안정하면 핸드셰이크 시간 초과, 속도 변동 또는 잦은 재연결이 발생할 수 있습니다. 이때 TCP 기반 방식은 최고 처리량이 두드러지지 않더라도 지속적인 사용성은 더 좋을 수 있습니다. UDP 지원 여부는 웹페이지가 열리는지만으로 판단하지 말고, 일정 시간 동안 연결 수립, 절전 후 복구, 대용량 전송과 네트워크 전환 상황을 관찰해야 합니다.

세 번째 제약 조건은 기기 리소스입니다. 데스크톱에서는 보통 동시 연결 수, 다운로드 처리량과 장시간 실행 안정성을 중시합니다. 스마트폰과 태블릿은 무선 모듈 깨우기, 백그라운드 유지, 네트워크 전환과 배터리 소모까지 고려해야 합니다. 라우터나 소형 서버는 CPU 명령어 세트, 메모리와 파일 디스크립터 수의 제한을 받을 수 있습니다. 암호화 알고리즘, 사용자 공간 혼잡 제어, 연결 재사용과 로그 수준은 모두 리소스 사용량을 바꾸므로 프로토콜 이름만으로 실측을 대신할 수 없습니다.

네 번째 제약 조건은 설정의 이식성입니다. 장기간 사용하는 구독에는 규칙 세트, 프록시 그룹, DNS, 스크립트 또는 특정 코어 확장이 포함될 수 있습니다. 다른 클라이언트로 옮길 때 가장 자주 문제가 되는 것은 기본 노드보다 규칙 프로바이더, TUN 매개변수, 스니핑 설정과 최신 프로토콜 필드입니다. 여러 기기에서 설정을 공유해야 한다면 공통으로 지원되는 필드만 우선 사용하고, 플랫폼 전용 설정은 하나의 공용 구독에 모두 넣지 말고 각 클라이언트에 로컬로 보관하세요.

선택할 때는 먼저 안정적인 기준선을 하나 남겨 둔 뒤 후보 프로토콜을 비교하세요. 기준선은 지속적으로 연결되고 설정 필드가 적은 현재 노드로 정할 수 있습니다. 이후 같은 서버 지역과 비슷한 회선을 유지한 채 TCP 기반 노드와 QUIC 기반 노드를 각각 테스트하는 등 한 번에 하나의 변수만 바꾸세요. 서버, 프로토콜, 포트와 프록시 그룹을 동시에 바꾸면 결과의 원인을 추적할 수 없어 다음에 무엇을 조정해야 할지 판단하기 어렵습니다.

02 · Established Protocols

Shadowsocks와 VMess: 검증된 기반과 조합 가능성

Shadowsocks의 간결한 설계

Shadowsocks는 흔히 SS로 줄여 부르며, 미리 공유한 비밀번호와 선택한 AEAD 암호화 방식으로 클라이언트와 서버 사이의 데이터를 보호하고 가벼운 프로토콜 캡슐화로 TCP 또는 UDP 트래픽을 전달합니다. 설정 항목이 비교적 집중되어 있어 일반적인 노드는 서버 주소, 포트, 비밀번호와 암호화 방식만 필요합니다. 협상 단계가 적고 구현 범위가 명확해 여러 코어와 클라이언트에서 쉽게 지원되며, 구독·DNS·프록시 그룹이 정상 작동하는지 확인하는 기준선 프로토콜로도 적합합니다.

“설정이 간단하다”고 해서 모든 Shadowsocks 노드가 같은 것은 아닙니다. 암호화 방식은 서버와 일치해야 하며 이름 표기도 코어 지원 목록에 맞아야 합니다. 최신 설정은 보통 AEAD 방식을 사용합니다. 구형 스트림 암호화 방식은 구현 정책이나 보안 특성 때문에 일부 클라이언트에서 더 이상 허용되지 않을 수 있습니다. 구독에 플러그인 필드가 포함되어 있다면 현재 코어가 해당 플러그인과 매개변수를 지원하는지도 확인해야 합니다. 기본 SS 노드를 가져올 수 있다고 해서 플러그인이 포함된 다른 노드까지 호환된다고 볼 수는 없습니다.

리소스 측면에서 Shadowsocks의 프로토콜 처리는 대체로 직접적입니다. 실제 CPU 사용량은 암호화 방식, 기기의 하드웨어 가속 지원, 동시 연결 수와 처리량에 따라 달라집니다. 일반적인 데스크톱에서는 일상적인 웹 사용의 주요 병목이 프로토콜 자체인 경우가 드뭅니다. 저전력 라우터, 고속 다운로드 또는 대량 동시 연결에서는 알고리즘 구현과 단일 코어 성능 차이가 점차 드러납니다. 속도 측정 중 CPU가 계속 최고 사용률에 가깝다면 프록시 그룹을 바꿔도 처리량이 늘지 않으므로 먼저 변수를 줄이고 기기의 처리 능력을 확인하세요.

VMess의 신원 인증과 전송 조합

VMess는 V2Ray 생태계에서 시작되었으며, 노드는 보통 UUID를 사용자 식별자로 사용하고 여러 하위 전송 방식과 조합할 수 있습니다. 구독에는 network, TLS, 호스트 이름, 경로 또는 서비스 이름 등의 필드가 함께 포함되는 경우가 많습니다. 사용자 관점에서 VMess의 핵심 특징은 특정 속도 우위가 아니라 다양한 설정 조합입니다. 같은 VMess라도 TCP, WebSocket, gRPC 방식에 따라 핸드셰이크 과정, 연결 재사용 방식과 추가 헤더 비용이 달라집니다.

VMess 노드 문제를 해결할 때는 바깥 계층부터 안쪽으로 확인해야 합니다. 먼저 서버, 포트와 UUID를 확인하고, 다음으로 암호화 또는 보안 필드를 확인한 뒤 전송 유형을 점검하세요. WebSocket을 사용한다면 경로와 Host를 확인해야 합니다. TLS를 함께 사용한다면 서버 이름, 인증서 검증과 ALPN 등의 정보를 확인하세요. gRPC라면 서비스 이름과 다중화 동작을 살펴봐야 합니다. 구독 변환 도구가 이 중 하나라도 누락하면 노드는 클라이언트에 표시되더라도 핸드셰이크 단계에서 연결이 실패할 수 있습니다.

VMess는 시스템 시간에 민감한 편입니다. 기기 시간이 크게 어긋나면 신원 인증이 정상적으로 완료되지 않을 수 있습니다. 따라서 “같은 구독이 한 기기에서는 작동하지만 다른 기기에서는 모두 시간 초과되는” 경우 시스템 시간과 시간대는 우선 확인할 가치가 큰 저비용 점검 항목입니다. 자동 시간 동기화를 복구한 뒤에는 설정을 다시 불러오거나 관련 연결을 재시작해 기존 연결 상태가 판단을 방해하지 않도록 하세요.

둘 중 어떻게 선택할까

서버가 SS와 VMess를 모두 제공하고 회선 조건도 비슷하다면 SS가 복잡도가 낮은 기준선으로 더 적합합니다. 필드가 적어 다른 코어로 옮길 때 문제를 찾기 쉽기 때문입니다. VMess는 이미 안정적인 배포 환경이 있거나 특정 전송 조합이 필요하고, 구독 생태계가 해당 매개변수를 중심으로 구성된 경우에 적합합니다. 필드가 많아서 더 고급이거나 적어서 반드시 더 빠르다고 판단하지 말고, 추가 전송 계층이 명확한 요구를 해결하는지와 현재 코어가 해당 설정을 정확히 표현할 수 있는지를 기준으로 선택하세요.

모바일에서는 한 번의 암호화 계산보다 연결 수와 재연결 빈도가 체감 성능에 더 큰 영향을 주는 경우가 많습니다. WebSocket 또는 gRPC 조합은 추가 핸드셰이크와 연결 관리를 발생시킬 수 있지만, 적절한 연결 재사용으로 반복적인 연결 수립을 줄일 수도 있습니다. 앱 트래픽이 짧은 요청 위주라면 첫 요청과 절전 후 복구를 관찰하고, 지속적인 동영상·오디오 재생이나 다운로드 위주라면 10분 이상 안정적인 처리량을 확인하세요. 한 번의 지연 시간 수치는 특정 대상의 한 시점만 보여 줄 뿐 이러한 차이를 충분히 반영하지 못합니다.

설정을 이전할 때 SS 기본 필드는 Clash 계열 코어 사이에서 대체로 이식성이 좋습니다. VMess 기본 필드도 성숙했지만 전송 확장의 이름과 중첩 구조는 더 꼼꼼히 확인해야 합니다. 구독이 변환 서비스를 거친다면 원본 구독 주소를 보관하고, 변환 전후로 한 노드의 서버, 포트, UUID, 네트워크 유형, TLS, 경로와 호스트 이름을 비교하세요. 노드 표시 이름만으로 변환이 완전했는지 판단해서는 안 됩니다.

proxies:
  - name: "SS 기준선 노드"
    type: ss
    server: server.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

위 예시는 mihomo 설정에서 기본 Shadowsocks 노드 필드의 관계를 보여 줍니다. 예시 도메인과 비밀번호는 서버가 제공한 실제 정보로 바꿔야 합니다. udp: true는 코어가 해당 노드의 UDP 트래픽을 처리하도록 허용한다는 뜻일 뿐이며, 서버와 네트워크 경로도 해당 기능을 지원해야 합니다. 다른 노드에서 비밀번호, 포트 또는 암호화 방식을 복사한 뒤 이름만 바꾸지 마세요. YAML 문법은 통과하더라도 프로토콜 인증을 완료할 수 없습니다.

03 · TLS-Oriented Choices

Trojan과 VLESS: 인증 계층과 전송 계층의 선택

Trojan의 연결 구조

Trojan은 일반적으로 비밀번호 인증과 TLS 연결을 결합합니다. 클라이언트는 먼저 TLS 핸드셰이크를 완료한 뒤 암호화된 연결에서 프로토콜 인증 정보와 대상 주소를 제출합니다. 설정에는 서버, 포트와 비밀번호 외에도 sni, 인증서 검증, ALPN과 UDP 지원 등의 필드가 자주 포함됩니다. 노드 구조는 복잡하지 않지만 TLS 매개변수는 서버 인증서와 진입점 설정에 맞아야 하며, 이름 하나만 달라도 핸드셰이크 실패로 나타날 수 있습니다.

SNI는 TLS 핸드셰이크에서 대상 서버 이름을 지정하는 데 사용됩니다. 구독이 서버 주소로 도메인을 제공한다면 코어가 이를 바탕으로 처리하는 경우가 많습니다. 서버 필드가 IP 주소인데 인증서는 특정 도메인으로 발급되었다면 서버 이름을 별도로 입력해야 할 수 있습니다. 인증서 검증을 끄면 이름이나 인증서 체인 문제를 일시적으로 우회할 수 있지만 연결의 신원 검증 특성이 바뀌므로 장기적인 문제 해결 방법으로 사용해서는 안 됩니다. 서버 인증서, 시스템 시간, SNI와 구독 필드가 일치하는지 확인하는 것이 더 안전합니다.

Trojan의 성능은 초기 TLS 핸드셰이크 비용과 연결 수립 후 데이터 전송 비용으로 나뉩니다. 짧은 연결이 많으면 반복되는 핸드셰이크가 첫 패킷 시간에 더 크게 영향을 줍니다. 연결을 유지하거나 합리적으로 재사용하면 이 비용은 분산됩니다. TLS 구현은 폭넓게 최적화되어 최신 데스크톱과 스마트폰 프로세서에서 하드웨어·소프트웨어 지원도 충분히 성숙했으므로 “TLS 계층이 하나 더 있다”는 이유만으로 반드시 느리다고 판단할 수 없습니다. 회선 지연, 서버 부하와 애플리케이션의 연결 수립 방식이 더 중요한 경우가 많습니다.

VLESS는 확장 기능을 외부 계층에 맡깁니다

VLESS 역시 V2Ray 관련 생태계에서 비롯되었지만 프로토콜 계층은 더 가볍게 설계되었습니다. 보통 UUID로 사용자를 식별하고 암호화와 보안 기능은 TLS, REALITY 또는 다른 외부 계층에 맡깁니다. Clash 사용자에게 중요한 것은 type: vless만이 아닙니다. 네트워크 전송, TLS 활성화 여부, 서버 이름, 흐름 제어 필드와 클라이언트 지문 같은 확장도 함께 확인해야 합니다. 프로토콜 이름 자체보다 조합별 호환 범위를 살펴보는 것이 중요합니다.

VLESS over TCP, VLESS over WebSocket과 VLESS over gRPC는 연결 동작이 서로 다릅니다. TCP 조합은 계층이 적어 문제 해결 경로가 비교적 짧습니다. WebSocket은 HTTP 업그레이드, 경로와 호스트 필드를 추가하고, gRPC는 HTTP/2 의미 체계와 서비스 이름에 의존합니다. TLS나 다른 보안 계층을 더하면 설정 필드는 계속 늘어납니다. 구독을 변환할 때는 이러한 필드 사이의 대응 관계를 유지해야 합니다. 전송 유형을 TCP로 바꾼 뒤 WebSocket에만 해당하는 경로를 남겨 두고 코어가 자동으로 추론하기를 기대해서는 안 됩니다.

VLESS의 일부 확장 기능은 여러 프로젝트에서 단계적으로 구현되었습니다. mihomo는 일반적인 VLESS 조합을 지원하지만 구형 Clash 원본 코어는 동일한 기능을 제공하지 않습니다. 일부 오래된 GUI는 YAML을 읽을 수 있어도 코어를 시작할 때 알 수 없는 프록시 유형이나 필드 오류를 보고할 수 있습니다. 따라서 VLESS가 포함된 구독은 지속적으로 유지 관리되고 mihomo를 명확히 사용하는 클라이언트에서 이용하는 편이 좋습니다. 이 사이트의 다운로드 페이지에서는 Clash Plus와 Clash Verge Rev를 데스크톱 우선 후보로 살펴볼 수 있으며, 구체적인 플랫폼 입구는 다운로드 페이지에서 선택할 수 있습니다.

인증 성공이 모든 트래픽의 정상 작동을 뜻하지는 않습니다

Trojan 또는 VLESS 노드가 연결 가능으로 표시되더라도 기본 탐색이 완료되었다는 뜻일 뿐, TCP, UDP, IPv6와 모든 애플리케이션 프로토콜이 검증되었다는 의미는 아닙니다. 테스트할 때는 일반 웹페이지, 장시간 연결 앱, 도메인 확인과 UDP가 필요한 사용 환경을 최소한 포함하세요. 일부 앱만 실패한다면 곧바로 프로토콜 자체가 사용할 수 없다고 판단하지 말고 규칙 매칭, DNS, TUN과 UDP 기능을 확인해야 합니다.

연결 직후 바로 끊긴다면 일반적인 점검 순서는 시스템 시간, 서버 주소와 포트, 인증 정보, TLS 활성화, SNI, 인증서 검증, 전송 유형, 경로 또는 서비스 이름입니다. VLESS는 flow와 같은 확장 필드가 서버에서 요구되는지, 코어가 지원하는지도 확인해야 합니다. 로그의 “TLS handshake”, “authentication”, “unknown field”는 서로 다른 계층을 가리키므로 문제 해결 시 키워드에 따라 위치를 좁혀야 하며, 원래 오류를 가리기 위해 노드만 반복해서 바꿔서는 안 됩니다.

선택 관점에서 Trojan은 서버가 표준 TLS 진입점을 중심으로 구성되어 있고 매개변수가 비교적 고정된 환경에 적합합니다. VLESS는 전송과 보안 계층 조합을 활용해야 하고 클라이언트 코어가 관련 확장을 명확히 지원하는 경우에 적합합니다. 여러 기기에서 구독을 공유한다면 먼저 모든 기기의 코어 기능을 나열한 뒤 공통으로 지원되는 조합을 선택하세요. 데스크톱에서 사용할 수 있는 최신 확장이 구형 모바일 클라이언트나 라우터 플러그인에서 완전히 인식된다는 보장은 없습니다.

04 · QUIC Transport

Hysteria2와 TUIC: 변화가 큰 경로를 위한 UDP 방식

QUIC과 UDP를 선택하는 이유

Hysteria2와 TUIC은 모두 QUIC을 중요한 기반으로 사용합니다. QUIC은 UDP 위에서 동작하며 사용자 공간에서 암호화 연결, 신뢰성 있는 전송, 다중 스트림과 혼잡 제어를 처리합니다. 기존 TCP 연결과 비교하면 전송 계층과 보안 계층에서 필요한 왕복 일부를 줄일 수 있고, 여러 논리 스트림이 하나의 TCP 헤드 오브 라인 블로킹 상태를 완전히 공유하는 문제도 피할 수 있습니다. 지연 변화가 크거나 어느 정도 패킷 손실이 발생하거나 높은 처리량이 필요한 경로에서는 이러한 설계가 더 다양한 조정 여지를 제공합니다.

하지만 UDP가 자동으로 고성능을 보장하는 것은 아닙니다. QUIC도 물리적 대역폭, 왕복 지연 시간, 패킷 손실, 서버 출구와 단말기 처리 능력의 제약을 받습니다. 일부 라우터는 장시간 UDP 세션의 상태를 짧게 유지하고, 일부 네트워크는 UDP 패킷 크기나 속도를 제한하며, 기업 네트워크는 특정 유형의 UDP 트래픽만 허용할 수 있습니다. 주기적으로 연결이 끊긴다면 클라이언트의 속도 측정 대상만 바꾸지 말고 NAT 세션, MTU, 경로 품질과 네트워크 전환을 확인하세요.

Hysteria2의 대역폭과 혼잡 제어

Hysteria2는 Hysteria 계열의 후속 프로토콜로, 설정에는 보통 서버, 포트, 비밀번호, TLS 서버 이름과 선택적 대역폭 또는 난독화 관련 매개변수가 포함됩니다. 복잡한 경로에서 QUIC과 혼잡 제어를 활용해 전송 효율을 유지하는 데 초점을 둡니다. 클라이언트의 업로드·다운로드 대역폭 설정은 통신사 요금제 수치를 표시하는 항목이 아니라 혼잡 제어 알고리즘의 중요한 입력값입니다. 실제 사용 가능한 능력보다 훨씬 높은 값을 입력하면 전송 과속, 큐잉과 패킷 손실이 늘어 오히려 안정성이 떨어질 수 있습니다.

대역폭 매개변수는 순간 최고치가 아니라 장기적으로 사용할 수 있는 수준을 기준으로 설정해야 합니다. 먼저 선택적 값을 생략하고 서버 권장값이나 코어 기본 동작을 사용해 보세요. 직접 설정해야 한다면 안정적인 시간대의 여러 측정 결과로 보수적인 범위를 정한 뒤 업로드와 다운로드를 따로 관찰하세요. 모바일 네트워크는 업로드 성능의 변동 폭이 더 큰 경우가 많아 업로드 추정치를 과도하게 높이면 확인 패킷과 상호작용 트래픽에 영향을 줄 수 있습니다. 변경 후에는 웹페이지 첫 패킷, 지속 다운로드, 동영상 탐색과 절전 후 복구를 최소한 테스트하고 짧은 순간의 속도만 보지 마세요.

Hysteria2는 TLS 관련 메커니즘으로 서버를 검증하므로 시스템 시간과 서버 이름이 여전히 중요합니다. 구독에 SNI가 제공되었다면 원래 값을 유지하세요. 노드가 IP 주소로 연결되더라도 인증서에 대응하는 도메인을 삭제해서는 안 됩니다. 인증서 오류가 발생하면 구독 출처로 돌아가 필드를 확인하세요. 난독화 비밀번호와 같은 확장도 서버와 일치해야 하며, 클라이언트에서만 활성화한다고 연결이 만들어지지는 않습니다.

TUIC의 세션 및 동시성 특징

TUIC도 QUIC을 기반으로 하며, 노드에는 서버, 포트, UUID, 비밀번호, 서버 이름, 혼잡 제어 알고리즘과 UDP 전달 모드가 자주 포함됩니다. 낮은 지연 시간의 연결 수립, 다중화와 UDP 트래픽 전달에 초점을 둔 설계입니다. TUIC 프로토콜 세대에 따라 필드가 완전히 같지 않을 수 있으므로 구독 출처, 서버 구현과 클라이언트 코어가 호환되는 형식을 사용해야 합니다. tuic 유형을 확인했더라도 인증 필드와 버전 의미를 점검해야 하며, 다른 노드의 UUID만 복사해서는 안 됩니다.

혼잡 제어 알고리즘은 확인 응답, 지연 시간과 패킷 손실을 바탕으로 송신 속도를 조절하는 방식을 결정합니다. 알고리즘 이름만으로 환경과 무관한 우열을 정할 수는 없습니다. 공격적인 방식은 대역폭이 충분할 때 처리량을 빠르게 높일 수 있지만 공유 네트워크나 버퍼가 깊은 경로에서는 큐잉을 유발할 수 있습니다. 보수적인 방식은 더 안정적일 수 있지만 최고 속도에 도달하는 데 오래 걸립니다. 구독에 서버 권장값이 있다면 우선 원래 값을 유지하세요. 반복 테스트로 문제가 재현되는 것을 확인한 뒤에만 해당 필드 하나를 따로 변경하는 것이 좋습니다.

TUIC과 Hysteria2는 특히 동시 연결이 많거나 지속 전송 및 잦은 연결 유지가 발생할 때 스마트폰 무선 모듈을 더 활발한 송수신 상태로 유지할 수 있습니다. 반대로 프로토콜이 전송을 더 빨리 완료하고 빠르게 유휴 상태로 전환하면 전체 에너지 소비가 줄어들 수도 있습니다. 따라서 “UDP 기반”이라는 이유만으로 배터리 소모량을 판단해서는 안 됩니다. 같은 밝기, 같은 앱 작업과 비슷한 신호 세기에서 충분한 사용 주기를 비교하고 백그라운드 재연결 횟수도 함께 관찰하세요.

신뢰할 수 있는 장애 전환 구성

구독에 QUIC 계열과 TCP 계열 노드가 모두 있다면 프록시 그룹에 두 종류의 후보를 남겨 두세요. 네트워크가 UDP를 지원할 때 Hysteria2나 TUIC을 우선 실측하고, 핸드셰이크 시간 초과, 네트워크 전환 후 복구 실패 또는 라우터 부하 증가가 발생하면 SS, Trojan 또는 다른 TCP 전송 노드로 전환합니다. 이는 프로토콜을 낮게 평가하는 것이 아니라 현재 경로에 맞는 연결 방식을 선택하는 것입니다.

QUIC 계열 노드를 점검할 때는 먼저 클라이언트에서 불필요한 동시 속도 측정을 꺼서 테스트 자체가 대역폭을 모두 사용하지 않도록 하세요. 이어서 시스템 시간, UDP 사용 가능 여부, 서버 주소와 포트, 인증 정보, SNI와 인증서를 확인한 뒤 MTU 또는 패킷 크기 관련 현상을 살펴봅니다. 소량 트래픽은 정상인데 대량 트래픽에서 멈춘다면 경로 MTU, 혼잡 제어와 라우터의 UDP 상태 테이블을 중점적으로 확인하세요. 처음부터 핸드셰이크가 되지 않는다면 UDP 경로, 포트, 인증 또는 TLS 매개변수 문제일 가능성이 큽니다.

05 · Performance

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

“속도”를 네 가지 지표로 나누세요

프로토콜 비교에서 속도는 최소한 연결 수립 시간, 첫 패킷 시간, 안정적인 처리량과 장애 복구 시간을 포함합니다. 연결 수립 시간은 DNS, TCP 또는 QUIC 핸드셰이크, TLS와 인증 단계의 영향을 받습니다. 첫 패킷 시간에는 서버가 대상에 접근하는 데 걸리는 시간도 포함됩니다. 안정적인 처리량은 대역폭, 혼잡 제어, 패킷 손실 복구와 단말기 처리 능력에 따라 달라집니다. 장애 복구 시간은 네트워크 전환이나 경로 변화 후 세션을 얼마나 빠르게 다시 만들 수 있는지를 보여 줍니다. 지연 시간 하나만 기록하면 이 차이들이 설명할 수 없는 결과로 압축됩니다.

Clash 클라이언트의 지연 시간 테스트는 보통 지정된 URL로 탐색 요청을 보냅니다. 완전히 연결할 수 없는 노드를 걸러내고 명확한 이상을 찾는 데는 유용하지만 실제 앱 사용을 그대로 재현하지는 않습니다. 탐색 대상의 위치, 연결 재사용 여부, DNS 결과와 캐시가 수치에 영향을 줍니다. 노드를 선택할 때는 먼저 지연 테스트로 범위를 좁힌 다음 실제 앱으로 지속적인 사용을 검증하세요. 두 노드의 탐색 결과가 비슷하다면 아주 작은 수치 차이를 반복해서 좇기보다 장시간 연결 안정성과 실패율을 더 중요하게 보세요.

공정한 비교를 위해서는 변수를 통제해야 합니다. 같은 서비스 제공업체, 같은 지역, 비슷한 시간대와 같은 대상을 선택하고 백그라운드 업데이트와 클라우드 동기화를 끄며 각 후보를 한 번 예열하세요. 각 테스트를 여러 번 반복해 중앙값과 최악의 상황을 기록하고 가장 빠른 결과만 남기지 마세요. 프로토콜 노드가 서로 다른 서버에 있다면 측정된 차이는 프로토콜 설계보다 회선과 부하에서 비롯될 수 있습니다.

CPU, 메모리와 동시 연결

Shadowsocks의 기본 캡슐화는 가벼운 편입니다. VMess, Trojan과 VLESS의 구체적인 비용은 외부 전송과 TLS에 따라 달라지고, Hysteria2와 TUIC은 사용자 공간에서 QUIC, 암호화, 패킷 손실 복구와 혼잡 제어를 처리해야 합니다. 이 순서는 처리 구조를 설명할 뿐 고정된 리소스 순위로 바꿀 수는 없습니다. 성숙한 구현, 하드웨어 가속, 패킷 크기와 연결 수에 따라 결과가 달라집니다. 저속 웹 브라우징에서는 차이가 작아도 고속 전달이나 수천 개의 연결에서는 단일 코어 병목이 드러날 수 있습니다.

메모리 사용량은 보통 연결 테이블, DNS 캐시, 규칙 세트, 로그와 TUN 상태가 늘면서 증가합니다. 대규모 규칙 세트와 복잡한 DNS 설정이 노드 프로토콜 자체보다 더 많은 메모리를 사용할 수도 있습니다. 클라이언트를 한동안 실행한 뒤 리소스가 계속 증가한다면 활성 연결이 해제되지 않는지, 로그 수준이 너무 높은지, 규칙 프로바이더가 업데이트 중인지 또는 코어 이상인지 구분해야 합니다. 프로토콜 노드만 바꿔서는 규칙과 로그로 인한 리소스 문제를 해결할 수 없습니다.

라우터와 소형 서버에서는 동시 연결과 아키텍처를 특히 확인해야 합니다. Mihomo 코어는 기기의 CPU 아키텍처와 맞아야 하며, 처리량이 높은 QUIC은 CPU가 약한 기기에서 처리 한계에 더 빨리 도달할 수 있습니다. 이때 동시 테스트 수를 줄이고 처리 비용이 낮은 노드를 선택하며 로그를 축소하세요. 시스템 소프트IRQ와 NAT 처리가 병목이 아닌지도 확인해야 합니다. 이 사이트의 다운로드 페이지 Linux 및 코어 영역은 데스크톱 GUI와 서버·라우터용 코어 파일을 구분해 제공합니다. 일반적인 데스크톱 사용자는 독립 코어를 직접 관리할 필요가 없습니다.

모바일 배터리는 작업 주기로 판단해야 합니다

스마트폰 배터리 소모는 클라이언트 프로세스의 순간 CPU 사용량만으로 판단할 수 없습니다. 프록시 연결은 무선 모듈 깨우기, 백그라운드 연결 유지, DNS 요청, 연결 재시도와 시스템 VPN 인터페이스에 영향을 줍니다. 신호가 약하면 기기의 송신 출력과 재전송 비용이 모두 증가합니다. 프로토콜이 자주 재연결되면 매번 계산량이 적어도 전체 사용 시간의 에너지 소비가 늘어날 수 있습니다. 반대로 세션을 안정적으로 유지하고 데이터를 빠르게 전송하는 방식은 더 빨리 유휴 상태에 들어갈 수 있습니다.

모바일 배터리를 비교할 때는 화면 밝기, 네트워크 유형, 앱 작업과 테스트 시간을 고정해야 합니다. 30분 동안 웹과 메시지를 섞어 사용하는 작업, 고정 크기 파일 전송, 화면을 잠근 뒤 백그라운드 알림과 복구의 세 가지 작업을 각각 실행해 볼 수 있습니다. 시스템 배터리 변화, 기기 온도와 연결 끊김 횟수를 기록하세요. 짧은 속도 측정은 백그라운드 동작을 보여 주지 못하고, 하루 종일 혼합 사용하면 카메라, 위치 정보와 화면 활동의 영향을 받기 쉬우므로 단계별 테스트가 원인을 찾는 데 더 유리합니다.

TUN 모드는 더 많은 앱 트래픽을 포괄하는 대신 코어가 라우팅과 DNS 처리에 계속 참여하게 합니다. 시스템 프록시는 프록시 설정을 따르는 앱에만 영향을 주므로 리소스 범위가 상대적으로 제한적입니다. 프로토콜을 비교할 때는 프록시 모드를 동일하게 유지해야 TUN과 시스템 프록시의 차이가 아닌 프로토콜 차이를 측정할 수 있습니다. Android와 iOS의 백그라운드 관리 방식은 다르므로 같은 클라이언트의 결과를 두 플랫폼에 그대로 적용해서도 안 됩니다.

최종 선택은 안정적인 구간을 기준으로 해야 합니다. 어떤 노드가 가끔 매우 높은 최고 속도를 내더라도 자주 멈춘다면 회의, 동기화와 장시간 연결 앱에 적합하지 않을 수 있습니다. 최고 속도는 조금 낮아도 연속 전송을 유지하는 노드는 기본 전략으로 더 적합한 경우가 많습니다. 전자는 다운로드나 대용량 트래픽 그룹에 넣고 후자는 일상 기본 그룹에 사용해 규칙 분류로 작업별 프로토콜 특성을 활용할 수 있습니다.

06 · Kernel Family

원본 Clash, Meta와 mihomo의 계보

원본 Clash가 설정 모델의 기반을 마련했습니다

원본 Clash는 이후 널리 사용된 설정 모델을 정립했습니다. 프록시 노드는 proxies에, 프록시 그룹은 proxy-groups에, 규칙은 rules에 순서대로 배치하고 시스템 프록시, 투명 프록시 또는 다른 진입점으로 트래픽을 받습니다. 규칙이 일치하면 연결은 프록시 그룹이나 지정된 출구로 전달됩니다. 많은 구독과 튜토리얼이 지금도 이 기본 용어를 사용하므로 원본 설정 구조를 이해하는 일은 여전히 유용합니다.

원본 프로젝트의 유지 관리 상태는 이미 달라졌으며, 지원하는 프로토콜과 확장 기능이 현재 mihomo 생태계를 대표하지는 않습니다. 기본 호환 계층을 이해하는 데는 적합하지만 최신 노드 유형의 지원 기준으로 삼아서는 안 됩니다. Hysteria2, TUIC, VLESS 확장, 복잡한 DNS 또는 규칙 프로바이더 옵션이 포함된 설정은 보통 mihomo 계열 코어가 필요합니다. 원본 코어를 고정으로 포함한 구형 클라이언트는 이러한 필드를 인식하지 못할 수 있습니다.

Clash.Meta의 확장 프로토콜과 네트워크 기능

Clash.Meta는 기존 설정 모델에 프로토콜, 전송, DNS, TUN, 스니핑과 규칙 관련 기능을 추가했습니다. 자주 사용하는 Clash 설정의 이전 경로를 최대한 유지하면서 새로운 노드 유형과 필드를 도입합니다. 사용자에게 가장 직접적인 변화는 하나의 구독에 더 다양한 프로토콜 조합을 포함할 수 있고, 클라이언트에서 더욱 완전한 투명 프록시와 DNS 제어를 제공할 수 있다는 점입니다.

확장 기능을 지원한다고 해서 모든 원본 설정이 완전히 같은 결과를 내는 것은 아닙니다. DNS 기본값, 규칙 세트 동작, TUN 스택, 스니핑과 연결 처리는 설정과 구현 업데이트에 따라 달라질 수 있습니다. 이전할 때는 먼저 원본 설정을 보관하고 코어의 설정 검사 기능으로 문법을 확인한 뒤 노드, 프록시 그룹, 규칙, DNS와 TUN을 순서대로 검증하세요. 모든 확장 기능을 한꺼번에 켜면 문제의 원인을 찾기 어렵습니다.

mihomo는 현재 이어진 프로젝트 명칭입니다

mihomo는 Clash.Meta가 이후 사용한 프로젝트 이름입니다. 실제 문서에는 “Meta core”, “Clash.Meta”, “mihomo”가 함께 등장할 수 있습니다. 이는 프로젝트의 역사와 클라이언트 화면에서 사용하는 명칭이 다르다는 뜻이지 서로 무관한 세 코어라는 뜻은 아닙니다. 현재 클라이언트가 mihomo 사용을 표시한다면 일반적으로 Meta 계열의 프로토콜과 설정 기능을 이어받았다는 의미지만, 구체적인 지원 범위는 클라이언트에 포함된 코어와 설정 문서를 기준으로 확인해야 합니다.

GUI 클라이언트와 코어의 업데이트 주기는 서로 다를 수 있습니다. 클라이언트 화면에 새 설정 항목이 추가되려면 하위 코어가 해당 매개변수를 제공해야 하며, 코어가 지원하는 새 필드가 GUI 컨트롤로 아직 구현되지 않았을 수도 있습니다. 대부분의 경우 구독 노드는 코어가 직접 읽으므로 제품 이름에 Clash가 포함되었는지만 보지 말고 실제로 어떤 코어를 호출하는지 확인하는 것이 중요합니다. Clash Plus, Clash Verge Rev, FlClash와 Clash Nyanpasu의 성격과 플랫폼 지원 범위는 클라이언트 비교 페이지에서 이어서 확인할 수 있습니다.

설정 호환성은 계층별로 판단해야 합니다

첫 번째 계층은 YAML 문법 호환성입니다. 들여쓰기, 목록과 키-값 구조가 올바라야 설정을 파싱할 수 있습니다. 두 번째 계층은 필드 인식입니다. 코어가 type, 전송과 확장 필드의 의미를 알아야 합니다. 세 번째 계층은 의미적 호환성으로, 필드가 존재하더라도 기본값이나 조합 제약이 같은지 확인해야 합니다. 네 번째 계층은 TUN 권한, 시스템 프록시 인터페이스, 네트워크 확장과 방화벽 규칙 같은 실행 환경 호환성입니다. 문법 검사만으로는 나머지 세 계층이 정상이라고 증명할 수 없습니다.

기본 SS, VMess, Trojan 노드와 일반적인 프록시 그룹은 대체로 이전 기반이 좋습니다. VLESS, Hysteria2, TUIC, REALITY, 복잡한 DNS와 TUN 옵션은 mihomo 기능에 더 크게 의존합니다. 여러 클라이언트를 동시에 지원해야 한다면 공통 기본 계층을 따로 관리하고, 공통으로 지원되는 노드·프록시 그룹·규칙만 넣으세요. 그런 다음 데스크톱, 모바일과 라우터 기기에 로컬 설정을 추가하는 편이 모든 플랫폼 옵션을 하나의 YAML에 넣는 것보다 유지 관리하기 쉽습니다.

Clash for Windows에서 이전할 때는 GUI 설정과 설정 파일 내용을 구분해야 합니다. 창 동작, 시작 시 실행, 시스템 프록시 포트와 업데이트 설정은 앱 로컬에 저장되어 구독과 함께 이전되지 않을 수 있습니다. 노드, 프록시 그룹과 규칙은 보통 설정에서 가져옵니다. Clash for Windows 지원 종료 후 이전 방법을 참고해 항목별로 정리하고 앱 폴더만 복사하지 마세요.

mihomo -t -f config.yaml

위 명령은 독립 mihomo 코어가 설정 파일을 검사하도록 합니다. 클라이언트에 따라 코어가 앱 내부에 포함되어 있어 사용자가 직접 명령을 실행할 필요가 없을 수 있습니다. 다운로드 페이지에서 제공하는 독립 코어를 사용한다면 터미널에서 파일이 있는 디렉터리로 이동한 뒤 config.yaml을 실제 설정 경로로 바꾸세요. 검사를 통과했다는 것은 문법과 알려진 필드를 읽을 수 있다는 뜻이며, 시작한 뒤 포트, DNS, 규칙과 노드 연결을 계속 테스트해야 합니다.

07 · Subscription

구독 형식, 필드 변환과 호환 범위

구독 링크가 곧 통합 파일 형식은 아닙니다

사용자는 보통 원격 주소 하나를 “구독”이라고 부르지만, 주소가 반환하는 내용은 Clash YAML, URI 목록, Base64로 포장된 텍스트 또는 특정 클라이언트용 JSON일 수 있습니다. 클라이언트에서 직접 가져올 수 있는지는 반환 형식을 인식하는지, 또는 변환 기능이 내장되어 있는지에 따라 달라집니다. HTTP 요청이 성공했다는 것은 파일을 다운로드했다는 뜻일 뿐 노드 필드가 올바르게 파싱되었다는 의미는 아닙니다.

Clash YAML은 보통 포트, DNS, 노드, 프록시 그룹, 규칙과 규칙 프로바이더를 한 번에 설명할 수 있어 전체 설정 배포에 적합합니다. URI 목록은 개별 노드에 더 초점을 두며 각 프로토콜이 자체 링크 구조를 사용하고 복잡한 전송 필드는 쿼리 매개변수로 표현될 수 있습니다. 클라이언트가 URI 목록을 Clash 설정으로 변환할 때는 노드 객체를 만들고 이를 프록시 그룹에 넣어야 합니다. 변환기가 최신 필드를 이해하지 못하면 노드가 누락되거나 매개변수가 사라지거나 유형이 하향 변환될 수 있습니다.

가져온 뒤 네 가지 계층을 확인하세요

첫 단계는 설정이 성공적으로 업데이트되었는지 확인하고 업데이트 시각과 출처 이름을 기록하는 것입니다. 업데이트에 실패하면 먼저 HTTP 상태, 인증서, 네트워크와 링크 유효성을 확인하고 기존 설정을 바로 삭제하지 마세요. 두 번째 단계에서는 노드 수와 유형을 확인해 SS, VMess, Trojan, VLESS, Hysteria2와 TUIC 등 예상 유형이 존재하는지 살펴봅니다. 세 번째 단계에서는 서버 이름, TLS, 전송 경로, UUID, 비밀번호와 UDP 옵션을 중심으로 필드가 온전한지 일부 노드를 점검합니다. 네 번째 단계에서는 프록시 그룹이 참조하는 노드 이름이 여전히 존재하는지 확인해 가져온 노드가 선택 가능한 그룹에 들어가지 못하는 상황을 방지합니다.

노드 표시 이름은 신뢰할 수 있는 고유 식별자가 아닙니다. 구독 업데이트로 이름이 바뀌거나 지역 접두사가 붙거나 정렬 순서가 달라질 수 있어, 이전 이름을 기준으로 작성한 프록시 그룹은 업데이트 후 프록시를 찾지 못할 수 있습니다. 정규식 필터나 프록시 프로바이더를 사용할 때도 새 노드를 실수로 제외하지 않는지 확인하세요. 장기간 고정 선택이 필요하다면 목록 위치에 의존하지 말고 명확한 프록시 그룹과 자동 필터 조건을 사용하는 것이 좋습니다.

구독 변환에서 가장 자주 누락되는 것은 중첩된 전송 매개변수입니다. VMess 또는 VLESS의 WebSocket 경로, Host, gRPC 서비스 이름, Trojan의 SNI, Hysteria2의 인증과 TLS 매개변수, TUIC의 혼잡 제어와 인증 필드는 모두 보존해야 합니다. 변환 후 기본 노드는 작동하지만 특정 유형만 모두 실패한다면 전역 DNS를 수정하기보다 해당 유형의 원본 필드와 생성된 YAML을 먼저 비교하세요.

설정 병합에는 명확한 덮어쓰기 규칙이 필요합니다

일부 클라이언트는 원격 구독 위에 로컬 덮어쓰기를 적용해 사용자 지정 규칙을 추가하거나 DNS를 수정하거나 프록시 그룹을 만들 수 있습니다. 병합 방식은 키 덮어쓰기, 목록 추가, 스크립트 처리 또는 템플릿 생성일 수 있으며 클라이언트마다 순서가 다릅니다. 덮어쓰기 전에 “원격 값이 로컬 값을 덮는지”, “로컬 값이 마지막에 적용되는지” 확인하세요. 특히 rules와 proxy-groups 같은 목록을 주의해야 합니다. 잘못된 추가 순서로 인해 최종 규칙이 먼저 일치하면 이후 규칙은 실행될 기회가 없어집니다.

규칙은 위에서 아래로 일치 여부를 확인하고, 일치하면 검사를 중지합니다. 로컬 설정에서 MATCH 또는 이에 준하는 최종 규칙을 앞에 두면 원격 규칙이 정상적으로 병합되어도 적용되지 않습니다. 프록시 그룹은 이름이 고유하고 참조 관계가 완전해야 하며, 순환 참조는 설정 실패를 일으킬 수 있습니다. DNS 덮어쓰기는 노드 서버 도메인의 확인 경로에도 영향을 줄 수 있으므로 nameserver, fake-ip 또는 프록시 서버의 DNS 설정을 수정한 뒤 노드 도메인이 정상적으로 확인되는지도 함께 테스트하세요.

구독 보안과 유지 관리 습관

구독 주소에는 계정이나 설정을 식별하는 무작위 경로가 포함되는 경우가 많으므로 민감한 설정으로 취급해야 합니다. 공개 페이지, 스크린샷이나 로그에 게시하지 마세요. 문제를 해결할 때는 노드 유형과 비식별 처리한 필드만 보여 주고 전체 구독 주소, 비밀번호와 UUID는 숨겨야 합니다. 다른 사람에게 설정을 보내 도움을 요청하기 전에는 복사본을 만든 뒤 인증 정보를 교체해 현재 사용 중인 원본을 직접 편집하지 않도록 하세요.

구독을 업데이트하기 전에 최근에 작동한 설정을 보관하면 “원격 내용의 변화”와 “로컬 클라이언트의 변화”를 구분하는 데 도움이 됩니다. 업데이트 후 모든 노드가 사라지면 이전 설정으로 되돌려 확인하세요. 이전 설정도 실패한다면 네트워크, 시스템 시간과 서버 상태를 점검합니다. 클라이언트 업그레이드와 구독 업데이트는 가능하면 동시에 진행하지 마세요. 문제가 생겼을 때 변화가 코어에서 왔는지 원격 설정에서 왔는지 확인하기 어려워집니다.

여러 기기에서 같은 구독을 사용할 때는 노드 정보와 플랫폼 설정을 분리하는 것이 좋습니다. 구독은 노드와 공통 정책을 담당하고, 로컬 클라이언트는 시스템 프록시, TUN 권한, 시작 동작과 플랫폼 DNS를 담당하게 하세요. iOS, Android, Windows, macOS와 Linux는 시스템 인터페이스가 다르므로 특정 플랫폼의 경로, 네트워크 인터페이스 이름이나 권한 필드를 공용 설정에 넣으면 이식성이 떨어집니다. 플랫폼별 클라이언트를 선택해야 한다면 다운로드 페이지에서 해당 탭으로 이동하세요. Clash Plus를 모든 플랫폼의 우선 선택지로 두고 나머지 클라이언트는 운영체제와 설정 요구에 맞춰 보완하면 됩니다.

가져오기, 업데이트 또는 프록시 그룹 참조가 계속 비정상이라면 자주 묻는 질문에서 설치·설정과 장애 해결 항목으로 나누어 계속 원인을 찾을 수 있습니다. 설정 구조를 구간별로 읽어야 한다면 Clash 설정 파일 구조 해설을 참고해 포트, 노드, 프록시 그룹과 규칙의 참조 관계를 먼저 이해한 뒤 클라이언트별 덮어쓰기 기능을 다루세요.

08 · Scenario Guide

기기와 사용 환경에 맞춰 프로토콜을 선택하세요

데스크톱 일상 사용: 안정적인 기준선 우선

Windows와 macOS 데스크톱에서는 장기간 안정적인 기본 프록시 그룹을 먼저 만드는 것이 좋습니다. 서버가 Shadowsocks, Trojan 또는 안정적인 VMess 노드를 제공한다면 필드가 완전하고 연결이 안정적인 유형부터 시작하세요. VLESS, Hysteria2와 TUIC은 지원 여부를 확인한 뒤 후보로 추가합니다. 기본 그룹에 모든 노드를 넣을 필요는 없습니다. 노드가 너무 많으면 선택 비용이 커지고 자동 테스트가 연결을 지나치게 자주 만들 수 있습니다. 프로토콜이나 용도별로 프록시 그룹을 나눈 뒤 상위 그룹에서 선택하는 방식이 좋습니다.

클라이언트는 Clash Plus를 모든 플랫폼의 우선 선택지로 삼을 수 있으며, Clash Verge Rev는 데스크톱에서 규칙, 구독과 mihomo 설정 화면이 필요한 사용자에게 적합합니다. 구형 클라이언트에서 이전할 때는 구독과 기본 규칙부터 가져오고 앱 설정을 한꺼번에 복사하지 마세요. 시스템 프록시 포트, DNS와 노드 사용 가능 여부를 확인한 뒤 필요할 때 TUN을 활성화하세요. 이렇게 하면 시스템 권한 문제와 프로토콜 연결 문제를 분리할 수 있습니다.

업무, 회의와 실시간 통신에서는 연속성이 더 중요합니다. 최고 속도가 가장 높은 노드보다 장시간 연결이 안정적이고 네트워크 복구가 신뢰할 수 있는 노드를 선택하세요. 대용량 파일 다운로드나 동기화는 별도의 프록시 그룹으로 분리해 처리량이 높지만 리소스 사용량도 커질 수 있는 Hysteria2, TUIC 또는 다른 노드를 선택하도록 할 수 있습니다. 규칙으로 앱별 그룹을 나누면 전역 노드를 자주 수동 전환하는 것보다 제어하기 쉽습니다.

스마트폰과 태블릿: 네트워크 전환과 백그라운드 복구 우선

모바일에서 가장 먼저 테스트할 항목은 Wi-Fi와 모바일 네트워크 전환, 화면 잠금 후 복구, 약한 신호에서의 재연결과 시스템 VPN 안정성입니다. 고정된 Wi-Fi에서는 빠르지만 네트워크 전환 후 수동 재연결이 필요한 프로토콜은 기본 모바일 노드로 적합하지 않습니다. SS와 Trojan 같은 성숙한 조합을 기준선으로 삼을 수 있습니다. Hysteria2와 TUIC이 실제 모바일 네트워크에서 안정적으로 유지된다면 처리량과 복구 성능이 필요한 작업에 사용할 수 있습니다.

배터리 비교는 최소한 하나의 전체 작업 주기를 포함하고 프록시 모드를 동일하게 유지해야 합니다. 노드 탐색 간격이 너무 짧거나 프록시 그룹의 자동 테스트가 지나치게 빈번하거나 로그가 계속 기록되거나 백그라운드 앱 트래픽이 많으면 배터리 소모가 과장될 수 있습니다. 먼저 자동 테스트 빈도를 줄이고 불필요한 디버그 로그를 끈 뒤 프로토콜을 비교하세요. 그렇지 않으면 결과는 노드 유형보다 클라이언트 설정을 주로 반영하게 됩니다.

iOS와 Android는 백그라운드 정책이 다르고 클라이언트에서 사용할 수 있는 기능도 다릅니다. 데스크톱 YAML의 TUN, 네트워크 인터페이스와 스크립트 매개변수를 모두 모바일에 그대로 복사하지 마세요. 구독에는 노드와 공통으로 지원되는 프록시 그룹만 남기고 플랫폼 권한과 DNS는 모바일 클라이언트에서 로컬로 관리하세요. iOS 사용자는 다운로드 페이지에서 Clash Plus App Store 입구를 선택할 수 있습니다. Android에서는 화면 구성 선호도와 설정 호환성에 따라 Clash Plus, Clash Meta for Android, FlClash와 Surfboard를 비교할 수 있습니다.

라우터와 상시 실행 기기: 리소스와 유지 관리성 우선

라우터, 홈 서버와 소형 Linux 기기는 먼저 CPU 아키텍처, 메모리, 저장 공간과 시스템 서비스 관리 방식을 확인해야 합니다. 독립 mihomo 코어는 명령줄, 설정 파일과 서비스 로그에 익숙한 사용자에게 적합하고 일반 데스크톱 사용자는 GUI 클라이언트가 더 편리합니다. 저전력 기기에서는 GUI 유무보다 규칙 세트 규모, 동시 연결 수와 DNS 캐시가 리소스 사용량에 더 큰 영향을 줄 수 있습니다.

프로토콜 선택은 기기가 지속적으로 처리할 수 있는 처리량을 상한으로 삼아야 합니다. Hysteria2 또는 TUIC은 회선 조건이 좋을 때 우수한 전송 성능을 보일 수 있지만 사용자 공간의 QUIC 처리가 CPU를 점유합니다. 기기의 처리 능력이 부족하다면 SS나 다른 가벼운 조합이 오히려 더 안정적일 수 있습니다. 전송 중 CPU 단일 코어 사용량, 소프트IRQ와 메모리를 확인해 병목이 기기, 회선 또는 서버에 있는지 구분하세요.

상시 실행 기기에는 장애 전환 설정이 특히 필요합니다. 검증된 기본 YAML을 보관하고 실험적인 프로토콜은 별도 프록시 그룹에 넣으세요. 코어를 업데이트하기 전에 설정을 검사하고, 업데이트 후 DNS, 노드, 규칙과 로컬 네트워크 접근을 순서대로 확인합니다. 코어, 구독, 규칙 세트와 시스템 네트워크 구성 요소를 동시에 업데이트하지 마세요. 변화를 나누어 적용하면 시간이 더 걸리는 것처럼 보여도 실제 장애 해결 시간은 크게 줄어듭니다.

반복 실행할 수 있는 의사 결정 절차

첫째, 구독이 실제로 제공하는 프로토콜과 현재 클라이언트 코어를 나열하고 클라이언트에서 노드를 임의로 추측하거나 변환하지 마세요. 둘째, 네트워크 경로별로 그룹을 나눕니다. TCP 계열 노드는 기본 후보로, Hysteria2와 TUIC은 UDP 검증이 필요한 후보로 분류합니다. 셋째, 프로토콜에 필요한 필드가 완전한지 확인합니다. 특히 TLS, SNI, UUID, 비밀번호, 전송 경로와 서비스 이름을 점검하세요. 넷째, 고정된 대상으로 연결 수립, 지속 처리량, 네트워크 전환 후 복구와 리소스 사용량을 테스트합니다.

다섯째, 기기에 맞춰 기본 노드를 선택합니다. 데스크톱은 안정성과 지속 실행, 모바일은 백그라운드 복구와 배터리, 라우터는 리소스 한도와 서비스 관리성을 우선합니다. 여섯째, 장점은 뚜렷하지만 적용 범위가 좁은 노드는 다운로드, 스트리밍 또는 대용량 동기화 같은 전용 프록시 그룹에 넣습니다. 일곱째, 현재 사용 가능한 설정과 테스트 조건을 기록해 구독이나 코어가 바뀐 뒤 다시 비교할 수 있도록 합니다.

결과 차이가 작다면 필드가 명확하고 여러 기기에서 지원되며 유지 관리 비용이 낮은 방식을 선택하세요. 프로토콜 선택의 목표는 이론적으로 가장 복잡한 조합을 찾는 것이 아니라 현재 서버, 네트워크와 기기 조건에서 설명 가능하고 복구할 수 있으며 이전하기 쉬운 연결을 얻는 것입니다. 안정적으로 작동하고 문제를 쉽게 해결할 수 있는 설정이 특정 확장 기능에 크게 의존하는 설정보다 장기 기준선으로 적합한 경우가 많습니다.

선택을 마친 뒤 Clash Verge Rev 튜토리얼로 돌아가 구독 가져오기, 규칙 모드 선택과 연결 확인을 단계별로 진행하세요. 규칙 순서를 더 조정해야 한다면 Clash 트래픽 분할 설정과 프록시 그룹 실전을 참고하세요. 클라이언트에서 계속 설정 오류가 보고되면 원본 로그의 첫 번째 오류 메시지를 보관한 뒤 자주 묻는 질문 페이지에서 설정 파싱, 연결 수립, DNS와 시스템 프록시 네 가지 방향으로 점검하세요.