Clash 프로토콜 상세 가이드
mihomo 코어와 호환성

연결 구조: 프로토콜, 전송 방식, 아웃바운드 경로

먼저 설정의 네 가지 계층을 구분하세요

클라이언트 화면에서는 프로토콜, 노드, 프록시 그룹이 나란히 표시되는 경우가 많지만 서로 다른 개념입니다. 프로토콜은 클라이언트와 서버가 인증하고 데이터를 주고받는 방식을 정합니다. 노드는 주소, 포트, 인증 정보와 전송 매개변수를 포함한 설정 인스턴스입니다. 프록시 그룹은 여러 아웃바운드 중 하나를 선택하고, 규칙은 연결을 어느 프록시 그룹으로 보낼지 결정합니다. 같은 프로토콜로 여러 노드를 만들 수 있고, 하나의 프록시 그룹에 서로 다른 프로토콜의 노드를 넣을 수도 있습니다. 따라서 노드를 바꾼 뒤 속도가 달라져도 프로토콜 차이 때문이라고 단정할 수 없습니다. 경로, 서버 부하, 대상 웹사이트도 영향을 줄 수 있습니다.

전송 계층도 따로 확인해야 합니다. 일부 프로토콜은 TCP 연결에서 직접 동작하고, 일부는 WebSocket이나 gRPC와 함께 사용할 수 있으며, QUIC 기반으로 동작하는 프로토콜도 있습니다. TLS는 인증과 암호화된 채널을 제공하며 여러 애플리케이션 계층 프로토콜과 조합할 수 있습니다. 화면에 VLESS가 표시된다고 연결에 TLS가 적용된 것은 아닙니다. WebSocket 역시 별도의 암호화 프로토콜을 뜻하지 않습니다. 설정을 확인할 때는 프로토콜 종류, 하위 전송 방식, 보안 계층, 서버 신원을 각각 살펴보세요. 이름만 보고 기능을 판단하지 않는 것이 중요합니다.

애플리케이션 트래픽은 어떻게 코어에 전달될까요?

시스템 프록시는 운영체제 설정을 통해 애플리케이션에 HTTP 또는 SOCKS 진입점을 사용하도록 안내합니다. 이를 따를지는 애플리케이션에 따라 다릅니다. TUN 모드는 가상 네트워크 인터페이스와 라우팅을 사용해 조건에 맞는 트래픽을 처리하므로 적용 범위가 더 넓은 편이지만, 권한과 라우팅, DNS 조정이 추가로 필요합니다. 진입 방식과 원격 프로토콜은 서로 독립적입니다. TUN을 켜도 SS 노드가 QUIC 노드로 바뀌지 않으며, 시스템 프록시를 꺼도 TUN이 이미 처리 중인 연결이 반드시 중단되는 것은 아닙니다. 문제를 해결할 때는 먼저 트래픽이 코어에 들어오는지 확인하고, 그다음 원격 핸드셰이크가 성공했는지 살펴보세요.

일반적인 접속은 도메인 해석, 규칙 매칭, 정책 선택, 서버 연결, 대상 사이트 접속 순서로 진행됩니다. DNS 모드, 도메인 규칙, 기존 해석 캐시에 따라 실제 순서는 달라질 수 있습니다. 예를 들어 IP 규칙은 도메인 해석을 유발할 수 있지만, no-resolve가 포함된 규칙은 해당 규칙에서 직접 도메인을 해석하지 않도록 제한합니다. 로그에 DIRECT가 표시된다면 노드 프로토콜이 아니라 규칙이나 모드가 원인일 수 있습니다. 핸드셰이크 실패가 표시될 때는 인증, 시간, 인증서, 전송 설정을 확인하세요.

지연 시간, 처리량, 가용성을 구분해 기록하세요

노드 지연 시간은 보통 클라이언트가 프록시를 통해 테스트 주소에 접속하는 데 걸린 시간입니다. 연결 설정, TLS 협상, 서버 전달, 웹사이트 응답 시간이 포함될 수 있습니다. 단순한 네트워크 왕복 시간도 아니며 대용량 파일 다운로드 속도를 나타내지도 않습니다. 처리량은 경로 대역폭, 혼잡 제어, 윈도 크기, 대상 서버의 속도 제한, 기기 성능에 따라 달라집니다. 가용성은 연결이 안정적으로 성공하는지를 의미합니다. 작은 요청에 빠르게 응답하는 노드도 장시간 다운로드에서는 제한될 수 있고, 첫 연결이 느린 노드도 연결을 재사용하면 안정적으로 작동할 수 있습니다.

프로토콜을 비교할 때는 서버 지역, 테스트 대상, 클라이언트 버전, 진입 방식을 동일하게 유지하고 최초 연결, 연속 탐색, 장시간 전송을 각각 테스트하는 것이 좋습니다. 조건을 맞출 수 없다면 결과는 프로토콜 자체가 아니라 현재 노드 구성의 성능으로 봐야 합니다. 로그의 시간 초과도 DNS 해석, 연결, 데이터 읽기 단계로 나눠 살펴보세요. DNS 시간 초과라면 먼저 DNS를 확인하고, 연결 시간 초과라면 경로와 포트를, 읽기 시간 초과라면 서버와 대상 사이트를 점검합니다. 이런 계층 구조를 먼저 이해해야 설정을 합리적으로 조정할 수 있습니다.

SS와 VMess: 경량 전송과 세션 인증

Shadowsocks의 설계 특징

Shadowsocks는 보통 SS라고 부르며, 비교적 간결한 프로토콜로 프록시 트래픽을 전달하도록 설계됐습니다. 일반적인 설정에는 서버, 포트, 비밀번호, 암호화 방식이 포함되며 HTTPS처럼 도메인 인증서를 반드시 설정할 필요는 없습니다. 여러 세대의 구현이 존재하므로 모든 SS 노드를 완전히 동일한 전송 규격으로 보면 안 됩니다. 기존 스트림 암호화, AEAD, Shadowsocks 2022는 키 처리, 메시지 형식, 구현 요구 사항이 서로 다릅니다. 선택할 때는 클라이언트에 SS 항목이 있는지만 확인하지 말고, 구체적인 암호화 방식이 지원되는지 먼저 살펴보세요.

AEAD는 암호화와 무결성 보호를 함께 제공하며, 키 길이와 키 파생 또는 인코딩 방식은 암호화 방식마다 다릅니다. Shadowsocks 2022 키는 정해진 형식을 따라야 하므로 일반 텍스트 비밀번호로 대체할 수 없습니다. 서버와 클라이언트의 암호화 방식이 일치해야 하며 인증 정보도 그대로 사용해야 합니다. 암호화 알고리즘의 실제 부하에는 프로세서의 명령어 지원 여부도 영향을 줍니다. 데스크톱에서 가볍게 작동하는 방식이 구형 모바일 기기나 라우터에서도 같은 장점을 보장하지는 않습니다. 알고리즘 이름만으로 기기 간 성능을 비교하지 마세요.

TCP, UDP, 플러그인은 서로 다른 설정입니다

SS는 TCP를 전달할 수 있고 UDP 중계 기능도 지원하지만, 실제로 사용하려면 클라이언트, 서버, 네트워크 경로가 모두 해당 기능을 지원해야 합니다. 클라이언트에서 UDP를 켜도 서버에 없는 기능이 추가되지는 않습니다. 일부 노드는 전송을 캡슐화하는 별도 플러그인에 의존합니다. 플러그인 이름, 모드, 매개변수도 설정의 일부입니다. 주소와 비밀번호만 복사하면 가져오기는 되더라도 연결에 실패할 수 있습니다. 출처가 분명한 구독이라면 원래 설정을 유지하고, 낯설다는 이유만으로 플러그인 필드를 삭제하지 마세요.

TCP 웹 탐색은 정상인데 게임이나 음성 통화에 문제가 있다면 먼저 해당 애플리케이션의 트래픽이 프록시로 들어오는지, 규칙이 해당 노드를 선택하는지 확인한 뒤 UDP 지원과 응답 경로를 살펴보세요. DNS 요청이 성공해도 모든 UDP 애플리케이션이 작동한다고 볼 수는 없습니다. DNS가 코어를 통해 다른 경로로 처리됐을 수 있기 때문입니다. 큰 패킷에서 문제가 생긴다면 경로 MTU와 단편화도 고려해야 합니다. 이 경우 암호화 방식만 바꾸는 것은 문제 해결에 도움이 되지 않을 수 있으며, 정상 작동하던 TCP 연결까지 영향을 받을 수 있습니다.

VMess의 배경과 인증 조건

VMess는 V2Ray 생태계에서 나온 프로토콜로, 인증과 데이터 보호를 담당하며 여러 전송 방식과 조합할 수 있습니다. 일반적인 노드는 UUID로 사용자를 식별하며, 과거 설정에는 이전 방식의 인증 관련 필드가 남아 있을 수 있습니다. 현재 구현은 주로 AEAD를 사용하지만, 구독과 코어에 따라 과거 필드를 처리하는 방식이 완전히 같지는 않습니다. 예전 클라이언트에서 설정을 받아들였다고 해서 모든 최신 코어가 같은 방식으로 해석한다고 볼 수 없습니다. 이전할 때는 먼저 대상 코어에 맞는 설정을 확보한 다음 과거 호환 옵션을 처리하세요.

VMess 인증은 시간 유효성에 영향을 받으므로 시스템 시간이 크게 어긋나면 인증 실패처럼 보일 수 있습니다. 먼저 시스템 시간 동기화를 켜고 UUID와 서버 설정을 확인하세요. 노드에서 WebSocket을 사용한다면 경로와 Host도 살펴보고, TLS를 사용한다면 SNI와 인증서를 추가로 확인해야 합니다. UUID가 맞는 것은 필요한 조건 중 하나일 뿐입니다. 모든 실패를 인증 정보 오류로만 보면 하위 전송이 연결되지 않은 상황을 놓치기 쉽고, 구독을 반복해서 다시 가져와도 문제가 해결되지 않을 수 있습니다.

경로 조건이 확인된 환경에서 SS는 간결한 설정과 성숙한 구현을 우선하는 사용자에게 적합합니다. VMess는 관련 서버와 전송 설정을 이미 갖춘 환경에 알맞습니다. 이는 관리 비용의 차이지 품질의 우열을 뜻하지 않습니다. 현재 노드가 안정적으로 작동한다면 프로토콜이 오래됐다는 이유만으로 교체할 필요는 없습니다. 최신 전송 기능이 필요하더라도 클라이언트의 프로토콜 목록만 바꾸지 말고, 먼저 서버에서 해당 기능을 제공하는지 확인하세요.

Trojan과 VLESS: 인증과 보안 계층의 조합

Trojan은 TLS에 보안 처리를 맡깁니다

Trojan은 TLS 채널을 기반으로 하며, 채널 안에서 프록시 인증과 데이터 교환을 처리합니다. 프로토콜 자체가 암호화 기능을 모두 맡는 방식과 달리, 성숙한 TLS 구현과 인증서 체계에 의존합니다. 클라이언트에는 보통 주소, 포트, 비밀번호, 서버 이름을 설정합니다. 설정 항목은 적어 보여도 도메인 해석, 인증서 유효성, 서버 배포 구성이 서로 일치해야 합니다. 포트에 연결됐다고 TLS 신원 확인까지 성공한 것은 아니며, TLS에 성공해도 비밀번호 인증까지 통과한 것은 아닙니다.

접속 주소와 SNI는 서로 다를 수 있습니다. 접속 주소는 서버를 찾는 데 사용하고, SNI는 TLS 핸드셰이크에서 접속하려는 서비스 이름을 전달합니다. 인증서도 예상한 신원과 일치해야 합니다. 서버에서 여러 사이트를 운영한다면 SNI가 잘못됐을 때 다른 인증서나 서비스로 연결될 수 있습니다. 도메인을 IP 주소로 바꾼 뒤 인증서 오류가 발생해도 검증을 바로 끄지 마세요. 원래 설정에 별도의 서버 이름이 필요한지, 그 이름이 서버 인증서와 일치하는지 확인해야 합니다.

VLESS가 가벼운 이유는 기능을 분리했기 때문입니다

VLESS 역시 V2Ray 관련 생태계에서 나온 프로토콜입니다. VMess 프로토콜 계층의 자체 암호화 부담을 줄이고 사용자 식별과 외부 보안 전송을 분리하도록 설계됐습니다. UUID는 주로 인증에 사용하며 암호화 키로 보면 안 됩니다. 적절한 보안 계층을 설정하지 않은 VLESS 연결은 프로토콜 이름만으로 통신 내용이 보호된다고 판단할 수 없습니다. 실제 사용 시 TLS, REALITY 또는 다른 배포 요구 사항을 확인해야 하며, 해당 기능은 클라이언트 코어와 서버가 모두 지원해야 합니다.

REALITY는 별도 지원이 필요한 보안 핸드셰이크 방식으로, 일반 TLS의 다른 이름이 아닙니다. 공개 키, 짧은 식별자, 서버 이름 등의 매개변수에는 각각 정해진 의미가 있으므로 일반 인증서 설정을 임의로 조합해서는 안 됩니다. VLESS의 flow도 범용 가속 옵션이 아니며 지정된 전송 방식과 서버 설정이 맞을 때만 사용할 수 있습니다. 클라이언트가 관련 필드를 인식하지 못해 삭제 후 가져오기에 성공했더라도 설정의 의미가 유지된다는 보장은 없습니다. 대상 코어의 지원 여부를 확인하고 호환되는 설정을 다시 받는 편이 안전합니다.

WebSocket, gRPC, 연결 재사용의 비용

WebSocket은 HTTP 업그레이드 이후의 연결을 통해 양방향 데이터를 전달합니다. 경로, 요청 헤더, 서버 진입점이 서로 일치해야 합니다. gRPC는 보통 HTTP/2를 사용하며 서비스 이름, 연결 협상, 리버스 프록시 설정이 결과에 영향을 줍니다. 이러한 캡슐화 방식은 기존 배포 환경에 맞출 수 있지만 프로토콜 계층과 문제 진단 단계가 늘어납니다. 기본 TCP, WebSocket, gRPC 사이에 배포 환경과 무관한 속도 순위는 없습니다. 중간 프록시, 연결 재사용, 서버 리소스 설정이 전송 방식 자체보다 사용 경험에 더 큰 영향을 주는 경우도 많습니다.

연결을 재사용하면 연결을 반복해서 만드는 비용을 줄일 수 있지만, 여러 요청이 같은 연결을 공유하면 혼잡이나 하위 연결 오류의 영향을 함께 받을 수도 있습니다. 모든 서버가 동일한 재사용 방식을 지원하는 것은 아니며, 짧은 연결이 많은 작업에서 항상 이득이 되는 것도 아닙니다. 문제를 확인할 때는 서버가 허용하는 범위에서 연결 재사용 설정을 비교하고, 새 연결에 걸리는 시간과 지속 전송, 오류 복구를 살펴보세요. 한 번 측정한 노드 지연 시간만으로 판단하지 마세요. 연결 재사용, 전송 방식, DNS를 한꺼번에 바꾸면 어떤 설정이 개선을 가져왔는지 알기 어렵습니다.

Trojan은 TLS가 올바르게 구성되어 있고 인증 경로를 명확하게 유지하려는 환경에 적합합니다. VLESS는 인증과 보안 전송을 유연하게 조합하는 데 중점을 두지만, 사용자가 더 많은 조합 조건을 확인해야 합니다. 클라이언트에서 입력 방식이 비슷해 보여도 비밀번호와 UUID를 서로 바꿔 쓸 수 없으며, 유형 필드만 수정해 변환할 수도 없습니다. 선택하기 전에 원본 구독을 보관하고 연결 세부 정보에서 실제 아웃바운드 유형을 확인하세요. 지원 범위는 코어 기능 및 설정 호환성 참고에서 확인할 수 있습니다.

Hysteria2와 TUIC: QUIC과 UDP 경로

QUIC은 전송 방식을 바꾸지만 물리 경로를 바꾸지는 않습니다

QUIC은 UDP를 기반으로 사용자 공간에서 신뢰성 있는 전송, 혼잡 제어, 보안 핸드셰이크를 구현합니다. 한 데이터 흐름의 패킷 손실이 다른 흐름의 전송을 기다리게 하는 현상을 줄일 수 있지만, 패킷 손실의 영향이 사라지는 것은 아니며 경로 대역폭을 넘어설 수도 없습니다. 모든 흐름은 연결의 혼잡 상태와 실제 네트워크 자원을 공유합니다. QUIC을 단순히 더 빠른 UDP로 이해하면 안 됩니다. UDP는 하위 전송 수단일 뿐이며 신뢰성, 확인 응답, 흐름 제어는 여전히 프로토콜 구현이 담당합니다.

Hysteria2와 TUIC은 모두 QUIC을 활용하지만 서로 다른 프로토콜이며 인증 필드, 전달 방식, 매개변수의 의미도 다릅니다. 서버가 둘 중 하나만 제공한다면 클라이언트에서 유형만 바꿔 다른 프로토콜로 전환할 수 없습니다. 서버까지 UDP 통신이 가능해야 하며 통신사 네트워크, 기업 게이트웨이, 라우터, 서버 방화벽 중 어느 한 곳에서 UDP를 제한해도 연결이 실패할 수 있습니다. 브라우저에서 일반 HTTPS 사이트가 열리는 것은 TCP 경로가 대체로 작동한다는 뜻일 뿐, QUIC 노드의 UDP 경로가 작동한다는 뜻은 아닙니다.

Hysteria2의 대역폭 설정은 실제 환경에 맞추세요

Hysteria2는 복잡한 네트워크 경로를 고려한 QUIC 기반 프록시 전송을 제공하며, 예상 대역폭과 관련된 혼잡 제어 방식을 지원합니다. 모드에 따라 대역폭 필드의 역할이 다를 수 있고 서버 정책의 제한도 받습니다. 업로드와 다운로드 수치를 크게 입력한다고 대역폭이 늘어나는 것은 아닙니다. 기대치를 지나치게 높이면 대기열과 패킷 손실이 늘고 다른 애플리케이션의 지연 시간까지 높아질 수 있습니다. 현재 네트워크와 서버 제한에 맞춰 보수적으로 설정하고, 장시간 전송 중 상호작용 요청의 품질도 함께 살펴보세요.

업로드 용량은 특히 놓치기 쉽습니다. 가정용 인터넷이나 모바일 네트워크의 업로드 속도는 다운로드보다 크게 낮을 수 있으며, 확인 응답과 애플리케이션 업로드, 다른 기기까지 같은 자원을 공유합니다. 다운로드 중에만 통화가 끊긴다면 다운로드 대역폭 수치를 올리기보다 먼저 대기열이 쌓이는지 확인하세요. Hysteria와 Hysteria2는 이름만 다른 동일 프로토콜이 아니므로 가져오기 전에 서버에서 어느 버전을 제공하는지 확인해야 합니다. 인증 정보, 난독화 설정, TLS 매개변수도 함께 유지하고 비밀번호 필드만 옮기지 마세요.

TUIC의 세션, 인증서, 구현 호환성

TUIC도 QUIC으로 프록시 연결을 전달하며, 구현에 따라 신뢰성 있는 데이터 스트림과 데이터그램을 조합해 다양한 트래픽을 처리할 수 있습니다. 설정할 때는 구현이 지원하는 프로토콜 세대, UUID와 비밀번호 등의 인증 매개변수, 인증서, 서버 이름을 확인해야 합니다. 일부 구현에는 0-RTT, 혼잡 제어, UDP 전달 모드 옵션이 있지만, 이 옵션들은 따로 켜도 되는 기능 묶음이 아닙니다. 서버에서 지원하는 기능과 일치해야 합니다. 구독 변환 도구가 관련 매개변수를 누락하면 노드가 목록에 표시되더라도 정상적으로 트래픽을 전달하지 못할 수 있습니다.

0-RTT는 조건을 충족하는 재연결의 비용을 줄일 수 있지만, 이전 세션 상태가 필요하며 재전송 공격과 관련된 제약도 있습니다. 최초 연결에서 모든 대기 시간이 사라지는 것은 아닙니다. 모바일 기기에서 네트워크를 바꾼 뒤 연결이 자연스럽게 복구되는지는 연결 마이그레이션 구현, 주소 변경, NAT 상태, 클라이언트의 수명 주기 관리에 따라 달라집니다. QUIC 프로토콜에 관련 기능이 있다고 해서 모든 클라이언트가 Wi-Fi와 모바일 네트워크 전환 중에도 연결을 유지하는 것은 아닙니다. 프로토콜 설명만으로 사용 경험을 추측하지 말고 실제 애플리케이션으로 복구 여부를 확인하세요.

두 프로토콜은 UDP 경로가 안정적이고 서버 설정이 맞는 환경에서 후보로 고려할 수 있습니다. 불확실한 게스트 네트워크를 자주 이용한다면 같은 QUIC 설정을 반복해서 바꾸기보다 TCP 기반 노드를 별도의 예비 연결로 유지하세요. 예비 노드는 서로 다른 경로 조건에 대비하기 위한 것이지, 특정 프로토콜이 언제나 더 낫다는 뜻은 아닙니다.

성능과 배터리: 측정 방법과 리소스 선택

연결 속도는 여러 지표로 나눠 살펴보세요

최초 연결 시간에는 DNS, 서버 핸드셰이크, 프로토콜 인증, 대상 사이트 연결이 포함됩니다. 기존 연결을 재사용하면 그중 일부를 생략할 수 있습니다. 웹페이지 로딩에는 여러 도메인과 동시 요청도 영향을 주므로 테스트 주소 하나의 결과가 페이지 전체 성능을 대변하지는 않습니다. 비교할 때는 첫 응답 시간, 페이지 로딩 완료 시간, 지속 다운로드, 오류 횟수를 함께 기록하세요. 어느 단계가 느린지 알아야 노드를 바꿀지, DNS를 조정할지, 핸드셰이크와 연결 재사용을 확인할지 판단할 수 있습니다. 지연 시간 숫자 하나만 낮추려 해서는 안 됩니다.

처리량을 테스트할 때는 테스트 서버의 속도 제한을 노드 문제로 오해하지 않도록 주의하세요. 신뢰할 수 있는 동일한 테스트 대상을 사용하고 비슷한 시간대에 여러 번 비교하며, 테스트 중에는 다른 대용량 작업을 중지하는 것이 좋습니다. 서버 위치와 출구 경로가 다른 설정 두 개는 실제 사용 환경에 맞는 선택에는 활용할 수 있지만, 프로토콜의 우열을 증명하는 자료는 아닙니다. 지속 다운로드는 데이터를 소모하고 기기 온도를 높이므로 모바일 네트워크에서는 특히 테스트 시간을 제한하세요. 속도 하나만 저장하기보다 네트워크 유형, 진입 모드, 기기 상태를 함께 기록해야 비교에 도움이 됩니다.

CPU, 메모리, TUN 부하

암호화와 복호화, 캡슐화, 패킷 처리, 규칙 매칭은 모두 프로세서 자원을 사용합니다. 대역폭이 높을 때는 사용자 공간에서 동작하는 QUIC이 계산과 패킷 처리 작업을 늘릴 수 있습니다. 반대로 하드웨어 가속을 지원하는 암호화 방식은 특정 기기에서 더 효율적일 수 있습니다. 이는 어디까지나 조건에 따른 차이입니다. TCP 기반 프로토콜이 항상 전력을 아낀다고 할 수도 없고 QUIC이 반드시 메모리를 더 많이 사용한다고 볼 수도 없습니다. 연결 수, 버퍼, 코어 구현, 애플리케이션의 요청 방식도 영향을 주므로 실제 기기에서 확인해야 합니다.

TUN은 가상 네트워크 인터페이스와 프로토콜 스택 처리를 추가하며, DNS 가로채기, 트래픽 스니핑, 다수의 연결 기록도 추가 부하를 일으킬 수 있습니다. 시스템 프록시만으로 일상적인 애플리케이션을 처리할 수 있다면 먼저 시스템 프록시를 기준으로 측정한 뒤 TUN을 켜서 적용 범위와 리소스 변화를 비교하세요. TUN이 필요하다면 약간의 부하를 줄이려고 필요한 기능을 포기하지 말고, 불필요한 디버그 로그, 지나치게 잦은 자동 속도 측정, 중복 DNS 조회가 켜져 있는지 확인하세요. 메모리 사용량이 높은 이유가 캐시 축적일 수도 있으므로 안정적인 사용량과 지속적인 증가를 구분해야 합니다.

모바일 배터리 소모에는 깨어나는 빈도가 큰 영향을 줍니다

휴대폰 배터리는 암호화 연산뿐 아니라 무선 모듈의 활성 상태 유지, 백그라운드 깨우기, 신호 세기, 재연결에도 영향을 받습니다. 연결 유지 신호를 너무 자주 보내면 기기를 더 자주 깨우고, 너무 드물게 보내면 NAT 매핑이 만료되어 다음 요청에서 연결을 다시 만들어야 할 수 있습니다. 모든 모바일 네트워크에 통하는 최적 값은 없습니다. 화면을 잠근 뒤 연결이 자주 끊긴다면 먼저 클라이언트의 백그라운드 권한과 시스템 절전 제한을 확인한 다음 연결 유지 설정을 살펴보세요. 주기를 지나치게 짧게 하면 겉으로는 연결이 개선되어도 대기 중 배터리 소모가 크게 늘 수 있습니다.

배터리 소모를 비교할 때는 화면 밝기, 네트워크 유형, 백그라운드 애플리케이션, 작업량을 비슷하게 맞추고 적극적으로 사용할 때와 화면을 잠근 대기 상태를 나눠 관찰하세요. 짧은 시간의 배터리 백분율 변화는 배터리 잔량 추정 오차의 영향을 받으므로 미세한 순위를 정하는 데 적합하지 않습니다. 시스템 배터리 통계, 백그라운드 활동 시간, 기기 온도, 연결 로그를 함께 확인하면 도움이 됩니다. 연결할 수 없는 노드에 클라이언트가 계속 재접속을 시도하면 실제 전송량이 적어도 배터리가 소모될 수 있습니다. 이때는 암호화 방식을 바꾸기보다 연결 가능 여부와 재시도 정책을 바로잡는 것이 효과적입니다.

반복해서 사용할 수 있는 검증 절차는 다음과 같습니다. 고정된 네트워크에서 노드가 작동하는지 확인하고, 웹 탐색과 다운로드, 음성 통화나 게임 같은 실제 작업을 연속해서 수행합니다. 그다음 화면 잠금 후 복구와 네트워크 전환을 관찰하고 마지막으로 배터리와 오류를 기록합니다. 매번 프로토콜 또는 관련 매개변수 하나만 바꾸고 반복해서 비교하세요. 지연 시간이 낮더라도 기기 온도가 높아지고 재연결이 잦다면 실제 작업에 맞춰 판단해야 합니다. 테스트 숫자가 더 낮은 설정이 반드시 최선은 아닙니다. 모드에 따른 차이는 규칙·전역·직접 연결 모드 안내에서 확인할 수 있습니다.

코어 계열: 원본 Clash, Meta, mihomo

클라이언트 화면과 프록시 코어를 구분해 살펴보세요

그래픽 클라이언트는 구독 관리, 시스템 프록시, 서비스 설치, 사용자 인터페이스, 플랫폼 연동을 담당합니다. 코어는 설정을 해석하고 규칙을 매칭하며 아웃바운드 연결을 실행합니다. 화면이 비슷해도 기능이 같다는 뜻은 아니며, 같은 클라이언트도 코어를 바꾸면 동작이 달라질 수 있습니다. VLESS나 Hysteria2 지원 여부를 물을 때는 클라이언트 이름과 코어 정보를 함께 확인해야 합니다. 앱 이름에 Clash가 포함되어 있다는 이유만으로 프로토콜, TUN, 규칙 필드가 지원된다고 판단하거나 설정을 그대로 옮길 수 있다고 보장할 수는 없습니다.

원본 Clash는 규칙 기반 프록시, 프록시 그룹, YAML 설정의 기본 사용 방식을 확립했습니다. Clash Premium은 일반 오픈소스 버전과 다른 확장 기능을 제공한 적이 있지만, 이를 모든 원본 빌드의 공통 기능 목록으로 보면 안 됩니다. Clash.Meta는 관련 생태계를 바탕으로 프로토콜과 설정 기능을 확장했으며, 이후 mihomo라는 이름으로 프로젝트가 이어졌습니다. Meta와 mihomo는 각각 설치해야 하는 별개의 서비스라기보다 프로젝트의 연속성에 가까운 관계입니다. 오래된 안내에서는 여전히 Meta라는 명칭을 사용할 수 있으므로 실제 코어 기능을 기준으로 판단하세요.

공통 문법이 있다고 완전한 하위 호환을 보장하지는 않습니다

프록시, 프록시 그룹, 규칙 같은 기본 구조는 비교적 잘 이어지지만 새 프로토콜, DNS 옵션, 규칙 유형, TUN 필드는 구형 코어에서 지원하지 않을 수 있습니다. 구형 설정을 새 코어로 옮길 때도 변화가 없다고 단정할 수 없습니다. 필드의 기본값, 이전 옵션 처리 방식, 플랫폼 구현이 다를 수 있습니다. 설정을 파싱하는 데 성공했다는 것은 설정을 받아들였다는 뜻일 뿐 이전과 같은 경로로 연결된다는 의미는 아닙니다. 마이그레이션 후에는 구독 노드, 프록시 그룹 선택, 도메인 라우팅, 로컬 네트워크 접속, DNS 동작을 최소한 확인하세요. 실행에 성공했다는 이유만으로 작업을 끝내지 마세요.

운영체제에 따라서도 기능 범위가 달라집니다. TUN 권한, 시스템 서비스, 가상 네트워크 인터페이스, 라우팅 구현은 플랫폼마다 다릅니다. 데스크톱에서 작동한 설정을 휴대폰에 그대로 적용할 수 있다고 보장할 수 없습니다. 일부 그래픽 클라이언트는 코어 설정을 생성하거나 덮어씁니다. 실행 파일을 직접 수정해도 구독을 새로 고치거나 클라이언트를 다시 시작하면 기본 설정으로 돌아갈 수 있습니다. 수정하기 전에 클라이언트가 설정 오버라이드, 병합 스크립트, 원본 파일 편집 중 어떤 방식을 제공하는지 확인하세요. 장기적으로 유지할 사용자 설정은 적절한 계층에 두어야 하며, 인터페이스의 동작을 코어 미지원 문제로 오해하지 않아야 합니다.

교체하기 전에 확인부터 하세요

독립 실행형 mihomo에서는 아래 명령으로 지정한 디렉터리의 설정을 확인할 수 있습니다. 디렉터리에는 사용할 config.yaml 파일과 관련 로컬 종속 항목이 있어야 하며, 명령의 경로는 실제 설치 위치에 맞춰 조정하세요. 설정 검사가 실제 연결 테스트를 대신하지는 않지만 형식, 참조, 필드 문제를 미리 찾는 데 도움이 됩니다. 그래픽 클라이언트에서 설정 검사를 제공한다면 해당 기능을 우선 사용하세요. 실행 디렉터리, 병합 과정, 권한을 클라이언트가 관리할 수 있으므로 다른 디렉터리에서 명령을 실행해도 실제 환경을 재현하지 못할 수 있습니다.

mihomo -t -d ./profile

클라이언트는 Clash Plus부터 비교해 볼 수 있으며, 플랫폼별 다운로드 링크는 다운로드 센터에서 확인하세요. Windows에서는 Clash Verge Rev, FlClash, Clash Nyanpasu도 비교할 수 있습니다. macOS에서는 Clash Verge Rev와 FlClash를, Linux에서는 Clash Verge Rev와 FlClash를 살펴보세요. Clash for Windows와 ClashX Meta는 유지 관리가 중단됐으므로 기존 환경을 파악할 때는 참고할 수 있지만 익숙한 화면이라는 이유만으로 유지 관리 상태를 무시해서는 안 됩니다. 최종 선택은 사용하는 클라이언트의 실제 코어, 플랫폼 지원, 기존 설정을 기준으로 해야 합니다. 추천 순서가 프로토콜 기능을 증명하는 것은 아닙니다.

구독 호환성: 형식, 필드, 설정 덮어쓰기

구독 주소가 하나의 통일된 파일 형식을 뜻하지는 않습니다

구독은 주소를 통해 데이터를 가져오는 방식입니다. 응답 내용은 전체 YAML, 프록시 프로바이더 데이터, 공유 링크 모음, 인코딩된 텍스트일 수 있습니다. 주소가 모두 HTTPS로 시작하더라도 가져오는 방법이 같다는 뜻일 뿐, 클라이언트가 같은 형식으로 읽을 수 있다는 뜻은 아닙니다. 일부 서비스는 요청 매개변수나 클라이언트 식별 정보에 따라 서로 다른 내용을 반환합니다. 같은 주소를 여러 앱에 복사해도 결과가 다를 수 있습니다. 가져오기에 실패했다면 노드 프로토콜이 호환되지 않는다고 단정하거나 인증 정보를 반복해서 바꾸기 전에 응답 형식부터 확인하세요.

전체 설정에는 일반적으로 프록시, 프록시 그룹, 규칙이 포함되며 DNS, 수신 포트, 제어 인터페이스 설정이 들어갈 수도 있습니다. 프록시 프로바이더는 보통 노드 목록만 제공하므로 메인 설정에서 이를 참조해야 합니다. 공유 링크는 주로 개별 연결을 설명하며 규칙이나 전체 DNS 정책은 포함하지 않는 경우가 많습니다. 노드 목록을 전체 설정으로 가져오면 라우팅 구조가 빠질 수 있고, 전체 설정을 노드 목록만 받는 메뉴에서 가져오면 파싱에 실패할 수 있습니다. 먼저 클라이언트에서 구독 가져오기, 설정 가져오기, 프로바이더 관리 메뉴를 구분한 다음 해당 형식에 맞는 메뉴를 선택하세요.

변환은 필드를 재배치할 수 있지만 없는 기능을 만들어 내지는 못합니다

구독 변환 도구는 공유 링크를 해석해 YAML을 만들거나 규칙 템플릿을 적용할 수 있습니다. 하지만 구형 코어가 지원하지 않는 프로토콜을 이해하게 만들거나 누락된 정보에서 인증서, flow, QUIC 매개변수를 정확히 복원할 수는 없습니다. 변환기가 일부 확장 필드를 인식하지 못하면 오류가 나거나 해당 필드를 조용히 버릴 수 있습니다. 후자는 노드가 가져온 것처럼 보여서 알아차리기 더 어렵습니다. 새 프로토콜은 서비스 제공자가 대상 코어용 형식을 직접 제공하는지 먼저 확인하고 변환 전후의 매개변수를 비교하세요. 노드 개수만 표시된다는 이유로 변환이 완전하다고 판단하지 마세요.

구독 주소에는 보통 접근 인증 정보가 포함되어 있으며 전체 설정에도 노드 비밀번호와 UUID가 들어갈 수 있습니다. 문제를 확인할 때는 필요한 필드만 로컬에서 살펴보고 로그나 스크린샷을 공유하기 전에 민감한 정보를 가리세요. 전체 구독을 출처가 불분명한 타사 서비스에 제출하지 마세요. 변환이 필요하다면 원본 주소와 내용이 원격 서버로 전송되는지 먼저 확인해야 합니다. 클라이언트가 읽을 수 있는 설정 자체도 기능 범위를 결정합니다. 규칙 프로바이더, 외부 리소스, 제어 인터페이스는 네트워크 동작을 바꿀 수 있으므로 출처와 용도를 이해할 수 있는 설정만 가져오세요.

로컬 오버라이드와 원격 업데이트를 분리하세요

구독을 새로 고친 뒤 로컬 수정 사항이 사라지는 것은 보통 저장 실패가 아니라 원격 콘텐츠가 같은 계층의 파일을 덮어쓴 결과입니다. 장기간 유지해야 할 규칙, DNS 설정, 포트 변경은 클라이언트가 지원하는 병합 또는 오버라이드 방식으로 관리하세요. 특히 병합 순서가 중요합니다. 이름이 같은 프록시 그룹은 기존 구성원을 대체할 수 있으며, MATCH 뒤에 추가한 규칙은 매칭되지 않을 수 있습니다. 해당 필드를 통째로 교체하는지, 목록에 추가하는지, 이름을 기준으로 병합하는지 먼저 확인한 다음 수정 위치를 정하세요. 이름의 공백과 대소문자도 그대로 유지해야 존재하지 않는 대상을 참조하는 일을 막을 수 있습니다.

아래 예시는 Proxy 프록시 그룹이 이미 정의된 설정에서 규칙 구조를 설명합니다. 로컬 네트워크 대상은 직접 연결하고 지정 도메인은 프록시 그룹으로 보내며, 나머지는 마지막 규칙으로 처리합니다. 완전한 노드 구독 설정이 아니므로 단독으로 가져와 연결 설정으로 사용해서는 안 됩니다. no-resolve는 해당 IP 규칙의 도메인 해석 방식만 제한하며 DNS를 전역으로 끄지 않습니다. 실제 라우팅은 기존 규칙 순서와 함께 확인해야 하며 서비스 제공자의 규칙 목록 전체를 기계적으로 덮어쓰지 마세요.

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,github.com,Proxy
  - MATCH,Proxy

관리 과정에서 작동하는 설정을 백업해 두세요. 업데이트 후에는 먼저 파싱 결과를 확인하고 대표 노드와 자주 사용하는 규칙을 테스트합니다. 일부 새 프로토콜 노드만 실패한다면 필드와 코어를 우선 확인하고, 모든 노드가 실패한다면 구독 응답, 시스템 시간, 로컬 진입점을 먼저 살펴보세요. 연결은 정상이지만 라우팅이 달라졌다면 규칙과 오버라이드 순서를 확인해야 합니다. 자세한 매칭 방법은 GEOIP 및 DOMAIN-SUFFIX 라우팅 활용법에서 볼 수 있습니다. 문제를 올바른 계층에서 찾아야 프로토콜 교체로 규칙 문제를 해결하려는 일을 피할 수 있습니다.

사용 환경별 선택: 프로토콜 후보와 검증 절차

일상적인 웹 탐색과 데스크톱 업무

일상적인 웹 탐색에서는 최신 프로토콜 이름보다 연결 안정성, 구독 관리의 명확성, 규칙 제어를 우선하세요. 안정적으로 작동하는 SS, VMess, Trojan 노드가 있다면 이를 기준 설정으로 삼을 수 있습니다. VLESS, Hysteria2, TUIC이 필요하다면 코어와 서버 조합을 먼저 확인하세요. 업무 네트워크에 명확한 프록시 이용 규칙이 있다면 이를 준수하고, 시스템 프록시나 라우팅, DNS를 두고 충돌하는 클라이언트를 여러 개 실행하지 마세요. 클라이언트는 Clash Plus부터 살펴본 다음 플랫폼에 맞춰 다른 선택지를 비교할 수 있습니다.

브라우저는 정상인데 데스크톱 앱이 작동하지 않는다고 바로 프로토콜을 바꾸지 마세요. 먼저 앱이 시스템 프록시를 따르는지, 별도의 프록시 설정이 있는지, 연결이 클라이언트 로그에 표시되는지 확인해야 합니다. 트래픽 전체를 처리해야 할 때 TUN을 검토하세요. 로컬 네트워크 프린터, 파일 공유, 개발 서버에는 적절한 직접 연결 경로가 필요합니다. 프록시 자체가 작동해도 이 경로가 없으면 업무에 지장이 생길 수 있습니다. 자세한 원리는 TUN 가상 네트워크 인터페이스의 트래픽 처리 안내에서 확인하고 실제 설정 방법은 사용 가이드를 참고하세요.

모바일 네트워크, 실시간 통신, 장시간 다운로드

모바일에서는 네트워크 전환, 화면 잠금 후 복구, 대기 중 활동을 먼저 테스트하세요. Android에서는 Clash Plus를 시작점으로 삼고 Clash Meta for Android, FlClash, Surfboard의 실제 형식과 기능 지원을 비교할 수 있습니다. iOS에서는 Clash Plus의 앱 스토어 링크와 공식 웹사이트 clashplus.io를 확인하세요. 이 클라이언트들이 같은 코어와 구독 형식을 지원한다고 가정해서는 안 됩니다. 링크 하나를 가져올 수 있다고 해서 모든 프로토콜 확장 기능과 규칙 동작까지 동일한 것은 아닙니다.

음성 통화와 게임은 지터, 패킷 손실, UDP 사용 가능 여부가 중요하므로 HTTP 지연 시간 한 번으로 판단하기 어렵습니다. 먼저 애플리케이션이 올바른 아웃바운드 경로를 사용하는지 확인한 다음 실제 세션에서 끊김, 복구, 지연 변화를 살펴보세요. Hysteria2나 TUIC도 후보가 될 수 있지만 현재 네트워크에서 UDP가 제한된다면 조건에 맞는 다른 방식을 사용해야 합니다. 대용량 다운로드에서는 지속 처리량과 기기 온도, 다른 작업이 대기열에 영향을 받는지 확인하세요. 접속 대역폭에 도달한 뒤 예상 대역폭을 더 높여도 이득이 없으며, 동시 상호작용 품질이 오히려 낮아질 수 있습니다.

라우터, 서버, 리소스가 제한된 기기

라우터와 서버에서는 상시 안정성, 반복 가능한 설정 배포, 장애 복구가 중요합니다. 독립 mihomo 코어는 프로세스와 설정을 직접 관리하려는 사용자에게 적합하며, 일반적인 데스크톱 사용자는 그래픽 클라이언트가 관리하기 편한 경우가 많습니다. 프로세서 아키텍처, 사용 가능한 메모리, 시스템 권한, TUN 지원을 각각 확인해야 합니다. 데스크톱에서 측정한 처리량을 저전력 기기에 그대로 적용할 수는 없습니다. 규칙 세트의 크기, 연결 수, 로그 기록도 리소스에 영향을 주므로 간단한 설정으로 기준을 잡은 뒤 기능을 단계적으로 추가하세요.

기기 전체에 적용되는 프록시는 여러 단말에 영향을 주므로 변경 전에 되돌릴 방법을 준비하세요. 기존 설정과 검증된 노드를 보관하고 적은 트래픽으로 먼저 테스트한 다음 적용 범위를 넓히세요. 라우터, 클라이언트, 다른 서비스가 DNS를 동시에 처리한다면 각자의 역할을 분명히 정해 순환 조회를 방지해야 합니다. 서버 출구에 방화벽 제한이 있다면 인증서 검증 수준을 낮추려 하지 말고 TCP와 UDP를 각각 확인하세요. 프로토콜 연결 실패와 라우팅·권한 문제는 원인이 다르므로 해결 방법도 달라야 합니다.

마지막으로 정해진 순서에 따라 결정하세요. 먼저 코어나 서버가 지원하지 않는 조합을 제외하고, 다음으로 현재 네트워크에서 사용할 수 없는 전송 방식을 제외합니다. 그런 다음 실제 작업으로 지연 시간, 처리량, 온도, 복구 성능을 비교하고 마지막으로 다른 전송 경로를 사용하는 예비 노드를 유지하세요. 프로토콜, DNS, TUN, 라우팅 규칙을 동시에 바꾸지 마세요. 설정을 바꿀 때마다 자주 사용하는 웹사이트, 로컬 네트워크, 실시간 애플리케이션을 확인하고 문제가 생기면 검증된 이전 설정으로 되돌리세요. 프로토콜 선택은 한 번 정하는 순위표가 아니라, 분명한 조건 아래에서 설명하고 유지 관리할 수 있는 연결 방식을 만드는 과정입니다.