Clash 프로토콜·코어 기술 가이드

1. 프로토콜, 전송 방식, 클라이언트를 구분하기

이름마다 답하는 질문이 다릅니다

설정을 선택할 때는 먼저 연결을 세 부분으로 나눠 살펴보세요. Shadowsocks, VMess, Trojan, VLESS, Hysteria 2, TUIC은 프로토콜 이름으로, 클라이언트와 서버가 인증하고 요청을 전달하는 방식 및 필요한 매개변수를 정합니다. TCP, UDP, TLS, WebSocket, HTTP/2, gRPC, QUIC은 연결에 사용하는 전송 또는 캡슐화 방식을 나타냅니다. 하나의 프로토콜도 여러 전송 방식과 조합할 수 있지만, 모든 코어가 모든 조합을 지원하는 것은 아닙니다. Clash Plus 같은 클라이언트는 설정 가져오기와 연결 제어, 시스템 인터페이스를 제공합니다. 실제로 설정을 해석하고 연결을 만드는 것은 클라이언트가 사용하는 코어 또는 구현체입니다. 앱 이름만으로 특정 프로토콜의 지원 여부를 판단할 수는 없습니다.

예를 들어 VLESS 공유 링크를 발견했다면 TCP와 WebSocket 중 어떤 전송 방식을 쓰는지, TLS를 사용하는지, 별도의 보안 계층이 있는지, 필요한 필드를 대상 코어가 지원하는지까지 확인해야 합니다. Hysteria 2 또는 TUIC은 QUIC 기반이므로 현재 네트워크에서 UDP가 안정적으로 통하는지 먼저 살펴보세요. 프로토콜 이름이 같아도 전송 매개변수가 다르면 호환 여부가 완전히 달라질 수 있습니다. 따라서 '링크를 가져올 수 있음'과 '연결을 수립할 수 있음'은 별도로 판단해야 합니다. 가져오기 도구는 텍스트를 설정 항목으로 변환하고, 코어는 그 설정을 해석해 연결을 시도합니다.

매개변수는 연결 제공업체의 정보를 따르세요

서버 주소와 포트, 비밀번호 또는 사용자 ID, TLS 서버 이름, 인증서 검증 설정은 모두 연결 제공업체가 안내한 정보와 일치해야 합니다. 주소와 포트는 서버를 찾는 데 쓰이고, 비밀번호나 사용자 ID는 프로토콜 인증에 사용됩니다. TLS 서버 이름은 보통 서버 인증서가 해당 서버와 일치하는지 확인하는 데 쓰입니다. 서로 다른 설정의 필드를 임의로 조합해도 정상적으로 연결되지 않는 경우가 대부분입니다. 특히 '이 프로토콜이 TLS를 지원한다'는 말을 'TLS를 켜면 연결 문제가 해결된다'고 해석하지 마세요. 서버도 같은 방식으로 설정되어 있어야 하며 클라이언트의 전송 계층 설정도 일치해야 합니다.

Clash 설정에는 프로토콜 외의 요소도 포함됩니다. proxies는 사용할 수 있는 아웃바운드를 정의하고, proxy-groups는 선택 관계를 구성하며, rules는 요청을 어떤 아웃바운드로 보낼지 정합니다. DNS 설정은 도메인 이름을 해석하는 방식에 영향을 줍니다. 프로토콜 설정이 올바르더라도 프록시 그룹이 해당 아웃바운드를 참조하지 않거나 규칙이 최종적으로 직접 연결을 가리키면 기대한 결과가 나타나지 않을 수 있습니다. 반대로 아웃바운드 모드를 바꿔도 노드가 사용하는 프로토콜은 달라지지 않습니다. 설정을 점검할 때는 '설정 파싱 → 아웃바운드 선택 가능 여부 → 연결 수립 → 규칙에 따른 아웃바운드 선택' 순서로 확인하면 스위치를 반복해서 바꾸는 것보다 원인을 찾기 쉽습니다.

프로토콜 지원 여부는 클라이언트 버전, 사용 중인 코어, 구체적인 전송 방식의 조합으로 결정됩니다. 프로토콜 이름 옆에 영구적으로 표시되는 단순한 체크 항목이 아닙니다. 가져오기에 실패했다면 형식을 먼저 확인하고, 가져오기는 됐지만 연결에 실패했다면 필드와 네트워크 환경을 점검하세요.

비교할 때는 테스트 조건부터 맞추세요

어떤 프로토콜이 '더 빠르다'는 평가는 서버 위치와 회선, 기기, 네트워크, 테스트 시간이 비슷할 때만 의미가 있습니다. 셀룰러 네트워크와 가정용 Wi-Fi는 패킷 손실, UDP 연결 가능 여부, 절전 방식이 서로 다릅니다. 같은 설정도 연결 환경이 바뀌면 성능 순위가 달라질 수 있습니다. 일상적으로 쓸 수 있는지 판단하려면 먼저 웹 페이지의 짧은 요청, 연속 다운로드, 동영상 재생, 장시간 백그라운드 대기 중 어떤 작업에 쓸지 정하세요. 그런 다음 연결이 안정적으로 복구되는지, 첫 페이지가 제때 열리는지, 전송 중 속도가 흔들리는지 살펴보고 마지막으로 프로토콜을 비교하면 됩니다. 뒤에서 설명하는 리소스와 배터리 사용량은 작동 방식에 대한 정성적 분석이며, 특정 iPhone의 고정된 배터리 소모량을 뜻하지 않습니다.

2. Shadowsocks: 설정 항목이 비교적 적은 암호화 프록시

가벼운 중계 방식에서 다양한 암호화 방식까지

Shadowsocks는 처음부터 가벼운 프록시를 지향하며 발전했습니다. 클라이언트와 서버가 암호화 방식과 비밀번호를 약속하고, 프록시가 양쪽 사이에서 트래픽을 중계합니다. 매개변수 조합이 하나뿐인 프로토콜은 아닙니다. 구현체마다 지원하는 암호화 방식과 인증 방식, 확장 기능이 다를 수 있으므로 설정의 cipher를 생략하거나 임의로 바꾸면 안 됩니다. 일반적인 AEAD 방식은 암호화와 메시지 무결성 보호를 함께 제공하며, 최신 Shadowsocks 2022 방식은 별도의 키 형식과 구현 요구사항이 있습니다. 코어가 특정 Shadowsocks 설정을 인식한다고 해서 모든 암호화 방식을 지원하는 것은 아닙니다.

Clash 형식 설정에서 기본 Shadowsocks 아웃바운드는 보통 type: ss로 지정하고 server, port, cipher, password를 함께 설정합니다. 제공업체에서 별도의 플러그인이나 전송 래퍼를 요구하면 관련 플러그인 필드도 필요합니다. 플러그인이 빠지면 기본 아웃바운드의 필드를 모두 채워도 서버 설정과 일치하지 않을 수 있습니다. 가져오기 전에 제공된 내용이 표준 아웃바운드 필드인지, ss:// 공유 링크인지, 플랫폼 전용 확장이 포함된 구독인지 확인하세요. 가져오기 도구마다 링크 매개변수와 플러그인 필드를 변환하는 범위가 다릅니다.

사용 조건과 점검 순서

Shadowsocks는 필드를 비교적 쉽게 확인할 수 있어 프록시 설정 구조를 이해하기 좋은 출발점입니다. 기본 연결의 처리 과정도 비교적 단순합니다. 하지만 실제 지연 시간은 네트워크 왕복 시간, 서버 부하, DNS, 전송 상태에 따라 달라지므로 '설정 항목이 적다'는 이유만으로 '어떤 환경에서나 가장 빠르다'고 볼 수는 없습니다. 암호화 방식이 서버와 다르면 규칙 모드를 바꿔도 연결이 복구되지 않습니다. 플러그인이 일치하지 않는다면 비밀번호만 바꾸지 말고 양쪽의 플러그인 종류와 매개변수를 확인하세요. iPhone에서는 선택한 클라이언트의 코어가 해당 암호화 방식을 구현했는지, 구독 변환 과정에서 플러그인 정보가 누락되지 않았는지도 점검해야 합니다.

실용적인 확인 방법은 설정 상세 정보에서 주소, 포트, 암호화 방식, 비밀번호 출처를 차례로 확인한 다음 플러그인 관련 필드가 있는지 살펴보는 것입니다. 이어서 프록시 그룹에 해당 아웃바운드가 포함되어 있는지 확인하고, 선택한 뒤 연결을 다시 수립하세요. '연결 스위치는 켜졌지만 요청이 계속 직접 연결된다면' 암호화 방식을 계속 바꾸기보다 아웃바운드 모드와 규칙을 확인해야 합니다. 같은 설정에 포함된 다른 아웃바운드는 정상인데 Shadowsocks 하나만 작동하지 않는다면, 시스템 네트워크 권한 문제로 단정하지 말고 해당 설정과 제공업체의 원본 매개변수를 먼저 비교하세요.

'프로토콜 유형'과 '서비스 제공업체의 구독 형식'은 구분해야 합니다. YAML 형식 구독 하나에 여러 종류의 프로토콜 아웃바운드가 포함될 수 있습니다. 반면 ss://로 시작하는 링크는 보통 Shadowsocks 연결 하나만 설명합니다. YAML에는 규칙, 프록시 그룹, DNS도 포함될 수 있지만 단일 링크는 일반적으로 클라이언트에서 직접 프록시 그룹에 추가해야 합니다. 여러 연결에 규칙을 적용하려면 파일 이름만 보고 짐작하지 말고 전체 설정을 가져온 것인지, 단일 공유 링크를 가져온 것인지 확인하세요.

3. VMess: 사용자 식별 정보와 전송 방식 조합

프로토콜 식별 정보와 전송 방식은 다릅니다

VMess는 V2Ray 생태계에서 비롯된 프로토콜로, 사용자 ID 등의 정보로 연결을 식별하고 여러 하위 전송 방식과 조합할 수 있습니다. 설정에는 UUID 형식의 uuid가 자주 표시되며, 경우에 따라 alterId도 볼 수 있습니다. 최신 설정을 사용하는 연결에서는 일반적으로 alterId 값이 0이지만, 서버의 실제 매개변수를 기준으로 해야 합니다. 오래된 구독의 값을 무조건 0으로 바꾸면 안 됩니다. VMess의 사용자 식별 필드는 연결을 식별하는 데 쓰이고, TCP나 WebSocket 등의 네트워크 유형은 데이터 전송 방식을 정합니다. 문제를 점검할 때 두 정보를 모두 확인해야 합니다.

공유 링크에서 자주 보이는 vmess://는 바로 읽을 수 있는 YAML이 아니라 인코딩된 연결 매개변수일 수 있습니다. 클라이언트에 아웃바운드 이름이 표시되더라도 일부 정보를 파싱했다는 의미일 뿐입니다. 주소, 포트, UUID, 전송 유형, TLS 설정, 경로, 호스트 이름이 코어 설정에 빠짐없이 반영됐는지 확인하세요. 특히 WebSocket 경로와 요청 호스트 이름은 서버 설정과 짝을 이루는 경우가 많아 문자 하나만 빠져도 핸드셰이크가 실패할 수 있습니다. TLS 서버 이름도 제공업체의 안내에 따라 설정해야 하며 아웃바운드 표시 이름으로 대체하지 않는 것이 좋습니다.

성능은 연결 전체를 기준으로 비교하세요

설정이 적은 기본 Shadowsocks 연결과 비교하면 VMess는 TLS나 WebSocket 같은 캡슐화 계층을 추가할 수 있어 연결 수립 과정에 더 많은 단계가 필요할 수 있습니다. 그러나 그 과정이 실제 대기 시간으로 이어지는지는 연결 재사용 여부, 네트워크 왕복 시간, 서버 구현에 따라 달라집니다. WebSocket과 TLS를 사용하는 VMess를 이러한 계층이 없는 연결과 비교한 뒤 차이를 모두 'VMess 프로토콜이 느리다'고 설명하는 것은 적절하지 않습니다. 같은 기기에서 실제로 자주 하는 작업을 비교하세요. 페이지를 처음 열 때, 리소스를 연속해서 불러올 때, Wi-Fi에서 셀룰러로 전환한 뒤 연결이 복구되는지를 확인하는 편이 좋습니다.

리소스 사용량도 프로토콜 이름만으로 순위를 매길 수 없습니다. 암호화 처리, TLS, 시스템 네트워크 확장, 로그 기록, 활성 연결 수가 CPU 활성화와 메모리 사용량에 모두 영향을 줍니다. 짧은 테스트에서는 화면 새로고침이나 시스템 백그라운드 작업이 차이를 가릴 수도 있습니다. iPhone에서는 프로토콜 이름만 보고 배터리 사용량을 예상하기보다 매개변수가 완전하고 현재 코어가 전송 조합을 지원하며 연결이 안정적인 설정을 우선하세요. 가져온 설정에 전송 필드가 빠져 있다면 흔히 쓰는 WebSocket 경로를 임의로 입력하지 말고 원본 구독에서 변환 결과를 확인해야 합니다.

VMess 점검 순서: UUID와 서버 주소를 확인한 뒤 네트워크 유형을 확인하세요. TLS를 사용한다면 서버 이름을, WebSocket을 사용한다면 경로와 요청 호스트 이름을 점검하세요. 마지막으로 프록시 그룹과 규칙을 확인하면 됩니다.

같은 구독이 다른 클라이언트에서는 작동하지만 현재 클라이언트에서 작동하지 않는다면 노드 표시 이름만 비교하지 말고 각 클라이언트가 인식한 설정 항목을 기록해 하나씩 대조하세요. 일부 구독 변환 도구는 구현체에 따라 다른 필드를 생성하므로 이름은 같아도 실제 전송 설정이 다를 수 있습니다. 프로토콜 필드 설명은 용어집에서 확인할 수 있습니다. 연결 스위치와 설정 가져오기, 규칙 모드의 적용 순서를 확인하려면 빠른 시작 가이드의 단계별 안내를 따라가세요.

4. Trojan과 VLESS: 이름은 비슷해도 필요한 조건은 다릅니다

Trojan의 TLS와 비밀번호

Trojan은 TLS를 연결 설계의 핵심으로 사용합니다. 설정에는 보통 서버 주소와 포트, 비밀번호, TLS에 필요한 서버 이름 등이 포함됩니다. 클라이언트 식별에는 비밀번호를 사용하지만, 비밀번호가 TLS 인증서 검증을 대신하지는 않습니다. 일반적으로 제공업체의 안내에 따라 인증서와 서버 이름이 일치하는지 확인해야 합니다. 인증서 검증을 끄는 것은 일반적인 해결책이 아니며, 필요한 서버 신원 확인 절차를 생략하게 됩니다. 인증서 오류가 발생하면 기기 시간, 서버 이름, 인증서 상태, 서버 설정부터 점검하세요.

Trojan은 WebSocket이나 gRPC 같은 전송 방식과 조합할 수도 있습니다. 이 경우 'Trojan + 비밀번호' 정보만으로는 연결 설정을 완성할 수 없습니다. 경로, 서비스 이름, 요청 호스트 이름도 서버 설정과 일치해야 합니다. 모바일에서는 TLS 핸드셰이크가 처음 연결을 수립할 때 추가 작업을 발생시키지만, 연결을 유지하는 동안의 사용 경험은 네트워크 안정성과 연결 재사용 여부에 더 크게 좌우됩니다. TLS가 있다는 이유만으로 Trojan이 다른 프로토콜보다 배터리를 더 많이 쓴다고 단정할 수는 없습니다. 연결이 자주 끊겨 핸드셰이크를 반복한다면 장기간 안정적으로 유지되는 연결보다 그 원인을 먼저 확인하는 편이 좋습니다.

VLESS의 인증과 외부 보안 계층

VLESS도 V2Ray 관련 생태계에서 비롯됐지만 VMess의 단순한 이름 변경 버전은 아닙니다. VLESS는 사용자 ID로 신원을 확인하며 프로토콜 자체는 전송 암호화를 제공하지 않습니다. 실제 보안 수준은 함께 사용하는 TLS 등의 외부 계층과 구체적인 전송 설정에 따라 달라집니다. 따라서 type: vless를 확인했다면 UUID뿐 아니라 전송 유형, 보안 계층, 관련 매개변수도 점검해야 합니다. 일부 VLESS 설정에는 특정 보안 확장이 사용됩니다. 해당 확장의 지원 여부는 클라이언트에서 사용하는 코어의 기능을 기준으로 확인해야 합니다.

Clash 코어 종류에 따라 기능이 다르므로 이 점은 특히 중요합니다. 원본 Clash의 지원 범위는 Meta 및 mihomo와 같지 않습니다. YAML 파일을 열 수 있다고 해서 그 안의 VLESS 아웃바운드까지 실제로 실행된다고 볼 수는 없습니다. VLESS를 모두 인식하는 두 코어라도 특정 전송 방식이나 확장 필드의 지원 수준은 다를 수 있습니다. 가져오기 전에 클라이언트 안내에서 사용하는 코어를 확인하세요. 가져온 뒤에는 파싱 알림과 아웃바운드 목록, 연결 로그를 살펴보세요. '지원하지 않는 프록시 유형' 또는 알 수 없는 필드가 표시되면 서버 인증 정보를 바꾸기보다 설정과 코어가 호환되지 않는 상황인지 먼저 확인해야 합니다.

보안 계층과 연결 가능 여부를 나눠 점검하세요

Trojan과 VLESS 모두 TLS를 사용할 수 있지만 점검 방법은 서로 다릅니다. Trojan은 비밀번호와 TLS 매개변수를 확인하고, VLESS는 사용자 ID와 전송 방식, 외부 보안 계층을 확인해야 합니다. 두 프로토콜 모두 포트는 열려 있지만 핸드셰이크가 실패할 수 있습니다. Trojan은 비밀번호나 인증서 이름이 맞지 않을 수 있고, VLESS는 확장 매개변수가 지원되지 않거나 전송 경로가 일치하지 않을 수 있습니다. 먼저 구독 원본 필드를 확인하고, 변환된 Clash 설정을 살펴본 뒤, 마지막으로 클라이언트에서 수정할 수 있는 옵션을 바꾸세요. 이렇게 하면 가져오기 도구에서 필드가 누락된 문제를 프로토콜 자체의 문제로 오해하는 일을 피할 수 있습니다.

설정 제공업체가 여러 프로토콜을 지원하더라도 더 최신으로 보이는 이름을 선택하기 위해 안정적으로 작동하는 아웃바운드를 바꿀 필요는 없습니다. 실제 선택은 서버에서 제공하는 전체 매개변수, 클라이언트 지원 범위, 네트워크 안정성, 사용 목적을 기준으로 해야 합니다. 일상적인 연결을 원하는 사용자라면 다운로드 페이지에서 추천하는 Clash Plus iOS 다운로드를 확인한 다음 가져올 설정이 어떤 프로토콜을 지원하는지 점검하세요. 프로토콜의 인기는 설정이 유효하다는 근거가 아닙니다.

5. Hysteria 2와 TUIC: 먼저 UDP 환경을 확인하세요

QUIC을 비교할 때 고려해야 할 점

Hysteria 2와 TUIC은 모두 UDP 기반 QUIC 연결을 사용하지만 서로 다른 프로토콜이므로 인증 필드와 설정 형식을 바꿔 쓸 수 없습니다. QUIC은 연결 수립, 보안 핸드셰이크, 멀티플렉싱 등의 기능을 결합합니다. 적절한 네트워크 환경에서는 일부 연결 수립 대기 시간을 줄이고, 패킷 하나의 손실로 여러 전송 스트림이 동시에 막히는 현상을 피할 수 있습니다. 그러나 QUIC 기반이라는 이유만으로 모든 접속 환경에서 더 빠른 것은 아닙니다. 기기와 서버 사이에서 UDP가 정상적으로 통신되어야 합니다. 일부 공용 Wi-Fi나 기업 네트워크, 특수한 접속 환경에서는 UDP를 제한해 연결에 실패하거나 재시도가 반복될 수 있습니다.

Hysteria 2는 효율적인 전송을 지향하는 Hysteria 프로젝트의 흐름을 이어받았으며 설정에는 서버 주소, 인증 정보, TLS 관련 매개변수가 자주 포함됩니다. 대역폭 및 전송 동작과 관련된 설정도 있는데, 필드를 처리하는 방식은 클라이언트나 코어 버전에 따라 다를 수 있습니다. TUIC 역시 QUIC 기반 프록시 연결을 구성하며 보통 사용자 ID와 인증 정보가 필요하고 혼잡 제어 옵션 등이 포함될 수 있습니다. 이런 옵션은 연결 동작을 조정하는 것이지 '값이 높을수록 빠른' 성능 조절기가 아닙니다. 서버에서 요구하지 않는다면 다른 연결의 매개변수를 복사해 시험하지 마세요.

모바일 네트워크 전환과 재연결

iPhone에서 Wi-Fi와 셀룰러 네트워크를 오가면 네트워크 주소와 라우팅, 시스템 네트워크 확장 상태가 달라질 수 있습니다. 특정 조건에서는 QUIC 연결이 빠르게 복구될 수 있지만 클라이언트 구현과 서버 설정, 시스템 스케줄링도 중요합니다. 프로토콜 설계상의 잠재적 이점이 언제나 나타나는 것은 아닙니다. 네트워크 전환 후 첫 요청이 성공하는지, 수동으로 다시 연결해야 하는지, 화면을 오랫동안 잠근 뒤 연결이 복구되는지 실제로 확인하세요. 특정 Wi-Fi에서만 실패하고 셀룰러에서는 정상이라면 구독 전체를 바꾸기 전에 해당 Wi-Fi의 UDP 통신 가능 여부부터 살펴볼 수 있습니다.

UDP 문제를 점검할 때는 '서버에 연결할 수 없음'과 'UDP 경로가 불안정함'을 구분해야 합니다. 여러 네트워크에서 같은 설정으로 연결을 수립할 수 없다면 주소와 포트, 인증 정보, TLS 설정을 먼저 확인하세요. 특정 네트워크에서만 실패한다면 해당 네트워크 환경을 우선 비교해야 합니다. 인증서 검증을 무조건 완화하거나 인증 필드를 임의로 바꿔도 제한된 UDP 경로는 복구되지 않습니다. 설정에서 TCP와 QUIC 기반 프로토콜을 모두 제공한다면 같은 장소와 시간에 각각 사용해 실제 작업이 완료되는지 확인하세요. 연결 목록에서 선택된 것으로 표시되는지만 보지 마세요.

설정 호환성 측면에서 Hysteria 2는 Hysteria의 이전 형식과 동일하게 해석할 수 없으며, TUIC도 QUIC을 사용한다는 이유만으로 Hysteria 2의 설정 형식을 적용할 수 없습니다. 구독 변환 서비스가 일부 필드만 출력하면 가져온 뒤 이름은 정상적으로 보여도 연결에 실패할 수 있습니다. 구독을 내보낼 때 사용 중인 코어에 맞는 형식을 선택했는지 확인하고, 프로토콜 유형과 인증 필드, TLS 이름이 빠지지 않았는지 살펴보세요. 코어가 지원하지 않는다면 YAML 들여쓰기를 바꿔도 프로토콜 기능을 추가할 수 없습니다.

6. 속도, 리소스 사용량, iPhone 배터리

첫 응답, 전송 속도, 안정성을 나눠 살펴보세요

'연결 속도'에는 적어도 세 가지 의미가 있습니다. 연결 수립에 걸리는 시간, 새 페이지를 열 때 첫 응답이 오는 시간, 지속적으로 데이터를 전송할 때의 처리량입니다. 이 세 가지 결과가 항상 같은 방향으로 움직이는 것은 아닙니다. 핸드셰이크 단계가 적은 프로토콜도 서버 회선이 혼잡하면 페이지 로딩이 느릴 수 있습니다. 반대로 처음 연결을 수립하는 데 더 많은 작업이 필요해도 이후 요청에서 연결을 재사용해 연속 탐색이 안정적인 프로토콜도 있습니다. 비교할 때는 기기와 접속 네트워크, 서버 조건을 동일하게 유지하고 첫 요청과 연속 요청의 체감 차이를 따로 기록하세요. DNS 대기 시간이나 앱 자체의 로딩 시간을 프로토콜 탓으로 돌리지 않도록 주의해야 합니다.

네트워크 품질이 달라지면 성능 순위도 뒤집힐 수 있습니다. 패킷 손실은 재전송과 혼잡 제어에 영향을 줍니다. TCP와 QUIC은 여러 요청을 처리하는 방식이 다르지만 둘 다 실제로 사용할 수 있는 하위 네트워크 경로가 필요합니다. UDP가 불안정하면 Hysteria 2나 TUIC이 TCP 기반 설정보다 원활하지 않을 수 있습니다. 웹 페이지는 짧은 요청이 많이 발생하고, 동영상 재생은 지속적인 전송과 중단 후 복구가 중요합니다. 프로토콜을 선택하기 전에 가장 자주 겪는 문제가 첫 화면 로딩 지연인지, 장시간 연결 끊김인지, 특정 네트워크에서의 연결 실패인지 확인하세요. 문제에 따라 점검 순서가 달라집니다.

배터리 소모량은 프로토콜 이름만으로 정해지지 않습니다

iOS 클라이언트는 보통 시스템 네트워크 기능을 이용해 관련 트래픽을 처리합니다. 배터리 사용량은 무선 통신 상태와 화면 밝기, 백그라운드 앱, DNS 조회, 로그 수준, 연결 재시도, 암호화 작업의 영향을 함께 받습니다. 프로토콜 필드 수를 배터리 소모량으로 바로 환산할 수는 없습니다. 소수의 연결을 안정적으로 유지하는 설정이 반복해서 실패하고 계속 재시도하는 '가벼운 프로토콜'보다 리소스를 덜 쓸 수도 있습니다. 반면 데이터를 장시간 전송하면 무선 네트워크와 프로세서가 계속 활성 상태를 유지합니다. 배터리 사용량을 비교하려면 화면과 앱 사용 방식을 최대한 동일하게 유지하고 평소처럼 충분한 시간 동안 사용해 보세요. 몇 분간의 배터리 퍼센트 변화만으로 결론을 내리지 마세요.

배터리가 비정상적으로 빨리 닳는다면 구체적인 동작부터 확인하세요. 먼저 아웃바운드가 반복해서 재연결을 시도하는지 살펴보고, 로그에 연결 오류가 계속 기록되는지 확인합니다. 이어서 구독 자동 업데이트 간격과 DNS 설정, 백그라운드 네트워크 활동을 점검하세요. 특정 설정에서만 문제가 발생한다면 안정적으로 작동하는 설정과 전송 방식, 오류 메시지를 비교합니다. 모든 설정에서 같은 현상이 나타난다면 시스템 네트워크 확장과 다른 앱의 네트워크 요청, 현재 접속 환경을 살펴보세요. 배터리를 아끼려고 TLS 검증을 임의로 끄거나 모든 규칙을 직접 연결로 바꾸지 마세요. 그렇게 하면 연결 방식만 달라질 뿐 배터리 소모의 원인이 밝혀지지는 않습니다.

실제 작업으로 범위를 좁혀 비교하세요

재현 가능한 테스트 방법은 다음과 같습니다. 같은 네트워크에서 매개변수가 올바른 것으로 확인된 아웃바운드 두 개를 차례로 선택하고, 연결이 수립될 때까지 기다린 뒤 평소 사용하는 웹 페이지나 앱을 열어 처음 로딩, 연속 로딩, 네트워크 전환 후 복구 상태를 확인하세요. DNS와 규칙, 프로토콜, 서버를 동시에 바꾸면 어떤 변경이 차이를 만들었는지 알기 어렵습니다. 테스트를 마친 뒤에는 사용 목적에 맞고 더 안정적인 설정을 유지하면 됩니다. 한 번의 속도 측정에서 최고값을 얻으려고 할 필요는 없습니다. DNS 모드가 첫 요청에 영향을 주는 이유는 Fake-IP와 DNS 매핑 설명에서 확인할 수 있습니다.

모든 환경에서 가장 빠르거나 배터리를 가장 적게 쓰는 프로토콜은 없습니다. 먼저 연결이 정상적으로 되는지 확인한 다음 같은 네트워크와 비슷한 작업, 동일한 설정에서 비교하세요. 재시도가 계속된다면 성능 순위를 매기기 전에 오류부터 해결해야 합니다.

7. 원본 Clash, Meta, mihomo의 관계

원본 설정에서 확장 코어까지

원본 Clash는 널리 사용되는 YAML 설정 구조를 정립했습니다. 아웃바운드와 프록시 그룹, 규칙, DNS 등의 최상위 필드를 조합해 코어가 읽을 수 있는 설정 파일을 구성합니다. 이후 등장한 Clash.Meta는 이 체계를 바탕으로 프로토콜과 네트워크 기능을 확장했으며, mihomo는 이러한 코어 계열에서 이어서 사용되는 이름입니다. 설정을 계승하는 관계는 있지만 '원본 설정은 모두 완전히 호환되고 확장 설정도 원본 코어에서 역으로 열 수 있다'고 단순화해서는 안 됩니다. 파일을 읽는 데 필요한 최소 기능은 실제로 사용된 필드와 아웃바운드 유형에 따라 달라집니다.

예를 들어 기본 Shadowsocks 아웃바운드와 일반적인 프록시 그룹, 규칙만 사용하는 설정은 VLESS나 Hysteria 2, 특정 DNS 확장을 포함한 설정보다 코어 간에 옮기기 쉬운 편입니다. 하지만 프로토콜 유형이 같아도 확장 필드와 규칙 유형, 기본 동작은 달라질 수 있습니다. 원본 Clash가 Meta나 mihomo에 나중에 추가된 모든 프로토콜을 지원한다고 가정해서는 안 됩니다. 클라이언트 인터페이스에 'Clash'라는 이름이 표시되더라도 실제 사용 중인 코어나 내장 프로토콜 지원 안내를 확인해야 합니다.

설정 호환성은 필드별로 판단하세요

YAML을 확인할 때는 먼저 최상위 구조를 살펴보고, 아웃바운드의 type을 확인한 다음 각 유형에만 해당하는 필드를 점검하세요. proxy-groups가 참조하는 아웃바운드 이름은 proxies에 정의된 이름과 일치해야 합니다. rules가 최종적으로 가리키는 프록시 그룹이나 아웃바운드도 실제로 존재해야 합니다. 코어가 특정 프록시 유형을 인식하지 못한다면 필드 이름을 다른 방식으로 바꾸는 것만으로 호환시킬 수 없습니다. 일부 설정 항목의 이름만 달라진 경우에는 대상 코어의 설정 문서를 참고해 조정하고 기본값도 바뀌었는지 확인하세요. 설정을 옮길 때는 사용 중인 원본 파일을 덮어쓰지 말고 복사본에서 항목별로 수정하는 편이 안전합니다.

아래는 설정 구조를 살펴보기 위한 간단한 YAML 예제입니다. 아웃바운드와 프록시 그룹, 규칙이 서로를 참조하는 구조를 보여줍니다. 예제의 도메인과 비밀번호는 필드를 설명하기 위한 값일 뿐이므로, 실제로 연결할 때는 연결 제공업체가 안내한 전체 매개변수로 바꿔야 합니다. 이 예제에는 클라이언트의 모든 시스템 설정이 포함되어 있지 않으며, 모든 코어가 임의의 추가 필드를 지원한다는 뜻도 아닙니다.

mode: rule
proxies:
  - name: Sample-SS
    type: ss
    server: proxy.example.net
    port: 443
    cipher: aes-128-gcm
    password: your-password

proxy-groups:
  - name: SELECT
    type: select
    proxies:
      - Sample-SS
      - DIRECT

rules:
  - MATCH,SELECT

예제의 MATCH,SELECT는 다른 규칙에 해당하지 않는 요청을 SELECT 프록시 그룹으로 보냅니다. SELECT 그룹에서는 예제 아웃바운드나 DIRECT를 선택할 수 있습니다. 이 구성은 참조 관계를 설명하기 위한 것으로 모든 요청에 동일한 규칙을 적용하라는 뜻은 아닙니다. 실제 구독에는 도메인과 네트워크에 따른 더 세부적인 규칙이 포함되며 규칙 집합을 업데이트할 수도 있습니다. 설정을 읽을 때는 마지막에 적용되는 규칙에서 거꾸로 따라가세요. 규칙이 어떤 그룹을 가리키는지, 그룹에 어떤 아웃바운드가 있는지, 선택한 아웃바운드의 프로토콜 필드가 완전한지 확인하면 노드 이름 하나만 보는 것보다 참조 오류를 쉽게 찾을 수 있습니다.

클라이언트는 시스템과 코어부터 확인하세요

다운로드 페이지에는 Windows, macOS, Android, iOS, Linux용 클라이언트가 안내되어 있으며 Clash Plus는 지원되는 플랫폼에서 추천 클라이언트로 표시됩니다. 그 밖의 클라이언트가 지원하는 범위는 실제 구현에 따라 확인해야 합니다. 데스크톱에서는 Clash Verge Rev, FlClash 등을, Android에서는 Clash Meta for Android 등을 사용할 수도 있지만 같은 구독이라도 클라이언트마다 가져온 결과를 따로 확인해야 합니다. iPhone용 클라이언트를 고를 때는 iOS 다운로드 페이지와 클라이언트 안내를 먼저 확인하고, 현재 구독에 필요한 프로토콜을 해당 코어가 지원하는지 살펴보세요. 데스크톱 클라이언트의 기능을 휴대폰에서도 지원한다고 추정하면 안 됩니다.

port, dns, proxies부터 rules까지 파일 전체 구조를 더 알아보려면 YAML 구조 항목별 해설을 확인하세요. 이 장의 핵심은 하나입니다. 호환성은 파일 확장자나 클라이언트 이름이 아니라 '대상 코어가 설정에 실제로 사용된 모든 항목을 인식하고 올바르게 실행할 수 있는지'로 판단해야 합니다.

8. 구독 형식 호환성과 사용 상황별 선택

전체 설정과 단일 공유 링크를 구분하세요

'구독'은 설정을 가져오고 업데이트하는 방식이지 특정 프록시 프로토콜을 뜻하지 않습니다. 구독 URL은 전체 Clash YAML을 반환할 수도 있고, 여러 공유 링크를 담은 텍스트를 반환할 수도 있으며, 다른 클라이언트용 형식일 수도 있습니다. ss://, vmess:// 같은 단일 링크에는 보통 특정 아웃바운드의 연결 매개변수만 들어갑니다. 전체 YAML에는 프록시 그룹과 규칙, DNS, 업데이트에 필요한 기타 정보도 포함될 수 있습니다. 클라이언트가 URL에서 내용을 내려받을 수 있다는 것은 파일을 가져왔다는 뜻일 뿐, 현재 가져오기 도구가 형식을 제대로 인식했다는 뜻은 아닙니다.

가져오기에 실패하면 먼저 URL이 파일 내용이 아니라 로그인 페이지나 오류 페이지를 반환하는지 확인하세요. 그런 다음 제공업체에서 안내한 내보내기 형식이 Clash 형식 설정에 맞는지 살펴봅니다. 가져온 뒤 아웃바운드 수가 예상과 다르거나 이름은 정상적으로 표시되는데 전송 매개변수가 빠졌다면 구독 원본과 클라이언트의 파싱 결과를 비교하세요. 필요하면 현재 코어에 맞는 내보내기 형식을 요청할 수 있습니다. 다른 클라이언트용 파일의 이름만 config.yaml로 바꾸지 마세요. 확장자를 바꿔도 필드가 변환되거나 프록시 그룹이 추가되지는 않습니다. iPhone에서 여러 Profile을 추가하고 업데이트하거나 전환하는 방법은 설정 파일 관리 안내를 참고하세요.

프로토콜 이름으로 순위를 매기지 말고 조건으로 선택하세요

처음 사용한다면 클라이언트에서 설정 전체를 가져올 수 있고 각 필드를 제공업체의 정보와 대조할 수 있는 구성을 선택하세요. 이미 안정적으로 작동하는 Shadowsocks, VMess, Trojan 아웃바운드가 있다면 프로토콜을 바꾸려고 규칙 전체를 다시 만들 필요는 없습니다. 제공업체가 VLESS 설정을 제공하면 현재 코어가 전송 방식과 보안 확장을 지원하는지 확인하세요. Hysteria 2나 TUIC을 제공한다면 자주 사용하는 Wi-Fi와 셀룰러 네트워크에서 UDP 연결이 가능한지 각각 확인해야 합니다. 여러 네트워크를 자주 오가는 사용자라면 정적인 프로토콜 설명만 보지 말고 전환 후 연결이 얼마나 잘 복구되는지도 선택 기준에 넣으세요.

웹 브라우징에서는 첫 요청과 DNS 응답이 체감되기 쉽고, 데이터를 계속 전송할 때는 연결 안정성이 더 중요합니다. 장시간 대기할 때는 불필요한 재시도와 백그라운드 활성화가 발생하는지 살펴봐야 합니다. 어떤 경우에도 프로토콜 이름만으로 공통된 답을 낼 수는 없습니다. 실용적인 선택 순서는 코어 지원 여부 확인, 필드 점검, 자주 쓰는 네트워크에서 연결, 실제 작업 수행, 복구 상태와 배터리 사용량 확인입니다. 단계마다 조건을 하나씩만 바꾸고 비교할 결과를 기록하세요. 어느 단계에서든 실패하면 속도 순위를 따지기 전에 해당 문제부터 해결해야 합니다.

이전 설정으로 되돌릴 수 있도록 보관

설정을 변경하기 전에 정상적으로 작동하는 Profile을 하나 보관해 두세요. 새 구독은 별도 설정으로 가져온 뒤 아웃바운드와 프록시 그룹, 규칙이 모두 정상인지 확인하고 일상적으로 사용할 설정으로 전환합니다. 업데이트 후 연결이 실패하면 이전 설정으로 되돌린 뒤 업데이트 전후의 프로토콜 유형과 서버 필드, 프록시 그룹 참조를 비교하세요. 그러면 설정 내용이 바뀐 것인지 네트워크 접속 환경이 달라진 것인지 빠르게 구분할 수 있습니다. 구독 업데이트가 클라이언트 코어 업데이트를 뜻하는 것은 아닙니다. 새 설정에 코어가 지원하지 않는 프로토콜 필드가 추가되면 호환되는 클라이언트 구현을 선택하거나 제공업체에서 지원하는 형식을 사용해야 합니다.

작업 순서는 빠른 시작 가이드에서 다시 확인할 수 있고, 설치 옵션은 클라이언트 다운로드에서 볼 수 있습니다. 연결 스위치와 설정 가져오기, 규칙 모드에 대해 궁금한 점이 있으면 도움말 센터를 확인하세요. 이 가이드는 각 작업을 진행하면서 반복해서 참고할 수 있습니다. 현재 문제가 프로토콜과 전송 방식, 코어, 구독 형식 중 어디에 해당하는지 먼저 파악한 다음 관련 장을 확인하세요. 모든 설정을 한꺼번에 바꾸지 않는 것이 중요합니다.