Clash 프로토콜과 커널 참고서

제1장 · 먼저 확인하세요: 이 페이지 활용법과 튜토리얼 페이지와의 역할 구분

사이트 안에는 두 갈래의 콘텐츠가 있으니 먼저 구분해 두세요. 튜토리얼 페이지는 실전 위주입니다. 클라이언트 설치, 구독 가져오기, 모드 선택, 분산 라우팅 확인까지 그대로 따라 하면 바로 사용할 수 있으며 프로토콜의 세부 원리를 이해할 필요는 없습니다. 이 페이지는 또 다른 축으로, 체계적으로 정리한 참고 문서입니다. "왜 그런가"와 "무엇을 선택해야 하는가"에 답합니다. 구독 노드 목록에 나열된 프로토콜 종류가 각각 어떤 배경을 가졌는지, 접속 속도 차이가 어느 단계에서 발생하는지, 모바일에서는 어떤 프로토콜이 더 절전인지, 여러 커널 사이의 관계가 정확히 무엇인지 다룹니다. 두 페이지는 서로 보완적입니다. 처음 설정할 때는 튜토리얼 페이지로 먼저 실전을 마치고, 설정이 정상 작동한 뒤 노드 목록의 옵션들을 제대로 이해하고 싶을 때 다시 이곳으로 돌아와 장별로 참고하세요.

이 페이지는 알파벳순이 아니라 "선택 의사결정" 흐름에 따라 구성되어 있습니다. 2장과 3장은 프로토콜 자체를 다룹니다. 먼저 클래식 삼종인 Shadowsocks, VMess, Trojan의 등장 배경과 설계 방향을 살펴보고, 이어서 차세대 프로토콜인 VLESS, Hysteria2, TUIC가 각각 어떤 기존 문제를 해결했는지 설명합니다. 4장과 5장은 가로 비교입니다. 접속 속도, 처리량 한계, CPU와 메모리 사용량, 그리고 모바일에서 가장 궁금한 배터리 소모까지 다룹니다. 6장과 7장은 이를 구현하는 소프트웨어 계층으로 넘어갑니다. 커널 계열 관계와 설정 호환성, 그리고 구독 형식이 왜 "이 클라이언트에서는 되는데 다른 클라이언트에서는 오류가 나는지"를 설명합니다. 8장에서는 앞선 모든 결론을 상황별로 바로 찾아볼 수 있는 선택 가이드 표로 정리합니다.

읽는 방식은 독자 유형에 따라 세 가지로 나눌 수 있습니다. Clash를 처음 접하는 분이라면 2장부터 4장까지 순서대로 읽어 "프로토콜은 전송 방식, 커널은 실행 엔진, 클라이언트는 조작 화면"이라는 3단계 개념을 잡아두세요. 이후 모든 결론이 이 틀 위에 놓입니다. 이미 사용 중이지만 "특정 노드가 연결되지 않는다", "특정 프로토콜이 유난히 배터리를 많이 먹는다" 같은 구체적 문제를 겪는 분은 5장과 7장으로 바로 넘어가고, 문제 해결의 해당 항목도 함께 참고하세요. 가족이나 지인을 위해 클라이언트를 골라주는 것이 목적이고 깊이 파고들 생각이 없다면 6장의 커널 비교표와 8장의 상황별 가이드만 보면 충분하며, 10분이면 끝납니다.

용어 정의를 먼저 짚어두겠습니다. 이 페이지에서 "프로토콜"은 노드의 전송 프로토콜 종류, 즉 설정 파일 proxies 항목의 type 필드 값을 가리킵니다. "커널"은 실제로 트래픽을 처리하는 핵심 프로그램을 뜻하고, "클라이언트"는 그래픽 인터페이스를 갖춘 소프트웨어 껍데기를 뜻합니다. 개별 용어의 전체 설명은 용어 사전에, 구체적인 문제 해결 절차는 문제 해결에 정리되어 있으니 이 페이지에서는 중복 설명하지 않습니다. 낯선 용어가 나오면 그때그때 찾아보세요.

경계도 하나 명확히 해두겠습니다. 이 페이지는 오직 기술적 선택—핸드셰이크 횟수, 암호화 부하, 배터리, 호환성—만 다루며 어떤 서비스 제공자도 평가하지 않고 노드의 출처도 다루지 않습니다. 노드가 어떤 프로토콜을 쓰는지는 구독 제공자가 정하는 부분이고, 사용자가 실제로 할 수 있는 선택은 두 가지입니다. 하나는 자신의 구독 내용을 모두 처리할 수 있는 커널을 갖춘 클라이언트 조합을 고르는 것, 다른 하나는 구독에 여러 프로토콜의 노드가 섞여 있을 때 어떤 상황에서 어떤 종류로 정책 그룹을 전환할지 아는 것입니다. 이 페이지의 모든 조언은 이 두 가지 선택 지점에서 출발합니다.

제2장 · 클래식 삼종: Shadowsocks, VMess, Trojan의 유래와 설계 방향

먼저 세 가지 "오래된 강자"를 살펴보겠습니다. 등장 시기가 빠르고 배포 범위가 넓어 거의 모든 커널이 지원하며, 구독에서 가장 흔히 볼 수 있는 종류입니다. 각각의 설계 출발점을 이해해야 이후 새로운 프로토콜을 볼 때 "무엇이 새로워졌는지" 파악할 수 있습니다.

Shadowsocks: 일을 최소화한 모범 사례

Shadowsocks(설정에서는 ss로 표기)는 셋 중 가장 먼저 완성된 방식으로, "최소화"라는 설계 철학을 따릅니다. 클라이언트와 서버가 사전 공유 키를 합의하고, 트래픽을 대칭 암호화 알고리즘으로 곧바로 캡슐화해 전달할 뿐 별도의 세션 협상이나 복잡한 메타데이터 구조가 없습니다. 현재 구현체들은 대부분 AEAD 계열 암호화 스위트(예: aes-128-gcm, chacha20-ietf-poly1305)를 사용해 암호화와 무결성 검증을 동시에 처리합니다. 이렇게 최소화된 구조는 곧바로 속도와 효율로 이어집니다. 접속 과정에서 프로토콜 차원의 추가 왕복이 거의 없고, 현대 CPU에서는 암복호화 부하를 무시할 수 있을 정도이며, 라즈베리파이급 저사양 라우터에서도 원활히 동작합니다. 대가도 분명합니다. 전송 계층 멀티플렉싱을 지원하지 않아 연결마다 독립적으로 동작하고, 확장 가능한 기능이 적어 새로운 기능을 추가하려면 외부에 플러그인 형태로 붙여야 합니다. 한마디로 정리하면: 가볍고 빠르며 구형 기기에 가장 친화적인, "일단 되면 충분하다"는 상황의 안전한 선택입니다.

VMess: 생태계와 맞바꾼 필드, 필드가 낳은 부담

VMess는 V2Ray 생태계에서 나온 프로토콜로, Shadowsocks와 정반대 방향을 택했습니다. 즉 "모든 것을 담자"는 방식입니다. 자체 사용자 ID 체계, 내장 암호화, 자유롭게 조합할 수 있는 전송 계층(순수 TCP, WebSocket, HTTP/2 등 모두 사용 가능)을 갖추고 있어 다양한 필드를 통해 서버 측에서 세밀한 사용자 및 라우팅 관리를 할 수 있습니다. 하지만 필드가 많다는 것은 부담도 크다는 뜻입니다. VMess의 인증 방식은 클라이언트와 서버 간 타임스탬프 검증에 의존하므로 두 기기의 시스템 시간이 크게 어긋나면 핸드셰이크 자체가 실패합니다. "VMess 노드가 전부 타임아웃되는데 다른 프로토콜은 정상"이라는 대표적인 증상은 대부분 로컬 시간이 정확하지 않아서 발생하며, 해결 절차는 노드 타임아웃 진단 순서 글에 전체 흐름이 정리되어 있습니다. 또한 VMess는 흔히 WebSocket + TLS 조합으로 쓰이는데, 캡슐화 계층이 많아 접속 왕복 횟수와 CPU 부하가 Shadowsocks보다 한 단계 높습니다. 정리하면: 생태계가 성숙하고 설정이 유연하지만 "무거운" 방식에 속하며, 새 배포에서는 점차 VLESS로 대체되는 추세입니다.

Trojan: HTTPS의 성숙한 경로를 그대로 빌려 쓰는 방식

Trojan의 방향성은 또 다릅니다. 자체 암호화 방식을 만들지 않고 트래픽을 표준 TLS 연결에 그대로 실어 보내며, 서버 동작은 일반적인 HTTPS 웹사이트 서버와 동일합니다. 이 선택의 실질적 이점은 명확합니다. TLS는 인터넷에서 가장 검증된 암호화 채널이라 핸드셰이크 경로가 안정적이고 각종 네트워크 중간 장비와의 호환성이 좋으며 클라이언트 구현도 간단합니다. 대가는 배포 부담이 서버 쪽으로 넘어간다는 점입니다. 유효한 도메인 인증서가 필요하고, 인증서가 만료되거나 도메인 해석에 문제가 생기면 노드 전체가 사용 불가능해지는데, 이런 문제는 클라이언트 쪽에서 해결할 방법이 없고 구독 제공자의 조치를 기다려야 합니다. 사용자 입장에서 Trojan 노드는 대체로 안정적이고 지연 시간이 예측 가능해 웹 브라우징과 영상 시청 같은 용도에 무난한 선택입니다.

제3장 · 차세대 프로토콜: VLESS, Hysteria2, TUIC는 각각 무엇을 해결했나

세 가지 신규 방식은 뜬금없이 등장한 것이 아니라 각각 앞 장에서 다룬 특정 문제를 겨냥해 만들어졌습니다. 살펴볼 때는 한 가지 질문에 집중하세요. 어떤 부분을 프로토콜 계층에서 걷어냈고, 대신 어떤 부분을 더 무겁게 만들었는가.

VLESS: VMess의 체중 감량판

VLESS는 VMess의 감산 버전이라고 이해하면 됩니다. 내장 암호화와 타임스탬프 검증을 제거하고 기밀성을 완전히 외부 TLS에 맡겨, 프로토콜 자체는 최소한의 사용자 식별과 라우팅 정보만 유지합니다. 암호화 캡슐화 계층이 한 단계 줄어든 만큼 CPU 부하가 크게 낮아지고, 시간 차이로 인한 핸드셰이크 실패도 더 이상 발생하지 않습니다. VMess 사용자를 가장 골치 아프게 했던 두 가지 문제가 한 번에 해결된 셈입니다. VLESS는 흔히 새로운 방식의 전송 계층—예를 들어 TLS 세션 특성을 최적화한 전송 방식—과 조합되어 쓰이는데, 이런 조합의 가용성은 커널 버전에 따라 달라지며 7장에서 구독 호환성을 다룰 때 자세히 설명합니다. 선택 시 기억할 원칙 하나: 같은 구독에 VMess와 VLESS 노드가 모두 있고 클라이언트 커널이 지원한다면, VLESS를 우선하는 편이 거의 손해 볼 일 없는 선택입니다.

Hysteria2: 열악한 네트워크 환경을 위해 만들어진 QUIC 기반 프로토콜

Hysteria2(설정에서는 hysteria2로 표기)는 아예 기반 자체를 바꿨습니다. TCP가 아니라 QUIC(UDP 위에서 동작하는 현대적 전송 프로토콜) 위에 구축되었고, 여기에 공격적인 자체 혼잡 제어 전략을 결합했습니다. 이 조합이 겨냥하는 상황은 뚜렷합니다. 패킷 손실과 지터가 큰 네트워크, 예를 들어 모바일 네트워크나 이동통신사 간 장거리 연결입니다. 기존 TCP는 패킷 손실이 발생하면 크게 속도를 줄이면서 급격히 느려지지만, Hysteria2는 미리 설정한 대역폭을 계속 밀어붙이고 손실분은 보충하는 전략을 씁니다. 그 결과 열악한 네트워크에서는 처리량이 TCP 계열 프로토콜보다 눈에 띄게 나은 경우가 많습니다. 대가는 두 가지입니다. 첫째, 지속적인 대역폭 추정과 재전송 로직 때문에 "좋은 네트워크"에서는 오히려 이점이 없고 리소스를 더 소모합니다. 둘째, UDP 기반이라 일부 네트워크 환경에서 UDP 트래픽을 제한하거나 방해하면 오히려 TCP 계열보다 성능이 떨어질 수 있습니다. 정리하면: 열악한 네트워크의 강자, 좋은 네트워크에서는 평범.

TUIC: QUIC의 멀티플렉싱을 최대한 활용

TUIC도 QUIC 위에 구축되지만 초점이 다릅니다. QUIC의 네이티브 멀티플렉싱과 0-RTT 세션 복원을 적극 활용합니다. 여러 프록시 요청이 하나의 QUIC 연결 안에서 서로 막힘없이 동작하고, 한 번 접속한 적 있는 서버라면 거의 왕복 없이 세션을 복원할 수 있어 두 번째 접속은 거의 즉시 이루어집니다. 빈도가 높고 요청이 작은 상황(웹 브라우징, 메신저)에서는 체감 개선이 뚜렷합니다. Hysteria2와 비교하면 TUIC의 혼잡 제어는 일반적인 구현에 더 가까워 공격적으로 대역폭을 선점하지 않으며 지속 부하도 더 온화한 편입니다. 마찬가지로 UDP를 사용하므로 Hysteria2와 동일한 환경 의존성을 가집니다. 네트워크가 UDP에 우호적이지 않으면 성능이 떨어질 수 있습니다.

제4장 · 접속 속도와 리소스 사용량: 첫 데이터는 핸드셰이크 횟수로 결정된다

"어떤 프로토콜이 빠른가"는 가장 많이 묻지만 오해하기도 쉬운 질문입니다. 먼저 "빠르다"를 두 부분으로 나눠야 합니다. 접속 속도(링크를 눌러 콘텐츠가 로드되기 시작하는 짧은 순간)와 지속 처리량(대용량 파일 다운로드, 고비트레이트 영상 시청 시의 안정적인 속도)입니다. 두 가지를 결정하는 요인이 전혀 다르므로 선택할 때는 구분해서 봐야 합니다.

접속 속도: 왕복 횟수를 세어보자

접속 속도는 대체로 "클라이언트와 서버 사이에 몇 번을 주고받는가"로 결정되며, 한 번의 왕복마다 하나의 RTT(왕복 지연 시간)가 소모됩니다. 대략적으로 세어보면: Shadowsocks는 TCP를 사용하므로 TCP 핸드셰이크 한 번이면 바로 데이터를 보낼 수 있습니다. Trojan과 VLESS는 TCP 위에 TLS 핸드셰이크가 한 번 더 필요해 왕복이 한 번 늘어납니다. VMess가 WebSocket+TLS 조합이라면 업그레이드 핸드셰이크가 한 층 더 추가되어 왕복 횟수가 가장 많습니다. QUIC 계열인 Hysteria2와 TUIC는 전송 핸드셰이크와 암호화 핸드셰이크를 하나의 교환으로 합쳐 첫 연결도 한 번의 왕복으로 끝납니다. TUIC의 0-RTT 복원은 한 걸음 더 나아가 이전에 연결했던 서버로 재접속할 때는 거의 왕복이 필요 없습니다. 물리적 지연 자체가 큰 경우(예: 대륙 간 연결로 RTT가 200ms 이상), 이 왕복 횟수 차이는 체감 차이로 크게 확대됩니다. 같은 구독 안에서 QUIC 계열 노드는 "누르면 바로" 뜨고 TCP 계열 노드는 "한 박자 멈췄다가" 시작하는 경우, 대부분 이 원인입니다.

지속 처리량: 병목은 보통 암호화가 아니다

지속 전송 단계에서는 현대 CPU가 AEAD 암복호화를 처리하는 속도가 가정용 대역폭을 훨씬 앞서기 때문에 암호화 자체가 병목이 되는 경우는 드뭅니다. 실제로 차이를 만드는 것은 전송 계층이 패킷 손실에 반응하는 방식입니다. TCP 계열 프로토콜(SS, VMess, Trojan, VLESS)은 운영체제 TCP 스택의 혼잡 제어에 좌우되어 패킷이 손실되면 즉시 속도가 떨어집니다. Hysteria2는 자체 전략으로 억지로 밀어붙여 열악한 네트워크에서 처리량이 앞서고, TUIC는 그 중간쯑에 위치합니다. 따라서 결론은 다소 직관에 반합니다. 네트워크 품질이 좋을 때는 여섯 프로토콜 간 처리량 차이가 크지 않고, 네트워크 품질이 나쁠 때 차이는 주로 프로토콜 자체보다 전송 계층에서 나옵니다.

메모리와 CPU: 참고용 정성적 비교

리소스 사용량은 정성적인 순서로 참고하면 됩니다. CPU 부하는 낮은 순부터 대략 SS ≈ VLESS < Trojan < TUIC < VMess ≈ Hysteria2 순입니다. VMess는 다층 캡슐화 때문에, Hysteria2는 지속적인 대역폭 탐지 때문에 부하가 높습니다. 메모리 차이는 프로토콜 자체보다 연결 수에서 주로 발생합니다. QUIC 계열 프로토콜은 하나의 연결에 여러 요청을 실어 보내 전체 연결 수가 적어 메모리 면에서 오히려 유리하고, 메모리가 MB 단위인 라우터 같은 기기에서는 SS의 극단적으로 단순한 구현이 여전히 유일하게 안전한 선택입니다.

제5장 · 모바일 배터리 소모: 소모의 세 가지 원인, 프로토콜은 그중 하나일 뿐

"Clash를 켜면 휴대폰 배터리가 빨리 닳는다"는 모바일에서 가장 흔한 불만입니다. 먼저 원인을 명확히 나눠보겠습니다. 배터리 소모는 세 계층에서 발생합니다. 프로토콜 자체의 연결 유지 동작, 클라이언트의 상태 확인 정책, 시스템 차원의 상주 방식입니다. 세 계층은 각각 독립적이므로 하나씩 짚어야 프로토콜에 억울한 누명을 씌우지 않습니다.

프로토콜 계층: UDP 연결 유지가 눈에 안 보이는 배터리 킬러

QUIC 계열 프로토콜(Hysteria2, TUIC)은 UDP 세션을 유지하기 위해 주기적으로 연결 유지 패킷을 보내야 하며, Hysteria2의 대역폭 탐지 로직은 연결이 활성 상태일 때도 계속 동작합니다. 패킷을 보낼 때마다 모바일 기기의 무선 모듈이 잠깐 깨어나는데, 이 무선 모듈 깨우기가 바로 모바일 배터리 소모의 주범입니다. TCP 계열 프로토콜(SS, Trojan, VLESS)은 트래픽이 없을 때 오랫동안 조용히 대기할 수 있어 시스템이 더 깊은 절전 상태로 들어갈 수 있습니다. 그러므로 배터리를 우선할 때의 결론은 4장의 결론과 정확히 상호 보완적입니다. 전원이 연결된 상태나 Wi-Fi 환경에서는 QUIC 계열을 마음 놓고 쓰고, 배터리로만 동작하는 모바일 네트워크 환경에서는 TCP 계열의 경량 프로토콜을 우선하세요.

클라이언트 계층: 상태 확인 간격 조정이 가장 손쉬운 개선 포인트

url-test 계열 정책 그룹은 interval 주기로 그룹 내 모든 노드에 속도 테스트를 실행합니다. 간격을 너무 짧게 설정하면(예: 60초) 휴대폰이 매분마다 수십 개 노드를 차례로 깨워 테스트하는 셈이 됩니다. 모바일에서는 간격을 600초 이상으로 늘려도 체감 지연 차이는 거의 없고 배터리 개선 효과는 바로 나타납니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 600        # 모바일에서는 600초 이상 권장
    tolerance: 80        # 신규/기존 노드 지연 차이가 80ms 미만이면 전환하지 않음
    proxies: [노드A, 노드B]

tolerance도 함께 설정할 필요가 있습니다. 이 값이 없으면 지연 시간이 비슷한 두 노드가 계속 반복해서 전환되고, 전환할 때마다 새 연결이 한 번씩 생성됩니다. 구독이 제공자 측에서 관리되어 설정을 직접 수정할 수 없다면 클라이언트 화면에서 자동 테스트 그룹을 select 방식의 고정 노드로 바꾸는 것도 같은 효과를 냅니다.

시스템 계층: TUN 상주와 제조사별 백그라운드 정책

TUN 모드는 가상 네트워크 카드를 만들어 트래픽을 전량 처리하므로 프로세스가 항상 상주해야 하는데, 안드로이드 각 제조사의 백그라운드 제한 정책은 이를 반복적으로 종료하고 다시 실행시키며, 이 종료-재실행 과정이 조용히 상주하는 것보다 오히려 배터리를 더 많이 씁니다. TUN과 시스템 프록시의 방식 차이는 TUN 모드와 시스템 프록시의 차이 글에서 단계별로 다룹니다. 안드로이드에서 배터리 통계를 통해 소모 원인을 찾고 하나씩 끄는 전체 체크리스트는 안드로이드 배터리 소모 점검을 참고하세요. 충분히 활용 가능한 원칙 하나: 휴대폰에서 전체 트래픽 처리가 필요 없다면 시스템 프록시 모드를 쓰고, TUN은 데스크톱 환경에 남겨두세요.

제6장 · 커널 계열: 오리지널, Meta, mihomo는 정확히 어떤 관계인가

많은 호환성 문제의 근본 원인은 "Clash"를 하나의 소프트웨어로 착각하는 데 있습니다. 실제로는 하나의 계열입니다. 커널은 설정에 따라 트래픽을 처리하고, 클라이언트는 그 커널을 감싸는 조작 화면일 뿐입니다. 계보를 명확히 이해하면 7장의 호환성 문제도 한눈에 이해됩니다.

계보: 한 번의 분기, 두 개의 이름

최초의 오픈소스 프로젝트는 오리지널 Clash 커널이었고, TUN 등의 기능이 추가된 비공개 소스의 Premium 빌드도 함께 존재했습니다. 오리지널 저장소의 유지보수가 중단된 뒤 커뮤니티가 관리하는 Clash.Meta 브랜치가 개발의 주류를 이어받아 새로운 프로토콜과 규칙 유형을 계속 추가했고, 이후 mihomo로 이름이 바뀌었습니다. 그러니 "Clash.Meta"와 "mihomo"는 같은 혈통의 전후 두 이름이며, 흔히 말하는 "Meta 계열 커널"이 바로 이것을 가리킵니다. 오늘날 활발히 유지보수되며 6종 프로토콜을 모두 지원하는 것은 mihomo 이 계열뿐입니다. 클라이언트를 고를 때 가장 먼저 확인해야 할 것이 바로 어떤 커널이 내장되어 있는지입니다.

기능 차이: 표 하나로 정리

규칙 차원에서 한 가지 덧붙이면: mihomo는 오리지널 커널의 자주 쓰이는 필드(port, mode, DOMAIN-SUFFIX, GEOIP, MATCH 등)를 그대로 하위 호환하므로 기존 설정을 mihomo에 그대로 적용해도 대체로 정상 작동합니다. 반대 방향은 그렇지 않습니다. 설정에 mihomo 전용 문법이 하나라도 있으면 오리지널 커널은 오류를 내며 로드를 거부합니다.

rules:
  - GEOSITE,category-ads-all,REJECT   # mihomo만 인식, 오리지널 커널은 오류 발생
  - GEOIP,CN,DIRECT                   # 두 커널 계열 모두 지원
  - MATCH,수동 선택                    # 두 커널 계열 모두 지원

클라이언트와 커널의 대응 관계

클라이언트 다운로드 페이지의 목록으로 정리하면: Clash Plus(전 플랫폼 최우선 추천), Clash Verge Rev, FlClash, Clash Nyanpasu, Clash Meta for Android는 모두 Meta 계열 기반이라 6종 프로토콜을 모두 사용할 수 있습니다. ClashX Meta도 Meta 계열이지만 유지보수가 종료되었습니다. Clash for Windows는 오리지널 커널 기반이며 유지보수가 종료되어 "구독에 새 프로토콜 노드가 있는데 로드에 실패한다"는 문제의 가장 흔한 원인입니다. 아직 이를 쓰고 있다면 Clash Verge Rev로 이전하는 전체 절차는 Windows에서 Clash Verge Rev 설치 전체 가이드를 참고하세요. 선택 원칙은 한마디로 정리됩니다. 구독에 VLESS, Hysteria2, TUIC 중 하나라도 있으면 클라이언트는 반드시 Meta 계열이어야 하며, 다른 선택지는 없습니다.

제7장 · 구독 형식과 필드 호환성: 클라이언트만 바꿔도 오류가 나는 이유

프로토콜과 커널 사이에는 한 단계가 더 있습니다. 구독입니다. 같은 구독 링크가 A 클라이언트에서는 노드가 모두 보이는데 B 클라이언트에서는 텅 비어 보이는 문제는 거의 이 단계에서 발생합니다. 이 장에서는 구독의 형태와 실패 패턴을 정리합니다.

구독의 두 가지 형태

구독 링크가 반환하는 내용은 두 종류로 나뉩니다. 첫 번째는 완전한 Clash 설정(전체 YAML, proxies, proxy-groups, rules 포함)으로, 클라이언트가 그대로 사용할 수 있고 분산 라우팅 정책은 구독 제공자가 미리 작성해둔 상태입니다. 두 번째는 범용 노드 목록(주로 Base64로 인코딩된 공유 링크 모음)으로, Clash 계열 클라이언트가 직접 사용할 수 없어 구독 변환 서비스를 거쳐 Clash 형식으로 변환해야 합니다. 이 변환 단계는 눈에 잘 안 보이는 변수입니다. 변환 템플릿이 출력 설정에서 어떤 커널 계열 문법을 쓸지 결정하는데, 템플릿이 오래되면 Hysteria2 노드를 조용히 빠뜨리거나 오리지널 커널이 인식하지 못하는 필드를 출력할 수 있습니다. 노드 수가 맞지 않을 때는 먼저 구독 형태를 확인하고 그다음 변환 설정을 점검하는 순서를 지키세요.

필드 호환성: 필드 하나가 설정 전체를 뒤엎는다

YAML 설정은 전체가 한 번에 로드되며, 커널이 인식하지 못하는 노드 type이나 필드를 만나면 구현에 따라 처리 방식이 다릅니다. 관대한 구현은 해당 노드만 건너뛰어 노드 수가 줄어드는 형태로 나타나고, 엄격한 구현은 아예 로드를 거부해 구독 가져오기 실패, 노드 목록 전체 공백으로 나타납니다. Hysteria2 노드 하나를 예로 들면, 그 전용 필드는 오리지널 커널이 하나도 인식하지 못합니다.

proxies:
  - name: 예시-HY2
    type: hysteria2          # 오리지널 커널이 인식하지 못하는 타입
    server: example.com
    port: 443
    password: your-password
    sni: example.com

반대로도 함정이 있습니다. 일부 클라이언트는 가져올 때 설정을 "알아서" 재작성하거나 기본 필드를 채워 넣는데, 이 재작성 로직이 클라이언트마다 달라 같은 구독이라도 클라이언트에 따라 최종 동작이 미묘하게 달라질 수 있습니다. "특정 클라이언트에서만 이상하다"는 상황을 만나면, 구독 링크를 브라우저에서 직접 열어 원본 내용을 확인하는 것이 가장 빠른 진단 방법입니다.

가져오기 실패 시 점검 순서

네 단계를 순서대로 진행하세요. ①구독이 만료되지 않았는지 확인—대부분의 만료된 구독은 오류 대신 빈 내용이나 오류 페이지를 반환합니다. ②클라이언트가 Meta 계열인지 확인(6장의 표 참고). ③구독 변환을 거쳤는지, 변환 템플릿이 구독 내 모든 프로토콜을 지원하는지 확인. ④클라이언트 로그에서 YAML 오류가 발생한 줄 번호를 확인해 구체적인 필드를 찾아냅니다. 앞의 두 단계로 대부분의 문제는 해결됩니다. "노드 목록이 비어 있다", "모든 노드가 타임아웃된다"는 두 가지 흔한 증상은 문제 해결과 노드 타임아웃 진단 글에 각각 완전한 절차가 정리되어 있으니 그대로 따라 하면 됩니다.

제8장 · 상황별 선택 가이드: 한 장으로 정리한 참조표

앞선 7개 장의 결론을 상황별로 바로 찾아볼 수 있는 표로 정리했습니다. 사용법: 먼저 왼쪽 열에서 자신의 주된 사용 상황을 찾고, "우선—대안" 순서로 정책 그룹에서 고정하거나 그룹을 나누세요. 구독에 우선 항목이 없으면 대안으로 넘어가면 되고, 무리하게 맞추지 않아도 됩니다.

표 밖에서도 기억해둘 만한 세 가지 일반 원칙이 있습니다. 첫째, 프로토콜 선택은 언제나 노드 선택 다음입니다. 같은 프로토콜이라도 노드 품질 차이가 같은 노드의 프로토콜 차이보다 큰 경우가 많으니, 먼저 지연 테스트와 실제 다운로드로 노드 풀을 걸러낸 뒤 프로토콜 취향을 논하세요. 둘째, 매번 손으로 고르지 말고 정책 그룹으로 고정하세요. 열악한 네트워크용 QUIC 계열 노드를 한 그룹, 절전용 TCP 계열 노드를 다른 그룹으로 묶어두고 상황에 따라 그룹만 전환하면 수십 개 노드를 일일이 뒤질 필요가 없습니다. 정책 그룹 작성법은 튜토리얼 페이지의 심화 섹션에 단계별로 설명되어 있습니다. 셋째, 주기적으로 재검토하세요. 구독 제공자는 노드의 프로토콜 구성을 계속 조정하고 커널도 꾸준히 발전하고 있습니다. 이 페이지의 정성적 결론은 안정적이지만, 자신이 쓰는 구독의 최적 조합은 몇 달에 한 번씩 다시 확인해볼 만합니다.

선택이 끝났다면 실행할 단계는 두 가지뿐입니다. 클라이언트 다운로드 페이지에서 사용 중인 플랫폼에 맞는 Meta 계열 클라이언트를 받으세요. 전 플랫폼에는 Clash Plus를 최우선으로 추천하며, Windows/macOS/Linux에서는 Clash Verge Rev나 FlClash도 선택할 수 있습니다. 그다음 튜토리얼 페이지로 돌아가 구독 가져오기와 분산 라우팅 확인을 마치세요. 설정 과정에서 막히는 부분이 있다면 문제 해결을 분류별로 찾아보고, 낯선 용어는 용어 사전에서 바로 확인하세요. 이 참고 문서에서 짚어야 할 핵심 포인트는 여기까지입니다.