Clash 프로토콜 및 코어기술 가이드

01 / DECISION MODEL

프로토콜 선택을 네 가지 질문으로 나누기

프로토콜 이름이 실제 사용감을 결정하지는 않습니다

Clash 클라이언트에서 SS, VMess, Trojan, VLESS, Hysteria2, TUIC를 보면 보통 어느 쪽이 더 최신이고 빠른지부터 비교하게 됩니다. 하지만 이런 순서는 판단을 흐리기 쉽습니다. 프로토콜은 세션 수립, 데이터 캡슐화, 인증, 전송 처리를 정할 뿐입니다. 실제 사용감은 서버 출구, 사용자와 서버 사이의 경로, 노드 부하, 혼잡 제어, 클라이언트 코어, 접속 대상의 경로에도 영향을 받습니다. 경로가 짧고 부하가 낮으며 설정이 적절한 기존 프로토콜 노드가, 설정이 부실한 최신 프로토콜 노드보다 안정적일 수 있습니다. 프로토콜은 여러 변수 중 하나일 뿐, 결과를 단독으로 결정하는 라벨이 아닙니다.

더 신뢰할 수 있는 판단법은 네 가지 질문으로 나누는 것입니다. 첫째, 하위 전송이 TCP인지 UDP인지, 현재 네트워크의 패킷 손실과 지터에 적합한지 확인합니다. 둘째, 클라이언트 코어가 해당 프로토콜과 추가 파라미터를 모두 인식하는지 봅니다. 셋째, 기기를 장시간 백그라운드에서 실행해야 하는지, CPU 깨우기와 지속적인 송수신, 연결 마이그레이션 비용을 감당할 수 있는지 판단합니다. 넷째, 구독 제공자가 호환되는 서버 구현과 파라미터를 제공하는지 확인합니다. 네 가지 중 하나라도 충족되지 않으면 문서상의 장점은 실제 연결로 이어지지 않습니다.

전송 계층이 문제의 양상을 결정합니다

SS, VMess, Trojan, VLESS의 일반적인 배포는 대부분 TCP를 기반으로 하며 TLS, WebSocket, gRPC 또는 다른 전송 방식을 조합하기도 합니다. TCP는 신뢰성 있는 전송, 순서 보장, 혼잡 제어를 제공하므로 웹, 다운로드, 코드 저장소 등 대부분의 서비스에 적합합니다. 다만 내부 애플리케이션도 TCP를 사용할 때 패킷 손실이 발생하면 여러 계층에서 재전송이 일어나고 헤드 오브 라인 블로킹이 생길 수 있습니다. 그렇다고 단순히 “TCP 위에 TCP라서 반드시 느리다”고 단정할 수는 없습니다. 실제 프록시 구현은 대개 바이트 스트림을 전달하며, 두 개의 완전한 TCP 상태 머신을 기계적으로 중첩하는 것은 아니기 때문입니다. 그래도 지연이 크고 패킷 손실이 많은 환경에서는 복구 속도가 제한될 수 있습니다.

Hysteria2와 TUIC는 UDP를 사용하며 QUIC 또는 유사한 방식으로 신뢰성 있는 스트림, 다중화, 암호화를 제공합니다. 고지연 환경이나 간헐적인 패킷 손실이 있고 TCP 혼잡 제어의 복구가 느린 경로에서 주로 강점을 보입니다. 반대로 UDP를 제한하는 네트워크도 있고, 라우터의 UDP 세션 유지 시간이 짧을 수도 있으며, 모바일 네트워크 전환 후 연결을 원활하게 마이그레이션할 수 있는지는 구현에 따라 달라집니다. “UDP 프로토콜이 더 빠르다”는 말은 “UDP가 허용되고 경로 특성이 맞을 때 처리량을 유지할 가능성이 높다”로 이해해야 합니다.

노드, 프로토콜, 전송 방식, 코어는 서로 다른 네 계층입니다

노드는 연결 가능한 서버 인스턴스이고, 프로토콜은 인증과 데이터 캡슐화를 정의합니다. 전송 계층 또는 전송 방식은 데이터가 TCP, UDP, TLS, WebSocket 중 어떤 경로를 지나는지 결정하며, 코어는 구독 필드를 실제 연결로 변환합니다. 클라이언트 화면은 이 계층들을 하나의 노드 이름으로 압축해 보여 주기 때문에 “특정 노드가 연결되지 않는다”는 문제를 “프로토콜 전체가 작동하지 않는다”로 오해하기 쉽습니다. 문제를 확인할 때는 먼저 같은 프로토콜의 다른 노드로 바꾸고, 다음으로 같은 노드 그룹의 다른 프로토콜을 시도한 뒤, 마지막으로 클라이언트 코어와 구독 필드를 확인하세요. 한 번에 변수 하나만 바꿔야 결과가 의미를 가집니다.

예를 들어 VLESS 노드에는 TLS, 흐름 제어, 서버 이름, 전송 유형이 함께 포함될 수 있습니다. 이 중 하나를 삭제하면 프로토콜 이름은 여전히 VLESS로 표시되지만 핸드셰이크 동작은 달라집니다. Hysteria2의 인증, 서버 이름, 포트 점프 범위, 대역폭 안내도 구체적인 구현 파라미터에 해당합니다. 노드 이름에 있는 “고속”, “전용선” 같은 문구만 봐서는 기술적인 판단을 할 수 없습니다. 설정을 열어 실제 필드를 확인하거나 클라이언트의 노드 상세 정보에서 프로토콜 유형을 확인해야 합니다.

테스트 대상과 시간대를 고정하세요

프로토콜을 비교할 때는 최소한 노드 지역, 테스트 대상, 클라이언트 모드, 시간대를 고정해야 합니다. 먼저 클라이언트의 지연 테스트로 연결 가능성을 확인한 다음 실제 웹페이지, 지속 다운로드, 동영상 탐색, 네트워크 전환으로 사용감을 살펴보세요. 지연 수치는 대개 테스트 URL까지 한 번 핸드셰이크한 경로를 측정하므로 대역폭을 의미하지 않습니다. 자세한 원리는 《Clash 지연 테스트 수치의 의미》에서 확인할 수 있습니다. 같은 노드를 3~5회 연속 측정하고 변동 범위를 기록하는 편이 한 번의 최저값에 집중하는 것보다 효과적입니다.

최종 선택을 하나의 프로토콜로 고정할 필요도 없습니다. 구독에 일상용 안정 노드와 패킷 손실이 많은 환경을 위한 예비 노드 그룹을 함께 보관한 뒤 url-test 또는 수동 선택 그룹으로 관리할 수 있습니다. 규칙은 트래픽이 어느 그룹으로 갈지 결정하고, 프로토콜은 해당 그룹의 노드가 어떻게 전송할지 결정합니다. 둘의 역할은 다릅니다. 이 관계를 이해하면 프로토콜 선택은 편 가르기가 아니라 검증 가능한 엔지니어링 문제가 됩니다.

02 / TCP FAMILY

SS, VMess, Trojan, VLESS의 설계와 선택 기준

Shadowsocks: 단순한 구조와 성숙한 배포 환경

Shadowsocks는 보통 SS로 줄여 부릅니다. 사전 공유 키로 암호화 프록시를 구성하는 것이 핵심이며, 프로토콜 구조가 비교적 간결하고 서버와 클라이언트 구현이 다양해 리소스 요구량도 관리하기 쉽습니다. 일반적인 웹 이용, 다운로드, 장시간 백그라운드 연결에서 SS의 장점은 과장된 최고 속도가 아니라 구성 요소가 적고 파라미터 범위가 좁으며 배포 경험이 풍부하다는 점입니다. 노드 정보에는 보통 서버, 포트, 비밀번호, 암호화 방식이 포함됩니다. 최신 배포에서는 클라이언트와 서버가 함께 지원하는 AEAD 계열 암호화 방식을 사용해야 하며, 구식 스트림 암호 설정을 새로운 배포의 기준으로 삼아서는 안 됩니다.

SS가 단순하다고 해서 모든 전송 문제를 해결하는 것은 아닙니다. 플러그인 추가 여부, UDP 사용 여부, 서버의 UDP 포워딩 활성화 여부는 배포 방식에 따라 달라집니다. 같은 SS라도 구독에 포함된 두 노드가 암호화 방식, 플러그인, 서버 구현에 따라 크게 다른 성능을 보일 수 있습니다. Clash로 가져온 뒤 TCP 웹 접속은 정상인데 음성 통화나 게임에 문제가 있다면 먼저 노드의 UDP 지원과 클라이언트 TUN 설정을 확인하세요. 곧바로 DNS를 바꿀 문제는 아닙니다.

VMess: 기능은 풍부하지만 필드 조합이 많습니다

VMess는 V2Ray 생태계에서 널리 사용되는 프로토콜로, 사용자 식별자와 인증, 시간 관련 검증을 포함하며 TCP, WebSocket, HTTP/2 방식의 전송 또는 TLS와 조합되는 경우가 많습니다. 여러 전송 방식을 하나의 설정 체계에 담았다는 점에 역사적 의미가 있어 많은 구독 서비스가 여전히 VMess 노드를 제공합니다. 대신 파라미터가 많습니다. 사용자 ID, alterId, 암호화 필드, 전송 유형, 경로, Host, TLS, 서버 이름 중 하나라도 맞지 않으면 핸드셰이크가 실패할 수 있습니다.

오래된 튜토리얼에서는 일부 과거 필드를 필수 항목처럼 설명하지만, 최신 서버는 다른 기본값을 사용할 수 있습니다. VMess를 처리할 때 가장 안전한 방법은 파라미터를 직접 추측하지 말고 서버가 생성한 전체 구독을 사용하는 것입니다. 변환 과정에서 network, ws-opts, servername 같은 필드가 누락되지 않았는지도 확인하세요. 한 클라이언트에서는 작동하지만 Clash YAML로 변환한 뒤 실패한다면 프로토콜 자체보다 변환기의 필드 매핑을 먼저 의심해야 합니다.

Trojan: TLS 세션 기반의 간결한 인증

Trojan은 보통 TLS 위에서 실행되며 비밀번호로 클라이언트를 인증합니다. 성숙한 TLS 스택으로 전송을 보호하므로 인증서 도메인, 서버 이름, 포트, 비밀번호가 핵심 설정입니다. 사용자 정의 전송 필드가 많은 구성보다 표준 Trojan 노드는 이해하기 쉽지만, “TLS를 사용한다”는 이유로 인증서 검증을 무시해서는 안 됩니다. 클라이언트 설정의 sni 또는 servername은 서버 인증서와 배포 환경에 맞아야 하며, 시스템 시간이 크게 틀려도 핸드셰이크가 실패할 수 있습니다.

일부 구독은 인증서 검증 건너뛰기를 설정합니다. 이 옵션은 인증서 체인 문제를 진단할 때는 유용하지만 장기적인 기본값으로 적합하지 않습니다. 이 옵션을 켜야 연결된다면 인증서 이름, 서버 인증서 체인, 시스템 시간을 확인해 근본 원인을 해결하세요. Trojan은 gRPC 또는 WebSocket과 조합되기도 하며, 이 경우 경로와 서비스 이름 같은 필드가 추가됩니다. “Trojan”을 하나의 고정된 캡슐화 형태로 이해해서는 안 됩니다.

VLESS: 가벼운 인증 프레임워크, 성능은 조합에서 결정

VLESS는 가벼운 프로토콜 계층을 사용하고 암호화와 전송 보안을 TLS 같은 외부 계층에 더 많이 맡깁니다. VLESS 자체가 켜기만 하면 자동으로 빨라지는 기능은 아닙니다. 실제 성능과 보안은 TLS, Reality 계열 보안 계층, 흐름 제어, 구체적인 전송 방식의 조합에서 나옵니다. Clash 사용자는 조합 이름을 외우기보다 현재 mihomo가 구독에 포함된 모든 필드를 지원하는지 확인해야 하며, YAML을 직접 줄일 때 flow, reality-opts, client-fingerprint, 서버 이름을 삭제하지 않도록 주의해야 합니다.

VLESS 설정에서 흔히 발생하는 문제는 “프로토콜 이름은 인식했지만 추가 기능은 인식하지 못하는” 경우입니다. 일부 오래된 코어는 기본 VLESS는 읽어도 최신 보안 계층이나 지문 필드를 처리하지 못할 수 있습니다. 화면에는 노드가 표시되지만 클릭한 뒤 오류가 발생하기도 합니다. 따라서 호환성 판단은 가져오기 성공에서 끝나서는 안 되며, 최소한 연결, DNS 요청, 실제 HTTPS 접속까지 확인해야 합니다. 지속적으로 관리되는 mihomo 코어를 사용하는 편이 오래된 Clash 설정 문법에서 필드를 계속 삭제하는 것보다 대체로 간단합니다.

네 가지 중 절대적인 승자는 없습니다

패킷 손실이 적고 라우팅이 안정적인 유선 또는 Wi-Fi 환경에서는 이 네 가지 TCP 기반 방식이 비슷한 웹 사용감을 제공할 수 있습니다. 차이는 초기 핸드셰이크, 연결 재사용, 서버 부하, 복잡한 필드의 오류 허용성에서 더 자주 나타납니다. SS는 설정 범위가 작아 장애 지점이 적고, VMess는 기존 노드가 많지만 변환할 때 전체 필드를 보존해야 합니다. Trojan은 인증서 체인이 핵심이며, VLESS는 조합 능력이 강한 대신 최신 코어에 더 의존합니다.

구독에 네 종류의 노드가 모두 있다면 먼저 노드 경로를 기준으로 같은 지역끼리 묶은 뒤 안정성을 비교하세요. 부하가 높은 SS 노드와 부하가 낮은 VLESS 노드를 비교해 프로토콜의 결론을 내리면 안 됩니다. 이름이 더 최신이라는 이유로 안정적인 노드를 삭제할 필요도 없습니다. 클라이언트는 Windows 사용자의 경우 다운로드 페이지에서 우선 추천하는 Clash Plus를 먼저 사용하거나 Clash Verge Rev, FlClash, Clash Nyanpasu를 선택할 수 있습니다. 다만 그래픽 클라이언트의 실제 기능은 통합된 코어와 설정 업데이트 상태에 따라 달라집니다.

03 / UDP TRANSPORT

Hysteria2와 TUIC: 패킷 손실이 많은 경로에서의 선택

두 프로토콜이 UDP에 집중하는 이유

기존 TCP는 안정적인 네트워크에서 훌륭하게 작동하지만 왕복 시간이 길고 무작위 패킷 손실이 있으며 대역폭이 빠르게 변하는 환경에서는 혼잡 윈도 복구가 보수적으로 진행될 수 있습니다. Hysteria2와 TUIC는 모두 UDP 위에 암호화, 신뢰성 있는 전송, 다중화를 구축해 애플리케이션 스트림이 단일 TCP 바이트 스트림의 헤드 오브 라인 블로킹에 완전히 묶이지 않도록 합니다. 신뢰성을 버리는 것이 아니라 QUIC 또는 프로토콜 자체의 세션 계층에서 신뢰성 있는 전송을 처리하는 방식입니다.

이런 설계는 “사용 가능한 대역폭은 남아 있지만 패킷 손실 때문에 TCP 속도가 계속 떨어지는” 상황에 특히 적합합니다. 여러 웹 요청, 동영상 조각, DNS 조회를 하나의 연결 안에서 독립적인 스트림으로 나눌 수 있어 한 스트림의 손실 복구가 다른 스트림 전체를 막지 않습니다. 연결 수립에 필요한 추가 왕복도 줄어들 수 있습니다. 다만 하위 UDP가 로컬 네트워크, 라우터, 통신망, 서버 방화벽을 안정적으로 통과해야 합니다. 어느 한 단계라도 UDP를 제한하거나 세션 유지 시간을 줄이면 장점이 잦은 재연결로 바뀔 수 있습니다.

Hysteria2: 처리량 중심이지만 대역폭 파라미터는 측정 결과가 아닙니다

Hysteria2는 고처리량 경로에서 혼잡 제어와 신뢰성 있는 전송을 구현하는 데 중점을 둡니다. 설정에는 업로드 및 다운로드 대역폭 안내가 포함될 수 있지만, 이는 혼잡 제어가 경로의 용량을 파악하도록 돕는 값일 뿐 클라이언트가 해당 속도를 보장한다는 뜻은 아닙니다. 실제 경로보다 훨씬 높은 값을 입력하면 과도한 전송, 큐 적체, 지터가 발생할 수 있고, 너무 낮게 입력하면 처리량이 제한됩니다. 구독에 이미 파라미터가 있다면 먼저 서버 권장값을 유지하세요. 지속적인 테스트에서 큐 적체나 속도 제한이 확인될 때만 조정하는 것이 좋습니다.

Hysteria2에는 인증 문자열, TLS 서버 이름, 인증서 검증, 선택적 포트 점프도 관련됩니다. 포트 점프는 서버, 방화벽, 클라이언트가 함께 설정해야 하며 클라이언트에 포트 범위만 입력한다고 자동으로 작동하지 않습니다. 연결 문제를 확인할 때는 먼저 단일 포트로 고정해 기본 연결을 확인한 뒤 추가 기능을 다시 활성화하세요. 모바일 네트워크에서 단일 포트는 작동하지만 포트 점프가 불안정하다면 라우터와 네트워크가 UDP 매핑을 처리하는 방식을 확인해야 합니다.

TUIC: QUIC 세션, 동시 스트림, 연결 마이그레이션

TUIC 역시 UDP와 QUIC 방식을 기반으로 하며, 일반적인 설정에는 사용자 식별자, 비밀번호, 서버 이름, 혼잡 제어 알고리즘, UDP 릴레이 모드, 연결 유지 파라미터가 포함됩니다. 동시 연결을 처리하는 데 적합하고 QUIC의 스트림 및 세션 관리 기능을 활용할 수 있습니다. 휴대폰에서는 연결 마이그레이션이 중요한 기능입니다. Wi-Fi에서 셀룰러 네트워크로 전환할 때 클라이언트, 코어, 서버 구현이 잘 맞으면 여러 TCP 연결을 새로 만드는 것보다 기존 세션을 빠르게 복구할 가능성이 있습니다.

하지만 연결 마이그레이션이 모든 상황에서 자동으로 성공하는 것은 아닙니다. 기기 절전, 시스템의 백그라운드 네트워크 권한 회수, NAT 매핑 변경, VPN 인터페이스 재생성으로 기존 세션이 무효화될 수 있습니다. 실제 테스트에는 화면 잠금 후 복구, Wi-Fi와 셀룰러 전환, 신호가 약한 구역에서의 짧은 단절을 포함해야 하며 데스크톱에서 다운로드를 한 번 연속 실행하는 것만으로는 부족합니다. TUIC의 혼잡 제어 옵션도 다른 사람의 설정을 그대로 복사해서는 안 됩니다. 서버 지원, 경로 특성, 구현 버전이 서로 맞아야 합니다.

UDP가 통하지 않으면 증상이 TCP보다 명확하게 나타납니다

대표적인 증상은 노드 지연 테스트 시간 초과, 연결 직후 끊김, 잠시 작동한 뒤 속도 저하, 네트워크 전환 후 장시간 복구되지 않는 현상입니다. 먼저 같은 네트워크에서 다른 UDP 애플리케이션이 정상인지 확인한 다음 라우터 방화벽, 서버 포트, 클라이언트 TUN, 구독 필드를 점검하세요. 다른 Wi-Fi로 바꾸자마자 정상화된다면 로컬 네트워크 경로의 문제일 가능성이 높습니다. 모든 네트워크에서 실패한다면 서버의 리스닝 상태, 인증서 이름, 인증 필드로 돌아가야 합니다.

“프로토콜 연결이 UDP를 사용한다”는 것과 “프록시가 UDP 애플리케이션 트래픽을 전달한다”는 것은 구분해야 합니다. Hysteria2와 TUIC의 하위 세션 자체는 UDP에 의존하지만, 클라이언트가 게임, 음성 통화, QUIC 웹사이트 트래픽을 제대로 가로채는지는 TUN 모드, 시스템 VPN 인터페이스, 규칙, UDP 포워딩 기능에도 영향을 받습니다. 웹페이지가 열린다는 것은 일부 TCP 애플리케이션 트래픽이 통과했다는 뜻일 뿐, UDP 애플리케이션 경로가 완전히 작동한다는 증거는 아닙니다.

선택 순서: 도달 가능성을 먼저 확인하고 지속 부하를 테스트하세요

실제 선택은 세 차례로 나눌 수 있습니다. 첫 번째는 연결 수립, DNS, 일반 HTTPS를 테스트합니다. 두 번째는 몇 분간 지속 전송하며 처리량이 갑자기 0이 되는지, 재연결이 잦은지 관찰합니다. 세 번째는 화면 잠금, 네트워크 전환, 약한 신호, 여러 앱 동시 실행 등 실제 기기 동작을 재현합니다. Hysteria2는 패킷 손실이 많은 장거리 경로에서 처리량 우위를 보이는 경우가 많고 TUIC는 다중 스트림과 세션 관리 측면에서 매력적이지만, 어느 쪽이 우수한지는 서버 구현과 로컬 네트워크를 빼고 판단할 수 없습니다.

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

proxy-groups:
  - name: UDP-Fallback
    type: select
    proxies:
      - HY2-Example
      - DIRECT

위 조각은 mihomo에서 자주 사용하는 필드 구조만 보여 주며, 도메인과 인증 값은 명확한 예시입니다. 실제 설정은 서버가 제공해야 합니다. 현재 구독에 Hysteria2 또는 TUIC 노드가 없다면 type만 바꿔 강제로 변환해서는 안 됩니다. 프로토콜은 서버와 클라이언트가 쌍으로 지원해야 하며 노드 유형을 바꾼다고 서버가 다른 프로토콜로 변하는 것은 아닙니다.

04 / PERFORMANCE

연결 속도, 처리량, 리소스 사용량은 따로 측정해야 합니다

“빠르다”에는 최소 네 가지 지표가 있습니다

클라이언트의 지연 수치는 첫 번째 지표일 뿐입니다. 전체 성능을 판단하려면 연결 수립 시간, 첫 바이트까지의 시간, 지속 처리량, 지터를 최소한 함께 봐야 합니다. 연결 수립 시간은 DNS, TCP 또는 QUIC 핸드셰이크, TLS, 프로토콜 인증의 영향을 받습니다. 첫 바이트 시간에는 대상 사이트의 처리 시간도 더해집니다. 지속 처리량은 혼잡 제어, 패킷 손실, 서버 출구, CPU에 좌우되고, 지터는 음성 통화, 게임, 실시간 상호작용의 부드러움을 결정합니다. 지연은 낮지만 처리량이 나쁜 노드도 있고, 초기 로딩은 조금 느리지만 지속 다운로드가 안정적인 노드도 있습니다.

다중화도 많을수록 좋은 것은 아닙니다. 반복적인 핸드셰이크를 줄이고 여러 논리 연결이 하위 세션을 공유하게 할 수 있지만, 모든 스트림이 하나의 불안정한 연결에 몰리면 하위 세션의 혼잡이나 리셋이 더 넓은 범위에 영향을 줍니다. 웹 브라우징에서는 다중화가 많은 단기 연결 비용을 줄이는 경우가 많지만, 장시간 대용량 전송에서는 단일 세션이 병목이 되는지 확인해야 합니다. 프로토콜 구현, 클라이언트 코어, 서버 파라미터를 함께 평가해야 합니다.

핸드셰이크 비용과 연결 재사용

SS의 기본 핸드셰이크는 비교적 간결해 표준 설정에서 CPU와 왕복 비용을 예측하기 쉽습니다. Trojan은 TLS에 의존하므로 첫 연결에서 TLS 절차를 완료해야 하지만 이후 연결 재사용 여부가 실제 비용에 큰 영향을 줍니다. VMess와 VLESS의 성능은 외부 전송 방식에 따라 달라지며 WebSocket, TLS, gRPC 조합마다 핸드셰이크와 캡슐화 비용이 추가됩니다. Hysteria2와 TUIC는 UDP 기반 세션과 다중 스트림 기능을 활용해 짧은 동시 연결을 반복해서 수립하는 비용을 줄일 수 있지만, 최초 인증서 검증과 QUIC 세션에도 비용이 있습니다.

따라서 프로토콜 헤더 크기만으로 실제 속도를 순위 매길 수는 없습니다. 웹 접속은 수십 개의 동시 리소스로 구성되는 경우가 많아 연결 풀과 재사용 전략의 영향이 단일 패킷에 추가되는 몇 바이트보다 클 수 있습니다. 반대로 성능이 낮은 라우터에서는 높은 동시성, 사용자 공간 네트워크 스택, 복잡한 규칙 매칭이 CPU를 점유합니다. 이론상 처리량이 네트워크 카드 한계에 도달하기도 전에 프로세서가 먼저 과부하될 수 있습니다.

CPU, 메모리, 규칙 규모

리소스 사용량은 주로 암호화, 데이터 복사, 네트워크 스택, DNS 캐시, 규칙 집합, 연결 상태에서 발생합니다. 프로토콜 차이가 암호화와 세션 처리에 영향을 주지만 설정 규모도 중요합니다. 여러 대형 규칙 집합을 불러오거나 TUN, 트래픽 스니핑, 많은 연결 기록을 활성화하면 기본 시스템 프록시만 사용하는 설정보다 메모리 사용량이 높아질 수 있습니다. “특정 프로토콜이 메모리를 더 많이 사용한다”고 판단하기 전에 규칙 집합, DNS, 로그 수준, 실행 모드를 동일하게 유지해야 합니다.

데스크톱에서는 여러 프로토콜의 리소스 차이가 서버 경로 차이만큼 뚜렷하지 않은 경우가 많지만, 저전력 라우터와 오래된 휴대폰에서는 차이가 커질 수 있습니다. Hysteria2와 TUIC의 사용자 공간 신뢰성 전송, 타이머, 지속적인 UDP 세션은 CPU 깨우기를 늘릴 수 있고, 복잡한 VLESS 조합도 추가 TLS와 전송 처리를 요구할 수 있습니다. SS의 단순한 구조는 리소스가 제한된 기기에 적합한 경우가 많지만, 서비스 품질이 요구 사항을 충족해야 합니다.

속도 테스트 순서가 결론의 신뢰도를 좌우합니다

첫 단계는 변수를 비우는 것입니다. 클라이언트, 코어, DNS 모드, 규칙, 대상을 고정하고 노드만 바꾸세요. 두 번째로 도달 가능성을 테스트해 핸드셰이크 실패와 변동이 지나치게 큰 노드를 제외합니다. 세 번째로 비슷한 지역과 경로 안에서 프로토콜을 비교합니다. 네 번째로 일상적인 시간대에 테스트를 반복해 네트워크가 한산할 때만 결론을 내리지 않도록 합니다. 마지막으로 기기 온도, CPU, 배터리를 확인하세요. 프로토콜 테스트는 여러 차례 진행해야 하며, 지연 시간을 한 번 측정한 뒤 최저 숫자를 고르는 방식으로 끝내서는 안 됩니다.

다운로드 테스트에서도 여러 스레드, 시스템 업데이트, 클라우드 드라이브 동기화를 동시에 실행하지 않도록 해야 합니다. 브라우저가 HTTP/3를 사용하면 대상 트래픽 자체가 UDP로 전송될 수 있습니다. 클라이언트가 UDP를 완전히 가로채지 못하면 일반 HTTPS와 결과가 달라집니다. 프록시 프로토콜을 비교하려면 TCP를 명확히 사용하는 테스트 대상과 실제 동영상 또는 실시간 애플리케이션 환경을 함께 준비하세요. 도구의 출력은 일부 정보일 뿐이고 실제 작업이 최종 판단 기준입니다.

로그는 문제를 특정할 만큼만 활성화하세요

연결 문제를 확인할 때는 로그 수준을 일시적으로 debug로 높여 DNS, 규칙 매칭, 프록시 핸드셰이크, 대상 연결 중 어디에서 실패했는지 확인할 수 있습니다. 높은 로그 수준을 장시간 유지하면 디스크 쓰기, 화면 갱신, CPU 깨우기가 늘어나며 특히 휴대폰과 라우터에 적합하지 않습니다. 문제를 해결한 뒤에는 info 또는 클라이언트 권장 수준으로 되돌리세요. 로그에 인증서 이름, 인증 실패, UDP 시간 초과가 나타나면 해당 계층에 맞게 처리해야 하며 모든 설정을 한꺼번에 초기화해서는 안 됩니다.

log-level: info
mode: rule

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

unified-delay: true
tcp-concurrent: true

unified-delay는 지연 테스트 기준을 통일된 연결 과정에 가깝게 맞추는 데 사용하고, tcp-concurrent는 확인된 주소에 동시에 연결을 시도해 일부 연결 대기 시간을 줄일 수 있습니다. 이 옵션들은 프로토콜 가속기가 아니며 서버 장애를 해결하지도 않습니다. 설정 항목이 실제로 작동하는지는 mihomo 코어의 지원 여부에 달려 있습니다. 오래된 원본 코어에서는 알 수 없는 필드가 무시되거나 로딩 오류를 일으킬 수 있습니다.

05 / MOBILE POWER

모바일 배터리, 백그라운드, 네트워크 전환 성능

배터리 소모는 암호화뿐 아니라 지속적인 깨우기에서 발생합니다

휴대폰의 프록시 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 가로챕니다. 데이터는 가상 인터페이스로 들어간 뒤 코어가 규칙을 매칭하고 도메인을 조회하며 프록시 연결을 수립한 다음 시스템 네트워크 스택으로 다시 전달합니다. 배터리 소모는 암호화 연산, 데이터 복사, 규칙 검색, DNS, 연결 유지, 로그, 화면 갱신, 무선 모뎀 깨우기 등 여러 곳에서 발생합니다. 프로토콜의 암호화 알고리즘만으로 배터리 지속 시간을 정확히 예측할 수 없습니다. 짧은 간격의 지속적인 소량 패킷은 한 번의 대용량 전송보다 기기가 저전력 상태에 진입하지 못하게 만들기 쉽습니다.

Wi-Fi에서 얻은 결론을 셀룰러 네트워크에 그대로 적용해서는 안 됩니다. 셀룰러 모뎀이 절전 상태에서 활성 상태로 복귀할 때 추가 비용이 발생하며, 잦은 연결 유지는 고전력 상태가 이어지는 시간을 늘립니다. Hysteria2와 TUIC는 UDP 세션을 유지하기 위해 주기적인 활동을 사용할 수 있고, TCP 프로토콜도 하트비트, 연결 풀, 앱의 백그라운드 요청 때문에 활성 상태를 유지할 수 있습니다. 실제로 측정해야 할 것은 프로토콜 이름이 아니라 “고정된 앱 부하에서 기기 전체가 사용하는 전력”입니다.

시스템 백그라운드 정책은 데스크톱보다 엄격합니다

Android 제조사는 백그라운드 프로세스, 배터리 최적화, 자동 시작 권한을 추가로 제한하는 경우가 많습니다. 시스템이 클라이언트를 일시 중지하면 VPN 아이콘이 잠시 남아 있어도 코어가 새 연결을 제때 처리하지 못할 수 있습니다. 화면을 잠근 뒤 접속할 수 없고 잠금 해제 후 복구된다면 클라이언트의 배터리 정책, 백그라운드 실행 권한, 절전 모드를 확인하세요. Clash Plus, Clash Meta for Android, FlClash, Surfboard는 화면 경로가 다르지만 모두 시스템 VPN과 백그라운드 정책의 영향을 받습니다.

iOS의 네트워크 확장은 시스템이 관리합니다. App Store에서 Clash Plus를 설치한 뒤에도 연결과 백그라운드 동작은 시스템 스케줄링의 영향을 받습니다. 데스크톱처럼 프로세스가 계속 실행된다고 생각해서는 안 됩니다. 시스템은 네트워크 변화 시 터널을 다시 만들 수 있고 확장의 메모리와 실행 시간도 제어합니다. 노드 수가 지나치게 많거나 규칙 집합이 크고 로그가 계속 갱신되면 네트워크 확장의 부담이 커질 수 있습니다.

모바일 사용감에 미치는 프로토콜의 실제 영향

SS는 연결 구조가 단순해 CPU와 메모리 비용을 관리하기 쉽고 모바일의 안정적인 기준선으로 적합합니다. Trojan과 TLS를 사용하는 VLESS, VMess는 TLS 처리를 수행하지만 최신 모바일 프로세서는 일반적인 암호화를 잘 지원하므로 일상적인 웹 이용에서 차이가 크지 않을 수 있습니다. 복잡한 전송, 다층 캡슐화, 많은 동시 연결을 더 주의 깊게 봐야 합니다. 같은 노드 그룹에서 사용감이 비슷하다면 장애 지점이 적고 네트워크 전환 후 복구가 안정적인 방식을 우선하세요.

Hysteria2와 TUIC는 약한 네트워크, 다중 스트림, 경로 변화에서 더 매끄럽게 작동할 수 있지만 지속적인 UDP 세션이 일부 모바일 네트워크와 잘 맞지 않을 수 있습니다. 어떤 네트워크는 UDP NAT 매핑을 빠르게 회수하고, 어떤 네트워크는 대용량 UDP 처리에 보수적입니다. Wi-Fi에서 셀룰러로 전환한 뒤 노드가 오랫동안 연결 중 상태에 머문다면 먼저 TCP 폴백 노드로 바꾸세요. 그런 다음 프로토콜 세션 마이그레이션 실패인지 시스템 VPN 인터페이스 재생성 지연인지 판단합니다.

재현 가능한 배터리 테스트 방법

먼저 경로가 비슷하고 부하가 안정적인 노드 두 개를 선택하고 규칙, DNS, 앱, 화면 밝기를 동일하게 유지하세요. 충전을 마친 뒤 기기 온도가 정상으로 돌아올 때까지 기다린 다음 같은 시간 동안 웹 브라우징, 백그라운드 오디오, 짧은 동영상, 대기 상태를 각각 실행합니다. 시스템 배터리 통계에서 클라이언트, 네트워크, 화면의 비중을 기록하고 기기가 자주 깨어나는지도 관찰하세요. 한 번의 테스트만으로는 앱의 백그라운드 활동을 배제하기 어려우므로 비슷한 시간대에 최소 두 번 반복해야 합니다.

테스트 중에는 구독과 규칙 집합을 동시에 업데이트하지 마세요. 규칙 다운로드, 압축 해제, 파싱은 일시적인 CPU와 네트워크 피크를 만들므로 이를 프로토콜의 배터리 소모로 계산하는 것은 의미가 없습니다. 지속적인 최대 속도 다운로드를 일상적인 대기 상태의 대표로 삼아서도 안 됩니다. 최대 속도 환경은 처리 효율을 측정하고 대기 환경은 연결 유지와 시스템 스케줄링을 측정합니다. 두 결과는 따로 기록해야 합니다.

기기 비용을 줄이는 설정 경로

첫째, 실제로 필요한 규칙 집합만 남기고 같은 역할의 대형 목록을 여러 개 중복 로드하지 마세요. 둘째, 로그는 일반 수준으로 유지하고 문제 해결이 끝나면 실시간 디버그를 끄세요. 셋째, 노드 자동 테스트 간격을 지나치게 짧게 설정하지 마세요. 수십 초마다 많은 노드를 검사하면 네트워크와 CPU가 계속 깨어납니다. 넷째, 필요할 때만 연결하는 기능을 켤 경우 시스템 동작을 확인해 여러 자동화 규칙이 서로를 반복 실행하지 않도록 하세요. 다섯째, DNS nameserver 수를 적정하게 유지하세요. 동시 조회를 늘린다고 속도가 선형적으로 빨라지지는 않습니다.

클라이언트에서 TUN 스택, 트래픽 스니핑, IPv6, UDP 포워딩 같은 옵션을 제공하더라도 필요에 따라 켜야 하며 모두 활성화할 필요는 없습니다. 기능을 끄기 전 사용 환경을 먼저 확인하세요. 게임과 음성 통화에는 대개 UDP가 필요하고, 도메인 규칙에 의존하는 앱은 스니핑으로 대상 정보를 보완해야 할 수 있으며, IPv6 네트워크에서는 DNS와 규칙이 IPv6까지 제대로 포함하는지 확인해야 합니다. 절전은 기능을 무작정 삭제하는 것이 아니라 실제 트래픽에 맞게 기능을 사용하는 것입니다.

모바일에서는 최종적으로 두 경로를 남겨 두는 것이 좋습니다. 하나는 간단하고 안정적인 TCP 노드를 상시 기준선으로 사용하고, 다른 하나는 약한 네트워크와 패킷 손실이 많은 환경을 위한 Hysteria2 또는 TUIC 노드로 둡니다. 실제 네트워크 전환, 화면 잠금, 대기 테스트를 통해 기본 경로를 결정하세요. 프로토콜이 복잡할수록 포그라운드 속도 테스트 화면의 숫자보다 시스템 백그라운드 동작을 검증하는 일이 중요합니다.

06 / CORE FAMILY

원본 Clash, Clash Meta, mihomo의 관계

먼저 클라이언트 외형과 프록시 코어를 구분하세요

Clash 생태계에서는 “클라이언트”와 “코어”를 자주 혼동합니다. 그래픽 클라이언트는 설정 관리, 구독 업데이트, 시스템 프록시, 트레이 메뉴, 로그 화면을 담당합니다. 코어는 포트 리스닝, DNS, 규칙 매칭, 프로토콜 연결, TUN을 담당합니다. Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu 등은 그래픽 클라이언트이며 mihomo를 통합하거나 코어를 바꿀 수 있도록 제공하기도 합니다. 화면이 비슷하다고 해서 하위 프로토콜 지원이 완전히 같다는 뜻은 아닙니다.

호환성 문제를 확인할 때는 먼저 클라이언트의 정보 화면이나 시작 로그에서 코어 이름을 확인한 뒤 설정 파일을 살펴보세요. 앱 이름만 보고 판단하면 오류가 생깁니다. 예를 들어 특정 클라이언트 버전은 코어 빌드 방식을 바꿀 수 있고, 다른 클라이언트는 호환 옵션을 유지할 수 있습니다. 이 사이트에서 특정 버전 번호를 고정하지 않는 이유는 간단합니다. 코어와 클라이언트는 계속 바뀌므로 실제 설치 패키지에 표시된 코어 식별자가 현재의 사실이기 때문입니다.

원본 Clash: 기본 문법의 출발점

원본 Clash는 널리 쓰이는 YAML 구조를 정립했습니다. proxies는 노드를 정의하고, proxy-groups는 선택 및 테스트 로직을 정의하며, rules는 순서대로 트래픽을 매칭합니다. DNS, 리스닝 포트, 실행 모드는 최상위에 위치합니다. 많은 튜토리얼과 구독 형식이 이 모델을 따르고 있으며 SS, VMess, Trojan 같은 기본 프로토콜과 전통적인 규칙 문법에도 여전히 영향을 미칩니다.

하지만 원본 코어는 이미 유지 관리가 중단되었습니다. Hysteria2, TUIC, 최신 VLESS 보안 조합, 규칙 집합 형식, 현대적인 TUN 기능을 다룰 때 원본의 기능 범위를 새 설정의 기준으로 삼으면 많은 한계에 부딪힙니다. 기존 설정은 문법의 출발점으로 사용할 수 있지만 오래된 코어를 새로운 프로토콜의 호환 대상으로 삼아서는 안 됩니다. Clash for Windows도 유지 관리가 중단되었으며 다운로드 페이지에서는 보관 항목으로 분류합니다. 기존 환경을 다룰 때는 사용할 수 있지만 새 설치의 우선 선택으로는 적합하지 않습니다.

Clash Meta: 호환성 확장 단계

Clash Meta는 원본 설정 모델에 프로토콜, DNS, 규칙 제공자, TUN, 네트워크 기능을 확장했습니다. 많은 원본 YAML을 그대로 불러온 뒤 Meta 확장 필드를 단계적으로 추가할 수 있습니다. 이 단계에서 생태계는 새로운 프로토콜과 복잡한 설정 요구를 해결했고, “Meta 설정”이라는 표현도 널리 쓰이게 되었습니다. 설정 파일에 rule-providers, 더 완전한 DNS 항목, sniffer, 새로운 프로토콜 필드가 나타난다면 대개 원본 Clash의 안정적인 기능 범위를 넘어선 것입니다.

호환성은 한쪽으로 기울어 있습니다. Meta 계열 코어는 대체로 많은 원본 설정을 읽을 수 있지만 원본 코어는 모든 Meta 확장을 이해하지 못합니다. mihomo 설정을 오래된 원본 코어에 그대로 넘기면 알 수 없는 프록시 유형, 알 수 없는 필드, 규칙 제공자 로딩 실패가 발생할 수 있습니다. 오류가 난 줄을 삭제하면 실행될 때도 있지만 DNS, 라우팅, 노드 보안 파라미터가 조용히 바뀔 수 있으므로 “실행된다”는 사실을 동등한 호환성으로 보아서는 안 됩니다.

mihomo: 현재 지속적으로 유지 관리되는 계승 코어

mihomo는 Clash Meta 프로젝트의 후속 명칭이자 지속적으로 유지 관리되는 코어입니다. Clash 설정 방식을 이어받으면서 새로운 프로토콜, 네트워크 스택, DNS, 규칙 기능을 계속 지원합니다. 많은 클라이언트 화면은 여전히 Clash 또는 Meta라는 용어를 사용하지만 실제 하위에서 mihomo가 실행됩니다. 새로 설치하는 사용자는 mihomo를 통합하고 지속적으로 업데이트하는 클라이언트를 우선 선택하는 편이 좋습니다. Windows에서는 이 사이트가 Clash Plus를 우선 추천하며, 화면과 플랫폼 요구에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu도 선택할 수 있습니다.

mihomo의 기능이 많다고 해서 모든 옵션을 켤 필요는 없습니다. TUN, 스니핑, Fake-IP, 규칙 제공자, 외부 제어 인터페이스는 각각 다른 문제를 해결합니다. 인터넷에서 큰 설정 파일을 통째로 복사하면 필드 충돌, DNS 루프, 잘못된 규칙 순서, 리소스 사용량 증가가 발생하기 쉽습니다. 구독에서 생성된 작동 가능한 설정을 출발점으로 삼고, 한 번에 하나의 모듈만 추가한 뒤 로그와 트래픽 경로를 확인하는 방식이 더 안전합니다.

설정 호환성은 문법이 아니라 동작을 확인해야 합니다

첫 번째 호환성은 YAML을 파싱할 수 있는지입니다. 두 번째는 노드 필드를 완전히 인식하는지입니다. 세 번째는 DNS, 규칙, TUN 동작이 예상과 일치하는지입니다. 일부 알 수 없는 필드는 무시되어 설정이 실행될 수 있지만 트래픽 경로에는 차이가 생깁니다. 예를 들어 프록시 노드에 서버 이름이 없으면 TLS가 실패할 수 있고, 규칙 제공자가 로드되지 않으면 트래픽이 최종 규칙으로 넘어가며, Fake-IP 필터가 없으면 로컬 네트워크 도메인 조회에 영향을 줄 수 있습니다. 코어를 업그레이드한 뒤에는 로그, 노드 연결, 주요 규칙 매칭을 확인해야 합니다.

이전할 때는 원본 구독, 현재 클라이언트에서 작동하는 설정, 수정할 새 설정이라는 세 가지 사본을 보관하세요. 먼저 최상위 필드를 비교하고, 다음으로 노드 프로토콜과 프록시 그룹을 비교한 뒤 규칙과 DNS를 확인합니다. 여러 클라이언트가 같은 설정 디렉터리를 동시에 수정하지 않도록 하세요. 자동 업데이트가 수동 변경을 덮어쓸 수 있습니다. 장기적으로 유지할 사용자 규칙은 구독 생성 파일을 직접 수정하기보다 클라이언트가 지원하는 오버라이드 또는 merge 기능에 두는 편이 좋습니다.

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

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

이 최소 구조는 계층 관계만 보여 주며 실제 노드는 포함하지 않습니다. 설정이 파싱된 뒤 구독 또는 클라이언트 오버라이드로 프록시 노드, DNS, 규칙 제공자를 추가합니다. 최소 설정은 실행되지만 전체 설정이 실패한다면 모듈을 구간별로 하나씩 복원하세요. 이분 탐색 방식이 화면 전체의 로그를 바라보며 필드를 추측하는 것보다 훨씬 빠릅니다. 라우터에서 mihomo 코어를 직접 실행하는 배포 차이는 《라우터에서 mihomo 코어로 투명 프록시를 구성하는 방법》에서 확인할 수 있습니다.

07 / PROFILE FORMAT

구독 형식, 노드 필드, 변환 호환성

구독 링크는 Clash 설정 파일과 같지 않습니다

구독 링크는 데이터를 가져오는 입구일 뿐입니다. 반환되는 내용은 전체 Clash YAML, 여러 공유 링크를 합친 텍스트, base64로 인코딩된 목록, 서비스 제공자의 사용자 지정 구조일 수 있습니다. 전체 Profile에는 노드 외에도 프록시 그룹, 규칙, DNS, TUN, 규칙 제공자가 포함될 수 있지만 일반 구독은 노드만 담는 경우가 많습니다. 클라이언트로 가져온 뒤 노드만 표시되고 예상한 규칙이 없다면 가져오기에 실패한 것이 아닐 수 있습니다. 원본 구독이 애초에 전체 정책을 제공하지 않았을 가능성이 있습니다.

반대로 전체 Clash YAML이라고 해서 모든 클라이언트에 바로 적합한 것도 아닙니다. 클라이언트가 mihomo를 사용하더라도 오버라이드, 스크립트, 외부 규칙 집합 경로를 자체적으로 관리할 수 있습니다. 가져오기 전에 파일 유형을 확인하세요. proxies:, proxy-groups:, rules: 세 구간이 보이면 대개 전체 설정입니다. 여러 줄의 ss://, vmess:// 링크가 보이면 노드 목록에 가깝습니다.

공유 링크에 포함되는 정보는 프로토콜에 따라 달라집니다

SS 공유 링크에는 보통 암호화 방식, 비밀번호, 서버, 포트가 포함되며 쿼리 파라미터로 플러그인이 추가될 수 있습니다. VMess 공유 형식에는 사용자 식별자, 전송 방식, Host, 경로, TLS 등이 인코딩되는 경우가 많습니다. Trojan 링크에서는 비밀번호, 서버, 포트, SNI, 전송 파라미터가 중요합니다. VLESS 링크에는 보안 유형, flow, 지문, 공개 키 식별자, 서버 이름, 전송 필드가 포함될 수 있습니다. Hysteria2와 TUIC도 인증, SNI, 혼잡 제어 또는 UDP 관련 파라미터가 필요합니다.

문제는 변환기가 이러한 필드를 인식하는지에 있습니다. 변환기가 프로토콜의 기본 필드만 구현했다면 노드 이름과 서버는 보존하면서 flow, Reality 설정, WebSocket 헤더, gRPC 서비스 이름, Hysteria2 대역폭 안내를 누락할 수 있습니다. 생성된 YAML은 깔끔해 보여도 실제 핸드셰이크는 반드시 실패합니다. 새 프로토콜이나 복잡한 조합에서 가져오기 문제가 발생하면 먼저 클라이언트가 원본 구독을 직접 읽도록 시도한 뒤 변환 결과와 필드를 하나씩 비교하세요.

YAML 자체에도 놓치기 쉬운 경계가 있습니다

YAML은 들여쓰기에 민감합니다. Tab 문자, 잘못된 계층, 콜론 뒤의 특수 텍스트가 파싱을 깨뜨릴 수 있습니다. 노드 이름에 콜론, 샵, 대괄호, 앞뒤 공백이 포함되면 따옴표를 사용하는 편이 안전합니다. 불리언 값은 코어 요구 사항에 따라 true 또는 false로 작성하고 포트는 숫자로 유지하세요. 같은 키가 중복되면 파서마다 처리 방식이 다를 수 있으므로 뒤의 키가 앞의 키를 덮어쓰는 우연한 동작에 의존해서는 안 됩니다.

프록시 그룹은 노드 이름을 참조하므로 이름을 바꾸면 그룹 내부의 참조도 함께 수정해야 합니다. 규칙 마지막에는 보통 MATCH,PROXY 같은 기본 처리 항목이 필요합니다. 규칙은 위에서 아래 순서로 매칭되므로 앞의 포괄적인 규칙이 뒤의 세부 규칙을 가로챌 수 있습니다. 구독 변환은 구조를 생성할 뿐 실제 업무 규칙이 적절한지 자동으로 판단하지 않습니다. 설정 파일 구조와 여러 설정 관리 방법은 《Clash 설정 파일이란 무엇인가》에서 확인할 수 있습니다.

가져온 뒤 네 계층으로 검수하세요

첫 번째는 수량입니다. 노드 수가 원본 구독과 대략 일치하는지, 프로토콜 유형이 빠짐없이 포함되는지 확인하세요. 두 번째는 필드입니다. 복잡한 VLESS 하나, Trojan 또는 VMess 하나, Hysteria2 또는 TUIC 하나를 추출해 TLS, SNI, 전송, 인증 필드를 확인합니다. 세 번째는 정책입니다. 프록시 그룹이 실제로 존재하는 노드를 참조하는지, 규칙 집합이 정상적으로 로드되는지, 최종 규칙이 있는지 봅니다. 네 번째는 동작입니다. DNS, 일반 HTTPS, UDP 애플리케이션, 노드 전환을 각각 테스트하세요.

일부 노드만 실패한다면 실패한 노드와 같은 프로토콜의 정상 노드 필드 구조를 비교하세요. 특정 프로토콜 전체가 실패한다면 코어 지원과 변환기 매핑을 확인합니다. 모든 노드가 정상이지만 웹페이지가 열리지 않는다면 문제는 구독 형식보다 시스템 프록시, TUN, DNS, 규칙일 가능성이 높습니다. 장애가 어느 계층에 있는지 좁힌 뒤 수정해야 하며, 계속 다시 가져와 설정 목록을 복잡하게 만들지 않도록 하세요.

구독 업데이트와 사용자 규칙은 계층을 나누어 관리하세요

구독에서 생성된 Profile을 직접 편집하면 다음 업데이트에서 수정 내용이 덮어써지는 경우가 많습니다. 클라이언트가 오버라이드, 설정 병합, 확장 스크립트를 지원한다면 로컬 규칙, DNS 조정, 프록시 그룹 변경을 별도 계층에 두세요. 기본 구독은 노드를 제공하고 오버라이드 계층은 사이트 또는 기기 정책을 담당하게 합니다. 이렇게 하면 노드가 업데이트될 때 전체 YAML을 다시 수정할 필요가 없고 문제가 있는 사용자 모듈도 빠르게 비활성화할 수 있습니다.

여러 서비스나 용도의 설정을 함께 사용할 때는 이름에 출처와 용도를 담으세요. 예를 들어 “일상”, “모바일 예비”, “테스트”처럼 지정하고 “설정 1”, “설정 2”는 피하는 것이 좋습니다. 마지막 업데이트 시각과 사용자 오버라이드 활성화 여부도 기록하세요. Profile을 전환한 뒤에는 시스템 프록시 또는 TUN 상태를 다시 확인해야 합니다. 일부 클라이언트는 설정만 바꾸고 기존 연결 상태를 자동으로 복구하지 않습니다.

proxy-providers:
  primary:
    type: http
    url: "https://example.invalid/subscription"
    path: ./providers/primary.yaml
    interval: 21600
    health-check:
      enable: true
      interval: 1800
      url: https://www.gstatic.com/generate_204

이 예시는 mihomo의 프록시 제공자 구조를 보여 주며 주소는 명확한 예시 도메인입니다. interval은 구독 업데이트 간격을 제어하고 상태 확인에는 별도의 간격이 있습니다. 두 값을 지나치게 짧게 설정하면 네트워크 요청과 모바일 기기 깨우기가 늘어납니다. 실제 구독 주소는 클라이언트 화면을 통해 저장하고 문서, 스크린샷, 공유 설정에 공개해서는 안 됩니다.

base64, YAML, 일반 형식에 대한 추가 설명은 《Clash 구독 형식 알아보기》에서 확인할 수 있습니다. 변환의 목표는 파일을 짧게 만드는 것이 아니라 의미를 보존하는 것입니다. 새 프로토콜 필드를 만났을 때 불필요한 형식 변환을 한 번 줄이면 호환성 문제 지점도 대개 하나 줄어듭니다.

08 / FIELD GUIDE

기기와 네트워크 환경에 맞춰 프로토콜을 선택하세요

Windows 및 macOS의 일상적인 데스크톱 사용

데스크톱은 대체로 백그라운드 리소스 여유가 있고 네트워크가 안정적이므로 클라이언트 유지 관리 상태, 노드 경로, 설정 호환성을 우선 봐야 합니다. Windows 새 설치는 Clash Plus부터 시작하고 화면 요구에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu를 고려하세요. macOS에서도 Clash Plus를 우선 사용할 수 있으며 Clash Verge Rev, FlClash도 선택할 수 있습니다. Clash for Windows와 ClashX Meta는 유지 관리가 중단되었으며 다운로드 페이지에는 보관 옵션으로 남아 있습니다.

프로토콜은 먼저 구독에서 안정적인 SS, Trojan, VLESS 노드로 기준선을 세우세요. 지역을 고정한 뒤 Hysteria2 또는 TUIC를 추가해 패킷 손실과 지속 처리량을 비교합니다. 데스크톱에서는 수동 선택 그룹과 자동 테스트 그룹을 함께 유지할 수 있지만 자동 테스트는 도달 가능성과 테스트 URL의 핸드셰이크만 확인합니다. 기본 노드는 실제 웹페이지, 다운로드, 동영상 작업으로 최종 확인해야 합니다.

Android 및 iOS의 장기 백그라운드 사용

Android에서는 화면과 설정 요구에 따라 Clash Plus, Clash Meta for Android, FlClash, Surfboard 중에서 선택할 수 있고 iOS에서는 Clash Plus를 사용합니다. 모바일에서는 먼저 백그라운드 권한, VPN 상태, 네트워크 전환 후 복구를 확인한 뒤 프로토콜을 비교하세요. 일상적으로 메시지, 웹, 오디오를 주로 사용한다면 간단하고 안정적인 SS, Trojan, VLESS가 기본값으로 적합한 경우가 많습니다. 약한 네트워크나 패킷 손실이 많은 환경에서는 Hysteria2 또는 TUIC로 전환할 수 있지만 화면 잠금과 셀룰러 네트워크에서 반드시 검증해야 합니다.

노드 그룹을 지나치게 크게 만들지 마세요. 수십 개 노드를 자동 테스트하면 DNS, 연결, 배터리 비용이 늘어납니다. 지역과 용도에 따라 작은 그룹으로 나누는 것이 좋습니다. 일상 그룹에는 검증된 소수의 노드만 넣고 예비 그룹에는 다른 프로토콜과 경로를 보관하세요. 여행지, 호텔 Wi-Fi, 임시 방문자 네트워크에서 UDP 노드가 모두 시간 초과되면 현장에서 인증서와 DNS를 반복 수정하지 말고 TCP 폴백 그룹으로 바로 전환하세요.

라우터 및 저전력 기기

라우터에서 mihomo를 실행할 때는 데스크톱보다 CPU 아키텍처, 메모리, 냉각, 하드웨어 포워딩 성능이 중요합니다. SS 구현은 대체로 가벼워 리소스 기준선으로 적합합니다. TLS, 복잡한 VLESS 조합, Hysteria2, TUIC는 더 많은 사용자 공간 처리를 요구하므로 실제 처리량이 CPU 단일 코어 성능에 제한될 수 있습니다. 기기에 표시된 네트워크 포트 속도가 프록시 처리량을 보장하지는 않습니다. TUN, 투명 프록시, 규칙 집합, DNS도 리소스를 사용합니다.

먼저 작은 규칙 집합과 하나의 프로토콜로 안정적인 처리량을 테스트한 뒤 투명 프록시, Fake-IP, 스니핑, 규칙 제공자를 단계적으로 활성화하세요. CPU가 최대 부하인데 네트워크 속도가 기대치에 미치지 못한다면 프로토콜을 바꾸기 전에 로그를 줄이고 규칙 규모를 축소하며 소프트 라우터에서 중복 포워딩이 발생하는지 확인하세요. 라우터는 여러 단말을 서비스하므로 단일 연결의 최고 속도보다 안정성이 중요한 경우가 많습니다. Hysteria2 또는 TUIC는 경로가 맞을 때 처리량을 높일 수 있지만 UDP 세션 테이블과 방화벽 용량도 확인해야 합니다.

실시간 음성 통화, 게임, 동영상

실시간 서비스는 지터, 패킷 손실 복구, UDP 포워딩을 중요하게 봅니다. 먼저 클라이언트 TUN 또는 시스템 VPN이 해당 트래픽을 인계받았는지, 규칙이 앱을 DIRECT 또는 REJECT로 잘못 보내고 있지 않은지 확인하세요. 다음으로 노드 서버까지의 지연이 아니라 노드에서 실제 대상 서비스까지의 경로를 비교합니다. Hysteria2와 TUIC는 패킷 손실이 많은 네트워크에서 더 매끄러운 다중 스트림 전송을 유지할 수 있지만, 추가적인 신뢰성 계층이 모든 실시간 UDP 애플리케이션의 지연을 낮춘다고 보장할 수는 없습니다.

동영상은 지속 처리량과 혼잡 복구가 더 중요합니다. 지연은 낮지만 출구가 혼잡한 노드는 버퍼링이 잦을 수 있고, 지연은 높아도 처리량이 안정적인 노드가 더 적합할 수 있습니다. 노드를 선택할 때는 《Clash 노드 선택 방법》에서 설명하는 지연, 배율, 지역, 프로토콜 네 가지 기준을 활용하세요. 배율은 트래픽 비용이고 지역은 콘텐츠와 라우팅에 영향을 주며 프로토콜은 그중 하나의 요소일 뿐입니다.

바로 실행할 수 있는 선택 절차

1. 코어를 확인합니다. 클라이언트 정보 화면 또는 로그에서 mihomo를 사용하는지 확인해 새 프로토콜 필드가 오래된 원본 코어로 넘어가지 않도록 합니다.
2. 구독을 확인합니다. 노드 수, 프로토콜 유형, 복잡한 필드를 확인하고 여러 차례 변환하기 전에 원본 구독을 보관합니다.
3. TCP 기준선을 만듭니다. SS, Trojan, VMess, VLESS 중 안정적인 노드를 하나 선택해 DNS, HTTPS, 지속 연결을 확인합니다.
4. UDP 경로를 테스트합니다. 같은 지역의 Hysteria2 또는 TUIC를 추가해 UDP 도달 가능성, 지속 처리량, 네트워크 전환과 복구를 확인합니다.
5. 기기 비용을 확인합니다. 데스크톱에서는 CPU와 안정성, 휴대폰에서는 대기 상태와 백그라운드, 라우터에서는 여러 단말의 동시 접속과 온도를 확인합니다.
6. 폴백 그룹을 만듭니다. 하위 전송 방식이 다른 노드를 하나의 수동 선택 그룹에 넣어 네트워크 변화 때 빠르게 전환하고 임시로 설정을 수정하지 않도록 합니다.

특정 프로토콜이 한 노드에서만 제공된다면 공정한 비교 조건이 아니므로 프로토콜 결론이 아니라 노드 선택으로 취급하세요. 같은 프로토콜의 여러 노드가 한 네트워크에서 모두 실패하고 다른 네트워크에서는 복구된다면 UDP 또는 전송 경로를 먼저 확인합니다. 특정 클라이언트에서만 실패하면 코어와 필드를 먼저 확인하고, 모든 클라이언트에서 실패하면 서버와 구독 원본으로 돌아가세요. 계층별로 문제를 확인하면 같은 잘못된 설정을 유지한 채 클라이언트만 계속 바꾸는 일을 피할 수 있습니다.

결론: 이름이 아니라 제약 조건에 따라 선택하세요

SS의 가치는 단순함과 성숙도에 있어 일반적인 사용과 저사양 기기의 기준선으로 적합합니다. VMess는 기존 노드와 전송 조합이 많다는 현실적인 장점이 있지만 전체 필드를 보존해야 합니다. Trojan은 표준 TLS 경로에 의존하므로 인증서와 서버 이름이 정확해야 합니다. VLESS의 성능은 보안 계층과 전송 조합에서 나오므로 지속적으로 관리되는 코어가 더 중요합니다. Hysteria2는 패킷 손실과 처리량이 큰 경로를 겨냥하고, TUIC는 QUIC의 다중 스트림과 세션 기능을 강조합니다. 각 프로토콜이 해결하는 문제가 다르므로 경로, 기기, 서버 구현을 배제한 고정 순위는 존재하지 않습니다.

코어는 새 설정의 주요 확인 대상으로 mihomo를 사용하고, 원본 Clash 문법은 구조의 기반으로 활용하세요. Clash Meta 설정은 대체로 mihomo로 이전할 수 있습니다. 구독은 원래 의미를 우선 보존하고 불필요한 변환을 줄인 뒤 가져온 후 노드, 필드, 정책, 동작의 네 계층으로 검수하세요. 클라이언트는 지속적으로 유지 관리되며 코어 상태를 명확하게 표시하는 제품을 우선 선택하는 것이 좋습니다. Windows와 macOS에서는 Clash Plus를 우선 고려하고 다른 플랫폼은 다운로드 페이지의 목록에 따라 선택하세요.

선택을 마쳤다면 입문 가이드로 돌아가 구독 가져오기, 모드 선택, 연결 확인을 진행하세요. 설치 파일이 필요하면 다운로드 페이지로 이동하고, 인터넷 연결, DNS, 규칙 매칭에 문제가 생기면 도움말 센터를 확인하세요. 프로토콜 선택은 이제 반복 가능한 절차가 되어야 합니다. 코어 확인, 원본 설정 보관, 변수 고정, 실제 작업 테스트, 폴백 경로 유지의 순서로 진행하세요.