Clash 프로토콜 및 코어 가이드

프로토콜, 전송 및 연결 계층

클라이언트, 코어, 서버를 구분하세요

클라이언트 목록에서 노드를 선택하는 일은 프로토콜 이름만 고르는 것이 아니라 연결 매개변수 조합을 선택하는 것입니다. 클라이언트는 구독을 표시하고 설정을 관리하며 시스템 프록시를 설정합니다. 코어는 규칙을 해석하고 서버에 연결해 데이터를 전달하며, 서버는 클라이언트를 대신해 목적지에 접속합니다. 각 요소는 서로 다른 프로젝트에서 구현되고 업데이트 주기도 다릅니다. 따라서 인터페이스에서 특정 항목을 저장할 수 있다고 해서 코어가 이를 사용할 수 있는 것은 아닙니다. 코어가 프로토콜을 지원하더라도 현재 서버에 해당 연결 지점이 열려 있다는 뜻은 아닙니다.

일반적인 노드에는 서버 주소, 포트, 프로토콜 유형, 인증 정보가 포함됩니다. 암호화 방식, TLS 서버 이름, 전송 경로, QUIC 매개변수가 추가로 필요한 경우도 있습니다. 이러한 항목이 함께 프로토콜 규격을 구성하므로 서버 설정과 하나씩 일치해야 합니다. Shadowsocks 노드의 유형을 Trojan으로 바꾼다고 프로토콜이 변환되지는 않습니다. 서버 주소가 같더라도 서버 측에 해당 프로토콜을 수신하는 포트가 있어야 하며, 인증 및 전송 매개변수도 별도로 올바르게 설정해야 합니다.

프로토콜 이름과 네트워크 계층은 다릅니다

Shadowsocks, VMess, Trojan, VLESS는 프록시 통신에서 인증·캡슐화·전달 방식을 규정합니다. TCP와 UDP는 데이터를 운반하는 전송 계층 프로토콜이며, TLS는 인증된 암호화 연결을 제공합니다. WebSocket, HTTP/2 등은 추가 전송 방식으로 사용될 수 있습니다. Hysteria2와 TUIC는 QUIC를 중요한 기반으로 삼습니다. 호환성을 판단할 때는 각 계층을 구분해야 합니다. 둘 다 TLS를 사용한다고 해서 서로 연결할 수 있는 것은 아닙니다.

앱에서 UDP가 필요한 경우와 노드의 전송 계층이 UDP를 사용하는 경우도 구분해야 합니다. 음성 앱은 UDP 데이터그램을 만들 수 있지만, 프록시가 이를 다른 연결에 캡슐화할 수도 있습니다. 브라우저는 주로 HTTPS에 접속하더라도 QUIC 기반 프록시를 통해 데이터를 전송할 수 있습니다. 노드 세부 정보의 udp 옵션은 일반적으로 UDP 전달을 허용할지 여부를 뜻하며, TCP 연결을 자동으로 QUIC로 바꾸지는 않습니다. 앱, 프록시 진입점, 서버의 출구가 모두 최종 동작에 영향을 줄 수 있습니다.

요청은 어떤 과정을 거칠까요?

요청이 코어에 들어오면 일반적으로 도메인, 목적지 주소, 규칙을 바탕으로 정책 그룹을 선택하고, 정책 그룹이 실제 출구를 고릅니다. 도메인 조회는 설정과 규칙에 따라 로컬, 코어 또는 원격에서 수행될 수 있습니다. 이후 코어가 서버 연결을 만들고 필요한 인증과 핸드셰이크를 완료한 다음 앱 데이터를 전달합니다. 이 과정에서 접속에 실패했다면 DNS, 규칙, 서버 연결, 대상 사이트 중 어디에 문제가 있는지 살펴봐야 합니다. 시간 초과 메시지만으로 프로토콜이 작동하지 않는다고 단정할 수는 없습니다.

시스템 프록시와 TUN도 요청을 받는 진입점이며, 노드 프로토콜과는 별개입니다. 시스템 프록시는 앱이 로컬 HTTP 또는 SOCKS 진입점을 사용해야 동작합니다. TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 전달합니다. TUN을 켜면 처리할 수 있는 트래픽 범위는 넓어지지만, 잘못된 비밀번호나 인증서 이름, 서버 포트 문제까지 해결되지는 않습니다. 특정 앱만 연결되지 않는다면 먼저 해당 트래픽이 코어에 들어오는지 확인한 다음 프로토콜 변경을 고려하세요.

선택 순서: 먼저 서버가 제공하는 프로토콜을 확인하고, 코어가 지원하는지 확인한 뒤, 네트워크 환경에 얼마나 잘 맞는지 비교하세요. 프로토콜 기능, 클라이언트 기능, 트래픽 진입점은 서로 독립된 요소입니다.

이 가이드의 속도와 리소스 비교는 조건에 따라 달라지는 경향을 설명하며, 프로토콜에 고정 순위를 매기지 않습니다. 같은 프로토콜도 회선, 서버 부하, 프로세서, 통신사 네트워크에 따라 성능이 크게 달라질 수 있습니다. 처음 설정한다면 시작 가이드를 따라 연결을 완성한 다음, 이 페이지의 방법으로 변수 하나씩 비교하세요. DNS, TUN, 프로토콜, 규칙을 한꺼번에 바꾸면 원인을 찾기 어렵습니다.

Shadowsocks와 VMess

Shadowsocks: 간결한 암호화 프록시

Shadowsocks는 보통 SS로 줄여 부르며, 로컬 프록시 요청을 암호화된 연결을 통해 서버로 전달하는 방식에서 출발했습니다. 일반적인 설정은 비교적 간단합니다. 서버, 포트, 암호화 방식, 비밀번호가 핵심 매개변수입니다. 외부 TLS나 추가 전송 계층이 필요한 조합에 비해 직접 전송하는 프로토콜 스택은 대체로 단순해 이해하고 배포하기 쉽습니다. 다만 설정 항목이 적다고 보안이 비밀번호 길이에만 좌우되는 것은 아닙니다. 암호화 방식과 구현 품질, 키 관리도 중요합니다.

Shadowsocks는 역사적으로 여러 암호화 방식을 사용했습니다. 기존 서버에 연결할 때는 서비스 제공자가 명시적으로 지원하는 최신 AEAD 방식을 우선 사용하고, 오래된 클라이언트와의 호환을 위해 낡은 방식을 임의로 선택하지 마세요. AEAD는 암호화와 메시지 인증을 함께 처리해 데이터 변조를 감지합니다. 최근 프로토콜 변형 중에는 키 형식과 세션 처리 방식이 다른 경우도 있습니다. 암호화 방식 이름만 바꿔서는 구형 서버와 호환되지 않습니다.

설정할 때는 cipher 값이 서버 설정과 정확히 일치해야 하며, 비밀번호 형식에도 제한이 있을 수 있습니다. 특히 일부 Shadowsocks 2022 방식은 정해진 길이의 Base64 키를 사용하므로 일반적인 짧은 비밀번호를 그대로 입력할 수 없습니다. AES와 ChaCha20 중 무엇을 쓸지는 기기에 해당 하드웨어 가속 기능이 있는지 고려해 선택하세요. 데스크톱 프로세서에서의 성능 이점이 저전력 라우터에서도 그대로 나타나는 것은 아닙니다. 이름으로 추측하기보다 실제 처리량을 측정하는 편이 정확합니다.

플러그인과 UDP 호환성도 확인하세요

플러그인을 사용하는 Shadowsocks 노드는 클라이언트 코어가 동일한 플러그인과 옵션을 지원해야 합니다. 공유 링크를 가져올 수 있다는 사실은 파서가 기본 구조를 인식했다는 뜻일 뿐, 플러그인 매개변수까지 모두 보존된다는 뜻은 아닙니다. 연결이 즉시 종료된다면 비밀번호를 계속 다시 입력하기보다 원본 정보를 확인해 플러그인 이름, 호스트 항목, 전송 옵션이 맞는지 살펴보세요. 플러그인은 프로토콜 스택과 배포 조건도 바꾸므로 모든 SS 노드를 같은 성능 모델로 볼 수는 없습니다.

UDP를 사용하려면 양쪽 모두 지원해야 합니다. 클라이언트에서 UDP를 허용하고, 서버에서 전달 기능을 열고, 호스트 방화벽에서 관련 트래픽을 허용해야 합니다. 하나라도 빠지면 음성 통화나 게임에 문제가 생길 수 있습니다. 웹페이지가 열린다고 해서 해당 TCP 요청만 성공한 것이며 UDP 경로까지 사용할 수 있다는 뜻은 아닙니다. 플러그인 방식이라면 플러그인의 UDP 처리 범위도 확인해야 합니다. 직접 전송 방식의 기능을 플러그인 연결에 그대로 적용할 수는 없습니다.

VMess: 인증 방식과 전송 조합

VMess는 V2Ray 생태계에서 나온 프로토콜로, 사용자 인증과 프록시 데이터 캡슐화를 포함하며 여러 전송 방식과 함께 사용할 수 있습니다. VMess를 비교할 때는 TLS 사용 여부와 WebSocket 같은 중간 계층 사용 여부를 함께 명시해야 합니다. 그렇지 않으면 “VMess가 더 느리다”는 비교의 기준이 분명하지 않습니다. 직접 TCP 연결과 여러 계층으로 캡슐화한 연결은 핸드셰이크, 버퍼링, 서버 처리 경로가 다릅니다. 따라서 최종 오버헤드가 VMess 자체에서만 발생한다고 볼 수 없습니다.

최신 VMess 설정은 일반적으로 AEAD 인증을 사용합니다. 오래된 자료의 alterId나 구형 인증 설정을 그대로 따라 하지 마세요. 호환 필드가 남아 있다고 해서 과거 방식을 일부러 활성화할 이유는 없습니다. 인증에 시간 정보가 사용되므로 기기의 시스템 시각도 정확해야 합니다. 시스템 시간이 크게 어긋나면 인증에 실패할 수 있습니다. 문제를 해결할 때는 암호화 옵션을 계속 바꾸기보다 먼저 시각을 동기화하고 UUID, 전송 방식, TLS, 서버 경로를 확인하세요.

두 프로토콜의 사용 범위는 다음과 같이 정리할 수 있습니다. 안정적으로 운영되는 SS 서버가 있다면 간단한 설정이 실용적인 장점입니다. V2Ray 전송 환경이 이미 구축되어 있다면 VMess 생태계와의 호환성이 더 중요할 수 있습니다. 프로토콜 이름이 새롭다는 이유만으로 전체 서버 구성을 다시 만들 필요는 없습니다. 새로 선택한다면 클라이언트 지원 여부, 서버 유지 관리 상태, 구독에서 매개변수를 빠짐없이 표현할 수 있는지 함께 살펴보세요. 설정 항목이 많거나 프로토콜이 더 최근에 나왔다는 사실만으로 가치를 판단해서는 안 됩니다.

Trojan, VLESS 및 TLS

Trojan: TLS 연결을 통한 프록시 인증

Trojan은 TLS 연결 안에서 프록시 통신을 수행하고 프로토콜 계층에서 비밀번호로 인증하는 데 중점을 둡니다. 자체 데이터 암호화 캡슐화를 제공하는 일부 프로토콜과 달리, 성숙한 TLS 체계에 전송 보호를 더 많이 의존합니다. 따라서 인증서, 서버 이름, TLS 핸드셰이크는 선택 사항이 아니라 연결 성립에 중요한 요소입니다. 기본 Trojan 설정은 대체로 이해하기 쉽지만, 실제 배포에서 다른 전송 방식을 덧붙이는 경우도 있으므로 서버 안내에 따라 입력해야 합니다.

서버 주소는 IP일 수 있지만 인증서는 보통 도메인 이름으로 발급됩니다. 이때 클라이언트에서 서버 이름을 별도로 지정해야 TLS 핸드셰이크에 올바른 이름을 사용하고 인증서를 검증할 수 있습니다. 이 이름을 흔히 SNI라고 부르지만 클라이언트마다 필드 이름은 다를 수 있습니다. 접속 가능한 도메인을 임의로 입력해서는 안 되며, WebSocket의 Host와 반드시 같은 것도 아닙니다. Host는 다른 프로토콜 계층에 속합니다. 일부 배포에서는 두 값이 같지만, 그렇지 않은 경우도 있습니다.

인증서 오류는 원인을 구체적으로 확인해 해결하세요. 시스템 시각과 인증서 유효 기간, 이름 일치 여부, 인증서 체인의 완전성, 로컬 HTTPS 검사 도구 사용 여부를 확인해야 합니다. 인증서 검증을 끄는 방법을 장기적인 해결책으로 삼지 마세요. 검증을 끄면 원격 서버의 신원을 확인하는 중요한 보호 기능이 사라져 네트워크 중간 장비가 서버를 사칭하기 쉬워질 수 있습니다. 자세한 점검 순서는 HTTPS 인증서 오류 원인과 해결 방법을 참고하세요.

VLESS: 간결한 인증이 독립적인 암호화를 뜻하지는 않습니다

VLESS는 V2Ray 관련 생태계에서 발전했으며, 가벼운 인증 및 전달 구조에 중점을 둡니다. 가장 중요한 점은 VLESS 자체가 일반적인 의미의 독립 전송 암호화를 제공하지 않는다는 것입니다. 전체적인 보안 수준을 판단하려면 TLS, REALITY 등 적절한 보안 전송 계층과 함께 살펴봐야 합니다. 노드 유형이 VLESS라는 정보만으로는 보안 특성이나 연결 비용을 알 수 없습니다. 전송 방식과 보안 계층, 선택 가능한 flow 설정도 확인해야 합니다.

REALITY는 TLS 옵션의 다른 이름이 아니라 별도의 보안 전송 방식입니다. 공개 키, 짧은 ID, 서버 이름, 관련 핸드셰이크 설정이 서로 맞아야 하며 코어 구현의 지원 범위에도 영향을 받습니다. Vision 같은 flow 옵션도 지원되는 조합에서만 사용할 수 있으므로 모든 VLESS 연결에 일괄 적용할 수는 없습니다. 서버가 해당 조합을 사용하지 않는다면 클라이언트에 매개변수를 추가해도 연결에 실패합니다. 다른 노드에서 설정을 복사하는 것만으로 실제 서버 매개변수를 대신할 수도 없습니다.

VLESS를 선택할 때는 먼저 서버에서 제공하는 구체적인 조합을 확인한 다음 현재 코어가 이를 지원하는지 살펴보세요. 클라이언트에서 VLESS 공유 링크를 가져올 수 있어도 링크의 확장 항목을 코어가 모두 지원한다는 뜻은 아닙니다. 특히 오래된 클라이언트, 변환된 구독, 덮어쓰기된 설정에서는 항목이 무시되거나 변경 또는 삭제될 수 있습니다. 문제를 진단할 때는 구독 목록에 표시된 프로토콜 이름만 보지 말고 실제로 코어에 전달되는 최종 설정을 확인해야 합니다.

핸드셰이크 재사용과 지연 시간의 실제 의미

TLS 연결을 만들려면 일반적으로 하위 연결을 수립한 뒤 보안 핸드셰이크를 완료해야 합니다. 최초 연결과 이미 연결된 상태에서 이어지는 요청은 소요 시간의 구성이 다릅니다. 세션 재개, 연결 재사용, 대상 사이트의 HTTP 연결 방식도 체감 속도를 바꿀 수 있습니다. 따라서 클라이언트의 지연 시간 측정은 해당 경로의 연결 및 응답 과정을 주로 반영하며, 장시간 다운로드나 영상 재생, 여러 앱의 동시 사용 성능을 단독으로 보여주지는 않습니다.

Trojan과 VLESS 모두 적절한 선택이 될 수 있습니다. 기존 TLS 환경의 Trojan은 비밀번호와 인증서를 기준으로 문제를 찾기 쉽고, VLESS는 적절한 보안 전송 계층과 함께 더 유연한 조합을 제공할 수 있습니다. 실제 선택은 현재 서버 환경과 유지 관리 역량을 기준으로 하세요. 확장 기능을 더 켠다고 반드시 최적화되는 것은 아닙니다. 전송 방식이나 특수 옵션을 추가할 때마다 호환성을 한 단계 더 확인해야 하며, 나중에 문제를 진단할 때 설명해야 할 변수도 늘어납니다.

인증서 검증, 서버 이름, 앱 계층의 Host, 프로토콜 인증 정보는 각각 서로 다른 문제를 해결합니다. 한 항목이 올바르다고 다른 항목의 오류가 상쇄되는 것은 아닙니다. 인증서 경고가 나타나면 먼저 원인을 확인하세요.

Hysteria2, TUIC 및 QUIC

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

QUIC는 UDP 위에서 보안 연결, 신뢰성 있는 전송, 다중 스트림 등의 기능을 구현하며 TLS 핸드셰이크도 통합합니다. 단순히 “도착을 보장하지 않는 빠른 TCP”가 아니라, 전송 계층이 맡던 여러 기능을 사용자 공간 프로토콜 스택에 구현한 방식입니다. Hysteria2와 TUIC는 모두 QUIC를 활용하지만 인증, 혼잡 제어 방식, 데이터그램 전달, 설정 구조가 서로 다릅니다. 서로 연결할 수 없으며, 둘 다 UDP를 쓴다는 이유로 매개변수를 함께 사용할 수도 없습니다.

QUIC의 중요한 특징 중 하나는 여러 스트림이 TCP 계층의 순서 보장 제약을 공유할 필요가 없다는 점입니다. 한 스트림에서 패킷이 손실되어도 다른 스트림의 데이터는 계속 전달될 수 있어 스트림 간 일부 지연을 줄일 수 있습니다. 다만 공통 혼잡 제어, 회선 용량, 프로세서 성능의 영향을 받습니다. 모든 스트림이 혼잡한 회선을 공유하거나 서버 부하가 지나치게 높으면 프로토콜만으로 대역폭을 추가할 수 없습니다. 모든 서비스가 동시에 빨라진다고 보장할 수도 없습니다.

Hysteria2: 대역폭 설정과 혼잡 제어

Hysteria2는 복잡한 네트워크 경로에서 처리량을 높이는 데 초점을 두며, 설정과 협상 조건에 따라 적절한 혼잡 제어 동작을 사용할 수 있습니다. 일부 환경에서는 업로드 및 다운로드 대역폭을 입력해야 합니다. 이 값은 알고리즘이나 서버 제한 판단에 사용되는 입력값이지, 실제 속도 측정 결과가 아니며 크게 입력할수록 빨라지는 것도 아닙니다. 실제 업로드 용량보다 훨씬 높은 값을 설정하면 대기열과 패킷 손실이 늘고 다른 앱의 사용 경험이 나빠질 수 있습니다. 가정용 인터넷이나 여러 기기가 공유하는 모바일 네트워크에서 특히 주의해야 합니다.

구현 및 서버 정책에 따라 대역폭 추정, 명시적인 속도 설정 또는 다른 혼잡 제어 방식을 사용할 수 있습니다. 입력 여부는 서버 요구 사항에 따라 결정해야 하며, 일반적인 예시 하나만 보고 모든 Hysteria2 노드에 같은 값이 필요하다고 판단해서는 안 됩니다. 비밀번호, TLS 서버 이름, 선택적 난독화 설정, 포트 범위도 서버와 일치해야 합니다. 포트 호핑은 기본 연결을 대신하지 않습니다. 서버에서 지원하지 않는데 활성화해도 연결 가능한 포트가 늘어나지 않습니다.

이름이 비슷해도 프로토콜 버전 간 호환성이 보장되지는 않습니다. Hysteria와 Hysteria2는 프로토콜이 다르므로 클라이언트에서 올바른 유형을 선택해야 합니다. 이름만 보고 판단하는 변환 도구는 겉으로는 완전해 보여도 실제 인증에 실패하는 항목을 만들 수 있습니다. 핸드셰이크에 실패하면 대역폭과 고급 옵션을 먼저 바꾸기보다 서비스가 제공하는 프로토콜 버전, UDP 연결 여부, 인증서와 인증 항목부터 확인하세요.

TUIC: 연결 재사용과 데이터그램 전달

TUIC도 QUIC를 기반으로 하며, 일반적으로 UUID, 비밀번호, TLS 관련 설정을 포함합니다. UDP 전달 방식, 혼잡 제어, 연결 유지 옵션을 제공하는 경우도 있습니다. 프로토콜 발전 과정에서 호환되지 않는 이전 구현이 있었으므로 TUIC라는 이름을 사용하는 모든 서버가 임의의 클라이언트에서 작동한다고 가정할 수 없습니다. 서버가 요구하는 프로토콜과 코어 지원 범위를 확인하고, 공유 링크의 접두어만으로 전체 호환성을 판단하지 마세요.

대화형 앱에서는 데이터그램을 어떤 방식으로 전달하는지가 특히 중요합니다. 데이터그램을 신뢰성 있는 스트림에 넣으면 패킷 손실 시 재전송을 기다릴 수 있습니다. 신뢰성을 보장하지 않는 데이터그램은 원래 UDP 의미에 가깝지만 경로 MTU, 데이터그램 크기, 구현 정책의 영향을 받습니다. 앱마다 패킷 손실과 대기 시간에 대한 허용 범위가 다르므로 음성, 게임, 파일 전송을 하나의 옵션으로 모두 최적화할 수는 없습니다. 고급 모드를 무작정 켜기보다 기본 설정을 유지하는 편이 대체로 안정적입니다.

UDP를 사용할 수 없을 때의 한계

공용 Wi-Fi, 기업 네트워크, 라우터, 통신사 네트워크에서 UDP를 제한할 수 있으며, NAT가 유휴 매핑을 빠르게 제거하기도 합니다. 이때 QUIC 기반 노드는 핸드셰이크에 실패하거나 화면을 끈 뒤 복구가 늦어질 수 있습니다. 검증된 TCP 기반 출구를 별도의 대안으로 준비하세요. 코어가 Hysteria2나 TUIC를 자동으로 TCP 프로토콜로 바꿔주기를 기대해서는 안 됩니다. 자동 전환은 명시적으로 구성한 정책 그룹과 사용할 수 있는 노드가 함께 있어야 가능합니다.

QUIC 기반 프로토콜도 실제 테스트 후보로 고려할 수 있지만, UDP 경로를 사용할 수 있어야 합니다. 장점은 프로토콜 이름 자체가 아니라 구체적인 전송 방식과 네트워크 조건에서 나옵니다.

연결 속도, 리소스 및 모바일 배터리

‘속도’를 여러 지표로 나눠 살펴보세요

연결 속도에는 최소한 최초 연결 시간, 첫 바이트 대기 시간, 지속 처리량, 동시 요청 응답이 포함됩니다. 웹페이지를 처음 여는 속도가 느리다면 DNS, 프록시 핸드셰이크, 대상 사이트가 원인일 수 있습니다. 대용량 파일 전송 속도는 회선 대역폭, 패킷 손실, 서버 속도 제한, CPU 성능의 영향을 받을 수 있습니다. 게임과 음성 통화는 지연 시간의 변동과 패킷 손실이 더 중요하므로 다운로드 처리량으로 대체할 수 없습니다. 테스트 전에 개선하려는 작업을 정해야 어떤 지표를 관찰할지 알 수 있습니다.

지연 시간 테스트는 보통 프록시를 통해 지정된 주소에 요청을 보냅니다. 측정값에는 기기와 서버 사이의 순수 왕복 시간뿐 아니라 DNS 조회, 보안 핸드셰이크, 대상 서버의 응답, 연결 재사용 여부도 반영될 수 있습니다. 클라이언트마다 테스트 주소가 다르면 수치도 직접 비교할 수 없습니다. 테스트가 성공하면 해당 시점에 특정 경로에서 응답을 받았다는 뜻일 뿐, 모든 사이트에 연결할 수 있거나 앱에서 필요한 UDP 전달을 지원한다는 의미는 아닙니다.

프로토콜 오버헤드가 하드웨어에 미치는 영향

직접 전송하는 SS는 일반적으로 캡슐화가 적습니다. TLS와 추가 전송 방식을 조합하면 핸드셰이크나 프레임 처리가 늘어날 수 있고, QUIC 구현은 암호화, 혼잡 제어, 타이머, 사용자 공간 패킷 처리를 수행해야 합니다. 이는 작동 방식의 차이이지 고정된 성능 순위가 아닙니다. 최신 데스크톱 기기는 이런 작업을 여유롭게 처리할 수 있지만, 저전력 라우터나 휴대전화는 처리량이 높을 때 단일 코어 성능, 발열 제한, 메모리 대역폭의 한계에 더 쉽게 도달할 수 있습니다.

메모리 사용량은 프로토콜만으로 결정되지 않습니다. 동시 연결 수, 연결 버퍼, 규칙 집합, DNS 캐시, 로그 수준, 클라이언트 인터페이스도 메모리를 사용합니다. 같은 코어를 쓰더라도 한 클라이언트가 더 많은 규칙을 불러오고 상세 로그를 남기면 메모리 사용량이 크게 달라질 수 있습니다. 비교할 때는 설정 규모를 동일하게 맞추고 불필요한 디버그 로그를 끄세요. 또한 GUI 프로세스와 코어 프로세스의 사용량을 구분해 인터페이스 리소스를 노드 프로토콜 탓으로 돌리지 않도록 해야 합니다.

휴대전화 배터리 소모는 먼저 연결 동작부터 확인하세요

휴대전화의 배터리 소모는 무선 신호 세기, 데이터 사용량, 기기 깨우기 빈도, 연결 유지 방식의 영향을 함께 받습니다. 신호가 약한 환경에서는 무선 모듈의 송신과 재전송에 드는 비용이 프로토콜 암호화보다 클 수 있습니다. 상태 확인, 구독 업데이트, 연결 유지, 로그 기록을 지나치게 자주 수행하면 기기가 저전력 상태를 유지하기 어려워집니다. 따라서 프로토콜을 선택하기 전에 속도 측정을 너무 자주 실행하는지, 여러 프록시 또는 VPN 앱이 네트워크 진입점을 반복해서 차지하려는지 확인하세요.

연결 유지는 장단점이 있습니다. 간격을 짧게 하면 NAT 매핑이 만료된 뒤 재연결이 줄어들 수 있지만 백그라운드 데이터 사용과 무선 모듈 깨우기가 늘어납니다. 간격이 너무 길면 유지 비용은 줄지만 연결 복구가 늦어질 수 있습니다. QUIC의 연결 이동 기능도 프로토콜 구현, 서버, 클라이언트 설정에 따라 제약을 받습니다. Wi-Fi와 모바일 네트워크를 전환할 때 연결이 절대 끊기지 않는다고 보장하지는 않습니다. 모바일 환경에서는 최고 속도 한 번보다 대기 후 안정적으로 복구되는지가 더 중요할 수 있습니다.

같은 기기와 네트워크, 대상, 비슷한 시간대를 사용해 콜드 스타트 접속, 지속 전송, 일정 시간 대기한 뒤 복구 상태를 각각 기록하세요. 한 번에 노드나 프로토콜 하나만 바꾸고 여러 차례 반복해 추세를 살펴보며 기기 온도도 확인하세요. 배터리를 비교하려면 사용 부하가 비슷해야 하며 충분히 긴 관찰 시간이 필요합니다. 몇 초간의 속도 측정에서 나타난 작은 배터리 변화만으로 특정 프로토콜이 더 절전된다고 판단할 수는 없습니다.

장시간 데이터 전송으로 통화나 웹 응답이 나빠진다면 먼저 대용량 작업을 제한하고 로컬 대기열과 대역폭 설정을 확인한 다음 프로토콜 변경을 고려하세요. 프로토콜은 특정 네트워크 동작을 개선할 수 있지만, 이미 포화된 같은 업로드 회선에 무제한 작업을 동시에 실어 나를 수는 없습니다. 최고 속도 하나만 좇기보다 안정성, 복구 속도, 유지 관리 편의성을 함께 평가하는 편이 일상적인 사용 경험에 더 가깝습니다.

Clash, Meta 및 mihomo

명칭과 기능 범위

원본 Clash는 YAML로 프록시, 정책 그룹, 규칙을 설정하는 방식을 확립했습니다. Clash.Meta는 이 생태계에서 발전한 포크로 프로토콜과 네트워크 기능을 확장했으며, mihomo는 Meta 계열의 발전을 이어갑니다. 오래된 자료와 구독 형식 옵션, 클라이언트 설정에는 여전히 Meta라는 이름이 남아 있을 수 있습니다. Clash Meta 튜토리얼을 볼 때는 이름만으로 적용 가능성을 판단하지 말고, 해당 글에서 말하는 코어 기능을 확인하세요.

원본 Clash도 시기별로 배포 형태가 달랐으며, 오픈소스 구현과 과거의 다른 배포 형태를 같은 기능 집합으로 취급해서는 안 됩니다. 오래된 튜토리얼의 규칙 집합, TUN, 스크립트, 특정 설정 항목은 당시의 특정 구현에만 적용될 수 있습니다. 새 프로토콜을 선택할 때는 실제로 실행 중인 코어와 해당 설정 문서를 직접 확인하세요. 오래된 글의 기능 목록을 모든 Clash 클라이언트의 공통 기준으로 삼지 마세요.

mihomo는 여러 최신 프로토콜과 DNS, TUN, 규칙 기능에 대한 지원을 추가하거나 이어오고 있지만 지원 범위는 구현의 발전에 따라 달라집니다. 설정 문서에 항목이 있어도 오래된 바이너리에서 구현됐다는 보장은 없습니다. 반대로 클라이언트 이름에 Meta가 없다고 해서 mihomo를 사용하지 않는다고 단정할 수도 없습니다. 신뢰할 수 있는 근거는 클라이언트의 코어 정보, 시작 로그, 실제 설정 로드 결과입니다. 앱 아이콘이나 설치 파일 이름만으로 판단하지 마세요.

설정 호환성은 항목별로 확인해야 합니다

기본 포트, 일반적인 정책 그룹과 규칙은 공통 문법이 많아 일부 설정을 이전할 수 있습니다. 그러나 호환성은 설정 파일 전체에 무조건 적용되는 것이 아니라 항목마다 다릅니다. 원본 설정을 mihomo로 옮겨도 폐기된 동작, 경로, 플랫폼별 기능을 확인해야 합니다. VLESS, Hysteria2, TUIC 또는 확장 DNS 항목이 포함된 설정은 구형 코어가 모두 인식할 것이라고 기대해서는 안 됩니다. 알 수 없는 항목은 오류를 내거나 무시될 수 있으며, 어느 경우든 확인이 필요합니다.

클라이언트가 설정을 불러오기 전에 최종 파일을 생성하는 경우도 있습니다. 구독을 병합하고 로컬 포트와 제어 인터페이스를 추가하거나 DNS를 덮어쓰고 규칙을 삽입할 수 있습니다. 구독 원본 파일을 수정했는데 반영되지 않더라도 반드시 코어가 해당 항목을 지원하지 않는다는 뜻은 아닙니다. 후속 덮어쓰기가 변경 내용을 다시 적용했을 수 있습니다. 실행 중인 설정이나 내보내기 기능으로 최종 항목을 확인하고 로그를 비교해 문제를 찾아보세요. 코어에 직접 전달되지 않는 중간 파일을 계속 수정하지 마세요.

클라이언트 선택과 운영체제 연동

데스크톱과 모바일에서는 먼저 Clash Plus 다운로드 및 플랫폼 옵션을 확인하고, 필요한 프로토콜이 대상 운영체제에서 작동하는지 살펴보세요. Linux 데스크톱에서는 다운로드 페이지를 참고해 Clash Verge Rev 또는 FlClash를 선택할 수 있습니다. Windows에서는 Clash Nyanpasu도 비교해 볼 수 있습니다. Clash for Windows와 ClashX Meta는 유지 관리가 중단된 보관용 옵션입니다. 예전 인터페이스를 계속 사용하려는 이유만으로 새 프로토콜 요구 사항의 기본 선택지로 삼는 것은 권장하지 않습니다.

Android에서는 Clash Plus, Clash Meta for Android, FlClash, Surfboard를 비교할 수 있지만, 이 앱들이 모두 같은 코어나 설정 형식을 사용한다는 뜻은 아닙니다. iOS의 네트워크 확장 기능과 백그라운드 동작도 시스템의 영향을 받습니다. 플랫폼 간에 설정을 옮길 때는 데스크톱 설정을 그대로 사용할 수 있다고 가정하지 말고, 필요한 프로토콜 지원 여부, 현재 구독 수신 가능 여부, 트래픽 처리 방식을 다시 확인하세요.

Ubuntu: GUI와 독립 서비스

Ubuntu 데스크톱 사용자는 보통 GUI로 시스템 프록시와 설정을 관리하는 편이 좋습니다. 서버나 부팅 시 실행이 필요한 환경에서는 mihomo를 별도 배포할 수 있지만, 설정 디렉터리와 서비스 사용자, 로그, TUN 권한을 직접 관리해야 합니다. 데스크톱 클라이언트와 systemd 서비스가 같은 포트를 사용하거나 라우팅을 서로 차지하지 않도록 하세요. 자세한 단계는 Ubuntu에 mihomo 코어 배포하기를 참고하세요.

mihomo -v
mihomo -t -d "$HOME/.config/mihomo"

첫 번째 명령은 실제 실행 파일 정보를 확인하고, 두 번째 명령은 지정한 디렉터리의 설정을 코어가 검사할 수 있는지 확인합니다. 관련 명령이 설치되어 있고 디렉터리에 config.yaml이 있어야 합니다. 검사를 통과했다는 것은 로드 단계에서 해당 오류가 발견되지 않았다는 뜻일 뿐, 노드에 연결할 수 있다는 뜻은 아닙니다. 업그레이드 전에 설정과 기존 실행 파일을 저장하고, 검사한 뒤 서비스를 교체하세요. 코어 업그레이드, 구독 갱신, 라우팅 변경을 한꺼번에 진행하지 않는 것이 좋습니다.

구독 형식 및 설정 호환성

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

공유 링크는 일반적으로 노드 하나를 설명하며, 프로토콜 접두사 뒤에 인코딩된 인증 정보와 쿼리 매개변수가 포함될 수 있습니다. 노드 목록은 여러 링크의 모음일 수도 있고 YAML의 프록시 항목일 수도 있습니다. 전체 설정에는 여기에 정책 그룹, 규칙, DNS, 로컬 수신 설정까지 포함됩니다. 각 형식의 역할은 다릅니다. 앱에서 공유 링크를 가져올 수 있다고 해서 전체 Clash YAML을 읽을 수 있는 것은 아닙니다. YAML을 읽을 수 있어도 모든 프록시 유형을 지원한다는 뜻은 아닙니다.

구독 주소는 콘텐츠를 가져오는 진입점일 뿐입니다. 같은 서비스에서도 선택한 형식이나 요청 매개변수에 따라 다른 데이터를 반환할 수 있으며, 파일 확장자로 실제 구조를 정확히 알 수는 없습니다. 가져온 뒤 목록이 비어 있다면 먼저 클라이언트에서 요구하는 구독 유형을 확인한 다음 로그인 페이지, 오류 문구, 호환되지 않는 형식이 반환되지 않았는지 살펴보세요. 개인 구독 식별 정보가 포함된 전체 주소를 공개 페이지에 붙여넣지 마세요. 다른 사람이 구독 내용을 가져가거나 사용량을 소진할 수 있습니다.

구독 변환의 기능과 한계

구독 변환 도구는 공유 링크를 YAML 노드로 바꾸고 정책 그룹과 규칙을 조합하는 등 표현 형식을 변경할 수 있습니다. 하지만 서버에 프로토콜 기능을 추가하거나 TUIC를 지원하지 않는 코어에 TUIC 구현을 제공할 수는 없습니다. 변환기가 특정 항목을 이해하지 못하면 플러그인 매개변수, TLS 이름, 특수 전송 옵션을 버릴 수 있습니다. 이 경우 기본 노드는 목록에 표시되더라도 실제 핸드셰이크에 필요한 정보가 사라진 상태일 수 있습니다.

서비스 제공자가 직접 제공하고 현재 코어와 호환되는 설정 형식을 우선 사용하세요. 변환이 꼭 필요하다면 신뢰할 수 있고 실제로 필요한 방식만 선택하고, 구독 내용이 누구에게 전달되는지 이해해야 합니다. 온라인 변환 서비스는 프로토콜 이름뿐 아니라 서버 주소와 인증 정보까지 처리할 수 있습니다. 변환 결과에서는 노드 이름과 개수만 확인하지 말고 프로토콜 유형, 인증 항목, 보안 계층, 전송 옵션을 중점적으로 비교하세요.

YAML 최상위 계층과 정책 그룹 참조

튜토리얼의 general은 기본 설정 구간을 가리키는 표현으로 자주 쓰이지만, 실제 파일에 넣어야 하는 최상위 키는 아닙니다. 포트와 모드 같은 항목은 YAML 최상위 계층에 바로 배치해야 합니다. 아래의 최소 예시는 원격 노드를 포함하지 않으며 로컬 수신, 정책 그룹 참조, 기본 규칙을 이해하는 데 사용할 수 있습니다. 이 예시는 직접 연결 출구를 선택할 뿐, 원격 프록시를 만들어내지는 않습니다. 실제 노드는 유효한 구독이나 서버 매개변수로 제공해야 하며, 예시에서 인증 정보를 추측해서는 안 됩니다.

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

proxy-groups:
  - name: 직접 연결 선택
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,직접 연결 선택

YAML은 공백으로 계층을 표현합니다. 목록 항목 앞의 하이픈과 같은 계층에 있는 항목의 들여쓰기를 일관되게 유지하세요. 정책 그룹을 참조할 때는 정확한 이름을 사용해야 하며, 이름을 바꾸면 규칙과 다른 그룹의 참조도 함께 수정해야 합니다. 이름이 중복되거나 존재하지 않는 노드가 참조되거나 그룹 간 순환 참조가 생기면 설정을 불러오지 못하거나 예상하지 못한 동작이 발생할 수 있습니다. 7890 포트를 다른 프로세스가 사용 중이라면 포트 사용 충돌 해결 방법을 확인한 뒤 앱의 프록시 설정도 함께 변경하세요.

구독을 갱신하면 수정 내용이 덮어써지는 이유

원격 구독에서 내려받은 내용을 직접 수정하면 다음 새로고침 때 새 내용으로 교체되는 경우가 많습니다. 클라이언트에서 명시적으로 지원하는 로컬 덮어쓰기, 설정 병합, 규칙 확장 기능을 사용하고 적용 순서를 기록하는 편이 안전합니다. proxy-providers는 정해진 형식의 프록시 모음을 불러오는 데 사용하고, rule-providers는 규칙 모음을 불러오는 데 사용합니다. 두 항목은 임의의 전체 설정을 가져오는 범용 기능이 아닙니다. 최상위 설정이 모두 포함된 파일을 노드 제공자 파일로 마음대로 사용할 수는 없습니다.

설정 호환성에는 DNS도 포함됩니다. 노드를 정상적으로 가져왔더라도 도메인 조회에 문제가 있으면 웹페이지가 열리지 않을 수 있습니다. fake-ip는 요청 진입점과 DNS 조회 경로가 함께 작동해야 하므로 항목 하나만 켰다고 DNS가 처리되고 있다고 단정할 수 없습니다. 전체 조회 흐름은 nameserver, fallback, DNS 가로채기 항목 설명에서 확인하세요. 구독을 이전할 때는 기본 연결을 먼저 검증한 뒤 사용자 지정 DNS와 규칙을 단계별로 복원해야 차이가 생긴 계층을 찾기 쉽습니다.

사용 환경별 선택과 결과 검증

일상적인 데스크톱 사용: 먼저 이해하기 쉬운 연결을 선택하세요

일상적인 웹 검색, 문서 동기화, 개발 도구 사용에는 안정적인 연결과 관리하기 쉬운 설정이 우선입니다. 이미 검증된 SS, Trojan 또는 다른 TCP 기반 진입점이 있다면 프로토콜 이름을 좇아 바꿀 필요가 없습니다. 클라이언트는 Clash Plus를 먼저 살펴보고 운영체제와 필요한 기능에 따라 다른 옵션을 비교할 수 있습니다. 규칙 모드로 프록시가 필요한 요청과 직접 접속할 요청을 구분하면 전송 확장을 더 많이 켜는 것보다 불필요한 우회를 줄이는 데 효과적일 수 있습니다.

개발 도구 중에는 환경 변수나 자체 프록시 설정만 읽고 시스템 프록시를 사용하지 않는 경우도 있습니다. 브라우저는 정상인데 터미널만 실패한다면 도구의 프록시 진입점과 인증서 환경을 먼저 확인하세요. 기업용 소프트웨어에는 자체 네트워크 스택이나 접속 정책이 있을 수 있습니다. 적절한 환경에서 TUN을 진입점으로 사용할 수 있지만, 활성화한 뒤에는 라우팅, DNS, 로컬 네트워크 접속 여부를 확인해야 합니다. 앱이 프록시를 사용하지 않는 문제를 노드 프로토콜 탓으로 돌리지 마세요.

모바일 네트워크: 복구와 대기 상태를 함께 테스트하세요

Wi-Fi와 모바일 네트워크를 자주 전환한다면 전환 직후 첫 요청, 대기 후 복구, 음성 통화의 지속성, 백그라운드 배터리 소모를 살펴보세요. Hysteria2와 TUIC도 비교 대상으로 삼을 수 있지만, 대상 네트워크에서 작동이 확인된 TCP 기반 대안은 남겨두세요. 특정 공용 네트워크에서만 QUIC 연결이 실패한다면 인증 정보를 바로 바꾸기보다 UDP 경로가 제한되는지 확인하세요. 같은 설정이 다른 네트워크에서는 작동한다는 점도 문제를 찾는 데 유용한 단서입니다.

모바일에서는 VPN이나 네트워크 확장 기능을 관리하는 운영체제의 동작도 고려해야 합니다. 백그라운드 제한, 다른 VPN 앱 실행, 시스템 절전 설정, 네트워크 권한 변경이 연결을 끊을 수 있습니다. 프로토콜을 계속 바꾸기보다 불필요한 상태 확인 빈도를 줄이고 지나치게 짧은 연결 유지 간격을 피하는 것이 먼저입니다. 진입점, 권한, 백그라운드 상태를 동일하게 맞춰야 프로토콜별 배터리 차이를 의미 있게 비교할 수 있습니다.

대용량 트래픽과 저전력 기기: 병목을 찾으세요

장시간 다운로드, 원격 백업, 높은 동시 접속이 필요한 경우 서버 부하, 업로드 대기열, 기기 온도, 단일 코어 사용률을 살펴보세요. 프로세서가 먼저 한계에 도달한다면 캡슐화가 적고 하드웨어 가속을 지원하는 방식을 비교해 볼 수 있습니다. 패킷 손실과 회선 변동이 주된 문제라면 QUIC 기반 방식을 테스트하세요. 라우터는 프로세서 아키텍처와 메모리 용량, UDP 처리 성능도 확인해야 합니다. 데스크톱에서 얻은 테스트 결과를 그대로 적용할 수는 없습니다.

Ubuntu 서버 배포에서는 일반적으로 서비스 관리, 복구 가능성, 최소 권한이 중요합니다. 먼저 일반 로컬 프록시로 코어와 노드가 작동하는지 확인한 다음 필요에 따라 TUN, 라우팅, 부팅 시 서비스를 추가하세요. 변경할 때마다 설정을 검사하고 관련 서비스를 다시 시작한 뒤 로그를 확인하세요. 데스크톱 클라이언트와 서비스가 동시에 네트워크를 처리하지 않도록 해야 합니다. 원격으로 라우팅을 변경할 때는 별도의 관리 경로와 되돌릴 방법을 마련해 한 번의 설정 오류로 유지 관리 연결이 끊기는 상황을 막으세요.

재현 가능한 문제 해결 절차 만들기

완전한 검증은 네 단계로 진행할 수 있습니다. 먼저 요청이 로컬 코어에 들어오는지 확인하고, 다음으로 서버 연결 여부를 확인합니다. 그런 다음 대상 도메인의 DNS 조회와 규칙 적용을 확인하고 마지막으로 실제 앱이 작동하는지 검증합니다. 로그에서 인증 실패가 나타나면 인증 정보를 다시 확인하고, 인증서 오류라면 시스템 시각과 이름을 점검하세요. 연결 시간 초과는 네트워크, 포트, 프로토콜을 함께 살펴봐야 합니다. 오류 유형마다 확인할 변수가 다르므로 클라이언트를 무작정 재설치해도 문제를 밝힐 추가 근거가 생기지는 않습니다.

작동하는 설정을 비교 기준으로 보관하고, 변경할 때는 어떤 항목을 바꿨는지, 어떤 네트워크에서 테스트했는지, 결과가 어떻게 달라졌는지 기록하세요. 로그를 공유하기 전에 구독 주소, 인증 정보, 개인 접속 기록을 가리세요. 겉으로 연결되는 것처럼 보이게 하려고 보안 검증을 끄지 마세요. 단계별 설정으로 돌아가려면 시작 가이드를 계속 확인하세요. 특정 앱이나 설정 단계에서만 문제가 발생한다면 자주 묻는 질문에서 해당 문제를 찾아볼 수 있습니다. 프로토콜 선택의 최종 기준은 요구 사항을 검증할 수 있고, 장애 원인을 설명할 수 있으며, 설정을 장기간 유지 관리할 수 있는지입니다.