프로토콜 매뉴얼: 프록시 프로토콜 및 코어 기술 참고서

A프로토콜 개요: 6가지 프로토콜의 등장 배경과 설계 방향

Clash 생태계에서 흔히 쓰이는 6가지 프로토콜은 등장 순서에 따라 하나의 발전 흐름으로 정리할 수 있습니다. Shadowsocks가 가장 먼저 나왔고, VMess와 Trojan은 중간 세대, VLESS, Hysteria2, TUIC는 비교적 최근의 방향입니다. 각 세대는 이전 세대에서 드러난 문제에 대응하며 등장했기 때문에 "모든 면에서 완벽한" 프로토콜은 없고, 저마다 다른 절충안을 가진 프로토콜만 존재합니다.

Shadowsocks: 극도로 단순한 대칭 암호화

Shadowsocks(줄여서 SS)의 설계 목표는 최소화입니다. 클라이언트와 서버가 동일한 비밀번호와 암호화 방식을 미리 정해두고, 데이터는 AEAD 대칭 암호화를 거쳐 그대로 전송되며, 별도의 핸드셰이크 협상이나 추가 인증 왕복이 없습니다. 이 덕분에 구현이 단순하고 연결 수립이 빠르지만, 프로토콜 자체에 위장 계층이 없어 확장 기능은 SIP003 플러그인 체계(obfs, v2ray-plugin 등)에 의존해야 합니다. 암호화 방식으로는 aes-128-gcm과 chacha20-ietf-poly1305가 주로 쓰이는데, 전자는 하드웨어 가속을 지원하는 x86 기기에서 더 빠르고, 후자는 대부분의 스마트폰 ARM 칩에서 성능이 더 좋습니다.

VMess와 Trojan: 서로 반대되는 두 가지 방향

VMess는 V2Ray 프로젝트에서 나온 것으로 "기능 풍부함"을 추구합니다. 사용자 UUID를 기반으로 동적 인증을 하며, 여러 전송 계층(TCP, WebSocket, gRPC 등)을 자유롭게 조합할 수 있고, 메타데이터에 비교적 많은 제어 정보를 담습니다. 그 대가로 프로토콜 헤더 오버헤드가 크고, 인증 과정이 클라이언트와 서버의 시스템 시간이 대략 일치해야 한다는 조건에 의존합니다. 시간 차이가 크면 연결이 바로 실패하는데, 이는 VMess 노드 이상을 점검할 때 가장 먼저 확인해야 할 부분입니다. 반면 Trojan은 정반대 노선을 택합니다. 자체 암호화를 만들지 않고 표준 TLS를 그대로 사용해 일반 HTTPS 웹사이트 접속과 겉모습이 동일하게 보입니다. 그 부담은 서버 측이 지는데, 도메인과 유효한 인증서가 필요하지만 사용자 입장에서는 거의 체감되지 않으며 설정 항목도 가장 적습니다.

VLESS, Hysteria2, TUIC: 새로운 세대의 경량화와 방향 전환

VLESS는 VMess에서 기능을 덜어낸 형태입니다. 프로토콜 자체의 암호화와 시간 인증을 없애고 보안을 전적으로 외부 TLS(및 REALITY 등의 확장)에 맡겨, 프로토콜 헤더를 최대한 가볍게 하고 VMess보다 전달 오버헤드를 크게 줄였습니다. Hysteria2와 TUIC는 방향을 전환한 사례입니다. TCP를 버리고 UDP 기반의 QUIC를 기반으로 삼았습니다. Hysteria2는 적극적인 혼잡 제어 전략을 내장해 손실률이 높고 지연이 큰 열악한 회선에서도 처리량을 유지하는 것이 특징이고, TUIC는 핸드셰이크 효율에 초점을 맞춰 QUIC의 0-RTT 특성을 활용해 연결 수립 시간을 극도로 줄이고 UDP 전달을 기본적으로 지원합니다. 이 세 가지 프로토콜은 Clash 생태계에서 mihomo 계열 코어만 지원하며, 이에 대해서는 E장에서 자세히 다룹니다.

B전송 계층 차이: TCP 계열과 QUIC 계열의 분기점

6가지 프로토콜의 진짜 분기점은 암호화 방식이 아니라 전송 계층입니다. SS, VMess, Trojan, VLESS는 TCP 계열이고, Hysteria2와 TUIC는 QUIC 계열입니다. 이 구분을 이해하는 것이 각 프로토콜의 필드를 외우는 것보다 훨씬 유용한데, 이는 서로 다른 네트워크 환경에서 프로토콜의 동작 차이를 직접적으로 결정하기 때문입니다.

TCP 계열: 성숙하고 안정적이며 경로 친화적

TCP 계열 프로토콜의 가장 큰 장점은 "경로 친화성"입니다. TCP는 인터넷에서 가장 성숙한 전송 프로토콜로, 경유하는 라우터, 방화벽, 통신사 QoS 장비가 모두 완비된 처리 로직을 갖추고 있어 트래픽 전체가 제한되거나 폐기되는 경우가 매우 드뭅니다. Trojan과 VLESS는 TLS를 덧씌우면 일반 웹 접속과 트래픽 특성이 동일해져 호환성이 가장 좋습니다. 대가는 두 가지입니다. 첫째는 핸드셰이크 횟수가 많다는 점으로, TCP 3-way 핸드셰이크에 TLS 핸드셰이크가 더해져 연결 수립에 최소 2~3번의 왕복이 필요하며, 노드와의 물리적 거리가 멀수록 첫 패킷 대기 시간이 눈에 띄게 늘어납니다. 둘째는 헤드 오브 라인 블로킹(Head-of-Line Blocking)으로, TCP는 바이트 스트림의 순서를 엄격히 보장하기 때문에 패킷 하나가 손실되면 이후의 모든 데이터가 지연되며, 이는 뒤따르는 데이터가 전혀 관련 없는 요청이라도 마찬가지입니다. 손실률이 높은 회선에서는 이 특성이 간헐적인 손실을 전체적인 끊김으로 증폭시킵니다.

QUIC 계열: 핸드셰이크가 적고 손실에 강하지만 UDP 처리 방식에 의존

QUIC는 UDP 위에 신뢰성 있는 전송을 다시 구현하고 TLS 1.3 핸드셰이크를 연결 수립 과정에 통합해, 새 연결은 보통 한 번의 왕복으로 완료되며 재연결 시에는 0-RTT로 첫 패킷에 데이터를 실어 보낼 수도 있습니다. QUIC의 스트림(stream)은 서로 독립적이어서 패킷 하나의 손실이 해당 스트림에만 영향을 미치고 다른 요청을 막지 않는데, 이것이 열악한 네트워크에서 QUIC의 체감이 더 나은 근본적인 이유입니다. 또한 QUIC는 연결 마이그레이션을 지원해 기기가 Wi-Fi에서 셀룰러로 전환되어도 연결을 재수립하지 않고 이어갈 수 있어 모바일 기기에서 특히 유용합니다. 반면 약점 역시 UDP에서 옵니다. 일부 통신사와 기업 네트워크는 UDP 트래픽을 제한하거나 낮은 우선순위로 처리하는데, 이런 회선에서는 QUIC 계열 프로토콜이 일반적인 TLS-over-TCP 연결보다 오히려 못한 체감을 보일 수 있습니다. 따라서 "Hysteria2가 Trojan보다 무조건 빠르다"는 결론은 성립하지 않습니다. 빠른지는 그 경로가 UDP를 어떻게 대우하는지에 달려 있습니다.

멀티플렉싱 위치의 차이

TCP 계열 프로토콜은 mux 설정으로 여러 요청을 한 연결에 다중화해 핸드셰이크 횟수를 줄일 수 있지만, 다중화는 헤드 오브 라인 블로킹의 영향 범위도 함께 넓히기 때문에 보통 지연이 큰 회선에서만 필요에 따라 켜는 것을 권장합니다. QUIC 계열 프로토콜의 멀티플렉싱은 기본적으로 내장되어 있어 별도 설정이 필요 없고 요청 간 블로킹도 발생하지 않습니다. 이는 전송 계층 설계에서 나오는 근본적인 차이로, 파라미터 튜닝으로 메울 수 있는 부분이 아닙니다.

C연결 속도와 리소스 사용량: 정성적 비교

프로토콜 성능에는 일반적으로 인용할 만한 수치가 존재하지 않습니다. 같은 프로토콜이라도 회선과 기기에 따른 차이가 프로토콜 간 차이보다 훨씬 큽니다. 따라서 이 장에서는 정성적 비교만 다루며, "다른 조건이 동일하다"는 전제하의 상대적 순위와 리소스 사용량의 구조적 차이를 제시합니다.

연결 수립 속도

"새 웹사이트를 열 때 얼마나 기다려야 하는가"를 결정하는 핵심 변수는 연결 수립에 필요한 왕복 횟수입니다. 핸드셰이크 횟수가 적은 순서로 나열하면 TUIC와 Hysteria2(QUIC, 한 번의 왕복, 재연결 시 0-RTT 가능)가 가장 빠르고, 그다음이 SS(프로토콜 핸드셰이크 없이 TCP 3-way 핸드셰이크만 필요), Trojan과 VLESS는 TCP와 TLS 두 계층의 핸드셰이크가 필요하며, VMess는 프로토콜 헤더와 인증 오버헤드로 인해 보통 같은 계열 중 연결 수립이 가장 느립니다. 이 순위는 새 연결의 첫 패킷 시간에만 영향을 미치며 연결이 수립된 이후의 지속적인 전송 속도와는 무관하다는 점에 주의해야 합니다. 짧은 연결을 자주 여는 웹 브라우징 같은 상황은 연결 수립 속도에 가장 민감하고, 동영상 시청이나 대용량 다운로드 같은 장기 연결 상황에서는 거의 체감이 없습니다.

처리량과 CPU 오버헤드

지속적인 처리량의 병목은 대부분 회선 자체에 있으며, 프로토콜 간 차이는 주로 CPU 사용량에서 드러납니다. 암호화 연산이 가장 큰 부분을 차지합니다. x86 기기는 대부분 AES 하드웨어 가속 명령을 지원해 aes-128-gcm을 실행해도 CPU 사용량이 거의 없고, 대부분의 ARM 모바일 칩에서는 chacha20-ietf-poly1305가 오히려 더 효율적입니다. VLESS는 프로토콜 자체가 암호화를 수행하지 않고(외부 TLS 한 계층만 있음) 동일한 처리량 대비 CPU 사용량이 가장 낮아, 대용량 전달 시나리오에 자주 쓰이는 이유입니다. QUIC 계열 프로토콜의 암호화 송수신은 현재 대부분 사용자 공간에서 처리되어 운영체제가 TCP에 제공하는 성숙한 최적화를 누리지 못하며, 대역폭을 최대로 쓰는 극한 상황에서는 CPU 사용량이 TCP 계열보다 눈에 띄게 높아집니다. 데스크톱 기기에서는 체감이 거의 없지만 저전력 기기에서는 유의해야 합니다.

메모리와 저사양 기기

메모리 사용량은 주로 코어와 규칙 데이터에 의해 결정되며, 프로토콜 자체의 차이는 미미합니다. 실제로 메모리를 많이 차지하는 것은 GEO 데이터베이스와 대용량 규칙 세트입니다. 라우터, 구형 스마트폰처럼 메모리가 한정된 기기에서는 규칙 파일을 정리하는 것이 프로토콜을 바꾸는 것보다 메모리 절감에 더 효과적입니다. 메모리가 적은 라우터 기기라면 SS나 Trojan처럼 구현이 단순한 프로토콜을 우선 선택하고 mihomo 코어의 경량 설정을 사용하는 것이 좋으며, 저사양 기기에서 QUIC 계열 프로토콜의 신기능을 무리하게 추구하지 않는 것을 권장합니다. 동시 연결 수가 많은 상황(웹페이지 다중 열기, P2P 등)에서는 TCP 연결마다 독립적인 시스템 오버헤드가 발생하므로 mux를 켜거나 네이티브 멀티플렉싱을 지원하는 QUIC 계열 프로토콜로 전환하면 전체 연결 수를 줄일 수 있습니다. 이는 리소스 관점에서 프로토콜을 선택할 때 고려할 또 다른 요소입니다.

D모바일 배터리 소모: 프로토콜 외에 클라이언트 동작도 영향

스마트폰의 배터리 소모 문제는 흔히 프로토콜 탓으로 여겨지지만, 실제로는 세 가지 요소가 겹쳐 배터리를 소모시킵니다. 프로토콜의 연결 유지 동작, 클라이언트의 백그라운드 정책, 시스템이 VPN 서비스를 스케줄링하는 방식입니다. 프로토콜만 바꾸고 클라이언트 동작을 조정하지 않으면 절전 효과는 대체로 제한적입니다.

무선 모듈 웨이크업: 모바일 배터리 소모의 진짜 원인

셀룰러 네트워크에서는 데이터 전송이 없을 때 스마트폰의 베이스밴드 칩이 저전력 상태로 들어가며, 어떤 패킷이라도 도착하면 이를 깨워 일정 시간 고전력 상태를 유지하게 됩니다. 따라서 배터리 소모의 핵심은 데이터 전송량이 아니라 웨이크업 횟수입니다. 프로토콜 계층의 연결 유지 하트비트, 클라이언트의 주기적 지연 테스트, 정책 그룹의 자동 속도 측정 등이 모두 주기적인 웨이크업을 유발합니다. QUIC 계열 프로토콜의 연결 마이그레이션 특성은 여기서 실질적인 가치를 발휘합니다. Wi-Fi와 셀룰러 전환 시 연결이 그대로 이어져 재연결에 필요한 핸드셰이크와 연쇄적인 웨이크업을 줄일 수 있습니다. TCP 계열 프로토콜은 네트워크 전환 시 모든 연결이 무효화되어 재수립해야 하며, 전환이 빈번한 통근 상황에서는 그 차이가 누적됩니다.

클라이언트 측에서 조정 가능한 항목

프로토콜 선택보다 더 큰 영향을 주는 것은 클라이언트 설정입니다. 첫째, 정책 그룹의 자동 속도 측정 간격입니다. url-test 유형의 그룹은 기본적으로 그룹 내 모든 노드를 주기적으로 테스트하는데, 간격을 너무 짧게 설정하면 몇 분마다 스마트폰을 깨워 대량의 연결을 발생시키는 셈이 됩니다. 모바일 기기에서는 interval 값을 넉넉하게 설정하거나 자주 쓰지 않는 그룹은 수동 선택으로 바꾸는 것이 좋습니다. 둘째, TUN 모드와 시스템 프록시의 차이입니다. TUN 모드는 전체 트래픽을 처리하므로 경로가 더 길어져 대기 전력 소모가 브라우저 트래픽만 처리하는 시스템 프록시 모드보다 약간 높습니다. 전체 트래픽을 관리할 필요가 없다면 모바일에서는 시스템 프록시 모드가 더 절전에 유리합니다. 셋째, 규칙 개수입니다. 새 연결마다 규칙 매칭을 거쳐야 하므로 규칙 세트가 클수록 매칭 오버헤드가 커집니다. 모바일 설정에서는 사용하지 않는 대량의 규칙 세트를 쌓아두지 않는 것이 좋습니다.

iOS의 특수한 제약

iOS에서 프록시 클라이언트는 Network Extension 프레임워크 안에서 실행되며, 시스템이 이 확장 프로세스에 부여하는 메모리 제한이 매우 엄격해 한도를 넘으면 즉시 종료됩니다. 이는 프록시가 이유 없이 끊기는 현상으로 나타납니다. 따라서 iOS 클라이언트는 규칙과 GEO 데이터 용량을 특히 엄격하게 관리해야 하며, 프로토콜 역시 구현이 가벼운 쪽을 선택하는 것이 바람직합니다. Clash Plus는 iOS에서 App Store를 통해 배포되며 이 제약에 맞춰 메모리 관리를 최적화했기 때문에 iOS 플랫폼에서 우선 추천됩니다. 설치는 다운로드 페이지의 iOS 섹션에서 가능합니다. 안드로이드에서는 시스템의 배터리 최적화 예외 목록을 확인하는 것이 좋습니다. 클라이언트가 시스템에 의해 정지된 후 VPN 서비스가 재시작되면 재연결 과정에서 다시 배터리를 소모하게 되므로, 예외 목록에 추가하는 것이 프로토콜을 바꾸는 것보다 배터리 지속 시간 개선에 더 효과적입니다.

E코어 계열: 오리지널, Premium, Meta, mihomo의 관계

"Clash"라는 용어는 맥락에 따라 다른 것을 가리킵니다. 때로는 코어(백그라운드에서 트래픽을 처리하는 커맨드라인 프로그램)를, 때로는 클라이언트(그래픽 인터페이스를 가진 앱)를 의미합니다. 클라이언트는 코어를 감싸는 외피일 뿐이며, 프로토콜 지원, 규칙 기능, TUN 구현은 모두 코어가 결정합니다. 코어 계열 간의 관계를 이해하는 것은 "같은 노드가 A 클라이언트에서는 되고 B 클라이언트에서는 오류가 나는 이유"를 이해하는 전제입니다.

3세대 코어의 발전 흐름

오리지널 Clash 코어는 이 모든 것의 출발점으로, proxies, proxy-groups, rules 3단 구조의 설정 방식을 확립했고 SS, VMess, Trojan 등 기본 프로토콜을 지원했습니다. 다만 상위 저장소는 이미 아카이브되어 더 이상 업데이트되지 않습니다. Premium은 오리지널 작성자가 유지 관리한 비공개 강화 버전으로, TUN 모드와 규칙 제공자(rule providers) 등의 기능을 추가했지만 오리지널과 함께 개발이 멈췄습니다. Clash Meta는 커뮤니티가 오리지널을 기반으로 이어간 파생 프로젝트로, 이후 mihomo로 이름이 바뀌었습니다. 두 이름은 같은 발전 흐름을 가리키며, 현재 정식 명칭은 mihomo입니다. 기존 설정 구조와의 호환성을 유지하면서 VLESS, Hysteria2, TUIC 등 신규 프로토콜을 지원하고, 규칙 세트(rule-set), 도메인 스니핑(sniffer), 더 완비된 GEO 데이터 관리 기능 등을 확장했으며, 현재 유일하게 활발히 유지 관리되는 메인 코어입니다.

클라이언트와 코어의 대응 관계

클라이언트를 선택하는 것은 본질적으로 코어를 선택하는 것입니다. 다운로드 페이지에 등록된 클라이언트 중 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, Clash Meta for Android, ClashX Meta는 모두 mihomo 계열 코어를 기반으로 하여 6가지 프로토콜을 온전히 사용할 수 있습니다. Clash for Windows는 오리지널/Premium 코어 기반이며 유지 관리가 중단되어 VLESS, Hysteria2, TUIC 노드를 만나면 바로 미지원 오류가 발생하므로, 기존 설정을 그대로 써야 하는 사용자에게만 계속 사용을 권장합니다. 구독에 이미 QUIC 계열 프로토콜 노드가 포함되어 있다면 클라이언트는 무조건 mihomo 계열을 선택해야 하며 다른 대안은 없습니다. 각 클라이언트의 인터페이스, 플랫폼 지원 범위, 업데이트 주기 등 세부 차이는 클라이언트 비교 페이지에서 확인할 수 있으며, 결론부터 말하면 전 플랫폼에서는 Clash Plus를 우선 추천하고 데스크톱에서는 Clash Verge Rev를 그다음으로 추천합니다.

F설정과 구독 형식 호환성

구독은 "서버가 내려주는 설정 파일"이므로 형식 호환성 문제는 두 계층으로 나뉩니다. 설정 파일 자체의 필드가 코어에서 인식되는지, 그리고 구독 링크가 내려주는 형식이 클라이언트에서 인식되는지입니다. 두 계층은 각각 별개의 함정을 가지고 있어 섞어서 점검하면 오히려 더 헤매게 됩니다.

설정 필드 계층: 같은 구조, 두 개의 필드 세트

모든 Clash 계열 코어는 동일한 YAML 구조를 공유합니다. proxies는 노드를 정의하고, proxy-groups는 정책 그룹을 정의하며, rules는 분기 규칙을 정의합니다. 차이는 필드 세트에 있습니다. 오리지널 코어는 기본 프로토콜의 필드만 인식하고, mihomo는 같은 구조 안에서 신규 프로토콜 유형과 추가 파라미터를 확장했습니다. 아래 예시는 같은 설정 파일 안에서 신규와 기존 노드의 형태 차이를 보여줍니다.

proxies:
  - name: "노드-SS"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
  - name: "노드-HY2"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com

이 설정을 오리지널 코어에 넘기면 type: hysteria2를 읽는 순간 "unsupported proxy type" 같은 오류로 전체 설정을 통째로 거부합니다. 해당 노드만 건너뛰는 것이 아니라 전체 설정 로딩이 실패하는 것입니다. 이는 흔히 보이는 현상을 설명해 줍니다. 같은 구독이 새 클라이언트에서는 정상인데 오래된 클라이언트에서는 "노드가 하나도 없다"는 식으로 나타나는 것입니다. 반대로 기본 프로토콜만으로 구성된 설정은 mihomo에서도 그대로 실행됩니다. 즉 호환성은 한 방향으로만 작동합니다. 새 코어는 옛 설정을 인식하지만 옛 코어는 새 필드를 인식하지 못합니다.

구독 전달 계층: 형식과 User-Agent

구독 링크가 반환하는 내용은 보통 세 가지 형태입니다. Clash YAML(바로 사용 가능), Base64로 인코딩된 공유 링크 목록(클라이언트 변환 필요), 그리고 sing-box 등 다른 생태계의 JSON(Clash 계열 클라이언트가 직접 지원하지 않음)입니다. 많은 구독 서버는 요청 헤더의 User-Agent에 따라 어떤 형식을 내려줄지 결정합니다. 같은 링크라도 Clash 계열 클라이언트로 요청하면 YAML을 받고 브라우저로 열면 Base64를 받는 식입니다. 여기서 눈에 잘 안 보이는 문제가 생길 수 있습니다. 서버가 특정 클라이언트의 UA를 인식하지 못하면 잘못된 형식을 내려주거나 응답을 거부할 수 있는데, 이는 "이 링크가 다른 클라이언트에서는 되는데 이 클라이언트에서는 가져오기가 실패한다"는 현상으로 나타납니다. 이런 경우 클라이언트의 구독 설정에서 UA 문자열을 직접 지정하거나 구독 제공자에게 지원되는 클라이언트 목록을 확인하는 것이 좋습니다.

구독 가져오기 오류, 업데이트 후 노드가 사라지는 등 구체적인 문제의 항목별 점검은 기술 노트 《Clash 구독 실패 또는 파싱 오류의 6가지 원인과 점검 방법》에서 따로 다루고 있으므로 이 장에서는 반복하지 않습니다.

G사용 환경별 선택 가이드

앞선 각 장의 결론을 여기서 실행 가능한 지침으로 정리합니다. 전제를 다시 강조합니다. 회선 품질의 영향이 프로토콜 차이보다 훨씬 크며, 아래 지침은 모두 "같은 노드 서버가 여러 프로토콜 접속 방식을 제공한다"는 것을 전제로 합니다. 이 전제 위에서 상황에 맞게 프로토콜을 고르는 것이 의미가 있습니다.

정책 그룹으로 선택을 반영하고, 수동 전환에 의존하지 않기

선택을 실제로 반영하는 방법은 매번 수동으로 노드를 바꾸는 것이 아니라 판단을 정책 그룹에 반영해두는 것입니다. 흔히 쓰는 방식은 용도별로 별도의 정책 그룹을 만드는 것입니다. 브라우징용으로 url-test 그룹(지연이 가장 낮은 노드를 자동 선택)을, 다운로드용으로 수동 select 그룹(처리량이 좋은 노드로 고정)을 만들고, 규칙을 이용해 도메인별로 해당 그룹에 배분하는 것입니다. 이렇게 하면 프로토콜 선택은 한 번만 하면 되고 이후에는 규칙이 자동으로 처리합니다. 그룹 안에 여러 프로토콜을 섞어 두는 것도 가능하며, url-test의 자동 테스트가 실제 성능을 대신 비교해 줍니다. 다만 자동 테스트가 반영하는 것은 주로 연결 지연이며 처리량 차이는 직접 체감해 확인해야 합니다.

고민할 필요 없는 두 가지 경우

첫째, 구독이 한두 가지 프로토콜만 제공하는 경우에는 선택할 여지가 없으므로 그대로 쓰면 됩니다. "매뉴얼에서 QUIC가 더 빠르다고 했으니"라는 이유로 프로토콜 변경을 요구할 필요는 없습니다. 이득은 불확실한데 소통 비용은 확실히 들기 때문입니다. 둘째, 데스크톱 유선 네트워크에서 회선 품질이 좋을 때는 6가지 프로토콜의 체감 차이가 거의 느껴지지 않을 정도로 좁혀지므로, 이때는 규칙과 정책 그룹 구성에 신경 쓰는 것이(가이드의 분기 관련 챕터 참고) 프로토콜을 이리저리 바꾸는 것보다 훨씬 이득입니다. 선택 가이드의 가치는 경계 상황에서 드러납니다. 열악한 네트워크, 이동 중, 저사양 기기, UDP 제한 이 네 가지 환경에서는 위 표에 따라 조정하면 체감할 수 있는 차이가 생깁니다.

H흔한 오해와 문제 해결 힌트

마지막 장에서는 프로토콜과 코어를 둘러싼 자주 발생하는 오해와, "증상—원인 파악—해결 방법" 형태의 점검 인덱스를 정리합니다. 여기서는 판단에 필요한 힌트만 제공하며, 전체적인 점검 절차는 각 전문 문서에서 다룹니다.

가장 널리 퍼진 세 가지 오해

오해 1: "프로토콜이 새로울수록 빠르다." 새 프로토콜은 특정 상황(열악한 네트워크, 핸드셰이크 지연, UDP 전달)의 문제를 해결하는 것이며 모든 상황에서 속도를 높여주지 않습니다. 회선 자체의 대역폭, 혼잡 정도, 물리적 거리가 체감의 상한선을 결정하며 프로토콜은 그 상한선에 얼마나 가깝게 다가가는지에만 영향을 줍니다. 오해 2: "암호화가 강할수록 안전하니 가장 복잡한 프로토콜을 선택해야 한다." 6가지 프로토콜 모두 암호학적으로 현대적인 AEAD 또는 TLS 1.3을 사용하므로 강도는 이미 충분하며, 복잡도의 차이는 기능과 오버헤드에서 드러날 뿐 "보안 수준"에서 드러나지 않습니다. 상상 속의 보안을 위해 오버헤드가 큰 프로토콜을 선택하는 것은 순전한 손실입니다. 오해 3: "지연 테스트 수치가 실제 사용 체감을 대표한다." 클라이언트 내 지연 테스트는 보통 HTTP 요청 한 번의 소요 시간으로 연결 수립과 회선 왕복을 반영할 뿐, 처리량, 손실률, UDP 처리 방식은 반영하지 않습니다. 두 노드의 지연 수치가 같더라도 실제 체감은 크게 다를 수 있습니다. 수치는 같은 프로토콜 노드 간 비교에는 유효하지만 프로토콜을 넘나드는 비교에는 신중해야 합니다.

증상별 원인 파악

노드가 "unsupported proxy type" 오류를 내거나 구독 로드 후 노드가 사라진 경우: 코어가 해당 프로토콜 유형을 지원하지 않을 가능성을 우선 의심하고, E장을 참고해 클라이언트의 코어 계열을 확인한 뒤 필요하면 mihomo 계열 클라이언트로 교체합니다(다운로드 페이지에서 각 플랫폼별로 제공). VMess 노드만 실패하고 다른 프로토콜은 정상인 경우: 기기의 시스템 시간이 표준 시간과 크게 벗어나 있는지 확인합니다. QUIC 계열 노드(Hysteria2/TUIC)가 특정 네트워크에서 눈에 띄게 느려지거나 연결되지 않다가 네트워크 전환 후 정상으로 돌아오는 경우: UDP가 제한받는 특징에 부합하므로 해당 네트워크에서는 TCP 계열 프로토콜로 전환합니다. 모든 노드가 전부 타임아웃되는 경우: 대부분 로컬 네트워크, 구독 서버, 클라이언트 상태 문제와 관련이 있고 프로토콜 선택과는 무관하므로 《Clash 노드가 전부 타임아웃되어 연결할 수 없을 때》의 순서대로 가까운 곳부터 먼 곳까지 점검합니다. 프록시는 연결되었지만 웹페이지가 열리지 않는 경우: 대부분 시스템 프록시, DNS, 규칙 매칭 단계에서 막히는 것이므로 《Clash는 연결됐지만 웹페이지가 열리지 않을 때》의 체크리스트를 항목별로 확인합니다.

추가로 참고할 만한 곳

용어 관련 궁금증(정책 그룹, TUN, GEO 데이터, REALITY 등)은 용어집에 분류별로 정리되어 있고, 설치·설정·사용 중의 개별 문제는 FAQ에서 "기본 개념—설치 설정—사용 팁—문제 해결" 4가지 분류로 정리되어 있습니다. 플랫폼 관련 설치 세부 사항(macOS 네트워크 확장 권한, Windows TUN 모드)은 기술 노트의 플랫폼 가이드 시리즈에서 화면별로 설명하고 있습니다. 이 페이지는 코어와 프로토콜 생태계의 변화에 따라 계속 수정되며, 현재 버전을 기준으로 참고하시기 바랍니다.