Clash 프로토콜과 코어
호환성 및 사용 환경별 선택

1. 프로토콜, 전송 방식, 프록시 진입점

노드 이름만으로 연결 구성을 판단할 수 없습니다

클라이언트에 표시되는 노드 하나는 실제로 여러 연결 파라미터의 조합입니다. 서버 주소와 포트는 연결 대상을 정하고, 프로토콜은 인증과 데이터 캡슐화 방식을 규정하며, 전송 방식은 데이터가 어떤 경로로 전달되는지 결정합니다. TLS는 통신 경로를 암호화하고 서버 신원을 확인하는 데 쓰일 수 있습니다. 노드 표시 이름은 구분을 위한 라벨일 뿐입니다. 이름에 특정 프로토콜이 적혀 있어도 실제 설정 유형이 같다는 뜻은 아닙니다. 호환성을 판단할 때는 이름이나 지역, 아이콘으로 추측하지 말고 노드 상세 정보의 실제 유형을 확인하세요.

이러한 계층은 자주 혼동됩니다. 예를 들어 VLESS는 프록시 프로토콜이고 WebSocket은 전송 방식이며 TLS는 보안 채널 메커니즘입니다. 세 요소는 하나의 연결에 함께 쓰일 수 있습니다. QUIC은 UDP를 기반으로 하며 보안 핸드셰이크와 다중 스트림을 통합합니다. 따라서 “VLESS와 QUIC 비교”라고만 하면 서로 다른 계층을 비교하는 셈입니다. 특정 VLESS 전송 조합과 특정 Hysteria2 노드를 비교하고 클라이언트와 코어를 함께 밝히는 편이 정확합니다.

앱에서 대상 서비스까지 이어지는 네 구간

프록시 연결은 앱에서 로컬 진입점까지, 로컬 코어에서 프록시 서버까지, 서버에서 대상 서비스까지, 대상 서비스에서 데이터가 돌아오는 구간으로 나눠 볼 수 있습니다. 시스템 프록시는 해당 설정을 따르는 앱에만 적용되는 경우가 많습니다. TUN은 가상 네트워크 어댑터와 라우팅을 통해 지정된 트래픽을 전달합니다. 이 기능들은 트래픽이 코어에 들어오는 방식을 정할 뿐, SS 노드를 Trojan으로 바꾸거나 서버에 없는 UDP 포워딩 기능을 자동으로 추가하지 않습니다. 트래픽을 가로채는 범위와 노드 프로토콜은 따로 확인해야 합니다.

규칙 모드는 진입점 이후에 연결의 출구 정책을 선택합니다. DIRECT 규칙에 일치한 연결은 직접 전송되고, 프록시 정책 그룹에 일치한 연결만 해당 노드를 사용합니다. 따라서 “노드를 바꿨는데 웹페이지가 달라지지 않았다”면 프로토콜 차이가 작아서가 아니라 해당 페이지가 계속 직결되거나 기존 세션을 재사용한 것일 수 있습니다. 비교하기 전에 연결 패널에서 적용된 규칙, 정책 체인, 대상 주소를 확인하면 규칙 설정 오류를 프로토콜 성능 문제로 오해하지 않을 수 있습니다.

프로토콜을 비교하기 전에 고정할 조건

프로토콜을 공정하게 비교하려면 프록시 서버의 네트워크 위치, 대상 서비스, 테스트 기기, 대략적인 시간대를 최소한 동일하게 맞춰야 합니다. 같은 지역의 노드라도 경로가 다르고 대역폭을 공유하는 방식이 다르며 부하도 크게 차이 날 수 있습니다. 이때 한 노드가 더 빠르다는 사실은 현재 조건에서 그 노드가 더 적합하다는 뜻일 뿐, 해당 프로토콜이 전반적으로 더 빠르다는 의미는 아닙니다. 같은 서버를 비교하기 어렵다면 실제 사용감에 따라 노드를 고르되, 결론은 프로토콜 순위가 아닌 해당 조합의 성능으로 한정하세요.

설정을 파싱할 수 있는 상태, 연결을 수립한 상태, 대상 서비스에 필요한 트래픽을 처리할 수 있는 상태는 서로 다릅니다. 설정 가져오기에 성공했다는 것은 구문과 일부 필드가 받아들여졌다는 뜻입니다. 핸드셰이크에 성공했다는 것은 클라이언트와 서버가 인증을 마치거나 채널을 수립했다는 뜻입니다. 음성 통화, 게임, 동영상이 정상적으로 작동하는지는 UDP, DNS, 라우팅, 대상 서비스에도 달려 있습니다. 단계별로 확인하고, 연결 상태가 녹색이라는 이유만으로 전체 데이터 경로가 검증됐다고 판단하지 마세요.

이 페이지의 구성은 실제 선택 순서를 따릅니다. 먼저 서버에서 제공하는 항목을 확인하고, 코어 지원 여부를 점검한 뒤 네트워크 조건과 리소스 사용량을 평가하고, 마지막으로 실제 서비스를 검증하세요. 프로토콜 자체가 더 나은 네트워크 경로를 만들어 주지는 않으며, 클라이언트가 서버에 아직 배포되지 않은 기능을 일방적으로 활성화할 수도 없습니다. 이 경계를 염두에 두면 대역폭 파라미터, 혼잡 제어, 연결 유지 옵션을 볼 때 설정 변경을 모든 연결 문제의 해결책으로 착각하지 않게 됩니다.

2. Shadowsocks와 VMess의 설계상 특징

Shadowsocks: 간결한 프록시 캡슐화

Shadowsocks는 보통 SS라고 부르며, 비교적 일찍부터 가벼운 암호화 프록시 방식으로 널리 사용됐습니다. 프록시 요청과 데이터를 암호화해 캡슐화한 뒤 서버에서 복원하여 대상으로 전달하는 것이 기본 구조입니다. 클라이언트 설정은 보통 서버, 포트, 비밀번호, 암호화 방식 중심이라 개념이 비교적 단순합니다. 다만 SS가 영구적으로 고정된 단일 형식인 것은 아닙니다. 세대별 암호화 방식과 확장 기능에 따라 키 요구 사항, 구현 지원, 설정 세부 사항이 다르므로 유형이 같다는 이유만으로 필드를 서로 바꿔 쓸 수는 없습니다.

널리 쓰이는 AEAD 방식은 암호화와 무결성 보호를 결합하므로, 과거 스트림 암호 방식의 사용 경험을 새 설정에 그대로 적용해서는 안 됩니다. SS 2022에는 별도의 키와 프로토콜 요구 사항이 있으며 일부 구현은 다중 사용자 관련 구조도 지원합니다. 지정된 방식이 있다면 이름과 키 형식을 그대로 유지하세요. 일반 비밀번호, 인코딩된 키, 여러 부분으로 구성된 키는 서로 다른 입력입니다. 클라이언트가 문자열을 저장할 수 있다고 해서 서버가 이를 의도한 대로 해석한다는 뜻은 아닙니다.

SS의 리소스 사용량은 암호화 알고리즘, 하드웨어 가속, 구현 품질에 따라 달라집니다. 관련 명령어를 지원하는 프로세서는 일부 AES 방식에 더 적합할 수 있고, 다른 기기에서는 ChaCha20 계열 방식이 더 나은 성능을 낼 수 있습니다. 이는 기기와 구현의 조합에 따른 결과이므로 스마트폰 브랜드나 프로세서 아키텍처만으로 단정하지 마세요. 일반적인 웹 이용, 소용량 파일, 메신저에서는 알고리즘 차이보다 네트워크 지연이 더 크게 체감되는 경우가 많습니다. 암호화 방식을 계속 바꾸기보다 연결 안정성을 먼저 확인하는 편이 효과적입니다.

VMess: 다양한 인증 및 전송 조합

VMess는 V2Ray 생태계에서 나온 프록시 프로토콜로, 사용자 식별과 인증, 데이터 전송을 중심으로 설계됐으며 다양한 전송 방식과 조합할 수 있습니다. 흔히 UUID, 암호화 관련 옵션, 전송 유형, TLS 설정이 포함됩니다. VMess라는 이름만으로 적용 범위를 판단할 수는 없습니다. 직접 TCP로 연결하는 경우와 WebSocket에 TLS를 결합하는 경우는 연결 과정, 추가 헤더, 리버스 프록시 구성, 중간 장비 요구 사항이 모두 다릅니다.

과거 VMess 설정의 alterId는 구형 인증 방식과 관련된 항목입니다. 현재 많이 쓰이는 설정은 AEAD 기반 인증을 사용하며 값이 0으로 표시되는 경우가 많습니다. 오래된 가이드에 필드가 “빠짐없이” 보이게 하려고 0이 아닌 값으로 바꾸지 마세요. 구형 클라이언트에서 내보낸 설정을 현재 서버 설정 템플릿으로 그대로 사용해서도 안 됩니다. 인증 오류가 발생하면 관련 없는 파라미터를 여러 개 동시에 바꾸기보다 서버에서 안내한 UUID, 인증 방식, 시스템 시간을 먼저 확인하고 전송 계층을 점검하세요.

시간 동기화는 VMess 문제 해결에서 놓치기 쉬운 부분입니다. 사용자 정보와 포트가 정확해도 기기 시간이 크게 어긋나면 인증에 실패할 수 있습니다. 절전 모드에서 복귀한 기기, 시간대를 수동 설정한 기기, 오프라인 기기는 특히 확인이 필요합니다. 데스크톱에 표시된 시간대 이름이 아니라 실제 시스템 시각을 점검하세요. TLS 인증서 오류도 시계와 관련이 있을 수 있지만 이는 별도의 검증 계층입니다. 로그의 인증 실패와 인증서 유효 기간 오류를 같은 원인으로 묶어 해석하지 마세요.

어떤 경우에 선택하며 UDP는 어떻게 봐야 할까요?

설정 제공자가 구조가 명확하고 안정적으로 관리되는 SS 또는 VMess 노드를 제공하며 주 사용처가 웹과 일반 앱이라면, 프로토콜이 오래됐다는 이유만으로 바꿀 필요는 없습니다. 먼저 클라이언트가 지정된 암호화 방식이나 전송 방식을 지원하는지, 실제 연결이 안정적으로 유지되는지 확인하세요. 리버스 프록시를 통해 연결해야 한다면 VMess의 구체적인 전송 파라미터가 더 중요할 수 있습니다. 설정 항목이 적고 서버에 적합한 구현이 마련돼 있다면 SS의 간결한 구조가 유지 관리에 유리할 수 있습니다.

클라이언트의 UDP 스위치 하나만으로 모든 UDP 서비스가 작동한다고 보장할 수는 없습니다. 코어, 서버, 노드 설정, 현재 전송 조합이 모두 지원해야 하며 원격 방화벽에서도 해당 통신을 허용해야 합니다. 게임은 연결되지 않지만 웹은 정상이라면 UDP가 필요한 서비스를 별도로 테스트하고 연결 기록과 서버 기능을 확인하세요. UDP를 끈 뒤에도 웹이 정상이라고 해서 이전 UDP 경로가 작동했다는 뜻은 아니며, 해당 프로토콜이 게임에 본질적으로 부적합하다는 의미도 아닙니다.

이 두 유형의 설정을 이전할 때는 원본 구독을 보관하고, 새 클라이언트에서 유형, 암호화 방식, 사용자 정보, 전송, TLS를 항목별로 확인한 뒤 간단한 웹페이지와 지속 연결을 테스트하는 것이 가장 확실합니다. 프로토콜 이름은 같아도 연결 동작이 다르다면 전송 옵션이나 플러그인 설정이 누락됐을 가능성이 있습니다. SS 플러그인은 모든 코어에서 지원되는 것이 아닙니다. 플러그인 필드가 있으면 대상 코어 문서를 먼저 확인하고, 필드를 삭제하면 서버가 자동으로 호환해 줄 것이라고 기대하지 마세요.

3. Trojan, VLESS와 TLS의 경계

Trojan: TLS 채널을 기반으로 한 프록시 연결

Trojan은 일반적으로 TLS로 보안 채널을 만든 뒤 그 안에서 프록시 인증과 데이터 전송을 처리합니다. 클라이언트에서는 서버 주소, 포트, 비밀번호뿐 아니라 서버 이름과 인증서 검증도 중요합니다. ‘주소’는 서버를 찾는 데 쓰이고 ‘서버 이름’은 TLS 핸드셰이크와 신원 확인에 사용됩니다. 서로 관련은 있어도 문자열이 항상 같지는 않습니다. IP 주소로 서버에 연결하면서 검증에는 도메인 이름을 지정하는 설정이 이 구분을 유지해야 하는 대표적인 사례입니다.

TLS 인증서는 인증서가 있는지만 확인하는 것이 아닙니다. 인증서 신뢰 체인, 유효 기간, 이름 일치 여부도 검사합니다. 서버 주소에 연결할 수 있는데 검증에 실패한다면 시스템 시간, SNI, 인증서 도메인, 서버 인증서 체인을 확인하세요. 검증 건너뛰기를 켜면 연결은 될 수 있지만 중요한 신원 보호 기능이 사라집니다. 인증서 자체를 고치는 설정도 아닙니다. 장기적으로 사용할 설정이라면 검사를 건너뛰는 범용 호환 옵션에 의존하지 말고 올바른 이름과 인증서를 사용하세요.

Trojan 성능은 TLS 세션 재사용, 하위 TCP 연결, 배포 방식에도 영향을 받습니다. 첫 연결의 왕복 시간은 기존 세션이나 연결을 유지한 상태에서 요청할 때와 같지 않습니다. 클라이언트를 재시작한 뒤 웹페이지를 처음 여는 체감 속도를 이미 연결이 유지된 다른 노드와 바로 비교할 수는 없습니다. 서버에서 리버스 프록시나 별도의 전송 확장을 사용하면 계층이 추가될 수 있습니다. 이러한 확장에는 코어 지원이 필요하므로 ‘Trojan 지원’만 보고 모든 조합이 가능하다고 판단하지 마세요.

VLESS: 사용자 식별과 보안 채널을 구분해서 보기

VLESS는 V2Ray 및 Xray 관련 생태계에서 나온 프로토콜입니다. 설계의 핵심 중 하나는 프록시 프로토콜 자체를 간결하게 하고 사용자 식별, 하위 전송, 보안 메커니즘을 분리하는 것입니다. 특히 VLESS 자체에는 페이로드 암호화 보호 기능이 없습니다. 실제 배포에서는 일반적으로 TLS나 지원되는 다른 보안 메커니즘으로 채널을 보호합니다. 따라서 “VLESS는 암호화 부담이 적다”는 말은 보안 설정을 생략해도 된다는 뜻이 아닙니다. 서버와 클라이언트가 합의한 보안 모드를 전체 연결 구성의 일부로 함께 평가해야 합니다.

VLESS 노드라도 TCP, WebSocket, gRPC 등 전송 조합에 따라 파라미터가 다릅니다. WebSocket에는 경로와 요청 헤더가 자주 쓰이고, gRPC에는 서비스 이름이 사용되며, TLS에는 서버 이름과 인증서 검증이 포함됩니다. 공유 링크, 구독, YAML에서는 같은 필드가 서로 다른 형태로 표현될 수 있습니다. 수동으로 이전할 때는 의미에 맞춰 대응하고, 한 전송 방식의 경로 필드를 다른 방식에 임의로 넣지 마세요. 필드가 지원되지 않는다면 먼저 코어 문서와 설정 구조를 확인하세요.

REALITY, Vision 같은 이름도 VLESS와 함께 자주 등장하지만 VLESS 자체와 같은 것은 아닙니다. REALITY에는 특정 보안 핸드셰이크 설정이 필요하고 Vision은 특정 flow 조합입니다. 클라이언트가 VLESS를 지원해도 이러한 기능까지 자동으로 지원하는 것은 아닙니다. 공개 키, 짧은 ID, 서버 이름, flow 정보는 서버 설정을 기준으로 해야 합니다. 다른 노드에서 필드를 몇 개 복사해 채우지 말고, 가져오기 도구가 필드를 무시했다고 해서 기존 연결 동작이 유지된다고 가정하지 마세요.

성능 차이는 먼저 실제 조합에서 원인을 찾으세요

Trojan과 VLESS의 클라이언트 CPU 사용량은 프로토콜 헤더 크기만으로 계산할 수 없습니다. TLS 구현, 세션 재사용 방식, 전송 캡슐화, 데이터량, 하드웨어 명령어가 모두 결과를 바꿀 수 있습니다. 짧은 연결이 많은 서비스는 핸드셰이크와 파싱 대기 시간이 더 크게 느껴질 수 있고, 장시간 전송은 네트워크 용량, 혼잡 제어, 서버 포워딩 성능의 영향을 더 많이 받습니다. 선택할 때는 인증 방식을 속도 등급처럼 보지 말고, 전체 조합이 유지 관리되고 있는지 확인한 뒤 같은 네트워크에서 반복 가능한 성능을 비교하세요.

웹은 정상인데 일부 앱만 작동하지 않는다면 진입점과 트래픽 유형부터 확인하세요. 앱이 시스템 프록시를 사용하지 않거나 UDP를 이용할 수 있고, DNS를 별도로 처리할 수도 있습니다. 이때 TLS 계열의 다른 프로토콜로 바꾸면 설정 차이 하나를 우연히 피할 수는 있지만, 프로토콜 설계가 원인이라는 증거는 아닙니다. 먼저 자주 묻는 질문을 참고해 시스템 프록시, TUN, DNS를 구분하고 연결 패널에서 실패한 구간을 확인하세요.

4. Hysteria2, TUIC와 QUIC 전송

UDP 기반 전송이라고 해서 앱도 반드시 UDP를 써야 하는 것은 아닙니다

Hysteria2와 TUIC은 모두 QUIC 기반 설계를 사용하며 하위 계층에서 UDP에 의존합니다. 여기서 UDP는 클라이언트와 프록시 서버 사이의 전송 채널을 가리키며, UDP 앱만 프록시할 수 있다는 뜻은 아닙니다. TCP 트래픽도 전달할 수 있습니다. 이 차이를 이해하는 것이 중요합니다. 브라우저의 TCP 요청을 QUIC에 캡슐화해 전달할 수 있지만, UDP 게임이 원활한지는 프로토콜 구현, 데이터 포워딩 방식, 경로 품질, 서버 지원에 달려 있으므로 하위 계층 이름만으로 판단할 수 없습니다.

QUIC은 보안 핸드셰이크, 스트림 관리, 혼잡 제어를 사용자 공간 전송에 통합합니다. 독립된 여러 스트림은 한 스트림에서 데이터가 손실됐다고 해서 모두 같은 순서의 바이트를 기다릴 필요가 없습니다. 이는 여러 트래픽을 단일 TCP 연결에 함께 넣는 방식과 다른 중요한 특징입니다. 다만 같은 스트림 안의 신뢰성 있는 데이터는 여전히 복구가 필요하고, 모든 스트림은 연결 수준의 리소스와 혼잡 예산을 공유합니다. ‘스트림 간 선두 차단 감소’가 패킷 손실에 따른 비용이 없다는 뜻도, 혼잡 상황에서 모든 요청이 기존 속도를 유지한다는 뜻도 아닙니다.

Hysteria2: 네트워크 경로에 맞는 대역폭 파라미터

Hysteria2는 복잡한 네트워크 경로를 고려해 대역폭 관련 파라미터와 혼잡 제어 메커니즘을 제공합니다. 일반적인 설정의 업로드·다운로드 값은 클라이언트와 서버가 전송량을 협상하고 제어할 때 쓰는 입력값이지, 입력만 하면 실제 대역폭을 얻는 값이 아닙니다. 회선 성능보다 훨씬 높은 값으로 설정하면 큐가 쌓이고 패킷 손실이 늘어 같은 네트워크의 다른 앱에도 영향을 줄 수 있습니다. 어떤 제어 방식이 활성화되는지, 파라미터가 실제 적용되는지는 서버 정책과 코어 구현을 함께 확인해야 합니다.

대역폭 값을 정할 때는 인터넷 요금제에 표시된 속도가 아니라 현재 기기에서 서버까지 이어지는 경로의 지속 가능한 성능을 기준으로 삼으세요. 휴대전화가 셀룰러 네트워크로 바뀌면 집에서 적합했던 설정이 더는 맞지 않을 수 있습니다. 제공자가 기본 협상값을 유지하거나 특정 파라미터를 사용하라고 안내했다면 우선 해당 지침을 따르세요. 반복 테스트에서 개선이 확인되고 끊김이나 다른 트래픽과의 경쟁이 눈에 띄게 늘지 않을 때만 변경 사항을 유지하세요. 테스트 중에는 업로드나 다운로드 중 한 방향씩 조정해야 업로드 혼잡이 다운로드 확인 응답과 상호작용에 미치는 영향을 판단하기 쉽습니다.

TUIC: 인증, 버전, 세션 동작

TUIC도 QUIC의 스트림 및 데이터그램 기능을 활용해 프록시 전송을 구성하며, 신뢰성 있는 스트림, UDP 포워딩, 연결 관리를 함께 다룹니다. 설정에는 UUID, 비밀번호, 혼잡 제어, UDP 포워딩 방식 등이 들어갈 수 있습니다. 프로토콜 세대에 따라 호환성 경계가 있으므로 클라이언트와 서버가 서로 통신할 수 있는 구현을 사용해야 합니다. ‘TUIC’이라고만 적힌 공유 설명으로는 전체 파라미터를 알 수 없습니다. 가져오기에 실패하거나 핸드셰이크가 비정상적이면 서버에서 요구하는 프로토콜 세대와 코어 지원 범위를 확인하세요.

일부 QUIC 계열 설정에서는 연결 유지, 빠른 복구, 핸드셰이크 동작을 조정할 수 있습니다. 이러한 옵션은 기존 세션 상태, 서버의 허용 정책, 네트워크 전환과 관련이 있습니다. 매번 최초 연결의 대기 시간을 없앨 수 있는 기능으로 이해해서는 안 됩니다. 초기 데이터 전송에는 재전송 공격 등의 보안 경계도 있으므로 프로토콜 구현과 실제 서비스가 함께 처리해야 합니다. 일반 사용자는 핸드셰이크 횟수를 최소화하는 파라미터를 복사하기보다 클라이언트와 제공자가 함께 지원하는 기본 조합을 먼저 사용한 뒤 세부 조정을 검토하는 편이 안정적입니다.

패킷 손실이 많은 환경과 모바일 네트워크의 한계

QUIC 계열 프로토콜은 왕복 시간이 길고 패킷 손실이 있는 일부 경로에서 유리할 수 있지만, UDP 경로 품질이 TCP보다 크게 나쁘지 않아야 합니다. 일부 네트워크는 UDP에 다른 큐잉, 속도 제한, 유휴 연결 시간 제한을 적용해 반대 결과가 날 수 있습니다. 연결 전환 기능도 프로토콜 구현, 클라이언트 네트워크 스택, 트래픽 가로채기 방식에 따라 달라집니다. Wi-Fi에서 셀룰러로 바뀌어도 연결이 끊기지 않을 것이라고 QUIC의 연결 식별자 지원만으로 보장할 수는 없습니다. 기존 연결은 실제 앱에서 별도로 검증해야 합니다.

작은 웹페이지는 열리는데 대용량 파일 전송이 멈춘다면 MTU와 경로의 단편화 처리도 살펴보세요. 추가 캡슐화는 사용할 수 있는 페이로드 공간을 줄이며, 일부 경로는 큰 UDP 데이터그램을 제대로 처리하지 못합니다. MTU를 지나치게 낮춰 장기간 사용하는 대신 노드를 고정하고 다른 변수를 끈 상태에서 특정 네트워크에서만 문제가 생기는지 확인하세요. 같은 기기가 다른 네트워크에서 정상이라면 경로 문제로 범위를 좁힐 수 있습니다. 모든 네트워크에서 실패한다면 인증, TLS 이름, 서버 포트 설정을 확인하세요.

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

서로 다른 ‘속도’ 네 가지를 구분하세요

연결 속도에는 프록시 채널 수립 시간, 대상에서 첫 바이트를 받을 때까지의 시간, 지속 전송 속도, 장시간 사용 시 안정성이 포함됩니다. 웹페이지가 느리게 열리는 원인은 DNS, 핸드셰이크, 대상 서비스 응답에 있을 수 있습니다. 파일 다운로드가 느리다면 네트워크 용량, 혼잡, 출구 부하의 영향이 더 클 수 있습니다. 이런 결과를 지연 시간 숫자 하나로 합치면 실제 차이가 가려집니다. 노드 테스트에 표시되는 밀리초 값은 보통 특정 요청의 한 번의 결과이며, 대역폭이나 게임 지연, 모든 사이트의 사용 경험을 종합한 점수가 아닙니다.

자동 속도 측정 결과는 테스트 주소, 연결 재사용, 타임아웃 기준에도 영향을 받습니다. 같은 노드를 먼저 테스트할 때와 나중에 테스트할 때 연결 상태가 다를 수 있고, 대상 사이트도 요청을 서로 다른 경로로 처리할 수 있습니다. 수치가 의미하는 바를 알고 싶다면 Clash 노드 지연 시간 테스트 원리를 참고하세요. 직접 노드를 고를 때는 같은 테스트 대상으로 기본 연결 여부를 확인한 다음 자주 쓰는 서비스에서도 검증하세요. 숫자만 줄이려다 실제 사용감이 더 나쁜 노드를 고르는 일을 줄일 수 있습니다.

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

두 프로토콜 조합을 비교할 때는 구독 업데이트와 자동 정책 전환을 잠시 중지하고 정책 그룹 출구를 고정하세요. 대용량 파일 동기화, 시스템 업데이트 등 경쟁 트래픽을 끄고 접속 네트워크와 기기 전원 상태를 기록합니다. 첫 방문과 재방문을 따로 테스트하고 결과도 구분해 적으세요. 노드를 바꾼 뒤에는 이전 연결을 종료하거나 앱을 다시 열어 기존 세션이 이전 출구를 계속 사용하지 않도록 합니다. 각 조합을 여러 번 테스트하고 순서를 번갈아 진행하면 한 노드만 연속해서 측정할 때보다 시간대 차이에 따른 편향을 줄일 수 있습니다.

대역폭 테스트에서 전송 속도를 계속 최대치로 유지할 필요는 없습니다. 같은 대상과 비슷한 테스트 시간, 동일한 동시 연결 조건으로 속도의 안정성과 상호작용 저하 여부를 확인하면 충분합니다. 테스트 중 라우터와 휴대전화 모두 지연 시간이 크게 늘어난다면 프로토콜의 대역폭 부족이 아니라 접속 구간의 큐 혼잡일 수 있습니다. 원격 대상 하나만 느리고 다른 서비스는 정상이라면 대상이나 출구 경로를 먼저 확인하세요. 결론에는 현재 기기, 네트워크, 전체 노드 조합을 함께 기록하고 한 번의 결과를 장기적인 순위로 일반화하지 마세요.

CPU, 메모리, 배터리 사용량은 별도로 봐야 합니다

CPU 부하는 암복호화, 프로토콜 캡슐화, 사용자 공간 네트워크 처리, 규칙 매칭, 로그 기록 등 여러 작업에서 발생합니다. 사용자 공간에서 구현되는 QUIC 처리 경로는 운영체제의 TCP 스택과 다릅니다. 그렇다고 항상 전력을 더 많이 쓰는 것은 아니지만, 처리량이 높거나 작은 패킷이 많거나 구현 최적화가 부족하면 차이가 커질 수 있습니다. 메모리 사용량은 연결 수, 캐시, 규칙 세트, 클라이언트 UI의 영향을 더 많이 받습니다. 특정 클라이언트의 사용량이 크다고 해서 현재 노드의 프로토콜을 바로 원인으로 지목할 수는 없습니다.

모바일에서는 무선 통신을 활성 상태로 유지하는 데 드는 비용도 고려해야 합니다. 잦은 연결 유지 신호, 자동 테스트, 구독 확인은 기기가 저전력 상태로 진입하는 것을 방해할 수 있습니다. 한 번에 쓰는 데이터가 적더라도 누적 영향이 생길 수 있습니다. 셀룰러 신호가 약하면 같은 데이터를 전송해도 재전송 횟수가 늘고 통신이 활성 상태인 시간도 길어질 수 있습니다. 대기 전력 소모를 비교할 때는 비슷한 신호 세기, 같은 백그라운드 앱, 비슷한 사용 시간으로 맞추세요. 신호가 강한 Wi-Fi와 약한 셀룰러를 직접 비교하면 안 됩니다.

배터리 소모를 줄이려면 불필요하게 자주 속도를 측정하지 않고, 연결 재수립을 일으키는 반복적인 전환을 피하며, 장시간 디버그 로그를 끄는 것부터 시작하세요. 여러 네트워크 트래픽 가로채기 도구를 동시에 실행하는지도 확인해야 합니다. TUN이 부하를 늘리는지는 가로채는 트래픽 규모와 플랫폼 구현에 따라 다릅니다. TUN의 기본 목적은 절전이 아니라 트래픽 처리 범위를 정하는 것입니다. 클라이언트 백그라운드 권한이나 시스템 프록시 설정은 TUN 및 프록시 진입점 가이드에서 동작 범위를 확인하세요.

최종 선택이 항상 최고 속도를 내는 조합일 필요는 없습니다. 모바일 업무에서는 절전 후 복구, 약한 네트워크에서의 재연결, 배터리가 더 중요할 수 있습니다. 데스크톱 다운로드에서는 지속 처리량이 중요하고 라우터는 단일 코어 성능과 메모리에 제한을 받을 수 있습니다. ‘화면을 잠근 뒤에도 메시지를 받을 수 있음’, ‘다운로드 중 음성 통화가 눈에 띄게 끊기지 않음’처럼 요구 사항을 검증 가능한 조건으로 정하세요. 프로토콜에 가벼움, 초고속, 저전력 같은 고정된 꼬리표를 붙이는 것보다 실제 결과를 비교하는 편이 정확합니다.

6. 기본 Clash, Meta, mihomo의 관계

클라이언트는 관리하고 코어는 연결합니다

GUI 클라이언트는 구독 관리, 정책 선택, 로그, 시스템 연동 기능을 제공합니다. 코어는 설정 파싱, 규칙 매칭, DNS 처리, 실제 프록시 연결을 담당합니다. 둘은 같은 계층이 아닙니다. UI가 다른 클라이언트 두 개가 같은 코어를 사용할 수도 있고, 한 클라이언트에서 코어를 바꾸거나 별도로 업데이트할 수도 있습니다. 프로토콜 사용 가능 여부를 판단할 때는 실제 실행 중인 코어와 기능 설명을 먼저 확인한 다음 클라이언트가 관련 필드를 빠짐없이 저장할 수 있는지 살펴보세요. UI에 버튼이 없다고 해서 코어에도 해당 기능이 없다는 뜻은 아닙니다.

기본 Clash는 널리 쓰이는 YAML 설정과 규칙 체계를 마련했습니다. 생태계의 역사에는 오픈소스 코어와 Premium 브랜치 등의 차이도 있으므로 과거에 Clash 기능으로 소개된 항목을 모두 같은 기준으로 볼 수는 없습니다. 기존 설정의 리스닝 포트, 정책 그룹, 규칙 순서는 지금도 사용 방식에 영향을 줍니다. 하지만 최신 프로토콜, 보안 조합, 네트워크 스택 기능까지 기본 코어가 지원한다고 추측해서는 안 됩니다. 구형 클라이언트가 새 설정 파일을 열 수 있어도 새로운 의미대로 실행된다는 보장은 없습니다.

Meta와 mihomo는 이어지는 계열이지만 서로 바꿔 쓸 수 있는 명칭은 아닙니다

Clash.Meta는 Clash 생태계를 바탕으로 프로토콜과 네트워크 기능을 확장했으며, 이후 mihomo라는 이름으로 개발을 이어갔습니다. 구독과 가이드에서 Meta, Clash Meta, mihomo를 볼 때 같은 발전 흐름을 가리키는 경우가 많지만, 이름만으로 정확한 기능 범위를 알 수는 없습니다. 설치 패키지에 어떤 빌드가 포함됐는지, 특정 구현이 활성화됐는지는 클라이언트의 실제 정보를 확인해야 합니다. 설정 파일 제목의 Meta를 mihomo로 바꾸는 것만으로 이전이 끝났다고 판단하지 마세요.

mihomo가 확장한 프로토콜 유형, DNS 설정, 규칙 프로바이더, TUN 동작은 기본 Clash에서 파싱할 수 있는 범위를 벗어날 수 있습니다. 반대로 기본 Clash 설정 중 상당수는 계속 시작점으로 활용할 수 있지만, 오래된 필드와 플랫폼별 옵션, 동작 변화는 확인해야 합니다. 설정 호환성을 단순히 ‘지원’ 또는 ‘미지원’ 두 가지로 나눌 수는 없습니다. 특정 필드가 거부되거나 무시될 수 있고, 기본값이 바뀌어 결과가 달라질 수도 있습니다. 이전한 뒤에는 프로세스가 시작되는지만 보지 말고 로그도 확인하세요.

오판하기 쉬운 부분은 클라이언트가 설정을 생성하는 단계입니다. 클라이언트에 따라 구독, 전역 설정, 오버라이드를 병합하므로 코어에 전달되는 최종 파일은 사용자가 본 구독 원문과 다를 수 있습니다. 노드에 필드가 있는데 실제 동작이 나타나지 않는다면 편집기에서 필드를 보존하지 않았거나 오버라이드가 덮어썼을 수 있습니다. 문제 해결 시에는 실행 설정과 시작 로그부터 확인하세요. 여기에는 구독 주소와 인증 정보가 포함될 수 있으므로 다른 사람과 공유하기 전에 민감한 내용을 삭제해야 합니다.

플랫폼에 맞는 클라이언트를 고른 뒤 기능을 확인하세요

일반 사용자는 다운로드 센터의 첫 추천 항목인 Clash Plus부터 살펴보고 플랫폼에 따라 Clash Verge Rev, FlClash 등을 선택할 수 있습니다. Windows에는 Clash Nyanpasu도 있고 Android에는 Clash Meta for Android와 Surfboard도 있습니다. 클라이언트마다 코어가 다를 수 있으며 같은 구독을 받아들이는 것도 아닙니다. 특히 Surfboard 설정 체계는 mihomo YAML로 바로 사용할 수 없습니다. 클라이언트를 고를 때 제공자가 지원하는 형식도 함께 확인하세요.

Clash for Windows와 ClashX Meta는 다운로드 페이지에서 유지 관리가 중단된 보관용 프로젝트로 소개됩니다. 기존 환경 때문에 출처를 확인해야 하는 사용자를 위한 자료이며, 새 프로토콜 호환성을 위한 기본 선택지는 아닙니다. 이전 전에 클라이언트 비교 리뷰에서 플랫폼, 구독 관리, 트래픽 처리 방식을 확인하고 더 세부적인 선택 기준이 필요하면 GUI 클라이언트 기능 비교를 살펴보세요. 이름이 비슷하다고 패키지 내부 구현도 같다고 추측하지 마세요.

코어 업그레이드 후 문제가 생기면 최소 설정으로 새 코어가 시작되는지 확인한 다음 규칙 프로바이더, DNS, TUN을 단계별로 복원하세요. 이전 디렉터리 전체를 한꺼번에 가져오지 마세요. 캐시, 오래된 스크립트, 로컬 설정까지 테스트에 포함될 수 있습니다. 데스크톱과 휴대전화는 각각 검증해야 합니다. 같은 YAML의 논리는 비슷해도 권한, 가상 네트워크 어댑터, 시스템 DNS, 백그라운드 정책이 다릅니다. 코어의 프로토콜 지원은 연결 경로의 일부 호환성만 해결하므로 플랫폼 연동은 별도로 확인해야 합니다.

7. 구독 형식, YAML, 필드 호환성

구독 주소만으로 응답 형식을 알 수 없습니다

구독은 전체 설정, 노드만 포함된 YAML, 공유 링크 목록, 인코딩된 텍스트를 반환할 수 있습니다. 주소 끝에 파일 확장자가 있는지로 형식을 확실하게 판단할 수는 없습니다. 일부 서비스는 요청 파라미터나 클라이언트 식별 정보에 따라 다른 내용을 반환하기도 합니다. 따라서 브라우저에서 텍스트가 보인다고 해서 모든 클라이언트에서 가져올 수 있는 것은 아닙니다. 제공자 페이지에서 대상 클라이언트나 코어용으로 명시된 형식을 선택하고, 다른 생태계용 구독을 Clash 설정 파서에 바로 넣지 마세요.

전체 설정에는 노드뿐 아니라 정책 그룹, 규칙, DNS, 리스닝 설정이 들어가는 경우가 많습니다. 반면 노드 구독은 프록시 항목만 제공하며 로컬 템플릿이나 proxy-providers 기능으로 연결해야 합니다. 두 형식은 업데이트 방식도 크게 다릅니다. 전체 설정을 가져온 뒤 다른 설정으로 바꾸면 규칙도 함께 달라질 수 있습니다. 노드 프로바이더만 업데이트하면 일반적으로 로컬 정책과 규칙은 주 설정에 남습니다. 구독이 어느 유형인지 알아야 업데이트 후 노드뿐 아니라 모드나 분기 동작까지 바뀐 이유를 설명할 수 있습니다.

공유 링크 변환 과정에서 의미가 달라질 수 있습니다

공유 링크는 노드 하나를 전달하는 데 적합하지만 전체 정책, 규칙, DNS를 표현하지 못할 수 있습니다. 변환기가 새 필드를 인식하지 못해 삭제하거나 프로토콜 파라미터를 완전히 같지 않은 설정 항목에 대응할 수도 있습니다. 특히 전송 경로, 서버 이름, flow, 보안 핸드셰이크, UDP 방식은 주소와 비밀번호만 확인해서 이전이 끝났다고 볼 수 없습니다. 변환 후에는 원본 파라미터와 대조하고 로그 및 연결 동작을 확인하세요. ‘변환 성공’은 호환성을 보장하지 않습니다.

구독 URL과 노드 인증 정보는 실제 서비스 이용 권한을 줄 수 있습니다. 전체 구독을 공개 변환 사이트에 붙여 넣거나 문제 화면에 노출하지 마세요. 실행 설정을 토론 게시판에 그대로 공개해서도 안 됩니다. 변환이 꼭 필요하다면 클라이언트의 지원되는 가져오기 기능을 우선 사용하거나 신뢰할 수 있는 환경에서 처리하세요. 문서나 문제 해결에는 필요한 필드만 보여 주고, 서버 이름은 구조를 유지하되 예시 도메인으로 바꾸세요. 인증 정보, 구독 파라미터, 로컬 제어 인터페이스 정보는 공유 내용에서 삭제해야 합니다.

구조를 이해한 다음 오버라이드 적용 순서를 확인하세요

아래는 분기 동작을 이해하기 위한 최소 YAML 예시입니다. 원격 노드는 없으며 로컬 리스닝과 직결 규칙만 포함합니다. 프록시 구독이 아니므로 실행해도 원격 출구가 생기지 않습니다. 포트, 모드, 정책 그룹, 규칙의 연결 방식을 설명하기 위한 예시입니다. 규칙에 적은 정책 이름은 기존 아웃바운드 또는 정책 그룹을 가리켜야 하며, 들여쓰기에는 공백을 사용하고 목록 계층을 일치시켜야 합니다. 실제 구독 가져오기와 연결 절차는 구독 가져오기 가이드를 기준으로 진행하세요.

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

proxy-groups:
  - name: 출구 선택
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,출구 선택

사용자 오버라이드는 구독 업데이트와 별도로 적용되는 로컬 사용자 설정이지만, 모든 클라이언트에서 동일한 병합 알고리즘을 쓰는 것은 아닙니다. 어떤 클라이언트는 필드 전체를 교체하고, 어떤 클라이언트는 목록에 항목을 추가하며, 스크립트로 최종 설정을 생성하기도 합니다. rules를 통째로 바꾸면 구독의 기존 규칙이 모두 사라질 수 있고, MATCH 뒤에 목록을 추가하면 새 규칙이 적용되지 않을 수 있습니다. 편집 전에 병합 방식과 삽입 위치를 확인하고, 업데이트 후에는 편집기에 저장된 내용뿐 아니라 실행 설정도 확인하세요.

정책 그룹 이름도 참조 관계의 일부입니다. 노드 업데이트 후 이름이 삭제되면 정적 참조가 깨질 수 있고, 필터 조건이 지나치게 엄격하면 프로바이더의 노드가 모두 제외될 수 있습니다. 이 경우 YAML 문법 오류가 없어도 그룹에 사용할 수 있는 멤버가 없을 수 있습니다. 노드 프로바이더 가져오기 성공 여부, 형식, 필터 조건 일치 여부, 정책 그룹의 현재 선택을 차례대로 확인하세요. 실제 원인이 빈 목록이나 참조 오류인데 들여쓰기만 반복해서 바꾸지 마세요.

업데이트 후 갑자기 작동하지 않으면 오류 로그를 보관하고 이전에 작동하던 설정으로 되돌린 뒤 노드 유형, 전송 필드, 오버라이드 결과를 비교하세요. 로컬 리스닝만 실패한다면 구독을 다시 변환하지 말고 포트 충돌을 확인하세요. 구체적인 명령어는 Clash 리스닝 포트 충돌 문제 해결을 참고하세요. 다운로드 실패, 파싱 실패, 참조 실패, 실행 실패를 구분하면 오류 메시지를 실제로 수정해야 할 위치와 연결할 수 있습니다.

8. 사용 환경에 맞는 프로토콜 선택과 문제 해결

데스크톱에서 일상적으로 사용한다면 안정적인 기준 구성을 유지하세요

데스크톱에서 웹, 문서 동기화, 일상적인 개발을 한다면 제공자가 안정적으로 관리하고 현재 클라이언트가 완전히 지원하는 노드 조합부터 사용하세요. SS, VMess, Trojan, VLESS 모두 요구 사항을 충족할 수 있습니다. 중요한 것은 안정적인 핸드셰이크, 올바른 인증서나 인증 정보, 자주 쓰는 서비스의 일관된 응답입니다. 이미 검증된 기준 노드를 하나 유지한 뒤 다른 프로토콜을 시도하세요. 바꾼 뒤 특정 사이트만 나아졌다면 결론을 해당 경로로 한정하세요. 나중에 문제를 비교할 기준이 사라지지 않도록 다른 유형의 노드를 모두 삭제하지 마세요.

지속적인 다운로드와 높은 동시성이 필요한 개발 작업에서는 연결 관리도 중요합니다. 여러 의존성 다운로드, 컨테이너 이미지, 백그라운드 동기화가 동시에 네트워크를 사용할 수 있으므로 파일 하나의 최고 속도가 전체 성능을 나타내지는 않습니다. 같은 작업 조건에서 처리량, 재시도 횟수, 기기 온도를 확인하세요. 대역폭을 최대한 사용할 때 상호작용이 눈에 띄게 느려진다면 프로토콜보다 접속 구간의 큐와 동시 연결 수를 먼저 확인하세요. 로컬 네트워크 공유에는 로컬 리스닝과 방화벽 설정도 필요합니다. 관련 내용은 LAN 허용 및 프록시 공유 설정을 참고하세요.

모바일 기기: 네트워크 전환과 배터리를 우선하세요

출퇴근 중에는 휴대전화가 Wi-Fi, 셀룰러, 신호 세기가 서로 다른 네트워크 사이를 자주 전환합니다. 한 네트워크에서 최고 속도를 내는지보다 전환 후 연결이 복구되는지, 화면을 잠근 뒤에도 작동하는지, 메시지 연결이 자주 끊겼다 다시 맺어지는지 확인하는 편이 중요합니다. Hysteria2나 TUIC을 통제된 조건에서 비교할 수 있지만 UDP 경로와 서버 설정을 먼저 확인해야 합니다. 특정 접속 네트워크에서 불안정하다면 안정적인 TCP 계열 조합으로 되돌릴 수 있어야 합니다. 모든 네트워크에서 하나의 파라미터만 고집하지 마세요.

음성 통화와 게임에서는 지터, 연속적인 패킷 손실, 세션 복구가 더 중요합니다. 먼저 앱 트래픽이 실제로 클라이언트에 들어오는지 확인하고, 선택한 노드가 필요한 UDP 포워딩을 지원하는지 점검하세요. 웹페이지 지연 시간 한 번을 측정해 요청이 완료됐다는 것만으로 실시간 서비스 경로를 검증할 수는 없습니다. 같은 앱과 서버를 비슷한 시간대에 사용해 비교하고 백그라운드 다운로드가 경험에 영향을 주는지도 확인하세요. 직결 상태에서도 같은 문제가 나타난다면 프록시 프로토콜이 주된 원인이 아닐 수 있으므로 로컬 무선 네트워크와 대상 서비스를 먼저 확인하세요.

소형 기기: 리소스 예산에 따라 선택지가 달라집니다

서버나 라우터에서 코어를 실행할 때는 사용 가능한 메모리, 단일 코어 성능, 저장 공간, 아키텍처 지원을 고려해야 합니다. 규칙이 많거나 로그가 자주 기록되거나 연결이 집중되면 리소스 사용량이 누적되므로 유휴 상태의 사용량만 봐서는 안 됩니다. 간결한 규칙과 단일 출구로 먼저 연결한 다음 프로바이더, DNS, 트래픽 가로채기 기능을 단계적으로 추가하세요. GUI 관리가 필요한 일반 기기는 다운로드 페이지에서 클라이언트를 선택하면 됩니다. mihomo를 직접 실행하는 방식은 서비스, 권한, 네트워크 라우팅을 관리할 수 있는 사용자에게 적합하며 모두에게 필요한 단계는 아닙니다.

실패가 발생한 위치를 기준으로 범위를 좁히세요

첫 번째는 설정이 아직 시작되지 않은 상태입니다. 로그에서 가장 먼저 나타난 파싱, 필드, 포트 오류를 확인하고 그 문제부터 해결하세요. 뒤에 이어지는 오류는 앞선 문제의 연쇄 결과일 수 있습니다. 두 번째는 프록시 서버에 연결할 수 없는 상태입니다. 주소 해석, 포트, 접속 네트워크를 확인하고 이미 사용 가능한 다른 노드와 비교하세요. 세 번째는 인증 또는 보안 핸드셰이크 실패입니다. 프로토콜에 맞춰 비밀번호, UUID, 시스템 시간, TLS 이름, 서버 요구 사항을 확인하세요. 모든 실패를 네트워크 타임아웃으로 뭉뚱그리지 마세요.

네 번째는 채널을 수립했지만 일부 서비스만 실패하는 경우입니다. 규칙 적용 여부, 대상 주소 해석, UDP, 전송 크기를 확인한 뒤 서버 출구에서 대상까지의 연결을 살펴보세요. 다섯 번째는 절전 모드에서 복귀하거나 네트워크가 바뀐 뒤 실패하는 경우입니다. 기존 세션을 종료하고 새 연결을 수립한 다음 특정 프로토콜에서만 문제가 재현되는지 확인하세요. 클라이언트를 다시 열면 복구되더라도 기존 라우팅, DNS 캐시, 세션 상태를 더 구분해야 합니다. 한 번 재시작해 성공했다는 사실은 원인을 찾는 단서일 뿐 장기적인 해결책은 아닙니다.

문제를 기록할 때는 운영체제, 클라이언트 이름, 실제 코어, 프로토콜 및 전송 조합, 접속 네트워크, 재현 절차를 남기세요. 관련 시간대의 로그만 첨부하고 구독과 인증 정보는 삭제해야 합니다. ‘가져온 뒤 작동하지 않음’ 대신 ‘설정 시작 성공, TLS 핸드셰이크 실패, 다른 노드는 정상’처럼 쓰면 문제를 구체적으로 파악할 수 있습니다. 용어가 여전히 헷갈린다면 개념 빠른 참조를 확인하세요. 기본 연결을 단계별로 복구하려면 빠른 설정 가이드로 돌아가 검증 가능한 최소 연결부터 다시 시작하세요.