Clash 프로토콜 및 코어 기술 레퍼런스

1. 먼저 프로토콜 선택 기준 세우기

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

Clash 클라이언트의 프록시 항목에는 일반적으로 프로토콜 유형, 서버 주소, 포트, 인증 정보, 전송 방식 및 여러 확장 매개변수가 함께 들어갑니다. 화면에 표시되는 “VLESS”, “Trojan” 또는 “hysteria2”는 가장 바깥쪽 프로토콜 유형만 나타내며 실제 사용감을 단독으로 결정하지 않습니다. 같은 프로토콜도 안정적인 유선 네트워크와 기지국을 자주 전환하는 모바일 네트워크에서 실행하면 결과가 크게 달라질 수 있습니다. 같은 서버라도 혼잡 제어, TLS 설정 또는 하위 전송 방식을 바꾸면 연결 시간과 리소스 사용량이 달라집니다.

클라이언트는 설정과 코어를 담는 외피입니다. Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, Clash Meta for Android 같은 그래픽 클라이언트는 구독 관리, 시스템 프록시, TUN 전환, 로그 표시를 담당하고, 실제로 프로토콜을 해석해 연결을 수립하는 것은 내부 코어입니다. 특정 프로토콜을 사용할 수 있는지 판단할 때는 클라이언트가 어떤 코어를 사용하는지, 코어가 해당 프로토콜 필드를 인식하는지, 구독 변환 과정에서 필요한 매개변수가 보존되는지, 실행 플랫폼이 필요한 네트워크 기능을 허용하는지 순서대로 확인해야 합니다.

연결 속도만 비교하지 마세요

선택할 때는 최소한 네 가지를 살펴봐야 합니다. 첫 핸드셰이크에 필요한 왕복 횟수, 연결 후 처리량의 안정성, 패킷 손실 시 복구 방식, 기기가 계속 실행될 때의 리소스 비용입니다. TCP 계열 프로토콜은 이해하기 쉽고 시스템 네트워크 스택과 가정용 라우터의 지원이 성숙했습니다. QUIC 또는 UDP 기반 방식은 지연이 크고 어느 정도 패킷 손실이 있는 환경에 강하지만, 재전송·혼잡 제어·연결 상태를 자체적으로 관리하므로 매개변수 조합과 서버 구현이 더 중요합니다.

‘연결이 빠르다’는 말도 세 단계로 나눠 봐야 합니다. 첫 단계는 DNS 조회와 서버 주소 탐색, 두 번째는 TCP·TLS 또는 QUIC 세션 수립, 세 번째가 되어야 대상 사이트와 데이터를 주고받습니다. 도메인 조회가 느린데 이를 프록시 프로토콜 문제로 판단하면 잘못된 결론에 이릅니다. 서버 부하가 높다면 클라이언트에서 프로토콜 이름을 바꿔도 처리량은 개선되지 않습니다. 테스트할 때는 서버, 회선, 시간대, 대상 리소스를 동일하게 유지하고 한 번에 하나의 변수만 바꾸세요.

제약을 먼저 확인한 뒤 선호도를 비교하세요

프로토콜 선택은 보통 여섯 가지 중 아무 것이나 고르는 일이 아닙니다. 먼저 현재 서버에서 제공하지 않거나, 코어가 지원하지 않거나, 네트워크 환경에 맞지 않는 유형을 제외해야 합니다. 구독에 SS 노드만 있다면 클라이언트에서 이를 로컬로 Hysteria2로 바꿀 수 없습니다. VLESS 항목에 서버가 요구하는 Reality 매개변수가 빠져 있다면 유형 필드만 수정해도 연결되지 않습니다. 올바른 순서는 전체 설정을 먼저 확인한 뒤 사용 가능한 범위에서 비교하는 것입니다.

대부분의 데스크톱 사용자에게는 이론상 최고 속도보다 안정성, 설정의 투명성, 문제 원인 파악 가능성이 중요합니다. 모바일 네트워크를 자주 사용하는 경우에는 네트워크 전환 후 복구 속도와 배터리 소모에 더 큰 비중을 두어야 합니다. 먼저 클라이언트를 설치해야 한다면 Clash 다운로드 페이지에서 플랫폼에 맞는 버전을 선택하세요. 데스크톱과 모바일 모두 우선 Clash Plus를 확인하고, 나머지 클라이언트는 운영체제와 인터페이스 취향에 따라 고르면 됩니다.

2. 널리 쓰이는 여섯 가지 프로토콜의 설계상 차이

Shadowsocks: 간결한 구조와 넓은 호환성

Shadowsocks는 보통 SS로 줄여 부릅니다. 핵심 설정은 서버, 포트, 비밀번호, 암호화 방식이며 프로토콜 자체가 비교적 간결하고 오랫동안 다양한 클라이언트와 서버 구현이 축적되었습니다. Clash 사용자에게 SS의 주요 장점은 필드가 적고 이전 비용이 낮으며 문제의 범위를 확인하기 쉽다는 점입니다. 양쪽에서 같은 암호화 방식과 인증 정보를 사용한다면 기본 연결에는 대개 추가 전송 계층 협상이 필요하지 않습니다.

간결하다고 해서 모든 SS 항목이 완전히 호환되는 것은 아닙니다. 일부 서버는 plugin과 plugin-opts로 추가 전송을 설명하는 플러그인이나 특정 확장을 사용합니다. 코어가 해당 플러그인을 지원하지 않으면 기본 SS 기능은 남아 있어도 항목이 예상대로 연결되지 않습니다. 최신 설정에서는 AEAD 암호화 방식을 더 자주 사용합니다. 아주 오래된 알고리즘 이름을 만났다면 YAML에서 대소문자를 반복해서 바꾸기보다 코어가 여전히 이를 허용하는지 먼저 확인하세요.

VMess: 필드가 풍부하고 오래된 설정이 많음

VMess는 V2Ray 생태계와 밀접하며 설정에는 uuid, alterId, cipher, network, TLS, WebSocket 등의 필드가 자주 등장합니다. 많은 구독 형식에서 채택되었던 만큼 오래된 설정과 클라이언트 간 변환 결과에서 여전히 흔히 볼 수 있습니다. VMess의 장점은 성숙한 생태계와 풍부한 전송 조합이며, 단점은 설정 계층이 복잡해 어느 한 항목이라도 서버와 다르면 핸드셰이크가 실패할 수 있다는 점입니다.

VMess를 다룰 때는 프로토콜 인증 정보와 전송 정보를 특히 구분해야 합니다. uuid는 인증 정보이고 network는 하위 전송 방식을 결정합니다. ws-opts 또는 grpc-opts는 구체적인 경로와 호스트 필드를 설명하며, tls와 servername은 보안 세션에 영향을 줍니다. 구독 변환기가 uuid와 주소만 보존하고 WebSocket 경로를 잃으면 생성된 항목은 완전해 보여도 실제로 사용할 수 없습니다. alterId는 오래된 설정에서 자주 보이며, 새 설정에 필요한지는 서버가 제공한 내용을 기준으로 판단해야 합니다.

Trojan: TLS 기반의 명확한 구성

Trojan의 일반적인 항목은 비밀번호, TLS 서버 이름, 선택적 전송 매개변수로 구성됩니다. 표준 TLS 기능을 사용해 보안 세션을 수립하므로 여러 계층으로 구성된 VMess보다 설정을 읽기 쉽습니다. 안정적인 TLS 배포가 이미 갖춰진 서버라면 Trojan은 유지 관리가 쉬운 선택인 경우가 많습니다. 클라이언트에서 가장 흔한 문제는 프로토콜 자체보다 servername, 인증서 이름, 시스템 시간 또는 전송 경로가 서로 일치하지 않는 것입니다.

skip-cert-verify를 true로 설정하면 인증서 검증 오류를 우회할 수 있지만, 일반적인 해결책으로 사용해서는 안 됩니다. 먼저 기기 시간, 서버 이름, 인증서 체인 및 구독 필드를 확인하는 편이 적절합니다. 서버가 WebSocket이나 gRPC를 사용한다면 Trojan 항목에도 해당 매개변수가 필요합니다. TLS가 보인다고 해서 하위 전송이 반드시 일반 TCP인 것은 아닙니다.

VLESS: 인증 정보와 전송 기능을 더욱 분리

VLESS는 가벼운 프로토콜 계층을 강조하고 암호화와 전송 보안을 TLS, Reality 같은 외부 메커니즘에 맡깁니다. 설정에서는 여전히 uuid로 사용자를 식별하지만 실제 연결 가능 여부는 flow, network, servername, reality-opts 등의 조합에 크게 좌우됩니다. 전송 구조를 명확하게 제어해야 하는 배포에 적합하지만, 구독과 코어가 이러한 확장 필드를 완전히 이해해야 합니다.

Reality는 흔히 사용하는 VLESS 연계 기능이지, VLESS와 분리해 단독으로 입력할 수 있는 일반적인 암호화 옵션이 아닙니다. 클라이언트에는 보통 public-key, short-id, servername 등의 정보가 필요합니다. 구독 변환 후 필드 이름이 바뀌거나 계층이 사라지면 로그에는 핸드셰이크 실패로만 나타날 수 있습니다. 문제를 점검할 때는 원본 공유 링크, 변환된 YAML, 코어 로그를 대조해 원인이 원본·변환·실행 중 어느 단계에서 발생했는지 확인해야 합니다.

Hysteria2: 변동이 큰 회선을 위한 QUIC 방식

Hysteria2는 QUIC과 UDP를 기반으로 하며 지연이 크거나 패킷 손실이 있거나 대역폭이 빠르게 변하는 환경에서 전송 효율을 높이는 데 초점을 둡니다. 일부 불안정한 네트워크에서 기존 TCP의 헤드 오브 라인 블로킹 영향을 줄이고, 대역폭·난독화·TLS 관련 매개변수로 동작을 조정할 수 있습니다. 다만 장점이 발휘되려면 클라이언트와 서버 사이의 UDP 경로가 안정적이고 서버 매개변수와 인증서 설정이 올바라야 합니다.

Hysteria2는 설정에 대역폭 수치를 크게 입력할수록 좋은 것이 아닙니다. 상·하행 대역폭은 혼잡 제어 판단에 사용되므로 실제 회선 능력보다 크게 높이면 큐잉과 패킷 손실이 발생할 수 있고, 지나치게 낮으면 사용 가능한 처리량이 제한됩니다. 일부 mihomo 설정에서는 대역폭을 생략하고 더 일반적인 혼잡 제어 방식을 사용할 수 있습니다. 서버가 제공한 항목을 따르고 속도 측정의 순간 최고치만 보고 임의로 높이지 마세요.

TUIC: 낮은 지연과 이동성을 중시하는 방식

TUIC 역시 QUIC을 기반으로 하며 일반적인 설정에는 uuid, password, 혼잡 제어 알고리즘, UDP 릴레이 모드, SNI가 포함됩니다. 연결 수립, 동시 스트림, 네트워크 변화 속에서의 사용성을 중시하므로 지원이 양호한 모바일 환경에서 자연스럽게 작동합니다. Hysteria2와 마찬가지로 TUIC는 UDP 품질과 구현 버전의 조합에 더 민감합니다.

TUIC 설정에서는 프로토콜 버전과 필드 의미에 주의해야 합니다. 오래된 구현마다 인증 정보 형식이나 릴레이 모드가 다를 수 있으므로 ‘TUIC’라는 이름만으로 상호 운용성을 판단할 수 없습니다. 서버가 생성한 구독이라면 가능한 한 원본 그대로 가져오세요. 수동으로 이전할 때는 현재 mihomo 설정 문법을 참고해 항목별로 매핑해야 합니다. 네트워크의 UDP 처리가 불안정하면 TUIC의 이론적 장점이 잦은 재연결로 바뀔 수 있으며, 이때는 성숙한 TCP 계열 프로토콜이 오히려 더 안정적입니다.

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

핸드셰이크 횟수는 최초 연결 비용을 좌우합니다

최초 연결 시간은 DNS, 전송 계층 핸드셰이크, 보안 핸드셰이크, 프로토콜 인증이 함께 결정합니다. 일반 TCP 환경에서 SS는 구조가 짧지만 대상 연결에는 여전히 전체 네트워크 왕복이 필요합니다. Trojan이나 TLS를 사용하는 VMess·VLESS는 TLS 과정을 완료해야 하며, 세션 재개를 활성화하면 이후 연결이 첫 연결보다 눈에 띄게 빨라질 수 있습니다. Hysteria2와 TUIC는 QUIC을 이용해 보안 및 전송 협상을 결합하고 하나의 세션에서 여러 스트림을 처리하므로 짧은 연결이 많을 때 적합하지만, 최초 수립 시간은 여전히 UDP 경로 품질의 영향을 받습니다.

브라우저는 웹페이지를 열 때 기존 HTTP/2 또는 HTTP/3 연결을 재사용하는 경우가 많으므로 사용자가 느끼는 ‘즉시 열림’이 프록시 핸드셰이크 속도와 완전히 같은 것은 아닙니다. 비교할 때는 먼저 기존 연결을 닫거나 세션이 만료될 때까지 기다린 뒤 최초 접속과 연속 접속을 따로 관찰해야 합니다. Clash 로그는 프록시 선택과 오류 단계를 보여주지만 일반 info 수준에서는 각 프로토콜 내부 단계의 정확한 소요 시간을 제공하지 않습니다. 프록시 그룹의 지연 테스트 값을 웹페이지 로딩 속도로 해석하지 마세요. 보통 특정 테스트 주소에 대한 한 번의 연결 결과일 뿐입니다.

처리량은 암호화만이 아니라 회선에 좌우됩니다

최신 기기는 일반적인 AEAD 및 TLS 암호화에 대해 소프트웨어 또는 하드웨어 최적화가 잘 되어 있어 단순 암호화 연산이 데스크톱의 첫 번째 병목인 경우는 많지 않습니다. 서버 CPU, 단일 코어 성능, 네트워크 출구, 패킷 손실, 경로 MTU가 처리량을 더 쉽게 제한합니다. SS는 프로토콜 오버헤드를 예측하기 쉽고, VMess·VLESS·Trojan의 추가 비용은 전송 계층에 따라 달라집니다. WebSocket은 캡슐화가 늘어나고, gRPC는 HTTP/2에 의존하며, QUIC 계열은 사용자 공간에서 더 많은 전송 로직을 처리합니다.

리소스가 부족한 라우터에서는 더 신중해야 합니다. QUIC은 암호화, 재전송, 혼잡 윈도우, 여러 스트림 상태를 관리하므로 저성능 프로세서에서는 시스템 커널이 대부분의 TCP 작업을 담당할 때보다 CPU를 더 사용할 수 있습니다. 반대로 회선의 패킷 손실이 뚜렷하면 QUIC이 스트림 간 헤드 오브 라인 블로킹을 피해 절약하는 대기 시간이 계산 비용을 상쇄할 수도 있습니다. 따라서 유휴 메모리나 특정 순간의 CPU 최고치만 보지 말고, 실제 전송을 몇 분간 지속한 뒤 온도·부하·속도 안정성을 관찰해야 합니다.

모바일 배터리 소모는 깨우기 빈도와 적용 범위가 함께 결정합니다

휴대전화의 배터리 차이는 보통 프로토콜 이름 자체보다 무선 모듈 깨우기, 백그라운드 연결 유지, 네트워크 전환 재연결, TUN 처리 범위에서 발생합니다. 작은 패킷을 계속 생성하는 연결은 모뎀을 자주 깨울 수 있습니다. 상세 로그, 짧은 간격의 상태 점검, 지나치게 잦은 자동 속도 측정도 백그라운드 활동을 늘립니다. Hysteria2와 TUIC는 불안정한 네트워크에서 대기 시간을 줄일 수 있지만 UDP 경로가 불안정해 계속 재시도하면 마찬가지로 전력 소모가 커집니다.

시스템 프록시는 프록시 설정을 따르는 앱에만 영향을 주므로 적용 범위가 비교적 제한적입니다. TUN 모드는 더 많은 트래픽을 인계받고 DNS·라우팅·시스템 프록시를 직접 사용하지 않는 앱까지 처리하므로 일반적으로 더 많은 작업을 맡습니다. Android에서는 시스템 백그라운드 제한과 VPN 서비스 수명 주기도 고려해야 하고, iOS 클라이언트는 Network Extension 실행 방식의 영향을 받습니다. 프로토콜별 배터리 소모를 비교할 때는 프록시 모드, 규칙 집합, 상태 점검 주기, 사용하는 앱을 동일하게 유지해야 합니다.

재현 가능한 로컬 테스트 만들기

효과적인 테스트는 같은 기기, 같은 네트워크, 비슷한 시간대에 진행해야 합니다. 먼저 자동 선택 프록시 그룹을 끄고 하나의 항목으로 고정하세요. 최초 접속, 연속 접속, 장시간 전송, 네트워크 전환 후 복구 상황을 기록한 다음 같은 서버가 제공하는 다른 프로토콜로 바꿉니다. 서버가 같지 않다면 결과는 전체 회선의 차이만 보여줄 뿐 특정 프로토콜이 더 빠르다는 증거가 될 수 없습니다.

4. 전송 계층, TLS 및 핵심 설정 매개변수

network 필드는 전달 방식을 바꿉니다

VMess, VLESS, Trojan은 network 필드로 tcp, ws, grpc 등의 전달 방식을 선택하는 경우가 많습니다. 프로토콜은 인증 정보와 데이터 형식을 담당하고, network는 이 데이터를 하위 연결에 어떻게 담을지 결정합니다. WebSocket 설정에는 보통 경로와 Host가 필요하고, gRPC에는 일반적으로 service-name이 필요합니다. 일반 TCP에도 추가 헤더 옵션이 있을 수 있습니다. 서버가 사용하는 방식을 클라이언트에서 항목별로 맞춰야 하며, 포트가 443이라는 이유만으로 특정 전송 방식이라고 추측해서는 안 됩니다.

WebSocket은 일반적인 웹 서비스 배포 방식과 결합하기 쉽지만 프레임마다 추가 캡슐화가 발생합니다. gRPC는 HTTP/2 기반이라 다중화에 적합하지만 중간 네트워크 장비와 서버의 리버스 프록시가 올바르게 지원해야 합니다. 일반 TCP는 경로가 직접적이어서 문제 원인을 찾기도 쉽습니다. 선택할 때는 기존 서버가 제공한 설정을 기준으로 해야 합니다. 일반적인 구독 사용자라면 network를 수동으로 바꿔도 성능이 저절로 향상되지 않고 클라이언트와 서버가 불일치할 뿐입니다.

servername, Host, 서버 주소는 각각 역할이 다릅니다

server 필드는 클라이언트가 연결할 호스트 또는 IP를 결정합니다. servername은 TLS의 SNI와 인증서 이름 검증에 주로 사용되고, WebSocket의 Host는 HTTP 요청 헤더에 속합니다. 세 값이 같을 때도 있지만 서로 다를 수도 있습니다. 구독 변환기가 이들을 합치면 TCP 연결은 되지만 TLS 또는 상위 요청이 실패하는 경우가 흔합니다. 점검할 때는 로그에 DNS, connect, certificate, handshake, timeout 중 어떤 단계가 표시되는지 먼저 보고 해당 계층을 찾아야 합니다.

기기 시간도 TLS 검증의 일부입니다. 시스템 시계가 크게 어긋나면 Trojan, VLESS TLS, Hysteria2, TUIC에서 인증서 유효 기간 오류가 발생할 수 있습니다. 이때 프로토콜을 바꾸거나 구독을 반복해서 새로 고쳐도 의미가 없으므로 먼저 자동 시간 동기화를 복구해야 합니다. Reality 설정에서는 public-key, short-id, servername, fingerprint도 함께 확인하세요. 이 필드들은 한 묶음이며 어느 하나라도 빠지면 핸드셰이크 단계에서 종료될 수 있습니다.

UDP, MTU 및 조각화 문제

Hysteria2와 TUIC는 UDP에 의존하며, 다른 프로토콜도 UDP 애플리케이션 스트림을 전달할 수 있습니다. UDP 패킷이 가정용 라우터, 모바일 네트워크, 터널을 통과할 때 실제 사용 가능한 MTU는 물리 네트워크 카드의 표시값보다 낮을 수 있습니다. 큰 패킷이 제대로 조각화되지 않으면 작은 요청은 정상인데 대용량 데이터에서 멈추거나 일부 사이트만 작동하고 다른 연결은 시간 초과되는 현상이 나타납니다. TUN 모드에서는 클라이언트의 MTU 설정이 가상 인터페이스 패킷 크기에 영향을 줄 수도 있지만, 증거 없이 무작정 낮춰서는 안 됩니다.

합리적인 점검 순서는 먼저 구독 기본값을 유지하고 TCP 계열 트래픽이 정상인지 확인한 다음 UDP 프로토콜 항목을 확인하는 것입니다. QUIC 연결이 계속 시간 초과되면 같은 서비스 제공자가 제공하는 TCP 계열 프로토콜로 바꿔 비교하세요. TCP는 정상인데 모든 UDP 방식이 실패한다면 로컬 네트워크, 라우터, 서버 UDP 포트를 우선 확인해야 합니다. 클라이언트의 skip-cert-verify만 조정해서는 UDP 경로 문제를 해결할 수 없습니다.

읽기 쉬운 mihomo 설정 예시

아래 예시는 필드 계층을 보여주기 위한 것으로, 바로 연결할 수 있는 서비스 설정이 아닙니다. 도메인과 인증 정보는 문서용 예시이며 실제 사용 시에는 서버가 생성한 완전한 설정을 사용해야 합니다. YAML을 직접 작성할 때는 공백으로 들여쓰고 탭은 사용하지 마세요.

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

  - name: "Trojan 예시"
    type: trojan
    server: proxy.example.com
    port: 443
    password: "your-password"
    sni: service.example.com
    udp: true

proxy-groups:
  - name: "노드 선택"
    type: select
    proxies:
      - "SS 예시"
      - "Trojan 예시"

rules:
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

설정을 YAML로 파싱할 수 있다는 것은 문법이 성립한다는 뜻일 뿐 서버 매개변수가 올바르다는 의미는 아닙니다. 가져온 뒤에는 클라이언트 로그를 확인하세요. unsupported proxy type이 나타나면 코어가 해당 유형을 인식하지 못하는 것입니다. 필드 파싱 오류가 나타나면 키 이름이나 계층이 호환되지 않는 것입니다. 항목은 정상적으로 로드되지만 연결 시간이 초과된다면 주소·포트·전송·네트워크 경로를 계속 확인해야 합니다. YAML 기본 용어는 Clash 용어집과 함께 읽어보세요.

5. Clash 원본, Meta, mihomo 코어의 관계

코어가 설정 파일을 실행할 수 있는지 결정합니다

Clash 생태계에서는 ‘클라이언트’와 ‘코어’를 혼동하는 경우가 많습니다. 원본 Clash는 비교적 이른 시기에 설정 문법과 규칙 모델을 확립한 핵심 구현으로, 프록시 그룹·규칙 분기·DNS·외부 제어 인터페이스 등의 기본 기능을 제공합니다. 그래픽 클라이언트는 이러한 기능을 중심으로 설정 관리와 시스템 통합 기능을 추가합니다. 이후 Clash.Meta가 등장해 원본 문법을 폭넓게 호환하면서 프로토콜·DNS·규칙 집합·TUN 기능을 확장했으며, mihomo는 현재 이 확장 코어에 일반적으로 사용되는 프로젝트 이름입니다.

따라서 ‘Meta 설정’과 ‘mihomo 설정’은 일상적인 상황에서 같은 발전 계열을 가리키는 경우가 많지만, 오래된 문서·구독 생성기·클라이언트 인터페이스에는 여전히 Clash.Meta라는 표기가 남아 있을 수 있습니다. 호환성을 판단할 때는 이름만 보지 말고 클라이언트가 실제로 사용하는 코어 설명과 실행 로그를 확인해야 합니다. Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, Clash Meta for Android 같은 최신 클라이언트는 대체로 mihomo 생태계를 기반으로 기능을 제공하지만 플랫폼마다 코어 업데이트 주기와 노출되는 옵션이 완전히 같지는 않습니다.

원본 호환은 기본일 뿐 역방향 호환을 뜻하지 않습니다

대부분의 기본 SS, VMess, Trojan, 프록시 그룹, 기존 규칙은 원본 설정에서 mihomo로 옮길 수 있습니다. 반대 방향은 성립하지 않습니다. VLESS, Hysteria2, TUIC, GEOSITE, 최신 rule-providers 또는 확장 DNS 필드를 포함한 mihomo 설정은 오래된 원본 코어가 로드를 거부하거나 인식하지 못한 필드를 무시할 수 있습니다. 설정 파일이 여전히 YAML처럼 보여도 Clash라는 이름이 들어간 모든 프로그램에서 실행된다는 뜻은 아닙니다.

호환성 문제는 대략 세 가지로 나뉩니다. 첫째는 프록시 유형 미지원으로, 로그가 보통 type을 가리킵니다. 둘째는 필드 구조 변화로, 일부 TLS·Reality·QUIC 매개변수에 중첩 객체가 필요할 수 있습니다. 셋째는 동작 차이로, 같은 필드를 파싱하더라도 DNS·규칙·인터페이스 바인딩의 기본 동작이 다를 수 있습니다. 이전할 때는 먼저 최소 설정이 파싱되도록 한 다음 DNS·TUN·규칙 집합·스크립트 기능을 단계적으로 복원하세요. 복잡한 파일 전체를 한 번에 가져오면 문제 위치를 찾기 어렵습니다.

그래픽 인터페이스가 코어 차이를 자동으로 해결하지는 않습니다

그래픽 클라이언트는 복잡한 필드를 숨기고 스위치를 제공하며 오류를 표시할 수 있지만, 코어가 모르는 프로토콜을 실행하게 만들 수는 없습니다. 일부 클라이언트는 가져올 때 구독을 변환하고, 일부는 원본 YAML을 그대로 코어에 전달합니다. 전자에서는 필드가 손실될 수 있고 후자에서는 문법 오류가 바로 보고될 수 있습니다. 같은 구독이 클라이언트마다 다르게 작동한다면 인터페이스 이름만 비교하지 말고 양쪽의 코어 계열, 가져온 실제 설정, 로그를 비교해야 합니다.

Clash for Windows와 ClashX Meta는 이미 유지 관리가 중단된 보관용 클라이언트입니다. 과거 생태계를 이해하는 데는 쓸 수 있지만 최신 프로토콜 호환성을 검증하는 기준으로는 적합하지 않습니다. VLESS, Hysteria2, TUIC 또는 최신 geodata 기능이 필요하다면 여전히 mihomo 계열을 사용하는 클라이언트를 선택하세요. 각 플랫폼에서 현재 선택할 수 있는 소프트웨어와 유지 관리 상태는 다운로드 페이지에 모아 두었습니다.

코어를 업데이트하기 전에 되돌릴 설정을 저장하세요

코어 업데이트는 프로토콜 기능을 추가할 수도 있지만 잘못된 설정의 파싱을 더 엄격하게 만들 수도 있습니다. 업그레이드 전에 현재 정상 작동하는 설정과 클라이언트 옵션을 저장하세요. 특히 사용자 지정 DNS, rule-providers, TUN 라우팅, 외부 제어 인터페이스를 보존해야 합니다. 업데이트 후에는 먼저 설정이 성공적으로 로드되는지 확인하고, 다음으로 프록시 그룹이 온전한지, 마지막으로 DNS와 규칙 매칭을 확인하세요. 문제가 새 코어에서만 발생한다면 일단 알려진 정상 환경으로 돌아가 로그를 비교하고, 구독·규칙·시스템 네트워크 설정을 동시에 변경하지 마세요.

6. 구독 형식, 공유 링크 및 변환 호환성

구독은 전달 방식이지 프록시 프로토콜이 아닙니다

사용자는 ‘구독 형식’과 ‘프로토콜 형식’을 함께 이야기하는 경우가 많습니다. 실제로 구독은 노드·프록시 그룹·규칙을 일괄적으로 설명하고, 노드 내부에 SS·VMess·Trojan·VLESS·Hysteria2·TUIC가 들어갑니다. 하나의 구독에는 한 종류의 프로토콜만 포함될 수도 있고 여러 프로토콜이 섞일 수도 있습니다. 같은 프로토콜도 공유 링크, 범용 JSON, Clash YAML, 서버 전용 응답 등으로 전달할 수 있습니다.

클라이언트가 구독을 새로 고칠 때는 보통 다운로드, 식별, 변환, 설정 기록, 코어 로드의 다섯 단계를 거칩니다. 다운로드 실패는 네트워크 또는 인증 오류로 나타나고, 식별 실패는 콘텐츠 유형이 예상과 다르다는 뜻입니다. 변환 실패에서는 확장 필드가 사라질 수 있으며, 기록 실패는 파일 권한과 관련됩니다. 로드 실패일 때에야 YAML 또는 코어 호환성을 의심해야 합니다. 이 다섯 단계를 구분하면 ‘업데이트 실패’만 보고 프로토콜을 계속 바꾸는 일을 피할 수 있습니다.

Clash YAML은 완전한 구조를 표현할 수 있습니다

Clash YAML은 proxies, proxy-groups, rules, dns, rule-providers 등을 동시에 설명할 수 있어 클라이언트가 직접 로드하는 완전한 설정으로 적합합니다. 구조가 명확하고 검토와 조합이 쉽다는 장점이 있지만, 코어마다 지원하는 필드 집합이 다르다는 위험도 있습니다. YAML이 mihomo용 서버에서 생성되었다면 오래된 코어에 가져올 때 지원되지 않는 프록시 유형이나 규칙 기능이 나타날 수 있습니다.

proxies만 포함된 구독이 이상적인 프록시 그룹까지 자동으로 만들어 주는 것은 아닙니다. 일부 클라이언트는 덮어쓰기 또는 전역 확장 기능을 제공해 원격 노드를 로컬 템플릿에 병합합니다. 이때 노드 이름이 중복되지 않는지, 프록시 그룹 참조가 여전히 존재하는지, 업데이트 후 로컬 수정 사항이 덮어쓰이지 않는지 확인해야 합니다. 규칙을 장기적으로 사용자 지정하려면 매번 새로 고쳐져 교체되는 구독 파일을 직접 편집하기보다 원격 노드와 로컬 규칙을 계층별로 관리하는 편이 좋습니다.

공유 링크는 단일 항목 이전에 적합하지만 필드가 인코딩 제한을 받을 수 있습니다

ss://, vmess://, trojan://, vless://, hysteria2://, tuic:// 같은 링크는 개별 항목을 전달하기 편리합니다. 클라이언트는 링크를 읽은 뒤 쿼리 매개변수를 내부 설정에 매핑합니다. 단순한 SS 또는 Trojan 링크는 대체로 직관적이지만 WebSocket, gRPC, Reality, ALPN, 지문, 혼잡 제어 매개변수가 포함되면 링크 파서가 전체 매개변수 집합을 인식해야 합니다.

링크가 인식되어 노드 목록에 나타난다고 해서 모든 필드가 보존된 것은 아닙니다. 가져온 뒤 생성된 설정이나 상세 화면에서 server, port, uuid 또는 password, network, servername, 경로 및 확장 매개변수를 확인하세요. 원본 링크가 다른 생태계에서 왔다면 매개변수 이름을 변환해야 할 수 있습니다. ‘모르는 매개변수’를 삭제해 가져오기 성공만을 추구하지 마세요. 삭제한 필드가 서버 핸드셰이크에 필요한 정보일 수 있습니다.

새로 고침 실패와 프로토콜 사용 불가는 별도로 처리하세요

구독 URL을 다운로드할 수 없다면 클라이언트는 아직 프로토콜 설정에 접근하지도 못한 상태입니다. 이때는 링크가 완전한지, 유효 기간이 남았는지, 접근 방식과 클라이언트 요청 동작이 올바른지 확인해야 합니다. 구독은 정상적으로 업데이트되었지만 특정 노드만 실패할 때 프로토콜 필드를 분석하세요. 새 노드가 모두 로드되지 않는다면 형식이나 코어 문제일 가능성이 높고, 단일 노드만 시간 초과된다면 해당 서버·포트·항목 매개변수 문제일 가능성이 큽니다.

자동 업데이트는 수동으로 수정한 내용을 덮어쓸 수도 있습니다. 프록시 그룹을 수정해야 한다면 클라이언트가 제공하는 덮어쓰기·확장 설정·로컬 설정 기능을 우선 사용하고 원격 구독 원본을 보관하세요. 링크 만료, 요청 방식, 자동 업데이트 간격은 Clash 구독 업데이트 실패의 일반적인 원인과 자동 업데이트 간격 설정에서 계속 확인할 수 있습니다.

7. 프로토콜 외부의 DNS, 규칙, TUN 영향

연결 실패는 프로토콜 선택 전에 발생할 수도 있습니다

클라이언트가 프록시 연결을 수립하기 전에 서버 도메인을 먼저 조회해야 할 수 있습니다. DNS에서 주소를 얻지 못하면 어떤 프로토콜도 실패합니다. 로그의 lookup, resolve, no such host는 보통 조회 단계의 문제를 가리킵니다. connect timeout은 주소를 얻었지만 네트워크 연결을 완료하지 못했다는 뜻이고, handshake 또는 certificate 오류는 프로토콜 및 보안 계층에 더 가깝습니다. 오류가 발생한 단계를 기준으로 처리하는 편이 노드를 계속 바꾸는 것보다 효과적입니다.

Clash의 DNS 모듈은 대상 도메인 조회도 담당하며 fake-ip 또는 redir-host 모드를 사용할 수 있습니다. fake-ip는 먼저 가상 주소를 반환한 뒤 코어가 도메인을 복원하고 규칙을 매칭하므로 TUN과 정밀한 도메인 분기에 적합합니다. redir-host는 실제 조회 결과를 반환하는 방식에 더 가깝습니다. 두 방식은 앱 호환성·캐시·규칙 동작에서 차이가 있지만 원격 노드가 SS인지 VLESS인지 TUIC인지에는 영향을 주지 않습니다.

규칙이 사용할 프록시 그룹을 결정합니다

규칙은 순서대로 매칭되며 한 번 일치하면 아래 규칙으로 계속 내려가지 않습니다. DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR, GEOIP, GEOSITE, MATCH는 트래픽의 목적지를 처리할 뿐 노드 프로토콜을 바꾸지는 않습니다. 특정 트래픽이 항상 DIRECT로 간다면 프록시 그룹에서 Hysteria2를 선택했더라도 해당 트래픽은 이를 통과하지 않습니다. 문제를 점검할 때는 규칙 매칭 기록과 프록시 그룹 선택을 함께 확인해야 합니다.

GEOIP는 IP 지리 데이터베이스에, GEOSITE는 도메인 분류 데이터에 의존합니다. 데이터베이스가 오래되면 규칙 결과가 예상과 달라질 수 있지만 프록시 유형이 지원되지 않게 되는 것은 아닙니다. mihomo는 geodata, MMDB, 규칙 제공자 등의 메커니즘을 사용할 수 있으며 구체적인 파일 출처와 업데이트 방식은 일관되게 유지해야 합니다. 관련 관리 방법은 GeoIP 및 GeoSite 데이터베이스 업데이트 안내에서 확인하세요.

rules:
  - DOMAIN-SUFFIX,github.com,노드 선택
  - DOMAIN-KEYWORD,google,노드 선택
  - GEOSITE,category-ads-all,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

위 순서는 먼저 명확한 도메인과 광고 분류를 처리한 다음 IP 지리 규칙을 적용하고 마지막에 MATCH로 기본 처리합니다. MATCH를 앞에 두면 이후 규칙은 영원히 실행되지 않습니다. 규칙에서 사용하는 정책 이름은 proxy-groups의 이름과 대소문자·공백까지 완전히 같아야 합니다. 프록시 그룹이 존재하지 않는 노드를 참조하면 코어가 설정을 거부하거나 사용할 수 없는 그룹을 남길 수 있으며, 구체적인 동작은 설정 구조에 따라 다릅니다.

TUN은 적용 범위를 바꾸고 점검 계층도 늘립니다

시스템 프록시는 앱이 운영체제의 프록시 설정을 직접 읽어야 하며 브라우저는 보통 이를 지원하지만 터미널 프로그램과 일부 게임은 따르지 않을 수 있습니다. TUN은 가상 네트워크 인터페이스를 만들고 라우팅 계층에서 더 많은 트래픽을 인계받으므로 적용되는 앱이 늘어나는 대신 라우팅·DNS 가로채기·MTU·시스템 권한 같은 변수가 추가됩니다. 시스템 프록시에서는 정상인데 TUN에서 문제가 발생한다고 즉시 프로토콜 비호환으로 단정해서는 안 됩니다. 먼저 트래픽이 TUN에 들어가는지, DNS가 올바르게 인계되었는지, 대상이 우회되지 않았는지 확인하세요.

모바일 기기는 보통 시스템 VPN 인터페이스로 비슷한 기능을 구현합니다. 운영체제는 절전, Wi-Fi와 셀룰러 네트워크 전환, 배터리 절약 모드에서 인터페이스를 다시 만들 수 있습니다. TUIC와 Hysteria2의 QUIC 세션은 네트워크 변화에 대응하도록 설계될 여지가 있지만 클라이언트·시스템·서버가 모두 해당 동작을 지원해야 하며 실제 결과는 기기에서 확인해야 합니다. 자주 끊긴다면 먼저 시스템이 백그라운드 서비스를 종료하는지 확인한 다음 프로토콜 로그를 살펴보세요.

로그로 계층적인 점검 순서를 세우세요

권장 순서는 다음과 같습니다. 설정이 성공적으로 로드되었는지 확인하고, 프록시 항목이 대상 프록시 그룹에 표시되는지 확인합니다. 그다음 서버 도메인 조회, TCP 또는 UDP 포트 연결, TLS·Reality·프로토콜 인증, 규칙이 대상 트래픽을 해당 그룹으로 보내는지, 마지막으로 시스템 프록시 또는 TUN이 대상 앱을 적용 범위에 포함하는지 확인합니다. 각 단계에서 하나의 질문만 해결하면 문제 범위를 크게 줄일 수 있습니다.

브라우저는 작동하지만 터미널이 작동하지 않는다면 대개 터미널이 시스템 프록시 환경을 읽지 않는 것이지, 프로토콜이 브라우저만 지원하는 것은 아닙니다. TUN을 켠 뒤 모든 앱에서 도메인을 조회하지 못한다면 DNS와 TUN 설정을 확인하세요. 더 많은 일반 오류는 FAQ 문제 해결에서 현상별로 찾을 수 있고, 브라우저와 터미널의 차이를 점검하는 절차는 시스템 프록시가 작동하지 않을 때의 점검 방법에서 확인할 수 있습니다.

8. 기기와 네트워크 환경별 프로토콜 선택

데스크톱 일상 사용: 안정성과 유지 관리 우선

Windows와 macOS 데스크톱은 상대적으로 리소스가 충분하므로 프로토콜 연산 비용이 보통 첫 번째 제약은 아닙니다. 서버가 성숙한 SS, Trojan 또는 TLS를 사용하는 VLESS 항목을 제공한다면 설정이 완전하고 장기간 안정적인 항목을 우선 선택하세요. 짧은 연결이 많고 지연이 높으며 UDP 경로가 안정적일 때 Hysteria2 또는 TUIC를 비교하면 됩니다. 데스크톱에서는 테스트가 쉬우므로 TCP 계열 방식을 하나 남겨 대조와 장애 시 대체용으로 사용하세요.

클라이언트는 Clash Plus부터 시작하고, 이후 인터페이스와 플랫폼 요구에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu를 비교하는 편이 좋습니다. 클라이언트 선택과 프로토콜 선택은 분리해서 생각해야 합니다. 그래픽 인터페이스를 바꾸면 설정 관리 경험은 좋아질 수 있지만 두 클라이언트가 비슷한 mihomo 코어를 사용한다면 같은 잘못된 설정은 여전히 실패합니다. 클라이언트를 옮길 때는 원본 구독 주소와 필요한 로컬 덮어쓰기를 내보내고 인터페이스 캐시 파일만 복사하지 마세요.

모바일 네트워크: 전환 복구와 백그라운드 동작 관찰

Android와 iOS는 Wi-Fi, 셀룰러 네트워크, 절전 상태 사이를 자주 전환합니다. 이때 연결 복구 시간, 백그라운드 서비스가 시스템에 의해 유지되는지, UDP 경로가 안정적인지, 하루 동안 배터리가 얼마나 줄어드는지를 중점적으로 관찰해야 합니다. 조건이 맞으면 TUIC와 Hysteria2가 불안정한 네트워크에서 더 부드러운 사용감을 제공할 수 있지만, 현재 통신망의 UDP 품질이 불안정하다면 Trojan, VLESS TLS, SS가 더 신뢰할 만할 수 있습니다.

모바일에서는 연속 속도 측정으로 프로토콜을 선택하지 않는 편이 좋습니다. 빈번한 테스트 자체가 네트워크와 프로세서를 깨우며 일반 앱의 장기 사용 경험을 대표하지도 않습니다. 더 실용적인 방법은 후보 프로토콜을 각각 동일한 규칙과 TUN 설정으로 한 번의 업무 시간 동안 사용하고, 네트워크 전환 후 복구·오디오와 동영상의 연속성·배터리 변화를 기록하는 것입니다. 한 번의 높은 최고 속도가 잦은 연결 끊김보다 중요할 수는 없습니다.

가정용 라우터와 소형 기기: 먼저 프로세서와 메모리 확인

라우터는 여러 기기의 연결, DNS, 규칙 매칭을 동시에 처리해야 합니다. 성능이 낮은 프로세서에서는 단순한 SS 또는 성숙한 TCP/TLS 방식이 안정적인 부하를 유지하기 쉽습니다. Hysteria2와 TUIC는 일부 고지연 회선을 개선할 수 있지만 QUIC의 사용자 공간 전송과 암호화가 CPU 사용량을 높일 수 있습니다. 선택하기 전에 단일 컴퓨터로 한 번 속도를 측정하기보다 실제 동시 접속 환경에서 관찰해야 합니다.

규칙 집합의 규모도 리소스에 영향을 줍니다. 많은 GEOSITE 분류, 원격 rule-providers, 상세 로그는 프록시 프로토콜보다 메모리를 더 사용할 수 있습니다. 기기가 자주 재부팅되거나 코어가 종료된다면 먼저 설정을 줄이세요. 프록시 그룹 하나, 소수의 규칙, 단일 노드만 남겨 안정성을 확인한 뒤 항목을 단계적으로 복원합니다. mihomo 코어 패키지는 명령줄과 서비스 관리에 익숙한 사용자에게 적합하고, 일반 데스크톱 사용자는 그래픽 클라이언트에서 오류를 확인하는 편이 편리합니다.

지연이 높거나 패킷 손실이 있는 회선: 그다음 QUIC 방식 고려

기존 TCP가 패킷 손실 후 뚜렷하게 속도가 떨어지지만 UDP는 안정적으로 통과한다면 Hysteria2와 TUIC를 테스트할 가치가 있습니다. 두 방식 모두 모든 네트워크에서 자동으로 더 빠른 것은 아닙니다. Hysteria2는 대역폭과 혼잡 동작을 회선에 맞춰야 하고, TUIC는 서버·클라이언트 구현 버전, 인증 정보, 릴레이 모드가 일치해야 합니다. 테스트할 때는 같은 서버의 TCP 계열 항목과 비교해야 회선 차이를 최대한 배제할 수 있습니다.

작은 데이터는 정상인데 대용량 전송이 멈춘다면 MTU·UDP 조각화·라우터 상태를 확인하세요. 최초에는 작동하지만 몇 분 후 끊긴다면 세션 시간 초과·NAT 매핑·백그라운드 제한을 확인합니다. 한 번도 연결되지 않는다면 UDP 포트·TLS 이름·인증 필드를 확인하세요. 현상을 분류한 뒤 매개변수를 조정하고 대역폭·MTU·SNI·인증서 검증을 동시에 바꾸지 마세요.

최종 결정 체크리스트

특정 프로토콜을 사용하기 전에 다음 여섯 가지를 순서대로 확인하세요. 서버가 해당 유형을 실제로 제공하는지, 클라이언트가 이를 지원하는 mihomo 코어를 사용하는지, 구독이 인증·전송·보안 필드를 완전히 보존하는지, 현재 네트워크가 필요한 TCP 또는 UDP 경로를 허용하는지, 기기 리소스가 지속 실행에 충분한지, 같은 조건에서 실제 테스트 결과가 안정적인지입니다. 여섯 가지가 모두 충족되어야 선택을 재현할 수 있습니다.

그래도 판단하기 어렵다면 서버가 명확히 권장하고 설정이 완전한 항목을 우선 사용하며 고급 매개변수는 수정하지 마세요. 먼저 가져오기, 프록시 그룹 선택, 연결, 검증의 기본 절차를 완료한 뒤 이 페이지의 방법으로 대조 테스트를 진행하세요. 최초 연결 순서는 노드 선택, 지연 측정 및 프록시 작동 확인에서도 참고할 수 있습니다. 프로토콜에는 환경과 무관한 영구 순위가 없으며, 현재 기기에 적합하고 안정적이며 문제를 진단할 수 있는 선택이 더 가치 있는 결론입니다.