Clash 프로토콜·코어 참고 자료

01 / 판단 순서

프로토콜 선택의 4단계

클라이언트, 코어, 프로토콜, 회선

클라이언트는 설정을 가져오고 저장하며 시스템 권한을 요청하는 사용자 인터페이스입니다. 코어는 규칙을 해석하고 연결을 생성해 데이터를 전달합니다. 프로토콜은 클라이언트와 서버가 인증하고 데이터를 구성·전송하는 방식을 정합니다. 회선은 로컬 네트워크 연결, 중간 라우팅, 서버 출구까지 포함합니다. 이 네 단계는 서로 협력하지만 서로를 대체하지는 않습니다. 인터페이스를 바꿔도 코어가 바뀌지 않을 수 있고, 프로토콜을 바꿔도 출구가 달라지지는 않습니다. 그렇다고 모든 앱이 빨라지는 것도 아닙니다.

예를 들어 같은 서버에서 SS와 Trojan을 모두 제공하더라도 두 프로토콜이 같은 CPU, 출구 대역폭, 상위 라우팅을 공유할 수 있습니다. 저녁 시간대에 혼잡해지면 둘 다 속도가 떨어질 수 있습니다. 이름만 보고 판단하면 회선 부하를 프로토콜 문제로 오해하기 쉽습니다. 반대로 같은 프로토콜이라도 서버마다 인증서 구성, 혼잡 제어, 사용자별 속도 제한, 동시 연결 제한이 다를 수 있습니다. 비교할 때는 먼저 테스트 대상이 같은 회선을 공유하는지 확인한 뒤 프로토콜 자체의 추가 비용을 살펴보세요.

연결 과정을 나눠서 살펴보기

웹페이지를 열 때는 보통 도메인 조회, 연결 생성, 보안 핸드셰이크, 요청 전송, 콘텐츠 다운로드를 거칩니다. 노드 테스트에 표시되는 시간은 이 중 일부만 측정한 값일 수 있으므로 페이지 전체 로딩 시간과 같지 않습니다. 브라우저는 이미지, 글꼴, 스크립트를 동시에 요청하고 이미 만든 연결을 재사용하기도 합니다. 테스트는 빠른데 웹페이지가 느리다면 대상 사이트의 응답, DNS 조회 위치, 규칙 선택이 다를 수 있습니다. 암호화 알고리즘이 복잡해서 그렇다고 단정하지 마세요.

전송 계층과 프록시 프로토콜도 구분해서 이해해야 합니다. TCP는 데이터 순서를 보장하는 신뢰성 있는 바이트 스트림이며, 손실된 데이터는 재전송합니다. UDP는 데이터그램을 전송하지만 순서대로 전달되는 것을 보장하지 않습니다. QUIC은 UDP 위에서 동작하며 암호화, 신뢰성 있는 스트림, 혼잡 제어를 제공합니다. 단순히 신뢰성을 없앤 방식이 아닙니다. 노드에서 UDP 포워딩을 지원한다고 해서 노드 자체가 QUIC을 사용한다는 뜻은 아닙니다. 앱이 사용하는 데이터 유형과 클라이언트에서 서버까지 데이터를 전달하는 방식은 서로 다른 기준입니다.

재현 가능한 비교 조건 만들기

비교하기 전에 기기, 네트워크, 프록시 모드, 대상 사이트, 테스트 시간을 기록하세요. 가능한 한 같은 출구를 선택하고 다른 기기의 대용량 작업을 중단한 다음, 일반 웹페이지로 연결을 확인하고 지속 다운로드와 응답성을 측정합니다. 규칙과 DNS 설정은 유지하고 프로토콜만 바꾸는 식으로 한 번에 변수 하나만 변경하세요. 여러 번 반복해 변동 폭을 기록하면 가장 잘 나온 결과 하나만 저장하는 것보다 평소 사용 경험을 제대로 파악할 수 있습니다. 일시적인 캐시 효과를 성능 우위로 착각할 가능성도 줄어듭니다.

보안도 계층별로 판단해야 합니다. 전송 암호화는 해당 연결 구간을 보호할 뿐이며, 서버 운영자의 권한을 바꾸거나 웹사이트 자체의 HTTPS를 대신하지 않습니다. 앱은 웹사이트 인증서를 정상적으로 검증해야 합니다. 노드의 서버 이름, 인증서 이름, 실제 연결 주소가 서로 다를 수 있지만 배포 방식에 맞아야 합니다. 인증서 오류가 발생하면 이름, 시간, 인증서 체인을 확인하세요. 연결을 위해 검증을 비활성화해서는 안 됩니다.

실제 선택은 호환성, 안정성, 리소스 사용량, 최대 처리량 순으로 진행할 수 있습니다. 먼저 기기에서 지원하지 않거나 네트워크에서 허용하지 않는 유형을 제외하고, 장시간 사용 시 안정적인지 확인한 다음 수용 가능한 배터리·데이터 비용 안에서 속도를 비교하세요. 현재 설정으로 웹, 회의, 파일 전송을 충분히 처리할 수 있다면 프로토콜이 새롭다는 이유만으로 바꿀 필요는 없습니다. 뒤에서 살펴볼 차이는 후보를 좁히기 위한 정보이지, 프로토콜의 고정 순위가 아닙니다.

02 / 널리 쓰이는 프로토콜

SS와 VMess의 설계 차이

SS: 간결한 데이터 전달 구조

Shadowsocks는 보통 SS라고 부르며, 암호화된 프록시 데이터 전달을 중심으로 설계되어 구조가 비교적 간결합니다. 복잡한 라우팅을 프로토콜 자체에서 모두 처리하기보다는 클라이언트와 서버 사이의 데이터를 보호하고 목적지로 전달하는 데 중점을 둡니다. 규칙 매칭, 정책 그룹, 앱 트래픽 가로채기는 클라이언트와 코어가 담당합니다. 다양한 구현에서 지원되므로 호환성과 간편한 배포가 중요한 환경에서 자주 사용됩니다. 다만 구현마다 지원하는 암호화 방식은 다를 수 있습니다.

SS 설정을 확인할 때는 서버, 포트, 암호화 방식, 비밀번호를 함께 확인해야 합니다. 암호화 방식은 클라이언트에서 임의로 최적화할 수 있는 옵션이 아니라 서버 설정과 일치해야 합니다. 이전 세대의 스트림 암호화 방식과 이후의 AEAD 방식은 같은 설정으로 볼 수 없으며, SS 2022에는 별도의 규격과 키 요건이 있습니다. 구독에 SS라고만 표시되어 있어도 사용 가능 여부를 판단하기는 어렵습니다. 현재 코어가 해당 암호화 방식을 지원하는지 확인하세요.

일반적인 AEAD 구현에서는 AES-GCM이나 ChaCha20-Poly1305를 선택할 수 있습니다. 하드웨어 가속 기능이 있는 프로세서는 특정 AES 구현에 더 적합할 수 있고, 저전력 기기에서는 다른 결과가 나올 수 있습니다. 알고리즘 이름만으로 휴대전화 배터리 사용량을 예측할 수 없으며, 속도 테스트를 위해 구독의 암호화 방식을 단독으로 바꾸는 것도 권장하지 않습니다. 서버에서 여러 설정을 제공한다면 같은 회선과 실제 부하 조건에서 비교하고 CPU 사용률이 지속해서 높게 유지되는지 살펴보세요.

VMess: 인증과 전송 설정의 분리

VMess는 V2Ray 생태계에서 시작한 프로토콜로, 사용자 인증과 데이터 보호 기능을 포함하며 여러 전송 방식과 조합해 사용합니다. 사용자 인터페이스에 VMess 노드로 표시되어도 일반 TCP를 사용할 수도 있고, WebSocket이나 구현에서 지원하는 다른 전송 방식과 조합할 수도 있습니다. TLS 계층, 리버스 프록시, 경로 설정도 연결 과정에 영향을 줍니다. 따라서 둘 다 VMess라고 표시되어 있어도 핸드셰이크 단계, 서버 구성, 장애가 발생하는 지점은 크게 다를 수 있습니다.

VMess 설정에는 보통 사용자 ID, 보안 방식, 전송 매개변수가 포함됩니다. 예전 문서에 나온 호환성 필드를 현재 구현에 그대로 적용해서는 안 됩니다. 프로토콜 인증에는 시간 동기화가 필요하므로 기기 시간이 크게 어긋나면 네트워크는 정상인데 인증에 실패할 수 있습니다. 계속 실패한다면 먼저 시스템의 자동 시간 설정을 켜고 서버 정보가 유효한지 확인한 뒤 코어 로그를 살펴보세요. 인증 오류를 DNS 문제로 오해해 DNS 서버를 계속 바꾸지 마세요.

플러그인과 캡슐화는 노드 이름만으로 판단할 수 없습니다

일부 SS 설정은 별도 플러그인이 필요하며, 공유 링크의 매개변수에 플러그인 이름과 옵션이 포함될 수 있습니다. 클라이언트가 기본 SS 정보를 가져올 수 있다고 해서 해당 플러그인까지 실행할 수 있는 것은 아닙니다. 일부 클라이언트는 호환되는 구현 몇 가지만 지원하고, 플러그인 설정 자체를 제공하지 않는 경우도 있습니다. VMess도 마찬가지입니다. 구독을 정상적으로 파싱했다는 것은 필드를 읽을 수 있다는 의미일 뿐, 실제 전송 조합을 코어가 구현한다는 뜻은 아닙니다. 프로토콜 지원 여부만 묻기보다 제공업체에 구체적인 조합을 확인하세요.

이 두 프로토콜은 이름만으로 앱에서 UDP를 사용할 수 있다고 보장하지 않습니다. 클라이언트의 UDP 설정, 코어 지원, 서버의 포워딩 설정, 중간 네트워크가 모두 제한 요인이 될 수 있습니다. 웹은 되는데 음성 통화나 게임이 이상하다면 먼저 앱 트래픽이 예상한 정책을 따르는지 확인한 다음 UDP 포워딩 조건을 살펴보세요. 무작정 전역 모드로 바꾸면 규칙 문제를 가릴 수는 있지만 서버에서 지원하지 않는 기능이 생기지는 않습니다.

안정적으로 작동하는 SS 설정을 사용 중이라면 기존 조합을 유지하고 암호화 방식과 플러그인 호환성을 확인하는 것이 좋습니다. VMess 설정을 사용 중이라면 전송 필드, 기기 시간, 구독 출처를 특히 살펴보세요. 새 환경을 구성할 때 특정 프로토콜 이름을 선호한다는 이유만으로 전송 계층을 여러 겹 추가할 필요는 없습니다. 계층이 하나 늘어날 때마다 일치시켜야 할 매개변수도 늘고, 인증서·경로·리버스 프록시 설정 오류를 찾는 데 더 많은 시간이 듭니다.

03 / TLS와 인증

Trojan과 VLESS의 조합과 한계

Trojan: TLS로 전송 보호

Trojan은 일반적으로 TLS 연결 안에서 프록시 인증과 데이터 전달을 처리하고, 검증된 TLS 구현으로 연결을 보호합니다. 사용 가능 여부는 비밀번호와 포트뿐 아니라 서버 이름, 인증서 체인, 서버 TLS 설정에도 달려 있습니다. 기존 인증서와 서버 관리 방식을 활용할 수 있지만, 포트만 열려 있으면 연결된다는 뜻은 아닙니다. Trojan으로 표시된 확장 구현이 서로 바꿔 쓸 수 있다는 의미도 아닙니다.

연결 주소는 클라이언트가 실제로 접속하는 위치이고, SNI는 TLS 핸드셰이크에서 알리는 서버 이름입니다. 인증서 검증에서는 이름과 신뢰 관계도 확인합니다. 배포 방식에 따라 이 값들이 같을 수도, 다를 수도 있습니다. 구독에 서버 이름이 제공되어 있다면 서버 요구사항에 맞춰 유지하세요. 연결 주소가 IP라는 이유만으로 삭제하면 안 됩니다. 인증서 만료, 기기 시간 오류, 이름 불일치, 불완전한 인증서 체인은 프록시 인증 전에 연결을 끊을 수 있습니다.

Trojan은 흔히 TCP와 TLS 조합으로 동작하며, 첫 연결에는 해당 연결 설정 과정이 필요합니다. 연결 재사용으로 반복 설정 비용을 줄일 수 있지만 실제 효과는 클라이언트, 서버, 앱의 요청 방식에 따라 달라집니다. 브라우저에서 여러 사이트에 접속할 때도 연결 구성 방식이 체감 속도에 영향을 줍니다. 콜드 스타트 때 한 번 느렸다고 지속적인 프로토콜 속도 문제로 단정하거나, 다운로드 한 번의 최고 속도로 웹페이지 첫 로딩이 항상 빨라진다고 결론 내리지 마세요.

VLESS: 인증 계층만으로 완성되는 보안은 아닙니다

VLESS도 V2Ray 관련 생태계에서 시작했으며 인증과 데이터 전달에 중점을 둡니다. 프로토콜 자체에는 VMess와 같은 데이터 암호화 계층이 없습니다. 실제 배포에서는 일반적으로 TLS나 지원되는 다른 보안 전송 방식에 의존합니다. 설정의 암호화 필드가 비어 있거나 추가 암호화를 사용하지 않는다고 표시되어도 연결이 보호되지 않는다고 단정해서는 안 됩니다. 바깥쪽 보안 설정을 확인해야 합니다. 반대로 외부 보안 계층이 제대로 설정되지 않았다면 VLESS라는 이름만으로 연결이 안전하다고 볼 수 없습니다.

VLESS의 실제 호환성은 전송 유형, TLS 설정, 서버가 요구하는 flow 등 조합 매개변수에 따라 달라지는 경우가 많습니다. 일부 배포에서는 REALITY도 사용합니다. 이는 일반 TLS 필드의 다른 이름이 아니라 별도로 확인해야 하는 보안 핸드셰이크 방식입니다. 공개 키, short ID, 서버 이름, 클라이언트 지원 여부가 모두 일치해야 합니다. 서로 다른 예제의 설정을 잘못 섞으면 가져오기 단계의 문법 검사는 통과해도 연결은 계속 실패할 수 있습니다.

전송 방식 이름이 같아도 세부 설정을 확인해야 합니다

WebSocket 조합에서는 경로, 요청 헤더, 리버스 프록시 전달 구성을 확인해야 합니다. gRPC 조합은 서비스 이름이나 HTTP/2 설정이 필요할 수 있습니다. 경로는 문자 하나까지 구분될 수 있고 끝의 슬래시가 달라져도 서버 라우팅에 영향을 줄 수 있습니다. 연결이 수락된 직후 끊긴다고 해서 사용자 인증 정보가 잘못된 것은 아닐 수 있습니다. 요청이 잘못된 백엔드로 전달됐을 가능성도 있습니다. TLS 완료 여부를 확인하고, 그다음 전송 계층 연결, 마지막으로 프로토콜 인증을 점검하세요.

일부 매개변수는 특정 서버 핸드셰이크 동작과 클라이언트의 호환성을 맞추기 위한 것이므로, 어디서나 통하는 속도 향상 옵션으로 취급해서는 안 됩니다. 다중화도 프로토콜 조합의 지원 여부, 연결 격리 방식, 서버 제한을 함께 고려해야 합니다. 여러 요청을 적은 수의 연결에 모으면 핸드셰이크를 줄일 수 있지만, 연결 하나에 문제가 생겼을 때 더 많은 요청이 영향을 받을 수도 있습니다. 기본 설정이 정상 작동한다면 그대로 두고 재현 가능한 문제가 있을 때만 변경 전후를 비교하세요.

실제 선택에서는 인증서가 정상이고 배포 안내가 명확한 Trojan 설정을 계층별로 점검하기가 비교적 쉽습니다. VLESS는 전체 조합을 하나의 구성으로 보고 확인해야 합니다. 초보자는 여러 글의 매개변수를 직접 조합하지 않는 편이 좋습니다. 현재 코어용으로 제공업체가 생성한 완성된 설정을 우선 사용하고 원본 파일은 비교용으로 보관하세요. 클라이언트에서 알 수 없는 필드를 표시한다면 삭제한 뒤 가져오기에 성공한 것을 문제 해결로 여기지 말고, 먼저 코어가 해당 기능을 지원하는지 확인하세요.

두 프로토콜 모두 일상적인 웹 사용이나 장시간 연결에 적합할 수 있지만, 어느 쪽이든 항상 배터리를 덜 쓴다고 단정할 수는 없습니다. 바깥쪽 전송 방식, 핸드셰이크 빈도, 연결 유지, 무선 신호가 인증 계층의 차이보다 더 큰 영향을 주는 경우가 많습니다. 모바일 기기에서 비교하려면 네트워크, 앱, 백그라운드 권한을 동일하게 유지하고 대기와 사용 상태를 나눠 관찰하세요. 신호 변화나 시스템의 백그라운드 정리를 프로토콜 특성으로 오해하지 않도록 주의해야 합니다.

04 / UDP 전송

Hysteria2와 TUIC에 필요한 네트워크 환경

공통 기반은 임의의 UDP가 아닌 QUIC입니다

Hysteria2와 TUIC은 모두 QUIC 기반으로 설계되었으며, 특정 네트워크 환경에서 프록시 전송 경험을 개선하는 것을 목표로 합니다. QUIC은 사용자 공간의 프로토콜 구현에서 신뢰성 있는 스트림, 암호화, 혼잡 제어를 처리하고 하위 계층에서 UDP 데이터그램을 사용합니다. 이 방식은 기존 TCP 조합과 다른 전송 스케줄링을 제공하지만, 로컬 네트워크, 중간 경로, 서버에서 해당 UDP 통신을 허용해야 합니다. UDP가 제한된 환경에서는 프로토콜 이름이 적절해도 제 기능을 발휘할 수 없습니다.

QUIC의 서로 다른 스트림은 하나의 TCP 바이트 스트림처럼 순서가 보장될 때까지 함께 기다릴 필요가 없어 일부 스트림 간 대기 시간을 줄일 수 있습니다. 하지만 모든 스트림은 사용 가능한 대역폭과 혼잡 상태를 공유합니다. 패킷 손실은 복구해야 하며 물리적인 회선 용량을 늘릴 수도 없습니다. 네트워크 혼잡, 무선 재전송, 서버 처리 성능 부족은 여전히 사용 경험에 영향을 줍니다. QUIC은 패킷 손실이나 지연의 영향을 받지 않는다고 이해하면 설정에 대해 잘못된 기대를 하게 됩니다.

Hysteria2: 대역폭 정보와 혼잡 제어 전략

Hysteria2는 이전 세대 Hysteria와 별개의 프로토콜이므로, 기존 설정에서 유형 이름만 바꿔 사용할 수 없습니다. 지연이 크거나 손실이 발생하는 네트워크에서 처리량을 높이는 데 중점을 두며, 여러 혼잡 제어 방식을 제공합니다. 일부 배포 설정에는 대역폭 관련 값이 포함되지만 이는 예상 조건을 나타낼 뿐 측정 결과가 아닙니다. 클라이언트와 서버가 지원하는 방식, 서버 제한, 대역폭 정보 제공 여부가 실제 동작을 함께 결정합니다.

대역폭을 직접 입력할 때는 인터넷 요금제의 표시 속도가 아니라 현재 네트워크에서 지속적으로 낼 수 있는 성능을 기준으로 삼으세요. 값을 크게 입력한다고 빨라지는 것도 아닙니다. 실제보다 높게 설정하면 대기열, 패킷 손실, 대역폭 경쟁이 발생해 같은 네트워크를 사용하는 회의나 웹 응답이 느려질 수 있습니다. 반대로 너무 낮게 설정하면 처리량이 제한될 수 있습니다. 셀룰러와 Wi-Fi를 자주 오가는 기기는 환경 변화가 크므로, 먼저 제공업체 권장값이나 기본 설정을 사용한 다음 통제된 조건에서 비교하세요.

TUIC: 연결 구성과 구현 호환성

TUIC도 QUIC 기반이며 인증, 연결 다중화, 데이터 전달 기능을 포함합니다. 실제로 사용하려면 프로토콜 세대와 구현 매개변수가 서로 맞는지 확인해야 합니다. 구독에 모두 TUIC으로 표시되어 있어도 호환성 한계를 무시해서는 안 됩니다. 사용자 ID, 비밀번호, 혼잡 제어, UDP 포워딩 옵션은 서버 안내에 맞춰 설정하세요. 코어마다 선택 필드 지원 여부가 다를 수 있습니다. 인터페이스에서 매개변수를 저장할 수 있다고 해서 하위 구현까지 전달됐다는 뜻은 아닙니다.

일부 TUIC 구현은 초기 데이터와 관련된 기능 등으로 반복되는 핸드셰이크 대기를 줄이는 옵션을 제공합니다. 이런 기능은 세션 복구, 서버 정책, 보안 조건에 따라 제한되므로 매번 시작할 때 즉시 효과를 보장하지 않습니다. 초기 데이터를 사용할 때는 재전송 공격 위험과 요청의 특성도 고려해야 합니다. 연결 대기를 한 번 줄이려고 관련 옵션을 모두 직접 켤 필요는 없습니다. 서버에서 명확히 지원하고 검증된 조합을 우선 사용하세요.

MTU와 네트워크 전환도 조건으로 고려하기

터널 캡슐화는 데이터에 추가 오버헤드를 발생시키며, 사용할 수 있는 경로 MTU는 연결 방식에 따라 달라집니다. 작은 요청은 되는데 큰 데이터 전송이 반복해서 멈춘다면 로그를 참고해 데이터그램 크기, 경로 탐색, 단편화 관련 문제를 확인할 수 있습니다. 하지만 MTU가 모든 시간 초과 문제의 해답은 아닙니다. 잘못된 인증서나 인증 정보는 MTU를 낮춰도 해결되지 않습니다. 핸드셰이크가 성공하고 서버에 연결할 수 있음을 확인한 뒤에 전송 크기와 경로 호환성을 점검하세요.

네트워크를 전환한 뒤의 동작은 구현에 따라서도 달라집니다. QUIC에는 연결 마이그레이션 관련 기능이 있지만, 모든 상황에서 프록시 클라이언트, 서버, 운영체제가 기존 연결을 유지하는 것은 아닙니다. 셀룰러 네트워크 전환, 절전 모드 해제, 주소 변경 뒤에는 다시 연결해야 할 수 있습니다. 최초 실행만 확인하지 말고 화면 잠금 해제, 네트워크 전환, 장시간 다운로드를 각각 테스트하세요. 모바일에서는 한 번의 최고 속도보다 안정적인 재연결이 더 중요할 때가 많습니다.

네트워크에서 UDP를 허용하고 기기의 처리 성능이 충분하며 손실이 있는 경로에서 기존 TCP 조합이 좋지 않다면 이 두 프로토콜을 후보로 고려할 수 있습니다. 현재 네트워크에서 UDP가 자주 제한된다면 검증된 TCP 기반 설정을 준비하세요. 이 프로토콜들은 특정 환경의 문제를 해결하기 위한 선택지이지 모든 프로토콜을 대체하지는 않습니다. 실제 비교에서는 출구 조건을 비슷하게 유지해 서버 회선의 이점을 QUIC의 일반적인 장점으로 오해하지 않도록 하세요.

05 / 사용 경험 측정

연결 속도, 리소스 사용량, 모바일 배터리

첫 응답 시간과 지속 처리량은 따로 측정하세요

연결 속도에는 클릭한 뒤 첫 유효 응답을 받을 때까지 걸리는 시간과 연결이 만들어진 뒤 지속적으로 데이터를 전송하는 성능, 최소 두 가지 경험이 포함됩니다. 첫 응답은 DNS 조회, 핸드셰이크, 대상 사이트의 응답에 영향을 받고, 지속 전송은 대역폭, 혼잡 제어, 서버 부하에 더 크게 좌우됩니다. 프로토콜에 따라 한쪽은 빠르고 다른 쪽은 비슷할 수 있습니다. 짧은 웹페이지, 동영상 버퍼링, 대용량 파일 다운로드는 요구 사항이 다르므로 속도 측정 파일 하나로 모든 앱 성능을 판단할 수 없습니다.

새 연결과 재사용 연결도 나눠서 봐야 합니다. 새 연결은 도메인을 다시 조회하고 TLS 또는 QUIC 핸드셰이크를 거칠 수 있지만, 기존 연결은 이전 세션을 재사용할 수 있습니다. 테스트 전에 클라이언트를 재시작했는지, 브라우저에 캐시가 남아 있는지, 연결 풀이 유효한지에 따라 결과가 달라집니다. 실제 첫 접속을 확인하려면 같은 조건에서 연결을 다시 만드세요. 평소 웹 사용을 평가하려면 자연스러운 연결 재사용을 유지해 상태를 인위적으로 초기화한 뒤 발생하는 비용을 과장하지 마세요.

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

CPU 비용은 암호화, 데이터 복사, 프로토콜 스택 처리, 규칙 매칭, 로그 기록 등에서 발생합니다. 하드웨어 가속, 운영체제의 네트워크 인터페이스, 코어 구현에 따라 결과가 달라집니다. 메모리 사용량은 연결 수, 버퍼, 규칙 규모, 캐시와도 관련이 있습니다. 클라이언트가 유휴 상태에서 리소스를 적게 사용해도 동시 연결이 많을 때는 그렇지 않을 수 있습니다. 추가 캡슐화가 적은 프로토콜이라고 해서 복잡한 규칙을 포함한 전체 설정이 가볍다는 보장도 없습니다.

리소스를 살펴볼 때는 인터페이스 프로세스와 코어 프로세스를 구분하세요. 데스크톱 클라이언트 인터페이스는 구현 기술에 따라 창을 열고 닫을 때의 사용량이 다를 수 있습니다. 작업 관리자에서 프로세스 하나만 확인하면 실제 데이터 전달을 담당하는 프로세스를 놓치기 쉽습니다. 휴대전화에서는 시스템 배터리 통계, 화면 사용 시간, 백그라운드 실행 시간을 함께 확인하세요. 특히 기기에서 업데이트를 다운로드하거나 미디어를 처리하는 동안 짧은 테스트 한 번으로 기기 온도가 올라갔다고 프로토콜을 탓해서는 안 됩니다.

무선 모듈 깨우기와 백그라운드 연결 유지

모바일 배터리 사용량은 암호화에 따른 소비만으로 결정되지 않습니다. 무선 모듈은 적은 데이터를 보낸 뒤에도 활성 상태를 유지할 수 있으며, 잦은 하트비트, 상태 확인, 자동 업데이트는 기기를 더 자주 깨웁니다. 신호가 약하면 재전송이나 송신 출력 변화로 배터리 소모가 커질 수도 있습니다. 기기가 대기 중에도 배터리를 많이 쓴다면 프로토콜을 비교하기 전에 예약 작업과 연결 유지 빈도를 확인하세요. 인증 방식만 바꿔서는 백그라운드 폴링으로 계속 발생하는 활동을 줄이지 못하는 경우가 많습니다.

정책 그룹의 자동 테스트는 실제 사용 목적에 맞춰야 합니다. 테스트 간격이 너무 짧거나 후보 노드가 너무 많고 자주 전환되면 추가 요청이 발생하고 기존 연결이 끊길 수도 있습니다. 자동 선택이 필요하다면 사용하지 않는 후보부터 줄이고 기본 간격이 요구 사항에 맞는지 살펴보세요. 자동 정책 그룹의 선택 방식은 url-test, fallback, load-balance 비교를 참고하세요. 세 기능을 같은 자동 속도 측정 기능으로 보면 안 됩니다.

TUN 모드는 더 많은 앱 트래픽을 가로챌 수 있지만, 시스템 프록시는 앱이 프록시 설정을 따르는 데 의존하므로 전체 처리량이 달라질 수 있습니다. 배터리 사용량을 비교할 때는 트래픽 가로채기 방식을 먼저 동일하게 맞춰야 합니다. Android VPN 서비스의 백그라운드 제한과 iOS 네트워크 확장 관리 정책도 연결 유지 시간에 영향을 줍니다. 필요한 백그라운드 실행을 허용하면 안정성에 도움이 되지만, 특정 클라이언트를 위해 모든 시스템 절전 기능을 끄지는 마세요.

비슷한 시간 동안 평소 사용과 화면 잠금 대기 상태를 각각 기록하고 여러 주기에 걸쳐 반복해 보세요. 시스템 업데이트, 핫스팟 공유, 신호 변화의 영향을 제외한 뒤 특정 설정이 지속해서 배터리를 더 많이 쓰는지 판단해야 합니다. 최적화가 필요하다면 불필요한 테스트, 지나치게 상세한 로그, 중복 실행 중인 서비스부터 줄인 뒤 프로토콜을 평가하세요. 속도 문제가 있다면 노드, 회선, 로컬 설정을 단계별로 확인하는 방법을 참고하고, 배터리 문제는 기기 자체의 통계도 함께 확인하세요.

06 / 구현 기능

Clash, Meta, mihomo의 관계

비슷한 설정 형식이 같은 기능을 뜻하지는 않습니다

Clash는 널리 사용되는 프록시 설정과 규칙 생태계를 만들었고, 많은 클라이언트가 YAML 구조와 제어 인터페이스를 이어받았습니다. Clash Meta는 이 생태계를 기반으로 프로토콜과 네트워크 기능을 확장했으며, mihomo는 Meta 코어의 유지보수 흐름을 이어갑니다. 실제 자료에서는 Meta, Clash Meta, mihomo라는 이름이 모두 사용됩니다. 가이드를 읽을 때는 코어, 클라이언트, 구독 형식 중 무엇을 가리키는지 확인하세요. 이전 명칭을 별개의 완전 호환 제품으로 오해하지 않도록 주의해야 합니다.

오픈소스 Clash 원본, 추가 기능을 제공했던 Premium 분기, Meta/mihomo는 기능 범위가 같은 하나의 구현이 아닙니다. 특정 코어에서 작동하는 오래된 가이드가 다른 코어에서도 같은 DNS, TUN, 규칙 제공자 필드를 지원한다는 뜻은 아닙니다. 오래된 클라이언트는 특정 코어를 함께 배포할 수 있습니다. 인터페이스가 계속 열리더라도 새로운 구독에 필요한 기능을 지원한다는 보장은 없습니다. 실제 실행 중인 코어 정보와 현재 문서를 기준으로 확인하세요.

코어를 확인한 다음 인터페이스 기능을 살펴보세요

데스크톱 클라이언트에서는 보통 정보, 설정, 로그 화면에 코어 이름과 시작 정보가 표시됩니다. 클라이언트 제목이나 설치 파일 이름만 보고 판단하지 마세요. 일부 클라이언트는 코어를 바꾸거나 업데이트할 수 있으므로 변경 후 실제 실행 정보를 다시 확인해야 합니다. 클라이언트가 실행 설정을 직접 생성한다면 인터페이스 설정이 가져온 파일의 DNS, 포트, TUN 필드를 덮어쓰는지도 알아야 합니다. 구독 파일을 수정하면 실제 실행 상태도 바뀔 것이라고 단정하지 마세요.

프로토콜 지원은 전체 기능 중 일부에 불과합니다. 규칙 유형, 규칙 세트 형식, 도메인 조회 방식, 가상 네트워크 어댑터 구현, 외부 제어 인터페이스의 동작도 사용 경험에 영향을 줄 수 있습니다. 두 코어가 같은 노드를 인식하더라도 기본 DNS, 라우팅 우선순위, 연결 처리 방식에 따라 결과가 달라질 수 있습니다. 이전할 때는 최소한의 설정부터 유지해 기본 데이터 전달을 확인한 다음 기존 규칙을 단계별로 추가하세요. 시작에 성공했다고 모든 기능 이전이 끝난 것은 아닙니다.

플랫폼별 지원과 보관 대상 클라이언트

이 사이트의 Windows 다운로드에는 Clash Nyanpasu와 유지보수가 중단된 Clash for Windows가 포함됩니다. macOS에는 유지보수가 중단된 ClashX Meta, Android에는 Clash Meta for Android와 Surfboard, Linux에는 Clash Verge Rev와 FlClash가 있습니다. 이들은 같은 인터페이스의 테마만 다른 클라이언트가 아닙니다. 특히 Surfboard는 자체 지원 설정 형식에 맞춰 사용해야 합니다. Android 다운로드 섹션에 함께 있다는 이유만으로 완전한 Clash YAML을 바로 읽을 수 있다고 판단해서는 안 됩니다.

iOS 다운로드 페이지에서는 Clash Plus의 App Store 페이지로 연결하며 공식 웹사이트는 clashplus.io입니다. 모바일 운영체제는 네트워크 확장, 백그라운드 실행, 트래픽 가로채기 방식에 자체 제한을 두므로 데스크톱 가이드의 시스템 프록시나 서비스 설치 절차를 그대로 적용할 수 없습니다. 플랫폼을 옮길 때는 먼저 클라이언트의 구독 형식과 프로토콜 조합 지원 여부를 확인하고 시스템 권한을 점검하세요. 계정 인증 정보가 같다고 해서 모든 플랫폼에 똑같은 실행 설정을 써야 하는 것은 아닙니다.

설정을 통째로 바꾸지 말고 계층별로 복구하세요

이전 코어에서 옮기기 전에 원본 구독과 로컬 오버라이드를 저장하고 모드, DNS, 트래픽 가로채기 방식을 기록하세요. 먼저 소수의 노드로 인증과 전송을 확인한 다음 정책 그룹을 추가하고, 규칙 제공자를 복구한 뒤 마지막으로 TUN 같은 시스템 기능을 활성화하세요. 각 단계가 끝날 때마다 웹페이지, 도메인 조회, 필요한 앱 연결을 테스트합니다. 문제가 생기면 이전 단계로 되돌릴 수 있어 완성된 설정에서 여러 호환성 문제를 한꺼번에 찾아야 하는 상황을 피할 수 있습니다.

서버나 라우터에서 코어를 실행할 때는 시작 관리, 수신 범위, 권한도 책임져야 합니다. 외부 제어 인터페이스를 공용 서비스 주소로 열지 말고 신뢰할 수 있는 로컬 환경이나 필요한 제한된 환경에서만 사용하세요. 배포 요건에 맞춰 접근 보호도 설정해야 합니다. 일반 사용자는 그래픽 클라이언트를 선택하는 편이 시스템 프록시와 권한을 관리하기 쉽습니다. 자동 실행, 서비스 관리, 라우터 트래픽 가로채기가 꼭 필요할 때만 코어를 직접 사용하고 시스템 설정을 관리하세요.

07 / 설정 공유

구독 형식과 설정 호환성

공유 링크, 노드 목록, 전체 설정

구독은 설정을 전달하는 방식이지 프록시 프로토콜이 아닙니다. 구독 주소에서 전체 Clash YAML, 인코딩된 공유 링크 목록, 특정 클라이언트 전용 형식 중 하나를 반환할 수 있습니다. 공유 링크에는 보통 노드 하나의 정보가 들어가지만 전체 설정에는 정책 그룹, 규칙, DNS, 수신 포트가 포함될 수 있습니다. 정보량이 서로 다르므로 파일이 다운로드된다는 이유만으로 가져온 뒤에도 원하는 라우팅 규칙이 모두 작동한다고 판단할 수 없습니다.

전체 YAML에서 노드는 보통 proxies, 정책 그룹은 proxy-groups, 규칙은 rules에 들어갑니다. 제공자를 사용하는 경우 proxy-providers나 rule-providers를 참조할 수도 있습니다. 클라이언트에 가져온 설정은 프로필로 저장될 수도 있고, 노드 정보만 추출한 뒤 설정을 새로 생성할 수도 있습니다. 먼저 가져오기 기능이 어떤 형식을 요구하는지 확인하세요. 노드 목록을 전체 설정 입력란에 넣으면 필드 누락 오류가 발생하거나 원하는 규칙 없이 실행될 수 있습니다.

변환만으로 기능이 추가되지는 않습니다

구독 변환은 필드 표현이나 대상 형식을 바꿀 수 있지만 코어에서 지원하지 않는 프로토콜을 갑자기 지원하게 만들지는 않습니다. 일부 공유 형식은 전송 세부 정보를 모두 표현하지 못하므로 변환 중에 플러그인, 경로, UDP, 특수 핸드셰이크 매개변수가 누락될 수 있습니다. 변환 결과가 문법 검사를 통과해도 실제 연결은 실패할 수 있습니다. 가능한 한 대상 클라이언트에서 바로 쓸 수 있는 구독을 요청하세요. 변환이 꼭 필요하다면 원본을 보관하고 복잡한 노드를 항목별로 확인하세요.

구독 링크에는 계정 접근 정보가 포함되는 경우가 많습니다. 링크를 가진 사람이 관련 설정을 읽을 수도 있습니다. 공개 스크린샷이나 질문 게시물, 잘 모르는 온라인 변환 페이지에 전체 주소를 올리지 마세요. 도움을 요청할 때는 인증 정보를 삭제한 오류 메시지, 프로토콜 유형, 관련 필드 이름만 보여 주세요. 로컬에서 변환해야 한다면 도구가 데이터를 어떻게 처리하는지 확인하세요. 링크를 짧은 주소로 바꿔도 해당 링크의 접근 권한이 사라지는 것은 아닙니다.

짧은 예제로 규칙 참조 이해하기

아래는 위에서 아래 순서로 규칙을 매칭하고 내장 DIRECT 정책을 사용하는 방법을 보여주는 설정 예제입니다. 프록시 노드가 없으므로 완전한 구독 설정이 아닙니다. 예시 도메인은 문법 설명용입니다. 실제 트래픽 분리는 앱의 요구 사항에 맞춰 조정해야 하며 이 짧은 예제로 기존 규칙 전체를 대체할 수는 없습니다. 기존 연결은 규칙을 변경한 뒤에도 경로가 바로 바뀌지 않을 수 있으므로 새 연결을 만들어 확인하세요.

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

규칙에서 사용하는 정책 이름은 실제로 존재하는 정책 그룹이나 내장 정책과 일치해야 합니다. 문자 하나만 달라도 파싱에 실패할 수 있습니다. 구독을 업데이트한 뒤 노드 이름이 바뀌면 이름으로 필터링하는 정책 그룹이 비어 있을 수도 있습니다. 제공자를 사용하는 경우 리소스 다운로드 성공 여부와 반환 형식도 확인해야 합니다. 기본 구독 업데이트에 성공했다고 모든 외부 규칙 세트와 노드 제공자가 정상적으로 로드된 것은 아닙니다. 로그에서 관련 결과를 각각 확인하세요.

오버라이드, 업데이트, 파싱 오류

많은 클라이언트는 구독 업데이트로 로컬 규칙이 덮어써지지 않도록 오버라이드, 병합, 확장 설정 기능을 제공합니다. 병합 순서는 클라이언트마다 다릅니다. 전체 블록을 교체하거나 목록을 추가하거나 스크립트로 결과를 만드는 방식이 있습니다. 사용하기 전에 최종 실행 설정을 확인할 수 있는 위치를 알아두고 변경 후 실제 결과를 점검하세요. 원본 구독과 오버라이드 양쪽에서 서로 반대되는 DNS 설정을 관리하면 다음 업데이트 때 어떤 설정이 적용됐는지 파악하기 어렵습니다.

YAML 오류는 들여쓰기, 탭 문자, 목록 단계, 특수 문자가 들어간 값에서 자주 발생합니다. 구독 주소가 로그인 페이지나 오류 페이지를 반환해도 설정 파싱 오류로 잘못 표시될 수 있습니다. 먼저 응답 내용이 올바른 설정인지 확인한 뒤 로그에서 오류가 난 줄과 필드를 찾으세요. 설정 파일 전체를 공개 검사 도구에 붙여 넣지 마세요. 업데이트에 실패하면 마지막으로 사용할 수 있었던 설정을 보관하고, 네트워크에서 가져오기 실패한 경우와 가져온 뒤 파싱에 실패한 경우를 구분하세요. 두 문제의 해결 방법은 다릅니다.

GeoIP, GeoSite 데이터는 노드 구독과 별개로 규칙 실행에 필요한 데이터입니다. 설정을 업데이트했어도 데이터베이스를 불러오지 못하면 일부 규칙이 제대로 작동하지 않을 수 있습니다. GeoIP·GeoSite 데이터베이스 업데이트 안내에서 자세히 확인하세요. 구독 관리의 목표는 출처, 로컬 수정 위치, 실패 후 복구 방법을 파악할 수 있게 하는 것입니다. 우연히 연결될 때까지 가져오기 방법을 계속 바꾸는 것이 아닙니다.

08 / 실제 선택

사용 상황별 선택과 단계별 문제 해결

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

데스크톱에서 일상적으로 사용할 때는 전체 구독 호환성, 연결 안정성, 유지관리 편의성을 우선 고려하세요. Clash Plus를 시작점으로 삼아 운영체제와 사용 습관에 맞는 다른 클라이언트를 비교한 뒤 서버에서 검증된 프로토콜 조합을 사용하면 됩니다. 현재 SS, Trojan, VLESS 설정이 안정적으로 작동한다면 이름이 새롭다는 이유만으로 프로토콜을 바꿀 필요는 없습니다. 회의, 개발 도구, 브라우저를 함께 사용할 때는 각 트래픽이 어떤 규칙에 연결되는지 확인해 작업에 필요한 연결이 다른 정책으로 잘못 분류되지 않도록 하세요.

모바일 기기에서는 네트워크 전환과 백그라운드 복구를 먼저 확인해야 합니다. 출퇴근 중의 신호 변동, 셀룰러와 Wi-Fi 간 전환, 화면이 잠겼을 때의 시스템 제한은 최고 속도보다 사용 경험에 더 큰 영향을 주는 경우가 많습니다. 후보 프로토콜을 시작, 대기, 화면 잠금 해제, 네트워크 전환의 네 가지 상태에서 테스트하세요. 현재 네트워크에서 QUIC 기반 설정이 안정적이라면 배터리 사용량도 비교해 볼 수 있습니다. UDP 연결이 자주 되지 않는다면 검증된 TCP 기반 설정을 기본 선택지로 유지하세요.

대용량 파일, 실시간 앱, 제한된 네트워크

대용량 파일을 전송할 때는 지속 처리량과 다른 서비스에 미치는 영향을 살펴보세요. 프로토콜을 비교하기 전에 원본 서버와 출구에서 속도 제한을 걸고 있지 않은지 확인해야 합니다. 병렬 다운로드 여러 개로 네트워크를 가득 채운 상태에서 웹 응답을 평가하지 마세요. Hysteria2의 대역폭 설정이나 다른 혼잡 제어 전략은 실제 회선에 맞춰야 합니다. 같은 가정용 네트워크에서 회의가 진행 중이라면 한 번 최고 속도를 내는 것보다 안정적으로 대역폭을 배분하는 편이 더 유용합니다. 프로토콜은 라우터의 적절한 대역폭 관리를 대신할 수 없습니다.

음성 통화, 게임 등 실시간 앱은 앱 자체가 UDP를 사용하는지, 클라이언트에서 해당 트래픽을 가로채고 서버가 전달하는지 확인해야 합니다. 노드 테스트 시간이 짧다고 게임 내 지연 시간도 낮다는 뜻은 아닙니다. 테스트 대상과 게임 서버가 다를 수 있기 때문입니다. 먼저 연결 로그에서 대상과 정책을 확인한 다음 회선을 바꿀지 판단하세요. UDP 제한이 뚜렷한 네트워크에서는 QUIC 기반 프로토콜로 바꾸면 기본 연결 문제가 해결될 것이라고 가정하지 마세요.

노드를 계속 바꾸지 말고 실패 단계부터 확인하세요

아예 연결할 수 없다면 먼저 로컬 네트워크, 서버 주소 조회, 포트 상태를 확인한 뒤 인증서나 프로토콜 핸드셰이크, 마지막으로 인증 정보를 살펴보세요. 핸드셰이크는 성공했는데 웹사이트가 열리지 않는다면 규칙 매칭, 출구 연결, DNS를 확인합니다. 일부 앱에서만 실패한다면 우선 트래픽 가로채기 범위와 UDP 조건을 확인하세요. 오류 내용과 발생 시간을 매번 기록하고, 같은 과정에서 모드 변경, DNS 수정, TUN 활성화, 프로토콜 변경을 한꺼번에 하지 마세요.

도메인은 열리지 않는데 IP 관련 테스트는 성공한다면 DNS 조회 문제일 수 있습니다. 하지만 HTTPS에는 올바른 도메인 이름이 필요하므로 IP에 직접 접속하는 것이 유효한 웹사이트 테스트라고 단정할 수는 없습니다. 인증서 검사를 끄지 말고 클라이언트 로그에서 도메인 조회와 실제 연결을 확인하세요. Fake-IP 모드에서 앱에 표시되는 가상 주소가 서버 주소에 문제가 있다는 뜻도 아닙니다. 작동 원리와 해결 방법은 자주 묻는 질문에서 확인할 수 있습니다. 설정을 바꾸기 전에 먼저 동작 방식을 파악하세요.

결론은 적용 조건과 함께 기록하세요

유용한 비교 기록에는 어떤 기기와 네트워크에서, 어느 시간대에, 어떤 작업을 할 때 안정적이었는지 적어야 합니다. 특정 프로토콜이 더 빠르다고만 기록해서는 안 됩니다. 비교 대상이 같은 회선을 사용하지 않았다면 결론은 해당 두 노드의 경험으로 한정하고 프로토콜 일반의 특성으로 확대 해석하지 마세요. 계속 실패한다면 연결 가능 여부, 인증, DNS 조회, 출구 문제를 구분해야 합니다. 그래야 전체 구독을 공개하지 않고도 서비스 제공업체에 재현 가능한 정보를 전달할 수 있습니다.

유지관리를 위해 매일 모든 매개변수를 다시 조정할 필요는 없습니다. 구독 업데이트, 시스템 업그레이드, 네트워크 전환 후에 간단한 점검을 실행하면 됩니다. 웹페이지와 DNS가 정상인지, 자주 쓰는 앱이 연결되는지, 필요한 UDP 앱이 작동하는지, 화면 잠금 해제 후 연결이 예상대로 복구되는지 확인하세요. 모드 변경의 영향을 알아보려면 규칙 모드, 전역 모드, 직접 연결 모드의 차이를 참고하고, 설치 과정을 다시 진행해야 한다면 가이드의 순서대로 설정하세요.

최종 선택은 네 가지 조건을 모두 충족해야 합니다. 현재 클라이언트에서 프로토콜 조합 전체를 구현할 수 있고, 서버 매개변수가 명확하고 유효하며, 네트워크에서 해당 전송 방식을 허용하고, 기기의 리소스와 배터리 비용을 감당할 수 있어야 합니다. 이 조건을 충족한 뒤에 성능 세부 사항을 비교하세요. 서버와 라우터에서는 권한, 수신 범위, 재시작 후 복구 여부도 확인해야 합니다. 이렇게 해야 한 번의 테스트나 프로토콜 이름에 의존한 임시 판단이 아니라 유지관리 가능한 설정을 만들 수 있습니다.