Clash 프로토콜·커널 가이드

1. 프로토콜·전송 방식·트래픽 처리 방식 구분하기

클라이언트의 노드는 단순한 프로토콜 이름이 아니라 여러 연결 매개변수의 조합입니다. 프로토콜은 인증, 요청 캡슐화, 데이터 교환 방식을 정하고, 전송 방식은 이 데이터를 어떤 경로로 전달할지 결정합니다. TLS 같은 보안 계층은 해당 경로를 보호하며, VPN이나 TUN은 휴대폰 트래픽이 클라이언트로 들어오는 방식을 정합니다. 각 계층을 구분해야 이름이 모두 VLESS인 설정도 호환성이나 연결 결과가 서로 다른 이유를 이해할 수 있습니다.

노드 이름만으로 전체 기능을 알 수 없습니다

노드에는 보통 서버 주소, 포트, 인증 정보, 암호화 방식과 전송 설정이 포함됩니다. 조합에 따라 서버 이름, 경로 또는 특정 핸드셰이크 매개변수가 필요할 수도 있습니다. 화면에 표시되는 이름은 구성을 제공한 쪽에서 정하며 자유롭게 바꿀 수 있으므로 실제 유형을 판단하는 근거로 삼기 어렵습니다. 노드 상세 정보나 내보낸 설정 필드를 확인하고, 특히 type, network와 보안 계층 옵션을 살펴보세요. 이름에 '고속'이나 프로토콜 약어가 있다고 해서 성능을 단정할 수는 없습니다.

전송 방식과 프록시 프로토콜을 아무 조합으로나 사용할 수 있는 것은 아닙니다. 특정 커널이 VLESS를 지원하더라도 모든 VLESS 전송 확장 기능까지 지원한다는 뜻은 아닙니다. 클라이언트가 공유 링크를 가져올 수 있어도 링크에 담긴 모든 매개변수를 온전히 처리한다는 보장은 없습니다. 클라이언트 화면에서 커널 기능 일부만 제공할 수도 있습니다. 호환성을 확인하려면 서버 설정, 커널 문서, 클라이언트 가져오기 결과를 모두 살펴봐야 합니다. 어느 한 단계라도 빠지면 잘못 판단할 수 있습니다.

VPN 아이콘만으로 원격 프로토콜을 알 수 없습니다

휴대폰 상태 표시줄에 VPN 아이콘이 나타나는 것은 보통 클라이언트가 시스템에서 제공하는 가상 네트워크 인터페이스를 사용하고 있음을 뜻합니다. 이는 로컬에서 트래픽을 처리하는 방식이지, 모든 원격 연결이 같은 기존 VPN 프로토콜을 사용한다는 뜻은 아닙니다. 인터페이스로 들어온 트래픽은 규칙에 따라 SS, Trojan 등의 프록시 아웃바운드로 전달되거나 목적지에 직접 연결될 수 있습니다. 데스크톱의 시스템 프록시는 해당 설정을 따르는 프로그램만 처리하므로 트래픽을 포괄하는 범위가 다릅니다.

마찬가지로 TUN을 켠다고 프로토콜 호환성 문제가 저절로 해결되지는 않습니다. 노드 매개변수가 잘못된 상태에서 더 많은 트래픽을 처리하면 영향을 받는 앱만 늘어날 수 있습니다. 먼저 클라이언트가 서버에 연결할 수 있는지 확인한 다음 앱 트래픽이 규칙 체인에 들어오는지 살펴보세요. 로그에 대상 앱의 연결 기록이 없다면 트래픽 처리 범위를 점검해야 합니다. 연결 기록은 있지만 핸드셰이크에 실패한다면 프로토콜 매개변수, 인증서, 네트워크 연결 상태를 확인하세요.

연결 흐름을 따라 문제 찾기

하나의 접속 과정을 도메인 조회, 로컬 트래픽 처리, 규칙 매칭, 정책 그룹 경로 선택, 원격 핸드셰이크, 목적지 요청으로 나눠 살펴볼 수 있습니다. 실제 구현에서는 여러 단계가 동시에 처리될 수 있지만, 이 순서는 문제를 확인할 때 유용합니다. 예를 들어 사이트가 열리지 않지만 직접 연결은 정상이라면 곧바로 프로토콜 문제라고 단정할 수 없습니다. 규칙이 다른 아웃바운드를 선택했거나 DNS가 연결할 수 없는 주소를 반환했을 수도 있습니다. 한 번에 설정 하나만 바꾸고 접속 대상과 시간을 기록해야 로그와 증상을 비교하기 쉽습니다.

2. SS와 VMess: 암호화 캡슐화와 호환성 범위

Shadowsocks는 보통 SS로 줄여 부르며, 간결한 프록시 전달과 암호화 캡슐화를 중심으로 설계되었습니다. VMess는 V2Ray 생태계에서 시작된 프로토콜로, 프로토콜 계층에서 인증과 데이터 보호를 담당하며 여러 전송 방식과 함께 사용되기도 합니다. 두 프로토콜 모두 구현과 설정 방식이 변화해 왔으므로 'SS 지원' 또는 'VMess 지원'은 확인을 시작하는 기준일 뿐입니다. 실제 연결 여부는 사용하는 암호화 방식과 인증 설정, 전송 계층이 서로 일치하는지에 달려 있습니다.

SS가 간단하다고 해서 매개변수를 생략해도 되는 것은 아닙니다

SS의 주요 매개변수는 보통 서버 주소, 포트, 비밀번호, 암호화 방식으로 구성됩니다. 최신 설정은 인증 기능이 있는 암호화 방식을 사용하는 경우가 많지만, 방식마다 키 처리와 캡슐화 방법이 다르므로 이름이 비슷하다고 서로 바꿔 쓸 수는 없습니다. 구독에 최신 프로토콜 확장이나 특정 플러그인이 포함되어 있으면 오래된 커널이 설정을 거부하거나 기본 노드만 인식하고 연결에는 실패할 수 있습니다. 서버에서 제공한 전체 조합을 그대로 입력하고 임의로 필드를 바꾸지 마세요.

암호화 방식의 연산 비용은 기기 하드웨어에 따라 다릅니다. 해당 명령어 가속을 지원하는 칩은 특정 알고리즘을 효율적으로 처리할 수 있고, 다른 알고리즘은 다른 프로세서에 더 적합할 수 있습니다. 휴대폰 발열은 무선 신호, 전송량, 백그라운드 앱, 화면 밝기의 영향도 받습니다. '알고리즘 이름이 짧다'는 이유만으로 배터리를 덜 쓴다고 판단하지 마세요. 성능을 시험하겠다며 암호화 방식을 임의로 바꾸는 것도 피해야 합니다. 클라이언트와 서버의 설정이 일치해야 하므로 한쪽만 바꾸면 대개 연결되지 않습니다.

SS의 UDP 전달도 별도로 확인해야 합니다. 클라이언트에서 UDP를 허용해도 서버, 라우팅, 통신 사업자 네트워크가 해당 데이터를 통과시킨다는 보장은 없습니다. 대부분 TCP를 사용하는 웹에서는 UDP 지원 부족이 드러나지 않을 수 있지만 게임, 음성 통화, 일부 DNS 조회에서는 문제가 나타납니다. 웹은 정상인데 실시간 앱에 문제가 있다면 노드의 UDP 지원과 규칙 경로를 확인하세요. 전역 DNS를 바로 바꾸거나 같은 구독을 반복해서 다시 가져오지 마세요.

VMess는 인증과 전송 조합을 확인하세요

VMess 설정은 보통 UUID로 사용자를 식별하며 보안 옵션과 전송 매개변수가 포함될 수 있습니다. 인증 과정에 시간이 영향을 미치므로 기기 시간이 크게 어긋나면 연결에 실패할 수 있습니다. 이런 경우 먼저 시스템에서 날짜와 시간을 자동으로 설정하고 시간대와 시계가 정상인지 확인한 다음 서버의 인증 설정을 살펴보세요. DNS를 반복해서 바꿔도 인증 불일치 문제는 해결되지 않습니다. 여러 옵션을 한꺼번에 바꾸기보다 연결 계층을 나눠 확인하는 편이 효과적인 이유입니다.

VMess over TCP와 VMess over WebSocket은 연결 경로가 다릅니다. 후자는 리버스 프록시를 거칠 수 있어 경로, 요청 헤더, TLS 설정이 올바르게 구성되어야 합니다. 서버 주소는 하위 연결을 설정하는 데 사용하고, TLS 서버 이름은 해당 핸드셰이크에서 쓰며, WebSocket의 Host는 애플리케이션 계층 요청에 사용합니다. 값이 같은 경우도 있고 다를 수도 있습니다. 구독에 있는 도메인 형태의 모든 필드를 한 값으로 바꾸거나 다른 노드의 범용 설정처럼 보이는 매개변수를 복사하지 마세요.

오래된 설정을 옮길 때는 차이를 그대로 유지하세요

과거 VMess 설정에는 오래된 인증 방식이나 더 이상 사용하지 않는 필드가 들어 있을 수 있습니다. 새 커널에서 구문 검사를 통과하더라도 서버가 해당 조합을 여전히 받아들인다는 뜻은 아닙니다. 먼저 설정 제공자에게 현재 커널에 맞는 항목을 요청한 뒤 가져오기 전후의 주요 필드를 비교하세요. 변환 도구가 매개변수를 알리지 않고 무시하면 화면에는 노드 이름이 표시되어도 실제 연결은 뒤 단계에서 실패할 수 있습니다. '가져오기 성공'을 완전한 호환으로 간주하지 마세요.

오래된 구독을 유지해야 한다면 일상적으로 사용하는 설정을 덮어쓰지 말고 별도 설정에서 먼저 테스트하세요. 일부 노드만 실패하면 해당 노드의 암호화 방식과 전송 유형을 비교하세요. 모든 노드가 실패하면 인증 정보의 출처, 기기 시간, 전체 설정 형식을 확인하세요. 이렇게 하면 노드 자체 문제와 클라이언트의 설정 로드 문제를 구분할 수 있어 재설치로 불필요한 작업을 반복하지 않아도 됩니다.

3. Trojan과 VLESS: 보안 계층과 전송 방식 조합

Trojan은 보통 TLS 연결 안에서 프록시 요청을 처리해 검증된 TLS 체계로 전송을 보호하고 비밀번호로 인증합니다. VLESS는 프로토콜 계층을 가볍게 설계하는 데 중점을 두며 데이터 보호는 대개 외부 보안 계층에 맡깁니다. 두 프로토콜이 같은 구독에 들어 있는 경우가 많지만 보안 역할은 서로 다릅니다. 프로토콜 이름뿐 아니라 TLS, REALITY 등의 조합 요구 사항도 확인하세요. 프로토콜 이름만으로 모든 보안 기능이 포함된다고 볼 수는 없습니다.

Trojan은 TLS 연결을 올바르게 설정하는 것이 핵심입니다

Trojan 노드는 서버, 포트, 비밀번호 외에도 TLS 서버 이름과 인증서 검증을 올바르게 설정해야 합니다. 연결 주소는 도메인이나 IP를 사용할 수 있지만, 서버 인증에 쓰는 이름은 서버 인증서와 설정에 맞아야 합니다. 인증서가 만료되었거나 인증서 체인이 불완전하거나 이름이 일치하지 않으면 인증 전에 연결이 종료될 수 있습니다. 이때는 핸드셰이크 관련 로그를 확인하고 시간, 이름, 인증서 배포 상태부터 점검하세요. 프록시 모드를 반복해서 바꾸는 것은 해결책이 아닙니다.

인증서 검증을 끄면 서버 신원 확인이 약해지므로 장기적인 해결 방법으로 적합하지 않습니다. 구독에서 검증을 건너뛰도록 요구한다면 그 배포 방식과 신뢰 범위를 확인하세요. 직접 운영하는 서버라면 인증서 체인과 이름 설정을 바로잡아야 합니다. 휴대폰이 로그인 포털이 있는 Wi-Fi를 사용할 때는 먼저 네트워크 로그인을 마치세요. 포털이 초기 요청을 가로채 원격 TLS 오류처럼 보일 수 있습니다. 정상 작동이 확인된 다른 네트워크와 비교하면 로컬 접속 문제인지 서버 문제인지 구분하는 데 도움이 됩니다.

Trojan은 TCP와 TLS 조합으로 많이 사용되지만 다른 전송 방식을 제공하는 구현도 있습니다. WebSocket이나 gRPC 계층을 추가하는 것은 보통 리버스 프록시 구성과 관련이 있으며, 클라이언트에서 켠다고 성능이 개선되는 기능은 아닙니다. 오히려 일치시켜야 하는 매개변수와 중간 단계가 늘어납니다. 일반 TCP 방식으로 요구 사항을 충족한다면 계층을 더 추가할 필요가 없습니다. 서버에서 특정 경로를 요구한다면 해당 설정을 정확히 유지해야 합니다.

VLESS의 경량 설계에는 전제가 있습니다

VLESS 프로토콜 계층 자체는 범용 데이터 암호화를 담당하지 않습니다. 따라서 설정을 가져온 뒤 UUID만 보고 연결이 보호된다고 여기지 말고 외부 보안 계층을 확인해야 합니다. 일반적으로 TLS나 해당 구현이 지원하는 REALITY 조합을 사용합니다. 조합에 따라 필요한 필드가 다르며 클라이언트가 VLESS를 지원한다고 해서 모든 관련 흐름 제어와 핸드셰이크 방식을 지원하는 것은 아닙니다. 실제 커널의 기능 문서를 기준으로 확인하고, 특히 모바일 화면에서 해당 필드를 유지할 수 있는지 살펴보세요.

설정의 flow는 양쪽이 모두 지원해야 하는 프로토콜 관련 매개변수이지, 범용 속도 설정이 아닙니다. 다른 노드의 흐름 제어 값을 현재 노드에 입력하면 호환성이 깨질 수 있습니다. REALITY의 공개 키, 짧은 ID, 서버 이름도 해당 서버에서 제공한 값이어야 하며 임의로 조합하면 안 됩니다. 매개변수가 빠져 있다면 원본 정보를 보완하거나 제공자가 안내한 호환 구독을 사용하세요. 무작위 조합을 시도하는 것은 바람직하지 않습니다.

변경할 만한지 판단하는 방법

현재 Trojan 노드가 안정적으로 작동한다면 VLESS로 바꿔도 웹페이지가 더 빨리 열리는 것은 아닙니다. 반대로 프로토콜 헤더가 가볍더라도 서버 혼잡을 상쇄할 수는 없습니다. 지속적인 전송량을 비교하기 전에 연결을 쉽게 설정할 수 있는지, 장시간 연결이 안정적인지, 네트워크를 바꾼 뒤 재시작해야 하는지부터 살펴보세요. 출퇴근이나 화면을 자주 잠그는 상황에서는 짧은 순간의 다운로드 최고 속도보다 복구 속도와 백그라운드 안정성이 더 중요할 때가 많습니다.

문제를 연결 주소에 도달할 수 없는 경우, TLS 또는 보안 계층 핸드셰이크 실패, 사용자 인증 실패, 목적지 전달 실패로 나눠 살펴보세요. 로그 문구는 커널마다 다를 수 있으므로 특정 오류 문구만 찾기보다 어느 단계에서 실패했는지 확인해야 합니다. 한 번에 노드 하나만 테스트하고 정책 그룹을 일시적으로 고정해 자동 선택 중 다른 설정으로 바뀌지 않게 하세요. 그래야 변경한 설정과 테스트 대상이 일치합니다.

4. Hysteria2와 TUIC: QUIC 기반 방식의 장단점

Hysteria2와 TUIC는 모두 QUIC 관련 기술을 기반으로 프록시 환경에서 신뢰성 있는 스트림과 데이터그램을 처리합니다. QUIC는 일반적으로 UDP를 사용하며 사용자 공간에서 연결, 암호화, 혼잡 제어를 처리합니다. 이는 '앱의 UDP 트래픽을 그대로 전달하는 것'과는 다른 개념입니다. 목적지 사이트가 TCP를 사용하더라도 프록시 구간은 QUIC로 전송될 수 있으므로 휴대폰과 서버 사이의 UDP 경로가 작동하는지 먼저 확인해야 합니다.

QUIC로 달라지는 점

기존 TCP 바이트 스트림은 순서에 맞춰 데이터를 전달하므로 패킷 하나가 손실되면 같은 연결의 후속 데이터가 재전송을 기다릴 수 있습니다. QUIC는 서로 다른 스트림 간의 상호 대기를 줄일 수 있지만, 하나의 신뢰성 있는 스트림 안에서는 여전히 순서를 보장해야 하며 대역폭과 혼잡의 영향도 받습니다. 패킷 손실을 없애거나 물리적 회선의 용량을 넘어설 수 있는 기술은 아닙니다. 네트워크 상태가 좋을 때는 사용자 공간 처리 때문에 성숙한 TCP 구현보다 리소스를 더 쓸 수도 있으므로 실제 사용 경험을 기준으로 판단하세요.

QUIC에는 연결 마이그레이션 관련 기능이 있지만 휴대폰이 Wi-Fi에서 모바일 네트워크로 전환할 때 연결이 원활하게 복구되는지는 프로토콜 구현, 클라이언트 수명 주기, 네트워크 주소 변경, 서버 정책에 따라 달라집니다. 기반 기술의 기능이 모든 클라이언트에서 보장되는 것은 아닙니다. 네트워크 전환을 시험할 때는 상태 표시줄의 VPN 아이콘이 계속 표시되는지만 보지 말고 기존 세션이 복구되는지, 이후 새 요청을 설정할 수 있는지 확인하세요.

Hysteria2의 대역폭 매개변수는 신중하게 설정하세요

Hysteria2는 손실이 있거나 변동이 큰 네트워크 경로를 고려한 전송 방식을 제공합니다. 대역폭 추정에 기반한 전송 전략을 사용할 때 입력한 업로드·다운로드 값은 실제 전송 동작에 반영되며, 측정 결과를 표시하는 값이 아닙니다. 실제 사용 가능한 대역폭보다 훨씬 높게 설정하면 대기열과 패킷 손실이 늘고 다른 앱에도 영향을 줄 수 있습니다. 클라이언트와 서버가 값을 협상하는 방식을 이해한 뒤 보수적인 값부터 검증하세요. 다른 혼잡 제어 방식을 사용하는 경우에도 같은 기준을 그대로 적용하지 마세요.

서버가 전송 동작을 제한할 수 있고 구독에 이미 적절한 매개변수가 포함되어 있을 수도 있습니다. 모바일 요금제에 표시된 속도는 현재 무선 환경과 원격 경로에서 지속적으로 사용할 수 있는 처리량과 다릅니다. 동영상을 재생할 때 더 자주 끊기고 시스템 네트워크 대기열이 늘거나 다른 앱도 눈에 띄게 느려진다면 대역폭 값을 더 높이는 것이 해결책은 아닙니다. 목표 값을 낮추고 테스트 부하를 줄인 뒤 무선 신호와 서버 리소스가 병목인지 확인하세요.

TUIC의 다중화와 데이터그램 선택

TUIC는 QUIC의 스트림과 데이터그램 기능으로 프록시 요청을 전달합니다. 인증 정보와 혼잡 제어 설정은 양쪽에서 일치해야 합니다. 구현에 따라 UDP 전달 방식, 연결 유지, 0-RTT 관련 옵션을 제공할 수 있습니다. 0-RTT는 이미 형성된 신뢰 상태와 구현 정책에 의존하며 재전송 공격에 대한 보안 고려 사항도 있습니다. 첫 연결마다 핸드셰이크를 생략할 수 있는 것은 아닙니다. '더 빠르게' 연결하려고 화면에 보이는 옵션을 무작정 모두 켜지 마세요.

신뢰성 있는 전송과 신뢰성 없는 데이터그램은 각기 쓰임이 다릅니다. 실시간 음성이나 게임에서는 이미 늦은 데이터를 재전송해도 도움이 되지 않을 수 있습니다. 반면 완전한 전달이 필요한 요청은 해당 계층에서 신뢰성을 보장해야 합니다. 구독의 UDP 모드는 서버 기능과 대상 앱의 요구 사항에 맞아야 합니다. 실시간 앱에만 문제가 있다면 데이터그램 경로와 MTU 등을 먼저 비교하세요. 브라우저가 정상이라는 이유만으로 QUIC 연결 전체에 문제가 없다고 단정하면 안 됩니다.

프로토콜을 업그레이드하면 인증 방식과 설정 구조도 달라질 수 있습니다. 표시 이름만 바꿔 Hysteria와 Hysteria2를 서로 바꿔 쓸 수 없으며, TUIC도 프로토콜 버전에 맞는 지원이 필요합니다. 가져오기 전에 제공자가 어떤 구현과 형식을 말하는지 확인하세요. 화면에서 핵심 옵션을 찾을 수 없다면 이름이 비슷한 노드를 반복해서 바꾸기보다 실제 설정과 커널 오류를 확인하는 편이 효과적입니다.

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

'프로토콜 속도'에는 최소한 최초 연결 시간, 요청 응답 시간, 지속적인 전송량, 장애 복구 속도라는 네 가지 측면이 있습니다. 웹페이지가 늦게 열리는 원인은 DNS나 핸드셰이크일 수 있고, 파일 다운로드가 느린 원인은 혼잡이나 서버 속도 제한일 수 있습니다. 게임 끊김은 지터나 패킷 손실 때문일 수도 있습니다. 이런 현상을 지연 시간 하나로 압축하면 실제 병목이 가려집니다. 휴대폰 테스트는 기기 온도, 배터리 모드, 무선 규격 변화에도 영향을 받으므로 짧게 한 번 측정한 결과만으로 장기간 사용할 설정을 결정하기는 어렵습니다.

지연 시간 측정만으로 실제 접속을 판단할 수 없습니다

클라이언트의 지연 시간 테스트는 보통 지정된 주소로 요청을 보냅니다. DNS 조회, 핸드셰이크, 기존 연결 재사용이 포함되는지는 구현과 연결 상태에 따라 달라집니다. 단순한 네트워크 왕복 시간 측정이 아닐 수 있고 모든 목적지 사이트의 성능을 나타내지도 않습니다. 두 노드가 서로 다른 테스트 주소를 사용한다면 결과를 직접 비교하기는 더 어렵습니다. 측정 방식을 이해한 뒤 노드 지연 시간 및 접속 확인 절차를 참고해 평소 사용하는 사이트로 추가 점검하세요.

비교할 때는 가능한 한 같은 장소와 네트워크, 비슷한 시간대에 테스트하고 정책 그룹 선택을 고정하세요. 먼저 소수의 웹 요청으로 첫 응답을 살펴보고, 이어서 합법적이고 안정적인 다운로드 출처로 지속 전송을 확인하세요. 마지막으로 화면 잠금과 네트워크 전환을 시험하세요. 여러 속도 테스트를 동시에 실행하면 서로 대역폭을 나눠 쓰고 대기열 상태도 달라집니다. 단일 최고 속도보다 간헐적으로 멈추는지, 재연결 후 복구되는지, 백그라운드에서 연결이 끊기는지 기록하는 편이 유용합니다.

CPU·메모리·배터리는 서로 다른 지표입니다

암복호화, 데이터 복사, 사용자 공간 네트워크 스택, 규칙 매칭은 모두 연산 자원을 사용합니다. 메모리 사용량은 활성 연결 수, 규칙 모음, DNS 캐시, 로그 버퍼에도 영향을 받습니다. 특정 프로토콜의 기본 캡슐화가 작다고 해서 전체 설정의 메모리 사용량까지 낮은 것은 아닙니다. 연결을 많이 유지하거나 방대한 규칙을 불러오는 것이 프로토콜 헤더 차이보다 더 큰 영향을 줄 수 있습니다. 프로토콜에 고정된 리소스 순위를 매기기보다 같은 작업에서 전체 설정을 비교하세요.

휴대폰 배터리 소모는 프로세서와 무선 모듈 모두에 좌우됩니다. 앱의 CPU 사용률이 높지 않아도 연결 유지, 상태 확인, 구독 새로고침이 너무 잦으면 무선 연결이 계속 활성 상태로 유지될 수 있습니다. 신호가 약한 곳에서 패킷을 반복해서 재전송하면 배터리가 더 소모됩니다. 대기 중 배터리가 빨리 줄어든다면 시스템 배터리 통계와 백그라운드 활동을 확인해 클라이언트, 사용 중인 앱, 무선 신호의 영향을 구분하세요. 노드 유형만 보고 원인을 단정하지 말고 확인 간격을 조정하세요.

백그라운드 안정성과 확인 빈도의 균형

자동 선택 정책 그룹에는 보통 상태 확인이 필요합니다. 확인을 자주 할수록 변화를 빠르게 감지할 수 있지만 추가 요청과 연결 유지 비용도 늘어납니다. 여러 그룹이 같은 노드 목록을 반복해서 확인하면 부담이 더 커집니다. 자동 전환을 자주 해야 하는지 먼저 살펴본 다음 간격을 늘리거나 확인 대상을 줄이세요. 연결이 안정적인 휴대폰이라면 보수적으로 설정하는 편이 배터리 사용량을 예측하기 쉽습니다.

Android에서는 필요한 경우 사용 중인 클라이언트의 백그라운드 제한을 조정할 수 있지만 모든 앱의 배터리 관리를 끌 필요는 없습니다. iOS의 네트워크 확장은 시스템 수명 주기와 리소스 제약을 받으므로 데스크톱의 상시 실행 프로세스에 대한 경험을 그대로 적용할 수 없습니다. 기기가 뜨겁거나 시스템 메모리가 부족하다면 클라이언트를 바꾸기 전에 동시 테스트, 상세 로그, 불필요한 규칙부터 줄이세요. 성능 최적화의 목표는 고급 옵션을 전부 켜는 것이 아니라 일상적인 사용에서 안정성을 확보하는 것입니다.

6. Clash·Meta·mihomo 커널의 관계

Clash는 초기 프록시 커널을 가리키기도 하고, 그 설정 방식과 호환되는 클라이언트 생태계를 통칭하기도 합니다. Meta는 관련 기반에서 발전한 포크의 이름이며, mihomo는 이 계열이 이후 사용한 커널 이름입니다. 서로 계승 관계가 있지만 모든 기능이 상위·하위 버전에서 완벽하게 호환되는 것은 아닙니다. 클라이언트에서 어떤 설정을 실행할 수 있는지 확인하려면 실제 커널과 지원 기능을 살펴보세요. 앱 이름에 Clash가 들어 있는지만으로 판단하면 안 됩니다.

커널은 실행을 담당하고 클라이언트는 UI와 시스템 연동을 담당합니다

커널은 보통 노드 연결, 규칙 처리, DNS, 정책 그룹 등을 담당하고 그래픽 클라이언트는 구독 관리, 권한 요청, 설정 화면, 백그라운드 서비스, 시스템 트래픽 처리를 맡습니다. 프로젝트에 따라 역할의 경계가 달라질 수 있지만 이 구분은 문제를 찾는 데 도움이 됩니다. 같은 커널을 사용하더라도 클라이언트가 다르면 설정 가져오기, 덮어쓰기 순서, 시스템 라우팅 방식이 달라질 수 있습니다. 화면에 옵션이 있다고 해서 모든 플랫폼에서 세부 동작까지 같다는 뜻은 아닙니다.

원본 Clash의 기본 설정 구조는 많은 구독 형식에 영향을 주었지만 공개 오픈 소스 구현과 과거의 다른 배포 형태, 이후 포크를 같은 것으로 보면 안 됩니다. mihomo는 프로토콜과 규칙 등에서 기능을 확장했으며 이에 따라 전용 필드도 추가했습니다. 새 프로토콜이나 확장 구문이 포함된 설정은 오래되었거나 기능이 다른 커널에서 거부될 수 있습니다. YAML 형식을 사용한다고 해서 의미나 기능까지 호환되는 것은 아닙니다.

클라이언트 선택 시 실제 기능을 확인하세요

이 사이트에서는 설치 경로로 Clash Plus를 먼저 안내합니다. 사용 중인 기기 플랫폼에서 이용할 수 있는 설치 방법을 확인할 때 적합합니다. 특정 프로토콜, 규칙 확장, 시스템 트래픽 처리 기능이 필요하다면 해당 플랫폼의 안내를 별도로 확인하세요. 한 플랫폼의 기능이 다른 플랫폼에서도 제공된다고 가정할 수는 없습니다. 데스크톱에서는 Clash Verge Rev, FlClash, Clash Nyanpasu를 비교할 수 있으며 Android에서는 Clash Meta for Android, FlClash, Surfboard를 살펴볼 수 있습니다. 지원하는 설정과 프로토콜 범위는 각각 확인해야 합니다.

Surfboard는 자체 설정 형식을 사용합니다. 프록시를 관리할 수 있다는 이유만으로 완전한 Clash YAML을 같은 형식으로 입력할 수는 없습니다. Clash for Windows와 ClashX Meta는 지원이 종료된 보관용 선택지이므로 과거 설정을 확인하거나 오래된 기기를 이전할 때 참고할 수는 있지만, 현재 프로토콜 지원 여부를 판단하는 기준으로 삼아서는 안 됩니다. iOS 설치 방법과 기능은 해당 앱의 안내를 확인하세요. Android 커널 파일을 iOS 클라이언트에 직접 설치할 수는 없습니다.

구체적인 선택은 클라이언트 선택 가이드를 참고하세요. 설치 파일과 플랫폼별 링크는 다운로드 페이지에서 확인할 수 있습니다. 클라이언트에서 커널 정보를 볼 수 있다면 실제 커널 이름과 빌드 정보를 기록하고, 문제를 확인할 때 설정에 사용된 프로토콜 유형과 함께 비교하세요. 앱 이름만 있고 커널 정보가 없다면 특정 고급 필드를 사용할 수 없는 이유를 판단하기 어려울 수 있습니다.

커널과 앱 업데이트를 각각 검증하세요

일부 클라이언트는 앱과 함께 커널을 업데이트하고, 일부는 커널을 별도로 전환할 수 있습니다. 업데이트 전에 구독 출처, 로컬 덮어쓰기, 필요한 설정을 보관해 복구할 수 있는지 확인하세요. 자동 생성된 실행 파일 하나만 백업하지 마세요. 클라이언트가 포트, 경로, 시스템 설정을 이미 덮어썼을 수 있어 다른 기기에서 그대로 재사용하기 어렵습니다. 업데이트를 마친 뒤에는 먼저 로드 로그를 확인하고 노드, DNS, 규칙, 백그라운드 동작을 점검하세요.

업데이트 후 시작 문제가 생기면 먼저 최소 설정으로 실행해 구문 호환성 문제와 시스템 권한 충돌을 구분하세요. 프로젝트 계열에 대한 자세한 배경은 Clash·Meta·mihomo의 관계 정리를 참고하세요. 이름의 변천을 알아보는 목적은 기능이 어디서 비롯되었는지 확인하기 위해서이지, 특정 포크 이름을 성능이나 신뢰성의 보증으로 삼기 위해서가 아닙니다.

7. 구독 형식·필드 유지·규칙 호환성

구독 주소가 반환하는 내용은 전체 YAML, 노드 목록, 공유 링크 모음, 클라이언트 전용 형식일 수 있습니다. 전체 설정에는 노드뿐 아니라 정책 그룹, 규칙, DNS, 원격 규칙 출처가 포함될 수 있지만 노드 목록에는 보통 아웃바운드 정보만 담깁니다. 가져온 뒤 노드가 보인다고 해서 전체 트래픽 분기 설정까지 들어온 것은 아닙니다. 먼저 구독 유형을 확인한 다음 규칙을 구독에서 제공할지 로컬 설정에서 노드를 참조할지 결정하세요.

구문 분석에 성공해도 의미상 호환되지 않을 수 있습니다

YAML의 들여쓰기, 필드 유형, 목록 구조에 따라 파일을 파싱할 수 있는지가 결정됩니다. 프로토콜 지원, 정책 그룹 참조, 규칙 동작에 따라 설정이 예상대로 실행되는지가 결정됩니다. 예를 들어 규칙이 존재하지 않는 그룹을 참조하거나 노드가 현재 커널에서 지원하지 않는 유형을 사용하면 YAML 문법이 유효해도 연결이 제대로 되지 않습니다. 로그의 파싱 오류, 필드 오류, 실행 오류는 서로 다른 단계에서 발생합니다. 뒤따르는 오류를 각각 별개의 문제로 취급하지 말고 가장 먼저 나타난 문제부터 해결하세요.

형식 변환은 프로토콜 변환이 아닙니다. 변환 도구는 필드 이름을 바꾸고 노드를 정리하거나 규칙을 생성할 수 있지만 커널에 프로토콜 구현 기능을 새로 추가하거나 누락된 인증 매개변수를 만들어 낼 수는 없습니다. 원본 형식에 표현되지 않은 흐름 제어, 보안 계층, 데이터그램 설정은 대상 설정에서 생략될 수 있습니다. 복잡한 노드는 변환 전후의 주요 필드를 비교하세요. 유지 여부를 확인하기 어렵다면 여러 단계로 변환하기보다 대상 클라이언트에 맞게 구성된 원본 형식을 제공자에게 요청하세요.

규칙 순서와 이름 참조를 함께 확인하세요

Clash 형식의 규칙은 보통 위에서 아래로 적용되며 먼저 일치한 규칙이 아웃바운드를 결정합니다. 범위가 넓은 규칙을 너무 앞에 두면 뒤의 세부 규칙이 적용되지 않을 수 있습니다. 다음은 전체 설정이 아닌 규칙 일부입니다. 사용자 지정 정책 그룹을 참조하지 않아 순서를 이해하는 데 사용할 수 있습니다. 예시의 직접 연결 설정이 모든 사용자에게 적합한 분할 정책이라는 뜻은 아닙니다. 실제로 사용할 때는 대상 서비스와 필요에 따라 조정하고, 업데이트 시 클라이언트가 로컬 변경 사항을 덮어쓰지 않는지 확인하세요.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

DOMAIN-SUFFIX는 도메인 접미사로 일치 여부를 확인하고 GEOIP는 해당 지역 데이터와 DNS 조회 조건에 따라 동작하며 MATCH는 기본 규칙으로 사용됩니다. 프록시가 필요하다면 실제로 존재하는 정책 그룹 이름을 동작 값으로 지정하세요. 다른 설정의 그룹 이름을 그대로 복사해서는 안 됩니다. IP 규칙을 사용할 때는 도메인 조회를 유발하는지, 추가 조회를 피하는 관련 옵션을 사용하는지도 알아둬야 합니다. 그렇지 않으면 도메인 규칙이 적용되지 않는다고 오해할 수 있습니다.

자세한 규칙 작성법은 사용자 지정 규칙과 모바일 덮어쓰기 팁을 참고하세요. 로컬에서 추가한 규칙은 클라이언트가 지원하는 덮어쓰기 또는 병합 기능에 넣는 편이 원격 구독을 직접 수정하는 것보다 관리하기 쉽습니다. 클라이언트마다 목록을 교체하거나 추가하거나 전용 스크립트로 처리할 수 있으므로 같은 이름의 목록이 자동으로 병합된다고 가정하지 마세요. 편집 화면에서 보이는 위치만으로 최종 적용 순서를 판단할 수도 없습니다.

업데이트 실패와 구독 내용 변경을 구분하세요

업데이트 실패는 주소 만료, 인증 정보 만료, 다운로드 경로 연결 불가, 응답 형식 오류로 발생할 수 있습니다. 요청 성공이 유효한 설정을 보장하는 것도 아닙니다. 로그인 페이지, 안내 페이지, 빈 응답이 설정으로 저장될 수도 있습니다. 먼저 업데이트 로그와 응답 내용의 유형을 확인한 뒤 업데이트 요청에 사용할 아웃바운드를 바꿀지 판단하세요. 접근 권한이 포함된 구독 주소를 공개 문의 게시판에 올리거나 출처가 불분명한 변환 서비스에 업로드하지 마세요.

기기를 옮길 때는 원격 구독 출처와 로컬 규칙을 따로 내보내고 인증 정보는 숨기세요. 새 기기에서만 문제가 생기면 동일한 최소 설정으로 커널 기능을 비교하세요. 여러 기기에서 동시에 실패한다면 구독 출처와 서버 상태를 확인하세요. 문제를 한 계층으로 좁혀 살펴보면 모든 데이터를 반복해서 삭제하지 않고 기존 트래픽 분기 설정을 보존하기 쉽습니다.

8. DNS 경로·상황별 선택·확인 순서

DNS는 도메인을 IP 주소로 변환하며 도메인 규칙을 적용하는 데 필요한 정보에도 영향을 줍니다. DNS는 프록시 프로토콜 자체는 아니지만 잘못 설정하면 노드는 연결되는데 일부 앱에서 사이트가 열리지 않을 수 있습니다. DNS 유출을 확인하려면 먼저 어떤 조회를 어느 경로로 보낼지 정하고 실제 동작이 그에 맞는지 살펴봐야 합니다. DNS 조회를 암호화하는 것과 프록시를 거쳐 조회하는 것은 서로 다른 문제입니다. 암호화된 DNS를 사용해도 요청이 로컬 네트워크에서 직접 나갈 수 있습니다.

목적지 도메인과 노드 도메인의 조회를 구분하세요

클라이언트는 사용자가 접속하는 도메인뿐 아니라 프록시 서버의 도메인도 조회해야 할 수 있습니다. 아직 프록시 연결이 설정되지 않았는데 노드 도메인 조회에도 프록시가 필요한 경우 순환 문제가 생길 수 있습니다. 일부 설정은 별도의 DNS 서버나 노드 전용 DNS 설정으로 이 문제를 해결합니다. DNS를 조정하기 전에 현재 커널에서 각 필드가 어떤 의미인지 확인하세요. 다른 커널의 같은 이름 설정을 그대로 적용해서는 안 됩니다. 오류 로그에 서버 도메인 조회 실패가 가장 먼저 나타난다면 우선 기본 조회 경로부터 복구하세요.

Fake-IP는 합성 주소를 할당해 이후 연결에서도 클라이언트가 도메인 정보를 유지하도록 합니다. 다른 모드는 실제 DNS 조회 결과를 반환합니다. Fake-IP가 웹사이트의 실제 주소를 바꾸거나 모든 우회 DNS 조회를 자동으로 막아 주는 것은 아닙니다. 로컬 네트워크 기기 검색, 일부 게임, 자체 DNS 처리를 사용하는 앱에는 예외가 필요할 수 있습니다. 예외를 추가할 때는 해당 도메인과 증상에 맞게 설정하세요. 모든 도메인을 제외하면 원래 필요한 도메인 연결 정보가 사라질 수 있습니다.

IPv6도 함께 확인해야 합니다. IPv4 프록시 경로만 설정했는데 시스템이나 앱이 IPv6를 직접 사용하면 예상과 다른 방식으로 연결될 수 있습니다. 듀얼 스택 라우팅, 클라이언트의 트래픽 처리 범위, DNS 응답 정책을 확인한 뒤 특정 환경에서 한쪽 프로토콜을 제한할지 결정하세요. IPv6 비활성화는 문제 위치를 찾기 위한 방법일 수 있지만 모든 휴대폰에 권장되는 최적화라고 할 수 없으며 트래픽 처리 규칙의 빈틈을 가리는 용도로 써서도 안 됩니다.

사용 상황에 맞는 조합을 선택하세요

일상적인 웹 검색과 메시지 사용에는 서버 매개변수가 완전하고 최초 연결이 안정적이며 백그라운드 복구가 정상적인 설정을 우선 선택하세요. SS, VMess, Trojan, VLESS 모두 용도에 따라 충분할 수 있으므로 프로토콜이 새것인지 오래된지만 보고 사용 가능한 설정을 바꿀 필요는 없습니다. 모바일로 업무를 본다면 회의, 파일 전송, 화면 잠금 후 복구를 추가로 테스트하세요. 로컬 네트워크 기기에 접속해야 한다면 직접 연결 규칙과 로컬 이름 조회를 별도로 확인해 프린터나 저장 장치 요청이 원격 서버로 잘못 전달되지 않게 하세요.

실시간 음성 통화와 게임에서는 UDP 지원, 지터, 네트워크 전환 동작을 확인해야 하며 웹페이지 테스트 결과만 비교해서는 안 됩니다. 변동이 큰 네트워크에서는 Hysteria2 또는 TUIC를 비교해 볼 수 있지만 먼저 UDP 경로를 확인하고 TCP 계열 아웃바운드를 대체 경로로 유지하세요. 대용량 파일 전송에서는 지속 전송량, 기기 온도, 다른 앱에 미치는 영향을 살펴보세요. 최고 속도를 높이려고 대역폭 추정값을 과도하게 설정하지 마세요. 배터리가 중요하다면 프로토콜을 자주 바꾸기보다 불필요한 재연결과 중복 상태 확인을 줄이는 편이 효과적입니다.

최소한의 변경부터 검증하세요

다음 순서로 문제 범위를 좁혀 보세요. 네트워크에 로그인할 수 있고 기본 서비스에 접속할 수 있는지 확인합니다. 노드 주소를 조회할 수 있고 핸드셰이크 매개변수가 일치하는지 확인합니다. 정책 그룹을 고정해 목적지 하나로 테스트합니다. 연결 로그에서 어떤 규칙이 적용되었는지 살펴봅니다. 마지막으로 DNS, IPv6, 시스템 트래픽 처리 범위를 확인합니다. 각 단계의 전후 결과를 기록하고 커널, 구독, 네트워크를 동시에 바꾸지 마세요. 특정 앱에서만 문제가 발생한다면 자체 DNS 조회, 특수 전송 방식, 브라우저와 다른 연결 방식을 사용하는지 확인하세요.

DNS 경로를 점검할 때는 클라이언트 연결 기록, DNS 조회 로그, 예상되는 트래픽 출구를 함께 확인해야 합니다. 브라우저에 표시되는 DNS 서비스 제공자 이름은 참고 자료일 뿐, 모든 앱의 조회가 예상대로 처리된다는 증거가 되지는 않습니다. 상세 로그를 잠시 켰다면 확인 후 평소 로그 수준으로 되돌리세요. 기록을 공유하기 전에 구독 주소, 인증 정보, 개인 접속 내용을 제거하세요. 문제가 해결된 뒤에는 화면 잠금, 네트워크 전환, 백그라운드 동작을 다시 확인해 브라우저를 사용하는 동안에만 해결된 것은 아닌지 점검하세요.