Clash 프로토콜과 mihomo 코어 가이드

1. 프로토콜 선택: 클라이언트, 코어, 전송 방식을 구분하세요

화면에 표시된 프로토콜 이름은 연결의 일부만 설명합니다

프록시 연결은 보통 로컬 접속, 규칙 매칭, 프록시 프로토콜, 하위 전송, 원격 출구의 여러 단계로 구성됩니다. 브라우저가 요청을 로컬 포트로 보내면 코어가 도메인이나 주소에 따라 프록시 그룹을 선택하고, 지정된 노드를 통해 서버에 연결합니다. 프로토콜 이름은 주로 클라이언트와 서버 사이의 인증·캡슐화·전달 방식을 나타냅니다. 출구 대역폭이나 원격 서버 부하, 대상 웹사이트의 응답 속도를 직접 결정하지는 않습니다.

클라이언트는 구독 관리, 화면 설정, 백그라운드 실행과 시스템 연동을 담당하고, 코어는 설정 해석, 연결 수립, DNS 처리와 규칙 실행을 담당합니다. 같은 이름의 클라이언트라도 항상 동일한 코어를 사용하는 것은 아니며, 서로 다른 클라이언트가 같은 계열의 코어를 쓸 수도 있습니다. 특정 노드를 사용할 수 있는지 판단하려면 클라이언트에 포함된 코어와 관련 기능, 서버 측 요구 사항을 함께 확인해야 합니다. 화면이 비슷하다는 이유만으로 호환성을 단정하지 마세요.

프로토콜, 전송 방식, 보안 매개변수를 각각 확인하세요

예를 들어 VLESS는 프록시 프로토콜이고, WebSocket은 전송에 사용할 수 있는 캡슐화 방식이며, TLS는 보안 세션을 제공하는 방식입니다. 서버 이름은 인증서 검증이나 핸드셰이크 선택에 관여합니다. 각각 서로 다른 계층에 속합니다. 구독은 여러 필드를 하나의 노드 설정으로 묶기 때문에 이름만 보면 모든 차이를 프로토콜 탓으로 돌리기 쉽습니다. 비교하기 전에 노드 세부 정보를 열어 프로토콜 유형, 전송 방식, 원격 포트와 보안 옵션을 확인하세요.

TCP는 신뢰성과 순서를 보장하는 데이터 스트림을 제공하고, UDP는 재전송이나 순서를 애플리케이션 대신 보장하지 않는 데이터그램을 전달합니다. QUIC은 UDP 위에서 동작하며 자체 프로토콜에 보안 연결, 신뢰성 있는 스트림과 혼잡 제어를 구현합니다. 노드가 UDP를 사용한다는 이유만으로 모든 애플리케이션 트래픽이 신뢰성 없는 전송으로 바뀌는 것은 아닙니다. 반대로 노드 연결에 TCP를 쓴다고 해서 애플리케이션이 보낸 UDP 데이터그램까지 반드시 전달할 수 있는 것도 아닙니다. 두 항목을 따로 확인해야 합니다.

재현 가능한 비교 조건부터 설정하세요

공정하게 비교하려면 기기, 접속 네트워크, 대상 서비스와 테스트 시간을 가능한 한 동일하게 유지하세요. 두 노드가 서로 다른 지역에 있거나 다른 회선을 사용한다면 결과는 프로토콜만이 아니라 전체 경로의 차이를 반영합니다. 일상적인 선택에 실험실 수준의 측정까지 필요하지는 않지만, 첫 페이지 로딩, 지속 전송, 음성 통화, 대기 후 복구를 각각 확인하세요. 테스트 버튼 하나로 모든 사용 경험을 판단하지 마세요.

클라이언트에 표시되는 지연 시간은 대개 지정된 주소로 한 번 요청한 결과입니다. DNS 조회, 핸드셰이크, 서버 응답 등 여러 단계가 포함될 수 있습니다. 클라이언트마다 측정 방식이 다를 수 있으므로 숫자를 그대로 비교해서는 안 됩니다. 측정에 성공했다는 것은 당시 테스트 경로를 사용할 수 있었다는 뜻일 뿐입니다. 대상 앱은 다른 도메인이나 프로토콜을 쓰거나 별도의 DNS 처리를 할 수 있으므로 직접 실행해 확인해야 합니다.

이 페이지에서 다루는 기능은 실제 코어 구현 범위에 따라 달라집니다. 구독 제공자는 서버가 지원하는 프로토콜과 매개변수를 결정하며, 클라이언트가 SS 노드를 TUIC 노드로 바꿀 수는 없습니다. 다른 프로토콜이 필요하다면 서버에서 제공하는 해당 설정을 받아야 합니다. 로컬에서 유형 필드만 바꾸지 마세요. 이어지는 비교도 인증 정보가 올바르고 서버가 정상이며 매개변수가 일치한다는 전제에 기반합니다.

2. Shadowsocks와 VMess: 간결한 전달 방식과 프로토콜의 발전

Shadowsocks는 프로토콜 계층이 적다는 점이 특징입니다

Shadowsocks는 보통 SS라고 부르며, 암호화된 프록시 전달을 위해 설계됐습니다. 일반적인 설정에는 서버 주소, 포트, 암호화 방식과 비밀번호가 포함됩니다. 각 연결에 범용 웹 전송 계층을 별도로 덧붙이지 않아 직접 사용하는 환경에서는 구성이 비교적 간단합니다. 그래도 클라이언트가 암호화, 인증과 주소 캡슐화를 처리하므로 ‘가볍다’고 해서 연산 부담이 없는 것은 아닙니다. 모든 네트워크에서 더 빠르다고 보장할 수도 없습니다.

SS의 암호화 방식은 자유롭게 바꿔도 되는 장식용 필드가 아닙니다. 기존 스트림 암호, AEAD 방식, 최신 Shadowsocks 2022 계열은 구현 요구 사항이 서로 다르며 일부 방식은 키 형식에도 명확한 제약이 있습니다. 노드 정보에 특정 방식이 표시돼도 구형 코어에서 불러올 수 있다는 뜻은 아닙니다. 암호화 방식 미지원 오류가 발생하면 코어의 지원 범위와 원본 설정을 확인하세요. 익숙한 이름으로 임의 변경하지 마세요.

SS는 구현과 서버 설정에 따라 TCP를 전달할 수도 있고 UDP를 전달할 수도 있습니다. 두 방식은 네트워크에서 연결 가능한 범위가 다를 수 있습니다. 웹은 정상인데 통화에 문제가 있다면 UDP 지원 여부와 허용 상태를 확인하세요. 일부 설정은 플러그인으로 전송 기능을 확장하므로 별도의 의존성이 추가됩니다. 완전한 노드 설정을 옮길 때는 플러그인 이름과 옵션도 보존해야 합니다. 서버, 포트, 비밀번호만 복사하면 연결 방식을 결정하는 정보가 빠질 수 있습니다.

VMess는 인증 방식과 전송 조합을 함께 확인해야 합니다

VMess는 V2Ray 생태계에서 시작된 프로토콜로, 사용자 인증과 프록시 데이터 캡슐화를 제공하고 여러 전송 방식과 조합할 수 있습니다. 인증 및 보안 방식이 발전해 왔기 때문에 VMess라는 이름이 같아도 과거 설정끼리 항상 호환되는 것은 아닙니다. 설정을 확인할 때는 사용자 ID뿐 아니라 전송 유형, TLS 사용 여부, 경로와 요청 호스트 등의 필드도 살펴보세요. 공유 링크의 긴 문자열 하나만으로 전체 설정을 알 수는 없습니다.

오래된 VMess 설정에는 이전 인증 절차에 관련된 매개변수가 포함될 수 있습니다. 최신 설정은 보통 AEAD 인증을 사용하지만, 과거 필드의 기본 해석은 구현마다 다를 수 있습니다. 이전할 때 오래된 가이드의 고정 매개변수 조합을 그대로 복사하지 말고, 오류를 없애려고 필드를 무작정 추가하거나 삭제하지도 마세요. 기기 시간이 크게 어긋나면 인증이나 인증서 확인에 영향을 줄 수 있습니다. 계정 설정을 반복해서 바꾸기 전에 날짜와 시간, 자동 시간 설정 상태부터 확인하세요.

VMess의 실제 성능은 외부 전송 방식의 영향을 크게 받습니다. TCP를 직접 사용하는 설정과 WebSocket, TLS 또는 다른 계층을 거치는 설정은 핸드셰이크 과정, 헤더 캡슐화와 연결 재사용 방식이 다를 수 있습니다. 전송 계층이 서로 다른 두 노드는 프로토콜 이름이 같더라도 첫 요청 시간이나 지속 전송 성능이 달라질 수 있습니다. ‘VMess 노드가 느리다’고 뭉뚱그리지 말고 DNS 조회, 연결, 인증, 애플리케이션 요청 중 어느 단계가 느린지 확인하세요.

클라이언트에서 계속 사용해도 되는지 확인하는 방법

가져온 뒤 먼저 코어가 노드를 제외하지 않았는지 확인하고, 프록시 그룹에서 해당 노드를 선택해 일반 웹 요청과 실제 서비스 테스트를 진행하세요. 노드가 표시되는데도 연결되지 않는다면 로그에서 가장 먼저 나온 오류를 확인하세요. 암호화 방식 미지원, 인증 실패, 연결 시간 초과는 서로 다른 원인입니다. 첫 번째는 호환성, 두 번째는 인증 정보와 시간, 세 번째는 주소와 포트 및 현재 네트워크를 점검해야 합니다.

안정적으로 작동하는 SS 또는 VMess 서비스가 있다면 다른 프로토콜 이름이 더 최신이라는 이유만으로 이전할 필요는 없습니다. 현재 코어의 지원이 중단됐거나 필요한 전송 방식을 지원하지 않거나, 기존 조합에서 재현 가능한 문제가 있을 때 변경을 고려하세요. 데스크톱 웹 탐색과 일반 다운로드에는 익숙하고 검증된 설정을 유지해도 됩니다. 실시간 통화는 UDP 전달 지원을 별도로 확인하고, 웹이 열리는지만으로 판단하지 마세요.

이 두 프로토콜은 이전 과정에서 비교 기준으로도 활용할 수 있습니다. 클라이언트를 바꾼 뒤에는 과거에 작동했던 매개변수가 명확한 설정 하나를 먼저 불러와 로컬 접속과 규칙 처리가 정상인지 확인한 다음 새 프로토콜을 테스트하세요. 모든 유형이 한꺼번에 실패하면 노드를 하나씩 수정하기보다 설정 활성화 여부, 프록시 그룹 선택, 시스템 프록시 적용 상태부터 점검하세요. 클라이언트 접속 문제를 프로토콜 문제로 오해할 가능성을 줄일 수 있습니다.

3. Trojan과 VLESS: 인증, TLS, 외부 전송

Trojan은 TLS 세션을 주요 기반으로 사용합니다

Trojan의 일반적인 구현은 TLS를 통해 프록시 통신을 전달하며, 보안 세션 안에서 비밀번호 인증과 요청 전달을 처리합니다. 설정에는 보통 서버, 포트, 비밀번호와 서버 이름이 포함됩니다. 검증된 TLS 방식을 이용해 전송을 보호하므로 인증서 체인의 신뢰 여부, 이름 일치 여부와 기기 시간이 연결 성립에 중요합니다. 비밀번호가 맞는지만 확인해서는 핸드셰이크 문제를 배제할 수 없습니다.

서버 주소와 TLS 서버 이름은 서로 다른 역할을 할 수 있습니다. 서버 주소는 연결할 위치를 지정하고, 서버 이름은 보통 서버 인증서 선택과 클라이언트의 이름 검증에 영향을 줍니다. 주소로 접속하면서 도메인으로 검증하는 배포 방식도 있으므로 구독에 해당 필드가 있다면 보존해야 합니다. 이전 과정에서 서버 이름이 빠지면 클라이언트가 다른 이름으로 인증서를 확인해 기존 클라이언트에서는 정상인데 새 클라이언트에서는 핸드셰이크가 실패할 수 있습니다. 이를 프로토콜 속도 차이로 단정하지 마세요.

인증서 검증에 실패하면 먼저 노드에 지정된 이름, 서버 인증서와 시스템 신뢰 설정을 확인하세요. 인증서 검증 건너뛰기를 일반적인 해결책으로 사용해서는 안 됩니다. 검증을 끄면 보안 경계가 달라지고 설정 오류를 가릴 수도 있습니다. 서버가 별도의 신뢰 설정을 요구한다면 해당 서비스의 안내에 따라 구성하고, 무관한 노드의 옵션을 복사하지 마세요. 이름 불일치, 인증서 만료, 연결 시간 초과는 각각 따로 해결해야 합니다.

VLESS의 간소한 인증만으로 완전한 보안이 보장되는 것은 아닙니다

VLESS는 주로 사용자 식별과 프록시 캡슐화를 담당하며, 그 자체를 완전한 암호화 전송 방식으로 봐서는 안 됩니다. 실제 배포에서는 TLS, REALITY 또는 다른 외부 보안 방식과 함께 쓰는 경우가 많으며 조합은 서버에서 결정합니다. 사용자 ID, 전송 방식과 관련 보안 매개변수를 확인하세요. VLESS라는 이름만 보고 특정 보호 방식이 적용된다고 단정하거나 모든 VLESS 설정을 오래된 코어에서 인식할 수 있다고 생각하는 것은 정확하지 않습니다.

일부 VLESS 설정에는 flow가 지정되고, 일부 REALITY 조합에는 공개 키, 짧은 ID와 서버 이름이 포함됩니다. 이는 생략해도 되는 메모가 아니며 서로 다른 서버에서 값을 바꿔 쓸 수도 없습니다. 사용 가능한 flow 값은 구체적인 조합에 따라 다릅니다. 설정을 불러오기 위해 구독의 필드를 삭제하면 구문 분석만 통과하고 실제 연결 인증은 실패할 수 있습니다. 확인해야 할 것은 프로토콜 이름 하나의 지원 여부가 아니라 조합 전체의 지원 여부입니다.

WebSocket, gRPC 등의 전송 방식도 연결 수립과 데이터 캡슐화에 영향을 줍니다. 경로, 요청 호스트와 서비스 이름이 서버 라우팅 설정과 맞지 않으면 서버에 도달해도 해당 서비스로 연결되지 않을 수 있습니다. 이때 오류 양상은 비밀번호 오류와 다릅니다. 서버 연결 가능 여부, TLS 또는 다른 보안 핸드셰이크, 전송 라우팅 순으로 확인한 뒤 마지막으로 프록시 인증을 점검하세요. 여러 계층의 매개변수를 동시에 바꾸지 않는 것이 좋습니다.

연결 재사용과 UDP 지원 여부는 프로토콜 표시만으로 판단할 수 없습니다

일반적인 구현에서 Trojan의 UDP 전달은 신뢰성 있는 바이트 스트림으로 캡슐화됩니다. VLESS의 UDP 전달 방식도 구체적인 설정과 구현에 따라 달라집니다. 앱에서 통화가 정상적으로 이뤄지는지는 프로토콜 지원뿐 아니라 클라이언트의 전달 방식과 서버 지원 여부에도 영향을 받습니다. 신뢰성 있는 스트림에 실린 데이터그램은 패킷 손실 후 재전송 대기 때문에 지연될 수 있지만, 모든 실시간 서비스에서 사용할 수 없다는 뜻은 아닙니다. 실제 네트워크에서 확인해야 합니다.

연결 재사용을 이용하면 여러 요청이 하위 연결을 공유해 반복적인 연결 수립 비용을 줄일 수 있지만, 장애나 혼잡도 함께 영향을 줄 수 있습니다. 모든 서버가 특정 재사용 옵션을 지원하는 것은 아니며, 켠다고 반드시 빨라지는 것도 아닙니다. 기존 구독에서는 제공자가 지정한 설정을 우선 유지하세요. 재사용 효과를 비교하려면 같은 노드와 서비스에서 한 항목만 바꾸고 짧은 요청, 장시간 연결, 복구 과정을 확인하세요.

선택 기준으로 보면 Trojan은 호환되는 TLS 서버가 있고 매개변수 관계를 명확히 확인하고 싶을 때 적합합니다. VLESS는 외부 조합과 코어 지원 범위를 더 꼼꼼히 확인해야 합니다. 서버와 무관하게 어느 한쪽이 항상 우월한 것은 아닙니다. 클라이언트에서 구문 분석에 성공했다는 표시만으로는 충분하지 않으며 실제 요청을 테스트해야 합니다. 매개변수가 더 필요하다면 구독 제공자에게 원본 값을 확인하고, 비슷한 노드의 정보를 조합해 그럴듯한 설정을 만들지 마세요.

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

QUIC은 전송을 구성하는 방식을 바꿉니다

Hysteria2와 TUIC은 모두 QUIC을 이용해 프록시 전송을 구성합니다. QUIC은 UDP 위에서 동작하며 자체 프로토콜에서 보안 핸드셰이크, 스트림 관리와 혼잡 제어를 처리합니다. 여러 작업을 하나의 TCP 바이트 스트림에 단순히 연결하는 방식과 비교하면, 스트림 간 순서 전달로 인해 일부 요청이 서로 기다리는 상황을 줄일 수 있습니다. 하지만 여러 스트림이 여전히 링크 대역폭과 혼잡 상태를 공유하므로 요청마다 독립된 대역폭이 할당되는 것은 아닙니다.

한 스트림에서 데이터 손실이 발생해도 다른 스트림이 순서 전달이 끝날 때까지 반드시 기다릴 필요는 없습니다. 이것이 QUIC의 다중 스트림을 이해하는 중요한 지점입니다. 다만 전체 네트워크가 혼잡하거나 서버 출구가 포화 상태이거나 무선 링크 품질이 나빠지면 모든 스트림이 영향을 받을 수 있습니다. QUIC이 하위 네트워크의 패킷 손실을 없애는 것은 아닙니다. 자체 확인 응답, 재전송과 혼잡 제어 알고리즘으로 경로 변화에 대응합니다. 지속 전송 성능은 경로 조건과 함께 판단해야 하며 프로토콜 이름만으로 순위를 매기지 마세요.

하위 계층에서 UDP를 사용하므로 현재 네트워크가 해당 데이터그램의 왕복 통신을 허용해야 합니다. 일반 웹사이트는 열리더라도 일부 네트워크에서는 특정 UDP 통신이 제한될 수 있습니다. 이 경우 Hysteria2와 TUIC이 연결되지 않거나 대기 후 복구에 문제가 생길 수 있습니다. 먼저 작동이 확인된 TCP 계열 설정과 비교하고 다른 네트워크에서도 시험하세요. 시간 초과 값을 계속 늘리기보다는 연결 가능성을 확인해야 합니다. 시간 초과를 늘려도 하위 경로가 연결 가능해지지는 않습니다.

Hysteria2: 대역폭 매개변수와 서버 측 제약을 확인하세요

Hysteria2는 프록시 전송을 위해 인증, TCP 스트림과 UDP 전달 기능을 제공하며 혼잡 제어 관련 설계를 포함합니다. 실제 대역폭 성능은 구현, 경로, 서버 정책과 선택한 제어 방식에 따라 달라집니다. 설정의 업로드·다운로드 대역폭 값은 구매한 요금제의 총량과 같지 않으며, 높게 입력한다고 무조건 좋은 것도 아닙니다. 현실과 맞지 않는 값은 대기열과 패킷 손실을 늘리고 다른 앱과의 경쟁을 심화할 수 있습니다.

일부 설정은 특정 난독화 옵션을 제공하며 클라이언트와 서버에서 같은 값을 사용해야 합니다. 비밀번호, 난독화 설정, TLS 이름과 인증서 신뢰는 서로 다른 계층이므로 하나라도 맞지 않으면 연결이 실패할 수 있습니다. Hysteria의 세대가 다르면 유형 이름만 바꿔서 호환할 수 없습니다. 구독 제공자가 Hysteria2라고 명시했다면 해당 프로토콜을 실제 지원하는 코어를 사용하고 원본 인증 정보를 보존하세요. 구형 프로토콜 가이드를 그대로 적용하지 마세요.

대부분의 경우 사용자가 모든 고급 매개변수를 직접 조정할 필요는 없습니다. 먼저 구독 제공자의 설정으로 연결한 다음 재현 가능한 현상을 기준으로 변경을 검토하세요. 다운로드 중 다른 요청이 눈에 띄게 느려진다면 대역폭 값을 조정하기 전에 회선 포화와 서버 속도 제한부터 확인해야 합니다. 핸드셰이크조차 완료되지 않는다면 네트워크와 인증을 살펴보세요. 처리량 매개변수로 인증 문제를 해결하려고 하면 대개 확인할 변수만 늘어납니다.

TUIC: 버전과 데이터그램 전달 방식을 맞춰야 합니다

TUIC 역시 QUIC 기반으로 프록시 연결과 데이터 전달을 처리하며 인증, 혼잡 제어, 연결 유지와 UDP 전달 관련 설정을 제공합니다. 프로토콜 세대나 구현이 다르면 호환되지 않을 수 있으므로 TUIC이라는 이름만으로 상호 연결을 단정하지 마세요. 클라이언트 코어는 서버에서 실제 사용하는 프로토콜 형식을 지원해야 하고, 구독 변환기도 해당 ID 및 인증 필드를 올바르게 출력해야 합니다.

UDP 전달 모드에 따라 데이터그램의 캡슐화와 신뢰성 처리 방식이 달라집니다. QUIC 데이터그램을 사용하는 방식과 신뢰성 있는 스트림을 이용하는 방식은 각각 장단점이 있으며, 애플리케이션 패킷 크기, 손실 허용 수준과 네트워크 경로가 결과에 영향을 줍니다. 서버가 한 가지 방식만 지원한다면 클라이언트에서 임의로 전환할 수 없습니다. 실시간 앱에 문제가 있다면 웹 테스트 성공 여부만 보지 말고 서버 안내와 전달 모드를 먼저 확인하세요.

QUIC은 연결 이동 등의 기능을 지원하지만, 실제로 무선 네트워크를 전환한 뒤에도 서비스가 유지되는지는 클라이언트 구현, 연결 ID, 서버 정책과 시스템 네트워크 인터페이스 변화에 달려 있습니다. 무선 네트워크에서 셀룰러 네트워크로 전환해도 모든 앱이 끊김 없이 작동한다고 보장할 수 없습니다. 회의나 원격 세션을 사용한다면 네트워크 전환과 절전 후 복구를 직접 테스트하세요. 앱이 자동으로 다시 연결되지 않는다면 앱 자체의 복구 기능도 확인해야 합니다.

따라서 Hysteria2나 TUIC은 해당 프로토콜을 지원하는 서버가 있고, 현재 네트워크에서 UDP를 사용할 수 있으며, 실제 서비스가 해당 경로에서 원활하게 작동할 때 선택하는 것이 좋습니다. 기존 노드의 속도를 높이는 스위치가 아니며 서버 용량이나 양호한 네트워크 경로를 대신하지도 않습니다. 특정 네트워크에서만 반복적으로 사용할 수 없다면 클라이언트 설정 손상으로 단정하기보다 경로 호환성 문제로 분류하세요.

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

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

페이지를 처음 열 때는 도메인 조회, 연결 수립, 보안 핸드셰이크, 프록시 인증과 대상 서버 응답이 차례로 발생할 수 있습니다. 프로토콜 핸드셰이크는 그중 일부일 뿐입니다. 캐시 사용, 기존 연결 재사용, 앱의 사전 연결 때문에 두 번째 방문이 첫 방문보다 훨씬 빠를 수도 있습니다. 노드를 비교할 때는 첫 실행과 연속 사용을 나눠 살펴보세요. 이미 재사용 중인 연결의 요청을 새로 연결하는 요청과 직접 비교하지 마세요.

지속 전송은 병목 대역폭, 혼잡 제어, 패킷 손실과 서버 리소스의 영향을 더 많이 받습니다. 다운로드 속도가 점차 빨라져도 프로토콜이 바뀐 것이 아니라 연결의 사용 가능한 전송 창이 커지는 중일 수 있습니다. 속도가 들쭉날쭉하다면 무선 간섭, 원격 서버의 부하나 대상 사이트의 제한 때문일 수 있습니다. 원인을 구분하려면 비슷한 시간대에 같은 대상을 이용하고 다른 기기가 네트워크를 점유하는지도 확인하세요. 서로 다른 사이트의 다운로드 결과로 프로토콜을 비교하지 마세요.

연결을 재사용하면 반복적인 핸드셰이크를 줄일 수 있지만 여러 서비스가 장애 영향을 함께 받게 될 수 있습니다. 대용량 다운로드와 짧은 요청이 같은 전송을 공유하면 대기열과 스케줄링이 응답성에 영향을 줍니다. 다중 스트림 프로토콜이 일부 대기를 줄여도 공유 출구 용량을 넘어설 수는 없습니다. 일상 업무에서는 짧은 순간의 최대 처리량보다 안정적인 페이지 응답과 정상적인 세션 복구가 더 중요할 수 있습니다. 대용량 파일만 실행하지 말고 실제 작업을 기준으로 테스트하세요.

암호화 부담은 기기 구현과 함께 리소스 사용량을 결정합니다

CPU 사용률은 암호화 알고리즘, 하드웨어 가속, 코어 구현, 데이터 처리량과 연결 수에 따라 달라집니다. 같은 프로토콜도 데스크톱 프로세서와 저전력 기기에서 다르게 작동할 수 있습니다. 추가 캡슐화, 데이터 복사, 사용자 공간 프로토콜 스택과 상세 로그도 리소스를 더 사용합니다. 따라서 기기와 무관하게 항상 가장 효율적인 프로토콜을 정할 수 없으며, 한 컴퓨터의 결과를 휴대폰이나 라우터에 그대로 적용할 수도 없습니다.

메모리 사용량에는 연결 상태, 캐시, 규칙 집합, DNS 데이터와 클라이언트 화면도 포함됩니다. TUN을 활성화하면 앱 트래픽이 코어로 들어가는 경로가 달라져 리소스 사용량도 변할 수 있지만, TUN 자체가 노드 프로토콜을 다른 유형으로 바꾸지는 않습니다. 클라이언트를 바꾼 뒤 배터리 소모가 늘었다면 프로토콜 구현만 의심하지 말고 트래픽 가로채기 범위, 백그라운드 실행, 로그 수준과 구독 갱신 주기를 각각 확인하세요.

저전력 기기에서는 불필요한 전체 노드 테스트를 장시간 실행하지 않는 것이 중요합니다. 많은 노드를 자동으로 점검하거나 구독을 자주 새로고침하고 상태 확인을 지나치게 자주 하면 네트워크가 깨어나는 횟수가 늘어납니다. 요청 데이터가 적더라도 무선 모듈이 계속 활성 상태를 유지하면 대기 전력에 영향을 줄 수 있습니다. 배터리 절감을 위해 프로토콜 이름을 반복해서 바꾸기보다 실제 사용하는 프록시 그룹만 점검하고 적절한 확인 간격을 설정하세요.

모바일에서는 대기 상태와 네트워크 전환을 모두 테스트하세요

휴대폰의 무선 모듈은 여러 상태로 작동하며 연결 유지와 패킷 깨우기가 활성 시간에 영향을 줍니다. 상태 확인을 너무 자주 하면 배터리 소모가 늘고, 너무 드물게 하면 중간 네트워크 장비가 유휴 연결 정보를 삭제할 수 있습니다. 연결 복구와 대기 전력 사이의 균형이 필요하며 모든 통신 환경에 맞는 고정 간격은 없습니다. 구독 기본값을 사용해도 문제가 계속된다면 화면이 꺼진 시간, 네트워크 유형과 복구 양상을 기록한 뒤 필요한 항목만 조정하세요.

시스템의 백그라운드 정책이 클라이언트를 중지하거나 배터리 최적화가 네트워크 활동을 제한할 수 있습니다. 이 경우 화면이 잠긴 뒤에는 모든 프로토콜에서 문제가 생길 수 있습니다. 연결 유지에 필요한 시스템 권한이 클라이언트에 부여됐는지, 다른 VPN 앱이 트래픽을 가로채고 있지는 않은지 먼저 확인하세요. 우선 화면이 켜진 상태에서 재현한 뒤 화면을 끄고 테스트하세요. 백그라운드에서만 실패한다면 노드의 암호화 방식이나 포트를 바꾸기보다 시스템의 앱 수명 주기를 점검해야 합니다.

기기, 네트워크, 노드 조합, 테스트 작업과 오류가 발생한 단계를 간단히 기록해 두세요. 민감한 인증 정보는 기록하지 않아도 됩니다. 매번 한 가지 설정만 바꾸고 비슷한 조건에서 반복 테스트하세요. 특정 조합은 처리량이 높지만 계속 기기가 뜨거워지고 다른 조합은 작업 요구를 충족하면서 대기 후 복구도 안정적이라면 후자를 우선할 수 있습니다. 목표는 실제 요구를 충족하는 조합을 찾는 것이지 모든 프로토콜의 영구적인 순위를 매기는 것이 아닙니다.

6. Clash, Clash Meta, mihomo 코어의 관계

비슷한 설정 구조를 사용해도 기능이 모두 같은 것은 아닙니다

기존 Clash는 프록시 항목, 프록시 그룹, 규칙과 DNS 등을 포함하는 널리 쓰이는 YAML 설정 구조를 만들었습니다. Clash Meta는 관련 생태계에서 프로토콜과 기능을 확장했고, mihomo는 해당 계열의 후속 개발을 이어가고 있습니다. 이름이 달라 서로 무관한 클라이언트 세 개라고 생각하기 쉽지만, 여기서 다루는 것은 주로 코어 계열의 관계입니다. 그래픽 클라이언트는 코어 위에 설정 관리와 시스템 연동 기능을 제공합니다.

과거의 Clash Premium과 기본 오픈소스 코어도 구분해야 합니다. 일부 오래된 가이드는 Premium의 특정 기능을 전제로 하지만, 이름에 Clash가 들어가는 모든 프로그램이 같은 기능을 제공한다는 뜻은 아닙니다. 이전할 때는 예전 클라이언트 화면의 스위치를 그대로 옮기지 말고 현재 실행 중인 코어 이름과 기능을 확인하세요. TUN, 규칙 집합과 DNS 지원 및 기본 동작은 대상 코어와 클라이언트의 연동 방식을 기준으로 점검해야 합니다.

mihomo는 익숙한 설정 구성 방식을 상당 부분 유지하면서 프로토콜과 네트워크 기능을 확장했습니다. 하지만 기존 구조와 호환된다고 해서 모든 과거 필드, 비공개 확장이나 잘못된 표기까지 지원하는 것은 아닙니다. 일부 오래된 설정은 관대한 구문 해석에 의존하고, 기능의 기본 동작이 바뀐 경우도 있습니다. 대상 코어에서 먼저 설정을 검사하고 계층별로 실행 결과를 확인하세요. 알 수 없는 필드가 표시되면 무시해도 기능이 유지될 거라고 생각하지 말고 해당 필드가 어디서 왔는지 확인해야 합니다.

클라이언트 화면에 보이는 설정이 실제 실행 설정과 다를 수 있습니다

그래픽 클라이언트는 원격 구독, 로컬 설정, 덮어쓰기 규칙과 실행 포트를 병합한 뒤 코어에 전달할 수 있습니다. 사용자가 편집한 파일은 여러 입력 중 하나일 뿐입니다. 구독에는 특정 포트가 있지만 실제로는 화면 설정의 다른 포트가 적용되는 사례가 있습니다. 이는 코어 호환성 문제가 아니라 클라이언트 설정의 우선순위 때문일 수 있습니다. 실행 설정을 확인하거나 클라이언트의 설정 미리보기를 열어 최종 적용 내용을 점검하세요.

설정을 병합하는 과정에서 규칙 순서도 결과에 영향을 줍니다. 프록시 항목이 인식되더라도 모든 요청이 해당 항목으로 전달되는 것은 아닙니다. 앞선 규칙이 직접 연결이나 다른 그룹을 선택했을 수 있습니다. 이전 후 웹 출구가 달라졌다면 프로토콜을 먼저 바꾸지 말고 적용된 규칙과 그룹을 확인하세요. DNS와 라우팅도 별도로 점검해야 합니다. 조회 결과나 트래픽 가로채기 경로가 달라지면 노드 매개변수가 같아도 접속 결과가 달라질 수 있습니다.

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

위 예시는 로컬 접속과 실행 모드에 해당하는 필드만 보여 줍니다. 프록시 서버까지 포함한 완전한 설정이 아닙니다. 혼합 포트는 해당 프록시 방식으로 접속할 수 있는 앱에 제공되며, 규칙 모드에는 적용 가능한 규칙도 필요합니다. 이런 필드를 구독에 적어도 클라이언트 화면 설정이 덮어쓸 수 있으므로 실제 실행 상태를 기준으로 확인해야 합니다. 이 설정만으로 시스템 프록시가 활성화되거나 터미널 환경 변수가 자동으로 구성되지는 않습니다.

전체 디렉터리를 한 번에 복사하지 말고 단계별로 이전하세요

먼저 구독 주소, 로컬 YAML, 덮어쓰기 설정과 보관할 선택 기록을 백업하세요. 그런 다음 새 클라이언트에 설정을 가져오고 노드와 프록시 그룹을 확인한 뒤 DNS, 시스템 프록시와 TUN을 차례로 검증하세요. 클라이언트 데이터 디렉터리에는 캐시, 데이터베이스 또는 이전 프로그램에 종속된 상태 정보가 포함될 수 있습니다. 디렉터리 전체를 복사한다고 이전이 끝나는 것은 아닙니다. 실행 캐시를 모두 보관하는 것보다 원본 설정 파일을 보존하는 편이 더 유용한 경우가 많습니다.

클라이언트는 설치 파일 페이지에서 Clash Plus부터 살펴보고, 운영체제와 설정 방식에 따라 Clash Verge Rev, FlClash 등을 비교할 수 있습니다. 기존 작업 환경을 유지해야 한다면 두 클라이언트가 동시에 시스템 프록시를 수정하거나 TUN을 활성화하지 않도록 주의하세요. 과거 클라이언트는 이전 설정을 이해하는 데 참고할 수 있지만, 화면이 익숙하다는 이유로 유지 관리 상태와 새 프로토콜의 호환 범위를 간과해서는 안 됩니다.

이전 후 특정 유형의 노드만 실패하면 해당 프로토콜에서 추가되거나 달라진 필드를 먼저 확인하세요. 모든 노드는 정상인데 앱이 프록시를 사용하지 않는다면 시스템 접속을 점검하고, 규칙 모드에서만 문제가 생긴다면 규칙 참조와 그룹 이름을 확인해야 합니다. 계층별로 분류하면 불필요한 시도를 줄일 수 있습니다. 코어 계열 관계와 설정 차이는 기본 버전, Meta, mihomo 코어 비교에서 더 살펴보고 개념을 실제 실행 로그와 연결해 보세요.

프로토콜 지원 여부는 클라이언트에 포함된 코어의 업데이트 주기에 따라 달라질 수 있습니다. 클라이언트 프로그램과 코어 업데이트가 항상 동시에 이뤄지는 것은 아닙니다. 화면에 기능 메뉴가 있다고 해서 현재 실행 파일이 모든 옵션을 지원한다는 뜻은 아닙니다. 실행 중인 코어 정보를 확인해 실제 결과를 기록하되, 새 이름을 쫓아 자주 교체할 필요는 없습니다. 필요한 기능부터 확인한 다음 클라이언트가 제공하는 업데이트 방법을 이용하세요.

7. 구독 형식과 YAML: 다운로드된다고 바로 불러올 수 있는 것은 아닙니다

먼저 받은 콘텐츠의 유형부터 확인하세요

구독 주소는 콘텐츠를 가져오는 경로일 뿐, 응답 형식이 항상 같은 것은 아닙니다. 일반적으로 전체 Clash YAML, 프록시 항목만 담긴 제공자 파일, 공유 링크 목록 또는 인코딩된 목록이 있습니다. 전체 설정에는 규칙과 프록시 그룹을 정의할 수 있고, 프록시 제공자는 보통 노드 목록을 불러오는 역할을 합니다. 용도가 다르므로 다운로드 가능한 텍스트라면 무엇이든 같은 가져오기 메뉴에 넣을 수 있는 것은 아닙니다.

전체 설정은 보통 proxies에서 로컬 노드를 정의하거나 proxy-providers에서 외부 노드 목록을 불러온 뒤, proxy-groups로 선택 관계를 구성하고 rules에서 요청 경로를 정합니다. 제공자 파일에는 proxies 목록만 있고 실행에 필요한 다른 설정은 빠져 있을 수 있습니다. 제공자 파일을 전체 설정으로 사용하면 사용할 그룹이 없거나 규칙이 빠질 수 있습니다. 그렇다고 노드 비밀번호가 만료됐다는 뜻은 아닙니다.

공유 링크는 별도의 표현 방식입니다. 필드는 인코딩될 수 있고 프로토콜마다 규칙이 다릅니다. 구독 변환기는 해당 필드를 해석한 뒤 대상 코어 형식에 맞게 변환해야 합니다. YAML을 출력했다는 사실은 텍스트가 생성됐다는 뜻일 뿐, 경로, 서버 이름, UDP 모드와 보안 매개변수가 모두 보존됐다는 의미는 아닙니다. 복잡한 전송 설정은 중간 변환으로 정보가 빠질 가능성을 줄이기 위해 구독 제공자가 명시적으로 제공하는 대상 코어 형식을 우선 사용하세요.

제공자 참조는 필요한 의존성을 모두 연결해야 합니다

proxy-providers:
  my-sub:
    type: http
    url: "https://example.com/sub?token=xxxx"
    path: ./providers/my-sub.yaml
    interval: 86400

proxy-groups:
  - name: PROXY
    type: select
    use:
      - my-sub

rules:
  - MATCH,PROXY

이 예시는 제공자, 프록시 그룹과 최종 규칙이 서로 참조되는 관계를 보여 줍니다. 예시의 도메인과 토큰은 실제 값이 아니므로 노드를 가져올 수 없습니다. 실제로 사용하려면 프록시 제공자 형식의 응답을 반환하는 유효한 주소로 바꿔야 합니다. interval의 단위는 초이며 연결 시간 초과가 아니라 예정된 갱신 간격을 나타냅니다. path는 로컬 캐시에 사용하는 경로이고 실제 위치는 클라이언트의 실행 디렉터리와 권한에 따라 달라집니다. 모든 플랫폼에서 같은 위치에 저장된다고 가정하지 마세요.

여기서 MATCH는 조건에 일치하는 요청을 PROXY로 전달합니다. 모든 요구에 적합한 분기 설정은 아닙니다. 직접 연결과 프록시를 구분해야 한다면 최종 매칭 규칙보다 앞에 해당 규칙을 추가하세요. 제공자 이름, 프록시 그룹의 use에 적힌 이름, 규칙이 가리키는 그룹 이름은 서로 일치해야 합니다. 표시 이름만 바꾸고 참조를 수정하지 않으면 설정을 불러오지 못하거나 규칙에서 대상을 찾지 못할 수 있습니다. 이는 노드 프로토콜과 무관한 문제입니다.

구독 가져오기 실패와 연결 실패를 나눠 확인하세요

구독 업데이트에 실패하면 먼저 올바른 응답을 받았는지 확인하세요. 주소 만료, 인증 실패, 로그인 페이지나 오류 안내가 반환되면 클라이언트가 설정이 아닌 콘텐츠를 받을 수 있습니다. 쿼리 매개변수에 계정 접근 권한이 포함될 수 있으므로 전체 구독 주소를 공개 게시물에 붙여 넣지 마세요. 로그를 공유하기 전 토큰, 계정과 전용 주소를 가리고 오류 유형, 응답 콘텐츠 종류와 필요한 설정 구조만 남기세요.

텍스트를 정상적으로 받았다면 다음으로 YAML 구문과 설정 의미를 확인하세요. 들여쓰기는 공백을 사용하고 같은 단계의 필드가 동일한 구조를 유지해야 합니다. 특수 문자가 포함된 값은 구문에 따라 따옴표로 감싸는 것이 좋습니다. 구문 검사를 통과해도 구조를 해석할 수 있다는 뜻일 뿐입니다. 코어가 프로토콜 유형을 인식하는지, 필수 필드가 모두 있는지, 프록시 그룹 참조가 존재하는지 확인해야 합니다. 프로토콜 미지원 메시지가 나오면 관련 없는 들여쓰기를 반복 수정하지 말고 코어 지원 범위를 점검하세요.

설정을 불러오는 데 성공해도 특정 노드만 연결되지 않을 수 있습니다. 이 경우 서버 연결 가능 여부, 인증과 전송 매개변수를 확인하세요. 반대로 구독 업데이트에 실패했다고 해서 캐시된 노드까지 바로 사용할 수 없게 되는 것은 아닙니다. 기존 설정이 계속 실행 중일 수도 있습니다. 업데이트 시간, 현재 활성 설정과 실제 연결 상태를 따로 기록해 업데이트 알림 하나로 모든 접속 실패의 원인을 단정하지 마세요.

덮어쓰기에도 한계가 있습니다. 전체 목록을 교체하는 것과 규칙 한 줄을 추가하는 것은 결과가 다를 수 있으며 클라이언트마다 병합 방식도 다릅니다. 설정 출처를 바꿀 때마다 최종 실행 설정, 특히 그룹 이름과 규칙 위치를 확인하세요. 원격 구독, 로컬 파일과 여러 설정을 관리하는 방법은 Clash Profile과 여러 설정 관리에서 이어서 살펴보세요. 업데이트 동작을 코어가 설정을 임의로 바꾼 것으로 오해하지 않도록 도와줍니다.

8. 사용 환경에 맞는 프로토콜 선택과 결과 확인

데스크톱 웹 탐색과 모바일 사용은 우선순위가 다릅니다

일상적인 데스크톱 웹 탐색에서는 현재 이용할 수 있는 설정 중 안정적이고 필드가 완전하며 클라이언트가 지원하는 것을 우선 선택하세요. SS, VMess, Trojan, VLESS 모두 요구를 충족할 수 있으며 실제 경로와 전송 조합이 중요합니다. 재현 가능한 문제가 없다면 특정 프로토콜을 쓰기 위해 전체 설정을 바꿀 필요는 없습니다. 클라이언트는 Clash Plus를 먼저 살펴본 뒤 다운로드 페이지에서 운영체제별 다른 옵션을 비교할 수 있습니다. 프로토콜은 선택한 클라이언트의 호환 범위 안에서 결정하세요.

모바일에서는 화면 잠금 후 복구, 무선 네트워크 전환과 백그라운드 제한도 확인해야 합니다. 지속 전송 성능이 좋은 QUIC 계열 노드라도 특정 네트워크에서 UDP 연결이 제한될 수 있습니다. TCP 계열 노드 역시 유휴 연결이 정리되어 재연결이 필요할 수 있습니다. 휴대폰에 적합한 설정인지 판단하려면 앱을 막 연 직후 한 번 테스트하는 데 그치지 말고 화면이 켜진 상태의 접속과 평소 대기 상태를 모두 확인하세요.

음성 통화, 회의와 게임에서는 파일 다운로드 속도만 보지 말고 앱의 데이터그램 전달, 지터와 패킷 손실을 확인해야 합니다. 먼저 앱 트래픽이 프록시를 통과하는지, 노드가 필요한 UDP 전달을 지원하는지 확인하세요. 일부 앱은 여러 서버에 동시에 연결하므로 로그인에 성공해도 미디어 연결은 정상이라고 단정할 수 없습니다. 양방향 통화나 세션을 실제로 진행하고 지속 사용 및 네트워크 전환 후 복구 상태를 확인하세요.

서버와 저전력 기기는 먼저 실행 환경의 제약을 해결하세요

서버나 라우터는 보통 코어를 직접 실행하므로 서비스 시작, 설정 경로, 권한과 수신 인터페이스 범위를 직접 관리해야 합니다. 그래픽 클라이언트와 필요한 작업이 다르므로 화면 하나를 줄이기 위해 배포 방식을 바꾸는 것은 권장하지 않습니다. 기기 성능이 제한적이라면 불필요한 전체 검사와 복잡한 트래픽 가로채기부터 줄인 뒤 프로토콜 부담을 비교하세요. 트래픽 진입점을 올바르게 처리하지 못하는 코어는 프로토콜을 모두 지원하더라도 전체 네트워크를 자동으로 프록시하지 않습니다.

LAN 공유를 사용하면 새로운 접속 경계가 생깁니다. 다른 기기의 접속을 허용할 때는 수신 주소, 방화벽과 인증 정책을 확인해야 합니다. 이 기기에서 연결된다고 LAN에서도 연결되는 것은 아닙니다. 프로토콜 선택은 클라이언트와 원격 서버 사이의 연결을 다루며, LAN 기기가 로컬 프록시 포트에 도달하는 문제는 별도입니다. 다른 기기에서 인터넷에 연결되지 않는다면 원격 프로토콜을 바꾸기 전에 로컬 접속부터 확인하세요.

정해진 순서에 따라 문제 계층을 찾으세요

첫째, 설정이 정상적으로 불러와졌는지, 프록시 그룹에 대상 노드가 있는지 확인하고 해당 노드를 직접 선택하세요. 둘째, 로그를 살펴 구문 오류, 연결 시간 초과, 인증 실패, 보안 핸드셰이크 실패 중 무엇인지 판단합니다. 셋째, 앱 트래픽이 실제로 클라이언트를 통과하는지 연결 화면이나 규칙 적용 기록으로 확인하세요. 브라우저는 정상인데 터미널만 실패한다면 접속 방식을 점검하고 브라우저와 터미널의 시스템 프록시 문제 해결을 참고하세요.

넷째, 교차 테스트를 진행합니다. 같은 노드에서 네트워크를 바꾸거나, 같은 네트워크에서 전송 유형을 바꾸거나, 호환성이 확인된 다른 클라이언트에서 동일한 설정을 사용해 보세요. 매번 한 가지 조건만 바꾸고 결과를 기록합니다. UDP 기반 프로토콜만 실패한다면 현재 네트워크 경로를 우선 점검하세요. 특정 보안 조합만 계속 실패하면 해당 조합의 필드를 확인합니다. 모든 프로토콜의 연결 테스트는 통과하는데 앱만 실패한다면 규칙, DNS와 앱 자체의 프록시 설정을 중점적으로 살펴보세요.

DNS 문제는 프로토콜 문제처럼 보이기 쉽습니다. 대상 도메인이 올바르게 해석되지 않거나 연결할 수 없는 주소가 반환되거나, DNS 요청이 예상한 경로로 전달되지 않으면 접속에 실패할 수 있습니다. 클라이언트의 Fake-IP와 실제 주소 모드도 일부 앱 동작에 영향을 줍니다. 기록 없이 DNS 모드, TUN과 노드 프로토콜을 한꺼번에 바꾸지 마세요. 먼저 도메인 조회가 성공하는지 확인한 뒤 연결이 어디로 전달되는지 점검해야 합니다.

마지막으로 검증을 마친 기준 설정과 필요한 백업을 보관하세요. 프로토콜이나 덮어쓰기 규칙을 바꾼 뒤에는 같은 테스트를 다시 실행해 구독 업데이트 후에도 정상적으로 불러올 수 있는지 확인합니다. 변경으로 개선되지 않았다면 옵션을 계속 추가하지 말고 기준 설정으로 되돌리세요. 단계별 설정 방법은 빠른 시작을, 오류 양상별 확인 방법은 도움말 센터를 참고하세요. 프로토콜 가이드는 문제 범위를 좁히고 선택의 차이를 설명하기 위한 것이며 모든 네트워크에 적용되는 고정 매개변수를 제공하지는 않습니다.

신뢰할 수 있는 선택 기준은 현재 기기와 접속 네트워크, 사용하는 앱에서 특정 설정의 연결이 안정적이고 복구도 정상적이라는 식으로 구체적으로 정리할 수 있어야 합니다. 이렇게 기록하면 다시 테스트할 수 있고 환경이 달라졌을 때 재평가할 수 있습니다. 특정 프로토콜이 항상 가장 빠르거나 배터리 효율이 높고 모든 사용자에게 적합하다고 말하면 구현별 차이를 놓치고 다음 문제 해결에도 도움이 되지 않습니다. 경계 조건과 검증 과정을 기록하는 편이 한계 없는 순위표를 외우는 것보다 유용합니다.