프로토콜·코어 기술 참고서

A프로토콜 발전 흐름: 세 세대의 설계 사고

여섯 가지 프로토콜은 같은 시기에 만들어진 것이 아니며, 각각 당시 가장 두드러진 문제를 해결하기 위해 설계되었습니다. 핵심 사고에 따라 세 세대로 나눌 수 있으며, 이 순서를 이해하면 이후의 모든 비교를 굳이 외우지 않아도 됩니다 — 각 세대의 장점과 단점은 설계 목표의 직접적인 결과이기 때문입니다.

1세대: 극단적 단순화

Shadowsocks가 대표적입니다. 설계 목표는 "경량화"로, 대칭 암호화로 TCP 스트림을 직접 감싸고 프로토콜 헤더를 최소화해 핸드셰이크 협상, 세션 관리, 추가 메타데이터가 전혀 없습니다. 서버와 클라이언트는 네 가지 파라미터(주소, 포트, 암호화 방식, 비밀번호)만 합의하면 통신할 수 있습니다. 대가는 프로토콜 자체에 신원 체계나 전송 계층 위장 능력이 없다는 것으로, 이후의 모든 요구 사항은 외부 수단으로 보완해야 합니다.

2세대: 프로토콜 내 메타데이터

Vmess가 대표적입니다. 프로토콜 내부에 사용자 ID(UUID), 타임스탬프 검증, 명령 필드 등 구조화된 메타데이터를 도입하고, "전달 방식"을 교체 가능한 전송 계층으로 추상화했습니다. 동일한 Vmess 노드는 순수 TCP, WebSocket, HTTP/2, gRPC 위에서 실행될 수 있으며, 필요에 따라 TLS를 추가로 얹을 수 있습니다. 유연성이 크게 향상된 대신 설정 항목도 함께 늘어나 — Vmess 노드 하나의 설정 가능한 파라미터는 Shadowsocks의 몇 배에 달하며, 문제 해결 난이도도 함께 올라갑니다.

3세대: 위장과 기반 교체

3세대는 두 갈래로 나뉩니다. 하나는 "위장" 노선으로, Trojan과 VLESS는 자체 암호화 캡슐을 만들지 않고 데이터를 표준 TLS 세션 안에 직접 넣어, 프록시 트래픽이 외형상 일반 HTTPS 접속과 동일하게 보이도록 하면서 불필요한 암호화 계층을 하나 줄입니다. 다른 하나는 "기반 교체" 노선으로, Hysteria2와 TUIC는 TCP를 버리고 QUIC(UDP) 기반으로 전송 계층을 재구축해 고지연·고손실 링크에서의 처리량과 핸드셰이크 속도를 주로 노립니다. 두 노선이 해결하는 문제는 서로 다르며 대체 관계가 아닙니다.

한 줄로 정리하면: 만능 프로토콜은 없으며, 목표가 다른 트레이드오프만 존재합니다. 1세대는 단순함과 자원 절약, 2세대는 유연성, 3세대의 위장 노선은 깔끔한 트래픽 특징, 기반 교체 노선은 열악한 네트워크에서의 성능이 강점입니다. 선택이란 결국 사용 시나리오를 이 목표 중 하나에 맞추는 일입니다.

B여섯 프로토콜 상세 분석

이 장에서는 프로토콜별로 설계 요점, 핵심 파라미터, 적용 범위를 설명합니다. 모든 파라미터명은 Clash 계열 설정 파일(YAML)의 필드를 기준으로 하며, 예시 값은 모두 자리표시자로 실제 연결에 사용할 수 없습니다.

Shadowsocks(SS)

가장 간결한 방식입니다. 현재 구현은 통일된 AEAD 암호화 스위트(일반적으로 aes-128-gcm, aes-256-gcm, chacha20-ietf-poly1305)를 사용해 기밀성과 무결성 검증을 동시에 보장합니다. 파라미터는 서버 주소, 포트, 암호화 방식, 비밀번호 네 가지뿐이라 설정 오류가 거의 발생하지 않습니다. CPU와 메모리 사용량이 여섯 프로토콜 중 가장 낮아 오래된 기기와 임베디드 환경에 친화적입니다. 단점도 명확합니다. 트래픽은 암호화되지만 어떤 프로토콜 위장도 하지 않으며, 프로토콜 자체에 멀티플렉싱도 없어 연결마다 별도로 수립됩니다. 설정 예시는 다음과 같습니다.

proxies:
  - name: "ss-example"
    type: ss
    server: node.example.com
    port: 8388
    cipher: aes-256-gcm
    password: "your-password"

Vmess

V2Ray 생태계의 핵심 프로토콜입니다. 신원 인증은 UUID 기반이며, 초기 버전은 클라이언트와 서버의 시간 차이가 약 90초를 넘지 않도록 요구했습니다 — 시간 동기화 오류는 Vmess 노드가 연결되지 않는 전형적인 원인 중 하나입니다. alterId는 구버전에서 남은 필드로, 현행 AEAD 인증 방식에서는 0으로 설정해야 합니다. Vmess의 진정한 가치는 전송 계층 조합에 있습니다. network 필드는 tcp / ws / h2 / grpc를 선택할 수 있고, 여기에 tls: true로 외부 암호화를 추가할 수 있습니다. 그중 WebSocket + TLS가 가장 널리 쓰이는 조합인데, 표준 웹 서버 뒤에 걸어 443 포트를 재사용할 수 있기 때문입니다. 파라미터가 많다는 것은 문제 지점도 많다는 뜻으로, 경로(ws-opts.path), Host 헤더, SNI 중 어느 하나라도 서버 측과 일치하지 않으면 핸드셰이크가 실패합니다.

Trojan

"위장" 노선의 직접적인 구현체입니다. Trojan은 자체 암호화를 만들지 않고, 전체 세션이 실제 TLS 연결 그 자체이며 서버는 유효한 인증서를 보유하고 인증은 오직 비밀번호 해시로만 이루어집니다. 인증에 실패한 접속은 실제 웹사이트로 폴백(fallback)되므로, 외부에서 관찰하면 Trojan 서버는 일반 HTTPS 사이트와 동일하게 동작합니다. 클라이언트 파라미터는 매우 적어 주소, 포트, 비밀번호, SNI뿐입니다. skip-cert-verify 필드에 주의해야 하는데, 이는 인증서 검증을 건너뛰는 옵션으로 자체 서명 인증서를 쓰는 테스트 환경에만 사용해야 합니다.

VLESS

"내부 암호화를 제거한 Vmess"로 이해할 수 있습니다. 외부에 이미 TLS가 있으므로 프로토콜 내부에서 다시 암호화하지 않고 UUID 인증과 최소한의 프로토콜 헤더만 유지해, 한 번의 암복호화에 드는 CPU 비용을 줄입니다. VLESS는 반드시 TLS 계열 전송과 함께 사용해야 하며 단독으로는 동작하지 않습니다. flow 필드(예: xtls-rprx-vision)는 TLS 위에 TLS를 씌우는 상황에서 발생하는 중복 암호화 문제를 한층 더 최적화한 것으로, 현재 저부하 방향의 주류 방식 중 하나입니다. 핵심 제약: VLESS는 오리지널 Clash 코어에서 지원하지 않으며, mihomo(Clash Meta) 계열 코어만 이를 해석할 수 있습니다. 자세한 내용은 E장을 참고하세요.

Hysteria2

"기반 교체" 노선의 대표주자입니다. QUIC 기반으로 구축되어 인증은 비밀번호 하나만 필요하며 설정 복잡도는 Shadowsocks에 가깝습니다. 핵심 차이는 혼잡 제어에 있습니다. 전통적인 TCP의 손실 시 후퇴 전략에 의존하지 않고, 설정값 또는 탐지된 대역폭에 맞춰 지속적으로 전송하여 고손실·고지연 링크에서 TCP 계열 프로토콜보다 훨씬 높은 실제 처리량을 유지할 수 있습니다. 대가는 링크 대역폭을 다소 적극적으로 점유한다는 점이며, 일부 네트워크 환경은 UDP 트래픽에 속도 제한이나 폐기 정책을 적용해 이런 네트워크에서는 성능이 눈에 띄게 떨어집니다. 설정 예시는 다음과 같습니다.

proxies:
  - name: "hy2-example"
    type: hysteria2
    server: node.example.com
    port: 443
    password: "your-password"
    sni: node.example.com

TUIC

역시 QUIC 기반이지만, 설계 목표는 "높은 처리량"보다 "낮은 지연"에 가깝습니다. TUIC는 QUIC의 0-RTT 기능을 활용해 재연결 시 첫 데이터 패킷에 요청을 실을 수 있어 핸드셰이크 지연이 거의 0에 가깝습니다. UDP 트래픽에 네이티브 전달 모드(udp-relay-mode: native)를 제공해 게임, 실시간 음성처럼 지연 흔들림에 민감한 애플리케이션에 적합합니다. Hysteria2와 마찬가지로 UDP 통로에 의존하므로 UDP를 제한하는 네트워크에서는 동일하게 영향을 받습니다. 지원 범위 역시 mihomo 계열 코어에 한정됩니다.

C연결 속도와 처리량 비교

"어떤 프로토콜이 빠른가"는 세 가지 독립적인 지표로 나눠 봐야 합니다. 핸드셰이크 지연(새 연결 수립에 몇 번의 왕복이 필요한가), 안정적 처리량(대역폭을 얼마나 채울 수 있는가), 열악한 네트워크에서의 저하 정도(손실 시 얼마나 떨어지는가). 세 지표의 순위는 서로 일치하지 않습니다.

핸드셰이크 지연

TCP 계열 프로토콜(SS, Vmess, Trojan, VLESS)은 새 연결을 만들 때 최소 한 번의 TCP 핸드셰이크가 필요하고, TLS 1.3을 얹으면 왕복이 하나 더 늘어 합계 약 2 RTT입니다. QUIC 계열 프로토콜(Hysteria2, TUIC)은 전송 핸드셰이크와 암호화 핸드셰이크를 통합해 첫 연결이 약 1 RTT이며, 세션을 재사용할 때 TUIC는 0-RTT까지 가능합니다. 웹 브라우징처럼 "짧은 연결이 많은" 부하에서는 이 핸드셰이크 차이가 페이지 첫 바이트 도착 시간에 그대로 드러납니다.

안정적 처리량

링크 품질이 좋을 때 여섯 프로토콜의 처리량 차이는 매우 작으며, 병목은 대개 프로토콜이 아니라 노드 대역폭에 있습니다. 프로토콜 측에서 체감할 수 있는 차이는 두 가지입니다. 첫째는 암호화 오버헤드로, AES 하드웨어 명령을 지원하는 기기에서는 aes-*-gcm이 거의 무료이며 VLESS의 vision 흐름 제어는 중복 암호화까지 절약할 수 있습니다. 둘째는 헤드 오브 라인 블로킹으로, TCP 위에서 멀티플렉싱할 때 하나의 손실이 동일 연결 내 모든 스트림을 막지만 QUIC는 스트림들이 서로 독립적이라 이 문제가 없습니다.

열악한 네트워크에서의 저하

고손실 환경은 QUIC 계열 프로토콜의 주무대입니다. TCP의 혼잡 제어는 손실을 혼잡으로 해석해 속도를 크게 낮추며 원거리 고지연 링크에서 특히 두드러집니다. Hysteria2의 대역폭 기반 전략은 동일한 손실률에서 몇 배에 달하는 유효 처리량을 유지할 수 있습니다. 반대로 UDP가 제한된 네트워크에서는 TCP 계열 프로토콜이 오히려 더 안정적입니다.

참고로, 클라이언트 노드 목록에 표시되는 "지연" 숫자는 테스트 주소로 HTTP 요청을 한 번 보내는 데 걸린 총 시간으로, 현재 링크 상태를 반영할 뿐 프로토콜의 우열을 나타내지 않습니다. 동일한 노드라도 시간대에 따라 측정된 지연이 흔들리는 것은 프로토콜 종류와 거의 무관합니다. 지연 숫자가 비정상일 때의 점검 방법은 블로그 《Clash 노드 타임아웃 연결 불가 점검 순서》를 참고하세요.

D리소스 사용량과 모바일 배터리 성능

데스크톱에서는 여섯 프로토콜의 리소스 차이를 거의 느낄 수 없지만, 스마트폰에서는 프로토콜과 실행 모드 선택이 배터리 통계에 직접 나타납니다. 배터리에 영향을 주는 요인은 비중 순으로 실행 모드 > 연결 유지 전략 > 암호화 오버헤드입니다.

CPU와 암호화 오버헤드

최신 스마트폰 SoC는 대부분 AES 하드웨어 명령을 탑재해 aes-128-gcm / aes-256-gcm의 암복호화 비용이 매우 낮습니다. chacha20-ietf-poly1305는 AES 명령이 없는 오래된 기기를 위해 설계된 것으로, 최신 기기에서는 오히려 다소 느립니다. VLESS는 내부 암호화를 제거했기 때문에 단위 트래픽당 CPU 소모가 여섯 프로토콜 중 가장 낮습니다. QUIC 계열 프로토콜의 프로토콜 스택은 사용자 영역에서 실행되므로, 대용량(장시간 고화질 영상, 대용량 파일 전송) 시나리오에서 CPU 사용량이 TCP 계열보다 눈에 띄게 높아지며, 이 오버헤드는 스마트폰에서 발열과 배터리 소모로 이어집니다.

연결 유지와 백그라운드 동작

모바일 네트워크에서는 장기 연결이 NAT 매핑을 유지하기 위해 주기적인 하트비트가 필요하며, 매번의 하트비트가 짧게 베이스밴드를 깨웁니다. TCP 계열 프로토콜은 시스템 프로토콜 스택의 연결 유지에 의존해 동작이 비교적 절제되어 있습니다. QUIC 연결의 유지는 애플리케이션 계층이 담당하며 구현마다 하트비트 간격 차이가 큽니다. 백그라운드에 오래 두고 메신저 위주로 사용하는 일상적인 시나리오에서는 SS / Trojan 같은 "조용한" 프로토콜의 배터리 성능이 보통 더 좋습니다. Hysteria2 / TUIC는 포그라운드에서 집중적으로 사용하는 시간대에 더 적합합니다.

실행 모드의 영향

프로토콜 선택보다 더 큰 영향을 주는 것은 실행 모드입니다. 시스템 프록시 모드는 프록시 설정을 따르는 앱의 트래픽만 처리하고, TUN 모드는 시스템의 모든 트래픽을 인계받아 모든 패킷이 클라이언트 프로세스를 거치므로 상시 CPU 점유율과 메모리 점유율이 모두 더 높습니다. iOS 플랫폼에는 추가 제약이 있는데, 네트워크 확장 프로세스에 엄격한 메모리 상한이 있어 규칙 세트와 구독 용량이 너무 크면 확장 프로세스 재시작이 유발될 수 있습니다. 특정 앱만 인계할 필요가 없다면 모바일에서는 시스템 프록시 모드를 우선 사용하는 것이 좋습니다.

E코어 계보: 오리지널, Premium, mihomo

"Clash"라는 단어는 실제로 코어 계보 전체를 가리키며, 클라이언트마다 내장된 코어가 달라 인식 가능한 프로토콜이 그대로 결정됩니다. 클라이언트를 고르기 전에 코어를 먼저 구분해 두면 "구독을 가져왔는데 노드가 사라졌다"는 문제를 대부분 피할 수 있습니다.

세 갈래의 관계

오리지널 Clash 코어가 모든 것의 시작점입니다. Go 언어로 작성된 오픈소스로, YAML 설정 형식과 정책 그룹, 규칙 분기라는 기본 모델을 확립했으며 당시 주류 프로토콜인 SS, Vmess, Trojan 등을 지원했습니다. 현재 저장소는 아카이브되어 더 이상 업데이트되지 않습니다. Premium은 원저작자가 오리지널을 기반으로 내놓은 비공개 빌드로, 주로 TUN 모드와 더 강력한 규칙 기능을 보강했으며 이 역시 발전을 멈췄습니다. Clash Meta는 커뮤니티가 오리지널이 아카이브되기 전후로 이어받아 유지한 브랜치로, 이후 mihomo로 이름을 바꿨습니다 — 현재 유일하게 활발히 활동 중인 브랜치이며 새로운 프로토콜 지원은 모두 이 라인에서 이루어집니다.

기능 차이 비교

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

클라이언트는 코어 바깥의 그래픽 인터페이스 껍데기이며, 코어가 프로토콜 능력을 결정하고 껍데기가 조작 경험을 결정합니다. 현재 활발한 클라이언트인 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, Clash Meta for Android는 모두 mihomo 코어를 기반으로 하여 여섯 가지 프로토콜을 전부 사용할 수 있습니다. 반면 Clash for Windows, ClashX Meta 등 유지보수가 중단된 클라이언트는 예전 코어나 예전 버전에 머물러 있어 새 프로토콜이 포함된 구독에는 권장하지 않습니다. 각 클라이언트의 자세한 장단점은 종합 비교에서, 설치 패키지는 클라이언트 다운로드 페이지에서 통일해서 받을 수 있습니다. mihomo와 오리지널 코어의 전체 차이 분석은 블로그 《mihomo 코어와 오리지널 Clash 코어 차이 상세 설명》을 읽어보세요.

F설정과 구독 형식 호환성

프로토콜과 코어 선택은 결국 하나의 질문으로 귀결됩니다. 지금 가진 구독이 이 클라이언트에서 완전히 로드될 수 있는가. 이 장에서는 구독의 흔한 형태와 코어 간 이전 시 호환성 요점을 설명합니다.

구독의 세 가지 형태

첫째는 Clash YAML 구독으로, proxies, proxy-groups, rules 세 부분을 포함하는 완전한 설정 파일이며 Clash 계열 클라이언트가 바로 가져올 수 있어 가장 권장되는 형태입니다. 둘째는 공유 링크 모음으로, ss://, vmess:// 등의 URI로 구성된 Base64 텍스트이며 여러 클라이언트에 범용적이며 Clash 계열 클라이언트가 가져올 때 클라이언트나 변환 서비스가 YAML로 번역합니다. 셋째는 다중 형식 엔드포인트로, 동일한 구독 주소가 요청자의 User-Agent에 따라 다른 형식을 반환하는 방식이며 서비스 제공자 측에서 흔히 볼 수 있습니다. 어떤 형태든 가져오기 절차는 튜토리얼 페이지의 첫 단계를 참고하세요.

코어 간 이전 요점

예전 코어에서 mihomo로 이전할 때는 대부분의 필드가 그대로 호환되어 YAML을 다시 작성할 필요가 없습니다. 반대 방향은 그렇지 않습니다. 설정에 예전 코어가 인식하지 못하는 type(예: vless, hysteria2, tuic)이 하나라도 포함되어 있으면 예전 코어는 해석 단계에서 오류를 내고 전체 설정 로드가 실패하며, 이는 "구독 업데이트 후 모든 노드가 사라짐"으로 나타납니다. 이는 Clash for Windows에서 현역 클라이언트로 이전하는 가장 흔한 계기 중 하나이기도 합니다. 구독이 proxy-providers로 외부 노드 목록을 참조하는 경우에도 동일한 규칙이 적용됩니다.

proxy-providers:
  main:
    type: http
    url: "https://example.com/subscribe-url"
    interval: 86400
    path: ./providers/main.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

흔한 로드 실패 원인

구독 가져오기는 정상인데 노드가 이상할 때는 순서대로 세 가지를 확인하세요. 첫째, 클라이언트 코어가 구독 안의 모든 프로토콜 유형을 지원하는지(텍스트 편집기로 구독을 열어 type: 필드를 검색해 확인). 둘째, YAML 들여쓰기가 재편집으로 손상되지 않았는지 — YAML은 들여쓰기에 민감해 공백 하나만 늘어도 해석에 실패합니다. 셋째, proxy-groups가 참조하는 노드 이름이 proxies 안의 name과 공백과 이모지까지 완전히 일치하는지. 구독 자체를 가져오는 데 실패한 경우(타임아웃, 403 등)의 처리는 자주 묻는 질문의 문제 해결 분류를 참고하세요.

G사용 시나리오별 프로토콜 선택 가이드

앞 장들의 결론을 이 장에서 바로 실행할 수 있는 선택표로 정리합니다. 전제는 구독에서 같은 서버가 여러 프로토콜 입구를 제공한다는 것으로, 대부분의 서비스 제공자가 그렇습니다. 구독에 단일 프로토콜만 있다면 이 장을 서비스 제공자와 소통하거나 요금제를 바꿀 때 참고 자료로 활용하세요.

일상적인 웹 브라우징과 업무

부하 특징은 짧은 연결이 많고 연결당 데이터량이 적다는 것입니다. Trojan 또는 VLESS가 균형 잡힌 선택으로, 핸드셰이크 비용이 감당할 만하고 트래픽 특징이 깨끗하며 CPU 사용량이 낮습니다. SS도 충분히 쓸 만하며 파라미터가 가장 적어 설정 오류가 가장 적습니다. 이 시나리오에서는 프로토콜 차이의 체감이 거의 없으므로 크게 고민할 필요가 없습니다.

고화질 스트리밍과 대용량 파일

부하 특징은 장시간 연결과 높은 지속 처리량입니다. 링크 품질이 좋으면 어떤 프로토콜이든 대역폭을 다 채울 수 있습니다. 원거리 고지연이나 피크 시간대 손실이 뚜렷할 때는 Hysteria2의 우위가 가장 크며, 동일한 링크에서 유효 처리량이 TCP 계열 프로토콜보다 훨씬 높은 경우가 많습니다. 사용 중인 네트워크가 UDP를 제한하지 않는지 확인해야 하며, 그렇지 않다면 Trojan / VLESS로 되돌아가세요.

모바일 네트워크 통근

셀룰러 네트워크는 신호 변동이 크고 기지국 전환이 빈번해 연결 재수립이 일상적입니다. QUIC 계열 프로토콜의 연결 마이그레이션과 낮은 핸드셰이크 비용이 여기서 가장 가치를 발합니다. TUIC의 0-RTT는 네트워크 끊김 복구를 거의 무감각하게 만듭니다. 배터리 절약이 우선이라면 D장의 결론을 참고해 대기 시간대에는 SS / Trojan, 집중 사용 시간대에 전환하세요.

게임과 실시간 회의

핵심 지표는 대역폭이 아니라 지연 흔들림이며 트래픽은 주로 UDP입니다. TUIC의 네이티브 UDP 전달이 우선 선택이며 Hysteria2가 그다음입니다. TCP 계열 프로토콜이 UDP를 전달하려면 추가 캡슐화가 필요해 흔들림 성능이 전반적으로 더 나쁩니다. 클라이언트 측에서는 TUN 모드와 함께 사용해 게임 프로세스의 UDP 트래픽이 인계되도록 하는 것이 좋습니다.

서버와 라우터 상시 운영

화면 없는 환경에서 mihomo 코어를 직접 실행하며, 프로토콜 선택은 안정성을 최우선으로 합니다. SS 또는 Trojan의 장기 안정성과 낮은 리소스 사용량이 24시간 상시 운영에 가장 적합합니다. 코어 설치 패키지는 다운로드 페이지의 코어 섹션에서 확인하세요. 공유기 등 ARM 기기는 해당 아키텍처에 맞는 빌드를 선택해야 합니다.

H흔한 오해와 문제 해결 진입점

오해 1: 프로토콜이 새로울수록 빠르다

프로토콜이 결정하는 것은 특정 조건에서의 동작 차이일 뿐, 절대적인 속도가 아닙니다. 링크 품질이 좋으면 여섯 프로토콜의 처리량은 거의 같습니다. Hysteria2는 양질의 링크에서 SS보다 빠르지 않으며, UDP가 제한된 네트워크에서는 오히려 더 느립니다. 병목이 어디에 있는지(노드 대역폭, 로컬 네트워크, 아니면 프로토콜과 네트워크의 궁합 문제인지) 먼저 확인한 뒤 프로토콜 교체를 논해야 합니다.

오해 2: 지연 숫자가 낮으면 체감이 좋다

노드 목록의 지연은 HTTP 왕복 한 번을 측정한 값이며 지속 처리량이나 손실률과 직접적인 관계가 없습니다. 50ms지만 피크 시간대 손실이 심한 노드는 실제 체감이 180ms지만 링크가 깨끗한 노드보다 훨씬 나쁠 수 있습니다. 노드 품질은 측정 숫자만 볼 게 아니라 실제 사용 중의 로딩 속도와 안정성을 함께 판단해야 합니다.

오해 3: 전역 모드가 더 안정적이다

전역 모드는 모든 트래픽을 프록시로 보내는 것일 뿐 어떤 연결 계층 문제도 해결하지 않으며, 오히려 원래 직접 연결되어야 할 트래픽까지 돌아가게 만들어 노드 장애의 영향 범위를 키웁니다. 규칙 모드와 합리적인 분기 규칙을 함께 쓰는 것이 일반적인 사용법이며, 전역 모드는 "규칙이 매칭되지 않은 게 아닐까"를 일시적으로 점검할 때 적합합니다.

오해 4: 암호화 계층이 많을수록 안전하다

VLESS가 내부 암호화를 제거한 것은 보안을 약화시킨 것이 아닙니다 — 외부의 TLS 1.3이 이미 완전한 기밀성과 무결성 보장을 제공하므로, 두 번째 대칭 암호화 계층을 얹어도 CPU 비용만 늘 뿐 방어력은 늘지 않습니다. 보안의 핵심은 인증서 검증이 켜져 있는지, 비밀번호 강도가 충분한지에 있으며 암호화 계층 수에 있지 않습니다.

문제 해결 진입점 모음

• 구독 업데이트 실패, 부팅 시 자동 시작, 모드 전환 등 자주 발생하는 문제: 자주 묻는 질문에서 분류별 표준 처리 절차를 정리해 두었습니다.
• 노드가 전부 또는 일부 타임아웃되는 경우: 블로그 《노드 타임아웃 연결 불가 점검 순서》에서 제시하는 고정된 순서로 단계별 점검하세요.
• 클라이언트 로그의 오류 메시지를 이해하기 어려운 경우: 《Clash 실행 로그 보는 법》을 참고해 오류 항목을 하나씩 대조하세요.
• 본문에 등장한 용어(AEAD, SNI, RTT, TUN 등)의 정의: 용어 사전에서 해당 분류를 찾아보세요.