Clash 프로토콜 및 커널
기술 가이드

1. 연결 계층: 클라이언트, 커널, 프로토콜

클라이언트 화면에 표시되는 노드는 실제로 여러 연결 매개변수를 묶은 항목입니다. 보통 원격 주소와 포트, 인증 정보, 프로토콜 유형, 선택 사항인 전송 및 보안 설정이 포함됩니다. 노드 이름을 클릭하면 프록시 그룹의 현재 출구를 해당 매개변수로 바꿀 뿐, 프로토콜 자체가 바뀌지는 않습니다. 이 관계를 이해하면 ‘노드 변경’, ‘프로토콜 유형 변경’, ‘규칙 모드 전환’을 구분할 수 있습니다. 각각 연결 대상, 연결 방식, 트래픽 처리 기준을 바꾸는 작업이므로 문제 해결 시 혼동하지 마세요.

화면은 조작을 담당하고 커널은 연결을 처리합니다

Clash Plus, Clash Verge Rev, FlClash 등의 클라이언트는 구독 관리, 정책 선택, 시스템 연동 기능을 제공합니다. 설정과 도메인 이름을 해석하고, 규칙을 적용하며, 연결을 수립해 데이터를 전달하는 역할은 커널이 맡습니다. 이름이 비슷한 클라이언트라도 서로 다른 커널 빌드를 사용할 수 있고, 이름이 다른 클라이언트가 같은 계열의 커널을 채택할 수도 있습니다. 따라서 화면에 특정 스위치가 있는지와 커널이 해당 프로토콜을 지원하는지는 별개의 문제입니다. 반대로 커널이 기능을 지원하더라도 클라이언트가 그래픽 설정 화면을 제공한다고 보장할 수는 없습니다.

요청 흐름은 네 단계로 나눠 볼 수 있습니다. 애플리케이션이 트래픽을 로컬 진입점으로 보내면 커널이 규칙에 따라 정책을 선택하고, 프로토콜 구현이 원격 서버와 세션을 수립한 뒤 원격 서버가 목적지 서비스에 접속합니다. 로컬 진입점은 HTTP 프록시, SOCKS 프록시 또는 TUN 가상 네트워크 인터페이스일 수 있습니다. 프록시 프로토콜은 주로 커널과 원격 서버 사이에 적용됩니다. 브라우저가 시스템 프록시를 따르는지, 로컬 DNS·라우팅·권한 문제가 해결되는지를 직접 결정하지는 않습니다. 애플리케이션이 연결되지 않으면 먼저 해당 트래픽이 실제로 커널에 들어오는지 확인하세요.

애플리케이션 트래픽과 하위 전송 계층 구분하기

TCP와 UDP는 애플리케이션이 생성한 트래픽을 가리킬 수도 있고 프록시 프로토콜이 사용하는 하위 전송 방식을 뜻할 수도 있습니다. 서로 다른 문제입니다. 예를 들어 QUIC 기반 프로토콜은 UDP를 전송 계층으로 사용하면서 애플리케이션의 TCP 연결을 프록시할 수 있습니다. UDP 전달을 지원하는 프로토콜도 서버, 클라이언트, 진입점이 모두 조건을 충족해야 합니다. 게임에서 UDP 요청을 사용한다고 해서 반드시 QUIC 프로토콜을 골라야 하는 것은 아닙니다. TUN을 켰다고 모든 원격 서버가 UDP를 허용하는 것도 아닙니다. 선택할 때는 ‘애플리케이션에 필요한 것’과 ‘현재 네트워크에서 허용되는 것’을 따로 확인하세요.

보안 설정은 신뢰 경계와 함께 고려해야 합니다

프록시 연결의 암호화와 목적지 웹사이트의 HTTPS는 서로 다른 계층에 적용됩니다. 프록시 연결 암호화는 로컬 기기와 원격 서버 사이의 데이터 전송을 보호하고, HTTPS는 애플리케이션과 목적지 서비스 사이에 보안 세션을 제공합니다. 프록시를 사용한다고 인증서 검증을 무시해도 되는 것은 아니며, 원격 측에서 모든 정보를 볼 수 없다는 뜻도 아닙니다. 목적지 주소, 연결 시간, 트래픽 특성은 연결에 참여하는 주체가 관찰할 수 있습니다. 구체적인 범위는 프로토콜, DNS 경로, 애플리케이션 자체의 암호화 여부에 따라 달라집니다. 서비스를 선택할 때는 설정 정보의 출처와 원격 운영 주체의 신뢰성도 함께 살펴보세요.

설정을 기록할 때는 클라이언트 이름, 커널 이름, 프로토콜 유형, 로컬 트래픽 연결 방식, 문제가 발생한 애플리케이션부터 적고 증상을 설명하세요. ‘Clash가 안 돼요’라고만 말하는 것보다 원인을 찾기 쉽습니다. 트래픽이 커널에 들어오지 않는다면 TUN 모드와 시스템 프록시의 차이를 먼저 확인하세요. 트래픽이 올바른 정책에 적용된 것을 확인한 뒤 다음 프로토콜 항목으로 넘어가면 됩니다. 이 가이드의 비교는 설정이 올바르고 서버를 사용할 수 있다는 전제에 기반합니다. 서비스 품질 차이를 프로토콜 이름 탓으로 돌리지는 않습니다.

2. SS와 VMess: 경량 전달과 세션 설계

Shadowsocks는 보통 SS로 줄여 부르며, 비교적 단순한 구조로 암호화된 프록시 전달을 제공하는 데 초점을 둡니다. VMess는 V2Ray 생태계에서 나온 프로토콜로, 인증·요청 정보·데이터 전송을 별도의 체계로 구성합니다. 두 프로토콜 모두 Clash 생태계에서 오랫동안 사용됐지만, 오래 쓰였다는 이유만으로 모든 클라이언트가 세부 기능까지 똑같이 지원한다고 볼 수는 없습니다. 비교할 때는 구독의 유형 표시만 보지 말고 암호화 방식, 인증 방식, 외부 전송 방식을 확인하세요.

SS의 장단점은 단순한 구조와 암호화 방식에 있습니다

SS 설정에는 보통 서버 주소, 포트, 비밀번호, 암호화 방식이 포함됩니다. 최근 배포 환경에서는 수신 측에서 데이터 변조를 감지할 수 있도록 인증을 포함한 암호화 방식을 사용하는 경우가 많습니다. 구형 스트림 암호와 최신 AEAD 방식은 서로 같은 것이 아닙니다. 일부 설정은 Shadowsocks 2022 계열 방식을 사용하며, 이 방식은 키 형식과 구현 요건이 기존 비밀번호 기반 설정과 다릅니다. 일반 비밀번호를 아무 방식에나 입력해서는 안 됩니다. 클라이언트가 ss 유형을 인식한다는 것은 해당 프로토콜 진입점을 지원한다는 뜻일 뿐, 세부 암호화 방식까지 확인했다는 뜻은 아닙니다.

해당 하드웨어 명령을 지원하는 기기에서는 AES 계열 알고리즘이 더 빠르게 처리될 수 있고, 관련 명령이 없는 프로세서에서는 ChaCha20 계열 구현이 더 적합할 때도 있습니다. 다만 실제 부하는 커널 구현, 패킷 크기, 동시 연결 수, 기기 온도에도 영향을 받습니다. 알고리즘을 선택할 때는 ‘더 빠를 것’이라는 기대보다 서버 측 설정을 우선해야 합니다. 양쪽의 방식이 다르면 보통 연결이 실패하며, 다른 사용 가능한 방식으로 자동 협상되지 않습니다. 같은 SS 노드라도 기기마다 성능이 다를 수 있으므로 곧바로 설정 오류라고 단정하지 마세요.

SS는 TCP를 전달할 수 있고, 구현과 배포 환경이 지원하면 UDP도 전달할 수 있습니다. 구독에 플러그인이 포함돼 있다면 현재 커널에서 플러그인 이름과 매개변수를 지원하는지도 확인해야 합니다. 플러그인은 연결 경로에 처리 계층을 추가하는 기능이며, SS를 지원하는 모든 클라이언트가 모든 플러그인을 지원하는 것은 아닙니다. 가져온 뒤 해당 노드만 실패한다면 먼저 플러그인 필드와 로그의 파싱 안내를 확인하세요. 낯선 매개변수를 지우고 운에 맡기기보다 설정 제공자에게 현재 클라이언트에서 사용할 수 있는 완전한 형식을 요청하는 편이 좋습니다.

VMess는 인증과 외부 전송을 나눠서 이해해야 합니다

VMess는 사용자 식별자를 인증에 사용하며 자체적인 세션 및 데이터 보호 설계를 갖추고 있습니다. 흔히 볼 수 있는 공유 링크에는 TCP, WebSocket 등의 전송 정보와 선택적 TLS 매개변수가 함께 들어갑니다. WebSocket은 외부 전송 방식이지 새로운 프록시 프로토콜이 아닙니다. TLS 역시 VMess와 같은 뜻이 아닙니다. 경로, 호스트 이름, 인증서 설정이 잘못돼 VMess 연결이 실패할 수 있으며, 이 경우 UUID를 바꿔도 해결되지 않습니다. 원격 주소에서 전송 설정, 인증 순으로 하나씩 확인하세요.

오래된 자료에 나오는 alterId와 구형 인증 설정을 새 배포 환경의 기본 예제로 그대로 사용하지 마세요. 최신 설정은 보통 AEAD 인증 방식을 사용하지만, 구체적인 호환성은 커널과 서버에 따라 다릅니다. VMess 인증에는 시스템 시간이 중요합니다. 기기의 시간이 크게 어긋나면 설정이 올바른 것처럼 보여도 인증에 실패할 수 있습니다. 네트워크 시간 자동 동기화를 복구한 뒤 다시 시험해 보세요. 같은 링크를 반복해서 가져오는 것보다 효과적입니다. 다만 시간이 정상인데 로그에 TLS 오류가 표시된다면 인증서와 서버 이름을 다시 확인하세요. 모든 연결 실패를 시계 문제로 돌려서는 안 됩니다.

두 프로토콜 중 실제로 선택하는 방법

안정적으로 작동하는 SS 설정이 있고 데스크톱 웹 브라우징과 일반 애플리케이션 연결이 목적이라면, 단순한 설정이 관리하기 편할 수 있습니다. 서버가 VMess와 지정된 전송 방식으로 구성돼 있다면 필드가 더 짧은 방식을 찾기보다 양쪽의 설정을 그대로 유지하는 것이 중요합니다. 어느 프로토콜도 이름만으로 대역폭이나 지연 시간을 예측할 수 없습니다. 원격 출구의 혼잡, 연결 거리, 서비스 제한이 프로토콜 처리 비용 차이보다 훨씬 큰 영향을 주는 경우가 많습니다. 서로 다른 서비스 제공자의 노드 두 개를 비교하지 말고, 같은 애플리케이션과 비슷한 시간대, 같은 목적지를 사용해 테스트하세요.

3. Trojan과 VLESS: TLS, 보안 계층, 전송 조합

Trojan과 VLESS는 구독에서 TLS와 함께 표시되는 경우가 많아 같은 기술의 다른 이름으로 오해하기 쉽습니다. 실제로 Trojan은 TLS 연결 안에서 프록시 요청을 처리하도록 설계됐습니다. VLESS는 더 간결한 인증 및 요청 형식에 중점을 두며, VMess와 같은 데이터 암호화 기능을 자체적으로 제공하지 않습니다. 두 프로토콜은 보안 경계와 설정 구조, 조합 방식이 서로 다릅니다. 포트나 인증서 설정이 같다고 해서 서로 호환된다고 판단해서는 안 됩니다.

Trojan: TLS에 보안 전송을 맡기는 방식

Trojan은 보통 TLS로 연결의 기밀성과 서버 인증을 제공한 뒤, 해당 연결 안에서 프로토콜 인증과 목적지 요청을 처리합니다. 흔히 설정하는 항목은 주소, 포트, 비밀번호, 서버 이름입니다. 클라이언트가 연결하는 IP 주소와 인증서에 등록된 도메인이 다를 수 있지만, 인증할 때는 올바른 서버 이름을 사용해야 합니다. 이 이름은 임의로 붙이는 메모가 아니라 TLS 핸드셰이크와 인증서 검사에 쓰입니다. 노드 표시 이름을 서버 이름에 입력하면 인증서가 일치하지 않을 수 있습니다.

TLS 세션 복구 여부, 연결 재사용, 서버가 지원하는 전송 방식에 따라 실제 연결 비용이 달라질 수 있습니다. TLS를 ‘항상 핸드셰이크만큼 느려진다’고 단정할 수 없고, 모든 구현이 같은 방식으로 연결을 재사용한다고 가정할 수도 없습니다. 첫 연결과 짧은 시간 안에 다시 연결할 때, 애플리케이션이 연결을 오래 유지할 때의 부하는 서로 다를 수 있습니다. 비교 결과를 볼 때는 새 연결을 측정했는지, 보안 세션을 이미 수립한 뒤의 데이터 전송을 측정했는지 확인하세요. 그렇지 않으면 같은 프로토콜도 서로 모순되는 결과처럼 보일 수 있습니다.

인증서 오류는 올바른 도메인과 유효한 인증서, 시스템 시간을 확인해 해결해야 합니다. 검증을 건너뛰는 설정을 일상적으로 사용하지 마세요. 검증을 끄면 중요한 서버 신원 확인을 포기하게 되며, 연결에 성공했다는 사실만으로 의도한 서버에 접속했다고 볼 수 없습니다. 설정 제공자가 별도의 신뢰 방식을 요구한다면 먼저 근거와 위험을 파악하고 클라이언트 지원 여부를 확인하세요. 다른 노드에서 관련 스위치를 그대로 복사하지 마세요. 비밀번호와 인증서 신뢰 관계는 서로 다른 역할을 하므로, 비밀번호가 맞아도 잘못된 인증서 설정을 보완할 수 없습니다.

VLESS: 프로토콜·전송·보안 계층을 각각 확인하세요

VLESS는 간결한 요청 구조를 바탕으로 여러 전송 및 보안 방식과 조합할 수 있습니다. type: vless를 확인한 뒤에는 TCP 또는 다른 네트워크 전송 방식, TLS 또는 REALITY 관련 설정, 서버에서 특정 flow를 요구하는지를 살펴보세요. VLESS 자체는 완전한 데이터 암호화를 제공하지 않으므로 사용자 식별자가 있다고 해서 암호화되지 않은 전송도 안전하다고 볼 수는 없습니다. 유형 필드 하나만 따로 평가하지 말고 전체 연결 조합을 기준으로 판단하세요.

REALITY는 특정 보안 핸드셰이크 방식이며 Vision은 특정 flow 제어 및 데이터 처리 경로와 관련된 기능입니다. 어느 노드에나 마음대로 추가할 수 있는 범용 속도 향상 스위치가 아닙니다. 서버 이름, 공개 키, 짧은 식별자, flow 등의 항목은 서버 설정과 일치해야 하며 현재 커널에서 지원해야 합니다. 클라이언트마다 화면에 표시되는 항목 이름이 다를 수 있고, 완전한 YAML만 받는 클라이언트도 있습니다. 가져오기는 성공했지만 연결되지 않는다면 목록에 노드가 보이는지만 확인하지 말고 해당 필드가 커널에 실제로 전달됐는지 살펴보세요.

필드 수가 아니라 전체 구성을 지원하는지가 중요합니다

서버가 두 종류의 진입점을 모두 제공한다면 클라이언트가 명확히 지원하고, 설정 정보가 완전하며, 인증서 검증을 유지할 수 있는 조합을 우선하세요. 필드가 적다고 배터리 사용량이 반드시 줄어드는 것도 아니고, 조합이 복잡하다고 반드시 빨라지는 것도 아닙니다. 일상적인 웹 브라우징에서는 연결 안정성, 애플리케이션 복구 속도, 안정적인 설정 업데이트가 더 중요할 수 있습니다. 특정 VLESS 기능이 필요한 사용자는 실제 성능을 비교하기 전에 mihomo 빌드와 클라이언트의 가져오기 경로를 확인하세요. 전송 정보가 없는 노드 링크만 받았다면 링크 모양을 보고 추측하지 말고 완전한 설정을 요청하세요.

4. Hysteria2와 TUIC: QUIC 전송의 장단점

Hysteria2와 TUIC는 모두 QUIC을 이용해 프록시 데이터를 전송하지만, 같은 프로토콜을 다르게 부르는 이름은 아닙니다. QUIC은 UDP를 기반으로 보안 핸드셰이크, 스트림 관리, 혼잡 제어 기능을 통합해 기존 TCP 연결과는 다른 방식으로 프록시 세션을 구성합니다. 두 프로토콜 중 하나를 선택하기 전에 현재 네트워크에서 UDP에 접속할 수 있는지, 어떤 제한이 있는지 확인하세요. 그다음 혼잡 제어와 대역폭 설정을 살펴보면 됩니다. 하위 UDP 경로가 막혀 있으면 인증 정보가 완벽해도 세션을 수립할 수 없습니다.

QUIC이 해결하는 문제와 해결하지 못하는 문제

QUIC은 여러 스트림을 사용해 한 패킷의 손실이 다른 스트림의 전송까지 막는 현상을 줄일 수 있습니다. 모든 데이터를 하나의 TCP 바이트 스트림에 넣는 방식과는 다릅니다. 그러나 한 스트림 안에서 순서대로 전달해야 하는 데이터는 재전송을 기다릴 수 있으며, 모든 스트림은 대역폭과 혼잡 상태, 단말 리소스를 공유합니다. ‘패킷 손실이 속도에 영향을 주지 않는’ 기술은 아닙니다. 네트워크가 혼잡해지면 전송 속도를 조절해야 하며, 애플리케이션 요청 간 의존성이나 서버 응답 시간도 QUIC으로 사라지지 않습니다.

일부 네트워크는 UDP에 별도의 속도 제한, 시간 초과, 패킷 손실 정책을 적용합니다. 영상 통화가 된다고 해서 모든 원격 포트의 UDP 품질이 같다는 뜻은 아닙니다. 핸드셰이크에 한 번 성공했다고 장시간 대용량 전송도 안정적이라고 볼 수 없습니다. 지속적인 접속, 잠시 멈춘 뒤 복구, 기기 절전 후 재연결을 포함해 테스트하세요. QUIC은 연결 마이그레이션을 지원할 수 있지만, 프록시 구현과 주소 변경 방식, 네트워크 장비 상태에 따라 결과가 달라집니다. Wi-Fi에서 모바일 네트워크로 전환할 때 연결이 계속 유지된다고 보장할 수는 없습니다.

Hysteria2: 실제 네트워크 조건에 맞춰 전송 설정하기

Hysteria2는 불안정한 네트워크에서의 데이터 전송을 고려해 설계됐으며, 배포 설정에는 대역폭 관련 항목과 여러 혼잡 제어 방식이 포함되는 경우가 많습니다. 대역폭 선언에 의존하는 전송 전략을 사용한다면 입력한 업·다운로드 속도는 기기의 표기 속도가 아니라 지속적으로 낼 수 있는 실제 속도에 가까워야 합니다. 수치를 높게 입력한다고 대역폭이 늘어나는 것은 아닙니다. 오히려 대기열이 길어지고 패킷 손실이 늘어 같은 네트워크를 사용하는 다른 애플리케이션에 영향을 줄 수 있습니다. 서버에도 자체 제한이 있을 수 있으며 클라이언트 설정으로 원격 리소스 제한을 우회할 수는 없습니다.

mihomo 설정에는 실제로 지원되는 Hysteria2 유형과 필드를 사용해 가져와야 합니다. 기존 Hysteria 설정의 이름만 바꿔 계속 사용해서는 안 됩니다. 인증 정보, TLS 서버 이름, 선택적 난독화 매개변수는 모두 원격 설정과 일치해야 합니다. 대역폭 필드를 생략할지, 어떤 전송 전략을 사용할지는 제공자의 안내와 현재 커널 문서를 따르세요. 연결은 되지만 다운로드가 지속적으로 크게 흔들린다면 DNS를 계속 바꾸기보다 UDP 경로, 대역폭 추정, 기기 처리 능력을 함께 확인하세요.

TUIC: 세션 구성과 UDP 전달 방식

TUIC 역시 QUIC을 사용하며 프록시 세션, 인증, 데이터 전달 방식을 자체적으로 정의합니다. 프로토콜 버전과 구현이 다르면 서로 호환되지 않을 수 있으므로 공유 설정은 커널이 받아들이는 형식과 일치해야 합니다. UDP 전달 방식, 혼잡 제어 옵션, 연결 유지, 시간 초과 설정이 사용 경험에 영향을 줄 수 있습니다. 일부 모드는 추가 부하를 줄이는 데 중점을 두고 다른 모드는 전달 방식에 초점을 둡니다. 옵션 이름만 보고 선택하지 마세요. 특히 실시간 데이터가 필요한 애플리케이션에서는 대용량 파일 다운로드 완료 여부보다 갑작스러운 끊김과 패킷 손실을 살펴보세요.

QUIC은 사용자 공간에서 처리하는 프로토콜 로직이 많아 암호화, 패킷 처리, 높은 패킷 전송률에 CPU를 사용할 수 있습니다. 최신 데스크톱 기기는 무리 없이 처리할 수 있지만, 저전력 라우터나 발열이 계속되는 휴대전화는 처리 한계에 먼저 도달할 수 있습니다. 프로토콜 부하는 기기와 구현에 따라 달라지므로 모든 플랫폼에 적용할 수 있는 리소스 순위는 없습니다. 같은 회선에서 TCP 계열 진입점이 이미 안정적으로 요구사항을 충족한다면 QUIC으로 바꿔도 큰 이점이 없을 수 있습니다. 지연 시간이 높고 패킷 손실이 실제로 발생하는 회선이라면 조건을 통제해 테스트한 뒤 개선 여부를 확인하는 편이 정확합니다.

5. 성능과 배터리: 의미 있는 비교 방법

프로토콜을 비교하려면 적어도 네 가지 지표를 따로 살펴봐야 합니다. 새 연결에 걸리는 시간, 지속 전송 속도, 요청 응답의 안정성, 기기 리소스 사용량입니다. 클라이언트에 표시되는 지연 시간은 대개 특정 테스트 경로에서 한두 번 요청한 시간입니다. 대역폭도 아니고 전체적인 애플리케이션 사용 경험도 아닙니다. 테스트 대상과 출구, 시간대, 기기 조건이 비슷해야 프로토콜 차이를 논의할 수 있습니다. 지역과 서비스 제공자가 다른 노드의 결과를 프로토콜 순위로 바로 해석해서는 안 됩니다.

연결 속도, 대역폭, 간헐적 지연

첫 접속 시간에는 DNS, 하위 연결, 보안 핸드셰이크, 프록시 인증, 목적지 서버 응답이 모두 영향을 줍니다. 애플리케이션이 이미 만든 연결을 재사용하면 이후 요청은 일부 과정을 건너뛸 수 있으므로, 첫 연결은 느리지만 연속해서 탐색할 때는 빠른 상황이 동시에 발생할 수 있습니다. 대용량 파일 전송은 지속 처리량을 확인하기 좋지만, 페이지의 여러 소규모 요청이 완료되는 경험을 보여주지는 못합니다. 실시간 서비스는 갑작스러운 패킷 손실과 긴 지연에 더 민감합니다. 평균 응답 시간이 비슷해도 간헐적으로 크게 멈추면 사용 경험이 달라질 수 있습니다.

합리적으로 비교하려면 서버 조건이 최대한 비슷한 두 진입점을 골라 비슷한 시간대에 같은 작업을 번갈아 실행하세요. 페이지 첫 접속, 열린 페이지 새로고침, 짧은 파일 전송, 실제로 사용하는 음성 통화나 원격 애플리케이션을 시험할 수 있습니다. 각 항목을 여러 번 반복하고 실패도 기록하세요. 가장 잘 나온 결과만 남겨서는 안 됩니다. 테스트 중 여러 대용량 작업을 동시에 실행하면 대역폭 경쟁이 차이를 가릴 수 있습니다. 자세한 원리는 노드 지연 시간 테스트와 실제 인터넷 속도의 차이를 참고하세요.

리소스 사용량에는 정해진 프로토콜 순위가 없습니다

CPU 부하는 암호화 구현, 시스템 호출, 패킷 처리, 데이터 복사 등 여러 요인에 따라 달라집니다. 메모리 사용량은 연결 수, 버퍼, 규칙 데이터베이스의 영향도 받습니다. TUN 모드에서 발생하는 트래픽 처리 작업이 두 프록시 프로토콜 사이의 부하 차이보다 클 수도 있습니다. 메모리 사용량이 늘었다면 먼저 연결이 증가했는지, 캐시가 쌓였는지, 계속 비정상적으로 커지는지 확인하세요. 특정 프로토콜을 사용한다는 이유만으로 원인을 단정해서는 안 됩니다. 클라이언트를 비교할 때는 화면 프로세스와 커널 프로세스도 구분해야 합니다. 데스크톱 인터페이스의 사용량을 프로토콜 부하에 포함하면 안 됩니다.

하드웨어 가속과 네트워크 오프로드도 결과를 바꿉니다. 관련 암호화 명령을 지원하는 프로세서인지, 운영체제의 네트워크 스택이 어떤지, 커널 빌드에서 어떤 구현을 사용했는지에 따라 같은 프로토콜도 기기별로 다르게 작동할 수 있습니다. 저전력 기기는 온도가 올라가면 클럭이 낮아져 처음 몇 분은 빠르다가 점차 느려질 수 있습니다. 이때는 연결 수나 버퍼를 더 늘려 기존 리소스 병목을 악화시키지 말고, 온도와 CPU 부하, 네트워크 상태의 연관성을 살펴보세요.

모바일 배터리 사용량은 기기 깨움과 연결 유지 방식이 중요합니다

휴대전화 배터리는 암호화 연산뿐 아니라 무선 통신의 활성 상태, 백그라운드 깨움, 반복적인 재연결에도 사용됩니다. 상태 확인, 구독 갱신, 연결 유지 요청을 지나치게 자주 보내면 원래 유휴 상태였을 기기에서도 네트워크 활동이 계속 발생합니다. 반대로 시간 초과를 너무 짧게 설정하면 세션이 자주 끊겨 앱을 다시 사용할 때마다 연결을 새로 수립할 수 있습니다. 클라이언트의 적절한 기본값을 우선 사용하고 실제 연결 끊김이 있을 때 조정하세요. 순간적인 속도 측정값을 높이려고 높은 빈도의 확인을 계속 켜두지 마세요.

배터리 사용량을 비교할 때는 화면 밝기, 네트워크 유형, 사용 시간, 작업량을 고정하고 시스템 배터리 통계에서 백그라운드 활동을 확인하세요. 모바일 신호가 약하면 무선 통신의 전력 소모가 프로토콜 차이보다 커지는 경우가 많습니다. Wi-Fi와 모바일 네트워크의 결과도 직접 비교하기 어렵습니다. Android의 절전 제한은 백그라운드 서비스를 종료할 수 있고, iOS의 네트워크 확장은 시스템이 수명 주기를 관리하므로 동작 방식이 완전히 같지 않습니다. 시스템이 실행 조건을 유지했는지 살펴보지 않은 채 복구 후 재연결을 프로토콜 문제로 단정하지 마세요.

6. 커널 계열: 원본, Meta, mihomo

Clash는 처음에 YAML 설정, 정책 그룹, 규칙 기반 트래픽 분기를 중심으로 한 사용 방식을 형성했습니다. 이후 생태계는 이러한 개념을 바탕으로 여러 커널과 그래픽 클라이언트로 발전했습니다. 원본 오픈소스 커널과 과거의 여러 배포 계열, Meta 브랜치는 완전히 같은 구현을 제공하지 않습니다. mihomo는 Clash.Meta의 후속 프로젝트 이름이므로 자료나 클라이언트 화면에서 여전히 Meta라는 이름이 보일 수 있습니다. 이러한 이름 관계는 오래된 가이드를 이해하는 데 도움이 되지만, 실제 커널 기능을 확인하는 일을 대신하지는 않습니다.

기본 문법이 같아도 모든 기능이 동일한 것은 아닙니다

일반적인 설정은 proxies, proxy-groups, rules 등의 구조를 유지하므로 기본 개념은 상당 부분 그대로 사용할 수 있습니다. 하지만 프로토콜 유형, DNS 동작, TUN 기능, 규칙 공급자, 확장 필드는 브랜치와 빌드에 따라 달라집니다. 원본 자료에 특정 필드가 있다고 해서 모든 클라이언트에서 똑같이 작동하는 것은 아닙니다. mihomo에서 지원하는 확장을 오래된 원본 커널에 그대로 적용할 수도 없습니다. 마이그레이션할 때는 파일 확장자가 같은지가 아니라 구체적인 필드가 호환되는지를 확인하세요.

Hysteria2, TUIC, 특정 VLESS 조합, 확장된 라우팅 기능은 최신 커널 지원 여부를 확인할 때 자주 살펴보는 항목입니다. 실제 지원 여부는 빌드와 플랫폼 제한, 클라이언트 통합 방식에 따라 달라집니다. 일부 그래픽 인터페이스는 특정 필드를 걸러내고, 일부는 중간 설정을 생성하며, 원본 YAML을 직접 읽는 클라이언트도 있습니다. ‘독립 커널에서는 작동하지만 클라이언트에 가져오면 안 된다’면 가져오기 전 파일만 비교하지 말고 실제로 적용된 설정을 비교하세요.

커널 확인 순서

클라이언트의 정보, 커널 관리, 실행 로그에서 커널 이름을 먼저 확인한 다음 실제로 어떤 빌드가 실행 중인지 확인하세요. 설치 폴더에 커널 파일이 여러 개 있다고 해서 동시에 작동하는 것은 아닙니다. 클라이언트 화면의 버전도 커널 버전과 다를 수 있습니다. 커널 전환 기능을 제공한다면 전환 후 서비스가 다시 시작될 때까지 기다리고 로그에서 확인하세요. 화면에 정보가 명확히 표시되지 않으면 클라이언트 설명과 실행 출력을 기준으로 판단하세요. 설치 파일 이름만 보고 추측해서는 안 됩니다. 버전 기록은 문제 해결에 참고할 수 있지만, 선택을 위해 매번 바뀌는 버전을 따라갈 필요는 없습니다.

업그레이드하기 전에 원본 구독과 필요한 로컬 오버라이드를 저장하고, 현재 트래픽 연결 방식과 포트, DNS 설정을 기록하세요. 업그레이드 후에는 가장 단순한 사용 가능한 설정으로 기본 연결을 확인한 다음 사용자 지정 규칙과 확장 기능을 복구하세요. 이렇게 하면 ‘프로토콜 파싱 변경’, ‘시스템 연동 변경’, ‘로컬 오버라이드 충돌’을 구분할 수 있습니다. 처음 실행부터 실패한다면 설정 파싱 로그를 확인하세요. 커널은 실행되지만 애플리케이션이 연결되지 않는다면 시스템 프록시, TUN 권한, 라우팅을 확인해야 합니다. 두 종류의 문제에 같은 해결 방법을 적용해서는 안 됩니다.

클라이언트 선택과 유지 관리 기준

일반 사용자는 Clash Plus부터 시작해 기기 플랫폼별 프로토콜 가져오기와 시스템 요구 사항을 확인하면 됩니다. 데스크톱 관리 방식에 대한 선호가 뚜렷하다면 Clash Verge Rev, FlClash, Clash Nyanpasu를 비교해 보세요. Android에서는 설정 출처에 따라 Clash Meta for Android와 Surfboard를 비교할 수 있지만, 후자의 설정 체계를 Clash YAML과 같은 것으로 볼 수는 없습니다. Linux 데스크톱에서는 Clash Verge Rev와 FlClash 중에서 선택할 수 있습니다. 독립 mihomo 커널과 서비스 관리는 서버나 라우터 환경에서 고려하면 됩니다.

Clash for Windows와 ClashX Meta는 이 사이트에서 지원이 종료된 보관용 클라이언트로 안내합니다. 새로운 프로토콜 기능을 확인할 때 기본 참조 대상으로 삼지 않는 것이 좋습니다. 기존 작업 흐름 때문에 구형 환경에서 계속 사용한다면 지원되는 프로토콜과 설정 범위를 확인하세요. 새 설정의 알 수 없는 필드를 하나씩 삭제해 ‘실행만 되게’ 만들지 마세요. 라우팅과 보안 동작이 바뀔 수 있습니다. 플랫폼별 다운로드와 보관 상태는 클라이언트 다운로드 페이지에서, 인터페이스 비교는 선택 가이드에서 확인하세요.

7. 구독과 설정: 형식 확인 및 호환성 점검

구독 링크는 콘텐츠를 가져오는 경로일 뿐, 형식이 고정돼 있다는 보장은 아닙니다. 비슷한 HTTPS 주소라도 노드 공유 링크 모음, Base64로 인코딩된 텍스트, 완전한 YAML 설정을 반환할 수 있습니다. 클라이언트에서 바로 사용할 수 있는지는 반환된 콘텐츠와 가져오기 방식이 맞는지에 따라 달라집니다. 브라우저에서 주소가 열린다는 것은 서버가 콘텐츠를 반환했다는 뜻일 뿐입니다. 로그인 페이지, 오류 메시지, 빈 텍스트가 반환된다면 유효한 프록시 설정이 아닙니다.

노드 목록, 제공자, 전체 설정 구분하기

노드 링크에는 보통 프록시 하나의 연결 정보가 들어 있습니다. 링크 여러 개를 모아도 로컬 포트, DNS, 정책 그룹, 규칙이 포함돼 있다고 보장할 수 없습니다. 전체 Clash 설정은 이러한 항목을 구성해 트래픽을 어떻게 연결하고, 이름을 어떻게 해석하며, 출구를 어떻게 선택하는지 지정합니다. 프록시 제공자는 또 다른 범위의 기능으로, 기존 설정에 프록시 목록을 제공합니다. 모든 실행 설정을 대신하지는 않습니다. 가져오기 방식을 잘못 선택하면 노드는 표시되지만 적절한 정책 그룹이 없거나, 파일을 파싱할 수는 있어도 단독 설정으로 실행되지 않을 수 있습니다.

Base64는 단순한 인코딩 방식으로 추가적인 보안 기능을 제공하지 않으며 노드 목록을 자동으로 YAML로 변환하지도 않습니다. 구독 변환 도구는 원본 형식을 파싱한 뒤 대상 커널이 사용하는 필드와 정책 구조로 만들어야 합니다. 변환 과정에서 전송 세부 정보, 특정 보안 매개변수, UDP 설정 등 인식하지 못하는 확장 정보가 빠질 수 있습니다. 변환 결과에 노드 이름이 표시된다고 모든 기능이 유지된 것은 아닙니다. 복잡한 VLESS나 QUIC 설정은 제공자가 명확히 지원하는 대상 형식을 우선 사용하고 핵심 매개변수를 대조하세요.

반복해서 다시 가져오기보다 구조를 확인하세요

설정을 읽을 때는 먼저 프록시 정의를 찾고, 그 프록시를 참조하는 정책 그룹을 살펴본 다음 규칙이 가리키는 정책이 존재하는지 확인하세요. 아래는 참조 관계를 보여 주는 최소 예시이며 전체 실행 설정은 아닙니다. 기존 설정에 ‘기존 노드’라는 이름의 프록시가 이미 정의돼 있다고 가정합니다. 사용할 때는 기존 설정에 해당 내용을 병합해야 하며, 같은 이름의 최상위 키를 두 번째로 만들면 안 됩니다. 예시는 일반적인 규칙 형식으로, 각 규칙이 어떤 출구를 선택하는지 파악하는 데 도움이 됩니다.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 기존 노드
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - MATCH,DIRECT

이 설정에서는 먼저 규칙이 도메인 접미사와 일치하는지 확인합니다. 일치하면 PROXY 그룹에 전달되고, 해당 그룹에서 현재 선택한 항목이 출구가 됩니다. 일치하지 않으면 마지막의 DIRECT로 넘어갑니다. 그룹 안에 DIRECT가 있다고 해서 모든 요청이 직접 연결되는 것은 아닙니다. 직접 연결을 수동으로 선택할 수 있도록 제공하는 항목입니다. 규칙은 위에서부터 확인해 처음 일치하는 항목을 적용하고 멈춥니다. 더 포괄적인 규칙을 앞에 두면 뒤의 세부 규칙이 적용되지 않을 수 있습니다. 자세한 문법과 순서는 사용자 지정 규칙과 MATCH 최종 규칙을 참고하세요.

YAML, 오버라이드, 업데이트는 각각 적용 범위가 다릅니다

YAML은 들여쓰기와 구조에 민감하므로 공백을 사용하고 같은 단계의 항목을 정렬하세요. 비밀번호나 특수 문자가 포함된 문자열, 다른 형식으로 잘못 인식될 수 있는 값은 올바르게 따옴표로 묶어야 합니다. 파싱 오류에 가까운 줄 번호가 표시돼도 실제 원인은 바로 앞 줄의 콜론 누락이나 잘못된 목록 단계일 수 있습니다. 먼저 파싱 오류를 해결하고, 참조 관계를 확인한 뒤 프로토콜 연결을 검증하세요. 여러 필드를 한 번에 바꾸는 것보다 효율적입니다. 규칙이나 노드 이름이 길더라도 그대로 유지하세요. 화면에서 줄이 바뀐 것을 파일의 줄바꿈으로 착각하지 마세요.

구독을 업데이트하면 수동 수정 내용이 덮어써질 수 있으므로 계속 유지해야 하는 로컬 규칙은 클라이언트가 지원하는 오버라이드 또는 병합 기능을 사용하세요. 클라이언트마다 병합 순서는 다릅니다. 목록을 교체할 수도 있고 추가할 수도 있습니다. 수정 후에는 실제 적용된 결과, 특히 규칙 순서와 DNS 항목을 확인하세요. DNS의 Fake-IP는 도메인 해석 및 주소 매핑 방식이지 프록시 프로토콜 유형이 아닙니다. 노드 형식을 변환한다고 애플리케이션의 Fake-IP 호환성 문제가 저절로 해결되지는 않습니다. DNS를 수정하기 전에 문제가 도메인 해석 단계에서 발생하는지 원격 연결 단계에서 발생하는지 확인하세요.

같은 구독을 두 클라이언트에서 사용했는데 노드 수나 프로토콜 유형이 다르면 구독이 잘못됐다고 단정하기 전에 필터 설정, 형식 선택, 커널 지원을 확인하세요. 형식별 차이는 Base64 노드 링크와 YAML 설정 안내에서 확인할 수 있습니다. 원본 제공자 설정과 로컬 수정 내용을 구분해 두면 이후 업데이트와 마이그레이션을 추적하기 쉽습니다.

8. 사용 환경과 문제 해결: 요구사항에 맞춰 선택 범위 좁히기

프로토콜 선택은 ‘무엇이 가장 최신인가’가 아니라 기기, 네트워크, 애플리케이션, 설정 출처가 서로 맞는지 확인하는 데서 시작합니다. 먼저 기존 설정을 올바르게 가져올 수 있고 계속 관리하기 쉬운 클라이언트를 고르세요. 다음으로 트래픽 연결 방식을 정한 뒤 같은 서버의 진입점끼리 성능을 비교하면 됩니다. 일반 사용자는 Clash Plus와 설정 제공자가 지원하는 구성을 우선 사용하는 것이 좋습니다. 명확한 호환성 요구나 반복적으로 확인된 성능 문제가 있을 때만 새 커널이나 프로토콜 조합을 추가하세요. 문제 해결 환경을 지나치게 복잡하게 만들 필요는 없습니다.

데스크톱·모바일·라우터별 고려 사항

데스크톱의 웹 브라우징과 업무용 애플리케이션에서는 먼저 시스템 프록시가 필요한 프로그램을 모두 처리하는지 확인하세요. 브라우저는 되지만 명령줄은 연결되지 않는다면 원격 프로토콜 문제가 아니라 명령줄 도구가 시스템 프록시를 읽지 않는 것일 수 있습니다. 더 많은 앱의 트래픽을 처리해야 한다면 TUN을 고려하되 가상 네트워크 인터페이스 권한, 라우팅 충돌, 로컬 네트워크 접근을 확인하세요. 안정적으로 작동하는 SS, Trojan, 완전한 VLESS 조합은 계속 사용해도 됩니다. 이름이 새롭다는 이유만으로 바꿀 필요는 없습니다. 개발 도구는 자체 프록시와 환경 변수도 따로 확인해야 합니다.

모바일에서는 절전 모드에서 복구되는지, 네트워크 전환이 원활한지, 백그라운드에서 안정적으로 작동하는지를 우선 살펴보세요. Wi-Fi와 모바일 네트워크를 자주 오간다면 한 네트워크에서만 속도를 측정하지 말고 실제로 전환한 뒤 기존 세션과 새 세션을 확인하세요. QUIC 계열 프로토콜도 선택지가 될 수 있지만 현재 통신망에서 UDP를 사용할 수 있는지 검증해야 합니다. 재연결을 한 번 줄이려고 연결 유지를 임의로 강화하지 마세요. 시스템이 백그라운드 서비스를 중단해 연결이 끊긴 상황을 인증 실패로 오해해서도 안 됩니다. iOS에서는 Clash Plus 앱 스토어 페이지에서 시작하고 공식 사이트 clashplus.io에서 제품 정보를 확인할 수 있습니다.

라우터와 서버에서는 독립 커널, 자동 시작, 로그 관리, 명확한 라우팅 경계를 고려해야 합니다. 저전력 프로세서는 높은 암호화 처리량과 QUIC 패킷 처리에 더 민감하며, 연결 수와 규칙 때문에 메모리가 부족해질 수도 있습니다. 적은 연결로 안정성을 먼저 확인한 뒤 부하를 단계적으로 늘리세요. 데스크톱 설정을 복잡한 그대로 복사해 장기간 실행하지 마세요. 별도 라우터, 다중 네트워크 인터페이스, 기존 투명 프록시 규칙이 있는 환경에서는 트래픽이 순환하지 않는지도 확인해야 합니다. 프로토콜을 바꿔도 잘못된 라우팅 테이블은 고칠 수 없고, 관리자가 방화벽 규칙을 확인하는 일도 대신할 수 없습니다.

문제가 생기면 계층별로 확인하고 여러 설정을 동시에 바꾸지 마세요

첫째, 커널이 시작됐는지 확인하세요. 설정 파싱 오류, 알 수 없는 프로토콜, 누락된 필드는 설정과 커널 호환성을 먼저 살펴보세요. 수신 포트에서 오류가 나면 포트 번호와 다른 서비스의 사용 여부를 확인합니다. 둘째, 애플리케이션 요청이 연결 기록에 나타나는지 확인하세요. 기록이 없다면 로컬 트래픽 연결 방식을 점검합니다. 셋째, 규칙이 어떤 정책에 적용됐는지 확인하고 실수로 DIRECT나 사용할 수 없는 프록시 그룹을 선택하지 않았는지 살펴보세요. 넷째, 원격 연결의 시간 초과, 인증, 인증서, UDP 경로 문제를 확인합니다. 이 순서를 따르면 원격 연결이 정상인데도 노드를 계속 바꾸는 일을 줄일 수 있습니다.

로그에 인증서 오류가 표시되면 서버 이름, 시스템 시간, 인증서 체인을 확인하세요. 인증 실패라면 비밀번호나 사용자 식별자를 점검하고, 계속 시간 초과가 발생하면 TCP 또는 UDP 전송 경로의 연결 가능성을 살펴보세요. 특정 사이트만 실패한다면 원격 출구와 목적지 서비스의 관계, DNS 응답 결과도 고려해야 합니다. 포트 충돌은 로컬 실행 문제입니다. 포트 사용 여부 확인과 혼합 포트 변경을 참고하세요. 처음 가져오는 과정이나 기본 사용법에 문제가 있다면 사용 가이드를 확인하면 됩니다. 설정 체계 전체를 처음부터 바꿀 필요는 없습니다.

재현 가능한 선택 기록 남기기

마지막으로 기기와 운영체제, 클라이언트와 커널, 전체 프로토콜 조합, 트래픽 연결 방식, 테스트할 애플리케이션, 네트워크 유형, 반복해서 확인된 증상을 간단히 기록하세요. 한 번에 핵심 요소 하나만 바꾸고 이미 작동하는 설정은 보존하세요. 새 조합의 속도 측정값이 더 좋더라도 절전 후 재연결, 리소스 사용량, 호환성 문제가 생긴다면 기존의 안정적인 구성을 계속 사용해도 됩니다. 프로토콜은 연결 수단이지 등급이 아닙니다. 신뢰할 수 있는 설정 출처, 설명 가능한 동작, 업데이트 후 복구 가능성이 장기간 사용할 설정을 고르는 기준입니다.