Clash 프로토콜 및 커널 선택

선택 기준과 확인 순서: 먼저 다섯 가지 계층을 구분하세요

Clash 설정에 표시되는 SS, VMess, Trojan 등의 이름은 프록시 엔드포인트 간의 인증·캡슐화·데이터 전달 방식을 나타냅니다. 애플리케이션 트래픽이 클라이언트로 들어오는 방식과는 별개입니다. 브라우저가 시스템 프록시를 사용하는 경우, 앱이 로컬 SOCKS 포트에 연결하는 경우, TUN이 시스템 라우팅을 처리하는 경우는 각각 다른 진입 경로입니다. 진입 경로에 따라 프록시가 처리하는 범위는 달라질 수 있지만, 서버 측 프로토콜이 다른 프로토콜로 바뀌지는 않습니다. 선택할 때는 먼저 로컬 진입 경로와 원격 프로토콜을 구분해야 진입 경로 문제를 프로토콜 성능 문제로 오인하지 않습니다.

클라이언트 인터페이스와 커널 기능을 구분하세요

클라이언트는 구독 관리, 프록시 그룹 인터페이스, 시스템 프록시 전환, 권한 요청을 담당합니다. 커널은 설정을 읽고 규칙을 적용하며 도메인을 확인하고 아웃바운드 연결을 설정합니다. 인터페이스에 특정 프로토콜 이름이 표시된다고 해서 현재 실행 중인 커널이 모든 확장 기능을 지원하는 것은 아닙니다. 반대로 커널이 특정 필드를 읽을 수 있어도 클라이언트 편집기에는 그 값을 입력할 항목이 없을 수 있습니다. 지원 범위를 확인할 때는 클라이언트 이름, 실제 실행 중인 커널 이름, 노드의 전송 방식 조합을 함께 기록하세요.

프로토콜 이름에는 전송 계층과 보안 계층이 추가로 결합될 수 있습니다. 예를 들어 VLESS는 여러 전송 방식을 사용할 수 있고 TLS 또는 REALITY와 함께 구성할 수도 있습니다. VMess도 프로토콜 인증과 외부 전송을 구분해야 합니다. 노드 두 개의 프로토콜 약칭만 비교하면 연결 경로의 중요한 요소를 놓치게 됩니다. 서버 주소, 경로 거리, 통신사 간 연결, 출구 혼잡, 서버 측 제한이 프로토콜 자체의 처리 비용보다 성능에 더 큰 영향을 줄 수도 있습니다.

연결 시간, 첫 바이트 응답 시간, 지속 처리량은 서로 다른 지표입니다

연결을 설정하는 데 걸리는 시간에는 도메인 조회, 전송 핸드셰이크, 인증, 보안 핸드셰이크가 포함될 수 있습니다. 웹페이지의 첫 바이트 응답 시간은 대상 사이트의 응답과 규칙 처리에도 영향을 받으며, 대용량 파일의 처리량은 혼잡 제어와 대역폭, 서버 자원의 영향을 더 많이 받습니다. 처음 연결할 때는 느려도 연결을 재사용하면 안정적인 프로토콜이 있는가 하면, 짧은 요청은 빠르지만 장시간 다운로드에서 서버 속도 제한을 받는 프로토콜도 있습니다. 테스트 전에 어떤 작업을 평가할지 정하고, 클라이언트에 표시되는 지연 시간 하나만 보지 마세요.

UDP 지원 여부도 각 계층에서 확인해야 합니다. 노드 프로토콜이 UDP 전달을 지원해도 현재 앱의 트래픽이 UDP 진입 경로를 통해 프록시에 들어온다는 뜻은 아닙니다. 노드 설정에서 UDP를 활성화해도 서버가 해당 전달을 허용한다는 보장은 없습니다. 게임, 음성 통화, 일부 실시간 통신 앱에서는 특히 이 점을 확인해야 합니다. QUIC 기반 아웃바운드 프로토콜은 클라이언트와 서버 사이에서 UDP 연결이 가능해야 합니다. 이 조건은 프록시 내부에서 전달되는 앱 트래픽이 UDP인지 여부와는 별개의 문제입니다.

나중에 다시 확인할 수 있는 선택 기준을 세우세요

실제 작업은 네 단계로 진행할 수 있습니다. 먼저 서버에서 제공한 전체 매개변수를 확인하고, 클라이언트 커널이 이를 지원하는지 점검한 다음, 진입 경로와 규칙이 제대로 적용되는지 검증합니다. 마지막으로 같은 작업에서의 사용 경험을 비교하세요. 우연히 측정된 최저 지연 시간 대신 연결 성공률, 첫 로딩, 지속 전송, 네트워크 전환 후 복구 상태를 기록하는 것이 좋습니다. 두 노드가 같은 서버나 경로를 사용하지 않는다면 결과는 두 서비스의 차이만 보여줄 뿐, 프로토콜 전체의 우열을 나타내지 않습니다. 이러한 조건을 테스트 기록에 남겨 두면 나중에 클라이언트를 바꿀 때도 판단 기준으로 활용할 수 있습니다.

Shadowsocks와 VMess: 간결한 전달 방식과 프로토콜 인증

Shadowsocks는 보통 SS로 줄여 부르며, 비교적 단순한 방식으로 암호화된 프록시 트래픽을 전달하는 데 중점을 둡니다. 일반적인 클라이언트는 TCP 연결과 UDP 데이터그램을 각각 처리하며 웹 전송 계층을 필수로 추가하지 않아 설정이 대체로 간결합니다. 간결한 이유는 프로토콜의 역할이 명확하기 때문이지, 모든 네트워크 문제를 자동으로 해결하기 때문은 아닙니다. 실제 보안성과 사용 가능 여부는 암호화 방식, 키 관리, 클라이언트 구현, 서버 설정에 따라 달라지므로 SS라는 이름만으로 결론 내릴 수 없습니다.

기존 AEAD 방식과 Shadowsocks 2022 구분하기

일반적인 AEAD 방식은 암호화와 메시지 인증을 결합해 수신 측에서 암호문이 변조되었는지 확인할 수 있습니다. Shadowsocks 2022는 별도로 지원 여부를 확인해야 하는 프로토콜 방식이며 기존 방식의 다른 이름이 아닙니다. 키 형식 등 매개변수 요구 사항이 다르고, 일부 서버는 다중 사용자 관련 규칙도 적용합니다. 기존 노드의 암호화 방식 이름만 다른 방식으로 바꿔서는 마이그레이션이 되지 않습니다. 서버와 클라이언트에서 호환되는 구현과 인증 정보를 사용해야 합니다.

SS 노드 문제를 확인할 때는 먼저 cipher가 지원되는지 점검한 다음 비밀번호나 키 형식, 서버 포트, UDP 설정을 확인하세요. 일부 노드는 플러그인에 의존하며, 플러그인의 전송 캡슐화는 SS 핵심 프로토콜과 별개입니다. 구독 변환 과정에서 플러그인 매개변수가 누락되면 노드 이름과 주소가 정상으로 보여도 연결되지 않을 수 있습니다. 이때는 로컬 수신 포트를 계속 바꾸기보다 원본 노드 안내를 다시 확인하세요.

VMess의 설계와 인증 범위

VMess는 V2Ray 생태계에서 시작된 프로토콜로, 사용자 인증과 프록시 요청 캡슐화를 포함하며 여러 기반 전송 방식과 조합할 수 있습니다. SS와의 차이는 비밀번호를 UUID로 바꾸는 데 그치지 않습니다. VMess에는 자체 요청 형식과 인증 방식, 데이터 보호 방식이 있으며 TLS나 WebSocket 같은 계층을 추가로 사용할 수도 있습니다. 사용자 식별자, 프로토콜 설정, 외부 전송 매개변수를 모두 맞춰야 하며, 어느 한 계층이라도 일치하지 않으면 핸드셰이크가 실패할 수 있습니다.

오래된 설정을 살펴보면 alterId 또는 alter-id 필드가 보일 수 있습니다. 이러한 필드는 과거 호환 경로와 관련이 있습니다. 현재 흔히 사용하는 VMess AEAD 설정에서는 보통 값이 0이지만, 이를 근거로 서비스 제공자가 지정한 다른 매개변수를 임의로 수정해서는 안 됩니다. 소프트웨어마다 필드 이름을 다르게 표시하기도 합니다. 오래된 가이드의 설정은 해당 커널 환경에 맞춰 이해하고, 다른 설정 형식의 객체를 Clash YAML에 그대로 붙여 넣지 마세요.

VMess 인증은 시스템 시간의 영향을 받습니다. 기기 시간이 크게 어긋나면 주소와 UUID가 올바르더라도 인증에 실패할 수 있습니다. 문제를 확인할 때는 인증서 검증을 느슨하게 설정하기보다 시스템 자동 시간 동기화가 정상인지 점검하세요. 시스템 시계는 TLS 인증서 유효 기간에도 영향을 주지만, 이는 인증 실패와는 별개의 문제입니다. 로그에 시간이나 인증 관련 오류가 나타나면 먼저 기기 시계를 바로잡고 다시 연결하세요.

자원 사용량과 적합한 환경 비교하기

네트워크가 안정적이고 엔드포인트 구현이 충분히 검증되었으며 별도 캡슐화가 없는 환경에서는 SS의 처리 경로가 비교적 단순해 폭넓은 호환성이 필요한 일상적인 트래픽 전달에 적합한 경우가 많습니다. VMess의 실제 처리 비용은 전송 방식 조합과 함께 평가해야 합니다. 직접 전송과 WebSocket·TLS를 거치는 연결은 핸드셰이크 횟수와 캡슐화 경로가 다릅니다. 여러 계층을 거치는 VMess와 직접 연결된 SS의 테스트 결과를 프로토콜 자체의 고정된 속도 차이로 단순화할 수는 없습니다.

모바일에서는 연결 수와 백그라운드 동작도 고려해야 합니다. 지속적으로 다운로드할 때는 암호화 연산이 자원 사용량의 일부를 차지할 수 있지만, 간헐적으로 메시지를 주고받는 환경에서는 무선 모듈 깨우기, DNS 요청, 연결 유지가 더 큰 영향을 줄 수 있습니다. SS나 VMess를 선택할 때는 서버에서 명확히 지원하고 현재 클라이언트가 완전히 읽을 수 있는 조합을 우선하세요. 오래된 노드가 더 이상 관리되지 않는 클라이언트에만 의존한다면, 구형 프로그램을 계속 사용하는 대신 서버 이전 방안을 검토하세요.

Trojan과 VLESS: 인증과 보안 전송의 역할

Trojan과 VLESS는 TLS와 함께 사용되는 경우가 많지만, 이름만 다른 같은 프로토콜은 아닙니다. 일반적인 Trojan 배포는 TLS 연결로 프록시 요청을 전달하고 비밀번호 관련 인증 정보로 사용자를 식별합니다. VLESS는 프록시 프로토콜 자체를 간결하게 유지하고 전송 보호는 외부 보안 계층에 맡기는 방식에 가깝습니다. 비교할 때는 인증, 전송 내용 보호, 서버 신원 확인을 구분해야 합니다. 이 세 가지 목적이 하나의 필드로 모두 처리되는 것은 아닙니다.

Trojan: TLS 연결 후 프록시 인증 확인

표준 Trojan 연결에는 올바른 TLS 설정이 필요합니다. 클라이언트가 접속하는 서버 주소는 도메인이나 IP일 수 있지만, TLS 검증은 인증서가 나타내는 신원과 관련이 있습니다. sni는 보통 서버 이름을 전송하고 연결 처리에 활용하는 값이므로, 아무 도메인이나 입력한다고 자동으로 일치하지 않습니다. 서버 인증서, 예상 서버 이름, 포트, 비밀번호가 모두 올바르게 설정되어야 합니다. 일부 배포에서는 앞단 서비스가 연결을 분배할 수 있으므로 추가 규칙이 있다면 제공자에게 확인해야 합니다.

Trojan은 UDP 전달을 지원할 수 있지만, 일반적인 구현에서는 앱의 데이터그램도 TLS가 사용하는 안정적인 바이트 스트림을 통해 전송됩니다. 따라서 로컬에서는 UDP를 사용하는 것처럼 보이는 앱도 원격 전송 경로에서 TCP의 헤드 오브 라인 블로킹 영향을 받을 수 있습니다. 실시간 통신에 적합한지는 노드의 UDP 표시만 확인하지 말고 실제 패킷 손실과 상호작용을 측정하세요. 일부 확장 구현은 다른 전송 방식도 추가할 수 있으므로, 그 동작을 모든 Trojan 서비스의 공통 특성으로 일반화해서는 안 됩니다.

VLESS: 프로토콜이 간결해도 전송이 자동으로 암호화되는 것은 아닙니다

VLESS의 사용자 인증에는 보통 UUID를 사용하지만, UUID는 인증 식별자이지 TLS를 대신하는 암호화 스위치가 아닙니다. 기존 VLESS 설정에서 흔히 보이는 encryption: none은 해당 프로토콜 계층에서 데이터 암호화를 제공하지 않는다는 뜻입니다. 그렇다고 전체 연결이 반드시 보호되지 않는 것은 아닙니다. 실제로 TLS, REALITY 또는 명시적으로 지원되는 다른 방식을 외부 계층에서 사용하는지 확인해야 합니다. 반대로 보안 계층이 없는 설정을 VLESS라는 이유만으로 암호화된 연결이라고 간주해서도 안 됩니다.

VLESS는 전송 방식 조합이 다양하므로 클라이언트 지원 여부를 필요한 기능별로 확인해야 합니다. flow는 임의로 입력해 성능을 높이는 태그가 아니라 특정 데이터 흐름 처리 방식과 엔드포인트 구현에 맞춰야 하는 매개변수입니다. 예를 들어 Vision 관련 흐름을 사용하는 경우 서버, 커널, 전송 방식, 보안 계층이 모두 요구 사항을 충족하는지 확인하세요. 다른 노드의 flow 값을 복사하면 정상적으로 연결되던 노드가 실패할 수 있습니다.

REALITY는 일반 TLS 스위치의 다른 표기가 아닙니다. 해당 방식을 사용할 때는 공개 키, 짧은 식별자, 서버 이름, 핸드셰이크 매개변수가 서버 설정과 일치해야 합니다. 소프트웨어 설정 형식에 따라 필드 이름이 다를 수 있으므로 현재 커널 문서를 기준으로 확인하세요. 브라우저 지문 관련 매개변수는 특정 핸드셰이크 동작에 영향을 주지만, 잘못된 포트나 유효하지 않은 사용자 식별자, 일치하지 않는 공개 키를 해결해 주지는 않습니다. 일반적인 속도 향상 옵션으로 사용해서도 안 됩니다.

전송 옵션이 선택에 미치는 영향

WebSocket, gRPC 등의 전송 방식은 기존 서비스 아키텍처에 맞추는 데 쓰이는 경우가 많으며, 별도의 경로, 서비스 이름, 요청 헤더, 중간 계층 요구 사항이 추가될 수 있습니다. 캡슐화 계층이 하나 더 있다고 반드시 느려지는 것은 아닙니다. 실제 병목은 프로세서가 아니라 네트워크 경로에 있을 수 있습니다. 다만 설정 범위가 넓어지고 문제를 확인할 때 점검할 조건도 늘어납니다. 명확한 아키텍처 제약이 없다면 제공자 안내가 완전하고 클라이언트가 기본 지원하며 매개변수가 적은 조합을 우선하세요.

두 프로토콜 모두 인증서 검증을 끄는 방식으로 배포 오류를 해결해서는 안 됩니다. 인증서 만료, 서버 이름 불일치, 시스템 시간 오차는 각각 따로 처리해야 합니다. 검증을 건너뛰면 보안 경계가 달라지고 실제 문제를 가리는 경우가 많습니다. 노드를 가져온 뒤 민감한 매개변수를 추가로 입력해야 한다면 로컬 클라이언트에서 처리하고, 전체 구독과 인증 정보가 포함된 화면을 공개하지 마세요. 문제를 공유할 때는 프로토콜 종류, 오류 유형, 필드 이름만 남겨도 충분합니다.

Hysteria2와 TUIC: QUIC 기반 프로토콜의 차이

Hysteria2와 TUIC는 모두 QUIC을 사용하지만, 서로 설정을 가져오거나 인증 매개변수를 공유할 수 있는 것은 아닙니다. QUIC은 UDP에서 암호화된 전송, 신뢰성 있는 스트림, 연결 관리를 제공하며 TCP와 다른 기반을 갖습니다. Hysteria2는 복잡한 네트워크 경로에서의 전송과 대역폭 활용에 중점을 둡니다. TUIC는 QUIC을 기반으로 프록시 요청과 데이터 전달을 구성하고 자체 인증 및 UDP 처리 방식을 제공합니다. 두 프로토콜은 설정 필드와 서버 구성을 각각 맞춰야 합니다.

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

QUIC은 하나의 연결에서 여러 스트림을 전달할 수 있습니다. 한 스트림에서 패킷 손실이 발생해도 단일 TCP 바이트 스트림처럼 모든 스트림이 같은 누락 데이터를 기다릴 필요는 없습니다. 다만 연결 내 혼잡 제어, 사용 가능한 대역폭, 일부 자원은 공유되므로 요청마다 서로 완전히 영향을 주지 않는 것은 아닙니다. 물리적 거리, 심한 혼잡, 서버 성능 제한도 해결하지 못합니다. 네트워크에서 UDP 패킷을 차단하면 QUIC 기반 연결 자체가 설정되지 않을 수 있습니다.

연결 마이그레이션은 QUIC의 기능 중 하나입니다. 실제로 Wi-Fi와 모바일 네트워크를 전환한 뒤에도 계속 사용할 수 있는지는 프록시 구현, 서버 정책, 클라이언트 수명 주기에 따라 달라집니다. 모바일 운영체제가 프로세스를 일시 중지하거나 자원을 회수할 수 있고, 클라이언트가 터널을 다시 만들 수도 있습니다. 네트워크 전환 후 복구를 테스트할 때는 연결 식별자가 있다는 사실만으로 앱 세션이 항상 유지된다고 단정하지 말고, 앱 요청이 다시 성공하는지와 복구가 안정적인지 확인하세요.

Hysteria2: 대역폭 매개변수는 실제 네트워크에 맞추세요

Hysteria2 설정 형식은 이전 버전의 Hysteria와 임의로 바꿔 쓸 수 없습니다. hysteria2 유형을 선택했다면 이에 맞는 인증, TLS 및 기타 선택 매개변수를 사용해야 합니다. 난독화 관련 설정도 서버와 일치해야 하며, 연결을 시도하려고 임의로 활성화해서는 안 됩니다. 표준 연결에서는 서버 신원과 인증서를 올바르게 검증해야 합니다. QUIC을 사용한다고 해서 이 요구 사항이 없어지는 것은 아닙니다.

Hysteria2의 대역폭 협상과 혼잡 제어 동작은 양쪽 설정에 영향을 받습니다. 클라이언트는 up, down 등의 필드로 방향별 대역폭 정보를 지정할 수 있지만, 모든 배포에서 직접 입력해야 하는 것은 아닙니다. 값을 높게 설정한다고 사용 가능한 용량이 자동으로 늘어나지는 않습니다. 오히려 대기열과 패킷 손실이 늘고 같은 네트워크의 다른 기기에 영향을 줄 수 있습니다. 먼저 서버 요구 사항을 확인하고, 값을 명시해야 한다면 무선 연결의 표시 속도가 아니라 실제로 지속 가능한 대역폭을 기준으로 보수적으로 조정하세요.

TUIC: 인증, 혼잡 제어, 데이터그램 모드

TUIC의 일반적인 설정에는 UUID, 비밀번호, TLS 관련 매개변수가 포함되며 혼잡 제어와 UDP 전달 모드를 지정할 수도 있습니다. 구체적인 필드는 TUIC 프로토콜 버전과 클라이언트 구현에 따라 달라지므로, “TUIC 지원”만으로 충분하지 않고 서버 구현까지 확인해야 합니다. Hysteria2 인증 문자열을 TUIC 비밀번호 필드에 넣어도 QUIC 기반이 같다는 이유로 연결이 호환되지는 않습니다.

혼잡 제어 알고리즘은 전송 속도와 네트워크 피드백에 대한 반응에 영향을 주며, 모든 네트워크에서 쓸 수 있는 속도 설정값은 아닙니다. UDP 데이터그램을 어떤 방식으로 전달하는지도 신뢰성, 지연 시간, 추가 처리 비용에 영향을 줍니다. 신뢰성 있는 전달은 일부 앱 데이터그램의 손실을 막을 수 있지만 대기 시간이 늘어날 수 있습니다. 비신뢰성 전달은 데이터그램 본래의 의미를 더 잘 유지하지만 앱이 패킷 손실을 처리할 수 있어야 합니다. 선택하기 전에 실제 용도를 파악하고, 모든 옵션을 공격적인 설정으로 바꾸지는 마세요.

프로토콜 사용 경험을 비교하기 전에 네트워크 조건부터 확인하세요

공용 Wi-Fi, 기업 게이트웨이, 모바일 네트워크는 UDP를 서로 다르게 처리할 수 있습니다. TCP 계열 노드는 연결되지만 QUIC 계열 노드 두 개가 모두 실패한다면 인증부터 의심하기보다 UDP 연결 가능 여부, 포트 정책, 경로 문제를 먼저 확인하세요. 오래 사용한 뒤에야 끊긴다면 NAT 매핑, 유휴 시간 제한, 모바일 백그라운드 제한이 원인일 수 있습니다. 먼저 고정 네트워크에서 기준 테스트를 한 다음 실제 사용 환경에서 검증하면 여러 조건이 한꺼번에 바뀌어 잘못 판단할 가능성을 줄일 수 있습니다.

UDP 연결이 가능한 고지연·패킷 손실 환경에서는 Hysteria2나 TUIC를 후보에 넣어 볼 수 있지만, 특정 순위를 고정 추천하는 것은 아닙니다. 더 적극적인 전송 방식은 처리량을 높일 수도 있지만 처리 비용과 무선 활동 시간도 늘릴 수 있습니다. 다운로드 속도와 함께 기기 발열, 같은 네트워크의 다른 기기 사용 경험, 실제 작업의 안정성도 기록하세요.

연결 성능, 자원 사용량, 모바일 배터리 소모

프로토콜 성능을 비교하려면 가능한 한 조건을 동일하게 맞춰야 합니다. 같은 클라이언트와 기기, 동일한 진입 방식, 비슷한 시간대가 기본 조건입니다. 서버 위치, 출구 대역폭, 대상 사이트가 다르면 테스트 결과는 전체 서비스 경로의 차이만 보여줍니다. 프로토콜 처리 방식에도 차이가 있지만, 일반적인 웹 사용에서는 도메인 조회와 원격 서버 응답이 더 큰 비중을 차지할 수 있습니다. 대기 시간을 모두 암호화나 핸드셰이크 탓으로 돌려서는 안 됩니다.

짧은 연결, 연결 재사용, 지속 전송을 나누어 측정하세요

첫 요청에는 DNS 조회, TCP 또는 QUIC 연결 설정, TLS, 프로토콜 인증이 포함될 수 있습니다. 후속 요청은 기존 전송 연결을 재사용할 수 있습니다. 테스트 결과를 기록할 때는 연결을 처음 여는 상태인지, 미리 연결을 설정해 둔 상태인지 구분하세요. 지연 시간 테스트를 연달아 실행하면 캐시와 연결 재사용으로 수치가 점점 낮아질 수 있지만, 실제 앱이 유휴 상태 이후에도 같은 조건을 누리는 것은 아닙니다. 짧은 요청을 비교한다면 첫 로딩과 반복 로딩의 안정성을 각각 기록하세요.

대용량 파일 전송은 충분히 긴 시간 동안 관찰해 시작 직후의 순간적인 속도만 기록하지 않도록 하세요. 단일 연결 다운로드인지 다중 연결 다운로드인지도 구분해야 합니다. 다중 연결은 네트워크와 처리 자원을 더 많이 사용할 수 있으므로 프로토콜의 단일 스트림 효율이 더 높다는 증거가 되지 않습니다. 재전송, 혼잡 피드백, 서버 속도 제한도 전송 속도 변화에 영향을 줍니다. 속도 측정은 데이터 사용량과 당시 네트워크 부하를 늘리므로 노드를 바꿀 때마다 대용량 테스트를 자동으로 실행하지 않는 것이 좋습니다.

프로세서와 메모리에는 모든 기기에 통하는 고정 순위가 없습니다

암호화 알고리즘의 하드웨어 가속 여부, 커널의 버퍼 관리 방식, 동시 연결 수에 따라 프로세서 사용량이 달라집니다. 한 프로세서에서 효율적인 알고리즘이 구형 모바일 칩이나 소형 라우터에서도 더 효율적이라는 보장은 없습니다. QUIC 구현은 사용자 공간에서 더 많은 전송 로직을 처리하는 경우가 많지만, 그렇다고 모든 작업에서 자원을 더 많이 쓴다고 단정할 수도 없습니다. 실제 처리량과 시스템 스케줄링을 함께 살펴보세요.

메모리 사용량은 규칙 집합, DNS 캐시, 연결 추적, 로그 수준, 인터페이스 프레임워크의 영향도 받습니다. 대규모 규칙 집합을 포함한 클라이언트와 간소화된 설정의 클라이언트를 비교해 프로토콜의 메모리 사용량을 결론 내릴 수는 없습니다. 라우터에 메모리 부족이 발생하면 프로토콜을 바꾸기 전에 연결 규모, 규칙 로딩, 로그 설정을 먼저 확인하세요. 데스크톱 클라이언트에서 표시하는 전체 프로세스 메모리에는 인터페이스도 포함될 수 있으므로 프록시 커널만의 사용량과 같지 않습니다.

모바일 배터리 소모는 무선 활동과 백그라운드 정책을 주로 확인하세요

휴대폰 네트워크 모듈이 자주 깨어나는 현상, 지나치게 잦은 연결 유지 신호, 약한 신호에서의 반복 전송, 앱의 백그라운드 요청은 모두 배터리 소모를 늘릴 수 있습니다. 유휴 연결을 유지하는 상황과 동영상을 계속 전송하는 상황의 전력 사용 패턴은 다르므로 신뢰할 만한 보편적인 프로토콜별 배터리 순위는 없습니다. 비교할 때는 화면을 켜고 웹을 탐색하는 경우, 화면을 끈 대기 상태, 지속 전송을 나누어 기록하고 화면 밝기, 신호, 네트워크 유형, 앱 부하를 가능한 한 일정하게 유지하세요.

Android의 배터리 최적화가 클라이언트를 일시 중지하면 화면을 잠근 뒤 연결이 끊길 수 있습니다. 관련 제한을 해제하면 지속 실행에 도움이 될 수 있지만 백그라운드 활동도 늘어날 수 있습니다. iOS의 네트워크 확장은 운영체제의 앱 수명 주기 관리에 따르므로 데스크톱 백그라운드 설정을 그대로 적용할 수 없습니다. 연결이 끊기면 시스템 설정과 클라이언트 로그를 확인하고, 연결 유지 빈도를 바로 높이지 마세요. 지나치게 잦은 확인은 연결을 유지하더라도 불필요한 온라인 상태를 위해 배터리를 더 소모할 수 있습니다.

프록시 연결은 활성 상태인데 웹페이지가 열리지 않는다면, 성능을 비교하기 전에 시스템 프록시부터 DNS까지 단계별 점검 목록을 따라 연결 경로를 확인하세요. 프록시가 아직 트래픽을 처리하지 않는 상태에서 성능을 비교하는 일을 막을 수 있습니다. 한 번의 최고 처리량보다 실제 작업 요구 사항을 안정적으로 충족하는 조합이 더 중요합니다.

Clash, Meta, mihomo: 커널 계열과 인터페이스의 역할

기존 Clash는 YAML 설정, 프록시 그룹, 규칙 기반 라우팅을 중심으로 한 사용 방식을 정립했습니다. 이후 생태계에서 여러 커널 분기와 확장 구현이 등장했습니다. Meta는 보통 Clash.Meta 계열의 발전 경로를 가리키며, mihomo는 그 계열에서 이어서 사용하는 프로젝트 이름입니다. 이들은 임의로 기능을 덧붙일 수 있는 플러그인 세 개가 아닙니다. 설정을 실행할 수 있는지는 파일 이름에 Clash가 포함되어 있는지가 아니라, 실제 커널이 지원하는 노드 유형과 규칙 문법, 관련 모듈에 달려 있습니다.

기본 문법이 비슷해도 기능이 모두 같은 것은 아닙니다

proxies, proxy-groups, rules처럼 여러 구현에서 비슷한 구조를 유지하는 필드가 많아 기본 설정은 어느 정도 쉽게 옮길 수 있습니다. 그러나 프로토콜 확장, DNS 동작, TUN 매개변수, 규칙 기능까지 동일하게 지원되는 것은 아닙니다. 기존 Clash 설정에서 기본 노드를 사용할 수 있다고 해서 최신 확장 노드도 기존 커널에서 읽을 수 있는 것은 아닙니다. 알 수 없는 프록시 유형이 나타나면 YAML 들여쓰기를 바꿔 오류를 가리기보다 지원 범위를 먼저 확인하세요.

자료를 읽을 때는 과거의 오픈 소스 버전, Premium 관련 기능, Meta 계열 구현을 구분해야 합니다. 오래된 글에서 어떤 기능을 간단히 “Clash 지원”이라고 표현했더라도 당시 특정 커널에서만 사용할 수 있었을 수 있습니다. 이런 설명을 모아 모든 클라이언트가 지원하는 기능 목록으로 취급해서는 안 됩니다. 특히 TUN, 규칙 제공자, 스크립트, 특정 규칙 형식은 현재 사용하는 커널의 문서를 기준으로 하나씩 확인하세요.

클라이언트 이름과 커널 이름은 다릅니다

일반 사용자는 다운로드 페이지에서 우선 안내하는 Clash Plus를 시작점으로 삼아 운영체제에 맞는 클라이언트를 선택하고, 실제 프로토콜 및 가져오기 지원 여부를 확인할 수 있습니다. Clash Verge Rev, FlClash 등도 인터페이스 클라이언트이므로 설정 지원 범위는 실제로 포함된 커널에 따라 달라집니다. Clash Meta for Android라는 이름은 생태계와의 연관성을 나타내지만, 설치한 프로그램의 구체적인 구현은 별도로 확인해야 합니다. 브랜드가 비슷하다는 이유만으로 모든 설정 확장을 동일하게 지원한다고 추정하지 마세요.

데스크톱에서 인터페이스 프로그램을 업데이트해도 실행 중인 커널까지 성공적으로 바뀌는 것은 아닙니다. 일부 클라이언트는 커널을 별도로 관리하고, 다른 클라이언트는 설치 패키지에 커널을 함께 포함합니다. 정보 화면, 실행 로그, 커널 관리 페이지에서 실제 실행 정보를 확인할 수 있습니다. 설정 디렉터리가 여러 개라면 클라이언트가 현재 어떤 파일을 읽는지 확인하세요. 백업 파일만 수정한 뒤 동작이 바뀌지 않은 것을 커널 문제로 오해하지 않도록 주의하세요.

Clash for Windows와 ClashX Meta는 이 사이트의 다운로드 목록에서 지원이 중단된 보관용 클라이언트로 안내합니다. 보관용 클라이언트는 이전 환경을 살펴보거나 마이그레이션할 때 참고할 수 있지만, 새로운 프로토콜 기능을 이용하기 위한 기본 선택지는 아닙니다. 지원이 중단되었다고 기존 연결이 즉시 모두 실패하는 것은 아니지만, 이후 운영체제 변경이나 프로토콜 확장, 오류 수정이 계속 반영되리라고 기대할 수는 없습니다. 이전하기 전에는 기존 설정을 보관하고 복사본으로 새 클라이언트를 검증하세요.

커널을 바꿀 때는 모듈 단위로 이전하세요

이전할 때는 노드와 수동 선택 프록시 그룹 하나만 남긴 상태로 시작해 인증과 전송 연결이 되는지 확인하세요. 그다음 규칙, DNS, 제공자, TUN을 차례대로 복원합니다. 이렇게 하면 실패 원인을 특정 모듈로 좁힐 수 있습니다. 복잡한 설정을 한꺼번에 가져온 뒤 인터넷에 연결되지 않으면 노드 오류, DNS 순환, 라우팅 충돌, 규칙 참조 오류가 한꺼번에 나타나 로그를 해석하기 어려워집니다. 기본 연결을 검증한 다음 기능을 하나씩 추가하는 편이 전체 설정을 동시에 시험하는 것보다 대체로 빠릅니다.

서비스 모드와 관리자 권한은 시스템 통합 조건이지 원격 프로토콜의 속성이 아닙니다. 커널이 TUN을 지원해도 일반 권한의 프로세스가 가상 네트워크 어댑터를 만들거나 라우팅을 수정할 수 있다는 뜻은 아닙니다. 더 많은 앱의 트래픽을 처리하려면 TUN 모드와 가상 네트워크 어댑터 안내를 확인하세요. 서버와 라우터를 사용하는 경우에는 그래픽 클라이언트와 독립 커널 배포를 구분하고, OpenWrt 및 게이트웨이 우회 구성 개요를 참고해 자원과 네트워크 구성을 검토하세요.

구독 호환성: 링크, 노드, 전체 설정

구독은 설정을 전달하는 방식이지 별도의 프록시 프로토콜이 아닙니다. 구독 주소에서 반환되는 내용은 전체 Clash YAML, 여러 공유 링크, 인코딩된 노드 목록, 다른 소프트웨어의 설정 형식일 수 있습니다. 클라이언트가 주소에서 데이터를 가져올 수 있다는 것은 응답을 받았다는 뜻일 뿐, 현재 커널 설정으로 바로 사용할 수 있다는 의미는 아닙니다. “형식 오류”가 난 뒤 계속 새로고침하기보다 먼저 콘텐츠 유형을 확인하세요.

단일 노드 공유 형식과 전체 YAML은 포함 정보가 다릅니다

ss://, vmess://, trojan:// 등의 공유 형식은 보통 단일 아웃바운드 노드를 표현하며, 구체적인 필드 인코딩은 생태계의 규칙에 따라 다를 수 있습니다. 프록시 그룹, 분기 규칙, DNS, 로컬 포트는 포함되지 않을 수 있습니다. 전체 Clash 설정은 보통 이러한 모듈을 중심으로 실행 환경을 구성합니다. 노드 링크 텍스트를 .yaml 파일로 저장해도 내용이 자동으로 YAML 설정이 되지는 않습니다. 파일 확장자를 바꿔도 형식은 변하지 않습니다.

다른 커널의 JSON 설정도 괄호와 들여쓰기만 바꿔 Clash 설정으로 만들 수는 없습니다. 모듈 구조, 라우팅 표현식, DNS 의미가 근본적으로 다를 수 있습니다. 변환 도구는 이해하는 항목만 대응할 수 있으므로 모든 동작이 보존된다고 보장하지 않습니다. REALITY, 특정 흐름 제어, 플러그인, 최신 프로토콜 매개변수가 포함되어 있다면 변환한 뒤 각 필드를 특히 주의해서 확인하세요. 노드 수가 같아도 연결에 필요한 정보가 모두 포함된 것은 아닙니다.

프록시 제공자는 별도의 최상위 설정이 아닙니다

proxy-providers를 사용하면 외부 소스에서 노드 목록을 불러온 다음 프록시 그룹에서 참조할 수 있습니다. 제공자 파일은 보통 노드 목록만 담당하므로 다른 전체 구독에 포함된 포트, DNS, 규칙까지 함께 병합한다고 가정해서는 안 됩니다. 외부 소스가 실제로 전체 설정을 반환한다면 노드를 추출할 수 있는지는 클라이언트나 커널에서 지원하는 처리 방식에 달려 있습니다. 제공자가 요구하는 구조에 맞춰 내용을 준비하세요. 전체 설정 가져오기가 성공한 경험을 제공자에 그대로 적용하지 마세요.

다음은 원격 노드 없이 독립적으로 읽을 수 있는 로컬 분기 기본 설정입니다. 포트, 선택 그룹, 규칙 구조를 확인하기 위한 예시이며 프록시 성능 측정용이 아닙니다. 실제 노드를 가져온 뒤 해당 노드 이름을 프록시 그룹에 추가하세요. 전체 구독을 바로 사용하는 경우에는 로컬 설정이 덮어써지지 않도록 클라이언트의 병합 방식을 먼저 확인하세요.

mixed-port: 7890
mode: rule
proxies: []
proxy-groups:
  - name: 수동 선택
    type: select
    proxies: [DIRECT]
rules:
  - MATCH,수동 선택

설정 파싱에 성공한 뒤에는 참조 관계도 확인하세요

YAML은 들여쓰기, 목록 계층, 문자열 표기 규칙을 따릅니다. 특수 기호가 포함된 값은 올바른 따옴표로 묶어야 합니다. 프로토콜 필드의 유형도 중요하므로 불리언 값과 문자열을 임의로 바꾸어 쓸 수 없습니다. 하지만 문법이 올바른 것은 첫 단계일 뿐입니다. 프록시 그룹이 참조하는 노드 이름, 규칙이 참조하는 그룹 이름, 규칙 제공자 이름이 실제로 존재해야 합니다. 구독 업데이트 후 노드 이름이 바뀌었는데 로컬에서 직접 작성한 그룹이 이전 이름을 사용하면 참조가 끊길 수 있습니다.

클라이언트는 로컬 설정을 유지하기 위해 덮어쓰기, 병합, 스크립트 기능을 사용하는 경우가 많습니다. 각 기능의 실행 시점과 적용 범위는 다르며, 실제 적용되는 설정 파일이 다운로드한 원본과 다를 수 있습니다. 문제를 확인할 때는 실행 설정을 열어 노드와 규칙이 최종적으로 어떻게 조합되었는지 살펴보세요. 구독 편집기에서 필드를 검색할 수 있다는 이유만으로 커널이 해당 필드를 읽었다고 단정하지 마세요. 필요하면 복사본에서 로컬 덮어쓰기를 잠시 끄고 원본 구독을 검증한 뒤 하나씩 복원하세요.

업데이트 오류와 형식 비호환은 따로 해결하세요

HTTP 오류, 로그인 페이지로의 리디렉션, 빈 응답, YAML 파싱 실패는 서로 다른 문제입니다. 구독 주소에 접근 인증 정보가 포함될 수 있으므로 신뢰할 수 없는 온라인 변환 서비스에 보내지 마세요. 변환 서비스가 전체 노드 정보를 볼 수 있게 됩니다. 클라이언트에 내장된 가져오기 기능이나 직접 제어할 수 있는 처리 방식을 우선 사용하세요. 업데이트 순서는 구독 업데이트 실패 및 자동 업데이트 설정을 참고하세요.

업데이트하기 전에 정상 작동하는 설정 복사본을 보관하고, 업데이트 후에는 노드 유형과 프록시 그룹을 확인한 다음 규칙과 DNS를 검증하세요. 서버에서 현재 커널이 지원하지 않는 유형을 새로 제공했다면 호환되는 구독 형식을 선택하거나 지원되는 클라이언트를 업데이트하세요. 오류가 난 필드를 무작정 삭제해서는 안 됩니다. 필드를 제거하면 파싱은 통과할 수 있지만 인증이나 전송의 의미가 바뀌어 오히려 원인을 찾기 어려운 연결 실패가 발생할 수 있습니다.

사용 환경에 맞는 프로토콜 선택: 기준 설정을 유지하고 비교하세요

실제 프로토콜 선택은 이미 제공되는 서비스 조건에서 시작해야 합니다. 먼저 프로토콜 이름을 정한 뒤 모든 매개변수를 맞추려 해서는 안 됩니다. 프로토콜은 서버와 클라이언트가 함께 지원해야 하며, 로컬에서 type만 바꿔도 원격 서버가 자동으로 업그레이드되지는 않습니다. 서비스 제공자가 검증된 조합 하나만 제공한다면 먼저 현재 작업에 충분한지 확인하세요. UDP 연결 불가, 네트워크 전환 후 불안정한 복구, 기기 자원 부족처럼 명확한 제약이 있을 때 다른 조합을 추가해 목적을 정하고 비교하면 됩니다.

데스크톱 웹 사용과 모바일 일상 사용

데스크톱 웹과 업무 앱에서는 보통 안정성, 도메인 조회, 규칙 적용 여부를 먼저 확인합니다. 호환성이 검증된 SS, VMess, Trojan, VLESS 조합은 모두 후보가 될 수 있으므로 이미 안정적으로 작동하는 연결을 더 최신으로 보이는 이름 때문에 바꿀 필요는 없습니다. 클라이언트는 Clash Plus와 다운로드 페이지의 플랫폼별 목록에서 선택하고, 아키텍처와 시스템 요구 사항을 확인한 뒤 대상 노드의 전송 기능을 모두 지원하는지 점검하세요. 설치 후 기본 사용 방법은 사용 가이드를 참고하세요.

모바일 기기에서는 화면 잠금, 네트워크 전환, 백그라운드 복구도 추가로 테스트해야 합니다. 먼저 Wi-Fi에서 조건을 고정해 테스트한 다음 모바일 네트워크로 전환하세요. 전환 후에만 문제가 발생한다면 인증 매개변수를 즉시 바꾸기보다 클라이언트가 연결을 다시 설정하는지 확인하세요. TUN으로 트래픽을 처리한다면 운영체제의 VPN 권한과 다른 네트워크 확장 기능의 충돌도 확인해야 합니다. 운영체제가 클라이언트를 일시 중지하는 문제와 프록시 서버가 인증을 거부하는 문제는 해결 방법이 전혀 다릅니다.

고지연 경로와 실시간 서비스

네트워크 지연이 크고 패킷 손실이 있는 경우 UDP 연결이 가능하다는 전제하에 Hysteria2, TUIC, 기존 TCP 계열 방식을 비교해 볼 수 있습니다. 다운로드 최고 속도만 보지 말고 상호작용 대기 시간, 지속 전송, 다른 앱에 미치는 영향을 확인하세요. 공용 네트워크에서 QUIC 계열 연결이 자주 끊긴다면 검증된 TCP 계열 대안을 유지하는 편이 실용적입니다. 백업 경로는 주 경로가 실패한 뒤 처음 가져오지 말고 미리 테스트하세요.

음성 통화와 게임 같은 실시간 서비스는 데이터그램 전달이 전체 경로에서 제대로 동작하는지, 오래 기다리거나 주기적으로 끊기는 현상이 있는지 확인해야 합니다. 신뢰성 있는 전달은 패킷 손실 양상을 바꿀 수 있지만 실시간 사용 경험을 반드시 개선하지는 않습니다. 일부 앱은 재전송을 기다리는 것보다 오래된 데이터를 버리는 편을 선호합니다. 실제 서비스를 사용해 검증하고 대상 서비스가 IP 주소 변경에 민감한지도 살펴보세요. 앱 세션이 종료된 문제를 프록시 프로토콜 오류로 오해하지 않도록 주의하세요.

라우터와 저사양 기기

라우터에서는 먼저 프로세서 아키텍처, 사용 가능한 메모리, 동시 연결 규모, 규칙 집합 크기를 확인해야 합니다. 자원이 부족하다면 프로토콜만 바꾸기보다 규칙을 간소화하고 불필요한 로그를 줄이며 중복 상태 확인을 피하는 편이 더 직접적인 해결책일 수 있습니다. 암호화 구현과 QUIC 처리에 필요한 자원은 실제 사용할 하드웨어에서 테스트하세요. 데스크톱 성능으로 소형 라우터의 성능을 추정할 수 없으며, 하드웨어 네트워크 포트 속도를 프록시 사용 시에도 반드시 달성할 처리량으로 볼 수 없습니다.

게이트웨이 우회 라우터 구성에서는 게이트웨이, DNS, 반환 경로도 확인해야 합니다. 단말 요청이 프록시 기기를 거치지 않으면 프로토콜 선택은 아무런 효과가 없습니다. 잘못된 DNS 설정이나 라우팅 루프 때문에 모든 노드가 동시에 실패할 수도 있습니다. 먼저 최소 구성으로 단일 단말에서 확인한 뒤 전체 네트워크로 확장하세요. 안정적으로 동작하는 기기에서는 커널 변경과 프로토콜 변경을 따로 진행해야 어떤 계층에서 차이가 생겼는지 판단하기 쉽습니다.

비교 테스트 기록 예시

1. 기기, 운영체제, 클라이언트, 실제 커널을 기록하고 트래픽을 처리하는 프로그램이 여러 개 동시에 실행 중이지 않은지 확인하세요.
2. 기존 설정을 저장하고 네트워크와 작업을 고정한 뒤 노드 인증, 전송, 인증서 매개변수를 확인하세요.
3. 첫 요청, 지속 사용, 유휴 상태에서 복구, 네트워크 전환을 각각 관찰하고 서로 다른 작업의 결과를 섞지 마세요.
4. 한 번에 조건 하나만 바꾸고, 실패하면 오류 유형을 기록한 뒤 정상 기준 설정으로 돌아가 네트워크가 여전히 작동하는지 확인하세요.
5. 요구 사항을 안정적으로 충족하는 조합을 선택하고 검증된 대안을 보관한 다음 중요한 업데이트 후 다시 테스트하세요.

최종 판단은 세 가지로 정리할 수 있습니다. 설정이 서버 요구 사항을 정확히 표현하는지, 기기가 감당할 수 있는 자원 사용량으로 계속 작동하는지, 실제 네트워크가 해당 전송을 안정적으로 처리하는지 확인하세요. 세 조건이 충족된 뒤 사용 경험의 차이를 비교하면 됩니다. 프로토콜 이름은 관련 정보를 찾아보는 출발점이지 품질을 보장하는 기준이 아닙니다. 특정 기기와 작업에서 반복해 확인한 결과가 특정 노드와 클라이언트 조합을 계속 사용할 근거가 됩니다.