Clash 프로토콜·코어 가이드

코어 간 관계: Clash 원본, Meta, mihomo

클라이언트·코어·서버의 역할

클라이언트는 사용자가 조작하는 화면으로, 설정 가져오기와 구독 관리, 프록시 그룹 표시를 담당하며 시스템 프록시 설정이나 가상 네트워크 인터페이스 사용을 요청합니다. 코어는 설정을 해석하고 규칙을 적용하며 도메인을 조회하고 실제 연결을 설정합니다. 서버는 원격에서 프로토콜 접속 지점을 제공하는 프로그램입니다. 서로 역할을 대신할 수는 없습니다. 클라이언트 화면을 바꿔도 원격 서버의 프로토콜이 달라지지 않으며, 구독의 유형 이름을 다른 프로토콜로 바꿔도 서버가 해당 프로토콜을 지원하게 되지는 않습니다. 호환성을 판단하려면 클라이언트가 사용하는 코어, 코어가 구현한 프로토콜, 서버가 요구하는 설정을 모두 확인해야 합니다.

Clash 원본은 프록시, 프록시 그룹, 규칙을 YAML로 정의하는 사용 방식을 정립했고, 이후 생태계에서도 많은 필드와 개념을 이어받았습니다. 원본 프로젝트는 더 이상 유지 관리되지 않습니다. 오픈 소스 구현과 과거에 존재했던 Premium 브랜치도 기능 구성이 완전히 같지는 않으므로, Clash라고 표시된 예전 가이드를 모두 같은 기술 사양으로 보면 안 됩니다. Meta는 이 생태계에서 프로토콜과 네트워크 기능을 확장한 코어 프로젝트로 시작했고, 이후 mihomo라는 이름으로 개발이 이어지고 있습니다. 현재 Clash Meta의 옛 문서를 참고할 때는 이름만 보고 구버전 여부를 판단하지 말고, 최신 mihomo 설정 문서와 함께 살펴보세요.

이름이 이어진다고 모든 필드가 양방향으로 호환되는 것은 아닙니다

mihomo는 널리 쓰이는 설정 구조를 다수 유지하면서 프로토콜 지원, DNS 동작, 규칙 기능을 확장했습니다. 이러한 호환성은 기존 설정을 새 구현으로 옮기는 데 도움이 되지만, 새 설정을 구형 코어에서 실행할 수 있다는 뜻은 아닙니다. VLESS, Hysteria2 또는 특정 TLS 옵션이 포함된 구독은 오래된 클라이언트에서 바로 파싱에 실패할 수 있습니다. 가져오기는 성공해도 특정 노드를 사용할 때 오류가 발생할 수도 있습니다. 그래픽 클라이언트의 버전과 코어 버전은 별개의 정보입니다. 문제를 제보할 때는 설치 파일 이름만 적지 말고 두 버전을 각각 기록하세요.

데스크톱에서 실제 적용된 설정 확인

클라이언트는 우선 Clash Plus를 추천합니다. 다른 화면 구성을 비교하려면 다운로드 페이지에서 Clash Verge Rev, FlClash 등의 선택지를 확인하세요. 클라이언트마다 설정 관리 방식이 다르므로, 모든 프로젝트에 같은 코어 전환 메뉴가 있다고 가정하면 안 됩니다. 정보, 실행 정보 또는 로그 화면에서 코어 이름을 찾고, 실행 설정에 구독 내용이 포함되어 있는지 확인하세요. 클라이언트는 구독, 전역 재정의 설정, 로컬 규칙을 합쳐 코어에 전달할 수도 있습니다. 따라서 원본 파일과 실제 적용 파일이 다르더라도 반드시 오류인 것은 아닙니다.

이전하기 전에 로컬 설정을 내보내고 기존 구독 출처를 보관한 뒤, 정상 작동이 확인된 설정 하나로 테스트하세요. 프로토콜, DNS, TUN, 규칙 세트를 한꺼번에 옮기면 실패 원인을 찾기 어렵습니다. 프로젝트의 계보와 그래픽 인터페이스의 역할은 Clash 오픈 소스 프로젝트 관계도에서 더 확인할 수 있습니다. 생태계 소개를 읽는 이유는 연결을 실제로 처리하는 구성 요소를 찾기 위해서이지, 특정 프로젝트 이름을 호환성 보장으로 여기기 위해서가 아닙니다.

SS와 VMess: 가벼운 전달과 인증 구조

Shadowsocks의 설계 범위

Shadowsocks는 보통 SS로 줄여 부르며, 비교적 단순한 암호화 프록시 모델을 사용합니다. 클라이언트가 목적지 주소를 서버에 전달하고 데이터를 중계하며, 프로토콜 자체에 완전한 HTTP 페이지나 인증서 체계가 필요한 것은 아닙니다. 설계의 핵심은 프로토콜 부담을 줄이고 전달 역할을 명확히 하는 데 있으며, 라우팅이나 구독 관리, 그래픽 인터페이스까지 프로토콜에 포함하지 않습니다. 클라이언트에서 SS 노드를 설정할 때는 일반적으로 서버 주소, 포트, 비밀번호, 암호화 방식을 입력합니다. 네 항목 모두 서버 설정과 일치해야 합니다. 암호화 방식은 프로토콜 매개변수이지 사용자가 임의로 바꿔 성능을 조정하는 옵션이 아닙니다.

초기 SS는 스트림 암호 방식을 사용했으며, 이후 AEAD 방식은 기밀성과 무결성 보호를 결합했습니다. Shadowsocks 2022는 키와 세션 설계가 또 다릅니다. 모두 SS라고 표시되어도 서로 바꿔 사용할 수 있는 구현이라는 뜻은 아닙니다. 특히 정해진 길이와 인코딩 형식의 키를 요구하는 방식에는 일반 텍스트 비밀번호를 그대로 입력하면 안 됩니다. 선택할 때는 구형 클라이언트에 맞춰 매개변수를 임의로 낮추기보다 양쪽에서 지원하는 최신 방식을 먼저 확인하세요. 기기에 해당 암호화 가속 기능이 있는지도 방식별 실제 자원 사용량에 영향을 줄 수 있습니다.

SS의 TCP와 UDP 전달 지원 여부는 각각 확인해야 합니다. 브라우저에서 웹페이지가 열린다고 해서 해당 경로로 연결할 수 있다는 뜻일 뿐, 게임이나 음성 통화 등 UDP 앱도 사용할 수 있다고 단정할 수는 없습니다. 일부 SS 설정은 추가 플러그인에 의존합니다. 플러그인 이름과 매개변수, 클라이언트 지원 여부도 연결 조건에 포함됩니다. 기본 SS 노드는 작동하지만 플러그인이 포함된 노드만 실패한다면 서버 전체의 문제라고 판단하기 전에 플러그인 구현과 설정을 확인하세요. 프로토콜 자체와 추가 전송 계층은 구분해서 살펴봐야 합니다.

VMess의 사용자 인증과 전송 옵션

VMess는 V2Ray 생태계에서 시작했으며, 프록시 요청에 사용자 인증과 데이터 보호 기능을 포함하고 여러 전송 방식을 조합할 수 있습니다. 일반적인 설정에는 UUID, 암호화 옵션, TLS 사용 여부, WebSocket 등의 전송 매개변수가 포함됩니다. VMess의 과거 설정에는 구형 인증 방식과 이후 도입된 AEAD 방식이 있으므로, 오래된 구독을 가져올 때 서버와 코어의 지원 범위를 확인해야 합니다. 가이드에 예전 필드가 나온다고 해서 현재 노드에 그대로 복사하지 마세요. 판단 기준은 서버가 제공한 설정의 의미이며, 클라이언트가 일부 구형 조합을 더는 지원하지 않을 수도 있습니다.

VMess는 시스템 시간이 정확해야 합니다. 기기 시계가 실제 시간과 크게 어긋나면 인증에 실패할 수 있으며, 일반적인 연결 시간 초과처럼 보이기도 합니다. 문제를 해결할 때는 먼저 자동 시간 동기화가 정상인지 확인한 다음 UUID와 전송 계층 설정을 점검하세요. WebSocket을 사용하는 경우 경로와 Host 등은 서버에서 요구한 값과 일치해야 합니다. 외부 계층에 TLS를 사용하는 경우 인증서에 설정된 이름도 확인하세요. 계층을 하나 추가할 때마다 일치해야 하는 매개변수도 늘어납니다. 구독을 성공적으로 가져왔더라도 이러한 값이 검증된 것은 아닙니다.

두 유형의 노드 비교하기

서버 환경이 같다면 기본 SS의 프로토콜 경로가 대체로 단순합니다. VMess의 실제 부담은 암호화 방식과 외부 전송 계층에 따라 달라집니다. 다만 서버가 다르면 거리, 대역폭, 혼잡, 서비스 제한이 캡슐화 차이보다 더 큰 영향을 주는 경우가 많습니다. 안정적인 SS 노드를 사용 중이고 필요한 앱이 문제없이 작동한다면 유형 이름을 바꾸기 위해 이전할 필요는 없습니다. VMess를 사용해야 한다면 서버가 제공한 매개변수 조합을 그대로 적용하고, 비교를 위해 검증된 연결 경로 하나를 유지하세요. 일반 사용자에게는 프로토콜 이름보다 설정이 완전한지, 장기간 안정적인지, 관리 상태가 명확한지가 더 중요한 판단 기준입니다.

Trojan과 VLESS: 인증과 TLS의 역할

Trojan: TLS가 연결을 보호하는 방식

Trojan은 TLS 연결 안에서 프록시 인증을 처리하며 비밀번호로 클라이언트를 식별하고, TLS가 전송 데이터의 기밀성과 무결성을 보호합니다. HTTPS 웹사이트 주소를 프록시 주소로 쓰는 방식도 아니고, 비밀번호만 입력하면 연결되는 것도 아닙니다. 서버 주소, 수신 포트, 비밀번호, TLS 이름, 인증서 신뢰 관계가 모두 맞아야 합니다. 클라이언트는 보통 시스템이나 코어의 신뢰 설정으로 서버 인증서를 확인합니다. 인증서가 만료되었거나 이름이 일치하지 않거나 기기 시간이 잘못되면 프록시 인증 단계에 도달하기 전에 핸드셰이크가 실패할 수 있습니다.

연결에 사용하는 서버 주소와 TLS 검증에 사용하는 이름은 다를 수 있지만, 실제 서버 배포 설정에 따른 차이여야 합니다. 서버 주소는 접속할 위치를 정하고, SNI는 일반적으로 TLS 핸드셰이크에서 대상 서비스를 알립니다. 인증서 검증은 상대방의 신원이 예상한 값과 일치하는지 확인합니다. SNI를 다른 도메인으로 임의 변경해도 인증서 문제는 해결되지 않습니다. 인증에 실패하면 올바른 이름과 인증서 체인, 기기 시계를 확인하세요. 인증서 검증을 끄는 것은 장기적인 기본 설정으로 삼지 마세요. 서버 신원을 확인하는 중요한 절차가 사라집니다.

VLESS: 인증 구조가 간단해도 암호화를 단독으로 제공하지는 않습니다

VLESS는 V2Ray/Xray 관련 생태계에서 발전했으며, 프로토콜 계층의 인증과 전달 구조를 단순화하고 UUID로 사용자를 식별하는 경우가 많습니다. VLESS 자체는 외부 TLS와 같은 콘텐츠 암호화를 제공하지 않으므로 보안을 논할 때는 전체 연결 구성을 밝혀야 합니다. TLS, REALITY 또는 지원되는 다른 전송 방식과 결합한 VLESS는 유형만 VLESS로 표시된 설정과 다릅니다. 서비스 제공업체가 안내한 매개변수 전체를 가져오세요. ‘가볍다’는 이유로 연결 보호를 생략하거나, 특정 구현의 확장 기능을 모든 클라이언트가 지원한다고 단정하지 마세요.

REALITY는 특정 구현에서 제공하는 핸드셰이크 방식이지 일반 인증서 모드를 다르게 표기한 이름이 아닙니다. 설정에는 공개 키, 짧은 식별자, 서비스 이름 등이 필요할 수 있으며, 서버 설정과 일치해야 합니다. 일부 VLESS 조합에는 Vision 관련 모드와 같은 flow 설정도 포함됩니다. flow 값이 길수록 좋은 것도 아니고, 모든 전송 방식에서 사용해야 하는 것도 아닙니다. 서버가 지정하지 않았다면 다른 노드 설정을 복사하지 마세요. 알 수 없는 필드, 핸드셰이크 실패, 연결 직후 끊김이 발생하면 UUID만 확인하지 말고 코어 지원 여부와 전체 매개변수 조합을 먼저 점검하세요.

전송 계층 조합에 따른 성능 차이

Trojan과 VLESS는 전송 조합에 따라 성능 차이가 크게 날 수 있습니다. TCP와 TLS를 직접 연결하는 방식과 WebSocket 또는 다른 애플리케이션 계층 전송을 더하는 방식은 핸드셰이크와 캡슐화 부담이 다릅니다. 외부 서비스의 유휴 시간 제한, 연결 재사용, 중간 네트워크 장비도 안정성에 영향을 줍니다. 노드를 평가할 때는 Trojan이나 VLESS라는 유형만 기록하지 말고 TLS 사용 여부와 전송 방식 등 전체 조합을 적으세요. 서버의 연결 수 제한과 자원 할당도 병목이 될 수 있습니다.

주로 웹 탐색이나 원격 근무에 사용할 경우 인증서가 유효하고, 설정이 완전하며, 반복 테스트에서도 안정적인 구성을 우선 선택하세요. VLESS가 프로토콜 계층에서 중복 암호화를 하지 않는다고 해서 Trojan보다 반드시 빠르다고 결론 내릴 수는 없습니다. Trojan이 TLS를 사용한다고 해서 반드시 배터리를 더 많이 소모하는 것도 아닙니다. 실제 부담은 전체 연결 스택에서 발생합니다. 문제가 생기면 TLS 검증을 켠 상태로 오류 유형을 확인하고, 접속 주소와 서비스 이름, 인증 정보를 각각 검증하세요. 보안 옵션을 느슨하게 해 실제 불일치를 가리지 않도록 주의해야 합니다.

Hysteria2와 TUIC: QUIC 기반 전송 방식 비교

QUIC이 바꾸는 계층

Hysteria2와 TUIC는 모두 QUIC을 사용하지만 같은 프로토콜의 다른 이름은 아닙니다. QUIC은 일반적으로 UDP에서 실행되며 암호화 핸드셰이크, 안정적인 전송, 다중 스트림 관리를 결합합니다. 여러 스트림을 사용할 때 한 스트림의 손실 데이터가 공유 TCP 바이트 스트림처럼 다른 스트림의 전달까지 막을 필요는 없습니다. 다만 모든 스트림이 연결의 혼잡 상태와 대역폭을 공유할 수 있으므로, ‘헤드 오브 라인 블로킹 감소’가 ‘패킷 손실에 따른 비용이 없음’을 뜻하지는 않습니다. 기본 UDP 연결이 불가능하면 QUIC도 연결을 만들어낼 수 없습니다.

프록시를 통해 앱의 TCP 트래픽을 전달할 때 앱에서는 여전히 안정적인 연결로 보일 수 있으며, 외부 전송은 프로토콜이 담당합니다. 앱 자체의 UDP 데이터그램은 보통 별도의 전달 방식을 사용합니다. 두 방식의 안정성 요구는 서로 다릅니다. 프록시가 UDP에서 동작한다고 해서 앱 데이터가 모두 비신뢰성 전송으로 바뀌는 것은 아닙니다. 반대로 모든 데이터그램이 TCP와 똑같은 보장을 받는다고 볼 수도 없습니다. 실시간 음성, 게임, 파일 전송 성능을 평가하려면 앱의 트래픽 유형과 프록시의 실제 처리 방식을 각각 확인해야 합니다.

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

Hysteria2는 처리량과 복잡한 네트워크 환경을 고려해 설계되었으며, 대역폭 추정과 혼잡 제어 관련 기능을 제공합니다. 설정의 업로드 및 다운로드 대역폭 값은 대역폭 구매를 의미하지 않으며, 높게 입력할수록 속도가 빨라지는 것도 아닙니다. 이 값은 구현이 전송 속도를 판단하는 방식에 영향을 줍니다. 실제 동작은 서버 정책과 협상 결과에도 좌우됩니다. 지나치게 높게 추정하면 큐 지연이나 패킷 손실이 발생하거나 다른 앱과 대역폭을 다툴 수 있고, 너무 낮게 추정하면 처리량이 제한될 수 있습니다. 서비스 제공업체가 값과 단위를 명시한 경우에만 조정하세요.

Hysteria의 버전도 구분해야 합니다. Hysteria라고 표시된 구형 노드는 Hysteria2와 같은 것이 아니며, 이름만 바꿔서는 유형, 인증, 매개변수를 이전할 수 없습니다. 일부 배포에서는 추가 난독화나 포트 관련 설정을 사용하므로 서버 요구 사항에 맞춰야 합니다. 클라이언트가 Hysteria2를 지원한다는 것은 해당 구현이 있다는 뜻일 뿐, 구독에 포함된 모든 확장 옵션까지 지원한다는 보장은 아닙니다. 문제를 해결할 때는 먼저 프로토콜 버전을 확인하고 UDP 경로, 인증 정보, TLS 이름을 점검하세요. 복잡한 옵션을 모두 켜서 시험하지 마세요.

TUIC: 연결 재사용과 전달 방식

TUIC 역시 QUIC으로 프록시 연결을 전송하며 연결 재사용과 UDP 전달 등의 요구를 다룹니다. 일반적인 설정에는 UUID, 비밀번호, 혼잡 제어 알고리즘, UDP 전달 모드가 포함됩니다. 프로토콜 개정판이나 구현체에 따라 호환 범위가 다를 수 있으므로 유형 이름이 같아도 추가로 확인해야 합니다. 일부 옵션은 QUIC을 통한 데이터그램 전송 방식을 바꿔 부담, 패킷 손실 처리, 네트워크 경로 요구에 영향을 줍니다. 이는 서버와 클라이언트가 함께 합의해야 하는 동작이지, 상대 설정과 무관하게 바꿀 수 있는 최적화 버튼이 아닙니다.

QUIC 헤더, 암호화, 사용자 공간 전송 처리에도 자원이 사용됩니다. 처리량이 높은 환경에서는 구형 기기의 CPU 사용량이 늘 수 있습니다. 무선 네트워크를 전환할 때 연결을 원활하게 유지할 수 있는지는 프로토콜 구현, 주소 변경, 서버 정책에 따라 달라집니다. QUIC에 연결 마이그레이션 기능이 있다고 해서 휴대전화가 네트워크를 바꿔도 모든 세션이 끊기지 않는다고 보장할 수는 없습니다. 재인증이 필요한 앱은 새 연결을 직접 만들 수도 있습니다. 이는 프록시가 세션을 유지하는지와는 다른 계층의 문제입니다.

Hysteria2나 TUIC를 선택하려면 서버 지원, 코어 호환성, 현재 네트워크의 UDP 적합성이 먼저 확인되어야 합니다. 대용량 파일이나 다중 스트림 작업은 실제 사용 시간대에 반복 비교하세요. 배터리가 중요한 모바일 기기라면 발열, 백그라운드 동작, 네트워크 전환 후 복구 상태도 함께 살펴보세요. 문제를 찾기 쉽게 TCP 계열 노드를 비교 대상으로 유지하되, 별도의 후보 설정으로 두어야 합니다. QUIC 노드의 유형을 TCP로 바꿔 연결을 시도하지 마세요.

연결 속도, 자원 사용량, 모바일 배터리

‘빠르다’를 관찰 가능한 네 단계로 나누기

웹페이지를 눌러 내용이 표시되기까지는 최소한 도메인 조회, 연결 설정, 첫 응답 수신, 후속 데이터 전송의 네 단계가 필요합니다. 노드 지연 시간 테스트는 보통 이 중 일부만 측정하며 테스트 URL, 연결 재사용, 캐시의 영향을 받습니다. 핸드셰이크가 짧다고 다운로드 속도가 더 빠른 것은 아니며, 대역폭이 높다고 작은 웹페이지가 더 빨리 표시되는 것도 아닙니다. 프로토콜을 비교하기 전에 해결하려는 문제가 최초 접속 지연인지, 지속 다운로드 속도인지, 간헐적 연결 끊김인지 확인하세요. 각 현상의 병목이 다르므로 테스트 숫자 하나만으로 결론 내리면 정반대의 판단을 할 수 있습니다.

첫 연결에서는 TCP, TLS, QUIC의 핸드셰이크에 왕복 시간이 걸릴 수 있지만, 세션 복구와 기존 연결 재사용, 구현 방식에 따라 실제 부담은 달라집니다. 고정된 핸드셰이크 횟수만으로 모든 노드를 순위 매기지 마세요. 원격 서버 응답 시간, DNS 조회 위치, 연결 재사용 여부도 체감에 영향을 줍니다. 처음만 느리고 이후 정상이라면 새 연결의 DNS 조회와 핸드셰이크를 따로 확인하세요. 전송이 계속될 때만 느려진다면 혼잡, 서버 속도 제한, 기기 처리 능력을 살펴보는 편이 좋습니다.

공정한 비교를 위해 변수를 통제하세요

가능한 한 비슷한 지역과 서비스 조건, 같은 테스트 대상을 선택하고 동일한 기기와 네트워크에서 번갈아 테스트하세요. 매번 전송 방식을 포함한 프로토콜 전체 조합을 기록하고, 프록시 그룹 선택을 고정하며, 한쪽 요청만 직접 연결되도록 규칙이 작동하지 않았는지 확인하세요. 노드와 DNS, TUN 상태를 동시에 바꾸지 말고, 한쪽은 백그라운드 다운로드 중인데 다른 쪽은 유휴 상태인 결과를 비교하지 마세요. 테스트 순서를 번갈아 진행하면 앞선 테스트는 한가한 네트워크에서, 뒤의 테스트는 혼잡 시간대에 이루어진 차이를 프로토콜 차이로 오해하는 일을 줄일 수 있습니다.

모바일에서는 기기를 깨우는 동작도 큰 부담입니다

휴대전화 배터리는 암호화 연산뿐 아니라 무선 통신, 백그라운드 깨우기, 반복적인 재연결에도 소모됩니다. 연결 유지를 너무 자주 보내면 연결은 안정적으로 유지될 수 있지만 무선 통신이 활성화되는 시간도 늘어날 수 있습니다. 간격이 너무 길면 라우터나 통신사 네트워크가 유휴 매핑을 정리해 다음 연결 때 핸드셰이크를 다시 해야 할 수도 있습니다. 적절한 간격은 접속 네트워크에 따라 다릅니다. 인터넷에서 찾은 매우 짧은 연결 유지 간격을 모든 프로토콜에 똑같이 적용하지 말고, 화면을 잠근 뒤 몇 분간의 배터리 변화만으로 장기적인 사용량을 판단하지 마세요.

시스템 프록시와 TUN의 적용 범위도 배터리 사용량 관찰에 영향을 줍니다. 시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 적용되지만, TUN은 더 많은 트래픽을 처리해 DNS 및 연결 이벤트까지 늘릴 수 있습니다. 같은 노드에서 TUN으로 전환한 뒤 배터리 사용량이 증가했다면 프로토콜이 갑자기 나빠진 것이 아니라 처리량이 늘어난 탓일 수 있습니다. 디버그 로그, 잦은 자동 프록시 그룹 테스트, 빈번한 구독 갱신도 추가 활동을 유발합니다. 비교 전에 이런 설정을 통일하고 충분한 시간 동안 관찰하세요.

데스크톱에서는 코어 프로세스의 CPU와 메모리 사용량, 연결 동작을 함께 살펴볼 수 있습니다. 모바일에서는 시스템 배터리 통계와 발열, 백그라운드 제한을 함께 확인하세요. 순간적인 처리량 급증으로 CPU 사용량이 늘었다고 해서 지속적인 이상은 아닙니다. 메모리 캐시가 증가해도 반드시 누수가 있다는 뜻은 아닙니다. 동일한 작업 부하에서 반복되는 추세가 유용한 판단 근거입니다. 최종 선택은 자주 사용하는 앱의 반응과 안정성을 기준으로 하세요. 테스트 결과는 문제를 찾는 도구로 활용하고, 사용 환경과 무관한 속도 순위나 배터리 순위를 만들지 마세요.

구독 형식과 설정 호환성: 가져오기부터 적용까지

노드 목록과 전체 설정을 구분하세요

구독 URL은 콘텐츠를 가져오는 주소이지 그 자체가 형식은 아닙니다. 같은 주소라도 매개변수나 클라이언트 식별 정보에 따라 다른 콘텐츠를 반환할 수 있습니다. Clash YAML에는 보통 프록시, 프록시 그룹, 규칙이 포함됩니다. 노드 공유 링크에는 연결 하나의 정보만 들어 있을 수 있고, Base64 목록에는 여러 공유 링크를 인코딩한 내용이 담기는 경우가 많습니다. 파일 확장자나 웹페이지의 다운로드 버튼 문구만으로 실제 콘텐츠 형식을 보장할 수는 없습니다. 가져오기 전에 제공업체가 명시한 대상 형식을 확인하세요. 파싱 오류가 발생하면 콘텐츠 유형을 살펴보고, 링크 문자를 무작정 바꿔가며 반복 시도하지 마세요.

mihomo 설정에서 proxies는 연결 매개변수를 정의하고, proxy-groups는 프록시 그룹을 구성하며, rules는 트래픽에 적용할 프록시 그룹을 결정합니다. 노드 목록만 받은 경우 클라이언트가 프록시 그룹을 자동으로 생성할 수도 있고, 사용자가 전체 설정을 보완해야 할 수도 있습니다. 가져오기는 성공했지만 노드만 있고 사용할 규칙이 없는 상황은 프로토콜 비호환과 다른 문제입니다. 관련 형식의 가져오기 방법은 구독 링크와 로컬 YAML 파일 가져오기 안내를 참고하세요. 설정 자동 생성 기능을 프로토콜 자동 변환으로 오해하지 마세요.

형식 변환으로 누락된 정보를 보충할 수는 없습니다

변환 도구는 기존 필드를 재배치할 수는 있지만 누락된 비밀번호, TLS 이름, 서버별 매개변수를 추측할 수는 없습니다. 구형 코어가 지원하지 않는 프로토콜을 구현해 주지도 않습니다. 일부 공유 형식은 복잡한 전송 옵션을 모두 표현할 수 없어서 변환 후 정상적인 YAML처럼 보여도 중요한 필드가 빠질 수 있습니다. 출처에서 mihomo 전용 구독도 제공한다면 그에 맞는 출력을 우선 사용한 다음 클라이언트가 다시 처리했는지 확인하세요. 구독 URL을 처리하는 도구는 접근 자격 정보에 노출될 수 있으므로 사용 전에 데이터 처리 위치와 저장 방식을 확인해야 합니다.

YAML의 들여쓰기와 필드 유형, 참조 관계도 호환성의 일부입니다. 포트는 보통 숫자여야 하고 불리언 값에는 true 또는 false를 사용해야 하며, 참조하는 이름은 대상과 정확히 일치해야 합니다. 프록시 그룹 이름을 Proxy로 작성했는데 규칙은 다른 철자의 이름을 가리키면 해당 프록시 그룹을 찾지 못합니다. YAML 파서가 문법을 읽을 수 있어도 필드가 코어의 설정 스키마에 맞는다는 뜻은 아닙니다. 문법 오류, 설정 의미 오류, 실행 중 연결 오류를 차례로 구분하세요. 모든 문제를 해결하기 위해 클라이언트를 다시 설치하지 마세요.

# 로컬 접속 지점과 라우팅 예시; Proxy 프록시 그룹은 전체 설정에서 정의해야 합니다
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,local,DIRECT
  - DOMAIN-SUFFIX,github.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

위 내용은 전체 설정에 합쳐 사용할 예시이며 서버 접속 정보는 포함하지 않습니다. mixed-port는 HTTP와 SOCKS가 함께 사용하는 로컬 접속 포트입니다. allow-lan: false는 이 프록시 접속 지점을 로컬 네트워크에 공개하지 않습니다. mode: rule은 규칙에 따라 요청을 처리하고, log-level: info는 일반적인 실행 상태를 확인할 때 사용합니다. 포트는 실제 환경에 맞게 바꿀 수 있으며 이 값이 모든 클라이언트의 기본 설정을 뜻하지는 않습니다. 규칙은 위에서 아래 순서로 검사하고, 처음 일치하는 규칙의 프록시 그룹을 사용합니다. 마지막 MATCH 규칙이 나머지 요청을 처리합니다.

구독 갱신, 재정의 설정, 구성 이전

구독으로 생성된 파일을 직접 수정하면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 클라이언트에서 제공하는 재정의, 확장 또는 병합 기능을 우선 사용하고 업데이트 후에도 적용되는지 확인하세요. 배열을 교체하는지 추가하는지는 클라이언트마다 다를 수 있습니다. MATCH 뒤에 규칙을 추가하면 보통 의도한 결과를 얻을 수 없습니다. 삽입 위치는 사용자 지정 규칙 문법과 우선순위를 참고하세요. 이전할 때는 먼저 노드와 기본 프록시 그룹만 유지해 검증한 뒤 DNS, 규칙 세트, 기타 확장을 복구하세요. 편집기에서 보이는 문구만 확인하지 말고 실제 실행 설정을 항목별로 점검해야 합니다.

사용 환경에 맞는 프로토콜과 클라이언트 선택

일반 웹 탐색, 업무, 지속적인 다운로드

일반적인 웹 탐색과 원격 근무에서는 연결이 안정적으로 설정되는지, 인증서 검증이 정상인지, 자주 사용하는 서비스에 지속적으로 접속할 수 있는지를 먼저 확인하세요. 기존 SS, Trojan, VLESS 설정이 이 조건을 만족한다면 새 프로토콜 이름 때문에 바꿀 필요는 없습니다. 업무용 앱은 장시간 연결을 유지할 수도 있고 회사 네트워크의 접속 정책에 영향을 받을 수도 있으므로 허용된 사용 방식을 먼저 확인하세요. 원격 데스크톱이나 협업 도구가 끊기면 웹페이지 지연 시간을 한 번 재는 것보다 유휴 시간 제한과 네트워크 전환을 점검하는 편이 문제에 더 가깝습니다.

지속적인 다운로드에서는 장시간 처리량, 패킷 손실 복구, 서버 제한을 확인해야 합니다. UDP 경로가 정상이라면 Hysteria2나 TUIC를 비교 후보로 시험할 수 있지만, 기본적으로 더 낫다고 볼 수는 없습니다. 회선 대역폭이 제한되어 있다면 어떤 프로토콜도 실제 접속 한계를 넘을 수 없습니다. 지나치게 공격적인 전송 방식은 같은 네트워크의 화상 회의나 다른 기기까지 느리게 할 수 있습니다. 비교할 때는 다운로드 작업과 다른 앱의 반응을 함께 관찰하고, 짧은 순간의 최고 속도가 아니라 전체 작업에 적합한 설정을 선택하세요.

음성 통화, 게임, 모바일 네트워크

실시간 앱은 평균 처리량보다 지터, 패킷 손실, 순간적인 멈춤에 더 민감할 수 있습니다. 먼저 앱의 트래픽이 실제로 프록시를 거치는지, 노드와 코어가 필요한 UDP 전달을 지원하는지 확인하세요. 일부 앱은 시스템 프록시 설정을 따르지 않으므로 시스템 프록시만 켜서는 트래픽을 처리할 수 없습니다. TUN이 필요하다면 권한과 라우팅을 먼저 점검하세요. 프록시가 UDP를 전송하더라도 원격 출구 서버, 대상 서비스, 중간 네트워크가 해당 데이터를 허용한다는 보장은 없습니다. 연결 기록에서 대상과 출구를 확인해야 합니다.

휴대전화가 Wi-Fi와 모바일 데이터 사이를 자주 오갈 때는 복구 속도, 백그라운드 재연결, 화면 잠금 중 동작을 살펴보세요. 고정 유선망에서 성능이 뛰어난 QUIC 노드도 다른 접속 환경에서는 UDP 경로의 영향을 받을 수 있습니다. 일반적인 TCP 노드도 서버의 유휴 시간 제한 때문에 연결을 자주 다시 설정해야 할 수 있습니다. 데스크톱 결과를 그대로 휴대전화에 적용하지 말고 실제 통근이나 이동 환경에서 평가하세요. 배터리가 걱정된다면 불필요한 백그라운드 탐색을 줄인 다음 프로토콜 차이를 비교하세요.

설정 지원 여부부터 확인하고 클라이언트를 선택하세요

처음 설치한다면 먼저 Clash Plus를 확인하고 운영체제와 사용 습관에 따라 다른 클라이언트와 비교하세요. Windows 다운로드 페이지에서는 Clash Verge Rev, FlClash, Clash Nyanpasu도 제공합니다. Clash for Windows는 유지 관리가 중단된 것으로 표시되어 있습니다. macOS에서는 Clash Plus, Clash Verge Rev, FlClash를 비교할 수 있으며 ClashX Meta는 유지 관리가 중단된 보관 프로젝트입니다. 구형 프로젝트가 일부 구독을 가져올 수 있다고 해서 새 프로토콜 확장에 적합한 것은 아닙니다. 과거 화면 캡처만 보고 현재 코어의 기능을 판단하지 마세요.

Android에서는 다운로드 페이지의 순서에 따라 Clash Plus, Clash Meta for Android, FlClash, Surfboard를 비교하고 대상 프로토콜과 구독 형식을 하나씩 확인하세요. 모든 앱이 완전히 같은 설정 문법을 사용한다고 가정하면 안 됩니다. iOS에서는 Clash Plus를 우선 추천합니다. 공식 사이트는 clashplus.io입니다. Linux에서는 Clash Verge Rev와 FlClash를 비교할 수 있습니다. 일반 데스크톱 사용자는 그래픽 클라이언트를 먼저 선택하고, 프로세스와 서비스, 권한을 직접 관리해야 할 때만 mihomo 코어를 직접 배포하는 편이 좋습니다.

선택 순서는 다음과 같이 정할 수 있습니다. 현재 기기가 지원하는 것, 서버가 제공하는 것, 접속 네트워크가 허용하는 것을 확인한 뒤 마지막으로 성능을 비교합니다. 후보마다 전체 매개변수 안내와 연결 성공 기록을 보관해 나중에 설명할 수 없는 노드 이름만 남지 않도록 하세요. 여러 후보를 함께 사용할 때는 수동 선택으로 테스트 출구를 고정한 다음 자동 프록시 그룹을 단계적으로 활성화합니다. 자동 선택으로 실제 출구가 가려지면 개선이 프로토콜, 서버, 프록시 그룹 전환 중 어디서 비롯되었는지 판단할 수 없습니다. 사용 방법은 사용 가이드에서, 용어는 용어 설명에서 확인하세요.

검증과 문제 해결: 오류가 발생한 계층부터 찾기

요청이 클라이언트에 전달되는지 먼저 확인하세요

문제 해결은 프로토콜을 바꾸기보다 로컬 접속 지점부터 시작해야 합니다. 코어가 실행 중이고 설정이 정상적으로 로드되었는지 확인한 다음 시스템 프록시가 가리키는 주소와 포트를 점검하세요. 앱이 시스템 프록시를 따르지 않는다면 TUN과 관련 권한이 필요한지 확인하세요. 확실한 테스트 대상을 열고 연결 기록에서 대상 도메인, 일치한 규칙, 출구 프록시 그룹을 찾습니다. 기록이 전혀 없다면 앱의 프록시 설정과 예외 목록, 라우팅 가로채기를 먼저 확인하세요. 기록은 있지만 DIRECT로 연결된다면 원격 노드 비밀번호가 아니라 모드와 규칙을 집중적으로 살펴봐야 합니다.

로컬 접속 지점을 별도로 확인해야 한다면 curl이 설치된 터미널에서 다음의 짧은 명령을 사용할 수 있습니다. 포트는 실제 실행 설정과 일치해야 합니다. 혼합 포트를 변경했다면 명령에도 같은 값을 적용하세요. 응답이 반환되면 해당 요청이 완료되었다는 뜻일 뿐입니다. 연결 기록을 함께 확인해 실제 출구를 확인해야 합니다. 이 명령은 일반 공개 웹페이지를 요청 대상으로 사용합니다. 모든 앱 프로토콜을 확인할 수는 없으며 UDP 앱을 별도로 검증하는 작업도 대신하지 않습니다.

curl -I --proxy http://127.0.0.1:7890 https://example.com/

DNS, 핸드셰이크, 인증 오류를 구분하세요

도메인 조회에 실패하면 프록시 서버의 도메인과 최종 접속 대상 중 어느 쪽의 조회가 실패했는지 먼저 구분하세요. 서버 도메인 조회가 실패하면 원격 연결을 시작할 수 없지만, 최종 대상 조회 문제는 특정 웹사이트에만 영향을 줄 수 있습니다. 서버 주소를 IP로 직접 바꾸면 TLS 이름 처리 방식이 달라질 수 있으므로 임시 비교를 하더라도 서버에서 요구하는 이름 설정은 유지하세요. 연결 시간 초과는 제한된 시간 안에 특정 단계가 완료되지 않았다는 뜻이지, 곧바로 비밀번호가 잘못되었다는 의미는 아닙니다. 로그에 구체적인 원인이 없다면 다른 사용 가능한 노드와 네트워크 환경에서 교차 확인하세요.

TLS 오류가 발생하면 시스템 시간, 인증서 유효 기간, 서비스 이름, 신뢰 체인을 우선 확인하세요. 인증 오류가 발생하면 비밀번호와 UUID, 키 형식, 서버의 계정 허용 여부를 확인합니다. VMess는 시간 차이를, VLESS는 flow와 외부 방식을, Hysteria2와 TUIC는 프로토콜 버전과 UDP 경로, 관련 인증 필드를 각각 확인해야 합니다. 오류 하나를 없애기 위해 인증 검증을 끄고 DNS를 바꾸며 전송 방식까지 한꺼번에 수정하지 마세요. 확인된 변수 하나씩만 바꿔야 결과를 해석할 수 있습니다.

연결은 되지만 앱에 문제가 있으면 중간 경로를 점검하세요

작은 웹페이지는 정상인데 대용량 전송이 멈춘다면 경로 MTU, 패킷 손실, 서버 제한, 기기 자원을 확인하세요. QUIC은 데이터그램 경로에 구체적인 조건이 있으므로 비정상적인 네트워크 장비나 제한된 경로가 연결 또는 전송에 문제를 일으킬 수 있습니다. 그렇더라도 검증 없이 일괄적인 MTU 값을 적용하지 마세요. 특정 앱만 실패한다면 앱이 별도 DNS나 자체 프록시 설정을 사용하는지, 시스템 프록시의 영향을 받지 않는 연결 방식인지 확인하세요. 특정 도메인만 실패한다면 규칙과 DNS 응답을 확인해야 합니다. 이를 근거로 프로토콜 전체가 작동하지 않는다고 판단할 수는 없습니다.

구독 갱신 실패는 설정을 가져오는 경로의 문제이며 실행 중인 노드의 연결 경로와 다를 수 있습니다. 브라우저에서 구독 주소에 접속되더라도 클라이언트가 업데이트할 때 같은 프록시와 인증서 신뢰 설정을 사용한다고 보장할 수는 없습니다. 구독 갱신 실패와 자동 새로고침 설정을 참고해 시간 초과, 인증서, 형식 오류를 각각 확인하세요. 구독 URL 전체를 공개하지 마세요. 경로나 쿼리 매개변수에 계정 접근 정보가 포함될 수 있으므로 스크린샷과 로그에서도 가려야 합니다. 노드 비밀번호와 UUID, 기타 인증 정보도 공개된 문의에 올리지 마세요.

재현 가능한 결과를 남긴 뒤 이전 여부를 결정하세요

문제를 재현할 수 있도록 운영체제, 클라이언트 이름, 실제 코어, 프로토콜 및 전송 조합, 오류 발생 단계, 단일 변수별 테스트 결과를 기록하세요. 필요한 경우 잠시 로그 수준을 높여 재현한 뒤 일반 설정으로 되돌려 로그가 과도하게 쌓이지 않도록 합니다. 새 설정은 실패하지만 기존 설정은 정상이라면 필드와 지원 범위를 먼저 비교하세요. 모든 노드가 동시에 실패한다면 로컬 네트워크와 접속 지점을 먼저 확인해야 합니다. 일반적인 문제는 도움말 센터에서 확인하세요. 코어 기능이 부족하거나 프로젝트의 유지 관리가 중단된 사실을 확인한 뒤 이전을 계획하는 편이 반복해서 재설치하는 것보다 안정적인 결과를 얻기 쉽습니다.