Clash 프로토콜 및 mihomo 코어 선택 가이드

재사용 가능한 프로토콜 선택 모델 세우기

프로토콜, 전송 방식, 클라이언트를 먼저 구분하기

Clash 설정 화면에서 보이는 SS, VMess, Trojan, VLESS, Hysteria2, TUIC은 노드 연결 방식입니다. 반면 Clash Plus, Clash Verge Rev, FlClash 등은 그래픽 클라이언트이고, mihomo는 설정을 해석하고 연결을 수립하며 규칙을 실행하는 코어입니다. 세 요소는 서로 다른 계층에 있습니다. 클라이언트는 조작 방식과 시스템 연동을 결정하고, 코어는 설정 문법과 프로토콜 기능을 결정하며, 프로토콜은 개별 프록시 연결의 핸드셰이크, 암호화, 다중화와 데이터 전송 방식을 결정합니다. 이 개념을 섞으면 “클라이언트를 바꾸면 속도가 반드시 빨라지는가” 또는 “구독을 가져올 수 있으면 노드도 사용할 수 있는가” 같은 잘못된 판단을 하게 됩니다. 그래픽 인터페이스를 바꿔도 회선 환경이 직접 바뀌지는 않지만, 클라이언트에 포함된 코어 버전, 기본 DNS, TUN 구현과 연결 매개변수가 최종 성능에 영향을 줄 수 있습니다.

프로토콜 선택은 단순한 속도 순위가 아닙니다. 실제 연결 품질은 서버 처리 성능, 클라이언트 기기 성능, 네트워크 왕복 시간, 패킷 손실, 전송 계층 동작, 도메인 해석 경로와 규칙 적용 결과가 함께 결정합니다. 프로토콜은 그중 일부만 제어합니다. 예를 들어 안정적인 유선 네트워크에서는 기존 TCP 프로토콜이 대체로 안정적입니다. 기지국을 자주 전환하거나 간헐적인 패킷 손실이 있는 모바일 네트워크에서는 UDP 기반으로 혼잡 제어를 직접 관리하는 방식이 더 빠르게 복구될 수 있지만, 지속 실행과 연결 유지, 재전송 전략 때문에 배터리 소모가 늘어날 수도 있습니다. 네트워크 조건을 제외한 “가장 빠른 프로토콜” 논의는 대개 재현하기 어렵습니다.

네 가지 질문으로 범위 좁히기

첫째, 현재 클라이언트의 코어가 목표 프로토콜과 필수 필드를 지원하는지 확인합니다. 원본 Clash의 지원 범위는 일찍 고정되었고, 이후 등장한 VLESS, Hysteria2, TUIC 등은 주로 Meta 계열과 mihomo에서 확장되었습니다. 둘째, 구독에 완전한 노드 매개변수가 포함되어 있는지, 아니면 이름과 서버 주소만 있는지 확인합니다. 프로토콜 이름이 같아도 설정을 그대로 바꿔 쓸 수 있는 것은 아닙니다. 인증 식별자, TLS 서버 이름, 전송 유형, UDP 지원, 인증서 검증 건너뛰기 등의 필드가 핸드셰이크에 영향을 줄 수 있습니다. 셋째, 주로 사용할 플랫폼을 정합니다. 데스크톱은 시스템 프록시, TUN 적용 범위와 장시간 안정성을 중시하고, 모바일은 백그라운드 연결 유지, 네트워크 전환과 배터리 제한까지 확인해야 합니다. 넷째, 주요 트래픽이 짧은 연결의 웹 탐색인지, 지속 다운로드인지, 실시간 음성·영상인지, 대량 동시 요청인지 판단합니다. 연결 방식에 따라 핸드셰이크 비용, 선두 차단과 다중화에 대한 민감도가 다르기 때문입니다.

1. 먼저 해석 가능 여부 확인

   클라이언트로 가져온 뒤 노드 유형이 인식되는지 확인하고, 설정 로그에 알 수 없는 유형이나 누락된 필드가 없는지 살펴봅니다.

2. 그다음 연결 가능 여부 확인

   같은 네트워크에서 핸드셰이크, 웹 접속과 지속 전송을 각각 테스트합니다. 한 번의 지연 시간 측정만으로 판단하지 마세요.

3. 마지막으로 장시간 실행에 적합한지 확인

   네트워크 전환, 시스템 절전 복귀, 백그라운드 배터리 소모와 규칙 적용 결과를 관찰해 짧은 순간의 최고치를 안정적인 결론으로 착각하지 않도록 합니다.

테스트 조건을 동일하게 유지

프로토콜을 비교할 때는 클라이언트, 코어, 서버 지역, 테스트 시간대와 DNS 설정을 고정하고 대역폭을 지속적으로 사용하는 동기화 프로그램은 종료합니다. 먼저 직접 연결 상태를 기록한 뒤 후보 노드를 하나씩 테스트하세요. 지연 시간 테스트는 탐색 요청의 왕복 시간만 보여 주며 페이지 로딩 속도와 같지 않습니다. 다운로드 최고 속도 역시 불안정한 네트워크에서의 복구 능력을 나타내지 않습니다. 더 신뢰할 수 있는 방법은 여러 리소스가 포함된 웹페이지를 여러 번 열고, 몇 분간 안정적으로 전송한 뒤, Wi-Fi와 모바일 네트워크를 전환하면서 연결 복구를 관찰하는 세 가지 작업을 연속으로 수행하는 것입니다. 결과 차이가 작다면 이론적인 기능을 위해 설정을 복잡하게 만들기보다 구성이 단순하고 클라이언트 지원이 성숙한 쪽을 선택하세요.

SS, VMess, Trojan, VLESS, Hysteria2와 TUIC의 설계상 트레이드오프

SS: 구조가 단순하고 호환 범위가 넓음

Shadowsocks는 보통 SS라고 부르며, 적은 프로토콜 계층으로 암호화 프록시를 구현하는 데 중점을 둡니다. 노드 설정은 주로 서버, 포트, 비밀번호와 암호화 알고리즘으로 구성되므로 필드 수가 비교적 적습니다. 따라서 클라이언트나 구독 형식을 바꿔도 설정을 동일하게 유지하기 쉽습니다. 최신 구현은 대개 AEAD 계열 암호화 알고리즘을 사용합니다. 알고리즘을 선택할 때는 클라이언트와 서버가 모두 지원하는지 확인해야 하며, 이름이 비슷해도 구현 범위가 다른 알고리즘을 임의로 바꿔서는 안 됩니다. SS는 구현이 성숙하고 핸드셰이크 부담이 적으며 다양한 기기를 지원해 설정 변수를 줄이고 싶은 경우에 적합합니다. SS 자체에는 복잡한 전송 위장 계층이 정의되어 있지 않으므로, 추가 플러그인이나 다른 전송 캡슐화를 사용하면 호환성 요구 사항이 늘어납니다. 이때 “SS 지원”을 “모든 SS 확장 지원”으로 이해해서는 안 됩니다.

VMess와 VLESS: 통합 인증에서 경량 프로토콜 계층으로

VMess는 사용자 식별자, 인증과 연결 절차를 프로토콜 안에 결합하며, 일반적인 설정에는 UUID, 전송 네트워크, TLS, Host, Path 등의 필드가 포함됩니다. 여러 전송 방식을 통합 관리해야 했던 클라이언트 생태계에서 만들어졌기 때문에 오래된 구독에 많이 남아 있습니다. 문제는 사용할 수 없다는 데 있지 않고 매개변수 조합이 많다는 데 있습니다. WebSocket, HTTP 계열 전송, gRPC와 일반 TCP는 필드 위치가 다르므로 구독 변환 과정에서 경로, 호스트 이름이나 서비스 이름이 누락되기 쉽습니다. VMess를 점검할 때는 UUID와 포트만 비교하지 말고 전송 유형부터 확인해야 합니다.

VLESS는 프로토콜 계층을 더 가볍게 설계하고, 기밀성과 서버 인증을 TLS 같은 외부 계층에 맡기는 경우가 많습니다. 즉 VLESS는 이름만 선택한다고 완전한 암호화가 자동으로 적용되는 통합 방식이 아닙니다. 클라이언트가 TLS, 서버 이름, 인증서 검증과 선택한 전송 방식을 올바르게 처리해야 합니다. 프로토콜 오버헤드가 명확하고 다양한 전송 방식과 조합하기 쉽다는 장점이 있지만, 설정 완성도에 더 민감합니다. 구독 변환 도구가 서버와 UUID만 남기고 flow, server name, transport 또는 Reality 관련 필드를 누락하면 노드는 가져와져도 핸드셰이크에 실패합니다. mihomo는 VLESS를 비교적 완전하게 지원하지만, 실제 설정 필드와 현재 코어가 인식하는 문법을 기준으로 확인해야 합니다.

Trojan: TLS 연결을 기반으로 한 직관적인 모델

Trojan의 일반적인 설정은 비밀번호, TLS 서버 이름과 인증서 검증을 중심으로 구성되며 데이터는 TLS 연결 위에서 전달됩니다. 이해 순서도 간단합니다. 먼저 도메인과 인증서의 관계가 올바른지 확인하고, 비밀번호와 포트를 점검한 다음 UDP 사용 여부를 확인합니다. Trojan이 어떤 상황에서나 VMess보다 빠르다는 뜻은 아닙니다. 같은 네트워크 경로와 비슷한 전송 방식을 사용하면 차이가 회선 변동보다 작을 수 있습니다. Trojan의 실질적인 장점은 설정 모델이 명확하고 주요 Meta 및 mihomo 클라이언트의 지원이 성숙하다는 점입니다. IP 주소로 연결하면서 TLS는 도메인 신원을 요구하는 경우 올바른 server name을 유지해야 하며, 서버 주소를 모든 TLS 필드에 기계적으로 복사해서는 안 됩니다.

Hysteria2와 TUIC: UDP 전송과 불안정한 네트워크 복구에 초점

Hysteria2는 QUIC 체계로 연결을 구성하며, 애플리케이션 계층에서 혼잡 제어와 패킷 손실 환경의 처리량 회복을 중시합니다. 왕복 시간이 길거나 대역폭 변동이 크고 간헐적인 패킷 손실이 있는 네트워크에 적합하지만, UDP 도달 가능성, 서버 매개변수와 적절한 대역폭 설정에 따라 결과가 달라집니다. 실제 네트워크보다 훨씬 높은 업로드·다운로드 능력을 입력한다고 속도가 자동으로 빨라지지는 않으며, 오히려 큐 대기와 자원 경쟁이 발생할 수 있습니다. 설정할 때는 인증 비밀번호, TLS 서버 이름, 포트 점프나 난독화 같은 선택 항목을 양쪽에서 동일하게 활성화했는지도 확인해야 합니다.

TUIC 역시 QUIC과 UDP를 기반으로 하며 다중 연결, 인증과 네트워크 변화 중 연결 연속성을 강조합니다. mihomo 호환 설정에서 자주 보이며 UUID, 비밀번호, 혼잡 제어 알고리즘, UDP 릴레이 모드와 인증서 옵션이 포함될 수 있습니다. TUIC과 Hysteria2는 둘 다 UDP를 사용한다고 해서 서로 바꿔 쓸 수 있는 프로토콜이 아닙니다. 핸드셰이크, 인증, 매개변수 이름과 서버 구현이 다릅니다. 선택할 때는 클라이언트에서 노드 유형을 임의로 수정하지 말고 서버가 실제로 제공하는 유형을 기준으로 해야 합니다. 모바일 네트워크에서 연결이 더 빠르게 복구될 수 있지만, 지속적인 연결 유지, 활발한 UDP 세션과 시스템 백그라운드 정책이 배터리 소모에 영향을 줄 수 있습니다.

연결 속도, 안정성과 리소스 사용량을 올바르게 비교하는 방법

핸드셰이크 속도와 지속 처리량은 다른 지표

웹페이지를 처음 열 때는 DNS 조회, TCP 또는 QUIC 연결 수립, TLS 핸드셰이크와 첫 요청의 응답 시간이 더 큰 영향을 줍니다. 대용량 파일 전송은 혼잡 제어, 회선 용량과 지속적인 패킷 손실 상태에 더 좌우됩니다. SS는 프로토콜 계층이 단순해 복잡한 추가 핸드셰이크를 거의 만들지 않습니다. Trojan과 TLS를 활성화한 VMess·VLESS는 TLS 절차를 완료해야 하지만 연결 다중화와 세션 복구로 후속 요청 비용을 낮출 수 있습니다. Hysteria2와 TUIC은 QUIC으로 보안 연결을 수립하며, 최초 연결에는 역시 핸드셰이크가 필요하지만 연결이 만들어진 뒤에는 하나의 연결로 여러 스트림을 전달할 수 있습니다. 따라서 “지연 시간 테스트를 한 번 클릭하는 것”만으로는 좁은 동작 구간만 확인할 뿐, 지속 다운로드나 여러 리소스가 있는 페이지의 사용 경험을 완전히 나타낼 수 없습니다.

TCP의 선두 차단은 같은 연결에서 패킷이 손실되면 이후 데이터가 재전송을 기다리게 한다는 뜻입니다. QUIC은 스트림 단위로 전송을 처리해 한 스트림의 패킷 손실이 다른 스트림에 미치는 영향을 줄일 수 있지만, 하위 네트워크의 UDP 품질이 나쁘면 이론적인 장점이 드러나지 않을 수 있습니다. 일부 네트워크는 UDP 세션 유지 시간을 짧게 설정해 유휴 상태 후 다시 핸드셰이크하게 만들고, 일부 라우터는 많은 UDP 세션을 처리하는 데 한계가 있습니다. 선택할 때는 실제 애플리케이션을 관찰해야 합니다. 짧은 연결의 반복 실패, 장시간 전송 속도 변동, 절전 복귀 지연은 각각 다른 문제에 해당하며 프로토콜 이름 하나로 통일해 설명할 수 없습니다.

CPU, 메모리와 연결 수

리소스 사용량은 우선 코어 구현과 규칙 규모에 좌우되고, 그다음에 프로토콜의 영향을 받습니다. 대규모 규칙 집합, 복잡한 DNS 처리, TUN 트래픽 가로채기, 연결 스니핑과 로그 수준은 암호화 자체보다 많은 리소스를 사용할 수 있습니다. SS가 최신 AEAD 알고리즘을 사용할 때 데스크톱 프로세서는 대체로 효율적으로 처리합니다. 오래된 저전력 기기에서는 알고리즘별 하드웨어 가속 지원 여부가 CPU 사용량에 영향을 줍니다. VMess는 프로토콜 처리와 여러 전송 방식의 조합으로 작업량이 늘 수 있으며, 특히 WebSocket, TLS와 다중화를 겹쳐 사용할 때 두드러집니다. Trojan과 VLESS의 비용은 TLS 구현과 선택한 전송 방식에 밀접하게 관련됩니다. Hysteria2와 TUIC은 QUIC 상태, 확인 응답과 혼잡 제어를 유지해야 하므로 고속 또는 패킷 손실 환경에서 CPU를 더 사용할 수 있지만, 처리량을 더 잘 회복해 작업 완료 시간을 줄일 수도 있습니다.

메모리 사용량은 클라이언트 주 프로세스만 봐서는 안 됩니다. 그래픽 인터페이스, WebView, 시스템 트레이, 로그 캐시와 코어가 함께 실행되는 경우가 많습니다. Clash Plus, Clash Verge Rev와 FlClash를 비교할 때는 동일한 설정, 실행 시간과 연결 수를 유지하고 인터페이스 프로세스와 mihomo 코어 프로세스를 구분해 관찰해야 합니다. 한 클라이언트가 유휴 상태에서 적은 메모리를 사용한다고 해서 수십만 개의 규칙을 불러온 뒤에도 같다는 뜻은 아닙니다. 단일 연결에서 프로토콜 오버헤드가 작아도 동시 연결을 많이 열면 누적 비용이 발생할 수 있습니다. 라우터와 소형 서버에서는 프로토콜을 계속 바꾸기보다 규칙 제공자 수를 줄이고, 필요 없는 상세 로그를 끄며, 연결 다중화와 동시성을 조절하는 편이 대체로 효과적입니다.

재현 가능한 3단계 테스트

첫 단계는 연결 수립 테스트입니다. 기존 연결을 정리한 뒤 서로 다른 여러 도메인에 연속으로 접속하고 최초 대기나 간헐적인 핸드셰이크 실패가 발생하는지 기록합니다. 두 번째는 안정적인 전송 테스트입니다. 몇 분 동안 속도 곡선, CPU 사용량과 연결 재설정을 관찰하고 순간 최고치만 기록하지 않습니다. 세 번째는 복구 테스트입니다. 기기를 절전 상태로 전환했다가 깨우거나 Wi-Fi와 모바일 네트워크 사이를 전환한 뒤 노드가 자동으로 복구되는지, DNS가 계속 작동하는지, 기존 연결이 올바르게 정리되는지 확인합니다. 후보 프로토콜마다 최소 두 차례 반복하고 규칙 모드는 동일하게 유지하세요. 결과가 비정상적이면 먼저 로그에서 timeout, TLS, DNS 또는 UDP 오류 유형을 확인한 뒤 비교에 포함할지 결정합니다.

모바일 배터리, 백그라운드 실행과 네트워크 전환

배터리 소모는 암호화만이 아니라 지속적인 작업에서 발생

모바일에서 Clash 계열 클라이언트를 실행하면 배터리 소모는 네트워크 송수신, CPU 깨우기, VPN 또는 TUN 가로채기, DNS 조회, 규칙 매칭, 로그 기록과 시스템 백그라운드 스케줄링이 함께 결정합니다. 프로토콜 암호화는 그중 한 요소일 뿐입니다. 앱이 많은 연결을 계속 유지하거나 상태 확인을 자주 수행하거나, 정책 그룹이 짧은 간격으로 여러 노드를 테스트하면 실제 트래픽이 적어도 기기가 저전력 상태에서 계속 깨어날 수 있습니다. 반대로 계산량이 조금 더 많더라도 연결을 안정적으로 유지하는 프로토콜은 자주 연결이 끊겼다 재연결되는 단순한 프로토콜보다 실제 배터리 소모가 적을 수 있습니다. 따라서 몇 분 동안의 시스템 배터리 비율만으로 결론 내리지 말고, 완전한 사용 주기를 기준으로 관찰해야 합니다.

SS, Trojan, VMess와 VLESS는 주로 TCP 또는 TCP 기반 전송에서 작동합니다. 시스템의 TCP 연결 상태 관리는 성숙해 유휴 연결이 낮은 활동 상태로 들어가기 쉽지만, 모바일 네트워크 전환 후에는 기존 연결이 시간 초과되거나 다시 수립되어야 할 수 있습니다. Hysteria2와 TUIC은 UDP와 QUIC을 기반으로 하며 일정 조건에서 네트워크 변화를 더 빠르게 처리할 수 있지만, 더 활발한 확인 응답, 연결 유지와 혼잡 제어로 세션을 유지할 수도 있습니다. 배터리 소모는 클라이언트 구현, keep-alive 매개변수, 네트워크 품질과 시스템의 UDP 처리 방식에 따라 달라지므로 특정 프로토콜이 항상 더 절전적이거나 더 많은 전력을 쓴다고 단정할 수 없습니다.

Android 배터리 최적화와 백그라운드 제한

Android 제조사마다 백그라운드 앱, VPN 서비스와 자동 시작 정책을 처리하는 방식이 크게 다릅니다. 화면을 잠근 뒤 시스템이 클라이언트를 중지하면 알림이 사라지고 네트워크에 접속할 수 없다가 앱을 다시 열면 복구되는 경우가 많습니다. 이때는 먼저 시스템의 배터리 최적화, 백그라운드 활동, VPN 상시 알림과 자동 시작 권한을 확인해야 하며, 곧바로 노드 프로토콜을 바꿀 필요는 없습니다. Clash Plus, Clash Meta for Android와 FlClash의 화면 경로는 다르지만 판단 순서는 같습니다. 코어가 계속 실행 중인지 확인하고, VPN 인터페이스가 존재하는지 확인한 다음 노드 연결 로그를 살펴보세요. 코어가 반복해서 재시작된다면 상태 확인 빈도를 낮추고 상세 로그를 잠시 끄며, 설정에 지나치게 큰 규칙 집합이 포함되어 있지 않은지 점검합니다.

정책 그룹도 배터리를 소모하는 흔한 원인입니다. url-test는 설정한 간격마다 여러 후보 노드를 탐색합니다. 노드가 많고 간격이 짧으면 네트워크가 계속 깨어납니다. fallback은 사용 가능 여부를 감시하고, load-balance는 더 많은 연결을 동시에 유지할 수 있습니다. 모바일 기기에서 주로 고정 노드를 사용한다면 후보 수를 줄이고 테스트 간격을 적절히 늘리세요. 이러한 정책의 차이는 Clash 정책 그룹 유형 자세히 알아보기에서 확인할 수 있습니다. 규칙 제공자의 업데이트 간격도 합리적으로 설정해야 하며, 짧은 시간에 거의 바뀌지 않는 목록을 반복해서 가져올 필요는 없습니다.

iOS와 시스템 VPN 수명 주기

iOS 클라이언트는 시스템이 제공하는 네트워크 확장 기능으로 작동합니다. 앱 화면을 닫았다고 해서 프록시 연결이 반드시 중지되는 것은 아니며, 실제 상태는 시스템 VPN 표시와 클라이언트 코어 상태를 기준으로 확인해야 합니다. iOS용 Clash Plus는 App Store에서 제공되며, 설정할 때 시스템에서 처음 VPN을 수립할 때 표시되는 권한 요청에 주의해야 합니다. Wi-Fi 전환 후 잠시 도메인이 해석되지 않으면 먼저 시스템 네트워크 경로가 안정될 때까지 기다린 다음 DNS와 노드 재연결을 확인하세요. 수동으로 반복해서 켜고 끄면 문제를 재현하기 어려워질 수 있습니다. 백그라운드 실행은 시스템이 통합 관리하며 사용자가 조정할 수 있는 항목이 Android보다 적으므로, 설정을 단순하게 유지하고 고빈도 탐색과 불필요한 로그를 줄이는 편이 좋습니다.

시스템 통계로 장기간 관찰하기

프로토콜의 배터리 소모를 평가할 때는 일상 사용 강도가 비슷한 두 시간대를 골라 후보 프로토콜을 각각 실행하고 화면 밝기, 네트워크 유형, 정책 그룹과 백그라운드 앱을 최대한 동일하게 유지하세요. 시스템 배터리 페이지의 화면 사용 시간, 백그라운드 시간과 네트워크 활동을 관찰하고 총 배터리 비율만 비교하지 마세요. 특정 테스트에서 비정상적인 소모가 나타나면 클라이언트 재시작, 연결 실패, 노드 탐색 증가 또는 약한 네트워크 신호가 동반되었는지 먼저 확인합니다. 신호가 약하면 모바일 기지국이 송신 출력을 높이므로 프록시 프로토콜 자체보다 영향이 클 수 있습니다. 더 자세한 점검 절차는 Clash 모바일 배터리 이상 문제 해결에서 확인할 수 있습니다.

원본 Clash, Meta와 mihomo 코어 계열의 관계

원본 Clash: 설정 기반과 호환성 기준

원본 Clash는 proxies, proxy-groups, rules, DNS, 규칙 제공자와 제어 인터페이스 등 핵심 개념을 포함한 널리 사용되는 YAML 설정 구조를 확립했습니다. 많은 구독 변환기와 그래픽 클라이언트도 여전히 이 필드를 호환성 기준으로 삼습니다. SS, VMess, Trojan 같은 주요 유형에 대한 문법은 성숙했지만 프로젝트의 유지보수 상태와 기능 범위는 이미 고정되어 있으므로 이후 프로토콜이나 복잡한 네트워크 기능이 당연히 포함된다고 보면 안 됩니다. 어떤 설정에 “Clash 형식”이라고 표시되어 있어도 이는 해당 설정 계열을 사용한다는 뜻일 뿐, 원본 코어가 모든 노드를 해석할 수 있다는 보장은 아닙니다.

원본 문법은 여전히 중요한 가치가 있습니다. 기본 프록시 그룹, 도메인 규칙, IP 규칙과 MATCH 규칙은 이식성이 높습니다. 설정이 이러한 공통 기능만 사용한다면 파생 코어 사이에서 옮겨도 대체로 안정적입니다. 문제는 확장 노드 유형, 규칙 문법, 고급 DNS 옵션, TUN 매개변수와 프로토콜 전용 필드에서 주로 발생합니다. 따라서 호환성을 판단할 때 파일 확장자가 YAML인지, 최상위 키 이름이 무엇인지만 봐서는 안 됩니다. 코어가 노드의 type, 정책 그룹 동작과 확장 규칙을 인식하는지 항목별로 확인해야 합니다.

Clash Meta: 신규 프로토콜과 고급 네트워크 기능을 위한 계열

Clash Meta는 원본 설정 모델을 기반으로 VLESS, Hysteria, Hysteria2, TUIC, WireGuard 등의 유형을 확장하고 DNS, 규칙, TUN, 스니핑과 전송 매개변수 지원을 강화했습니다. 오래된 자료에서는 이러한 기능을 지원하는 코어를 통칭해 Meta라고 부르는 경우가 많습니다. 사용자에게 중요한 것은 계열의 역사를 외우는 것이 아니라 Meta 설정에 원본이 인식하지 못하는 필드가 포함될 수 있다는 점입니다. Meta 구독을 원본 Clash만 지원하는 클라이언트로 가져오면 일부 매개변수가 무시되거나 로딩 단계에서 오류가 발생할 수 있습니다. 반대로 기본 원본 설정은 대체로 Meta 계열 코어에서 읽을 수 있지만 일부 기본 동작은 다를 수 있습니다.

mihomo: 현재 널리 사용되는 계승 구현

mihomo는 Meta 계열 기능을 이어받아 유지보수하며 Clash Plus, Clash Verge Rev, FlClash 등 현대적인 클라이언트에서 자주 선택되는 코어입니다. Clash 설정의 주요 구성 방식을 유지하면서 신규 프로토콜, 규칙 집합, TUN과 DNS 기능도 계속 지원합니다. 이름이 바뀌었다고 설정을 처음부터 다시 작성해야 하는 것은 아니며 많은 Meta 설정을 계속 사용할 수 있습니다. 다만 “대체로 호환됨”이 모든 기존 필드가 영원히 동일하다는 뜻은 아닙니다. 클라이언트를 업그레이드하거나 설정을 옮긴 뒤에는 시작 로그의 사용 중단 안내, 알 수 없는 필드와 해석 오류를 확인하고 현재 문서에 맞게 조정해야 합니다. 변환기가 파일 전체를 반복해서 수정하도록 맡겨서는 안 됩니다.

그래픽 클라이언트와 코어는 고정된 연결 관계가 아닙니다. 일부 클라이언트는 코어를 전환하거나 코어 구성 요소를 업데이트할 수 있고, 일부는 코어와 앱 배포 패키지를 함께 제공합니다. 문제를 확인할 때는 “정보”, “코어” 또는 로그 페이지에서 실제 실행 중인 구현을 확인해야 하며 클라이언트 이름만으로 추측하지 마세요. Clash for Windows와 ClashX Meta는 유지보수가 중단되었으므로 일부 오래된 설정을 읽을 수는 있지만 신규 프로토콜 호환성을 검증하는 유일한 환경으로 사용하기에는 적합하지 않습니다. VLESS, Hysteria2 또는 TUIC이 필요하다면 mihomo 또는 Meta 기능을 명확히 지원하는 클라이언트를 우선 선택하세요.

mixed-port: 7890
mode: rule
ipv6: false

profile:
  store-selected: true
  store-fake-ip: true

위 예시는 일반적인 최상위 설정만 사용하며 YAML 들여쓰기와 코어 로딩을 확인하는 최소 출발점으로 활용할 수 있습니다. 노드, 구독 주소와 규칙이 포함되어 있지 않아 단독으로 프록시 연결을 완료할 수는 없습니다. 완전한 설정은 신뢰할 수 있는 구독이나 명확한 수동 매개변수로 보완해야 합니다. 프로젝트 관계는 Clash 오픈 소스 생태계 프로젝트 관계와 원본, Meta와 mihomo 기능 호환성 비교에서 더 확인할 수 있습니다.

구독 형식, YAML 필드와 변환 호환성

가져올 수 있다고 필드가 완전한 것은 아님

구독은 보통 두 가지 형태로 클라이언트에 들어옵니다. 하나는 노드, 정책 그룹, 규칙과 DNS가 이미 포함된 완전한 Clash YAML이고, 다른 하나는 클라이언트나 변환 서비스가 해석해 로컬 설정을 생성하는 노드 링크 모음입니다. 완전한 YAML은 정책 구조를 보존하기 쉽지만 특정 코어 확장을 사용할 수 있습니다. 노드 링크는 여러 소프트웨어 사이에서 전달하기 편하지만 모든 고급 필드를 표현하지는 못합니다. 가져오기에 성공했다는 것은 파일을 읽을 수 있다는 뜻일 뿐, 모든 노드가 원래 전송 매개변수를 그대로 보존했다는 의미는 아닙니다. 특히 VMess, VLESS, Hysteria2와 TUIC은 필드가 많아 변환 단계가 길수록 누락 가능성이 커집니다.

SS 노드 링크에는 일반적으로 암호화 알고리즘, 비밀번호, 서버와 포트가 포함되어 구조가 비교적 단순합니다. Trojan은 TLS 서버 이름, ALPN과 인증서 관련 옵션을 추가로 확인해야 합니다. VMess와 VLESS에는 네트워크 유형, Host, Path, service name, flow, 핑거프린트와 TLS 설정이 포함될 수 있습니다. Hysteria2는 인증, 서버 이름, 포트와 선택적 전송 매개변수를 사용하고, TUIC에는 UUID, 비밀번호, 혼잡 제어와 UDP 릴레이 설정이 자주 포함됩니다. 변환 후 노드 이름은 남아 있지만 연결되지 않는다면 구독을 반복해서 업데이트하지 말고 변환 전후의 핵심 필드를 나란히 비교해야 합니다.

Clash YAML의 세 계층

첫 번째 계층은 노드 정의로, proxies 안에서 각 연결의 유형과 매개변수를 지정합니다. 두 번째는 정책 그룹으로, proxy-groups가 노드를 조합하고 수동 선택이나 자동 탐색을 결정합니다. 세 번째는 규칙으로, rules가 도메인, IP 또는 기타 매칭 결과를 정책 그룹에 전달하는 방식을 정합니다. 세 계층은 서로 참조합니다. 규칙에는 정책 그룹 이름이 쓰이고, 정책 그룹은 노드나 다른 그룹을 참조하며, 노드에 서버 연결 정보가 들어갑니다. 이름을 바꿀 때는 모든 참조를 함께 수정해야 하며, 그렇지 않으면 정책 그룹이 노드를 찾지 못하거나 규칙이 존재하지 않는 대상을 가리키는 오류가 발생합니다.

proxies:
  - name: "HY2-example"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    skip-cert-verify: false

proxy-groups:
  - name: "수동 선택"
    type: select
    proxies:
      - "HY2-example"
      - DIRECT

rules:
  - MATCH,수동 선택

이 예시는 노드, 정책 그룹과 최종 규칙 사이의 참조 관계를 보여 줍니다. 서버와 비밀번호는 명확한 예시 값입니다. 실제 설정에서는 실제 제공 매개변수로 바꾸고 공백 들여쓰기를 동일하게 유지해야 합니다. YAML에서는 탭으로 계층 들여쓰기를 대신할 수 없습니다. 특수 문자가 포함된 이름은 따옴표로 감싸는 것이 좋습니다. 클라이언트에서 해석 오류가 표시되면 먼저 들여쓰기, 콜론 뒤 공백과 중복 키를 확인한 다음 프로토콜 필드를 점검하세요. 설정은 로드되지만 노드 핸드셰이크에 실패한다면 YAML 서식을 계속 수정하지 말고 서버 주소, 인증, TLS와 전송 매개변수를 확인해야 합니다.

구독 변환의 한계

구독 변환은 형식 정리, 노드 필터링, 이름 처리와 기본 정책 그룹 생성에 적합하지만 누락된 매개변수를 추측하는 용도로는 적합하지 않습니다. 변환기는 일반적인 SS 링크에서 VLESS의 UUID와 TLS 구조를 추론할 수 없으며, type만 바꿔 Hysteria2 노드를 TUIC으로 만들 수도 없습니다. 원본과 대상이 모두 Clash 설정 계열이라도 대상 템플릿이 원본 필드를 기준으로 하면 mihomo 확장 필드를 걸러낼 수 있습니다. 변환 후에는 비교용 원본 설정을 보관하고 노드 수, 프로토콜 유형, TLS 필드, 정책 그룹 참조와 규칙 마지막의 MATCH를 중점적으로 확인해야 합니다.

원격 규칙 제공자와 원격 구독은 업데이트 실패 후의 동작도 고려해야 합니다. 클라이언트는 보통 마지막으로 성공한 설정을 보관하지만 구체적인 캐시 정책은 구현에 따라 다릅니다. 업데이트 후 갑자기 많은 노드가 사라졌다면 먼저 설정 업데이트 시간과 다운로드 로그를 확인하고, 아직 작동하는 로컬 사본을 바로 덮어쓰지 마세요. 구독 주소는 민감한 설정이므로 공개 페이지나 로그 캡처에 게시해서는 안 됩니다. 문제를 확인할 때는 주소 매개변수를 가리고 오류 상태, 응답 유형과 클라이언트 메시지만 남기는 것이 좋습니다.

클라이언트, 운영체제와 프로토콜 기능의 조합

그래픽 클라이언트는 우선 시스템 통합을 해결

클라이언트를 선택할 때는 먼저 운영체제 지원, 코어 유형, 시스템 프록시와 TUN 통합을 확인한 다음 인터페이스 취향을 고려하세요. Clash Plus는 Windows, macOS, Android와 iOS를 지원해 여러 기기에서 비슷한 조작 방식을 유지하려는 사용자에게 적합한 본 사이트의 전 플랫폼 우선 선택지입니다. Clash Verge Rev는 Windows, macOS와 Linux 데스크톱 환경에 적합하며 mihomo 설정 관리, 시스템 프록시와 TUN에 자주 사용됩니다. FlClash는 데스크톱과 Android를 지원하는 크로스 플랫폼 대안입니다. Clash Nyanpasu는 Windows용이고, Clash Meta for Android와 Surfboard는 Android에서 사용할 수 있습니다. ClashX Meta와 Clash for Windows는 유지보수가 중단되었으므로 기존 환경을 처리하는 데 더 적합하며 신규 프로토콜 선택을 맡기기에는 적절하지 않습니다.

클라이언트가 특정 프로토콜을 지원한다는 것은 보통 포함된 코어가 해당 유형을 해석하고 연결을 수립할 수 있다는 뜻입니다. 하지만 그래픽 인터페이스가 모든 매개변수를 제공하는지도 확인해야 합니다. 예를 들어 노드를 수동으로 추가하는 화면은 일반 필드만 지원할 수 있지만 YAML을 가져오면 더 많은 고급 매개변수를 보존할 수 있습니다. 양식에 flow, sni, udp relay mode 또는 혼잡 제어 옵션이 없다면 의미가 비슷한 필드로 대체하지 말고 완전한 설정을 가져온 뒤 로그로 확인하세요. 플랫폼별 설치 패키지와 클라이언트 순서는 다운로드 페이지에서 확인할 수 있으며, 다운로드 관련 문제는 다운로드 페이지 FAQ를 참고하세요.

Windows: 시스템 프록시, TUN과 앱별 차이

Windows의 시스템 프록시는 시스템 설정을 따르는 앱에 주로 영향을 주며 일부 프로그램은 자체 네트워크 스택을 사용합니다. 더 넓은 범위에서 트래픽을 가로채야 한다면 TUN을 사용할 수 있지만 추가 권한과 가상 네트워크 인터페이스가 필요한 경우가 많습니다. 어떤 앱이 시스템 프록시를 따르는지는 프로토콜이 아니라 클라이언트 실행 모드가 결정합니다. 브라우저는 정상인데 스토어 앱에 문제가 있다면 앱 루프백 제한과 프록시 경로를 확인하고 Windows UWP 앱에서 Clash를 사용할 수 없을 때의 해결 절차를 참고하세요. TUN을 활성화한 뒤 로컬 네트워크 접근이 달라지면 SS나 VLESS를 먼저 바꾸지 말고 라우팅, DNS와 제외 항목을 확인해야 합니다.

macOS와 Linux: 권한, 시스템 서비스와 아키텍처

macOS의 시스템 프록시는 일반적인 데스크톱 앱에 적합하고, TUN 또는 강화 모드는 시스템 네트워크 확장과 권한 확인이 필요합니다. Apple Silicon과 Intel은 설치 패키지 아키텍처가 다르지만 설정 파일의 프로토콜 문법은 대체로 같습니다. Linux 데스크톱에서는 Clash Verge Rev나 FlClash를 사용할 수 있고, 서버와 라우터 환경에서는 mihomo 코어를 직접 실행해 설정 파일과 제어 인터페이스로 관리하는 편이 적합합니다. 서비스, 권한과 시작 스크립트를 직접 관리할 필요가 없는 일반 데스크톱 사용자는 그래픽 클라이언트를 선택하면 절차를 줄일 수 있습니다. 코어 패키지의 프로세서 아키텍처는 기기와 일치해야 하며 AMD64, ARM64, ARMv7과 MIPS는 서로 바꿔 사용할 수 없습니다.

Android와 iOS: 시스템 VPN 인터페이스 우선

Android와 iOS의 Clash 계열 클라이언트는 대체로 시스템 VPN 인터페이스를 통해 트래픽을 가로챕니다. 이때 “시스템 프록시 스위치”의 의미는 데스크톱과 다르며, 앱 적용 범위는 앱별 설정, 시스템 VPN 제한과 로컬 네트워크 권한의 영향도 받습니다. Android에서는 Clash Plus, Clash Meta for Android, FlClash와 Surfboard 중에서 선택할 수 있습니다. mihomo 확장 프로토콜이 필요하다면 실제 코어와 가져오기 결과를 확인해야 합니다. iOS에서는 Clash Plus가 주요 선택지입니다. 모바일에 규칙이 많은 데스크톱 설정을 가져오기 전에는 메모리와 업데이트 시간을 고려하고, 필요하면 더 간결한 규칙 집합을 사용하세요.

클라이언트를 바꾸기 전에 현재 설정을 내보내거나 백업하고 수동으로 수정한 DNS, TUN, 정책 그룹과 규칙을 기록해야 합니다. 이동 후에는 먼저 규칙 모드에서 기본 웹페이지, DNS와 단일 노드를 확인한 다음 복잡한 설정을 복원하세요. 클라이언트, 코어, 구독 템플릿과 프로토콜을 한 번에 모두 바꾸면 오류 원인을 찾기 어려워집니다. 더 안정적인 이동 방법은 한 번에 한 계층만 변경하는 것입니다. 먼저 설정을 그대로 둔 채 클라이언트만 바꾸고 실행을 확인한 뒤 코어 기능을 업그레이드하고 마지막으로 신규 프로토콜 노드를 가져오세요.

사용 상황에 따른 프로토콜과 코어 선택 결론

일상적인 데스크톱 사용: 성숙한 설정을 먼저 선택하고 프로토콜을 비교

Windows나 macOS에서 웹 탐색, 업무 앱과 일반적인 다운로드가 중심이라면 mihomo 클라이언트를 우선 선택하고 구독에서 필드가 완전하며 연결이 안정적인 프로토콜을 사용하세요. SS, Trojan, 설정이 올바른 VMess나 VLESS 모두 후보가 될 수 있습니다. 같은 서비스에서 여러 프로토콜을 제공한다면 동일한 회선에서 최초 접속, 몇 분간의 지속 전송과 절전 복귀를 먼저 테스트하세요. 차이가 뚜렷하지 않다면 필드가 적고 업데이트 후 오류가 적은 쪽을 선택합니다. 클라이언트는 Clash Plus를 우선 고려하고, 데스크톱 관리 요구에 따라 Clash Verge Rev나 FlClash를 선택할 수도 있습니다.

모바일 네트워크와 잦은 전환: 복구와 백그라운드 상태에 주목

휴대폰이 Wi-Fi와 모바일 네트워크 사이를 자주 오간다면 Hysteria2나 TUIC을 테스트 대상에 포함할 수 있습니다. QUIC 계열 연결은 네트워크 변화와 패킷 손실 상황에서 더 나은 복구 성능을 보일 수 있기 때문입니다. 단, 현재 네트워크가 UDP를 안정적으로 지원하고 클라이언트 코어가 설정을 완전하게 해석하며 서버 매개변수도 올바르다는 전제가 필요합니다. 화면을 잠근 뒤 연결이 끊기면 먼저 시스템 백그라운드 제한을 해결하세요. 유휴 상태 후 최초 접속이 느리다면 연결 유지와 DNS를 확인하고, 배터리 소모가 늘었다면 상태 확인과 후보 노드 수를 줄이세요. 곧바로 프로토콜을 사용할 수 없다고 판단해서는 안 됩니다.

고지연 또는 패킷 손실 회선: 처리량과 공정성을 함께 확인

왕복 시간이 길고 대역폭 변동이 큰 네트워크에서는 Hysteria2와 TUIC의 혼잡 제어가 일반 TCP 연결보다 처리량을 더 빠르게 회복할 수 있습니다. 그러나 테스트할 때는 단일 작업이 속도를 모두 사용하는지만 보지 말고 다른 앱에 뚜렷한 영향이 있는지, 라우터 CPU가 계속 상승하는지, 네트워크가 유휴 상태가 된 뒤 자주 재연결되는지도 관찰해야 합니다. 대역폭 매개변수는 지속 가능한 실제 성능에 가깝게 설정해야 하며 접속 회선의 이론상 상한으로 대신해서는 안 됩니다. UDP 경로가 불안정하다면 설정이 성숙한 Trojan, VLESS 또는 SS가 오히려 더 예측 가능할 수 있습니다.

오래된 기기, 라우터와 소형 서버: 변수 줄이기

리소스가 제한된 기기에서는 규칙 수, 로그 수준, DNS 복잡도와 동시 연결을 먼저 줄여야 합니다. 프로토콜은 구현이 성숙하고 매개변수가 적은 SS나 기존의 안정적인 TCP 방식부터 시작한 뒤 실제 필요에 따라 다른 유형을 테스트하세요. mihomo 코어를 실행할 때는 프로세서에 맞는 패키지를 다운로드하고 최소 설정으로 서비스가 시작되는지 확인한 다음 DNS, 규칙 제공자와 TUN을 단계적으로 추가해야 합니다. 데스크톱의 대규모 설정을 저메모리 기기에 그대로 복사하지 마세요. 인터페이스가 없더라도 규칙과 연결 상태에는 리소스 비용이 발생합니다.

기존 구독: 서버가 실제로 제공하는 유형을 기준으로 선택

프로토콜 이름을 좇기 위해 사용자가 노드를 직접 수정할 필요는 없습니다. 구독이 SS를 제공하면 SS 매개변수로 사용하고, VLESS를 제공하면 TLS와 전송 필드를 확인하며, Hysteria2나 TUIC을 제공하면 mihomo 지원과 UDP 환경을 확인하세요. 서버에 해당 프로토콜이 배포되어 있지 않다면 클라이언트에서 유형을 바꿔도 일치하는 핸드셰이크를 만들 수 없습니다. 같은 구독에 여러 프로토콜이 포함되어 있다면 수동 선택 그룹과 별도 테스트 그룹을 만들고, 이미 안정적인 노드를 기준선으로 남겨 다른 노드와 비교하세요.

문제가 발생하면 계층별로 점검

첫 번째 계층은 설정 로딩 여부입니다. YAML 해석 오류, 알 수 없는 유형이나 누락된 필드가 나타나면 형식 또는 코어 호환성 문제입니다. 두 번째는 노드 핸드셰이크입니다. 로그에 인증, TLS, timeout 또는 UDP 오류가 표시되면 노드 매개변수와 네트워크 조건을 확인하세요. 세 번째는 시스템 트래픽 가로채기입니다. 노드는 연결되지만 앱에 접속할 수 없다면 시스템 프록시, TUN, VPN 권한과 DNS를 확인합니다. 네 번째는 규칙입니다. 일부 도메인만 문제가 있으면 규칙 순서, 정책 그룹 선택과 MATCH의 대상 그룹을 확인하세요. 계층별로 점검하면 시스템 프록시 문제를 프로토콜 문제로 오해하거나 노드 매개변수가 잘못된 상태에서 규칙을 반복해서 수정하는 일을 피할 수 있습니다.

• 처음 사용을 빠르게 완료하려는 경우

  빠른 시작으로 이동해 구독 가져오기, 모드 선택, 시스템 프록시 활성화와 연결 확인 순서로 진행하세요.

• 설치 패키지를 선택해야 하는 경우

  다운로드 페이지에서 Windows, macOS, Android, iOS 또는 Linux에 맞는 클라이언트를 선택하세요.

• 코어를 비교해야 하는 경우

  현재 클라이언트에서 실제로 실행 중인 코어를 먼저 확인한 뒤 코어 호환성 비교를 참고해 이동하세요.

• 정책 그룹을 최적화해야 하는 경우

  url-test, fallback과 load-balance의 차이를 읽고 탐색 동작이 실제 목적에 맞지 않는 상황을 피하세요.

최종 선택의 기준은 “설정이 필요한 내용을 완전히 표현하고, 클라이언트가 안정적으로 해석하며, 현재 네트워크에서 반복 실행할 수 있는가”입니다. 프로토콜 이름은 설계 방향을 나타낼 뿐 환경과 무관한 고정 등급을 의미하지 않습니다. 대부분의 사용자에게는 한 번의 지연 시간 기록이나 잦은 프로토콜 변경보다 안정적인 mihomo 클라이언트, 명확한 구조의 구독, 적절한 규칙과 재현 가능한 테스트 절차가 더 중요합니다. 검증된 설정을 기준선으로 보관하고 한 번에 하나의 변수만 바꾸며 로그의 구체적인 오류를 기록해야 이후 업그레이드와 문제 해결을 통제할 수 있습니다.