Clash 프로토콜 및 커널 기술 참고서

1. 프로토콜 선택 기준 세우기

프로토콜·전송 계층·클라이언트를 먼저 구분하기

Clash 클라이언트는 설정과 트래픽 라우팅의 진입점이고, 프로토콜은 클라이언트가 원격 서버와 통신하는 방식을 정의합니다. 둘은 서로 다른 계층에 있습니다. 설정 파일의 type은 프록시 노드 유형을 결정하며, 예를 들어 ss, vmess, trojan, vless, hysteria2, tuic 등이 있습니다. 커널은 이 필드를 읽고 해당 구현을 호출해 연결을 만듭니다. 그래픽 클라이언트는 구독 가져오기, 프록시 그룹 선택, 규칙 관리, 시스템 프록시, TUN 전환을 담당하지만, 실제로 프로토콜 핸드셰이크·암호화·다중화·데이터 전달을 수행하는 것은 커널입니다.

하나의 프로토콜도 서로 다른 전송 방식과 조합될 수 있습니다. VMess와 VLESS는 TCP, WebSocket, gRPC 등을 전송 방식으로 사용할 수 있으며 TLS는 별도의 계층입니다. Trojan은 일반적으로 TLS 위에서 직접 동작합니다. Hysteria2와 TUIC는 QUIC 및 UDP를 기반으로 합니다. “VLESS + WebSocket + TLS”는 세 부분으로 나누어 이해해야 합니다. VLESS는 인증과 프로토콜 의미를 담당하고, WebSocket은 데이터 캡슐화를 담당하며, TLS는 암호화와 서버 인증을 담당합니다. 어느 한 계층의 매개변수라도 일치하지 않으면 연결이 실패할 수 있습니다.

클라이언트 이름도 커널 이름을 대신할 수 없습니다. Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu 등은 사용자가 직접 조작하는 그래픽 클라이언트이며, mihomo를 통합할 수도 있고 플랫폼과 배포 방식에 따라 다른 빌드를 사용할 수도 있습니다. 클라이언트를 선택할 때는 커널 유형, 업데이트 방식, 대상 플랫폼을 확인해야 합니다. 프로토콜을 선택할 때는 현재 커널이 해당 프로토콜과 확장 필드를 구현하는지 확인해야 합니다. 화면이 비슷하다는 사실만으로는 하위 호환 범위를 판단할 수 없습니다.

우선 확인할 네 가지 조건

첫 번째는 설정 출처입니다. 서비스 제공자가 사용 가능한 구독을 제공한다면 구독에 선언된 프로토콜과 매개변수를 우선 사용하세요. 클라이언트에서 SS 노드를 수동으로 Trojan으로 바꾸거나 type 필드만 교체해서는 안 됩니다. 프로토콜마다 인증 정보, 전송 매개변수, 핸드셰이크 과정이 다르므로 이름만 바꾼다고 프로토콜이 변환되지 않습니다. 두 번째는 커널 지원입니다. 최신 Hysteria2, TUIC 및 일부 VLESS 확장은 대체로 mihomo 또는 호환 구현이 필요하며, 구형 원본 Clash는 이러한 필드를 완전히 읽지 못합니다.

세 번째는 네트워크 조건입니다. 안정적이고 패킷 손실이 적은 고정 네트워크에서는 TCP 계열 프로토콜이 안정적으로 동작하는 경우가 많습니다. 변동이 크고 어느 정도 패킷 손실이 있는 모바일 네트워크에서는 최신 혼잡 제어와 빠른 복구 기능을 갖춘 QUIC 계열이 더 적합할 수 있습니다. 다만 UDP 연결 가능 여부, 통신사 네트워크 정책, 라우팅 장비 구현이 QUIC 성능에 영향을 주므로 프로토콜 이름만 보고 결과를 예측해서는 안 됩니다. 네 번째는 기기 제약입니다. 모바일 기기는 지속적인 깨우기, 백그라운드 유지, 핸드셰이크 빈도, 무선 모듈 활성 시간을 중요하게 봐야 하며, 서버나 라우터는 동시 연결 수, 메모리 한도, 전달 효율을 더 중요하게 봅니다.

속도 측정만으로 결론을 낼 수 없는 이유

한 번의 다운로드 테스트는 보통 특정 시간대, 하나의 경로, 제한된 연결 수만 반영합니다. TCP 슬로 스타트, QUIC 혼잡 윈도우, DNS 조회, 대상 사이트의 연결 재사용, 당시 서버 부하가 결과를 바꿀 수 있습니다. 짧은 테스트는 핸드셰이크와 첫 바이트 성능에 치우치고, 긴 테스트는 지속 처리량과 혼잡 복구를 더 잘 보여줍니다. 웹 탐색은 DNS, 핸드셰이크, 첫 바이트, 작은 객체 동시 요청이 중요하고, 대용량 파일 전송은 안정적인 처리량이 중요하며, 실시간 음성·영상은 지터, 패킷 손실 복구, UDP 전달이 중요합니다. 서로 다른 작업을 하나의 최고값으로만 요약할 수는 없습니다.

더 신뢰할 수 있는 방법은 같은 기기, 같은 규칙, 같은 대상, 비슷한 시간대에서 여러 차례 비교하면서 연결 성공률, 첫 화면이 열리는 시간, 장시간 연결 안정성, 기기 발열을 함께 관찰하는 것입니다. 특정 프로토콜이 일부 시간대에만明显하게 비정상이라면 경로와 서버 상태를 추가로 확인해야 하며, 곧바로 프로토콜 자체의 결함으로 단정해서는 안 됩니다. 최종 선택 기준은 지속적인 사용 가능성, 설정 유지 관리의 용이성, 기기 부담의 수용 가능성입니다.

2. SS·VMess·Trojan·VLESS의 설계상 선택지

Shadowsocks: 구조가 간결한 암호화 프록시 프로토콜

Shadowsocks는 보통 SS로 줄여 부르며, 비교적 간결한 방식으로 암호화된 전달을 수행하는 데 목적이 있습니다. 클라이언트는 비밀번호와 암호화 방식으로 세션에 필요한 정보를 파생한 뒤 TCP 또는 UDP로 서버와 통신합니다. 프로토콜 구조가 가벼워 성숙한 구현에서는 처리 오버헤드가 낮고 설정 항목도 이해하기 쉽습니다. 일반적인 노드에는 서버 주소, 포트, 비밀번호, 암호화 방식이 포함됩니다. 최신 설정에서는 서버가 명확히 제공하고 현재 커널이 지원하는 AEAD 또는 2022 계열 방식을 선택해야 하며, 클라이언트와 서버의 암호화 방식은 완전히 일치해야 합니다.

SS의 장점은 폭넓은 구현, 비교적 관리하기 쉬운 리소스 요구량, 양호한 크로스 플랫폼 호환성입니다. 설정 계층을 줄이고 안정적인 전달과 기기 리소스를 중시하는 환경에 적합합니다. 다만 SS 자체가 TLS를 의미하는 것은 아니며 VLESS나 VMess의 전송 확장 의미를 포함하지도 않습니다. 일부 구독은 플러그인 매개변수를 추가로 선언하는데, 플러그인은 클라이언트와 서버가 모두 지원해야 합니다. 구독에 플러그인이 포함되어 있는데 커널이 이를 인식하지 못하면 노드가 목록에 표시되어도 연결되지 않을 수 있습니다.

SS 문제를 점검할 때는 먼저 암호화 방식 표기, 비밀번호, 서버 포트, UDP 전환을 확인하세요. TCP 페이지는 열리지만 UDP를 사용하는 앱에 문제가 있다면 노드, 프록시 그룹, 클라이언트 커널이 모두 UDP를 허용하는지 확인해야 합니다. 구독으로 생성된 설정이라면 암호화 방식을 수동으로 바꾸지 않는 것이 좋습니다. 클라이언트 설정을 바꿔도 서버 설정은 자동으로 변하지 않기 때문입니다. SS의 간결함은 프로토콜 계층이 적다는 뜻이지, 매개변수 일치 확인을 생략해도 된다는 뜻은 아닙니다.

VMess: 시간 검증과 사용자 식별자를 사용하는 완전한 프로토콜

VMess는 V2Ray 생태계에서 시작되었으며 사용자 식별자와 프로토콜 핸드셰이크로 연결을 구성하고, TCP·WebSocket·HTTP/2·gRPC 등의 전송 방식과 함께 사용되는 경우가 많습니다. SS보다 설정 계층이 많아 서버, 포트, 사용자 식별자 외에도 보안 옵션, 네트워크 유형, 경로, 호스트 이름, TLS 전환, 서버 이름 등이 포함될 수 있습니다. VMess는 여러 전송 조합이 필요한 배포에서 널리 사용되었기 때문에 많은 범용 구독과 기존 설정에 여전히 VMess 노드가 포함되어 있습니다.

VMess는 시스템 시간 오차에 민감합니다. 기기 시간이 크게 어긋나면 인증 단계가 실패할 수 있지만 화면에는 시간 초과나 핸드셰이크 오류만 표시될 수 있습니다. 문제를 점검할 때는 운영체제의 자동 시간 동기화를 활성화하고 시간대와 현재 시간이 정상인지 확인하세요. 또 다른 흔한 문제는 WebSocket 경로, Host 요청 헤더, TLS 서버 이름을 하나의 항목으로 혼동하는 것입니다. 경로는 WebSocket 요청 위치이고, Host는 HTTP 계층의 필드이며, 서버 이름은 TLS 인증서 검증에 사용됩니다. 세 값은 같을 수도 있지만 서버가 각각 다르게 지정할 수도 있습니다.

VMess는 기능이 완전한 편이지만 프로토콜 처리와 설정 복잡도는 순수 SS보다 높은 경우가 많습니다. 이미 안정적으로 작동하는 VMess 구독이라면 프로토콜이 오래되었다는 이유만으로 반드시 이전할 필요는 없습니다. 새 설정은 서버 지원, 커널 호환성, 유지 관리 방안을 기준으로 결정해야 합니다. 실제 성능은 주로 전송 방식과 네트워크 경로에 좌우됩니다. 예를 들어 VMess over WebSocket은 캡슐화와 핸드셰이크 계층이 늘어나고, 직접 TCP를 사용하는 경로는 더 짧지만 서버 구조가 다릅니다. 프로토콜 이름만으로 비교할 수 없습니다.

Trojan: 표준 TLS 연결을 기반으로 하는 프로토콜

Trojan은 TLS 연결 안에서 인증과 데이터 전달을 수행합니다. 클라이언트에는 서버 주소, 포트, 비밀번호가 필요하며 일반적으로 올바른 서버 이름도 필요합니다. TLS 핸드셰이크는 인증서와 대상 이름의 일치 여부를 확인하므로 시스템 시간, 인증서 체인, SNI, 서버 설정이 연결 결과에 영향을 줍니다. Trojan의 설정 개념은 비교적 직관적이지만 “TLS 사용”이 인증서 검사를 생략해도 된다는 뜻은 아닙니다. 인증서 검증을 끄면 서버 신원 확인이 약화되므로 통제된 테스트 외에는 장기적인 해결책으로 사용하지 않는 것이 좋습니다.

Trojan에서 흔한 문제는 서버 이름과 주소의 관계입니다. 노드 주소는 도메인이나 IP일 수 있지만 sni에는 일반적으로 인증서가 포함하는 도메인을 입력해야 합니다. 구독에 sni가 이미 지정되어 있다면 해당 값을 유지하세요. ALPN 같은 고급 매개변수도 서버가 협상하는 범위와 일치해야 합니다. 일반 사용자는 그래픽 화면에서 항목을 하나씩 추측하기보다 구독이 제공하는 완전한 매개변수를 우선 사용하는 편이 안정적입니다.

성능 측면에서 Trojan은 TLS 핸드셰이크가 필요하지만, 최신 구현은 연결 재사용, 세션 복구, 장시간 연결로 반복 비용을 줄일 수 있습니다. 안정적인 네트워크에서는 핸드셰이크 비용이 대개 연결 설정 단계에 집중됩니다. 짧은 연결을 자주 만들거나 모바일 네트워크가 반복 전환되거나 백그라운드 연결이 시스템에 의해 회수되면 재연결 비용이 더 커집니다. 따라서 Trojan은 이미 연결된 장시간 처리량만 보지 말고 최초 연결과 지속 사용을 함께 관찰해야 합니다.

VLESS: 간결한 인증 계층과 조합 가능한 전송

VLESS 역시 V2Ray 생태계에서 시작되었으며, 프로토콜 자체가 담당하는 암호화 역할을 줄이고 TLS 또는 지원되는 다른 보안 계층에 기밀성과 서버 검증을 맡기는 설계입니다. 설정에는 사용자 식별자, 전송 방식, TLS 설정, 서버 이름, 그리고 특정 커널이 지원하는 확장 필드가 포함되는 경우가 많습니다. VLESS 자체는 하나의 고정된 전송 방식이 아니며 TCP, WebSocket, gRPC 등과 조합할 수 있습니다. 따라서 “VLESS가 더 빠른가”를 논하려면 전송 방식과 보안 계층을 함께 밝혀야 합니다.

VLESS 설정의 호환성 문제는 확장 기능에서 발생하는 경우가 많습니다. 커널마다 Reality, 흐름 제어 태그, 클라이언트 지문, 전송 세부 설정 등의 지원 범위가 다를 수 있습니다. 원본 Clash는 최신 VLESS 설정을 많이 지원하지 못하는 반면, mihomo는 관련 프로토콜과 확장을 더 폭넓게 지원합니다. 구독을 성공적으로 가져왔다고 해서 모든 필드가 실행되는 것은 아닙니다. 일부 변환 서비스는 기본 필드는 유지하면서 확장 매개변수를 삭제할 수 있어 노드는 존재하지만 연결되지 않는 결과가 나타날 수 있습니다.

SS, VMess, Trojan, VLESS는 모두 TCP를 하위 전송으로 사용할 수 있지만 인증 방식, 암호화 책임, 확장 방식은 서로 다릅니다. SS는 가벼운 암호화 전달에 중점을 두고, VMess는 완전한 프로토콜 핸드셰이크와 여러 전송 조합을 제공하며, Trojan은 TLS를 기반으로 인증을 구성하고, VLESS는 더 많은 보안 책임을 외부 계층에 맡기면서 조합 가능성을 유지합니다. 선택은 서버 설정과 커널 지원을 따라야 하며 특정 프로토콜을 다른 프로토콜의 직접적인 대체재로 간주해서는 안 됩니다.

3. Hysteria2·TUIC: QUIC 기반 연결 모델

QUIC가 바꾸는 전송 동작

Hysteria2와 TUIC는 모두 UDP와 QUIC 기능을 기반으로 합니다. QUIC는 사용자 공간에서 신뢰성 있는 전송, 암호화 핸드셰이크, 다중 스트림을 구성하여 기존 TCP 연결에서 서로 다른 논리 스트림이 동일한 헤드 오브 라인 블로킹 상태를 공유하는 문제를 줄일 수 있습니다. 한 스트림에서 패킷 손실이 발생해도 다른 스트림이 같은 순서의 누락 데이터를 반드시 기다릴 필요는 없습니다. 이는 동시 요청이 많거나 지터가 있는 네트워크에서 실제 이점이 될 수 있습니다. QUIC는 TLS 의미도 연결 설정 과정에 포함해 프로토콜 계층 간 중복 협상 여지를 줄입니다.

이 모델이 UDP가 본질적으로 TCP보다 빠르다는 뜻은 아닙니다. UDP는 데이터그램 전달만 제공하고 신뢰성, 혼잡 제어, 재전송, 스트림 관리는 QUIC가 담당합니다. 성능은 구현 방식, 혼잡 제어 매개변수, 경로 MTU, 서버 대역폭, 네트워크의 UDP 지원 여부에 따라 달라집니다. 로컬 네트워크가 UDP를 차단하거나 엄격하게 제한하면 Hysteria2와 TUIC는 연결되지 않을 수 있습니다. 반대로 UDP 경로 품질이 좋고 어느 정도 패킷 손실이 있다면 TCP 혼잡 복구를 반복하는 방식보다 안정적일 수 있습니다.

QUIC는 사용자 공간에서 실행되므로 빠른 반복 개발과 유연한 제어가 가능하지만, 암호화·패킷 스케줄링·재전송 처리에 CPU를 사용합니다. 데스크톱 기기는 대체로 이 비용을 감당하기 쉽지만 모바일 기기와 저전력 라우터는 지속적인 고처리량에서 발열과 배터리를 확인해야 합니다. 네트워크 효율과 기기 에너지 효율은 같은 지표가 아닙니다. 전송을 빨리 끝내 무선 모듈을 일찍 절전 상태로 만들 수도 있지만, 지속적인 CPU 부하가 그 이점을 상쇄할 수도 있습니다.

Hysteria2의 대역폭 및 혼잡 제어 방식

Hysteria2는 지연 시간이 길거나 패킷 손실이 있거나 대역폭 변동이 있는 경로를 대상으로 합니다. 설정에는 보통 서버 주소, 인증 정보, TLS 서버 이름, 선택적 업로드·다운로드 대역폭 힌트가 포함됩니다. 대역폭 값은 클라이언트의 측정 결과나 강제 보장값이 아니라 혼잡 제어가 적절한 송신 동작을 설정하는 데 도움을 주는 값입니다. 실제 회선 능력보다 훨씬 높은 값을 입력하면 큐가 쌓이고 패킷 손실이 발생할 수 있으며, 너무 낮으면 사용 가능한 처리량을 능동적으로 제한합니다. 근거가 없다면 서버나 구독이 제공한 설정을 우선 사용하세요.

Hysteria2의 인증 필드는 문자열로 표시될 수 있으며 TLS 관련 필드는 서버 이름과 인증서 설정이 일치해야 합니다. 일부 설정에는 난독화나 포트 점프 같은 확장이 포함되지만, 이러한 기능은 서버·클라이언트 커널·설정 형식이 모두 지원해야 합니다. 범용 구독 변환기가 확장 필드를 인식하지 못하면 기본 노드만 출력되어 가져온 뒤 연결되지 않을 수 있습니다. 이때는 그래픽 화면에서 프록시 모드를 계속 바꾸기보다 원본 YAML을 확인해야 합니다.

경로 MTU는 QUIC 계열 연결에서 쉽게 놓치는 요소입니다. 경로의 특정 구간이 큰 UDP 데이터그램을 처리하지 못하고 조각화나 경로 탐색이 제대로 작동하지 않으면 핸드셰이크는 성공하지만 대용량 트래픽이 멈추거나 일부 사이트만 열리고 다운로드가 중단될 수 있습니다. 문제를 점검할 때는 먼저 추가 전송 계층을 끄고 구독의 원래 매개변수를 복원한 뒤 다른 네트워크에서 비교하세요. 특정 LAN이나 라우터에서만 문제가 발생한다면 라우터의 UDP 세션, MTU, 방화벽 정책을 추가로 확인해야 합니다.

TUIC의 다중화와 모바일 네트워크 전환

TUIC도 QUIC를 기반으로 하며 낮은 지연 시간의 연결, 다중 스트림, 효율적인 전달을 강조합니다. 일반적인 설정에는 서버 주소, 포트, 사용자 식별자, 비밀번호, TLS 서버 이름, 혼잡 제어 알고리즘, UDP 릴레이 모드가 포함됩니다. TUIC 프로토콜 세대에 따라 필드가 다를 수 있으므로 클라이언트와 서버가 호환되는 구현을 사용해야 합니다. 구독에 “TUIC”만 적혀 있고 필요한 인증 필드가 보존되지 않았다면 커널이 추측으로 이를 완성할 수 없습니다.

QUIC에는 연결 마이그레이션 관련 기능이 있지만 클라이언트, 운영체제, 실제 프로토콜 구현이 이 기능을 활용하는지는 버전과 플랫폼에 따라 판단해야 합니다. 휴대폰이 무선 LAN에서 이동통신망으로 전환되면 로컬 주소가 바뀝니다. 이상적인 경우 연결이 더 빠르게 복구될 수 있지만 시스템 백그라운드 제한, VPN 인터페이스 재생성, DNS 갱신, 클라이언트 수명 주기가 완전한 재연결을 유발할 수 있습니다. 따라서 QUIC의 연결 마이그레이션을 모든 모바일 앱이 세션을 유지한다는 뜻으로 보아서는 안 됩니다.

TUIC의 혼잡 제어 옵션을 다른 사람의 설정에서 그대로 복사해서는 안 됩니다. 알고리즘은 네트워크 경로와 서버 기능에 맞아야 하며, 일부 구현은 기본값을 제공하고 구독이 명시적으로 지정할 수도 있습니다. 일반 사용자는 먼저 구독값을 유지하고 장기 안정성을 관찰한 뒤 조정하는 편이 단기 속도 최고값만 추구하는 것보다 신뢰할 수 있습니다. 부하가 높을 때 지연 시간이 갑자기 늘어난다면 업로드가 가득 찼는지, 라우터에 UDP 큐가 쌓였는지, 대역폭 관리가 QUIC 트래픽과 충돌하는지 확인하세요.

QUIC 계열을 우선 선택하지 않아도 되는 경우

고정 네트워크가 안정적이고 TCP 노드가 지속적으로 안정적이며 기기 성능이 제한적이거나 사용 환경의 UDP 동작을 예측하기 어려울 때는 프로토콜이 최신이라는 이유만으로 전환할 필요가 없습니다. 라우터의 저전력 프로세서는 NAT, DNS, 규칙 매칭, 암호화 전달을 동시에 처리해야 하므로 QUIC의 사용자 공간 처리가 CPU 한도에 더 빨리 도달할 수 있습니다. 모바일 기기에서 주로 가벼운 웹 탐색만 한다면 QUIC의 처리량 이점이 백그라운드 연결과 암호화 처리 비용을 상쇄하지 못할 수도 있습니다.

반대로 네트워크에 뚜렷한 지터가 있고 장거리 경로에서 간헐적인 패킷 손실이 발생하며 앱이 여러 동시 스트림을 사용하고 UDP 경로가 안정적이라면 Hysteria2나 TUIC를 후보에 넣을 수 있습니다. 올바른 방법은 안정적으로 작동하는 TCP 계열 노드를 하나 기준으로 남겨 두고 같은 규칙과 비슷한 시간대에 며칠간 관찰하는 것입니다. 한 번의 짧은 속도 측정으로 장기 기본 노드를 정해서는 안 됩니다.

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

속도를 네 단계로 나누기

사용자가 느끼는 “속도”에는 최소한 이름 해석, 연결 설정, 첫 바이트 도착, 지속 전송의 네 단계가 포함됩니다. DNS는 대상 주소를 얻는 방식을 결정하고, 클라이언트와 프록시 서버가 프로토콜 및 보안 핸드셰이크를 수행한 뒤 서버가 대상과 연결하고 안정적인 데이터 전송에 들어갑니다. 웹 페이지는 느리지만 다운로드가 정상이라면 DNS, 핸드셰이크, 작은 객체 동시 요청에 문제가 있을 수 있습니다. 다운로드가 처음에는 빠르다가 흔들리면 혼잡 제어, 패킷 손실, 서버 제한 속도, 로컬 무선 품질과 관련될 가능성이 큽니다.

SS의 프로토콜 처리는 비교적 직접적이어서 CPU가 약한 기기에서도 예측 가능한 비용을 유지하기 쉽습니다. Trojan은 TLS 처리가 필요하지만 성숙한 TLS 라이브러리는 보통 잘 최적화되어 있습니다. VMess와 조합형 VLESS 설정의 비용은 전송 계층의 영향을 크게 받으며 WebSocket, gRPC, 추가 TLS가 캡슐화와 메모리 버퍼를 늘립니다. Hysteria2와 TUIC는 사용자 공간에서 QUIC 상태, 스트림, 재전송을 관리하므로 CPU 사용량이 더 높을 수 있지만 특정 패킷 손실 경로에서는 작업을 더 빨리 끝낼 수도 있습니다.

연결 재사용은 짧은 연결의 비용을 바꿉니다. 여러 요청이 이미 설정된 하나의 연결을 공유하면 반복 핸드셰이크와 시스템 호출을 줄일 수 있지만, 과도한 재사용은 많은 논리 스트림을 하나의 연결에 집중시켜 해당 연결에 문제가 생겼을 때 영향 범위를 키울 수 있습니다. 커널마다 재사용 구현과 기본값이 완전히 같지 않으므로 다른 도구의 매개변수를 복사해 mihomo에 바로 적용해서는 안 됩니다. 서버 지원을 확인하고 문제를 재현할 수 있으며 측정 방법이 명확할 때만 재사용 옵션을 조정하세요.

CPU·메모리·동시 연결

프로토콜 리소스 사용량은 유휴 상태의 작업 관리자 수치만으로 판단할 수 없습니다. 실제 부하는 처리량, 연결 수, 규칙 수, DNS 모드, 로그 수준, TUN 전달이 함께 결정합니다. 높은 처리량은 암호화와 데이터 복사 작업을 늘리고, 짧은 연결이 많으면 핸드셰이크와 연결 테이블 관리가 늘어나며, 복잡한 규칙 집합은 매칭 비용을 높입니다. 상세 로그를 계속 기록하는 것도 추가 I/O를 발생시킵니다. 프로토콜을 비교할 때는 다른 설정을 동일하게 유지해야 하며, 그렇지 않으면 전체 클라이언트 설정 차이를 측정하게 됩니다.

데스크톱 시스템은 일반적으로 메모리와 스케줄링 여유가 더 크지만 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu의 화면 프로세스도 각각 그래픽 런타임 비용을 발생시킵니다. 커널을 평가할 때는 화면 프로세스와 커널 프로세스를 구분해야 합니다. Linux 서버에서 mihomo 커널을 직접 실행하면 리소스 구성이 더 단순합니다. 라우터는 시스템 서비스, 연결 추적 테이블, DNS 캐시에 필요한 메모리를 따로 확보해야 합니다. 메모리가 한도에 가까워지면 어떤 프로토콜이든 시스템 회수나 프로세스 종료로 불안정해질 수 있습니다.

동시 연결 수와 단일 연결 처리량은 같은 지표가 아닙니다. 웹, 소프트웨어 업데이트, 동기화 도구는 전체 트래픽이 많지 않아도 많은 연결을 만들 수 있으며, 이 경우 파일 디스크립터, 연결 상태, DNS 조회가 증가합니다. QUIC 다중 스트림은 여러 논리 스트림을 더 적은 하위 연결에 담을 수 있지만 커널은 여전히 각 스트림의 상태를 관리해야 합니다. SS와 Trojan도 커널 수준 재사용으로 연결 수를 줄일 수 있지만 서버와 클라이언트 설정이 일치해야 합니다.

모바일 배터리 소모를 결정하는 요소

모바일 배터리는 주로 무선 모듈 활성 시간, CPU 깨우기, 백그라운드 유지, 데이터 전송량, VPN 인터페이스 처리, 네트워크 전환의 영향을 받습니다. 프로토콜 암호화 알고리즘은 그중 일부일 뿐입니다. 지속적인 저속 전송은 무선 모듈을 오랫동안 높은 전력 상태로 유지할 수 있으며, 처리량이 높아 작업을 빨리 끝내면 오히려 더 일찍 절전 상태에 들어갈 수도 있습니다. 동시에 복잡한 핸드셰이크, 잦은 재연결, 강한 사용자 공간 암호화는 프로세서 작업을 늘리므로 “더 빠르다”를 곧바로 “더 절전이다”로 바꿔 말할 수 없습니다.

Android에서 Clash Plus, Clash Meta for Android, FlClash, Surfboard를 사용하면 시스템은 보통 VPN 서비스를 통해 트래픽을 가로챕니다. 절전 정책은 백그라운드 프로세스를 제한해 화면이 꺼진 뒤 연결을 회수할 수 있으며, 화면을 켜면 클라이언트가 프록시 연결을 다시 설정해야 할 수 있습니다. iOS 클라이언트는 Network Extension 수명 주기의 영향을 받아 데스크톱과 백그라운드 동작이 다릅니다. 모바일에서 프로토콜을 비교할 때는 같은 시스템 설정, 같은 신호 조건, 비슷한 사용 강도에서 관찰해야 하며 클라이언트와 프로토콜을 동시에 바꾸어서는 안 됩니다.

안정적인 네트워크에서 TCP 계열의 장시간 연결은 성숙한 시스템 수준 최적화를 활용하는 경우가 많습니다. QUIC 계열 연결은 네트워크 지터와 전환 상황에서 일부 복구 대기 시간을 줄일 수 있지만 사용자 공간 데이터 처리가 CPU 활동을 늘릴 수도 있습니다. 가벼운 웹 탐색, 메시지 동기화, 장시간 대기에서는 백그라운드 안정성과 깨우기 횟수가 더 중요하고, 영상·대용량 파일·클라우드 동기화에서는 작업 완료 시간과 발열이 더 중요합니다. 기기가 계속 뜨거워진다면 프로토콜만 바꾸지 말고 이상 재시도, DNS 순환, 과도한 로그 기록, TUN 라우팅 충돌을 먼저 확인하세요.

반복 가능한 비교 방법

먼저 서버 위치와 회선 조건이 비슷하고 프로토콜 또는 전송 방식만 다른 두 노드를 선택하세요. 클라이언트, 커널, 규칙 모드, DNS 설정, 네트워크 환경을 고정하고 결과에 영향을 줄 수 있는 백그라운드 다운로드를 끕니다. 1차 테스트에서는 콜드 연결을 사용해 최초 열림 시간과 연결 실패를 기록합니다. 2차 테스트에서는 지속 전송으로 처리량 안정성을 관찰합니다. 3차 테스트에서는 여러 앱을 동시에 사용합니다. 모바일에서는 화면 잠금 후 복구와 무선 네트워크 전환도 추가합니다. 한 번의 서버 부하로 잘못 판단하지 않도록 각 라운드를 서로 다른 시간대에 반복하세요.

결과는 최고값 순위가 아니라 “작업을 충족하는가”를 기준으로 기록해야 합니다. 예를 들어 웹 첫 화면이 안정적으로 열리고, 영상이 끊기지 않으며, 화면 잠금 후 정상 복구되고, 기기 발열이 허용 범위인 것이 어느 한 번 처리량이 조금 높은 것보다 중요할 수 있습니다. 두 프로토콜 모두 요구를 충족한다면 설정이 더 단순하고 클라이언트 지원이 더 완전하며 서버 유지 관리가 더 명확한 쪽을 우선 선택하세요. 안정성과 설명 가능성 자체가 중요한 성능 지표입니다.

5. 원본 Clash·Clash.Meta·mihomo 커널의 관계

원본 Clash의 역할과 한계

원본 Clash는 설정 파일, 프록시 그룹, 규칙 매칭, DNS, 제어 인터페이스 등 핵심 사용 방식을 정립했습니다. 많은 YAML 필드와 클라이언트 상호작용 모델이 이 생태계를 통해 널리 사용되었습니다. 원본 Clash는 SS, VMess, Trojan 등 주요 유형을 처리하고 규칙에 따라 요청을 프록시, 직접 연결, 거부로 보낼 수 있습니다. 여러 튜토리얼의 proxies, proxy-groups, rules 구조도 지금까지 유효합니다.

원본 프로젝트가 지속적인 개발을 중단한 뒤 프로토콜 지원과 플랫폼 대응은 기존 범위에 머물렀습니다. 최신 VLESS 확장, Hysteria2, TUIC, 규칙 제공자 개선, TUN, DNS의 새로운 기능은 원본 커널에서 사용할 수 있다고 가정해서는 안 됩니다. 구형 클라이언트가 최신 구독을 가져오더라도 알 수 없는 필드를 무시하거나 노드를 건너뛰거나 시작 시 설정 오류를 보고할 수 있습니다. 구버전 클라이언트는 기존 환경 유지에만 적합하며 최신 프로토콜 선택의 기본 기준으로 삼기에는 적절하지 않습니다.

Clash for Windows는 유지 관리가 중단된 그래픽 클라이언트이며, 과거에는 원본 Clash 생태계와 긴밀하게 연결되어 있었습니다. 오래된 설정 안내에 여전히 등장할 수 있지만 최신 구독과 프로토콜에서는 호환 범위가 제한적입니다. 현재 유지 관리되는 클라이언트를 다운로드하려면 클라이언트 목록에서 Clash Plus를 우선 선택하거나 플랫폼에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu 등을 고려하세요.

Clash.Meta의 확장 기능

Clash.Meta는 Clash 설정 구조와의 호환성을 유지하면서 프로토콜, 규칙, DNS, TUN, 플랫폼 네트워크 기능을 확장했습니다. 익숙한 프록시 그룹과 규칙 문법을 계속 사용하면서 더 많은 노드 유형과 최신 전송 방식을 지원할 수 있게 한 것입니다. “Meta 커널”이라고 표시된 많은 클라이언트가 VLESS, Hysteria, TUIC 등의 확장 기능을 제공하는 이유도 여기에 있습니다. 설정 계층은 여전히 YAML이 중심이지만 추가 필드는 Meta 계열 구현만 인식할 수 있습니다.

“Clash 설정과 호환된다”는 말이 모든 방향에서 완전히 상호 변환된다는 뜻은 아닙니다. 원본 Clash 설정은 대체로 Meta 계열이 쉽게 읽지만, Meta 확장이 포함된 설정이 원본 커널에서도 계속 작동한다고 보장할 수는 없습니다. 위험 요소로는 알 수 없는 노드 유형, 추가 DNS 필드, TUN 매개변수, 규칙 제공자 동작, 프록시 그룹 확장이 있습니다. 이전할 때 호환성을 “기본 구조의 계승”으로 이해해야 하며, 모든 필드를 커널 간에 바꿔 쓸 수 있다는 뜻으로 이해해서는 안 됩니다.

일부 구독 변환 도구는 Clash와 Clash.Meta를 출력 대상으로 제공합니다. 구독에 VLESS, Hysteria2, TUIC가 포함되어 있다면 Meta 또는 mihomo용 형식을 선택해야 합니다. 구형 Clash 템플릿을 선택하면 해당 노드가 삭제되거나 하위 호환 형태로 변환될 수 있습니다. 구독에 SS, VMess, Trojan만 포함되어 있다면 두 출력 대상 모두 기본 노드를 읽을 수 있을 가능성이 있지만 DNS와 규칙 부분은 별도로 확인해야 합니다.

mihomo는 현재 이어지는 커널 이름

mihomo는 Clash.Meta 이후에 사용되는 커널 이름으로, 기존 설정 체계와 확장 기능을 이어갑니다. 실제 클라이언트 화면에는 여전히 “Meta”라는 표시가 남아 있을 수 있고 설정 문서에서도 두 이름을 함께 언급하는 경우가 많습니다. 판단할 때는 화면의 브랜드만 보지 말고 클라이언트의 커널 정보나 프로젝트 설명을 확인하세요. 새로 설치하거나 최신 프로토콜을 사용할 때 mihomo는 일반적으로 더 적합한 호환 기준입니다.

mihomo는 프로토콜 연결, DNS, 규칙 매칭, 프록시 그룹, TUN, 제어 인터페이스를 담당합니다. 그래픽 클라이언트는 그 위에서 설정 관리, 시스템 트레이, 구독 업데이트, 플랫폼 권한 처리를 제공합니다. 클라이언트 업데이트와 커널 업데이트는 서로 다른 주기로 진행될 수 있습니다. 화면 버전이 바뀌었다고 커널 기능이 바뀌는 것은 아니며, 커널 업데이트가 클라이언트에 조용히 통합될 수도 있습니다. 최신 프로토콜을 인식하지 못한다면 클라이언트 배포 상태와 실제 커널 정보를 모두 확인하세요.

서버나 라우터 사용자는 데스크톱 그래픽 화면 없이 mihomo 커널을 직접 배포할 수도 있습니다. 이 방식은 설정 파일과 시스템 서비스로 관리하기 쉽지만 권한, 로그, 시작 순서, DNS 포트, 방화벽을 직접 처리해야 합니다. 일반적인 데스크톱 및 모바일 사용자는 시스템 프록시, TUN 권한, 구독 관리가 화면에 통합된 완전한 클라이언트를 사용하는 편이 적합합니다.

안전한 설정 이전 순서

구형 클라이언트에서 mihomo 클라이언트로 이전할 때는 먼저 기존 설정 사본을 보관한 뒤 구독이나 YAML을 가져오고, 기존 파일을 즉시 덮어쓰지 마세요. 시작 후 설정 파싱 로그를 확인해 프록시 노드 수, 프록시 그룹 이름, 규칙 제공자가 모두 로드되었는지 확인합니다. 그런 다음 기본 TCP 노드를 테스트하고 Hysteria2나 TUIC 같은 확장 노드를 테스트하세요. 마지막으로 시스템 프록시나 TUN을 켜서 설정이 검증되기 전에 시스템 라우팅 변수까지 동시에 도입하지 않도록 합니다.

설정 파싱에 실패하면 로그에 표시된 필드나 줄 번호부터 확인하세요. YAML은 들여쓰기에 민감하며 Tab, 중복 키, 따옴표, 콜론 위치가 모두 오류를 일으킬 수 있습니다. 설정은 로드되지만 일부 노드가 사라진다면 노드 유형과 필드가 현재 커널 지원 범위에 속하는지 확인하세요. 모든 노드는 정상인데 규칙 동작만 바뀌었다면 규칙 순서, 규칙 집합 형식, DNS 모드를 다시 확인하세요. 이전 과정을 파싱, 노드, 프록시 그룹, 규칙, 시스템 연결의 다섯 단계로 나누면 문제 범위를 크게 좁힐 수 있습니다.

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: "Example-SS"
    type: ss
    server: 192.0.2.10
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "노드 선택"
    type: select
    proxies:
      - "Example-SS"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,노드 선택
  - MATCH,노드 선택

위 조각은 기본 구조를 설명하기 위한 예시이며 주소는 문서용입니다. 실제 노드 매개변수는 서버나 구독이 제공해야 합니다. 설정을 mihomo가 읽을 수 있다고 해서 예시 노드가 연결된다는 뜻은 아닙니다. 실제 배포에서는 플랫폼에 따라 DNS, TUN, 제어 인터페이스 설정을 추가해야 합니다.

6. 구독 형식·YAML 필드·변환 호환성

구독 링크가 반환하는 형식은 하나가 아니다

클라이언트에 붙여 넣는 “구독 링크”는 설정을 가져오는 입구일 뿐이며, 반환 내용은 완전한 Clash YAML, Base64로 인코딩된 범용 노드 목록, 단일 공유 링크 모음, 서버가 클라이언트 식별자에 따라 동적으로 생성한 형식 중 하나일 수 있습니다. 가져오기의 성공 여부는 클라이언트 구독 파서가 반환 내용을 인식하는지에 달려 있습니다. 브라우저에서 링크가 열린다고 해서 내용이 Clash 설정이라는 뜻은 아니며, 읽기 어려운 문자열이 표시된다고 데이터가 손상된 것도 아닙니다.

완전한 Clash YAML에는 보통 proxies, proxy-groups, rules가 포함되고 DNS, 규칙 제공자, 포트 설정이 추가되기도 합니다. 범용 구독에는 노드만 있고 프록시 그룹과 규칙이 없을 수 있으며, 이 경우 가져온 뒤 클라이언트에서 기본 그룹을 직접 생성해야 합니다. 공유 링크는 ss://, vmess://, trojan://, vless:// 같은 프로토콜 스킴으로 시작합니다. Hysteria2와 TUIC에도 각자의 표현 방식이 있지만, 단일 링크와 일괄 구독 지원 범위는 클라이언트마다 다릅니다.

더 자세한 설명은 구독 링크 형식과 가져오기 방법을 참고하세요. 이 문서에서는 호환성 판단에 집중합니다. 구독 서비스가 mihomo 또는 Clash.Meta YAML을 직접 출력할 수 있다면 프록시 그룹, 규칙, 최신 프로토콜 필드를 보존할 수 있으므로 해당 형식을 우선 선택하세요. 범용 노드 목록만 얻을 수 있다면 클라이언트나 변환기가 그룹과 규칙을 추가해야 합니다.

YAML에서 노드 사용 가능 여부를 결정하는 필드

모든 노드에는 이름, 유형, 서버, 포트가 필요하지만 프로토콜마다 별도의 인증 필드도 요구합니다. SS는 비밀번호와 암호화 방식을 사용하고, VMess는 보통 사용자 식별자를 사용하며 alterId, 보안 옵션, 전송 네트워크를 선언할 수 있습니다. Trojan은 비밀번호와 TLS 서버 이름을 사용하고, VLESS는 사용자 식별자, 보안 계층, 전송 확장을 사용합니다. Hysteria2는 인증, SNI, 선택적 대역폭 매개변수를 사용하며, TUIC에는 사용자 식별자, 비밀번호, SNI, 혼잡 제어, UDP 릴레이 설정이 포함되는 경우가 많습니다.

필드 이름은 대상 커널의 문법에 맞아야 합니다. 특정 앱이 내보낸 JSON 설정을 Clash YAML에 그대로 복사할 수는 없습니다. 계층과 이름 규칙이 다르기 때문입니다. 두 도구가 모두 VLESS를 지원하더라도 전송, 보안 계층, 지문을 서로 다른 필드로 표현할 수 있습니다. 신뢰할 수 있는 방법은 대상 커널이 인정하는 구독 템플릿을 사용하거나 mihomo 문서에 따라 항목별로 변환한 뒤 시작 로그에서 설정 파싱 결과를 확인하는 것입니다.

YAML 문자열에 콜론, 샵, 중괄호, 특수 접두사가 포함되면 따옴표를 사용하는 것이 파싱 혼동을 줄이는 데 도움이 됩니다. 들여쓰기는 공백으로 하고 계층을 일관되게 유지해야 합니다. 프록시 그룹이 노드 이름을 참조한다면 공백과 대소문자를 포함해 문자열이 완전히 같아야 합니다. 구독 업데이트 후 노드 이름이 바뀌면 수동으로 작성한 프록시 그룹이 이전 이름을 참조해 비어 있거나 다른 항목으로 되돌아갈 수 있습니다. 규칙 대상도 현재 존재하는 프록시 그룹 이름과 일치해야 합니다.

구독 변환에서 누락되는 항목

변환 과정에서는 원본 필드를 대상 필드에 매핑해야 합니다. 기본 SS, VMess, Trojan 노드는 비교적 쉽게 매핑되지만 최신 VLESS 확장, Hysteria2 대역폭 옵션, TUIC 릴레이 모드, 클라이언트 지문, 특정 전송 매개변수는 템플릿 기능이 부족하면 누락될 수 있습니다. 변환 결과가 YAML 문법 검사를 통과했다는 것은 텍스트 구조가 유효하다는 뜻일 뿐 프로토콜 의미가 완전하다는 뜻은 아닙니다.

변환이 완전한지 판단하려면 원본 노드와 출력 YAML을 대조하세요. 노드 유형이 유지되었는지, 서버와 포트가 같은지, 인증 필드가 존재하는지, TLS가 켜져 있는지, SNI·경로·Host·ALPN·지문·프로토콜 확장이 남아 있는지 확인해야 합니다. Hysteria2와 TUIC는 UDP, 혼잡 제어, 인증 필드도 확인해야 합니다. 변환 후 특정 노드 유형 전체가 사라졌다면 출력 대상이 구형 Clash 형식이거나 변환기가 해당 프로토콜을 지원하지 않는 경우가 많습니다.

변환을 여러 번 연속으로 수행하지 마세요. 변환이 한 번 추가될 때마다 노드 이름을 다시 지정하거나 프록시 그룹을 재생성하거나 알 수 없는 필드를 삭제할 수 있습니다. 가장 이상적인 경로는 구독 원본이 mihomo 설정을 직접 출력하는 것입니다. 그다음은 원본 범용 구독을 한 번 변환하는 방식입니다. 구형 Clash로 먼저 변환한 뒤 Meta로 다시 변환하는 것은 권장하지 않습니다. 사용자 지정 규칙을 유지해야 한다면 클라이언트가 지원하는 덮어쓰기나 규칙 제공자 기능으로 노드 구독과 로컬 규칙을 조합해 업데이트마다 전체 파일을 수동 수정하는 일을 줄이세요.

구독 업데이트와 로컬 수정의 관계

대부분의 클라이언트는 구독을 업데이트할 때 원격 내용을 다시 다운로드합니다. 구독으로 생성된 설정을 로컬에서 직접 편집하면 다음 업데이트에서 덮어써질 수 있습니다. 장기간 유지할 규칙, DNS, 프록시 그룹 변경은 클라이언트가 제공하는 덮어쓰기·병합 설정·스크립트 기능을 사용해야 합니다. 이러한 기능이 없다면 로컬 설정으로 복사해 직접 업데이트를 관리할 수 있지만, 노드 변경 사항도 수동으로 동기화해야 합니다.

구독 업데이트에 실패하면 먼저 다운로드 실패와 파싱 실패를 구분하세요. 다운로드 실패는 링크 유효성, 시스템 시간, DNS, 현재 네트워크와 관련된 경우가 많고, 파싱 실패는 로그에 YAML 줄 번호, 알 수 없는 유형, 필드 오류로 나타납니다. 기존 설정이 여전히 연결된다면 업데이트 실패만으로 기존 파일을 즉시 삭제하지 마세요. 사용 가능한 이전 설정을 보관하면 문제를 해결하는 동안 노드 필드와 프록시 그룹 구조를 비교할 수 있습니다.

클라이언트 사이에서 구독을 이전할 때 캐시 파일 경로만 복사하지 마세요. 클라이언트마다 설정 디렉터리, 덮어쓰기 규칙, 커널 매개변수 구성이 다릅니다. 더 안정적인 방법은 원본 구독 링크를 다시 가져온 뒤 필요한 로컬 규칙만 옮기는 것입니다. 로컬 YAML을 사용한다면 경로 권한, 파일 인코딩, 줄바꿈이 정상인지 확인하세요. Windows 경로의 역슬래시가 YAML 문자열에 들어갈 때는 따옴표와 올바른 이스케이프로 잘못 해석되지 않도록 해야 합니다.

7. 클라이언트·운영체제·프로토콜 지원 선택

그래픽 클라이언트는 먼저 커널과 플랫폼 통합을 확인

프로토콜 지원은 커널이 결정하지만 일상적인 사용 가능성은 클라이언트가 커널을 관리하는 방식에도 달려 있습니다. Windows와 macOS 클라이언트는 시스템 프록시, 서비스 모드, TUN 권한, 시작 시 실행, 트레이 상태를 처리해야 합니다. Android와 iOS는 시스템 VPN 인터페이스에 의존하며, Linux 데스크톱은 데스크톱 환경, 시스템 프록시 변수, 권한을 추가로 고려해야 합니다. 명령줄 커널에서 프로토콜을 사용할 수 있다고 해서 그래픽 클라이언트가 가져오기, 편집, 오류 표시까지 완전히 지원한다는 뜻은 아닙니다.

Clash Plus는 모든 플랫폼을 우선 지원하는 선택지로, Windows·macOS·Android·iOS에서 비슷한 조작 방식을 유지하려는 사용자에게 적합합니다. Windows와 macOS에서는 Clash Verge Rev와 FlClash도 고려할 수 있고, Windows에서는 Clash Nyanpasu를 사용할 수 있습니다. Android에서는 Clash Meta for Android, FlClash, Surfboard를 선택할 수 있습니다. Linux 데스크톱에서는 Clash Verge Rev와 FlClash가 자주 사용되며 mihomo를 직접 배포할 수도 있습니다. Clash for Windows와 ClashX Meta는 유지 관리가 중단되었으므로 기존 설정 처리에 더 적합하고 최신 프로토콜의 우선 선택 환경으로 삼아서는 안 됩니다.

클라이언트를 선택할 때는 세 가지 사실을 확인하세요. 통합된 커널이 구독의 노드 유형을 지원하는지, 시스템 연결 방식이 요구 사항에 맞는지, 구독과 설정 관리가 명확한지입니다. 화면 테마, 창 배치, 트레이 스타일은 사용 취향일 뿐 프로토콜 호환성 판단을 대신할 수 없습니다. 전체 클라이언트 목록과 시스템 요구 사항은 클라이언트 비교 및 클라이언트 받기에서 확인할 수 있습니다.

Windows와 macOS

Windows의 시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 영향을 줍니다. 일부 UWP 앱, 게임, 자체 네트워크 스택을 사용하는 소프트웨어는 TUN이나 추가 시스템 설정이 필요할 수 있습니다. 프로토콜 연결은 성공하지만 특정 앱이 프록시를 사용하지 않는다면 노드 프로토콜을 바꾸기 전에 트래픽이 커널로 들어오는지부터 확인하세요. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 트래픽을 가로채므로 적절한 권한과 올바른 라우팅이 필요합니다. Windows 설치, 시스템 프록시, 흔한 오류는 Windows 설치 및 설정 전체 과정에서 확인할 수 있습니다.

macOS도 시스템 프록시와 가상 네트워크 연결을 구분합니다. Apple Silicon과 Intel은 설치 패키지 아키텍처가 다르지만 설정 파일의 프로토콜 의미는 같습니다. 클라이언트는 실행되지만 커널 프로세스가 즉시 종료된다면 아키텍처, 실행 권한, 설정 파싱 로그를 확인하세요. Trojan, VLESS, Hysteria2처럼 TLS를 사용하는 프로토콜은 시스템 시간과 서버 이름에도 의존하므로 시간 오류가 여러 노드에 동시에 영향을 줄 수 있습니다.

데스크톱에서는 더 자세한 로그를 활용해 문제를 점검할 수 있습니다. 먼저 로그 수준을 info로 설정하고 연결 문제를 한 번 재현한 뒤 DNS, 프로토콜 핸드셰이크, TLS, 시간 초과, 규칙 선택 중 어디에서 문제가 발생했는지 기록하세요. 지나치게 높은 로그 수준을 장기간 사용하면 디스크 쓰기가 늘고 핵심 정보를 찾기 어려워집니다. 문제를 파악한 뒤에는 일반적인 수준으로 되돌리세요.

Android와 iOS

Android 클라이언트는 일반적으로 로컬 VPN 서비스를 만들어 앱 트래픽을 커널로 보냅니다. 시스템 절전 정책, 백그라운드 실행 권한, 상시 알림이 지속적인 연결에 영향을 줍니다. 화면을 일정 시간 꺼 둔 뒤 연결이 끊기고 클라이언트를 열면 복구된다면 시스템이 백그라운드 활동을 제한하는지 확인하세요. 특정 앱만 프록시를 거치지 않는다면 앱별 프록시, 우회 설정, 규칙 적중 여부를 확인하세요. 프로토콜 자체는 보통 첫 번째 점검 대상이 아닙니다.

iOS 클라이언트는 시스템 네트워크 확장을 사용하며 앱이 사용할 수 있는 메모리와 백그라운드 수명 주기는 시스템이 관리합니다. Clash Plus는 App Store에서 iOS 버전을 제공하고 clashplus.io에서 제품 정보를 제공합니다. 모바일에서는 너무 큰 규칙 집합을 가져온 뒤 상세 로그를 계속 켜 두는 것이 적합하지 않습니다. 메모리와 처리 부담이 증가하기 때문입니다. 규칙이 복잡하다면 정리된 규칙 집합을 우선 사용하고 중복 항목을 줄이세요.

모바일 네트워크 전환은 로컬 주소, DNS, 사용 가능한 전송 방식을 바꿉니다. TCP 노드는 연결을 다시 만들어야 할 수 있고 QUIC 계열은 더 빠르게 복구할 수도 있지만 시스템 VPN 인터페이스와 클라이언트 수명 주기의 영향을 여전히 받습니다. 모바일 프로토콜을 비교할 때는 무선 LAN, 이동통신망, 화면 잠금 후 복구, 네트워크 전환의 네 가지 상태를 최소한 테스트하세요. 데스크톱에서만 속도가 정상이라고 모바일 설정도 안정적이라고 증명되는 것은 아닙니다.

Linux·서버·라우터

Linux 데스크톱에서는 그래픽 클라이언트를 사용할 수도 있고 mihomo를 직접 실행할 수도 있습니다. 그래픽 클라이언트는 구독과 데스크톱 프록시 관리에 적합하고, 커널을 직접 실행하는 방식은 서버·컨테이너·라우터에 적합합니다. 명령줄 배포에서는 설정 디렉터리, 작업 디렉터리, 로그 출력, 서비스 사용자를 명확히 지정해야 합니다. 설정 파일은 먼저 포그라운드에서 시작해 검증한 뒤 systemd 같은 서비스 관리기에 맡기세요. 그래야 시작 실패 시 반복 재시작 로그만 보게 되는 일을 피할 수 있습니다.

라우터 배포에는 전달 체인, DNS 가로채기, LAN 접근, 연결 추적도 포함됩니다. Hysteria2와 TUIC는 UDP 경로를 요구하며 저전력 기기에서는 CPU도 확인해야 합니다. 라우터 커널은 정상적으로 작동하지만 LAN 기기가 접근하지 못한다면 프로토콜 인증을 바로 바꾸지 말고 수신 주소, LAN 연결 허용, 시스템 방화벽, 클라이언트 게이트웨이를 확인하세요. 배포 방식은 라우터 및 우회 라우터 배포 개요를 참고할 수 있습니다.

서버 환경에서는 복구 가능성을 우선 확보해야 합니다. 검증된 설정을 하나 보관하고 커널을 업데이트하기 전에 현재 시작 매개변수를 기록하며, 프로토콜 노드를 수정한 뒤에는 먼저 설정 검사나 포그라운드 시작을 실행하세요. 새 설정이 실패하면 빠르게 되돌릴 수 있어야 합니다. 여러 기기가 공유하는 라우터 환경에서는 안정적인 SS, Trojan 또는 기존 TCP 노드가 프로토콜을 자주 조정하는 것보다 유지 관리하기 쉽습니다. 패킷 손실 경로를 개선하거나 UDP 앱이 필요할 때만 QUIC 계열을 검토하세요.

8. 사용 상황별 프로토콜 선택과 문제 해결

일상적인 웹 탐색과 업무 앱

일상적인 웹 탐색, 문서 협업, 메시지 앱은 단일 연결 최고값보다 연결 성공률, 첫 바이트 시간, 장기 안정성을 더 중요하게 보는 경우가 많습니다. 기존 SS, Trojan, VMess 노드가 안정적으로 작동한다면 최신 프로토콜이 등장했다는 이유만으로 이전할 필요는 없습니다. 새 설정이 필요하다면 구독이 기본 제공하고 클라이언트가 완전히 지원하며 설정 계층이 적은 노드를 우선 선택하세요. 규칙 모드에서는 대상 요청이 예상한 프록시 그룹에 적중했는지도 확인해야 합니다.

브라우저는 정상인데 다른 앱에 문제가 있다면 먼저 시스템 프록시의 적용 범위를 확인하세요. 시스템 프록시는 해당 설정을 따르는 프로그램에만 영향을 주며, 더 넓은 트래픽을 가로채는 것은 TUN입니다. 브라우저의 첫 실행만 느리고 이후에는 정상이라면 DNS와 핸드셰이크를 나누어 확인하세요. 모든 프로토콜에서 동시에 이름 해석에 실패한다면 DNS 설정이나 시스템 네트워크 문제일 가능성이 더 큽니다. 특정 프로토콜만 실패할 때는 해당 프로토콜의 인증, TLS, UDP 조건을 점검하세요.

규칙 설정은 구체적인 항목에서 기본 처리 항목으로 이어지는 순서를 따라야 합니다. 도메인 접미사, 규칙 집합, 지역 규칙이 적중하면 이후 매칭을 중단하고, 어떤 규칙에도 맞지 않는 트래픽은 MATCH가 처리합니다. 노드 연결 테스트는 정상인데 앱이 잘못된 경로를 사용한다면 구독을 반복 업데이트하지 말고 연결 목록의 규칙과 프록시 그룹을 확인하세요. 규칙 분할의 전체 작성법은 Clash 규칙 분할 설정 실전을 참고할 수 있습니다.

영상·대용량 파일·고처리량 작업

지속 전송에서는 서버의 가용 대역폭, 회선 안정성, 혼잡 복구를 우선 비교해야 합니다. 패킷 손실이 적고 안정적인 네트워크에서는 SS, Trojan, VLESS, VMess 모두 좋은 처리량을 얻을 수 있으며 프로토콜 차이보다 회선 차이가 더 큰 경우가 많습니다. 패킷 손실이 뚜렷하고 UDP 경로가 양호하다면 Hysteria2나 TUIC를 테스트할 수 있지만, 시작 단계의 속도만 보지 말고 장시간 처리량, 버퍼링 중단, 기기 발열을 관찰해야 합니다.

고처리량에 문제가 생기면 먼저 로컬 무선 신호와 업로드가 다른 작업으로 가득 차지 않았는지 확인한 뒤 직접 연결과 프록시 경로를 비교하세요. 모든 노드가 비슷한 속도에서 한계에 도달한다면 로컬 네트워크, 서버 대역폭, 기기 CPU 제한일 수 있습니다. QUIC 계열 연결만 흔들린다면 UDP, MTU, 대역폭 매개변수를 확인하세요. WebSocket이나 gRPC 노드만 문제가 있다면 경로, Host, TLS 이름, 서버 전송 설정을 대조하세요.

라우터가 전체 트래픽의 진입점이 되면 기기 CPU가 쉽게 병목이 됩니다. 단일 데스크톱 클라이언트가 낼 수 있는 처리량이 저전력 라우터에서도 그대로 나온다는 보장은 없습니다. 테스트할 때 커널 프로세스 CPU가 단일 코어 한도에 가까운지 확인하고 고빈도 디버그 로그를 끄세요. CPU가 이미 가득 찼다면 혼잡 제어를 계속 조정해도 문제가 해결되지 않습니다. 리소스 비용이 더 적합한 프로토콜로 바꾸거나 성능이 더 높은 기기에 커널을 배포해야 합니다.

모바일 기기와 잦은 네트워크 전환

모바일에서는 최고 처리량보다 백그라운드 복구를 우선해야 합니다. 무선 LAN과 이동통신망 사이를 자주 전환한다면 Trojan, VLESS, QUIC 계열 노드의 복구 시간을 비교할 수 있지만 클라이언트, 규칙, DNS는 동일하게 유지해야 합니다. 전환 후 모든 노드가 잠시 실패한다면 VPN 인터페이스 재생성이나 DNS 갱신 지연일 수 있습니다. Hysteria2와 TUIC만 실패한다면 새 네트워크의 UDP 연결 가능 여부를 추가로 확인하세요.

대기 중 배터리 소모가 비정상적이라면 지속적인 재연결이 있는지 확인하세요. 잘못된 서버 주소, 만료된 구독, TLS 이름 불일치, 연결할 수 없는 UDP 노드가 클라이언트의 반복 연결을 유발할 수 있습니다. 기본 프록시 그룹을 잠시 검증된 안정 노드로 바꾸고 백그라운드 배터리 소모가 회복되는지 관찰하세요. 불필요한 상태 확인 빈도를 낮추고 규칙 규모를 줄이며 디버그 로그를 끄는 것도 지속적인 깨우기를 줄일 수 있습니다.

모바일에서는 기능이 중복되는 노드를 많이 유지할 필요가 없습니다. 프록시 그룹의 노드가 지나치게 많으면 상태 확인과 구독 처리 부담이 커집니다. 실용적인 구성은 안정적인 TCP 노드 몇 개, 검증된 QUIC 계열 노드 하나, 명확한 장애 복구 항목을 유지하는 것입니다. 자동 선택 그룹은 적절한 검사 간격을 사용하고, 여러 프록시 그룹이 같은 노드 묶음을 높은 빈도로 반복 테스트하지 않도록 하세요.

오류 현상에서 문제 계층 추론하기

설정을 로드할 수 없다면 먼저 YAML 문법, 알 수 없는 필드, 지원하지 않는 노드 유형을 확인하세요. 설정은 로드되지만 노드가 나타나지 않는다면 구독 변환과 커널 호환성을 확인합니다. 노드는 나타나지만 즉시 인증에 실패한다면 비밀번호, 사용자 식별자, 암호화 방식, 프로토콜 세대를 확인하세요. TLS 핸드셰이크 실패는 시스템 시간, SNI, 인증서 이름, ALPN을 확인해야 합니다. QUIC 노드 시간 초과는 UDP 경로, 포트, MTU, 서버 수신을 확인하세요. 노드 테스트는 정상인데 앱이 작동하지 않는다면 규칙, 시스템 프록시, TUN, DNS를 점검하세요.

연결 문제는 한 번에 한 종류의 변수만 바꾸어야 합니다. 먼저 원본 구독을 보존하고 노드 하나를 선택해 규칙이 최소인 테스트 설정으로 프로토콜 연결을 확인합니다. 그다음 프록시 그룹을 복원하고, 이어서 규칙과 DNS를 복원한 뒤 마지막으로 TUN을 켜세요. 프로토콜, DNS, 규칙, 시스템 연결을 동시에 바꾸면 어떤 결과도 해석하기 어렵습니다. 흔한 오류의 추가 해결 방법은 자주 묻는 질문에서 확인할 수 있습니다.

최종 선택 제안

기존 SS 노드가 안정적이고 기기 리소스가 제한적이며 설정 요구가 단순하다면 SS를 계속 사용하는 것이 합리적입니다. 기존 VMess 설정이 장기간 안정적으로 작동한다면 프로토콜의 역사가 길다는 이유만으로 즉시 바꿀 필요는 없습니다. 새 조합형 설정을 만들 때는 전송과 TLS 매개변수를 확인하세요. 표준 TLS 연결과 명확한 인증 구조를 중시한다면 서버가 제공하는 Trojan을 선택할 수 있습니다. 최신 확장이 필요하고 클라이언트가 mihomo를 사용한다면 완전한 매개변수를 갖춘 VLESS를 사용할 수 있습니다.

네트워크에 패킷 손실이나 지터가 있고 UDP 경로가 정상이며 기기 리소스가 충분하다면 Hysteria2나 TUIC를 테스트할 수 있습니다. 둘 다 서버 설정과 분리해 독립적으로 선택해서는 안 되며 인증 필드를 수동으로 서로 바꿔서도 안 됩니다. 모바일에서는 백그라운드 복구와 배터리를 주요 지표로 보고, 라우터에서는 CPU·메모리·유지 관리 복잡도를 주요 지표로 보며, 데스크톱에서는 호환성을 확보한 뒤 전송 경험을 더 폭넓게 비교할 수 있습니다.

최종적으로 어떤 프로토콜을 선택하든 검증된 백업 노드 하나와 되돌릴 수 있는 설정 사본 하나를 보관하세요. 구독 업데이트 후에는 먼저 노드 유형과 프록시 그룹을 확인하고 그다음 규칙을 점검하세요. 클라이언트 업데이트 후에는 실제 커널을 확인해야 합니다. 장애가 발생하면 설정 파싱, 프로토콜 핸드셰이크, 규칙 선택, 시스템 연결 순서로 원인을 좁혀 가세요. 프로토콜 선택의 목표는 이름을 좇는 것이 아니라 현재 기기와 네트워크에 적합하고 검증과 유지 관리가 가능한 연결 구성을 세우는 것입니다.