Clash 프록시 프로토콜 및 코어 기술 가이드

1. 프로토콜 선택 전 확인할 사항

클라이언트, 코어, 노드는 각자 역할이 다릅니다

클라이언트는 구독 관리, 시스템 프록시 설정, 구성 편집, 로그 표시를 담당하는 조작 창구입니다. 코어는 구성을 해석하고 규칙을 적용해 실제 연결을 만듭니다. 노드는 서버가 제공하는 연결 지점입니다. 화면에 프로토콜 이름이 표시된다고 해서 현재 기기에서 완벽하게 지원된다는 뜻은 아닙니다. 코어 구현, 빌드 옵션, 플랫폼의 네트워크 권한을 확인해야 합니다. 반대로 코어가 지원하는 필드라도 클라이언트의 그래픽 편집기에는 아직 표시되지 않을 수 있습니다.

선택은 새로워 보이는 이름을 먼저 고르는 대신 현재 사용하는 구독을 기준으로 시작해야 합니다. 서버가 어떤 프로토콜을 제공하는지, UDP 전달을 허용하는지, 인증서 도메인이 필요한지 확인한 뒤 클라이언트가 설정을 그대로 가져올 수 있는지 살펴보세요. 일반적으로 노드의 프로토콜은 로컬에서 임의로 바꿀 수 없습니다. 설정의 SS를 Trojan으로 바꿔도 서버가 수신 방식을 바꾸지는 않습니다. 연결을 시작할 때 양쪽이 서로의 데이터를 이해하지 못하게 될 뿐입니다.

프로토콜, 전송 방식, 보안 계층을 구분하세요

프록시 프로토콜은 대상 주소와 인증 정보, 데이터를 표현하는 방식을 정합니다. 하위 전송 계층은 TCP와 UDP 중 무엇을 사용할지, WebSocket이나 gRPC 같은 캡슐화를 적용할지를 결정합니다. TLS는 보안 연결에서 인증과 암호화를 처리합니다. 같은 VLESS라도 전송 방식과 보안 설정의 조합은 여러 가지이며, 이에 따라 핸드셰이크 횟수와 사용 가능한 네트워크 환경, 필요한 매개변수가 달라집니다. 따라서 비교할 때는 목록의 유형만 보지 말고 전체 조합을 기록하세요.

노드 프로토콜과 기기에서 트래픽을 전달하는 방식도 구별해야 합니다. 시스템 프록시, TUN, 혼합 포트는 기기가 트래픽을 클라이언트에 넘기는 경로입니다. 규칙 모드, 전역 모드, 직접 연결은 트래픽이 어떤 출구를 이용할지 정하는 정책입니다. TUN을 켠다고 SS가 QUIC 프로토콜로 바뀌지 않으며, 전역 모드를 선택한다고 UDP를 지원하지 않던 서버가 게임 데이터를 갑자기 처리하는 것도 아닙니다. 앱이 인터넷에 연결되지 않을 때는 먼저 트래픽이 코어에 전달되는지 확인하고, 그다음 출구가 사용 가능한지 점검하세요.

비교할 때는 조건을 통제하세요

연결 속도는 최소 세 단계로 나눠 볼 수 있습니다. 서버 주소를 찾는 단계, 프록시 연결을 수립하는 단계, 서버에서 대상 서비스에 접속하는 단계입니다. 노드 테스트 결과는 이 중 일부만 반영하는 경우가 많고, 테스트 주소와 캐시, 연결 재사용의 영향을 받습니다. 목록에서 숫자가 작다고 모든 웹 리소스가 더 빨리 열리거나 동영상 버퍼링이 줄어드는 것은 아닙니다. 프로토콜 캡슐화에 필드 몇 개가 추가되는 것보다 서버 부하, 출구 경로, 대상 웹사이트까지의 거리가 더 큰 영향을 미칠 때가 많습니다.

실제로 비교할 때는 기기, 네트워크, 대상 웹사이트, 대략적인 시간대를 동일하게 맞추고 각 조합을 여러 번 테스트하세요. 첫 접속, 연속 탐색, 파일 전송, 대기 후 복구를 각각 기록합니다. 무선 신호 변화나 서버 혼잡을 프로토콜 차이로 오인하지 마세요. 특히 휴대폰에서는 화면을 켠 직후 첫 요청에 무선 링크를 깨우는 과정이 포함될 수 있습니다. 이는 다운로드를 계속할 때의 성능과 다른 지표이므로 나누어 살펴봐야 합니다.

이후 비교는 위 기준을 바탕으로 진행합니다. 모든 프로토콜에 고정 순위를 매기는 것이 아니라 현재 기기에서 관리하기 쉽고 설정이 완전하며 안정적으로 작동하는 조합을 찾는 것이 목적입니다. “어떤 프로토콜이 더 빠르다”는 말을 외우기보다 문제가 어느 단계에서 발생했는지 파악하는 편이 유용합니다. 네트워크나 클라이언트를 바꿔도 이 판단 방식은 계속 적용할 수 있습니다.

2. SS와 VMess: 간결한 데이터 흐름과 구조화된 인증

SS의 배경과 구현상 한계

Shadowsocks는 보통 SS라고 줄여 부르며, 클라이언트와 서버가 공유하는 키를 사용해 연결을 중계합니다. 비교적 간결한 암호화 프록시 데이터 흐름을 중심으로 설계되었습니다. SS는 하나의 고정된 암호화 알고리즘을 뜻하지 않습니다. 설정의 암호화 방식에 따라 키와 난수, 데이터 레코드의 처리 방법이 달라집니다. SS를 비교할 때는 암호화 방식도 함께 확인해야 합니다. 서로 다른 방식과 구현, 하드웨어의 리소스 사용량을 한데 묶어 비교해서는 안 됩니다.

일반적인 AEAD 방식은 암호화와 무결성 보호를 결합해 현대 SS의 기본 작동 방식을 이해하는 데 도움이 됩니다. 이후 등장한 방식 계열은 각자의 키 형식과 구현 요건을 갖습니다. 구독에 SS 유형이 표시되어도 모든 SS 방식이 지원된다고 단정할 수는 없습니다. 가져온 뒤 암호화 방식을 인식하지 못한다는 메시지가 뜨면 먼저 코어 지원 여부와 키 형식을 확인하세요. 임의로 다른 방식 이름으로 바꾸는 것만으로 해결하려 하지 마세요. 서버도 같은 설정을 사용해야 합니다.

플러그인을 추가하지 않는 일반적인 구성에서 SS의 연결 구조는 비교적 단순하며 별도의 외부 TLS 핸드셰이크에 의존하지 않습니다. 연결 준비 과정 일부를 줄일 수는 있지만, 이를 근거로 항상 더 빠르다고 보장할 수는 없습니다. 설정에 플러그인이 필요하다면 클라이언트와 코어 모두 해당 플러그인 형식을 지원해야 합니다. 모바일과 데스크톱에서 제공하는 플러그인 목록이 다를 수 있습니다. 서버, 포트, 비밀번호를 복사하면서 플러그인 옵션을 빠뜨리면 인증 단계에 이르기도 전에 연결이 끊길 수 있습니다.

VMess에는 왜 설정 항목이 더 많을까요?

VMess는 V2Ray 생태계에서 시작된 프로토콜로, 프록시 데이터에 인증 등의 구조를 도입하고 여러 전송 방식과 조합할 수 있습니다. 일반적인 설정에는 사용자 식별자와 암호화 옵션, 전송에 필요한 경로나 호스트 정보가 포함됩니다. 다양한 조합을 구성할 수 있는 만큼 문제 해결 시 비밀번호 항목 하나만 확인해서는 부족합니다. 최신 인증 방식을 사용하는 서버에 오래된 가이드의 과거 설정을 적용하면 가져오기는 성공해도 실제 연결은 실패할 수 있습니다.

VMess 인증에는 시간 정보가 영향을 줍니다. 기기의 시스템 시간이 크게 어긋나면 주소와 사용자 식별자가 정확해도 인증에 실패할 수 있습니다. 여러 VMess 노드가 동시에 작동하지 않지만 다른 프로토콜은 정상이라면 시스템 자동 시간 설정을 먼저 확인하고 코어 로그에서 인증 관련 내용을 살펴보세요. 처음부터 클라이언트 전체를 다시 설치할 필요는 없습니다. 오래된 설정에 추가 식별자 매개변수가 있다면 과거 스크린샷을 따라 임의로 넣지 말고 서비스 제공자의 최신 안내를 따르세요.

TCP·UDP와 외부 캡슐화의 차이

SS와 VMess 모두 프로토콜 이름만으로 UDP를 사용할 수 있는지 판단할 수 없습니다. 서버에서 관련 전달 기능을 활성화했는지, 클라이언트가 앱 데이터를 코어로 전달하는지, 중간 네트워크에서 해당 경로를 허용하는지 확인해야 합니다. 웹페이지 하나가 열린다고 해서 음성 통화, 게임, 실시간 회의 데이터도 전달된다는 뜻은 아닙니다. 테스트할 때는 실제로 해당 전송 방식에 의존하는 앱을 사용하고 로그를 함께 확인하세요. 웹페이지 테스트 하나만 보고 판단하지 마세요.

VMess에 WebSocket이나 다른 전송 방식을 추가하면 해당 캡슐화의 처리와 연결 준비 과정이 더해집니다. 내부 데이터가 안정적인 TCP 연결 하나에 실릴 경우 패킷 손실이 발생하면 앞선 바이트가 복구될 때까지 뒤의 데이터가 기다릴 수 있습니다. 연결 재사용으로 짧은 연결의 부담을 줄일 수 있는지는 서버와 구현에 따라 다릅니다. 여러 업무가 같은 연결을 공유하면 혼잡이나 장애의 영향도 함께 받을 수 있으므로 재사용을 모든 상황의 기본 최적화로 여겨서는 안 됩니다.

일상적인 웹 탐색, 문서 동기화, 중간 규모 파일 전송에는 설정이 명확한 SS를 간결한 기준으로 삼을 수 있습니다. 이미 완전한 VMess 구성을 사용 중이라면 인증과 외부 전송 방식의 호환성을 확인하세요. 둘 중 무엇을 선택할지는 대체로 서버 품질과 설정의 신뢰성에 달려 있습니다. 특정 프로토콜이 모든 기기에서 본질적으로 메모리나 배터리를 덜 사용한다고 볼 수는 없습니다.

3. Trojan과 VLESS: TLS 및 전송 조합 이해하기

Trojan은 보안 연결 안에서 인증을 처리합니다

Trojan은 일반적으로 먼저 TLS 보안 연결을 수립한 뒤 그 안에서 프록시 인증과 데이터 전달을 처리합니다. 검증된 보안 전송 방식으로 암호화와 서버 신원 확인을 수행하고, 프록시 프로토콜 자체는 비교적 단순하게 유지합니다. 클라이언트 설정에서는 서버 주소와 포트, 비밀번호뿐 아니라 인증서 검증에 사용할 이름도 확인해야 합니다. 연결 주소로 IP를 쓸 수 있지만 인증서는 보통 도메인에 발급되므로 두 값이 항상 같지는 않습니다.

SNI는 TLS 핸드셰이크에서 서버에 접속하려는 이름을 전달합니다. 클라이언트는 구현과 설정에 따라 인증서의 신원도 확인해야 합니다. 이름을 잘못 입력하면 다른 사이트로 연결되거나 인증서 오류가 발생할 수 있습니다. 서비스 제공자가 별도의 서버 이름을 알려줬다면 그대로 유지하세요. 서버 주소에 도메인이 들어 있다고 해서 해당 값을 삭제해도 된다는 뜻은 아닙니다. 인증서 만료, 기기 시간 오류, 신뢰 체인 누락도 프록시 인증 전에 연결을 끊을 수 있으므로 각각 점검해야 합니다.

VLESS가 가볍다고 해서 자체 암호화를 제공하는 것은 아닙니다

VLESS도 V2Ray 생태계에서 시작되었으며, 비교적 간결한 프록시 프로토콜 구조가 특징입니다. 일반적인 사용 방식에서는 외부 보안 계층으로 전송을 보호합니다. 사용자 식별자는 프로토콜에 필요한 신원 정보를 제공하지만 만능 암호화 스위치는 아닙니다. 설정의 암호화 필드가 비어 있거나 특정 비활성화 값으로 표시되어도 외부 TLS 등의 설정을 무시한 채 연결 전체가 암호화되지 않는다고 단정해서는 안 됩니다. 반대로 VLESS라는 이름만으로 보안이 보장된다고 여겨서도 안 됩니다.

VLESS는 실제로 TCP, WebSocket, gRPC와 TLS 또는 REALITY 같은 보안 설정을 조합할 수 있습니다. 각 항목은 서로 다른 문제를 해결하므로 VLESS 지원이 모든 조합의 지원을 의미하지는 않습니다. REALITY에는 공개 키와 짧은 식별자, 서버 이름 등의 매개변수가 필요하며 흐름 제어 옵션에도 조합상 제약이 있습니다. 화면에서 설정을 저장할 수 있다고 해서 해당 플랫폼의 코어가 실행할 수 있는 것은 아닙니다. 실제 로그와 유지 관리자의 기능 안내를 기준으로 확인하세요.

같은 프로토콜도 연결 부담이 다른 이유

일반적인 TCP와 TLS 조합은 하위 연결과 보안 핸드셰이크를 준비해야 합니다. 여기에 WebSocket을 추가하면 보통 업그레이드 과정도 필요합니다. gRPC는 HTTP/2 등의 메커니즘에 의존하며 자체적인 스트림 관리와 구현 특성이 있습니다. 연결 재사용과 세션 복구, 기존 연결의 유효 여부에 따라 이후 요청의 비용도 달라집니다. 따라서 첫 방문은 느리지만 연속 방문은 정상이라면 지속 전송 대역폭이 부족한 것이 아니라 연결 준비에 시간이 걸리는 것일 수 있습니다.

짧은 연결을 자주 만드는 작업에서는 핸드셰이크와 주소 확인, 스케줄링의 비중이 커지는 편입니다. 지속 다운로드에서는 회선 용량과 패킷 손실, 혼잡 제어의 차이가 더 잘 드러납니다. 서버에서 여러 조합을 제공한다면 매개변수가 적고 클라이언트가 명확히 지원하는 방식으로 기준을 먼저 세운 뒤 외부 캡슐화의 효과를 비교하세요. 전송 방식 이름이 익숙하다는 이유로 서비스 제공자가 지정한 경로, 서비스 이름, 호스트 필드를 삭제하지 마세요. 서버 라우팅에 사용될 수 있습니다.

문제를 해결할 때 인증서 오류가 발생하면 신원 확인을 계속 끄기보다 이름과 시간, 서버 인증서를 바로잡으세요. 인증을 끄면 서버 신원 확인이 약해지고 설정 오류가 일시적으로 가려질 수 있습니다. 초보자라면 복잡한 조합을 직접 입력하는 것보다 완전한 구독을 사용하는 편이 대체로 안전합니다. 구독이 어떤 필드를 보존하는지 알아보려면 이 페이지의 구독 호환성 섹션을 확인하세요.

4. Hysteria2와 TUIC: QUIC 기반 전송의 장단점

QUIC은 연결을 전달하는 방식을 바꿉니다

QUIC은 UDP 위에서 보안 연결, 신뢰성 있는 스트림, 혼잡 제어 등의 기능을 구현합니다. 신뢰성 처리를 앱에 떠넘기는 단순한 방식도 아니며 UDP를 사용한다고 해서 본질적으로 TCP보다 빠른 것도 아닙니다. 일부 패킷 손실 상황에서 서로 다른 데이터 흐름이 기다리는 시간을 줄일 수 있지만, 하나의 흐름 안에서는 여전히 순서대로 데이터를 전달해야 합니다. 모든 흐름은 공용 회선 용량의 제약도 받습니다. 무선 신호가 나쁘거나 출구가 혼잡하거나 서버 부하가 높으면 QUIC으로 바꿔도 문제가 사라지지 않습니다.

Hysteria2와 TUIC은 모두 QUIC 관련 기능을 기반으로 하지만 서로 바꿔 쓸 수 있는 프로토콜은 아닙니다. 인증과 전달 방식, 설정 매개변수, 혼잡 제어 선택이 다르므로 서버 유형과 클라이언트 설정이 일치해야 합니다. 기존 Hysteria 설정의 유형 이름만 바꿔 Hysteria2로 사용할 수도 없습니다. 가져올 때 지원하지 않는 유형이라는 오류가 나면 먼저 프로토콜 세대와 코어 지원 범위를 확인한 다음 필드 변환을 살펴보세요.

Hysteria2의 대역폭 설정값은 속도 측정 결과가 아닙니다

Hysteria2는 지연 시간이 길거나 패킷 손실이 있는 회선에서 사용할 수 있는 전송 방식입니다. 일반적인 구현에서는 설정한 예상 대역폭을 전송 제어에 반영할 수 있으며 혼잡 제어 동작도 달라질 수 있습니다. 구독의 업로드·다운로드 매개변수는 대개 설정 목표나 참고값이지 클라이언트가 측정한 실제 속도가 아닙니다. 서버가 동작을 제한할 수도 있으므로 화면의 대역폭 숫자를 보장된 실제 속도로 해석해서는 안 됩니다.

예상 대역폭을 실제 연결 용량보다 훨씬 높게 설정하면 대기열과 패킷 손실이 늘어 통화와 웹 탐색에 영향을 줄 수 있습니다. 여러 기기가 함께 쓰는 가정용 네트워크에서는 특히 주의해야 합니다. 다운로드 하나의 속도가 높아졌다고 전체 사용 경험이 좋아진 것은 아닙니다. 클라이언트에 관련 설정이 있다면 먼저 서비스 제공자의 값을 유지하세요. 조정이 필요하면 회선 대역폭과 업로드 병목, 다른 기기의 사용량을 고려해 조금씩 시험하고 부하가 높은 상황에서도 웹페이지가 제때 응답하는지 기록하세요.

TUIC도 구현 방식과 인증 설정을 확인해야 합니다

TUIC은 QUIC 연결 위에서 프록시 트래픽을 전달하며 여러 업무 흐름을 처리하고 UDP 전달 기능을 제공합니다. 프로토콜 세대와 구현에 따라 인증 방식과 설정 필드가 다를 수 있으므로 오래된 연결 정보 하나만으로 최신 코어가 가져오기를 지원한다고 단정해서는 안 됩니다. 클라이언트에 TUIC이 표시되어도 서버가 요구하는 인증 정보와 서버 이름, 혼잡 제어 옵션을 확인하세요. 주소만 입력하고 기본값이 맞기를 기대하지 마세요.

혼잡 제어는 피드백에 따라 전송량을 늘리거나 줄이는 방식을 정하며, 더 공격적이라고 항상 좋은 것은 아닙니다. 알고리즘마다 패킷 손실과 대기열, 공정성 측면의 장단점이 있고 구현도 유지 관리 과정에서 바뀔 수 있습니다. 통제된 테스트 없이 특정 알고리즘이 항상 일정 비율의 성능 향상을 보장한다고 단정하지 마세요. 서버와 클라이언트가 모두 명확히 지원하는 옵션을 우선 사용하고, 지속 전송뿐 아니라 같은 네트워크의 다른 앱이 영향을 받는지도 확인하세요.

사용 전 UDP 연결 가능 여부를 확인하세요

일부 게스트 Wi-Fi와 기업 네트워크, 모바일 네트워크는 UDP를 제한하거나 장시간 연결에 다르게 대응할 수 있습니다. 이때 TCP 기반 노드는 작동하지만 QUIC 기반 노드는 시간 초과가 발생해도 인증 정보 오류라고 단정할 수 없습니다. 같은 기기에서 다른 네트워크로 전환해 다시 테스트하고 로그가 주소 확인, 핸드셰이크, 인증 중 어느 단계에서 멈췄는지 확인하세요. 서버와 설정을 그대로 둔 상태에서 네트워크를 바꿨을 때의 차이는 중요한 단서입니다.

QUIC은 연결 마이그레이션을 지원할 수도 있지만 휴대폰이 Wi-Fi에서 셀룰러 네트워크로 전환된 뒤 원활하게 복구될지는 클라이언트와 운영체제, 네트워크 주소 변환, 서버 구현에 따라 달라집니다. 완전히 끊기지 않는다고 보장할 수는 없습니다. 게임을 하려면 게임 트래픽이 프록시로 전달되는지, 노드가 해당 UDP 전달을 허용하는지도 확인하세요. 게임 데이터를 전달할 수 있는 것과 게임 왕복 지연 시간이 줄어드는 것은 별개의 문제입니다.

5. 연결 속도, 리소스 사용량과 휴대폰 배터리

성능을 네 가지 사용 경험으로 나눠 살펴보세요

첫 접속 속도에는 도메인 확인과 핸드셰이크, 대상 사이트 응답이 영향을 줍니다. 지속 전송 속도는 회선 용량과 패킷 손실, 서버 출구에 더 크게 좌우됩니다. 반응성은 요청이 제때 처리되는지를 보여주며, 복구 성능은 화면을 끄거나 네트워크를 바꾸거나 한동안 사용하지 않은 뒤 얼마나 빨리 다시 쓸 수 있는지를 나타냅니다. 네 지표의 결과는 서로 다를 수 있습니다. 계속 다운로드할 때 빠른 노드가 자주 깨어나는 소량 요청에도 적합한 것은 아니며 첫 접속이 다소 느려도 이후 장시간 전송에는 지장이 없을 수 있습니다.

프로토콜은 이 중 일부에만 영향을 미칩니다. 최신 기기는 암호화 연산을 하드웨어로 가속할 수 있으며, 구체적인 암호화 방식과 프로세서 구현에 따라 CPU 사용량이 달라집니다. 캡슐화 계층 수와 패킷 빈도, 연결 재사용 정책도 스케줄링 부담에 영향을 줍니다. 데스크톱에서 측정한 사용량을 저전력 휴대폰에 그대로 적용하거나, 서버가 다른 두 번의 다운로드로 프로토콜의 리소스 순위를 매겨서는 안 됩니다. 메모리 사용량에는 연결 수와 규칙, 캐시도 포함됩니다.

휴대폰 배터리는 암호화 옵션 하나로 결정되지 않습니다

휴대폰으로 셀룰러 네트워크를 사용할 때는 무선 링크를 저전력 상태에서 깨우고 활성 상태로 유지하는 데 배터리가 소모될 수 있습니다. 잦은 연결 유지 신호와 작은 패킷, 재시도, 백그라운드 앱의 접속도 통신 모듈을 계속 작동하게 합니다. 한 번의 처리가 가벼운 프로토콜이라고 해서 기기 전체의 배터리 소모가 반드시 적은 것은 아닙니다. 연결이 반복해서 끊기고 다시 만들어지면 핸드셰이크와 무선 링크 재활성화에 드는 총비용이 더 커질 수도 있으므로 실제 사용 시간 전체를 관찰해야 합니다.

TUN은 더 넓은 범위의 트래픽을 처리하므로 이전에는 프록시를 거치지 않던 백그라운드 연결까지 전달할 수 있습니다. 따라서 TUN을 켜기 전후의 배터리 차이가 출구 프로토콜의 부담 때문이 아닐 수 있습니다. 규칙 규모와 로그 수준, 연결 스니핑, DNS 요청, 자동 테스트에도 추가 작업이 필요합니다. 배터리 문제를 확인할 때는 트래픽 전달 방식을 일정하게 유지하고 불필요한 고빈도 테스트와 상세 로그를 먼저 끈 뒤 노드 프로토콜을 비교하세요. 여러 변수를 함께 바꾸면 원인을 파악하기 어렵습니다.

연결 유지, 재사용, 유휴 시간 제한을 함께 살펴보세요

연결 유지 신호를 자주 보내면 중간 네트워크의 주소 매핑이 유지되어 유휴 상태 이후 재연결이 줄어들 수 있지만 백그라운드 기동은 늘어날 수 있습니다. 간격이 너무 길면 매핑이 먼저 만료되어 다음 요청에서 연결을 다시 만들어야 할 수 있습니다. 적절한 값은 네트워크 장비와 통신 환경, 서버의 시간 제한에 따라 달라지므로 모든 휴대폰에 같은 간격을 적용할 수 없습니다. 서비스 제공자가 설정값을 지정했다면 먼저 현상을 기록하고, 관련 설정을 한 번에 하나씩 조정하세요.

연결 재사용은 일부 연결 준비 비용을 줄이지만 여러 작업이 하나의 연결에서 혼잡과 장애, 유휴 처리를 공유하게 만들 수도 있습니다. 지속 전송에서 절약한 핸드셰이크 비용이 모든 상황에서 공유에 따른 영향을 상쇄하는 것은 아닙니다. 특히 대화형 작업과 대용량 다운로드를 함께 할 때 웹페이지가 눈에 띄게 느려지는지 확인하세요. 서버 기능을 잘 모른다면 여러 재사용 확장 기능을 임의로 함께 켜지 않는 편이 좋습니다. 먼저 구독의 기본 동작으로 안정적인 기준을 만든 뒤 비교하세요.

배터리를 비교할 때는 사용 시간과 화면 밝기를 비슷하게 맞춰야 합니다. 시스템 배터리 통계에서는 네트워크 서비스의 소모량이 어떻게 분류되는지도 확인하세요. 기기 발열과 시스템 업데이트, 백그라운드 동기화가 결과에 영향을 줄 수 있습니다. 이상이 있으면 모든 프로토콜을 바로 바꾸기보다 지속적인 재시도와 백그라운드 트래픽, 반복 연결부터 살펴보세요. 설정과 현상을 기록한 뒤 자주 묻는 질문을 참고해 원인을 하나씩 좁힐 수 있습니다.

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

“Clash”는 생태계나 특정 코어를 가리킬 수 있습니다

원본 Clash는 널리 쓰이는 규칙과 정책 그룹, YAML 설정 방식의 기반을 마련했습니다. 이후 다양한 포크와 파생 구현, 그래픽 클라이언트가 등장했습니다. 이름에 Clash가 들어간 프로그램이라도 같은 코어를 실행한다고 볼 수는 없습니다. 원본 프로젝트는 유지 관리가 중단되었으며, 구형 클라이언트에 포함된 코어 기능도 구독을 업데이트한다고 자동으로 늘어나지 않습니다. 이 점을 이해해야 같은 파일이 한 기기에서는 작동하고 다른 기기에서는 알 수 없는 프로토콜이나 필드 오류를 표시하는 이유를 파악할 수 있습니다.

Clash Meta는 이 생태계에서 기능을 확장한 포크의 이름이고, mihomo는 해당 코어 프로젝트의 후속 명칭입니다. 사용자 사이에서는 두 이름을 번갈아 쓰는 경우가 많지만, 이름이 같거나 비슷하다고 과거의 모든 빌드가 동일하다는 뜻은 아닙니다. 최신 프로토콜과 보안 조합, 네트워크 스택 기능은 현재 클라이언트가 실제로 사용하는 코어를 기준으로 확인해야 합니다. 과거 가이드의 Meta 전용 옵션도 현재 문서에서 계속 지원되는지 확인하세요.

설정 호환성은 세 단계로 나눠 확인하세요

첫 번째는 문법을 읽을 수 있는지입니다. 들여쓰기와 목록, 필드 유형이 YAML 파서의 요구 사항에 맞아야 합니다. 두 번째는 코어가 필드를 인식하는지입니다. 특정 프로토콜 유형이나 DNS 옵션을 지원하는지 확인해야 합니다. 세 번째는 실행 환경에서 실제 동작을 수행할 수 있는지입니다. 가상 네트워크 어댑터를 만들고 포트를 열며 인증서를 불러올 수 있어야 합니다. 가져오기에 성공해도 앞 단계의 일부 검사만 통과했을 수 있습니다. 네트워크 권한이 모두 갖춰졌거나 모든 노드의 연결 테스트가 완료됐다는 뜻은 아닙니다.

최신 코어는 일반적인 설정 방식 대부분을 유지하는 경우가 많지만 호환된다고 해서 모든 구형 파일이 수정 없이 실행되는 것은 아닙니다. 폐기된 필드와 기본 동작 변경, 규칙 리소스 형식, 실험적 옵션이 차이를 만들 수 있습니다. 반대로 새 설정을 구형 코어에 넣어도 지원하지 않는 기능이 자동으로 낮은 수준으로 대체되지는 않습니다. 오류가 발생하면 단순히 “설정 오류”라고 기록하지 말고 구체적인 필드 경로를 확인하세요. 그래야 문법 문제인지 기능 지원 문제인지 파악할 수 있습니다.

그래픽 인터페이스가 원본 설정을 덮어쓸 수 있습니다

클라이언트는 포트와 시스템 프록시, DNS, TUN을 관리하기 위해 설정을 덮어쓰거나 패치를 적용하고 병합하는 경우가 많습니다. 사용자가 편집한 구독 파일이 코어에 최종 전달되는 내용과 다를 수 있습니다. 예를 들어 파일에서 혼합 포트를 바꿨는데 재시작 후 원래 값으로 돌아왔다면 시작 시 그래픽 설정이 해당 필드를 덮어썼을 수 있습니다. 구독 업데이트로 교체될 캐시 파일을 계속 수정하기보다 클라이언트가 제공하는 실행 설정이나 병합 미리보기를 확인하세요.

클라이언트를 옮길 때는 먼저 기존 설정을 내보내고 로컬 덮어쓰기 항목을 기록하세요. 새 클라이언트에는 복사본을 가져오는 편이 좋습니다. 먼저 TUN을 끄고 규칙 모드와 작동이 확인된 노드 하나로 기본 연결을 테스트한 뒤 DNS와 규칙 리소스, 가상 네트워크 어댑터를 하나씩 복구하세요. 그러면 문제가 어느 단계에서 생겼는지 파악하기 쉽습니다. 클라이언트와 코어, 구독, 트래픽 전달 방식을 한꺼번에 바꾸면 작업은 빨라 보일 수 있지만 되돌리거나 문제를 찾기가 훨씬 어려워집니다.

플랫폼과 권한에도 제약이 있습니다

Windows의 서비스 권한, macOS의 네트워크 권한, Linux의 네트워크 관리 및 방화벽, Android의 VPN 서비스 인터페이스가 실제 트래픽 전달에 영향을 줄 수 있습니다. iOS 클라이언트도 시스템 인터페이스와 자체 기능 구현을 따라야 합니다. 이름이 같은 앱이라도 데스크톱과 완전히 동일한 코어 기능을 공유한다고 단정해서는 안 됩니다. 클라이언트를 고를 때 플랫폼 안내와 가져오기 지원을 함께 확인하세요. 데스크톱 스크린샷을 모바일 기능의 보장으로 여겨서는 안 됩니다.

구형 클라이언트가 실행 직후 종료된다고 해서 구독 프로토콜이 너무 새롭다고 바로 단정하지 마세요. 포트 충돌과 권한, 설정 문법, 실행 환경도 시작 실패의 원인이 될 수 있습니다. 먼저 시작 시 충돌 문제 해결 체크리스트를 참고해 로그를 확인한 다음 코어 업데이트와 설정 이전, 시스템 변경 중 어떤 조치가 필요한지 판단하세요.

7. YAML·Base64·SIP008의 호환 범위

구독은 설정을 전달하는 형식이지 연결 프로토콜이 아닙니다

구독 주소는 설정 내용을 전달하며, 그 안에는 노드뿐 아니라 정책 그룹과 규칙, 원격 리소스가 포함될 수 있습니다. 설정을 어떤 방식으로 다운로드하는지는 노드의 SS·Trojan·TUIC 사용 여부와 직접적인 관련이 없습니다. 같은 서비스 제공자가 비슷한 이름으로 여러 구독 형식을 제공해 서로 다른 클라이언트를 대상으로 할 수도 있습니다. 나중에 변환하는 것보다 현재 클라이언트나 mihomo 설정 체계용이라고 명확히 표시된 주소를 우선 선택하는 편이 원래 의미를 보존하기 쉽습니다.

Clash 스타일의 YAML은 완전한 설정 파일일 수도 있고 노드 리소스만 담은 파일일 수도 있습니다. 완전한 설정에는 보통 프록시 목록과 정책 그룹, 규칙 같은 최상위 필드가 있습니다. 노드 리소스에는 필요한 구조 일부만 포함될 수 있으며 기본 설정에서 불러와야 합니다. 리소스 주소를 완전한 설정으로 가져오면 클라이언트에 필요한 정책 그룹이 없어질 수 있습니다. 반대로 노드 리소스만 읽는 메뉴에 완전한 설정을 넣으면 구조가 맞지 않는다는 오류가 발생할 수 있습니다.

Base64는 인코딩 방식만 나타낼 뿐 전체 내용을 설명하지 않습니다

여러 공유 링크를 모은 텍스트를 Base64로 인코딩한 구독이 많습니다. Base64는 단순한 인코딩 방식으로 암호화 기능도, 노드 프로토콜도 정의하지 않습니다. 디코딩한 내용에는 SS·VMess·Trojan 링크가 섞여 있을 수 있으며 클라이언트는 각 링크의 문법을 따로 해석해야 합니다. 일반적으로 완전한 규칙 설정만큼 다양한 정보를 담을 수 없으므로 가져온 뒤 노드는 표시되지만 기존 그룹과 트래픽 분리 규칙이 보이지 않더라도 다운로드 오류라고 단정할 수 없습니다.

SIP008은 Shadowsocks 서버 정보를 담는 JSON 형식입니다. 여러 SS 서버와 관련 필드를 표현할 수 있지만 6가지 프로토콜을 모두 담는 공통 구독 형식은 아닙니다. JSON이라는 이유만으로 VMess 공유 링크에서 흔히 보는 JSON 구조와 같은 형식이라고 볼 수 없습니다. 파일 확장자나 브라우저 표시 여부가 아니라 실제 구조와 용도를 기준으로 판단하세요. 구독 주소 끝부분만으로 응답 형식을 알아낼 수 있는 것도 아닙니다.

변환 시 사라지는 것은 필드뿐 아니라 의미입니다

변환 도구는 여러 공유 링크를 대상 클라이언트가 읽을 수 있는 노드 목록으로 정리할 수 있습니다. 하지만 원본에 없는 규칙과 정책 그룹, 상태 확인 정보를 복구할 수는 없습니다. 복잡한 전송 필드가 대상 형식에서 지원되지 않으면 무시되거나 간소화되거나 오류가 발생할 수 있습니다. 이름이 비슷한 필드도 허용하는 값의 범위가 다를 수 있으므로 변환된 파일을 파싱할 수 있다고 해서 원래 설정과 똑같이 연결된다는 뜻은 아닙니다.

구독 내용에는 연결 인증 정보가 포함될 수 있고 구독 주소 자체에 접근 자격 증명이 들어갈 수도 있습니다. 출처가 불분명한 변환 서비스에 실제 주소를 입력하지 마세요. 공개적으로 도움을 요청하기 전에는 비밀번호와 사용자 식별자, 주소의 민감한 매개변수를 삭제하세요. 서비스 제공자가 직접 제공하는 형식이나 신뢰할 수 있는 로컬 처리 방식을 우선 사용하세요. 형식별 구조를 더 자세히 비교하려면 구독 형식 및 상호 변환 안내를 확인하세요.

로컬 규칙과 구독 업데이트를 따로 관리하세요

구독을 내려받아 만든 파일에 로컬 규칙을 직접 추가하면 다음 업데이트 때 덮어써질 수 있습니다. 클라이언트에서 제공하는 덮어쓰기 또는 병합 기능을 사용하고, 필드 교체와 목록 추가 중 어떤 방식으로 동작하는지 확인하는 편이 안전합니다. 규칙은 보통 순서대로 적용되므로 맨 끝에 추가한다고 항상 작동하는 것은 아닙니다. 앞에 기본 규칙이 있으면 새 규칙이 적용될 기회를 얻지 못할 수 있습니다. 정책 그룹에서 참조하는 이름도 실제 노드나 그룹 이름과 일치해야 합니다.

mode: rule
mixed-port: 7890
allow-lan: false
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

위 예시는 직접 연결만 수행하는 최소 설정으로 YAML 들여쓰기와 규칙 순서를 설명하며 프록시 노드는 포함하지 않습니다. 혼합 포트는 이 기기의 앱에서 사용하고 LAN 접근은 차단합니다. 예시 도메인 규칙을 먼저 적용하고 마지막 줄에서 나머지 연결을 처리합니다. 이 설정을 현재 사용하는 구독에 그대로 덮어쓰면 안 됩니다. 프록시 출구를 사용하려면 먼저 실제로 작동하는 노드와 정책 그룹을 마련한 뒤 규칙 대상을 존재하는 이름으로 바꿔야 합니다. 한 줄의 텍스트만 고치는 것으로는 충분하지 않습니다.

구독을 업데이트한 뒤 노드가 사라지면 먼저 응답이 예상한 형식인지 확인한 다음 가져오기 메뉴와 파싱 로그, 로컬 필터 조건을 살펴보세요. 일부 클라이언트는 이름으로 노드를 필터링하거나 이전에 선택한 정책 그룹 참조를 유지할 수 있습니다. “응답 내용 오류”, “필드 호환성 문제”, “필터 적용 후 비어 있음”을 나누어 확인하면 업데이트 버튼을 반복해서 누르는 것보다 효과적입니다. 되돌릴 수 있는 설정 복사본을 실수로 삭제하는 일도 막을 수 있습니다.

8. 사용 상황에 맞게 선택하고 로그로 확인하기

일상적인 웹 탐색, 모바일 사용, 지속 전송

웹 탐색과 업무, 문서 동기화가 주된 용도라면 먼저 구독에서 설정이 완전하고 안정적으로 연결되는 노드를 선택하세요. SS·Trojan·VMess가 이미 작동한다면 프로토콜 이름 때문에 전체 설정을 새로 만들 필요는 없습니다. 현재 플랫폼에 적합한 Clash Plus 등의 클라이언트를 설치하고 빠른 시작 가이드에 따라 가져온 뒤 규칙이 제대로 적용되는지 확인하세요. 규칙이 일부 연결을 직접 연결 경로로 보내는 경우 노드를 바꿔도 해당 요청에 영향이 없는 것은 정상 동작입니다.

휴대폰 화면을 자주 끄거나 이동 중 네트워크를 전환하고 셀룰러 데이터를 사용한다면 복구 속도와 백그라운드 재시도도 비교해야 합니다. 같은 네트워크 조건에서 TCP 기반 노드와 QUIC 기반 노드를 하나씩 시험해 대기 후 시간 초과가 자주 발생하는지 확인하세요. 연결 유지를 위해 처음부터 모든 간격을 줄이지 마세요. 시스템이 장시간 백그라운드에서 작동한 뒤에만 실패한다면 절전 정책과 VPN 서비스 상태도 확인해 시스템 일시 중지를 프로토콜 연결 끊김으로 오인하지 않도록 하세요.

지속 전송이나 원격 상호작용에서 패킷 손실의 영향을 크게 받는다면 UDP를 사용할 수 있고 서버 설정도 완전한 경우 Hysteria2 또는 TUIC을 시험해 볼 수 있습니다. TCP 기반 노드를 기준으로 남겨 두고 일반 웹페이지도 함께 열어 응답을 확인하세요. 대용량 다운로드가 업로드나 다운로드 대역폭을 모두 사용해 다른 작업을 느리게 만든다면 전송 목표값과 혼잡 상태를 먼저 점검하세요. 예상 전송량을 계속 높이는 방식으로 해결하려 하지 마세요. 서버 출구 용량이 부족하면 로컬 프로토콜을 바꿔도 용량이 늘어나지 않습니다.

게임, LAN 공유, 라우터 기기

게임과 실시간 음성·영상에서는 먼저 UDP 전달과 트래픽이 프록시로 넘어오는 범위를 확인해야 합니다. 시스템 프록시가 모든 앱 트래픽을 처리하지 못할 수 있으므로 필요한 경우 TUN을 검토하세요. TUN이 시스템 네트워크 스택에 연결되는 방식과 DNS 처리 방법은 시스템 프록시와 TUN 작동 방식 비교 및 가상 네트워크 어댑터 트래픽 전달 안내를 참고하세요. 트래픽 전달이 성공해도 서버 경로에 따라 결과가 달라지므로 모든 게임의 지연 시간이 개선된다고 보장할 수는 없습니다.

휴대폰이나 TV에서 컴퓨터의 프록시를 공유할 때는 “기기에서 컴퓨터로 연결하는 로컬 프록시 방식”과 “컴퓨터에서 노드로 연결하는 출구 프로토콜”을 구분하세요. 혼합 포트는 HTTP와 SOCKS5를 함께 받을 수 있지만 기기에서 해당 프록시 설정을 지원하는지 확인해야 합니다. LAN 연결 허용을 켰다면 사용 범위를 제한하고 방화벽도 점검하세요. 자세한 방법은 혼합 포트 및 LAN 공유 설정을 참고하세요. 라우터 기기에서는 프로세서와 메모리, 연결 수, 규칙 규모도 고려해야 합니다.

연결이 진행되는 순서대로 문제를 확인하세요

첫째, 앱 요청이 연결 목록이나 로그에 표시되는지 확인합니다. 기록이 전혀 없다면 앱의 프록시 설정과 시스템 프록시 상태, TUN 전달 여부부터 점검하세요. 기록이 있다면 적용된 규칙과 정책 그룹을 살펴보고 예상하지 못한 출구로 전송된 것은 아닌지 확인합니다. 둘째, 서버 도메인을 정상적으로 확인할 수 있는지 점검합니다. 특히 아직 만들어지지 않은 프록시 경로에 DNS가 의존하는지 확인하세요. 노드 인증을 살펴보기 전에 기본 주소 확인부터 해결해야 합니다. 그렇지 않으면 이후 테스트가 실제로 진행되지 않았을 수 있습니다.

셋째, 하위 연결과 보안 핸드셰이크를 확인합니다. 연결 시간 초과는 주소와 포트, 네트워크 도달 가능성을 살펴보세요. 인증서 오류는 기기 시간과 이름, 인증서 체인을 확인하고 인증 실패는 비밀번호와 사용자 식별자, 프로토콜 세대를 점검합니다. 넷째, 대상 서비스 접속과 UDP 전달을 확인합니다. 모든 오류를 DNS 문제로 돌리거나 인증서 검증을 끄고 전역 직접 연결을 사용해 문제를 잠시 덮지 마세요. 원인을 찾는 데 필요한 단서를 잃게 됩니다.

최종 선택을 영구히 고정할 필요는 없습니다. 가정용 네트워크와 셀룰러 네트워크, 게스트 네트워크마다 우선 노드를 달리할 수 있지만 규칙 구조와 대체 경로는 가능한 한 명확하게 유지하세요. 한 번의 테스트에서 나온 최저 숫자보다 안정적으로 재현되는 결과가 더 중요합니다. 클라이언트를 바꾸려면 다운로드 페이지에서 플랫폼과 유지 관리 상태를 확인하세요. 일반적인 사용 방법은 자주 묻는 질문을 참고하고, 프로토콜과 코어 차이는 이 페이지의 목차에서 계속 살펴볼 수 있습니다.