Clash 프로토콜과 코어 선택

코어 계열과 클라이언트의 역할

Clash, Meta, mihomo의 관계

Clash는 YAML 설정으로 노드, 정책 그룹, 규칙을 지정하는 방식을 처음 정립했습니다. 앱의 연결을 하나의 라우팅 흐름으로 모은 뒤 규칙에 따라 직접 연결하거나 프록시를 거치거나 차단합니다. 원본 오픈 소스 프로젝트는 이미 보관 처리되었으며, 과거의 오픈 소스 코어와 Premium 브랜치도 기능이 완전히 같지는 않았습니다. 따라서 설정에 “Clash용”이라고 적혀 있어도 이름이 비슷한 모든 클라이언트에서 읽을 수 있다고 단정할 수 없고, 현재 사용되는 모든 프로토콜을 지원한다고 볼 수도 없습니다.

Clash.Meta는 기존 설정 체계를 바탕으로 프로토콜, DNS, 라우팅 기능을 확장했으며 이후 mihomo라는 이름으로 개발이 이어졌습니다. 네트워크 관련 글에서 Meta, Clash Meta, mihomo는 같은 코어의 발전 과정을 가리키는 경우가 많지만, 작성 시점에 따라 설명하는 동작이 다를 수 있습니다. 새로운 프로토콜이나 규칙 매개변수, DNS 필드를 사용할 때는 글 제목의 이름만 보고 호환성을 판단하지 말고 현재 실행 중인 코어가 실제로 지원하는지 확인하세요. 오래된 예시는 구조를 이해하는 데 도움이 되지만, 최신 필드 설명을 대신할 수는 없습니다.

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

클라이언트는 관리 인터페이스이고, 프로토콜 핸드셰이크, 도메인 이름 조회, 정책 선택, 연결 전달은 코어가 처리합니다. Clash Verge Rev는 데스크톱 설정 관리와 연결 확인 기능을 제공합니다. FlClash, Clash Meta for Android 등도 각기 다른 인터페이스와 시스템 연동 방식을 갖고 있습니다. 같은 코어라도 인터페이스에 따라 설정 이름, 설정 병합 순서, 권한 요청 방식이 다를 수 있습니다. 클라이언트가 실행된다고 해서 구독의 모든 노드가 코어에서 받아들여진 것은 아닙니다. 설정을 가져오는 데 성공했더라도 각 노드의 인증까지 완료됐다는 뜻은 아닙니다.

여러 플랫폼에서 사용할 클라이언트는 우선 추천하는 Clash Plus를 살펴본 뒤 필요한 기능에 따라 다른 클라이언트와 비교할 수 있습니다. Clash Plus가 여러 플랫폼을 지원한다고 해서 플랫폼별 구현까지 완전히 같은 것은 아니며, 제품 이름만으로 구체적인 코어를 추측해서도 안 됩니다. 데스크톱에서 규칙과 오버라이드를 관리해야 한다면 Clash Verge Rev도 검토해 보세요. 선택 가능한 클라이언트는 다운로드 페이지에서 확인할 수 있습니다. Clash for Windows와 ClashX Meta는 개발이 중단되었으므로, 이전 자료를 볼 때는 보관된 클라이언트와 계속 발전 중인 프로토콜 기능을 구분해야 합니다.

현재 실행 중인 코어부터 확인

클라이언트의 설정 또는 정보 페이지에서 코어 이름을 확인하세요. 화면에 클라이언트 정보만 표시된다면 시작 로그에서 코어 식별자를 찾아보세요. 안정 채널과 Alpha 채널도 구분해야 합니다. Alpha 채널은 대개 최신 변경 사항을 시험하는 용도이며, 연결 성능을 자동으로 높여 주는 설정이 아닙니다. 일상적인 사용에는 안정적인 환경을 유지하고, 해결된 문제를 확인하거나 특정 기능을 시험해야 할 때만 다른 채널을 사용하세요. 채널을 바꾸기 전에 설정을 백업하고, 구독 업데이트와 코어 채널 변경을 동시에 적용하지 마세요. 그러면 문제가 생겼을 때 원인을 파악하기 어려워집니다.

마이그레이션할 때는 먼저 설정이 파싱되는지 확인하고, 다음으로 노드가 연결되는지, 마지막으로 규칙이 예상대로 적용되는지 살펴보세요. 이 세 단계는 각각 필드 지원, 프로토콜 호환성, 라우팅 로직에 해당합니다. YAML 형식을 공유한다는 것은 구조가 비슷하다는 뜻일 뿐, 필드와 기본값, 확장 기능까지 모두 같다는 보장은 없습니다. 기존 설정이 스크립트, 특정 규칙 제공자의 동작, 클라이언트 전용 치환 기능에 의존한다면 대체 방법을 하나씩 확인하세요. 파싱 오류를 피하려고 알 수 없는 필드를 한꺼번에 삭제하지 마세요. 설정은 실행되지만 동작이 달라질 수 있습니다.

SS와 VMess: 기본 구성의 차이

간결한 구조의 Shadowsocks

Shadowsocks는 보통 SS라고 줄여 부르며, 클라이언트와 서버가 공유하는 키로 암호화 프록시를 구성합니다. 초기 설계는 프로토콜 오버헤드를 줄이고 배포 구조를 단순하게 만드는 데 중점을 두었으며, 모든 연결을 완전한 TLS 세션으로 감싸지는 않습니다. 사용자가 주로 입력하는 값은 서버 주소, 포트, 암호화 방식, 비밀번호입니다. 매개변수가 적다고 서로 바꿔 써도 되는 것은 아닙니다. 서버에서 사용하는 암호화 방식과 클라이언트 설정이 일치해야 합니다. 비밀번호가 같더라도 알고리즘을 잘못 선택하면 정상적으로 통신할 수 없습니다.

최신 배포 환경에서는 구형 스트림 암호화, AEAD 암호화, Shadowsocks 2022 계열을 구분해야 합니다. AEAD는 암호화와 메시지 인증을 결합해 수신 측에서 데이터 변경 여부를 확인할 수 있게 합니다. 2022 계열은 키와 세션 처리 방식도 조정했습니다. 이는 기존 노드에 임의로 선택하는 “강화 모드”가 아닙니다. 일부 방식은 정해진 길이의 인코딩된 키가 필요하므로 일반 비밀번호로 대체할 수 없습니다. 구독에 특정 암호화 방식이 표시되면 먼저 현재 코어의 지원 여부와 서버 설정을 확인하세요. 입력란을 통과시키려고 다른 이름으로 임의 변경하지 마세요.

SS는 TCP를 처리할 수 있으며, 양쪽에서 지원하고 활성화한 경우 UDP도 전달할 수 있습니다. 다만 TCP와 UDP는 서로 다른 경로로 처리됩니다. 웹 페이지는 열리지만 음성 연결이 실패한다면 UDP가 양 끝까지 연결되지 않았을 수 있습니다. 플러그인은 또 다른 확장 계층입니다. 일부 SS 구성은 별도 플러그인으로 트래픽을 감싸므로 클라이언트에서 같은 플러그인과 옵션을 지원해야 합니다. SS를 지원한다고 해서 어떤 플러그인 조합이든 지원하는 것은 아닙니다. 노드를 옮길 때 플러그인 필드가 빠지면 주소와 비밀번호가 맞아 보이는데도 연결 직후 끊길 수 있습니다.

VMess의 인증과 전송 조합

VMess는 V2Ray 생태계에서 나온 프로토콜로, 사용자 식별자와 인증, 데이터 전송을 중심으로 설계되었으며 UUID를 식별 정보로 사용하는 경우가 많습니다. SS와의 차이는 비밀번호를 UUID로 바꾸는 데 그치지 않고 인증과 데이터 캡슐화 방식도 다릅니다. VMess는 여러 전송 방식과 조합할 수 있으므로 같은 VMess 노드라도 하나는 TCP 직결, 다른 하나는 WebSocket과 TLS를 사용할 수 있습니다. 이에 따라 연결 과정, 인증서 요구 사항, 중간 장비와의 호환성이 달라집니다. 한 VMess 노드에서 얻은 테스트 결과를 모든 VMess 노드에 적용할 수는 없습니다.

VMess 노드를 확인할 때는 식별 정보, 전송 유형, TLS 활성화 여부, 경로와 서비스 이름 같은 추가 필드를 함께 확인해야 합니다. VMess 인증은 시간과도 관련이 있으므로 기기의 시스템 시각이 어긋나면 인증에 실패할 수 있습니다. 이런 오류가 발생하면 계정 정보를 확인하기 전에 자동 시간 설정부터 복구하세요. 오래된 인증 방식과 관련된 매개변수가 과거 문서에 등장할 수 있지만, 최신 설정에서는 일반적으로 현대적인 AEAD 방식을 사용합니다. 오래된 화면을 따라 하려고 과거 필드를 추가하지 마세요. 클라이언트가 특정 필드를 받아들인다고 해서 서버도 여전히 그 방식을 사용하는 것은 아닙니다.

기존 노드 중에서 선택하는 방법

일반적인 웹 검색과 파일 전송이 목적이고 서버 조건이 비슷하다면, SS는 설정 구조가 비교적 단순해 확인하기 쉽고 변수가 적은 편입니다. 기존 서비스에서 VMess를 사용하고 있고 설정이 완전하며 안정적으로 작동한다면, 프로토콜 이름이 오래됐다는 이유만으로 바꿀 필요는 없습니다. 암호화에 필요한 연산량은 기기의 프로세서와 알고리즘 구현에 따라서도 달라집니다. 하드웨어 가속을 지원하는 데스크톱과 저전력 라우터의 성능은 크게 다를 수 있습니다. 설정 필드 수만으로 성능을 추정하거나 프로토콜이 나온 순서로 품질을 판단하지 마세요.

실제 비교에서는 같은 기기와 접속 네트워크, 비슷한 서버 지역을 고정한 뒤 연결 설정, 지속 전송, UDP 앱을 각각 확인하세요. 두 노드의 회선이 다르면 프로토콜보다 회선 차이가 더 큰 영향을 줄 수 있습니다. 이름 해석, 인증, 전송 중 어느 단계에서 실패했는지 기록하면 암호화 방식을 계속 바꾸는 것보다 문제를 해결하는 데 도움이 됩니다. 매개변수가 확실하지 않으면 구독 제공자에게 확인하세요. 시행착오로 바꾼 설정을 구독 원본에 덮어쓰지 마세요. 다음 업데이트에서 원래 설정으로 돌아가 문제가 반복되는 것처럼 보일 수 있습니다.

Trojan과 VLESS: 인증과 전송 계층

Trojan은 TLS 연결 안에서 인증합니다

Trojan의 일반적인 구현은 TLS를 기반으로 하며, 보호된 연결 안에 프록시 인증과 요청을 담습니다. TLS는 전송 암호화와 서버 인증을 담당하고, Trojan은 사용자의 프록시 이용 권한을 확인합니다. 검증된 TLS 생태계를 활용하면서 프록시 요청 구조는 비교적 단순하게 유지하는 설계입니다. 노드에는 보통 서버, 포트, 비밀번호, 서버 이름이 포함됩니다. 필드가 적어 보여도 인증서, 도메인, 서버 수신 설정이 서로 맞아야 합니다. 그렇지 않으면 인증 단계에 도달하기도 전에 연결이 실패합니다.

서버 주소와 TLS 서버 이름은 서로 다른 개념입니다. 주소는 도메인이나 IP처럼 연결할 대상을 정합니다. 서버 이름은 보통 SNI 전송과 인증서 이름 확인에 사용되며, 서버에 사용할 사이트 설정을 알려 줍니다. 구독에 별도의 서버 이름이 제공된다면 주소란의 IP로 임의 변경하지 말고 해당 값을 유지하세요. 인증서 만료, 인증서 체인 누락, 이름 불일치는 서버나 올바른 설정 위치에서 해결해야 합니다. 일반적인 호환성 대책으로 인증서 검증을 끄면 안 됩니다.

Trojan이 다른 프로토콜보다 빠르다고 보장되지는 않습니다. 새 연결을 맺을 때는 하위 연결과 TLS 핸드셰이크를 완료해야 하며, 실제 소요 시간은 왕복 시간, 세션 복구, 클라이언트의 연결 재사용 방식에 영향을 받습니다. 일반적인 Trojan 구성은 TCP 터널로 프록시 데이터를 전달합니다. UDP 전달은 양쪽 구현과 설정에서 지원하는지 별도로 확인해야 합니다. 앱이 UDP를 사용한다고 해서 노드의 외부 전송까지 UDP라고 단정할 수 없습니다. 프로토콜 이름이 가리키는 것은 프록시 계층이며, 실제 네트워크 동작에는 바깥쪽 전송 방식도 영향을 줍니다.

VLESS는 경량 인증과 외부 보안을 분리합니다

VLESS는 V2Ray 관련 생태계에서 나온 프로토콜로, 간결한 식별 정보와 요청 구조를 사용합니다. SS처럼 독립적인 콘텐츠 암호화를 제공하지는 않으므로 보통 TLS, REALITY 같은 외부 계층으로 전송을 보호합니다. VLESS를 “암호화가 없으니 더 빠르다”고만 보면 전체 연결 구성을 놓치게 됩니다. 실제 노드에는 인증, 전송 캡슐화, 암호화 핸드셰이크, 기타 트래픽 처리가 포함될 수 있습니다. 설정의 유형 이름만 비교하지 말고 VLESS와 TLS, 특정 전송 방식의 조합처럼 전체 구성을 비교하세요.

REALITY는 특정 서버 배포와 함께 사용하는 보안 방식이지, 아무 VLESS 노드에나 추가할 수 있는 옵션이 아닙니다. 사용하려면 올바른 공개 키, 짧은 ID, 서버 이름, 관련 핸드셰이크 매개변수가 필요합니다. 구체적인 필드는 클라이언트 구현에 따라 다를 수 있습니다. 공개 키 오류와 UUID 오류는 서로 다른 단계의 문제입니다. 공개 키가 틀리면 보안 핸드셰이크가 실패할 수 있고, UUID가 틀리면 이후 인증 단계에서 실패할 수 있습니다. 구독에 값이 빠져 있어도 다른 노드의 필드를 가져와 조합하지 마세요. 모든 값은 같은 서버 설정에서 제공되어야 합니다.

VLESS의 flow도 범용 속도 향상 단계가 아닙니다. 서버와 맞는 트래픽 처리 방식을 선택하는 필드이며, 해당 보안 계층과 전송 조건을 충족해야 합니다. WebSocket 경로와 gRPC 서비스 이름도 실제 라우팅에 쓰이며 단순한 메모가 아닙니다. 특정 조합만 지원하는 노드에서 전송 유형을 바꾼다고 서버 설정까지 자동으로 바뀌지는 않습니다. 변경하기 전에 서버가 실제로 어떤 접속 방식을 제공하는지 확인하세요. 클라이언트의 드롭다운에서 더 최신처럼 보이는 이름을 선택해도 대개 프로토콜 불일치만 발생합니다.

인증서 오류와 전송 오류를 나눠서 확인

TLS 오류가 발생하면 먼저 시스템 시간, 인증서 유효성, 서버 이름을 확인하고 기기의 인증서 환경에도 문제가 없는지 살펴보세요. TLS 연결은 성공했지만 이후 끊긴다면 비밀번호, UUID, 경로, 요청 헤더, 서비스 이름을 확인하세요. 로그의 “연결이 재설정됨”은 상대방이나 경로상의 장비가 연결을 종료했다는 뜻일 뿐, 비밀번호가 틀렸다는 증거는 아닙니다. 실패 단계에 따라 판단하고 필요하면 서버 관리자에게 해당 접속 로그를 확인해 달라고 요청하세요. 클라이언트에서 관련 없는 보안 옵션을 계속 바꾸지 마세요.

신뢰할 수 있는 TLS 구성을 이미 사용하고 있고 설정을 단순하게 유지하고 싶다면 Trojan을 검토할 수 있습니다. VLESS 관련 전송 조합이나 트래픽 처리 기능이 필요한 환경이라면 해당 설정을 지원하는 VLESS 노드를 선택하세요. 두 프로토콜 모두 완전하고 신뢰할 수 있는 서버 매개변수가 필요합니다. 구독만 가져오는 사용자는 제공자가 만든 설정을 우선 유지하고 클라이언트가 전체 조합을 지원하는지 확인하세요. 필드 이름만 이해하려면 용어집을 참고하면 됩니다. 일상적인 사용을 위해 노드 전체를 직접 다시 만들 필요는 없습니다.

Hysteria2와 TUIC: QUIC 기반 전송

UDP 기반 전송을 사용하는 이유

QUIC은 UDP 위에서 연결 관리, 보안 핸드셰이크, 신뢰성 있는 전송, 다중 스트림 기능을 구현합니다. TCP 데이터를 단순히 UDP 패킷으로 바꾸는 것이 아닙니다. 전송 계층이 맡던 기능 일부를 사용자 공간 프로토콜 구현에 포함합니다. 여러 스트림을 사용하면 한 스트림의 패킷 손실로 다른 데이터 전달까지 막히는 현상을 줄일 수 있지만, 혼잡 제어와 경로 용량은 여전히 공유할 수 있습니다. Hysteria2와 TUIC은 QUIC을 바탕으로 프록시 프로토콜을 구성해 특정 네트워크 환경에서 더 유연하게 전송하려는 방식입니다. 모든 네트워크에서 TCP보다 빠르다고 보장하지는 않습니다.

이 두 유형의 노드를 사용하기 전에 접속 네트워크에서 해당 UDP 통신이 허용되는지 확인하세요. 일부 네트워크는 UDP에 별도의 연결 시간 제한, 속도 제한, 전달 정책을 적용합니다. 웹에 직접 연결할 수 있다고 해서 QUIC 프록시도 작동하는 것은 아닙니다. 노드가 핸드셰이크 단계에서 계속 멈춘다면 인증 정보를 보기 전에 UDP 연결 가능 여부, 포트, 서버의 수신 상태를 확인하세요. 모든 문제를 비밀번호 탓으로 돌리면 시간만 낭비하게 됩니다. 같은 서버의 TCP 노드가 연결되더라도 다른 전송 경로가 작동한다는 뜻일 뿐, UDP 접속 지점까지 정상이라는 뜻은 아닙니다.

Hysteria2의 대역폭과 혼잡 제어

Hysteria2는 왕복 시간이 길고 패킷 손실이 있는 네트워크를 위해 QUIC 기반 전송 방식을 제공합니다. 혼잡 제어 동작은 대역폭 설정과 관련될 수 있으며, 서버 정책도 영향을 줍니다. 설정의 업로드·다운로드 매개변수는 전송 제어에 사용하는 입력값이지, 대역폭을 구매하거나 회선 제한을 해제하는 버튼이 아닙니다. 실제 접속 성능보다 훨씬 높은 값을 입력하면 대기열과 패킷 손실이 늘고 다른 앱의 응답이 느려질 수 있습니다. 먼저 로컬 네트워크 성능과 서버 안내에 맞춰 설정하고, 재현 가능한 조건에서 결과를 확인하세요.

Hysteria2와 구형 Hysteria는 서로 호환되지 않는 프로토콜입니다. 노드 이름에 Hysteria가 포함되어 있다고 해서 유형 필드만 바꾸면 마이그레이션할 수 있는 것은 아닙니다. 인증, 난독화, 포트 관련 설정을 양쪽 구현에 맞게 다시 확인해야 합니다. 포트 호핑을 사용하려면 서버와 중간 전달 장비 모두 지정한 범위를 지원해야 합니다. 클라이언트에 여러 포트를 입력하는 것만으로 서버 접속 지점이 생기지는 않습니다. 가정용 라우터나 통신망의 연결 추적 방식에 따라 같은 노드도 네트워크별로 다르게 동작할 수 있습니다.

TUIC의 인증과 UDP 전달 방식

TUIC도 QUIC 기반으로, 신뢰성 있는 스트림 전송과 UDP 전달을 하나의 연결 체계에 포함합니다. 프로토콜 세대에 따라 인증 매개변수와 동작이 다를 수 있으므로 구독에 지정된 유형, 사용자 ID, 비밀번호, 구현 요구 사항을 한꺼번에 맞춰야 합니다. 클라이언트에 TUIC 옵션이 있다고 해서 모든 구형 설정까지 지원하는 것은 아닙니다. 특히 이전 공유 링크를 새 코어에 가져올 때는 이해하지 못하는 인증 필드를 지우기보다 노드 제공자에게 프로토콜 세대와 권장 클라이언트를 확인하는 편이 안전합니다.

TUIC의 UDP 전달 방식에 따라 데이터 전달 방법과 손실 처리가 달라집니다. 네이티브 데이터그램과 신뢰성 있는 스트림을 통한 전송의 차이는 속도만이 아닙니다. 전자는 원래 UDP의 패킷 손실 특성에 가깝고, 후자는 이전 데이터 재전송이 적시성에 영향을 줄 수 있습니다. 혼잡 제어 옵션도 구현이 지원하는 범위에 맞춰야 합니다. 온라인 게임, 음성 통화, 일반 다운로드는 패킷 손실과 재전송을 견디는 정도가 다르므로 실제 앱으로 확인하세요. 다른 회선의 설정을 보고 더 공격적으로 보이는 모드를 고르지 마세요.

QUIC은 연결 마이그레이션 같은 기능을 지원하지만, 프로토콜에 기능이 있다고 해서 모든 클라이언트가 네트워크를 바꿔도 서비스를 계속 유지하는 것은 아닙니다. 시스템 네트워크 확장 기능, 서버 정책, 앱 시간 제한 등으로 세션이 끊길 수 있습니다. 무선 네트워크와 셀룰러 네트워크를 자주 오간다면 실제 전환 테스트도 선택 기준에 포함하세요. Hysteria2나 TUIC을 선택할 때 안정적으로 연결되는 TCP 계열 예비 노드를 하나 남겨 두는 것도 유용합니다. 접속 환경이 바뀌면 먼저 연결을 복구한 뒤 UDP 경로가 제한되는지 확인할 수 있습니다.

연결 속도, 처리량, 리소스 사용량

‘빠르다’를 단계별로 나눠 보기

노드 테스트에서 혼동하기 쉬운 항목은 연결 시간, 첫 응답, 지속 처리량입니다. 연결 시간에는 주소 조회, 하위 계층 핸드셰이크, 인증이 포함됩니다. 첫 응답에는 대상 서비스 처리와 응답 경로도 영향을 줍니다. 지속 처리량은 혼잡 제어, 경로 용량, 서버 리소스에 좌우됩니다. 클라이언트에서 URL 테스트를 한 번 실행해 얻은 값은 특정 대상과 테스트 방법에서 일부 과정만 반영할 수 있습니다. 수치가 낮다고 다운로드가 반드시 빨라지는 것은 아니며, 동영상·음성·장시간 연결이 더 안정적이라는 뜻도 아닙니다. 먼저 개선하려는 사용 경험을 정하세요.

SS의 일반적인 구성은 완전한 외부 TLS 핸드셰이크를 필수로 하지 않습니다. Trojan과 VLESS의 실제 핸드셰이크는 보안 계층과 전송 방식의 조합에 따라 달라지고, Hysteria2와 TUIC은 QUIC의 연결 방식을 사용합니다. 세션 복구와 연결 재사용에 따라 핸드셰이크 과정이 달라질 수 있으므로, 같은 노드에서 두 번째 접속이 더 원활하다고 해서 네트워크가 갑자기 좋아진 것은 아닐 수 있습니다. 비교할 때는 새 연결과 기존 연결의 사용 경험을 나누어 보세요. 한 노드는 이미 준비된 상태이고 다른 노드는 방금 켠 상태라면 바로 결론 내리지 마세요.

처리량의 한계는 프로토콜 밖에 있을 때가 많습니다

지속 다운로드 속도는 로컬 무선 신호, 서버의 외부 회선, 대상 사이트, 기기 프로세서, 중간 네트워크의 영향을 받을 수 있습니다. 패킷 손실이 많은 경로에서는 혼잡 제어가 결과에 큰 차이를 만들 수 있고, 왕복 시간이 짧고 안정적인 경로에서는 추가 캡슐화와 구현 효율이 더 잘 드러날 수 있습니다. 특정 프로토콜에서 한 번 기록한 최고 속도를 일반적인 성능으로 볼 수 없습니다. 노드를 바꾸면서 서버 지역과 통신 회선까지 달라졌다면 프로토콜의 영향만 따로 판단할 수 없습니다. 해당 테스트 조건에서는 지금의 노드 조합이 더 적합했다고 볼 수 있을 뿐입니다.

다중화는 연결을 반복해서 만드는 비용을 줄일 수 있지만 여러 서비스가 서로 영향을 주는 방식도 바뀝니다. 여러 논리 연결을 하나의 외부 연결에 모으면 핸드셰이크 횟수는 줄 수 있지만 대기열과 장애 영향이 한곳에 집중될 수도 있습니다. 개선 여부는 외부 프로토콜과 구현을 확인해야 합니다. 서버 측 지원 없이 다중화를 임의로 활성화하지 말고, 이름이 같은 설정이 클라이언트마다 같은 기능이라고 가정하지 마세요. 웹, 멀티미디어, 파일 전송에서 각각 검증하는 편이 설정 설명의 “최적화”라는 말만 보는 것보다 효과적입니다.

프로세서, 메모리, 백그라운드 작업

리소스 사용량은 암호화만으로 결정되지 않습니다. 사용자 공간 프로토콜 처리, 패킷 캡슐화, 규칙 조회, DNS 캐시, 로그 기록, 연결 통계도 리소스를 사용합니다. 저전력 기기에서는 암호화의 하드웨어 가속 여부와 코어 구현의 효율이 프로토콜 필드 몇 개의 차이보다 더 중요할 수 있습니다. 라우터에서는 동시 연결 수와 메모리 용량도 고려해야 합니다. 데스크톱에서 문제없이 처리되는 설정이 소형 기기에서는 프로세서를 계속 바쁘게 만들어 처리량을 떨어뜨릴 수 있습니다. 이는 서버 회선이 느려진 것과는 다른 문제입니다.

리소스를 관찰할 때는 같은 부하를 유지하세요. 먼저 유휴 상태에서 백그라운드 사용량을 기록하고, 일정한 수의 앱을 실행한 뒤 지속 전송을 시험합니다. 디버그 로그는 기록과 형식 처리에 추가 비용이 들므로 문제 해결이 끝나면 로그 수준을 원래대로 복구하세요. 연결 수는 계속 늘어나는데 실제 작업은 멈췄다면 프로토콜이 “메모리를 많이 쓰는 것”이라고 단정하지 말고 앱의 반복 재시도, DNS 실패, 정책 순환을 확인하세요. 캐시나 연결 수명 때문에 리소스가 늘어나는 경우도 있으므로 짧은 시간의 화면만으로 장기 누수를 판단할 수 없습니다.

정책 그룹도 테스트 결과에 영향을 줍니다. url-test는 지정한 탐지 결과를 바탕으로 노드를 자동 선택하고, fallback은 순서대로 사용 가능한 항목을 선택하는 데 중점을 둡니다. load-balance는 연결마다 서로 다른 노드를 선택할 수 있습니다. 특정 프로토콜을 테스트할 때는 정책 그룹이 백그라운드에서 출구 노드를 바꾸지 않도록 노드를 하나로 고정하세요. 각 정책의 차이는 정책 그룹 유형 자세히 보기에서 확인할 수 있습니다. 정책 그룹은 노드를 선택할 뿐, 노드 자체의 프로토콜 구현을 바꾸지는 않습니다.

결론은 “이 기기와 현재 무선 네트워크에서는 이 노드가 더 안정적이었다”처럼 조건을 포함해 작성하세요. “특정 프로토콜이 항상 가장 빠르다”고 일반화하면 안 됩니다. 네트워크나 기기가 바뀌면 이전 결과를 다시 확인해야 합니다. 같은 대상에서 모든 프로토콜이 실패한다면 대상 서비스 자체와 DNS, 라우팅 규칙도 고려하세요. 문제를 구체적인 단계로 나누면 프로토콜 이름을 좇아 클라이언트만 바꾸고 실제 연결 제한 원인은 그대로 두는 일을 피할 수 있습니다.

모바일 배터리와 시스템 트래픽 처리 범위

배터리 소모는 전체 작업 흐름에서 발생합니다

모바일 기기의 배터리 소모는 화면, 무선 통신, 프로세서, 백그라운드 스케줄링, 프록시 작업이 함께 결정합니다. 프로토콜 암호화는 그중 한 요소일 뿐입니다. 셀룰러 통신을 계속 주고받거나 기기를 자주 깨우면 무선 장치가 더 활성 상태를 유지할 수 있습니다. 신호가 약하거나 재전송이 반복되고 앱이 계속 재시도해도 전력 소모가 늘어납니다. 따라서 SS, Trojan, QUIC 계열의 배터리 소모 순위를 고정할 수는 없습니다. 같은 프로토콜도 무선 네트워크와 셀룰러 네트워크에서, 같은 장소라도 신호 상태에 따라 결과가 달라질 수 있습니다.

연결을 유지하는 것과 반복해서 다시 연결하는 것은 비용이 다릅니다. 장시간 연결하면 인증을 반복하는 횟수를 줄일 수 있지만 하트비트가 너무 잦으면 백그라운드 활동이 늘어납니다. 반대로 너무 뜸하면 중간 장비가 세션을 해제해 앱을 다시 사용할 때 연결을 새로 만들 수 있습니다. QUIC, TCP, 프록시 구현마다 연결 유지 방식이 다르므로 다른 클라이언트의 하트비트 간격을 그대로 적용하지 마세요. 먼저 서버와 클라이언트의 적절한 기본값을 사용하고, 유휴 상태에서 연결이 끊기거나 백그라운드에서 자주 깨어나는 것이 확인된 경우에만 관련 설정을 조정하세요.

시스템 프록시가 모든 트래픽을 처리하는 것은 아닙니다

데스크톱 시스템 프록시는 해당 설정을 따르는 앱에 주로 적용되며 모든 UDP 트래픽이나 앱 자체 네트워크 스택을 자동으로 처리하지 않습니다. TUN 모드는 가상 네트워크 인터페이스에서 트래픽을 받아 코어로 전달하므로 대체로 더 넓은 범위를 다루지만, 라우팅, DNS, 권한 등 추가 조건이 필요합니다. 이는 트래픽 진입 방식이지 프록시 프로토콜이 아닙니다. 시스템 프록시를 TUN으로 바꿔도 VMess가 다른 프로토콜로 바뀌거나 서버 비밀번호 오류가 해결되지는 않습니다. 어떤 연결이 프록시 규칙 처리 과정에 들어오는지만 달라집니다.

Android 클라이언트는 보통 시스템 VPN 인터페이스로 기기 트래픽을 받으며, 백그라운드 연결 유지 여부는 제조사의 배터리 정책, 백그라운드 권한, 앱 절전 설정에도 영향을 받습니다. 화면을 끄면 연결이 끊기는 경우 먼저 시스템이 클라이언트의 백그라운드 실행을 제한하는지 확인하고, 특정 노드의 유휴 세션만 회수된 것은 아닌지 살펴보세요. 백그라운드 실행을 허용하면 연결 유지에 도움이 되지만 기기가 활성 상태를 유지하는 시간이 늘 수도 있습니다. 한 번에 하나만 바꾸고 실제 대기 상태에서 효과를 확인하세요. 모든 배터리 제한을 해제할 필요는 없습니다.

iOS 클라이언트는 시스템 네트워크 확장 기능으로 작동하며, 메모리와 백그라운드 동작은 시스템이 관리합니다. 클라이언트를 선택할 때는 우선 추천하는 Clash Plus를 살펴보고 실제 구독 지원 여부와 기기 사용 방식에 맞는지 평가하세요. 설치 방법은 iOS 클라이언트 섹션에서 확인할 수 있습니다. 데스크톱의 코어 전환 방법, 프로세스 관리 방식, 로컬 파일 경로를 모바일에 그대로 적용하지 마세요. 시스템이 네트워크 확장을 종료한 경우, 앱에 연결 끊김이 표시되는 경우, 노드 핸드셰이크가 실패한 경우는 서로 다른 계층의 문제이므로 시스템 상태와 클라이언트 로그를 각각 확인해야 합니다.

정책 탐지와 로그도 배터리를 사용합니다

정책 그룹의 주기적인 탐지는 요청을 직접 보냅니다. 설정에 상태 확인 항목이 많이 있으면 웹을 보지 않을 때도 기기에서 네트워크 활동이 이어질 수 있습니다. 탐지 간격을 줄인다고 서비스가 반드시 안정되는 것은 아니며, 오히려 기기를 깨우고 요청을 보내는 비용이 커질 수 있습니다. 실제 필요한 확인 대상과 주기만 설정하고 백그라운드 확인과 모든 노드 수동 테스트를 구분하세요. 구독과 규칙 데이터도 적절한 주기로 업데이트해 모바일 네트워크에서 큰 파일을 반복해서 받지 않도록 합니다.

규칙 기반 분할 라우팅을 사용하면 프록시가 필요 없는 트래픽은 직접 연결해 불필요한 프록시 캡슐화를 줄일 수 있지만, 규칙이 정확해야 효과가 있습니다. 전역 프록시로 더 많은 연결을 노드에 보낸다고 모든 앱이 개선되는 것은 아닙니다. 직접 연결 모드에서도 클라이언트의 백그라운드 작업이 완전히 중단되는 것은 아닙니다. 앱 제외 설정, 로컬 네트워크 접근, DNS 라우팅을 함께 맞춰 트래픽은 한 경로로 보내면서 이름 조회는 사용할 수 없는 다른 경로로 보내는 상황을 피하세요. 특정 앱이 프록시를 켰을 때만 이상하다면 먼저 연결이 코어에 들어오는지 확인한 뒤 어떤 규칙이 적용됐는지 살펴보세요.

모바일에서 클라이언트를 선택할 때는 구독 호환성을 먼저 확인하고, 백그라운드 연결과 네트워크 전환 후 복구를 검증한 뒤 배터리 사용량을 살펴보세요. 음성 통화나 게임을 자주 한다면 웹 페이지 접속뿐 아니라 UDP 사용도 확인해야 합니다. 현재 셀룰러 네트워크에서 TCP 계열 노드가 안정적이라면 “새 프로토콜”이라는 이유만으로 QUIC으로 바꿀 필요는 없습니다. 반대로 약한 네트워크에서 특정 QUIC 노드가 더 적합하다면 백그라운드 전력 소모가 높아 보인다는 이유만으로 바로 제외하지 말고 실제 사용 경험을 기준으로 판단하세요.

구독 형식과 설정 호환성

링크, 노드 목록, 전체 설정

구독 URL은 내용을 가져오는 주소이지, 그 자체가 콘텐츠 형식은 아닙니다. 서버는 요청 방식에 따라 노드 공유 링크, 인코딩된 링크 목록, Clash 스타일 YAML, 다른 클라이언트 전용 형식을 반환할 수 있습니다. 한 앱에서 가져올 수 있는 주소라고 해서 다른 앱에 전달되는 내용까지 같다는 뜻은 아닙니다. 가져오기에 실패하면 먼저 제공자가 현재 클라이언트에 맞는 주소를 제공하는지 확인한 뒤 반환된 내용이 정상적인 설정인지 살펴보세요. 로그인 페이지, 오류 메시지, 트래픽 만료 안내가 구독 내용으로 다운로드될 수도 있습니다.

노드 공유 링크는 노드 하나를 설명하고, 노드 목록은 선택 가능한 서버를 제공합니다. 전체 설정에는 정책 그룹, 규칙, DNS, 리스너 설정도 포함될 수 있습니다. 세 형식은 서로 대체할 수 없습니다. 노드만 가져오면 클라이언트가 라우팅 구조를 생성하거나 보완하는 경우가 많고, 전체 설정을 가져오면 기존 설정이 덮어써질 수 있습니다. 변환 서비스는 표현 형식을 바꿀 수는 있지만 대상 코어에 새 프로토콜 기능을 추가하지는 않습니다. 대상에서 특정 전송 조합을 지원하지 않는다면 변환 후 올바른 YAML이 만들어져도 노드는 작동하지 않을 수 있습니다.

변환 과정에서 누락되기 쉬운 필드

기본 주소와 포트는 대체로 유지되지만 TLS 서버 이름, WebSocket 요청 헤더, gRPC 서비스 이름, REALITY 매개변수, 트래픽 처리 방식, UDP 관련 설정 같은 복잡한 옵션은 변환 중에 빠지기 쉽습니다. 원래 클라이언트에서는 작동했는데 변환 후 실패한다면 표시 이름만 비교하지 말고 같은 노드의 민감 정보를 가린 매개변수를 비교하세요. 일부 변환기는 알 수 없는 필드를 걸러 내고, 다른 변환기는 대상 코어가 인식하지 못하는 위치에 필드를 넣을 수 있습니다. 어느 쪽이든 가져오기는 성공한 것처럼 보이지만 연결되지 않을 수 있습니다.

구독 정보를 외부 변환 서비스에 맡기면 접근 정보가 노출될 수 있습니다. 구독 URL에는 계정을 식별할 수 있는 경로나 매개변수가 포함되는 경우가 많아 전체 주소를 올리면 상대방이 같은 구독 내용에 접근할 수 있습니다. 우선 제공자가 직접 생성한 호환 형식을 사용하거나 신뢰할 수 있는 환경에서 변환하세요. 다른 사람에게 도움을 요청할 때는 주소의 인증 정보와 노드 비밀번호, UUID 같은 식별 정보를 지우고 문제 해결에 필요한 필드 구조만 남기세요. 노드 이름과 서버 도메인도 개인 사용 정보를 드러낼 수 있으므로 필요에 따라 가려야 합니다.

구독 원문과 로컬 오버라이드를 구분

클라이언트는 구독 내용에 로컬 오버라이드, 전역 설정, 설정 보강을 결합해 코어의 실행 설정을 만들 수 있습니다. 구독 캐시를 직접 수정하면 다음 업데이트에서 변경 사항이 덮어써지는 경우가 많습니다. DNS, 규칙, 정책을 장기간 유지하려면 클라이언트가 공식 지원하는 오버라이드 기능을 사용하고 병합 방식을 확인하세요. 목록은 추가될 수도 있고 전체 교체될 수도 있습니다. 특히 규칙은 순서대로 매칭되므로 최종 규칙 뒤에 추가한 항목은 적용되지 않을 수 있습니다. 텍스트에 규칙이 보인다고 해서 실제로 적용된다고 단정하지 마세요.

아래는 규칙 순서를 이해하기 위한 mihomo 설정 예시이며 노드 정의는 포함하지 않습니다. 먼저 지정 도메인에 도메인 접미사 규칙을 적용하고, 사설 주소는 직접 연결한 뒤, 마지막에 기본 정책을 적용합니다. 여기서 PROXY는 완성된 설정에 실제 노드나 정책 그룹으로 정의되어 있어야 합니다. no-resolve는 이 주소 규칙을 위해 별도의 도메인 조회를 하지 않도록 하는 옵션입니다. 설정 전체의 DNS 기능을 끄는 것이 아니며, 모든 단계에서 이름 조회가 발생하지 않는다고 보장하지도 않습니다.

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,private,DIRECT,no-resolve
  - MATCH,PROXY

YAML은 들여쓰기와 데이터 유형에 규칙이 있으므로 공백으로 들여쓰고 계층에 탭 문자를 섞지 않는 것이 좋습니다. 특수 문자가 포함된 값은 올바르게 따옴표로 묶어야 하며 필드 이름도 코어 요구 사항에 맞아야 합니다. 파싱 오류에 표시된 줄의 이전 줄이 실제 원인일 수도 있습니다. 예를 들어 따옴표가 닫히지 않았거나 목록 표시가 빠졌을 수 있습니다. 네트워크를 테스트하기 전에 구문부터 수정해 설정이 로드되지 않은 상태에서 노드만 계속 바꾸는 일을 피하세요. 클라이언트가 이전 실행 설정을 유지한다면 화면에서 연결되는 것처럼 보여도 새 설정이 적용됐다는 뜻은 아닙니다.

설정을 업데이트하기 전에 복구 가능한 사본을 남기고, 업데이트 후에는 파싱 성공 여부와 정책 그룹 참조, 주요 규칙을 확인하세요. 모든 노드가 한꺼번에 사라지면 먼저 구독 내용과 필터 조건을 살펴보세요. 특정 프로토콜만 오류가 나면 관련 필드와 코어 지원 여부를 확인하세요. 노드는 연결되지만 트래픽이 잘못된 출구로 나간다면 규칙 적용과 오버라이드 결과를 확인하세요. 형식, 프로토콜, 라우팅을 세 계층으로 나눠 확인하면 모든 문제를 “구독 오류”로 뭉뚱그리는 것보다 정확하고 제공자에게 문의할 때도 재확인을 줄일 수 있습니다.

사용 환경에 맞는 선택과 문제 해결

관리하기 쉬운 클라이언트와 완전한 설정부터 선택

일반 사용자는 먼저 설정이 완전하고 업데이트 방법이 명확하며 기기에서 안정적으로 실행되는 클라이언트를 선택해야 합니다. 우선 추천하는 Clash Plus를 살펴본 뒤 데스크톱 관리, 모바일 백그라운드 실행, Linux 사용 여부에 따라 다른 클라이언트를 선택하세요. Clash Verge Rev는 데스크톱에서 설정과 연결을 확인하려는 사용자에게 적합합니다. FlClash는 여러 플랫폼을 지원하며 Clash Meta for Android는 Android용 선택지를 제공합니다. Surfboard는 가져오기 형식과 기능을 별도로 확인해야 합니다. 다운로드 페이지에 함께 소개되어 있다고 해서 모든 Clash YAML 확장을 지원한다고 볼 수는 없습니다.

서버와 라우터에서는 mihomo 코어를 직접 사용할 수 있지만 서비스 시작, 파일 권한, 라우팅, 설정 업데이트를 직접 관리해야 합니다. 데스크톱 사용자는 업무와 무관한 프로세스 관리에 시간을 쓰지 않도록 인터페이스가 있는 클라이언트를 쓰는 편이 보통 더 적합합니다. 설치 전에 운영체제와 프로세서 아키텍처를 확인하고, 설치 후 코어가 지원하는 기능을 살펴보세요. 클라이언트 선택과 프로토콜 선택은 별개의 문제입니다. 전자는 관리와 시스템 연동 경험을, 후자는 노드의 통신 방식을 결정합니다. 현재 지원되는 프로토콜 하나를 바꾸려고 전체 환경을 다시 설치할 필요는 없습니다.

사용 목적에 따라 테스트 항목 선택

일상적인 웹 검색과 업무에서는 첫 접속 시간, 연결 안정성, 규칙 정확성을 우선 확인하세요. 안정적으로 작동하는 SS, VMess, Trojan, VLESS 노드는 모두 사용할 수 있습니다. 대용량 파일을 전송할 때는 지속 처리량, 프로세서 부하, 다른 서비스가 대기열의 영향을 받는지 살펴보세요. 왕복 시간이 길거나 패킷 손실이 있는 경로에서는 Hysteria2와 TUIC을 검토할 수 있지만, UDP 경로가 안정적이어야 합니다. 회의, 음성 통화, 게임은 실제 앱의 데이터 흐름을 확인해야 하며 브라우저 페이지가 열리는지만으로 정상 여부를 판단할 수 없습니다.

로컬 네트워크 기기를 자주 사용하는 환경에서는 사설 주소, 로컬 도메인, 가상 네트워크 인터페이스의 라우팅도 확인해야 합니다. TUN을 사용한다면 프린터, 공유 폴더, 로컬 서비스에 예상대로 접근할 수 있는지 살펴보세요. 원격 근무용 소프트웨어는 자체 프록시 설정과 인증서 요구 사항이 있을 수 있으므로 앱 문서에 따라 설정해야 합니다. 이런 호환성 문제는 트래픽 처리 범위나 라우팅과 관련된 경우가 많아 노드 프로토콜을 바꿀 필요가 없을 수 있습니다. 프로토콜을 무작정 바꾸면 연결 동작은 잠시 달라져도 라우팅 충돌은 해결되지 않을 수 있습니다.

실패 단계별로 범위를 좁혀 문제 해결

문제 해결은 기기 자체부터 시작하세요. 현재 설정이 활성화되었는지, 코어가 실행 중인지, 앱의 트래픽이 프록시 입력 경로로 들어오는지 확인합니다. 이어서 DNS가 예상한 주소를 반환하는지, 서버 포트에 연결할 수 있는지 살펴본 뒤 보안 핸드셰이크와 인증을 확인하세요. 마지막으로 대상 연결과 규칙 적용을 점검합니다. 코어에 들어온 연결만 로그나 연결 페이지에서 라우팅을 확인할 수 있습니다. 앱 연결이 전혀 보이지 않는다면 노드 비밀번호를 바꾸기 전에 시스템 프록시, 앱 설정, TUN 처리 여부부터 확인하세요.

같은 구독의 모든 노드가 동시에 실패하면 기기 네트워크, 설정 로드, 구독 상태, 공통 DNS 설정을 먼저 확인하세요. 노드 하나만 실패하면 서버와 매개변수를 살펴보고, 특정 프로토콜만 실패하면 코어 지원 여부와 해당 전송 경로를 확인하세요. 노드는 연결되지만 일부 사이트만 실패한다면 대상 DNS, 규칙, 서버 출구를 살펴보세요. 이 순서로 범위를 좁히면 여러 매개변수를 동시에 바꾸는 일을 피할 수 있습니다. 기기 관련 문제는 자주 묻는 질문을, 처음 연결을 확인하는 방법은 시스템 프록시 설정을 참고하세요.

제공자에게 문의할 때는 기기의 운영체제, 클라이언트, 코어 이름, 프로토콜 유형, 실패 단계와 함께 민감 정보를 가린 관련 로그를 전달하세요. “안 됩니다”라고만 하기보다 오류 원문을 보존하는 편이 문제 해결에 도움이 됩니다. 구독 전체나 인증 정보를 보내지 마세요. 노드 시간 초과의 구체적인 점검 방법은 가까운 단계부터 확인하는 문제 해결 순서를 참고하세요. 프로토콜을 비교 중이라면 테스트한 접속 네트워크와 노드를 고정했는지도 기록해 제공자가 같은 조건에서 재현할 수 있도록 하세요.