Clash 프로토콜 및 코어 가이드

프로토콜 선택을 좌우하는 네 가지 계층

클라이언트, 코어, 프로토콜, 네트워크 경로

Clash 생태계에서 각 용어는 서로 다른 계층을 가리킵니다. 클라이언트는 창, 구독 관리, 시스템 프록시, 권한 요청을 담당합니다. 코어는 연결을 설정하고 규칙을 적용하며 DNS를 처리합니다. 프로토콜은 클라이언트와 서버가 서로 인증하고 데이터를 캡슐화해 전송하는 방식을 정합니다. 네트워크 경로는 데이터가 실제로 통과하는 네트워크를 결정합니다. 클라이언트를 선택했다고 프로토콜까지 정해지는 것은 아닙니다. mihomo를 지원하는 그래픽 클라이언트를 설치해도 구독의 노드 유형과 서버 설정을 확인해야 합니다.

이 네 계층에서는 각각 문제가 생길 수 있습니다. 설정을 가져올 수 있다는 것은 파일이 관리 화면에 들어왔다는 뜻일 뿐, 코어가 모든 필드를 인식한다는 보장은 아닙니다. 노드에 연결됐다고 표시되어도 한 번의 연결 테스트만 통과했을 뿐, 동영상·다운로드·실시간 통화에 모두 적합하다는 뜻은 아닙니다. 프로토콜 이름이 같은 노드라도 서버, 출구 경로, 전송 계층, 대역폭 정책은 다를 수 있습니다. 따라서 프로토콜을 비교할 때는 서버 위치, 테스트 대상, 테스트 시간을 최대한 동일하게 맞춰야 합니다. 그렇지 않으면 프로토콜이 아니라 네트워크 경로 차이를 비교하게 됩니다.

순위보다 먼저 사용 조건을 확인하세요

먼저 기기 운영체제, 클라이언트 코어, 서버 프로토콜, 현재 네트워크에서 허용되는 전송 방식을 확인하세요. 사내 네트워크는 TCP 연결은 허용하면서 UDP는 차단할 수 있습니다. 모바일 네트워크는 기지국 전환 후 주소가 바뀔 수 있고, 구형 기기는 암호화 연산 성능이 부족할 수 있습니다. 서버가 한 가지 프로토콜만 제공한다면 클라이언트에서 유형 필드만 바꿔 다른 프로토콜로 만들 수 없습니다. 양쪽에서 같은 프로토콜을 사용해야 하며 포트, 인증 정보, 전송 옵션도 일치해야 합니다.

그다음 주로 사용할 작업을 정하세요. 웹 브라우징은 첫 응답 시간과 짧은 연결의 비용이 중요하고, 대용량 파일 전송은 지속 처리량이 중요합니다. 음성 통화와 게임은 지터, 패킷 손실, UDP 전달 기능에 민감합니다. 원격 데스크톱은 반응 속도와 연결 복구를 모두 고려해야 합니다. 장시간 다운로드에 안정적인 설정이 불안정한 네트워크의 통화에도 적합하다고 볼 수는 없습니다. 한 가지 작업에 맞춘 최적화가 백그라운드 데이터 사용량과 휴대폰 배터리 소모를 늘릴 수도 있습니다.

보안과 연결 품질은 따로 확인하세요

암호화와 인증은 연결 대상이 신뢰할 수 있는지, 전송 내용을 어떻게 보호하는지에 관한 것입니다. 속도 테스트는 현재 경로에서 어떤 성능을 얻을 수 있는지 보여줍니다. 둘은 서로 대체할 수 없습니다. 인증서를 사용하는 설정은 인증서 체인과 서버 이름을 확인하고, 사전 공유 자격 증명을 사용하는 설정은 자격 증명의 출처가 신뢰할 수 있는지 확인해야 합니다. 특정 노드의 속도가 빠르다는 이유로 인증 검사를 장기간 꺼 두지 마세요. 최신 프로토콜이라는 이유만으로 보안 수준이 더 높다고 단정해서도 안 됩니다.

이 가이드에서는 고정된 속도 순위를 제시하지 않습니다. 프로토콜 오버헤드는 프로세서, 암호화 구현, 경로의 최대 전송 단위, 패킷 손실, 서버 부하에 따라 달라집니다. 뒤의 내용을 읽으면서 후보 노드마다 세 가지를 기록해 보세요. 현재 코어가 완전히 지원하는지, 현재 네트워크에서 하위 전송 방식이 허용되는지, 실제 작업에서 개선 효과가 있는지 확인하면 됩니다. 하나라도 확인할 수 없다면 검증된 설정을 유지하고 여러 매개변수를 한꺼번에 바꾸지 마세요.

SS와 VMess: 독립 암호화 프록시의 설계 차이

경량 구조의 Shadowsocks

일반적으로 SS라고 부르는 Shadowsocks는 비교적 간결한 프록시 구조를 사용합니다. 클라이언트가 로컬 연결을 받아 대상 주소와 데이터를 캡슐화해 서버로 전달하면, 서버가 대상 서버에 연결합니다. 모든 배포 환경에서 웹 전송이나 인증서 체계를 요구하지는 않습니다. 기본 설정은 주로 서버, 포트, 암호화 방식, 자격 증명으로 구성됩니다. 구조가 단순해 여러 플랫폼에서 구현하기 쉽고 필수 필드가 적어 문제를 추적하기도 편하지만, 모든 SS 노드의 특성이 같다는 뜻은 아닙니다.

SS의 암호화 방식은 서로 바꿔 쓸 수 없습니다. 초기 스트림 암호 방식, 널리 쓰이는 AEAD 방식, 이후의 Shadowsocks 2022 방식은 키 형식과 구현 요구사항이 다릅니다. 서버가 사용하는 방식에 맞춰 클라이언트도 지원해야 합니다. 일부 방식은 정해진 길이와 인코딩의 키가 필요하며, 임의의 비밀번호를 넣을 수 없습니다. 가져오기 오류가 발생하면 포트만 바꾸지 말고 먼저 암호화 방식 이름과 키 형식을 확인하세요.

SS는 TCP를 사용할 수 있으며, 클라이언트와 서버, 네트워크가 모두 지원하면 UDP도 전달할 수 있습니다. 클라이언트의 UDP 옵션은 로컬 허용 여부만 결정합니다. 서버, 구독 설정, 네트워크 경로도 조건을 충족해야 합니다. 웹은 정상인데 게임이나 통화에 문제가 있다면 해당 트래픽이 실제로 프록시를 거치는지, 서버가 필요한 기능을 제공하는지, 현재 네트워크가 UDP를 제한하는지 확인하세요. 웹 페이지를 한 번 열어 보는 것만으로 UDP 전달 가능 여부를 확인할 수는 없습니다.

VMess의 사용자 인증과 전송 조합

VMess는 V2Ray 생태계에서 시작된 프로토콜로, 사용자 식별자를 인증에 사용하며 자체 암호화 및 캡슐화 방식을 갖추고 있습니다. 실제 노드에서는 TCP나 WebSocket 같은 전송 방식이 추가될 수 있고 TLS를 함께 사용할 수도 있습니다. 비교할 때는 조합 전체를 명시해야 하며, VMess가 다른 프로토콜보다 빠르다고만 말해서는 안 됩니다. 직접 연결과 추가 게이트웨이를 거치는 연결은 핸드셰이크 횟수, 캡슐화 비용, 중간 장비 지원 면에서 큰 차이가 날 수 있습니다.

VMess 문제를 해결할 때는 시스템 시간 동기화도 확인해야 합니다. 인증 과정에서 기기 시각을 확인하므로 시간 오차가 있으면 인증이 실패할 수 있지만, 화면에는 시간 초과나 연결 종료로만 표시되기도 합니다. 먼저 운영체제의 자동 시간 동기화를 켜고 사용자 식별자와 서버 로그를 확인하세요. 오래된 구독에는 과거 호환 매개변수가 포함될 수 있습니다. 해당 필드의 의미는 코어 구현에 따라 다르므로 오래된 안내서의 값을 그대로 적용하지 마세요.

WebSocket 경로, 요청 호스트 이름, TLS 서버 이름은 서로 다른 정보입니다. 경로는 애플리케이션 계층 핸드셰이크에 사용되고, 요청 호스트 이름은 HTTP 라우팅에 사용되며, TLS 이름은 핸드셰이크와 인증서 검증에 쓰입니다. 경우에 따라 값이 같을 수 있지만 반드시 같아야 하는 것은 아닙니다. 서버 앞에 리버스 프록시가 있다면 경로를 빠뜨리거나 요청 헤더를 잘못 설정했을 때 서버에 연결되더라도 프록시 세션이 만들어지지 않을 수 있습니다. 이런 문제는 라우팅 규칙 오류가 아닙니다.

선택과 유지 관리의 실제 기준

이미 검증된 TCP 네트워크와 리소스가 제한된 기기에서는 구조가 단순한 SS 설정을 기준으로 삼을 수 있습니다. VMess를 완전하게 운영 중이라면 이름이 오래됐다는 이유만으로 즉시 옮길 필요도 없습니다. 실제로 확인해야 할 것은 서버 유지 관리 상태, 암호화 설정, 클라이언트 지원 여부, 일상적인 작업에서의 성능입니다. 전송 캡슐화를 추가하면 특정 배포 요구를 충족할 수 있지만 일치시켜야 할 필드도 늘어납니다. 그렇다고 속도가 자동으로 빨라지는 것은 아닙니다.

SS 설정에 플러그인 매개변수가 있다면 클라이언트가 해당 플러그인과 구체적인 모드를 지원하는지 별도로 확인하세요. 기본 SS를 지원한다고 모든 플러그인까지 지원하는 것은 아니며, 노드 변환 도구가 플러그인 옵션을 누락할 수도 있습니다. VMess도 전송 조합에 따라 호환 범위가 달라집니다. 원본 링크와 설정 출처를 보관하고 변환된 필드를 하나씩 대조하는 편이 실행 모드를 반복해서 바꾸는 것보다 효과적입니다. 가져오기 문제가 있다면 먼저 자주 묻는 질문의 설치 및 설정 안내를 확인하세요.

Trojan과 VLESS: 인증, TLS, 전송 방식의 역할

Trojan: TLS에 보안 채널을 맡기는 방식

일반적인 Trojan 구성은 TLS를 외부 보안 채널로 사용하고, 그 안에서 프록시 인증과 데이터 전달을 처리합니다. 별도의 애플리케이션 암호화 알고리즘 목록을 관리할 필요는 없습니다. 설정에서는 비밀번호, 인증서, 서버 이름, 서버 수신 설정이 중요합니다. 여기서 구조가 단순하다는 것은 각 요소의 역할이 나뉜다는 뜻입니다. TLS는 전송을 보호하고 프록시 프로토콜은 대상과 인증을 설명합니다. 실제로 안전하게 운영되는지는 인증서 검증과 서버 설정이 올바른지에 달려 있습니다.

연결 주소와 인증서 이름은 다를 수 있습니다. 예를 들어 클라이언트는 주소로 서버에 접속하지만 서버 인증서는 도메인에 발급된 경우, TLS 서버 이름을 올바르게 설정하고 인증서가 해당 이름과 일치하는지 확인해야 합니다. SNI는 핸드셰이크에서 서버 이름을 전달하는 방식이며, 인증서 검증은 신원과 신뢰 체인을 확인합니다. 서로 관련은 있지만 같은 기능은 아닙니다. 그럴듯한 도메인을 입력한다고 잘못된 인증서가 신뢰할 수 있는 인증서로 바뀌지는 않습니다.

Trojan 연결 실패를 해결할 때는 TCP 연결 실패, TLS 핸드셰이크 실패, 프록시 인증 실패를 구분하세요. 첫 번째는 주로 주소, 포트, 네트워크 경로와 관련이 있습니다. 두 번째는 시계, 인증서 유효 기간, 이름 일치 여부, 신뢰 체인을 확인해야 합니다. 마지막 경우에는 비밀번호와 서버 인증 설정을 중점적으로 살펴보세요. 클라이언트가 여러 종류의 실패를 모두 시간 초과로 표시할 수 있으므로, TLS 옵션을 전부 바꾸기보다 로그에서 실패한 단계를 확인해야 합니다.

VLESS: 경량 프로토콜이 독립 암호화 계층을 뜻하지는 않습니다

VLESS도 V2Ray 관련 생태계에서 시작됐으며, 프로토콜 자체의 부담을 줄이고 함께 사용하는 전송 보안 방식에 보호 기능을 맡기는 설계입니다. 사용자 식별자만 입력하면 완전한 암호화가 자동으로 제공된다고 이해해서는 안 됩니다. 흔히 TLS나 REALITY를 함께 사용하지만, 지원 여부는 클라이언트 코어와 선택한 전송 조합에 따라 달라집니다. 구독에 보안 계층 관련 필드가 없다면 기본 동작을 추측하지 말고 설정 제공자에게 확인하세요.

REALITY 설정은 일반적인 인증서 기반 TLS와 다르며, 보통 공개 키, 짧은 ID, 서버 이름 등의 매개변수가 서로 맞아야 합니다. 사용자 식별자가 올바르더라도 이 필드가 일치하지 않으면 연결에 실패합니다. 일부 VLESS 구성은 서버가 특정 Vision 흐름 제어를 요구하는 등 흐름 제어 방식도 지정합니다. 이는 양쪽의 협상 및 구현 조건이지, 어디서나 사용할 수 있는 속도 향상 옵션이 아닙니다. 서버 요구사항에 맞춰 설정하고 관련 필드를 모든 노드에 복사하지 마세요.

같은 VLESS 노드라도 전송 방식은 다를 수 있습니다. 클라이언트가 기본 VLESS를 지원한다고 해서 서버가 사용하는 모든 전송 방식, 보안 계층, 흐름 제어 조합을 지원하는 것은 아닙니다. 노드 공유 링크에 모든 확장 필드가 담기지 않을 수도 있습니다. 호환성을 확인하려면 현재 코어 문서에서 조합별 제한을 살펴보고 실제 생성된 설정을 기준으로 판단하세요. 클라이언트 이름이나 프로토콜 지원 목록만으로는 이런 차이를 확인할 수 없습니다.

인증서 검증과 연결 재사용 정책

인증서 검증을 끄면 클라이언트가 서버 신원을 확인하는 능력이 약해지므로 장기적인 해결책으로 사용해서는 안 됩니다. 자체 서명 인증서를 사용하는 환경이라면 클라이언트 기능에 맞춰 신뢰할 인증서나 적절한 신원 제약을 설정하세요. 공인 인증서를 사용한다면 이름과 인증서 체인을 바로잡아야 합니다. 특정 기기에서만 실패한다면 시스템 시간, 신뢰 저장소, 보안 소프트웨어의 연결 개입 여부도 확인하세요. 같은 노드라도 기기마다 다르게 동작한다면 프로토콜보다 로컬 환경이 원인일 수 있습니다.

연결 재사용은 여러 논리적 요청이 하위 연결을 공유하게 해 연결 설정을 반복하는 비용을 줄여줍니다. 하지만 혼잡 경쟁 방식과 장애가 미치는 범위가 달라질 수 있습니다. 공유 연결이 막히면 여러 요청이 함께 영향을 받고, 서버가 해당 재사용 방식을 지원하지 않으면 간헐적인 연결 끊김처럼 보일 수 있습니다. Trojan이나 VLESS를 선택할 때는 서버가 명확히 지원하는 최소 설정으로 먼저 검증한 뒤 연결 재사용, 전송 캡슐화, 흐름 제어를 평가하세요. 처음부터 옵션을 여러 개 추가하는 것보다 문제를 찾기 쉽습니다.

Hysteria2와 TUIC: QUIC 기반 연결 방식

QUIC은 어떤 계층을 바꾸나요?

QUIC은 보통 UDP 위에서 동작하며 암호화 핸드셰이크, 신뢰성 있는 전송, 다중 스트림 등의 기능을 제공합니다. 여기서 UDP는 하위 전송 수단일 뿐, 애플리케이션 데이터가 반드시 신뢰할 수 없는 방식으로 전달된다는 뜻은 아닙니다. 웹과 파일 데이터는 신뢰성 있는 스트림으로 전송할 수 있습니다. 여러 논리적 스트림이 하나의 TCP 바이트 스트림을 공유할 때와 비교하면 QUIC은 스트림 간 순차 전달로 인한 차단을 줄일 수 있습니다. 다만 공유 연결은 같은 경로의 혼잡과 가용 대역폭의 영향을 받으며 물리 네트워크의 용량을 넘어설 수는 없습니다.

Hysteria2와 TUIC은 모두 QUIC을 사용하지만 서로 다른 프로토콜이며 이름만 바꿔 쓸 수 없습니다. 인증 필드도 서로 호환되지 않습니다. 서버가 Hysteria2를 사용하면 클라이언트도 Hysteria2 방식으로 세션을 설정해야 합니다. TUIC은 프로토콜 세대별로 지원 여부를 확인해야 합니다. 화면에 “QUIC 지원”이라고 표시된 것만으로 모든 QUIC 기반 프록시 서버에 연결할 수 있는 것은 아닙니다. 노드 유형과 구현 범위를 함께 확인하세요.

Hysteria2의 대역폭 추정과 혼잡 제어

Hysteria2는 패킷 손실과 복잡한 네트워크 경로가 있는 환경의 전송을 고려해 대역폭 설정과 관련된 혼잡 제어 옵션을 제공합니다. 설정의 업로드 및 다운로드 대역폭은 일반적으로 클라이언트 측에서 예상하는 성능을 나타내며, 서버 네트워크 카드의 표시 속도를 그대로 입력하라는 뜻은 아닙니다. 가용 대역폭을 지나치게 높게 추정하면 대기열, 경쟁, 패킷 손실이 늘어나 웹 응답 속도와 같은 네트워크를 사용하는 다른 기기에 영향을 줄 수 있습니다. 너무 낮게 설정하면 지속 전송 속도가 제한될 수 있습니다.

서버도 대역폭을 제한하거나 협상 결과에 영향을 줄 수 있으므로 클라이언트에 입력한 값만으로 최종 동작을 판단할 수 없습니다. 먼저 서비스 운영자가 안내한 설정을 사용하고, 지속 다운로드와 상호작용 작업을 함께 관찰하세요. 일부 선택적 난독화 옵션은 양쪽 설정이 일치해야 합니다. 이러한 옵션은 인증서 검증이나 인증을 대신하지 않습니다. 옵션을 변경한 뒤 핸드셰이크 자체가 실패하면 대역폭 부족으로 단정하지 말고 먼저 이전 설정으로 되돌리세요.

TUIC의 스트림, 데이터그램, 연결 유지

TUIC도 QUIC을 사용해 프록시 세션을 전달합니다. 설정에는 사용자 식별자, 비밀번호, 혼잡 제어, UDP 전달 방식, 연결 유지 매개변수가 포함될 수 있습니다. TCP 프록시 스트림과 UDP 트래픽은 처리 방식이 다릅니다. 신뢰성 있는 전달과 데이터그램 중 무엇을 선택할지는 애플리케이션의 즉시성과 데이터 완전성 요구를 고려해야 합니다. 실시간 통화는 오래된 데이터를 제때 버리는 것이 중요할 수 있지만, 파일 데이터는 순서대로 정확히 도착해야 합니다. 모든 요구를 막연히 “안정성” 하나로 설명할 수는 없습니다.

연결 유지 주기와 유휴 시간 초과 설정은 트래픽이 없을 때 연결을 어떻게 유지할지 결정합니다. 모바일 네트워크의 주소 변환 장비는 UDP 매핑을 빠르게 회수할 수 있어 적절한 연결 유지 요청이 이후 데이터 전달에 도움이 됩니다. 하지만 너무 자주 보내면 무선 통신을 깨우고 백그라운드 데이터 사용량을 늘립니다. 네트워크 전환 후 연결을 계속 사용할 수 있는지는 구현, 서버, 네트워크 경로에 따라 달라집니다. QUIC의 연결 마이그레이션 기능이 모든 클라이언트에서 세션 연속성을 보장한다고 생각해서는 안 됩니다.

UDP 경로를 항상 사용할 수 있는 것은 아닙니다

현재 네트워크에서 UDP가 크게 제한된다면 두 프로토콜은 TCP 기반 방식보다 연결하기 어려울 수 있습니다. 재시도 횟수를 늘려도 하위 네트워크에 도달하지 못하는 문제는 해결되지 않습니다. 캡슐화된 패킷 크기도 확인해야 합니다. 추가 프록시 계층, 터널, 접속 네트워크가 경로에서 사용할 수 있는 전송 단위를 줄이면 작은 요청은 정상인데 대량 전송이 멈출 수 있습니다. 로그와 다른 네트워크를 활용해 계층별로 확인하고 모든 기기의 시스템 매개변수를 무작정 낮추지 마세요.

비교할 때는 검증된 TCP 설정을 기준으로 준비하고 같은 네트워크에서 웹 브라우징, 지속 전송, 유휴 후 연결 복구를 각각 테스트하세요. QUIC 방식은 일부 패킷 손실이 있는 경로에서 더 적합할 수 있지만, 통신 사업자 환경에 따라 속도가 제한될 수도 있습니다. 한 번의 최고 속도가 아니라 현재 작업에서 반복적으로 개선되는지를 기준으로 선택해야 합니다. 설정을 조정할 때는 서버 처리 용량과 공유 네트워크의 다른 애플리케이션도 고려하세요.

속도, 리소스 사용량, 모바일 배터리

속도 테스트를 단계별로 나눠 보세요

사용자가 체감하는 대기 시간에는 DNS 조회, 하위 연결 설정, 프로토콜 핸드셰이크, 대상 사이트 응답, 콘텐츠 전송이 모두 포함됩니다. 노드 지연 시간 테스트는 보통 이 중 일부만 측정하며 모든 웹사이트의 첫 화면 표시 시간을 의미하지 않습니다. 테스트 응답이 빠른 노드라도 대상 사이트까지의 출구 경로가 좋지 않으면 다운로드가 느릴 수 있습니다. 프로토콜 차이를 판단할 때는 첫 방문, 재방문, 장시간 연결 작업을 각각 기록하세요. 캐시와 연결 재사용에 따른 변화를 프로토콜의 장점으로 오인하지 않도록 주의해야 합니다.

지속 처리량은 전송 창 크기, 혼잡 제어, 왕복 시간, 패킷 손실의 영향을 받습니다. 대역폭이 큰 경로라도 왕복 시간이 길다면 용량을 활용하려면 충분한 데이터가 전송 중이어야 합니다. 패킷 손실 후 복구 속도는 혼잡 제어 방식에 따라 달라집니다. 그러나 더 적극적으로 데이터를 보내는 것이 항상 좋은 것은 아닙니다. 접속 회선의 대기열을 가득 채워 상호작용 지연을 높일 수 있습니다. 다운로드 속도를 평가할 때는 자주 사용하는 웹사이트를 함께 열거나 음성 통화를 테스트해 다른 작업의 사용성이 떨어지는지 확인하세요.

프로세서 부하는 전체 처리 과정에서 발생합니다

암호화는 리소스 비용의 일부일 뿐입니다. 사용자 영역 네트워크 스택, 데이터 복사, 전송 캡슐화, 연결 재사용, 규칙 검색, 로그 출력도 프로세서 시간을 사용합니다. 프로세서마다 특정 암호화 알고리즘의 하드웨어 지원이 다르므로 데스크톱 테스트 결과를 휴대폰이나 라우터에 그대로 적용할 수 없습니다. 저전력 기기의 부하가 계속 높다면 시스템 프록시와 TUN, 간소한 설정과 전체 설정을 각각 비교해 병목을 확인하세요.

메모리 사용량은 연결 수, 규칙 집합, 구독 규모, 캐시, 인터페이스 프로세스의 영향도 받습니다. 클라이언트 두 개의 전체 메모리 사용량만 비교해서 코어 효율을 판단하기는 어렵습니다. 한쪽은 더 많은 규칙을 불러왔고 다른 쪽은 연결 패널을 열지 않았을 수 있습니다. 규칙과 작업을 동일하게 맞추고 그래픽 인터페이스와 코어 프로세스를 구분해 관찰하세요. 특히 라우터는 여유 메모리가 중요합니다. 메모리 부족으로 프로세스가 종료된 것을 프로토콜 연결 끊김으로 오해할 수 있습니다.

휴대폰 배터리와 무선 연결 깨우기

휴대폰 배터리는 암호화뿐 아니라 무선 연결 유지, 백그라운드 깨우기, 재연결, 트래픽 검사에도 소모됩니다. 모든 노드를 자주 검사하거나 연결 유지 주기를 너무 짧게 설정하거나 상세 로그를 계속 출력하면 유휴 상태를 유지하기 어렵습니다. 프로토콜 이름만으로 배터리 소모 순위를 정할 수는 없습니다. 같은 휴대폰과 네트워크, 비슷한 작업량으로 비교해야 참고할 만한 결과를 얻을 수 있습니다. 화면 밝기와 신호 세기도 최대한 일정하게 유지하세요.

모바일 운영체제는 플랫폼과 클라이언트에 따라 VPN 또는 네트워크 확장 기능으로 트래픽을 처리합니다. 클라이언트에 TUN이라고 표시되어도 데스크톱 환경과 같은 방식으로 구현됐다는 뜻은 아닙니다. 시스템 절전 정책이 백그라운드 작업을 일시 중지했다가 다시 시작할 때 세션을 재설정해야 할 수 있습니다. 화면이 꺼진 뒤에만 문제가 생기고 앱을 열어 두면 정상이라면 프로토콜을 바꾸기 전에 백그라운드 권한과 네트워크 복구 동작을 확인하세요. 연결 유지 주기를 무작정 줄이면 문제를 감추는 대신 배터리 사용량이 늘어날 수 있습니다.

재현 가능한 비교 기록 만들기

한 번에 한 가지 요소만 바꾸세요. 노드 지역과 대상 사이트를 동일하게 유지하고, TUN 사용 여부를 고정하며 자동 노드 검사를 일시 중지한 뒤 짧은 요청, 대용량 파일, 유휴 후 복구를 각각 확인하세요. 다운로드 중 구독 업데이트, DNS 전환, 혼잡 제어 매개변수 변경을 동시에 하면 결과를 해석할 수 없습니다. 최고 속도 스크린샷만 남기지 말고 발생 시각, 네트워크 유형, 오류 단계, 작업 결과를 기록하세요.

특정 앱에서만 문제가 발생한다면 라우팅 규칙과 DNS 조회 경로도 확인해야 합니다. Fake-IP는 도메인 정보를 보존하는 주소 매핑 방식이지 속도를 높이는 프로토콜이 아닙니다. TUN은 트래픽 가로채기 범위를 넓히지만 모든 연결을 더 빠르게 만들지는 않습니다. 활성화 후 성능이 달라졌다면 이전에는 직접 연결되던 트래픽이 프록시를 거치기 시작했을 수 있습니다. 연결 기록에서 적용된 규칙과 출구를 확인한 다음 인터넷 속도 저하를 세 단계로 진단하는 방법을 참고해 노드, 경로, 로컬 기기 순으로 점검하세요.

원본 Clash, Clash Meta, mihomo

프로젝트 계보와 기능의 출처

원본 Clash는 YAML로 프록시, 정책 그룹, 규칙을 정의하는 방식을 정립했으며 여러 그래픽 클라이언트가 이 설정 모델을 이어받았습니다. 원본 프로젝트는 유지 관리가 중단됐습니다. 기존 설치본은 계속 작동할 수 있지만 새 프로토콜과 호환성 수정이 계속 제공될 것이라고 기대해서는 안 됩니다. 구형 클라이언트가 일반적인 설정을 인식하더라도 나중에 추가된 프로토콜 필드를 처리할 수 있다는 뜻은 아닙니다. 알 수 없는 유형이 있다면 창 제목만 보지 말고 실제 연결을 처리하는 코어부터 확인하세요.

Clash Meta는 Clash 관련 기반에서 발전한 확장 코어 계열이며, 이후 mihomo라는 이름으로 유지 관리되고 있습니다. 사용자가 말하는 Meta, 설정 파일의 확장 기능, 현재 mihomo 문서는 대체로 같은 발전 흐름을 가리킵니다. 다만 과거 설치 패키지에는 이전 구현이 남아 있을 수 있습니다. 이름의 관계는 프로젝트의 출처를 설명할 뿐, Meta라고 표시된 모든 클라이언트가 같은 기능을 제공한다는 뜻은 아닙니다. 클라이언트의 코어 정보와 유지 관리 안내를 확인하세요.

mihomo는 프로토콜, 규칙, DNS, 네트워크 트래픽 처리 기능을 확장해 여러 데스크톱 및 모바일 클라이언트의 연결 기반으로 사용됩니다. 그래픽 인터페이스는 보통 구독 다운로드, 설정 덮어쓰기, 권한 관리도 담당합니다. 따라서 한 기능이 두 곳에 걸쳐 있을 수 있습니다. 코어는 관련 필드를 읽을 수 있지만 인터페이스에 해당 설정이 없을 수도 있고, 반대로 인터페이스에는 옵션이 있어도 현재 코어가 해당 문법을 지원하지 않을 수 있습니다. 문서를 확인할 때 인터페이스와 코어 문서를 따로 살펴보세요.

설정 구조가 호환돼도 모든 필드가 호환되는 것은 아닙니다

세 계열의 연속성은 프록시 목록, 정책 그룹, 규칙 같은 기본 구조에서 주로 나타납니다. 하지만 확장 프로토콜, 규칙 동작, DNS 필드는 완전한 하위 호환성을 보장하지 않습니다. 새 설정을 구형 코어에서 불러오면 실패하거나 일부 필드가 무시될 수 있고, 구형 설정을 새 코어에서 불러와도 필드 제약이 엄격해져 문제가 드러날 수 있습니다. 설정을 불러오는 것은 첫 단계일 뿐입니다. 규칙이 실제로 적용되는 경로, 도메인 조회 결과, UDP 작업도 확인해야 합니다.

클라이언트 선택과 구형 환경 마이그레이션

처음 선택할 때는 다운로드 페이지에서 우선 추천하는 Clash Plus를 사용해 보고, 운영체제별 지원 범위와 설정 방식을 확인하세요. 데스크톱에서는 Clash Verge Rev, FlClash, Clash Nyanpasu도 비교할 수 있습니다. 모바일에서는 다운로드 페이지에서 Clash Meta for Android, FlClash, Surfboard의 형식 요구사항을 확인하세요. 클라이언트마다 설정 문법이 다를 수 있습니다. 모두 구독 링크를 받을 수 있다고 해서 전체 설정 파일을 그대로 공유할 수 있는 것은 아닙니다.

Clash for Windows와 ClashX Meta는 다운로드 목록에서 유지 관리가 중단된 보관용 선택지로 분류됩니다. 마이그레이션 전에 원본 구독 주소, 개인 규칙, 덮어쓰기 설정, 필요한 로컬 설정을 보관하세요. 기존 폴더를 바로 덮어쓰지 마세요. 새 클라이언트에서 구독을 가져온 뒤 시스템 프록시, TUN 권한, 시작 시 실행, 포트를 각각 확인하세요. 기존 환경의 실행 스크립트를 그대로 복사해 실행하지 말고 먼저 어떤 설정 필드를 변경하는지 파악해야 합니다.

클라이언트에서 명시적으로 지원하는 경우에만 코어를 전환하세요. 코어 패키지마다 특정 제어 인터페이스, 실행 매개변수, 권한 관리 방식이 필요할 수 있습니다. 파일을 수동으로 교체하면 인터페이스에 표시되는 상태와 실제 실행 상태가 달라질 수 있습니다. 전환 여부를 확인하려면 실행 중인 프로세스와 시작 로그의 코어 정보를 살펴본 뒤 설정이 정상적으로 로드됐는지 확인하세요. 설정 메뉴에 옵션이 표시된다는 이유만으로 판단하지 마세요. 이전 프로세스가 남아 기존 포트를 계속 사용하고 있을 수 있습니다.

마이그레이션 문제는 두 단계로 나눠 해결하세요. 먼저 최소한의 구독 설정으로 연결한 다음 규칙과 덮어쓰기 설정을 하나씩 복원합니다. 이렇게 하면 문제가 프로토콜 호환성에서 비롯됐는지 사용자 설정에서 비롯됐는지 구분하기 쉽습니다. 프로젝트 계보에 관한 자세한 설명은 세대별 코어 기능 및 호환성 비교를 참고하세요. 구형 데스크톱 환경에서 옮길 때는 Clash for Windows 마이그레이션 단계를 참고하면 클라이언트 관리 계층 문제와 프로토콜 테스트를 혼동하지 않을 수 있습니다.

구독 형식, 필드 보존, 설정 병합

구독 주소가 항상 같은 파일 형식을 반환하는 것은 아닙니다

구독은 업데이트를 가져오는 경로입니다. 응답 내용은 전체 Clash YAML, 노드 목록, 인코딩된 공유 링크 모음, 다른 클라이언트용 설정일 수 있습니다. 같은 주소라도 요청 방식에 따라 다른 형식을 반환할 수 있습니다. 따라서 링크가 열린다고 현재 클라이언트에서 해석할 수 있다는 뜻은 아닙니다. 구독 제공자가 대상으로 안내한 클라이언트를 확인하고 가져오기 메시지를 살펴보세요. 웹 페이지, 로그인 화면, 오류 문구가 반환된다면 YAML 들여쓰기를 바꾸지 말고 접근 및 인증 문제를 해결해야 합니다.

전체 설정에는 프록시, 정책 그룹, 규칙, DNS가 포함될 수 있습니다. 노드 구독은 보통 연결 지점만 설명하므로 정책과 라우팅은 로컬 설정에서 제공해야 합니다. 둘을 혼동하면 규칙이 사라지거나 정책 그룹에서 노드를 찾지 못할 수 있습니다. 일부 클라이언트는 가져올 때 템플릿을 자동으로 만들어 문제를 잠시 숨기기도 합니다. 다른 클라이언트로 바꾼 뒤에야 문제가 드러날 수 있습니다. 설정을 읽을 때는 최상위 구조부터 확인한 다음 프로토콜 필드를 살펴보세요. 노드 이름만 검색해서는 충분하지 않습니다.

변환으로 형식은 바꿀 수 있어도 모르는 정보를 채울 수는 없습니다

형식 변환 도구는 보통 이미 알고 있는 필드를 다른 문법에 맞게 옮깁니다. 원본 데이터에 없는 공개 키, 인증서 이름, 플러그인 매개변수, 전송 경로를 만들어 낼 수는 없습니다. 대상 형식이 지원하지 않는 기능은 필드가 삭제될 수도 있습니다. 변환 후에는 프로토콜 유형, 주소, 포트, 신원 정보, TLS, 전송 옵션이 모두 보존됐는지 확인하세요. 특히 Hysteria2, TUIC, 확장 조합을 사용하는 VLESS 노드를 주의 깊게 확인해야 합니다.

공유 링크는 개별 노드를 전달하기에 적합하지만 전체 설정에는 규칙 순서, 정책 그룹 의존성, 로컬 DNS 동작도 포함됩니다. 노드 링크 모음을 다른 클라이언트로 가져왔다고 기존 네트워크 정책까지 옮겨지는 것은 아닙니다. Surfboard 등의 클라이언트도 별도의 설정 형식을 사용하므로 Clash YAML의 확장자만 바꿔 사용할 수 없습니다. 형식이 맞지 않으면 변환을 반복해 불확실성을 늘리지 말고 대상 클라이언트용 구독을 제공자에게 요청하세요.

원격 업데이트와 로컬 정책 분리하기

구독을 업데이트하면 원격에서 관리하는 콘텐츠가 대체되는 경우가 많습니다. 다운로드한 파일의 노드나 규칙을 직접 수정하면 다음 업데이트 때 변경 사항이 사라질 수 있습니다. 구독은 노드 공급을 담당하고 로컬 덮어쓰기 설정은 개인 규칙, DNS, 그룹을 담당하도록 나누는 편이 안전합니다. 다만 병합 순서는 클라이언트마다 다릅니다. 로컬 키가 원격 키를 덮어쓰는 경우도 있고 목록을 추가하거나 대체하는 경우도 있습니다. 작업 전에 병합 안내를 확인하고 코어에 전달되는 최종 설정을 점검하세요.

아래 예시는 해석 가능한 최소 규칙 구조만 보여 주며 원격 노드는 포함하지 않습니다. 최상위 필드의 관계를 설명하기 위한 것으로 기존 구독을 대체해서는 안 됩니다. 실제 설정에서는 프록시 그룹의 이름이 실제 노드나 내장 정책을 가리켜야 합니다. 규칙은 순서대로 적용되므로 조건이 넓은 규칙을 앞에 두면 뒤의 세부 조건이 적용되지 않을 수 있습니다. 변경한 뒤에는 클라이언트의 설정 검사를 실행하고 연결 기록에서 예상한 규칙이 적용되는지 확인하세요.

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

proxy-groups:
  - name: 기본 정책
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,기본 정책

DNS 설정도 설정 호환성에 포함됩니다

Fake-IP는 가상 주소 매핑으로 도메인 정보를 보존하며 규칙과 트래픽 가로채기 기능과 함께 사용됩니다. 노드 프로토콜의 일부는 아닙니다. 구독을 가져온 뒤 DNS 모드까지 바꾸면 프록시 노드가 같더라도 앱 동작이 달라질 수 있습니다. DNS 요청을 누가 처리하는지, 운영체제나 앱 자체의 암호화 DNS가 사용되는지, 트래픽 처리 범위가 원하는 연결을 포함하는지 확인하세요. DNS 옵션 하나만 보고 전체 경로를 판단할 수는 없습니다.

병합 문제를 확인할 때는 원본과 최종 설정을 따로 보관하고 구독 자격 증명을 가린 뒤 관련 필드를 비교하세요. 구독 주소를 신뢰할 수 없는 변환 서비스에 올리거나 공개 로그에 인증 정보를 남기지 마세요. 도메인 관련 문제가 있다면 DNS 요청 경로와 Fake-IP 설정 안내를 참고하세요. 설정은 한 번에 한 그룹씩 조정하고 결과를 확인한 뒤 다음 단계로 넘어가야 업데이트, 병합, DNS 문제가 한꺼번에 얽히지 않습니다.

사용 환경에 맞는 프로토콜 선택과 검증

데스크톱 브라우징, 개발, 지속 전송

일상적인 웹 브라우징과 개발 도구에는 서버 유지 관리 상태가 명확하고 클라이언트가 완전히 지원하는 설정부터 사용하세요. 처음부터 복잡한 전송 조합을 선택할 필요는 없습니다. 브라우저는 보통 시스템 프록시를 따르므로 트래픽 경로를 확인하기 쉽습니다. 명령줄 도구나 독립 실행 환경은 프록시를 따로 설정해야 할 수 있습니다. 터미널에서는 실패하지만 웹 브라우저에서는 정상이라면 프로토콜을 바로 바꾸지 말고 해당 프로그램이 프록시를 사용하는지 먼저 확인하세요. 컨테이너, 가상 머신, 원격 개발 환경도 별도의 네트워크 설정을 가질 수 있습니다.

대용량 파일을 다운로드할 때는 시작 시점의 최고 속도뿐 아니라 지속 처리량과 복구 능력을 확인하세요. TCP 방식이 안정적이라면 기준 설정으로 유지하세요. 경로에 패킷 손실이 뚜렷하고 UDP를 사용할 수 있다면 Hysteria2나 TUIC도 비교해 볼 수 있습니다. 테스트 중에는 상호작용 응답과 기기 부하도 확인하세요. 대역폭 매개변수를 조정해 성능이 좋아졌다면 다른 작업에 영향을 주지 않는지 확인해야 합니다. 짧은 시간 동안 회선을 가득 채웠다고 해서 일반적으로 최적의 설정인 것은 아닙니다.

이동 중인 모바일 환경과 실시간 앱

휴대폰으로 이동 중에는 네트워크 전환, 신호 변화, 백그라운드 절전이 자주 발생합니다. 화면을 끈 뒤의 복구, Wi-Fi에서 모바일 네트워크로의 전환, 장시간 유휴 후 첫 요청을 우선 테스트하세요. 하위 연결 방식이 연결 마이그레이션을 지원하면 일부 상황에서 도움이 될 수 있지만, 클라이언트와 서버에서 실제로 활성화됐는지는 확인해야 합니다. 고정 네트워크에서는 빠르더라도 전환할 때마다 수동 재연결이 필요한 설정은 현재 모바일 사용 환경에 적합하지 않을 수 있습니다.

게임과 통화에서는 UDP 전달, 규칙 적용, 출구 위치를 확인해야 합니다. 노드 사용 가능 표시가 떠도 실시간 트래픽이 해당 노드를 사용한다는 뜻은 아닙니다. 일부 앱은 인증, 미디어, 업데이트 서버에 동시에 연결하며 각 연결에 다른 규칙이 적용될 수 있습니다. 먼저 실제 연결 기록을 확인하고 프로토콜 조정이 필요한지 판단하세요. 원격 데스크톱은 파일 다운로드 속도만 보지 말고 화면 갱신, 키보드와 마우스 반응, 짧은 패킷 손실 후 복구도 살펴봐야 합니다.

서버, 라우터, 제한된 네트워크

서버와 라우터에서는 보통 mihomo 코어를 직접 관리하는 방식이 적합하지만 프로세스, 권한, 설정 업데이트, 로그 순환을 직접 관리해야 합니다. 리소스가 제한된 환경에서는 규칙 규모와 연결 검사 빈도를 줄이고 디버그 로그가 저장 공간을 계속 차지하지 않도록 하세요. 원격에서 변경하기 전에 복구할 수 있는 관리 경로를 확보하고 설정을 검사한 뒤 서비스를 다시 불러오세요. 데스크톱 클라이언트가 생성한 전체 설정을 라우터로 옮길 때는 파일 경로, 수신 주소, 권한 차이도 확인해야 합니다.

사무실이나 게스트 네트워크에서 UDP를 제한한다면 QUIC을 계속 재시도하기보다 사용 가능한 TCP 설정을 먼저 확인하세요. 추가 프록시나 게이트웨이를 거쳐야 한다면 여러 겹의 캡슐화와 주소 조회 방식의 차이도 확인해야 합니다. 특정 접속 네트워크에서만 노드가 실패한다면 다른 네트워크에서 먼저 재검사한 뒤 로컬 설정을 확인하세요. 반대로 모든 네트워크에서 같은 인증 단계에 실패한다면 자격 증명, 인증서, 프로토콜 필드를 확인하는 편이 우선입니다.

일관된 검증 및 롤백 순서

처음 검증할 때는 설정이 로드되는지 확인하고, 기본 연결을 설정한 다음 규칙, DNS, 대상 앱을 차례대로 점검하세요. 각 단계에서 코어가 어떤 프로토콜을 인식했는지, 요청에 어떤 정책이 적용됐는지, 실제 출구가 예상과 일치하는지 명확하게 기록하세요. 실패하면 가장 최근에 정상 작동했던 설정으로 돌아가세요. 코어, 구독 출처, 네트워크 모드를 한꺼번에 바꾸지 마세요. 클라이언트가 비정상 종료되는 문제와 프로토콜 핸드셰이크 실패는 별도로 살펴봐야 합니다. 비정상 종료 문제는 시작 중 충돌 및 로그 문제 해결을 참고하세요.

1. 서버 프로토콜과 클라이언트 코어를 대조하고 신원, 전송, 보안 계층 필드를 확인하세요.
2. 사용 가능한 것으로 확인된 네트워크에서 일반 웹 페이지를 테스트해 실제 적용된 정책을 확인하세요.
3. 지속 전송, 실시간 앱, 유휴 후 연결 복구를 각각 테스트하고 실패 단계를 기록하세요.
4. 변수 하나만 바꿔 같은 작업을 다시 수행한 뒤 설정을 유지할지 되돌릴지 결정하세요.

최종적으로는 주로 사용할 설정과 검증된 대체 설정을 각각 마련하는 것이 좋습니다. 두 설정이 같은 장애 경로에 의존하지 않도록 하위 전송 조건이 다른 방식을 선택하세요. 단, 자격 증명과 설정 출처는 신뢰할 수 있어야 합니다. 클라이언트를 설치하려면 다운로드 페이지에서 운영체제에 맞는 항목을 선택하세요. 우선 추천하는 앱은 Clash Plus입니다. 구체적인 절차는 사용 가이드를, 일반적인 문제는 자주 묻는 질문을 참고하세요. 프로토콜은 연결 방식일 뿐, 모든 네트워크에서 원하는 결과를 보장하지 않습니다.