Clash 프로토콜 및 코어
기술 가이드

연결 계층: 클라이언트, 코어, 프로토콜

화면 조작과 실제 연결을 구분하세요

클라이언트는 설정 목록, 프록시 모드, 로그와 스위치를 보여 주는 조작 창구입니다. 코어는 설정을 해석하고 앱의 연결을 받아 규칙을 적용한 뒤 상위 서버와 연결합니다. Clash Nyanpasu의 인터페이스와 mihomo 코어는 서로 다른 계층에 있습니다. 화면에 설정 항목이 보인다고 해서 현재 실행 중인 코어가 해당 매개변수를 지원한다는 뜻은 아닙니다. 문제를 확인할 때는 바탕 화면 아이콘만 보고 기능을 판단하지 말고 클라이언트 이름, 실제 코어 이름, 현재 설정의 출처를 함께 기록하세요.

프로토콜은 클라이언트 코어와 원격 서버가 데이터를 인증하고 캡슐화해 전달하는 방식을 정합니다. 구독의 SS, VMess, VLESS는 연결 유형이지 클라이언트 모델이나 지리적 경로가 아닙니다. 원격 서버가 해당 프로토콜과 매개변수를 제공해야 합니다. 로컬 드롭다운에서 유형을 바꾼다고 기존 서버가 다른 프로토콜을 지원하게 되는 것은 아닙니다. 프로토콜을 선택하기 전에 서버에서 실제로 제공하는 연결 지점과 각 연결이 같은 장비 및 네트워크 경로를 사용하는지 확인하세요.

요청 과정을 확인 가능한 단계로 나누기

브라우저로 웹페이지를 열면 먼저 도메인 이름을 조회하고, 시스템 프록시나 가상 네트워크 인터페이스를 통해 연결이 코어로 전달됩니다. 코어는 규칙에 따라 직접 연결하거나 정책 그룹을 선택하고, 정책 그룹은 다시 상위 연결 지점을 고릅니다. 그 뒤에야 서버와 전송 연결을 맺고 인증 및 데이터 교환을 진행합니다. 어느 단계에서든 문제가 생기면 웹페이지가 열리지 않을 수 있습니다. 따라서 연결 실패가 곧 프로토콜 문제라는 뜻은 아닙니다. 요청이 클라이언트에 들어오지 않았거나 규칙이 사용할 수 없는 출구를 선택했을 수도 있습니다.

전송 계층과 프록시 프로토콜도 구분해야 합니다. TCP는 신뢰성 있는 순서 보장 바이트 스트림을 제공하고, UDP는 데이터그램을 전달합니다. TLS는 인증과 암호화 채널을 제공하며, QUIC는 UDP 위에서 보안 연결과 여러 스트림을 구성합니다. WebSocket은 또 다른 캡슐화 방식입니다. VLESS 항목 하나도 서로 다른 전송 및 보안 설정과 조합할 수 있습니다. 이름이 둘 다 VLESS여도 핸드셰이크 과정이나 지연 시간, 호환 조건은 다를 수 있습니다.

시스템 프록시와 TUN은 원격 프로토콜을 바꾸지 않습니다

시스템 프록시는 시스템 프록시 설정을 따르는 앱의 요청을 로컬 수신 포트로 전달합니다. TUN은 가상 네트워크 인터페이스를 통해 더 많은 네트워크 트래픽을 처리합니다. 둘의 차이는 트래픽이 코어로 들어오는 방식에 있으며, 원격 대역폭을 자동으로 늘리거나 서버에 UDP 전달 기능을 추가하지는 않습니다. 시스템 프록시에서는 작동하지 않던 앱이 TUN에서 정상 작동한다면 우선 진입 경로가 다르다는 뜻입니다. 이를 곧바로 SS가 Trojan보다 빠르거나 느리기 때문이라고 판단해서는 안 됩니다.

마찬가지로 규칙 모드, 전역 모드, 직접 연결 모드는 출구를 선택하는 방식이지 암호화 프로토콜 세 가지가 아닙니다. 규칙 모드는 규칙을 차례로 적용하고, 전역 모드는 관련 요청을 전역 선택에 맡기며, 직접 연결 모드는 프록시 출구를 우회합니다. 프로토콜을 비교할 때 모드와 정책 그룹을 고정하지 않으면 테스트 대상이 어느새 직접 연결로 바뀔 수 있습니다. 규칙 순서가 미치는 영향은 규칙 라우팅 실전 가이드에서 확인하세요.

권장 점검 순서: 요청이 코어에 들어왔는가 → 어떤 규칙이 적용됐는가 → 어떤 출구를 선택했는가 → 서버 연결이 수립됐는가 → 앱 데이터가 정상적으로 전달되는가. 먼저 문제가 발생한 계층을 찾고 프로토콜 매개변수를 조정하세요.

문제를 기록할 때는 막연하게 “연결이 안 됨”이라고 쓰기보다 상황을 한 문장으로 구체화하세요. 예: 특정 앱이 시스템 프록시를 통해 mihomo에 연결되고 지정된 정책 그룹을 적용한 뒤, 특정 프로토콜 연결 지점에서 핸드셰이크 오류가 발생함. 이런 정보가 있으면 점검 범위를 좁힐 수 있습니다. 로그의 도메인, 주소, 인증 정보에는 개인 설정이 포함될 수 있으므로 공유 전에 민감한 내용을 삭제하세요. 초기 분석에는 오류 유형, 발생 단계, 설정 필드 이름만으로도 충분한 경우가 많습니다.

SS와 VMess: 간결한 캡슐화와 전송 조합

Shadowsocks의 설계 특성

Shadowsocks는 보통 SS라고 부르며, 간결한 암호화 프록시 설계에서 출발했습니다. 클라이언트와 서버가 비밀번호와 암호화 방식을 약속하고, 적은 설정 항목으로 TCP 또는 UDP 트래픽을 전달합니다. 인증서나 웹 서비스, 복잡한 전송 조합을 필수 요소로 삼지 않아 일반적인 배포 구조가 비교적 단순합니다. 여기서 ‘경량’은 프로토콜과 배포 과정이 상대적으로 간결하다는 뜻입니다. 모든 기기에서 다른 프로토콜보다 리소스를 적게 쓴다는 보장은 없으며, 실제 사용량은 암호화 구현과 기기 성능에 따라 달라집니다.

SS를 선택할 때는 유형 표시만 확인해서는 안 됩니다. 암호화 방식은 클라이언트와 서버 양쪽에서 지원해야 하고, 비밀번호 형식도 해당 방식의 요구 사항에 맞아야 합니다. 최신 방식과 구형 방식은 키 처리, 재전송 방지, 구현 조건이 다르며 이름만 바꾼다고 업그레이드되지 않습니다. 특히 고정 길이 키를 사용하는 방식은 서버 설정이나 구독에서 올바른 값을 받아야 합니다. 일반 텍스트 비밀번호를 억지로 적용하지 마세요. 파싱 오류가 발생하면 네트워크를 살피기 전에 암호화 방식과 키 형식부터 확인하세요.

TCP와 UDP 지원 여부를 따로 확인하세요

SS 연결 지점에서 웹페이지가 열린다고 해서 게임, 음성 통화 등 데이터그램을 사용하는 앱도 작동한다고 볼 수는 없습니다. 웹페이지는 주로 TCP를 사용하지만 실시간 앱은 UDP에 의존할 수 있습니다. 서버, 방화벽, 구독 표기, 클라이언트 설정이 모두 UDP 전달에 영향을 줍니다. 클라이언트의 UDP 스위치는 관련 동작을 허용하는 여러 요소 중 하나일 뿐이며, 데이터그램 연결을 제공하지 않는 서버에 해당 기능을 만들어 주지는 않습니다. 테스트할 때는 실제로 데이터그램을 생성하는 앱을 사용하고 연결 기록을 확인하세요. 웹페이지 속도 측정 한 번으로는 충분하지 않습니다.

SS의 리소스 사용량은 암호화 방식에도 영향을 받습니다. 일부 프로세서는 특정 알고리즘에 맞는 하드웨어 가속을 지원하고, 다른 기기는 소프트웨어 효율이 높은 구현에서 더 나은 성능을 낼 수 있습니다. 저전력 라우터와 데스크톱 컴퓨터의 결과가 서로 다를 수도 있습니다. 알고리즘 순위를 추측할 필요는 없습니다. 서비스 제공업체가 지원하고 현재 코어에서 안정적으로 파싱되는 최신 방식을 우선 사용한 뒤, 지속 전송 중 프로세서 사용률과 실제 처리량을 확인해 기기 병목이 있는지 살펴보세요.

VMess의 인증 및 전송 조합

VMess는 V2Ray 생태계에서 시작된 프로토콜로, 사용자 식별자와 인증, 암호화를 기반으로 프록시 연결을 구성하며 여러 전송 방식과 조합할 수 있습니다. 일반적인 설정에는 서버와 포트뿐 아니라 사용자 식별자, 보안 설정, WebSocket 경로 또는 요청 헤더 등이 포함됩니다. 다양한 조합으로 기존 서비스 구조에 맞출 수 있지만 호환성 문제를 점검할 항목도 늘어납니다. 설정을 가져올 수 있다는 것은 로컬에서 형식을 읽었다는 뜻일 뿐, 원격 경로와 인증서, 인증 정보까지 일치한다는 뜻은 아닙니다.

VMess 인증에는 시간 정보가 사용되므로 기기 시계 오차가 크면 인증에 실패할 수 있습니다. 네트워크에 연결되고 포트 연결도 가능하지만 인증 오류가 계속된다면 시스템 시간과 시간대 표시, 자동 시간 동기화를 먼저 확인하세요. 오래된 자료에는 과거 호환성 매개변수가 포함될 수 있으므로 현재 코어가 모든 구형 동작을 지원한다고 단정해서는 안 됩니다. 오래된 구독을 가져온 뒤 필드 경고가 뜨면 매개변수를 무작정 바꾸기보다 설정 제공처에 형식을 확인하세요.

둘 중 어떤 것을 선택할지 판단하는 방법

서버에서 안정적인 SS 연결을 제공하고 설정이 단순하며 필요한 앱도 잘 작동한다면, 다른 프로토콜의 이름이 더 새롭다는 이유만으로 바꿀 필요는 없습니다. 기존 서비스가 특정 전송 경로에 의존한다면 VMess의 조합 설정이 더 적합할 수 있습니다. 두 프로토콜을 비교할 때는 서버 위치, 네트워크 출구, 테스트 시간을 최대한 비슷하게 맞추세요. 그렇지 않으면 프로토콜보다 네트워크 경로의 차이를 측정하게 됩니다. 혼잡한 연결과 한산한 연결의 결과를 프로토콜 성능 차이의 근거로 삼지 마세요.

전환할 때는 기존 설정을 보존하고 복사본을 만들어 테스트하세요. 새 연결의 인증 방식, 전송 유형, UDP 지원 여부도 확인해야 합니다. 한 번에 연결 지점 하나만 바꾸고 같은 앱으로 첫 요청, 연속 다운로드, 짧은 네트워크 끊김 후 복구를 다시 확인하세요. 테스트가 끝난 뒤 일상적으로 사용하는 정책 그룹을 조정하면 됩니다. 새 연결이 현재 네트워크에 맞지 않더라도 기존 설정으로 빠르게 되돌릴 수 있어 구독, 규칙, 프로토콜 변경이 뒤섞이는 일을 막을 수 있습니다.

Trojan과 VLESS: 인증과 보안 계층의 역할

Trojan은 TLS 채널 안에서 프록시 인증을 처리합니다

Trojan은 일반적으로 먼저 TLS 연결을 맺은 다음 보안 채널 안에서 프록시 인증과 요청 전달을 수행합니다. 성숙한 TLS 메커니즘으로 연결 암호화와 서버 인증을 처리하고, 프록시 계층에서는 비밀번호 등의 정보로 사용자를 확인합니다. 클라이언트 설정의 핵심은 서버 주소, 포트, 비밀번호, 인증서 이름입니다. 구조가 일반적인 보안 연결과 비슷해 보여도 원격에는 호환되는 프록시 서버가 필요합니다. 임의의 웹사이트 주소를 Trojan 연결 지점으로 사용할 수는 없습니다.

연결 주소와 인증서 이름은 서로 다를 수 있습니다. 클라이언트는 특정 주소에 연결하면서 SNI로 서비스 이름을 지정하고, 인증서가 예상한 이름과 일치하는지 검증할 수 있습니다. 인증서가 만료됐거나 이름이 일치하지 않거나 기기에 필요한 신뢰 체인이 없으면 핸드셰이크가 실패할 수 있습니다. 이때는 인증서를 바로 검증하지 않도록 바꾸기보다 구독에 지정된 이름, 시스템 시간, 인증서 구성을 확인하세요. 인증서 검증을 끄면 서버 신원 확인이 약해집니다. 연결이 되더라도 설정 또는 서버 문제를 해결한 것은 아닙니다.

VLESS는 프록시 계층을 간결하게 유지합니다

VLESS 역시 관련 프록시 생태계에서 시작했지만 프록시 계층을 더 간결하게 구성하고, 이 계층 자체에서 완전한 콘텐츠 암호화를 제공하지 않습니다. 보호 기능은 보통 TLS나 다른 보안 메커니즘이 담당합니다. 사용자 식별자, 전송, 보안 계층의 역할을 나눠 조합하기 쉽지만 각 계층의 기능을 이해해야 합니다. ‘VLESS’라는 이름만으로 연결이 암호화되는지 알 수 없으므로 보안 설정과 실제 서버 구성을 확인하세요.

일반적인 VLESS 항목은 TCP, WebSocket, gRPC 등의 전송 방식과 조합하거나 flow 같은 추가 필드를 사용할 수 있습니다. 전송 유형, 경로, 서비스 이름과 관련 매개변수는 서버 설정과 한 세트로 일치해야 합니다. 코어가 기본 VLESS를 지원하더라도 모든 신규 확장이나 조합까지 지원하는 것은 아닙니다. 특히 다른 코어에서 내보낸 설정은 필드 이름이 비슷해도 의미까지 같다고 단정할 수 없습니다. 현재 코어 문서에서 지원 범위를 확인하세요.

TLS, REALITY, flow는 같은 계층의 개념이 아닙니다

TLS는 범용 보안 전송 메커니즘이고, REALITY는 일부 생태계에서 사용하는 별도의 보안 핸드셰이크 방식입니다. flow는 특정 연결 처리 방식을 지정하는 설정 필드입니다. 이 셋을 서로 바꿔 쓸 수 있는 태그처럼 취급해서는 안 됩니다. 서버에서 사용하는 조합에 맞춰 클라이언트 매개변수를 설정해야 하며 코어도 해당 조합을 지원해야 합니다. 공개 키, 이름 또는 필수 정보가 없다면 구독 제공처에서 완전한 설정을 받아야 합니다. 관계없는 안내서에서 매개변수를 가져와 임의로 조합하지 마세요.

오류가 발생한 단계를 확인하면 원인을 찾기 쉽습니다. 인증서나 보안 핸드셰이크 오류라면 보안 계층을, 핸드셰이크 완료 후 인증 실패라면 비밀번호나 사용자 식별자를 먼저 확인하세요. 특정 경로만 실패한다면 WebSocket 경로, 요청 헤더, gRPC 서비스 이름을 살펴보세요. 로그에 시간 초과만 표시된다면 주소 조회 오류, 포트 연결 실패, 서버 미수신 상태도 확인해야 합니다. 프로토콜 이름은 분류에 도움이 되지만 호환성은 대개 이러한 조합 필드에 달려 있습니다.

이름의 길이가 아니라 서버 구성을 기준으로 선택하세요

인증서를 배포하고 안정적인 TLS 연결을 제공하는 환경에서는 Trojan이 설명과 유지 관리가 간편한 경우가 많습니다. 특정 전송 조합을 계속 사용해야 하고 양쪽 코어의 지원 범위가 명확하다면 VLESS를 고려할 수 있습니다. 이는 속도 순위가 아닙니다. 추가 캡슐화, 연결 재사용, 인증서 핸드셰이크, 서버 부하가 모두 사용 경험에 영향을 줍니다. 두 설정이 같은 서버를 사용하더라도 서로 다른 연결 지점이나 리버스 프록시를 거칠 수 있으므로 실제 경로를 확인한 뒤 비교하세요.

인증서 검증 건너뛰기를 만능 해결책으로 사용하지 마세요. 먼저 서비스 이름과 인증서 유효성, 기기 시간을 확인하세요. 신뢰 경계를 이해한 통제된 테스트에서만 검증 정책을 임시로 변경하는 방법을 검토해야 합니다.

전환 과정에서는 구독 변환도 주의해야 합니다. 일부 변환 과정은 서버, 포트, 사용자 식별자를 유지하면서 확장 필드를 누락할 수 있습니다. 이 경우 목록은 정상적으로 표시되지만 연결이 계속 실패합니다. 원본 항목과 비교해 전송 및 보안 계층 정보가 모두 남아 있는지 확인하세요. 클라이언트 화면에 간단한 요약만 표시된다면 코어 로그와 실제 적용 설정도 함께 확인하세요. 화면의 프로토콜 태그만 보고 변환이 제대로 됐다고 판단하지 마세요. 전체 설정 이전 방법은 뒤의 구독 호환성 절을 참고하세요.

Hysteria2와 TUIC: QUIC 기반 프로토콜 선택

UDP 기반 안정적 전송이 필요한 이유

Hysteria2와 TUIC는 모두 QUIC 기반 설계를 사용합니다. QUIC는 UDP 위에서 보안 핸드셰이크, 안정적인 전송, 다중 스트림을 구현해 연결 제어를 시스템 TCP 스택에만 의존하지 않습니다. 스트림 사이의 일부 대기 현상을 줄일 수는 있지만 물리적 회선의 혼잡을 없애거나 패킷 손실을 막아 주지는 않습니다. QUIC로 바꾸는 것은 전송 동작을 변경하는 것이지 네트워크 대역폭을 늘리거나 지리적 거리를 줄이는 것이 아닙니다.

이런 프로토콜을 사용하려면 현재 네트워크에서 관련 UDP 통신이 허용되어야 합니다. 웹페이지가 TCP로 정상 작동한다고 해서 QUIC 연결도 가능하다는 뜻은 아닙니다. 사무실이나 게스트 네트워크, 일부 접속 장비는 UDP를 제한할 수 있고 원격 방화벽도 해당 포트를 허용해야 합니다. 같은 설정이 모바일 네트워크에서는 작동하지만 특정 Wi-Fi에서 계속 핸드셰이크 시간 초과가 발생한다면 먼저 네트워크 경로 차이를 의심하세요. 이때는 시간 제한을 계속 늘리기보다 사용할 수 있는 TCP 연결을 대안으로 남겨 두는 편이 효과적입니다.

Hysteria2의 대역폭 및 혼잡 제어

Hysteria2는 높은 처리량과 복잡한 네트워크 환경을 염두에 두고 설계됐으며, 예상 대역폭과 관련된 설정을 지원합니다. 실제 혼잡 제어 방식은 양쪽 구현과 협상된 설정에 따라 달라지므로 모든 연결이 일정한 속도로 데이터를 보낸다고 단순화할 수 없습니다. 클라이언트의 업로드·다운로드 대역폭 값도 서비스 보장이 아니라 관련 제어 메커니즘의 입력값입니다. 설정할 때 방향과 단위를 이해하고 실제 사용 가능한 회선 성능에 맞추세요.

실제 회선 능력보다 훨씬 높은 대역폭을 설정하면 대기열과 패킷 손실이 늘고 다른 앱의 응답이 늦어질 수 있습니다. 속도 측정 결과는 좋아 보여도 대화형 작업은 불안정해질 수 있습니다. 모바일 네트워크의 가용 속도는 신호와 시간대에 따라 바뀌므로 유선 회선에 맞춘 설정이 출퇴근 중에도 적합하다고 볼 수 없습니다. 화상 통화가 영향을 받거나 다운로드 중 웹페이지가 느려진다면 수치를 더 높이기보다 동시 연결 수와 대역폭 기대치를 낮춰 혼잡이 줄어드는지 확인하세요.

TUIC의 연결 재사용과 데이터그램

TUIC도 QUIC로 프록시 연결을 구성하며 인증, 스트림, 데이터그램 전달 등의 기능을 포함합니다. 설정에는 보통 사용자 식별자, 비밀번호, 인증서 관련 정보가 들어가며 일부 구현은 혼잡 제어, UDP 전달 방식, 연결 유지 옵션도 제공합니다. 프로토콜 세대와 구현의 지원 범위를 맞춰야 합니다. 구형 형식과 최신 형식이 같은 이름을 사용하더라도 인증 필드와 동작이 완전히 같다고 가정할 수 없습니다. 현재 코어가 지원하는 형식인지 구독에서 확인하세요.

짧은 연결이 많은 환경에서는 기존 보안 연결을 재사용해 연결 설정을 반복하는 비용을 줄일 수 있습니다. 실제 이점은 세션 유지 가능 여부, 네트워크 안정성, 코어의 연결 관리 방식에 따라 달라집니다. 기본 QUIC 연결은 여전히 같은 물리 회선과 혼잡 예산을 공유하므로 대용량 작업이 다른 요청에도 영향을 줄 수 있습니다. 다중 스트림을 앱마다 독립적인 대역폭이 제공되는 것으로 오해하지 마세요. 짧은 속도 측정 한 번만으로 장기간 사용할 프로토콜을 결정해서도 안 됩니다.

데이터그램, MTU, 네트워크 전환의 한계

QUIC 데이터그램 경로는 경로 MTU, 조각 처리, 중간 장비 동작의 영향을 받을 수 있습니다. 핸드셰이크는 성공하고 적은 양의 데이터는 정상인데 대용량 전송이 반복해서 멈추는 증상이 나타날 수 있습니다. TUN과 추가 터널, 접속 네트워크가 겹치면 겉으로 드러난 증상만으로 원인을 찾기 어려워집니다. 일반 사용자는 우선 클라이언트와 서버의 기본 설정을 사용하고 다른 네트워크에서 다시 시험한 뒤 하나씩 점검하세요. MTU와 혼잡 제어, 인증서 매개변수를 한꺼번에 바꾸지 마세요.

QUIC는 연결 마이그레이션 기능을 지원하지만 모든 클라이언트에서 Wi-Fi와 모바일 네트워크 사이를 끊김 없이 전환할 수 있다는 뜻은 아닙니다. 클라이언트 구현과 서버 지원, 주소 변경, 앱의 연결 상태가 모두 결과에 영향을 줍니다. 네트워크를 자주 바꾼다면 화면 잠금 해제 후 복구, 네트워크 전환 후 재연결, 약한 신호에서의 사용 가능성을 테스트하세요. 장시간 다운로드에서의 장점이 메시지 전송이나 백그라운드 동기화의 안정성으로 이어지지 않을 수도 있습니다.

따라서 Hysteria2와 TUIC는 모든 TCP 연결을 기본적으로 대체하기보다 실측을 거쳐 선택할 후보로 적합합니다. 먼저 UDP 경로와 인증서 인증을 확인한 뒤 연속 전송과 대화형 작업을 비교하세요. 네트워크 제한이 뚜렷하다면 안정적인 TCP 계열 연결을 사용하는 편이 간편합니다. 최종 사용자에게는 고급 스위치가 많다는 점보다 문제를 복구하고 설명할 수 있으며 설정 출처가 명확하다는 점이 더 중요합니다.

성능과 배터리: 연결 속도와 다운로드 속도는 다릅니다

‘속도’를 세 가지 지표로 나눠 보기

연결 경험은 최소한 연결을 맺기까지 걸리는 시간, 첫 콘텐츠가 도착하는 시간, 지속 전송 처리량으로 나눠 볼 수 있습니다. 작은 웹페이지를 열 때는 이름 조회와 핸드셰이크, 서버 응답이 중요할 수 있습니다. 대용량 파일 다운로드는 회선 용량과 혼잡, 흐름 제어의 영향을 더 많이 받으며 원격 작업은 지터와 순간적인 패킷 손실에 민감합니다. 모든 지표에 공통으로 적용되는 순위는 없습니다. 다운로드는 빠르지만 웹페이지 첫 화면이 늦게 뜨는 것도 모순이 아니며, 단일 지연 시간 값으로 모든 앱의 사용 경험을 설명할 수도 없습니다.

클라이언트의 URL Test는 일반적으로 테스트 주소에 요청을 보내며 결과는 대상 서버, 연결 상태, 시간 제한, 구현 세부 사항에 따라 달라집니다. 순수한 지리적 왕복 시간도 아니고 대역폭 보장도 아닙니다. 테스트 대상의 응답이 느리면 값이 높게 나올 수 있고, 기존 연결을 재사용하면 더 낮게 측정될 수 있습니다. 테스트 값과 실제 인터넷 속도의 차이는 노드 지연 시간 측정 방식에서 자세히 확인하세요.

리소스 사용량은 전체 연결 경로에서 발생합니다

프로세서 사용량에는 암호화뿐 아니라 데이터 복사, 가상 네트워크 스택, 규칙 적용, 데이터그램 캡슐화, 로그 처리도 포함됩니다. 메모리 사용량은 동시 연결 수, 캐시, 규칙 데이터, 인터페이스 프로세스와 관련이 있습니다. 데스크톱 작업 관리자에 표시된 클라이언트 전체 사용량을 특정 프로토콜의 비용으로 볼 수는 없습니다. 비교할 때는 인터페이스와 코어 프로세스를 구분하고 규칙 규모와 트래픽 처리 방식을 동일하게 맞춘 뒤 유휴, 대화형 작업, 연속 전송 상태를 관찰하세요.

암호화 알고리즘이 하드웨어 명령어를 활용할 수 있는지에 따라 기기별 성능이 달라집니다. QUIC의 사용자 공간 처리와 추가 캡슐화, 연결 관리도 부담을 늘릴 수 있습니다. 반대로 적절한 연결 재사용과 혼잡 제어는 대기와 반복 작업을 줄일 수 있습니다. UDP 프로토콜은 항상 배터리를 더 많이 쓰거나 간결한 프로토콜은 무조건 전력 효율이 가장 좋다고 단정할 수 없습니다. 성능이 낮은 기기에서는 지속 부하 중 프로세서가 최대 사용률에 도달하는지, 발열이 생기는지, 처리량 증가가 멈추는지 확인하세요.

모바일 배터리에는 백그라운드 동작이 더 큰 영향을 줍니다

휴대폰에서는 암호화 연산 한 번보다 무선 모듈 깨우기, 연결 유지 신호, 백그라운드 재시도, 네트워크 전환이 더 중요할 수 있습니다. 연결 유지 간격이 너무 짧으면 소량의 데이터가 자주 전송돼 무선 모듈이 오래 활성 상태로 남을 수 있습니다. 반대로 간격이 너무 길면 중간 장비가 유휴 매핑을 지워 연결 복구 때 다시 연결해야 할 수 있습니다. 적절한 값은 접속 네트워크와 앱 요구 사항에 따라 다릅니다. 일반 사용자는 기본값을 유지하고 분명한 문제가 있을 때만 조정하세요.

속도 측정을 계속하면 화면과 프로세서, 무선 전송이 동시에 활성화되므로 그 결과만으로 일상적인 배터리 사용량을 판단할 수 없습니다. 화면 밝기와 신호 강도, 앱을 비슷하게 맞춰 일상적으로 사용한 뒤 시스템 배터리 통계를 비교하고 화면이 꺼진 동안 비정상적인 트래픽이나 재연결이 있었는지 확인하는 편이 낫습니다. 특정 연결에서 배터리 소모가 크게 늘어난다면 실패 후 재시도, 잦은 전환, 과도한 연결 유지 신호를 확인하세요. 문제를 프로토콜 유형 탓으로만 돌리지 마세요.

반복 가능한 비교 테스트 만들기

같은 서비스에서 경로가 비슷한 연결 두 개를 고르고 클라이언트, 규칙, 테스트 앱을 고정하세요. 매번 새로 연결해 웹페이지를 열고, 연속 전송을 진행하고, 일시 중단 후 복구한 다음, 네트워크 전환도 차례로 확인하세요. 시간대를 바꿔 여러 번 반복합니다. 최고 속도 하나보다 대용량 파일 실행 후 음성 통화가 끊기는지, 화면이 꺼진 뒤 수동으로 다시 연결해야 하는지처럼 증상을 기록하는 편이 유용합니다. 서버가 다른 두 연결을 비교했다면 결론은 ‘현재 네트워크에서는 이 연결이 더 적합하다’고 적으세요. 프로토콜 자체의 우열로 단정해서는 안 됩니다.

마지막으로 반복해서 확인할 수 있는 차이만 남기세요. 한 번 발생한 시간 초과는 대상 웹사이트나 일시적인 네트워크 변화 탓일 수 있으므로 장기적인 성능을 뒤집는 근거가 되지 않습니다. 일상적인 연결은 처리량보다 안정성과 복구를 우선하고, 휴대폰에서는 백그라운드 안정성과 배터리도 고려하세요. 연결 문제는 먼저 자주 묻는 질문에서 시스템 프록시, TUN, 설정 활성화 상태를 확인해 불필요한 변수를 줄이세요.

코어 계열: 원본, Meta, mihomo

이름의 관계와 기능 범위

원본 Clash는 규칙, 정책 그룹, 설정 파일, 제어 인터페이스의 기본 구조를 정립했으며 많은 클라이언트가 이러한 개념을 이어받았습니다. Clash.Meta는 관련 오픈 소스 생태계를 기반으로 프로토콜과 네트워크 기능을 확장했고, mihomo는 이 계열의 개발을 이어가고 있습니다. 기존 명칭의 영향으로 자료에서는 Meta와 mihomo가 함께 언급되는 경우가 많습니다. 하지만 특정 기능을 확인할 때는 문서 제목만 믿지 말고 실제 실행 중인 코어와 해당 문서를 기준으로 판단하세요.

원본 설정의 기본 구조 중 상당수는 이후 코어에서도 사용할 수 있습니다. 규칙 목록과 일반적인 정책 그룹이 그 예입니다. 반대 방향의 호환성은 보장되지 않습니다. 새 프로토콜이나 DNS 옵션, 네트워크 스택 매개변수가 포함된 설정은 기능이 제한된 구형 코어에서 파싱되지 않거나 일부 필드가 무시될 수 있습니다. 설정 호환성에는 방향과 범위가 있으므로 파일 확장자가 같다고 모두 호환되는 것은 아닙니다. 호환성을 확인할 때는 ‘Clash를 지원하나요?’라고만 묻지 말고 각 필드의 지원 여부를 확인하세요.

GUI 클라이언트는 별도의 프로토콜이 아닙니다

Clash Nyanpasu, Clash Verge Rev, FlClash 등의 이름은 각각 다른 인터페이스와 통합 방식, 코어 관리 방식을 가진 클라이언트 제품을 가리킵니다. Clash Plus는 다운로드 센터에서 우선 추천하는 선택지입니다. 먼저 사용 플랫폼과 설정 출처를 기준으로 적합성을 확인하고, 특정 데스크톱 설정이나 작업 흐름이 필요하다면 다른 클라이언트와 비교하세요. 어떤 클라이언트를 사용하든 실제 코어와 설정 기능을 확인해야 합니다. 클라이언트 이름만으로 지원 프로토콜을 판단할 수는 없습니다.

일부 클라이언트는 코어 전환을 지원하지만 실행 환경도 달라질 수 있으므로 실행 파일 하나만 바꾸는 작업으로 볼 수 없습니다. 설정 생성 방식, 실행 매개변수, 권한, 제어 인터페이스 호환성이 영향을 받을 수 있습니다. 화면에 Clash Rust나 다른 코어 이름이 표시돼도 mihomo의 모든 설정 필드와 동등하다는 뜻은 아닙니다. 먼저 클라이언트가 공식 지원하는 조합을 확인하고 기존 규칙, 구독, 네트워크 처리 기능을 테스트하세요. 이름이 비슷하다는 이유만으로 바로 전환하지 마세요.

안정 버전 코어와 Alpha 선택

Alpha는 일반적으로 개발 중인 빌드를 뜻합니다. 새 기능 지원이나 수정이 먼저 포함될 수 있지만 동작이 바뀔 수도 있습니다. 성능이 더 좋다는 보장은 없으며 눈에 띄는 태그만 보고 장기간 사용할 빌드로 바꾸는 것도 바람직하지 않습니다. 일반 사용자는 클라이언트가 권장하는 안정 버전을 우선 사용하세요. 안정 버전에 아직 포함되지 않은 기능이 꼭 필요하다면 프로젝트 안내를 확인한 뒤 테스트하세요. 검증되지 않은 특정 버전 번호만으로 지원 여부를 판단하지 말고 최신 기능 문서와 릴리스 노트를 확인하세요.

업데이트하기 전에 구독 출처, 클라이언트 설정, 로컬 규칙 복사본을 보관하고 이전 코어로 복구할 수 있는지 확인하세요. 업데이트 후에는 시작 로그에서 설정이 정상적으로 불러와졌는지 확인한 뒤 웹페이지와 데이터그램 앱, 절전 모드 복귀를 테스트하세요. 업그레이드와 함께 새 경고가 나타났다면 필드별 의미를 확인하세요. 설정 파싱에 성공했다고 해서 DNS와 라우팅, 정책 동작까지 기존과 완전히 같다는 뜻은 아닙니다. 기본 동작이 바뀌었을 가능성이 있다면 실제 환경에서 더 꼼꼼히 확인해야 합니다.

제어 인터페이스와 권한도 호환성에 포함됩니다

클라이언트는 로컬 제어 인터페이스를 통해 연결 정보를 읽고 정책을 바꾸거나 로그를 확인하는 경우가 많습니다. 인터페이스 주소, 인증 정보, 포트가 맞지 않으면 코어는 실행됐지만 화면에는 연결 끊김으로 표시되거나 조작할 수 없는 상황이 발생할 수 있습니다. 이는 관리 경로 문제이지 프록시 프로토콜 실패가 아닐 수 있습니다. 제어 인터페이스를 신뢰할 수 없는 네트워크에 직접 노출하지 마세요. 화면에서 상태를 읽지 못한다고 모든 요청이 전달되지 않는다고 단정하지 말고 프로세스와 수신 상태, 요청 경로를 각각 확인하세요.

TUN은 가상 인터페이스와 시스템 권한에도 의존합니다. 코어에서 관련 기능을 지원하더라도 현재 설치 방식에 필요한 권한이 부여됐다는 뜻은 아닙니다. 데스크톱 시스템의 서비스 모드, 네트워크 확장, 권한 요청은 클라이언트 안내에 따라 처리하세요. 코어를 바꾼 뒤 TUN만 실패하고 시스템 프록시는 작동한다면 프로토콜보다 권한과 네트워크 스택을 먼저 확인하세요. 트래픽 진입 경로, 코어 기능, 원격 연결을 따로 검증하면 같은 문제를 해결하려고 클라이언트를 계속 바꾸는 일을 줄일 수 있습니다.

설정을 이전할 때는 ‘실제 코어 → 필드 지원 → 트래픽 처리 권한 → 앱 테스트’ 순서로 확인하세요. 클라이언트 인터페이스가 같아도 내부 동작은 다를 수 있으며 같은 계열의 코어라도 모든 확장을 양방향으로 호환하지는 않습니다.

구독 호환성: 링크 형식부터 적용 설정까지

구독 주소와 노드 설정은 다릅니다

구독 주소는 설정 내용을 가져오는 진입점입니다. 응답은 전체 YAML, 노드 링크 목록, 인코딩된 텍스트, 특정 클라이언트 전용 형식일 수 있습니다. 브라우저에서 주소가 열린다는 사실은 응답을 받았다는 뜻일 뿐 현재 클라이언트에 맞는 내용이라는 보장은 없습니다. 로그인 페이지와 만료 안내, 웹 오류 메시지가 정상 응답처럼 반환될 수도 있습니다. 파싱에 실패하면 업데이트 버튼을 반복해서 누르기 전에 응답 형식과 클라이언트가 요구하는 형식을 확인하세요.

mihomo 전체 설정에는 일반적으로 프록시 항목, 정책 그룹, 규칙, 선택적으로 DNS 설정 등이 포함됩니다. 단일 프로토콜 링크에는 보통 연결 지점 하나의 정보만 들어 있습니다. 클라이언트에서 가져오기와 조합을 지원하더라도 모든 제품이 같은 형식을 지원하지는 않습니다. 서비스 제공업체가 여러 구독 버튼을 제공한다면 현재 코어에 맞는 형식을 명확히 선택하세요. 파일 확장자가 YAML이라고 해서 모든 프로토콜과 확장 필드가 올바르게 변환됐다고 볼 수는 없습니다.

형식 확인 후에는 설정의 의미도 검토하세요

YAML에는 들여쓰기와 목록, 문자열 구조에 관한 규칙이 있습니다. 복사 과정에서 탭 문자가 섞이거나 들여쓰기가 어긋나거나 특수 문자가 들어가면 설정 전체를 불러오지 못할 수 있습니다. 반대로 문법이 맞아도 참조가 올바르다는 보장은 없습니다. 규칙이 지정하는 정책 그룹이 있어야 하고 정책 그룹이 참조하는 연결 이름도 실제로 존재해야 합니다. 구독을 업데이트한 뒤 이름이 바뀌면 로컬 오버라이드 규칙에 영향을 줄 수 있습니다. 점검할 때는 특정 줄의 철자만 보지 말고 파싱 오류와 참조 관계를 함께 확인하세요.

아래의 짧은 예시는 직접 연결과 정책 그룹 참조의 기본 구조를 보여 줍니다. 원격 서비스 인증 정보는 포함하지 않습니다. 여기서 Proxy는 사용자가 임의로 정한 정책 그룹 이름이지 프로토콜 유형이 아닙니다. 현재 DIRECT만 포함하므로 원격 프록시 연결은 수립되지 않습니다. 실제 설정에서는 사용 가능 여부를 확인한 연결을 그룹에 추가한 뒤 규칙에서 해당 그룹을 참조하세요. 이 이름 관계를 이해하면 규칙마다 수정하지 않고도 클라이언트에서 출구를 바꿀 수 있는 이유를 알 수 있습니다.

mode: rule
proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT
rules:
  - DOMAIN-SUFFIX,github.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

변환 과정에서 누락될 수 있는 정보

구독 형식을 변환할 때 기본 주소와 포트는 대체로 유지하기 쉽지만 확장 보안 필드, 전송 매개변수, 데이터그램 옵션, 프로토콜별 설정은 달라질 수 있습니다. 대상 형식에서 지원하지 않는 필드는 변환만으로 만들 수 없고 변환 도구가 새 필드의 의미를 알지 못할 수도 있습니다. 변환 후 특정 프로토콜 계열만 실패한다면 해당 유형에 필요한 필드를 비교하세요. 모든 연결을 한꺼번에 바꾸지는 마세요. 원본 구독이 작동한다면 불필요한 변환 단계를 줄이는 편이 좋습니다.

구독 주소 자체에 접근 자격 증명과 사용량 정보가 포함될 수 있습니다. 변환 서비스에 전달하면 주소와 관련 설정을 다른 곳에서 처리하게 됩니다. 변환 방식을 선택할 때 데이터가 어디로 전달되는지 확인하고 출처를 알 수 없는 사이트에 비공개 구독 주소를 붙여 넣지 마세요. 문제를 공유할 때도 전체 주소와 사용자 식별자, 비밀번호를 삭제하세요. 프로토콜 유형, 필드 이름, 오류 설명만으로 형식 미지원인지 인증 실패인지 네트워크 시간 초과인지 판단할 수 있는 경우가 많습니다.

업데이트로 로컬 수정 사항이 사라지지 않게 하기

원격 구독은 업데이트할 때 내용을 다시 생성하므로 다운로드한 파일을 직접 편집하면 다음 새로 고침 때 변경 사항이 사라질 수 있습니다. 개인 규칙이나 정책 설정을 유지하려면 클라이언트가 제공하는 오버라이드, 병합, 로컬 설정 기능을 사용하고 어느 단계에 적용되는지 확인하세요. 클라이언트마다 병합 방식이 다릅니다. 목록 전체를 교체하는 경우도 있고 항목을 추가하는 경우도 있습니다. ‘병합’이 기존 순서를 유지한다고 가정하지 마세요. 규칙 목록은 위에서 아래로 적용되므로 순서가 실제 출구를 바꿀 수 있습니다.

업데이트에 실패하면 마지막으로 사용할 수 있었던 설정부터 보존하고 링크 유효성, 응답 형식, YAML 구조, 필드 지원, 네트워크 연결을 순서대로 확인하세요. 전체 절차는 구독 업데이트 실패 점검 가이드에서 확인할 수 있습니다. 설정은 불러왔지만 도메인 접속만 문제가 있다면 DNS와 규칙 데이터를 확인하세요. GeoIP 및 GeoSite 데이터베이스 안내를 참고하면 구독 내용 문제와 외부 규칙 데이터 문제를 구분하는 데 도움이 됩니다.

마지막으로 방금 가져온 설정이 클라이언트에서 실제로 활성화됐는지 확인하세요. 파일을 저장하기만 한 상태일 수도 있습니다. 적용된 설정 이름과 로그, 실제 연결에 적용된 정책을 확인해 가져오기, 로드, 규칙 적용, 전달 과정을 모두 검증하세요.

사용 환경별 선택: 제약 조건을 먼저 정하고 연결을 비교하세요

데스크톱 업무와 일상적인 웹 사용

데스크톱 업무에서는 안정성, 절전 모드 복귀, 기존 앱과의 호환성을 우선하세요. 먼저 다운로드 센터에서 추천하는 Clash Plus가 플랫폼에 맞는지 확인하고, 인터페이스 작업 흐름과 필요한 코어 기능에 따라 Clash Nyanpasu, Clash Verge Rev, FlClash를 비교하세요. 안정적으로 작동하는 연결이 있다면 프로토콜 이름을 바꾸기 위해 전환할 필요는 없습니다. 주로 웹, 이메일, 개발 도구를 사용한다면 시스템 프록시와 명령줄 환경이 같은 설정을 사용하는지 확인하세요. ‘특정 프로토콜에서 접속이 안 됨’이라는 문제가 사실은 앱이 같은 연결 경로를 사용하지 않아서 발생하는 경우가 많습니다.

로컬 서비스, 코드 저장소, 기타 업무 트래픽을 구분해야 할 때는 프로토콜 차이보다 규칙 품질이 사용 경험에 더 큰 영향을 줄 수 있습니다. 먼저 안정적인 연결 하나를 고정하고 로컬 네트워크, 직접 연결, 프록시 정책을 정리한 뒤 전송 성능을 비교하세요. 개발 도구는 자체 프록시 설정과 인증서 신뢰 저장소를 사용할 수 있으므로 브라우저가 정상 작동한다고 터미널 명령도 정상이라고 볼 수 없습니다. 테스트 기록에는 앱 이름과 트래픽 처리 방식을 명시하세요. 브라우저 한 번의 결과로 컴퓨터 전체를 판단하지 마세요.

모바일 네트워크, 음성 통화, 연속 다운로드

출퇴근 중에는 신호가 바뀌고 네트워크가 전환되는 일이 잦으므로 한 번의 속도 측정 최고값보다 복구 속도, 백그라운드 안정성, 배터리 사용량을 우선해야 합니다. 먼저 매개변수가 적고 출처가 분명한 연결을 사용하고 다른 전송 경로도 대안으로 남겨 두세요. 음성 통화나 게임을 사용한다면 전체 연결 경로가 UDP 전달을 지원하는지 확인해야 합니다. 웹페이지가 열린다는 이유로 테스트를 끝내지 마세요. TUN을 켠 뒤 앱이 개선됐다면 트래픽 처리 범위가 원인인지 확인하세요. 원격 프로토콜이 자동으로 바뀐 것으로 오해하지 마세요.

연속 다운로드나 높은 처리량이 필요한 작업에는 Hysteria2와 TUIC를 후보로 추가할 수 있지만 UDP 연결 가능 여부와 실제 동시 작업 경험을 먼저 확인해야 합니다. 대용량 파일을 내려받을 때 다른 앱까지 눈에 띄게 느려진다면 대역폭 예상값과 동시 연결 수, 혼잡 관련 설정부터 조정하세요. TCP 계열 연결도 안정적인 네트워크에서 충분한 처리량을 낼 수 있습니다. 현재 서비스와 네트워크에서 직접 측정한 결과를 기준으로 선택하세요. 한 가지 프로토콜만 제공하는 연결과 서버가 다른 연결의 결과를 비교해 프로토콜 성능 차이라고 단정할 수는 없습니다.

저전력 기기와 서버 환경

라우터, 소형 컴퓨터, 서버에서는 프로세서 아키텍처와 메모리, 암호화 성능, 연결 규모를 더 주의 깊게 살펴야 합니다. GUI 클라이언트는 일상적인 조작에 적합하고, 별도의 mihomo 코어는 서비스를 직접 관리해야 하는 사용자에게 더 적합합니다. 다운로드 센터의 코어 영역은 이런 환경을 위한 것입니다. 일반 데스크톱 사용자는 GUI 클라이언트를 우선 사용하세요. 설치 전에 아키텍처와 실행 환경을 확인하고 운영체제 이름만 보고 파일을 선택하지 마세요. 같은 Linux라도 프로세서나 패키지 관리 방식이 다를 수 있습니다.

리소스가 제한된 기기에서는 간결한 규칙과 필요한 로그 수준만 사용하고 일반적인 부하에서 안정성을 확인한 뒤 규칙 세트와 추가 기능을 늘리세요. 연결 목록을 자주 새로 고치거나 상세 로그를 계속 켜 두거나 연결을 많이 동시에 사용하면 프로토콜 리소스 비교 결과에 영향을 줄 수 있습니다. 처리량이 어느 수준에 도달한 뒤 프로세서가 계속 최대 사용률을 보인다면 기기 병목과 네트워크 병목을 구분하세요. 이때 프로토콜만 바꿔서는 해결되지 않을 수 있습니다. 적절한 암호화 구현을 선택하거나 추가 처리를 줄이는 방법이 더 효과적일 수 있습니다.

문제가 생기면 되돌릴 수 있는 절차로 선택하기

실제 테스트는 네 단계로 진행할 수 있습니다. 먼저 구독과 코어의 호환성을 확인하고, 연결 하나의 기본 동작을 테스트한 뒤 일상 앱과 네트워크 전환을 확인합니다. 마지막으로 평소처럼 사용한 뒤 리소스 사용량과 배터리를 살펴보세요. 각 단계에서는 한 번에 하나만 바꾸고 기존에 작동하던 설정을 보존하세요. 문제가 발생하면 이전 단계로 돌아가 새로 추가한 변수가 관련 있는지 확인합니다. 이 순서는 클라이언트, 코어, DNS, 프로토콜을 한꺼번에 바꾸는 것보다 원인을 명확히 파악하고 재현하기 쉽습니다.

도메인 이름 조회에만 문제가 있다면 DNS 점검 및 설정 안내를 확인하세요. 가져오기와 모드 설정, 연결 테스트를 처음부터 다시 확인하려면 사용 가이드로 돌아가세요. 최종 선택은 세 가지를 설명할 수 있어야 합니다. 현재 네트워크에서 이 경로를 사용할 수 있는 이유, 코어가 설정을 올바르게 해석하는 이유, 일상적인 작업에서 더 안정적인 이유입니다. 이 세 가지에 답하는 것이 일반적인 프로토콜 순위를 얻는 것보다 유용합니다.