SS·VMess·Trojan·VLESS·Hysteria2·TUIC: 연결 방식, 구독 호환성, 실제 사용 시 고려 사항.
프로토콜 이름만으로는 연결의 일부만 알 수 있습니다. 설정을 클라이언트가 읽을 수 있는지, 서버가 어떻게 구성됐는지, 접속 네트워크에서 UDP를 허용하는지, 휴대전화가 자주 네트워크를 전환하는지에 따라 실제 성능은 달라집니다. 이 페이지에서는 이러한 조건을 바탕으로 선택 순서를 정리해 설정 전 비교와 가져온 뒤 확인에 활용할 수 있도록 안내합니다.
처음 사용한다면 먼저 빠른 시작 가이드를 읽고 설치, 구독 가져오기, 연결 확인을 마친 뒤 이 페이지에서 프로토콜 세부 사항을 확인하세요. 클라이언트는 다운로드 페이지에서 Clash Plus를 선택할 수 있습니다. FlClash 등 다른 클라이언트의 기능은 실제로 사용하는 코어와 설정 화면을 기준으로 확인하세요.
프록시 연결은 두 구간으로 나눌 수 있습니다. 앱이 요청을 로컬 클라이언트에 전달하고, 클라이언트가 선택한 원격 노드를 통해 요청을 중계합니다. 시스템 프록시와 TUN 가상 네트워크 인터페이스는 첫 번째 구간에 해당하고, SS·VMess·Trojan 같은 노드 프로토콜은 두 번째 구간에 해당합니다. 따라서 TUN을 켜도 SS가 다른 프로토콜로 바뀌지는 않으며, 규칙 모드를 전환해도 노드의 암호화 방식은 달라지지 않습니다. 두 구간이 모두 정상 작동해야 앱 요청이 예상한 경로로 목적지에 도달합니다.
시스템 프록시는 운영체제 설정을 통해 앱에 로컬 HTTP 또는 SOCKS 엔드포인트를 사용하도록 알립니다. 앱이 이 설정을 따르는지는 앱마다 다릅니다. TUN은 가상 네트워크 인터페이스로 IP 패킷을 받아 클라이언트에서 처리합니다. 게임, 명령줄 도구, 브라우저는 트래픽이 클라이언트에 전달되는 방식이 서로 다를 수 있습니다. 브라우저만 되고 다른 앱은 안 된다면 원격 프로토콜이 고장 났다고 단정하기 전에 로컬 트래픽 처리 범위부터 확인하세요.
프로토콜 계층은 인증, 캡슐화, 전달 방식을 담당하고 전송 계층은 해당 데이터를 서버까지 운반합니다. VMess와 VLESS 등은 TCP 직접 연결이나 WebSocket 추가 등 여러 전송 방식을 조합할 수 있습니다. TLS는 신원 확인과 연결 암호화를 담당합니다. 노드 이름에 포함된 약어는 서로 다른 계층을 가리키는 경우가 많으므로, 이름 하나만 같다고 두 설정을 동일하다고 볼 수는 없습니다.
WebSocket과 TLS를 사용하는 노드를 예로 들면, 연결 과정은 도메인 조회, TCP 연결, TLS 핸드셰이크, WebSocket 업그레이드, 프록시 인증 순으로 진행될 수 있습니다. 서버 앞단에 리버스 프록시가 있다면 경로와 요청 헤더도 맞아야 합니다. 경로 항목 하나가 빠져도 연결이 실패할 수 있지만, 이것이 프로토콜 자체의 호환성 문제라는 뜻은 아닙니다. 문제를 해결할 때는 연결 계층을 따라 도메인과 포트부터 확인한 다음 보안 계층, 전송 계층, 인증 정보를 점검하세요.
| 계층 | 주요 항목 | 주요 역할 |
|---|---|---|
| 로컬 트래픽 처리 | 시스템 프록시, TUN | 어떤 앱의 요청을 클라이언트로 전달할지 결정 |
| 아웃바운드 결정 | 규칙, 전역, 직접 연결 | 요청에 적용할 정책이나 출구 노드 결정 |
| 프록시 프로토콜 | SS, Trojan, TUIC 등 | 인증 및 프록시 데이터 캡슐화 |
| 전송 방식 | TCP、WebSocket、QUIC | 핸드셰이크, 혼잡 제어, 네트워크 적응 방식 |
규칙 모드는 설정에 지정된 순서대로 요청을 비교해 일치하는 규칙에 따라 직접 연결, 차단, 특정 노드 또는 정책 그룹을 선택합니다. 전역 모드는 요청을 전역 정책으로 보내지만 실제로 사용할 수 있는 출구는 여전히 선택해야 합니다. 직접 연결 모드는 주로 로컬 네트워크와 비교할 때 사용합니다. 특정 사이트가 전역 모드에서는 열리지만 규칙 모드에서는 열리지 않는다면, 프로토콜부터 바꾸기보다 어떤 규칙과 정책 그룹이 적용됐는지 먼저 확인하세요.
DNS는 규칙 판정과 연결 설정에도 관여할 수 있습니다. 일부 규칙은 도메인으로 직접 매칭하고, 일부는 대상 IP나 지리 데이터베이스가 필요합니다. 클라이언트가 도메인 정보를 유지하는지, Fake-IP를 사용하는지, DNS 요청을 어떤 경로로 보내는지에 따라 매칭 결과가 달라질 수 있습니다. DNS 설정은 프로토콜 기능과 관련은 있지만 프로토콜 성능 순위의 일부는 아닙니다. DNS, 노드, 모드를 한꺼번에 바꾸면 문제 원인을 재현하기 어려워집니다.
실제로 확인할 때는 먼저 클라이언트에서 대상 설정이 선택돼 있는지 확인한 다음 프록시 화면에서 노드 유형과 정책 그룹 선택을 점검하세요. 이어서 연결 화면이나 로그에서 대상, 적용된 규칙, 아웃바운드 이름을 확인합니다. 요청이 실제로 클라이언트에 들어와 예상한 노드를 선택한 경우에만 프로토콜 간 비교가 의미 있습니다. 규칙 우선순위를 확인하려면 사용자 지정 규칙 작성법과 매칭 순서를 참고하세요.
Shadowsocks는 보통 SS라고 줄여 부릅니다. 암호화된 SOCKS 프록시 방식에서 출발해 연결 구조가 비교적 단순합니다. 클라이언트는 비밀번호나 키와 암호화 방식을 사용해 데이터를 처리하고, 서버는 데이터를 역캡슐화한 뒤 목적지에 전달합니다. SS는 완전한 설정 관리 시스템이 아니며 규칙 분기도 담당하지 않습니다. 구독, 정책 그룹, 화면 설정은 프로토콜 위에 클라이언트가 제공하는 기능입니다. 따라서 SS를 지원하는 프로그램이라고 해서 전체 Clash 설정을 바로 읽을 수 있는 것은 아닙니다.
최근 SS 배포에서는 AEAD 암호화 방식이 흔히 사용됩니다. 이전 세대의 스트림 암호화 방식은 보안 특성이 다릅니다. SS 2022에는 키와 세션 처리에 관한 별도 요구 사항이 추가됐으므로, 이름만 다른 선택지로 취급하면 안 됩니다. 서버가 요구하는 암호화 방식을 클라이언트가 지원하고 정확히 사용해야 합니다. 속도를 높이려고 cipher를 임의로 바꾸면 양쪽에서 데이터를 올바르게 복호화할 수 없습니다.
암호화 방식의 리소스 사용량은 기기 하드웨어에 따라 다릅니다. 관련 하드웨어 가속 기능이 있는 데스크톱 프로세서와 저전력 휴대전화에 적합한 알고리즘은 다를 수 있습니다. AES 계열의 효율은 명령어 지원과 구현에 따라 달라지고, 다른 기기에서는 ChaCha20 계열이 더 적합할 수 있습니다. 이미 정해진 구독만 사용하는 경우라면 알고리즘을 따로 선택할 수 없는 경우가 많으므로 서버 설정과 클라이언트 코어의 지원 여부부터 확인하세요.
SS는 UDP를 전달할 수 있지만 서버의 UDP 포워딩 활성화, 로컬 앱의 UDP 트래픽이 클라이언트에 들어오는지, 중간 네트워크가 해당 데이터를 허용하는지가 모두 충족돼야 합니다. 노드에서 UDP 옵션을 켰다는 것은 클라이언트가 해당 기능을 시도한다는 뜻일 뿐, 전체 경로가 연결됐다는 뜻은 아닙니다. 웹은 TCP로 잘 열리는데 실시간 음성 통화가 실패한다면 앱이 트래픽 처리 대상인지, 노드가 UDP를 지원하는지, 출구에서 대상 포트를 제한하는지 확인하세요.
일부 SS 노드는 별도 플러그인에 의존합니다. 플러그인이 전송이나 핸드셰이크 방식을 추가할 수 있으므로 클라이언트, 코어, 플러그인 구현이 모두 호환돼야 합니다. 가져온 설정에서 모르는 플러그인 이름이나 매개변수가 보이더라도 필드를 바로 지우고 연결을 시도하지 마세요. 삭제하면 서버가 기대하는 연결 방식이 바뀔 수 있습니다. 구독 제공자에게 대상 클라이언트의 형식을 확인하거나 해당 배포 방식을 명확히 지원하는 클라이언트를 선택하세요.
VMess는 V2Ray 생태계에서 발전했으며 사용자 ID와 자체 인증 방식을 사용해 프록시 요청을 구성합니다. 최근 배포에서는 보통 AEAD 인증을 사용하지만, 이전 설정에는 과거 인증 관련 필드가 남아 있을 수 있습니다. 사용자 ID와 암호화 옵션은 서버 설정과 일치해야 합니다. 다른 노드의 ID를 복사해 대체해서는 안 되며, 특정 필드가 있다는 이유만으로 서버가 구형 인증 방식을 사용한다고 단정해서도 안 됩니다.
VMess는 시간 조건에 민감해 시스템 시계가 맞지 않으면 인증에 실패할 수 있습니다. 도메인 조회와 포트 연결은 되는 듯한데 인증 오류가 계속되면 먼저 시스템 자동 시간 설정을 켜고 신원 정보와 서버 상태를 확인하세요. 인증서 오류는 다른 계층의 문제이므로 로그를 함께 살펴 구분해야 합니다. 시계 오차로 발생한 인증 실패는 노드 포트를 반복해서 바꿔도 해결되지 않습니다.
VMess는 TCP, WebSocket 등 여러 전송 방식과 TLS를 조합할 수 있습니다. 실제 리소스 사용량은 프로토콜 인증뿐 아니라 사용 중인 전송 방식, 암호화, 중간 전달 계층에도 영향을 받습니다. TCP 직접 연결 VMess 노드와 리버스 프록시를 거치는 WebSocket 노드는 연결 과정이 크게 다를 수 있습니다. 성능을 비교할 때는 이러한 조건을 함께 기록하고 모든 VMess 노드를 같은 성능 등급으로 묶지 마세요.
일반적인 웹 이용과 일상적인 파일 전송은 두 프로토콜 모두 충분히 처리할 수 있습니다. SS는 연결 구조가 비교적 단순하고, VMess는 인증과 전송 조합을 더 꼼꼼히 확인해야 합니다. 가져온 뒤 일부 노드만 작동하지 않는다면 문제가 있는 노드가 특정 암호화 방식, 플러그인 또는 전송 유형에 집중되는지 먼저 살펴보세요. 그다음 코어를 업데이트할지 제공자에게 설정 변경을 요청할지 결정하면 무작정 하나씩 시험하는 것보다 원인을 찾기 쉽습니다.
Trojan은 일반적으로 TLS 연결을 통해 프록시 요청을 전달하고 비밀번호로 사용자를 인증합니다. TLS는 연결 암호화와 서버 신원 확인을 제공하며, 프록시 프로토콜은 목적지와 인증 정보를 전달합니다. 다양한 암호화 방식을 프로토콜 내부에서 선택하는 대신 이미 널리 쓰이는 TLS 방식을 활용하는 설계입니다. 실제로 연결하려면 인증서, 도메인, 전송 매개변수를 확인해야 합니다. 비밀번호만 입력하면 모든 설정이 끝나는 것은 아닙니다.
서버 주소와 TLS에 사용되는 이름은 서로 다를 수 있습니다. 서버 주소는 연결할 엔드포인트를 지정하고, SNI는 TLS 핸드셰이크에서 대상 이름을 알리며, 인증서 검증 이름은 원격 서버의 신원을 확인합니다. 클라이언트에 따라 뒤의 두 항목이 하나의 필드로 합쳐지거나 설정에 따라 자동으로 결정될 수 있습니다. 서버 주소에 IP를 사용하더라도 올바른 서비스 이름을 입력해야 할 수 있습니다. 세 항목의 관계는 서버 구성 정보를 기준으로 확인하세요.
인증서 오류가 발생하면 기기 시간, 인증서 유효 기간, 인증서에 포함된 도메인, 설정의 이름을 확인하세요. 인증서 검증을 건너뛰면 서버 신원 확인이 약해지므로 장기적인 해결책으로 적합하지 않습니다. 이전에는 연결됐는데 구독을 업데이트한 뒤 실패했다면 검증을 완화하기보다 업데이트 전후의 서비스 이름을 비교하세요. 자세한 확인 절차는 프록시 사용 중 HTTPS 인증서 오류 안내를 참고하세요.
VLESS도 V2Ray 관련 생태계에서 시작해 Xray 등의 구현을 통해 발전했습니다. 일반적인 VLESS 구성은 사용자 인증과 외부 보안 계층을 분리하고 프로토콜 자체의 구조를 간결하게 유지합니다. 기존 설정에서 encryption이 none으로 표시된다면 해당 프로토콜 설정 계층에서 데이터 암호화를 사용하지 않는다는 뜻이지, 전체 연결이 반드시 평문이라는 뜻은 아닙니다. 실제 보안 수준은 TLS, REALITY 또는 명시적으로 지원되는 다른 조합을 함께 확인해야 합니다.
REALITY는 일반적인 인증서 기반 TLS와 매개변수 구성이 다릅니다. 클라이언트에서 공개 키, 짧은 ID, 서비스 이름 등을 확인해야 할 수 있습니다. 공개 키는 검증에 사용하는 값이며 숨겨야 하는 서버 개인 키가 아닙니다. 일반 사용자는 신뢰할 수 있는 구독에서 전체 항목을 받아야 하며, 서로 다른 노드의 매개변수를 임의로 조합해서는 안 됩니다. 이름이 비슷한 필드라도 다른 프로토콜이나 코어에서 그대로 사용할 수 있다는 뜻은 아닙니다.
VLESS 설정에는 flow가 지정될 수도 있습니다. 예를 들어 Vision 관련 값이 사용됩니다. flow는 임의로 입력하는 속도 조절 옵션이 아니라 서버, 전송 방식, 코어 구현이 함께 지원해야 하는 기능입니다. 호환되지 않는 전송 방식에 flow를 추가하면 거부되거나 연결이 비정상적으로 작동할 수 있습니다. 설정 가져오기에 성공했다는 것은 일부 파싱 검사를 통과했다는 뜻일 뿐이므로 실제 핸드셰이크와 접속 결과도 확인해야 합니다.
| 항목 | 역할 | 자주 하는 실수 |
|---|---|---|
| 서버 주소 | 연결 엔드포인트 지정 | 엔드포인트 IP를 인증서 도메인으로 취급 |
| SNI / 서비스 이름 | 핸드셰이크와 이름 검증에 사용 | 다른 웹사이트 이름으로 임의 변경 |
| ALPN | 상위 프로토콜 협상 | 값을 많이 입력할수록 호환성이 좋아진다고 생각 |
| flow | 특정 프로토콜 처리 흐름 선택 | 코어와 전송 방식 조합의 제약 무시 |
WebSocket은 일부 기존 웹 서비스 배포 환경에 맞출 수 있지만 업그레이드 요청, 경로, 요청 헤더 등의 설정이 추가됩니다. gRPC 계열 전송 방식은 서비스 이름과 연결 동작이 다릅니다. 이러한 기능은 배포와 전송 문제를 해결하기 위한 것이며 기본적으로 속도를 높이는 옵션은 아닙니다. 서버에서 한 가지 방식만 제공한다면 클라이언트도 그 방식에 맞춰야 합니다. 프로토콜은 엔드포인트가 실제로 지원하는 기능과 함께 고려해야 합니다.
Trojan과 VLESS 모두 일상적인 사용에 적합한 연결을 제공할 수 있지만, 모든 상황에 통하는 성능 순위는 없습니다. 기존 인증서 체계를 유지하는 서버라면 Trojan의 매개변수 관계를 이해하기가 비교적 쉽습니다. 특정 VLESS 조합이 필요한 서버라면 코어와 구독 필드가 완전한지 먼저 확인하세요. 클라이언트에서 노드를 선택할 때는 보안 매개변수가 유효한지 확인한 다음 회선 품질, 안정성, 리소스 사용량을 비교하는 편이 특정 프로토콜 이름을 좇는 것보다 신뢰할 수 있습니다.
QUIC은 UDP를 기반으로 보안 핸드셰이크, 신뢰성 있는 스트림, 다중화, 혼잡 제어 등의 기능을 전송 계층에 통합하며 TLS 1.3을 통해 보안 연결을 설정합니다. Hysteria2와 TUIC은 모두 QUIC 기능을 활용하지만 서로 다른 프록시 프로토콜이므로 인증 방식과 매개변수는 호환되지 않습니다. 노드가 QUIC 기반이라는 사실은 연결 기반이 비슷하다는 뜻일 뿐, 한 설정의 유형 필드를 다른 프로토콜로 바꿔도 된다는 의미는 아닙니다.
다중화를 사용하면 여러 논리 스트림이 하나의 연결을 공유할 수 있습니다. 여러 스트림이 단일 TCP 연결을 공유하는 방식과 비교하면 QUIC은 한 스트림에 데이터가 없어도 전송 계층에서 다른 독립 스트림의 전달이 막히는 현상을 줄일 수 있습니다. 하지만 모든 스트림은 네트워크 대역폭과 혼잡의 영향을 함께 받으며, 패킷 손실이 심하면 모두 영향을 받을 수 있습니다. 다중화가 모든 요청에 끊김 없는 전용 회선을 제공하는 것은 아닙니다.
UDP를 사용하려면 접속 중인 네트워크가 노드 포트까지 UDP 패킷을 전달해야 합니다. 일부 공용 네트워크, 기업 네트워크, 모바일 환경에서는 UDP를 제한하거나 UDP 매핑을 짧은 시간만 유지할 수 있습니다. 이런 환경에서 TCP 노드로는 웹을 이용할 수 있지만 QUIC 노드 핸드셰이크가 시간 초과되는 것은 문제를 파악하는 단서가 됩니다. 같은 구독을 반복해서 가져오기보다 먼저 UDP 연결 가능 여부를 확인한 다음 프로토콜 매개변수를 조정하세요.
Hysteria2는 지연 시간이 길거나 패킷 손실이 있는 환경을 포함한 여러 네트워크 조건을 대상으로 QUIC 기반 프록시 전송을 지원합니다. 배포 설정에는 대역폭 힌트, 혼잡 제어 선택, 추가 난독화 매개변수가 포함될 수 있습니다. 대역폭 값은 가입한 요금제의 속도나 서버 네트워크 카드의 표기 속도가 아니라 현재 회선에서 실제로 사용할 수 있는 대역폭을 기준으로 이해해야 합니다. 지나치게 큰 값을 입력하면 대기열, 패킷 손실, 공유 네트워크 내 경쟁이 심해질 수 있습니다.
클라이언트와 서버의 대역폭 협상 방식, 클라이언트가 값을 지정할 수 있는지, 값을 생략하면 어떻게 처리되는지는 구현과 서버 정책에 따라 다릅니다. 일반 구독 사용자는 제공자가 생성한 값을 그대로 유지하는 편이 좋습니다. 직접 조정해야 한다면 한 번에 한 방향의 값만 바꾸고, 지속 전송 중 지연 시간과 다른 앱의 반응을 기록하세요. 다운로드 순간 최고 속도만 보면 네트워크 전체에 혼잡이 발생한 사실을 놓칠 수 있습니다.
Hysteria 1세대와 Hysteria2는 유형 이름만 바꾼다고 서로 호환되지 않습니다. 두 프로토콜과 설정은 서로 다릅니다. 변환 도구가 대상 유형을 제대로 지원하지 않으면 인증 정보나 다른 필수 매개변수가 누락될 수 있습니다. 지원하지 않는 노드 유형이 표시된다면 구형 유형으로 파싱 검사를 우회하지 말고 해당 프로토콜을 명확히 지원하는 코어로 업데이트하거나 대상 형식의 설정을 다시 받으세요.
TUIC은 QUIC으로 프록시 트래픽을 전달하며 TCP와 UDP 포워딩을 처리할 수 있습니다. 구현에 따라 혼잡 제어, UDP 전달 방식, 연결 유지 옵션이 제공됩니다. 프록시의 TCP 트래픽은 전송 계층도 TCP로 바뀐다는 뜻이 아닙니다. 클라이언트는 TCP 트래픽을 QUIC 연결의 신뢰성 있는 스트림으로 전달할 수 있습니다. UDP 트래픽은 선택한 전달 방식에 따라 신뢰성과 패킷 손실 동작을 살펴봐야 합니다.
TUIC의 프로토콜 버전과 인증 필드도 서로 맞아야 합니다. 설정에 사용자 ID와 비밀번호가 있다고 해서 비슷한 필드를 사용하는 다른 노드로 바로 옮길 수 있는 것은 아닙니다. 코어에서 지원하는 프로토콜 버전, 데이터그램 방식, 필드 이름에 따라 호환성이 달라질 수 있습니다. 가져온 뒤 인증에 실패한다면 사용자 이름이 있는지만 확인하지 말고 노드 제공자에게 대상 코어와의 호환 여부를 문의하세요.
QUIC에는 연결 마이그레이션 관련 기능이 있지만 클라이언트와 프로토콜 구현, 네트워크 전환 방식이 이를 실제로 활용하는지는 직접 확인해야 합니다. Wi-Fi와 모바일 데이터 사이를 전환하면 앱이 다시 연결해야 할 수 있고, 백그라운드 절전으로 연결이 끊길 수도 있습니다. Hysteria2나 TUIC은 테스트를 거친 선택 경로로 활용할 수 있지만 패킷 손실, 네트워크 전환, 약한 신호를 한 번에 해결하는 방법은 아닙니다. 선택하기 전에 장시간 사용 후 배터리 소모와 발열도 비교하세요.
클라이언트에 표시되는 지연 시간은 대개 특정 방식으로 한 번 탐지한 값이며 프록시 연결을 설정하고 테스트 주소에 요청하는 과정이 포함될 수 있습니다. 프로토콜 자체의 지연 시간이 아니며 서버의 ICMP 왕복 시간과 같다고 볼 수도 없습니다. 클라이언트나 테스트 주소가 다르면 결과를 직접 비교하기 어렵습니다. 노드 탐지 결과가 빠르더라도 특정 웹사이트에 접속할 때는 목적지까지의 거리, 출구 혼잡, DNS의 영향을 받을 수 있습니다.
짧은 연결에서는 DNS 조회와 핸드셰이크 비용이 더 크게 드러납니다. 웹페이지를 처음 열면서 여러 연결을 설정하면 TLS, WebSocket 업그레이드, 인증 등의 과정이 대기 시간에 영향을 줍니다. 이미 연결된 상태에서는 기존 경로를 재사용해 연결 설정 비용을 일부 줄일 수 있습니다. 새 프로토콜을 테스트할 때는 최초 접속과 연속 접속을 구분하세요. 캐시와 연결 재사용 때문에 나중에 테스트한 노드가 더 빠른 것처럼 보일 수 있습니다.
지속 처리량에는 출구 대역폭, 혼잡 제어, 패킷 손실, 암호화 효율, 서버 부하 등 다른 조건이 영향을 줍니다. 작은 파일을 빠르게 내려받았다고 해서 장시간 전송도 안정적이라는 뜻은 아닙니다. 반대로 대용량 파일 전송 속도가 높아도 응답 지연이 낮다는 보장은 없습니다. 업로드가 회선을 가득 채우면 대기열이 길어져 웹과 음성 통화가 모두 느려질 수 있습니다. 하나의 속도 수치가 아니라 실제 작업 부하를 기준으로 선택하세요.
암호화와 복호화, 데이터 복사, 연결 수, 규칙 매칭, DNS 캐시, 로그 출력은 모두 리소스를 사용합니다. QUIC은 사용자 공간에서 전송 기능을 많이 처리하는 경우가 있고 TCP의 일부 작업은 시스템 네트워크 스택에서 처리됩니다. 그러나 실제 비용은 구현 품질, 시스템 최적화, 트래픽 규모에 따라 달라집니다. 사용자 공간인지 커널 공간인지 만으로 모든 기기의 CPU 성능 순위를 정할 수는 없습니다.
모바일 기기에서는 무선 통신 모듈이 활성 상태로 유지되는 시간도 중요합니다. 지속적인 연결 확인, 잦은 탐지, 다수의 짧은 연결, 실패 후 재시도는 기기를 깨우는 횟수를 늘릴 수 있습니다. 신호가 약하면 재전송과 무선 통신 전력으로 차이가 더 커집니다. 따라서 같은 설정이라도 집의 Wi-Fi와 출퇴근 중 모바일 데이터에서 배터리 소모가 크게 다를 수 있으며, 데스크톱 테스트 결과를 그대로 휴대전화에 적용할 수 없습니다.
TUN을 켜면 트래픽 처리 범위가 넓어져 더 많은 백그라운드 요청이 클라이언트를 통과합니다. 사용 후 배터리 소모가 늘었다면 TUN의 처리 비용뿐 아니라 기존에는 처리 대상이 아니던 앱에서 프록시 트래픽이 발생하기 시작한 것이 원인일 수 있습니다. 비교할 때는 백그라운드 앱, 트래픽 처리 모드, DNS 설정을 동일하게 유지하세요. 그렇지 않으면 노드 프로토콜은 그대로인데 테스트 대상 트래픽이 달라집니다.
| 작업 | 확인 항목 | 동일하게 유지할 조건 |
|---|---|---|
| 웹페이지 최초 접속 | 핸드셰이크, 첫 응답, 실패율 | 대상 주소, 캐시 상태, DNS |
| 지속적인 파일 전송 | 안정적인 처리량, 상호작용 응답 | 파일 출처, 시간대, 병렬 작업 |
| 음성 통화 또는 회의 | 끊김, 지터, UDP 사용 가능 여부 | 앱, 트래픽 처리 방식, 접속 네트워크 |
| 휴대전화 백그라운드 대기 | 배터리 소모, 깨우기, 재연결 기록 | 신호, 화면, 백그라운드 앱 |
먼저 네트워크와 클라이언트 설정을 고정하고 대용량 백그라운드 동기화를 중지한 다음 각 노드에서 같은 작업을 실행하세요. A 노드를 모두 테스트한 뒤 한참 후 B 노드를 테스트하기보다 번갈아 측정하면 시간대별 부하 차이를 줄일 수 있습니다. 각 테스트에서는 새 연결과 일정 시간 유지되는 연결을 모두 확인하고 오류 유형도 기록하세요. 두 노드의 출구가 다르다면 결과는 해당 경로의 차이만 보여줄 뿐, 두 프로토콜 전체의 일반적인 차이를 나타내지는 않습니다.
배터리 테스트는 실제 일상 사용 시간을 충분히 반영하고 시스템 배터리 통계에서 백그라운드 활동도 확인해야 합니다. 디버그 로그는 문제를 찾을 때만 잠시 사용하고 정상 작동을 확인한 뒤에는 일반 로그 수준으로 되돌리세요. 필요 이상으로 자주 실행되는 연결 상태 확인도 조정할 수 있습니다. 배터리를 아끼려고 연결 유지 간격을 임의로 지나치게 늘리지는 마세요. 일부 네트워크에서 매핑이 더 빨리 만료돼 재연결이 오히려 잦아질 수 있습니다.
최종적으로는 실패율이 낮고 일상 작업에 안정적으로 응답하며 기기 온도가 적정한 조합을 우선하세요. 특정 프로토콜의 최고 속도가 더 높아도 발열이나 네트워크 전환 실패가 계속된다면 휴대전화에 적합하지 않을 수 있습니다. 매개변수를 바꾸기 전에 기존 설정을 보관하고 한 번에 하나만 수정하세요. 노드가 계속 시간 초과되는 경우 노드 시간 초과 및 연결 실패 해결 순서를 참고하세요.
그래픽 클라이언트는 설정 화면, 시스템 연동, 구독 관리, 트레이, 사용자 인터페이스를 담당하고 코어는 설정 해석, 프록시 연결, DNS, 규칙 실행을 담당합니다. FlClash는 mihomo 코어를 기반으로 클라이언트 기능을 제공합니다. 하지만 화면에 특정 코어 기능을 위한 스위치가 있는지는 클라이언트 구현에 따라 달라집니다. 다운로드 페이지의 클라이언트들은 외관이나 이름만으로 기능이 같다고 판단할 수 없습니다.
같은 클라이언트도 업데이트에 따라 코어나 설정 처리 방식이 바뀔 수 있습니다. 호환성을 확인하려면 먼저 정보, 설정, 로그 화면에서 실제 코어 이름과 빌드 정보를 확인하고 해당 기능을 지원하는지 살펴보세요. Clash 클라이언트를 사용한다는 정보만으로는 VLESS, Hysteria2, 특정 DNS 필드를 지원하는지 알 수 없습니다. 구체적인 클라이언트와 코어, 설정 출처를 구분해야 합니다.
기존 Clash는 일반적인 YAML 설정 구조와 규칙 기반 트래픽 분기 방식을 확립했습니다. Clash.Meta는 그 생태계의 확장 포크였고 이후 mihomo라는 코어 이름으로 개발을 이어갔습니다. 예전 문서, 구독 옵션, 클라이언트 안내에서는 여전히 Meta라는 이름을 볼 수 있습니다. 이 이름은 과거 포크를 가리키기도 하고 호환 대상 라벨로 사용되기도 합니다. 라벨만 보고 어떤 기능이 포함됐는지 판단할 수는 없습니다.
mihomo는 여러 프로토콜, DNS, 규칙, 네트워크 트래픽 처리 기능을 추가하고 확장했습니다. 기본 설정 구조는 Clash 방식과 비슷한 부분이 많지만 확장 필드가 원본이나 다른 포크에서 읽힌다는 보장은 없습니다. 원본 프로젝트는 유지 관리가 중단됐으며 구형 클라이언트에 내장된 파서는 구독에 Clash 호환이라고 적혀 있어도 이후 추가된 노드 유형을 자동으로 이해하지 못합니다. 새 기능에는 해당 기능을 지원하는 코어가 필요합니다.
| 대상 | 일반적인 역할 | 사용 시 한계 |
|---|---|---|
| 기존 Clash | 기본 설정과 규칙 생태계 | 후속 확장 프로토콜은 기본적으로 호환되지 않음 |
| Clash.Meta | 확장 포크의 과거 명칭 | 구체적인 구현과 빌드에 따라 확인 필요 |
| mihomo | 지속적으로 개발되는 프록시 코어 | 필드 지원 여부는 빌드, 플랫폼, 구현에 따라 달라짐 |
| 그래픽 클라이언트 | 시스템 연동과 설정 관리 | 화면에 표시된 기능이 코어의 모든 기능을 뜻하지는 않음 |
호환성은 최소 네 가지 계층으로 나뉩니다. 파일 문법을 파싱할 수 있는지, 노드 유형을 인식하는지, 확장 옵션이 적용되는지, 운영체제가 관련 네트워크 작업을 허용하는지 확인해야 합니다. 설정이 문법 검사를 통과해도 서버 매개변수가 맞지 않아 연결에 실패할 수 있고, 노드는 정상이어도 TUN 권한이 부족할 수 있습니다. 이런 문제를 모두 설정 호환성 문제라고 부르면 실제로 조정해야 할 부분을 놓치게 됩니다.
클라이언트는 구독을 불러올 때 로컬 설정을 병합하거나 DNS를 덮어쓰고 규칙을 추가할 수 있습니다. 따라서 디스크에 저장된 원본 구독과 코어가 실행하는 최종 설정은 다를 수 있습니다. 문제를 해결할 때는 다운로드한 YAML만 확인하지 말고 클라이언트에서 제공하는 실행 설정이나 로그를 먼저 살펴보세요. 병합 충돌이 발생하면 최소한의 로컬 설정만 남겨 비교해 여러 항목의 덮어쓰기가 서로 영향을 주지 않도록 하세요.
운영체제별 차이도 있습니다. 데스크톱 운영체제의 프록시 스위치, 가상 네트워크 인터페이스, 권한 모델은 모바일의 네트워크 확장이나 VPN 서비스 인터페이스와 다릅니다. 설정을 여러 플랫폼에서 가져올 수 있다고 해서 시스템 설정까지 그대로 적용할 수 있는 것은 아닙니다. iOS 사용자는 다운로드 페이지에서 Clash Plus를 확인할 수 있지만, 실제 클라이언트가 지원하는 가져오기 형식과 네트워크 기능에 맞춰야 합니다. 데스크톱 mihomo의 모든 옵션이 모바일에 필요한 것은 아닙니다.
알 수 없는 노드 유형, 지원되지 않는 필드, 알려진 기능 문제가 있다면 클라이언트와 코어 업데이트가 도움이 될 수 있습니다. 업데이트 전에 설정, 오버라이드, 필요한 옵션을 저장하세요. 업데이트 뒤에는 정상 작동이 확인된 노드 하나를 먼저 검증한 다음 복잡한 규칙을 복원합니다. 클라이언트에서 코어를 별도로 전환하는 기능을 제공한다면 안내된 방식만 사용하세요. 다른 플랫폼의 실행 파일을 임의로 교체하면 안 됩니다.
새로 설치한다면 Clash Plus를 선택해 대상 프로토콜을 지원하는지 확인할 수 있습니다. FlClash, Clash Verge Rev 등이 필요하다면 플랫폼과 기능에 맞춰 선택하세요. Clash for Windows와 ClashX Meta는 유지 관리가 중단된 보관용 선택지이므로 구형 환경을 이해하는 데는 도움이 되지만 계속 확장되는 프로토콜을 기본 지원한다고 기대하기는 어렵습니다. 클라이언트 선택은 이름이 얼마나 오래 사용됐는지가 아니라 현재 필요한 프로토콜과 시스템 연동 기능을 기준으로 해야 합니다.
구독은 클라이언트가 설정 내용을 가져오는 경로입니다. 서버는 경로 매개변수, 요청 헤더, 클라이언트 식별 정보에 따라 서로 다른 형식을 반환할 수 있으므로 브라우저에서 내려받은 내용과 클라이언트가 받은 내용이 다를 수 있습니다. 흔히 사용되는 형식으로 단일 프로토콜 공유 링크, 인코딩된 노드 링크 목록, Clash 방식의 YAML, 다른 코어의 JSON 설정 등이 있습니다. 파일 확장자만 바꿔 서로 변환할 수는 없습니다.
단일 공유 링크에는 보통 노드 하나의 주소, 포트, 인증 정보, 일부 전송 매개변수가 들어 있습니다. 노드 목록에는 여러 연결이 포함되지만 규칙 분기 설정은 없을 수 있습니다. 전체 Clash 설정에는 proxies, proxy-groups, rules, dns 섹션 등이 포함될 수 있습니다. 클라이언트에 여러 가져오기 메뉴가 있다면 내용 형식에 맞는 항목을 선택하세요. 전체 설정만 받는 원격 설정 입력란에 노드 공유 링크를 붙여 넣으면 파싱 오류가 날 수 있습니다.
proxy-providers를 사용해 원격 노드 목록을 참조하고 노드 업데이트와 규칙 관리를 분리하는 설정도 있습니다. 이때 기본 설정 파일은 짧을 수 있지만 참조한 콘텐츠에 접근할 수 있어야 하고 형식도 맞아야 합니다. 기본 설정을 가져왔는데 정책 그룹에 노드가 없다면 기본 파일을 다시 내려받기보다 provider 업데이트 상태, 참조 이름, 필터 조건을 확인하세요.
구독 변환 도구는 원본 형식의 필드를 대상 코어의 필드에 맞게 매핑해야 합니다. 주소와 인증 정보는 유지하기 쉽지만 전송 경로, TLS 이름, ALPN, flow, REALITY 매개변수, UDP 옵션은 형식이나 도구 지원 부족으로 누락될 수 있습니다. 변환 뒤 노드 목록이 그대로 보이더라도 연결 방식까지 동일하다는 뜻은 아닙니다. 대상 프로토콜과 코어를 명확히 지원하는 출력 형식을 선택하세요.
변환 도구가 해당 프로토콜을 지원하지 않는 코어에 구현 기능을 추가할 수는 없으며 누락된 정보에서 올바른 매개변수를 신뢰성 있게 추론할 수도 없습니다. 원본에 필수 항목이 없다면 제공자에게 완전한 설정을 요청하세요. 온라인 변환 서비스를 사용하면 구독 주소를 제3자에게 전달하게 되어 인증 정보가 노출될 수 있습니다. 제공자가 직접 생성한 대상 형식을 우선 사용하고, 필요하다면 위험을 이해한 뒤 신뢰할 수 있는 로컬 변환 방식을 이용하세요.
YAML은 들여쓰기와 구조에 민감합니다. 목록 항목, 맵, 문자열의 계층을 일관되게 유지해야 하며 특수 문자가 포함된 값은 올바르게 따옴표로 묶어야 합니다. 브라우저가 로그인 페이지, 오류 페이지, 빈 응답을 반환했다면 설정 파일이 아니므로 들여쓰기를 고쳐도 해결되지 않습니다. 파일 첫 부분에서 파서 오류가 발생하면 다운로드한 내용의 유형과 첫 몇 줄부터 확인한 다음 서버에서 요청을 거부했는지 주소가 만료됐는지 판단하세요.
아래는 규칙 일부이며 전체 구독 설정이 아닙니다. 예시 도메인은 직접 연결하고 나머지 요청은 PROXY라는 기존 정책 그룹으로 보냅니다. 사용 전에 현재 설정에 해당 그룹이 있는지 확인해야 합니다. 규칙은 위에서 아래 순서로 적용되며 마지막 MATCH가 앞에서 일치하지 않은 요청을 처리합니다. 따라서 MATCH 뒤에 일반 규칙을 추가해도 예상대로 작동하지 않는 경우가 많습니다.
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXYGeoIP와 GeoSite 규칙은 해당 규칙 데이터에도 의존합니다. 설정 문법이 올바르더라도 데이터 파일이 없거나 업데이트에 실패하면 관련 규칙이 예상대로 작동하지 않을 수 있습니다. 노드 구독 업데이트와 규칙 데이터베이스 업데이트는 서로 다른 작업이므로 구분해야 합니다. 데이터 파일의 용도와 업데이트 방법은 GeoIP·GeoSite 데이터베이스 사용 안내를 참고하세요.
자동 업데이트는 원격 설정 파일에 직접 추가한 내용을 덮어쓸 수 있습니다. 규칙을 계속 유지해야 한다면 클라이언트가 제공하는 로컬 오버라이드나 병합 기능을 사용하고 삽입 순서도 확인하세요. 업데이트 동작을 직접 관리할 수 있는 경우에만 파일을 수동으로 수정하는 편이 좋습니다. 업데이트 뒤 문제가 다시 발생한다면 마지막 업데이트 시각만 확인하지 말고 원본 구독, 오버라이드 결과, 최종 실행 설정을 비교하세요.
설정 방법은 구독 가져오기 가이드에서, 구독 주소와 보안 관련 주의 사항은 구독 출처 안내에서 확인하세요. 자동 새로고침만 실패하고 수동 가져오기는 정상이라면 구독 업데이트 실패와 새로고침 간격 설정을 살펴보고 응답 내용, 접근 경로, 형식 호환성을 하나씩 확인하세요.
가정이나 사무실의 고정 네트워크에서 웹, 문서, 코드 저장소를 주로 이용한다면 이미 안정적으로 작동하며 인증서와 매개변수가 완전한 노드부터 선택하세요. SS, VMess, Trojan, VLESS는 모두 적합할 수 있고, 체감 성능에는 프로토콜 이름보다 출구 품질이 더 큰 영향을 주는 경우가 많습니다. 네트워크가 UDP를 제한한다면 TCP 계열 후보를 먼저 남겨두세요. QUIC을 시험하려고 DNS, 규칙, 시스템 트래픽 처리 방식을 한꺼번에 바꿀 필요는 없습니다.
장거리 전송이나 패킷 손실이 있는 환경에서는 Hysteria2와 TUIC도 비교할 수 있지만 먼저 UDP 연결 가능 여부를 확인해야 합니다. 지속적인 다운로드를 한다면 업로드, 웹 이용, 회의가 동시에 영향을 받는지도 확인하세요. 회선을 가득 채운 상태의 결과만으로 전체 사용 경험을 판단해서는 안 됩니다. 음성이나 게임 같은 실시간 작업에서는 웹 탐지 결과만 보지 말고 앱의 UDP 트래픽이 실제로 대상 노드를 거치는지 확인하세요.
모바일에서는 재연결 안정성, 발열, 백그라운드 활동, 네트워크 전환 후 복구를 우선 고려하세요. 주 노드 하나와 전송 방식이 다른 예비 노드 하나를 남겨두면 접속 환경이 바뀔 때 끊김을 줄일 수 있습니다. 자동 정책 그룹에는 적절한 탐지 대상과 간격이 필요합니다. 탐지 성공은 해당 대상에 연결할 수 있다는 뜻일 뿐 모든 앱이 작동한다는 보장은 아닙니다. 출구를 자주 바꾸면 이미 설정된 세션이 다시 연결될 수도 있습니다.
| 사용 환경 | 먼저 확인 | 그다음 비교 |
|---|---|---|
| 일상적인 웹 이용과 업무 | 규칙, DNS, 출구 안정성 | 최초 접속과 연속 접속 성능 |
| 실시간 음성 통화와 회의 | UDP 트래픽 처리와 전달 기능 | 지터, 끊김, 네트워크 전환 복구 |
| 지속적인 파일 전송 | 사용 가능한 대역폭과 회선 혼잡 | 장시간 처리량과 상호작용 지연 |
| 모바일 데이터와 대기 상태 | 신호, 재연결, 백그라운드 활동 | 발열, 배터리, 대체 경로 |
1단계: 설정이 정상적으로 로드됐는지 확인합니다. 클라이언트의 설정 화면에서 대상 설정을 선택하고 파싱이나 병합 오류가 없는지 살펴보세요. 그런 다음 프록시 화면에 후보 노드와 정책 그룹이 있는지 확인합니다. 노드가 표시되지 않는다면 네트워크 테스트보다 구독 내용, 필터 규칙, 코어 지원 여부부터 살펴보세요. 새로 설치하는 경우 다운로드 페이지에서 Clash Plus 또는 현재 시스템에 적합한 클라이언트를 선택하고 가이드에 따라 기본 설정을 가져오세요.
2단계: 요청이 클라이언트에 들어오는지 확인합니다. 연결을 시작하고 필요에 따라 시스템 프록시나 TUN을 사용한 뒤 대상에 접속하면서 연결 화면을 확인하세요. 기록이 없다면 앱이 시스템 프록시를 따르는지, 가상 네트워크 인터페이스 권한이 있는지, 다른 네트워크 프로그램과 트래픽 처리 방식이 충돌하는지 확인합니다. 기록이 있다면 적용된 규칙, 정책 그룹, 최종 노드를 확인해 실제로 직접 연결을 테스트하거나 그룹 안의 다른 노드를 사용하고 있지는 않은지 살펴보세요.
3단계: 로그를 따라 원격 연결 실패 원인을 확인합니다. 이름 조회에 실패하면 DNS를 살펴보세요. 핸드셰이크 시간 초과라면 엔드포인트 주소와 포트, 전송 연결 가능 여부를 확인합니다. 인증서 오류는 시간과 이름을, 인증 실패는 신원 매개변수를 점검하세요. 특정 프로토콜의 노드가 모두 실패한다면 코어 지원 여부와 네트워크 조건을 확인합니다. 로그 문구는 구현에 따라 달라지므로 오류 단어 하나만으로 원인을 단정하지 말고 발생 단계와 다른 노드의 비교 결과를 함께 살펴보세요.
4단계: 기능이 정상 작동하면 일상적인 트래픽에서 확인합니다. 같은 앱으로 웹 이용, 파일 전송, 회의 테스트를 진행한 뒤 장시간 사용과 네트워크 전환 결과를 평가하세요. 새 설정이 안정적인지 확인할 때까지 기존 설정을 보관하세요. 되돌릴 때는 노드 이름만 복원하지 말고 전체 설정 조합을 복원해야 합니다. 매개변수를 여러 개 변경했다면 일부씩 되돌리고 다시 확인해 우연히 문제가 해결된 것을 특정 설정 하나의 효과로 오해하지 않도록 하세요.
기록에 민감한 정보는 넣지 않아도 됩니다. 접속 네트워크, 클라이언트와 코어, 프로토콜 및 전송 조합, 로컬 트래픽 처리 방식, 테스트 작업, 오류 발생 단계만 적으면 됩니다. 다른 사람에게 도움을 요청할 때는 관련 로그에서 민감한 항목을 가리고 전체 구독 주소는 공유하지 마세요. 이렇게 하면 비슷한 문제를 판단하고 클라이언트 업데이트 뒤 다시 테스트하기도 쉽습니다. 무작정 노드를 바꾸는 데서 다시 시작할 필요가 없습니다.
프로토콜은 연결 방식을 정하고, 코어는 구현 가능한 기능을 결정하며, 구독은 매개변수를 제공하고, 클라이언트는 이러한 기능을 시스템에 연결합니다. 이 순서대로 살펴보면 형식 오류, 회선 문제, 기기 제한을 나누어 처리할 수 있습니다. 프로토콜 선택을 마친 뒤에는 빠른 시작 가이드에서 연결과 확인 절차를 점검하세요. 안내에 없는 화면이나 설치 문제가 발생하면 문제 해결을 참고해 모든 이상을 프로토콜 탓으로 돌리지 않도록 하세요.