Clash 프로토콜 및 커널 가이드

프로토콜, 전송 방식, 클라이언트의 차이

프로토콜은 클라이언트와 프록시 서버가 대상 주소와 인증 정보를 주고받고 데이터를 전달하는 방식을 정합니다. 전송 계층은 TCP, UDP 또는 이를 기반으로 만든 채널을 통해 데이터가 이동하는 방식을 결정합니다. 클라이언트는 설정 가져오기, 정책 선택, 로그 확인, 시스템 트래픽 처리 기능을 제공합니다. 세 요소는 서로 연관되어 있지만 같은 것은 아닙니다. Clash Plus, Clash Verge Rev, FlClash라는 이름만 보고 특정 노드의 프로토콜이나 확장 필드 지원 여부를 판단할 수는 없습니다. 소프트웨어의 외관만으로 호환성을 단정해서도 안 됩니다.

연결을 점검 가능한 단계로 나누기

웹페이지에 접속할 때는 보통 로컬 DNS 조회, 규칙 매칭, 프록시 연결, 원격 대상 연결, 애플리케이션 계층 협상이 차례로 이루어집니다. 사용자가 체감하는 대기 시간은 이 모든 단계가 합쳐진 결과입니다. 노드 테스트에 성공했다는 것은 테스트 대상에 그 시점에 접속할 수 있었다는 뜻일 뿐입니다. 특정 웹페이지는 자체 DNS, 인증서, 지역별 서비스 또는 사이트 장애 때문에 계속 열리지 않을 수 있습니다. 프로토콜을 비교하기 전에 트래픽이 실제로 지정한 정책을 따르는지 확인하세요. 그렇지 않으면 프로토콜 차이가 아니라 서로 다른 출구를 테스트한 결과일 수 있습니다.

TCP는 신뢰성 있고 순서가 보장되는 바이트 스트림을 제공합니다. 데이터가 손실되면 재전송해야 하며, 누락된 부분이 도착할 때까지 뒤따르는 데이터 전달이 지연될 수 있습니다. UDP는 데이터그램을 전달하지만 자체적으로 신뢰성이나 순서를 보장하지 않습니다. UDP 기반 QUIC은 사용자 공간에서 신뢰성 있는 스트림, 혼잡 제어, 암호화 핸드셰이크를 구현합니다. 따라서 ‘UDP 기반’이라고 해서 재전송이 없는 것도 아니고, 모든 UDP 앱이 프록시를 바로 통과할 수 있는 것도 아닙니다. 프로토콜 구현에서 데이터그램 전달을 지원해야 하며, 클라이언트의 트래픽 처리 방식도 해당 트래픽을 커널로 전달할 수 있어야 합니다.

세부 설정 조정보다 호환성 확인이 먼저

실제 선택은 네 단계로 좁혀 가면 됩니다. 먼저 서버가 어떤 프로토콜을 제공하는지 확인하고, 현재 커널이 어떤 필드를 해석할 수 있는지 살펴본 다음, 사용 중인 네트워크에서 어떤 전송 방식이 허용되는지 확인하세요. 그 후에 속도, 배터리, 기능을 비교하면 됩니다. 지원하지 않는 필드가 포함된 설정은 클라이언트에 저장되더라도 해당 기능이 활성화된다는 뜻이 아닙니다. 특히 프로토콜 이름과 전송 확장 기능을 구분해야 합니다. 같은 VLESS라도 전송 방식, 보안 계층, 흐름 제어 설정에 따라 요구 사항이 크게 다를 수 있습니다.

프록시 모드와 프로토콜도 구분해야 합니다. 규칙 모드, 전역 모드, 직접 연결 모드는 연결에 적용할 정책을 정할 뿐 SS를 Trojan으로 바꾸거나 노드에 UDP 기능을 추가하지 않습니다. TUN 모드는 시스템 네트워크 계층에서 트래픽을 처리하는 방식이지, 새로운 프로토콜이 아닙니다. TUN을 켠 뒤 게임이 연결된다면 대개 이전에 처리되지 않던 트래픽이 이제 프록시로 전달된 것입니다. 노드의 전송 성능이 갑자기 달라진 것은 아닙니다. 트래픽 처리 방식은 규칙 모드·전역 모드·직접 연결의 차이에서 확인할 수 있습니다.

이 가이드는 합법적으로 사용할 수 있는 서버 설정을 보유한 독자를 대상으로 합니다. 서버 인증 정보를 제공하지 않으며, 프로토콜 이름만 보고 구독 내용을 바꾸는 방법도 권장하지 않습니다. 클라이언트는 서버가 지원하는 방식으로만 연결할 수 있습니다. 설정의 프로토콜 이름을 다른 것으로 바꿔도 프로토콜이 변환되지는 않습니다. 프로토콜을 변경하려면 서버에서 제공하는 해당 접속 정보와 매개변수를 모두 받아야 합니다. 비교 기준을 잃지 않도록 기존 접속 설정은 복구용으로 남겨 두고, 한 번에 여러 변수를 변경하지 마세요.

SS와 VMess: 기본 프로토콜의 차이

Shadowsocks는 보통 SS로 줄여 부르며, 가벼운 암호화 프록시를 목표로 설계되었습니다. 주요 역할은 대상 주소와 앱 데이터를 서버에 전달하는 것으로, 프로토콜 자체에 복잡한 라우팅이나 관리 기능을 많이 넣지 않습니다. VMess는 V2Ray 생태계에서 나온 프로토콜로, 사용자 식별과 요청 인증, 데이터 전달을 자체 구조로 처리합니다. 두 프로토콜 모두 다양한 클라이언트에서 오랫동안 지원되어 왔습니다. 하지만 오래 사용되었다고 해서 모든 구형 설정, 암호화 방식, 확장 플러그인이 현재 구현에서도 적절하다는 뜻은 아닙니다.

SS는 암호화 방식과 설정을 정확히 맞춰야 합니다

SS에서는 서버 주소, 포트, 비밀번호, 암호화 방식을 한 세트로 정확히 맞춰야 합니다. AEAD 방식은 데이터 무결성을 검증하며, 사용할 수 있는 암호화 방식은 양쪽 구현에 따라 다를 수 있습니다. 최신 프로토콜 변형은 별도의 키 형식을 요구할 수 있으므로, 특정 인코딩의 키가 필요한 곳에 일반 비밀번호를 임의로 입력하면 안 됩니다. 인증에 실패하면 우선 암호화 방식 이름, 비밀번호 누락 여부, 구독 만료 여부를 확인하세요. 로컬 DNS를 끄거나 규칙을 바꾸는 것은 그다음입니다.

SS는 구조가 단순해 프로토콜 계층의 처리 부담을 줄일 수 있지만, 실제 CPU 사용량은 암호화 알고리즘, 프로세서의 명령어 지원, 구현 최적화에 따라 달라집니다. 한 기기는 AES 하드웨어 가속을 지원할 수 있고, 다른 기기에는 다른 암호화 방식이 더 효율적일 수 있습니다. 어떤 알고리즘이 모든 기기에서 항상 배터리를 덜 쓴다고 할 수는 없습니다. 설정에 플러그인이 포함되어 있다면 플러그인의 핸드셰이크, 프로세스, 호환성에 따른 비용도 고려해야 합니다. 기본 SS만 비교하면 실제 연결 경로의 부담을 과소평가할 수 있습니다.

VMess는 인증 방식과 전송 조합을 확인하세요

VMess는 UUID 등의 매개변수로 사용자를 식별하며, 과거에는 여러 인증 방식이 사용되었습니다. 현재 유지 관리되는 구현은 대체로 최신 인증 방식을 사용하므로 구형 튜토리얼의 호환성 필드를 그대로 복사하지 마세요. 일부 인증 검사는 시스템 시간의 영향을 받습니다. 기기 시간이 크게 어긋나면 요청이 거부될 수 있습니다. 문제를 해결할 때는 먼저 시스템의 자동 시간 설정을 복구하고 사용자 식별 정보와 서버 요구 사항을 확인하세요. GUI 클라이언트를 반복해서 다시 설치해도 시간이나 인증 매개변수 불일치는 해결되지 않습니다.

VMess는 WebSocket, TLS와 함께 사용되는 경우도 많습니다. 이때 대상 포트에 TCP 연결이 된다고 해서 프록시 경로 전체가 정상이라는 뜻은 아닙니다. TLS 서버 이름, WebSocket 경로, 요청 헤더, 서버 라우팅 설정이 모두 일치해야 합니다. 연결 직후 끊긴다면 각 계층을 차례로 확인하세요. 화면에 모두 VMess라고 표시된다는 이유로 두 접속 설정을 서로 바꿔 사용할 수 있다고 보면 안 됩니다. 같은 프로토콜 이름 아래에서도 전송 캡슐화 방식에 따라 연결 비용이 크게 달라질 수 있습니다.

현재 SS 또는 VMess 접속이 평소 사용하는 네트워크에서 안정적이고 앱에 필요한 TCP·UDP 및 플랫폼 호환성을 충족한다면, 프로토콜 이름만 보고 바꿀 필요는 없습니다. 반대로 기존 접속이 클라이언트에서 더 이상 지원하지 않는 플러그인이나 인증 방식에 의존한다면 설정 제공자에게 지원되는 접속 정보를 요청하세요. 소프트웨어 전체를 구형 상태로 유지하는 것은 해결책이 아닙니다. 기본 프로토콜의 적합성은 기능이 적다고 뒤처졌다고 판단할 것이 아니라, 실제 연결 경로와 유지 관리 요구 사항을 충족하는지로 평가해야 합니다.

Trojan과 VLESS: 보안 계층을 구분해서 보기

Trojan은 TLS 연결 안에서 프록시 인증과 트래픽 전달을 처리하며, 검증된 TLS 메커니즘으로 전송을 보호합니다. VLESS는 Xray 등의 생태계에서 나온 프로토콜로, 더 가벼운 프로토콜 헤더와 사용자 식별 방식을 사용하고 전송 보안은 외부 보안 계층에 맡깁니다. 두 프로토콜 모두 최신 구독에서 볼 수 있지만 같은 뜻은 아닙니다. 일반적인 Trojan 배포는 TLS를 중심으로 구성되며, VLESS는 설정된 보안 계층과 전송 방식의 조합에 따라 실제 동작이 달라집니다.

Trojan에서 인증서는 부가 요소가 아닙니다

일반적인 Trojan 설정에는 서버 주소, 포트, 비밀번호, TLS 서버 이름이 포함됩니다. 주소는 서버로 연결을 보내고, 서버 이름은 서버 인증에 사용됩니다. 주소가 IP인 경우에도 서버 이름과 인증서는 별도로 지정해야 할 수 있습니다. 인증서 체인, 유효 기간, 시스템 신뢰 저장소, 기기 시간이 핸드셰이크에 영향을 줍니다. 이름이 일치하지 않으면 인증서 검증을 무조건 끄지 말고 먼저 접속 안내를 확인하세요. 검증을 건너뛰면 서버의 신원을 신뢰성 있게 확인하지 못할 수 있습니다.

프록시 연결의 TLS 오류와 브라우저에서 대상 사이트를 열 때 발생하는 인증서 오류도 구분해야 합니다. 일반적인 프록시 전송은 브라우저의 HTTPS를 복호화하지 않습니다. 브라우저 오류는 시스템 시간, 대상 사이트의 인증서, 시스템에 설치된 검사 프록시, 비정상적인 출구 경로 때문에 발생할 수 있습니다. 특정 사이트 하나만 실패한다면 먼저 해당 사이트를 확인하세요. 모든 HTTPS 사이트에서 문제가 생기면 시스템 프록시 경로와 인증서 환경을 점검하세요. 관련 내용은 프록시 사용 후 발생하는 인증서 오류 해결에서 확인할 수 있습니다.

VLESS가 가볍다고 보안 설정을 생략해도 되는 것은 아닙니다

VLESS 자체는 독립적인 암호화 채널과 동등한 데이터 보호를 제공하지 않습니다. 따라서 실제 배포에서 TLS, REALITY 또는 지원되는 다른 보안 메커니즘을 사용하는지 알아야 합니다. 구독에 포함된 UUID, 서버 이름, 공개 키, 짧은 ID, 흐름 제어 필드는 각각 역할이 다르며 서로 대체할 수 없습니다. 일부 설정은 특정 전송 방식과 커널 기능이 있어야만 사용할 수 있습니다. 입력란이 있다고 해서 임의의 필드 조합이 정상적으로 연결되는 것은 아닙니다.

REALITY는 보안 계층과 관련된 기능이지, 단독으로 선택할 수 있는 별도의 프록시 프로토콜이 아닙니다. Vision도 양쪽 설정이 일치해야 하는 흐름 제어 설정이며, 모든 VLESS 노드에 적용하는 가속 옵션이 아닙니다. 이런 필드를 임의로 추가하면 정상적으로 연결되던 접속이 실패할 수 있습니다. 먼저 설정 제공자가 준 조합을 그대로 보존하고 현재 커널의 지원 범위를 확인하세요. 서버가 해당 기능을 활성화한 것이 확인된 경우에만 매개변수 조정이나 전송 방식 변경을 검토해야 합니다.

연결 경험 측면에서 Trojan과 VLESS는 모두 품질이 좋은 TCP 경로에서 잘 작동할 수 있지만, 복잡한 캡슐화, 서버 혼잡, 잘못된 라우팅 때문에 느려질 수도 있습니다. 외부 TLS의 영향은 연결 재사용, 세션 복구, 구현 방식에 따라 달라지므로 ‘암호화 계층이 하나 더 있다’는 이유만으로 지연 시간을 단정할 수 없습니다. 같은 대상과 비슷한 네트워크 조건에서 최초 연결과 이미 연결된 상태를 나눠 비교하세요. 브라우저에서 새로고침을 반복하면 기존 연결을 재사용할 수 있어 프로토콜의 초기 연결 비용을 제대로 보여 주지 못합니다.

인증서와 비밀번호를 직관적으로 설정하고 싶다면 서버에서 제공하는 Trojan 접속 정보가 항목별로 확인하기 쉬운 편입니다. 서버가 특정 보안 계층을 사용하는 VLESS를 제공한다면 해당 조합을 명확히 지원하는 유지 관리 중인 클라이언트를 선택하세요. 중요한 것은 이름이 더 최신인지가 아니라 매개변수가 완전하고 양쪽 설정이 일치하는지입니다. 현재 접속이 안정적이라면 반복 가능한 비교 결과를 먼저 확보한 뒤 변경 여부를 결정하세요.

Hysteria2와 TUIC: 먼저 UDP 경로를 확인하세요

Hysteria2와 TUIC는 모두 QUIC으로 프록시 연결을 구성하지만 같은 프로토콜의 다른 이름은 아닙니다. QUIC은 보통 UDP에서 동작하며 암호화 핸드셰이크, 다중 스트림 전송, 혼잡 제어를 통합합니다. TCP의 순서 보장 때문에 한 스트림의 지연이 다른 스트림에 영향을 주는 현상을 일부 줄일 수 있습니다. 그렇더라도 데이터 수신을 확인하고 손실된 데이터를 재전송하며 전송량 제한을 따라야 합니다. 네트워크 용량 제한을 우회하는 통로는 아닙니다. 서버 대역폭이 부족하다면 QUIC으로 바꿔도 출구 용량이 늘어나지 않습니다.

Hysteria2의 대역폭 설정에는 실제 근거가 필요합니다

Hysteria2는 높은 처리량과 복잡한 네트워크 경로에 대한 적응을 주요 목표로 설계되었습니다. 대역폭 추정과 혼잡 제어 관련 옵션은 양쪽 구현과 실제 설정을 고려해 이해해야 합니다. 클라이언트의 업로드·다운로드 대역폭 입력란은 요금제 광고에 나온 수치도, 값이 클수록 성능이 좋아지는 설정도 아닙니다. 실제 네트워크 용량보다 훨씬 높은 값을 넣으면 대기열과 패킷 손실이 늘어 같은 네트워크의 음성 통화나 웹 사용이 나빠질 수 있습니다. 잘 모르겠다면 다른 네트워크의 수치를 따라 하지 말고 서버 제공자의 안내와 현재 커널 문서를 따르세요.

Hysteria와 Hysteria2도 유형 이름만 바꿔 서로 전환할 수는 없습니다. 프로토콜과 매개변수가 다르므로 인증 및 난독화 설정을 서버에 맞춰야 합니다. 기존 가이드에서 현재 접속에 필요하지 않은 필드를 추가하면 인증 전에 연결이 끊길 수 있습니다. 연결이 실패하면 구독에 표시된 프로토콜 버전, 포트, 인증 매개변수부터 확인한 다음 TLS 이름과 UDP 연결 가능 여부를 살펴보세요. 혼잡 제어는 보통 핸드셰이크 자체가 실패하는 첫 번째 원인이 아닙니다.

TUIC의 전송 기능과 설정 버전을 구분하세요

TUIC도 QUIC 연결에서 프록시 트래픽을 전달하며 TCP와 UDP 포워딩을 고려합니다. 인증, UDP 포워딩 모드, 혼잡 제어 옵션은 서버, 구독 형식, 커널에서 모두 지원해야 합니다. TUIC 설정은 버전에 따라 인증 필드가 다를 수 있으므로 프로토콜 약어만으로 호환 여부를 판단할 수 없습니다. 어떤 필드 조합이 필요한지 접속 정보를 확인하세요. 변환 도구가 표현할 수 없는 옵션을 알리지 않고 삭제해 버린 뒤 연결 실패를 회선 불안정으로 오해하지 않도록 주의해야 합니다.

일부 설정은 0-RTT 핸드셰이크나 관련 복구 옵션을 제공합니다. 세션 복구 같은 조건이 충족될 때만 대기 시간이 줄어들 수 있으며, 재전송 공격과 관련된 의미 등 구현 측에서 처리해야 할 제약도 있습니다. 이를 전체 연결을 빠르게 해 주는 스위치로 여기지 마세요. 클라이언트 최초 실행, 네트워크 전환, 서버 재시작, 세션 티켓 만료에 따라 연결 과정이 달라질 수 있습니다. 일상적인 선택에서는 짧은 테스트에서 핸드셰이크가 한 번 줄었는지보다 지속 전송, 복구 능력, 앱 호환성을 확인하는 것이 중요합니다.

호텔, 사무실의 게스트 네트워크, 일부 모바일 네트워크는 UDP를 제한하거나 지속적인 UDP 트래픽에 별도의 정책을 적용할 수 있습니다. QUIC 접속이 한 네트워크에서는 정상인데 다른 네트워크에서 실패해도 구독이 만료된 것은 아닐 수 있습니다. 지원되는 TCP 기반 접속을 비교용으로 남겨 두고 같은 기기에서 다시 테스트하세요. 모바일 기기에서 네트워크 전환 후 연결을 복구할 수 있는지는 클라이언트, 커널, 서버 구현에 따라 다릅니다. QUIC에 연결 마이그레이션 기능이 있다는 이유로 모든 프록시 세션이 네트워크를 바꿔도 끊기지 않는다고 보장할 수는 없습니다.

따라서 Hysteria2나 TUIC를 선택하려면 연결 경로를 사용할 수 있고 양쪽 설정이 명확해야 합니다. 왕복 지연 시간이 길거나 연결 품질이 불안정한 환경에서는 후보가 될 수 있지만, 결과는 직접 테스트해야 합니다. 가벼운 웹 사용과 백그라운드 대기가 주된 용도라면 배터리 효율이나 연결 속도는 기존 접속과 직접 비교해야 합니다. 대용량 파일 전송 결과만으로 판단할 수는 없습니다.

속도·리소스·모바일 배터리 비교 방법

프로토콜 비교에서는 서로 다른 지표를 하나의 ‘속도’로 뭉뚱그리기 쉽습니다. 연결 대기 시간, 페이지 첫 바이트 도달 시간, 지속 다운로드 처리량, 상호작용 지연의 변동, 연결 성공률은 각각 다른 질문에 답합니다. 대용량 파일 전송이 빠른 접속도 짧은 연결이나 신호가 약한 환경에서는 만족스럽지 않을 수 있습니다. 지연 시간 테스트에서 한 번 좋은 결과가 나와도 저녁에 서버 부하가 늘면 자주 시간 초과가 발생할 수 있습니다. 앱에 필요한 조건부터 정한 뒤 측정할 항목을 선택하세요. 그렇지 않으면 측정값이 많아질수록 결론이 실제 요구에서 멀어질 수 있습니다.

반복 가능한 비교 절차 만들기

기기, 네트워크, 클라이언트, 대상 리소스, 프록시 모드를 고정하고 백그라운드 다운로드나 시스템 업데이트가 대역폭을 사용하지 않는지 확인하세요. 여러 접속을 동시에 켜 서로 대역폭을 차지하게 하지 말고 후보를 차례로 테스트합니다. 테스트 시간, 최초 연결 여부, 네트워크 전환 여부를 기록하고 여러 차례 결과의 분포를 살펴보세요. 서로 다른 프로토콜 접속이 다른 데이터센터나 출구를 사용한다면, 현재 환경에 어느 접속이 더 적합한지만 알 수 있습니다. 차이를 전부 프로토콜 작동 방식 탓으로 돌릴 수는 없습니다.

짧은 연결 테스트에서는 페이지를 처음 열 때와 연속해서 열 때의 차이를 살펴볼 수 있지만 브라우저 캐시, 연결 풀, HTTP 연결 재사용을 고려해야 합니다. 지속 전송에서는 웹, 음성 통화, 원격 터미널의 반응이 영향을 받는지도 확인하세요. 다운로드 속도는 올랐지만 상호작용이 눈에 띄게 느려졌다면 전체 성능 개선이 아니라 대기열이 쌓인 것일 수 있습니다. 노드 목록에 표시되는 테스트 결과는 대개 지정된 테스트 주소만 대상으로 합니다. 실제 앱 검증을 대신할 수 없으며 서버 리소스 사용량을 간접적으로 측정한 값으로 봐서도 안 됩니다.

CPU와 메모리는 실행 환경과 함께 평가하세요

클라이언트 전체 리소스 사용량에는 GUI, 커널, 규칙 집합, DNS 캐시, 연결 추적, 로그가 포함됩니다. 프로토콜은 그중 일부일 뿐입니다. 규칙과 연결이 많으면 메모리 사용량이 늘 수 있고, 상세 로그, 연결 목록의 잦은 새로고침, 그래픽 렌더링도 부하를 높입니다. 비교할 때는 로그 수준과 규칙 규모를 비슷하게 맞추고, 유휴 상태의 사용량과 전송 중 증가량을 구분하세요. 데스크톱 작업 관리자가 보여 주는 앱 전체 사용량만으로 특정 프로토콜 헤더가 더 복잡하다고 결론 내릴 수는 없습니다.

암호화 알고리즘의 하드웨어 가속 지원, 기기의 절전 모드, 시스템의 클럭 제한 여부에 따라 CPU 결과가 달라집니다. 저사양 라우터와 최신 노트북의 결과 순서는 반대일 수도 있습니다. 서버 CPU가 최대 부하 상태여도 클라이언트에서는 속도가 불안정하게 보일 수 있지만, 로컬에서 관찰하는 것만으로 원인을 확인할 수는 없습니다. 서버 모니터링이나 설정 제공자의 안내를 함께 확인하세요. 테스트 중 기기가 뜨거워지고 성능이 떨어지는지도 기록해 두어야 발열로 제한된 결과를 프로토콜 자체의 한계로 오해하지 않습니다.

배터리는 프로토콜 이름보다 사용 패턴이 좌우합니다

모바일 배터리 소모는 무선 모듈 활성화, 약한 신호에서의 재전송, 연결 유지, 백그라운드 제한, 화면 밝기와 함께 결정됩니다. 장시간 처리량 테스트는 전송 효율을 비교하는 데 적합하지만 하루 종일 대기할 때의 성능을 보여 주지는 않습니다. 작은 데이터의 연결 유지가 잦으면 무선 모듈이 더 오래 활성 상태로 남을 수 있고, 연결을 너무 적극적으로 정리하면 핸드셰이크를 반복해야 합니다. QUIC, TCP, 시스템 프록시, TUN 중 무엇이 배터리를 덜 쓰는지는 이름만으로 판단할 수 없습니다. 실제 트래픽과 백그라운드 정책이 더 중요한 경우가 많습니다.

설정을 최적화할 때는 한 번에 변수 하나만 바꾸고 원래 설정을 보존하세요. 먼저 불필요한 고빈도 로그와 화면 새로고침을 끄고, 그다음 연결 유지, 동시 연결 수, 프로토콜 매개변수를 조정할 필요가 있는지 확인합니다. 접속을 바꾼 뒤 배터리 소모가 줄었더라도 출구 경로와 신호 환경까지 바뀌었다면 조합 전체의 결과로만 기록해야 합니다. 일반 사용자에게는 최고 처리량이 조금 더 높지만 계속 관리해야 하는 접속보다 안정적으로 연결되고 대기 중 소모가 적으며 복구하기 쉬운 접속이 더 유용할 수 있습니다.

원본 Clash, Meta, mihomo의 관계

원본 Clash는 설정, 프록시 그룹, 규칙 기반 라우팅을 사용하는 체계를 만들었습니다. 이후 호환성과 기능 확장을 위해 여러 파생 버전이 등장했습니다. Clash Meta는 이후 mihomo라는 이름으로 개발을 이어 갔습니다. 따라서 현재 Meta와 mihomo를 이야기할 때는 별도로 설치해야 하는 두 커널이 아니라 같은 개발 계보를 가리키는 경우가 많습니다. 오래된 글에서 Meta라는 이름을 사용하는 것은 흔합니다. 자료의 적용 가능성을 확인할 때는 제목의 이름보다 설정 필드와 구현 기능을 살펴보세요.

GUI 클라이언트와 네트워크 커널은 다릅니다

Clash Plus, Clash Verge Rev, FlClash 등의 클라이언트는 설정 관리와 시스템 연동을 담당합니다. 실제 네트워크 동작은 내부에서 사용하는 커널과 빌드 방식에도 좌우됩니다. GUI 업데이트와 커널 업데이트 주기는 서로 다를 수 있으며, 설정에 옵션이 표시되더라도 플랫폼 권한이나 현재 빌드의 제한 때문에 사용할 수 없을 수 있습니다. 지원 기능을 확인할 때는 정보 페이지, 커널 정보, 실행 로그를 확인하세요. 설치 파일 이름만 보고 모든 mihomo 기능을 지원하거나 플랫폼마다 동일하게 동작한다고 가정하지 마세요.

mihomo는 원본 Clash에 비해 프로토콜, 규칙 유형, DNS 기능, 트래픽 처리 기능을 확장했지만 실제 지원 범위는 사용 중인 빌드의 문서를 확인해야 합니다. 원본 설정의 여러 기본 필드를 계속 사용할 수 있다고 해서 새 설정까지 구형 커널에서 사용할 수 있는 것은 아닙니다. 구독에 새 프로토콜이나 필드가 포함되어 있는데 사용자는 이를 인식하지 못하는 구형 구현을 계속 사용하는 상황이 마이그레이션에서 흔히 발생합니다. 자세한 차이는 mihomo와 원본 Clash 커널 비교에서 확인하세요.

설정 호환성은 세 단계로 확인하세요

첫 번째는 YAML 들여쓰기, 목록 구조, 문자열 유형 등이 올바른지 확인하는 문법 단계입니다. 두 번째는 프로토콜, 규칙 유형, DNS 옵션 등의 필드를 구현에서 인식하는지 확인하는 지원 단계입니다. 세 번째는 TUN 권한, 시스템 라우팅, 포트 사용 여부, 서비스 모드 등 실행 조건을 확인하는 단계입니다. 첫 번째 단계가 통과했다는 것은 파일을 읽을 수 있다는 뜻일 뿐, 나머지 두 단계까지 정상이라는 뜻은 아닙니다. ‘가져오기는 성공했지만 사용할 수 없음’ 문제는 이 세 단계를 따라가며 확인해야 합니다.

TUN 모드는 특히 여러 구성 요소의 역할이 얽히기 쉽습니다. 클라이언트는 시스템의 트래픽 처리 기능을 생성하거나 호출하고, 커널은 전달된 트래픽을 처리하며, 운영체제는 권한과 라우팅을 허용할지 결정합니다. 스위치를 켜도 효과가 없다면 서비스 실행 여부, 라우팅 설정 여부, 다른 VPN이나 네트워크 도구와의 충돌을 확인하세요. 프로토콜을 바꾸면 현상이 달라질 수 있지만 트래픽 처리 계층의 문제를 해결해 주지는 않습니다. 시스템 네트워크를 변경하기 전에 기존 설정을 저장하고 트래픽 처리 기능을 끌 수 있는 복구 방법을 준비하세요.

클라이언트는 이 사이트에서 Clash Plus를 우선 추천하지만, 플랫폼과 필요한 기능에 맞는 설치 항목인지 확인해야 합니다. Linux에서는 Clash Verge Rev와 FlClash를 우선 비교할 수 있으며, 다른 플랫폼의 후보와 아키텍처별 설치 파일은 클라이언트 다운로드 페이지에서 확인하세요. Clash for Windows와 ClashX Meta는 유지 관리가 중단된 보관용 선택지입니다. 과거 설정을 살펴보는 용도로는 쓸 수 있지만, 오래된 튜토리얼의 화면이 익숙하다는 이유만으로 새 설치의 기본 선택지로 삼는 것은 권장하지 않습니다. 이전할 때는 기존 설정을 복사해 보관하고, 새 클라이언트에서 최소 연결을 확인한 뒤 규칙, DNS, 트래픽 처리 설정을 복원하세요.

구독 형식과 설정 필드의 호환 범위

구독은 설정을 배포하는 방식이지 프록시 프로토콜이 아닙니다. 링크가 전체 YAML, 노드 목록, 인코딩된 공유 링크 모음, 다른 커널용 JSON을 반환할 수 있습니다. 클라이언트가 텍스트를 다운로드했다고 해서 현재 파서에서 사용할 수 있다는 뜻은 아닙니다. 가져오기에 실패했다면 노드 매개변수를 논하기 전에 응답 형식과 대상 클라이언트 유형부터 확인하세요. 그렇지 않으면 로그인 페이지, 오류 페이지, 다른 형식의 설정을 YAML로 오해해 반복해서 수정할 수 있습니다.

전체 설정과 노드 제공자 데이터는 다릅니다

전체 설정에는 보통 프록시, 정책 그룹, 규칙, DNS, 리스너 설정이 포함됩니다. 노드 제공자는 주 설정에서 참조할 수 있는 프록시 항목을 주로 제공합니다. 둘 다 YAML을 사용하더라도 가져오는 위치를 서로 바꿔 사용할 수는 없습니다. 전체 설정을 노드 목록만 받는 위치에 넣으면 구조 오류가 날 수 있습니다. 반대로 노드 목록만 가져오고 정책 그룹과 규칙이 없으면 기대한 방식으로 트래픽을 분기할 수 없습니다. 클라이언트의 ‘설정 가져오기’와 ‘제공자 추가’가 각각 어떤 구조를 받는지 먼저 확인하세요.

프로토콜 공유 링크에 모든 배포 정보가 포함되는 것도 아닙니다. 일부 필드는 링크 매개변수로 표현할 수 있지만, 별도 약속이 필요한 필드도 있습니다. 파서에 따라 이름 인코딩, 특수 문자, 확장 매개변수를 처리하는 방식이 다를 수 있습니다. 노드 이름이 깨져 보여도 연결에는 영향이 없을 수 있지만, 비밀번호, 경로, 인증 정보가 잘못 디코딩되면 연결이 실패합니다. 다시 가져올 때는 원본 링크를 보관해 로컬에서 비교하고, 인증 정보가 포함된 전체 내용을 공개 게시판에 붙여 넣지 마세요.

변환은 정보를 재배치할 뿐 기능을 만들어 내지 못합니다

구독 변환은 기존 노드 정보를 다른 구조로 정리할 수 있지만, 구형 커널에 Hysteria2 지원 기능을 추가하거나 누락된 필드에서 서버 공개 키를 추론할 수는 없습니다. 변환 도구가 알 수 없는 매개변수를 삭제하거나 규칙을 바꾸고 DNS 설정을 덮어쓸 수도 있습니다. 현재 커널을 지원한다고 설정 제공자가 명시한 형식을 우선 사용하세요. 변환이 필요하다면 변환 전후의 프로토콜 유형과 주요 필드를 비교하고, 처리 과정에서 구독 링크와 인증 정보에 접근하는지도 확인해야 합니다.

다음은 원격 노드 없이 독립적으로 파싱할 수 있는 로컬 라우팅 예시입니다. 리스닝 포트, 모드, 규칙 순서만 보여 줍니다. 실행하면 해당 포트를 통과하는 연결은 직접 연결되며 프록시 출구를 자동으로 사용하지 않습니다. 커널이 실행되는지와 원격 노드에 연결되는지를 따로 확인할 때 적합합니다. 실제 사용 시에는 이 예시로 구독 설정을 덮어쓰지 말고, 지원되는 기존 설정을 복원하세요. 이 예시에는 원래 노드가 포함되어 있지 않습니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

YAML은 들여쓰기 구조가 중요합니다. 목록 항목과 해당 필드의 위치를 맞추고 탭과 공백을 섞어 쓰지 마세요. 포트에는 올바른 숫자를 입력하고 특수 문자가 포함된 문자열은 YAML 문법에 맞게 따옴표로 묶어야 합니다. 먼저 파싱 오류를 수정한 뒤 프로토콜 필드를 확인하세요. 그렇지 않으면 로그에 가장 먼저 발견된 문법 문제만 표시되어 이후의 실제 설정 오류가 가려질 수 있습니다. 규칙은 작성 순서대로 적용되므로 범위가 넓은 규칙을 앞에 두면 뒤의 세부 규칙이 무효화될 수 있습니다. 구체적인 문법은 사용자 지정 규칙 문법과 우선순위에서 확인하세요.

구독을 업데이트하기 전에 로컬 수정 사항을 보관하세요

자동 업데이트는 로컬 설정을 원격 내용으로 바꿔 수동으로 수정한 규칙이나 DNS 설정을 지울 수 있습니다. 클라이언트에서 공식 지원하는 오버라이드, 병합, 별도 규칙 관리 기능을 우선 사용하고 적용 순서도 확인하세요. 업데이트가 실패하면 요청 상태, 응답 형식, 파싱 로그부터 살펴본 뒤 링크를 바꿀지 판단합니다. 반복해서 다시 시도해도 만료된 인증은 복구되지 않습니다. 서버가 오류 페이지를 반환하는 문제를 변환으로 감추려 해서도 안 됩니다. 자세한 내용은 FAQ의 설치 및 설정 또는 문제 해결 항목에서 확인할 수 있습니다.

사용 환경에 맞게 선택하고 문제 해결 경로를 남겨 두세요

실용적인 선택은 6개 프로토콜 중 하나를 영구적으로 고르는 것이 아니라, 주 접속과 조건이 다른 대체 접속을 마련하는 것입니다. 주 접속은 일상적인 네트워크와 앱, 배터리 요구를 충족해야 합니다. 대체 접속은 네트워크 경로와 로컬 설정 중 무엇이 달라졌는지 구분하는 데 사용합니다. 예를 들어 한 접속은 UDP에 의존하고 다른 접속은 지원되는 TCP 전송을 사용할 수 있습니다. 프로토콜 이름을 채우기 위해 출처가 불분명한 접속을 많이 남겨 두지 마세요. 관리 부담도 사용 비용에 포함됩니다.

일상적인 웹 사용과 모바일 업무

웹페이지, 문서, 메신저는 보통 안정적인 연결과 백그라운드 복구를 중요하게 여깁니다. 기존 SS, Trojan 또는 지원되는 다른 접속이 안정적으로 작동한다면 먼저 그대로 사용하고 절전 모드 해제, 네트워크 전환, 장시간 대기 후 동작을 살펴보세요. 모바일에서는 운영체제가 백그라운드 실행을 제한하는지, 다른 VPN과 충돌하는지도 확인해야 합니다. iOS에서는 다운로드 페이지에서 Clash Plus를 선택하고 공식 사이트 clashplus.io의 안내를 확인할 수 있습니다. Android에서는 배터리 최적화와 앱 트래픽 처리 범위를 특히 주의해서 살펴보세요.

대용량 파일, 불안정한 네트워크, 실시간 앱

지속 다운로드를 테스트할 때는 현재 네트워크의 UDP 경로가 안정적인 경우 Hysteria2, TUIC, 기존 TCP 기반 접속을 함께 비교할 수 있습니다. 네트워크 상태가 좋지 않다면 최대 처리량보다 연결 성공률, 복구 시간, 상호작용 지연의 변동을 먼저 확인하세요. 게임, 음성 통화, 실시간 통신은 앱 트래픽이 실제로 처리되는지, 노드가 필요한 데이터그램 전달을 지원하는지, 서버 출구가 대상 서비스에 적합한지도 확인해야 합니다. 전역 모드를 켠다고 시스템 프록시를 거치지 않는 앱까지 모두 처리되는 것은 아닙니다. 필요한 경우 지원되는 TUN 방식을 확인하세요.

실시간 앱에 문제가 생기면 ‘로그인되지만 세션에 들어갈 수 없음’, ‘한쪽만 음성이 들림’, ‘계속 끊김’을 구분해 기록하세요. 각각 다른 연결이나 포트와 관련될 수 있습니다. 먼저 연결 목록에 해당 트래픽이 나타나는지 보고, 규칙에 어떤 정책이 적용됐는지 확인한 뒤 프로토콜을 바꾸세요. 다른 프로토콜로 정상화되더라도 UDP 지원, 서버 경로, 설정 차이 중 무엇이 원인인지 추가로 확인해야 합니다. 우연히 효과가 있었던 전환을 일반적인 해결책으로 여기지 마세요.

데스크톱, 라우터, 여러 사람이 함께 쓰는 환경

데스크톱 클라이언트는 구독, 로그, 시스템 프록시를 GUI로 관리하기에 적합합니다. 서버나 라우터에서는 리스닝 주소, 권한, 프로세스 관리, 리소스 제한을 이해하는 것이 더 중요합니다. 로컬 네트워크 연결을 허용하면 리스닝 범위가 넓어지므로 접근 제어도 함께 설정해야 합니다. 로컬 전용 기본값을 공유 네트워크에 그대로 적용하면 안 됩니다. 커널 패키지에는 GUI 클라이언트의 시스템 연동 기능이 모두 포함되어 있지 않습니다. 일반 사용자는 GUI 클라이언트를 먼저 선택하고, ‘더 낮은 계층’을 쓴다는 이유로 배포를 복잡하게 만들 필요는 없습니다.

여러 사람이 함께 사용할 때는 프로토콜 헤더 차이보다 대역폭 경쟁, DNS 정책, 규칙 관리가 더 중요한 경우가 많습니다. 특정 기기의 대용량 다운로드 때문에 다른 기기가 느려진다면 모든 기기의 프로토콜을 바꾸기 전에 대역폭 사용량과 대기열을 확인하세요. 라우터 부하가 높다면 프로세서 성능, 연결 수, 규칙 규모도 살펴봐야 합니다. 기기 리소스 부족은 실행 환경의 한계입니다. 복잡한 규칙을 늘리거나 트래픽 처리 기능을 더 켜는 것으로 해결되지는 않습니다.

최단 경로로 문제 원인 찾기

가져오기가 전혀 안 되면 응답과 문법을 확인하세요. 가져오기는 되지만 커널이 시작되지 않으면 필드, 포트, 권한을 살펴봅니다. 커널은 실행되지만 노드에 연결되지 않으면 인증, TLS, 전송 경로를 확인하세요. 노드는 사용할 수 있지만 특정 앱만 실패한다면 트래픽 처리 여부, DNS, 규칙, 앱 자체를 살펴봐야 합니다. 한 번에 조건 하나만 바꾸고 변경 전후 결과를 기록하세요. 클라이언트를 열자마자 종료되면 프로토콜 속도를 논하기 전에 시작 직후 종료되는 문제의 로그 확인 절차를 따라 해결하세요.

주 접속이 꾸준히 안정적이고 대체 접속으로 네트워크 문제를 구분할 수 있으며 설정 업데이트가 중요한 항목을 덮어쓰지 않는다면, 이미 관리하기 좋은 구성이 갖춰진 것입니다. 프로토콜 가이드는 모든 설정을 가장 복잡하게 유지하기 위한 것이 아니라 다음 장애를 명확한 단계에 따라 설명하고 해결하기 위한 자료입니다. 검증된 조합 몇 가지를 잘 관리하는 편이 프로토콜 이름의 변화만 따라가는 것보다 장기적으로 유용합니다.