Clash 프로토콜 및 코어 가이드

코어 계열과 클라이언트의 차이

화면·코어·설정의 역할

Clash는 과거 프로젝트 이름이자, Clash 설정 방식과 호환되는 프록시 도구를 통칭하는 말로도 쓰입니다. 실제 실행 시 GUI 클라이언트는 구독 관리, 시스템 프록시 전환, 권한 요청, 화면 조작을 담당하고, 코어는 연결 설정, 규칙 매칭, DNS 처리, 데이터 전달을 담당합니다. 둘은 별도로 업데이트될 수 있으므로 화면이 비슷하다고 해서 지원 프로토콜, 필드, 네트워크 기능까지 같은 것은 아닙니다.

설정은 노드, 프록시 그룹, 규칙, DNS 설정을 연결합니다. 노드를 선택하면 특정 출구의 연결 매개변수가 정해지고, 프록시 그룹을 선택하면 자동 테스트나 장애 전환이 작동할 수도 있습니다. 규칙 모드를 바꾸면 어떤 연결이 해당 출구를 이용할지도 달라집니다. 문제가 생기면 먼저 어느 단계에서 발생했는지 확인해야 합니다. 설정 미적용, 잘못된 프록시 그룹 선택, 프로토콜 핸드셰이크 실패는 서로 다른 문제이므로 클라이언트만 계속 바꿔서는 해결되지 않습니다.

Clash 원본, Meta, mihomo의 관계

원본 Clash는 널리 쓰이는 YAML 설정 구조와 규칙 매칭 방식, 프록시 그룹 개념의 기반을 마련했으며, 원 프로젝트는 이미 유지보수가 중단됐습니다. Clash Premium은 과거에 별도로 배포된 버전으로, 오픈소스 원본과 일부 기능이 다릅니다. 두 버전의 기능을 하나로 묶어 생각해서는 안 됩니다. 오래된 가이드를 볼 때는 제목의 제품명만 보지 말고, 해당 가이드에서 Clash가 어떤 코어를 가리키는지 확인하세요.

Clash Meta는 Clash 설정 생태계와의 호환성을 바탕으로 프로토콜과 기능을 확장했으며, 이후 mihomo라는 이름으로 개발이 이어졌습니다. 따라서 과거 자료의 Meta와 현재의 mihomo는 프로젝트 계보상 직접적인 관계가 있으며, 서로 무관한 별개의 프로토콜 표준이 아닙니다. 다만 이름이 이어진다고 해서 모든 시기의 빌드가 같은 기능을 제공하는 것은 아닙니다. 특히 최신 프로토콜 매개변수, DNS 동작, TUN 옵션은 실제 실행 중인 코어를 기준으로 확인해야 합니다.

클라이언트가 이전 이름을 유지하면서 최신 코어를 탑재할 수도 있고, 반대로 새로운 화면에 오래된 빌드가 포함될 수도 있습니다. 정보, 설정 또는 진단 화면에서 코어 이름을 확인한 뒤 시작 로그의 설정 파싱 결과도 살펴보세요. 설치 파일 이름만으로 판단하지 마세요. 코어 교체 기능을 지원한다면 공식적으로 안내된 절차를 따르고, 인터페이스가 호환되지 않는 실행 파일을 직접 덮어쓰지 마세요.

클라이언트는 사용 편의성부터 확인

일반 사용자는 먼저 다운로드 센터에서 추천 클라이언트인 Clash Plus를 사용해 시스템 지원 여부와 구독 호환성을 확인한 뒤, 데스크톱 사용 방식에 따라 Clash Verge Rev나 FlClash를 고려할 수 있습니다. GUI에서 제공하는 기능은 클라이언트 자체 구현에 따라 달라집니다. 특정 코어를 사용한다고 해서 화면에서 모든 고급 옵션을 설정할 수 있는 것은 아닙니다. 화면에 설정 항목이 없다면 설정 파일로 활성화할 수 있는지도 확인해야 합니다.

보관용 클라이언트는 기존 환경을 재현하거나 오래된 설정을 읽는 데 적합하지만, 새 프로토콜을 선택할 때 기본 기준으로 삼기는 어렵습니다. Clash for Windows와 ClashX Meta는 유지보수가 중단됐습니다. 알 수 없는 노드 유형이 나타나면 오류 필드를 전부 지우기보다 먼저 코어 지원 여부를 확인하세요. Mihomo 코어를 직접 실행하려면 설정, 프로세스, 권한을 직접 관리해야 하므로 서버나 라우터 운영자, 명령줄 관리 경험이 있는 사용자에게 더 적합합니다.

SS와 VMess의 설계 차이

SS: 간결한 암호화 프록시 연결

Shadowsocks는 보통 SS로 줄여 부릅니다. SOCKS 프록시 사용 방식에 기반해 클라이언트와 서버 사이에서 비교적 간결하게 암호화된 데이터를 전달하도록 설계됐습니다. 각 연결에 HTTP 전송 계층을 추가하지 않아 일반적인 설정 구조가 단순합니다. 클라이언트의 서버 주소, 포트, 암호화 방식, 비밀번호가 함께 연결을 구성하며, 어느 하나라도 맞지 않으면 연결 직후 끊길 수 있습니다.

SS를 선택할 때는 노드 유형에 SS라고 적혀 있는지만 볼 것이 아니라 구체적인 암호화 방식을 확인해야 합니다. 최신 배포 환경에서는 인증을 포함한 암호화 방식이 흔히 사용되고, 일부는 Shadowsocks 2022 계열을 사용합니다. 후자는 키 재료와 구현 지원에 별도 조건이 있으므로 일반 비밀번호를 호환되는 키라고 임의로 간주해서는 안 됩니다. 같은 프로토콜 이름 아래 있더라도 암호화 방식은 서로 대체할 수 없으며 서버 설정과 일치해야 합니다.

SS의 리소스 사용량은 비교적 예측하기 쉽지만, CPU 명령어 세트, 암호화 구현, 동시 연결 수, 서버 성능에 따라서도 달라집니다. 데스크톱 CPU와 저전력 라우터는 같은 알고리즘도 처리 성능이 크게 다를 수 있습니다. 플러그인이나 추가 전송 캡슐화를 활성화하면 간결한 기본 연결 구조가 달라집니다. 플러그인 이름과 매개변수, 로컬 지원 여부까지 호환성 확인에 포함해야 하며 기본 SS의 비용만으로 판단해서는 안 됩니다.

VMess: 다양한 인증·전송 조합

VMess는 V2Ray 생태계에서 만들어졌으며 인증, 데이터 보호, 전송 조합에 고유한 설계를 사용합니다. 일반적인 공유 링크에는 서버 주소와 사용자 식별자 외에도 전송 유형, TLS, 경로, 요청 호스트 등의 필드가 포함될 수 있습니다. 클라이언트는 이 필드를 함께 해석해야 합니다. 주소, 포트, 사용자 식별자만 남기면 기존 연결을 그대로 재현하기 어려운 경우가 많습니다. 설정이 복잡한 이유는 특정 옵션 하나가 유난히 까다로워서가 아니라 조합이 다양하기 때문입니다.

VMess 인증은 시스템 시간과 관련이 있어 기기 시간이 크게 어긋나면 인증에 실패할 수 있습니다. 문제를 해결하기 전에 시스템 자동 시간 설정을 켜는 것이 암호화 필드를 바꾸는 것보다 합리적입니다. 오래된 자료에는 과거 인증 방식이나 추가 식별자 매개변수가 나올 수 있지만 현재 배포 환경에 그대로 적용해서는 안 됩니다. 서버에서 제공한 전체 설정과 현재 코어의 지원 범위를 기준으로 삼고, 용도를 모르는 옛 필드를 새 클라이언트에 기계적으로 입력하지 마세요.

같은 VMess라도 기본 TCP와 WebSocket을 이용한 연결은 경로, 핸드셰이크, 중간 서비스 요구사항이 서로 다릅니다. WebSocket을 사용한다면 경로와 요청 헤더가 진입 서버 설정과 일치해야 합니다. TLS를 켰다면 인증서와 서버 이름도 확인해야 합니다. 연결 실패가 VMess 자체의 문제라고 단정할 수는 없습니다. 전송 경로 변경, 진입 지점 설정 불일치, 구독 변환 과정에서 부가 필드가 누락된 경우도 원인일 수 있습니다.

SS와 VMess를 제대로 비교하는 방법

이미 안정적으로 작동하는 SS 노드가 있다면 프로토콜 이름만을 이유로 일상적인 웹 브라우징이나 일반 다운로드 환경을 바꿀 필요는 없습니다. 서비스 제공자가 전체 VMess 설정을 제공한다면 전송 조합을 그대로 유지하고 실제로 테스트하는 것이 좋습니다. 어느 프로토콜이든 이름만으로 UDP 앱 지원을 보장할 수는 없습니다. 클라이언트, 코어, 서버, 트래픽 처리 방식이 모두 지원해야 합니다. 설정에서 UDP를 켠다고 서버의 기능이 새로 생기는 것도 아닙니다.

비교할 때는 회선과 테스트 작업을 고정하고 첫 연결, 재접속, 지속 전송을 각각 확인하세요. 한 노드는 WebSocket과 TLS를 사용하고 다른 노드는 직접 암호화 전송을 사용한다면, 결과는 프로토콜 하나의 우열이 아니라 전체 배포 방식의 차이를 보여줍니다. 읽기 쉬운 로그를 남기고 파싱, 연결, 인증, 앱 응답 중 어느 단계에서 실패했는지 기록하면 모든 문제를 노드 시간 초과로 뭉뚱그리는 것보다 다음 조치를 정하기 쉽습니다.

Trojan과 VLESS의 보안 범위

Trojan: 연결 기반 계층에 TLS 적용

Trojan은 TLS 기반 연결 방식으로, 보호된 채널을 만든 뒤 인증을 거쳐 프록시 요청을 전달합니다. 일반적인 설정은 짧아 보이지만 인증서 체인, 서버 이름, 비밀번호가 모두 필요합니다. 클라이언트의 연결 주소는 도메인이나 IP 주소일 수 있지만, TLS 검증에 사용하는 서버 이름은 서버 인증서 및 진입 설정과 일치해야 합니다. 두 값은 서로 관련이 있어도 항상 같은 필드는 아닙니다.

TLS는 암호화와 서버 인증을 제공하므로 연결 실패 시 인증서 검증을 끄는 것을 일반적인 해결책으로 삼아서는 안 됩니다. 인증서 만료, 잘못된 시스템 시간, 이름 불일치, 시스템의 신뢰 체인 누락은 비슷한 핸드셰이크 오류를 일으킬 수 있습니다. 먼저 로그에서 원인을 확인한 다음 인증서나 이름 설정을 바로잡으세요. 서버가 자체 신뢰 체계를 사용한다면 클라이언트가 지원하는 인증서 신뢰 방식을 사용하고, 검증을 계속 무시하지 마세요.

Trojan의 실제 성능은 TLS 구현, 연결 재사용, 네트워크 환경에 따라 달라집니다. 첫 연결에는 보통 기본 전송 연결과 TLS 핸드셰이크가 필요하고, 이후 요청에서 기존 채널을 재사용할 수 있는지는 구현과 설정에 따라 달라집니다. TLS를 쓴다고 모든 짧은 요청이 느린 것도 아니고, 한 번의 연결 재사용 테스트가 빨랐다고 네트워크 전환 후 처음 연결도 빠르다고 볼 수도 없습니다. 테스트할 때 각 상태를 구분하세요.

VLESS: 프로토콜 계층과 보안 계층 구분

VLESS는 프록시 프로토콜 자체의 처리를 간소화하고 데이터 보호는 선택한 보안 계층이나 전송 방식에 맡깁니다. 보통 사용자 식별자로 인증하지만, 사용자 식별자가 전송 암호화를 의미하지는 않습니다. 유형이 VLESS라고 해서 연결에 완전한 기밀성과 인증이 보장된다고 생각해서는 안 됩니다. TLS, REALITY 또는 기타 지원 조합의 실제 설정과 서버 측 설정이 일치하는지 확인해야 합니다.

지원되는 배포 환경에서 REALITY는 일반적인 인증서 설정과 다른 인증 매개변수를 사용합니다. 공개 키, 짧은 ID, 서버 이름 등의 필드에는 정해진 의미가 있으므로 임의로 바꿔도 되는 메모처럼 취급해서는 안 됩니다. 사용 가능 여부는 클라이언트 통합 방식과 코어 구현에도 좌우됩니다. 공유 링크에 관련 정보가 포함돼도 가져온 뒤 설정을 다시 확인해야 하며, 특히 변환 도구가 인식하지 못하는 매개변수를 버리지 않았는지 살펴보세요.

VLESS의 전송 방식과 흐름 제어 옵션도 각각 확인해야 합니다. 다른 생태계의 클라이언트에서 작동하는 노드라고 해서 모든 Clash 계열 클라이언트에서 그대로 실행되는 것은 아닙니다. 프로토콜 유형이 같아도 전송 확장이 다르면 호환되지 않을 수 있습니다. 알 수 없는 흐름 제어 값을 비슷해 보이는 값으로 바꾸지 마세요. 통신 방식 자체가 달라질 수 있습니다. 현재 사용하는 코어에 맞춰 제공된 설정을 받는 편이 안전합니다.

인증·암호화·트래픽 처리 방식은 별개

비밀번호나 사용자 식별자는 인증에 사용하고, TLS 같은 보안 계층은 연결을 보호하며, TUN과 시스템 프록시는 앱 트래픽을 코어로 전달합니다. 세 설정은 서로 다른 계층에 있습니다. TUN을 켠다고 누락된 TLS 매개변수가 보완되는 것은 아니며, 규칙 모드를 바꿔도 인증서 이름 오류가 해결되지는 않습니다. 먼저 시스템 프록시로 기본 연결을 확인한 뒤 트래픽 처리 범위를 단계적으로 넓히면 여러 조건을 한꺼번에 바꾸지 않아도 되어 문제를 찾기 쉽습니다.

일반적으로 Trojan은 TLS 설정이 제대로 된 환경에서 매개변수를 한곳에 관리하고 싶을 때 적합하며, VLESS는 전송 조합을 명확히 지정하고 서버와 코어의 지원 여부를 확인한 환경에 적합합니다. 어느 쪽도 회선 품질과 무관하게 빠른 속도를 보장하지는 않습니다. 클라이언트 사용자는 새로워 보이는 프로토콜 이름보다 완전하고 관리하기 쉬우며 검증을 유지할 수 있는 설정을 우선하는 것이 좋습니다.

Hysteria2와 TUIC의 QUIC 연결

QUIC의 역할과 필요한 조건

QUIC은 UDP 기반의 안정적인 전송을 제공하고 최신 TLS 핸드셰이크를 통합합니다. 하나의 연결에서 여러 스트림을 처리할 수 있어, 한 스트림에서 데이터가 손실돼도 단일 TCP 바이트 스트림처럼 다른 스트림의 전달까지 반드시 막히지는 않습니다. 다중 요청과 일부 패킷 손실 환경에 유리한 설계지만, QUIC도 재전송, 혼잡 제어, 암호화 처리가 필요합니다. 대역폭, 지연 시간, 서버 부하의 한계를 뛰어넘는 지름길은 아닙니다.

QUIC 기반 프록시를 사용하기 전에 현재 네트워크에서 UDP 통신이 안정적으로 허용되는지 확인하세요. 일부 네트워크는 웹 브라우징은 정상적으로 되지만 UDP 세션 유지 시간을 짧게 제한하거나 속도를 낮추거나 패킷을 전부 버릴 수 있습니다. 이 경우 TCP 기반 노드는 되는데 Hysteria2나 TUIC은 시간 초과가 발생해도 모순이 아닙니다. 클라이언트에서 UDP 전달을 켜도 네트워크의 UDP 처리 방식은 바뀌지 않으므로 네트워크를 바꾸거나 적절한 대체 경로를 사용해야 합니다.

Hysteria2: 대역폭 설정이 전송 방식에 미치는 영향

Hysteria2는 QUIC 기반 프록시 전송을 사용하며, 초기 Hysteria와는 프로토콜 세대가 호환되지 않습니다. 노드 유형 이름만 바꿔서는 이전할 수 없습니다. 인증, TLS, 기타 프로토콜 매개변수는 서버와 클라이언트가 일치해야 합니다. 구독에 모호한 Hysteria 표기만 있다면 세대와 대상 형식을 설정 제공자에게 확인하세요. 프로토콜 핸드셰이크 불일치를 서버의 일시적인 부하로 오해하지 않도록 주의해야 합니다.

Hysteria2의 혼잡 제어와 대역폭 협상은 연결 성능에 영향을 줍니다. Brutal 관련 전송 방식을 실제로 사용할 때는 송수신 대역폭 설정이 특히 중요하며, 값이 클수록 좋은 것은 아닙니다. 실제 회선 용량을 크게 웃도는 설정은 패킷 손실과 대기열을 늘리고 다른 앱의 응답을 늦출 수 있습니다. 지속적으로 사용할 수 있는 대역폭을 기준으로 보수적으로 입력하고 단위도 확인하세요. 서버 정책과 클라이언트 구현에 따라 실제 동작이 달라질 수 있습니다.

다른 혼잡 제어 방식을 사용하는 배포 환경이라면 다른 설정의 대역폭 매개변수를 억지로 적용하지 마세요. 먼저 현재 코어가 해당 필드를 어떻게 해석하는지 확인한 뒤 변수 하나만 조정해 반복 테스트하세요. 선택적 난독화 매개변수도 서버와 일치해야 하며 입력한다고 연결이 반드시 개선되는 것은 아닙니다. 일반 사용자는 설명되지 않은 고급 옵션을 계속 시험하기보다 제공자가 확인한 전체 설정을 유지하는 편이 안정적입니다.

TUIC: 다중 스트림 연결과 UDP 전달

TUIC도 QUIC으로 프록시 연결을 전달하며 다중 스트림 통신과 UDP 전달을 위한 기능을 갖추고 있습니다. 프로토콜 세대에 따라 인증 필드와 동작이 달라질 수 있습니다. 현재 흔히 쓰이는 설정에는 사용자 식별자, 비밀번호, TLS, 혼잡 제어 등의 정보가 포함됩니다. 서버에서 지원한다고 명시한 세대에 맞춰 가져오고, 모든 TUIC 공유 링크를 하나의 오래된 코어가 인식한다고 생각하지 마세요.

TUIC의 UDP 전달 방식, 연결 유지, 혼잡 제어 옵션은 작업별 성능에 영향을 줍니다. 다중 요청, 실시간 데이터그램, 장시간 다운로드는 연결에 요구하는 조건이 서로 다릅니다. 다운로드에 효과적인 설정이 음성 통화에도 적합하다는 보장은 없습니다. RTT 0 핸드셰이크 옵션은 재전송 공격 위험과 구현의 기본 정책도 고려해야 하므로 속도 측정 결과를 줄이려고 무작정 켜지 마세요. 클라이언트와 서버가 권장하는 조합을 우선 사용하세요.

TCP 대체 경로 유지

Hysteria2와 TUIC은 지연 시간이 길거나 패킷 손실이 있는 네트워크에서 실제로 비교해 볼 만하지만, 속도뿐 아니라 연결 성공률도 측정해야 합니다. 무선 네트워크 전환, 기기 절전, 통신사 네트워크의 UDP 정책은 장시간 안정성에 영향을 줍니다. 검증된 TCP 기반 노드를 대체 경로로 남겨 두고, 자동 프록시 그룹 테스트가 대상 앱의 요구사항을 반영하는지 확인하세요. 웹 탐지는 성공하지만 실시간 앱이 계속 실패하는 상황을 피할 수 있습니다.

연결 속도와 리소스 사용량 비교 방법

연결 과정을 단계별로 나누기

웹 요청 한 번에도 도메인 조회, 프록시 서버로의 전송 연결, 프로토콜 인증, 원격 대상 연결, 앱 응답이 포함될 수 있습니다. 화면의 지연 시간 테스트는 보통 특정 탐지 주소에 요청을 보낸 시간으로, 순수한 물리적 왕복 시간이나 다운로드 속도가 아닙니다. 클라이언트마다 테스트 주소와 시간 초과 기준, 연결 재사용 여부가 다르므로 표시값을 소프트웨어 간 순위처럼 직접 비교해서는 안 됩니다. 한 번의 측정으로 장기적인 성능을 판단할 수도 없습니다.

새로 연결하는 콜드 커넥션은 전송 및 보안 컨텍스트를 다시 만들어야 하고, 기존 연결을 재사용하는 핫 커넥션은 이미 열린 세션을 활용할 수 있습니다. 짧은 웹 페이지, 잦은 소규모 API 호출, 지속 다운로드는 두 상태에 민감한 정도가 다릅니다. 첫 화면 로딩 속도를 비교하려면 조건을 맞춰 연결을 새로 만들고, 일상적인 브라우징을 비교하려면 연속으로 접속하며 재사용 성능을 확인하세요. 한쪽은 기존 장기 연결을 쓰면서 다른 쪽은 매번 핸드셰이크하게 해서는 안 됩니다.

같은 작업으로 전체 연결 과정 비교

가능하면 같은 지역의 비슷한 서버와 동일한 대상 리소스를 사용하고, 기기와 네트워크를 고정한 뒤 다른 대용량 작업을 중지하세요. 먼저 연결 성공 여부를 기록하고 첫 응답과 지속 전송 성능을 확인합니다. 일반 웹 페이지, 큰 파일, 실제 사용하는 실시간 앱을 나눠 최소 한 번씩 테스트하세요. 매 회차마다 조건 하나만 바꾸고 여러 차례 반복해 변동 폭을 살펴보세요. 보기 좋은 단일 수치를 얻으려고 계속 최선의 결과만 골라낼 필요는 없습니다.

리소스 사용량은 작업량과 함께 살펴봐야 합니다. 같은 시간 동안 더 많은 데이터를 전송했다면 CPU 사용률이 높아도 구현 효율이 떨어진다고 단정할 수 없습니다. 다수의 유휴 연결, 규칙 세트, DNS 캐시, GUI도 메모리를 사용합니다. 코어 자체를 비교하려면 클라이언트 화면 상태와 규칙 설정을 최대한 동일하게 유지하고, 클라이언트 프로세스와 코어 프로세스를 구분하세요. 화면 렌더링 비용을 프록시 프로토콜 탓으로 돌리지 않도록 주의해야 합니다.

연결 재사용·동시성·회선 병목

연결 재사용은 반복되는 핸드셰이크를 줄여 주지만 많을수록 좋은 것은 아닙니다. 여러 앱이 하나의 하위 연결을 공유하면 혼잡, 재전송, 서버 구현에 따라 앱 간 간섭이 생길 수 있습니다. TCP 기반 연결 재사용과 QUIC의 다중 스트림은 같은 방식이 아닙니다. 한 연결로 다운로드할 때는 정상인데 여러 앱을 동시에 사용하면 끊기는 경우, 규칙 모드를 바로 전역으로 바꾸기보다 공유 연결과 동시 연결 제한을 확인하세요.

저전력 기기에서는 암호화 구현과 데이터 복사가 회선 대역폭보다 먼저 병목이 될 수 있고, 고성능 데스크톱에서는 서버 속도 제한이나 대상 사이트 응답이 더 흔한 병목입니다. 장시간 전송 중 CPU 사용률이 계속 높고 기기가 발열과 성능 저하를 겪는다면 더 복잡한 프로토콜로 바꿔도 나아지지 않을 수 있습니다. 불필요한 캡슐화, 로그 출력, 동시 테스트를 먼저 줄이고 기기 성능을 확인하세요. 네트워크 설정으로 하드웨어 병목을 해결하려 하지 않는 편이 좋습니다.

자동 프록시 그룹도 테스트 결과를 바꿀 수 있습니다. url-test는 탐지 결과에 따라 출구를 선택하고, fallback은 순서에 따라 사용 가능한 출구를 고르며, load-balance는 정책에 따라 연결을 분산합니다. 여러 회선의 대역폭을 단순히 합산하는 기능은 아닙니다. 전환 조건을 확인하려면 세 가지 자동 프록시 그룹의 전환 방식을 참고하세요. 프로토콜을 비교할 때는 프록시 그룹 전환에 따른 변수를 없애도록 수동 출구를 고정하는 편이 좋습니다.

모바일 배터리와 네트워크 전환

전력 소모는 전체 연결 과정에서 발생

모바일 프록시의 배터리 소모를 SS, Trojan, QUIC 순으로 고정해 비교할 수는 없습니다. 무선 모듈의 활성 시간, 셀룰러 신호 세기, 백그라운드 깨우기, 암호화 처리, 로그 기록, 앱 트래픽이 함께 영향을 줍니다. 같은 노드를 사용해도 화면 밝기, 위치 정보 작업, 네트워크 음영 상태가 다르면 결과가 크게 달라질 수 있습니다. 먼저 테스트 중 작업이 비슷했는지 확인한 뒤 프로토콜 자체의 추가 비용을 비교하세요.

연결 유지 패킷은 세션 유지에 도움이 되지만 무선 모듈이 저전력 상태에서 자주 깨어나게 할 수도 있습니다. 일부 네트워크에서는 QUIC이나 UDP 세션의 매핑을 유지하기 위해 더 자주 신호를 보내야 하지만, 간격이 너무 짧으면 기기가 자주 깨어납니다. 간격이 너무 길면 연결이 복구된 뒤 다시 연결해야 할 수 있습니다. 검증된 기본값을 우선 사용하고 로그나 반복 가능한 현상으로 세션 만료가 확인될 때만 필요한 부분을 조정하세요.

백그라운드 테스트와 로그는 조정 가능한 변수

자동 프록시 그룹이 많은 노드를 자주 탐지하면 화면에 표시된 앱과 무관한 연결이 생깁니다. 여러 그룹이 각각 테스트하고 클라이언트가 실시간 통계를 표시하면 추가 작업이 겹칠 수 있습니다. 모바일에서는 불필요한 테스트 범위를 줄이고 사용 빈도에 맞는 간격을 설정하는 것이 좋습니다. 배터리를 아끼려고 필수적인 연결 상태 확인까지 완전히 끄지는 마세요. 간격은 장애를 발견하는 데 걸리는 시간도 고려해야 합니다.

디버그 로그는 단기 문제 해결에 적합하며 모든 정보를 장기간 기록하는 용도는 아닙니다. 로그가 많으면 문자열 처리와 저장 장치 쓰기, 화면 갱신이 늘어날 수 있습니다. 연결 화면을 계속 열어 두는 것도 부하를 더할 수 있습니다. 문제 해결이 끝나면 평소 로그 수준으로 되돌리고 필요 없는 실시간 화면을 닫으세요. 그러면 일반적인 사용 환경에 가까운 배터리 사용량을 확인할 수 있고 구독 주소나 대상 도메인 같은 민감 정보가 로컬 로그에 쌓이는 것도 줄일 수 있습니다.

TUN·시스템 프록시·플랫폼 기능

모바일 운영체제는 일반적으로 시스템의 VPN 또는 네트워크 확장 인터페이스를 통해 트래픽을 처리합니다. 데스크톱의 시스템 프록시와 TUN 옵션을 모바일 동작과 동일하다고 볼 수는 없습니다. Android의 앱별 설정, 백그라운드 제한, 배터리 최적화와 iOS의 네트워크 확장 수명 주기 및 시스템 절전이 연결 유지에 영향을 줄 수 있습니다. 클라이언트를 선택할 때는 해당 플랫폼이 실제로 제공하는 기능을 기준으로 삼고 다른 운영체제의 권한 설정 절차를 그대로 따라 하지 마세요.

TUN을 사용하면 더 많은 앱의 트래픽을 처리할 수 있지만, 처리되는 모든 연결이 원격 프록시를 거치는 것은 아닙니다. 최종 경로는 여전히 규칙이 결정합니다. 잘못된 DNS 설정은 반복 조회와 재시도를 유발하고, 지나치게 넓은 규칙은 직접 접속해도 되는 대용량 트래픽을 돌아가게 할 수 있습니다. 배터리를 최적화하기 전에 트래픽 분기가 예상대로 작동하는지 확인하세요. 프로토콜만 바꾸고 수많은 재시도나 잘못된 출구를 그대로 두면 안정적인 개선을 기대하기 어렵습니다.

단일 속도 측정보다 네트워크 전환 후 복구가 중요

Wi-Fi에서 셀룰러 네트워크로 전환하면 IP 주소, 라우팅, 세션 매핑이 모두 달라질 수 있습니다. QUIC은 연결 마이그레이션을 지원하도록 설계됐지만 프록시 구현, 서버 설정, 운영체제의 수명 주기가 매번 기존 연결의 유지를 보장하지는 않습니다. TCP도 다시 연결해야 할 수 있습니다. 따라서 프로토콜에 특정 기능이 있다고 앱 연결이 항상 유지된다고 여기지 말고 네트워크 전환 후 첫 요청, 절전 해제, 약한 신호에서의 복구를 실제로 확인하세요.

실측할 때는 대기, 가벼운 브라우징, 지속 전송 상태를 나눠 기록하세요. 신호 세기와 작업 시간은 매번 비슷하게 유지하고 시스템 배터리 사용량에서 백그라운드 활동도 확인합니다. 대기 중 소모가 크다면 연결 유지, 탐지, 백그라운드 재연결을 우선 살펴보고, 대용량 전송 중에 집중된다면 CPU, 발열, 무선 네트워크 상태를 확인하세요. 두 문제는 해결 방향이 다르므로 따로 테스트해야 원인을 잘못 짚지 않습니다.

구독 형식과 설정 호환성

링크 목록이 전체 설정을 의미하지는 않습니다

일반적인 구독 콘텐츠는 노드 공유 링크 모음과 전체 YAML 설정으로 나뉩니다. 링크 모음은 서버 연결 방법을 주로 설명하고, 전체 설정에는 프록시 그룹, 트래픽 분기 규칙, DNS, 실행 옵션도 포함될 수 있습니다. Base64는 데이터를 표현하는 인코딩 방식이지 별도의 프록시 프로토콜이 아닙니다. 내용이 인코딩됐다는 이유만으로 Clash와 호환된다고 판단할 수도 없습니다. 디코딩한 결과가 다른 클라이언트용 형식일 수 있으므로 내부 구조를 추가로 확인해야 합니다.

브라우저에서 열리는 구독 주소라고 해서 사용 가능한 설정을 반환하는 것은 아닙니다. 로그인 페이지, 만료 안내 또는 다른 형식의 텍스트가 표시될 수 있습니다. 업데이트가 실패하면 네트워크 요청 실패와 콘텐츠 파싱 실패를 구분하세요. 전자는 주소 접속 가능 여부와 인증 상태를 확인하고, 후자는 실제 반환 형식과 코어 오류를 확인해야 합니다. 개인 인증 정보가 포함된 구독 주소를 공개 테스트 사이트에 제출하거나 공개 문제 기록에 그대로 붙여 넣지 마세요.

변환 과정에서 누락될 수 있는 정보

변환 도구는 입력 프로토콜과 추가 전송 매개변수, 대상 코어의 문법을 이해해야 합니다. 도구가 특정 필드를 인식하지 못하면 무시하거나, 파싱은 되지만 연결은 불가능한 노드를 만들 수 있습니다. VLESS의 보안 계층 매개변수, WebSocket 요청 헤더, TUIC 세대 정보, SS의 특정 암호화 방식은 특히 꼼꼼히 확인해야 합니다. 노드 이름이 그대로 남아 있어도 연결 매개변수까지 전부 보존됐다는 뜻은 아닙니다.

규칙과 프록시 그룹 누락도 중요합니다. 노드만 있는 구독으로는 기존 트래픽 분기 설정을 자동으로 복원할 수 없습니다. 변환 중 프록시 그룹 이름을 바꾸면 규칙이 존재하지 않는 대상을 참조할 수도 있습니다. 병합 과정에서 이름이 같은 노드가 덮어써질 가능성도 있습니다. 가져온 뒤에는 노드 수와 유형이 적절한지 확인하고, 프록시 그룹 참조와 규칙 맨 끝의 기본 처리 경로를 차례로 점검하세요. 가져오기 성공 메시지만 확인해서는 안 됩니다.

YAML 문법과 코어의 설정 해석을 각각 확인

YAML은 들여쓰기로 계층을 나타내므로 들여쓰기가 달라지면 필드가 잘못된 객체에 속할 수 있습니다. 문법 검사 통과는 텍스트 구조를 읽을 수 있다는 의미일 뿐, 현재 코어가 해당 필드를 지원한다는 뜻은 아닙니다. 알 수 없는 필드는 무시될 수 있고, 형식이 맞지 않으면 설정 로드가 실패할 수 있습니다. 오류를 해결할 때는 로그에 표시된 필드부터 상위 계층을 확인하고, 명확한 문제 하나를 먼저 고치세요. 출처를 알 수 없는 긴 템플릿으로 설정 전체를 바꾸지 마세요.

다음은 전체 설정이 이미 있는 경우에 사용할 수 있는 규칙 예시입니다. 정책 참조와 매칭 순서를 보여 주기 위한 조각일 뿐, 서버 정보가 포함된 독립 구독은 아닙니다. 첫 번째 규칙은 예시 도메인을 직접 연결하고, 두 번째는 사설 IP 주소를 직접 연결하며, 나머지 트래픽은 기존의 ‘수동 선택’ 프록시 그룹으로 보냅니다. 해당 그룹이 먼저 정의돼 있어야 합니다. 실제 도메인과 출구는 필요에 맞게 변경하세요. 규칙 순서가 바뀌면 결과도 달라질 수 있습니다.

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,수동 선택

타사 클라이언트는 설정을 적용하기 전에 자체 옵션을 병합하거나 설정을 덮어쓰고 규칙을 추가할 수 있습니다. 따라서 디스크에 저장된 구독 파일을 수정해도 변경 사항이 계속 유지되지는 않을 수 있습니다. 다음 업데이트에서 수정 내용이 사라지거나 GUI 설정이 파일보다 우선 적용될 수도 있습니다. 변경 사항을 유지하려면 클라이언트에서 지원하는 재정의, 병합, 독립 규칙 기능을 사용하고 최종 적용 설정을 확인하세요. 캐시 파일을 바로 수정하는 것보다 먼저 백업하고, 업데이트한 다음 결과를 확인하는 방식이 더 안전합니다.

데이터 파일도 설정과 함께 관리

GEOIP, GEOSITE 또는 규칙 세트 참조는 해당 데이터 출처에 의존합니다. 노드 핸드셰이크는 성공했는데 트래픽 분기가 잘못된다면 데이터 로드 및 업데이트 여부도 확인해야 합니다. 데이터 형식은 파일 확장자만 바꿔서 서로 변환할 수 없습니다. 출처 확인에는 GeoIP 및 GeoSite 업데이트 안내를 참고하세요. 구독 구조를 비교하려면 구독 형식 및 변환 가이드를 확인하세요. 코어 또는 데이터를 업데이트한 뒤 같은 대상에 다시 연결해 변경 사항이 예상한 설정에서 비롯됐는지 확인합니다.

사용 환경별 선택과 문제 해결 순서

먼저 조건에 맞지 않는 조합 제외

프로토콜을 선택할 때는 속도보다 필수 조건부터 확인하세요. 클라이언트의 코어가 해당 프로토콜과 전송 조합을 지원하는지, 구독에 모든 매개변수가 포함됐는지, 네트워크가 필요한 전송 방식을 허용하는지, 기기가 장시간 부하를 감당할 수 있는지 살펴봅니다. 네 가지 중 하나라도 충족되지 않으면 속도 측정을 반복해도 해결되지 않습니다. 그다음 실제 작업에서 응답 속도와 안정성, 배터리 사용량을 비교하고, 평소 사용할 출구와 검증된 대체 경로 하나를 남기는 편이 알 수 없는 조합을 많이 관리하는 것보다 쉽습니다.

일반 웹 브라우징과 업무에는 인증 및 보안 매개변수가 완전하고 안정적으로 작동하는 노드를 우선 사용하세요. SS, Trojan, VMess, VLESS 모두 적합할 수 있습니다. 연결 성공률, 대상 응답 속도, 유지 관리 비용을 기준으로 선택하세요. 업무 중 네트워크를 자주 전환한다면 절전 해제와 네트워크 전환 테스트를 추가하세요. 로컬 네트워크 기기에 연결해야 한다면 라우팅, DNS, 직접 연결 규칙도 별도로 확인하고 모든 연결을 원격으로 보내지 마세요.

장시간 다운로드나 대용량 파일 동기화에서는 지속 전송 속도와 패킷 손실 후 복구, 다른 앱에 미치는 영향을 확인하세요. Hysteria2와 TUIC을 비교해 볼 수 있지만 UDP 통신이 안정적이어야 하며 혼잡 제어 설정도 적절해야 합니다. 실시간 음성이나 양방향 앱은 지터, 짧은 패킷 손실, 연결 복구가 더 중요합니다. 다운로드 속도가 빠른 노드가 더 적합하다고 단정할 수 없으므로 실제 앱으로 양방향 통신을 테스트하세요.

라우터와 저전력 호스트는 프로세서 아키텍처, 메모리, 냉각 성능을 특히 고려해야 합니다. 일반 데스크톱 사용자는 GUI 클라이언트를 우선 사용하고 서버 관리자는 Mihomo 코어를 독립적으로 실행하는 방식을 고려할 수 있습니다. 설치 전에 코어 다운로드 섹션에서 대상 플랫폼과 프로세서를 확인하세요. 운영체제 이름만 보고 선택해서는 안 됩니다. 기존 설정이 작동한다면 새 환경에서 먼저 검증하고 정상 작동을 확인한 뒤 주요 트래픽을 전환하세요. 롤백 파일과 원래 설정을 보관해야 합니다.

실패 단계에 따라 원인 좁히기

첫째, 설정이 로드됐는지 확인합니다. 알 수 없는 노드 유형은 코어 기능이나 변환 형식 문제일 수 있고, 들여쓰기 오류는 텍스트 구조 문제일 가능성이 큽니다. 둘째, 서버에 연결할 수 있는지 확인합니다. 시간 초과는 주소, 포트, 라우팅, 전송 방식의 접속 불가가 원인일 수 있고, 연결 거부는 포트가 열려 있지 않거나 서비스가 시작되지 않은 경우에 더 가깝습니다. 셋째, 인증과 TLS를 점검해 비밀번호 오류, 시스템 시간, 인증서 문제를 구분하세요. 이 단계에서 DNS와 규칙을 동시에 바꾸지 마세요.

넷째, 대상 연결과 규칙을 확인합니다. 일부 앱만 실패한다면 앱 트래픽이 시스템 프록시나 TUN으로 들어가는지 확인한 뒤 적용된 규칙과 실제 출구를 살펴보세요. 도메인 연결은 실패하지만 주소로 연결하면 성공하는 경우에는 DNS를 중점적으로 점검하되, HTTPS를 올바르게 검증하는 대신 IP 주소에 직접 접속해서는 안 됩니다. 모든 노드가 시간 초과라면 노드 시간 초과 문제 해결 순서에 따라 공통 원인을 확인해 동일한 로컬 문제를 각 서버의 문제로 반복해서 오해하지 않도록 하세요.

연결이 복구되면 스위치가 켜져 있는지만 보지 말고 출구 정보와 연결 화면을 함께 확인하세요. 첫 연결 확인 절차를 참고해 앱, 규칙, 출구, 실패 시간을 기록할 수 있습니다. 문제 해결 기록을 준비할 때는 비밀번호, 사용자 식별자, 구독 인증 정보, 개인 주소를 삭제하고 프로토콜 유형, 코어 이름, 네트워크 환경, 비식별화한 오류만 남기세요.

프로토콜 선택 관련 자주 묻는 질문

선택을 마쳤다면 안정적으로 작동하는 조합과 적합한 네트워크 환경을 기록하고, 이후 업데이트에서는 중요한 조건 하나만 바꾸세요. 코어를 교체하거나 구독을 변환하거나 DNS를 조정한 뒤에는 기본 연결을 다시 확인합니다. 명확한 문제가 없다면 모든 고급 매개변수를 계속 시험할 필요는 없습니다. 이 페이지는 선택 기준을 설명합니다. 설치와 가져오기는 사용 가이드를 참고하고, 용어는 용어집에서 주제별로 확인하세요.