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

1. 프로토콜·전송 방식·클라이언트 선택 기준

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

클라이언트 인터페이스, 프록시 코어, 프록시 프로토콜, 하위 전송 계층은 서로 다른 역할을 합니다. 클라이언트는 설정 관리, 구독 업데이트, 시스템 프록시 및 권한 처리를 담당합니다. 코어는 설정을 읽어 DNS, 규칙 매칭, 아웃바운드 연결을 처리합니다. 프로토콜은 클라이언트와 서버 간 인증 및 데이터 전달 방식을 정의하고, 전송 계층은 TCP, UDP 또는 그 위에 캡슐화된 방식으로 데이터가 상대방에게 도달하도록 합니다. 인터페이스에 같은 노드 이름이 표시되어도 실제 코어 매개변수까지 같다는 뜻은 아닙니다. 호환성을 판단할 때는 먼저 프로토콜 종류, 다음으로 전송 방식, 마지막으로 클라이언트가 관련 필드를 코어에 빠짐없이 전달하는지 확인하세요.

프로토콜 선택에서 가장 먼저 확인할 것은 어떤 프로토콜이 최신인지가 아니라 서버가 무엇을 지원하는지입니다. 서버가 Trojan만 제공하는데 로컬 유형을 VLESS로 바꿔도 연결 방식이 바뀌지 않습니다. 인증이나 핸드셰이크가 실패할 뿐입니다. 구독에 포함된 주소, 포트, 인증 정보, TLS 이름, 전송 경로는 하나의 설정 묶음으로 봐야 합니다. 필드를 편집할 수 있다고 해서 임의로 바꿔도 된다는 뜻은 아닙니다. 다른 프로토콜을 시험하려면 서버에서 명시적으로 제공한 별도 설정을 사용하고, 기존에 작동하는 설정은 비교를 위해 보관하세요.

연결 속도는 하나의 지표가 아닙니다

사용자가 느끼는 ‘빠르다’는 경험에는 첫 페이지가 열릴 때까지의 대기 시간, 지속 전송 속도, 장시간 사용 시 안정성이 모두 포함됩니다. 첫 요청은 도메인 조회, 서버 핸드셰이크, 인증, 목적지 서버 연결을 차례로 거칠 수 있습니다. 지속 다운로드 속도는 대역폭, 혼잡 제어, 패킷 손실, 서버 부하에도 영향을 받습니다. 작은 요청에 빠르게 응답하는 노드가 대용량 파일에 적합하다는 보장은 없고, 다운로드 한 번으로 대역폭을 꽉 채웠다고 화상회의 지터가 낮다는 뜻도 아닙니다. 따라서 이 페이지에서는 환경과 무관한 프로토콜 속도 순위를 제시하지 않으며, 클라이언트 테스트 항목의 단일 결과를 종합적인 성능 평가로 간주하지 않습니다.

보안 경계와 비교 순서

프록시 연결의 암호화는 주로 클라이언트와 프록시 서버 사이의 구간을 보호합니다. 목적지 웹사이트의 보안 특성까지 자동으로 바꾸지는 않습니다. HTTPS 사이트에 접속할 때 브라우저는 계속 웹사이트 인증서를 검증해야 합니다. 프록시 프로토콜이 TLS를 사용한다면 코어도 프록시 서버 인증서를 검증해야 하며, 두 검증은 서로를 대신할 수 없습니다. 서버 운영자, 구독 제공처, 목적지 앱의 권한 역시 신뢰 경계에 포함됩니다. 프로토콜 이름만으로 서비스가 신뢰할 만하다고 판단할 수 없으며, 이를 이유로 인증서 검증을 끄거나 구독 주소를 공개하거나 로컬 네트워크 수신 범위를 넓혀서는 안 됩니다.

‘연결 가능 여부, 기능 충족 여부, 리소스 사용량, 지속적인 유지 관리 가능성’ 순으로 선택지를 좁혀 보세요. 먼저 운영체제와 아키텍처에 맞는지 확인하고, 다음으로 코어가 구독의 프로토콜과 전송 방식을 지원하는지 살펴보세요. 마지막으로 실제 작업 환경에서 안정성과 배터리 소모를 비교합니다. 규칙 분류, TUN, 도메인 스니핑은 트래픽을 가로채고 식별하는 기능이지 특정 노드 프로토콜만의 가속 기능은 아닙니다. 브라우저 사용만 필요하다면 시스템 프록시로 충분할 수 있습니다. 시스템 프록시를 따르지 않는 앱까지 처리해야 할 때 TUN과 라우팅 설정을 검토하세요.

2. Shadowsocks와 VMess의 설계상 차이

Shadowsocks: 경량 전달과 암호화 방식

Shadowsocks는 흔히 SS라고 부르며, 암호화된 프록시 전달을 중심으로 설계되었습니다. 일반적으로 서버 주소, 포트, 암호화 방식, 비밀번호를 설정합니다. 복잡한 전송 협상, 인증서 관리, 제어 패널을 프로토콜에 모두 포함하기보다 전달 경로를 간결하게 유지하는 데 초점을 둡니다. 클라이언트 인터페이스에 SS라고 표시되어도 이는 프로토콜 계열만 나타낼 뿐이며, 실제 호환성은 암호화 방식과 확장 기능에 따라 달라집니다. 유형 이름이 같더라도 설정을 항목별로 확인해야 합니다. 이전 클라이언트에서 SS를 지원했다고 해서 이후에 나온 모든 암호화 방식까지 지원한다고 볼 수는 없습니다.

최신 설정에서는 인증 기능을 포함한 암호화 방식을 흔히 사용하며, AEAD는 암호화뿐 아니라 데이터 무결성도 확인합니다. SS의 암호화 방식마다 키 파생, 비밀번호 형식, 구현 요건이 다를 수 있으므로 방식 이름만 바꾸고 나머지 매개변수를 그대로 재사용해서는 안 됩니다. 최신 방식을 사용할 때는 클라이언트에 포함된 코어와 서버 구현이 모두 지원하는지 먼저 확인하세요. 프로세서 가속에 크게 의존하는 알고리즘은 데스크톱과 저전력 기기에서 리소스 사용 양상이 다를 수 있습니다. 알고리즘 이름만으로 배터리 효율을 판단할 필요는 없습니다. 실제 부하와 구현 품질이 더 중요할 때가 많습니다.

SS의 TCP 및 UDP 전달은 각각 따로 살펴봐야 합니다. 서버에서 TCP 연결을 허용한다고 해서 해당 UDP 경로와 포트, 방화벽 설정까지 준비되었다는 뜻은 아닙니다. 웹은 되지만 음성 통화나 게임에 문제가 있다면 UDP를 별도로 확인하세요. 일부 SS 설정은 플러그인에 의존하기도 합니다. 플러그인은 비밀번호에 덧붙이는 텍스트가 아니라 별도의 전송 조건입니다. 클라이언트가 SS 기본 필드는 인식하더라도 플러그인이나 옵션을 구현하지 못한다면, 가져오기에 성공해도 연결되지 않을 수 있습니다. 설정을 옮기기 전에 플러그인 이름, 모드, 서버 설정이 서로 일치하는지 확인하세요.

VMess: 인증, 시간, 전송 조합

VMess는 V2Ray 생태계에서 시작되었으며 사용자 인증과 프록시 데이터 전송을 중심으로 설계되었습니다. 일반적으로 UUID로 사용자를 식별합니다. VMess는 여러 전송 방식과 조합할 수 있으므로 ‘VMess 노드’라는 표현만으로는 연결 설정을 모두 알 수 없습니다. TCP 직결, WebSocket 등의 조합은 핸드셰이크 과정과 설정 필드가 다릅니다. 한 전송 방식의 경로나 요청 헤더를 다른 방식에 그대로 복사할 수 없습니다. 클라이언트는 VMess 구현과 지정된 전송 계층을 모두 지원해야 하며, 서버 진입점도 동일한 조합을 받아들여야 합니다. 그렇지 않으면 인증 전에 연결이 종료될 수 있습니다.

VMess는 시스템 시간이 정확해야 합니다. 기기 시계가 크게 어긋나 있으면 주소와 UUID가 올바르더라도 인증에 실패할 수 있습니다. 이 문제를 해결할 때는 포트를 계속 바꾸기보다 시스템 자동 시간 설정과 시간대 표시를 확인하세요. 이전 자료에 나오는 alterId는 과거 인증 방식과 관련된 항목입니다. 오래된 예제를 모든 서버에 통용되는 설정으로 간주해서는 안 됩니다. 최신 설정은 서버 안내와 현재 코어 문서를 기준으로 하며, 오래된 가이드와의 호환을 위해 이전 옵션을 임의로 켜지 마세요. 업데이트 후 문제가 생겼다면 인증 변경과 전송 방식 변경을 구분해서 확인하세요.

기존 서비스를 계속 사용하는 방법

기존 SS 또는 VMess 서비스가 안정적으로 작동한다면 새 프로토콜이 나왔다는 이유만으로 이전할 필요는 없습니다. 먼저 현재 문제를 분명히 하세요. 서버 대역폭 부족인지, UDP가 연결되지 않는지, 오래된 클라이언트가 설정을 불러오지 못하는지 확인합니다. 대역폭 부족은 보통 로컬 프로토콜 이름을 바꾼다고 해결되지 않습니다. 전송 지원이 부족하다면 코어를 바꿔야 할 수 있습니다. 비교할 때는 기존 노드를 남겨 두고 새 설정을 별도 이름으로 가져온 뒤 웹 접속, 지속 전송, 필요한 UDP 앱을 각각 확인하세요. 그래야 개선이 프로토콜 때문인지, 서버 리소스 때문인지, 클라이언트 설정 수정 때문인지 판단할 수 있습니다.

3. Trojan과 VLESS의 TLS 설정 범위

Trojan: TLS에 의존하는 인증 및 전달

Trojan은 TLS 연결 안에서 프록시 인증과 데이터 전달을 처리합니다. 일반적인 구성에서는 비밀번호로 사용자를 인증하고 TLS로 전송을 암호화합니다. 설정 항목은 간단해 보여도 서버 주소, 포트, 비밀번호, 인증서 이름, TLS 동작이 서로 맞아야 합니다. IP 주소로 연결하더라도 인증서는 도메인 이름을 대상으로 발급되는 경우가 많으므로 연결 대상과 인증서 검증 이름은 다를 수 있습니다. 오류를 없애려고 검증을 끄지 말고 서버가 제공한 이름 매개변수를 사용하세요. 인증서 만료, 기기 시간 오류, 신뢰 체인 누락 때문에 올바른 비밀번호도 인증 단계까지 도달하지 못할 수 있습니다.

SNI는 TLS 핸드셰이크에서 대상 서버 이름을 전달하는 정보입니다. 인증서 검증은 상대방의 신원이 예상한 이름과 일치하는지 확인합니다. 둘은 관련이 있지만 같은 개념은 아닙니다. 일부 클라이언트는 한 입력값으로 관련 매개변수를 자동 설정하고, 다른 클라이언트는 각각 별도로 표시합니다. 설정을 복사할 때는 코어 필드 매핑을 확인하고 인터페이스의 항목 이름만 보고 추측하지 마세요. ALPN은 애플리케이션 계층 프로토콜 협상에 쓰이므로 서버 요구사항을 따라야 합니다. 익숙해 보이는 값을 임의로 넣으면 잘못된 진입점으로 연결되거나 핸드셰이크 직후 연결이 끊길 수 있습니다.

VLESS: 프로토콜 본체와 보안 계층의 분리

VLESS 역시 V2Ray 관련 생태계에서 시작되었습니다. 프로토콜 자체의 일부 부담을 줄이고 암호화는 외부 보안 계층에 맡기도록 설계되었습니다. UUID는 인증 매개변수이지 실제 데이터 암호화에 쓰는 비밀번호가 아닙니다. 실제 사용에서는 VLESS를 TLS, REALITY 또는 명확하게 보호된 배포 환경과 함께 고려해야 합니다. 이름에서 ‘가볍다’는 인상을 받더라도 보안 계층을 빠뜨려서는 안 됩니다. 클라이언트가 VLESS를 지원하더라도 모든 전송 방식, 보안 계층, 흐름 제어 조합을 지원한다는 뜻은 아닙니다.

REALITY는 특정 핸드셰이크 방식과 공개 키 등의 매개변수를 사용합니다. 일반 TLS의 인증서 이름만 다른 필드로 바꾸는 기능이 아닙니다. 설정에는 공개 키, 짧은 ID, 서버 이름, 클라이언트 지문 등이 필요할 수 있으며 각 항목은 서로 일치하는 서버 설정에서 가져와야 합니다. flow는 별개의 프로토콜 동작 옵션이므로 REALITY를 켰다고 임의로 입력해서는 안 됩니다. 조합이 가능한지 확인하려면 현재 mihomo 구현과 서버 구현이 모두 지원하는지 살펴보세요. 다른 코어의 설정 예제를 통째로 복사해 그대로 사용할 수 있다고 가정하지 마세요.

WebSocket, gRPC 등의 전송 방식도 범용 가속 스위치가 아닙니다. 기존 진입점이나 중간 계층 구성에 맞춰 사용할 수 있지만, 추가 경로, 서비스 이름, 요청 헤더, 협상 조건이 필요합니다. 서버가 WebSocket을 사용하는데 경로가 틀리면 일반 HTTP 오류가 발생할 수 있습니다. gRPC에서 서비스 이름이 다르면 연결에 실패할 수 있습니다. 문제가 생기면 먼저 전송 유형을 확인하고 해당 필드를 점검하세요. 프로토콜, 보안 계층, 경로를 한꺼번에 바꾸지 말고 한 번에 한 가지 조건만 조정해야 어느 계층에서 해결되었는지 알 수 있습니다.

두 프로토콜 중 무엇을 선택할까요?

서버에서 Trojan과 VLESS를 모두 제공한다면 인증 필드의 개수만 비교하지 말고 설정 완성도와 구현 호환성을 우선하세요. 간단한 TLS 구성이 필요하고 기존 서비스가 안정적으로 작동한다면 Trojan을 그대로 사용할 수 있습니다. 서버가 명확히 지원하는 VLESS 전용 조합이 필요하다면 해당 조합과 호환되는 클라이언트를 선택하세요. 두 프로토콜 모두 안정적으로 작동할 수 있지만 DNS, 인증서, 서버 부하 때문에 속도가 느려질 수도 있습니다. 첫 연결이 실패하면 DNS 조회, TCP 연결, TLS 핸드셰이크, 사용자 인증 중 어느 단계에서 문제가 생겼는지 구분한 뒤 관련 매개변수를 확인하세요.

설정을 이전할 때 구독 변환 도구가 보안 계층 필드를 누락하지 않는지 특히 주의하세요. 변환된 노드에 이름, 주소, UUID가 남아 있어도 공개 키나 흐름 제어 옵션이 빠져 실제로는 사용할 수 없을 수 있습니다. 변환 전후 파일을 보관해 항목별로 비교하고, 실제 인증 정보는 공개된 공간에 붙여 넣지 마세요. 특정 필드에 대한 설명이 없으면 임의로 매개변수를 조합해 시험하지 말고 서버 문서를 확인하세요.

4. Hysteria2와 TUIC의 QUIC 연결 방식

공통 기반: UDP 기반의 신뢰성 있는 전송

Hysteria2와 TUIC은 모두 QUIC 관련 기능을 사용하지만 서로 다른 프로토콜이며 호환되지 않습니다. QUIC은 일반적으로 UDP 위에서 동작하며 암호화 핸드셰이크, 스트림 관리, 패킷 손실 복구 등을 전송 구현에 통합합니다. 그렇다고 데이터가 임의로 손실되어도 된다는 뜻은 아닙니다. 신뢰성 있는 스트림은 패킷 손실과 재전송을 처리합니다. TCP 단일 바이트 스트림과 달리 여러 QUIC 스트림은 한 스트림의 손실이 다른 스트림의 순서 대기를 유발하는 현상을 줄일 수 있습니다. 하지만 스트림은 여전히 경로 대역폭, 혼잡 상태, 기기 리소스를 공유하므로 네트워크 자체의 용량을 넘어설 수는 없습니다.

외부 전송에 UDP를 사용하는 것은 실제 배포 시 필요한 조건입니다. 현재 네트워크, 라우터, 서버 방화벽에서 해당 경로를 허용해야 합니다. UDP가 차단되면 브라우저에서 HTTPS가 정상적으로 작동하더라도 QUIC 프록시는 연결되지 않을 수 있습니다. 일부 네트워크는 UDP 매핑의 유휴 유지 시간을 짧게 설정해 일정 시간 사용하지 않으면 연결이 끊어지기도 합니다. 문제를 확인할 때는 앱에서 UDP를 사용하는지 여부만 보지 말고 클라이언트에서 프록시 서버까지의 UDP 경로를 살펴보세요. 외부 전송 프로토콜과 내부 앱이 사용하는 프로토콜은 별개입니다. TCP 앱도 QUIC 프록시를 통해 전달할 수 있습니다.

Hysteria2: 대역폭 매개변수와 혼잡 제어

Hysteria2는 Hysteria를 바탕으로 프로토콜을 다시 설계한 방식입니다. 일반적인 설정에서는 비밀번호로 인증하고 TLS로 서버를 검증합니다. Hysteria 1세대와 유형 및 매개변수를 혼용할 수 없습니다. 혼잡 제어 동작은 대역폭 설정과 관련이 있으며 구체적인 모드는 클라이언트와 서버 간 협상에도 영향을 받습니다. 업로드 및 다운로드 값은 서버 상품에 표시된 대역폭이나 목표 속도를 뜻하지 않습니다. 현재 네트워크 연결과 실제 경로를 고려해 설정해야 합니다. 다른 사람의 높은 대역폭 값을 그대로 복사하면 대기열, 패킷 손실, 다른 앱과의 대역폭 경쟁이 늘어날 수 있습니다.

서버에서 난독화를 설정했다면 유형과 비밀번호를 확인하세요. 난독화는 TLS를 대신하지 않으며 인증서 이름 오류도 해결하지 않습니다. 먼저 기본 QUIC 연결을 확인한 다음 인증과 난독화 조건을 점검하세요. 설정을 이전할 때 구독의 대역폭 단위와 클라이언트의 해당 필드 지원 여부를 확인해 문자열과 숫자를 혼동하지 않도록 합니다. 다운로드 속도가 낮아졌다고 해서 매개변수 값이 너무 작은 것은 아닙니다. 네트워크 변경, 서버 출구, 지속적인 혼잡이 원인일 수 있습니다. 대역폭을 바꾸기 전에 기존 값을 기록하고 변경 후 웹 응답 및 다른 앱의 동작도 확인하세요.

TUIC: 연결 다중화와 UDP 전달 방식

TUIC은 QUIC으로 프록시 세션을 전달하며 연결 다중화와 TCP·UDP 트래픽 처리 방식에 중점을 둡니다. 일반적으로 UUID와 비밀번호가 모두 필요하지만 정확한 형식은 서버 프로토콜 버전과 현재 코어 구현을 따라야 합니다. 이전 버전의 TUIC과 최신 버전은 필드 하나를 추가한다고 호환되지 않습니다. 클라이언트 지원 목록에 TUIC이 있는지 확인하는 데서 그치지 말고, 어떤 버전의 설정과 혼잡 제어 옵션, 서버 UDP 전달 방식을 지원하는지 확인하세요.

UDP 전달에는 서로 다른 캡슐화 경로가 사용될 수 있으며 신뢰성과 오버헤드 사이에 차이가 있습니다. 데이터그램 기반 방식은 실시간 서비스의 시간 민감성에 더 적합한 경우가 있습니다. 신뢰성 있는 스트림 기반 방식은 오래된 데이터의 재전송이 뒤따르는 데이터의 전달을 늦출 수 있습니다. 실제 동작은 구현 문서를 확인하세요. 인터페이스에 ‘신뢰성’이라는 문구가 있다고 해서 게임에 더 적합하다고 단정할 수는 없습니다. 게임, 음성 통화, 파일 전송은 재전송과 대기 시간을 허용하는 정도가 다르므로 웹 페이지가 열리는지만 보지 말고 대상 앱으로 확인해야 합니다.

적절한 네트워크 경로에서 두 프로토콜 모두 시험해 볼 수 있지만, 모든 네트워크의 기본 최적 해법으로 볼 수는 없습니다. 진단용으로 이미 검증된 TCP 계열 노드를 함께 보관하는 것이 좋습니다. QUIC 노드는 실패하지만 TCP 노드는 정상이라면 클라이언트를 재설치하기 전에 UDP 경로와 서버 설정을 먼저 확인하세요.

5. 연결 오버헤드, 리소스 사용량, 모바일 배터리

핸드셰이크·처리량·다중화를 따로 측정하세요

첫 요청에 걸리는 시간은 여러 과정의 합이며 프로토콜은 그중 일부에만 영향을 줍니다. DNS 캐시가 적중하는지, 프록시 서버와 세션이 이미 설정되어 있는지, 목적지 사이트가 연결 재사용을 허용하는지도 결과에 영향을 미칩니다. TLS를 사용하는 프로토콜은 첫 핸드셰이크에 추가 작업이 필요할 수 있지만, 이후 연결을 재사용하면 같은 비용을 반복하지 않아도 됩니다. QUIC의 세션 복구에도 조건이 있으므로 이상적인 복구 경로가 모든 요청에서 나타난다고 가정해서는 안 됩니다. 일상적인 웹 이용 성능을 평가하려면 캐시가 없는 첫 접속과 연속 접속을 모두 살펴보세요. 캐시된 페이지를 반복해서 새로고침하는 것만으로 판단하지 마세요.

지속 처리량은 혼잡 제어, 가용 대역폭, 수신 기기의 처리 성능에 더 크게 좌우됩니다. 외부 TCP에서 패킷이 손실되면 재전송과 속도 조절이 발생하며, 캡슐화가 여러 겹이면 헤더와 버퍼 오버헤드도 늘어납니다. QUIC은 사용자 공간에서 전송 처리를 많이 수행하므로 CPU 비용은 구현, 시스템 인터페이스, 하드웨어에 따라 다릅니다. 두 경로 모두 특정 기기에서는 병목이 될 수 있습니다. 다운로드 중 CPU 사용량이 계속 높은데도 네트워크가 최대 속도에 도달하지 않는다면 기기 처리 성능을 살펴보세요. CPU 사용량이 낮지만 처리량이 크게 변한다면 네트워크와 서버 출구를 추가로 확인해야 합니다.

모바일 배터리는 지속적인 작업으로 소모됩니다

프로토콜 이름만으로 휴대폰 배터리 소모 순위를 정할 수는 없습니다. 암호화 연산, 사용자 공간 데이터 처리, 무선 통신 활성화, 백그라운드 연결 유지, 로그 기록, DNS 조회가 모두 배터리 사용량에 영향을 줍니다. 셀룰러 네트워크에서는 작은 패킷도 무선 모듈을 활성 상태로 유지할 수 있으며, 지속적인 다운로드는 무선 송수신과 프로세서 부하를 함께 높입니다. 연결 다중화는 반복적인 핸드셰이크를 줄일 때도 있지만, 잦은 연결 유지 신호는 유휴 상태의 배터리 소모를 늘릴 수 있습니다. 실제 사용 시간대를 기준으로 관찰해야 합니다. 화면을 켜고 몇 분간 사용한 뒤의 배터리 변화로 하루 종일 백그라운드에서 사용할 때의 성능을 추정하지 마세요.

비교할 때는 화면 밝기, 네트워크 유형, 백그라운드 앱, 작업 내용을 동일하게 맞추고 유휴 상태와 부하 상태를 각각 확인하세요. 유휴 테스트에서는 비정상적인 재연결, 잦은 탐색 요청, 백그라운드 로그를 살펴봅니다. 부하 테스트에서는 같은 다운로드, 통화, 웹 사용 작업을 수행하며 리소스 비용을 비교합니다. 시스템 배터리 통계는 보통 앱별로 집계하지만 네트워크 확장이나 시스템 서비스의 일부 비용은 나뉘어 표시될 수 있습니다. 총 배터리 소모량과 기기 온도를 함께 살펴보세요. 기기가 이미 과열되어 성능이 제한된 상태라면 이후 결과를 차가운 기기에서 얻은 값과 직접 비교하기 어렵습니다. 상태가 회복된 뒤 다시 측정하는 편이 좋습니다.

TUN, MTU, 연결 유지 설정의 조정 범위

TUN은 트래픽을 가로채는 범위를 넓히며 라우팅, DNS, 네트워크 스택 처리 과정도 추가합니다. 활성화 후 배터리 소모가 늘어났다고 해서 곧바로 노드 프로토콜의 효율이 낮다고 단정하지 마세요. 이전에는 프록시를 거치지 않던 백그라운드 앱까지 이제는 프록시를 통과할 수 있습니다. 먼저 연결 목록에서 트래픽이 발생한 앱을 확인한 뒤 분류 규칙을 조정할지 판단하세요. MTU가 맞지 않으면 특히 경로에서 패킷 크기 정보를 제대로 전달하지 못할 때 일부 요청이 멈출 수 있습니다. 반대로 MTU를 지나치게 낮추면 패킷 분할과 처리 횟수가 늘어납니다. 관련 증상을 확인한 뒤에만 클라이언트와 코어 문서에 따라 통제된 방식으로 조정하세요.

연결 유지 설정은 세션이나 네트워크 매핑을 유지하기 위한 것이지, 주기를 짧게 할수록 안정적인 것은 아닙니다. 주기가 너무 짧으면 패킷이 불필요하게 늘고, 너무 길면 일부 네트워크에서 유휴 연결이 끊어질 수 있습니다. 적절한 간격은 프로토콜 구현, 네트워크, 사용 방식에 따라 달라집니다. 처음에는 클라이언트 기본값을 사용하고 유휴 상태에서 재현되는 연결 끊김이 있을 때 하나씩 조정하세요. 기록할 것은 ‘최적 설정값’ 하나가 아니라 네트워크 조건, 작업, 변경값, 결과입니다. 이 기록은 다른 기기에서 매개변수를 그대로 복사하는 것보다 유용합니다.

6. 오리지널 Clash, Meta, mihomo의 계열 관계

이름의 변천이 기능의 완전한 동일성을 뜻하지는 않습니다

오리지널 Clash는 YAML로 프록시, 정책 그룹, 규칙을 설정하는 일반적인 사용 방식을 정립했습니다. Clash Meta는 관련 프로젝트를 바탕으로 기능을 확장한 포크이며, mihomo는 이 계열의 개발을 이어갑니다. 기존 자료에는 여전히 Meta라는 이름이 많이 사용되고 클라이언트 이름에도 이전 명칭이 남아 있을 수 있습니다. 관계를 파악할 때는 소프트웨어 아이콘이나 제목만 보지 말고 실제 실행 중인 코어를 확인하세요. 클라이언트 이름에 Clash가 있다고 해서 오리지널 코어를 사용하는 것은 아닙니다. 인터페이스에 Meta라고 표시되어도 실행 정보에서 구체적인 구현과 기능 범위를 확인해야 할 수 있습니다.

오리지널 버전, 과거 Premium 포크, mihomo를 기능별로 완전히 포함하는 관계로 단순화해서는 안 됩니다. 과거 포크마다 규칙 집합, TUN 등 기능 구현에 차이가 있었으므로 이전할 때는 새 코어가 파일을 읽을 수 있는지만 판단하지 말고 필드의 의미도 비교해야 합니다. mihomo는 프로토콜, DNS, 스니핑, 규칙 기능을 확장했지만 구현이 발전하면서 새 필드가 변경될 수도 있습니다. 이 문서에서는 특정 버전의 지원 매트릭스를 고정해 다루지 않습니다. 경계선에 있는 옵션은 현재 코어 문서, 시작 로그, 설정 검사 결과를 함께 확인하세요.

설정 호환성은 세 단계로 확인합니다

첫 번째는 구문 호환성입니다. 파일을 파싱할 수 있는지 확인합니다. 들여쓰기, 콜론, 목록 구조가 틀리면 YAML 자체가 올바르지 않습니다. 두 번째는 필드 호환성으로 코어가 특정 키와 값을 인식하는지 확인합니다. 세 번째는 동작 호환성입니다. 기본값, 매칭 순서, 네트워크 스택 구현이 달라진 뒤에도 같은 설정이 예상대로 작동하는지 살펴봅니다. 시작에 성공했다는 사실은 일부 검사만 통과했다는 뜻이지 모든 동작이 검증되었다는 의미는 아닙니다. 구현마다 알 수 없는 필드를 거부하거나 무시할 수 있으므로 오류가 없다는 사실만으로 설정이 완전히 이전되었다고 판단하지 마세요.

정책 그룹과 규칙에서 이름을 참조하는 부분도 자주 누락됩니다. 변환 도구가 노드 이름을 바꿨는데 정책 그룹은 이전 이름을 참조하거나, 규칙이 존재하지 않는 정책을 가리키면 로드가 실패하거나 잘못된 선택이 이루어질 수 있습니다. rule-providers와 proxy-providers는 각각 규칙 출처와 프록시 출처를 관리하므로 서로 바꿔 쓸 수 없습니다. 서버가 새 프로토콜을 제공해도 해당 코어가 이를 구현해야 사용할 수 있습니다. GUI만 업데이트하고 이전 사용자 지정 코어를 계속 사용하면 새 프로토콜이 자동으로 추가되지 않습니다. 클라이언트가 실제로 실행하는 실행 파일과 실행 정보를 확인하세요.

# core-check.yaml로 저장하세요. 기본 필드와 규칙 구조 확인용
mixed-port: 7897
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

이 최소 설정은 수신 포트와 직접 연결 규칙만 확인합니다. 프록시 노드가 포함되어 있지 않으므로 어떤 프록시 프로토콜도 검증하지 않습니다. 독립형 mihomo 명령줄 프로그램이 설치된 환경에서는 mihomo -t -f core-check.yaml로 설정을 검사할 수 있습니다. 명령 이름과 경로는 로컬 설치 방식에 따라 다릅니다. 전체 설정을 검사하기 전에 복사본을 사용하고 원본 파일을 보관하세요. 전체 파일이 외부 규칙, 프록시 공급자, 데이터 파일에 의존한다면 네트워크 연결, 파일 경로, 해당 리소스도 사용할 수 있는지 확인해야 합니다. 정적 검사는 실제 실행 테스트를 대신할 수 없습니다.

클라이언트에서 설정하는 항목도 유지해야 합니다

Clash Verge Rev, FlClash, Clash Nyanpasu 등의 클라이언트는 오버라이드, 병합, 인터페이스 설정을 통해 최종 설정을 생성할 수 있습니다. 따라서 구독 원본과 코어가 실제로 실행하는 설정은 다를 수 있으며, 임시 파일을 직접 수정하면 업데이트나 재시작 후 변경 사항이 사라집니다. 클라이언트가 제공하는 지속성 오버라이드 기능을 사용하고 최종 설정의 관련 부분을 확인하세요. 서비스 모드, 시스템 프록시, 시작 시 자동 실행도 클라이언트와 시스템 연동에 속합니다. YAML을 복사해도 이러한 상태는 자동으로 이전되지 않습니다. 이전 후 권한, 수신 포트, 트래픽 가로채기 방식도 다시 확인해야 합니다.

설정 차이를 더 자세히 알아보려면 오리지널 Clash·Meta·mihomo 버전별 차이 비교를 참고하세요. 규칙 집합과 스니핑에 관한 별도 설명은 mihomo 코어 기능 안내에서 확인할 수 있습니다. 두 자료는 필드의 배경을 이해하는 데 도움이 되며, 실제 이전 시에는 현재 설정을 항목별로 검증해야 합니다.

7. 구독 형식, 필드 매핑, 업데이트 호환성

구독 주소는 접속 경로이지 형식 이름이 아닙니다

구독은 보통 URL을 통해 설정을 가져오지만 URL만으로 어떤 콘텐츠가 반환되는지는 알 수 없습니다. 서버는 전체 Clash YAML, 노드만 포함된 YAML, 인코딩된 공유 링크 모음, 다른 클라이언트용 설정을 반환할 수 있습니다. 일부 주소는 요청 매개변수나 클라이언트 식별 정보에 따라 다른 내용을 제공하기도 합니다. 따라서 브라우저에서 구독 주소가 열린다는 것은 응답을 받았다는 뜻일 뿐 현재 클라이언트에 적합하다는 의미는 아닙니다. 가져오기 전에 서비스 제공자가 표시한 형식을 확인하고 클라이언트에서 명시적으로 지원하는 가져오기 방식을 사용하세요. 파일 확장자만 보고 추측하지 마세요.

전체 Clash 설정에는 proxies, proxy-groups, rules, DNS 설정이 포함될 수 있습니다. 프록시 공급자 파일은 보통 노드 목록 등 제한된 역할만 하므로 전체 설정을 대신할 수 없습니다. 반대로 전체 설정을 프록시 공급자로 불러오면 구조가 맞지 않아 실패할 수 있습니다. 가져오기 화면에 ‘설정 구독’과 ‘프록시 공급자’가 따로 있다면 콘텐츠에 맞는 항목을 선택하세요. 업데이트가 끝나면 파일 크기만 바뀌었는지 확인하는 데 그치지 말고 정책 그룹에 사용 가능한 노드가 있는지, 규칙 참조가 유효한지도 확인해야 합니다.

공유 링크를 변환할 때 설정 의미가 누락될 수 있습니다

SS, VMess, Trojan, VLESS 등의 공유 링크는 각각 인코딩 방식과 매개변수 규칙이 다르며, 도구마다 확장 매개변수 지원 범위도 같지 않습니다. 변환기가 주소와 인증 정보는 추출해도 전송 경로, SNI, ALPN, 흐름 제어, 플러그인 매개변수, QUIC 관련 설정을 누락할 수 있습니다. 필드 이름이 비슷해도 허용되는 값 형식은 다를 수 있습니다. 변환 후에는 원래 서버 안내와 항목별로 비교하세요. 노드가 목록에 표시된다는 사실만으로 변환이 올바르다고 판단하지 마세요. 복잡한 프로토콜 조합에는 서비스 제공자가 지원하는 대상 클라이언트용 형식을 우선 사용하세요.

프로토콜 유형의 대소문자, 하이픈, 별칭도 대상 코어 규격에 맞춰야 합니다. 다른 생태계의 유형 이름을 YAML에 그대로 옮겨서는 안 됩니다. 파일을 억지로 불러오려고 알 수 없는 필드를 삭제해서도 안 됩니다. 삭제한 필드가 연결에 필요한 조건일 수 있습니다. 현재 클라이언트에서 특정 필드를 설정할 방법이 없다면 먼저 코어 지원 여부를 확인한 뒤 사용자 지정 설정을 사용할지, 호환되는 서버 설정을 선택할지 결정하세요. 웹에서 변환한 결과에는 민감한 인증 정보가 포함될 수 있으므로 저장하거나 공유할 때도 구독 자체와 같은 수준으로 보호해야 합니다.

업데이트 후 최종 설정 확인

구독을 업데이트하면 노드 이름, 그룹, 규칙이 달라지거나 직접 입력한 매개변수가 덮어써질 수 있습니다. 개인 규칙과 로컬 포트 등의 설정은 클라이언트에서 지원하는 지속성 오버라이드 계층에 두고 병합 순서를 분명히 하세요. 업데이트 후 정책 그룹이 갑자기 다른 노드로 돌아갔다면 노드 이름이 바뀌어 기존 선택이 무효화되었는지 먼저 확인하세요. 특정 사이트에서만 동작이 바뀌었다면 규칙과 DNS가 교체되었는지 살펴보세요. 차이를 확인하기 전에 업데이트를 반복해서 누르지 마세요. 재현 가능한 기존 상태를 보존하기 어려워지고 원격 변경과 로컬 설정 문제를 구분하기도 힘들어집니다.

구독 주소에는 접속 인증 정보가 포함되는 경우가 많으므로 스크린샷, 공개 로그, 온라인 변환 양식에 넣지 마세요. 다른 사람의 도움을 받을 때는 전체 URL, UUID, 비밀번호 및 기타 인증 필드를 먼저 삭제하고 유형, 필드 이름, 오류가 발생한 단계만 공유하세요. 클라이언트에서 구독 업데이트가 실패하면 네트워크 연결, HTTP 응답, 콘텐츠 형식, 설정 파싱 순서로 원인을 확인하세요. 연결 시간 초과와 YAML 파싱 오류는 서로 다른 문제입니다. 새 설정이 작동하는지 확인한 뒤 이전 복사본을 삭제하고, 다음 업데이트에 문제가 생겼을 때 빠르게 되돌릴 수 있도록 정상 작동이 확인된 설정 하나를 보관하세요.

8. 사용 환경에 맞는 프로토콜 선택과 체계적인 문제 해결

데스크톱·모바일·라우터 환경별 선택 기준

데스크톱에서 웹을 탐색하고 업무를 볼 때는 클라이언트 관리 기능, 규칙의 명확성, 기존 서비스의 안정성을 우선 고려하세요. Clash Plus를 첫 번째 선택지로 살펴본 뒤 운영체제 연동과 설정 요구사항에 따라 Clash Verge Rev, FlClash, Windows용 Clash Nyanpasu를 비교할 수 있습니다. 기존 SS, VMess, Trojan 서비스가 필요한 기능을 제공한다면 계속 사용해도 됩니다. 프로토콜 이름을 업그레이드하려고 이전 비용을 늘릴 필요는 없습니다. 특정 VLESS 조합이 필요하다면 인터페이스 사용 편의성을 따지기 전에 클라이언트의 실제 코어가 해당 조합을 지원하는지 확인하세요.

Android에서는 Clash Plus, Clash Meta for Android, FlClash, Surfboard 가운데 실제 설정 요구사항에 맞는 앱을 선택할 수 있습니다. 다만 각 클라이언트가 같은 코어와 필드 지원 범위를 갖췄다고 가정해서는 안 됩니다. iOS에서는 Clash Plus의 스토어 설명과 설정 기능을 먼저 확인하세요. 공식 웹사이트는 clashplus.io입니다. 휴대폰은 Wi-Fi와 셀룰러 네트워크를 자주 전환하므로 네트워크 변경 후 연결 복구, 백그라운드 안정성, 배터리 소모를 확인하세요. QUIC에 연결 마이그레이션 관련 기능이 있더라도 모든 클라이언트, 서버, 운영체제의 백그라운드 조건에서 서비스가 끊기지 않는다는 뜻은 아닙니다.

Linux 데스크톱에서는 Clash Verge Rev와 FlClash를 비교해 볼 수 있습니다. 서버나 라우터 기기에서는 mihomo 코어, 서비스 관리, 네트워크 라우팅을 별도로 평가해야 합니다. 저전력 기기라면 프로토콜 지원 목록만 볼 것이 아니라 프로세서 아키텍처, 암호화 비용, 메모리, 지속 처리량을 확인하세요. Clash for Windows와 ClashX Meta는 유지 관리가 종료된 보관용 선택지입니다. 기존 환경을 이전할 때 참고할 수 있지만 새로 설치할 때는 지속적인 유지 관리와 호환성을 우선해야 합니다. 설치 파일과 플랫폼 요구사항은 Clash 다운로드 페이지에서, 클라이언트별 특징은 클라이언트 비교에서 확인하세요.

실시간 서비스와 대용량 파일에는 서로 다른 기준이 필요합니다

음성 통화, 게임, 대화형 앱에서는 지터, 패킷 손실, 순간적인 멈춤을 우선 확인하세요. 노드와 서버가 해당 서비스에 필요한 UDP를 지원하는지 먼저 살펴본 뒤 실제 사용 경험을 비교합니다. 속도 측정이 된다고 해서 서비스 포트와 전달 경로까지 정상이라는 뜻은 아닙니다. 대용량 파일을 다운로드할 때는 안정적인 처리량, 기기 온도, 다른 앱에 미치는 영향을 확인하세요. UDP 경로가 적절하다면 Hysteria2나 TUIC을 후보로 고려할 수 있지만, 이미 작동이 확인된 TCP 계열 설정과 비교해야 합니다. 업무용 웹 탐색에서는 실패율과 첫 응답이 더 중요합니다. 일상적인 안정성을 희생하면서까지 순간 최고 속도를 추구할 필요는 없습니다.

프로토콜 이름을 추측하지 말고 오류가 발생한 단계를 확인하세요

첫 단계는 문제 범위를 정하는 것입니다. 모든 노드가 실패한다면 구독, 시스템 네트워크, 포트 점유, 트래픽 가로채기 상태를 확인하세요. 특정 프로토콜만 실패한다면 해당 전송 방식과 인증을 점검하고, 특정 도메인에서만 문제가 생긴다면 규칙, DNS, 대상 서비스를 확인하세요. 다음으로 오류가 발생한 단계를 구분합니다. DNS 조회 실패는 DNS부터, 연결 시간 초과는 주소와 경로부터, TLS 오류는 시간·이름·인증서부터, 인증 실패는 인증 정보를 확인하세요. 로그 확인 방법은 Clash에서 자주 발생하는 로그 오류 해결을 참고하세요. 서로 다른 단계의 문제를 모두 노드 사용 불가로 뭉뚱그리지 마세요.

세 번째 단계는 변경을 최소화해 다시 테스트하는 것입니다. 명확한 아웃바운드 정책을 임시로 선택해 대상 요청이 예상한 노드를 거치는지 확인한 뒤 웹과 필요한 실시간 앱을 각각 시험하세요. DNS를 바꿨다면 Fake-IP 매핑 및 호환성 안내를, 분류 순서를 바꿨다면 도메인 및 GeoIP 규칙 활용을 참고하세요. DNS, TUN, MTU, 프로토콜을 한꺼번에 변경하지 마세요. 연결이 복구되어도 원인을 알 수 없고 장기적으로 유지할 설정을 만들기도 어려워집니다.

최종 선택은 세 가지 질문에 답할 수 있어야 합니다. 서버가 지원하는가, 현재 클라이언트가 완전하게 구현하는가, 실제 작업에서 안정적인 결과를 얻는가. 모든 환경에 공통으로 적용되는 최상의 프로토콜은 없으며 모든 네트워크에 맞는 고정 설정값도 없습니다. 이 세 가지를 확인했다면 목적 없는 설정 조정을 멈춰도 됩니다. 처음 사용하면서 조작 방법이 궁금하다면 빠른 시작 가이드로 돌아가 가져오기, 모드, 연결, 확인 순서대로 살펴보세요.