Clash 프로토콜 및 코어 가이드

1. 프로토콜 선택: 연결의 각 계층부터 구분하기

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

클라이언트에서 노드를 선택하면 실제로는 서버 위치, 인증 방식, 프록시 프로토콜, 하위 전송 방식을 함께 선택하게 됩니다. Shadowsocks, VMess, Trojan, VLESS는 주로 프록시 연결의 구성 방식을 설명하고, TCP, UDP, TLS, WebSocket 등은 서로 다른 계층의 전송 방식을 나타냅니다. Hysteria2와 TUIC는 QUIC를 기반으로 전송을 설계했습니다. 이 이름들을 한데 놓고 바로 비교하면 프로토콜 차이를 회선 차이로 오해하기 쉽습니다.

클라이언트는 설정과 제어를 담당하고, 코어는 설정을 해석해 연결을 만들고 규칙을 실행합니다. 화면에 특정 노드가 표시된다고 해서 현재 코어가 그 노드의 모든 옵션을 처리할 수 있다는 뜻은 아닙니다. 코어가 프로토콜을 지원하더라도 구독 변환기가 관련 항목을 보존한다는 보장도 없습니다. 노드 이름의 약어만 볼 것이 아니라 서버 요구사항, 구독 내용, 코어 기능, 클라이언트 설정을 차례로 확인해야 합니다.

앱 트래픽과 프록시 터널의 전송 방식도 구분해야 합니다. 게임이 UDP 데이터를 보낸다고 해서 UDP라고 표시된 노드라면 무엇이든 제대로 처리되는 것은 아닙니다. 브라우저에서 HTTPS 사이트에 접속한다고 해서 프록시의 바깥쪽 연결도 반드시 TLS를 사용하는 것은 아닙니다. 연결은 여러 계층으로 캡슐화될 수 있으며, 각 계층의 암호화, 혼잡 제어, 시간 초과는 따로 적용됩니다. 문제를 점검할 때는 앱 요청과 클라이언트에서 프록시 서버까지의 연결 중 어느 쪽에 문제가 있는지 먼저 확인하세요.

호환성을 먼저 확인하고 성능을 비교하세요

실제 선택 순서는 서버가 허용하는 프로토콜 확인, 현재 운영체제의 클라이언트와 코어 지원 여부 점검, 같은 서비스 제공업체의 비슷한 지역과 시간대별 성능 비교입니다. 서버에서 Trojan만 제공한다면 노드 유형을 VLESS로 바꿔도 연결되지 않습니다. 프로토콜은 클라이언트에서 임의로 바꾸는 표시 옵션이 아닙니다. 인증 항목과 전송 매개변수가 서버 설정과 일치해야 합니다.

‘UDP 지원’, ‘다중화 지원’, ‘TUN 지원’은 서로 다른 기능입니다. UDP 전달은 프로토콜과 서버 기능에 속하고, 다중화는 연결 구성 방식이며, TUN은 기기에서 트래픽을 받아들이는 방법입니다. TUN을 켜면 시스템 프록시를 따르지 않는 일부 앱의 트래픽을 받을 수 있지만, 서버에 UDP 전달 기능을 추가하거나 잘못된 비밀번호와 인증서 도메인을 해결해 주지는 않습니다.

보안과 유지 관리도 선택 기준입니다

계속 유지 관리되는 클라이언트와 코어를 우선 사용하고, 인증서 검증을 유지하며, 신뢰할 수 있는 출처에서 설정을 가져오세요. 프록시 구간이 암호화되어도 앱에서 민감한 정보를 평문으로 보내도 되는 것은 아닙니다. 프록시 서버를 지난 뒤의 데이터 보호는 앱 프로토콜에 달려 있습니다. 계정, 결제 또는 관리자 페이지에 접속할 때는 유효한 HTTPS 연결을 계속 사용해야 하며, 프록시 구간의 암호화로 웹사이트 자체의 보안을 대신할 수 없습니다.

구독 주소에는 접근 자격 정보가 포함되는 경우가 많고, 설정 파일에도 비밀번호, UUID, 관리 인터페이스 키가 들어갈 수 있습니다. 화면을 공유할 때 주소와 인증 항목을 가리고, 문제를 문의할 때는 프로토콜 유형, 오류 분류, 필요한 비민감 매개변수만 제공하세요. 도움을 요청하더라도 전체 구독 파일을 공개 게시판에 올리지 마세요. 노드 이름에도 서비스 제공업체나 개인이 정한 정보가 드러날 수 있습니다.

2. Shadowsocks와 VMess: 암호화 프록시의 두 가지 구성 방식

Shadowsocks: 간결한 구조, 매개변수 일치가 중요

Shadowsocks는 흔히 SS라고 부르며, 비교적 가벼운 암호화 프록시 설계에서 출발했습니다. 서버 주소, 포트, 암호화 방식, 비밀번호를 사용해 프록시 연결을 구성하며, 설정이 간단해 소수의 노드를 직접 관리할 때 적합합니다. 여기서 가볍다는 말은 프로토콜 구성 방식이 간결하다는 뜻입니다. 모든 기기와 암호화 방식의 CPU 부담이 같거나 서버가 모든 선택 기능을 지원한다는 의미는 아닙니다.

SS를 선택할 때 가장 중요한 것은 암호화 방식과 비밀번호가 일치하는지 확인하는 것입니다. 최신 배포에서는 서버와 클라이언트가 모두 지원하는 인증 암호화 방식을 사용하고, 오래된 소프트웨어와의 호환을 위해 낡은 방식으로 임의로 낮추지 마세요. 일부 최신 SS 방식은 키 형식, 길이, 다중 사용자 구성에 별도 조건이 있어 아무 문자열이나 비밀번호로 입력할 수 없습니다. 가져온 뒤 키 길이 오류가 나면 포트를 계속 바꾸기보다 먼저 원본 형식을 확인하세요.

SS의 TCP와 UDP 전달은 각각 확인해야 합니다. 웹페이지가 열린다고 해서 해당 TCP 요청이 처리되었다는 것만 확인된 것입니다. 음성 통화, 게임, 일부 DNS 요청은 여전히 실패할 수 있습니다. 서버에서 UDP를 사용하도록 설정하지 않았거나 네트워크 경로가 UDP를 제한하거나 앱 트래픽이 기기의 프록시 진입점으로 들어오지 않는다면, 클라이언트에서 UDP 옵션만 켜도 조건이 충족되지 않습니다. 먼저 로그에서 요청이 코어에 들어왔는지 확인하고 서버와 전송 설정을 점검하세요.

일부 SS 배포는 플러그인에 의존하기도 합니다. 플러그인은 외부 연결 방식을 바꾸고 유형, 경로, TLS 매개변수를 추가하므로 ‘SS 지원’이 해당 플러그인 조합까지 지원한다는 뜻은 아닙니다. 구독을 변환할 때 주소와 비밀번호만 남으면 노드를 가져온 것처럼 보여도 사용할 수 없을 수 있습니다. 특히 모바일에서는 코어에 해당 플러그인 기능이 내장되어 있는지 확인해야 하며, 데스크톱의 외부 플러그인 사용법을 그대로 적용하면 안 됩니다.

VMess: 인증과 외부 전송을 따로 확인

VMess는 V2Ray 생태계에서 나온 프로토콜로, 사용자 인증과 프록시 데이터 전송을 중심으로 연결을 구성합니다. 노드에는 보통 UUID 같은 인증 정보가 사용되며, TCP, WebSocket 또는 지원되는 다른 전송 방식과 조합할 수 있습니다. 프로토콜 표시만 보는 것보다 전체 매개변수가 실제 동작에 더 큰 영향을 줍니다. 같은 UUID를 사용해도 경로, Host 헤더, TLS 설정이 다르면 연결 결과가 달라질 수 있습니다.

오래된 자료에는 과거 인증 방식과 더 이상 쓰지 않는 항목이 섞여 있을 수 있으므로 현재 권장 설정으로 간주하면 안 됩니다. 구독에 오래된 매개변수가 있다면 검색 결과에서 본 값을 하나씩 시험하기보다 제공업체의 요구사항과 코어 문서를 먼저 확인하세요. 기기 시간도 점검해야 합니다. 인증 관련 방식은 시간 설정이 정상이어야 할 수 있으므로 시스템 시계가 크게 어긋났다면 노드가 중단된 것으로 판단하기 전에 자동 시간 동기화를 복구하세요.

WebSocket을 사용할 때는 연결 포트, 요청 경로, Host 헤더, TLS 서버 이름을 각각 확인하세요. Host는 HTTP 계층 정보이고 서버 이름은 TLS 연결 및 인증서 검증에 사용됩니다. 두 항목은 서로 관련될 수 있지만 항상 같은 값이라고 볼 수는 없습니다. 리버스 프록시 배포에서는 경로가 서버 전달 규칙과 일치해야 합니다. 경로가 틀리면 로그에 인증 실패보다 HTTP 응답 오류가 먼저 나타날 수 있습니다.

두 프로토콜을 의미 있게 비교하는 방법

SS는 매개변수가 비교적 간단해 외부 조합을 줄이고 싶은 배포에 적합합니다. VMess는 조합 선택지가 더 많아 기존 전송 인프라에 연결하기 편리하지만 점검 항목도 늘어납니다. 그렇다고 SS는 언제나 배터리를 덜 쓰고 VMess는 항상 느리다고 결론 내릴 수는 없습니다. 암호화 구현, CPU 명령어 지원, 네트워크 왕복 시간, 연결 재사용 여부에 따라 결과가 달라지며, 저사양 라우터와 최신 스마트폰의 결과도 다를 수 있습니다.

비교할 때는 가능한 한 출구 지역, 서버 자원, 대상 파일을 동일하게 맞추세요. 서로 다른 서버의 노드를 비교하면 결과는 주로 두 노드의 종합 품질을 보여 줍니다. 일반 사용자에게는 첫 페이지가 매끄럽게 열리는지, 전송 중 안정적인지, 유휴 상태 후 제때 다시 연결되는지, 네트워크를 바꾼 뒤 복구되는지가 더 유용한 지표입니다. 한 번 측정한 연결 시간은 참고 자료로만 활용하세요.

3. Trojan과 VLESS: TLS, 인증, 전송 조합

Trojan: TLS 조건을 빠짐없이 점검

Trojan은 프록시 인증과 데이터를 TLS 연결 안에서 처리하며, 일반적인 배포에서는 비밀번호 인증을 사용합니다. 성숙한 TLS 전송으로 연결을 보호하고 그 안에 프록시 요청을 전달하는 구조입니다. 클라이언트에서는 노드 주소, 포트, 비밀번호, 서버 이름을 우선 확인하세요. 인증서 체인의 신뢰 여부와 시스템 시간도 연결에 영향을 주므로 비밀번호 입력란만 확인해서는 안 됩니다.

인증서 검증은 암호화 여부가 아니라 서버의 신원을 확인합니다. 연결 주소는 IP일 수도 도메인일 수도 있지만 인증서는 검증에 사용하는 이름과 일치해야 합니다. 일부 배포는 별도의 서버 이름을 지정해야 하므로 제공업체의 매개변수에 맞춰 입력하고 노드 표시 이름을 대신 사용하지 마세요. 인증서 만료, 도메인 불일치, 불완전한 인증서 체인은 설정 출처나 서버 관리자가 수정해야 합니다.

인증서 검증을 건너뛰면 신원 확인이 약해지므로 일반적인 해결 방법으로 사용하면 안 됩니다. 특정 기기에서만 인증서 오류가 발생한다면 해당 기기의 시간, 시스템 신뢰 저장소, 네트워크 중간 장비, 클라이언트 로그를 먼저 확인하세요. 모든 기기에서 동시에 실패한다면 서버 인증서와 배포 변경을 우선 살펴봐야 합니다. 검증 옵션을 바꾸면 오류가 사라질 수 있지만, 실제로 예상한 서버에 연결되었다는 증거는 되지 않습니다.

Trojan의 UDP 기능을 기본 UDP 전송과 동일하게 보면 안 됩니다. 일반적인 구현에서는 UDP 데이터를 신뢰성 있는 연결에 캡슐화하며, 구체적인 경로는 코어와 설정에 따라 달라집니다. 앱에 필요한 전달 방식을 제공할 수 있지만 패킷 손실 시 외부의 신뢰성 있는 전송이 끝날 때까지 기다려야 할 수 있습니다. 음성 통화나 게임은 노드의 UDP 지원 표시만 믿지 말고 실제 앱으로 테스트하세요.

VLESS: 인증이 간결해도 별도의 암호화가 필요합니다

VLESS는 인증과 외부 전송 보호를 분리하는 데 중점을 두며, 프로토콜 자체는 데이터 암호화를 제공하지 않습니다. 실제 배포에서는 보통 TLS, REALITY 등 지원되는 보안 전송 방식과 조합하므로 VLESS 노드에 UUID만 입력하면 된다고 이해해서는 안 됩니다. 서버에서 사용하는 보안 계층과 전송 방식, 특정 흐름 제어 요구사항을 클라이언트가 지원해야 합니다. 하나라도 빠지면 연결에 실패할 수 있습니다.

REALITY, Vision, VLESS는 서로 바꿔 쓸 수 있는 세 가지 프로토콜 이름이 아닙니다. VLESS는 프록시 프로토콜이고, REALITY는 보안 전송 방식이며, Vision은 특정 흐름 제어 방식입니다. 구독에 포함된 공개 키, 짧은 식별자, 서버 이름, 흐름 제어 항목은 각각 역할이 있으므로 화면에 보이지 않는다고 삭제해도 되는 것은 아닙니다. 클라이언트가 기본 VLESS 연결을 지원해도 모든 확장 기능까지 지원한다는 뜻은 아닙니다.

VLESS를 WebSocket 등의 전송 방식과 함께 사용한다면 경로, Host 헤더, TLS 조건을 확인해야 합니다. 특정 흐름 제어 방식과 함께 사용할 때는 서버와 클라이언트에서 선택한 전송 조합이 요구사항을 충족하는지도 확인하세요. 한 배포의 흐름 제어 항목을 다른 배포에 복사하면 안 됩니다. 설정을 옮길 때는 기존 조합을 유지하고 연결을 확인한 뒤 조정하세요. 프로토콜, 전송 방식, DNS를 한 번에 바꾸면 원인을 찾기 어렵습니다.

같은 보안 계층을 사용해도 성능 차이는 직접 확인해야 합니다

Trojan과 VLESS는 모두 TLS를 사용할 수 있으므로 핸드셰이크와 인증서 처리에 공통 비용이 발생할 수 있습니다. 하지만 인증, 캡슐화, 확장 기능이 다르므로 모든 성능 차이를 TLS 탓으로 돌릴 수는 없습니다. 첫 응답 시간에는 DNS 조회, TCP 연결, 보안 핸드셰이크, 대상 사이트의 응답이 모두 포함됩니다. 가벼운 테스트 주소 하나만 확인해서는 웹페이지의 여러 리소스가 로드되는 상황을 충분히 파악할 수 없습니다.

제공업체에서 두 유형의 노드를 모두 제공한다면 우선 필수 항목이 갖춰져 있고 현재 코어가 명확히 지원하는 설정을 선택한 뒤 일상적으로 사용하는 앱에서 확인하세요. 기존 서비스 인프라에 여러 전송 방식을 연결해야 한다면 프로토콜 이름을 비교하기보다 조합을 점검하는 편이 중요합니다. 기존 구독을 안정적으로 사용하고 싶다면 표시 이름을 바꾸려고 노드를 직접 다시 만들 필요가 없습니다. 서버 유지 관리 품질, 인증서 갱신, 설정 업데이트 주기도 장기적인 사용 가능성에 직접 영향을 줍니다.

4. Hysteria2와 TUIC: QUIC 연결의 장점과 한계

QUIC는 어느 계층을 바꾸나요?

QUIC는 UDP를 기반으로 하며 보안 핸드셰이크, 신뢰성 있는 스트림, 연결 관리 기능을 통합합니다. Hysteria2와 TUIC는 이러한 기능을 바탕으로 프록시 트래픽을 구성해 일부 연결 부담을 줄이고, 동시 처리와 복잡한 네트워크 경로에 대응하는 것을 목표로 합니다. 하지만 UDP는 전송의 기반일 뿐 경로가 더 좋다는 보장은 없습니다. 현재 네트워크에서 UDP 속도를 제한하거나 패킷을 버리거나 시간 초과를 엄격하게 적용한다면 QUIC 계열 노드가 TCP 계열보다 안정적으로 연결되기 어려울 수 있습니다.

QUIC의 여러 신뢰성 있는 스트림은 전송 계층의 순차 전달 때문에 서로 다른 스트림이 기다리는 상황을 줄일 수 있습니다. 하지만 한 스트림에서 손실된 데이터는 여전히 처리해야 하고, 모든 스트림이 혼잡 윈도와 하위 회선을 공유할 수도 있습니다. 무선 신호 변동을 없애거나 서버 대역폭을 늘려 주지는 않습니다. 웹 리소스가 동시에 많이 로드될 때 도움이 될 수 있지만, 단일 파일 다운로드는 여전히 사용 가능한 용량, 패킷 손실, 혼잡 제어의 영향을 크게 받습니다.

연결 식별자는 네트워크 경로가 바뀔 때 대응할 수 있는 기반을 제공하지만, 모바일 네트워크 전환 후 원활하게 복구되는지는 프로토콜 구현, 서버 상태, NAT, 클라이언트 동작에 달려 있습니다. QUIC가 항상 연결을 유지한다고 볼 수는 없습니다. 휴대폰이 Wi-Fi에서 셀룰러 네트워크로 바뀐 뒤 기존 앱이 복구되는지, 코어가 다시 핸드셰이크하는지, 시스템에서 백그라운드 실행을 허용하는지를 따로 확인하세요.

Hysteria2: 대역폭 값이 속도 배수는 아닙니다

Hysteria2는 좋지 않은 네트워크 경로에서 조정 가능한 전송 정책을 제공하는 데 중점을 둡니다. 일반적인 설정에는 인증, TLS, 선택적 대역폭 선언 등이 포함되며 구체적인 혼잡 제어 동작은 양쪽 설정에 따라 달라집니다. 업로드와 다운로드 대역폭 값은 회선 조건을 나타내는 것이지, 높게 입력할수록 좋은 값이 아닙니다. 실제 업로드 용량보다 훨씬 높은 값을 입력하면 큐가 쌓이고 재전송이 늘어나 다른 앱의 응답이 느려져 전체 사용 경험이 나빠질 수 있습니다.

대역폭 매개변수를 확인할 때는 방향과 단위부터 점검한 뒤 실제 사용 가능한 용량을 고려하세요. 가정용 인터넷의 표기 속도와 프록시 경로에서 지속적으로 사용할 수 있는 대역폭은 다르며, 셀룰러 네트워크는 신호와 부하에 따라 더 크게 변합니다. 적절한 값을 추정하기 어렵다면 신뢰할 수 있는 설정 출처의 값과 코어 기본 동작을 우선 따르세요. 온라인에서 본 과도한 수치를 그대로 복사하지 말고, 값을 조정한 뒤에는 전송량, 응답성, 패킷 손실을 함께 확인하세요.

Hysteria2 설정은 이전 버전 Hysteria에서 이름만 바꾸면 그대로 호환되는 것이 아닙니다. 구독 변환기가 유형, 인증 항목, 혼잡 설정을 잘못 처리하면 노드는 가져와지지만 연결되지 않을 수 있습니다. 혼잡 설정이나 포트 점프 같은 선택 기능을 사용할 때는 코어와 서버 양쪽의 지원도 필요합니다. 문제를 해결할 때는 먼저 제공업체가 준 전체 설정으로 기본 연결을 확인한 뒤 이러한 확장 조건을 하나씩 점검하세요.

TUIC: 동시 처리와 UDP 전달은 양쪽 지원이 필요합니다

TUIC도 QUIC로 연결을 구성하며 인증, 스트림 전달, UDP 전달 관련 기능을 제공합니다. 구현이나 설정 버전에 따라 인증 항목과 매개변수 요구사항이 다를 수 있으므로 TUIC라는 표시만으로 호환 여부를 판단하지 마세요. 가져오기 전에 현재 코어가 제공업체의 설정 형식을 명시적으로 지원하는지 확인하세요. 알 수 없는 항목이 있다면 바로 삭제하지 말고 코어 로그와 구독의 대상 형식을 먼저 확인하세요.

TUIC의 혼잡 제어, UDP 전달 방식, 연결 유지 옵션은 동작에 영향을 줍니다. 신뢰성 있는 전달은 데이터 도착을 중시하고, 비신뢰 데이터그램은 손실을 허용하는 대신 시의성을 중시하는 앱에 더 적합합니다. 최종 결과는 양쪽 구현에 따라 달라지므로 옵션 이름만 보고 모든 게임에 도움이 된다고 판단할 수는 없습니다. 실시간 앱은 실제 통화나 게임을 통해 지연 변동, 끊김, 복구 시간을 확인하세요.

두 QUIC 노드 모두 MTU, 경로의 UDP 조건, 라우터 상태를 확인해야 합니다. 작은 요청은 정상인데 대용량 전송이 멈춘다면 경로 분할이나 패킷 크기 문제를 의심할 수 있지만, 모든 시간 초과를 MTU 탓으로 돌려서는 안 됩니다. 먼저 다른 네트워크에서 비교하고 QUIC 노드에서만 실패하는지 확인한 뒤 클라이언트 문서에 따라 조정하세요. 비교 기준을 잃지 않도록 사용할 수 있는 TCP 계열 노드도 남겨 두세요.

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

첫 연결과 지속 전송을 나누어 측정하세요

연결 속도에는 첫 응답, 지속 전송량, 상호작용 지연 변동, 연결 끊김 후 복구 등 여러 요소가 포함됩니다. 첫 응답은 DNS, 연결 설정, 보안 핸드셰이크, 대상 서비스의 처리 시간에 영향을 받습니다. 지속 전송량은 회선 용량, 패킷 손실, 혼잡 제어, 서버 부하에 좌우됩니다. 페이지가 빨리 열리는 노드가 장시간 다운로드에도 적합한 것은 아니며, 다운로드 속도가 빠른 노드라도 화상 회의에서는 지연 변동이 클 수 있습니다.

클라이언트 연결 테스트는 보통 지정된 대상에 접속하므로 해당 탐지 경로의 결과만 보여 줍니다. 테스트 대상이나 연결 재사용 여부가 다르면 수치를 직접 비교하기 어렵습니다. 자동 선택 정책은 탐지 결과의 변동으로 노드를 자주 바꾸어 장시간 연결이 필요한 앱에 영향을 줄 수도 있습니다. 자동 선택을 켜기 전에 테스트 방식을 확인하세요. 안정적인 세션에는 적합한 노드를 고정하는 편이 문제를 파악하기 쉽습니다.

비교 테스트에서는 기기, 네트워크, 대상 리소스, 규칙을 동일하게 유지하고 대역폭을 사용하는 백그라운드 작업을 종료하세요. 한 번에 조건 하나만 바꾸고 먼저 페이지를 새로 여는 테스트를 한 뒤 지속 전송, 유휴 상태 후 복구를 차례로 확인합니다. 여러 번 순서를 바꿔 테스트해 시간대별 혼잡을 프로토콜 차이로 오인하지 않도록 하세요. 노드 출구나 서버가 다르면 결과는 노드별 사용 경험으로 기록하고 특정 프로토콜이 전반적으로 더 빠르다고 단정하지 마세요.

CPU와 메모리는 주로 어디에 사용되나요?

CPU 사용량은 암복호화, 캡슐화, 데이터 복사, 규칙 검사, 프로토콜 스택 처리에서 발생합니다. 최신 기기는 하드웨어 가속 덕분에 일부 암호화 방식의 부담이 낮을 수 있지만, 구형 라우터는 단일 코어 성능이 먼저 한계에 도달할 수 있습니다. QUIC의 사용자 공간 처리, 잦은 소형 패킷, 많은 동시 연결도 부담을 키울 수 있습니다. 전송량이 부족하다면 노드만 계속 바꾸지 말고 프로세서 사용량과 회선 상태를 함께 확인하세요.

메모리 사용량은 연결 수, 버퍼, 규칙 목록, DNS 캐시, 클라이언트 화면의 영향을 받습니다. 클라이언트 프로세스와 코어 프로세스를 나누어 확인하고, 상세 로그를 계속 기록해 부담이 커지지 않도록 로그 수준을 정상으로 되돌리세요. 연결 재사용은 반복적인 핸드셰이크를 줄일 수 있지만 추가 상태를 유지해야 합니다. 동시 연결 수나 버퍼를 늘려도 항상 이점이 있는 것은 아니며, 특히 메모리가 적은 라우터와 백그라운드 실행이 제한된 휴대폰에서는 주의해야 합니다.

TUN은 기기에서 트래픽을 받아 처리하는 단계를 추가합니다. DNS 가로채기, 프로세스 식별, 규칙 검사도 사용량에 영향을 줄 수 있습니다. 따라서 시스템 프록시와 TUN의 테스트 결과를 프로토콜 비교에 바로 활용할 수 없습니다. 두 연결 방식에서 앱에 적용되는 규칙이 다르면 실제 출구도 달라질 수 있습니다. 비교하기 전에 연결 기록을 확인해 같은 앱과 대상이 같은 노드와 정책을 사용했는지 확인하세요.

배터리 소모는 기기의 활성화 상태, 신호, 실제 트래픽에 따라 달라집니다

모바일 기기의 배터리는 암호화 연산만으로 소모되는 것이 아닙니다. 셀룰러 무선 통신 유지, 약한 신호에서의 재전송, 백그라운드 연결 유지, 앱의 잦은 네트워크 요청도 큰 영향을 줍니다. 연결을 오래 유지하면 핸드셰이크가 줄 수 있지만 무선 통신이 활성 상태인 시간은 늘어날 수 있습니다. 시간 초과를 짧게 설정하면 유휴 상태의 사용량은 줄어도 다음 요청 때마다 연결을 다시 만들어야 할 수 있습니다. 모든 휴대폰에 적용되는 고정 배터리 절약 순위는 없습니다.

배터리 사용량을 비교할 때는 화면 밝기, 신호 상태, 사용 앱, 테스트 시간을 고정하고 유휴 상태와 지속 사용을 각각 확인하세요. 시스템 배터리 통계는 사용량을 분류하는 방식에 영향을 받습니다. VPN 인터페이스를 사용하는 트래픽이 클라이언트에 몰아서 표시되더라도 전체 소모가 프록시 연산에서 비롯된 것은 아닙니다. 클라이언트의 배터리 순위만으로 결론 내리지 말고 전체 소모량, 트래픽, 백그라운드 활동을 함께 살펴보세요.

일상적인 최적화는 불필요하게 잦은 연결 검사와 상세 로그를 줄이고, 적절한 구독 업데이트 간격을 유지하며, 앱이 요청 실패 후 계속 재시도하는지 확인하는 것부터 시작하세요. 시스템의 배터리 제한이 지나치게 엄격하면 백그라운드 연결이 종료될 수 있으므로 배터리 수명과 지속적인 연결 사이에서 적절히 조정해야 합니다. Android에서는 백그라운드 실행 권한을, iOS에서는 VPN 상태와 주문형 연결 설정을 확인하세요. 이러한 운영체제 동작은 프로토콜 변경만으로 해결할 수 없습니다.

6. 원본 Clash, Clash Meta, mihomo: 코어와 클라이언트의 관계

이름이 비슷해도 기능을 서로 바꿔 쓸 수는 없습니다

Clash는 처음에 프록시 코어 프로젝트를 가리켰으며, 이후 관련 설정과 클라이언트 생태계 전체를 부르는 말로도 쓰였습니다. 원본 오픈 소스 코어, 과거의 Premium 브랜치, 이후의 Meta 계열은 기능 구성이 서로 다릅니다. 오래된 가이드에서 ‘Clash 지원’이라고만 하면 특정 브랜치에 대한 전제가 빠져 있을 수 있습니다. 규칙 유형, TUN, 프로토콜 확장을 확인할 때는 화면의 제목에 기대지 말고 정확한 코어 이름을 확인하세요.

Clash Meta는 기존 생태계를 바탕으로 프로토콜과 기능을 확장한 코어 계열이며, mihomo는 이 흐름을 이어갑니다. 많은 클라이언트와 구독에서 여전히 Meta라는 이름을 사용하므로 이름이 다르다고 설정 체계가 완전히 다른 것은 아닙니다. 하지만 이름이 이어진다고 해서 어느 시기의 빌드든 모든 새 항목을 지원한다는 뜻도 아닙니다. 실제 기능은 실행 중인 코어와 해당 문서를 기준으로 확인해야 하며, 최신 자료를 근거로 오래된 설치 파일의 기능을 추정하면 안 됩니다.

Premium에는 원본 오픈 소스 버전과 다른 기능이 포함된 적이 있습니다. 해당 버전의 전용 설정이나 스크립트 기능을 mihomo로 그대로 옮길 수 있다고 가정하지 마세요. 목적이 비슷한 항목도 구현과 문법이 다를 수 있어 그대로 남기면 구문 분석 오류나 동작 변화가 발생할 수 있습니다. 오래된 설정을 이전할 때는 먼저 최소 구성으로 실행한 뒤 규칙 세트, DNS, TUN, 자동화 설정을 하나씩 복원하세요. 과거 기능 전체를 한꺼번에 복사하지 않는 것이 좋습니다.

클라이언트는 화면을, 코어는 실행을 담당합니다

클라이언트는 구독 관리, 노드 선택, 시스템 프록시, 로그 표시 기능을 제공하며 설정 덮어쓰기와 코어 업데이트 기능을 포함할 수도 있습니다. 화면의 설정은 실행 설정을 생성하거나 수정하므로 디스크에 있는 원본 구독과 코어가 실제로 불러온 내용이 다를 수 있습니다. 문제를 점검할 때는 클라이언트에서 제공하는 실행 설정이나 병합 결과를 확인하세요. 특히 DNS, 포트, 정책 그룹, TUN 설정이 화면의 옵션으로 덮어써졌는지 살펴봐야 합니다.

처음 사용하는 경우 플랫폼에 따라 Clash Plus를 먼저 확인한 뒤 필요에 따라 Clash Verge Rev, FlClash 등을 비교하세요. Windows에서는 Clash Nyanpasu도 비교할 수 있고, Linux에서는 Clash Verge Rev와 FlClash 중 선택할 수 있습니다. 추천 클라이언트라고 해서 모든 플랫폼의 내부 구현이 완전히 같은 것은 아닙니다. 특정 프로토콜 확장이 필요하다면 해당 플랫폼용 빌드가 그 기능과 매개변수를 지원하는지 확인해야 합니다.

Android에서는 Clash Meta for Android와 Surfboard도 각각의 기능에 따라 판단해야 합니다. Surfboard는 자체 설정 체계를 사용하므로 같은 프록시 클라이언트라고 해서 Clash YAML을 그대로 적용할 수는 없습니다. iOS에서는 다운로드 페이지에서 Clash Plus의 앱 스토어 링크와 공식 사이트 clashplus.io를 확인할 수 있습니다. 운영체제를 옮길 때는 앱 이름만 비교하지 말고 실제 설정과 기능을 비교하세요.

보관된 소프트웨어, 코어 업데이트, 이전 범위

Clash for Windows와 ClashX Meta는 이 사이트의 다운로드 목록에서 유지 관리가 중단된 소프트웨어로 표시되어 있습니다. 명확한 호환성 요구가 있는 사용자가 참고할 수 있지만, 보관된 클라이언트에는 새 프로토콜 항목, 운영체제 호환성, 보안 수정이 반영되지 않을 수 있습니다. 예전 가이드의 화면이 익숙하다는 이유만으로 새로 설치할 때 우선 선택하지 마세요. 자세한 차이는 보관된 클라이언트 안내에서 확인한 뒤 기존 환경을 유지할지 이전할지 결정하세요.

클라이언트와 코어 업데이트는 별도로 진행할 수도 있고 클라이언트에서 함께 관리할 수도 있습니다. 업데이트 전에는 로컬 규칙, 덮어쓰기, 정책 그룹 이름, 시스템 연결 설정을 저장하세요. 업데이트 후에는 구독 구문 분석, 규칙 적용, DNS, 자주 쓰는 앱을 확인해야 합니다. 클라이언트, 구독 형식, 모든 노드를 한 번에 바꾸면 문제가 생겼을 때 어느 계층에서 달라졌는지 파악하기 어렵습니다.

mihomo를 직접 실행하는 방식은 서버, 라우터, 서비스를 직접 관리하려는 사용자에게 적합하며 프로세스 권한, 시작 방식, 로그, 설정 경로도 관리해야 합니다. 데스크톱에서는 GUI를 사용하는 편이 일반적으로 더 편리합니다. 코어를 직접 실행해도 투명 프록시 연결이 자동으로 설정되는 것은 아니며 라우팅, DNS, 방화벽 설계를 대신하지도 않습니다. 배포 전에 어떤 기기의 어떤 트래픽을 코어로 보낼지 명확히 정하세요.

7. 구독 형식, YAML 설정, 마이그레이션 호환성

공유 링크, 노드 목록, 전체 설정은 서로 다릅니다

구독은 설정을 가져오는 방법이지, 하나의 통일된 파일 형식이 아닙니다. 링크에서 인코딩된 공유 링크 목록, 완성된 Clash YAML, 다른 클라이언트용 설정을 받을 수 있습니다. 공유 링크에는 보통 개별 노드 정보가 담기고, 전체 설정에는 정책 그룹, 규칙, DNS, 수신 포트도 포함됩니다. 가져온 뒤 노드 목록이 보이더라도 기존 분기 설정까지 보존되었다는 뜻은 아니므로 정책 그룹과 규칙을 추가로 확인하세요.

구독 대상 형식을 선택할 때는 실제 클라이언트에 맞는 내용을 제공업체가 출력하도록 해야 합니다. 기존 Clash 형식, mihomo 확장용 형식, 다른 앱의 형식을 모두 호환되는 것처럼 취급할 수는 없습니다. 형식 변환은 일반적인 항목을 처리할 수 있지만 새 프로토콜 확장, 특수 전송, 플러그인 매개변수를 누락할 수 있습니다. 변환 후에는 노드 유형과 주요 매개변수를 확인하세요. ‘변환 성공’이 전체 연결 검증을 뜻하지는 않습니다.

구독 응답 내용은 요청 방식, 계정 상태, 제공업체 설정에 따라 바뀔 수 있습니다. 업데이트 후 노드가 갑자기 사라졌다면 YAML 구문 문제로 단정하기 전에 웹페이지, 로그인 안내, 오류 설명이 반환되었는지 확인하세요. 원래 설정을 바로 삭제하지 마세요. 사용할 수 있는 사본을 남겨 두면 변경 내용을 비교하는 데 도움이 됩니다. 문제를 문의할 때는 인증 정보를 제거한 구조와 오류만 공유하고 원본 구독 URL은 공개하지 마세요.

설정 계층에 따라 덮어쓰기와 업데이트 방식이 달라집니다

Clash 형식 설정에서 노드, 프록시 그룹, 정책 그룹, 규칙은 각각 다른 역할을 합니다. 프록시 그룹은 다른 출처에서 노드를 불러올 수 있고, 정책 그룹은 출구를 선택하며, 규칙은 순서에 따라 요청을 정책에 할당합니다. 규칙에서 참조하는 그룹 이름이 실제로 있어야 하며 이름이 바뀌면 시작 오류나 트래픽 분배 변화가 생길 수 있습니다. 구독 업데이트로 새 노드가 추가되어도 직접 지정한 정책 그룹에 자동으로 들어간다는 보장은 없습니다.

클라이언트의 덮어쓰기 기능은 구독이 업데이트될 때마다 설정을 다시 하지 않도록 로컬 설정을 유지하는 데 쓰입니다. 하지만 병합 방식은 전체 교체, 추가, 이름 기준 병합 등으로 다를 수 있으므로 모든 클라이언트가 똑같이 동작한다고 가정하면 안 됩니다. 특히 규칙이 추가되는 위치를 확인하세요. 최종 기본 규칙 뒤에 배치된 항목은 적용되지 않는 경우가 많습니다. 먼저 덮어쓰기 안내를 읽고 실제 실행 설정을 확인해 결과가 예상과 일치하는지 점검하세요.

다음은 해당 설정 위치에 넣을 수 있는 규칙 예시입니다. 예시의 PROXY는 실제로 존재하는 정책 그룹 이름이어야 합니다. 도메인 규칙을 먼저 두고 LAN 및 지역 규칙을 이어서 적용한 다음, 나머지 규칙에 일치하지 않는 연결은 최종 기본 규칙에서 처리합니다. 이 예시는 규칙 순서만 보여 주며 노드나 전체 DNS 설정은 포함하지 않습니다. 지역 규칙을 사용하려면 관련 데이터도 준비해야 하며, 실제 적용 결과는 DNS 조회 및 연결 기록을 함께 확인하세요.

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-KEYWORD,google,PROXY
  - GEOIP,LAN,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

마이그레이션은 문법을 확인한 뒤 동작을 검증하세요

YAML은 들여쓰기와 데이터 유형에 규칙이 있으므로 공백으로 들여써야 합니다. 비밀번호, 특수 문자, 잘못된 유형으로 해석될 수 있는 값은 원본 요구사항에 따라 올바르게 따옴표로 묶으세요. 복사할 때 영문 구두점을 전각 문장부호로 바꾸지 않도록 주의해야 합니다. 구문 분석 오류가 나면 해당 줄 주변의 들여쓰기, 목록 표시, 키와 값의 관계를 먼저 확인하세요. 알 수 없는 항목이나 지원하지 않는 유형이라면 모든 문제를 형식 오류로 취급하지 말고 코어 지원 여부를 확인해야 합니다.

마이그레이션은 세 단계로 검증할 수 있습니다. 먼저 설정이 불러와지는지 확인하고, 다음으로 특정 노드 하나에서 접속이 되는지 확인한 뒤, 마지막으로 자동 정책과 복잡한 규칙을 복원하세요. 기본 노드는 되지만 도메인 접속이 실패한다면 DNS를 확인하세요. 개별 노드는 되지만 자동 그룹이 동작하지 않는다면 그룹 구성원과 검사 조건을 확인하세요. 시스템 프록시는 되지만 TUN이 실패한다면 기기 측 연결 방식과 권한을 점검하세요. 이 순서를 따르면 서로 다른 문제의 간섭을 줄일 수 있습니다.

구독 업데이트 간격은 제공업체의 변경 빈도에 맞추세요. 너무 자주 업데이트하면 제공업체에서 요청을 제한할 수 있고 모바일 기기의 백그라운드 활동도 늘어납니다. 반대로 오랫동안 업데이트하지 않으면 사용할 수 없는 노드나 오래된 인증서 매개변수가 남을 수 있습니다. 업데이트가 실패하면 먼저 링크와 계정 상태를 확인한 뒤 네트워크와 반환 내용을 살펴보세요. 규칙 데이터와 노드 구독이 서로 다른 출처에서 제공될 수 있으므로 업데이트 시각과 로드 로그를 각각 확인해야 합니다.

8. 사용 환경에 맞게 선택하고 문제 해결 순서 세우기

데스크톱 업무와 모바일 사용의 선택 기준

데스크톱 업무에서는 브라우저, 개발 도구, 회의 앱의 연결 경로가 명확한지 우선 확인하세요. Clash Plus 같은 적절한 클라이언트에 전체 구독을 가져오고 규칙 모드에서 자주 쓰는 대상에 어떤 규칙이 적용되는지 확인합니다. 앱에서 프록시를 직접 설정할 수 있다면 시스템 프록시나 앱 내 프록시로 먼저 검증하세요. 더 많은 앱의 트래픽을 연결해야 할 때만 TUN을 고려해 권한, 라우팅, 프로토콜 문제를 한꺼번에 추가하지 않도록 하세요.

휴대폰에서는 다운로드 최고 속도만 비교하기보다 연결 복구와 백그라운드 안정성을 우선 고려하세요. 신뢰할 수 있는 설정의 기본 전송을 유지하고 Wi-Fi와 셀룰러 네트워크에서 각각 테스트하세요. 특정 네트워크에서만 QUIC 노드가 실패한다면 TCP 계열 노드를 예비로 남겨 두세요. 신호가 약하다면 신호를 개선하거나 네트워크를 바꾸는 것이 먼저입니다. 대역폭 값을 계속 높여도 재전송이나 무선 통신에 따른 배터리 소모는 해결되지 않는 경우가 많습니다.

실시간 음성 통화와 게임에서는 앱의 UDP 트래픽이 실제로 코어에 들어오는지 확인한 다음 노드와 서버가 해당 트래픽을 전달하는지 점검하세요. 대용량 파일 속도보다 지연 변동, 패킷 손실, 세션 유지 여부를 우선 확인해야 합니다. 일부 게임은 로컬 기기 검색, 특정 포트, 지역별 서비스 정책에도 의존합니다. 프록시는 자신이 처리하는 범위의 연결만 다루므로 웹페이지가 열린다는 이유만으로 게임 네트워크 전체가 설정되었다고 판단할 수 없습니다.

라우터, 보조 라우터, 다수의 동시 연결

라우터에서 mihomo를 사용할 때는 먼저 하드웨어 아키텍처, 사용 가능한 메모리, CPU 성능을 확인한 다음 프로토콜과 규칙 규모를 정하세요. 복잡한 전송 조합, 많은 동시 연결, 대규모 규칙 데이터는 리소스 부담을 높일 수 있습니다. 집 안의 모든 기기가 동시에 느려진다면 노드 품질 저하로 단정하지 말고 라우터 부하와 연결 상태부터 살펴보세요.

보조 라우터를 사용할 때는 게이트웨이, DNS, 반환 경로도 명확히 해야 합니다. 한 기기에서는 접속되는데 다른 기기에서는 안 되는 경우 프록시 프로토콜이 호환되지 않는 것이 아니라 연결 방식이 다를 수 있습니다. 모든 기기의 프로토콜을 먼저 바꾸지 마세요. 기본 게이트웨이, DNS 경로, 라우팅 규칙을 확인한 뒤 같은 대상을 테스트하세요. 배포 범위는 라우터와 보조 라우터에서 mihomo 실행하기 개요를 참고하고, 이 페이지의 프로토콜 선택 안내와 함께 확인하세요.

오류가 발생한 단계에 따라 범위를 좁히세요

첫 단계는 설정 로드 확인입니다. 코어가 시작되지 않거나 노드가 표시되지 않는다면 YAML, 구독 형식, 알 수 없는 프로토콜, 항목 지원 여부를 살펴보세요. 두 번째 단계는 서버 연결 확인입니다. 주소 확인 실패는 DNS, 연결 거부는 주소와 포트를 점검하고, 시간 초과는 다른 네트워크와 전송 방식으로 비교하세요. 세 번째 단계는 보안 핸드셰이크와 인증입니다. 인증서 이름, 시스템 시간, 비밀번호, UUID, 확장 매개변수를 설정 출처에 따라 하나씩 확인하세요.

네 번째 단계는 대상에 접속하는 과정입니다. 서버 연결이 이루어졌는데도 실패한다면 어떤 정책이 규칙에 적용되었는지, 대상 도메인이 어떻게 해석되었는지, 특정 유형의 요청만 실패하는지 확인하세요. 웹페이지는 열리는데 앱이 실패한다면 기기 측 연결 방식을 먼저 확인하세요. 도메인은 안 되지만 IP 연결은 된다면 DNS를 중점적으로 점검해야 합니다. 근본 원인을 숨기려고 인증서 검증을 계속 끄거나 임의로 직접 연결 규칙을 추가하거나 오류 항목을 삭제하지 마세요.

다섯 번째 단계에서 성능을 조정하세요. 먼저 같은 조건의 다른 노드로 바꾸고, 다음으로 전송 유형을 변경한 뒤, 대역폭 선언, 연결 재사용, TUN 설정을 하나씩 조정하세요. 무엇을 바꿨고 어떤 결과가 있었는지 기록하고 되돌리는 방법도 남겨 두세요. 문제를 문의할 때는 운영체제, 클라이언트, 코어 이름, 오류 단계, 민감 정보를 제거한 로그를 제공하세요. 원본 구독, 비밀번호, 전체 설정은 공개 첨부 파일에 올리지 마세요.

최종 선택은 매개변수가 가장 많은 조합이 아니라, 이유를 설명할 수 있고 복구할 수 있으며 안정적으로 사용할 수 있는 조합이어야 합니다. 속도 문제를 더 살펴보려면 노드, 회선, 로컬 설정의 세 단계 진단법에 따라 하나씩 확인하세요. 설치와 권한 문제는 빠른 시작 가이드로 돌아가고, 개별 오류는 자주 묻는 질문에서 살펴보세요. 계층을 구분하지 않고 무작정 설정을 바꾸지 않는 것이 중요합니다.